データアクセス監査ログを有効にする

このガイドでは、Google Cloud Console または API を使用して、Google Cloud プロジェクト、請求先アカウント、フォルダ、組織でデータアクセス監査ログの一部またはすべてを有効または無効にする方法について説明します。

始める前に

データアクセス監査ログの構成に進む前に、次の内容を理解してください。

  • データアクセス監査ログ(BigQuery を除く)は、デフォルトで無効になっています。BigQuery 以外の Google Cloud サービスのデータアクセス監査ログを書き込むには、明示的に有効にする必要があります。

  • データアクセス監査ログは、別の場所に転送しない限り _Default バケットに保存されます。詳細については、監査ログの保存と転送をご覧ください。

  • データアクセス監査ログは、Google サポートでアカウントの問題をトラブルシューティングする際に役立ちます。そのため、可能な場合は、データアクセス監査ログを有効にすることをおすすめします。

構成の概要

Google Cloud リソースおよびサービスに対して、データアクセス監査ログの特定の要素を有効にして構成できます。

  • 組織: 組織内の既存のプロジェクトとフォルダおよび新規の Google Cloud プロジェクトとフォルダのすべてに適用される組織内のデータアクセス監査ログを有効にして構成できます。

  • フォルダ: フォルダ内の既存の Google Cloud プロジェクトと新規のプロジェクトすべてに適用されるフォルダ内のデータアクセス監査ログを有効にして構成できますが、プロジェクトの親組織で有効になっているデータアクセス監査ログを無効にすることはできません。

  • プロジェクト: データアクセス監査ログは、個々の Google Cloud プロジェクトに対して構成できます。親組織やフォルダで有効になっているデータアクセス監査ログは無効にできません。

  • 請求先アカウント: 請求先アカウントのデータアクセス監査ログを構成するには、Google Cloud CLI を使用します。データアクセス監査ログと請求先アカウントで gcloud CLI を使用する方法の詳細については、gcloud beta billing accounts set-iam-policy のリファレンス ドキュメントをご覧ください。

  • デフォルト構成: データアクセス監査ログの作成を開始する Google Cloud サービスに適用する組織、フォルダ、または Google Cloud プロジェクトで、デフォルトのデータアクセス監査ログ構成を指定できます。手順については、デフォルトの構成を設定するをご覧ください。

  • サービス: 監査ログを収集する対象のサービスを指定できます。たとえば、Cloud SQL ではなく Compute Engine からの監査ログを使用することもできます。監査ログを生成できる Google Cloud サービスのリストについては、監査ログを使用する Google サービスをご覧ください。

  • ログタイプ: データアクセス監査ログに記録されるオペレーションのタイプを構成できます。データアクセス監査ログは次の 3 種類です。

    • ADMIN_READ: メタデータまたは構成情報を読み取るオペレーションを記録します。

    • DATA_READ: ユーザー提供データを読み取るオペレーションを記録します。

    • DATA_WRITE: ユーザー提供データを書き込むオペレーションを記録します。

    たとえば、Cloud DNS は 3 種類のデータアクセス ログをすべて書き込みますが、データアクセス監査ログが DATA_WRITE オペレーションだけを記録するように構成できます。

  • 除外されたプリンシパル: 特定のプリンシパルは、データアクセスを記録する対象から除外できます。たとえば、内部テスト アカウントを除外し、このアカウントが行った Cloud Monitoring のオペレーションをログに記録しないようにできます。ユーザーやグループなど、有効なプリンシパルのリストについては、Binding タイプ リファレンスをご覧ください。

データアクセスの監査ログは、Google Cloud コンソールの IAM [監査ログ] ページまたは API を使用して構成できます。これらの方法については、下記のセクションで説明します。

サービスに固有の構成

