![[번역] How to Secure Your Supply Chain at Scale](/images/posts/cloud_native_sec_title.png)
클라우드 네이티브 보안과 관련하여 글로벌 SW기업의 BP사례를 찾아보던 중 아주 좋은 자료로 생각되어 내용을 공유합니다.
- 원본 영상 주소 : How to Secure Your Supply Chain at Scale - Hemil Kadakia & Yonghe Zhao, Yahoo
- 발표 자료 : HowToSecureSupplyChain_2023.pdf
야후의 클라우드 네이티브 운영 환경
- 발표자는 세계 상위 10위 안에 드는 방문자 수를 기록하는 yahoo.com을 지원하고 있음
- 내부적으로는 약 60,000개의 빌드 작업이 실행되고 매일 약 5,000개의 이미지가 레지스트리에 게시됨
- 동시에 700개 이상의 Kubernetes 클러스터가 운영되고 있으며, 100,000개 이상의 파드가 존재
- 이는 Yahoo의 소프트웨어 전체를 의미하는 것은 아니며 Kubernetes 클러스터에 배포되지 않는 기타 다양한 유형의 아티팩트들, 예를 들어 온프렘 가상 머신으로의 배치도 있음
- 따라서, Yahoo의 인프라 구조는 규모 면에서뿐만 아니라 튜닝 선택의 면에서도 대단히 큼
코드에서 빌드까지
- Yahoo 내부에서는 다양한 요구 사항과 필요를 가진 다양한 팀이 있으며, 각 팀은 소프트웨어를 배포하기 위한 자신들만의 경로를 가질 수 있음
- 위 다이어그램은 Yahoo에서 사용 중인 주요 도구들, 소스 코드 관리 도구부터 빌드 시스템, 아티팩트 저장소, 그리고 마지막으로 배포 환경까지를 표시
- 도구의 다양성으로 인해 Yahoo에서의 소프트웨어 보안을 확보하는 것은 도전적인 과제였으며, 이를 위해 우리는 당면한 문제를 단순화 해야 했음
- GitHub Enterprise를 소스 코드 관리 도구로, Screwdriver를 빌드 파이프라인으로, 내부 사이트 레지스트리를 아티팩트 저장소로, 마지막으로 Kubernetes를 배포 환경으로 선택함
여행을 시작하며
- 소프트웨어의 보안은 많은 측면을 고려해야 하며 단 하나의 경로만 있더라도, 여러 보안 통제 및 모범 사례를 따라야 함.
- 다행히도, 우리는 처음부터 시작할 필요가 없음. 왜냐하면 이미 기본적인 정적 코드 스캐닝, 레포 브랜치 생산과 같은 보안 컨트롤을 갖추고 있기 때문
- 기존에 있던 보안 통제 방법과 오픈 소스 표준을 평가한 후, 우리는 세 가지 주요 격차를 깨달았음
- 첫째, 정적 코드 스캔이 있다 하더라도 취약점이나 오픈 소스 종속성을 감지할 수 없으므로 이 격차를 해결하기 위해 SCA를 도입하기로 결정
- 둘째, 코드가 리포지토리에서 릴리스된 후 소프트웨어를 확인하고 배포를 차단할 수 없으므로, SDLC에 두 개의 체크포인트(빌드 및 배포 단계)를 추가하기로 결정.
SCA 도구
- 기존의 코드 스캐닝은 코드의흐름과 논리를 살펴보고 취약점을 판단
- 하지만 잠재적인 취약점이 있는지, 오픈 소스 종속성이 어떻게 이루어지는지는 살펴보지 않음
- 따라서 이러한 문제를 해결하기 위해 SCA 도구가 오픈 소스 종속성에만 집중하여 검사
- SCA는 오픈 소스 의존성, 패키지 이름과 주소를 식별하고 취약성 데이터베이스를 확인한 다음 문제를 발견하면 알려줌
- 또한 오픈 소스 종속성의 버전을 업데이트 하기 위해 PR(Pull Request)을 제기할 수 있으며, 이를 통해 대부분의 경우 잠재적인 취약성을 수정 가능
- 따라서 이러한 도구를 적용함으로써 취약성을 탐지의 진전을 이룰 수 있으며 애플리케이션 코드를 훨씬 쉽게 수정 가능
빌드 타임 취약점 분석 (이미지 스캔)
- 그러나 Kubernetes 클러스터에 배포될 이미지에는 항상 애플리케이션 바이너리 이외의 구성 요소(예: 기본 운영 체제 및 추가할 수 있는 다른 패키지)가 포함됨
- 따라서 전체 이미지를 스캔할 수 있는 빌드 타임 취약점 평가가 매우 중요
- 이를 통해 애플리케이션 코드에서 해결되지 않은 취약점뿐만 아니라 빌드 과정에서 통합된 실제 구성 요소의 문제도 파악할 수 있음
- 실제로 Grype와 Trivy를 사용하여 SBOM및 취약점 데이터를 생성하여 평가를 수행
- 또한 심각한 취약성을 발견한 경우 특정 파이프라인을 차단하는 옵션도 제공
- 따라서 다음에 또 다른 Log4j 위기가 발생할 경우 신속하게 조치를 취하고 취약한 이미지가 레지스트리에 게시되는 것을 방지할 수 있음
프로덕션 배포 단계에서의 검증
- 마지막 배포 단계에서 배포될 이미지에 대한 보안 검증을 수행
- 이미지가 서명되지 않았거나 신뢰할 수 없는 레지스트리의 이미지이거나 해결되지 않은 취약점이 있는 경우 배포를 차단하거나 최소한 엔지니어에게 해당 위반 사항을 알림
- 배포 단계에서 검증을 위해 Kubernetes의 dynamic admission control을 활용
- 이를 통해 사전 정의된 정책에 따라 admission request를 수신하고 정책을 확인한 다음, 최종적으로 리소스를 배포할지 여부를 결정할 수 있는 HTTP 워크로드를 구현
- 실제로 Yahoo가 개발한 웹후크와 OPA (Open Policy Agent)를 모두 사용하여 이 목표를 달성
이미지 출처 보장
- Provenance는 이미지의 출처를 알려주는 다양한 기록의 집합
- 누가 코드를 커밋했는지, 이 이미지의 원래 출처인 리포지토리 및 브랜치, 빌드 정보 등이 포함될 수 있음
- GitHub, Screwdriver, 레지스트리에서 출처 데이터를 수집하여 provenance 데이터베이스에 저장
- provenance 저장소는 프로세스 포맷과 API, 백엔드 솔루션을 표준화하는 오픈소스 프로젝트인 Grafeas를 기반
배포 검증 데모 시연
- 세가지 이미지로 데모 시연
- 첫 번째 이미지는 출처 정보가 없는 케이스
- 두 번째 이미지는 완전한 출처 정보를 가지고 있지만 약간의 문제가 있는 케이스
- 세 번째 이미지는 완전한 출처 정보를 가지고 있는 케이스
- 첫 번째 이미지: 이 이미지는 공격자가 예상되는 CI/CD 파이프라인을 통과하지 않고 직접 레지스트리에 업로드
- 이 경우 webhook이 데이터베이스에서 어떤 출처 정보도 가져올 수 없기 때문에 배포를 거부
- 이 케이스는 리소스 저장소 또는 빌드 작업 정보가 없음을 확인할 수 있음
- 두 번째 이미지: 이 이미지는 악의적인 변경이 포함된 포크된 저장소에서 빌드되고 업로드됨
- 이 경우 이미지에 출처 정보가 있지만 이미지가 포크된 저장소에서 왔다는 정보가 표시
- 따라서 오류 메시지에서 볼 수 있듯이 “소스 리포지토리 불일치”라고 표시되며 webhook이 배포를 거부
- 세 번째 이미지: 마지막으로 이 이미지는 신뢰할 수 있는 레지스트리에 있는 신뢰할 수 있는 소스 코드 및 파이프라인에서 빌드됨
- 이 경우 이미지에는 완전한 출처 정보가 있으며, 출처 정보에 문제가 없으므로 webhook이 배포를 허용
이미지 서명 검증 + 데모
- 두 번째 검사는 이미지 서명
- 빌드 시스템에서 이미지에 서명이 되었는지 확인하며 이는 이미지의 무결성과 배포자를 검증하는데 도움이 됨
- 야후는 현재 자체 관리하는 장기간 사용 키(long-lived keys)를 사용하여 특정 이미지에 서명하며, 이 서명 파일은 이미지를 빌드하고 배포하는 대부분의 표준 템플릿에 통합되어 있음
- 서명 메커니즘은 오랫동안 존재해 왔지만 배포 전에 서명을 확인하는 시행(enforcement) 과정이 없었음
- 따라서 이 검사를 강제함으로써 해당 부분의 보안을 강화할 수 있음
- 서명 검사는 webhook에 직접 통합되어 있음.
- 첫 번째 이미지는 빌드 파이프라인에서 서명되지 않았기 때문에 webhook은 이 이미지에 연결된 서명을 서명 데이터베이스에서 찾을 수 없음. 따라서 배포를 거부
- 두 번째 이미지는 빌드 시스템에서 서명되었으므로 webhook이 배포를 허용
이미지 신선도(?) 체크
- 이 검사의 주요 목적은 사람들이 이미지를 정기적으로 업데이트하도록 장려하는 데 있음
- 오래된 이미지는 일반적으로 더 많은 취약점을 가지고 있고, 오랫동안 이미지를 업데이트하지 않으면 보안 수정을 해야 할 시점에 이르러 패치가 너무 구식이거나 변경에 따른 리스크가 높아질 수 있기 때문
- 이미지를 정기적으로 업데이트하면 빌드 파이프라인도 실행되므로 빌드 파이프라인의 문제를 제때 발견할 수 있음
- “이미지 최신성” 검사를 위해서는 KubeArmor와 KubeArmor 정책을 활용
- 이 검사를 위한 KubeArmor 정책은 6개월 이상 전에 빌드된 이미지를 차단
- 이 정책은 KubeArmor 공식 웹사이트에서도 찾을 수 있음
- 첫 번째 이미지는 약 1년 전에 빌드되어 너무 오래 되었음 따라서 KubeArmor는 6개월 기한을 초과했다는 이유로 이 이미지를 거부
- 다른 이미지는 한 달 이내에 빌드되었으므로 KubeArmor는 배포를 허용
추가적인 배포단계의 검증 수단들
- 배포 또는 빌드 단계에서 검사는 결코 완벽한 방식은 아님
- 필요한 데이터를 기반으로 거의 모든 정책을 평가하도록 선택할 수 있음
- 예를 들어, 배포 시 취약점 검사를 수행하고 싶다면 실제로는 Grafeas 데이터베이스에 취약점 데이터를 저장하여 webhook이 출처 데이터와 함께 이 취약점 데이터를 가져와 검증할 수 있도록 할 수 있음
- 나머지 두 가지 검사는 단일 정책을 적용하여 수행할 수 있음
야후의 여정
- 지금까지 사용해 온 도구와 현재에 도달하기 위한 과정을 간략하게 요약하고자 함
- 2020년 중반 이 여정을 시작했을 때, 사용 가능한 오픈소스 도구와 솔루션이 많지 않았음
- 따라서 많은 내부 툴링을 구축하고, provenance 저장소로 Grafeas를 사용함
- 2021년 중반에는 대부분의 소스 출처 데이터(provenance)를 수집할 수 있었고, 빌드 파이프라인을 통해 생성되는 약 10%의 빌드 출처 데이터도 수집
- 2021년 후반에는 Grafeas RDS를 오픈소스로 공개하였으며 이는 Postgres 데이터베이스에 대한 Grafeas 지원을 추가
- 2022년 초에는 Sigstore가 컨테이너 이미지 서명 및 소프트웨어 검증을 위한 유망한 솔루션으로 부상
- 따라서 일부 빌드 파이프라인에 대해 Sigstore를 내부적으로 탐색하기 시작
- 이와 함께 앞서 보여준 배포 검사 기능도 추가하였으며 이를 위해 KubeArmor와 Yahoo의 자체 정책을 사용
- 올해(2023년)에는 기존 빌드 파이프라인에 Cosine의 일부 기능을 통합했으며, Syft와 Grype가 생성하는 S-Bomb 데이터를 시각화하기 위해 Guac에도 작업 진행중
Lessons Learned
- 야후의 다양한 팀이 서로 다른 프로젝트와 도구로 작업하는 하이브리드 환경을 고려할 때, 우리는 여정에서 몇 가지 흥미로운 도전과제와 배움을 얻었음
- 기존 개발자 워크플로를 자동으로 향상시키기
- 도구가 백그라운드에서 작동하거나 다른 도구와 통합될 수 있다면, 개발자의 온보딩 및 학습 노력이 줄어듬
- 이를 통해 보안팀과 개발팀 간의 마찰을 줄일 수 있음
- 개발자는 프로젝트를 정기적으로 업데이트할 필요가 없으며 보안 작업은 behind에서 수행될 수 있기 때문
- 이것은 또한 시장 출시 시간 또는 실제 배포 시간을 줄이는 데 도움이 됨
- 이 교훈의 한 예는 앞서 언급했듯이 출처(provenance) 수집을 시작했을 때임. Grafeas를 사용했기 때문에 소스 메타데이터 수집을 GitHub 웹후크의 일부로 통합했으며, 빌드 메타데이터를 가져오기 위해 빌드 다운 단계와 통합함
- 이렇게 하면 Yahoo에서 실행되는 모든 빌드가 Grafeas 저장소로 provenance를 보낼 수 있었으며 약 70~80%의 출처 정보를 얻을 수 있었음
- 나머지 20%는 표준 도구를 사용하지 않기 때문
- 동일한 작업을 Admission Webhook에 적용했을 때, 많은 개별 팀과 소유자가 자체 클러스터를 실행하고 있었고, webhook를 클러스터에 추가하기 위해서는 개별 팀과 협력해야 했음
- 부서간 우선 순위가 달랐기 때문에 많은 시간이 걸렸고, 결국 webhook를 기본값으로 설정하는 데 약 6개월이 소요됨
- 회사 도구 및 서비스 채택
- 회사 전체의 Admission Webhook과 같은 도구 및 서비스의 채택과 관련하여 우리가 배운 가장 중요한 것 중 하나
- 회사의 일부가 이러한 도구의 온보딩을 하지 않더라도, 여전히 소프트웨어 공급망 공격에 취약할 수 있음
- 따라서 회사의 모든 사람이 Admission webhook을 사용하도록 보장해야 함
- 이를 위해 EKS 배포의 기본값으로 Webhook을 설정했지만, 비표준 도구나 다른 배포를 사용하는 다른 팀도 있었음
- 온보딩을 위해 Helm 차트를 생성하여 수동으로 설치할 수 있도록 하거나, 실제 도입 여부를 확인해야 했음
- 이는 여전히 해결 과제이며 우리는 회사 내 채택률을 높이기 위해 계속 노력하고 있음
- 사전 계획 및 프로젝트 가시성 보장
- 경영진에게 비즈니스 가치를 전달해야 하는 경우, 이해 관계자에게 프로젝트의 주기적인 상태 업데이트가 중요
- 전체적인 사명을 전달하는 것과 함께 프로젝트의 점진적인 가치도 보여주어야 함
- 오픈소스 기술 활용
- 우리가 소프트웨어 공급망 보안에 사용하는 많은 솔루션이나 도구는 이미 오픈소스 도구로 제공됨
- 오픈소스 기술을 채택하는 것은 매우 중요. 오픈소스 커뮤니티와 교류하고 의미 있는 기여를 하면 전문성이 높아지고 커뮤니티에 되돌려 줄 수 있음
- 지속적인 피드백
- 솔루션에 대한 지속적인 테스트를 수행하고 이해관계자들로부터 정기적인 피드백을 받는 것이 중요
- 요구사항과 사용 사례를 충족하는 것은 프로젝트 성공에 필수적
Comments