このドキュメントでは、組織がセキュリティを維持してリスクを最小限に抑えるために、一連の監査ロギングタスクを推奨しています。
このドキュメントは、すべての推奨事項を網羅したものではありません。監査ログ アクティビティの範囲を把握し、それに応じて計画を立てることを目的としています。
各セクションには、主要な作業の説明と参考情報のリンクが記載されています。
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 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 にログを遡及的に転送する手順については、ログエントリをコピーするをご覧ください。