データアクセスログの構成

このガイドでは、プロジェクトまたは組織でデータアクセス監査ログの要素を有効にして構成する方法について説明します。監査ログの概要については、Cloud Audit Logging をご覧ください。

管理アクティビティの監査ログはすべての Google Cloud Platform サービスに対して有効になっており、構成できません。

構成の概要

データアクセス監査ログ（BigQuery 用を除く）は、デフォルトで無効になっています。データアクセス監査ログの特定の要素を有効にして構成することができます。

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

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

サービスに固有の構成

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

特定の GCP サービスに対してデータアクセス監査ログを有効にできますが、全体の構成で有効にされた GCP サービスのデータアクセス監査ログを無効にすることはできません。
GCP サービスのデータアクセス監査ログに情報の種類を追加できますが、全体の構成で指定された情報の種類を削除することはできません。
除外リストにユーザーを追加できますが、全体の構成の除外リストからユーザーを削除することはできません。

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

組織、フォルダ、プロジェクトのデータアクセス監査ログを構成できます。階層全体にわたる GCP サービスの構成がある場合、その結果の構成はそれらの構成を結合したものになります。つまり、プロジェクトレベルでは、

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

アクセス制御

組織レベルでデータアクセス監査ログを構成するには IAM の役割 roles/resourcemanager.organizationAdmin、フォルダレベルでデータアクセス監査ログを構成するには roles/resourcemanager.folderAdmin、プロジェクトレベルでデータアクセス監査ログを構成するには roles/owner が必要です。

GCP Console でのデータアクセスログの構成

は、

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

こうしたタスクをプログラムで実行するために、API または Cloud SDK を使用することもできます。詳細については、API でのデータアクセスログの構成をご覧ください。

GCP Console の監査ログ構成オプションにアクセスするには、次の手順を実行します。

GCP Console で、左上のオーバーフローメニューから [IAM と管理] > [監査ログ] を選択します。

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

監査ログを有効にする

次の手順では、データアクセスログを有効にする方法を示します。

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

監査ログの構成

また、データアクセス監査ログを生成するすべての GCP サービスの監査ログを有効にすることもできます。[監査ログ] ページのメインの表で、[タイトル] の左側にあるボックスをクリックして、すべての GCP サービスを選択します。

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

監査ログを無効にする

次の手順では、データアクセスログを無効にする方法を示します。

[監査ログ] ページのメインの表で、[タイトル] 列のサービス名の左側にあるボックスをクリックして、1 つ以上の GCP サービスを選択します。
表の右側にある情報パネルの [ログタイプ] タブで、無効にするデータアクセス監査ログのタイプごとにボックスをオフにして、[保存] をクリックします。
監査ログが無効になると、表に灰色のダッシュが表示されます。有効な監査ログには緑色のチェックマークが付いています。

ユーザー除外を設定する

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

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

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

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

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

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

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

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

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

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

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

ここでは、API と Cloud SDK のコマンドラインインターフェースを使用してデータアクセス監査ログをプログラムで構成する方法について説明します。

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

IAM ポリシーオブジェクト

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

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

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

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

AuditConfig オブジェクト

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

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

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

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

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

次に、監査構成を JSON 形式と YAML 形式で記述した例を示します。Cloud SDK コマンドを使用するときは YAML 形式がデフォルトです。

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

一般的な構成

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

これらの構成では、プロジェクトの組織またはフォルダの監査ログ構成は考慮されていません。詳細については、組織の構成とプロジェクトの構成をご覧ください。

すべてのアクセスログを有効にする

次の 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

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

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

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

Cloud SDK には次の Cloud Resource Manager コマンドが用意されています。

gcloud projects get-iam-policy
gcloud projects set-iam-policy
gcloud organizations get-iam-policy
gcloud organizations set-iam-policy

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

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

最初のステップでポリシーを取得した後に他の誰かによってポリシーが変更されたことを Cloud Resource Manager が検出した場合、setIamPolicy は失敗します。これが起こった場合は、3 つのステップをもう一度やり直します。

例

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

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

Cloud SDK

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: セクションは、変更せずにそのままの状態にしておく必要があります。このようにしないと、プロジェクトを使用できなくなる場合があります。詳細については、次の setIamPolicy の更新マスクをご覧ください。
編集したポリシーの例（ここでは Cloud SQL のデータ書き込みデータアクセス監査ログを有効にしています）を次に示します。
```
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

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

getIamPolicy API メソッドに以下のパラメータを指定して、プロジェクトの IAM ポリシーを読み取ります。
- resource: projects/[PROJECT_ID]
- Request body: 空
これにより、次のような現在のポリシーオブジェクトが返されます。このプロジェクトのポリシーにはまだ 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 メソッドに以下のパラメータを指定して、新しいポリシーを書き込みます。
- resource: projects/[PROJECT_ID]
- Request body:
  - updateMask: "auditConfigs,etag"
  - policy: 編集済みのポリシーオブジェクト

setIamPolicy の更新マスク

このセクションでは、setIamPolicy メソッドにおける updateMask パラメータの重要性について説明し、SDK の set-iam-policy コマンドを実行する際にプロジェクトまたは組織に予期しない害が及ばないようにするため細心の注意を払わなければならない理由を示します。

setIamPolicy API メソッドには、更新するポリシーフィールドを制御するため、updateMask パラメータが用意されています。たとえば、マスクに bindings が含まれない場合、このポリシーセクションが誤って変更されるおそれはありません。その一方で、マスクに bindings が含まれる場合は、常に更新されます。bindings の更新値を含めなければ、このセクション全体がポリシーから削除されます。

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

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

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

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

データアクセス ログの構成

構成の概要

サービスに固有の構成

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

アクセス制御

GCP Console でのデータアクセス ログの構成

監査ログを有効にする

監査ログを無効にする

ユーザー除外を設定する

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

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

IAM ポリシー オブジェクト

AuditConfig オブジェクト

JSON

YAML

一般的な構成

すべてのアクセスログを有効にする

JSON

YAML

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

JSON

YAML

すべてのログを無効にする

JSON

YAML

getIamPolicy と setIamPolicy

例

Cloud SDK

API

setIamPolicy の更新マスク

フィードバックを送信...

GCP Console でのデータアクセスログの構成

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

IAM ポリシーオブジェクト