Borg용 Binary Authorization

이 콘텐츠는 2023년 9월에 마지막으로 업데이트되었으며 작성된 당시의 상황을 나타냅니다. Google의 보안 정책 및 시스템은 고객 보호를 지속적으로 개선함에 따라 앞으로도 계속 변경될 수 있습니다.

이 문서에서는 Google의 소프트웨어 공급망을 내부자 위험에서 보호하기 위해 코드 검토, 보안 인프라, Borg용 Binary Authorization(BAB)라는 시행 확인을 사용하는 방법을 설명합니다. BAB는 특히 코드가 민감한 정보에 액세스할 수 있을 때 프로덕션 소프트웨어가 배포되기 전 검토 및 승인되도록 보장하기 때문에 내부자 위험을 줄이는 데 도움이 됩니다. 이 문서의 최초 게시 이후 BAB의 주요 개념은 SLSA(Supply-chain Levels for Software Artifacts)라는 개방형 사양에 포함되었습니다.

이 문서는 BeyondCorp 및 BeyondProd를 포함하여 Google 보안팀이 보안 개선을 위해 개발한 일부 프로젝트를 설명하는 기술 문서 시리즈의 일부입니다. 인프라 보안 개요는 Google 인프라 보안 설계 개요를 참조하세요.

소개

내부자 위험 은 직원 데이터, 재무 데이터 또는 기타 독점 또는 비즈니스 데이터가 포함될 수 있는 사용자 데이터의 보안 위협을 나타냅니다. 내부자 위험은 직원이 조직의 지식 또는 액세스 권한을 사용하여 악의적인 행동을 수행하거나 외부 공격자가 직원의 도용된 사용자 인증 정보를 사용하여 동일한 작업을 수행할 수 있는 가능성을 말합니다.

소프트웨어 공급망 내에서 내부자 위험을 최소화하기 위해 BAB가 사용됩니다. BAB 는 소프트웨어가 배포될 때 수행되는 내부 시행 검사입니다. BAB는 코드 및 구성 배포가 특정 최소 표준을 충족하고 프로덕션 시스템 전반의 일관성을 지원하는지 확인합니다.

Google은 직원의 일방적인 액세스 를 방지하여 프로덕션 시스템 내에서 사용자 데이터를 보호합니다. BAB는 직원이 단독으로 조치를 취하는 동안 적절한 승인과 근거 없이 직접 또는 간접적으로 사용자 데이터에 액세스하거나 영향을 주지 못하도록 합니다. BAB 및 관련 제어는 최소 권한을 적용하는 데 도움이 되므로 특정 위협 행위자와는 독립적으로 보안 상태를 개선하는 데 도움이 됩니다. 즉, BAB는 행위자가 악의적인 의도를 갖고 있는지, 해당 계정이 손상되었는지, 의도치 않게 액세스 권한이 부여되었는지 여부에 관계없이 일방적인 액세스를 방지합니다.

BAB 이점

BAB 및 컨테이너화된 배포 모델을 채택하면 Google 인프라에 많은 보안 이점이 제공됩니다. 이러한 이점은 다음과 같습니다.

  • BAB는 전반적인 내부자 위험을 줄여줍니다. BAB는 코드가 사용자 데이터에 액세스하기 전에 특정 표준 및 변경 관리 권장사항을 충족하도록 요구합니다. 이 요구사항은 단독으로 조치를 취하는 직원(또는 보안 침해된 직원 계정)이 사용자 데이터에 프로그래매틱 방식으로 액세스할 가능성을 줄입니다.
  • BAB는 프로덕션 시스템의 균일성을 지원합니다. 컨테이너화된 시스템을 사용하고 배포 전에 BAB 요구사항을 확인함으로써 Google 시스템은 디버깅이 더 용이해지고 보다 안정적이며 명확한 변경 관리를 갖추게 되었습니다. BAB 요구사항은 프로덕션 시스템 요구사항에 적합한 공통 언어를 제공합니다.
  • BAB는 데이터 보호를 위한 공통 언어를 나타냅니다. BAB는 Google 시스템 전반에서 적합성을 추적합니다. 이 적합성 데이터는 내부적으로 게시되며 다른 팀에서 사용할 수 있습니다. BAB 데이터를 게시하면 팀이 데이터 액세스 보호에 대해 서로 통신할 때 공통 용어를 사용할 수 있습니다. 이러한 공통 언어는 여러 팀에서 데이터를 다룰 때 반복적인 작업을 줄여줍니다.
  • BAB의 규정 준수 요구사항에 대한 프로그래매틱 추적 허용: BAB는 이전에 수동으로 수행되었던 규정 준수 태스크를 간소화합니다. Google의 특정 프로세스에서는 데이터 처리 방법을 더욱 철저하게 관리해야 합니다. 예를 들어 재무 보고 시스템은 사베인즈 옥슬리법(SOX)을 준수해야 합니다. BAB 이전에는 수동 인증 시스템을 통해 규정 준수를 보장했습니다. BAB 도입에 따라 이러한 많은 검사가 서비스에 대한 BAB 정책에 따라 자동화되었습니다. 이처럼 확인 작업을 자동화함으로써 규정 준수팀은 다루는 서비스 범위와 이 서비스에 대한 적절한 제어 기능 채택 범위를 모두 확대할 수 있었습니다.

