検出制御

Last reviewed 2023-12-20 UTC

脅威の検出とモニタリングの機能は、Security Command Center の組み込みのセキュリティ管理と、セキュリティ イベントの検出と対応を可能にするカスタム ソリューションを組み合わせて実現されます。

セキュリティと監査のための一元的なロギング

このブループリントでは、1 つのプロジェクトに集約されたログを使用して、Google Cloud リソースに対する変更を追跡し分析するロギング機能が構成されます。

次の図に、ブループリントが複数のプロジェクトにある複数のソースから一元化されたログシンクにログを集約する仕組みを示します。

example.com のロギング構造。

この図では以下のことが示されています。

  • ログシンクは組織ノードに構成され、リソース階層におけるすべてのプロジェクトのログを集約します。
  • フィルタに一致するログを別の保存先に送信して分析できるように、複数のログシンクが構成されています。
  • prj-c-logging プロジェクトには、ログの保存と分析のためのすべてのリソースが含まれています。
  • 必要に応じて、ログを SIEM にエクスポートするための追加ツールを構成できます。

このブループリントでは、さまざまなログソースを使用し、それらのログをログシンク フィルタで指定することで、ログを一元化した宛先にエクスポートできるようにしています。各ログソースの説明は次の表に示すとおりです。

ログソース

説明

管理アクティビティ監査ログ

管理アクティビティ監査ログを構成、無効化、除外することはできません。

システム イベント監査ログ

システム イベント監査ログを構成、無効化、除外することはできません。

ポリシー拒否監査ログ

ポリシー拒否監査ログを構成、無効化することはできませんが、除外フィルタを使用して必要に応じて除外できます。

データアクセス監査ログ

データアクセス ログの量と費用が大きくなる可能性があるため、デフォルトでは、ブループリントでデータアクセス ログは有効化されていません。

データアクセス ログを有効にする必要があるかどうかを判断するには、ワークロードで機密データを扱う場所を評価し、センシティブ データを使用するそれぞれのサービスと環境にデータアクセス ログを有効にする要件があるかどうかを検討します。

VPC フローログ

このブループリントでは、すべてのサブネットで VPC フローログを有効にします。また、費用を削減するために、ログの 50% をサンプリングするようにログのサンプリングを構成します。

追加のサブネットを作成する場合は、サブネットごとに VPC フローログを有効にする必要があります。

ファイアウォール ルール ロギング

このブループリントでは、すべてのファイアウォール ポリシー ルールでファイアウォール ルールのロギングを有効にします。

ワークロード用に追加のファイアウォール ポリシー ルールを作成する場合は、新しいルールごとにファイアウォール ルールのロギングを有効にする必要があります。

Cloud DNS ロギング

このブループリントでは、マネージド ゾーンの Cloud DNS ログを有効にします。

追加のマネージド ゾーンを作成する場合は、それらの DNS ログを有効にする必要があります。

Google Workspace の監査ログ

このブループリントでは自動化されない 1 回限りの有効化ステップを行う必要があります。詳細については、Google Cloud サービスとデータを共有するをご覧ください。

アクセスの透明性ログ

このブループリントでは自動化されない 1 回限りの有効化ステップを行う必要があります。詳細については、アクセスの透明性を有効にするをご覧ください。

次の表に、ログシンクと、ブループリントのサポートされる宛先でのログシンクの使用方法を示します。

シンク

宛先

目的

sk-c-logging-la

ログは Cloud Logging バケットに転送されるログ分析とリンクされた BigQuery データセットを有効にする)

ログを積極的に分析する。コンソールのログ エクスプローラを使用してアドホック調査を実行することや、リンク済み BigQuery データセットを使用して SQL クエリ、レポート、ビューを作成することが可能です。

sk-c-logging-bkt

ログは Cloud Storage に転送される

コンプライアンス、監査、インシデント追跡を目的としてログを長期保存する。

必要に応じて、データ保持を義務付けるコンプライアンス要件がある場合は、バケットロックを別途構成することをおすすめします。