Google Cloud サービス全体(allServices)の構成と特定の Google Cloud サービス用の構成が両方とも存在する場合、結果的にそのサービスに適用される構成は、2 つの構成を結合したものになります。つまり、

  • 特定の Google Cloud サービスでデータアクセス監査ログを有効にすることはできますが、より幅広い構成で有効になっている Google Cloud サービスのデータアクセス監査ログは無効にできません。

  • Google Cloud サービスのデータアクセス監査ログに情報の種類を追加することはできますが、より幅広い構成で指定されている情報の種類は削除できません。

  • プリンシパルを除外リストに追加することはできますが、より幅広い構成の除外リストからプリンシパルを削除することはできません。

  • BigQuery Data Transfer Service では、データアクセス監査ログの構成がデフォルトの監査ログ構成から継承されます。

Google Cloud リソースの構成

Google Cloud プロジェクト、請求先アカウント、フォルダ、組織のデータアクセス監査ログを構成できます。階層内に Google Cloud サービスの構成が存在する場合、結果的にその構成は、複数の構成を結合したものになります。つまり、Google Cloud プロジェクト レベルでは:

  • Google Cloud サービスのログは有効にできますが、親組織やフォルダで有効になっている Google Cloud サービスのログは無効にできません。

  • 情報の種類を有効にすることはできますが、親組織や親フォルダで有効になっている情報の種類を無効にすることはできません。

  • プリンシパルを除外リストに追加することはできますが、親組織やフォルダの除外リストから削除することはできません。

  • 親組織または親フォルダレベルでは、Google Cloud プロジェクトでデータアクセス監査ログが構成されていなくても、その組織またはフォルダ内にある Google Cloud プロジェクトに対してデータアクセス監査ログを有効にできます。

アクセス制御

Identity and Access Management のロールと権限は、Logging データへのアクセス(データアクセス監査ログの構成の基礎となる IAM ポリシーの表示と管理など)を規定します。

データアクセス構成に関連付けられたポリシーを表示または設定するには、適切なリソースレベルの権限を持つロールが必要です。こうしたリソースレベルのロールを付与する方法については、Google Cloud プロジェクト、フォルダ、組織へのアクセスを管理するをご覧ください。

  • IAM ポリシーを設定するには、resourcemanager.RESOURCE_TYPE.setIamPolicy 権限を持つロールが必要です。

  • IAM ポリシーを表示するには、resourcemanager.RESOURCE_TYPE.getIamPolicy 権限を持つロールが必要です。

データアクセス監査ログを表示するために必要な権限とロールのリストについては、IAM によるアクセス制御をご覧ください。

Google Cloud コンソールでデータアクセス監査ログを構成する

このセクションでは、Google Cloud コンソールを使用してデータアクセス監査ログを構成する方法について説明します。

API または Google Cloud CLI を使用して、これらのタスクをプログラムで実行することもできます。詳しくは、API を使用したデータアクセス監査ログの構成をご覧ください。

Google Cloud コンソールで、監査ログ構成オプションにアクセスする方法は次のとおりです。

  1. Google Cloud コンソールで、[監査ログ] ページに移動します:

    [監査ログ] に移動

    検索バーを使用してこのページを検索する場合は、小見出しが [IAM と管理者] である結果を選択します。

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

監査ログを有効にする

データアクセス監査ログを有効にするには、次の手順を行います。

  1. [データアクセス監査ログの構成] テーブルで、[サービス] 列から 1 つ以上の Google Cloud サービスを選択します。

  2. [ログタイプ] タブで、選択したサービスに対して有効にするデータアクセス監査ログのタイプを選択します。

  3. [保存] をクリックします。

監査ログが有効になると、表に [チェック] アイコンが表示されます。

次の例では、Access Approval サービスに対して、[データ読み取り] 監査ログタイプが有効になっていることが確認できます。

監査ログの構成

データアクセス監査ログを生成するすべての Google Cloud サービスの監査ログを有効にすることもできます。[データアクセス監査ログの構成] テーブルで、すべての Google Cloud サービスを選択します。

この一括構成方法は、リソースで現在利用可能な Google Cloud サービスにのみ適用されます。新しい Google Cloud サービスが追加されると、デフォルト監査構成が継承されます。

データアクセス監査ログを無効にする

