Borg용 Binary Authorization: Google이 코드 출처를 확인하고 코드 ID를 구현하는 방법

Google은 보안을 강화하기 위해 보안팀에서 내부적으로 개발한 BeyondCorpBeyondProd 등의 프로젝트에 대해 설명하는 몇 가지 백서를 작성했습니다. Google 보안에 대한 개요는 보안 인프라 설계 백서를 참조하세요.

이 백서에서는 Google의 코드 검토 프로세스, 코드 출처1, 시행 메커니즘의 필요성에 대해 설명합니다. 또한 구체적인 시행 확인인 Borg용 Binary Authorization(BAB)의 발전을 중점적으로 살펴봅니다. BAB의 목표는 특히 해당 코드에 사용자 데이터에 액세스할 수 있는 권한이 있는 경우, Google에 배포된 프로덕션 소프트웨어가 적절하게 검토되고 승인되도록 설정하여 내부자 위험을 최소화하는 것입니다. Google은 모든 Google 제품에서 사용자 데이터를 확실하게 보호하고 Google이 취하는 보안 조치를 가능한 한 투명하게 공개하기 위해 노력하고 있습니다.

이 백서에 포함된 콘텐츠는 2019년 12월 기준으로 작성되었으며, 이 문서는 작성된 당시의 상황을 나타냅니다. Google에서 고객 보호를 지속적으로 개선하고 있으므로 Google Cloud의 보안 정책과 시스템은 앞으로도 계속 변경될 수 있습니다.

CIO 수준 요약

  • 내부자 위험은 사용자 데이터에 대한 보안 위협을 나타냅니다. Google에서는 Google 직원이 승인되지 않은 방식(예: 승인되지 않은 작업 실행 등)으로 조직의 기술 자료를 사용하거나 사용자 데이터에 액세스하는 가능성을 최소화하기 위해 최선의 노력을 다하고 있습니다.
  • Borg용 Binary Authorization(BAB)은 특히 해당 코드에 사용자 데이터에 액세스할 수 있는 권한이 있는 경우, Google에 배포된 프로덕션 소프트웨어 및 구성이 적절하게 검토되고 승인되도록 설정하여 내부자 위험을 최소화하는 내부 배포-시간 시행 확인입니다.
  • BAB는 코드 및 구성 배포가 특정 최소 기준을 충족하도록 보장합니다.
  • BAB는 정책 시행 강제 외에도 특정 요구사항이 충족되지 않을 때 경고를 보내기 위해 정책이 시행되지 않는 감사 모드에서도 사용할 수 있습니다.
  • BAB 채택을 통해 Google은 내부자 위험을 최소화하고 공격 가능성을 차단하며 프로덕션 시스템의 균일성을 지원할 수 있습니다.

Google에서 내부자 위험 최소화

보안을 최우선 과제로 생각하는 기업으로서 Google은 내부자 위험을 제한하기 위한 조치를 마련했습니다. 내부자 위험에는 Google 직원 또는 조직 내 다른 사람이 악의적인 행위를 위해 조직의 기술 자료 또는 액세스 권한을 사용할 가능성이 포함되며, 공격자가 쉽게 공격하기 위해 Google 직원의 사용자 인증 정보를 도용하는 상황도 포함됩니다. Google은 내부자 위험 차단 분야를 혁신하기 위해 막대한 리소스를 투입했습니다. Google에서는 사용자 데이터 보호를 무엇보다도 중요하게 여기며 이를 포괄적으로 보호하기 위해 노력하고 있습니다. Google의 목표는 Google 직원이 승인 없이는 사용자 데이터에 액세스하지 못하도록 하는 것입니다.

사용자 데이터 액세스를 위한 승인

Google에서는 서비스와 직원이 사용자 데이터에 액세스해야 하는 경우가 있으며, 다음과 같은 방법으로 사용자 데이터와 상호작용합니다.

  1. 최종 사용자로 상호작용: 서비스를 사용하는 직원이 서비스에 직접 인증하면 서비스가 해당 직원 고유의 데이터를 반환합니다. 예를 들어 Gmail 계정에 로그인한 직원은 자신의 이메일을 볼 수 있습니다.
  2. 역할의 일부로 상호작용: Google 직원이 수행하는 작업 대부분은 익명처리된 사용자 데이터를 사용해 성공적으로 완료할 수 있습니다. 그러나 드물게 작업(예: 지원 또는 디버깅)의 일부로 Google 직원이 사용자 데이터에 액세스해야 하는 경우도 있습니다 Google은 사용자 데이터 액세스에 대한 투명성을 최대한 유지하기 위해 노력하고 있습니다. 액세스 투명성은 이를 달성하기 위한 방법 중 하나로, Google Cloud 고객은 실시간 로그를 통해 적격한 데이터 액세스를 확인할 수 있습니다.
  3. 프로그래매틱 방식으로 서비스의 일부로 상호작용: 작업을 수행하기 위해 서비스에서 대규모의 사용자 데이터에 프로그래매틱 방식으로 액세스해야 할 수 있습니다. 예를 들어 데이터 파이프라인은 집계된 사용 통계를 생성하기 위해 수천 명의 사용자 데이터를 한 번에 쿼리합니다. 이러한 경우에는 개별 사용자의 데이터가 아닌 데이터 세트에 액세스 권한이 부여됩니다. 각 개별 사용자의 데이터에 대한 액세스는 로깅되지 않습니다.

