Binary Authorization for Borg

このコンテンツの最終更新日は 2024 年 5 月で、作成時点の状況を表しています。お客様の保護の継続的な改善のために、Google のセキュリティ ポリシーとシステムは変更される場合があります。

このドキュメントでは、コードレビュー、セキュリティ インフラストラクチャ、Binary Authorization for Borg（BAB）の適用チェックを使用して、Google のソフトウェア サプライ チェーンをインサイダー リスクから保護する方法について説明します。BAB は本番環境のソフトウェアがデプロイ前に審査、承認されていることを確認します。これにより、特にコードに機密データへのアクセスが許可されている場合に、インサイダー リスクを低減できます。BAB は、Borg で実行されているすべてのサービスに適用されます。このドキュメントを最初に公開してから、BAB の主なコンセプトをソフトウェア アーティファクトのためのサプライ チェーン レベル（SLSA）いうオープン仕様に追加しています。

このドキュメントは、Google セキュリティ チームが開発した BeyondCorp や BeyondProd などのセキュリティ プロジェクトを取り上げた一連の技術論文の一部です。インフラストラクチャのセキュリティの概要については、Google インフラストラクチャのセキュリティ設計の概要をご覧ください。

はじめに

インサイダー リスク は、雇用データ、財務データ、またはその他の専有データやビジネスデータなど、ユーザーデータのセキュリティに対する脅威を表します。 インサイダー リスクとは、従業員が組織の知識を不正に利用して悪意のある行為を行うことや、外部攻撃者が不正使用された認証情報を使用して悪意のある行為を行う可能性のことです。

ソフトウェア サプライ チェーン内のインサイダー リスクを最小限に抑えるために、Google では BAB を使用しています。BAB は、ソフトウェアのデプロイ時に実行される内部適用チェックです。BAB により、コードと構成のデプロイが特定の最小基準を満たし、Google の本番環境システムで均一性を確保できます。

Google の本番環境システム内のユーザーデータを保護するために、Google の社員による一方的なアクセスを制限しています 。BAB を使用すると、従業員は適切なアクションを実行できますが、適切な承認と正当な理由なく、ユーザーデータに直接的または間接的にアクセスすることや、データに影響を与えることができなくなります。BAB とそれに関連する管理は最小権限の適用に役立ち、特定の脅威アクターに関係なく、セキュリティ ポスチャーを向上させることができます。つまり、BAB は、行為者に悪意があるか、アカウントが不正使用されているか、意図せずアクセス権が付与されているかどうかにかかわらず、一方的なアクセスを制限します。

BAB のメリット

BAB とコンテナ化されたデプロイモデルを採用した結果、Google のインフラストラクチャに数多くのセキュリティ上の利点がもたらされています。これには、次のような利点があります。

• BAB による全体的なインサイダー リスクの低減: BAB では、コードがユーザーデータにアクセスする前に、コードが特定の基準を満たし、チェンジ マネジメント プラクティスを遵守している必要があります。この要件により、単独で行動する従業員（または不正使用された従業員アカウント）がプログラムによってユーザーデータにアクセスする可能性が低くなります。
• BAB による本番環境システムの一貫性のサポート: コンテナ化されたシステムを使用し、デプロイ前に BAB 要件を検証するため、Google システムがデバッグしやすくなり、システムの信頼性が向上しています。また、計画に定義されたチェンジ マネジメント プロセスを実施できます。BAB の要件は、本番環境システムの要件に関する共通言語となっています。
• データ保護に関する共通言語を BAB が決定: BAB は、Google のシステム全体にわたり適合性を追跡します。この適合性に関するデータは社内で公開され、他のチームが利用できるようになっています。BAB データを公開すると、データアクセス保護に関して情報を交換する際に、共通の用語を使用できます。この共通言語により、チーム間でデータを処理する際に何度も確認を取り合う必要が軽減されています。
• BAB を使用した、プログラムによるコンプライアンス要件の追跡: BAB により、これまで手動で行われていたコンプライアンス タスクが簡素化されます。Google での特定のプロセスでは、データの処理方法をより厳重に管理する必要があります。たとえば、Google の財務報告システムはサーベンス オクスリー法（SOX）に準拠していなければなりません。BAB が開発されるまで、Google ではコンプライアンスを確実にするため、手動による検証をサポートするシステムを使用していました。BAB の導入により、これらのチェックの多くがサービスの BAB ポリシーに基づいて自動化されました。こうした検証が自動化されたことで、コンプライアンス チームはサービスの対象範囲を拡大できただけでなく、これらのサービスに適切な管理機能を導入できました。

BAB は、Google がインサイダー リスクを低減するために使用する大規模な BeyondProd フレームワークの一部です。

