Binary Authorization for Borg: コードの出所を確認してコード ID を実装する方法

Google ではいくつかのホワイトペーパーで、セキュリティ チームが社内で開発したセキュリティ向上のためのプロジェクト(BeyondCorpBeyondProd など)について説明しています。Google のセキュリティの概要については、セキュリティ インフラストラクチャの設計ホワイトペーパーをご覧ください。

このホワイトペーパーでは、Google のコードレビュー プロセス、その出所1、強制適用メカニズムの必要性について説明しています。また、Binary Authorization for Borg(BAB)という、具体的な強制適用チェックの開発に重点を置いています。BAB の目標は、Google でデプロイする本番ソフトウェアが(特にそのコードがユーザーデータにアクセスできる場合に)適切に審査および承認されていることを確認し、インサイダー リスクを低減することです。Google ではすべてのプロダクトでユーザーデータの保護を重視し、可能な限り透明性の高いセキュリティ対策を講じるよう努めています。

このホワイトペーパーの内容は 2019 年 12 月時点のものです。本ドキュメントは作成時点の状況を表しています。お客様の保護の継続的改善のため、Google Cloud のセキュリティ ポリシーおよびシステムは適宜変更される場合があります。

CIO レベルの概要

  • インサイダー リスクは、ユーザーデータのセキュリティ脅威の一つです。Google は、Google の従業員が組織の知識を使用したり、ユーザーデータに不正アクセスしたりする(不正なジョブの実行を含む)可能性を最小限に抑えたいと考えています。
  • Binary Authorization for Borg(BAB)はデプロイ時に内部で行われる強制適用チェックのことで、Google にデプロイされた本番ソフトウェアと構成が(特にそのコードがユーザーデータにアクセスできる場合に)適切に確認および承認されるようにすることで、インサイダー リスクを最小限に抑えます。
  • BAB の実施は、コードと構成のデプロイが特定の最小基準を満たしているいことの保証になります。
  • 強制適用チェック以外に、非強制監査モードで BAB を使用して、特定の要件が満たされていない場合に生成される警告を確認することもできます。
  • BAB を導入することで、Google におけるインサイダー リスクの低減、起こりうる攻撃の阻止、Google の本番環境システムの均一性のサポートに役立っています。

Google におけるインサイダー リスクを最小限に抑える

Google はセキュリティを最優先事項とする企業として、インサイダー リスク(Google の従業員やその他組織に所属する人物が組織の知識を使用する、または不正アクセスを行う可能性)を抑制するための対策を講じています。こうしたリスクには、攻撃のために Google の従業員の認証情報を不正使用するというシナリオも含まれます。Google は、インサイダー リスクから保護するためのイノベーションに多大なリソースを投入してきました。また、ユーザーデータの保護を最重要事項に掲げ、包括的な保護を行うため努めています。Google の目標は、社内の従業員が承認なしでユーザーデータにアクセスするのを防ぐことです。

ユーザーデータへのアクセスの承認

Google では、サービスや従業員がユーザーデータにアクセスする必要が生じることがあります。ユーザーデータは次の方法で操作されます。

  1. エンドユーザーとして: サービスを使用する従業員がサービスに対して直接認証を行い、サービスから自身のデータが返されます。たとえば、従業員が Gmail アカウントにログインすると、自分のメールが表示されます。
  2. 役割の一環として: Google の従業員が行う作業の大部分は、匿名化されたユーザーデータを使用して完了できます。ただし、まれに業務の一環として、Google の従業員がユーザーデータにアクセスする必要がある場合があります(サポートやデバッグを行う場合など)。Google では、ユーザーデータへのアクセスに関して可能な範囲で最大限の透明性を提供することを目指しています。その方法の一つがアクセスの透明性で、これは Google Cloud のお客様がリアルタイム ログを使用して、ご自身のデータへのアクセスが適格かどうかを確認できる機能です。
  3. プログラムによりサービスの一部として: タスクを達成するために、サービスからユーザーデータへの大規模なアクセスをプログラムで行うことがあります。たとえば、データ パイプラインは、集計された使用統計情報を生成するために多数のユーザーのデータを一度にクエリします。このようなニーズが発生すると、個々のユーザーのデータではなく、データセットに対するアクセスが許可されます。個々のユーザーのデータへのアクセスはログに記録されません。

