データアクセス監査ログを構成する

このガイドでは、Cloud プロジェクト、請求先アカウント、フォルダ、組織でデータアクセス監査ログの要素を有効にして構成する方法について説明します。

始める前に

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

データアクセス監査ログ（BigQuery を除く）は、デフォルトで無効になっています。BigQuery 以外の Google Cloud サービスのデータアクセス監査ログを書き込むには、明示的に有効にする必要があります。
データアクセス監査ログは、Google サポートがアカウントに関する問題のトラブルシューティング行うのに役立ちます。そのため、可能であればデータアクセス監査ログを有効にすることをおすすめします。
管理アクティビティ監査ログは、すべての Google Cloud サービスで有効になっており、構成できません。

構成の概要

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

組織。組織内の既存のプロジェクトとフォルダおよび新規の Cloud プロジェクトとフォルダのすべてに適用される組織内のデータアクセス監査ログを有効にして構成できます。
フォルダ。フォルダ内の既存のプロジェクトと新規の Cloud プロジェクトすべてに適用されるフォルダ内のデータアクセス監査ログを有効にして構成できますが、プロジェクトの組織で有効になっているデータアクセス監査ログを無効にすることはできません。
プロジェクト。個々の Cloud プロジェクトに対してデータアクセス監査ログを構成できますが、プロジェクトの組織またはフォルダで有効になっているデータアクセス監査ログを無効にすることはできません。
請求先アカウント。請求先アカウントのデータアクセス監査ログを構成するには、gcloud コマンドラインツールを使用します。データアクセス監査ログと請求先アカウントで gcloud ツールを使用する方法については、gcloud beta billing accounts set-iam-policy コマンドのリファレンスドキュメントをご覧ください。
デフォルト構成。データアクセス監査ログの作成を開始する将来の GCP サービスに適用されるデフォルトのデータアクセス監査ログ構成を、組織、フォルダ、または Cloud プロジェクトで指定できます。
サービス。監査ログを収集する対象のサービスを指定できます。たとえば、Cloud SQL ではなく Compute Engine からの監査ログを使用することもできます。監査ログを生成できる Google Cloud サービスのリストについては、監査ログを生成する Google サービスをご覧ください。
情報の種類。監査ログに含める情報の種類を指定できます。データアクセス監査ログ情報には次の 3 つの種類があります。
- 管理読み取り: メタデータまたは構成情報を読み取るオペレーションを記録します。
  
  管理アクティビティ監査ログには、メタデータまたは構成情報の書き込みが記録されます。無効にすることはできません。
- データ読み取り: ユーザー提供データを読み取るオペレーションを記録します。
- データ書き込み: ユーザー提供データを書き込むオペレーションを記録します。
たとえば、「データ書き込み」オペレーションのみをログに記録し、Cloud DNS からは 3 種類の情報すべてを記録できます。
除外ユーザー。特定のユーザーまたはグループを、データアクセスを記録する対象から除外できます。たとえば、内部テストアカウントを除外し、このアカウントが行った Cloud デバッガに対するオペレーションをログに記録しないようにできます。

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

サービスに固有の構成

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

特定の Google Cloud サービスでデータアクセス監査ログを有効にすることはできますが、より幅広い構成で有効になっている Google Cloud サービスのデータアクセス監査ログは無効にできません。
Google Cloud サービスのデータアクセス監査ログに情報の種類を追加することはできますが、より幅広い構成で指定されている情報の種類は削除できません。
ユーザーを除外リストに追加することはできますが、より幅広い構成の除外リストからユーザーを削除することはできません。

プロジェクト、フォルダ、組織の構成

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

Google Cloud サービスのログは有効にできますが、フォルダまたは組織で有効になっている Google Cloud サービスのログは無効にできません。
情報の種類を有効にすることはできますが、組織やフォルダで有効になっている情報の種類を無効にすることはできません。
ユーザーを除外リストに追加することはできますが、組織またはフォルダの除外リストに含まれるユーザーは削除できません。
組織またはフォルダレベルでは、Cloud プロジェクトでデータアクセス監査ログが構成されていなくても、その組織またはフォルダ内にある Cloud プロジェクトに対してデータアクセス監査ログを有効にできます。

アクセス制御

Identity and Access Management のロールと権限は、Logging データへのアクセスを制御します。

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

Cloud Console でのデータアクセス監査ログの構成

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

API または gcloud コマンドラインツールを使用して、これらのタスクをプログラムで実行することもできます。詳細については、API を使用したデータアクセス監査ログの構成をご覧ください。

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

Cloud Console から、[IAM と管理] > [監査ログ] を選択します。

[監査ログ] ページに移動
ページの上部にある既存の Cloud プロジェクト、フォルダ、組織を選択します。

監査ログを有効にする