sk-c-logging-pub

ログは Pub/Sub に転送される

ログを外部プラットフォーム(既存の SIEM など)にエクスポートする。

このためには、次のような仕組みなど、SIEM と統合するための追加の作業が必要です。

追加のログタイプの有効化とログシンク フィルタの作成に関するガイダンスについては、ログスコープ ツールをご覧ください。

Security Command Center による脅威のモニタリング

組織を対象に Security Command Center Premium を有効にして、Google Cloud リソースの脅威、脆弱性、構成ミスを自動的に検出することをおすすめします。Security Command Center は、次のような複数のソースからセキュリティに関する検出結果を作成します。

  • Security Health Analytics: Google Cloud リソース全体で一般的な脆弱性と構成ミスを検出します。
  • 攻撃パスの発生可能性: Security Command Center の他のソースによって検出された脆弱性や構成ミスに基づいて、攻撃者がどのように高価値リソースを悪用するかをシミュレートしたパスを示します。
  • Event Threat Detection: 検出ロジックと独自の脅威インテリジェンスをログに適用し、ほぼリアルタイムで脅威を特定します。
  • Container Threat Detection: 一般的なコンテナ ランタイム攻撃を検出します。
  • Virtual Machine Threat Detection: 仮想マシンで実行中の悪意を持っている可能性があるアプリケーションを検出します。
  • Web Security Scanner: Compute Engine、App Engine、Google Kubernetes Engine 上のウェブ公開アプリケーションで OWASP トップ 10 の脆弱性をスキャンします。

Security Command Center が対処する脆弱性と脅威の詳細については、Security Command Center のソースをご覧ください。

Security Command Center は、ブループリントをデプロイした後に有効にする必要があります。手順については、組織で Security Command Center を有効にするをご覧ください。

Security Command Center を有効にした後は、脅威の優先順位づけや対応を行うために、Security Command Center によって生成された検出結果を既存のツールやプロセスにエクスポートすることをおすすめします。ブループリントでは、このインテグレーションに使用する Pub/Sub トピックを含む prj-c-scc プロジェクトを作成します。検出結果は、既存のツールに応じて、次のいずれかの方法でエクスポートします。

ログベースの指標とパフォーマンス指標に関するアラート

基盤上でワークロードのデプロイを開始したら、Cloud Monitoring を使用してパフォーマンス指標を測定することをおすすめします。

このブループリントでは、環境ごとに prj-p-monitoring などのモニタリング プロジェクトが作成されます。このプロジェクトは、複数のプロジェクトにわたって集約されたパフォーマンス指標を収集するスコーピング プロジェクトとして構成されます。このブループリントでは、ログベースの指標と、Cloud Storage バケットに適用される IAM ポリシーに変更があった場合にメール通知を生成するアラート ポリシーを備えた例がデプロイされます。これにより、Terraform の状態を含む prj-b-seed プロジェクトのバケットなど、機密性の高いリソースに対する不審なアクティビティをモニタリングできます。

より一般的には、Cloud Monitoring を使用してワークロード アプリケーションのパフォーマンス指標と健全性を測定することもできます。組織内のアプリケーションのサポートとモニタリングの運用責任に応じて、チームごとに、より詳細なモニタリング プロジェクトを作成できます。こうしたモニタリング プロジェクトを使用してパフォーマンス指標を表示し、アプリケーションの状態を示すダッシュボードを作成して、期待される SLO が満たされていない場合にアラートをトリガーします。

次の図に、Cloud Monitoring がパフォーマンス指標を集計する仕組みの概要を示します。

パフォーマンスのモニタリング。

ワークロードの信頼性と可用性を効果的にモニタリングする方法については、サイト信頼性エンジニアリングの書籍(特に Google による分散システムのモニタリングに関する章)をご覧ください。

自動ログ分析のカスタム ソリューション

