BeyondProd

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

このドキュメントでは、Google が BeyondProd というクラウドネイティブ アーキテクチャを使用してインフラストラクチャにセキュリティを実装する方法について説明します。BeyondProd は、ワークロードを保護するために連携して機能する Google インフラストラクチャ内のサービスとコントロールを指します。ワークロードとは、アプリケーションによって完了される固有のタスクです。BeyondProd は、コードの変更方法やユーザーデータへのアクセス方法など、Google の環境で実行するマイクロサービスの保護に有効です。

このドキュメントは、高度な脅威から Google プラットフォームを保護するために開発された、BeyondCorp Enterpriseなどのテクノロジーについて説明する一連の技術論文の一部です。BeyondCorp Enterprise は、Google プラットフォームとそのプラットフォーム上で実行されているサービスへの安全なアクセスを提供するように設計されたゼロトラスト アーキテクチャを実装しています。BeyondCorp Enterprise と同様に、BeyondProd はファイアウォールなどの従来のネットワーク境界の保護に依存しません。代わりに、BeyondProd ではコードの起点、サービス ID、信頼できるハードウェアなどの特性を使用して、マイクロサービス間の信頼関係を構築できます。この信頼は、Google Cloud で実行されるソフトウェアだけでなく、Google Cloud のユーザーがデプロイしてアクセスするソフトウェアにも適用されます。

このドキュメントでは、BeyondProd の利点、サービスとプロセス、このアーキテクチャへの移行方法について説明します。Google のインフラストラクチャ セキュリティの概要については、Google インフラストラクチャのセキュリティ設計の概要をご覧ください。

はじめに

従来の境界ベースのセキュリティ モデルではファイアウォールで境界を保護し、境界内にいるユーザーやサービスは信頼できる対象とみなしましたが、最新のセキュリティ アーキテクチャはこのモデルとは異なるものになってきています。

現在、モバイル環境で仕事をするユーザーが増加し、自宅やコーヒー ショップ、飛行機など、組織の従来のセキュリティ境界の外で仕事をすることが一般的になっています。BeyondCorp Enterprise では、ユーザーの ID、リソースへのアクセスに使用されているデバイスの ID、デバイスの健全性、ユーザーの行動などの信頼シグナル、アクセス制御リストなど、複数の要素によって企業のリソースに対するアクセスを許可しています。

BeyondCorp Enterprise と同様に、BeyondProd は本番環境サービスに対するユーザーの懸念に対応しています。クラウドネイティブ アーキテクチャの場合、ファイアウォールだけでは本番環境ネットワークを保護できません。マイクロサービスは、異種ホスト間を移動し、さまざまな環境にデプロイされます。さらに、さまざまなレベルの信頼性と感度で実行されます。BeyondCorp Enterprise では、ユーザーに対する信頼は社内ネットワークへの接続機能ではなく、デバイスのコンテキスト認識といった特性に依存する必要があるとしていますが、BeyondProd では、サービスに対する信頼は IP アドレスやホスト名などの本番環境ネットワーク内の場所ではなく、コードの起点、信頼できるハードウェア、サービス ID などの特性に依存する必要があるとしています。

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

Google のインフラストラクチャでは、ワークロードはコンテナ内の個々のマイクロサービスとしてデプロイされます。マイクロサービスは、アプリケーションが実行する必要のある個々のタスクを異なるサービスに分割します。各サービスは、独自の API、ロールアウト、スケーリング、割り当て管理を使用し、個別に開発して管理できます。マイクロサービスは、独立し、モジュール化された、動的で一時的なものです。また、多くのホスト、クラスタ、クラウドに分散させることができます。マイクロサービス アーキテクチャでは、ワークロードは 1 つまたは複数のマイクロサービスである場合があります。

コンテナ化されたインフラストラクチャとは、移動可能でスケジュール可能な独自のコンテナのセットとして各マイクロサービスがデプロイされることを意味します。これらのコンテナを内部で管理するために、Borgと呼ばれるコンテナ オーケストレーション システムが開発されました。このシステムでは、1 週間に数十億個のコンテナがデプロイされています。Borg は Google の統合コンテナ管理システムであり、Kubernetes はここから着想を得て開発されました。

