Google が本番環境のサービスを保護する方法

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

Google は、世界中の何十億人ものユーザーにプロダクトやサービスを提供するため、グローバル スケールのマルチテナント分散コンピューティング インフラストラクチャを運用しています。このインフラストラクチャでは、セキュリティ、信頼性、耐障性、効率性、開発速度、デバッグ可能性など、競合する優先事項のバランスをとる必要があります。

このドキュメントでは、業界トップのセキュリティ ポスチャーを維持するために、Google の本番環境で稼働するサービスに対して Google が使用しているメカニズムについて説明します。これらのサービスには、機密データにアクセスできない開発テストから重要な ID インフラストラクチャまで、さまざまなセキュリティ感度が存在しています。これらのサービスは、ユーザーデータの処理、ソフトウェア ロールアウトの管理、個々の物理マシンのプロビジョニングとライフサイクル管理などのタスクを実行します。

このドキュメントでは、インフラストラクチャの次の 3 つの主要レイヤを保護するのに役立つセキュリティ管理について説明します。

• 本番環境サービス。これには、セキュリティ上最も重要なサービス（基盤サービス）が含まれます。
• 本番環境マシン
• 本番環境ワークロード

Google では、Google の従業員がサービス、マシン、ワークロードにアクセスする機会を正当なビジネス目的（メンテナンス アクセスなど）がある場合に限定し、インサイダー リスクや個人アカウントの不正使用を防ぐため、これらの制御を適用しています。これらの制御は、アカウントの侵害を防ぐ既存のインフラストラクチャのセキュリティ管理を補完し、多層防御を強化するものです。

継続的な改善

このホワイトペーパーで説明する制御は、Google の本番環境全体で使用されています。基礎サービスを含む多くのサービスは、Google が提供する最新レベルの制御を使用しています。ただし、Google のインフラストラクチャの範囲と複雑さにより、個々の本番環境サービスに固有の要件がある場合が多く、最新の推奨事項を実装するために追加の時間が必要になることがあります。継続的な改善の文化を通じて、Google のサイト信頼性エンジニアリング（SRE）とセキュリティ チームは、変化する脅威状況に対応するためにセキュリティ管理を常に調整しています。

本番環境サービスの保護

Google は、本番環境サービスの完全性を保護し、Google の担当者がメンテナンスなどの正当なビジネス目的でのみサービスにアクセスできるようにしています。本番環境で実行されるサービスにアクセスするには主に 2 つの方法があります。管理者権限を介してアクセスする方法と、ソフトウェア サプライチェーンを介してアクセスする方法です。

次のリストは、各アクセスパスを保護する制御を示しています。

• 管理アクセス制御: 本番環境のサービスには、定期的なメンテナンス（バイナリや構成のロールアウトなど）が必要です。Google では、ゼロタッチ本番環境の哲学に沿って、このようなオペレーションを自動化し、安全なプロキシ、監査された緊急アクセスによって行うことを目標としています。本番環境アセットへの人間のアクセスを排除する一連の制御は No Persons（NoPe）と呼ばれます。NoPe により、Google は、本番環境サービスの機密性に基づくアクセス制御を柔軟にデプロイし、継続的な改善を通じて、さらに強力なポジションを実現しています。

  たとえば、Google は基盤となるサービスへの一方的なアクセスを許可していません。緊急アクセスであっても、他の Google 担当者の承認が必要です。あるユーザーが、別の承認済みユーザーの承認なしにアクセスできる場合、そのアクセスは一方的です。

• ソフトウェア サプライ チェーンの制御: 基盤となるサービスを含む Google の本番環境のワークロードの大部分は、信頼できるソースにあるピアレビュー済みのコードから検証可能な方法でビルドされたバイナリとジョブ構成を実行しています。このプロセスは、Binary Authorization for Borg（BAB）を使用して実現しています。

次の図は、本番環境サービスを保護する制御を示しています。

