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

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

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

構成の概要

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

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

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

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

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

  • デフォルト構成。データアクセス監査ログの作成を開始する Google 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 サービスのデータアクセス監査ログに情報の種類を追加することはできますが、より幅広い構成で指定されている情報の種類は削除できません。

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

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

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

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

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

  • ユーザーを除外リストに追加することはできますが、組織またはフォルダの除外リストに含まれるユーザーは削除できません。

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

アクセス制御

Google Cloud リソースのデータアクセス監査ログを構成するには、次の Identity and Access Management のロールが必要です。

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

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

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

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

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

    [監査ログ] ページに移動

  2. ページの上部にある既存の Google Cloud プロジェクト、フォルダ、組織を選択します。

監査ログを有効にする

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

  1. [監査ログ] ページのメインの表で、[タイトル] 列から 1 つ以上の Google Cloud サービスを選択します。

  2. [ログタイプ] タブで、有効にするデータアクセス監査ログのタイプごとにボックスをオンにして、[保存] をクリックします。

  3. 監査ログが有効になると、表にチェックマークが表示されます。次の例では、Cloud Composer API サービスに対して [管理読み取り] と [データ読み取り] の監査ログが有効になっていることがわかります。

    監査ログの構成

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

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

データアクセス監査ログの無効化

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

  1. [監査ログ] ページのメインの表で、1 つ以上の Google Cloud サービスを選択します。

  2. [ログタイプ] タブで、無効にするデータアクセス監査ログの種類を選択し、[保存] をクリックします。

  3. データアクセス監査ログが無効になっている場合は、表に灰色のダッシュが表示されます。有効になっているデータアクセス監査ログには緑色のチェックマークが表示されます。

ユーザー除外の設定

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

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

  1. [監査ログ] 構成ページのメインの表で、[タイトル] 列から 1 つ以上の Google Cloud サービスを選択します。

  2. [除外ユーザー] タブを選択します。[除外されるユーザーを追加] に、選択したサービスの除外リストに追加するユーザーのメールアドレスを入力します。複数のユーザーを追加するには、[除外されるユーザーを追加] ボタンを必要な回数だけ選択します。

  3. ユーザーに対して無効にするデータアクセス監査ログタイプのボックスを選択し、[保存] をクリックします。

  4. 除外されるユーザーをサービスに追加すると、表の [除外] 列の下に数が表示されます。

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

  1. 情報パネルの [除外ユーザー] タブに移動します。

  2. ユーザー名の上にカーソルを置き、表示されるゴミ箱アイコンを選択します。

  3. ユーザーの名前が取り消し線テキストで表示されたら、[保存] をクリックします。

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

  1. 情報パネルの [除外ユーザー] タブに移動します。

  2. ユーザー名の右側にある展開矢印をクリックします。

  3. ユーザーに適したデータアクセス監査ログのタイプを選択するか選択を解除し、[保存] をクリックします。

デフォルト構成の設定

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

  1. ページの上部にある [デフォルトの監査構成] をクリックします。

  2. [ログタイプ] タブで、有効にするか無効にするデータアクセス監査ログのタイプごとにボックスをオンまたはオフにして、[保存] をクリックします。

  3. [除外ユーザー] タブで、除外リストに追加するユーザーのメールアドレスを入力し、[保存] をクリックします。上記のユーザー除外の設定の手順に従います。

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

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

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

IAM ポリシー オブジェクト

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

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

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

次のセクションでは、AuditConfig オブジェクトについて詳しく説明します。構成の変更に使用する API コマンドと gcloud ツールコマンドについては、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 形式で記述した例を示します。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

一般的な構成

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

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

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

次の 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 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 コマンドと 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:colleague@example.com
      role: roles/editor
    - members:
      - user:myself@example.com
      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:colleague@example.com
      role: roles/editor
    - members:
      - user:myself@example.com
      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

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

  1. 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
    

    }

  2. 現在のポリシーを編集します。

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

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

    • etag の値を保持する。

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

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

    • リソース: projects/PROJECT_ID
    • リクエストの本文:
      • updateMask: "auditConfigs,etag"
      • policy: 編集済みのポリシー オブジェクト

setIamPolicy の更新マスク

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

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 セクションは更新マスクに存在するため、このセクションはポリシーから削除されます。これは非常に有害であり、すべてのユーザーがプロジェクトにアクセスできなくなります。

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