Google의 방식: Binary Authorization을 사용한 공급망 보안 강화

해당 블로그의 원문은 2025년 11월 22일 Google Cloud 블로그(영문)에 게재되었습니다. 

Google은 보안을 어떻게 할까요? 새로운 "Google의 방식" 시리즈의 일환으로, 오늘날 가장 시급한 보안 주제, 과제, 우려 사항에 대해 Google이 어떻게 접근하는지에 대한 통찰력, 관찰 내용, 그리고 최고의 팁을 Google 전문가들이 직접 공유합니다. 이번 편에서는 클라우드 보안 아키텍트인 대니얼 리스(Daniel Lees)가 Google이 Binary Authorization을 사용하여 소프트웨어 공급망에서 어떻게 코드 출처를 확인하고 코드 ID를 구현하는지 공유합니다.

동적인 환경과 컨테이너화된 워크로드가 일반화된 오늘날, 조직들은 신뢰할 수 있는 리포지토리, 코드 검토, 그리고 소프트웨어 개발 프로세스에 보안을 통합하는 데 많은 훌륭한 투자를 하고 있습니다. 소프트웨어 빌드가 프로덕션 환경에 배포될 때 안전한지 확인하기 위해, 저희는 다음과 같은 단순한 원칙에서 시작합니다: 신뢰하지 말고, 검증하라.

그 원칙은 저희가 전체 소프트웨어 공급망을 보호하는 방법을 안내합니다. 실용적인 차원에서, 모든 구성 요소가 저희의 보안 모범 사례와 표준을 충족하도록 보장하기 위해, 저희는 Binary Authorization을 사용합니다. 이 강제 검사는 모든 프로덕션 소프트웨어와 구성이 적절히 검토되고, 소스 코드 저장소에 반영(check in)되며, 검증 가능하게 빌드되고, 승인되었는지 확인하는 데 도움을 줍니다. 특히 해당 코드가 민감한 사용자 데이터에 접근할 수 있을 때 이는 더욱 중요합니다.

Binary Authorization이 공급망 리스크 완화에 기여하는 방식

소프트웨어 공급망 공격에서 공격 지점은 소프트웨어 개발 수명 주기 전반에 흩어져 있습니다. SolarWinds, Log4shell, Codecov는 헤드라인을 장식한 대표적인 사례로, 공격자들이 소프트웨어 빌드 시스템을 표적으로 삼고, 개발에 사용되는 서드파티 라이브러리나 다른 구성 요소의 취약점을 악용하며, 업데이트를 손상시키고, 지속적 통합 및 지속적 전달(CI/CD) 파이프라인에 침투하는 것을 보여줍니다.

Google에서는 내부 클러스터 관리 시스템인 Borg가 Google 검색에서부터 지도, YouTube에 이르기까지 모든 것을 구동하며, 이를 통해 저희는 일주일에 40억 개 이상의 컨테이너를 실행할 수 있습니다. Binary Authorization은 단일 장애 지점(single point of failure)이 치명적인 재앙으로 이어지는 것을 방지함으로써, Google이 요구하는 규모에서 안전하게 운영되도록 돕는 데 매우 중요합니다.

프로덕션 배포가 중앙 빌드 파이프라인에서 빌드되고, 취약점 스캐너로 검사되며, QA 엔지니어의 승인을 받아야 하는 정책을 생각해 보세요. 만약 공격자가 취약점 스캐너를 손상시키더라도, 이미지가 배포되기 전에 반드시 검증되어야 하는 다른 규칙들이 여전히 남아 있습니다.

Binary Authorization은 규정 준수(컴플라이언스)에도 도움이 됩니다. 오늘날 많은 조직들은 자신들이 어떤 코드를 배포하고 있는지, 그리고 그 코드가 민감한 정보에 접근하는지 파악해야 합니다. 이제는 조직이 코드를 신중하게 검토하도록 요구하는 광범위한 규제들이 존재하며, CI/CD 환경에서 수동 프로세스에 의존하여 출처를 확인하는 것은 어려울 수 있습니다.