最高レベルの NoPe と BAB を適用することで、緊急時であっても、基礎サービスへの一方的なアクセス権を持つ人員が存在しないことを保証し、付与される特権アクセス権に明確な範囲と期間が設定されます。特権アクセスは、自動化では対処できない特殊な状況で、重要な本番環境サービスを管理するためにユーザーに付与される、昇格されたアクセス権です。Google がロックアウト状態から抜け出す方法を確保するために、このルールには例外が設けられています。

Filestore や Cloud SQL などのプロダクトや、Borg や Spanner などの内部インフラストラクチャ プロダクトなど、他の多くの本番環境サービスは、最高レベルの NoPe と BAB を使用するように構成されています。Google は、本番環境サービスのオーナーが NoPE と BAB を長期にわたって採用できるように、継続的に取り組んでいます。

管理アクセス制御

Borg では、本番環境ロールのメンバーは、本番環境ロールが所有するデータの読み取り、書き込み、削除を行うことができます。また、ロールの権限を使用してコードを実行することもできます。本番環境ロールは、Google の本番環境でワークロードを実行できる ID です。

本番環境のロールのメンバーシップが永続的であると、本番環境で意図しない結果が生じるリスクや、これらの権限が悪用されるリスクがあります。ただし、SRE の使命は、チームが担当するサービスを維持できるようにすることです。そのため、アクセス権を完全に削除することは現実的な戦略ではない可能性があります。

NoPe スイートは、チームの能力を高めながら本番環境のシステムを安全に保つという相反する要件のバランスをとりながらアクセスを構成する方法を提供します。NoPe では、Google の従業員が本番環境のサービスにアクセスしようとすると、アカウントの権限に制約が課されます。NoPe では、次の制約が適用されます。

• アクセス リクエストには承認者と正当性が必要: マルチパーティ承認（MPA）と呼ばれる制御により、ビジネス上の正当性と、アクセス リクエストを承認する別の個人からの承認がなければ、Google の担当者が本番環境のサービスにアクセスできないようにします。
• 本番環境のサービスロールに直接アクセスしない: 本番環境のサービスには、NoPe の安全なプロキシを介してのみアクセスできます。安全なプロキシは、明確に定義されたコマンドのセットのみを実行できるように設計されています。Google のセキュリティ チームと SRE チームが危険だと判断したコマンド（サービス拒否、データへのアクセスや削除など）にも MPA が必要です。
• 本番環境のロールのメンバーシップは永続的でない: アクセス オンデマンド（AoD）と呼ばれる制御では、個人アカウントが常にアクセス権を持つのではなく、一時的なメンバーシップをリクエストする必要があります。この制御により、昇格された権限は、特定の理由でのみ一時的に付与されます。
• 本番環境サービスへの担当者のアクセス リクエストのモニタリング: Google では、本番環境サービスを実行する本番環境ロールへのアクセス パターンを定期的に監査することを義務付けています。この監査の目的は、管理 API の継続的な改善を通じて、将来的にこのようなリクエストの必要性をなくすことです。本番環境サービスへのアクセスは、緊急対応の状況でのみ行う必要があります。基盤サービスの場合、アクセスが許可される状況は非常に少ないため、セキュリティ チームは許可された各アクセスの監査を実施し、有効性を確認しています。

以降のセクションでは、各制御について詳しく説明します。

NoPe のマルチパーティ承認

MPA では、別の Google の認定担当者がアクセス リクエストを承認する必要があります。

機密性の高いサービスへのアクセス リクエストについては、進行中の緊急事態を示すビジネス上の正当な理由をリクエストごとに提示する必要があります。

これらの条件はどちらも、アクセスの不正使用を防ぐためのものです。

NoPe の安全なプロキシ