コンテナを利用することで、複数のマシン間でより簡単かつ効率的にワークロードをスケジューリングできます。コンテナにマイクロサービスをパッケージ化すると、ワークロードを管理しやすい小さなユニットに分割してメンテナンスや検索を行えます。このアーキテクチャは、ワークロードを必要に応じてスケーリングします。特定のワークロードの需要が高い場合は、同じコンテナのコピーを複数のマシンで実行し、要求された規模のワークロードに対応します。

Google では、アーキテクチャのあらゆる進化においてセキュリティが重要な役割を果たしています。このマイクロサービスのアーキテクチャと開発プロセスについては、開発と導入のライフサイクルのできる限り早い段階でコストをかけずにセキュリティ問題に対処し、標準化された一貫性のある方法で問題を解決することを目標としています。その結果、デベロッパーは最終的に安全性の向上に時間をかけずに安全性を確保できるようになります。

BeyondProd のメリット

BeyondProd は、Google インフラストラクチャにおいて多くの自動化とセキュリティに関する利点を提供します。これには、次のような利点があります。

  • ネットワーク エッジの保護: ワークロードは、ネットワーク攻撃やインターネットからの不正なトラフィックから隔離されます。境界ベースのアプローチは新しいコンセプトではありませんが、クラウド アーキテクチャのセキュリティのベスト プラクティスであることに変わりはありません。境界ベースのアプローチでは、不正なトラフィックや、ボリュームベースの DoS 攻撃など、潜在的なインターネット攻撃からできるだけ多くのインフラストラクチャを保護します。
  • サービス間の固有の相互信頼関係を排除: 他のサービスにアクセスできるのは、認証され、信頼できる、特別に承認された呼び出し元またはサービスのみです。これにより、攻撃者は信頼できないコードを使用してサービスにアクセスできなくなります。サービスが侵害されても、攻撃者が被害を拡大させるためのアクションを未然に防ぐことができます。この相互の不信感ときめ細かいアクセス制御と組み合わせることで、侵害の影響範囲を制限できます。
  • 出所の確かなコードを実行する信頼できるマシン: サービス ID は、承認済みのコードと構成のみを使用し、承認された確認済みの環境のみで実行されるように制約されています。
  • すべてのサービスに一貫したポリシーを適用: 一貫したポリシーを適用することで、サービス間でのアクセスに関する決定の信頼性を確保できます。たとえば、ユーザーデータへのアクセス リクエストを確認するポリシーを適用できます。サービスにアクセスするには、承認されたエンドユーザーが検証済みのリクエストを提示し、管理者がビジネス上の正当な理由を提示する必要があります。
  • 自動化され、標準化されたシンプルな変更のロールアウト: インフラストラクチャの変更によるセキュリティへの影響を簡単に確認でき、セキュリティパッチを本番環境にほとんど影響させずにロールアウトできます。
  • オペレーティング システムを共有するワークロード間の分離: サービスが不正使用されても、同じホスト上で実行されている別のワークロードのセキュリティに影響はありません。これにより、潜在的な侵害の範囲が制限されます。
  • 信頼できるハードウェアと証明書: ハードウェアのルート オブ トラストにより、ワークロードの実行がスケジュールされる前に、（ファームウェアからユーザーモードまでの）既知の承認済みコードのみがホスト上で実行されるようになります。

これらのメリットにより、インフラストラクチャのセキュリティを損なうことなく、コンテナと Google のクラウド アーキテクチャ内で実行されるマイクロサービスをデプロイし、相互に通信して連携して動作させることができます。さらに、基盤となるインフラストラクチャのセキュリティと実装の詳細に関して、個々のマイクロサービス デベロッパーに負担が生じることもありません。

BeyondProd セキュリティ サービス

Google は、BeyondProd のメリットで説明したメリットを生み出すために、複数の BeyondProd セキュリティ サービスを設計し、開発しました。以降のセクションでは、これらのセキュリティ サービスについて説明します。

ネットワーク エッジを保護する Google Front End

Google Front End（GFE）はネットワーク エッジを保護します。GFE はエンドユーザーからの接続を終了し、TLS のベスト プラクティスを実施するための中心的な機能を提供します。