이 백서에서는 세 번째 시나리오에 제시된 위협 모델을 중점적으로 설명합니다. Google은 사용자 데이터에 액세스하는 시스템 운영 관리자가 권한을 악용하지 못하도록 최선의 방법을 모색하고 있습니다.

위협 모델

이 백서에서 설명하는 제어 기능은 일방적인 액세스를 차단하여 사용자 데이터를 보호하도록 빌드되었습니다. Google은 Google 직원이 적절한 승인과 근거 없이 직접 또는 간접적으로 사용자 데이터에 액세스하거나 영향을 미치는 행동을 단독으로 실행하지 못하도록 규제합니다. Google의 제어 기능은 행위자에게 악의적인 의도가 있거나, 계정이 도용되었거나, 의도치 않게 권한이 부여되었는지 여부와 상관없이 이러한 행동을 차단합니다.

Google의 컨테이너화된 인프라

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

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

서비스에서 사용자 데이터에 대한 프로그래매틱 방식 액세스를 제한하는 솔루션을 개발한 방법을 이해하려면 먼저 Google에서 서비스가 프로덕션 단계로 어떻게 구현되는지를 이해하는 것이 중요합니다.

1단계: 코드 검토

Google의 소스 코드는 모놀리식 중앙 저장소에 저장되므로 수천 명의 직원들이 단일 위치에서 코드를 확인할 수 있습니다. 단일 코드베이스를 사용하면 소스 코드 관리, 특히 타사 코드에 대한 종속 항목을 간소화할 수 있습니다. 모놀리식 코드베이스는 코드 검토를 위해 단일 초크 포인트의 적용을 허용합니다. Google의 코드 검토에는 작성자 이외에 엔지니어 1명 이상의 승인과 검사가 포함되어 있습니다. Google의 코드 검토 절차에는 최소한 시스템의 코드 수정 시 해당 시스템 소유자의 승인을 받아야 한다는 규칙이 적용됩니다. 코드가 체크인되면 빌드됩니다.

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

2단계: 검증 가능한 빌드

Google은 Bazel과 매우 유사한 빌드 시스템을 사용해 소스 코드를 빌드 및 컴파일하여 배포용 바이너리를 만듭니다. 이 빌드 시스템은 빌드를 수행하는 직원과 격리되어 잠겨 있는 환경에서 실행됩니다. 각 빌드에 대해 시스템은 빌드에 적용된 소스, 모든 바이너리 또는 기타 빌드 아티팩트의 암호화 해시, 전체 빌드 매개변수를 설명하는 서명된 인증서인 검증 가능한 빌드 매니페스트를 생성합니다. 이 매니페스트를 사용하면 생성 시 사용된 소스 코드의 바이너리, 더 나아가 매니페스트가 설명하는 소스 코드의 생성 및 제출 관련 프로세스의 바이너리를 추적할 수 있습니다. 이 외에도 매니페스트는 파일의 변경사항이 자동으로 서명을 무효화하므로 바이너리를 수정하지 않았음을 확인할 수 있게 해줍니다.

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

3단계: 배포 작업

빌드된 바이너리는 컨테이너화된 인프라에 Borg 작업으로 배포할 수 있습니다. 이러한 작업은 바이너리 또는 데이터를 포함할 수 있는 패키지를 사용하고, 패키지 설치는 Borg에서 관리합니다. Borg 구성은 패키지, 런타임 매개변수, 인수, 플래그 등 작업 배포를 위한 요구사항을 지정합니다. Borg는 제약조건, 우선순위, 할당량, 구성에 나열된 기타 요구사항을 고려하여 작업을 예약합니다. 배포된 Borg 작업은 프로덕션 단계의 다른 작업과 상호작용할 수 있습니다.

4단계: 작업 ID

Borg 작업은 ID로 실행되고, 이 ID를 사용해 데이터 저장소나 다른 서비스의 리모트 프로시져 콜(RPC) 메서드에 액세스할 수 있습니다. ID는 역할 계정(예: 서비스)이거나 사용자 계정(예: 직원의 개인 계정)일 수 있습니다. 여러 작업을 동일한 ID로 실행할 수 있습니다. 특정 ID를 사용하는 작업을 배포하거나 수정하는 권한은 서비스 실행 책임자(일반적으로 사이트 안정성 엔지니어(SRE))로 제한됩니다.