安全なプロキシでは、安全なプロキシが呼び出し元に代わって実行できる一連の事前定義コマンドを公開するツールです。安全なプロキシは、本番環境サービスへのアクセスに制約を課すために、きめ細かいルールベースの認可ポリシーを実装します。たとえば、セキュリティや信頼性に悪影響を与える可能性のあるコマンド（ファイルを削除するコマンドなど）を実行するには、別の承認済みユーザーの承認が必要になる場合があります。ポリシーを使用して、特定の安全なコマンド（リソース使用率を表示するコマンドなど）を承認なしで実行することを許可することもできます。こうした柔軟性は、運用上の労力を最小限に抑えるために不可欠です。

アクセスの不正使用が発生した場合でも、アカウントは安全なプロキシで許可されているオペレーションに制限されます。アカウントは安全なコマンドを一方的に実行することしかできません。特権的なオペレーションを行う場合は、別の承認済みユーザーの承認が必要になります。すべてのオペレーションに明確な監査証跡が残ります。

安全なプロキシの詳細については、ゼロタッチ本番環境に関する SREcon のプレゼンテーションをご覧ください。ゼロタッチ本番環境とは、本番環境でのすべての変更が自動化される（人間が関与しないにする）か、ソフトウェアによって事前検証されるか、監査された緊急対応メカニズムによって行われることを強制する一連の原則とツールです。

オンデマンド アクセス

オンデマンド アクセス（AoD）では、永久メンバーシップを適格なメンバーシップに置き換えることで、Google がユーザーの権限を制限できます。

対象となるロールのメンバーは、そのロールの権限にアクセスできません。代わりに、資格のあるロールのメンバーがアクセスを必要とする場合は、一時的なメンバーシップ（AoD 付与）をリクエストできます。別の承認済みユーザーが承認した場合、AoD の付与により、リクエスト元はそのロールのメンバーになります（通常は 1 日以内）。

適格なメンバーシップ モデルでは、必要な期間に必要なアクセス権のサブセットのみをリクエストできます。概念的には、AoD は Unix の sudo -u コマンドと同様に、時間制限のある本番環境の sudo と考えることができます。これにより、特定のユーザーに関連付けられた権限を昇格させてコマンドを実行できます。ただし、Unix の sudo とは異なり、AoD の付与を受けるにはビジネス上の正当な理由と MPA が必要であり、監査証跡が残ります。AoD の付与も時間制限があります。

メンバーシップで機密権限を保護することにより、アクセスの不正使用が発生した場合でも、アカウントは有効な権限がある場合にのみ、それらの権限にアクセスできます。安全なプロキシを採用することで、そのような権限付与の必要性は大幅に減少します。

アクセス リクエストのモニタリング

Google の本番環境の多くの領域では、アクセスの削減方法として NoPe が使用されていますが、AoD の付与は、最も機密性の高い本番環境のロールでは非常にまれであり、緊急対応用にのみ予約されています。さらに、各イベントは事後的な手動監査をトリガーします。この監査の目的は、将来的に AoD の付与頻度を減らすことです（たとえば、これらのイベントを使用して、Administrative API の改善を促進します）。

Google は、AoD の付与と、それらの付与を保持している間に行われたアクションを、会社全体で継続的にモニタリングしています。Google は、リアルタイムのモニタリング データを使用して、潜在的な侵害を検出し、アクセスをさらに削減する領域を特定しています。インシデントが発生した場合、監査証跡により迅速な対応が可能になります。

Binary Authorization for Borg

NoPe が特権アクセスパスを保護するのと同様に、Binary Authorization for Borg（BAB）は Google ソフトウェア サプライ チェーンを保護します。BAB は、本番環境のソフトウェアとジョブ構成がデプロイ前に審査、承認されていることを確認します。これは特に、機密データにアクセスできる場合に役立ちます。当初の Google の本番環境インフラストラクチャ用に設計された BAB の主なコンセプトは、現在、ソフトウェア アーティファクトのサプライ チェーン レベル（SLSA）というオープン仕様に含まれています。

BAB を使用すると、ピアレビューなしにソースコードを変更したり、バイナリを実行したり、ジョブを構成したりできないようになります。また、バイナリ アーティファクトやソフトウェア構成は、チェックインされたピアレビュー済みのソースコードから検証可能な形でビルドされます。

