コンテンツに移動
セキュリティ & アイデンティティ

BeyondCorp と BeyondProd によって実現される実績のある統合型ゼロトラスト システム

2021年9月9日
https://storage.googleapis.com/gweb-cloudblog-publish/images/Google_Cloud_security.max-2600x2600.jpg
Google Cloud Japan Team

※この投稿は米国時間 2021 年 8 月 26 日に、Google Cloud blog に投稿されたものの抄訳です。

今日、サイバーセキュリティの世界で最も使われている流行語の 1 つが「ゼロトラスト」であることに疑いの余地はありません。ゼロトラストはさまざまなアプローチやプロダクトを説明するのに使用されているため、用語そのものに対する多くの混乱が生まれ、本来の意味がわかりにくくなっています。「ゼロトラストとは何も信頼しないことである」や「ゼロトラストとは VPN を使わずに安全なアクセスを実現することである」と断言することでゼロトラストを説明したり、わかりやすくしようとしたりする人もなかにはいます。しかし、こうした従来の常識は多くの場合間違いであり、ゼロトラストのすべてを説明しているとは言えません。ゼロトラスト アプローチの中核となるのは、複雑で相互接続されたシステムの単一コンポーネントに対する盲目的な信頼は、重大なセキュリティ リスクをまねく可能性があるという考えです。ですから、複数の仕組みを介して信頼を確立し、それを継続的に検証する必要があると考えます。エンドユーザーのアクセスは、このモデルを適用することでセキュリティを大幅に向上させることができる領域ですが、クラウドネイティブ インフラストラクチャ上で本番環境のシステムを実行し、ワークロードを保護するエンドツーエンドのプロセスなどの領域にも同様に適用することが可能です。

Google では大半の運用業務にゼロトラスト アプローチを適用しています。ユーザー認証情報は、最大限の努力を行ったとしても周期的に悪意のある人物の手に渡ってしまうものだということは、セキュリティに関する取り組みの初期段階からわかっており、Google では、ユーザーの生産性を下げすに不正アクセスから守るための新たな方法を必要としていました。BeyondCorp フレームワークによって、10 年以上前にゼロトラスト アクセス アプローチを導入したのもこのためです。さらに、Google のユースケースを世界中に公開するとともに、あらゆる組織が自社アプリケーションに同じような機能を実装できる、脅威からの保護とデータの保護を統合した製品バージョンである BeyondCorp Enterprise をリリースしました。

ユーザーの認証情報は不正な行為者に取得される可能性があるため、インターネット上でやりとりを行うソフトウェアにはさまざまなレベルで保護が必要です。そこで、Google では本番環境の運用方法にもゼロトラスト アプローチを適用することで、ソフトウェアを考案、製品化して管理し、他のソフトウェアとやりとりする方法を強化しました。ゼロトラストを Google 社内で製品化する方法を「BeyondProd」と命名したのもこのためです。

BeyondProd によるゼロトラストの製品化

2019 年、Google は BeyondProd モデルに関するホワイトペーパーを公開しました。このホワイトペーパーでは、Google が自社のクラウドネイティブ アーキテクチャを保護している方法を説明するとともに、Google が社内で確立したセキュリティ原則を組織に適用する方法を紹介しました。

Google は次のセキュリティ原則を策定して最適化しました。

  • エッジでのネットワークの保護。ネットワークからの攻撃やインターネットからの不正なトラフィックからワークロードが隔離されます。

  • サービス間の相互信頼がない。サービスを利用できるのは、既知の、信頼できる、具体的は利用を認可された呼び出し元のみです。これにより、攻撃者は信頼できないコードを使用してサービスにアクセスできなくなります。サービスが侵害された場合、攻撃者はリーチ拡大のためのアクションを実行できません。この相互の信頼確認は、侵害される範囲を制限するのに役立ちます。

  • 信頼できるマシン。Titan を使って設計されており、起動時から保護して出所の確かなコードを実行します。サービス ID は、許可されたコードと構成のみを使用して、認可および検証済みの環境でのみ実行するように制限されます。

  • すべてのサービスに一貫したポリシーを適用するためのチョーク ポイント。たとえば、ユーザーデータへのアクセス リクエストを検証するチョーク ポイントを見つけて、アクセス権限を付与されたエンドユーザーからの有効なリクエストに起因するサービス アクセスを受け入れ、管理者がアクセスする際にはビジネス上の正当な理由を求めるようにします。

  • 自動化され、標準化されたシンプルな変更のロールアウト。インフラストラクチャの変更によるセキュリティへの影響を簡単に確認でき、セキュリティパッチを本番環境にほとんど影響せずにロールアウトできます。

  • オペレーティング システムを共有するワークロード間の分離。サービスが侵害されても、同じホスト上で実行されている別のワークロードのセキュリティには影響しません。これにより、潜在的な侵害の範囲が制限されます。

BeyondCorp は、現代の企業ユーザーの働き方の変化に対応して生まれました。今のユーザーは、コーヒー ショップ、飛行機内など、組織の通常のセキュリティ境界の外で仕事をすることがよくあります。BeyondCorp では、特権のある企業ネットワークという概念や、ユーザーがネットワーク上のどこにいようがデバイスとユーザーの認証情報と属性だけを頼りにアクセスを許可するという発想を完全に捨てました。