Borg는 작업을 시작한 후 암호화 사용자 인증 정보로 작업을 프로비저닝합니다. 작업은 이러한 사용자 인증 정보를 사용해 다른 서비스의 요청을 실행할 때 ID를 증명합니다(애플리케이션 레이어 전송 보안 사용). 서비스에서 특정 데이터나 다른 서비스에 액세스하려면 서비스 ID에 필수 권한이 있어야 합니다. Google Cloud의 Cloud Data Loss Prevention(Cloud DLP) API와 같은 서비스 예시를 살펴보세요. 검사를 위해 DLP API에서 데이터에 액세스하려면 2가지 요건을 충족해야 합니다. 우선 DLP API가 고유 ID(이 경우 역할 계정)로 실행되도록 구성해야 합니다. 두 번째로 DLP API에서 검사하는 데이터에 대한 권한은 해당 역할 계정을 포함해야 합니다. 유효한 ID와 올바른 권한이 없으면 서비스에서 검사를 수행할 수 없습니다.

Google 정책에 따라 사용자 데이터 또는 다른 민감한 정보에 액세스할 수 있는 역할 계정은 BAB 및 기타 보안 시스템을 통해 철저하게 관리해야 합니다. 민감한 정보나 리소스에 대한 액세스 권한이 없는 품질 보증 및 개발 작업은 더 낮은 관리 수준으로 실행될 수 있습니다.

작업 절차 요약 정리

요약하면 Google 인프라에서 작업을 실행하는 단계는 다음과 같습니다.

  1. Google 개발자가 코드 변경 내용을 작성합니다. 그런 다음 1명 이상의 Google 엔지니어에게 해당 내용을 보내 검토를 받습니다. 검토 단계에서는 승인과 로깅이 적절한지 검사합니다. 승인되면 코드가 체크인됩니다.
  2. 개발자가 트리거하면 빌드 시스템은 샌드박스 처리된 환경에서 검증 가능한 방식으로 바이너리를 빌드하고 패키징합니다. 이 빌드 작업에서 패키지가 생성되며, 이렇게 생성된 패키지는 이후 빌드 시스템에서 검증을 위해 서명합니다.
  3. 적절한 보안 ID로 실행되는 작업에 대한 관리 권한이 특별히 부여된 엔지니어가 Borg에 작업을 배포합니다.
  4. Borg 작업이 사용자 데이터와 같이 권한이 있는 리소스에 액세스를 시도하면 작업의 ID가 승인되었는지 여부를 확인합니다.

이제 프로덕션 환경에서 작업이 어떻게 실행되는지 알았으니 BAB에서 해결할 위협 모델을 살펴보겠습니다(예: 악의적인 내부 사용자의 승인되지 않은 작업 실행 차단). 이를 위해 BAB는 바이너리를 배포하기 전에 필요한 모든 보안 확인이 수행되었는지 확인합니다.

이 섹션에서는 컨테이너화된 인프라를 간략하게 설명합니다. Google의 프로덕션 환경에 대한 기본적인 이해는 사용자가 프로그래매틱 방식으로 데이터에 액세스할 수 있도록 Google이 마련한 제어 기능을 이해하는 데 필요한 기본 요건입니다. 이러한 제어 기능에 대해서는 다음 섹션에서 더 자세히 설명합니다.

Borg용 Binary Authorization(BAB)

몇 년 동안 Google은 사용자 데이터에 수동으로 액세스하는 것을 차단하기 위해 상당한 노력을 기울여 왔습니다. 이러한 노력의 일환으로 Google은 데이터 및 작업 관리 액세스 권한을 업무를 수행하는 데 이러한 권한이 필요한 몇몇 Google 직원으로 제한했습니다.

BAB의 목표는 특히 해당 코드에 사용자 데이터에 액세스할 수 있는 권한이 있는 경우 Google에 배포된 모든 프로덕션 소프트웨어 및 구성이 적절하게 검토되고 승인되도록 설정하는 것입니다. 이를 위해 BAB는 승인되지 않은 작업이 시작되지 않도록 차단하는 배포-시간 시행 서비스뿐 아니라 BAB가 설정된 작업에 사용되는 코드 및 구성의 감사 추적을 제공합니다.

확인

BAB는 바이너리가 배포될 때 특정 요구사항을 충족하는지 확인합니다. 예를 들어 서비스 소유자는 서비스의 바이너리가 검토, 체크인, 테스트, 승인을 거친 코드에서 빌드되도록 요구할 수 있습니다. 이러한 유형의 확인을 배포-시간 확인이라고 합니다. BAB는 바이너리가 배포된 후의 확인도 수행하는데, 이를 배포 후 확인이라고 합니다. 배포 후 확인에 대한 자세한 내용은 시행 모드 섹션을 참조하세요.

