Google ゼロトラスト アーキテクチャの実践

背景の紹介

この記事の著者は、幸運にも 2015 年から 2020 年まで Google の実稼働環境に参加できた Chen Zhijie です。ゼロトラスト(本番環境におけるゼロトラスト) の理論と実践。このコンテキストで開発された Binary Authorization for Borg (BAB) システムは、Google の本番環境で完全にカバーされています: 本番環境でパッケージをサービスとして実行するには、その前にターゲット サービスに対する十分な認証を確立する必要があります。強力な BAB セキュリティポリシー。 BAB セキュリティ ポリシーに準拠していないプログラムは、対応するサービスとして実行できません。

このゼロトラスト運用環境を実装および推進する過程で、BAB チームは多くの回り道をしましたが、多くの経験も得ました。 2017 年から、BAB チームはこれらの実践的な経験を理論に変換し始め、一連のホワイト ペーパーを次々に発表しました ( BeyondProd、 Borg の Binary Authorization, SLSA: ソフトウェアアーティファクトのサプライチェーンレベル)、本( 安全で信頼性の高いシステムの構築) およびレポート ( Anthos セキュリティを使用したゼロトラスト セキュリティ モデルへの進化, ゼロタッチ製品）。同時に、このゼロトラストの概念は、パブリック クラウドでのゼロトラスト、パブリック クラウド自身のインフラストラクチャでのゼロトラスト、Android や Android の開発におけるゼロトラストなど、より多くのアプリケーション シナリオにも推進され始めています。 Chrome 自体とそのアプリ。

今回共有された内容はすべてGoogleが公開した上記情報に基づくものであり、Googleの企業秘密の漏洩や機密保持契約に違反するものではありません。この記事の結論は著者の個人的な見解のみを表すものであり、必ずしも Google の公式見解ではありません。

ゼロトラストとは何ですか

ゼロトラストとは何ですか?人が異なれば、異なる答えが返ってくる可能性があります。ゼロトラストはワークロードのマイクロセグメンテーションであるという人もいますし、ゼロトラストは継続的な脅威監視であるという人もいますし、ゼロトラストはネットワークの信頼をピアエンド（ネットワークではなくエンドポイントを信頼する）の信頼に置き換えているという人もいます。双方向 TLS 認証 (mTLS)。これらはすべて意味がありますが、明らかに包括的ではありません。

ここで、著者は機械学習に関するジョークを借りたいと思います:「機械学習は美化された統計です。同様に、ゼロトラストは美化された最小権限です。特権)」。これも明らかに不正確です。機械学習とゼロトラストはどちらも、統計や最小権限よりも特定の問題やアプリケーション シナリオに重点を置いているからです。機械学習とゼロトラストは単一の分野や理論ではなく、実際的な問題を解決するために開発された複数の分野 (数学、コンピューター アーキテクチャ、分散システム、ストレージ、ネットワークなど) における革新的な実践です。

ゼロトラストの場合、定義や理論をあまり厳格にする必要はなく、実践と組み合わせて、解決すべき特定の問題とアプリケーション シナリオから始める必要があることがわかります。したがって、この記事では問題とアプリケーション シナリオを一時的に組み合わせて、ゼロ トラストを次のように定義します: 保護されるデータとアクセス許可から始まり、保護されたデータと権限に関する運用環境での信頼を包括的に削減および再構築します。

ゼロ トラストの定義よりも重要な質問は、「なぜゼロ トラストを実行したいのですか?」です。

なぜゼロトラストが必要なのでしょうか?

なぜゼロトラストが必要なのでしょうか?最も本質的な理由は、保護する必要がある重要なデータや権限があり、クラウド ネイティブ時代には既存のセキュリティ システムでは十分な保護を提供できなくなっていることです。ユーザーの個人プライバシーデータ、従業員の給与データ、パスワード変更の許可、主要システムをシャットダウンする許可などはすべて保護対象です。これらのデータと権限は、企業イントラネットや VPN などの境界セキュリティに基づくネットワーク アクセス制御によって最初に保護されます。デバイスが企業イントラネットに接続されると、これらのデータと権限を取得する機能が継承されます。その後、IP ベースまたはユーザー名とパスワードベースのアクセス制御と、ID と役割 (ID と役割) に基づいたよりきめの細かいアクセス制御が導入され始めました。しかし、これらはクラウドネイティブ環境、特に Google のような複雑なエンタープライズ IT システムにおけるデータと権限の保護要件を満たすことができなくなりました。

