クラウドの構成ミスを回避し、継続的なコンプライアンスに移行する方法

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

セキュリティは、しばしば「高速化」か「安全性の確保」かのゼロサムゲームと見なされています。Google Cloud はこの考え方に疑問を投げかけ、このパラダイムを「高速化」と「安全性の確保」の両方を達成する「Win-Win ゲーム」に変更するフレームワークを紹介したいと思います。

これまで、アプリケーションのセキュリティのツールは、駐車場のゲートのように導入されてきました。駐車場には、境界ベースの出入口用遮断器が設置されています。遮断器は 1 台ずつしか通れないため、混雑時にはゲートでよく渋滞が発生します。しかし、中に入ってからの操作性はほとんどありません。どのレベルでもほぼすべてのスペースにアクセスでき、レベル間の移動も容易です。

このたとえをアプリケーション開発に当てはめてみましょう。アプリケーション セキュリティのツールは、ウォーターフォール ネイティブのワークフローにおける「通行手形」として実装されることが多くあります。開発者は順番を待ち、セキュリティ スキャンを受け、その結果を待つことになります。結果が出ると、デベロッパーは、セキュリティによって提起された危険信号を調査するために、多大な時間とエネルギーを費やすことになります。このプロセスは時間がかかるため、当然のことながら、開発者はあまり好みません。そのため、従来のセキュリティ プログラムはイノベーションの阻害要因とみなされることが多くあります。

ゲートではなくガードレール

Google Cloud は、駐車場のゲートのようなものではなく、高速道路のような常識的な安全対策を施したワークフローを提案します。高速道路には、すべての利用者のための指示規則があります。速度制限、進行方向の一方通行、退出時の速度低減義務ゾーンなどが高速道路の安全性に寄与しています。高速道路では、ルールに基づいて、対向車線を隔てる壁やガードレールなど、衝突事故や路外逸脱を未然に防ぐための対策が施されているところもあります。高速道路を走るには複雑な手続きが必要ですが、ブーム式のゲートで行く手を阻まれることはありません。

同じような指令のルールに従って、スピード探知機やカメラ、ドライバーに進行方向や速度を知らせる標識など、検知し、反応する制御があります。高速道路では、居眠りをしているドライバに車線を維持するよう促すためのランブル ストリップが設置されているところもあります。

高速道路の教訓をクラウド上のアプリケーション開発とコンプライアンスに適用することは、ソフトウェアをより安全に構築する良い機会となります。

最新のアプリケーションのセキュリティのツールについては、完全に自動化され、開発者からほとんど見えないようにし、DevOps パイプラインの摩擦を最小限に抑える必要があります。そのためには、これらのセキュリティ ツールは、開発者が望むように動作する必要があります。セキュリティ管理は、開発ライフサイクルの早い段階で、あらゆる場所に組み込まれる必要があります。これらのコントロールは、開発者が使用するツールの中で行われ、間違いをできるだけ早く修正できるよう、迅速なフィードバック ループを構築する必要があります。

一般的なコンプライアンス サイクルは次のようなものです。

ここでは、監査時に問題となる「望ましい状態」と「実際の状態」のギャップに焦点を当てます。そのため、監査全体の費用が増加し、コントロールの証拠を作成するために費やす時間が長くなってしまいます。

むしろ、このことが必要とされます。

望ましい状態を継続的に追跡するために、実際の状態が必要です。安全でないリソースが導入されるのを阻止するために、継続的な予防的コントロールが必要です。不適合なリソースを迅速かつ継続的に発見するための検出制御が必要です。不適合なリソースを自動的に修正するレスポンシブなコントロールが必要です。すべてにおいて、継続的なコンプライアンスが必要です。

インフラストラクチャの継続的コンプライアンス リファレンス アーキテクチャ

継続的なコンプライアンスはどのように実現できますか？この能力を開発するためのリファレンス アーキテクチャを紹介します。

このアーキテクチャは、指令制御、予防制御、検出制御、対応的制御の緊密なループを構築することを中心に据えています。また、オープンで拡張性があるのも特徴です。このブログでは Google Cloud のアーキテクチャを参照していますが、他のクラウド サービス プラットフォームやオンプレミスでも使用できます。

米国国立標準技術研究所の Open Security Controls Assessment Language（OSCAL）は、コントロール ライブラリを機械読み取りが可能な形式で表現するための有用なリソースです。OSCAL は、組織が一連のセキュリティ要件およびプライバシー要件を定義し、それを制御として表現し、制御カタログとしてグループ化できます。組織は、これらのカタログを使用して、複数のソースカタログからコントロールを集約し、調整するプロセスを通じて、セキュリティ管理およびプライバシー管理のベースラインを確立できます。OSCAL プロファイル モデルを用いてベースラインを表現することで、制御カタログとプロファイル間のマッピングが明示され、機械的に読みやすくなります。

指令制御

クローズドループの出発点は、指令制御と調和した制御です。次に、コンプライアンス要件に照らし合わせて、技術的なコントロールに合理化されたコントロール マッピングを用意する必要があります。これらの要件は、業界の脅威の状況、社内のセキュリティ ポリシーや規則、社外の規制遵守、業界のベスト プラクティスの枠組みなど、さまざまなソースから得ることができます。