코드를 변경하면 새 바이너리가 생성됩니다. 새 바이너리의 변경사항을 적용하려면 새 바이너리를 배포해야 합니다. BAB에서는 많은 종류의 배포-시간 확인이 허용됩니다. 이러한 확인의 몇 가지 예시는 다음과 같습니다.

  • 바이너리가 체크인된 코드에서 빌드되었는지 여부

    코드가 Google의 소스 코드 저장소에 제출되고 체크인되었는지 여부를 확인합니다. 코드가 제출되려면 일반적으로 다른 Google 엔지니어의 검토를 받아야 합니다.

  • 바이너리가 검증 가능한 방식으로 빌드되었는지 여부

    이 바이너리가 감사 가능한 소스까지 추적되며 승인된 빌드 시스템에서 빌드되었는지 여부를 확인합니다.

  • 바이너리가 테스트를 거친 코드에서 빌드되었는지 여부

    바이너리가 테스트 요구사항을 충족하는지 여부를 확인합니다.

  • 바이너리가 배포에 사용할 코드에서 빌드되었는지 여부

    특정 Borg 작업의 관련 프로젝트나 팀에 해당하는 Google 소스 코드 저장소의 적절한 영역으로 코드가 제출되었는지 여부를 확인합니다.

이러한 확인은 Google의 프로덕션 환경에만 해당되지만 자체 보안, 규정 준수 또는 안정성 요구사항에 따라 CI/CD(지속적 통합/지속적 배포) 환경에도 유사한 요구사항을 적용할 수 있습니다.

서비스별 정책

업무상 필요한 타당한 이유가 있는 경우를 제외하고 민감한 정보에 액세스하는 작업에는 일반적으로 코드 제출이 요구됩니다. 민감한 정보에는 사용자 데이터, 직원 및 재무 데이터, 기타 독점 또는 비즈니스 데이터가 포함됩니다. Google에서 수행하는 모든 작업에는 정책이 지정되어야 합니다. 사용자 데이터 액세스가 필요하지 않은 Borg 작업에도 구체적인 요구사항이 명시될 필요는 없지만 정책이 정의되어야 합니다.

BAB에 온보딩한 서비스 소유자는 자신의 서비스에 대한 보안 요구사항을 사용해 정책을 정의합니다. 서비스를 구현하는 데 사용되는 모든 역할 계정은 BAB 정책을 지정해야 합니다. BAB 정책은 각 역할 계정에 대해 실행할 작업, 작업의 코드, 구성 요구사항을 정의합니다. 정책을 정의하거나 수정하는 것 자체는 검토가 필요한 코드 변경입니다.

BAB 정책에서 시행할 수 있는 요구사항은 다음과 같습니다.

  • 검증 가능한 방식으로 코드 빌드: 검증 가능한 방식으로 빌드된 코드는 감사가 가능하지만, 그렇다고 이 코드가 코드 검토를 거쳤다는 의미는 아닙니다. 코드가 미제출 상태인 경우도 있습니다. 검증 가능한 방식으로 빌드된 코드는 제출되지 않은 경우에도 최소 18개월 동안 감사가 가능합니다.

  • 코드 제출: 소스 저장소의 지정되고 계획된 위치에서 코드가 빌드됩니다. 이는 일반적으로 코드가 코드 검토를 거쳤다는 것을 의미합니다.

  • 구성 제출: 배포 중에 제공되는 구성에는 일반 코드와 동일한 검토 및 제출 프로세스가 적용됩니다. 따라서 명령줄 플래그 값, 인수, 매개변수는 검토 없이 수정할 수 없습니다.

BAB를 시행하는 시스템과 구성요소는 철저하게 관리해야 하며, 이를 위해서는 가장 엄격한 요구사항 및 추가 수동 제어를 구현해야 합니다.

시행 모드

BAB는 Borg 작업에서 지정한 정책에 따라 다른 작업을 수행합니다. 이러한 작업을 시행 모드라고 부르며 배포-시간 시행, 배포-시간 감사, 지속적 확인이라는 3가지 모드로 구성됩니다. 서비스 소유자는 정책을 정의할 때 배포-시간 시행 또는 배포-시간 감사 중 하나를 선택해야 합니다. 지속적 확인 모드는 기본적으로 사용 설정됩니다. 다음 섹션에서는 각 모드에 대해 더 자세히 다룹니다.

배포-시간 시행 모드