このホワイトペーパーでは、3 つ目のシナリオで提示された脅威モデルについて説明します。Google は、ユーザーデータにアクセスするシステムを実行する管理者が、その権限を乱用することがないようにしたいと考えています。

脅威モデル

このホワイト ペーパーで説明する管理方法は、一方的なアクセスを防止してユーザーデータを保護するために構築されたものです。Google は、Google の従業員が適切な承認と正当な理由なく、ユーザーデータに直接的または間接的にアクセスする、データに影響を与えるなどの単独行動を取らないようにしたいと考えています。Google の管理方法では、操作者に悪意があるか、アカウントが不正使用されているか、意図せず承認が付与されているかどうかにかかわらず、このような行為を防止します。

Google のコンテナ化されたインフラストラクチャ

Google のインフラストラクチャは、Borg というクラスタ管理システムを使用してコンテナ化されます。複数のクラスタでさまざまなアプリケーションの数十万のジョブを実行し、各クラスタには最大数万台のマシンがあります。こうした規模にもかかわらず、本番環境では高い均一性が確保されています。その結果、ユーザーデータへのアクセスのタッチポイントをより簡単に制御、監査できます。

さらに、コンテナを使用することで、重要なセキュリティ上のメリットを得ることができました。コンテナは不変に使用されることを意図したものであるため、コンテナ イメージがビルドし直されるとデプロイされることになります。この不変性から生じるデプロイ回数の多さを利用してコンテキスト内でコード変更をレビューでき、これが Google のインフラストラクチャにデプロイされるすべての変更内容の単一のチョーク ポイントとなっています。

サービスからユーザーデータへのプログラムによるアクセスを制限するソリューションを Google がどのように開発したのかご理解いただくには、まず Google でサービスが製品版になる過程をご理解いただくことが重要です。

手順 1: コードのレビュー

Google のソースコードはモノリシックな中央リポジトリに格納されるため、数千人の従業員がコードを 1 か所でチェックできます。1 つのコードベースを使用すると、ソースコードの管理、特にサードパーティのコードへの依存を簡素化できます。モノリシック コードベースによって、コードレビューのための単一のチョーク ポイントの強制適用も可能になります。Google のコードレビューには、作成者を除く 1 人以上のエンジニアによる検査と承認が含まれています。このコードレビューのプロセスでは、少なくともシステムのコード変更をそのシステムのオーナーが承認する必要があるというルールが適用されます。コードはチェックインされると、ビルドされます。

サードパーティーまたはオープンソースのコードから変更をインポートするときは、変更が適切であること(最新バージョンであるなど)を確認しています。ただし、Google が使用するサードパーティーまたはオープンソースのコードに対し外部のデベロッパーが行ったすべての変更については、同じレビュー管理体制を取らないことがよくあります。

ステップ 2: 検証可能なビルド

Google では Bazel に非常によく似たビルドシステムを使用しています。このビルドシステムでは、ソースコードがビルドおよびコンパイルされて、デプロイ用のバイナリが作成されます。Google のビルドシステムは、ビルドを実行する従業員から離れた遮断された環境で実行されます。ビルドごとに、検証可能なビルド マニフェスト(ビルドに入ったソース、バイナリやその他のビルド アーティファクトの暗号ハッシュ、ビルド パラメータを完全に記述した署名入りの証明書)が作成されます。このマニフェストを使用すると、バイナリからその作成に使用されたソースコード、その拡張としてそのソースコードの作成と送信に使用されたプロセスまでトレースできます。さらに、ファイルを変更すると自動的に署名が無効になるため、バイナリが変更されていないことも確認できます。

ビルド アクションは理論上は任意のコードにできるため、Google のビルドシステムはマルチ テナンシー用に強化されています。つまり、あるビルドがその他のビルドに影響を与えないように設計されています。このシステムにより、検証可能なビルド マニフェストやシステム自体の整合性を損なうようなビルドの変更が阻止されます。ビルドが完了すると、Borg を使用して変更がデプロイされます。

