GoogleからBeyondProdというセキュリティの指針が発表されました。今までの境界を意識したセキュリティだけでは十分でなく、クラウドネイティブなアプリケーションを保護するための新たなアプローチとサポートツールやサービスが紹介されています。

ここ数年にわたり、Azure、AWS、GCPと各クラウドにおいてセキュリティを守る新しいサービスの提供や既存サービスの改善が行われてきています。今回提供されたBeyondProdにより指針が定義され、それぞれのサービスは何のために提供されているのかを考えるきっかけになります。

この記事では、BeyondProdのアプローチ、GCPでの実装方針やAzureのクラウドネイティブなセキュリティ機能をご紹介します。

BeyondProd:クラウドネイティブセキュリティにおける新しいアプローチ

BeyondProdでは、以下の6つのアプローチを定義しています。

1. エッジにおけるネットワークの保護

これにより、ワークロードはネットワーク攻撃やインターネットからの不正トラフィックから隔離されます。 境界ベースのアプローチはクラウドネイティブの新しい概念ではありませんが、セキュリティのベストプラクティスのままです。 クラウドネイティブの世界では、境界アプローチを使用して、不正トラフィックやインターネットからの潜在的な攻撃（ボリュームベースのサービス拒否攻撃など）から可能な限り多くのインフラストラクチャを保護します。

2. サービス間に固有の相互信頼関係を持たない

既知の信頼できる特別に許可された発信者のみがサービスを利用できます。 これにより、攻撃者が信頼できないコードを使用してサービスにアクセスするのを防ぎます。 サービスが侵害された場合、攻撃者がリーチを拡大できるアクションを実行できなくなります。 固有の信頼関係を持たないことにより、セキュリティ侵害が発生した場合の影響範囲を制限するのに役立ちます。

3. 出所が把握できているコードのみが実行される信頼されたマシン

サービスは、承認されたコードと設定のみを使用するように制限され、承認された検証済みの環境でのみ実行されます。

4. サービス全体で一貫したポリシーを適用するチョークポイント

ユーザーデータへのアクセスリクエストを検証するためのチョークポイントがこれにあたります。サービスのアクセスは承認されたエンドユーザーからの検証済みリクエストのみ受け付け、管理者のアクセスはビジネス上での承認が必要とする。

5. 単純で、自動化され、標準化された変更の適用

インフラストラクチャの変更がセキュリティに与える影響を簡単に確認できるようにし、セキュリティパッチを運用にほとんど影響を与えずに展開できるようにします。

6. 個々のワークロードの隔離

サービスが侵害されても、同じホストで実行されている別のワークロードのセキュリティに影響を与えることはできません。 これにより、潜在的な妥協点の影響範囲が制限されます。

また、PeyondProdで、適用される代表的な概念として以下が紹介されています。

・相互認証されたサービスエンドポイント
・トランスポートセキュリティ
・グローバルロードバランシングとサービス拒否ルールを備えたエッジによる通信の遮断
・エンドツーエンドのコード履歴
・ランタイム サンドボックス

BeyondProdの適用 GCPの場合

自分で構築した環境に、BeyondProdを取り込むために利用できるサービスが紹介されています。
・TSL終端制御や受信トラフィックのポリシー設定のための、Envoy or Traffic Director
・相互TLS認証、RPC認証、整合性、暗号化、サービスIDのためのIstio や GKE上のIstio
・コード検証のような、デプロイ時の強制チェックとして、kubernetes admission controllers、Kritis、OPA GatekeeperやBinary Authorization
・セキュアブートや整合性検証のための、Shielded GKE Nodes
・ワークロードの隔離のための、gVisor や GKE Sandbox
・Anthosのセキュリティモデル　詳細については、「Anthos：An Opunity to Modernize Application Security」を参照

Azureにおけるクラウドネイティブなセキュリティ機能

コンテナのセキュリティを担保するために、Azure Security Centerの機能アップがされています。
詳細はリンクをご確認ください。

Azure Security Center でのクラウド ネイティブ コンピューティングの脅威検出
https://docs.microsoft.com/ja-jp/azure/security-center/security-center-alerts-compute

Azure Security Center におけるアダプティブ アプリケーション制御
https://docs.microsoft.com/ja-jp/azure/security-center/security-center-adaptive-application

Azure Security Center でのアダプティブ ネットワークのセキュリティ強化機能
https://docs.microsoft.com/ja-jp/azure/security-center/security-center-adaptive-network-hardening

その他、セキュリティのドキュメント

Azureのセキュリティの概要
https://docs.microsoft.com/ja-jp/azure/security/fundamentals/overview

Azureのアーキテクチャーセンターのセキュリティフレームワーク
https://docs.microsoft.com/ja-jp/azure/architecture/framework/security/overview

Azureで運用可能なセキュリティのチェックリスト
https://docs.microsoft.com/ja-jp/azure/security/fundamentals/operational-checklist

まとめ

アプリケーションの作り方や動作する環境が変わることにより、守り方もどんどん変わっていきますね。公開されるサービスやソフトウェアだけを追っていると、全体としてどのように保護するのかが見通しにくくなります。こういった指針を見ながら振り返ることで、できていること、できていないことや新しい考え方などを得ることができ、日々の業務に生かしていきたいですね。

把握するために元記事をざっと訳をしています。

BeyondProd: どのようにGoogleは境界ベースセキュリティからクラウドネイティブセキュリティに移行したか