새로운 작업이 제출되면 Borgmaster2는 BAB를 참조하여 이 작업이 BAB 정책에 명시된 필수 요구사항을 충족하는지 확인합니다. 이 확인은 허용 컨트롤러 역할을 하며 요구사항이 충족되면 Borgmaster가 작업을 시작합니다. 그 외의 경우 Borgmaster는 요청을 실행한 사용자가 다른 방법으로 승인된 경우에도 해당 요청을 거부합니다.

시행 모드에서 BAB는 Borg 작업의 BAB 정책에 명시된 요구사항을 충족하지 못할 경우 해당 Borg 작업이 배포되지 않도록 차단합니다. BAB를 처음 사용하는 서비스는 일반적으로 감사 모드로 시작(다음 섹션에서 설명)한 다음 시행 모드로 전환합니다.

비상 대응 절차

이슈나 서비스 중단이 발생할 경우 Google의 최우선 과제는 영향을 받은 서비스를 최대한 신속하게 복구하는 것입니다. 비상 상황에서는 검토와 체크인을 거치지 않은 코드를 실행해야 할 수 있습니다. 따라서 비상 대응 플래그를 사용해 시행 모드를 재정의할 수 있습니다. 비상 대응 절차는 BAB 오류로 인하여 배포가 차단될 경우 백업 역할도 수행합니다. 비상 대응 절차를 사용해 작업을 배포하는 개발자는 요청의 일부로 타당한 근거를 제출해야 합니다.

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

배포-시간 감사 모드

감사 모드에서 BAB는 Borg 작업이 정책 요구사항을 충족하지 못하지만 배포를 차단하지 않을 때 로그를 기록합니다. 이러한 정책 위반은 역할 계정을 소유한 팀으로 알림을 트리거합니다.

Google에서는 사용자 데이터에 액세스하는 서비스 같은 특정 서비스에서 시행 모드를 사용하도록 요구합니다. 이에 따라 Google은 모든 서비스 소유자가 시행 모드를 사용하고 새 서비스를 온보딩할 때만 감사 모드를 사용할 것을 적극 권장합니다. 감사 모드를 사용하려면 서비스 소유자는 예외를 적용할 타당한 근거를 제공해야 합니다. 예를 들어 안정성 서비스 수준 목표(SLO)가 BAB에서 제공하는 것보다 훨씬 더 높은 서비스에서는 감사 모드를 사용합니다.

감사 모드는 초기 정책을 세부 조정할 때 유용하지만 대부분의 서비스에서 실제로 안정적인 상태가 아닙니다. 감사 모드를 사용하는 경우 서비스 소유자는 정책 위반이 발생하고 몇 시간이 지난 후에야 정책 위반 알림을 받게 됩니다. 이 경우 알림이 계속해서 전송되므로 서비스 소유자가 도입한 오류나 잘못된 정책 구성으로 인해 발생하는 실제 보안 문제가 숨겨질 수 있습니다. 시행 모드에서는 서비스 소유자가 정책을 준수하지 않는 작업을 시작하려고 시도하면 즉각적인 피드백이 해당 서비스 소유자에게 제공됩니다. 따라서 알림 스트림을 훨씬 더 깔끔하게 관리할 수 있습니다. 또한 BAB의 시행 모드에서는 지정된 역할이 아닌 다른 역할에서 실수로 작업을 실행하는 것과 같은 부적절한 오류를 포착합니다.

지속적 확인

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

전역적으로 허용되는 패키지

Google에는 다양한 Google 서비스에 널리 사용되는 패키지가 있습니다. 이러한 패키지의 경우 각 서비스에서 자체 버전을 유지관리하도록 강제하지 않고 중앙에서 관리될 수 있도록 허용됩니다. 이를 전역 관리형 패키지라고 합니다. BAB 정책을 작성할 때 서비스 소유자는 특정 작업에 대해 전역적으로 허용되는 패키지를 지정할 수 있습니다. 또한 널리 사용되는 패키지에는 전역 기본 메커니즘도 있기 때문에 각 서비스 정책의 일부로 개별적으로 표시할 필요가 없습니다. 이를 통해 Google은 조직 전반에서 사용되는 일반적인 시스템 구성요소를 명시적으로 제어할 수 있으며 개별팀의 개입 없이도 이러한 구성요소를 적절히 검토하고 업데이트할 수 있습니다. 개별 서비스 소유자가 이러한 패키지를 서비스의 BAB 정책의 일부로 명시적으로 허용할 수도 있지만, 이를 통해 소유자는 권장되고 지원되는 경로를 쉽게 사용할 수 있습니다.

특이 사례

Google은 코드 검토검증 가능한 빌드를 포함하여 프로덕션에 배포된 코드에 강력한 보안 제어를 구현합니다. BAB는 이러한 보안 제어가 실제로 적절하게 구현되도록 추가 제어 및 시행 지점 역할을 합니다.