データアクセス監査ログを有効にする方法は次のとおりです。

[監査ログ] ページのメインの表で、[タイトル] 列から 1 つ以上の Google Cloud サービスを選択します。
[ログタイプ] タブで、有効にするデータアクセス監査ログのタイプごとにボックスをオンにして、[保存] をクリックします。
監査ログが有効になると、表にチェックマークが表示されます。次の例では、Cloud Composer API サービスに対して [管理読み取り] と [データ読み取り] の監査ログが有効になっていることがわかります。

データアクセス監査ログを生成するすべての Google Cloud サービスの監査ログを有効にすることもできます。[監査ログ] ページのメインの表で、すべての Google Cloud サービスを選択します。

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

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

データアクセス監査ログを無効にする方法は次のとおりです。

[監査ログ] ページのメインの表で、1 つ以上の Google Cloud サービスを選択します。
[ログタイプ] タブで、無効にするデータアクセス監査ログの種類を選択し、[保存] をクリックします。
データアクセス監査ログが無効になっている場合は、表に灰色のダッシュが表示されます。有効になっているデータアクセス監査ログには緑色のチェックマークが表示されます。

ユーザー除外を設定する

監査ログを生成するユーザーを制御するには、除外を設定します。除外されたユーザーを追加すると、選択したログタイプの監査ログがそのユーザーに対して作成されません。管理アクティビティログは、除外ステータスに関係なく常に生成されることに注意してください。

除外を設定する方法は次のとおりです。

[監査ログ] 構成ページのメインの表で、[タイトル] 列から 1 つ以上の Google Cloud サービスを選択します。
[除外ユーザー] タブを選択します。[除外されるユーザーを追加] に、選択したサービスの除外リストに追加するユーザーのメールアドレスを入力します。複数のユーザーを追加するには、[除外されるユーザーを追加] ボタンを必要な回数だけ選択します。
ユーザーに対して無効にするデータアクセス監査ログタイプのボックスを選択し、[保存] をクリックします。
除外されるユーザーをサービスに追加すると、表の [除外] 列の下に数が表示されます。

除外リストからユーザーを削除するには:

情報パネルの [除外ユーザー] タブに移動します。
ユーザー名の上にカーソルを置き、表示されるゴミ箱アイコンを選択します。
ユーザーの名前が取り消し線テキストで表示されたら、[保存] をクリックします。

除外されるユーザーの情報を編集するには:

情報パネルの [除外ユーザー] タブに移動します。
ユーザー名の右側にある展開矢印をクリックします。
ユーザーに適したデータアクセス監査ログのタイプを選択するか選択を解除し、[保存] をクリックします。

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

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

ページの上部にある [デフォルトの監査構成] をクリックします。
[ログタイプ] タブで、有効にするか無効にするデータアクセス監査ログのタイプごとにボックスをオンまたはオフにして、[保存] をクリックします。
[除外ユーザー] タブで、除外リストに追加するユーザーのメールアドレスを入力し、[保存] をクリックします。上記のユーザー除外の設定の手順に従います。

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

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

これらのタスクの多くは、Cloud Console を使用して実行することもできます。詳細については、Cloud Console でのデータアクセス監査ログの構成をご覧ください。

IAM ポリシーオブジェクト

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

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

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

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

`AuditConfig` 個のオブジェクト

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

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

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

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

PRINCIPAL は、データアクセス監査ログが収集されないユーザーです。単一のユーザー、グループ、またはサービスアカウントを指定できます。Binding タイプではさまざまな種類のメンバーを記述できますが、それらすべてのメンバーをデータアクセス監査ログの構成に使用できるわけではありません。

次に、監査構成を JSON 形式と YAML 形式で記述した例を示します。YAML 形式は、gcloud コマンドラインツールを使用する場合のデフォルトです。

JSON

"auditConfigs": [
  {
    "auditLogConfigs": [
      {
        "logType": "ADMIN_READ"
      },
      {
        "logType": "DATA_WRITE"
      },
      {
        "logType": "DATA_READ"
      }
    ],
    "service": "allServices"
  },
  {
    "auditLogConfigs": [
      {
        "exemptedMembers": [
          "499862534253-compute@developer.gserviceaccount.com"
        ],
        "logType": "ADMIN_READ"
      }
    ],
    "service": "cloudsql.googleapis.com"
  }
],

YAML

auditConfigs:
- auditLogConfigs:
  - logType: ADMIN_READ
  - logType: DATA_WRITE
  - logType: DATA_READ
  service: allServices
- auditLogConfigs:
  - exemptedMembers:
    - 499862534253-compute@developer.gserviceaccount.com
    logType: ADMIN_READ
  service: cloudsql.googleapis.com

一般的な構成

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