境界ベースのセキュリティはもはや重視していませんが、GFE は引き続き、DoS 攻撃から内部サービスを保護する戦略の重要な部分を担っています。GFE は、Google インフラストラクチャに接続するユーザーの最初の入り口です。ユーザーが Google のインフラストラクチャに接続した後、GFE は必要に応じてロード バランシングとリージョン間のトラフィックのルーティング変更も行います。GFE は、適切なマイクロサービスにトラフィックを転送するエッジプロキシです。

Google Cloud のユーザーの VM は GFE に登録されません。代わりに、Cloud Front End に登録されます。Cloud Front End は、Compute Engine ネットワーキング スタックを使用する GFE の特別な構成です。Cloud Front End では、お客様の VM がパブリック IP アドレスまたはプライベート IP アドレスを使用して Google サービスに直接アクセスできます（プライベート IP アドレスは、限定公開の Google アクセスが有効な場合にのみ使用できます）。

サービス間の信頼を維持する Application Layer Transport Security

Application Layer Transport Security（ALTS）は、サービス間で固有の相互信頼関係を排除します。ALTS はリモート プロシージャ コール（RPC）認証、整合性、トラフィック暗号化、サービス ID に使用されます。ALTS は、Google のインフラストラクチャ内のサービスのための相互認証およびトランスポート暗号化システムです。ID は通常、特定のサーバー名やホストではなくサービスにバインドされます。このバインディングにより、ホスト間でのシームレスなマイクロサービス複製、ロード バランシング、再スケジューリングが容易になります。

各マシンにはホスト整合性システムを使用してプロビジョニングされた ALTS 認証情報が保管されています。この認証情報を復号できるのは、ホスト整合性システムがセキュアブートの成功を確認した場合のみです。ほとんどの Google サービスは、Borg 上でマイクロサービスとして実行されます。これらのマイクロサービスには、それぞれ独自の ALTS ID が割り当てられます。Borg の一元化されたコントローラである Borg Prime により、マイクロサービスの ID に基づいて、これらの ALTS マイクロサービス認証情報がワークロードに付与されます。マシンレベルの ALTS 認証情報により、マイクロサービス認証情報をプロビジョニングするためのチャネルがセキュリティで保護されます。したがって、ホスト整合性による検証済みブートに成功したマシンだけが、マイクロサービス ワークロードをホストできます。ALTS 認証情報の詳細については、ワークロード証明書をご覧ください。

コードの出所を確認する Binary Authorization for Borg

Binary Authorization for Borg（BAB）はコードの出所を確認します。BAB は、コードがデプロイ前に内部セキュリティ要件を満たしていることを確認する、デプロイ時に強制的に適用されるチェックのことです。たとえば、BAB 強制適用チェックでは、コードがソースコード リポジトリに送信される前に別のエンジニアによって変更がレビューされ、専用インフラストラクチャで検証可能な形でバイナリがビルドされます。Google のインフラストラクチャでは、BAB によって不正なマイクロサービスのデプロイを制限しています。

マシンの信頼性を維持するホスト整合性

ホストの整合性 は、セキュアブート プロセスを介してホストシステム ソフトウェアの整合性を検証します。サポートされている場合、ハードウェア ルート オブ トラスト セキュリティ チップ（Titan）によりバックアップされます。ホストの整合性チェックには、BIOS、ベースボード管理コントローラ（BMC）、ブートローダー、OS カーネルのデジタル署名の検証が含まれます。サポートされている場合、ホストの整合性チェックには、ユーザーモードのコードと周辺機器のファームウェア（NIC など）を含めることができます。ホストの整合性は、デジタル署名の検証だけでなく、各ホストが目的のソフトウェア コンポーネントのバージョンを実行していることを確認するのにも役立ちます。

ポリシーの適用に関するサービス アクセスの管理とエンドユーザー コンテキスト チケット

サービス アクセス管理とエンドユーザー コンテキスト チケットは、サービス間で一貫したポリシーを適用するのに役立ちます。