ステップ 3: デプロイジョブの実行

ビルドされたバイナリは、Borg ジョブとしてコンテナ化インフラストラクチャにデプロイできます。これらのジョブでは、バイナリまたはデータを含むパッケージを使用します。インストールは Borg によって管理されます。Borg の構成では、デプロイするジョブ、パッケージ、ランタイム パラメータ、引数、フラグの要件を指定します。Borg はジョブをスケジュールする際に、その制約、優先度、割り当て、構成にリストされているその他の要件を考慮します。Borg ジョブがデプロイされると、本番環境のその他のジョブとやり取りできるようになります。

ステップ 4: ジョブ ID

1 つの Borg ジョブは 1 つの ID として実行され、この ID を使用して、他のサービスのデータストアやリモート プロシージャ コール(RPC)メソッドにアクセスします。ID は、ロール(役割)アカウント(サービスなど)またはユーザー アカウント(各従業員の個人アカウントなど)のいずれかで、複数のジョブを同じ ID として実行することも可能です。特定の ID を持つジョブのデプロイや変更は、サービスを実行する担当者(一般には Google のサイト信頼性エンジニア(SRE))に制限されます。

Borg によってジョブが開始されると、暗号認証情報とともにジョブがプロビジョニングされます。ジョブはこれらの認証情報を使用して、その他のサービスをリクエストするときに(Application Layer Transport Security を使用して)その ID を証明します。サービスから特定のデータや別のサービスにアクセスするには、その ID に必要な権限が付与されている必要があります。Google Cloud の Cloud Data Loss Prevention(Cloud DLP)API などのサービスの例を考えてみましょう。DLP API がスキャン用のデータにアクセスするには、2 つのことが必要です。まず、DLP API を個別の ID で実行するように構成する必要があります。この場合はロール アカウントです。次に、DLP API がスキャンするデータの権限にそのロール アカウントを含める必要があります。有効な ID と正しい権限がない場合、サービスはスキャンを実行できません。

Google のポリシーにより、ユーザーデータやその他の機密情報にアクセスできるロール アカウントは、BAB やその他のセキュリティ システムによって厳重に管理される必要があります。機密性の高いデータやリソースにアクセスしない品質保証業務や開発業務は、管理を減らして実行することが許可されています。

すべて一括で: ジョブのライフサイクル

インフラストラクチャでジョブを実行する大まかな手順は次のとおりです。

  1. Google のデベロッパーがコードの変更を作成します。その他の 1 人以上の Google エンジニアに送り、レビューしてもらいます。レビューには、適切な承認とロギングのチェックが含まれます。承認されると、コードがチェックインされます。
  2. デベロッパーがトリガーすると、ビルドシステムはサンドボックス環境でバイナリを検証してビルドし、パッケージ化します。このビルド オペレーションでパッケージが生成され、ビルドシステムによって検証の目的で署名されます。
  3. 適切で安全な ID で実行されるジョブの管理権限を持つエンジニアによって、ジョブが Borg にデプロイされます。
  4. Borg ジョブがユーザーデータなどの権限のあるリソースにアクセスしようとすると、ジョブの ID が認証のために検証されます。

本番環境でジョブがどのように実行されるかを説明したので、次は BAB が対処する脅威モデルを見てみましょう。ここでは、悪意のある潜在的なインサイダーによる不正ジョブの実行が阻止されます。これを実現するため、BAB はバイナリがデプロイされる前に必要なセキュリティ チェックがすべて行われたことを確認します。

このセクションでは、コンテナ化されたインフラストラクチャの概要を説明しました。プログラムによるデータへのユーザー アクセスに対する Google の管理方法を理解するには、本番環境についての基本的な理解が必要になります。これらの管理方法については、次のセクションで詳しく説明します。

Binary Authorization for Borg(BAB)

Google では数年にわたり、ユーザーデータを手動アクセスから保護するための取り組みを行ってきました。これらの取り組みでは、データとジョブの管理アクセスを、業務を遂行するために必要とする Google 従業員に制限しています。

