Your build pipeline is not your trust boundary
AWS에 배포하는 팀이 CI 레지스트리와 프로덕션 레지스트리 사이에 독립적인 검증 게이트를 도입해 공급망 공격으로부터 프로덕션 환경 보호
AI 요약
Context
단일 레지스트리 아키텍처에서 CI 파이프라인이 직접 프로덕션 환경이 사용하는 레지스트리로 푸시하면, 빌드 환경과 프로덕션 환경이 동일한 신뢰 경계를 공유하게 된다. 이 경우 손상된 빌드 의존성, 악성 바이너리, 또는 우회된 보안 검사를 거친 컨테이너 이미지가 검증 없이 프로덕션에 배포될 수 있다. 공급망 공격이 CI 시스템을 대상으로 일상화되면서, '모든 파이프라인 상태가 정상'이어도 악성 이미지가 프로덕션에서 실행되는 상황이 발생한다.
Technical Solution
- 4개 격리된 영역으로 아키텍처 분할: GitLab CI 파이프라인(빌드만 담당) → GitLab Container Registry(임시 스테이징) → 검증 파이프라인(전용 게이트) → ECR(신뢰 신호) → ECS 배포
- CI 파이프라인의 권한 최소화: CI 러너는 GitLab 레지스트리에만 쓰기 권한을 가지며, AWS IAM, ECR, ECS 접근 권한 없음
- 독립적인 검증 게이트(Deliver Pipeline) 구성: 태그, 브랜치 머지, 또는 릴리스 이벤트 기준으로 트리거되며, 취약성 스캔, 서명 검증, 정책 체크, SBOM 증명 검증 수행
- ECR을 신뢰 신호로 재정의: ECR에 존재하는 이미지는 검증 파이프라인이 명시적으로 허용한 이미지만 존재하도록 강제, ECR 접근 정책으로 검증 파이프라인의 쓰기 권한과 ECS 태스크의 읽기 권한만 허용
- 배포 파이프라인의 단방향 실행: AWS 내부에서만 실행되며 ECR에서만 읽음, GitLab 레지스트리로 다시 나가지 않음
Key Takeaway
격벽 패턴의 핵심은 '이미지를 신뢰할 수 있다는 것이 무엇을 의미하는가', '누가 그 결정을 내리는가', '검증 실패 시 어떤 일이 일어나는가'를 명시적으로 정의하고, 이를 빌드 환경과 프로덕션 환경 사이의 필수 경로로 강제하는 것이다. 공급망 보안은 완벽한 빌드 환경으로 손상을 사전에 차단하는 것이 아니라, 손상이 프로덕션으로 전파되지 않도록 격리하는 아키텍처 결정에서 시작된다.
실천 포인트
AWS 기반 마이크로서비스를 배포하는 팀에서 CI 파이프라인과 프로덕션 레지스트리 사이에 독립적인 검증 파이프라인을 도입하면, CI 환경 침해 시 손상 범위를 스테이징 레지스트리로 제한할 수 있고, 검증을 통과하지 않은 이미지는 프로덕션 환경에 도달할 수 없도록 강제할 수 있다. 구현 시 ECR을 단순한 저장소가 아닌 신뢰 신호로 재정의하고, 각 영역의 권한을 명시적으로 제한하며, 검증 실패 시 진행을 중단하는 정책을 정의하는 것이 핵심이다.