Google에서는 Binary Authorization을 사용하여 운영 효율성과 제어 능력을 크게 향상시킵니다. 이는 배포 전에 컨테이너화된 시스템을 검증하여 프로덕션 시스템 전반에 걸쳐 일관성을 확립하고, 이를 통해 변경 관리를 간소화하며 신뢰성을 높였습니다.

더욱이, Binary Authorization은 적합성 데이터를 추적하고 게시함으로써 데이터 보호를 위한 공통 언어를 도입하여, 팀 간 커뮤니케이션을 원활하게 하고 불필요한 중복 업무를 줄였습니다. 또한, 사베인스-옥슬리법(Sarbanes-Oxley, SOX)과 같은 규정 준수 요건을 프로그래밍 방식으로 추적하고, 이전에는 수동으로 해야 했던 검사를 자동화하여 규정 준수 범위와 필수 통제 조치의 도입을 확대했습니다.

Binary Authorization의 작동 원리

여러분의 프로덕션 환경을 공항의 보안 구역이라고 생각해 보세요. 비행기에 탑승하기 위해, 여러분은 단순히 위협이 아니라고 "약속"하지 않습니다. 여러분은 유효한 신분증과 탑승권(증명)을 제시해야 하며, 이는 담당자(집행자)에 의해 일련의 규칙(정책)에 따라 검증됩니다.

Binary Authorization이 바로 여러분의 소프트웨어를 위한 그 담당자입니다. 그것은 신뢰하지 않고, 검증합니다. 컨테이너가 실행되기 전에, 그것은 유효한 ID와 "탑승권", 즉 모든 필수 검사를 통과했음을 증명하는 암호화 서명 세트(증명(attestation))를 제시해야 합니다. 이 과정은 결함이 있거나, 취약하거나, 승인되지 않은 코드가 여러분의 프로덕션 환경에 들어오는 것을 막아줍니다.

컨테이너 기반 아키텍처의 핵심 보안 문제 중 하나는 무엇이 실행되고 있으며 어디서 왔는지 파악하는 것입니다. 빠른 속도, 성능, 유연성은 더 많은 변경을 만들어내고, 이로 인해 승인된 소프트웨어만 배포하는 것을 보장하기 어렵게 만듭니다. 특히, 코드의 출처를 신뢰할 수 있는 기점으로 추적하고 원하는 모든 검증 단계가 완료되었는지 확인할 수 있는 능력, 즉 출처 추적성(provenance)을 확립하는 것이 중요합니다.

이러한 문제들을 해결하기 위해, 우리는 서비스의 코드와 구성이 프로덕션에 배포되기 전에 충족해야 하는 특정 기준을 강제하는 배포 시점 정책을 Binary Authorization에 정의할 수 있습니다.

예를 들어, 정책은 다음과 같은 사항을 확인할 수 있습니다.

• 해당 배포가 승인된 시스템을 사용하여 빌드되었는가?
• 취약점 스캔을 받았으며, 원하는 모든 검증 단계를 통과했는가?
• 필요한 신뢰할 수 있는 기관에 의해 검증되었는가?

빌드, 스캔, QA 검사와 같은 파이프라인의 각 단계는 위변조가 불가능한 암호화 서명, 즉 '증명(attestation)'이라고 불리는 승인 도장을 제공합니다. 증명은 키 쌍의 개인 키를 사용하여 서명되고, 배포 시점에 공개 키로 검증됩니다.

이미지를 배포하면, Binary Authorization은 정책을 확인하여 배포에 적용되는 모든 규칙을 강제합니다. 만약 이미지가 필요한 검사를 통과하지 못할 경우, 해당 이미지가 규정을 준수할 때까지 배포는 차단됩니다.