Googleでは、インフラはコンテナで稼働し、コンテナのオーケストレーターとしてkubernetesのベースとなったBorgを利用しています。Googleアーキテクチャは今日広くクラウドネイティブとして知られるアーキテクチャの源泉やベースになっています。マイクロサービスとコンテナを使用して、ワークロードをより小さく管理しやすい単位に分割して、サービスのメンテナンスと検出を可能にします。

Google クラウドネイティブアーキテクチャは、あらゆるアーキテクチャの進化の中でセキュリティを最優先にして開発されてきました。本日、BeyondProdに関するホワイトペーパーを紹介します。これは、Googleでクラウドネイティブセキュリティを実装するモデルを説明しています。多くの組織がクラウドネイティブのアーキテクチャを採用しようとしているため、Googleがこのアーキテクチャをどのように保護しているかについてセキュリティチームが学び、同様のセキュリティモデルを採用することでセキュリティの適用が簡素化できることを願っています。

BeyondProd:クラウドネイティブセキュリティにおける新しいアプローチ

セキュリティのアプローチは、伝統的な境界ベースのセキュリティモデルを拡張さてきました。このセキュリティモデルでは、壁で境界を保護することで内部のユーザやサービスを完全に信頼します。クラウドネイティブな環境においても、ネットワーク境界を保護する必要はありますが、それだけでは十分では無くなってきています。企業ネットワークをファイアウォールが完全に保護できないのと同じように、プロダクション環境のネットワークも完全には保護できません。

2014年に、GoogleはBeyondCorpを発表しました。これは企業ネットワークにユーザがアクセスするためのネットワークセキュリティモデルです。BeyondCorpはゼロトラスト原則を適用し、企業ネットワークへのアクセスを再定義しました。我々は、同じように、これらの原則をサーバ、ワークロード、サービスへどのようにアクセスするかに適用してきました。その結果が、BeyondProdです。

BeyondProdは、以下のセキュリティ原則に従うためにツール開発とサービスの最適化をすることで実現してきました。
・エッジにおけるネットワークの保護
・サービス間に固有の相互信頼関係を持たない
・出所のわかるコードのみが実行される信頼されたサーバ
・サービス全体で一貫したポリシーを適用するチョークポイント
　例えば、許可されたデータアクセスのみを確保する
・単純で、自動化され、標準化された変更の適用・個々のワークロードの隔離

PeyondProdは、相互認証されたサービスエンドポイント、トランスポートセキュリティ、グローバルロードバランシングとサービス拒否ルールを備えたエッジによる通信の遮断、エンドツーエンドのコード履歴、ランタイムサンドボックスなどの概念を適用しています。

結果として、これらの制御は、個々のマイクロサービス開発者が基盤となるインフラストラクチャのセキュリティのための詳細な実装の負担なく、コンテナとその内部で実行されるマイクロサービスをデプロイし、相互通信させ、安全にコンテナを配置して実行することができるようにしました。

BeyondProdの適用

Googleでは長年にわたり、これらのBeyondProdセキュリティ原則に従い、インフラストラクチャを保護するために、内部ツールとサービスを設計、開発してきました。クラウドネイティブセキュリティへの移行には、インフラストラクチャと開発プロセスを両方変更する必要がありました。私たちの目標は、開発と展開のライフサイクルのできるだけ早い段階でセキュリティの問題に対処することです。こうすることでセキュリティの問題に対するコストを最小化できます。また、標準化され一貫した方法で継続できることも必要でした。そのためには、個々の開発者がセキュリティの要求事項を担保するために負担がかからないように共通コンポーネントを開発することが重要でした。そうしたことで、セキュリティ機能は個々のアプリケーションへの統合をほとんど必要としないで済むようになりました。代わりにすべてのマイクロサービスを包み込み接続できるファブリックとして提供されます。最終的に開発者はセキュリティに費やす時間を短縮しながら、より安全な結果を達成できるようになりました。

BeyondProdの原則を自分の環境に適用しようとしている場合、Google Kubernetes Engine、Anthos、およびオープンソースを通じて、同様のアーキテクチャを実現するための活用できる多くのコンポーネントがあります。
・Envoy or Traffic Director、TSL終端制御や受信トラフィックのポリシー設定
・相互TLS認証、RPC認証、整合性、暗号化、サービスIDのためのIstio や GKE上のIstio
・コード検証のような、デプロイ時の強制チェックとして、kubernetes admission controllers、Kritis、OPA GatekeeperやBinary Authorization
・セキュアブートや整合性検証のための、Shielded GKE Nodes
・ワークロードの隔離のための、gVisor や GKE Sandbox
・Anthosのセキュリティモデル　詳細については、「Anthos：An Opunity to Modernize Application Security」を参照

BeyondCorpが境界ベースセキュリティモデルを超えた進化したのと同じように、BeyondProdはプロダクション環境のセキュリティへのアプローチにおいて同様の飛躍を実現します。BeyondProdモデルのセキュリティ原則を独自のクラウドネイティブインフラストラクチャに適用することにより、これらの経験からの知恵を得ることができます。そして、ワークロードの展開を強化し、通信がどのように保護され、他のワークロードにどのように影響するかを把握できるようになります。

BeyondProd、およびBeyondProdモデルで使用するコントロールの1つであるBorgのバイナリ認証について詳しくは、Googleセキュリティブログをご覧ください。