このホワイトペーパーでは、「クラウドネイティブ」と呼ばれるアーキテクチャで複数の Google インフラストラクチャを連携してワークロードを保護する方法を説明しています。Google のセキュリティの概要については、インフラストラクチャのセキュリティ設計についてのホワイトペーパーをご覧ください。
このドキュメントの内容は 2019 年 12 月時点のものです。このホワイトペーパーは作成日現在の状況を表しています。Google Cloud のセキュリティ ポリシーやシステムは、今後変更される可能性があります。
用語集
このドキュメントで使用する用語は、次のように定義されます。
マイクロサービスは、アプリケーションで実行される個々のタスクを、独自の API、ロールアウト、スケーリング、割り当て管理を使用して、個別に開発、管理できるサービスに分割します。最近のアーキテクチャでは、ウェブサイトなどのアプリケーションを単一のモノリシック サービスではなく、マイクロサービスの集合体として実行できます。マイクロサービスは、独立し、モジュール化された、動的でエフェメラルなサービスです。また、多くのホスト、クラスタ、クラウドに分散させることができます。
ワークロードは、アプリケーションによって完了される固有のタスクです。マイクロサービス アーキテクチャでは、ワークロードは 1 つまたは複数のマイクロサービスである場合があります。
ジョブは、アプリケーションの一部を実行するマイクロサービスの単一のインスタンスです。
マイクロサービスは、サービス ID を使用して、インフラストラクチャ内で実行されているその他のサービスに対して自身を認証します。
サービス メッシュは、トラフィックの制御、ポリシーの適用、サービスコールの集中監視を行う、サービス間通信のインフラストラクチャ レイヤです。マイクロサービス アーキテクチャを使用すると、個々のサービスでこれらの制御を行う負荷が軽減され、複数のマイクロサービスをシンプルに一元管理できます。
CIO レベルの概要
Google のインフラストラクチャでは、ワークロードをコンテナ内の個々のマイクロサービスとしてデプロイし、Borg というコンテナ オーケストレーション システムを使用してワークロードを管理します。これは、近年広く知られる「クラウド ネイティブ」アーキテクチャの着想の源であり、テンプレートとなります。
Google のインフラストラクチャは当初からセキュリティを念頭に設計され、後からセキュリティを付け足したものではありません。Google Cloud のインフラストラクチャは、サービス間の信頼がない（ゼロトラスト）ことを前提としています。
Google は BeyondProd という指針のもと、マイクロサービスを保護しています。この保護の対象には、コードの変更方法やマイクロサービスのユーザーデータへのアクセス方法も含まれます。BeyondProd は、相互認証されたサービスエンドポイント、伝送セキュリティ、エッジ終端によるグローバル負荷分散と DoS 攻撃防御、エンドツーエンドにわたるコードの出所の把握、ランタイム サンドボックスなどのコンセプトを適用しています。
従来のセキュリティ モデルからクラウドネイティブ セキュリティ モデルへ移行するには、インフラストラクチャと開発プロセスという 2 つの主な領域を変更する必要がありました。すべてのマイクロサービスを包括的に統合し、共有コンポーネントを共有ファブリックに組み込むことで（サービス メッシュ）、変更のロールアウトの簡易化や、サービス間での一貫したセキュリティを実現しました。
目的
コンテナとコンテナ オーケストレーションに移行し、リソースの使用効率を高め、可用性の高いアプリケーションを構築することで、Google デベロッパーの作業を簡素化しました。コンテナ化されたインフラストラクチャに移行し、セキュリティ管理をアーキテクチャに合わせることも目的としました。境界ベースのセキュリティ モデルではセキュリティが十分ではなかったことがわかり、攻撃者はいったん境界内部に侵入すると、ネットワーク内で自由に動くことができました。Google では、インフラストラクチャ全体でセキュリティ管理を強化する必要性を認識する一方、Google のデベロッパーが自身でセキュリティ機能を実装しなくても安全なアプリケーションを簡単に構築、デプロイできるようにすることが目標となりました。
モノリシック アプリケーションから、オーケストレーション システムを使用してコンテナからデプロイされる分散マイクロサービスに移行することにより、管理の簡素化、スケーラビリティの向上といった運用上のメリットが得られました。このクラウド ネイティブ アーキテクチャでは、デプロイメントを保護するために、マイクロサービスの管理面やスケーラビリティのメリットに合わせて、異なるセキュリティ モデルとさまざまなツールが必要となります
このドキュメントでは、BeyondProd という、Google でのクラウド ネイティブ セキュリティの実装に関連する、クラウド ネイティブ セキュリティへの移行がセキュリティに及ぼす影響、クラウド ネイティブ セキュリティに関するセキュリティ原則、これらの要件に対応するために構築されたシステム、および同様の変更に対処するためのガイダンスについて説明します。
Google のクラウド ネイティブ セキュリティ
コンテナ化されたマイクロサービス
Google は当初から、高価な高可用性ハードウェアに投資するのではなく、低コストの汎用サーバーによるデータセンター能力の構築を意図していました。信頼性については、システムのどの個別の部分が故障しても、ユーザーに表示されるサービスの可用性に影響を与えずに機能させる、という指針に従いました。この指針は今後も変わりません。この可用性を実現するには、サービスの冗長インスタンスを実行して、単一の障害が機能停止を引き起こさないようにする必要がありました。こうした哲学に基づき、コンテナ、マイクロサービス、コンテナ オーケストレーションが開発され、高度な冗長性を備えた分散システムのスケーラブルなデプロイが可能になりました。
コンテナ化されたインフラストラクチャとは、各ワークロードが独自の変更不可能、移動可能、かつスケジュール可能なコンテナとしてデプロイされることを意味します。これらのコンテナを内部で管理するために、Borg1 と呼ばれる、コンテナ オーケストレーション システムが開発されました。現在も使用され 1 週間に数十億個ものコンテナがデプロイされています。
コンテナを使用することで、ワークロードでの複数のマシンのバイナリパックやリスケジュールが容易になりました。マイクロサービスにより、アプリケーションのさまざまな部分の開発とデバッグが容易になりました。マイクロサービスとコンテナを組み合わせて使用すると、メンテナンスや検索のために、ワークロードを管理しやすい小さなユニットに分割できます。マイクロサービス アーキテクチャに基づくコンテナ化されたインフラストラクチャに移行することは、「クラウド ネイティブ」と呼ばれています。サービスは、Borg によってデプロイされたコンテナ内で実行されます。このアーキテクチャは、ワークロードを必要に応じてスケーリングします。特定のワークロードの需要が高い場合は、同じサービスのコピーを複数のマシンで実行し、要求された規模のワークロードに対応します。
Google が他社と一線を画すところは、アーキテクチャの進化の一環にセキュリティを位置づけていることです。最近のクラウド ネイティブ セキュリティのコンセプトは、Google がインフラを保護するために何年も使用してきたコンセプトと同様です。このマイクロサービスのアーキテクチャと開発プロセスについては、開発と導入のライフサイクルのできる限り早い段階でコストをかけずにセキュリティ問題に対処し、標準化された一貫性のある方法で問題を解決することを目標としています。その結果、デベロッパーは最終的に安全性の向上に時間をかけずに安全性を確保できるようになります。
クラウド ネイティブ アーキテクチャへの移行
最近のセキュリティ アーキテクチャは、ウォールで境界を保護し、その内部のユーザーやサービスは完全に信頼できるという従来の境界ベースのセキュリティ モデルを超えて進化しています。BeyondCorp は、現代の企業ユーザーの働き方の変化に対応して生まれました。今日のユーザーは、モバイルを使用し、コーヒーショップ、飛行機内など、組織の通常のセキュリティ境界の外で仕事をすることがよくあります。BeyondCorp では、特権のある企業ネットワークという概念や、ユーザーがネットワーク上のどこにいようがデバイスとユーザーの認証情報と属性だけを頼りにアクセスを許可するという発想を完全に捨てました。
クラウド ネイティブ セキュリティでは、ユーザーに対するのと同じようにサービスが扱われます。クラウド ネイティブ環境において、ファイアウォールだけでは、企業ネットワークを保護できないのと同様、本番環境ネットワークも保護できません。ユーザーがみな物理的に同じ場所やデバイスを使用しないのと同様、すべてのデベロッパーがコードを同じ環境にデプロイしているわけではありません。BeyondProd では、マイクロサービスはファイアウォールのあるデータセンターだけでなく、パブリック クラウド、プライベート クラウド、サードパーティのホストサービスでも動作し、どこからでも安全に動作する必要があります。
ユーザーが移動して、別のデバイスでさまざまな場所から接続するように、マイクロサービスも異機種のホスト間を移動することで、さまざまな環境にデプロイされます。BeyondCorp には「ユーザーの信頼は、社内ネットワークへの接続機能ではなく、デバイスのコンテキスト認識といった特性に依存する必要がある」と書かれています。一方、BeyondProd には「サービスの信頼は、IP やホスト名などの本番環境ネットワーク内の場所ではなく、コードの起点やサービス ID といった特性に依存する必要がある」と書かれています。
クラウド ネイティブとアプリケーション開発
従来のセキュリティ モデルでは、境界ベースのセキュリティを重視していたため、クラウド ネイティブ アーキテクチャを単独で保護することはできません。この例では、3 層アーキテクチャを使用するモノリシック アプリケーションを、クリティカル イベントのピーク負荷に対応するのに十分な処理能力を持つ企業のデータセンターにデプロイします。特定のハードウェアやネットワークの要件を持つアプリケーションは、固定 IP アドレスを保持する特定のマシンに意図的にデプロイされます。ロールアウトは頻繁に行われず、大型で、調整が困難です。これは、ロールアウトをすると、アプリケーションの多くの部分に同時に影響が及ぶからです。そのためアプリケーションの存続期間は非常に長く、更新はあまり行われず、セキュリティ パッチの適用頻度も低くなります。
一方、クラウド ネイティブ モデルでは、アプリケーションに必要なバイナリが、コンテナによって基盤となるホスト オペレーティング システムから切り離されるため、アプリケーションの移植性を高めます。コンテナは不変に使用される、つまりデプロイ後には変更されないことを意図したものであるため、コンテナ イメージがビルドし直されるとデプロイされ、デプロイ頻度が高くなります。ジョブは、処理する負荷に合わせてスケーリングされ、負荷が増えると新しいジョブがデプロイされ、負荷が減少すると既存のジョブは終了されます。コンテナが頻繁に再起動、削除、再スケジュールされるため、ハードウェアやネットワークの再利用や共有が頻繁に行われます。ビルドとディストリビューションのプロセスは共通化されているため、各開発チームが個別にマイクロサービス開発を管理していても、開発プロセスはチーム間で一貫して均一化されています。その結果、開発サイクルの早い段階でセキュリティ上の考慮事項（セキュリティ レビュー、コードスキャン、脆弱性管理など）に取り組むことができます。
セキュリティへの影響
BeyondCorp の「内部を（ユーザーも含めて）信頼しない」モデルが、BeyondProd のマイクロサービスにも当てはまることについて説明してきましたが、ではその変化とはどのようなものでしょうか。表 1 に、従来のインフラストラクチャ セキュリティの側面と、クラウド ネイティブ アーキテクチャの対応する側面の比較を示します。この表には、一方から他方への移行に必要な要件も示されています。このセクションの後半では、表の各行について詳しく説明します。
| 従来のインフラストラクチャ セキュリティ | クラウド ネイティブ セキュリティ | クラウド ネイティブ セキュリティの暗黙の要件 |
|---|---|---|
| 内部の通信が信頼できるとみなされている境界ベースのセキュリティ（ファイアウォールなど）。 | サービス間通信を検証するゼロトラスト セキュリティ、環境内ではサービスに対する暗黙の信頼がない。 | エッジでネットワークを保護し、サービス間の固有の相互信頼関係を排除。 |
| 特定のアプリケーション用の固定 IP とハードウェア。 | IP やハードウェアなどのリソースの利用、再利用、共有の促進。 | 出所の確かなコードを信頼できるマシンで実行。 |
| IP アドレスベースの識別。 | サービスベースの識別。 | |
| 予定された既知の場所でサービスを実行。 | パブリック クラウドとプライベート データセンターが混在する環境など、環境内のあらゆる場所でサービスを実行できる。 | |
| セキュリティ固有の要件が各アプリケーションに組み込まれ、個別に適用される。 | 一元化された適用ポリシーに従って、サービス スタックに統合されたセキュリティ要件。 | サービス全体で一貫したポリシーを適用するチョーク ポイント。 |
| サービスの構築と審査に関する限定的な制限。 | すべてのサービスに一貫して適用されるセキュリティ要件。 | |
| セキュリティ コンポーネントの制限付きの監視。 | セキュリティ ポリシーとポリシーへの準拠に関する一元表示。 | |
| 特化された低頻度のロールアウト。 | ビルドとロールアウトのプロセスを標準化し、個々のマイクロサービスを頻繁に変更。 | シンプルで標準化された変更の自動適用。 |
| ワークロードは、VM または物理ホストにデプロイされ、物理マシンやハイパーバイザを使用して分離されることが多い。 | バイナリパックされたワークロードとそのプロセスが、共有オペレーティング システムで実行されるため、ワークロードを分離するメカニズムが必要。 | オペレーティング システムを共有する個々のワークロードの隔離。 |
表 1: クラウド ネイティブ アーキテクチャへの移行におけるセキュリティの暗黙の要件
境界ベースのセキュリティからゼロトラスト セキュリティへの移行
従来のセキュリティ モデルでは、組織のアプリケーションはプライベート データセンターの外部ファイアウォールに依存して、受信トラフィックを保護できません。クラウド ネイティブ環境でも、BeyondCorp モデルと同様にネットワーク境界を引き続き保護する必要がありますが、境界ベースのセキュリティ モデルでは十分に保護できません。新しいセキュリティ上の問題が発生するわけではありませんが、ファイアウォールで企業ネットワークを完全に保護できなければ、本番環境ネットワークも完全に保護できません。ゼロトラスト セキュリティ モデルでは、内部トラフィックが暗黙に信頼されず、認証や暗号化などのセキュリティ制御が必要になります。同時に、マイクロサービスへの移行は、従来のセキュリティ モデルを再検討する機会となります。単一のネットワーク境界（1 つのファイアウォールなど）への依存を排除すると、ネットワークをサービスごとに分割できるようになります。このアイデアをさらに進めて、サービス間に固有の相互信頼関係をなくして、マイクロサービス レベルのセグメンテーションを実装することもできます。マイクロサービスでは、トラフィックの信頼度がさまざまであるため、内部トラフィックと外部トラフィックを比較するだけでは済みません。
固定 IP とハードウェアから共有リソースへの移行
従来のセキュリティ モデルでは、組織のアプリケーションが特定のマシンにデプロイされ、そのマシンの IP アドレスは頻繁には変更されませんでした。このためセキュリティ ツールは、予測可能な方法でアプリケーションにリンクされた、比較的静的なアーキテクチャ マップに依存できました。そのため、ファイアウォールなどのツールのセキュリティ ポリシーでは、IP アドレスを識別子として使用できました。
一方、クラウド ネイティブ環境では、ホストが共有され、ジョブが頻繁に変わるため、ファイアウォールではマイクロサービス間のアクセスを制御できません。特定の IP アドレスが特定のサービスに関連付けられていても役に立ちません。そのため、IP アドレスやホスト名をベースに識別するのではなく、サービスをベースに識別します。
アプリケーション固有のセキュリティ実装から、サービス スタックに統合される共通セキュリティ要件への移行
従来のセキュリティ モデルでは、個々のアプリケーションがそれぞれ独自のセキュリティ要件を満たす必要がありました。このような要件には、ID 管理、SSL / TLS の終端、データアクセス管理などが含まれます。このため、実装の不一致や、未対応のセキュリティ問題がしばしば生じ、あちこちで対応を要する問題が発生したため、対応がより難しくなりました。
クラウド ネイティブ環境では、サービス間でコンポーネントが頻繁に再利用され、サービス間で一貫したポリシーが適用されます。異なるセキュリティ サービスを使用して異なるポリシーを適用できます。アプリケーションごとに重要なセキュリティ サービスを個別に実装する必要はなく、複数のポリシーを個別のマイクロサービスに分割することもできます（たとえば、あるポリシーでは認可された者がユーザーデータにアクセスできることを保証し、別のポリシーでは最新の TLS 暗号スイートを使用できるようにする、など）。
特化された低頻度のロールアウト プロセスから、より頻繁なロールアウトを伴う標準化プロセスまで
従来のセキュリティ モデルでは、共有サービスの数は限られていました。コードが分散され、ローカルで開発されていたこともあり、アプリケーションの多くの部分にかかわる変更の影響を確認することは困難でした。そのため、ロールアウトはあまり頻繁に行われず、調整はしづらいものでした。変更を加えるには、各コンポーネントを直接更新する必要があります。たとえば、SSH で仮想マシンに接続し、設定を更新するなど）。全体的に見ると、これによりアプリケーションの寿命は大幅に伸びます。セキュリティの観点からは、コードが分散されると、脆弱性が修正されたときに修正箇所が多岐にわたり検証が難しくなります。ロールアウトが頻繁に行われ標準化されているクラウド ネイティブに移行すると、ソフトウェア開発ライフサイクルにおけるセキュリティのシフトレフト2 が可能になります。これにより、セキュリティ パッチの定期的な適用など、セキュリティをより簡単により一貫して適用できます。
物理マシンやハイパーバイザを使用して分離されたワークロードから、分離が強化された同じマシン上で実行されるバイナリパッキングのワークロードへの移行
従来のセキュリティ モデルでは、共有リソースのない独自のインスタンスでワークロードがスケジュール設定されていました。また、アプリケーションは事実上そのマシンとネットワーク境界により範囲が定められ、ワークロードの分離は、物理的なホスト分離、ハイパーバイザ、従来のファイアウォールだけに依存して行われていました。
クラウド ネイティブ環境では、ワークロードはコンテナ化され、共有ホストや共有リソースに格納されます。そのため、ワークロード間の分離を強化する必要があります。ワークロードは、ネットワーク制御とサンドボックス技術を使用して互いに分離されたマイクロサービスに分割できます。
セキュリティ原則
クラウド ネイティブ アーキテクチャの開発では、平行してセキュリティを強化するため、次のセキュリティ原則を策定して最適化しました。
エッジでのネットワークの保護。ネットワークからの攻撃やインターネットからの不正なトラフィックからワークロードが隔離されます。ウォールベースのアプローチはクラウド ネイティブのコンセプトではありませんが、なおもセキュリティ上のベスト プラクティスです。クラウド ネイティブ環境では、不正なトラフィックや、ボリュームベースの DoS 攻撃などのインターネット攻撃からできるだけ多くのインフラストラクチャを保護するために、境界ベースのアプローチがとられます。
サービス間の相互信頼がない。サービスを利用できるのは、既知の、信頼できる、具体的は利用を認可された呼び出し元のみです。これにより、攻撃者は信頼できないコードを使用してサービスにアクセスできなくなります。サービスが侵害された場合、攻撃者はリーチ拡大のためのアクションを実行できません。この相互の信頼確認は、侵害される範囲を制限するのに役立ちます。
出所の確かなコードを実行する信頼できるマシン。サービス ID は、許可されたコードと構成のみを使用して、認可および検証済みの環境でのみ実行するように制限されます。
サービス全体で一貫したポリシーを適用するチョーク ポイント。たとえば、ユーザーデータへのアクセス リクエストを検証するチョーク ポイントを見つけて、アクセス権限を付与されたエンドユーザーからの有効なリクエストに起因するサービス アクセスを受け入れ、管理者がアクセスする際にはビジネス上の正当な理由を求めるようにします。
自動化され、標準化されたシンプルな変更のロールアウト。インフラストラクチャの変更によるセキュリティへの影響を簡単に確認でき、セキュリティパッチは本番環境にほとんど影響せずにロールアウトできます。
オペレーティング システムを共有するワークロード間の分離。サービスが侵害されても、同じホスト上で実行されている別のワークロードのセキュリティには影響しません。これにより、潜在的な侵害の範囲が制限されます。
インフラストラクチャ全体では、個人に依存しない自動化されたセキュリティを実現することを目標としています。セキュリティは、サービスが拡張するのに合わせて拡張する必要があります。サービスのセキュリティが確保されるのがデフォルトで、確保されないのは例外的な場合であるべきです。そして人間によるアクションはルーティンではなく例外的で、それが発生するたびに監査できる必要があります。そうすれば、サービスをデプロイしたユーザーではなく、サービスにデプロイされたコードと構成に基づいてサービスを認証できます。
以上をまとめると、これらのセキュリティ原則を実施することにより、コンテナと内部で動作するマイクロサービスはデプロイされ、相互に通信でき、相互に連携して動作できます。それによりクラウド ネイティブ アーキテクチャの特性（すなわち、シンプルなワークロード管理、NoOps スケーリング、効率的なバイナリパック、など）が損なわれることはありません。これは、個々のマイクロサービス デベロッパーに、基盤となるインフラストラクチャのセキュリティと実装の詳細について負担をかけることなく実現できます。
Google の社内セキュリティ サービス
Google のクラウドネイティブ インフラストラクチャを保護するために、内部ツールとサービスをいくつか設計、開発しました。以下のセキュリティ サービスは連携して、セキュリティ原則のセクションで定義されているセキュリティ原則に対応しています。
Google Front End（GFE）: エンドユーザーからの接続を終了し、TLS のベスト プラクティスを実施するための中心的なポイントを提供します。境界ベースのセキュリティはもはや重視していませんが、GFE は引き続き、サービス拒否攻撃から内部サービスを保護する戦略の重要な部分を担っています。GFE は、Google へのユーザー接続の最初のポイントです。Google のインフラストラクチャ内では、GFE は必要に応じて負荷分散とリージョン間のトラフィックのルーティング変更も行います。GFE は、Google のインフラストラクチャにおいて、適切なマイクロサービスにトラフィックをルーティングするエッジプロキシです。
Application Layer Transport Security（ALTS）: RPC 認証、完全性、暗号化に使用されます。ALTS は、Google のインフラストラクチャ内のサービスのための相互認証およびトランスポート暗号化システムです。ID は通常、特定のサーバー名やホストではなくサービスにバインドされます。これにより、シームレスなマイクロサービスのレプリケーション、負荷分散、ホスト間のスケジューリングが容易になります。
Binary Authorization for Borg とホストの整合性。マイクロサービスとマシン整合性の検証にそれぞれ使用されます。
- Binary Authorization for Borg（BAB）: コードがデプロイ前に内部セキュリティ要件を満たしていることを確認するデプロイの際の適用チェックです。BAB チェックには、第 2 のエンジニアによるレビュー、ソースコード リポジトリへ送信されるコード、専用インフラストラクチャ上で検証可能な形でビルドされるバイナリのレビューが含まれます。Google のインフラストラクチャでは、BAB によって不正なマイクロサービスのデプロイを制限しています。
- Host Integrity（HINT）: セキュアブート プロセスを介してホストシステム ソフトウェアの整合性を検証し、セキュアなマイクロ コントローラ ハードウェア（サポートされている場合）によりバックアップされます。HINT チェックには、BIOS、BMC、ブートローダー、および OS カーネルのデジタル署名の検証が含まれます。
サービス アクセス ポリシーとエンドユーザー コンテキスト チケット。データへのアクセスを制限するために使用されます。
- サービス アクセス ポリシー: サービス間のデータアクセスを制限します。RPC が 1 つのサービスから別のサービスに送信されるとき、サービス アクセス ポリシーは、受信サービスのデータにアクセスするために必要な認証ポリシー、認可ポリシー、監査ポリシーを定義します。これにより、データのアクセス方法が制限され、最小限の必要なアクセス権が付与され、アクセスの監査方法が指定されます。Google のインフラストラクチャでは、サービス アクセス ポリシーにより、マイクロサービスから別のマイクロサービスのデータへのアクセスが制限され、アクセス制御の全般的な分析が可能になります。
- エンドユーザー コンテキスト（EUC）チケット: エンドユーザー認証サービスによってチケットが発行され、サービス ID とは別のユーザー ID でサービスが提供されます。これは、サービスの要求を行ったエンドユーザーの ID を証明する、完全に保護された、一元的に発行される、転送可能な認証情報です。これにより、サービス間の信頼の確認の必要性が低くなります。ALTS によるピア ID ではアクセス許可するには 不十分で、通常そのような認可はエンドユーザー ID に基づいているためです。
Blue / Green デプロイメント用 Borg ツール3: このツールは、メンテナンス タスクの実行時に実行中のワークロードの移行を行います。既存の Borg ジョブに加えて、新しい Borg ジョブがデプロイされます。ロードバランサによってトラフィックが徐々に移動されます。これにより、ユーザーに気付かれることなく、ダウンタイムなしでマイクロサービスを更新できます。この機能は新機能の追加のためにサービスを更新する場合や、Heartbleed や Spectre/Meltdown などの重要なセキュリティ アップデートをダウンタイムなしで適用する場合に使用されます。Google Cloud インフラストラクチャに影響する変更は、VM ワークロードに影響しないように、ライブ マイグレーションを使用して行います。
gVisor: ワークロードを分離するために使用されます。gVisor はユーザー空間カーネルを使用してシステムコールをインターセプトして処理することで、ホストとのやり取りを減らし、攻撃にさらされる可能性を低減します。ユーザー空間カーネルはアプリケーションの実行に必要なほとんどの機能を提供して、ホストカーネルを介したアプリケーションへのアクセスを制限します。Google のインフラストラクチャにおいて、gVisor は、同じホスト上で実行される Google 社内のワークロードと Google Cloud のお客様のワークロードを互いに分離するために使用されている重要なツールの 1 つです。
表 2 に、セキュリティ原則のセクションで説明した各原則と、その原則を実装するために Google で使用しているツールを記載します。
| セキュリティ原則 | Google 社内のセキュリティ ツール / サービス |
| エッジでのネットワーク保護 | Google Front End（GFE）。受信トラフィックの TLS 終端とポリシーの管理に使用 |
| サービス間に固有の相互信頼関係を排除 | Application Layer Transport Security（ALTS）。RPC 認証、整合性、暗号化、サービス識別に使用 |
| 出所が明らかなコードを信頼できるマシンで実行 | Binary Authorization for Borg（BAB）。コードの出所を確認するために使用 ホスト整合性（HINT）。マシン整合性の検証に使用 |
| すべてのサービスに一貫したポリシーを適用するためのチョーク ポイント | サービス アクセス ポリシー。サービス間でのデータアクセスを制限するために使用 エンドユーザー コンテキスト（EUC）チケット。元のリクエスト送信者の ID を証明するために使用 |
| 自動化され、標準化されたシンプルな変更のロールアウト | Borg ツール。Blue / Green デプロイメントに使用 |
| オペレーティング システムを共有するワークロードを互いに分離 | gVisor。ワークロードを分離するために使用 |
表 2: Google でのクラウド ネイティブ セキュリティ実装に使用されている原則とセキュリティ ツール
すべてを組み合わせる
このセクションでは、上述のコンポーネントがクラウド ネイティブ環境で連動してユーザー リクエストを処理する仕組みについて説明します。2 つの例で説明します。最初の例では、一般的なユーザーデータ リクエストが作成されてから配信されるまでの過程を追跡します。2 番目の例では、開発から本番までのコード変更を追跡します。ここで取り上げるすべてのテクノロジーが Google インフラストラクチャのあらゆる部分で使用されるわけではありません。使用されるかどうかは、サービスやワークロードによって異なります。
ユーザーデータへのアクセス
図 1 に示すように、GFE がユーザーのリクエストを受信すると（ステップ 1）、TLS 接続を終端し、ALTS4 を介して該当するサービスのフロントエンドにリクエストを転送します（ステップ 2）。アプリケーション フロントエンドは、中央のエンドユーザー認証（EUA）サービスを使用してユーザー リクエストの認証を行います。認証が成功すると、有効期限の短い暗号エンドユーザー コンテキスト（EUC）チケットを受信します（ステップ 3）。
図 1: Google クラウド ネイティブ アーキテクチャのセキュリティ管理（ユーザーデータへのアクセス）
アプリケーション フロントエンドはストレージ バックエンド サービスに対し、ALTS を介して RPC を行います。その際、EUC チケットをバックエンド リクエストに含めて転送します（ステップ 4）。バックエンド サービスは、サービス アクセス ポリシーを使用して次のことを確認します。
- フロントエンド サービスの ALTS ID に、バックエンド サービスに対するリクエストと EUC チケットの提示が許可されていること。
- フロントエンドの ID が Binary Authorization for Borg（BAB）で保護されていること。
- EUC チケットが有効であること。
バックエンド サービスはさらに、EUC チケットに記載されているユーザーにリクエスト対象のデータへのアクセスが許可されているかどうかを確認します。これらのチェックが 1 つでも失敗すると、リクエストは拒否されます。多くの場合、連鎖した形のバックエンド呼び出しが行われます。この呼び出しチェーンで、各仲介サービスが受信 RPC に対してサービス アクセス ポリシーのチェックを行い、送信 RPC で EUC チケットを転送します。これらのチェックに合格すると、データが承認済みアプリケーションフロントエンドに返され、そこから承認済みユーザーに配信されます。
各マシンには HINT システムを介してプロビジョニングされた ALTS 認証情報が保管されています。この認証情報を復号できるのは、HINT がマシンブートの成功を確認した場合のみです。ほとんどの Google サービスは、Borg 上でマイクロサービスとして実行されます。これらのマイクロサービスには、それぞれ独自の ALTS ID が割り当てられます。Borgmaster5 はこのマイクロサービスの ID に基づいて、ワークロードに ALTS マイクロサービス認証情報を付与します（図 1 を参照）。マシンレベルの ALTS 認証情報により、マイクロサービス認証情報をプロビジョニングするためのチャネルがセキュリティで保護されます。したがって、HINT によるブート検証に成功したマシンだけがマイクロサービス ワークロードをホストできます。
コードの変更
図 2 に示すように、Google 社員は適切な強度の BAB で保護されているマイクロサービスに変更を加える際に、その変更を Google の中央コードリポジトリに送信し、コードレビューを受ける必要があります。コードレビューで承認されると、変更が中央の信頼できるビルドシステムに送信されます。このシステムにより、署名付きの検証可能なビルド マニフェスト証明書を含むパッケージが生成されます（ステップ 1）。このプロセスに従ったコード変更であることを検証するために、BAB はデプロイ時に、ビルド パイプラインから生成された署名済み証明書を検証します（ステップ 2）。
図 2: Google クラウド ネイティブ アーキテクチャのセキュリティ管理（コード変更）
すべてのワークロード更新は、定期的なロールアウトであるか緊急セキュリティ パッチであるかにかかわらず、Blue / Green デプロイメントで処理されます（ステップ 3）。GFE は、新しいデプロイメントにトラフィックを負荷分散して、オペレーションの継続性を確保します。
すべてのワークロードは互いに分離しなければなりません。信頼性の低いワークロードの場合（マルチテナント ワークロードである場合や、ソースコードの出所が Google 以外の場合など）、gVisor で保護された環境にデプロイされるか、または別の分離レイヤが使用されます。この分離により、あるアプリケーション インスタンスが不正使用されたとしても、他のインスタンスには影響が及ばないようになっています。
BeyondProd の適用
完全な移行
クラウド ネイティブ化したインフラストラクチャを適切に保護することで、Google は社内と外部（Google Cloud）のワークロードに非常に強力なセキュリティ特性を備えさせます。
共有コンポーネントを構築すると、個々のデベロッパーが一般的なセキュリティ要件を満たす負担が最小限になります。理想的には、セキュリティ機能は、アプリケーションごとに統合する必要がほとんど、あるいは一切ない、すべてのマイクロサービスを包括的に接続するファブリックとして提供されるべきです。このように提供されるセキュリティ機能は、一般にサービス メッシュと呼ばれます。こうしたサービス メッシュは、セキュリティを通常の開発またはデプロイ アクティビティとは切り離して管理し、実装できることも意味します。
クラウド ネイティブへの移行
Google がクラウド ネイティブに移行する際に変更が必要となった主な分野は、インフラストラクチャと開発プロセスの 2 つです。Google はこの 2 つの分野での変更に同時に取り組みましたが、分野を切り分けて個別に対処することも可能です。
インフラストラクチャの変更
まず、サービスの ID、認証、承認の強力な基盤の構築から取り組みました。信頼性の高いサービス ID の基盤を構成することで、サービス アクセス ポリシーや EUC チケットなど、これらのサービス ID の検証に依存する高度なセキュリティ機能を実装できました。新しいサービスと既存のサービスの双方でこの移行を容易に実現するため、1 つのヘルパー デーモンによるライブラリとして ALTS を提供しました。このデーモンは各サービスのすべてで呼び出されるホストで実行され、サービス認証情報を使用して時間の経過とともにライブラリに進化しました。ALTS ライブラリはコア RPC ライブラリとシームレスに統合されたため、各開発チームに大きな負担をかけることなく、広範に導入できました。ALTS のロールアウトは、サービス アクセス ポリシーと EUC チケットをロールアウトするための前提条件でした。
開発プロセスの変更
Google にとって、ビルドとコードのレビュー プロセスの堅牢化は極めて重要な課題でした。堅牢なプロセスがあってこそ、実行中のサービスの整合性と ALTS で使用される ID の両方を確実に有意なものにできます。2 人によるコードレビュー、ビルドとデプロイ時の自動テストといった要件の実施を導入できるようするために、ビルドプロセスを一元化しました。（デプロイの詳細は、Binary Authorization for Borg に関するホワイトペーパーをご覧ください）。
基本事項が実現された後は、Google の環境内で外部の信頼できないコードを実行する必要性への対処に取り掛かりました。この目標の達成に向けて、まずサンドボックス化を ptrace を使用して開始し、その後 gVisor の使用に移行しました。セキュリティ（パッチ適用など）と信頼性の面では、Blue / Green デプロイメントも同様に大きなメリットをもたらしました。
サービスは、ポリシー違反をブロックするのではなくログに記録して開始した方が容易であることにすぐに気づきました。このアプローチのメリットには次の 2 つの側面があります。第一に、サービス オーナーは変更をテストして、クラウド ネイティブ環境への移行がサービスに及ぼす影響があるかどうか、また、その影響を評価できます。第二に、Google ではバグを修正できるだけでなく、サービスチームにさらに提供が必要な機能も特定できます。たとえば、サービス オーナーは、サービスを BAB にオンボーディングする際に監査専用モードを有効にできます。監査専用モードでは、要件を満たしていないコードまたはワークフローを識別できます。サービス オーナーは監査専用モードで指摘された問題を解決してから、実施モードに切り替えます。gVisor では、サンドボックス化する機能に互換性のギャップがあっても、まずワークロードをサンドボックス化することから開始して、その後、そのギャップを体系的に解決することでサンドボックスを改善するといった方法をとりました。
変更のメリット
同様に、BeyondCorp も、境界ベースのセキュリティ モデルからの進化に役立ちました。BeyondProd も本番環境のセキュリティに対する Google のアプローチの大幅な躍進の成果です。BeyondProd のアプローチは、クラウド ネイティブのセキュリティ アーキテクチャです。サービス間に信頼がないという想定でワークロードを相互に分離し、一元的に構築されたアプリケーションだけがデプロイされていることを確認します。また、脆弱性管理を自動化するほか、重要なデータに対して強力なアクセス制御を適用します。これらの要件を合わせ、Google は BeyondProd アーキテクチャに基づいた改革を行うことで、いくつかの新しいシステムを導入しました。
ほとんどの場合、セキュリティは最後、つまり新しいアーキテクチャへの移行が決定された後に「取り上げ」られます。しかし、早期にセキュリティ チームに関与を求めて、パッチ管理の簡素化、アクセス制御の厳密化といった新しいセキュリティ モデルのメリットに注目することで、クラウド ネイティブ アーキテクチャからアプリケーション開発とセキュリティのチームの双方に大きなメリットを提供できます。このドキュメントで概説したセキュリティ原則をクラウド ネイティブのインフラストラクチャに適用することで、ワークロードのデプロイ、ワークロード間の通信のセキュリティ保護、他のワークロードへの影響の管理を強化できます。
注
1 Borg とは、大規模にワークロードのスケジューリングと実行を行う Google のクラスタ管理システムです。Borg は、Google 初の統合コンテナ管理システムであり、Kubernetes は、ここから着想を得て開発されました。
2「シフトレフト」とは、コーディング、ビルド、テスト、検証、デプロイなどのステップを実施するタイミングをソフトウェア開発ライフサイクルのより早い時期に移すことです。通常、ライフサイクルを示す図は左から右に向かって描画されるため、「レフト」は初期段階でのステップを意味します。
3 Blue / Green デプロイメントとは、エンドユーザーがアクセスする利用するアプリケーションでダウンタイムが発生しないように、受信トラフィックに影響を及ぼすことなく、ワークロードに変更をロールアウトする方法です。
4 Google インフラストラクチャ内で GFE からサービスにトラフィックがルーティングされる仕組みについて理解を深めるには、転送データの暗号化に関するホワイトペーパーのトラフィックのルーティング方法のセクションをご覧ください。
5 Borgmaster は、 Borg の一元化されたコントローラです。ジョブのスケジューリングを管理し、実行中のジョブと通信してそのステータスを伝えます。