サービス アクセス ポリシー: サービス間のデータアクセスを制限します。RPC があるサービスから別のサービスに送信されるとき、サービス アクセス管理は、サービスが受信サービスのデータにアクセスするために必要な認可ポリシーと監査ポリシーを定義します。これにより、データのアクセス方法が制限され、最小限の必要なアクセス権が付与され、アクセスの監査方法が指定されます。Google のインフラストラクチャでは、サービス アクセス管理により、あるマイクロサービスから別のマイクロサービスのデータへのアクセスが制限され、アクセス制御の全般的な分析が可能になります。

エンドユーザー コンテキスト チケットはエンドユーザー認証サービスによって発行され、サービス ID とは別のユーザー ID をサービスに提供します。これらのチケットは、サービスをリクエストしたエンドユーザーの ID を証明する認証情報です。これは完全に保護され、一元的に発行され、転送が可能です。通常アクセスに関する決定はエンドユーザーの ID に基づいて行われますが、ALTS を使用するピア ID ではアクセス権の付与に十分でない場合があるため、これらのチケットにより、サービス間の信頼確認の必要性を低減できます。

変更とスケーラビリティの自動ロールアウトを行う Borg ツール

Blue/Green デプロイ用の Borg ツールは、自動化され、標準化されたシンプルな変更のロールアウトを提供します。Blue/Green デプロイメントとは、エンドユーザーがアクセスする利用するアプリケーションでダウンタイムが発生しないように、受信トラフィックに影響を及ぼすことなく、ワークロードに変更をロールアウトする方法です。

Borg ジョブは、アプリケーションの一部を実行するマイクロサービスの単一インスタンスです。ジョブは、処理する負荷に合わせてスケーリングされます。負荷が増えると新しいジョブがデプロイされ、負荷が減少すると既存のジョブは終了します。

Borg ツールは、メンテナンス タスクの実行時に実行中のワークロードの移行を行います。新しい Borg ジョブがデプロイされると、ロードバランサは既存のジョブから新しいジョブにトラフィックを徐々に移動します。これにより、ユーザーに気付かれることなく、ダウンタイムなしでマイクロサービスを更新できます。

また、このツールは新機能の追加のためにサービスを更新する場合や、Heartbleed や Spectre / Meltdown などの重要なセキュリティ アップデートをダウンタイムなしで適用する場合にも使用されます。インフラストラクチャに影響を与える変更については、ユーザーの VM のライブ マイグレーションを使用して、ワークロードへの影響を回避しています。

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

ワークロードを分離する gVisor カーネル

gVisor カーネルを使用すると、オペレーティング システムを共有するワークロード間の分離が可能になります。gVisor はユーザー空間カーネルを使用し、システムコールをインターセプトして処理することで、ホストとのやり取りを減らし、攻撃にさらされる可能性を低減します。ユーザー空間カーネルはアプリケーションの実行に必要なほとんどの機能を提供し、ホストカーネルを介したアプリケーションへのアクセスを制限します。gVisor は、同じホスト上で実行される Google 社内のワークロードと Google Cloud のお客様ワークロードを分離するために使用されているツールの 1 つです。他のサンドボックス ツールの詳細については、コードのサンドボックス化をご覧ください。

BeyondProd によるユーザーデータの保護

このセクションでは、BeyondProd サービスが連携して、インフラストラクチャのユーザーデータを保護する方法について説明します以降のセクションでは、2 つの例について説明します。

  • 作成から宛先への配信までのユーザーデータへのアクセス リクエスト。
  • 開発環境から本番環境へのコードの変更。

ここで挙げたすべてのテクノロジーが Google インフラストラクチャのすべての部分で使用されるわけではありません。これはサービスやワークロードによって異なります。

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

次の図は、ユーザーがユーザーデータへのアクセスを許可されていることを Google のインフラストラクチャが確認するプロセスを示しています。

ユーザーデータにアクセスする Google のクラウドネイティブのセキュリティ管理。

