はじめに
本記事はGoogle Cloudのログ管理サービスであるCloud Loggingについて記載しています。
クラウド環境におけるログ管理は、多くの利便性をもたらしますが、従量課金という切っては離せない課題が存在します。
本記事ではGoogle Cloudで取り扱う監査ログの運用を行うにあたり、サービスの使いどころやAWSと比較した際のポイントなどについてまとめています。
Google Cloudの監査ログは、AWSと比較した際にコストに影響を与える要因が多いため、適切な管理が求められます。
Cloud Logging
Cloud Loggingは、AWSのAmazon CloudWatch Logsに相当します。
基本的にGoogle CloudやAWSで管理するクラウドが出力するログは、JSON形式など構造化されたログを取り扱います。
従ってオンプレミスの環境と比べた場合、マネージドサービスなどを活用することで、収集したログに対する分析も容易です。
ログ分析系のサービスについては、2023年にGoogle Cloud及びAWSでそれぞれ新しいサービスがリリースされています。
Google CloudのLog Analyticsは、ログバケットに保存されたログに対してSQLクエリが実行できます。
Cloud Loggingが出力するログ
Cloud Loggingが出力するログは、公式ドキュメントの使用可能なログの通りに以下の種類に分類できます。
また、セキュリティ ログは監査ログと、アクセスの透明性ログの2種類になります。
更に監査ログはCloud Audit Logsと呼ばれ以下の種類に分類されます。
Cloud Audit Logsは、AWSのAWS CloudTrailに相当します。
ログバケット
Cloud Loggingの運用を適切に行うためには、Cloud Loggingが出力するログの仕組みにについて理解することが重要です。
公式ドキュメントの転送とストレージの概要からCloud Logging がログエントリを処理する方法が確認できます。
上記図を踏まえて、セキュリティ ログは以下のログバケットに保存されます。
| ログバケット | 監査ログ | 保持期間 | 料金 | カスタム |
|---|---|---|---|---|
| _Default | データアクセス監査ログ/ポリシー拒否監査ログ | 30日間 | 30日を超えるログは追加料金が発生 | 構成可能 |
| _Required | 管理アクティビティ監査ログ/システム イベント監査ログ/アクセスの透明性ログ | 400日間 | 発生しない | 構成不可 |
データアクセス監査ログは、デフォルトでBigQueryのみ有効です。
その他のサービスで監査ログを有効にする場合は、データアクセス監査ログの構成の設定が必要です。詳細は公式ドキュメントのデータアクセス監査ログを有効にするをご参照ください。
AWSに例えると、CloudTrailのデータイベントの機能に相当します。
料金
Cloud Loggingの料金は、公式サイトのCloud Loggingから確認できます。
Cloud Billingの料金明細上では、以下のSKUとして整理されます。
SKU IDは公式ドキュメントのSKU Groups - Cloud Loggingをご参照ください。
- Log Storage cost
- ログストレージに取り込んだログの合計量に対して、GiBあたり$0.50の金額が課金される
- プロジェクトごとに最初の50GiBは無料枠が適用される
- Log Retention cost
- 2023年4月1日以降から、30日を超えて保持されたログに対して、GiBあたり$0.01の金額が課金される
適切にCloud Loggingのコストを管理するためには、Log Storage costで取り込むべきログのみを保持する運用が重要です。
コスト最適化
監査ログに関する観点でコスト最適化のアプローチを以下に記載します。
データアクセス監査ログ
データアクセス監査ログについて、使用していない場合は設定を見直しましょう。
例えば、フォルダにログルーターのシンクを設定して、監査ログを集約している状況だとします。
フォルダ配下のプロジェクト側で、データアクセス監査ログに対する設定を個別に行っている場合、自ずとフォルダ側で設定している監査ログも同じログが出力されるため、コストに対する影響が発生します。
通常、データアクセス監査ログはデフォルトでBigQueryに関するログしか出力されません。
以下のように監査ログの設定を確認すると、全て-になっていて無効化されていることが確認できます。
Cloud Storageを例にすると、以下のように青色でチェックが入っている場合は、データアクセス監査ログに対する設定が有効になっています。
フォルダにログルーターのシンクを設定している状況で、集約した監査ログからBigQuery以外のログが出力されている場合は、プロジェクト側で有効になっている可能性があります。
必要なログのみを抽出する
データアクセス監査ログと管理アクティビティ監査ログは、出力されるログが多いため、集約する際は注意が必要です。
コスト増加対策として、公式ドキュメントのフィルタの例を参考にしながら、不要なログは除外しましょう。
例えば以下のような除外設定を行うことで、デフォルトで出力されるBigQueryに関連するすべてのログを除外できます。
resource.type=("bigquery_dataset" OR "bigquery_project" OR "bigquery_job" OR "bigquery_job_config" OR "bigquery_table" OR "bigquery_table_data" OR "bigquery_view" OR "dataflow_step" OR "bigquery_dts_config" OR "bigquery_resource") AND logName:"cloudaudit.googleapis.com%2Fdata_access"
圧縮して保存する
監査ログの観点ですが、監査ログをCloud Storageで保存する場合の話です。
以前「Cloud RunとCloud Storage FUSE コンテナからFUSEを介してCloud Storage（GCS）のオブジェクトを圧縮する方法」の記事でも書きましたが、AWSの場合はCloudTrailによって生成されるログのサフィックスは.json.gzとなっているので、自動的に圧縮されていることが分かります。
しかし、Google Cloudの監査ログは、.jsonのまま保存されているため、圧縮されていません。
従って圧縮することでコストの削減が可能です。詳細は上記記事をご参照ください。
監査ログの分析
Cloud Loggingの仕様を踏まえて、監査ログの分析方法について記載します。
AWSのCloudTrailと比較すると、Cloud Loggingの場合はGoogleの検索機能がユーザーライクに使えるのが特徴だと思います。
ログ エクスプローラ
Cloud Loggingで管理するログは、ログ エクスプローラから確認できます。
ログの見方やどのように検索できるかなどは、公式ドキュメントのログ エクスプローラを使用してログを表示するをご参照ください。
ログのフォーマットについては、公式ドキュメントのLogEntryから確認できます。
すべての監査ログを表示するには、次のいずれかのクエリをクエリエディタフィールドに入力し、「クエリを実行」をクリックします。
logName:"cloudaudit.googleapis.com"
protoPayload."@type"="type.googleapis.com/google.cloud.audit.AuditLog"
リソース識別子の変数を含む監査ログ名は次のとおりです。
projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity
projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access
projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fsystem_event
projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fpolicy
folders/FOLDER_ID/logs/cloudaudit.googleapis.com%2Factivity
folders/FOLDER_ID/logs/cloudaudit.googleapis.com%2Fdata_access
folders/FOLDER_ID/logs/cloudaudit.googleapis.com%2Fsystem_event
folders/FOLDER_ID/logs/cloudaudit.googleapis.com%2Fpolicy
billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com%2Factivity
billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com%2Fdata_access
billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com%2Fsystem_event
billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com%2Fpolicy
organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity
organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access
organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fsystem_event
organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fpolicy
特定のリソースと監査ログタイプの監査ログを表示するには、クエリビルダペインから「ログ名」を選択して表示することもできます。
LogEntryのinsertIdは、ログエントリの一意の識別子です。
サポートケースで問い合わせを行う際にも、どのログで発生したかなど情報を共有する際にも使用されます。
BigQuery
BigQueryから監査ログの分析を行う場合は工夫が必要です。
本記事執筆時点の監査ログのフォーマット形式で、そのままBigQueryにインポートする場合、以下のようなエラーが出力されます。
- 全ての監査ログのキーで、
@typeというキーが存在するため、テーブル作成時にInvalid field name "@type". Fields must contain only letters, numbers, and underscores, start with a letter or underscore, and be at most 300 characters long.のエラーが発生 - 管理アクティビティ監査ログと、データアクセス監査ログについて、
Unsupported empty struct type for field 'protoPayload.status'のエラーが発生して、スキーマを作成することができない
この件については、以前からIssue TrackerのFeature request: Exporting Older Logsに起票されていて現在も課題になっています。
そのため、BigQueryにインポートしたい場合は、列の命名規則に適合しないJson要素を回避する必要があります。
特に、データアクセス監査ログが構造上ネストを繰り返しているため、取り扱いが厄介なため、手間がかかります。
Metrics Explorer
毎月どのプロジェクトのログが多く出力しているかについて気になる場合は、Cloud MonitoringのMetrics Explorerから以下のような手順で確認できます。
- Metrics Explorerを開く。
- 画面上部のリンクマークの右横にある「期間」を設定する。
- 画面中央の「指標」から
Log bucket monthly bytes ingestedを選択する。 - フィルタ設定は全て削除する。
- グループ条件について「ラベル」は
log_sourceを選択して「グループ化関数」については合計を選択する。 - 画面右上部「ウィジェットタイプ」から
Stacked Bar Chartを選択する。
対象期間を考慮して正確な数字を確認したい場合、log ingestion bytesのメトリクスは、JST(日本標準時)ではなくPST/PDT(Pacific Time)に基づいているため、任意の値が含まれるように期間を調整する必要があります。
おわりに
Cloud Audit Logsは、構造的なログになっているので情報量が多く、利便性があると思います。
しかし、AWSと比べるとデフォルトでデータアクセス監査ログが一部有効になっているため、コスト的には安くはない仕組みになっているように感じました。
ログを出力するということは大事なことですが、クラウドを利用する際は、蛇口の水は回しっぱなしにしないように注意が必要です。