これらの構成には、プロジェクトの組織またはフォルダ内の監査ログ構成は含まれません。詳細については、組織の構成と 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 に対してデータアクセス監査ログを有効にします。ユーザー定義データの書き込みのみをログに記録します。

JSON

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

YAML

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

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

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

JSON

"auditConfigs": [],

YAML

auditConfigs:

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

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

`getIamPolicy` と `setIamPolicy`

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

Resource Manager API には次のメソッドがあります。

projects.getIamPolicy
projects.setIamPolicy
organizations.getIamPolicy
organizations.setIamPolicy

gcloud コマンドラインツールには、次の 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 つのステップを行います。

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

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

例

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

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

gcloud

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

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

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

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

bindings:
- members:
  - user:colleague@example.com
  role: roles/editor
- members:
  - user:myself@example.com
  role: roles/owner
etag: BwVM-FDzeYM=
version: 1

/tmp/policy.yaml 内のポリシーを編集し、データアクセス監査ログの構成のみを追加または変更します。

注意: bindings: セクションと etag: セクションは、変更せずにそのままの状態にしておく必要があります。このようにしないと、Cloud プロジェクトを使用できなくなる場合があります。詳細については、次の setIamPolicy の更新マスクをご覧ください。
編集したポリシーの例（ここでは Cloud SQL のデータ書き込みデータアクセス監査ログを有効にしています）を次に示します。先頭に 4 行追加されています。
```
auditConfigs:
- auditLogConfigs:
  - logType: DATA_WRITE
  service: cloudsql.googleapis.com
bindings:
- members:
  - user:colleague@example.com
  role: roles/editor
- members:
  - user:myself@example.com
  role: roles/owner
etag: BwVM-FDzeYM=
version: 1
```
新しい 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

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

getIamPolicy API メソッドに次のパラメータを指定して、プロジェクトの IAM ポリシーを読み取ります。
- リソース: projects/PROJECT_ID
- リクエストの本文: 空白
これにより、次のような現在のポリシーオブジェクトが返されます。このポリシーにはまだ auditConfigs セクションはありません。
```
{
  "bindings": [
  {
    "members": [
      "user:colleague@example.com"
    ],
    "role": "roles/editor"
  },
  {
    "members": [
      "user:myself@example.com"
    ],
    "role": "roles/owner"
  }
],
"etag": "BwUsv2gimRs=",
"version": 1
```
}
現在のポリシーを編集します。
- auditConfigs セクションを変更または追加する。
  
  データアクセス監査ログを無効にする場合は、次のセクション auditConfigs:[] に空の値を含めます。
- etag の値を保持する。
次の手順で updateMask を設定する場合は、新しいポリシーオブジェクトから他のすべての情報を削除することもできます。編集したポリシー（ここでは Cloud SQL のデータ書き込み監査ログを有効にしています）を次に示します。
```
{
  "auditConfigs": [
    {
      "auditLogConfigs": [
        {
          "logType": "DATA_WRITE"
        }
      ],
      "service": "cloudsql.googleapis.com"
    }
  ],
  "etag": "BwVM-FDzeYM="
}
```
setIamPolicy API メソッドに次のパラメータを指定して、新しいポリシーを書き込みます。
- リソース: projects/PROJECT_ID
- リクエストの本文:
  - updateMask: "auditConfigs,etag"
  - policy: 編集済みのポリシーオブジェクト

`setIamPolicy` 更新マスク

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

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

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

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

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

新しいポリシーで auditConfigs セクションを省略した場合、このセクションは更新マスクに含まれないため、auditConfigs セクションの以前の値（存在する場合）は変更されません。これは無害ですが、混乱を招く可能性があります。
新しいポリシーオブジェクトで bindings を省略した場合、bindings セクションは更新マスクに存在するため、このセクションはポリシーから削除されます。これは非常に有害であり、すべてのユーザーが Cloud プロジェクトにアクセスできなくなります。
新しいポリシーオブジェクトで etag を省略した場合、ポリシーに対する同時変更を確認できなくなり、自分が行った変更によって他の誰かの変更が誤って上書きされてしまう可能性があります。

データアクセス監査ログを構成する

始める前に

構成の概要

サービスに固有の構成

プロジェクト、フォルダ、組織の構成

アクセス制御

Cloud Console でのデータアクセス監査ログの構成

監査ログを有効にする

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

ユーザー除外を設定する

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

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

IAM ポリシー オブジェクト

AuditConfig 個のオブジェクト

JSON

YAML

一般的な構成

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

JSON

YAML

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

JSON

YAML

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

JSON

YAML

getIamPolicy と setIamPolicy

例

gcloud

API

setIamPolicy 更新マスク

IAM ポリシーオブジェクト

`AuditConfig` 個のオブジェクト

`getIamPolicy` と `setIamPolicy`

`setIamPolicy` 更新マスク