BAB の使命は、Google にデプロイされているすべての本番環境ソフトウェア(特にユーザーデータにアクセスできるコード)と構成が適切にレビューされて承認されるようにすることです。BAB はこの使命を果たすべく、デプロイ時の強制適用サービスを提供して、不正なジョブが開始されないよう阻止します。さらに、BAB 対応のジョブでは、使用されたコードと構成の監査証跡も提供します。

検証

BAB は、バイナリのデプロイ時に、そのバイナリが特定の要件を満たしていることを検証します。たとえば、サービス オーナーは、レビュー、チェックイン、テスト、承認のプロセスを経たコードからビルドされたバイナリのみをサービスに使用することを要件にする場合があります。このような要件のチェックは、デプロイ時チェックと呼ばれます。BAB では、デプロイの後に、デプロイ後チェックを実行することもできます。デプロイ後の検証について詳しくは、強制適用モードのセクションをご覧ください。

コードを変更すると、新しいバイナリが作成されます。コードの変更を適用するには、新しいバイナリをデプロイする必要があります。BAB では、さまざまなデプロイ時チェックを行えます。以下に、これらのチェックの数例を示します。

  • チェックインされたコードからビルドされたバイナリであるかどうか

    コードが Google のソースコード リポジトリに送信されてチェックインされているかどうかをチェックします。コードを提出するには、2 人目の Google エンジニアによるレビューが完了している必要があります。

  • 検証可能な形でビルドされたバイナリであるかどうか

    監査可能なソースまで追跡できるバイナリであるかどうかをチェックします。また、承認されたビルドシステムによってビルドされたものであるかどうかもチェックします。

  • テスト済みのコードからビルドされたバイナリであるかどうか

    バイナリがテスト要件を満たしているかどうかをチェックします。

  • デプロイで使用する予定のコードからビルドされたバイナリであるかどうか

    バイナリがビルドされたコードが、その特定の Borg ジョブに関連するプロジェクトまたはチームに対応するソースコード リポジトリの該当する領域に送信されているかどうかをチェックします。

以上の要件は Google の本番環境に固有のものですが、CI / CD(継続的インテグレーション / 継続的デプロイ)環境でも、それぞれに固有のセキュリティ、コンプライアンス、信頼性の要件に基づいて同様の要件を適用できます。

サービス固有のポリシー

通常、機密データにアクセスするジョブの場合はコードを提出することが要件となりますが、ビジネス上の正当な理由から、この要件が例外的に適用されない場合もあります。機密データには、ユーザーデータ、雇用データ、財務データのほか、必知事項の専有データやビジネスデータが含まれます。Google でのすべてのジョブには、ポリシーの適用が必須とされています。ポリシーは、ユーザーデータにアクセスする必要のない Borg ジョブに対しても定義されますが、具体的な要件は記載しません。

サービス オーナーは BAB にオンボーディングする際に、サービスのセキュリティ要件を規定したポリシーを定義します。サービスの実装に使用するすべてのロール アカウントでは、BAB ポリシーを指定する必要があります。BAB ポリシーで、各ロール アカウントで起動する対象となるジョブと、そのジョブのコードおよび構成要件を定義します。ポリシーの定義や変更は、それ自体がコードの変更であるため、レビューする必要があります。

BAB ポリシーで適用できる要件は次のとおりです。

  • コードが検証可能な形でビルドされていること: 検証可能な形でビルドされているコードは監査可能ですが、必ずしもコードレビューが実施されたことを意味するわけではありません。コードが提出されていない場合もあります。検証可能なビルドで使用されたコードは、提出されていないとしても少なくとも 18 か月間は監査可能です。

  • コードが提出されていること: コードはソース リポジトリ内の指定された対象の場所からビルドされます。これは通常、コードに対してコードレビューが実施されたことを意味します。

  • 構成が提出されていること: デプロイ時に提供される構成には、いずれも通常のコードと同じレビューおよび提出プロセスが適用されます。そのため、レビューを受けずにコマンドライン フラグの値、引数、パラメータを変更することはできません。

