Zenn
🌊

Google Cloud 監査ログ取得・活用ガイド

2024/06/10に公開
Google Cloud
Security
Google Cloud
tech

こんにちは、SRE ディビジョン所属の松島です。
本記事では Google Cloud の主要機能の監査ログについて取得方法及び活用方法をまとめて紹介したいと思います。

監査ログとは？

監査ログは誰がいつどこで何をしたかを記録するものです。
セキュリティインシデントの発生時など、不審な行動を追う際の重要な情報源となります。
また、PCI DSS など、セキュリティコンプライアンスで収集や活用が規定されている場合もあります。

Cloud Audit Logs

Cloud Audit Logs は 監査ログを生成する Google Cloud サービスへのアクセスを記録する、Google Cloud における監査ログの中核機能です。
集めたログを Cloud Logging で検索、閲覧したり、Pub/Sub で外部連携したりすることができます。

Cloud Audit Logs は下記の4種類に分類されます。
詳細な説明は公式ドキュメントをご参照ください。

  • 管理アクティビティ監査ログ
  • データアクセス監査ログ
  • システム イベント監査ログ
  • ポリシー拒否監査ログ

これらのうち、データアクセス監査ログ以外は常にログの取得が行われます。
データアクセス監査ログについては、BigQuery を除きデフォルトでは有効化されていないため、追加の設定を行う必要があります。必要に応じて有効化を検討してください。（なお、BigQuery は無効化不可です）
手順はこちらで、全ての機能で有効にすることも、機能ごとに個別に有効にすることも可能です。

公式ドキュメントではベストプラクティスも紹介されています。こちらも併せて参考にしてください。

また、データアクセス監査ログとポリシー拒否監査ログについてはデフォルトでは30日しか Cloud Logging 上に保存されません。
長期保存が必要な場合は別途ログルーターを作成の上、長期保存が可能なログバケットなどへの保管を実装する必要がある点にご注意ください。

追加の設定が必要なプロダクト

続いて個別の追加の考慮が必要な主要機能を紹介します。

Cloud SQL / AlloyDB

Cloud SQL インスタンス及び AlloyDB クラスタ自体への Google API を経由した操作は Cloud Audit Logs の機能のみで監査ログを取得できますが、機微な情報を保持している場合など、中身の RDBMS に対する操作を監査したい場合は追加の設定が必要です。

例えば、Cloud SQL で MySQL を利用している場合、個々のテーブルへのアクセスなどを記録するには下記の手順を踏む必要があります。
（詳細は公式ドキュメントをご確認ください。）

  1. データアクセス監査ログを有効にする
  2. Cloud SQL インスタンスにフラグ cloudsql_mysql_audit=ON を設定し、cloudsql_mysql_audit プラグインを有効にする（既存インスタンスで有効化する場合は再起動が必要なことに注意）
  3. データベース監査ルールを構成する
    • ストアドプロシージャ mysql.cloudsql_reload_audit_rule を呼び出して監査したい操作を定義します
    • 特定のテーブル、ユーザー、接続元のみを記録対象にすることや、逆に除外することが可能です
    • 全ての操作を監査すると量が多くなりすぎるため、SELECT は本当に重要なテーブルのみ記録する、Cloud SQL を動かしているだけで出るログは除外する、など実装時はログの量が増えすぎないよう注意する必要があります
    • 例えば、下記の SQL では全てを対象にしつつ、特定のテーブルのみ記録を除外するルールを設定することができます
# 全ての操作を監査
CALL mysql.cloudsql_create_audit_rule('*','*','*','*','B',1,@outval,@outmsg);
# 特定のテーブルのみを除外
CALL mysql.cloudsql_create_audit_rule('*','db1','table1','*','E',1, @outval,@outmsg);

他の DBMS の場合も個別の設定が必要となるため、公式ドキュメントを参考に確認してみてください。
AlloyDB についてはこちらに有効化方法が記載されていますので、併せてご確認ください。

GKE の中の Kubernetes

通常、Kubernetes への操作の監査ログを取得するには、監査ルールを作成して kube-apiserver に読み込ませる必要がありますが、GKE の場合はプリセットのルールが設定済みの状態となっており、データアクセス監査ログを有効にするだけでログを取得することができます。

従ってデータアクセス監査ログを有効にする以外の設定を追加で行う必要はありません。
こちらのドキュメントで必要に応じて監査ポリシーを確認してください。

Google Workspace

Google Workspace の監査ログは Google Workspace 上で閲覧することが可能ですが、こちらに記載の通り保持期間が決められています。