하지만 모든 경우에 BAB를 효과적으로 사용할 수 있는 것은 아닙니다. BAB는 몇 가지 특이 사례를 지원하지 않으며, 이러한 특이 사례에는 비표준 빌드 시스템을 사용해 빌드된 코드, Borg 이외의 환경에 배포된 코드, 최종 프로덕션 매개변수를 선택하기 전 사람이 직접 수행하는 코드 검토에 적합하지 않은 데이터 분석 및 머신러닝 코드가 포함됩니다. 이러한 경우에는 다른 코드 출처 시스템을 포함하여 다양한 보안 완화 조치를 적용합니다. 그렇더라도 이러한 코드에는 계속해서 Google의 일반적인 보안 제어가 적용됩니다.

Borg용 Binary Authorization 구현

BAB를 구현하기 위해 BAB 팀은 비상 대응 절차 및 감사 모드를 포함하여 몇 가지 새로운 기능을 개발했습니다. 이러한 도구를 사용하면 서비스 소유자가 손쉽게 BAB를 사용할 수 있습니다. 조직에 BAB 등을 배포하려는 경우 이 전환을 촉진하기 위해 몇 가지 추가 작업을 수행해야 할 수 있습니다. 이 섹션에서는 구현 계획의 일환으로 Google에서 수행한 조직 및 변경 관리 작업을 설명합니다.

이점

BAB의 내부자 위험 감소, 강력한 코드 ID, 간소화된 규정 준수라는 세 가지 이점은 Google에서 BAB를 개발 및 채택하기 위한 기업효용을 성립하는 데 도움을 주었습니다.

내부자 위험 감소

BAB는 본래 그 어떤 개인도 사용자 데이터에 프로그래매틱 방식으로 무단 액세스하지 못하도록 차단하기 위해 개발되었습니다. BAB는 엔지니어 개인이나 엔지니어의 사용자 인증 정보를 획득한 공격자가 발각되지 않고 부적절한 방법으로 민감한 정보에 액세스하기 더 어렵게 만듭니다.

강력한 코드 ID

컨테이너화된 인프라 섹션의 설명대로 Borg 작업은 일반적으로 역할 계정 ID로 실행됩니다. 이 ID는 모든 데이터에 대한 액세스 권한을 부여하기 전 적절한 승인을 받았는지 확인하기 위해 다른 서비스에서 사용됩니다. 하지만 다른 서비스는 해당 데이터의 사용을 시행할 수 없으므로 작업 ID가 수신된 데이터를 남용하지 않음을 신뢰할 수 있어야 합니다. BAB는 작업 ID를 특정 코드에 연결하여 지정된 코드만 사용해 작업 ID의 권한을 행사할 수 있도록 합니다. 이렇게 하면 ID와 권한이 부여된 사용자를 전이적으로 신뢰하는 작업 ID에서 특정 시맨틱스를 갖도록 검토되고 승인 프로세스 없이 수정할 수 없는 특정 코드 조각을 신뢰하는 코드 ID로 전환할 수 있습니다.

간소화된 규정 준수

BAB는 이전에 수동으로 실행했던 규정 준수 작업을 간소화했습니다. Google의 특정 프로세스에서는 데이터 처리 방법을 더욱 철저하게 관리해야 합니다. 예를 들어 재무 보고 시스템은 사베인즈 옥슬리법(SOX)을 준수해야 합니다. BAB 이전에는 수동 인증 시스템을 통해 규정 준수를 보장했습니다. BAB 이후에는 이러한 확인 중 대부분이 서비스의 BAB 정책에 따라 자동화되었습니다. 이처럼 확인 작업을 자동화함으로써 규정 준수팀은 다루는 서비스 범위와 이 서비스에 대한 적절한 제어 기능 채택 범위를 모두 확대할 수 있었습니다.

서비스 온보딩

BAB 팀은 온보딩 프로세스를 간단하고 직관적으로 구현해야 했습니다. 초기에 Google의 서비스 소유자는 BAB 채택과 관련하여 다음 2가지 사항을 우려했습니다.

  • BAB를 충분히 신뢰할 수 없는 경우 BAB 구현으로 중요한 상황의 변경사항이 차단될 수 있습니다.
  • BAB는 빈번한 코드 체크인 및 반복 프로세스를 통해 서비스 개발을 지연시킬 수 있습니다.

이러한 초기 우려 사항을 해결하기 위해 BAB 팀은 감사 모드를 개발했습니다. 이 모드에서 BAB 팀은 일부 주요 얼리 어답터에게 BAB가 효과가 있었음을 증명할 수 있었습니다. 안정성을 강화하기 위해 BAB 팀은 가용성 SLO를 개발하고 시행 모드비상 대응 절차를 도입했습니다.