データアクセス監査ログを無効にするには、次の手順を行います。

  1. [データアクセス監査ログの構成] テーブルで、1 つ以上の Google Cloud サービスを選択します。

  2. 情報パネルの [ログタイプ] タブで、選択したサービスに対して無効にするデータアクセス監査ログのタイプを選択します。

  3. [保存] をクリックします。

ここで、データアクセス監査ログが正常に無効にされた場合は、テーブルに灰色のマイナス記号が表示されます。有効になっているデータアクセス監査ログには、 [チェック] アイコンが表示されます。

除外を設定する

除外を設定して、特定サービスのデータアクセス監査ログを生成するプリンシパルを制御できます。除外されたプリンシパルを追加すると、選択したログタイプの監査ログがそのプリンシパルに対して作成されません。

除外を設定するには、次の操作を行います。

  1. [データアクセス監査ログの構成] テーブルで、[サービス] 列から Google Cloud サービスを選択します。

  2. 情報パネルで、[除外されるプリンシパル] タブを選択します。

  3. [除外されるプリンシパルを追加] で、選択したサービスのデータアクセス監査ログの生成から除外するプリンシパルを入力します。

    [除外されるプリンシパルを追加] ボタンを必要な回数だけクリックすることで、複数のプリンシパルを追加できます。

    ユーザーやグループなど、有効なプリンシパルのリストについては、Binding タイプのリファレンスをご覧ください。

  4. [無効にされるログの種類] で、無効にするデータアクセス監査ログの種類を選択します。

  5. [保存] をクリックします。

除外されたプリンシパルをサービスに追加すると、データアクセス監査ログの構成テーブルで、[除外されるプリンシパル] 列の下に数が表示されます。

除外リストからプリンシパルを削除するには、次の操作を行います。

  1. [データアクセス監査ログの構成] テーブルで、[サービス] 列から Google Cloud サービスを選択します。

  2. 情報パネルで、[除外されるプリンシパル] タブを選択します。

  3. プリンシパル名にカーソルを合わせて、表示される削除アイコン を選択します。

  4. プリンシパルの名前が取り消し線テキストで表示されたら、[保存] をクリックします。

除外されるプリンシパルの情報を編集するには、次の操作を行います。

  1. [データアクセス監査ログの構成] テーブルで、[サービス] 列から Google Cloud サービスを選択します。

  2. 情報パネルで、[除外されるプリンシパル] タブを選択します。

  3. プリンシパル名 を開きます。

  4. プリンシパルに合わせてデータアクセス監査ログタイプを選択または選択解除します。

  5. [保存] をクリックします。

デフォルト構成を設定する

Google Cloud プロジェクト、フォルダ、組織内のすべての新規および既存の Google Cloud サービスが継承する構成を指定できます。組織内のプリンシパルが使用を開始する新しい Google Cloud サービスが利用可能になった場合、このデフォルト構成を適用します。このサービスでは、他の Google Cloud サービス用に構成されている監査ログポリシーが継承され、データアクセス監査ログがキャプチャされます。

デフォルト構成を設定または編集するには、次の操作を行います。

  1. [デフォルト構成を設定] をクリックします。

  2. 情報パネルの [ログタイプ] タブで、有効または無効にするデータアクセス監査ログの種類を選択します。

  3. [保存] をクリックします。

  4. 情報パネルで、[除外されるプリンシパル] タブを選択します。

  5. [除外されるプリンシパルを追加] で、選択したサービスのデータアクセス監査ログの生成から除外するプリンシパルを入力します。

    [除外されるプリンシパルを追加] ボタンを必要な回数だけクリックすることで、複数のプリンシパルを追加できます。

    ユーザーやグループなど、有効なプリンシパルのリストについては、Binding タイプのリファレンスをご覧ください。

  6. [無効にされるログの種類] で、無効にするデータアクセス監査ログの種類を選択します。

  7. [保存] をクリックします。

API を使用したデータアクセス監査ログの構成

このセクションでは、API と gcloud CLI を使用してデータアクセス監査ログをプログラムで構成する方法について説明します。