BAB を適用するシステムとコンポーネントは厳重に管理する必要があります。それには、可能な限り厳しい要件を実装するとともに、手動でも管理します。

強制適用モード

BAB は、Borg ジョブによって指定されたポリシーに基づき、さまざまなアクションを実行します。これらのアクションは、強制適用モードと呼ばれます。強制適用モードには、デプロイ時の強制適用、デプロイ時の監査、継続的な検証の 3 つがあります。サービス オーナーは、ポリシーを定義する際にデプロイ時の適用またはデプロイ時の監査のいずれかのモードを選択する必要があります。デフォルトでは、継続的な検証モードが有効にされます。以降のセクションで、それぞれのモードについて詳しく説明します。

デプロイ時の強制適用モード

新しいジョブが送信されると、BABmaster2 は、そのジョブが BAB ポリシーで規定されている要件を満たしているかどうかを確認します。このチェックは、アドミッション コントローラとして機能します。要件が満たされている場合、Borgmaster はジョブを起動します。要件が満たされていない場合、リクエストを行ったユーザーが別の方法で承認されているとしても、Borgmaster はリクエストを拒否します。

強制適用モードでは、BAB ポリシーで規定されている要件を満たしていない Borg ジョブのデプロイは、BAB によってブロックされます。通常、BAB を初めて使用するサービスは最初に監査モード(次のセクションで説明)で開始され、後から強制適用モードに移行します。

緊急時の対応手順

インシデントまたはダウンタイムが発生した場合、該当するサービスのできるだけ迅速な復旧が最優先されます。緊急時には、まだレビューやチェックインが行われていないコードを実行しなければならない場合があります。その場合、緊急時対応フラグを使用して強制適用モードをオーバーライドできます。また、緊急時対応手順は、BAB に障害が発生してデプロイがブロックされた場合のバックアップとしても機能します。緊急時対応手順を使用してジョブをデプロイするデベロッパーは、リクエストの一部として正当な理由を提出する必要があります。

緊急時対応手順が使用されてから数秒以内に、BAB は関連する Borg ジョブの詳細をログに記録します。ログには、使用されたコードとユーザーが提出した理由も記録されます。数秒後に、一元化されたセキュリティ チームに監査証跡が送信されます。数時間以内に、ロール アカウントを所有するチームに監査証跡が送信されます。緊急時対応手順は、最後の手段としてのみ使用するよう意図されています。

デプロイ時の監査モード

監査モードでは、BAB はポリシーの要件を満たしていない Borg ジョブをログに記録しますが、Borg ジョブのデプロイをブロックすることはしません。このポリシー違反によって、ロール アカウントを所有するチームに対するアラートがトリガーされます。

Google では、特定のサービス(ユーザーデータにアクセスするサービスなど)には強制適用モードを使用することを要件としています。すべてのサービス オーナーに、強制適用モードを使用することと、監査モードを新しいサービスのオンボーディング時にのみ使用することを強くおすすめします。監査モードを使用するには、サービス オーナーが例外の適用を正当化する理由を提出する必要があります。たとえば、信頼性の SLO(サービスレベル目標)が BAB で規定している SLO を大幅に上回っているサービスでは、監査モードを使用することになります。

監査モードは初期ポリシーを微調整する際には役立ちますが、このモードではサービスが安定した状態にはならないため、ほとんどのサービスには実用的ではありません。監査モードを使用している場合、サービス オーナーにポリシー違反が通知されるのは、サービス違反が発生してから数時間後になります。このため、ノイズとなる通知が絶え間なく送信されて、ミスやサービス オーナーによるポリシーの設定ミスにより真のセキュリティ問題が埋もれて見落とされる可能性があります。強制適用モードでは、サービス オーナーがポリシーに準拠していないジョブを起動しようとすると、直ちにフィードバックが返されます。したがって、送信される通知がはるかに明確になります。さらに BAB の強制適用モードでは、ジョブを実行するよう指定された以外の役割で誤ってジョブを起動した場合など、故意ではないエラーも捕捉されます。

継続的な検証