기존 서비스를 BAB에 온보딩할 때 서비스 소유자는 일반적으로 감사 전용 모드를 먼저 사용 설정합니다. 이렇게 하면 시행 모드를 설정하기 전에 모든 문제를 식별하고 해결할 수 있습니다. 프로덕션 환경에서 BAB를 사용하는 모든 작업의 기본 정책은 시행 모드입니다. 작업을 배포하려면 서비스 소유자는 최소한 코드를 제출하고 검증 가능한 방식으로 코드를 빌드하도록 요구하는 정책을 제출해야 합니다. 서비스 소유자는 이 최소 기준을 충족하지 않고도 작업을 배포할 수 있지만 예외가 부여되어 있어야 합니다. 서비스에서 보다 민감한 정보 또는 서비스에 액세스해야 하는 경우 소유자는 더 엄격한 요구사항을 적용할 수 있습니다. 초기 정책을 정의하기 어려울 수 있으므로 BAB 팀은 서비스 소유자가 정책을 작성하는 데 도움이 되는 자동화된 도구를 개발했습니다. 이 도구는 소스 저장소의 어떤 부분이 기존 작업에 사용되는지 살펴보고 적절한 정책을 제안합니다.

새 서비스를 BAB에 온보딩할 때 서비스 소유자는 처음부터 시행 모드를 사용 설정합니다. 서비스 소유자는 초기 정책의 초안을 작성한 후 빠르게 반복하여 부가 요구사항을 추가합니다. 정책 자체는 코드 변경으로 관리되므로 다른 Google 엔지니어가 업데이트를 검토해야 합니다.

영향

BAB 및 컨테이너화된 배포 모델을 채택함으로써 Google은 보안 및 지원 측면에서 많은 이점을 기대할 수 있습니다.

  • BAB는 전반적인 내부자 위험을 줄여줍니다. 사용자 데이터에 액세스하기 전에 코드가 특정 기준과 변경 관리 권장사항을 충족하도록 함으로써 BAB는 Google 직원이 단독으로 또는 계정이 도용된 상태에서 프로그래매틱 방식으로 사용자 데이터에 액세스할 수 있는 가능성을 줄입니다.
  • BAB는 프로덕션 시스템의 균일성을 지원합니다. 컨테이너화된 시스템을 사용하고 배포 전에 BAB 요구사항을 확인함으로써 Google 시스템은 디버깅이 더 용이해지고 보다 안정적이며 더 명확한 변경 관리를 갖추게 되었습니다. BAB 요구사항은 프로덕션 시스템 요구사항에 적합한 공통 언어를 제공합니다.
  • BAB는 데이터 보호를 위한 공통 언어를 나타냅니다. BAB는 Google 시스템 전반에서 적합성을 추적합니다. 이 적합성 데이터는 내부적으로 게시되며 다른 팀에서 쿼리할 수 있습니다. 이 방식으로 BAB 데이터를 게시하면 팀 간에 데이터 보호에 대해 서로 통신할 때 공통 용어를 사용할 수 있습니다. 이 공통 언어는 여러 팀에서 데이터를 다룰 때 반복적인 작업을 줄여줍니다.
  • BAB를 통해 규정 준수 요구사항을 프로그래매틱 방식으로 추적할 수 있습니다. 재무 보고와 같은 특정 프로세스는 규정 준수 목적으로 특정 변경 관리 요구사항을 충족해야 합니다. BAB를 사용하면 이러한 확인 작업을 자동화하여 시간을 절약하고 적용 범위를 늘릴 수 있습니다.

BAB는 내부자 위험을 최소화하기 위해 Google에서 사용하는 여러 기술 중 하나입니다.

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

Google에서는 BAB를 구현하면서 여러 가지 중요한 교훈을 얻었습니다. 이렇게 극적인 변화를 이끌어 내는 것은 버거운 일처럼 보일 수 있습니다. 이 섹션에서는 BAB의 원칙을 조직에 적용할 수 있기를 기대하면서 Google이 지금까지 얻은 교훈에 대해 설명합니다.

보다 일관성 있는 컨테이너화된 CI/CD 파이프라인을 지향합니다.

Google은 코드 개발 시 사용하는 도구를 일관되게 유지하고 통합함에 따라 BAB를 채택할 수 있었습니다. 이 작업에는 코드 검토, 검증 가능한 빌드, 컨테이너화된 배포, 액세스 제어를 위한 서비스 기반 ID가 사용되었습니다. 검증 가능한 빌드를 사용하면 바이너리 빌드 방법을 확인할 수 있고, 컨테이너를 사용하면 데이터에서 바이너리를 분리하고 이러한 바이너리 사용에 필요한 요구사항을 충족하도록 시행 초크 포인트를 제공할 수 있습니다. 이 접근법은 BAB의 채택 과정을 간소화하고 BAB와 같은 솔루션이 제공할 수 있는 보증을 강화했습니다.