開発と本番環境プロセス

デフォルトでは、Google の開発と本番環境プロセスには、コードレビュー、検証可能なビルド、コンテナ化されたデプロイ、サービスベースの ID という 4 つの必須ステップがあります。以降のセクションでは、これらのステップについて詳しく説明します。

ステップ 1: コードのレビュー

ソースコードの大部分は、中央のモノリシック リポジトリ に格納されています。これらのソースコードに対して、作成者を除く 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 によってジョブが開始されると、暗号認証情報とともにジョブがプロビジョニングされます。ジョブはこれらの認証情報を使用して、その他のサービスをリクエストするときに Application Layer Transport Security（ALTS）を使ってその ID を証明します。 サービスから特定のデータや別のサービスにアクセスするには、その ID に必要な権限が付与されている必要があります。

Google のポリシーでは、ユーザーデータやその他の機密情報にアクセスできるサービス ID に対する BAB の保護が義務付けられています。 機密データにアクセスできない品質保証業務や開発業務は、より少ないコントロールでの実行が許可されています。

BAB の仕組み

BAB は、Borg と統合可能で 、承認済みのジョブのみが各サービスの ID で実行できるようにします。BAB では、モニタリングとインシデント対応のために、BAB 対応のジョブで使用されるコードと構成の監査証跡 も作成されます。

BAB は、すべての本番環境ソフトウェアと構成が適切に確認、チェックイン、検証可能な形でビルドされ、特にそのコードがユーザーデータにアクセスできるように設計されています。

サービス固有のポリシー

サービス オーナーは、Borg にサービスをオンボーディングする際に 、サービスのセキュリティ要件を定義する BAB ポリシーを作成します。このポリシーは、サービス固有のポリシーと呼ばれます。ポリシーの定義や変更は、それ自体がコードの変更であるため、レビューする必要があります。

サービス固有のポリシーは、サービスの ID として実行できるコードと構成のほか、そのコードと構成の必須プロパティを定義します。サービス ID として実行されるすべてのジョブは、サービス固有のポリシーを遵守する必要があります。

Google のすべての Borg サービスには、サービス固有のポリシーを構成する必要があります。

デフォルトでは、この方法により次の要件が適用されます。

• コードが監査可能な状態になっている必要がある: 検証可能なビルドによって生成された来歴を通じて、コンテナ イメージを人が読めるソースまで追跡できます。保持ポリシーにより、コードが送信されていない場合でも、人が読める形式のコードソースを少なくとも 18 か月間保持します。
• コードを提出する必要がある: コードは、ソース リポジトリ内の指定された定義済みの場所からビルドされます。送信は通常、コードに対してコードレビューが実施されたことを意味します。
• 構成を提出する必要がある: デプロイ時に提供される構成には、いずれも通常のコードと同じレビューおよび提出プロセスが適用されます。したがって、レビューを受けずにコマンドライン フラグの値、引数、パラメータを変更することはできません。

機密データにアクセスできないサービス、または有効で承認済みの例外があるサービス（まれなケース）では、より緩いポリシー（コードの監査可能性のみを要求するポリシーなど）や、BAB を完全に無効にするポリシーを適用できます。

BAB を適用するシステムとコンポーネントは、厳格な自動化要件と追加の手動制御により厳密に制御されます。

強制適用モード

BAB は 2 つの適用モードを使用して、ジョブがサービス固有のポリシーを遵守していることを確認します。

• デプロイ時の適用。これにより、非遵守のジョブのデプロイがブロックされます。
• 継続的検証。デプロイされた非準拠ジョブをモニタリングしてアラートを生成します。

また、緊急の場合、緊急時の対応手順でデプロイ時の強制適用をバイパスできます。

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

Borg Prime は Borg の一元化されたコントローラで、ALTS の認証局として機能します。新しいジョブが送信されると、Borg Prime は BAB を参照して、ジョブがサービス固有のポリシー要件を満たしているかどうかを検証してから、Borg Prime がジョブに ALTS 証明書を付与します。このチェックは、アドミッション コントローラとして機能します。Borg は、サービス固有のポリシーを満たす場合にのみジョブを開始します。このチェックは、デプロイ リクエストを行っている従業員またはサービスが別の方法で承認されている場合でも行われます。

まれに、十分な理由がある場合に、サービスがデプロイ時の適用をオプトアウトすることがあります。

継続的な確認モード

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

緊急時の対応手順

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

緊急対応時に、BAB は関連する Borg ジョブの詳細をログに記録し、Google の中央のセキュリティ チーム とサービス ID を所有するチームの両方に通知を送信します。 ログエントリには、デプロイされたコードのスナップショットへの参照と、ユーザーが提出した理由が含まれます。緊急時対応手順は、最後の手段としてのみ使用するよう意図されています。