BAB는 내부자 위험을 완화하기 위해 사용하는 더 큰 BeyondProd 프레임워크의 일부입니다.

개발 및 프로덕션 프로세스

Google의 개발 및 프로덕션 프로세스에는 코드 검토, 확인 가능한 빌드, 컨테이너화된 배포, 서비스 기준 ID라는 4개의 필수 단계가 포함됩니다. 다음 섹션에서는 이러한 단계를 자세히 설명합니다.

1단계: 코드 검토

대부분의 소스 코드는 중앙의 모놀리식 저장소, 에 저장되며 이를 통해 수천 명의 직원들이 단일 위치에서 코드를 확인할 수 있습니다. Google 코드베이스는 타사 코드에 대한 특정 종속 항목 관리 측면에서 소스 코드 관리를 간소화합니다. 모놀리식 코드베이스는 코드 검토를 위해 단일 초크 포인트의 적용을 허용합니다.

Google의 코드 검토에는 작성자 이외에 엔지니어 1명 이상의 검사와 승인 과정이 포함됩니다. 최소한 Google의 코드 검토 절차에 따라 시스템 소유자가 해당 시스템에 대한 코드 수정을 승인해야 합니다. 코드가 체크인된 후 빌드됩니다.

타사 또는 오픈소스 코드에서 변경사항을 가져올 때는 변경사항이 적절한지 여부를 확인합니다(예: 최신 버전). 하지만 외부 개발자가 Google이 사용하는 타사 또는 오픈소스 코드를 변경할 때마다 동일한 검토 제어 절차를 적용하지 않는 경우가 많습니다.

2단계: 검증 가능한 빌드

Google의 빌드 시스템 는 배포용 바이너리를 만들기 위해 소스 코드를 빌드 및 컴파일하는 Bazel과 유사합니다. Google의 빌드 시스템은 빌드를 수행하는 직원과 분리된 고립되고 격리된 환경 에서 실행됩니다. 각 빌드에 대해 시스템은 검증 가능한 빌드 로 생성된 출처를 생성합니다. 이러한 출처는 빌드, 바이너리 또는 기타 빌드 아티팩트의 암호화 해시, 전체 빌드 매개변수로 이동한 소스 및 종속 항목을 기술하는 서명된 인증서입니다. 이 출처는 다음을 사용 설정합니다.

  • 생성 시 사용된 소스 코드에 대한 바이너리를 추적하는 기능. 또한 확장 시 출처는 기술되는 소스 코드의 만들기 및 제출과 관련된 프로세스를 추적할 수 있습니다.
  • 파일에 대한 변경사항이 자동으로 서명을 무효화하므로 바이너리가 수정되지 않았는지 확인하는 기능입니다.

빌드 작업은 임의의 코드일 수 있으므로 멀티테넌시를 위해 빌드 시스템을 강화했습니다. 즉, Google의 빌드 시스템은 특정 빌드가 다른 빌드에 영향을 주지 않도록 설계되었습니다. 시스템은 빌드 출처나 시스템 자체의 무결성을 손상시킬 수 있는 빌드 변경을 차단합니다. 빌드가 완료되면 Borg를 통해 변경사항이 배포됩니다.

3단계: 컨테이너화된 배포

빌드 시스템이 바이너리를 만들면 컨테이너 이미지로 로 패키징되고 클러스터 조정 시스템 Borg에 Borg 작업 으로 배포됩니다. 각각 최대 수만 개의 머신을 보유한 여러 클러스터 전반에 걸쳐 매우 다양한 애플리케이션에서 수십만 개의 작업을 실행합니다. 이러한 규모에도 불구하고 Google의 프로덕션 환경은 상당히 균일하게 유지됩니다. 따라서 사용자 데이터 액세스를 위한 터치포인트를 더욱 간편하게 제어하고 감사할 수 있습니다.