ユーザー アカウントにアクセスする手順は次のとおりです。

  1. ユーザーが GFE にリクエストを送信します。
  2. GFE は TLS 接続を終端し、ALTS を使用して適切なサービスのフロントエンドにリクエストを転送します。
  3. アプリケーション フロントエンドは、中央のエンドユーザー認証（EUA）サービスを使用してユーザーのリクエストを認証します。成功すると、有効期間の短い暗号化されたエンドユーザー コンテキスト チケットを受け取ります。
  4. アプリケーション フロントエンドは、ストレージ バックエンド サービスに対し、ALTS を介して RPC を実行します。その際、バックエンド リクエストでチケットを転送します。
  5. バックエンド サービスは、サービス アクセス管理を使用して、次の条件が満たされていることを確認します。
    • フロントエンドが、有効で失効していない証明書を使用して認証されている。このチェックは、フロントエンドが信頼できるホストで実行されており、BAB チェックが成功したことを示します。
    • フロントエンド サービスの ALTS ID に、バックエンド サービスに対するリクエストと EUC チケットの提示が許可されている。
    • エンドユーザーのコンテキスト チケットが有効である。
    • EUC チケットに記載されているユーザーは、リクエストされたデータへのアクセスが許可されます。

これらのチェックが 1 つでも失敗すると、リクエストは拒否されます。

これらのチェックに合格すると、データが承認済みアプリケーションフロントエンドに返され、そこから承認済みユーザーに配信されます。

多くの場合、連鎖した形のバックエンド呼び出しが行われます。この呼び出しチェーンで、各仲介サービスがインバウンド RPC に対してサービス アクセス チェックを行い、アウトバンド RPC でチケットを転送します。

インフラストラクチャ内でのトラフィックのルーティングの詳細については、トラフィックのルーティング方法をご覧ください。

コードの変更

以下の図は、コードの変更をデプロイする方法を示しています。

コードの変更方法。

コードを変更する方法は次のとおりです。

  1. デベロッパーが BAB で保護されているマイクロサービスに変更を行います。その変更は、コードレビューが行われる中央のコード リポジトリに送信されます。 承認後、変更は中央の信頼できるビルドシステムに送信され、署名付きの検証可能なビルド マニフェスト証明書を含むパッケージが生成されます。

  2. このプロセスに従ったコード変更であることを検証するために、BAB はデプロイ時に、ビルド パイプラインから生成された署名済み証明書を検証します。

  3. Borg は、定期的なロールアウトでも緊急のセキュリティ パッチでも、サービスの中断を最小限に抑えられる信頼性モデルを使用して、すべてのワークロード更新を処理します。

  4. GFE は、ロード バランシングを使用して新しいデプロイにトラフィックを移行し、オペレーションの継続性を確保します。

このプロセスの詳細については、開発環境と本番環境のプロセスをご覧ください。

すべてのワークロードは互いに分離しなければなりません。ソースコードの出所が Google の外部で、ワークロードの信頼性が低い場合は、gVisor で保護された環境にデプロイされるか、または別の分離レイヤが使用されます。この分離は、アプリケーションへの不正侵入をもくろむ攻撃者を阻止するのに有用です。

クラウドネイティブ セキュリティへの影響

次のセクションでは、従来のインフラストラクチャ セキュリティの側面と、クラウド ネイティブ アーキテクチャの対応する側面について比較します。

アプリケーション アーキテクチャ

従来のセキュリティ モデルでは、境界ベースのセキュリティを重視していたため、それだけでクラウドネイティブ アーキテクチャを保護することはできません。従来、モノリシック アプリケーションは 3 層アーキテクチャを使用し、重大イベントのピーク負荷に対応できる十分な処理能力を持つ、企業のプライベート データセンターにデプロイされていました。特定のハードウェアやネットワークの要件を持つアプリケーションは、固定 IP アドレスを保持する特定のマシンに意図的にデプロイされます。ロールアウトは頻繁に行われず、大型で、調整が困難でした。これは、ロールアウトをすると、アプリケーションの多くの部分に同時に影響が及ぶためです。そのためアプリケーションの存続期間は非常に長く、更新はあまり行われず、セキュリティ パッチの適用頻度も低くなります。

しかし、クラウドネイティブ モデルでは、アプリケーションがパブリック クラウド、プライベート データセンター、サードパーティのホストサービスなどで動作するため、異なる環境間で移動可能である必要があります。したがって、モノリシック アプリケーションではなく、マイクロサービスに分割されコンテナ化されたアプリケーションがクラウド環境に最適となります。コンテナは、アプリケーションに必要なバイナリを、基盤となるホスト オペレーティング システムから切り離し、アプリケーションのポータビリティを高めます。Google のコンテナは不変です。つまり、デプロイ後に変更されることはありません。代わりに、頻繁に再構築と再デプロイが行われます。