たとえば、ログに対するカスタムクエリに基づいて、セキュリティ イベントのアラートを作成するという要件があるとします。このような場合、カスタムクエリを使用することで、Google Cloud 上のログを分析し、調査に値するイベントのみをエクスポートすることで、SIEM の機能を補うことができます(特に、すべてのクラウドログを SIEM にエクスポートする容量がない場合)。

このブループリントは、リンクされた BigQuery データセットを使用してクエリできるログの一元化されたソースを設定することで、このようなログ分析を可能にします。この機能を自動化するには、bq-log-alerting のコードサンプルを実装して基盤の機能を拡張する必要があります。このサンプルコードを使用すると、ログソースを定期的にクエリして、カスタムの検出結果を Security Command Center に送信できます。

次の図に自動ログ分析のフローの概略を示します。

自動ロギング分析。

この図では、自動ログ分析の以下のコンセプトが示されています。

  • さまざまなソースから生成されたログは、ログ分析およびリンクされた BigQuery データセットを使用して、一元化されたログバケットに集約されます。
  • BigQuery ビューは、モニタリングするセキュリティ イベントのログをクエリするように構成されます。
  • Cloud Scheduler は、15 分ごとにイベントを Pub/Sub トピックに push し、Cloud Functions をトリガーします。
  • Cloud Functions は、ビューの新しいイベントのクエリを実行します。イベントを見つけると、カスタム検出結果として Security Command Center に push します。
  • Security Command Center は、新しい検出結果に関する通知を別の Pub/Sub トピックにパブリッシュします。
  • SIEM などの外部ツールは、Pub/Sub トピックをサブスクライブして新しい検出結果を取り込みます。

サンプルには、疑わしいと思われる動作をクエリするためのユースケースが複数あります。たとえば、指定した特権管理者や他の高い権限を持つアカウントのリストからのログイン、ロギング設定の変更、ネットワーク ルートの変更などです。ユースケースは、要件に合わせて新しいクエリビューを作成することで拡張できます。独自のクエリを作成するか、Google Cloud ログの分析に役立つ SQL クエリのライブラリのセキュリティ ログ分析を参照してください。

アセットの変更に対応するカスタム ソリューション

リアルタイムでイベントに応答するには、Cloud Asset Inventory を使用してアセットの変更をモニタリングすることをおすすめします。このカスタム ソリューションでは、リソースの変更に関する Pub/Sub への通知をリアルタイムでトリガーするようにアセット フィードが構成されます。その後、Cloud Functions によってカスタムコードが実行され、変更を許可すべきかどうか基づいてユーザー独自のビジネス ロジックが適用されます。

ブループリントには、このカスタム ガバナンス ソリューションの例が含まれており、組織管理者、オーナー、編集者など、機密性の高いロールを追加する IAM の変更をモニタリングします。このソリューションを図で表すと、次のようになります。

IAM ポリシーの変更の自動復元と通知の送信

上記の図では、以下のコンセプトが示されています。

  • 許可ポリシーが変更されます。
  • Cloud Asset Inventory フィードが、許可ポリシーの変更に関するリアルタイムの通知を Pub/Sub に送信します。
  • Pub/Sub が関数をトリガーします。
  • Cloud Functions が、カスタムコードを実行してポリシーを適用します。サンプル関数には、変更によって組織管理者、オーナー、編集者のロールが許可ポリシーに追加されたかどうかを評価するロジックがあります。変更によって追加された場合、関数はカスタム セキュリティの検出結果を作成し、Security Command Center に送信します。
  • 必要に応じて、このモデルを使用して修復作業を自動化できます。Cloud Functions で追加のビジネス ロジックを作成すると、許可ポリシーを以前の状態に戻すことなど、検出結果に応じて自動的にアクションが実行されます。

さらに、このサンプル ソリューションで使用されているインフラストラクチャとロジックを拡張して、ビジネスにとって重要な他のイベントに対するカスタム レスポンスを追加することもできます。

次のステップ

  • 予防制御(このシリーズの次のドキュメント)を確認する。