컨테이너 는 주목할 만한 보안 이점을 제공합니다. 컨테이너는 불변성이 보장되어야 하며, 완전한 이미지 재빌드로 인한 빈번한 재배포가 이루어져야 합니다. 컨테이너화는 컨텍스트에서 코드 변경사항을 검토할 수 있도록 해주며 Google 인프라에 배포되는 모든 변경사항에 대한 단일 초크 포인트를 제공합니다.

Borg 작업의 구성 는 배포할 작업의 요구사항(컨테이너 이미지, 런타임 매개변수, 인수 및 플래그)을 지정합니다. Borg는 작업의 제약조건, 우선순위, 할당량, 구성에 나열된 기타 요구사항을 고려해서 작업을 예약합니다. 작업이 배포된 후 Borg 작업은 프로덕션의 다른 작업과 상호작용할 수 있습니다.

4단계: 서비스 기반 ID

Borg 작업은 서비스 ID로 실행됩니다. 이 ID는 기타 서비스의 데이터 스토어 또는 리모트 프로시져 콜(RPC) 메서드 에 액세스하는 데 사용됩니다. 여러 작업을 동일한 ID로 실행할 수 있습니다. 서비스 (일반적으로 사이트 안정성 엔지니어(SRE) 실행을 담당하는 직원만 특정 ID로 작업을 배포하거나 수정할 수 있습니다.

Borg는 작업을 시작한 후 암호화 사용자 인증 정보로 작업을 프로비저닝합니다. 작업은 이러한 사용자 인증 정보를 사용해 다른 서비스의 요청을 실행할 때 ID를 증명합니다(애플리케이션 레이어 전송 보안(ALTS) 사용). 서비스에서 특정 데이터나 다른 서비스에 액세스하려면 서비스 ID에 필수 권한이 있어야 합니다.

Google에서는 정책에 따라 사용자 데이터 및 기타 민감한 정보에 대해 액세스할 수 있는 서비스 ID에 대해 BAB 보호가 필요합니다. 민감한 정보나 리소스에 대한 액세스 권한이 없는 품질 보증 및 개발 작업은 더 낮은 관리 수준으로 실행될 수 있습니다.

BAB 작동 방식

BAB는 Borg 와 통합하여 승인된 작업만 각 서비스의 ID로 실행되도록 허용합니다. BAB는 또한 모니터링 및 이슈 대응을 허용하기 위해 BAB 사용 작업에 사용되는 코드 및 구성의 감사 추적을 생성합니다.

BAB는 특히 해당 코드가 사용자 데이터에 액세스할 수 있는 경우 모든 프로덕션 소프트웨어 및 구성이 적절하게 검토되고 체크인되며 검증 가능한 방식으로 빌드 및 승인되도록 설계되었습니다.

서비스별 정책

서비스 소유자가 서비스를 BAB에 온보딩할 경우 는 해당 서비스에 대한 보안 요구사항을 정의하는 정책을 만듭니다. 이 정책을 서비스별 정책이라고 부릅니다. 정책을 정의하거나 수정하는 것 자체가 검토가 필요한 코드 변경입니다.

서비스별 정책은 해당 코드 및 구성의 필수 속성은 물론 서비스 ID로 실행할 수 있도록 허용되는 코드 및 구성을 정의합니다. 서비스 ID로 실행되는 모든 작업은 서비스별 정책을 충족해야 합니다.

Google의 모든 서비스에는 서비스별 정책이 있어야 합니다. 민감한 정보에 액세스하는 서비스에는 충분히 강력한 정책이 있어야 하며, 민감한 정보에 액세스할 권한이 없는 서비스의 경우 "모든 것을 허용" 정책 권한이 있을 수 있습니다.

서비스별 정책은 다음 요구사항을 시행할 수 있습니다.

  • 코드는 감사가 가능해야 합니다. 검증 가능한 빌드로 생성된 출처를 통해 인간이 읽을 수 있는 소스로 컨테이너 이미지를 다시 추적할 수 있습니다. 보관 정책은 코드가 제출되지 않은 경우에도 인간이 읽을 수 있는 코드 소스를 18개월 이상 유지합니다.
  • 코드를 제출해야 합니다. 이 코드는 Google 소스 저장소에 지정되고 정의된 위치에서 빌드됩니다. 제출은 일반적으로 코드가 코드 검토를 거쳤다는 것을 의미합니다.
  • 구성을 제출해야 합니다. 배포 중에 제공되는 모든 구성에는 일반 코드와 동일한 검토 및 제출 프로세스가 적용됩니다. 따라서 명령줄 플래그 값, 인수, 매개변수는 검토 없이 수정할 수 없습니다.

BAB를 시행하는 시스템 및 구성요소는 가능한 한 가장 엄격한 자동화된 요구사항 및 추가적인 수동 제어 수단을 통해 긴밀하게 제어됩니다.

시행 모드

BAB는 두 가지 시행 모드를 사용하여 모든 작업이 서비스별 정책을 준수하도록 합니다.

  • 배포-시간 시행: 규정을 준수하지 않는 작업의 배포를 차단합니다.
  • 지속적 검증: 규정을 준수하지 않은 배포된 작업을 모니터링하고 알림을 제공합니다.

또한 긴급 상황에서 긴급 응답 절차는 배포 시 시행 규정을 우회할 수 있습니다.

배포-시간 시행 모드

Borg Prime은 ALTS의 인증 기관으로 수행되는 Borg의 중앙화된 컨트롤러입니다. 새 작업이 제출되면 Borg Prime은 BAB를 참조하여 작업이 서비스별 정책 요구사항을 충족하는지 확인한 후 Borg Prime에서 해당 작업에 ALTS 인증서를 부여합니다. 이러한 확인은 허용 컨트롤러 역할을 수행하며 Borg는 서비스별 정책을 충족하는 경우에만 작업을 시작합니다. 이 검사는 배포 요청을 수행하는 직원 또는 서비스가 다른 방법으로 승인된 경우에도 발생합니다.

드문 경우지만 서비스는 적절한 근거에 따라 배포 시 시행을 거부할 수 있습니다.

지속적 확인 모드

배포된 작업은 배포 당시의 시행 모드에 관계없이 수명 주기 동안 지속적으로 검증됩니다. BAB 프로세스는 하루에 최소 1번 실행되며, 시작되어 실행 중인 작업이 모든 정책 업데이트를 준수하는지 여부를 확인합니다. 예를 들어 지속적 확인 모드는 오래된 정책으로 실행 중이거나 비상 대응 절차를 사용해 배포된 작업이 있는지 지속적으로 확인합니다. 최신 정책을 준수하지 않는 작업이 발견되면 BAB는 위험을 최소화할 수 있도록 서비스 소유자에게 알림을 전송합니다.

비상 대응 절차

이슈 또는 중단이 발생할 때 첫 번째 우선순위는 가능한 한 빠르게 해당 서비스를 복원하는 것입니다. 비상 상황에서는 검토되지 않았거나 검증 가능한 방식으로 빌드되지 않은 코드를 실행해야 할 수 있습니다. 따라서 비상 대응 플래그를 사용해 시행 모드를 재정의할 수 있습니다. 비상 대응 절차는 BAB 오류로 인하여 배포가 차단될 경우 백업 역할도 수행합니다. 개발자가 비상 대응 절차를 사용해 작업을 배포하는 개발자는 요청의 일부로 타당한 근거를 제출해야 합니다.

비상 대응 절차가 사용되고 몇 초 내에 BAB는 연결된 Borg 작업에 대한 세부정보를 로깅합니다. 로그 에는 사용된 코드와 사용자가 제공한 근거가 포함됩니다. 몇 초 후 Google의 중앙 보안팀에 감사 추적이 전송됩니다. 몇 시간 이내에 작업 ID를 소유하는 팀에 감사 추적이 전송됩니다. 비상 대응 절차는 최후의 수단으로만 사용해야 합니다.

BAB를 다른 환경으로 확장

처음에 BAB에서는 Borg 작업 보호만 지원되고, Google의 기존 소스 제어, 빌드, 패키징 파이프라인을 사용하여 소프트웨어를 개발해야 했습니다. 이제 BAB는 다른 소프트웨어 제공 및 배포 환경을 보호하기 위한 지원과 대체 소스 제어, 빌드, 패키징 시스템을 지원을 추가했습니다. 이러한 여러 환경에서 구현 세부정보는 서로 다르지만 BAB의 이점은 그대로입니다.

배포 전에 사람이 직접 수행하는 코드 검토에 적합하지 않은 경우가 있으며, 특히 머신러닝 코드 및 빈도가 높은 데이터 분석을 반복적으로 개발하는 경우가 있습니다. 이러한 경우 작업자 검토를 보상하는 대체 제어 수단이 있습니다.

조직에 유사한 제어 기능 채택

이 섹션에서는 조직에서 유사한 제어 기능을 채택할 수 있도록 Google이 BAB를 구현하면서 배운 권장사항을 설명합니다.

컨테이너화된 동종 CI/CD 파이프라인 만들기

대부분의 팀에서 단일 소스 제어 시스템, 코드 검토 프로세스, 빌드 시스템, 배포 시스템이 사용되었기 때문에 BAB 채택이 더 쉬워졌습니다. 코드 검토는 이미 Google 문화의 일부였기 때문에 사용자에게 표시되는 중요 변경사항이 지나치게 많지 않도록 변경할 수 있었습니다. BAB를 채택하기 위해 코드 검토, 검증 가능한 빌드, 컨테이너화된 배포, 액세스 제어를 위한 서비스 기반 ID에 주력했습니다. 이 접근법은 BAB의 채택 과정을 간소화하고 BAB와 같은 솔루션이 제공할 수 있는 보증을 강화했습니다.

호스트 기반 ID(예: IP 주소)가 아닌 마이크로서비스 및 서비스 기반 ID(예: 서비스 계정)를 광범위하게 사용할 수 있으므로 각 서비스를 실행할 수 있는 소프트웨어를 세부적으로 제어할 수 있습니다.

조직이 서비스 ID를 직접 채택할 수 없는 경우 중간 단계로 다른 방식을 사용해서 ID 토큰 보호를 시도할 수 있습니다.

목표를 결정하고 요구사항에 따라 정책 정의

정책 기반 출시 프로세스는 한 번에 1개만 구현하세요. CI/CD 파이프라인에서 특정 변경사항을 다른 것보다 먼저 구현해야 할 수 있습니다. 예를 들어 배포 시 코드를 시행하려면 먼저 공식 코드 검토를 시작해야 할 수 있습니다.

정책 기반 출시 프로세스의 가장 큰 동기 부여 요소는 규정 준수입니다. 규정 준수 요구사항의 일부라도 정책에 인코딩할 수 있으면 테스트를 자동화하고 해당 요구사항이 항상 적용되도록 할 수 있습니다. 기본 요구사항부터 구현한 다음 필요에 따라 고급 요구사항을 코드화합니다.

개발 초기에 정책 적용

소프트웨어 실행 위치와 액세스할 데이터를 먼저 파악하지 않으면 소프트웨어에 대한 포괄적인 정책을 정의하기 어렵습니다. 따라서 서비스별 정책 시행은 코드가 빌드될 때가 아니라 코드가 배포되고 데이터에 액세스할 때 수행됩니다. 정책은 런타임 ID 측면에서 정의되므로 서로 다른 환경에서 동일한 코드가 실행될 수 있으며, 여러 정책에 적용될 수 있습니다.

Google은 사용자 데이터에 대한 액세스를 제한하기 위해 BAB 외에 다른 액세스 메커니즘도 사용합니다. 서비스 소유자는 또한 데이터가 특정 BAB 요구사항을 충족하는 작업에서만 액세스되도록 보장할 수 있습니다.

여러 팀 간 변경 관리자 등록

Google 차원에서 BAB 배포 의무 를 만들었을 때, 각 제품 그룹의 변화를 주도할 소유자를 찾는 게 성공률을 크게 좌우했습니다. Google은 시행 메커니즘을 통해 즉각적인 혜택을 누릴 수 있고 제공할 의향이 있는 소수의 서비스 소유자를 파악했습니다. 변경을 의무화하기 전에 서비스 소유자들에게 자발적 적용을 요청했습니다. 이들의 도움으로 공식적인 변경 관리팀을 구성하여 지속적인 변경사항을 추적했습니다. 그런 다음 각 제품 팀에서 변경사항을 구현할 책임이 있는 소유자를 파악했습니다.

타사 코드 관리 방법 확인

타사 코드를 관리해야 하는 경우 타사 코드베이스에 정책 요구사항을 적용하는 방법을 고려하세요. 예를 들어 사용된 모든 타사 코드의 저장소를 유지하는 방향(이상적인 상태)으로 전환하는 동안 코드를 먼저 제외할 수 있습니다. 정기적으로 보안 요구사항에 따라 코드를 검사하는 것이 좋습니다.

타사 코드 관리에 대한 자세한 내용은 안전한 오픈소스 커뮤니티를 구축하는 성공 사례 공유를 참조하세요.

다음 단계