コンテナが頻繁に再起動、停止、再スケジュールされるため、ハードウェアやネットワークの再利用や共有が頻繁に行われます。ビルドとディストリビューションのプロセスは共通化されているため、各開発チームが個別にマイクロサービス開発を管理していても、開発プロセスはチーム間で一貫して均一化されています。その結果、セキュリティの考慮事項（セキュリティ レビュー、コードスキャン、脆弱性管理など）は開発サイクルの早い段階で対処することが可能です。

サービス メッシュ

すべてのデベロッパーが使用する、安全に設計された共有インフラストラクチャを構築すると、デベロッパーが共通のセキュリティ要件を把握して実装する負担が最小限に抑えられます。セキュリティ機能は、各アプリケーションに統合する必要がほとんど、あるいは一切ない、すべてのマイクロサービスを包括的に接続するファブリックとして提供されるべきです。このように提供されるセキュリティ機能は、一般にサービス メッシュと呼ばれます。こうしたサービス メッシュは、セキュリティを通常の開発またはデプロイ アクティビティとは切り離して管理し、実装できることも意味します。

サービス メッシュは、すべてのマイクロサービスを包括的に接続する、インフラストラクチャ レイヤの共有ファブリックです。サービス メッシュを使用すると、トラフィックの制御、ポリシーの適用、サービス呼び出しの集中監視を行う、サービス間通信が可能になります。

ゼロトラスト セキュリティ

プライベート データセンターを使用する従来のセキュリティ モデルでは、組織のアプリケーションは、外部のネットワークベースの脅威からワークロードを保護するためにファイアウォールに依存しています。

ゼロトラスト セキュリティ モデルではファイアウォールが存在しません。その代わり、ワークロードの ID、認証、認可などの他の制御により、トランザクションが処理される前に内部接続や外部接続が検証されるようにすることで、マイクロサービスを保護しています。ファイアウォールやネットワーク ベースの制御への依存を排除すると、サービス間の固有の信頼関係のない、マイクロサービス レベルのセグメンテーションを実装できます。マイクロサービス レベルのセグメンテーションでは、トラフィックは異なる制御でさまざまな信頼度を持つようになるため、内部トラフィックと外部トラフィックを比較するしか方法はなくなります。

サービス スタックに統合される共有セキュリティ要件

従来のセキュリティ モデルでは、個々のアプリケーションがそれぞれ独自のセキュリティ要件を満たす必要がありました。このような要件には、ID 管理、TLS の終端、データアクセス管理が含まれます。これらの問題は複数の場所で修正が必要になるため、実装の不一致や、未対応のセキュリティ問題につながる可能性があり、対応が難しくなります。

クラウドネイティブ アーキテクチャでは、サービス間でコンポーネントが頻繁に再利用されます。チョーク ポイントを使用すると、サービス間で一貫したポリシーを適用できます。異なるセキュリティ サービスを使用して異なるポリシーを適用できます。アプリケーションごとに重要なセキュリティ サービスを個別に実装する必要はなく、さまざまなポリシーを個別のマイクロサービスに分割できます。たとえば、あるポリシーではユーザーデータに対する認可されたアクセスを保証し、別のポリシーでは最新の TLS 暗号スイートの使用を保証することが可能です。

より頻繁なロールアウトを伴う標準化プロセス

従来のセキュリティ モデルでは、共有サービスの数は限られており、多くの場合、コードが複製されてローカルでの開発と組み合わされます。限定的な共有の場合、変更の影響を把握するのが難しくなります。また、その変更がアプリケーションのどの部分にどのように影響するのかを判断するのも容易ではありません。その結果、ロールアウトは頻繁に行われず、調整は困難でした。変更を加えるには、各コンポーネントを直接更新する必要がありました（たとえば、仮想マシンに SSH で接続し、構成を更新するなど）。全体的に見ると、アプリケーションの寿命は大幅に長くなる可能性があります。

しかし、セキュリティの観点からは、コードが重複している場合が多く、脆弱性が修正されたときに修正箇所が多岐にわたるため、検証が難しくなります。