BeyondProd では、サービス保護に同様のゼロトラスト アプローチを採用しています。ユーザーがみな物理的に同じ場所やデバイスを使用しないのと同様、すべてのデベロッパーがコードを同じ環境にデプロイしているわけではありません。BeyondProd では、マイクロサービスはファイアウォールのあるデータセンターだけでなく、パブリック クラウド、プライベート クラウド、サードパーティのホストサービスでも動作し、どこからでも安全が確保される必要があります。

ユーザーが移動して、別のデバイスでさまざまな場所から接続するように、マイクロサービスも異機種のホスト間を移動することで、さまざまな環境にデプロイされます。BeyondCorp には「ユーザーの信頼は、社内ネットワークへの接続機能ではなく、デバイスのコンテキスト認識といった特性に依存する必要がある」と書かれています。一方、BeyondProd にはサービスの信頼は、IP やホスト名などの本番環境ネットワーク内の場所ではなく、コードの起点やサービス ID といった特性に依存する必要がある」と書かれています。

クラウドネイティブ アーキテクチャへの BeyondProd 原則の適用

BeyondProd を作成してから長年にわたり、Google における複雑さの規模は他とは比べものにならないほど大きなものでした。しかし、オンライン サービスやアプリ、クラウド コンピューティングが普及するにつれ、こうした状況も少しずつ変わっていきました。

他社の製品化の課題を解決していくなかで、Google Cloud のお客様に BeyondProd のツールやテクニックを提供してきました。Google Cloud のマネージド アプリケーション プラットフォームである Anthos や、Binary AuthorizationAnthos Service Mesh などの機能に BeyondProd の多くの機能が組み込まれています。

自社のクラウドネイティブ インフラストラクチャに BeyondProd モデルのセキュリティ原則を適用することで、通信を強化する方法やそれが他のワークロードに与える影響などの Google の経験を活かして、ワークロードのデプロイを強化できるのです。

自社環境に BeyondProd の原則を適用することを検討している場合、Anthos や Google Kubernetes Engine(GKE)、オープンソースのさまざまなコンポーネントを活用して同じようなアーキテクチャを実現できます。

  • Envoy または Traffic Director。受信トラフィックの TLS 終端とポリシーの管理に使用

  • Istio または Istio on GKE の一部としての相互 TLS。リモート プロシージャ コールの認証、連携、暗号化、およびサービス ID に使用

  • Anthos Service Mesh。自動的かつ宣言的にサービスとサービスの通信を保護するゼロトラスト セキュリティ モデル ツールセットに使用

  • Anthos Identity Services。複数の環境間での ID 連携のサポートに使用

  • Binary Authorization。コードの出所など、デプロイ時の強制適用チェックに使用

  • Anthos Config Management Policy Controller。プログラム可能なポリシーをクラスターに適用し、構成の変更によるセキュリティ、運用、コンプライアンスの管理の違反を防止するために使用

  • シールドされた GKE ノード。セキュアブートと整合性の検証に使用

  • gVisor または GKE Sandbox。ワークロードの分離に使用

ソフトウェア エコシステムへのゼロトラスト アプローチの拡張

BeyondCorp ではリソースにアクセスできるユーザーをきめ細かく制御できるようにしました。BeyondProd によって、サービス間のアクセスでも同じことができるようになりました。さらに、SLSA フレームワークによってソフトウェア エコシステムでも同じことができるようになりました。

本番環境にデプロイされたソフトウェアは通常、多くの異なるソースからのアーティファクトを組み込みます。

グローバルなソフトウェア サプライ チェーンは、コード、バイナリ、ネットワーク化された API とその構成ファイルを極めて複雑に組み合わせたものへと自然発生的に進化しています。このソフトウェア レイヤーにゼロトラストをどのように拡張すればよいのでしょうか。Binary Authorization for Borg など、社内の開発ワークフローとデプロイ ワークフローのための強力かつ実績のあるメカニズムを Google 社内では開発、導入しています。サプライ チェーンの整合性に関するベスト プラクティスの導入をさらに進めるため、Google ではこのアプローチをより幅広い業界の取り組みにまで拡張したいと考えています。Google は OpenSSF とのコラボレーションを通して、ソフトウェア サプライ チェーンの整合性に関連する基準を形式化するソフトウェア アーティファクトのためのサプライ チェーン レベル(SLSA)を提唱しました。

BeyondCorp と BeyondProd は今日の業界の多くに適用できる統合型ゼロトラスト システムであるとともに、認証情報の盗難やソフトウェア サプライ チェーン攻撃などの一般的なセキュリティ脅威を防止するためのフレームワークであると Google では考えています。Google はゼロトラストのアクセスと製品化の原則に基づくセキュリティの状況を改善すべく、引き続きさまざまなフォーラム、業界グループ、教育活動に参加していきます。

デジタル時代、そしてファイアウォールや境界、分離の視点から人々が考える時代に合わせてツールと手法を更新することで、世界中の数百万人ものエンジニアがクラウドでネイティブかつ安全に構築できるようにすることが重要です。

組織へのゼロトラスト環境の導入を成功させるソリューションを利用することで、Google、Google パートナー、サードパーティがソフトウェア セキュリティにおいて長年にわたって積み上げてきた実績というメリットを得ることができます。セキュリティを念頭に置いて策定された、ソフトウェアの製品化とユーザー アクセスに関するデザイン原則に従うことで、目の前、そしてまだ見ぬ課題にも対処できるクラウドネイティブ アーキテクチャを実現できます。

-Google Cloud バイス プレジデント兼フェロー Eric Brewer

-Google Cloud バイス プレジデント兼 CISO Phil Venables
投稿先