詳細については、Binary Authorization for Borg をご覧ください。

本番環境のマシンの保護

Google は、特権アクセスパスの強化とソフトウェア サプライ チェーンの完全性の維持に加えて、本番環境サービスが稼働するマシンを保護します。具体的には、以下を実装します。

• シェルアクセスの制御: ほとんどの Google 社員は、本番環境のマシンや、Google のクラスタ管理システムである Borg で実行されているワークロードにシェルアクセス（SSH など）ができません。代わりに、安全なプロキシを使用する必要があります。このプロキシでは、コマンドを実行する前に、別の承認済みユーザーが各コマンドを審査し、承認する必要があります。

  下位レベルのインフラストラクチャに取り組むチームは、安全なプロキシを使用できない複雑な問題をデバッグできるよう、一方的でないシェルアクセス権を保持しています。1 人以上の追加の認可を受けた担当者の承認を必要とするアクセスは、一方的でないアクセスです。Google は、一方的なシェルアクセスが許可される 1 つの例外を設定しています。これは、Google がロックアウト状態から抜け出す方法を確保するためです。

• 物理アクセスの制御: マシンを正常に動作させるには、物理的なメンテナンスを定期的に行う必要があります。データセンターの技術者が正当なビジネス上の理由で物理マシンにアクセスできるように、Google は物理から論理への制御を使用しています。

• ファームウェアとシステム ソフトウェアの制御: Google は、ハードウェアのルート オブ トラストに基づく、測定されたブート セキュリティ フローを導入しています。ハードウェア ルート オブ トラストは、各マシンのブート ファームウェアとシステム ソフトウェアの完全性を保証するのに役立ちます。

次の図は、データセンター内のマシンを保護する制御を示しています。

シェルアクセス制御

SSH は、Linux ベースのサーバーへの広範なアクセスを許可するためによく使用されるオープンソースの管理ツールです。SSH アクセスを制御しないと、適切な認証情報を持つアカウントが、監査が難しい方法で任意のコードを実行できるシェルを取得する可能性があります。

本番環境のサービスにシェルアクセス権を持つアカウントは、実行中のタスクの動作を変更したり、認証情報を取得したり、認証情報を使用して環境に永続的な足場を築くことができます。

このリスクを軽減するため、Google では、本番環境マシンへの SSH アクセスを安全な代替方法に置き換える一連の制御を使用しています。

• API の範囲を限定する: SSH が必要な明確に定義されたワークフローを実行しているチームに対しては、SSH の範囲を制限した監査可能な API に置き換えます。
• SSH 用の安全なプロキシ: アクセスの柔軟性がより必要なチームでは、安全なプロキシを使用して、コマンドの個別承認と監査を行うことができます。
• MPA: SRE がマシンへの緊急 SSH アクセスを必要とする場合は、ビジネス上の正当な理由と、アクセスを承認する権限を持つ個人が必要です。完全なシェル セッションの記録がログに記録されます。
• ロックアウト シナリオ: 一方的な SSH アクセスが許可される唯一の例外です。完全なシェル セッションの記録がログに記録されます。

これらの制御により、正当なシェルアクセスの必要性と、過度に広範なシェルアクセスに伴うリスクのバランスを取ることができます。

背景: Google での SSH

以前は、Google は SSH を使用してマシンを管理していました。Borg の開発により、ほとんどの Google 社員はバイナリを実行する Linux マシンへの直接アクセスを必要としなくなりましたが、シェルアクセスは次の理由で残っています。

• デバッグのために、マシンに直接アクセスする必要がある場合。
• SSH アクセスは、さまざまな抽象化レイヤを理解するための有用な教育ツールである。
• 予期しない障害復旧シナリオで、上位レベルのツールが使用できない場合がある。

こうした理由と、それによって発生するセキュリティ リスクのバランスをとるため、Google では SSH のリスクと使用を段階的に排除する一連のマイルストーンを検討しました。

