こんにちは、上野です。
前回に引き続き、Google Cloudのセキュリティ設定第２弾です。今回は監査ログ（Cloud Audit Logs）です。
監査ログは「誰が、いつ、どこで、何をしたか」を残すログで、AWSだとCloudTrailですね。目的はAWSと同じなのですが、設定方法や見え方がけっこう異なるので、概要を掴みつつ追加の保存設定を見ていきます。
Google Cloudの監査ログ
監査ログには、管理アクティビティ監査ログ、データアクセス監査ログ、システムイベント監査ログ、ポリシー拒否監査ログの4種類存在します。
管理アクティビティ監査ログ
ユーザーが VM インスタンスを作成したときや IAM権限を変更したときに記録されるログで、いわゆる一般的な監査ログです。デフォルト有効で、無効にできません。
データアクセス監査ログ
BigQueryやCloud Storageなど、データを含むリソースへのアクセスログです。BiqQuery以外はデフォルト無効になっています。
システムイベント監査ログ
Google Cloudによるシステムイベントのログです。利用者の操作に関係なくシステム上のイベントが記録されます。デフォルト有効で、無効にできません。
ポリシー拒否監査ログ
ユーザーまたはサービス アカウントがVPC Service Controlsによって、アクセス拒否された場合に記録されるログです。デフォルト有効で、無効にできません。ただし、除外フィルタによって一部のログを除外することができます。
4種類を表にまとめます。
| 監査ログの種類 | 概要 | デフォルト状態 | デフォルト 保持期間 |
料金 |
|---|---|---|---|---|
| 管理アクティビティ監査ログ | VMやネットワーク、IAMの変更操作内容 | 有効（無効不可） | 400日 （変更不可） |
無料 |
| データアクセス監査ログ | BigQueryやCloud Storageのデータアクセス | BigQueryのみ有効 | 30日 | 一定量超えると有料 |
| システムイベント監査ログ | Google Cloudのシステムイベント | 有効（無効不可） | 400日 （変更不可） |
無料 |
| ポリシー拒否監査ログ | VPC Service Controlsによって拒否されたアクセス | 有効（無効不可、除外可能） | 30日 | 一定量超えると有料 |
デフォルトの状態でも、管理系の操作は400日間、BigQueryへのデータアクセス、ポリシー拒否監査ログが30日間確認可能です。保存期間を延ばしたい、BigQuery以外のデータアクセスログも見たい場合は追加の設定が必要となります。
監査ログの確認方法
監査ログはロギングのログ エクスプローラ画面から確認できます。
ロギングには監査ログ以外のログも流れ込んでくるので、ログ名でCLOUD AUDITを選択してフィルタします。
BigQueryのAPIがたくさん呼ばれていることがわかります。「>」マークをクリックすると各ログの詳細が確認でき、実行されたAPIや実行者（サービスアカウント等）が表示されます。
データアクセスログの追加設定
ここからは監査ログでおススメな追加設定を見ていきます。
1つ目はデータアクセスログの追加です。今回はGoogle Cloud Storageのログを追加設定します。 設定は監査ログのページからできます。
（監査ログを見るページではないです）
データアクセスログには「管理読み取り」「管理書き込み」「データ読み取り」「データ書き込み」の4種類あり、管理書き込みのみ最初から有効になっています。残りの3つを追加します。画面上部でプロジェクトではなく組織を選んでおくと、組織配下のプロジェクトが一括設定されます。
データアクセスが大量にあるプロジェクトでは、この追加設定で料金も大幅に追加になる可能性があるため、注意が必要です。Google側がデフォルト無効なのも、この料金が理由かと思います。
※組織について補足
組織は、複数のプロジェクトをまとめて管理できる機能で、次のような構造になっています。Google Workspace アカウントまたは Cloud Identity アカウントの準備が必要です。組織は配下でプロジェクトをグループ化するフォルダという機能もあります。
※図はドキュメントより引用
AWSでいうと組織＝Organizations、フォルダ＝OU、プロジェクト＝AWSアカウントという感じですね。
データアクセスログの設定も、組織、フォルダ、プロジェクトそれぞれの単位で設定が可能で、上位の設定が優先されます。
保存期間の変更
管理アクティビティ、システムイベントの400日間は変更できません。データアクセスとポリシー拒否はログストレージのバケット編集から可能です。
ただし、この設定は監査ログ以外にも関わるロギングの設定のため、監査ログ以外のログも影響を受けます。
管理アクティビティを含め、ログの永続化や保持期間を変更する場合は次に紹介するシンク機能がおススメです。
シンクを使用したログのエクスポート（プロジェクト単体）
ログルーターおよびシンクというロギングの機能を使用して、BigQueryやGCSバケットにログをエクスポートできます。 今回はBiqQueryに転送する設定を見ていきます。この設定はプロジェクトごとに行うやりかたです。組織全体で行う場合は後術する集約シンクを行います。
※BiqQuery分の料金が別途発生します。
まず、転送先のBigQueryデータセットを用意しておきます。
続いてロギングのメニューからシンクを作成していきます。
任意のシンク名を入力し、宛先に作成したデータセットを指定します。
含めるログで監査ログすべてを指定するlogName:"cloudaudit.googleapis.com"を指定します。
除外設定は特に行わずシンクを作成します。
これで完了です。何かしらの操作をしてしばらく経つと、データセット上に監査ログが格納されたテーブルが作成されます。
集約シンクを使用した組織全体のログエクスポート
組織配下すべてのプロジェクトからログを集約するため、集約シンクを設定してみます。
先ほどとは別の転送先データセットを作成しておきます。
公式ドキュメントによると、集約シンクはAPIまたはコマンドラインで作成せよとのことなので、コマンドライン（gcloud）で作成します。
※プロジェクトIDと組織IDは環境に合わせて変更が必要です
gcloud logging sinks create audit_log_sink_organization \ bigquery.googleapis.com/projects/[プロジェクトID]/datasets/audit_log_sink_organizations --include-children \ --organization=[組織ID] --log-filter="logName:cloudaudit.googleapis.com"
コマンドが成功すると、以下のように結果が返ってきます。
Created [https://logging.googleapis.com/v2/organizations/[組織ID] /sinks/audit_log_sink_organization]. Please remember to grant `serviceAccount:oXXXXXXXXXXX-XXXXXX@gcp-sa-logging.iam.gserviceaccount.com` the BigQuery Data Editor role on the dataset. More information about sinks can be found at https://cloud.google.com/logging/docs/export/configure_export
GCP側でサービスアカウントのロールが作成されたので、そこからデータセットに書き込めるよう設定してくださいとのことです。 IAM側ではなく、データセット側で許可を行います。
ここで作成されるサービスアカウントは、Google側で管理されるもので、利用者は見えないようです。コチラを参考
シンクを作成すると、Logging によって一意の書き込み ID と呼ばれるシンクのサービス アカウントが新規に作成されます。このサービス アカウントは Cloud Logging によって所有、管理されているため、直接管理できません。シンクが削除されると、このサービス アカウントは削除されます。
データセットの権限変更を行い、作成されたサービスアカウントへBigQuery データ編集者ロールを付与します。
権限付与後、しばらくすると集約シンクのデータセットのにもテーブルが追加されます。
設定はここまでです。
操作内容を見てみる
せっかくなので何か操作をしてログを残してみます。
gsutilを使用して、GCSバケットを作成してデータを操作し、データアクセスログを見てみます。
テキストファイルのアップロードとダウンロードを行っています。
#バケット作成 $ gsutil mb gs://ueno-audit-bucket-20210819 Creating gs://ueno-audit-bucket-20210819/... # テキストファイル作成してアップロード $ echo 'this is audit test' > object.txt $ gsutil cp object.txt gs://ueno-audit-bucket-20210819/ Copying file://object.txt [Content-Type=text/plain]... / [1 files][ 19.0 B/ 19.0 B] # ダウンロード $ gsutil cp gs://ueno-audit-bucket-20210819/object.txt ./download-object.txt Copying gs://ueno-audit-bucket-20210819/object.txt... / [1 files][ 19.0 B/ 19.0 B] Operation completed over 1 objects/19.0 B. $ cat download-object.txt this is audit test
操作後にデータセットに対してクエリを発行してみます。見やすいよう項目は絞り、バケット名をWHERE句で指定しています。
SELECT resource.type, resource.labels.bucket_name, protopayload_auditlog.methodName, protopayload_auditlog.resourceName, protopayload_auditlog.authenticationInfo.principalEmail FROM `[プロジェクトID].audit_log_sink_organization.cloudaudit_googleapis_com_data_access_20210819` WHERE resource.labels.bucket_name = 'ueno-audit-bucket-20210819'
以下のように結果が表示され、誰が、どのオブジェクトに、どんな操作（create、get）をしたのかわかるようになっています。
今回はシンプルなクエリですが、書き方次第で複雑な情報の確認や分析もできそうですね。
検証以上となります。
まとめ
クラウド利用で大事な監査ログについて、自分の学習もかねてまとめてみました。
AWSのCloudTrailは色々と使用しているのですが、仕組みや設定方法はGoogle Cloudとけっこう異なるなぁという印象です。
Google CloudはとりあえずBigQueryに入れておけばあとで色々分析できる。という印象があってここは嬉しいポイントだと思っています。
追加設定もいくつか書きましたが、追加料金もかかるので、ログ要件、利用料金（ログ容量）をふまえ設定も検討しましょう。 それではまた！