コントロールのマッピングは、テクニカル コントロール ライブラリを形成します。このライブラリは、さまざまなコンプライアンス フレームワークで記述された要件に調和した制御をマッピングしたデータセットです。コントロール マッピングは、セキュリティ コントロールを正当化するものです。セキュリティとコンプライアンスの連携を構築し、コンプライアンス監査の費用削減を支援します。このデータセットは生きたドキュメントであるべきです。

このようなライブラリを構築するための簡単な第一歩は、CIS Google Cloud Platform 基礎ベンチマークから始めることです。このベンチマークは軽量で、Google Cloud で企業が正しく機能させる必要のある基礎的なセキュリティを構成しています。さらに、Security Command Center Premiumの Security Health Analytics は、組織内のすべてのプロジェクトにおいて、これらのベンチマークに対し、Google Cloud 環境を継続的にモニタリングできます。

テクニカル コントロール ライブラリは、残りのクローズド ループをガイドします。すべての指示的制御に対して、不適合なリソースのデプロイを阻止するための予防制御を用意する必要があります。不適合なリソースを探すために、環境全体を見渡すことができる検出制御を行う必要があります。そして、不適合なリソースを自動的に修復したり、セキュリティ運用機能でレスポンシブなワークフローを開始したりするレスポンシブな制御が必要です。最後に、すべてのポリシー評価ポイントには、エンジニアへのフィードバック ループがあるべきです。迅速で有意義なフィードバック ループは、より良いエンジニアリング エクスペリエンスを提供し、短期的には開発速度を向上させます。このようなフィードバック ループは、長期的にはより良い、より安全なコードを書くための良い行動を育むものとなります。

予防制御

Google Cloud のほぼすべてのアクションは、リソースの作成、構成、削除時など、API 呼び出しであるため、予防制御は API 呼び出しの制約がすべてです。これらの API 呼び出しには、Infrastructure-as-Code（IaC）ソリューションが含まれます。それには Terraform、Google Cloud Deployment Manager、Cloud コンソール インターフェース、Cloud Shell SDK、Python、GO SDK など、さまざまなラッパーがあります。

他のアプリケーション コードのデプロイと同様に、IaC ソリューションでは継続的インテグレーション（CI）ソリューションを使用する必要があります。CI 上では、アプリケーション コードの単体テストを書くのと同じように、IaC 制約をオーケストレートできます。すべての IaC ソリューションは JSON 形式で提供されているか、JSON 形式に変換できるため、IaC 制約ソリューションとして Open Policy Agent（OPA）を使用できます。OPA の Rego ポリシー言語は宣言的で柔軟性があり、Rego でほとんどすべてのポリシーを構築できます。

IaC ではない入力ソースについては、組織のポリシーと IAM にフォールバックできます。その理由として、この 2 つのコントロールは Google Cloud に最も近いことが挙げられます。とはいえ、本番環境に近い環境や本番環境など、より高い環境では IaC 以外の入力を制限することがベスト プラクティスとされています。そのため、ソース リポジトリでインフラストラクチャを成文化し、コントロールやワークフローを適用することも可能です。

検出制御と応答性制御

予防制御に励んで、クラウド環境が無菌状態になったとしても、検出制御と対応制御は必要です。その理由をご覧ください。

一つの理由は、すべての制御が、現実の世界で予防制御として安全に実施できるわけではないということです。たとえば、Google Compute Engine のデプロイが外部 IP アドレスを有している場合、特定のソフトウェアやユースケースで外部 IP アドレスが必要になることがあり、CI ですべてのデプロイが失敗しないということがあります。もう一つの理由は、監査用にタイムスタンプ付きのコンプライアンス状況を作成するというものです。CIS への対応を例にとると、CI ですべての CIS チェックを実施し、IaC をクラウド インフラストラクチャの唯一のデプロイ元として設定することも可能です。

ただし、Security Command Center を使用したランタイム CIS コンプライアンス レポートのデモは必要です。セキュリティ対応制御は、是正措置に限定されるものではありません。また、メールによる通知、メッセージング ツール、ITSM システムとの統合などの形態もあります。インフラストラクチャのデプロイに Terraform を使い、自動修復に Cloud Function を使う場合、Terraform の状態に気を配る必要があります。Cloud Function が行った自動修復アクションは Terraform のステート ファイルに記録されないため、エンジニアに Terraform のソースコードを更新するように伝える必要があります。

今後の計画

セキュリティとコンプライアンスに関する手動プロセスは拡張性がないため、次の実現策として自動化を挙げることができます。自動化の経済性により、規制遵守とクラウドのリスク管理に対する体系的な規律と全体的な企業規模のアプローチが必要とされています。

コンプライアンス プロセスのデータモデルを定義することで、前述の OSCAL は、リスク マネジメントと規制遵守における自動化のためのゲームチェンジャーとなり得ます。リスク・コンプライアンス管理のコード化（RCaC）において、「As Code」プラクティスを採用することは、ほとんどのお客様にとって長期的な投資であると認識しています。この投資を始めるまえには、いくつかのビルディング ブロックがあります。RCaC の原則を採用することで、クラウドを安全に移行するためのポリシーとインフラストラクチャを体系化できます。今後、Google Cloud のリスク・コンプライアンス管理のコード化にエキサイティングな新機能を導入していきますので、ご期待ください。