クラウド ネイティブには次のような課題があります。 まず、企業の IT システムはシングル コンピューター ルーム モデルからクロスクラウド ハイブリッド (マルチクラウドおよびハイブリッド クラウド) モデルに進化しました。これにより、境界があいまいになり、境界に基づくセキュリティが非効率になります。保護; 2 番目に、コンテナ (コンテナ) に基づくコンピューティングはホストの不確実性につながります。同じサービスをオフラインにすることなく、いつでも 1 つの物理ホストから別の物理ホストに移行できます。これにより、ホストベースのセキュリティ保護は不可能になります。さらに実現します。サービス ロジックに基づく徹底した保護、3 番目に、マイクロサービス (マイクロサービス) ときめ細かい API により、攻撃対象領域が増加します。アイデンティティとロールは、もはや単なるエンド ユーザーのアイデンティティとロールではなく、マイクロサービス間の対話のより重要な側面です。 . きめ細かい ID とアクセス制御。

2015 年頃の当時の Google の状況を踏まえ、社内ではキーと ID 認証に基づく比較的成熟した権利管理システムを実装していましたが、2 つのセキュリティ上の脅威が私たちの注意を引きつけました。データセンターでは、相互信頼を確立する方法と、侵害されたホストや侵害されたサービスが実稼働環境の他の部分に影響を与えないようにするにはどうすればよいでしょうか? 2 つ目は、単発のデータと権限アクセスに対する適切な認可と監査システムがある場合、機械学習のようなバッチ (Batch) データと権限アクセスによって引き起こされる大規模なデータ漏洩にどのように対処するか? 隠れた危険?ゼロトラストに基づくインサイダーリスク管理・統制体制の確立が急務となっている。

もちろん、これらはすべて、ネットワークおよびホスト保護システム、トラステッド ブート、キー管理システム、ID 認証および管理システムなどの、堅実な従来のセキュリティの基礎に基づいています。ゼロ トラストは、このセキュリティの基本に基づいて構築された上部構造です。

ゼロトラストの 3 つの要素: チェーン オブ トラスト、アイデンティティ 2.0、継続的アクセス制御

信頼の連鎖、アイデンティティ 2.0、継続的アクセス制御は、ゼロトラストの 3 つの主要な要素です。

信頼の連鎖

ゼロトラストは、信頼がまったく存在しないことを意味するのではなく、いくつかの基本的な最小限の信頼のルート (ルート オブ トラスト) から始まる信頼のチェーン (チェーン オブ トラスト) を再構築する明確なプロセスを意味します。典型的な例としては、多要素認証 (MFA) は個人の ID の信頼のルート、トラステッド プラットフォーム モジュール (TPM) とトラステッド ブート (トラステッド ブート) はマシンの ID です。信頼のルート、ソース コードと信頼できるビルド ( Trusted Build) はソフトウェアの信頼のルートです。巨大な IT システムの信頼は、これらの最も基本的な信頼のルートから始まり、一連の標準化されたプロセスを通じて完全な信頼のチェーンを確立します (これを信頼のツリーまたは信頼の Web と呼ぶ人もいます)。

アイデンティティ 2.0

Identity 2.0 は、信頼確立プロセス中に収集された情報をセキュリティ アクセス ポリシーで使用できるように、上記の信頼チェーンを標準化したものです。 Identity 2.0 では、すべてのエンティティが ID を持ち、ユーザーがユーザー ID を持ち、従業員が従業員 ID を持ち、マシンがマシン ID を持ち、ソフトウェアもソフトウェア ID を持ちます。Identity 2.0 では、すべてのアクセスが複数の ID (アクセス コンテキストとも呼ばれる) を持ちます。 、データベース内のデータ行へのアクセスには、「ユーザーが技術的な問題を解決できるようにするために、従業員 A はユーザー B の承認を得て、ソフトウェア C を介してマシン D へのアクセスを要求しました。」のようなものになります。背景にアクセスします。

継続的なアクセス制御

Identity 2.0 によって提供される豊富な ID とアクセスの背景情報を使用すると、これに基づいて継続的なアクセス制御システム (Continous Access Control) を確立できます。継続的アクセス制御では、ソフトウェア開発と運用のあらゆる側面でアクセスを継続的に制御します。典型的な例としては、従業員がログインするときに多要素認証を要求すること、ソフトウェアを安全な環境で信頼できるソース コード ライブラリから構築し、ソフトウェアをデプロイするときにコード レビュー (コード レビュー) を受けることを要求すること、マイクロサービス間の接続を確立するときに両方の認証を要求することなどがあります。関係者はホスト整合性証明書を提供する必要があり、マイクロサービスが特定のユーザー データを取得する場合は、ユーザーの認可トークン (認可トークン) が必要です。

