このドキュメントでは、組織がセキュリティを維持してリスクを最小限に抑えるために、一連の監査ロギングタスクを推奨しています。
このドキュメントは、すべての推奨事項を説明するものではありません。監査ログ アクティビティの範囲を把握し、それに応じて計画を立てることを目的としています。
各セクションには、主要な作業の説明と参考情報のリンクが記載されています。
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 コンソールで、[ログ エクスプローラ] ページに移動します。
検索バーを使用してこのページを検索する場合は、小見出しが [Logging] である結果を選択します。
組織を選択する。
[クエリ] ペインで、次の操作を行います。
リソースタイプに、表示する監査ログを含む Google Cloud リソースを選択します。
[ログ名] で、表示する監査ログタイプを選択します。
- 管理アクティビティ監査ログの場合は、[activity] を選択します。
- データアクセス監査ログの場合は、[data_access] を選択します。
- システム イベント監査ログの場合は、[system_event] を選択します。
- ポリシー拒否監査ログの場合は、[policy] を選択します。
これらのオプションが表示されない場合、そのタイプの監査ログは組織で存在しません。
クエリエディタで、表示する監査ログエントリをさらに指定します。一般的なクエリの例については、ログ エクスプローラを使用したサンプルクエリをご覧ください。
[クエリを実行] をクリックします。
ログ エクスプローラを使用したクエリの詳細については、ログ エクスプローラでクエリを作成するをご覧ください。
監査ログをモニタリングする
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 に遡って転送する手順については、ログエントリのコピーをご覧ください。