これらのタスクの多くは、Google Cloud コンソールを使用して実行することもできます。手順については、このページの Google Cloud コンソールでデータアクセス監査ログを構成するをご覧ください。

IAM ポリシー オブジェクト

API を使用してデータアクセス監査ログを構成するには、Google Cloud プロジェクト、フォルダ、組織に関連付けられた IAM ポリシーを編集する必要があります。監査ログの構成は、ポリシーの auditConfigs セクションにあります。

"auditConfigs": [
  {
    object(AuditConfig)
  }
]

詳細については、IAM ポリシータイプをご覧ください。

次のセクションでは、AuditConfig オブジェクトについて詳しく説明します。構成の変更に使用する API コマンドと gcloud CLI コマンドについては、getIamPolicy と setIamPolicy をご覧ください。

AuditConfig 個のオブジェクト

監査ログの構成は AuditConfig オブジェクトのリストで構成されています。各オブジェクトは 1 つのサービスのログを構成するか、すべてのサービスの全体の構成を設定します。各オブジェクトは次のように記述します。

{
  "service": SERVICE_NAME,
  "auditLogConfigs": [
    {
      "logType": "ADMIN_READ"
      "exemptedMembers": [ PRINCIPAL,]
    },
    {
      "logType": "DATA_READ"
      "exemptedMembers": [ PRINCIPAL,]
    },
    {
      "logType": "DATA_WRITE"
      "exemptedMembers": [ PRINCIPAL,]
    },
  ]
},

SERVICE_NAME"appengine.googleapis.com" などの値か、"allServices" という特殊値です。特定のサービスについての記述が構成に含まれない場合、そのサービスには全体の構成が使用されます。構成がない場合、そのサービスのデータアクセス監査ログは有効になりません。 サービス名の一覧については、ログサービスをご覧ください。

AuditConfig オブジェクトの auditLogConfigs セクションは、0~3 オブジェクトのリストで、各オブジェクトは 1 種類の監査ログ情報を構成します。リストからいずれかの種類を省略した場合、その種類の情報はサービスで有効になりません。

PRINCIPAL は、データアクセス監査ログが収集されないユーザーです。Binding タイプは、ユーザーとグループを含むさまざまな種類のプリンシパルを記述しますが、すべてをデータアクセス監査ログの構成に使用できるわけではありません。

次に、監査構成を JSON 形式と YAML 形式で記述した例を示します。Google Cloud CLI を使用する場合は、YAML 形式がデフォルトです。

JSON

"auditConfigs": [
  {
    "auditLogConfigs": [
      {
        "logType": "ADMIN_READ"
      },
      {
        "logType": "DATA_WRITE"
      },
      {
        "logType": "DATA_READ"
      }
    ],
    "service": "allServices"
  },
  {
    "auditLogConfigs": [
      {
        "exemptedMembers": [
          "[email protected]"
        ],
        "logType": "ADMIN_READ"
      }
    ],
    "service": "cloudsql.googleapis.com"
  }
],

YAML

auditConfigs:
- auditLogConfigs:
  - logType: ADMIN_READ
  - logType: DATA_WRITE
  - logType: DATA_READ
  service: allServices
- auditLogConfigs:
  - exemptedMembers:
    - [email protected]
    logType: ADMIN_READ
  service: cloudsql.googleapis.com

一般的な構成

以下に、Google Cloud プロジェクト用の一般的な監査ログ構成を示します。

すべてのデータアクセス監査ログを有効にする

次の auditConfigs セクションは、すべてのサービスとプリンシパルのデータアクセス監査ログを有効にします。

JSON

"auditConfigs": [
      {
        "service": "allServices",
        "auditLogConfigs": [
          { "logType": "ADMIN_READ" },
          { "logType": "DATA_READ"  },
          { "logType": "DATA_WRITE" },
        ]
      },
    ]

YAML

auditConfigs:
- auditLogConfigs:
  - logType: ADMIN_READ
  - logType: DATA_WRITE
  - logType: DATA_READ
  service: allServices

1 つのサービスと情報の種類を有効にする