마이크로서비스를 도입하면서 호스트 기반 ID(예: IP 주소)가 아닌 서비스 기반 ID(예: 서비스 계정)를 채택할 수 있었습니다. 서비스 기반 ID로 전환함에 따라 서비스 간 인증 및 승인을 관리하는 방법을 변경할 수 있게 되었습니다. 예를 들어 ID를 증명하기 위해 컨테이너 이미지로 만든 ID 토큰을 사용할 경우 코드 출처를 통해 제공되는 보증은 충분히 강력하지 않습니다. 서비스 ID를 직접 채택할 수 없는 경우 중간 단계로 보다 강력하게 보호하는 ID 토큰을 활용할 수 있습니다.

목표를 결정하고 요구사항에 따라 정책을 정의합니다.

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

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

개발 초기에 정책을 적용합니다.

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

Google은 사용자 데이터에 대한 액세스를 제한하기 위해 BAB 외에 다른 액세스 메커니즘도 사용합니다. 이 방식으로 BAB를 사용하면 서비스 소유자가 특정 BAB 요구사항을 충족하는 작업만 데이터에 액세스하도록 할 수 있으므로, 실질적으로 코드를 ID로 취급하는 셈입니다.

기존 서비스 소유자를 온보딩하는 방법을 결정합니다.

시행 메커니즘을 통해 즉각적인 혜택을 누릴 수 있고 피드백을 제공할 의향이 있는 소수의 서비스 소유자를 파악합니다. 이를 위한 한 가지 방법은 변경을 의무화하기 전에 서비스 소유자들에게 자발적 적용을 요청하는 것입니다.

가능하다면 감사 모드가 아닌 시행 모드를 요구하거나 감사 모드의 유예 기간을 제한하여 강제 적용합니다. 감사 모드를 사용하면 서비스 소유자가 신속하게 온보딩하여 내부자 위험을 보다 정확하게 이해할 수 있습니다. 감사 모드의 단점은 내부자 위험이 뚜렷하게 감소할 때까지 시간이 걸릴 수 있다는 것입니다. 이러한 지연으로 인해 가치를 제시하거나 다른 사람들이 시행 메커니즘을 채택하도록 유도하는 것이 어려워질 수 있습니다. BAB팀이 시행에 대한 비상 대응 절차를 제공했을 때 서비스 소유자는 필요한 경우 대비책을 이용할 수 있으므로 시행 메커니즘을 채택하려고 하는 경향이 더 높아졌습니다.

여러 팀 간 변경 관리자를 등록합니다.

Google 차원에서 BAB 배포 의무를 만들었을 때, 각 제품 그룹의 변화를 주도할 소유자를 찾는 게 성공률을 크게 좌우했습니다. 이들의 도움으로 공식적인 변경 관리팀을 구성하여 지속적인 변경사항을 추적했습니다. 그런 다음 각 제품 팀에서 변경사항을 구현할 책임이 있는 소유자를 파악했습니다.

타사 코드를 관리하는 방법을 파악합니다.

이 백서에서 설명한 CI/CD 제어 기능 중 다수는 단일 조직에서 코드를 개발, 검토, 유지관리하는 경우에 적용됩니다. 이러한 경우에 해당하면 정책 요구사항의 일부로 타사 코드를 어떻게 포함할 것인지 고려하세요. 예를 들어 처음에는 해당 코드를 제외하되 사용된 모든 타사 코드의 저장소를 유지하는 방향(이상적인 상태)으로 전환하여 보안 요구사항에 따라 해당 코드를 정기적으로 검사할 수 있습니다.

마무리

Google은 컨테이너화된 인프라 및 CI/CD 프로세스의 일부로 배포-시간 시행 확인을 구현함으로써 배포하는 코드 및 구성이 보안에 대한 특정 최소 기준을 충족하는지 확인할 수 있었습니다. 이는 악의적인 내부자가 사용자 데이터에 액세스할 수 있는 승인되지 않은 작업을 실행할 가능성을 제한하는 데 사용되는 중요한 제어 기능입니다. BAB 채택을 통해 Google은 내부자 위험을 최소화하고 공격 가능성을 차단하며 프로덕션 시스템의 균일성을 지원할 수 있었습니다.

추가 참조

Google의 전반적인 보안 및 컨테이너화된 인프라에 대해 자세히 알아보려면 다음 리소스를 참조하세요.

참고

1 출처란 구성요소, 구성요소의 변경사항, 관련 출처를 설명합니다. 참조 링크: https://csrc.nist.gov/glossary/term/Provenance

2 Borgmaster는 Borg의 중앙 집중식 컨트롤러로, 작업 예약을 관리하고 실행 중인 작업과 현재 상태에 대해 통신합니다.