배포 수명 주기의 각 단계는 자체적인 배포 환경을 가질 수 있으므로, Binary Authorization을 사용하면 규정을 준수하지 않는 이미지가 한 단계에서 다음 단계로 진행되는 것을 막는 정책을 정의하고 강제할 수 있습니다. 또한, 이미지가 정의된 정책을 준수하는지 주기적으로 확인하고 모든 위반 사항에 대해 로그 항목을 생성할 수 있는 모니터링 정책 생성도 지원합니다.

Binary Authorization 실제 적용하기: Google과 고객사들의 교훈

Binary Authorization은 어느 날 갑자기 등장한 것이 아니라, Google 내부의 보안 태세가 진화한 결과물입니다. Google의 내부 Kubernetes라 할 수 있는 Borg의 규모를 확장하면서, 저희는 경계 기반 보안의 한계를 인식하게 되었습니다. 거대한 규모의, 빠르게 변화하는 컨테이너화된 환경을 보호하는 데 따르는 어려움은, 저희가 배포 시점에 검증을 강제하는 시스템을 개발하게 된 계기가 되었으며, 이 원칙은 현재 저희 소프트웨어 공급망 보안의 초석이 되었습니다.

저희가 Binary Authorization을 처음 도입했을 때, 드라이런(dry-run) 모드의 모니터링 정책으로 시작했습니다. 이를 통해 프로덕션 환경에 영향을 주지 않고 작게 시작할 수 있었습니다. 모니터링은 진행 상황을 파악하고 오래된 소프트웨어나 보안 스캔과 같은 기존 문제를 발견하는 데 도움이 되었지만, 이는 저희 운영팀이 문제를 예방하기보다는 해결하는 데 더 많은 시간을 소비하고 있다는 것을 깨닫게 했습니다.

이제 새로운 프로젝트의 경우, 저희는 일반적으로 처음부터 강제 적용으로 시작하며, 가능한 한 정책을 강제하기 전에 모든 규칙이 올바른지 잠시 확인하는 용도로만 모니터링 정책을 사용합니다.

이러한 전략의 변화는 저희가 정책의 범위를 지정하는 방식 또한 정의합니다. 기존 프로젝트를 정리해야 하는 상황을 완전히 피할 수는 없지만, 신중한 계획이 매우 중요합니다. 만약 기존 시스템에 대해서만 규칙을 설정한다면, 나중에 새로운 시스템에 이를 적용하기 위해 시간을 투자해야 할 것입니다.

대신, 저희는 새로운 프로젝트에 자동으로 적용될 수 있는 방식으로 정책을 예측하고 구성하는 법을 배웠습니다. 한 가지 접근 방식은 특정 리소스에 한정하지 않고, 조직의 한 부분을 포괄하는 정책을 만드는 것일 수 있습니다.

저희가 고려해야 했던 또 다른 중요한 측면은 이것이 기존 프로세스에 어떻게 들어맞는가 하는 것이었습니다. 각기 다른 도구를 사용하고 자신만의 방식으로 작업하는 여러 팀에 걸쳐 이러한 규칙을 강제하는 것은 매우 어려운 과제임을 발견했습니다. 많은 글로벌 조직에서는, 중앙화된 DevOps 또는 플랫폼팀이 컨설턴트처럼 행동하며 독립적인 개발팀에게 표준화된 가이드라인, 도구, 템플릿을 제공하는 것이 더 낫다는 것을 알게 되었습니다.

하나의 팀이 프로덕션으로 가는 경로를 통제할 때, 그들은 모든 사람을 위한 정책을 효과적으로 설정하고 시행할 수 있습니다. 이 중앙 집중식 모델은 중앙팀이 전체 조직 단위에 적용되는 광범위한 정책을 생성하여, 새로운 프로젝트가 생성되는 순간 자동으로 적용되므로 정책의 확장성을 높여줍니다.