一元化されたモニタリングとアクセス制御のマイルストーン

Google は、ホスト ID ベースのモニタリング認可（HIBA）と呼ばれる一元的な SSH モニタリングと認可システムに投資しました。HIBA は SSH の使用状況を可視化し、厳密な認証ポリシーの適用を可能にします。SSH の試行は、ターゲット マシンだけでなく、一元化された BeyondCorp プロキシでも記録されます。シェルによって実行されたコマンドはログに記録され、悪意のある動作を検出するパイプラインに送られます。ただし、検出は基本的には受動的であり、回避や難読化に対しては脆弱です。

一方的なアクセスを排除するためのマイルストーン

ほとんどのユーザーの場合、本番環境のマシンや Borg で実行されているワークロードへのシェルアクセス（SSH など）は削除されています。ただし、開発チームのテストマシン（新しいハードウェアや新しい低レベル ソフトウェアの認定に使用されるが、本番環境サービスを実行しないマシンなど）では引き続きアクセスできます。

API の範囲の限定

これまで、Google の一部チームは、SSH を使用して、限られた数の正確に定義されたコマンドの実行（ハンドブックなど）や、構造が予測可能なデータの取得を行っていましたが、現在は、特定のユースケースに対応し、構造化されたデータを提供する、狭義に定義された API を使用しています。

範囲が限定された API は、一般的なユーザー ジャーニーに合わせてメソッドの数を少なくし、低レベルのアクセスの詳細を抽象化します。安全性と監査可能性の点で優れているため、Google では、この方法を推奨しています。Google のリモート プロシージャ コール（RPC）インフラストラクチャ上に構築することで、セキュリティと監査に数十年にわたって投資してきた成果を活用できます。

SSH 用の安全なプロキシ

一部の Google チームでは、事前に必要なコマンドを特定できない場合があります。この場合、Google では、セキュリティ チームが実行する信頼できるプロキシからの任意のコマンドの実行リクエストのみを受け入れるコマンド実行デーモンを使用しています。この技術は、NoPe の安全なプロキシで使用される技術に似ています。

SSH の安全なプロキシは、コマンド実行のきめ細かい認可と監査を担当します。認証は、コマンドの引数と環境、レート制限パラメータ、ビジネス上の正当性、MPA に基づいて行われます。この認可プロセスにより、チームのハンドブックとベスト プラクティスに従って、実行できるコマンドを正確に制限できます。既存のハンドブックでキャプチャされていない予期しない障害が発生した場合でも、別の承認済みの担当者が承認した後で、必要なデバッグ コマンドを実行できます。

SSH の MPA

下位レベルのインフラストラクチャを扱う少数のチームは、最も複雑な問題をデバッグするために、一方的でない形式のシェルアクセスを保持しています。

ロックアウト シナリオでの SSH

Google では、一方的なシェルアクセスが許可される例外を設定しています。これにより、Google はロックアウトの状況を解決できます。この目的で使用される SSH 鍵は、監査可能な個別のプロセスで生成され、改ざん防止ハードウェアにオフラインで保存されます。これらの鍵を使用すると、完全なシェル セッションのトランスクリプトがログに記録されます。

物理アクセスの制御

Google のデータセンターは、サーバー、ネットワーク デバイス、制御システムからなる複雑な環境です。管理、メンテナンス、運用に幅広い役割とスキルが必要になります。

Google では、データセンター内のワークロードを保護するため、マシン自体に 6 層の物理コントロールと多くの論理コントロールを実装しています。また、マシン間のスペース（物理から論理へのスペース）も保護しています。

物理から論理への制御は、マシンの強化、タスクベースのアクセス制御、システムの自己防衛と呼ばれる制御を通じて、防御レイヤを追加します。物理論理空間の制御は、マシンへの物理的なアクセスを悪用してマシンのワークロードに対する論理攻撃にエスカレーションしようとする攻撃者から環境を防御します。

詳細については、Google がデータセンターの物理論理空間を保護する仕組みをご覧ください。

