Cloud Storage での Cloud Audit Logs

このページでは、Cloud Storage で Cloud Audit Logs を使用する場合の補足情報を提供します。Cloud Audit Logs を使用すると、Cloud Storage で実行された API オペレーションのログを生成できます。

概要

Google Cloud サービスにより監査ログが書き込まれ、Google Cloud リソース内で「誰が、いつ、どこで、何をしたか」の確認に役立ちます。また、リソースにアクセスする方法についてより詳細な情報として、監査ログにカスタム情報を追加することもできます。

Google Cloud プロジェクトで記録されるのは、その Google Cloud プロジェクト内に直接存在するリソースの監査ログのみです。フォルダ、組織、請求先アカウントなど、その他の Google Cloud リソースには、そのエンティティ自体の監査ログが記録されます。

Cloud Audit Logs の概要については、Cloud Audit Logs の概要をご覧ください。監査ログ形式の詳細については、監査ログについてをご覧ください。

利用可能な監査ログ

Cloud Storage では、次の種類の監査ログを使用できます。

  • 管理アクティビティ監査ログ: Cloud Storage リソースへのアクセス権を変更するオペレーションと、バケット、マネージド フォルダ、インベントリ レポートの構成を作成、削除、変更するオペレーションが記録されます。管理アクティビティ監査ログは無効にできません。

  • データアクセス監査ログ: 管理アクティビティ監査ログで追跡されないオペレーションのエントリ。データアクセス監査ログには、さらにいくつかのサブタイプがあります。

    • ADMIN_READ: アクセス構成の読み取り、バケット メタデータの読み取り、プロジェクト内のバケットの一覧取得を行うオペレーションのエントリ。

    • DATA_READ: バケット以外の Cloud Storage リソースの読み取りまたは一覧取得を行うオペレーションのエントリ。

    • DATA_WRITE: オブジェクトの作成、変更、削除、復元、XML API マルチパート アップロードの作成、変更、削除、またはフォルダの作成、削除、名前変更を行うオペレーションのエントリ。

    データアクセス監査ログを受信するには、監査ログを明示的に有効にする必要があります。

Cloud Audit Logs では、Cloud Storage の監査ログだけでなく、Storage Insights の監査ログも作成できます。Storage Insights の監査ログは、インベントリ レポートの構成が作成、更新、取得されるたびに、またインベントリ レポートが取得される際に生成されます。

監査ログの種類の詳細については、監査ログの種類をご覧ください。

監査対象のオペレーション

次の表に、監査ログタイプに対応する Cloud Storage オペレーションを示します。

監査ログのタイプ サブタイプ Cloud Storage のオペレーション
管理アクティビティ ADMIN_WRITE
  • IAM ポリシーの設定 / 変更
  • オブジェクトの ACL の変更1
  • バケットの作成
  • バケットの削除
  • バケットのメタデータの更新
  • マネージド フォルダの作成
  • マネージド フォルダの削除
  • インベントリ レポートの構成の作成
  • インベントリ レポートの構成の更新
  • インベントリ レポートの構成の削除
データアクセス ADMIN_READ
  • IAM ポリシーの取得
  • オブジェクトの ACL の取得
  • バケットのメタデータの取得
  • バケットのリストの表示
データアクセス DATA_READ
  • オブジェクト データの取得
  • オブジェクト メタデータの取得
  • オブジェクトのリスト
  • フォルダのメタデータの取得
  • フォルダの一覧表示
  • マネージド フォルダのメタデータの取得
  • マネージド フォルダの一覧表示
  • オブジェクトのコピー2
  • オブジェクトの構成2
  • 進行中の XML API マルチパート アップロードのリスト取得
  • XML API マルチパート アップロードのパートのリスト取得
  • インベントリ レポートの構成の取得
  • インベントリ レポートの構成の一覧表示
  • インベントリ レポートの取得
  • インベントリ レポートの一覧表示
データアクセス DATA_WRITE
  • オブジェクトの作成
  • オブジェクトの削除
  • 削除(復元可能)状態のオブジェクトの復元
  • ACL 以外のオブジェクト メタデータの更新
  • オブジェクトのコピー1
  • オブジェクトの作成1
  • XML API マルチパート アップロードの開始
  • XML API マルチパート アップロードのパートの作成
  • XML API マルチパート アップロードの中止
  • XML API マルチパート アップロードの完了
  • フォルダの作成
  • フォルダの削除
  • フォルダの名前変更