ゼロトラスト展開の例

このセクションでは、2 つの具体的なゼロトラスト展開例を示します。1 つ目は、ユーザーが自分のデータを取得する方法であり、2 つ目は、開発者がソース コードを変更して運用環境でのデータ アクセス動作を変更する方法です。どちらの場合でも、Google のデータ アクセス制御はゼロトラストの原則に従っています。

ユーザーは自分のデータにアクセスします

ユーザーが Google のサービスを通じて自分のデータにアクセスすると、リクエストはまずユーザーと Google フロント エンド (GFE) 間の暗号化接続 (TLS) を通じて GFE に到達します。 GFE は、より効率的で安全なプロトコルとデータ構造に切り替えて、ユーザー リクエストをさまざまなバックエンド サービスに分散し、ユーザー リクエストを共同で完了します。たとえば、TLS は次のように置き換えられます。アプリケーション層TLS(ATLS)。ユーザー向けのパスワードは、より安全なエンド ユーザー コンテキスト チケット (EUC) に変換されます。これらの順列は、実際のリクエストに基づいて内部接続とトークンのアクセス許可を減らすように設計されており、特定の ATLS と EUC はこのリクエストに限定されたデータとアクセス許可のみにアクセスできます。

以下はBeyondProd元の画像では、画像内の開発者は実際にはユーザーである必要があります。

 

 

開発者がソフトウェアのデータアクセス動作を変更

開発者がサービス コードを変更してサービスのデータとアクセス許可の動作を変更したい場合 (開発者は SSH などの運用ホスト上でコマンド実行許可を取得できません)、コードの変更は一連のプロセスを経て行われます。開発プロセスに影響を及ぼします。作成者とそのチームの信頼が、新しいサービスへの信頼に変わります。プロセスに関与するすべての担当者が多要素認証を通じてアイデンティティを確立し、コードの変更は承認を得て 1 人以上の担当者によって評価されます。十分な承認が得られた場合にのみ、コードが中央のコード ベースにマージされます。中央のコード ベースのコードは、BAB によって保護されている信頼できるビルド サービスによって中央で構築、テストされ、署名されます。ソフトウェアは、展開プロセス中にターゲット サービスの BAB ポリシー認証に合格します (たとえば、GMail のサービスは、コード ベースの特定の場所で完全に評価およびテストされたコードのみを実行できます)。また、対応する BAB セキュリティ ポリシーに従って隔離されます。異なる BAB サービス ポリシーによって管理されるサービスは、異なる検疫エリアで実行されます。

以下はBeyondProd元の画像、詳細については元のテキストを参照してください。

 

実践的な体験とレッスン

人を第一に考え、プロセスから信頼を築きます

BeyondCorp を使用して開発環境 (Corp 環境) にゼロトラストを実装する場合、私たちは人を第一に考え、従業員の ID 管理と多要素認証を実施します。同時に、会社のデバイスを管理するプロセスを確立し、各会社のデバイスには TPM モジュールとオペレーティング システムの整合性検証が搭載されています。これら 2 つの取り組みにより、適切な人物が適切なデバイスを使用して、信頼できる認証情報を提供できるようになります。最後に、この認証情報を使用して、開発環境への従業員のアクセスを継続的に制御します。

BeyondProd を使用して実稼働環境 (本番環境) にゼロトラストを実装する場合、信頼の基盤として人とプロセスを使用することも試みます。 BeyondProd が直面している問題は、運用環境が人々と直接対話しないことです。そのため、開発者の認証と開発からソフトウェアの開発者までの一連のトレーサビリティ ソフトウェア (ソフトウェア プロビナンス) を運用環境に確立しました。このプロセスは、誰も実稼働環境でのソフトウェアの動作を変更できないようにするために開始されます (一方的な変更は禁止)。

セキュリティルールレベル

ローマは一日にして成らず、ゼロトラストの推進も段階的なプロセスです。安全性の向上を定量化し、奨励するために、当社は安全性ルールの評価を使用して、ある安全性ルールが別の安全性ルールよりも「安全」であるかどうかを測定します。たとえば、Binary Authorization for Borg システムでは、次のセキュリティ レベルを導入しました。

セキュリティ レベル 0: 保護なし。これは最も低いセキュリティ レベルであり、サービスが BAB によってまったく保護されていないことを意味します。これは、システムに機密性の高いアクセス許可がないか、システムが BAB と同等の他の保護を使用していることが原因である可能性があります。

