コンプライアンス エンジニアリング - GCP における継続的コンプライアンスに関するケーススタディ

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

前回の記事では、本番環境への導入プロセスを一変させ、Google Cloud のワークロードに対応させるためのツールや手法を紹介しました。この記事では、GCP に用意されている技術的な統制手段の例と、お客様の組織が GCP におけるセキュリティ態勢とコンプライアンス態勢を維持するのにこれらの統制手段がどのように役立つかを説明します。

オンプレミス インフラストラクチャと比較して、GCP は高度に統合された環境であり、多種多様な統制が実施されていることを証明するための機能があらかじめ用意されています。以下の基本要素を使用することで、統制が実施されていることを効果的に証明できます。

• インベントリ管理 - 多くの場合、オンプレミス ワークロードには、企業の IT 環境にどのようなインフラストラクチャ コンポーネントが実際にデプロイされているかを把握するための検出ツールが実装されています。GCP では、明示的に宣言されていないコンポーネントが環境内に存在することはあり得ません。このリアルタイムで正確に管理されるインベントリが、以下のケーススタディにおいて継続的コンプライアンスを実現するための基礎となります。

• Infrastructure as Code - GCP におけるすべてのデプロイメントと構成は、（Terraform のように）機械で読み取り可能な指示として実装され、上位環境へと順次ステージングされる CI / CD パイプラインに組み込まれている必要があります。インフラストラクチャのリソースをプログラムで定義することで、デプロイが行われる前にセキュリティ態勢（誤って構成された Google Cloud Storage バケットが公共インターネットに公開されてしまわないか、など）を効率的に確認できます。

• Compliance as Code - ポリシーの実装についても同じことが言えます。ワークロードの全期間を通じて証拠収集とコンプライアンス確認を自動化するには、プログラムによる定義である「Compliance as Code」を使用する必要があります。Google Cloud のリスク・コンプライアンス管理のコード化ソリューションは、ベスト プラクティスに基づくこのようなプロセスの実装を支援します。

それでは、クラウド セキュリティ アライアンスの Cloud Controls Matrix（CSA CCM）からいくつかの統制手段を取り上げ、GCP がどのように統制を支援するのかを見ていきましょう。

ケーススタディ - 鍵のライフサイクル管理イベントを記録する

鍵のライフサイクル管理の記録に関する CSA CCM の具体的な統制手段を見てみましょう。

LOG-11 - トランザクションの記録とモニタリングまたは活動の記録 - 暗号鍵の使用に関する監査と報告を行えるよう、鍵のライフサイクル管理イベントを記録、モニタリングします。

Cloud Key Management Service（KMS）と Cloud Audit Logs を併用することで、鍵の作成や破棄など、Key オブジェクトに対するお客様の活動が記録されます。お客様は、ログの保持期間のほか、アクセス許可を定義できます。ログメッセージは以下のようになります。

図 1 - 鍵作成のロギング

これらの活動を積極的にモニタリングするには、オペレーション スイートで protoPayload.methodName="CreateCryptoKey" について、ログベースのカウンタ指標を作成する必要があります。このログベースの指標を使用すると、イベントごとにアラームを作成したり、特定のしきい値に達したときに通知をトリガーしたりできます。Cloud Monitoring は、インシデント通知のほか、検査用のグラフを表示します。

ケーススタディ - 変更前の状態の復元

従来の IT 環境では、多くの場合、本番環境への展開は、厳格なチェンジ マネジメント プロセスによって守られた環境で段階的に行われ、変更承認委員会の審査を受けます。クラウド環境でも、同様の確認を行う必要がありますが、エンドツーエンドではるかに迅速に確認できます。前述のとおり、本番環境では、人の介入を制限する必要があります。すべてのアプリケーションとインフラストラクチャのデプロイは、Infrastructure as Code パターンに従い、自動化技術を活用する必要があります。繰り返し可能な自動化パターンにより、運用が簡素化され、大規模なコンプライアンス検証を行えます。CSA CCM 統制セットのうち、以下の例を見てみよう。

CCC-09 変更管理および構成管理 - 変更前の状態の復元 - エラーやセキュリティ上の懸念が生じた場合に、変更前の既知の良好な状態にロールバックするプロセスを定義し、実装します。

インフラ構成の状態を Terraform で記述することで、各変更を簡単に展開およびロールバックでき、抜けが生じたり、不可逆的な変更が行われたりすることはありません。統制責任者としては、変更が自動化されており、既知の作業状態に完全に戻すことができるという安心感を持てます。

ベスト プラクティスとして、Infrastructure as Code パターンをアプリケーション プロジェクトのソースコードと一緒にバージョン管理システムに格納し、CI / CD パイプラインを活用して、環境を介してステージングすることをおすすめします。

ケーススタディ - ログの完全性を守る

Cloud Audit Logs やアクセスの透明性などの GCP の広範なロギング機能は、環境内で発生した活動を記録します。特に、規制対象の業界では、これらのログは、不変性と完全性を確保しながら長期間保管する必要があります。この要件は、以下の CSA CCM に反映されています。

 IAM-12 Identity & Access Management - ログの完全性を守る - ロギング インフラストラクチャが特権的アクセスロールなどの書き込みアクセス権を持つすべてのユーザーに対して読み取り専用となること、ならびに書き込みアクセス権を無効化する機能が、義務の分離を保証する手順およびブレークグラス手順を介して制御されることを保証するためのプロセス、手順、技術的対策を定義、実装、評価します。

GCP のログシンクを利用して、ログエントリを Google Cloud Storage など、サポートされているさまざまな宛先にエクスポートできます。ログエントリは、JSON ファイルとして GCS バケットに保存されます。GCS バケットは、バケット内のオブジェクトをどのくらいの期間保持すべきかを規定するデータ保持ポリシーをサポートしています。「バケットロック」機能により、構成を永久的かつ不可逆的なものにするデータ保持ポリシーを該当の GCS バケットで設定できます。  

バケットをロックし、ファイルを 2 日間保存する Terraform の例:

図 2 - バケットロックの仕組み

バケットロックは不可逆的な活動です。上記の例で説明したとおり、該当の GCS バケット内に保存されたファイルは、特権的アクセス権を持つロールを含めて、定義された期間保持されます。

図 3 - バケットロックの効果

FSI における変革

ドイツ銀行では、自動化が変革を加速させる重要な原動力となっています。

GCP の統合環境は、セキュリティ態勢とコンプライアンス態勢を確立し維持する際に統制責任者にかかる負担を大幅に軽減する基本機能（リアルタイム インベントリなど）を備えています。このケーススタディは、GCP のお客様が、リアルタイムの証明書と（構成に誤りがある場合に発生し得る事態などについての）通知を含む、継続的なコンプライアンスに移行する方法の例を示しています。統制責任者が GCP の機能に慣れれば慣れるほど、統制の自動化に信頼が持てるようになります。

今回紹介した統制の自動化の例を基に、次のステップとして、GKE Policy Controller 内のポリシーに統制機能を組み込み、GKE Config Connector で Cloud Operations Suite や Security Command Center にシームレスにログインすることが考えられます。このトピックの詳細については、最近リリースしたソリューション「コンプライアンスのモダナイズ: リスクとコンプライアンスの管理のコード化」の一部でご確認いただけます。

- テクニカル アカウント マネージャー Florian Graf

- テクニカル アカウント マネージャー Jo Hellwig