1 オブジェクト作成時に ACL が初期設定される場合、管理アクティビティ監査ログは生成されません。また、オブジェクト ACL が一般公開に設定されている場合、そのオブジェクトまたはその ACL への読み書きで監査ログは生成されません。

2 これらのオペレーションにはデータの読み取りと書き込みの両方が含まれます。そのため、これらのオペレーションでは 2 つのログエントリが生成されます。

制限事項

Cloud Storage での Cloud Audit Logs には、次の制限が適用されます。

これらのいずれかのケースでロギング機能が必要な場合は、Cloud Storage 使用状況ログの使用を検討してください。

監査ログ形式

監査ログエントリには、次の要素が含まれます。

  • ログエントリ自体。これは LogEntry オブジェクトです。よく使用されるフィールドは次のとおりです。

    • logName には、リソース ID と監査ログの種類が含まれます。
    • resource には、監査対象オペレーションのターゲットが含まれます。
    • timestamp には、監査対象オペレーションの時間が含まれます。
    • protoPayload には、監査対象の情報が含まれます。
  • 監査ロギングデータ。ログエントリの protoPayload フィールドに保持される AuditLog オブジェクトです。

  • リクエストとレスポンスの詳細情報など、オプションの Cloud Storage 固有の監査情報については、詳細な監査ロギングモードをご覧ください。監査ログにカスタム情報を追加するために、詳細な監査ロギングを適用する必要はないことに留意してください。

これらのオブジェクトのその他のフィールドと、その解釈方法については、監査ログについてをご覧ください。

ログ名

Cloud Audit Logs のログ名にはリソース識別子が含まれています。これは、監査ログを所有する Google Cloud プロジェクトまたは他の Google Cloud エンティティを示しています。これにより、ログに管理アクティビティまたはデータアクセスの監査ログデータが含まれているかどうかがわかります。

リソース識別子の変数を含む監査ログ名は次のとおりです。

   projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity
   projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access

   folders/FOLDER_ID/logs/cloudaudit.googleapis.com%2Factivity
   folders/FOLDER_ID/logs/cloudaudit.googleapis.com%2Fdata_access

   billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com%2Factivity
   billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com%2Fdata_access

   organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity
   organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access

サービス名

Cloud Storage 監査ログでは、サービス名 storage.googleapis.com が使用されます。

Storage Insights の監査ログでは、サービス名 storageinsights.googleapis.com が使用されます。

すべての Cloud Logging API サービス名とそれに対応するモニタリング対象リソースタイプの一覧については、サービスとリソースのマッピングをご覧ください。

リソースタイプ

Cloud Storage 監査ログでは、リソースタイプ gcs_bucket が使用されます。

Cloud Logging でモニタリングされるすべてのリソースタイプのリストと記述情報については、モニタリング対象リソースタイプをご覧ください。

監査ロギングの有効化

管理アクティビティ監査ログは常に有効になっています。無効にすることはできません。

データアクセス監査ログはデフォルトで無効になっており、明示的に有効にしない限り書き込まれません。

データアクセス監査ログの一部またはすべてを有効にする方法については、データアクセス監査ログを構成するをご覧ください。

権限とロール

IAM の権限とロールにより、Google Cloud リソース内の監査ログデータにアクセス可能かどうか判断されます。