ファームウェアとシステム ソフトウェアの制御

データセンター マシンのセキュリティ ポスチャーは、起動時に確立されます。マシンの起動プロセスでは、Google の本番環境でマシンを安全に実行しながら、マシンのハードウェアを構成し、オペレーティング システムを初期化します。

Google では、起動プロセスの各ステップで期待される起動状態を適用し、顧客データを安全に保つために、業界トップクラスの制御機構を実装しています。これにより、マシンで目的のソフトウェアが起動され、マシンの初期のセキュリティ ポスチャーを損なうおそれのある脆弱性を排除しています。

詳細については、Google が本番環境マシンに起動時整合性を適用する方法をご覧ください。

ワークロードの保護

Google では、ゼロトラストの哲学に従って、セキュリティ要件の異なるワークロード間の横方向の移動の脅威から保護するための制御も導入しています。Google のインフラストラクチャは、ワークロード セキュリティ リング（WSR）と呼ばれるワークロード階層を使用しています。WSR を使用すると、リソース使用率への悪影響を回避しながら、重要なワークロードが安全性の低いワークロードと同じマシンにスケジュールされないようにできます。WSR は、ワークロードを 4 つの機密性クラス（基盤、機密、強化、非強化）に分類し、異なるマシンプールでスケジュールを設定しようとします。

次の図は、WSR が基盤マシン、本番環境マシン、開発マシン全体でワークロードをグループ化してスケジュールする方法を示しています。

WSR は、カーネルの脆弱性に対する攻撃や CPU サイドチャネル攻撃を使用したローカル特権昇格に対する防御レイヤを追加します。WSR を使用すると、セキュリティ要件が類似しているワークロードのみが同じマシンで一緒にスケジュールされます。WSR を実装するために、次の作業を行います。

• セキュリティ要件に応じてワークロードを分類します。各クラスはワークロード リングと呼ばれます。
• 物理マシンを、互いに分離された複数のマシンプールに分散します。これにより、プール間の横方向の移動パスを排除します。
• スケジューリングの制約を適用して、セキュリティ要件が異なるワークロードが同じマシンで実行されないようにします。これらのスケジューリングの制約により、ローカル権限昇格による侵害のリスクが軽減されます。

たとえば、WSR では、基盤となるワークロードを専用マシンで実行し、基盤以外のワークロードとともにスケジュールしないようにする必要があります。この制約により、セキュリティが低いワークロードから確実に分離されます。

ワークロードを分離する方法

最新のシステム ソフトウェアは複雑です。セキュリティ研究者は、カーネルのゼロデイ攻撃や新しい CPU サイドチャネル攻撃など、ローカル権限昇格の脆弱性を定期的に発見しています。WSR は、USENIX ;login: で初めて紹介されました。Google では、これによりリソース使用率を高く維持しながら、ワークロードのコロケーションに関連するリスクを軽減しています。

デフォルトでは、Borg は OS レベルのプロセス境界を使用してコンテナを分離します。これらのプロセスは、ハードウェア ベースの仮想化を使用する仮想マシンよりも分離境界が弱くなります。このような弱い分離は通常、信頼できるワークロードを実行するマルチテナント環境で効率性とセキュリティのトレードオフとなります。信頼できるワークロードとは、バイナリと構成が、証明された来歴を備えたピアレビュー済みのコードから検証可能にビルドされたワークロードです。信頼できるワークロードは、信頼できないデータを処理しません。信頼できないデータを処理する例としては、サードパーティ コードのホスティングや動画のエンコードなどがあります。

Google では、BAB を使用してバイナリの信頼を実現しています。ただし、信頼できないデータを処理するワークロードの完全性を確保するには、BAB だけでは不十分です。このようなワークロードは、BAB に加えてサンドボックス内で実行する必要があります。サンドボックスは、gVisor のような制約のある環境であり、バイナリを安全に実行できます。BAB とサンドボックスにはそれぞれ制限があります。

