このドキュメントでは、組織がセキュリティを維持してリスクを最小限に抑えるために、一連の監査ロギングタスクを推奨しています。
このドキュメントは、すべての推奨事項を説明するものではありません。その目的は、監査ロギング アクティビティの範囲を理解し、それに応じて計画を立てることです。
各セクションには、主要な作業の説明と参考情報のリンクが記載されています。
Cloud Audit Logs について
監査ログは、ほとんどの Google Cloud サービスで利用可能です。 Cloud Audit Logs では、Google Cloud のプロジェクト、フォルダ、組織ごとに次のタイプの監査ログが提供されます。
| 監査ログのタイプ | 構成可能 | 課金対象のログ |
|---|---|---|
| 管理アクティビティ監査ログ | いいえ。常に書き込まれます | いいえ |
| データアクセス監査ログ | はい | はい |
| ポリシー拒否監査ログ | はい。これらのログがログバケットに書き込まれないように除外できます。 | はい |
| システム イベント監査ログ | いいえ。常に書き込まれます | いいえ |
データアクセス監査ログ（BigQuery 用を除く）は、デフォルトで無効になっています。Google Cloud サービスのデータアクセス監査ログを書き込むには、明示的に有効にする必要があります。詳しくは、このページのデータアクセス監査ログを構成するをご覧ください。
Google Cloud での監査ロギングの詳細については、Cloud Audit Logs の概要をご覧ください。
ログへのアクセスを制御する
監査ロギングデータの機密性は、組織のユーザーに適切なアクセス制御を構成することが特に重要です。
コンプライアンスと使用状況の要件に応じて、これらのアクセス制御を次のように設定します。
- IAM 権限を設定する
- ログビューを構成する
- ログエントリのフィールド レベルのアクセス制御を設定する
IAM 権限を設定する
IAM の権限とロールによって、Logging API、ログ エクスプローラ、Google Cloud CLI 内の監査ログデータにアクセス可能かどうか判断されます。IAM を使用して、特定の Google Cloud バケットに対する詳細なアクセス権を付与し、他のリソースへの望ましくないアクセスを防ぎます。
ユーザーに付与する権限ベースのロールは、組織内の監査関連の機能によって異なります。たとえば、CTO に幅広い管理権限を付与しながら、デベロッパー チームのメンバーにはログ表示権限が必要になる場合があります。組織のユーザーに付与するロールのガイダンスについては、監査ロギングのロールの構成をご覧ください。
IAM 権限を設定するときは、リソースに必要なアクセス権のみをユーザーに付与するように、セキュリティに関する最小権限の原則を適用します。
- 不要なユーザーをすべて削除します。
- 重要なユーザーに正しい最小権限を付与します。
IAM 権限の設定手順については、プロジェクト、フォルダ、組織へのアクセスを管理するをご覧ください。
ログビューを構成する
Logging が受信したすべてのログ（監査ログを含む）は、ログバケットと呼ばれるストレージ コンテナに書き込まれます。ログビューを使用すると、ログバケット内のログにアクセスできるユーザーを制御できます。
ログバケットには複数の Google Cloud プロジェクトのログを格納できるため、それぞれのユーザーがログを表示できる Google Cloud プロジェクトを制御する必要がある場合があります。そうしたバケットへのアクセスを、カスタム ログビューを作成することでより細かく制御します。
ログビューの作成と管理の手順については、ログバケットでログビューを構成するをご覧ください。
ログフィールド レベルのアクセス制御を設定する
フィールド レベルのアクセス制御を使用すると、Google Cloud プロジェクトのユーザーに対して個々の LogEntry フィールドを非表示にして、ユーザーがアクセスできるログデータをより細かく制御できます。LogEntry 全体を表示しないログビューとは異なり、フィールド レベルのアクセス制御では LogEntry の個々のフィールドを非表示にします。たとえば、ログエントリのペイロードに含まれるメールアドレスなどの外部ユーザー PII を、組織のユーザーの大半から削除する必要が生じる場合があります。
フィールド レベルのアクセス制御を構成する手順については、フィールド レベルのアクセスを構成するをご覧ください。
データアクセス監査ログを構成する
新しい Google Cloud サービスを有効にする場合は、データアクセス監査ログを有効にするかどうかを判断します。
データアクセス監査ログは、Google サポートでアカウントの問題をトラブルシューティングする際に役立ちます。そのため、可能な場合は、データアクセス監査ログを有効にすることをおすすめします。
すべてのサービスですべての監査ログを有効にするには、Identity and Access Management（IAM）ポリシーの更新手順と監査ポリシーにリストされた構成に従ってください。
組織レベルのデータアクセス ポリシーを定義し、データアクセス監査ログを有効にしたら、テスト用の Google Cloud プロジェクトを使用して監査ログコレクションの構成を検証してから、組織でデベロッパーと本番環境の Google Cloud プロジェクトを作成します。
データアクセス監査ログを有効にする手順については、データアクセス監査ログを有効にするをご覧ください。
ログの保存方法を管理する
組織のバケットの側面を構成し、ユーザー定義のバケットを作成してログストレージを一元化または細分化できます。コンプライアンスと使用要件に応じて、ログストレージを次のようにカスタマイズできます。
- ログの保存場所を選択する。
- データの保持期間を定義する。
- 顧客管理の暗号鍵（CMEK）でログを保護する。
ログの保存場所を選択する
Logging では、バケットはリージョン リソースです。ログの保存、インデックス登録、検索を行うインフラストラクチャは特定の地理的な場所にあります。
組織によっては、ログデータを特定のリージョンに保存しなければならない場合があります。組織のレイテンシ、可用性、またはコンプライアンスの要件を満たしていることが、ログを保存するリージョンを選択する際の主な判断材料になります。
特定のストレージ リージョンを、組織で作成された新しい _Default バケットと _Required バケットに自動的に適用するには、デフォルトのリソース ロケーションを構成します。
デフォルトのリソース ロケーションを構成する手順については、組織のデフォルト設定を構成するをご覧ください。
データの保持期間を定義する
Cloud Logging は、ログが保持されるログバケット タイプに適用される保持ルールに従って、ログを保持します。
コンプライアンスのニーズを満たすには、ログを 1 ～ 3,650 日で保持するように Cloud Logging を構成します。カスタム保持ルールは、ログの種類やログが別の場所からコピーされたかどうかに関わらず、バケット内のすべてのログに適用されます。
ログバケットの保持ルールの設定については、カスタム保持の構成をご覧ください。
顧客管理の暗号鍵で監査ログを保護する
Cloud Logging では、お客様のコンテンツを保存時に暗号化するのがデフォルトの動作です。組織には、保存時のデフォルト暗号化では実現できない高度な暗号化要件が課せられている場合があります。組織の要件を満たすために、データを保護する鍵暗号鍵を Google が管理するのではなく、顧客管理の暗号鍵（CMEK）を構成して独自の暗号化を制御および管理します。
CMEK を構成する手順については、ログ ストレージに CMEK を構成するをご覧ください。
料金
Cloud Logging では、サポートされている宛先へのログの転送で料金を請求されることはありませんが、宛先での料金が発生する場合があります。_Required ログバケットを除き、Cloud Logging では、ログバケットへのログのストリーミングと、ログバケットのデフォルト保持期間よりも長いストレージの料金が請求されます。
Cloud Logging では、ログのコピー、[ログ エクスプローラ] ページまたは [ログ分析] ページを介して発行されたクエリには課金されません。
詳細については、次のドキュメントをご覧ください。
- Cloud Logging の料金概要
宛先の費用:
- VPC フローログの生成料金は、Cloud Logging から Virtual Private Cloud フローログを送信して除外した後に適用されます。
監査ログを構成して使用する際は、次の料金関連のベスト プラクティスをおすすめします。
使用状況データとアラートを設定して請求額を見積もる。
データアクセス監査ログは非常に大きいため、追加のストレージ コストが発生する可能性があります。
有用でない監査ログを除外して、費用を管理します。たとえば、開発プロジェクトではデータアクセス監査ログを除外できます。
監査ログのクエリと表示
トラブルシューティングが必要な場合は、ログをすばやく確認できるようにする必要があります。Google Cloud コンソールで、ログ エクスプローラを使用して組織の監査ログエントリを取得します。
-
Google Cloud コンソールのナビゲーション パネルで、[ロギング] を選択してから、[ログ エクスプローラ] を選択します。
組織を選択する。
[クエリ] ペインで、次の操作を行います。
リソースタイプに、表示する監査ログを含む Google Cloud リソースを選択します。
[ログ名] で、表示する監査ログタイプを選択します。
- 管理アクティビティ監査ログの場合は、[activity] を選択します。
- データアクセス監査ログの場合は、[data_access] を選択します。
- システム イベント監査ログの場合は、[system_event] を選択します。
- ポリシー拒否監査ログの場合は、[policy] を選択します。
これらのオプションが表示されない場合、組織にそのタイプの監査ログが存在しないことを意味します。
Query Editor で、表示する監査ログエントリをさらに指定します。一般的なクエリの例については、ログ エクスプローラを使用したサンプルクエリをご覧ください。
[クエリを実行] をクリックします。
ログ エクスプローラを使用したクエリの詳細については、ログ エクスプローラでクエリを作成するをご覧ください。
監査ログをモニタリングする
Cloud Monitoring を使用して、記述した条件の発生時に通知できます。Cloud Monitoring にログのデータを提供するため、Logging にはログベースのアラートが用意されています。これにより、ログに特定のイベントが表示されるたびに通知されます。
即時調査と、低優先度のイベントを必要とするイベントを区別するアラートを構成します。たとえば、監査ログで特定のデータアクセス メッセージが記録されたことを知りたい場合は、メッセージと一致するログベースのアラートを作成し、それが発生したときに通知できます。
ログベースのアラートの構成手順については、ログベースのアラートの管理をご覧ください。
サポートされている宛先にログをルーティングする
組織によっては、監査ログの作成と保持の要件が発生することがあります。シンクを使用すると、ログの一部またはすべてをサポートされている宛先に転送できます。
- Cloud Storage
- Pub/Sub（Splunk などのサードパーティを含む）
- BigQuery
- 別の Cloud Logging バケット
フォルダレベルまたは組織レベルのシンクが必要かどうかを判断して、集約シンクを使用して組織またはフォルダ内のすべての Google Cloud プロジェクトのログをルーティングします。たとえば、次のようなルーティングのユースケースを検討します。
組織レベルのシンク: 組織で SIEM を使用して複数の監査ログを管理する場合は、組織のすべての監査ログを転送することもあります。したがって、組織レベルのシンクは意味があります。
フォルダレベルのシンク: 場合によって、部門の監査ログのみをルーティングする場合があります。たとえば、「Finance」フォルダと「IT」フォルダがある場合は、「Finance」フォルダに属する監査ログのみをルーティングすることもできます。また、その逆も可能です。
フォルダと組織の詳細については、リソース階層をご覧ください。
ログ エクスプローラに適用されるのと同じアクセス ポリシーを、ログの転送に使用する Google Cloud 宛先に適用します。
集約シンクを作成して管理する手順については、組織レベルのログをサポートされている宛先に照合して転送するをご覧ください。
シンクの宛先のデータ形式について
監査ログを Cloud Logging の外部の宛先にルーティングする場合は、送信されたデータの形式を理解します。
たとえば、ログを BigQuery に転送する場合、Cloud Logging は、監査ログと特定の構造化ペイロード フィールドの BigQuery スキーマ フィールド名を短縮するルールを適用します。
Cloud Logging からサポートされている宛先に転送されたログエントリを確認するには、シンクのエクスポート先のログを表示するをご覧ください。
ログエントリのコピー
組織のコンプライアンスのニーズによっては、Logging の外部の監査者と監査ログエントリを共有する必要がある場合があります。すでに Cloud Logging バケットに保存されているログエントリを共有する必要がある場合は、手動で Cloud Storage バケットにコピーできます。
ログエントリを Cloud Storage にコピーする場合、ログエントリはコピー元のログバケットにも残ります。
なお、コピー オペレーションは、シンク（すべての受信ログエントリを Cloud Storage を含む事前選択されたサポートされているストレージの宛先に自動的に送信します）に代わるものではありません。
過去にさかのぼってログを Cloud Storage に転送する手順については、ログエントリのコピーをご覧ください。