CI/CD 보안: 빌드 및 배포 프로세스 보호
파이프라인 CI/CD 소프트웨어 제공 프로세스의 핵심입니다. 공격자라면 파이프라인을 손상시키고 이후의 각 빌드 및 배포에 악성 코드를 주입할 수 있습니다. 는 파이프라인 보안은 파이프라인이 테스트하는 것이 아니라 파이프라인이 자체적으로 테스트하는 방법에 관한 것입니다. 변조로부터 보호됩니다.
이 문서에서는 지점에서 CI/CD 파이프라인을 보호하기 위한 사례를 살펴보겠습니다. OIDC에서 최소 권한, 감사 로깅까지 서명된 커밋에 대한 보호 프로덕션 배포에 대한 승인 워크플로에 추가됩니다.
무엇을 배울 것인가
- CI/CD 파이프라인 위협 모델
- 지점 보호 및 코드 검토 시행
- 정적 비밀이 없는 인증을 위한 OIDC
- 실행기 및 워크플로에 대한 최소 권한
- 서명된 커밋 및 코드 검증 가능성
- 배포 승인 워크플로
CI/CD 파이프라인 위협 모델
파이프라인을 보호하려면 공격 표면이 어디에 있는지 이해해야 합니다.
- 소스 코드: 악의적인 기여자가 PR에 코드를 삽입합니다.
- 중독: 빌드 중에 손상된 종속성이 설치되었습니다.
- 파이프라인 구성: 비밀을 추출하기 위한 파일 워크플로 수정
- 달리는 사람: 인프라 지속성 빌드 에이전트 손상
- 유물: 아티팩트 빌드를 악성 빌드로 교체
- 자격 증명 배포: 인프라에 직접 접근하기 위한 배포 자격 증명 도난
지점 보호 규칙
Le 지점 보호 규칙 그들은 첫 번째 방어선입니다. 그들은 다음을 보장합니다 검토와 자동 확인 없이는 어떤 코드도 메인 브랜치에 도달하지 않습니다.
권장 구성
| 규칙 | 환경 | 동기 부여 |
|---|---|---|
| PR 검토 필요 | 최소 2개의 승인 | 네 눈의 원리 |
| 오래된 리뷰 닫기 | 활성화됨 | 푸시 후 승인 무효화 |
| 상태 확인 필요 | SAST, SCA, 테스트, 린트 | 필수 자동 게이트 |
| 서명된 커밋 필요 | 활성화됨 | 기여자 검증 가능성 |
| 푸시 액세스 제한 | CI/CD 봇만 해당 | 메인에 직접 푸시하지 않음 |
| 선형 이력 필요 | 활성화됨 | 깨끗하고 검증 가능한 이력 |
OIDC: 정적 비밀이 없는 인증
오픈ID 커넥트(OIDC) CI/CD 워크플로우를 통해 클라우드 인증 가능 정적 비밀(API 키, 서비스 계정 키)을 사용하지 않는 공급자입니다. 워크플로우는 다음을 얻습니다. 저장소와 지점의 ID를 기반으로 하는 임시 토큰입니다.
# .github/workflows/deploy-oidc.yml
name: Deploy with OIDC
on:
push:
branches: [main]
permissions:
id-token: write # Necessario per OIDC
contents: read
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Configure AWS Credentials (OIDC)
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/github-deploy
aws-region: eu-west-1
# Nessun secret! Il token OIDC viene usato automaticamente
- name: Deploy to AWS
run: |
aws s3 sync dist/ s3://my-bucket/
aws cloudfront create-invalidation --distribution-id E123 --paths "/*"
워크플로에 대한 최소 권한
각 GitHub Actions 워크플로에는 너무 광범위할 수 있는 기본 권한이 있습니다. 원리 최소 권한 권한을 최소한으로 제한해야 합니다. 각 직업에 필요한 것:
# Permessi globali restrittivi
permissions:
contents: read # Solo lettura del repository
jobs:
test:
runs-on: ubuntu-latest
# Nessun permesso aggiuntivo per i test
steps:
- uses: actions/checkout@v4
- run: npm test
deploy:
needs: test
runs-on: ubuntu-latest
permissions:
id-token: write # Solo per OIDC
contents: read
packages: write # Solo per push immagini
environment: production # Richiede approvazione manuale
steps:
- uses: actions/checkout@v4
- name: Deploy
run: ./deploy.sh
서명된 커밋
I 서명된 커밋 서명을 통해 기여자의 신원을 보장합니다. GPG 또는 SSH 암호화. 서명이 없으면 누구나 이름과 이메일로 커밋을 만들 수 있습니다. 임의적이고 다른 개발자를 사칭합니다.
# Configurare GPG per signed commits
gpg --full-generate-key
gpg --list-secret-keys --keyid-format=long
# Configurare Git per firmare automaticamente
git config --global user.signingkey YOUR_KEY_ID
git config --global commit.gpgsign true
git config --global tag.gpgsign true
# Alternativa: firmare con SSH key
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
배포 승인 워크플로
프로덕션 배포에는 명시적인 사람의 승인이 필요합니다. 승인됨. GitHub 환경을 사용하면 필수 수동 승인을 구성할 수 있습니다.
# Deploy con approvazione manuale
jobs:
deploy-staging:
runs-on: ubuntu-latest
environment: staging
steps:
- name: Deploy to staging
run: ./deploy.sh staging
deploy-production:
needs: deploy-staging
runs-on: ubuntu-latest
environment:
name: production
url: https://myapp.com
# Richiede approvazione da un reviewer designato
steps:
- name: Deploy to production
run: ./deploy.sh production
- name: Notify team
run: |
curl -X POST "${{ secrets.SLACK_WEBHOOK }}" \
-H "Content-Type: application/json" \
-d '{"text": "Production deploy completed successfully"}'
파이프라인 보안 강화 체크리스트
파이프라인 보안 체크리스트
- 필수 검토 및 상태 확인을 통한 지점 보호
- 클라우드 인증을 위한 정적 비밀 대신 OIDC
- 최소 워크플로 권한(최소 권한)
- 메인 브랜치에 필요한 서명된 커밋
- 태그 대신 SHA를 사용하여 작업 고정
- 수동 승인이 가능한 프로덕션 환경
- 모든 CI/CD 작업에 대한 활성 감사 로그
- 격리된 네트워크의 자체 호스팅 실행기(해당되는 경우)
- 파이프라인 구성에 대한 비밀 스캐닝
- 모든 빌드에서 SBOM이 생성되고 서명됨
GitHub 작업 고정
# INSICURO: usa un tag mutabile
- uses: actions/checkout@v4
# SICURO: usa il commit SHA (immutabile)
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
CI/CD 보안 모범 사례
- 어디서나 OIDC: 클라우드 공급자 인증을 위한 모든 정적 비밀을 삭제합니다.
- 최소한의 권한: 각 작업에는 필요한 권한만 있으며 그 이상은 없습니다.
- SHA의 핀 작업: 제3자 작업에 변경 가능한 태그를 사용하지 마세요.
- 별도의 환경: 다양한 구성 및 승인을 통한 준비 및 생산
- 모든 것을 감사하다: 모든 빌드, 배포, 승인 및 파이프라인 변경에 대한 로그
- 임시 주자들: 지속성을 방지하려면 각 작업마다 실행기를 다시 생성해야 합니다.
결론
CI/CD 파이프라인의 보안은 간과되는 경우가 많지만 이는 중요한 공격 벡터입니다. 손상된 파이프라인은 모든 후속 빌드에 악성 코드를 주입할 수 있습니다. 가지 포함 보호, OIDC, 최소 권한 및 배포 승인, 파이프라인 구축 탄력적이고 검증 가능합니다.
다음 기사에서는 살펴보겠습니다. IaC 스캐닝, 검증 방법 분석 보안 구성 오류를 방지하기 위한 Terraform, CloudFormation 및 ARM 구성.