BAB は成熟したプロダクトに対する強力な制御ですが、新しいシステム開発の初期段階や、機密データのないテストを実行する際には、速度が低下する可能性があります（すでに公開されているデータのエンコードの最適化など）。この制限により、一部のワークロードは常に BAB なしで実行する必要があります。このようなワークロードでは、ローカル権限昇格のリスクが本質的に高くなります（たとえば、カーネルの脆弱性が悪用され、マシンのローカル root 権限が盗まれる可能性が高くなります）。

信頼できないワークロードをサンドボックス化することでもセキュリティ リスクを軽減できますが、コンピューティングとメモリの使用量が増加します。ワークロードとサンドボックスの種類によっては、効率が 2 桁の割合で低下する可能性があります。サンドボックス化されたワークロードに対するパフォーマンスの影響の例については、gVisor パフォーマンス ガイドの詳細なベンチマークをご覧ください。WSR を使用すると、ワークロードの分離に伴う効率性の制限に対処できます。

ワークロード リング

Google では、セキュリティ要件に応じて、ワークロードを基盤、機密、強化、非強化の 4 つのクラスに定義しています。次の表に、これらの定義について詳しく説明します。

ワークロード リング	説明
基盤	Google のセキュリティにとって重要なワークロード（ID 管理サービスやアクセス管理サービスなど）。基盤となるワークロードには最高レベルのセキュリティ要件があり、効率性と引き換えに、セキュリティと信頼性を高めています。
機密	広範囲にわたるサービス停止の原因となる可能性のあるワークロード。または、ユーザーデータや顧客データなどの機密性の高いサービス固有のデータにアクセスするワークロード。
強化	セキュリティ上重要ではないが、BAB を採用しているかサンドボックス化されているワークロードをサポートし、隣接するワークロードにリスクがほとんどないようにします。
非強化	信頼できないコードを実行するワークロードを含む、他のすべてのワークロード。

Google では、特定のプロダクトをサポートする重要なワークロードを機密ワークロードとして分類しています。基盤となるワークロードは、すべてのプロダクトに影響を与える可能性のあるワークロードです。

基盤ワークロードや機密ワークロードとは異なり、ワークロードは、採用されている制御と処理する入力の種類のみに基づいて強化ワークロードとして分類できます。強化ワークロードでは、他のワークロードへの影響を主に懸念しているため、強化ソリューションにはサンドボックス化が含まれる場合があります。

マシンプール

機密性の高いサービスと信頼性が低いワークロード（サンドボックスなしで信頼できないデータを処理するワークロードなど）を同時にスケジュールしないようにするため、マシンが分離されたプールでワークロードを実行する必要があります。マシンの分離により、セキュリティの不変性を理解しやすくなりますが、マシンプールを追加するたびに、リソース使用率と保守性のトレードオフが発生します。

マシンの分離を行うと、物理リソースの使用率が低下します。これは、プールを追加するほど、マシンプールを完全に使用することが難しくなるためです。効率性のコストは、分離された大きなマシンプールが複数存在すると大きくなる可能性があります。

ワークロードのリソース フットプリントは各プールで変動するため、厳密な分離では、プール間でマシンを定期的に再調整し、再利用するための管理オーバーヘッドが発生します。このような再調整を行うには、マシンからすべてのワークロードをドレインしてマシンを再起動し、ファームウェアの信頼性と整合性を確保する最も重いマシン サニテーション プロセスを実行する必要があります。

これらの考慮事項を踏まえて、Google によるマシン分離の実装では、物理リソースの使用率を最適化する方法を提供するとともに、基盤となるワークロードと機密性の高いワークロードを攻撃者から保護しなければなりません。

Kubernetes では、このアプローチをノード分離と呼んでいます。Kubernetes ノードは物理マシンまたは仮想マシンにマッピングできます。このホワイトペーパーでは、物理マシンに焦点を当てて説明します。また、Compute Engine などの Google Cloud プロダクトは、物理マシンの分離を実現する単一テナンシーを提供しています。