ジョブがデプロイされると、デプロイ時に適用したかどうかにかかわらず、ジョブの存続期間中は継続的な検証が行われます。少なくとも 1 日 1 回は、開始された(場合によってはまだ実行中の)ジョブがポリシーの更新に適合しているかどうかを確認する BAB プロセスが実行されます。継続的な検証モードでは、たとえば古くなったポリシーで実行されているジョブや、緊急時対応手順を使用してデプロイされた ID で実行されているジョブの有無が常に確認されます。更新後のポリシーに準拠していないジョブが見つかった場合は、リスクを軽減できるよう、BAB がサービス オーナーに通知します。

グローバルに許可されたパッケージ

Google では、いくつかのパッケージを Google サービスの多くで広範に使用しています。これらのパッケージは、各サービスに独自のバージョンを維持させるのではなく、一元的に許可されます(グローバル管理パッケージと呼ばれます)。サービス オーナーは、BAB ポリシーを作成するときに、所定のジョブに対してグローバルに許可されたパッケージを指定できます。また、広範に使用されているパッケージにはグローバルなデフォルト メカニズムがあるため、これらのパッケージを各サービスのポリシーの一部として個別にリストする必要はありません。これにより、Google は組織全体で使用される共通のシステム コンポーネントの明示的な管理を維持し、個別のチームを関与させずに適切にレビュー、更新されるようにしています。個々のサービス オーナーがサービスの BAB ポリシーの一部として明示的にパッケージを許可することもできますが、グローバルに許可されたパッケージを使用すると、サービス オーナーは推奨されるサポート対象のパスに容易に従うことができます。

エッジケース

Google では、コードレビュー検証可能なビルドを含め、本番環境にデプロイされたコードのセキュリティを強固に管理します。BAB はセキュリティ管理を強化し、実施するポイントとして機能することで、これらのセキュリティ管理が実際に適切に行われるようにします。

ただし、あらゆるケースで BAB を効果的に使用できるわけではありません。BAB でサポートしていないエッジケースとしては、標準以外のビルドシステムを使用してビルドされたコード、Borg 以外の環境にデプロイされたコードが挙げられます。また、最終的な本番環境でのパラメータが選択されるまでは人間によるコードレビューに役立たない、データ分析と機械学習のコードもエッジケースに含まれます。こうしたケースでは、コードの出所を確認するシステムを含め、他のさまざまなセキュリティ対策が講じられます。それでもなお、コードは Google の一般的なセキュリティ管理の対象となります。

Binary Authorization for Borg の実装

BAB を実装するために、BAB チームは緊急時の対応手順や監査モードを含め、いくつかの新機能を開発しました。これらのツールは、サービス オーナーができるたけ簡単に BAB を試せるようにするためのものです。組織に BAB のような機能を導入することを検討している場合、この移行を促すために追加の作業が必要になることがあります。このセクションでは、Google が実装計画の一環として行った、組織管理作業とチェンジ マネジメント作業について説明します。

利点

Google での BAB の開発と導入に向けてビジネスケースを作成するにあたり、BAB の 3 つの利点(インサイダー リスクの低減、堅牢なコード ID、コンプライアンス タスクの簡素化)が役立ちました。

インサイダー リスクの低減

BAB が開発された主な目的は、個人がプログラムによって不正にユーザーデータにアクセスできないようにすることです。BAB を使用すると、1 人のエンジニアや、エンジニアの認証情報を取得した攻撃者が、検出の目をかいくぐり機密データに不正にアクセスすることが困難になります。

堅牢なコード ID

コンテナ化されたインフラストラクチャのセクションで説明したように、Borg ジョブはある ID(通常はロール アカウント)として実行されます。他のサービスはジョブにデータへのアクセス権を付与する前に、この ID を使用して、そのジョブが適切な承認を得ていることを確認します。ただし、他のサービスがジョブにデータの使用法を強制することはできないため、そのジョブ ID が受け取ったデータを悪用しないことを信用するしかありません。BAB はジョブ ID を特定のコードに関連付け、ジョブ ID の権限を行使する際は指定されたコードしか使用できないようにします。これにより、ジョブ ID からコード ID への移行が可能になります。つまり、あるジョブ ID とある権限を付与されたユーザーを信用するという仕組みから、承認されたプロセスでなければ変更できないあるセマンティクスを持つことが審査により確認された特定のコードを信用するという仕組みに遷移的に移行できます。