次の構成は、Cloud SQL の DATA_WRITE データアクセス監査ログを有効にします。

JSON

"auditConfigs": [
  {
    "service": "cloudsql.googleapis.com",
    "auditLogConfigs": [
      { "logType": "DATA_WRITE" },
    ]
  },
]

YAML

auditConfigs:
- auditLogConfigs:
  - logType: DATA_WRITE
  service: cloudsql.googleapis.com

すべてのデータアクセス監査ログを無効にする

Google Cloud プロジェクトですべてのデータアクセス監査ログ(BigQuery 用を除く)を無効にするには、新しい IAM ポリシーに空の auditConfigs: セクションを含めます。

JSON

"auditConfigs": [],

YAML

auditConfigs:

新しいポリシーから auditConfigs セクションを完全に削除した場合、setIamPolicy は既存のデータアクセス監査ログの構成を変更しません。詳細については、setIamPolicy の更新マスクをご覧ください。

BigQuery データアクセス監査ログは無効にできません。

getIamPolicysetIamPolicy

IAM ポリシーの読み取りと書き込みには、Cloud Resource Manager API の getIamPolicy メソッドと setIamPolicy メソッドを使用します。これらのメソッドには複数のタイプがあり、その中から使用するメソッドを選択します。

  • Cloud Resource Manager API には次のメソッドが用意されています。

    projects.getIamPolicy
    projects.setIamPolicy
    organizations.getIamPolicy
    organizations.setIamPolicy
    
  • Google Cloud CLI には次の Resource Manager コマンドがあります。

    gcloud projects get-iam-policy
    gcloud projects set-iam-policy
    gcloud resource-manager folders get-iam-policy
    gcloud resource-manager folders set-iam-policy
    gcloud organizations get-iam-policy
    gcloud organizations set-iam-policy
    gcloud beta billing accounts get-iam-policy
    gcloud beta billing accounts set-iam-policy
    

どれを選択するかにかかわらず、次の 3 つのステップを行います。

  1. getIamPolicy メソッドを使用して現在のポリシーを読み取ります。取得したポリシーを一時ファイルに保存します。
  2. 一時ファイルでポリシーを編集します。auditConfigs セクションのみ変更(または追加)します。
  3. setIamPolicy メソッドを使用して、編集したポリシーを一時ファイルに書き込みます。

Resource Manager が、最初の手順で他のユーザーがポリシーを変更したことを検出した場合、setIamPolicy は失敗します。これが起こった場合は、3 つのステップをもう一度やり直します。

次の例は、gcloud コマンドや Cloud Resource Manager API を使用して、プロジェクトのデータアクセス監査ログを構成する方法を示しています。

組織のデータアクセス監査ログを構成するには、コマンドまたは API メソッドの「projects」版を「organizations」版に置き換えてください。

gcloud

データアクセス監査ログを構成するには、gcloud projects 次のようにします。

  1. プロジェクトの IAM ポリシーを取得し、ファイルに保存します。

    gcloud projects get-iam-policy PROJECT_ID > /tmp/policy.yaml
    

    返されたポリシーを次に示します。このポリシーにはまだ auditConfigs セクションはありません。

    bindings:
    - members:
      - user:[email protected]
      role: roles/editor
    - members:
      - user:[email protected]
      role: roles/owner
    etag: BwVM-FDzeYM=
    version: 1
    
  2. /tmp/policy.yaml 内のポリシーを編集し、データアクセス監査ログの構成のみを追加または変更します。

    編集したポリシーの例(ここでは Cloud SQL のデータ書き込みデータアクセス監査ログを有効にしています)を次に示します。先頭に 4 行追加されています。

    auditConfigs:
    - auditLogConfigs:
      - logType: DATA_WRITE
      service: cloudsql.googleapis.com
    bindings:
    - members:
      - user:[email protected]
      role: roles/editor
    - members:
      - user:[email protected]
      role: roles/owner
    etag: BwVM-FDzeYM=
    version: 1
    
  3. 新しい IAM ポリシーを作成します。

    gcloud projects set-iam-policy PROJECT_ID /tmp/policy.yaml
    

    上記のコマンドで別の変更との競合が報告された場合は、最初のステップからやり直してください。