これを超えて長期保存が必要な場合や、他のログと合わせて利用したい場合など、Google Workspace のログを Google Cloud に連携し、Cloud Logging で Workspace のログを扱うことができます。
詳細や手順については下記2つのドキュメントをご参照ください。

VPC 関連

監査ログとは少し異なりますが、VPC 上のトラフィックに関してもロギングを求められる場合があります。
例えば、ログをもとに脅威を検知する機能を利用する場合や、コンプライアンス規準で取得を定められている場合が該当します。

主に次の3つについて必要に応じて有効化を検討、実装してください。

これらのログは Cloud Logging ではデフォルトで 30 日保管となります。
長期保存が必要な場合は別途ログルーターを作成の上、長期保存が可能なログバケットなどへの保管を実装する必要がある点にご注意ください。

アプリケーション

GCE や Cloud Run、GKE 上などで動かすアプリケーションについて、それらに監査が必要な場合はあらかじめそれらの機能をアプリケーションに組み込んでおく必要があります。
準拠するセキュリティコンプライアンスをや社内規定を確認の上、実装をご検討ください。

また、基本的にはアプリケーションのCloud Logging での保持期間はデフォルトで 30 日となります。
長期保存が必要な場合は別途ログルーターを作成の上、長期保存が可能なログバケットなどへの保管を実装する必要がある点にご注意ください。

GCS

allUsers または allAuthenticatedUsers によるオブジェクトの取得を記録したい場合など、Cloud Audit Logs では記録できない操作を記録したい場合、GCS ではバケットの使用状況ログを利用することができます。
設定方法や詳しいユースケースについてはこちらをご参照ください。

ただし、公式ドキュメントでは利用は推奨されておらず、利用量を見たいだけであれば Monitoring 指標を利用することが推奨されています。
利用する場合は本当に必要か検討してからご利用ください。

監査ログ活用例

監査ログは集めて終わりではなく、監視を行い異常の検出に活用することが勧められます。
以下、Google Cloud 上の監査ログに対する監視方法をいくつか紹介します。

Event Threat Detection を利用する

Security Command Center (以下 SCC) Premium の機能である Event Threat Detection を利用すれば、本記事で紹介したようなログから異常な行動を検出することができ、監査ログの自動レビュー機能として活用することができます。
プリセットのルールが充実しており、簡単に活用を始められるのが良いところです。

一部データアクセス監査ログやネットワーク関連のログが必要なものが含まれていますので、こちらを参照の上、適宜データアクセス監査ログを併せて設定してください。

便利な機能ですのでぜひ活用を検討してみてください。

ログアラートを設定する

Cloud Logging / Monitoring には特定のログが発生した際に通知を行うログアラート機能があります。
おそらく最初からアラートで検出を自動化するのは難しいかと思いますので、個人的にはダッシュボードでレビューしているもののうち発生した場合の緊急度が高いものなどをアラートで実装することにより自動化していくような使い方が良いのではないかと思います。

Log Analytics で可視化する

Cloud Logging の機能の一つである Log Analytics を利用することで、ログを可視化することができます。
これを利用することで、1ヶ月間の特定操作の履歴などをグラフを用いてレビューすることが可能となります。

緊急度の高いものは Event Threat Detection とログアラートで対応しつつ、これらで対応できないものや緊急度の低いものは Log Analytics でダッシュボードを作成して定期的に確認する、のように利用することができます。
例えば、全ての IAM 変更を日ごとにグラフ化、内訳で操作者を表示するようにしておけばどの日に誰が IAM の設定変更をおこなったかを一目で確認することができます。これを定期的に確認すれば不審な IAM 設定操作がなかったかを確認できます。

log_analytics.png

Log Analytics の詳細や利用イメージについては別に記事を作成していますので、そちらも併せてご参照ください。

その他 SIEM などに連携して活用する

Cloud Logging からログルーターで Pub/Sub を経由させるなどの方法で SIEM など、セキュリティイベントの解析が可能な外部ツールに連携することができます。これにより、より高度な解析や脅威検出を行うことができます。

例えば、Google SecOps では強力なマネージドの検出ルール (Curated Detections)や、YARA-L というクエリ言語による高度なパターンの異常検出が利用できるため、より効率的にクラウド上の脅威検出を行うことができます。

おわりに

設定や活用が面倒な印象のある監査ログですが、正しく活用することでセキュリティインシデントの防止や早期発見につなげることができます。
本記事が Google Cloud 上の監査ログの収集と活用を見直すきっかけになれば幸いです。

Discussion