コンプライアンス タスクの簡素化

BAB により、これまで手動で行われていたコンプライアンス タスクが簡素化されました。Google での特定のプロセスでは、データの処理方法をより厳重に管理する必要があります。たとえば、Google の財務報告システムはサーベンス オクスリー法(SOX)に準拠していなければなりません。BAB が開発されるまで、Google ではコンプライアンスを確実にするための手動による検証をサポートするシステムを使用していました。BAB を導入した結果、これらのチェックの多くがサービスの BAB ポリシーに基づいて自動化されました。こうしたチェックが自動化されたことで、コンプライアンス チームはサービスの対象範囲を拡大できただけでなく、これらのサービスに適切な管理機能を導入できました。

サービスのオンボーディング

BAB チームは、オンボーディング プロセスをシンプルでわかりやすいものにする必要がありました。当初、BAB の導入に関して、Google のサービス オーナーは主に次の 2 点を懸念していました。

  • BAB の信頼性が十分でない場合、BAB を実装すると、危機的な状況で変更がブロックされる恐れがある。
  • BAB を使用すると、頻繁なコードのチェックインと反復プロセスによってサービスの開発に時間がかかる可能性がある。

最初の懸念に対処するために BAB チームによって開発されたのが、監査モードです。BAB チームはこのモードを使用して、主要な先行ユーザーたちに BAB が有効であることを証明しました。BAB の信頼性をさらに向上させるために、BAB チームは可用性 SLO を策定するとともに、強制適用モード緊急時の対応手順を導入しました。

通常、サービス オーナーが既存のサービスを BAB にオンボーディングする際は、まず監査専用モードを有効にします。これにより、強制適用モードを有効にする前に問題を特定し、対処できます。本番環境で BAB を使用するジョブには、いずれもデフォルト ポリシーとして強制適用モードが設定されます。サービス オーナーがジョブをデプロイするには、少なくともコードを提出すること、そして検証可能な形でコードをビルドすることを要件とするポリシーを提出する必要があります。サービス オーナーはこの最小基準を満たしていないジョブでもデプロイできますが、その場合、ジョブが例外として認められている必要があります。サービスでより機密性の高いデータやサービスにアクセスする必要がある場合、オーナーはより厳格な要件に移行できます。初期ポリシーを定義するのは難しい場合があるため、BAB チームは、ポリシーを作成できるようサービス オーナーをサポートするための自動ツールを作成しました。これらのツールは、ソース リポジトリで既存のジョブに使用されている部分を確認し、適切なポリシーを提案します。

サービス オーナーが新しいサービスを BAB にオンボーディングするときは、最初から強制適用モードを有効にします。サービス オーナーは初期ポリシーの下書きを作成し、それを基に迅速に繰り返し要件を追加していきます。ポリシー自体はコードとして管理されるため、変更する際は 2 人目の Google エンジニアによる更新のレビューが必要になります。

効果

BAB とコンテナ化されたデプロイモデルを採用した結果、セキュリティとサポート性に関して Google にさまざまなメリットがもたらされています。

  • BAB による全体的なインサイダー リスクの低減: BAB は、コードが特定の基準を満たし、チェンジ マネジメント手法に従っていることを要件とします。これらの要件を満たすコードでなければユーザーデータにアクセスできないため、Google 社員が単独で(または Google 社員のアカウントを不正使用して)プログラムによってユーザーデータにアクセスするリスクが低減されています。
  • BAB による本番環境システムの一貫性のサポート: コンテナ化されたシステムを使用し、デプロイ前に BAB 要件を検証するため、Google システムがデバッグしやすくなり、システムの信頼性が向上しています。さらに、より明確にチェンジ マネジメントを行えるようになりました。BAB の要件は、本番環境システムの要件に関する共通言語となっています。
  • データ保護に関する共通言語を BAB が決定: BAB は、システム全体にわたり適合性を追跡します。この適合性に関するデータは社内で公開され、他のチームが照会できます。このように BAB データを公開すると、チーム間でデータ保護に関して情報を交換するときに共通の用語を使用できます。この共通言語により、チーム間でデータを処理する際に確認のために何度もやり取りする必要が軽減されています。
  • BAB を使用した、プログラムによるコンプライアンス要件の追跡: 財務報告などの特定のプロセスでは、コンプライアンス準拠のために特定のチェンジ マネジメント要件を満たす必要があります。BAB を使用すると、これらの要件チェックを自動化できるため、時間を節約し、対象範囲を広げることができます。