BAB の他の環境への拡張

当初、BAB は Borg ジョブの保護のみをサポートしていました。ソフトウェアは、Google の従来のソース管理、ビルド、パッケージ化のパイプラインを使用して開発する必要がありました。現在、BAB には他のソフトウェア配信およびデプロイ環境の保護のサポートと、代替ソース管理システム、ビルドシステム、パッケージ化システムのサポートが追加されています。これらの環境では実装の詳細が異なりますが、BAB のメリットは残ります。

デプロイ前の人によるコードレビューに適していないケースもあります。特に、機械学習コードの反復型開発と高頻度データ分析には適していません。そのような場合に対応するため、人間による確認を補完する代替コントロールが用意されています。

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

このセクションでは、BAB を実装する際に学んだベスト プラクティスについて説明します。これにより、組織で同様のコントロールを導入できます。

同種のコンテナ化された CI / CD パイプラインを作成する

ほとんどのチームが単一のソース管理システム、コードレビュー プロセス、ビルドシステム、デプロイ システムを使用しているため、BAB の導入が容易になりました。コードレビューはすでに Google の文化の一部になっていたため、ユーザーに見えるような大幅な変更を行わずに変更を加えることができました。BAB の導入では、コードレビュー、検証可能なビルド、コンテナ化されたデプロイ、サービスベースの ID に重点を置いてアクセス制御を行いました。このアプローチによって BAB の導入が簡素化され、BAB のようなソリューションがもたらすメリットをより確実に享受できるようになりました。

ホストベースの ID（IP アドレスなど）ではなく、マイクロサービスとサービスベースの ID（サービス アカウントなど）を広く使用することで、それぞれを実行するためのソフトウェアをきめ細かく制御できるようになりました。

組織でサービス ID をすぐに採用できない場合は、暫定的な措置として他の手段で ID トークンを保護できます。

目標を決め、要件に基づいてポリシーを定義する

リリース プロセスをポリシーに基づいて一度に 1 つずつ作成します。他の変更に先立って特定の変更を CI / CD パイプラインに実装しなければならない場合もあります。たとえば、デプロイ時にコードを適用するには、その前に正式なコードレビューを実施しなければならない場合もあります。

ポリシーに基づくリリース プロセスの採用を決定付ける大きな要因はコンプライアンスです。コンプライアンス要件の少なくとも一部をポリシーにエンコードすれば、テストを自動化して、常に信頼された状態であることを確認できるようになります。基本的な要件一式から始めて、徐々に高度な要件を体系化してください。

開発の早い段階でポリシーを適用する

まず最初に、ソフトウェアがどこで実行され、どのデータにアクセスするかを把握しなければ、ソフトウェアに包括的なポリシーを定義するのは困難です。そのため、サービス固有のポリシーの適用は、コードのビルド時ではなく、コードのデプロイ時とコードがデータにアクセスするときに行われます。ポリシーはランタイム ID に対して定義されるため、同じコードを別の環境で実行する場合は、異なるポリシーを適用することもできます。

Google では、BAB とその他のアクセス メカニズムを併用してユーザーデータへのアクセスを制限しています。サービス オーナーは、特定の BAB 要件を満たすジョブだけがデータにアクセスすることを確認できます。

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

Google が全社に執行する BAB デプロイに関する指令書 を作成した際、その成功に大きく寄与したのは、各プロダクト グループごとにその変更を推進できるオーナーを特定したことでした。強制適用がもたらす直接的なメリットを理解し、積極的にフィードバックを提供してくれるサービス オーナーを何人か特定しました。変更を必須とする前に、オーナーにボランティアを依頼しました。オーナーたちの協力を取り付けたあと、進行中の変更を追跡する正式なチェンジ マネジメント チームを立ち上げ、各プロダクト チームで変更を実装する責務を負うオーナーを指名しました。

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

サードパーティのコードを管理する必要がある場合は、サードパーティのコードベースにポリシー要件を導入する方法を検討してください。たとえば、最初の段階ではサードパーティ コードのリポジトリを引き続き使用するのも良いでしょう。セキュリティ要件に基づいてコードを定期的に検証することをおすすめします。

サードパーティのコードの管理の詳細については、より安全なオープンソース コミュニティの構築における成功をご覧ください。

次のステップ

• BeyondProd について確認する。これにより、マイクロサービスの周囲に安全な境界を構築できます。
• 安全な CI / CD パイプラインを導入する。ソフトウェア アーティファクトのサプライ チェーン レベル（SLSA）をご覧ください。