クラウドネイティブ アーキテクチャでは、ロールアウトが頻繁に行われ、標準化されています。このプロセスにより、ソフトウェア開発ライフサイクルにおけるセキュリティのシフトレフトが可能になります。シフトレフトとは、コーディング、ビルド、テスト、検証、デプロイなどのステップを実施するタイミングを、ソフトウェア開発ライフサイクルのより早い段階に移すことです。シフトレフトすることで、セキュリティ パッチの定期的な適用など、よりシンプルで一貫したセキュリティの実施が可能になります。

BeyondProd への変更

Google が BeyondProd へ移行するには、インフラストラクチャと開発プロセスの 2 つの主な領域での変更が必要でした。Google ではこの 2 つの領域での変更に同時に取り組みましたが、ユーザー環境に同様のものを設定する場合は、個別に対処できます。

インフラストラクチャの変更

Google の目標は、インフラストラクチャ全体でセキュリティを自動化することです。これは、サービスの拡張に合わせてセキュリティも拡張する必要があると考えているからです。サービスのセキュリティが確保されるのがデフォルトで、そうでない場合が例外的であるべきです。Google のインフラストラクチャへの人的な介入はルーティンではなく、例外的なものです。人の介入が発生した場合には、監査可能な状態で実施する必要があります。これにより、サービスをデプロイしたユーザーではなく、サービスにデプロイされたコードと構成に基づいてサービスを認証することが可能になります。

Google ではまず、サービスの ID、認証、認可に強力な基盤を構築することから取り組みました。マイクロサービスでは、サービス IDを使用して、インフラストラクチャ内で実行されているその他のサービスに対して自身を認証します。信頼性の高いサービス ID の基盤を構成することで、サービス アクセス管理やエンドユーザー コンテキスト チケットなど、これらのサービス ID の検証に依存する高度なセキュリティ機能を実装できました。新しいサービスと既存のサービスの双方でこの移行を容易に実現するため、1 つのヘルパー デーモンによるライブラリとして ALTS を提供しました。このデーモンは各サービスのすべてで呼び出されるホストで実行され、サービス認証情報を使用して時間の経過とともにライブラリに進化しました。ALTS ライブラリはコア RPC ライブラリにシームレスに統合されました。この統合により、個々の開発チームに大きな負担をかけることなく、広範囲に導入できるようになりました。ALTS のロールアウトは、サービス アクセス管理とエンドユーザー コンテキスト チケットを展開するための前提条件でした。

開発プロセスの変更

Google にとって、実行中のサービスの整合性を確保するために、ビルドとコードのレビュー プロセスの堅牢化は極めて重要な課題でした。Google では、ビルドとデプロイで 2 人の担当者によるコードレビューや自動テストなどの要件を満たす中央のビルドプロセスを構築しました（デプロイの詳細については、Binary Authorization for Borg をご覧ください）。

基本事項が実現された後、Google の環境内で外部の信頼できないコードを実行するための対策に取り組みました。この目標の達成に向けて、まず、ptrace を使用してサンドボックス化を実装しました。これは、その後 gVisor によるサンドボックス化に移行しました。セキュリティ（パッチ適用など）と信頼性の面では、Blue/Green デプロイも大きなメリットをもたらしました。

サービスは、ポリシー違反をブロックするのではなくログに記録して開始した方が容易であることにすぐに気づきました。このアプローチのメリットには次の 2 つの側面があります。

  • 第一に、サービス オーナーが変更をテストし、クラウドネイティブ環境への移行がサービスに及ぼす影響の有無とその度合いを評価できます。
  • バグを修正するだけでなく、サービスチームに提供する必要のある追加機能を特定できます。

たとえば、サービス オーナーは、サービスを BAB にオンボーディングする際に、監査専用モードを有効にできます。監査専用モードでは、要件を満たしていないコードまたはワークフローを識別できます。サービス オーナーは、監査専用モードで指摘された問題を解決してから、自動適用モードに切り替えます。gVisor では、サンドボックス化する機能に互換性のギャップがあっても、まずワークロードをサンドボックス化することから開始して、その後、そのギャップを体系的に解決することでサンドボックスを改善するといった方法をとりました。

次のステップ