ワークロードのスケジューリングの制約

Google では、マシンを 3 種類の分離されたプール（基盤マシン、本番環境マシン、開発マシン）にプロビジョニングします。Google では、基盤となるワークロードと機密性の高いワークロードをホストする複数の分離プールを運用していますが、このドキュメントではわかりやすくするため、それぞれを 1 つのプールとして説明します。

最も効果的な保護を提供するために、WSR には次のスケジューリング制約が適用されます。

• 基盤となるワークロードは、基盤となるマシンでのみ実行できます。
• 機密性の高いワークロードは、本番環境のマシンでのみ実行できます。
• 強化されていないワークロードは、開発マシンでのみ実行できます。
• 強化されたワークロードは、本番環境マシンまたは開発マシンで実行できますが、本番環境マシンを優先します。

次の図は、スケジューリングの制約を示しています。

この図では、分離境界によって、マシンプール内とマシンプール間で異なるクラスのワークロードが分離されています。基盤となるワークロードは、専用の基盤マシンの唯一のテナントです。本番環境のマシンで実行されるワークロードの Binary Authorization またはサンドボックス化は、ローカル権限昇格攻撃を防ぐのに役立ちます。開発マシンでは、強化されていないワークロードが別のワークロードを危険にさらすリスクが残りますが、強化されたワークロードは新しいジョブを作成できないため、危険にさらされるのは開発マシンに限定されます。

強化されたワークロードは、可用性に基づいて本番環境マシンまたは開発マシンでスケジュールされます。複数のプールでのスケジューリングを許可することはわかりづらいかもしれませんが、スケジューリングの制約によって生じる使用率の低下を軽減するためには不可欠です。強化されたワークロードは、機密性の高いジョブと強化されていないジョブを分離することで生じるギャップを埋めます。また、強化されたリソースのフットプリントが大きいほど、リング間で高コストなマシン移動を行うことなく、他の 2 つのクラスのリソース使用量の変化に対応できます。

次の図は、さまざまなクラスのワークロードに課されるスケジューリングの制約を示しています。強化されたワークロードは、本番環境マシンまたは開発マシンのいずれかに配置できます。

複数の基盤プールで基盤となるワークロードを分離することで、リソース効率を犠牲にしてセキュリティを強化しています。幸い、基盤となるワークロードは比較的リソース フットプリントが小さく、専用マシンの小規模な分離プールは全体的な使用率にほとんど影響しません。ただし、広範な自動化が導入されていても、複数のマシンプールを維持するにはコストがかかります。そのため、Google は絶えずマシン設計を進化させ、分離を改善しています。

WSR は、基盤となるマシンで基盤以外のワークロードを実行できないという強力な保証を提供しています。基盤となるマシンは、基盤となるワークロードのみが実行されるため、横方向の移動から保護されます。

制御のまとめ

Google では、本番環境のサービス、本番環境のマシン、ワークロードを保護するために、インフラストラクチャ全体でさまざまな制御を使用しています。制御には、次のものが含まれます。

• 本番環境サービスに対する管理者アクセス制御と BAB
• 本番環境マシンのシェルアクセス制御、物理アクセス制御、ファームウェアとシステム ソフトウェアの制御
• さまざまなクラスのワークロードに対する WSR

これらの制御を組み合わせることで、Google のユーザーと顧客、およびそのデータを保護するための制約を適用します。次の図は、Google のセキュリティ ポスチャーをサポートするために制御が連携する仕組みを示しています。

次のステップ

• Google のインフラストラクチャのセキュリティ制御の詳細については、Google インフラストラクチャのセキュリティ設計の概要をご覧ください。
• Google のセキュリティ文化については、『安全で信頼できるシステムの構築』（O'Reilly 書籍）をご覧ください。
• ゼロタッチ プロダクトの詳細については、SREcon のプレゼンテーションをご覧ください。

作成者: Michael Czapiński、Kevin Plybon