이러한 중앙 집중화와 개발자 자율성 사이의 균형을 맞추기 위해, 중앙팀은 핵심 정책 프레임워크를 관리하면서 개별 개발팀이 팀 수준의 검사를 위한 자신들만의 특정 증명자(attestor)를 생성하고 관리할 수 있도록 권한을 부여할 수 있습니다. Binary Authorization을 시작하려는 조직은, 신뢰할 수 있는 파이프라인에서 빌드된 승인된 소프트웨어만 프로덕션 환경에서 실행되도록 하기 위해 소프트웨어의 출처(provenance)를 확인하는 것부터 시작해야 합니다.

한 가지 방법은 빌드 시스템이 모든 컨테이너에 증명(attestation)을 추가하고 이미지와 함께 저장하도록 하는 것입니다. 그런 다음 Binary Authorization을 사용하여, 빌드 시스템의 유효한 서명이 있는 소프트웨어만 실행될 수 있도록 프로덕션 환경에 대한 정책을 설정할 수 있습니다. 예를 들어, 이것이 바로 고객들이 Binary Authorization을 사용하여 Cloud Build로 빌드된 이미지만 배포할 수 있는 방법입니다.

다중 프로젝트 설정의 경우, 저희는 별도의 프로젝트를 사용하는 것을 권장합니다: 정책이 구성되는 배포자(deployer) 프로젝트, 증명자가 저장되는 증명자(attestor) 프로젝트, 그리고 증명이 저장되는 증명(attestation) 프로젝트입니다. 이는 직무 분리(separation of duties) 원칙을 지원하며, 여러 배포자 프로젝트에 걸쳐 증명자를 쉽게 적용할 수 있게 해줍니다.

또한, Binary Authorization 정책이 항상 증명(attestation)을 요구하거나, 특정 증명자(attestor)가 포함되도록 강제하는 것과 같은 요구사항을 준수하도록 의무화할 수도 있습니다.

신뢰하지 말고, 검증하라: 시작하는 방법

잠재적으로 거대한 사고방식의 전환을 시도할 때, 시작하는 것이 복잡하게 느껴질 수 있지만, 그럴 필요는 없습니다. 단계적 접근 방식을 통해 개발팀에 지장을 주지 않으면서 점진적으로 보안 태세를 강화할 수 있습니다.

• 모니터 모드로 시작하기: 드라이런(dry-run) 모드의 정책으로 시작하세요. 이를 통해 프로덕션에 영향을 주지 않고 무엇이 차단될 수 있었는지 확인할 수 있습니다. 생성된 감사 로그를 사용하여 규정을 준수하지 않는 워크플로우를 식별하고 기존 시스템이 규정을 준수하도록 만드세요.
• 빌드 출처 강제하기: 첫 번째 강제 적용 단계는 간단합니다. 모든 프로덕션 코드가 신뢰할 수 있는 자동화된 빌드 시스템에 의해 서명되도록 보장하는 것입니다. 이 가치 높은 첫 단계는 추적되지 않거나 개발자가 직접 빌드한 이미지가 프로덕션 환경에서 실행되는 것을 방지하는 데 도움이 될 수 있습니다.
• 추가 검증 단계 적용하기: 빌드 출처가 확립되면, 정책에 점진적으로 더 많은 증명을 추가하세요. 이미지가 성공적으로 취약점 스캔을 받았거나 QA팀의 승인을 받았음을 증명하는 증명을 요구할 수 있습니다.

이러한 원칙들을 구현하는 방법에 대해 더 자세히 알아보려면, Binary Authorization 문서를 확인하세요. 여기에는 첫 번째 정책을 시작하는 데 도움이 되는 상세한 사용법 가이드, 정책 예시, 통합 패턴이 포함되어 있습니다.

이 기사에는 클라우드 보안 팟캐스트 에피소드인 "이 바이너리, 믿을 수 있나? Google이 Binary Authorization과 코드 출처를 사용하는 방법"의 통찰력이 포함되어 있습니다.