JSON

YAML ではなく JSON 形式の IAM ポリシーを使用する場合は、上記の例のコマンドを次の gcloud コマンドに置き換えます。

gcloud projects get-iam-policy PROJECT_ID --format=json >/tmp/policy.json
gcloud projects set-iam-policy PROJECT_ID /tmp/policy.json

API

Cloud Resource Manager API を使用してデータアクセス監査ログを構成する手順は次のとおりです。

  1. getIamPolicy API メソッドに次のパラメータを指定して、プロジェクトの IAM ポリシーを読み取ります

    • リソース: projects/PROJECT_ID
    • リクエストの本文: 空白

    これにより、次のような現在のポリシー オブジェクトが返されます。このプロジェクトのポリシーには、まだ auditConfigs セクションはありません。

    {
      "version": 1,
      "etag": "BwXqwxkr40M=",
      "bindings": [
        {
          "role": "roles/owner",
          "members": [
            "user:[email protected]"
          ]
        }
      ]
    }
    
  2. 現在のポリシーを編集します。

    • auditConfigs セクションを変更または追加する。

      データアクセス監査ログを無効にする場合は、次のセクション auditConfigs:[] に空の値を含めます。

    • etag の値を保持する。

    次の手順で updateMask を設定する場合は、新しいポリシー オブジェクトから他のすべての情報を削除することもできます。編集したポリシー(ここでは Cloud SQL のデータ書き込み監査ログを有効にしています)を次に示します。

    {
      "policy": {
        "auditConfigs": [
          {
            "auditLogConfigs": [
              {
                "logType": "DATA_WRITE"
              }
            ],
            "service": "cloudsql.googleapis.com"
          }
        ],
        "etag": "BwXqwxkr40M="
      },
      "updateMask": "auditConfigs,etag"
    }
    
  3. setIamPolicy API メソッドに次のパラメータを指定して、新しいポリシーを書き込みます

    • リソース: projects/PROJECT_ID
    • リクエスト本文: 編集したポリシーを含めます。

setIamPolicy 更新マスク

このセクションでは、setIamPolicy メソッドの updateMask パラメータの重要性と、gcloud CLI の set-iam-policy コマンドを慎重に使用して、Google Cloud プロジェクトや組織に誤って被害を及ぼさないようにする方法を説明します。

setIamPolicy API methodupdateMask パラメータを使用して、更新されるポリシー フィールドを制御します。たとえば、マスクに bindings が含まれていない場合、誤ってそのポリシー セクションを変更することはできません。それに対し、マスクに bindings が含まれている場合、このセクションは常に更新されます。bindings の更新後の値を指定しない場合、そのセクションはポリシーから完全に削除されます。

setIamPolicy を呼び出す gcloud projects set-iam-policy コマンドでは、updateMask パラメータを指定できません。その代わりに、このコマンドは updateMask の値を次のように計算します。

  • updateMask には常にフィールド bindingsetag が含まれます。
  • set-iam-policy に渡されたポリシー オブジェクトにその他のトップレベル フィールド(auditConfigs など)が存在する場合、それらのフィールドが updateMask に追加されます。

これらのルールの結果として、set-iam-policy コマンドは次のように動作します。

  • 新しいポリシーで auditConfigs セクションを省略した場合、このセクションは更新マスクに含まれないため、auditConfigs セクションの以前の値(存在する場合)は変更されません。これは無害ですが、混乱を招く可能性があります。

  • 新しいポリシー オブジェクトで bindings を省略した場合、bindings セクションは更新マスクに存在するため、このセクションはポリシーから削除されます。これは非常に有害であり、すべてのプリンシパルが Google Cloud プロジェクトにアクセスできなくなります。

  • 新しいポリシー オブジェクトで etag を省略した場合、ポリシーに対する同時変更を確認できなくなり、自分が行った変更によって他の誰かの変更が誤って上書きされてしまう可能性があります。