セキュリティ レベル 1: 監査可能なコード。このレベルのセキュリティ ルールにより、対応するサービスで使用されるソフトウェアが安全で検証可能な環境で既知のソース コードから構築されることが保証されます。

セキュリティ レベル 2: 信頼できるコード。セキュリティ レベル 1 を保証することに加えて、このレベルのセキュリティ ルールでは、対応するサービスで使用されるソフトウェアが特定のコード ベース (Gmail 独自のコード ベースなど) でコード レビューおよびテストされたコードから構築されていることも保証されます。 2020 年 2 月の時点で、このレベルはすべての Google サービスのデフォルトの保護レベルです。

セキュリティ レベル 3: 信頼できるコードと構成。セキュリティ レベル 2 を保証することに加えて、このレベルのセキュリティ ルールは、対応するサービスによって使用される構成ファイルがコードと同様の同じセキュリティ プロセス (コードとしての構成) を通過していることも保証します。 2020 年 2 月の時点で、このレベルはすべての Google のキー保護サービスのデフォルト レベルです。

警報システムと認証システム

ゼロトラストを推進する過程で、すべての関係者にスムーズな移行体験を提供するために、セキュリティ ルールに準拠しないすべてのアクセスを直接禁止するのではなく、セキュリティ ルール自体にアラーム システムと認可システムの 2 つのモードを提供します。 。警報システムでは、セキュリティルールに違反したアクセスは遮断せず、記録して関係者に警告しますが、認証システムでは、セキュリティルールに違反したアクセスを即座に遮断します。この二重システムの存在により、アラームに基づいて非準拠の動作を継続的に反復して改善する機会が与えられるだけでなく、セキュリティ ルールを強化し、非準拠の動作が排除された後の後退を防止する効果的なメカニズムも提供されます。

安全かつ安定してください

ゼロトラストの複雑さにより、システムの安定性 (信頼性) を維持する上で新たな課題に直面することになります。ゼロトラストを実践する過程で、ほとんどのシナリオに対して緊急時のガラス破りメカニズム (Break-glass Mechanism) が提供されます。これにより、緊急時にオペレーターはゼロトラスト システムの制限を打ち破り、複雑な緊急操作を実行できるようになります。継続的にセキュリティを確保するため、緊急侵害メカニズムが呼び出されると、セキュリティ チームは直ちにアラームを受け取り、侵害メカニズムに基づくすべての操作もセキュリティ ログに詳細に記録されます。これらのセキュリティ ログは、侵害の必要性を検証するために精査されます。これらのセキュリティ ログは、同様の状況で緊急侵害メカニズムが再び呼び出されるのを避けるための新しいゼロトラスト機能の設計にも役立ちます。

内生リスクに注意する

防御の観点から見ると、内生リスクは外生リスクのスーパーセットです。攻撃者が内部関係者 (正当なユーザーまたは従業員) のデバイスを侵害すると、攻撃者は内部関係者になるため、外部の攻撃者であるか、内部の違反者であるか、内部の違反者であるかは関係ありません。違反者は、最終的には内生リスクとなります。この観点から、ゼロトラストでは、どのホストも侵害される可能性があると想定されています。

セキュリティインフラストラクチャ

ゼロ トラストの実装は、強固な基本的なセキュリティ アーキテクチャに依存しており、基盤がなければ上部構造は存在しません。 Google ゼロ トラストは、基本的なセキュリティを提供するために次のインフラストラクチャに依存しています。

1. データの暗号化と鍵管理 (暗号化と鍵管理)
2. ID とアクセスの管理
3. デジタル人材
4. デジタルデバイス管理
5. データセンターのセキュリティ
6. サイバーセキュリティ（ネットワークセキュリティー）
7. ホストのセキュリティ
8. コンテナの分離 (gVisor)
9. トラステッドブート
10. 検証可能なビルド
11. ソフトウェアの完全性の検証
12. 相互TLS (mTLS)
13. サービスアクセスポリシー
14. エンドユーザーコンテキストトークン
15. コードとしての構成
16. 標準の開発と展開

他の

上記の教訓に加えて、小さく始めて反復する、徹底した防御、セキュリティ投資収益の定量化（投資に対する収益の定量化）、標準化によるコスト削減（均一性によるコストの削減）、セキュリティ左派化なども原則です。私たちは実践の中で蓄積してきましたので、ここでは詳しく説明しません。

結論は

ゼロトラストを適切に実現するには、20% は理論に依存し、80% は実践に依存します。ゼロトラストの実際的なソリューションはユニークなものではありませんが、著者は上記のゼロトラスト実践例を共有することで、それが出発点として役立つことを望んでいます。皆さんの批判や修正を歓迎します！