ユースケースに適用する Logging 固有の権限とロールを決定する際は、次の点を考慮してください。

  • ログ閲覧者のロール(roles/logging.viewer)は、管理アクティビティ、ポリシー拒否、システム イベントの監査ログに対する読み取り専用権限を付与します。このロールしかない場合は、_Required バケットと _Default バケットにあるデータアクセスの監査ログを閲覧できません。

  • プライベート ログ閲覧者ロール((roles/logging.privateLogViewer)には、roles/logging.viewer に含まれる権限に加え、_Required バケットと _Default バケット内のデータアクセス監査ログの読み取り権限が含まれます。

    これらのプライベート ログがユーザー定義バケットに保存されている場合、それらのバケット内のログを読み取る権限を持つユーザーは、プライベート ログを読み取ることができます。ログバケットの詳細については、転送とストレージの概要をご覧ください。

監査ログデータに適用される IAM の権限とロールの詳細については、IAM を使用したアクセス制御をご覧ください。

ログの表示

すべての監査ログに対してクエリを実行することも、監査ログ名でログをクエリすることもできます。監査ログ名には、監査ロギング情報を表示する Google Cloud プロジェクト、フォルダ、請求先アカウント、または組織のリソース識別子が含まれています。クエリでは、インデックス付きの LogEntry フィールドを指定できます。SQL クエリをサポートする [ログ分析] ページを使用する場合は、クエリ結果をグラフとして表示できます。

ログのクエリの詳細については、次のページをご覧ください。

Google Cloud コンソール、Google Cloud CLI、または Logging API を使用して、Cloud Logging で監査ログを表示できます。
コンソールgcloudAPI

Google Cloud コンソールでは、ログ エクスプローラを使用して、Google Cloud プロジェクト、フォルダ、または組織の監査ログエントリを取得できます。

  1. Google Cloud コンソールで、[ログ エクスプローラ] ページに移動します。

    [ログ エクスプローラ] に移動

    検索バーを使用してこのページを検索する場合は、小見出しが [Logging] の結果を選択します。

  2. 既存の Google Cloud プロジェクト、フォルダ、または組織を選択します。

  3. すべての監査ログを表示するには、次のいずれかのクエリを [クエリエディタ] フィールドに入力し、[クエリを実行] をクリックします。

    logName:"cloudaudit.googleapis.com"
    
    protoPayload."@type"="type.googleapis.com/google.cloud.audit.AuditLog"
    
  4. 特定のリソースと監査ログタイプの監査ログを表示するには、[クエリビルダー] ペインで次の操作を行います。

    • リソースタイプに、表示する監査ログの対象となる Google Cloud リソースを選択します。

    • [ログ名] で、表示する監査ログタイプを選択します。

      • 管理アクティビティ監査ログの場合は、[activity] を選択します。
      • データアクセス監査ログの場合は、[data_access] を選択します。
      • システム イベント監査ログの場合は、[system_event] を選択します。
      • ポリシー拒否監査ログの場合は、[policy] を選択します。
    • [クエリを実行] をクリックします。

    これらのオプションが表示されない場合、Google Cloud プロジェクト、フォルダ、または組織で利用可能なその種類の監査ログは存在しないことを意味します。

    ログ エクスプローラでログを表示する際に問題が発生した場合は、トラブルシューティングの情報をご覧ください。

    ログ エクスプローラを使用したクエリの詳細については、ログ エクスプローラでクエリを作成するをご覧ください。 Gemini を使用してログ エクスプローラでログエントリを要約する方法については、Gemini アシスト機能を使用してログエントリを要約するをご覧ください。

Google Cloud CLI は、Logging API へのコマンドライン インターフェースを提供します。ログ名ごとに有効なリソース識別子を指定します。たとえば、クエリに PROJECT_ID が含まれている場合、指定するプロジェクト ID は、現在選択された Google Cloud プロジェクトを参照している必要があります。

Google Cloud プロジェクト レベルの監査ログエントリを読み取るには、次のコマンドを実行します。

gcloud logging read "logName : projects/PROJECT_ID/logs/cloudaudit.googleapis.com" \
    --project=PROJECT_ID

フォルダレベルの監査ログエントリを読み取るには、次のコマンドを実行します。

gcloud logging read "logName : folders/FOLDER_ID/logs/cloudaudit.googleapis.com" \
    --folder=FOLDER_ID

組織レベルの監査ログエントリを読み取るには、次のコマンドを実行します。

gcloud logging read "logName : organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com" \
    --organization=ORGANIZATION_ID

Cloud 請求先アカウント レベルの監査ログエントリを読み取るには、次のコマンドを実行します。

gcloud logging read "logName : billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com" \
    --billing-account=BILLING_ACCOUNT_ID

1 日以上経過したログを読み取るには、コマンドに --freshness フラグを追加します。

gcloud CLI の使用方法に関する詳細については、gcloud logging read をご覧ください。

クエリを作成するときは、ログ名ごとに有効なリソース識別子を指定します。たとえば、クエリに PROJECT_ID が含まれている場合、指定するプロジェクト ID は、現在選択された Google Cloud プロジェクトを参照している必要があります。

たとえば、Logging API を使用してプロジェクト レベルの監査ログエントリを表示する手順は次のとおりです。

  1. entries.list メソッドのドキュメント内の [Try this API] セクションに移動します。

  2. [Try this API] フォームのリクエストの本文に、次のコードを入力します。この事前入力されたフォームをクリックすると、リクエストの本文が自動的に入力されますが、それぞれのログ名に有効な PROJECT_ID を指定する必要があります。

    {
      "resourceNames": [
        "projects/PROJECT_ID"
      ],
      "pageSize": 5,
      "filter": "logName : projects/PROJECT_ID/logs/cloudaudit.googleapis.com"
    }
    
  3. [Execute] をクリックします。

監査ログにカスタム情報を追加する

リクエストに x-goog-custom-audit-KEY: VALUE ヘッダーを含めることで、監査ログにカスタム情報を追加できます。XML API リクエストでは、x-goog-custom-audit-KEY=VALUE クエリ パラメータも使用できます。カスタム情報は、監査ログエントリの protoPayloadmetadata フィールドに追加されます。

カスタム監査情報を追加する際は、次の検討事項を留意してください。

  • KEY の最大文字数は 64 文字で、VALUE の最大文字数は 1,200 文字です。

  • 各リクエストには、最大 4 つのヘッダーまたはパラメータ エントリを組み合わせて含めることができます。

ヘッダー エントリの例

ヘッダー エントリに含めることができる Key-Value ペアの例を以下に示します。

  • x-goog-custom-audit-job: test-job-id-here
  • x-goog-custom-audit-user: user ID test 1
  • x-goog-custom-audit-internal-user-id: MATR2022-11
  • x-goog-custom-audit-tracking-ticket: TT/1516512851
  • x-goog-custom-audit-justification: Removed customer identity record at customer request
  • x-goog-custom-audit-customer-id: USCU12315154

リクエストの例

gcloud storage hash gs://example_bucket/example_object.jpeg --additional-headers=x-goog-custom-audit-job="job name",x-goog-custom-audit-user="test user"

カスタム ヘッダーをリクエストに追加する方法については、カスタム ヘッダーを追加するをご覧ください。

カスタム ヘッダーをリクエストに追加する方法については、カスタム ヘッダーを追加するをご覧ください。

カスタム ヘッダーをリクエストに追加する方法については、カスタム ヘッダーを追加するをご覧ください。

カスタム ヘッダーをリクエストに追加する方法については、カスタム ヘッダーを追加するをご覧ください。

カスタム ヘッダーをリクエストに追加する方法については、カスタム ヘッダーを追加するをご覧ください。

カスタム ヘッダーをリクエストに追加する方法については、カスタム ヘッダーを追加するをご覧ください。

カスタム ヘッダーをリクエストに追加する方法については、カスタム ヘッダーを追加するをご覧ください。

カスタム ヘッダーをリクエストに追加する方法については、カスタム ヘッダーを追加するをご覧ください。

JSON APIXML API
curl -X GET "https://storage.googleapis.com/storage/v1/b/example_bucket/o/example_object" \
-H "Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg" \
-H "x-goog-custom-audit-job: job name" \
-H "x-goog-custom-audit-user: test user"
curl -X GET "https://storage.googleapis.com/example_bucket/example_object" \
-H "Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg" \
-H "x-goog-custom-audit-job: job name" \
-H "x-goog-custom-audit-user: test user"
curl -X GET 'storage.googleapis.com/example_bucket?X-Goog-Algorithm=GOOG4-RSA-SHA256&X-Goog-Credential=example%40example-project.iam.gserviceaccount.com%2F20181026%2Fus-central1%2Fstorage%2Fgoog4_request&X-Goog-Date=20181026T181309Z&X-Goog-Expires=900&X-Goog-SignedHeaders=host,x-goog-custom-audit-job,x-goog-custom-audit-user&X-Goog-Signature=247a2aa45f169edf4d187d54e7cc46e4731b1e6273242c4f4c39a1d2507a0e58706e25e3a85a7dbb891d62afa8496def8e260c1db863d9ace85ff0a184b894b117fe46d1225c82f2aa19efd52cf21d3e2022b3b868dcc1aca2741951ed5bf3bb25a34f5e9316a2841e8ff4c530b22ceaa1c5ce09c7cbb5732631510c20580e61723f5594de3aea497f195456a2ff2bdd0d13bad47289d8611b6f9cfeef0c46c91a455b94e90a66924f722292d21e24d31dcfb38ce0c0f353ffa5a9756fc2a9f2b40bc2113206a81e324fc4fd6823a29163fa845c8ae7eca1fcf6e5bb48b3200983c56c5ca81fffb151cca7402beddfc4a76b133447032ea7abedc098d2eb14a7' \
-H "x-goog-custom-audit-job: job name" \
-H "x-goog-custom-audit-user: test user"

カスタム監査ヘッダーも X-Goog-SignedHeaders に含める必要があることに留意してください。

カスタム監査ヘッダーの追加をサポートする署名付き URL リクエストを作成するには、署名付き URL を生成する際に、リクエストで使用するカスタム監査ヘッダーも含める必要があります。例:

gcloud storage sign-url gs://example_bucket/example_object.jpeg --private-key-file=example-key.json --duration=10m --headers=x-goog-custom-audit-job:"job name",x-goog-custom-audit-user="test user"

また、カスタム ヘッダーを設定する際に、クライアント ライブラリを使用して署名付き URL を生成することもできます。

署名付きヘッダーを使用する代わりに、クエリ パラメータを使用してカスタム監査エントリを渡すこともできます。

curl -X GET 'storage.googleapis.com/example_bucket?X-Goog-Custom-Audit-Key=Value&X-Goog-Algorithm=GOOG4-RSA-SHA256&X-Goog-Credential=example%40example-project.iam.gserviceaccount.com%2F20181026%2Fus-central1%2Fstorage%2Fgoog4_request&X-Goog-Date=20181026T181309Z&X-Goog-Expires=900&X-Goog-SignedHeaders=host&X-Goog-Signature=247a2aa45f169edf4d187d54e7cc46e4731b1e6273242c4f4c39a1d2507a0e58706e25e3a85a7dbb891d62afa8496def8e260c1db863d9ace85ff0a184b894b117fe46d1225c82f2aa19efd52cf21d3e2022b3b868dcc1aca2741951ed5bf3bb25a34f5e9316a2841e8ff4c530b22ceaa1c5ce09c7cbb5732631510c20580e61723f5594de3aea497f195456a2ff2bdd0d13bad47289d8611b6f9cfeef0c46c91a455b94e90a66924f722292d21e24d31dcfb38ce0c0f353ffa5a9756fc2a9f2b40bc2113206a81e324fc4fd6823a29163fa845c8ae7eca1fcf6e5bb48b3200983c56c5ca81fffb151cca7402beddfc4a76b133447032ea7abedc098d2eb14a7'

これらのクエリ パラメータは、署名付き URL を生成するときに含める必要があります。例:

gcloud storage sign-url gs://example_bucket/example_object.jpeg --private-key-file=example-key.json --duration=10m --query-params=x-goog-custom-audit-job=job_name,x-goog-custom-audit-user=test_user

ログエントリの例

protoPayload: {
  @type: "type.googleapis.com/google.cloud.audit.Auditlog",
  ...
  metadata: {
    audit_context: {
      app_context: "EXTERNAL",
      audit_info: {
        x-goog-custom-audit-job: "job name",
        x-goog-custom-audit-user: "test user"
      }
    }
  }
}

type.googleapis.com/google.cloud.audit.Auditlog 型の protoPayload オブジェクトに含まれるフィールドの詳細については、AuditLog リファレンス ドキュメントをご覧ください。

監査ログを転送する

他の種類のログと同様に、サポートされている宛先に監査ログを転送できます。監査ログを転送する理由を以下に示します。

  • 監査ログを長期間保持する場合や、より強力な検索機能を使用する場合は、監査ログのコピーを Cloud Storage、BigQuery、または Pub/Sub に転送します。Pub/Sub を使用すると、他のアプリケーション、他のリポジトリ、サードパーティ製品に転送できます。
  • 組織全体の監査ログを管理するには、組織内の一部またはすべての Google Cloud プロジェクトからログを転送できる集約シンクを作成します。
  • 有効にしたデータアクセス監査ログが原因で Google Cloud プロジェクト数が無料の割り当てを超過している場合は、データアクセス監査ログを Logging から除外するシンクを作成できます。

ログの転送手順については、シンクを構成して管理するをご覧ください。

料金

Cloud Logging の料金については、Google Cloud Observability の料金: Cloud Logging をご覧ください。