BAB は、Google がインサイダー リスクを低減するために使用しているテクノロジーの 1 つです。

組織への同様の管理機能の導入

Google は、BAB の実装から多くの重要な教訓を学びました。このような大々的な変更は、手強いタスクのように思えるかもしれません。このセクションでは、BAB の原則を組織に適用できるよう、変更の過程で学んだ教訓をご紹介します。

コンテナ化 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 として扱うことができます。

既存のサービス オーナーのオンボーディング方法を決定する。

強制適用がもたらす直接的なメリットを理解し、喜んでフィードバックを提供してくれる少数のサービス オーナーを特定してください。そのための 1 つの方法としては、変更を必須とする前に、オーナーからボランティアを募ることが考えられます。

可能であれば、監査モードではなく強制適用モードを要件とします。あるいは、強制適用モードに切り替えるまでの猶予期間として監査モードが使用されるようにします。監査モードでは、オーナーはすぐにオンボーディングしてインサイダー リスクの理解を深めることができます。その一方で、監査モードには、インサイダー リスクが明らかに減少するまでに時間がかかるという欠点があります。このように時間がかかると、強制適用の価値が明らかになりにくいため、その他のオーナーに採用を説得するのが困難になります。BAB チームが強制適用モードに緊急時の対応手順を導入し、必要に応じて回避策を使用できるようにした時点で、サービス オーナーは強制適用モードを進んで採用するようになりました。

すべてのチームのチェンジ エージェントに協力を求める。

成功率に大きく影響した要因は、BAB 導入に関する Google 全体の要件を作成する際に、各プロダクト グループで変更を推進するオーナーを見つけたことでした。オーナーたちの協力を得たあと、進行中の変更を追跡する正式なチェンジ マネジメント チームを立ち上げ、各プロダクト チームで変更を実装する責務を負うオーナーを特定しました。

サードパーティのコードを管理する方法を見つけ出すこと。

このドキュメントで説明している CI / CD の管理機能の多くは、1 つの組織によってコードの開発、レビュー、管理が行われる状況で適用されます。このような状況にある場合は、ポリシーの要件にサードパーティのコードを含める方法を検討してください。たとえば、最初はサードパーティのコードをポリシーの適用対象外としたうえで、使用されるすべてのサードパーティのコードがリポジトリに保持されるという最適な状態へと徐々に移行して、定期的にセキュリティ要件に照らし合わせてコードを詳細に検査するという方法も考えられます。

まとめ

Google のコンテナ化されたインフラストラクチャと CI / CD プロセスの一部としてデプロイ時の強制適用チェックを実装したことにより、デプロイするコードと構成が一定の最小限のセキュリティ基準を満たしていることを確認できるようになりました。デプロイ時の強制適用チェックは、悪意のあるインサイダーがユーザーデータにアクセスする可能性のある不正なジョブを実行できないようにするために使用される不可欠の管理機能です。BAB の導入は、Google におけるインサイダー リスクの低減、起こりうる攻撃の阻止だけでなく、Google の本番環境システムの均一性のサポートにも役立っています。

その他の参考資料

Google の全体的なセキュリティとコンテナ化されたインフラストラクチャの詳細については、次のリソースをご覧ください。

1 「出所」とは、コンポーネント、コンポーネントに対する変更、およびその起点を表します。https://csrc.nist.gov/glossary/term/Provenance をご覧ください。

2 Borgmaster は、Borg の一元化されたコントローラです。ジョブのスケジューリングを管理し、実行中のジョブと通信してそのステータスを伝えます。