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

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

始める前に

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

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

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

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

  • データアクセス ログを含む、_Required バケットと _Default バケットのすべてのログに対するアクセス権の取得に必要な権限を取得するには、プロジェクトに対するプライベート ログ閲覧者（roles/logging.privateLogViewer）の IAM ロールを付与するように管理者へ依頼してください。

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

    編集者ロール（roles/editor）には、データアクセス ログの表示に必要な権限が含まれていません。

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

構成の概要

Google Cloud リソースとサービスに対してデータアクセス監査ログを有効にする方法を構成できます。

  • 組織: 組織に対してデータアクセス監査ログを有効にして、構成できます。この設定は、既存か新規かにかかわらず、組織内のすべてのGoogle Cloud プロジェクトとフォルダに適用されます。

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

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

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

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

  • 権限タイプ: 特定のタイプの権限のみをチェックする Google Cloud API が監査ログを出力するように指定できます。詳細については、このページの権限タイプをご覧ください。

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

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

権限タイプ

API メソッドは IAM 権限をチェックします。各 IAM 権限には、type プロパティで定義される権限タイプがあります。権限タイプには、データアクセス権限タイプと管理アクティビティ権限タイプがあります。

  • データアクセス権限タイプ:

    • ADMIN_READ: このタイプの IAM 権限は、メタデータまたは構成情報を読み取るGoogle Cloud API メソッドでチェックされます。通常、ADMIN_READ 監査ログはデフォルトで無効になっているため、有効にする必要があります。

    • DATA_READ: このタイプの IAM 権限は、ユーザー提供データを読み取るGoogle Cloud API メソッドでチェックされます。通常、DATA_READ 監査ログはデフォルトで無効になっているため、有効にする必要があります。

    • DATA_WRITE: このタイプの IAM 権限では、ユーザー提供データを書き込むGoogle Cloud API メソッドでチェックされます。通常、DATA_WRITE 監査ログはデフォルトで無効になっているため、有効にする必要があります。

  • 管理アクティビティ権限タイプ:

    • ADMIN_WRITE: このタイプの IAM 権限は、メタデータまたは構成情報を書き込むGoogle Cloud API メソッドで検証されます。このタイプに関連付けられた監査ログ（管理アクティビティ監査ログ）はデフォルトで有効になっており、無効にすることはできません。

サービスの権限タイプを有効または無効にするには、Google Cloud コンソールを使用するか、API を呼び出す必要があります。

ほとんどの Google Cloud API は、呼び出し元に 1 つの IAM 権限があるかどうかのみをチェックします。API が呼び出されているサービスで、権限に関連付けれている権限タイプが有効になっている場合、API は監査ログを生成します。

以降のセクションでは、 Google CloudAPI メソッドが IAM 権限をチェックするその他の方法について説明します。どの権限タイプでどのメソッドがチェックされるかについては、サービスの監査ロギングに関するドキュメントをご覧ください。

データアクセス権限タイプの IAM 権限チェック

一部の Google Cloud API メソッドは、呼び出し元に異なるデータアクセス権限タイプの IAM 権限が複数付与されているかどうかをチェックします。これらのデータアクセス権限のいずれかがプロジェクトで有効になっていると、監査ログが書き込まれます。

たとえば、API メソッドは、API リクエストを発行するプリンシパルに example.resource.get（DATA_READ）権限と example.resource.write（DATA_WRITE）権限があることをチェックします。サービスが呼び出し時に監査ログを出力するには、プロジェクトで DATA_WRITE または DATA_READ のいずれかが有効になっている必要があります。

管理アクティビティとデータアクセスでチェックされる IAM 権限タイプ

一部の Google Cloud API メソッドは、ADMIN_WRITE 権限タイプの IAM 権限と、データアクセス権限タイプの 1 つ以上の権限をチェックします。

このような API 呼び出しは、管理アクティビティ監査ログを出力します。これはデフォルトで有効になっており、無効にすることはできません。

サービスが所有していない IAM 権限をチェックする API メソッド

一部の Google Cloud サービスには、別のサービスで特定の権限タイプが有効になっている場合にのみ監査ログを生成する API メソッドがあります。

たとえば、Cloud Billing には、Resource Manager が所有する ADMIN_READ 権限タイプをチェックする API メソッドがあります。Cloud Billing API に関連付けられた監査ログを有効にするには、サービス cloudresourcemanager.googleapis.com で ADMIN_READ を有効にする必要があります。

同じ API メソッドで異なる IAM 権限を確認する

一部の Google Cloud API では、メソッドの呼び出し方法によって、監査ログを生成するためにプロジェクトで有効にする必要のある IAM 権限の種類が決まります。

たとえば、Spanner のある API メソッドでは、その呼び出し方法に応じて DATA_WRITE タイプの IAM 権限をチェックする場合と DATA_READ タイプの IAM 権限をチェックする場合があります。この場合、プロジェクトで Spanner の DATA_WRITE を有効にすると、API 呼び出しで DATA_WRITE タイプの IAM 権限がチェックされた場合にのみ、API に関連付けられた監査ログが有効になります。

サービスに固有の構成

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

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

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

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

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

Google Cloud MCP サーバーは、サービス固有のデータアクセス監査ログ（形式: SERVICE_NAME.googleapis.com/mcp）を書き込みます。これらのデータアクセス ログを有効にするには、IAM AuditConfig オブジェクトで mcp.googleapis.com の監査ロギングを有効にします。Google Cloud MCP サーバーの監査ロギングの詳細については、Google Cloud MCP サーバーの監査ロギングをご覧ください。

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": [
          "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

一般的な構成

以下に、 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 データアクセス監査ログは無効にできません。

getIamPolicy と setIamPolicy

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: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 のデータ書き込みデータアクセス監査ログを有効にしています）:

    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

    上の例に示すように、ポリシーの先頭に 4 行追加されています。

  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
    • リクエストの本文: 空白

    このメソッドは、現在のポリシー オブジェクトを返します。

    {
  "version": 1,
  "etag": "BwXqwxkr40M=",
  "bindings": [
    {
      "role": "roles/owner",
      "members": [
        "user:myself@example.com"
      ]
    }
  ]
}

    上の例では、プロジェクトのポリシーに auditConfigs セクションがありません。

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

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

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

    • etag の値を保持する。

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

    {
  "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 メソッドには、更新するポリシー フィールドを制御する 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 セクションは更新マスクに存在するため、このセクションはポリシーから削除されます。これは非常に有害であり、すべてのプリンシパルが Google Cloud プロジェクトにアクセスできなくなります。

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