BeyondProd

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

このコンテンツの最終更新日は 2022 年 11 月で、作成時点の状況を表しています。お客様の保護の継続的な改善のために、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、デバイスの健全性、ユーザーの行動などの信頼シグナル、アクセス制御リストなど、複数の要素を使用して企業のリソースへのアクセス権が付与されます。

BeyondProd は、BeyondCorp Enterprise と同じように、ユーザーの本番環境サービスに対する懸念に対処します。クラウドネイティブ アーキテクチャでは、ファイアウォールだけでは本番環境ネットワークを保護できません。マイクロサービスは、異種ホスト間でさまざまな環境に移動し、デプロイされます。そして、さまざまなレベルの信頼性と感度で動作します。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 のベスト プラクティスを実施するための中心的な機能を提供します。

境界ベースのセキュリティはもはや Google で重視されていませんが、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 強制適用チェックには、コードがソースコード リポジトリに送信される前に第 2 のエンジニアによって変更がレビューされること、専用インフラストラクチャで検証可能な形でバイナリがビルドされることなどが含まれます。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 で EUC チケットを転送します。

インフラストラクチャ内でトラフィックがどのようにルーティングされるかについては、トラフィックのルーティング方法をご覧ください。

コードの変更

次の図は、コードの変更がどのようにデプロイされるかを示しています。

コードの変更方法。

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

  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 のインフラストラクチャへの人間による介入は、ルーティンではなく例外的であり、その介入が発生するたびに監査できる必要があります。そうすれば、サービスをデプロイしたユーザーではなく、サービスにデプロイされたコードと構成に基づいてサービスを認証できます。

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

開発プロセスの変更

Google にとって、実行中のサービスの整合性を確保するために、ビルドとコードのレビュー プロセスの堅牢化は極めて重要な課題でした。2 人によるコードレビュー、ビルドとデプロイ時の自動テストといった要件の実施を導入できるようするために、ビルドプロセスを一元化しました。(デプロイの詳細は、Binary Authorization for Borg をご覧ください)。

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

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

  • サービス オーナーは変更をテストして、クラウドネイティブ環境への移行がサービスに及ぼす影響があるかどうか、また、その影響を評価できます。
  • バグを修正し、サービスチームにさらに提供が必要な機能を特定できます。

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

次のステップ