このガイドでは、Cloud プロジェクト、請求先アカウント、フォルダ、組織で、データアクセス監査ログの一部またはすべてを有効または無効にする方法について説明します。
始める前に
データアクセス監査ログの構成に進む前に、次の情報を理解してください。
データアクセス監査ログ(BigQuery を除く)は、デフォルトで無効になっています。BigQuery 以外の Google Cloud サービスのデータアクセス監査ログを書き込むには、明示的に有効にする必要があります。
データアクセス監査ログは、Google サポートでアカウントの問題をトラブルシューティングする際に役立ちます。そのため、可能な場合は、データアクセス監査ログを有効にすることをおすすめします。
管理アクティビティ監査ログは、すべての Google Cloud サービスで有効になっており、構成できません。
構成の概要
Google Cloud リソースおよびサービスに対して、データアクセス監査ログの特定の要素を有効にして構成できます。
組織: 組織内の既存のプロジェクトとフォルダおよび新規の Cloud プロジェクトとフォルダのすべてに適用される組織内のデータアクセス監査ログを有効にして構成できます。
フォルダ: フォルダ内の既存の Cloud プロジェクトと新規のプロジェクトすべてに適用されるフォルダ内のデータアクセス監査ログを有効にして構成できますが、プロジェクトの親組織で有効になっているデータアクセス監査ログを無効にすることはできません。
プロジェクト: 個々の Cloud プロジェクトに対してデータアクセス監査ログを構成できます。プロジェクトの親組織またはフォルダで有効になっているデータアクセス監査ログを無効にすることはできません。
請求先アカウント: 請求先アカウントのデータアクセス監査ログを構成するには、Google Cloud CLI を使用します。データアクセス監査ログと請求先アカウントで gcloud CLI を使用する方法については、
gcloud beta billing accounts set-iam-policy
コマンドのリファレンス ドキュメントをご覧ください。デフォルト構成: データアクセス監査ログの作成を開始する Google Cloud サービスに適用する組織、フォルダ、または Cloud プロジェクトで、デフォルトのデータアクセス監査ログ構成を指定できます。
サービス: 監査ログを収集する対象のサービスを指定できます。たとえば、Cloud SQL ではなく Compute Engine からの監査ログを使用することもできます。監査ログを生成できる Google Cloud サービスのリストについては、監査ログを使用する Google サービスをご覧ください。
オペレーション: データアクセス監査ログに記録するオペレーションの種類を構成できます。There are three types of operations that can be recorded:
ADMIN_READ
: メタデータまたは構成情報を読み取るオペレーションを記録します。これらのオペレーションは無効にできません。DATA_READ
: ユーザー提供データを読み取るオペレーションを記録します。DATA_WRITE
: ユーザー提供データを書き込むオペレーション
たとえば、Cloud DNS は 3 種類のオペレーションすべてを書き込みますが、
DATA_WRITE
オペレーションのみを記録するようにデータアクセス監査ログを構成できます。除外されたユーザーとグループ: 特定のユーザーまたはグループを、データアクセスを記録する対象から除外できます。たとえば、内部テスト アカウントを除外し、このアカウントが行った Cloud デバッガに対するオペレーションをログに記録しないようにできます。
データアクセス監査ログは、IAM 監査ログコンソールまたは API を使用して構成できます。これらの方法については、下記のセクションで説明します。
サービスに固有の構成
Google Cloud サービス全体(allServices
)の構成と特定の Google Cloud サービス用の構成が両方とも存在する場合、結果的にそのサービスに適用される構成は、2 つの構成を結合したものになります。つまり、
特定の Google Cloud サービスでデータアクセス監査ログを有効にすることはできますが、より幅広い構成で有効になっている Google Cloud サービスのデータアクセス監査ログは無効にできません。
Google Cloud サービスのデータアクセス監査ログに情報の種類を追加することはできますが、より幅広い構成で指定されている情報の種類は削除できません。
除外リストにユーザーとグループを追加できますが、全体の構成の除外リストからは削除できません。
BigQuery Data Transfer Service では、デフォルトの監査ログ構成からデータアクセス監査ログの構成が継承されます。
プロジェクト、フォルダ、組織の構成
Cloud プロジェクト、フォルダ、組織のデータアクセス監査ログを構成できます。階層内に Google Cloud サービスの構成が存在する場合、結果的にその構成は、2 つの構成の結合したものになります。つまり、Cloud プロジェクト レベルでは:
Google Cloud サービスのログは有効にできますが、フォルダまたは組織で有効になっている Google Cloud サービスのログは無効にできません。
情報の種類を有効にすることはできますが、組織やフォルダで有効になっている情報の種類を無効にすることはできません。
除外リストにユーザーとグループを追加できますが、組織やフォルダの除外リストからは削除できません。
組織またはフォルダレベルでは、Cloud プロジェクトでデータアクセス監査ログが構成されていなくても、その組織またはフォルダ内にある Cloud プロジェクトに対してデータアクセス監査ログを有効にできます。
アクセス制御
Identity and Access Management のロールと権限は、データアクセス監査ログの構成の基礎となる IAM ポリシーの表示や管理など、Logging データへのアクセスを制御します。
データアクセス構成に関連付けられたポリシーを表示または設定するには、適切なリソースレベルの権限を持つロールが必要です。これらのリソースレベルのロールを付与する方法については、Cloud プロジェクト、フォルダ、組織へのアクセスを管理するをご覧ください。
IAM ポリシーを設定するには、
resourcemanager.RESOURCE_TYPE.setIamPolicy
権限を持つロールが必要です。IAM ポリシーを表示するには、
resourcemanager.RESOURCE_TYPE.getIamPolicy
権限を持つロールが必要です。
データアクセス監査ログを表示するために必要な権限とロールのリストについては、Logging アクセス制御ガイドをご覧ください。
Cloud Console でのデータアクセス監査ログの構成
このセクションでは、Cloud Console を使用してデータアクセス監査ログを構成する方法について説明します。
API または Google Cloud CLI を使用して、これらのタスクをプログラムで実行することもできます。詳しくは、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 CLI を使用してデータアクセス監査ログをプログラムで構成する方法について説明します。
これらのタスクの多くは、Cloud Console を使用して実行することもできます。詳細については、Cloud Console でのデータアクセス監査ログの構成をご覧ください。
IAM ポリシー オブジェクト
API を使用してデータアクセス監査ログを構成するには、Cloud プロジェクト、フォルダ、組織に関連付けられた IAM ポリシーを編集する必要があります。監査ログの構成は、ポリシーの auditConfigs
セクションにあります。
"auditConfigs": [
{
object(AuditConfig)
}
]
詳細については、IAM ポリシータイプをご覧ください。
次のセクションでは、AuditConfig
オブジェクトについて詳しく説明します。構成の変更に使用する API コマンドと gcloud CLI コマンドについては、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 形式で記述した例を示します。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
一般的な構成
以下に、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
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 つのステップを行います。
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
内のポリシーを編集し、データアクセス監査ログの構成のみを追加または変更します。編集したポリシーの例(ここでは 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: 編集済みのポリシー オブジェクト
- updateMask:
- リソース:
setIamPolicy
更新マスク
このセクションでは、setIamPolicy
メソッドの updateMask
パラメータの重要性と、gcloud CLI の set-iam-policy
コマンドを慎重に使用して、プロジェクトや組織に誤って被害を及ぼさないようにする方法を説明します。
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
を省略した場合、ポリシーに対する同時変更を確認できなくなり、自分が行った変更によって他の誰かの変更が誤って上書きされてしまう可能性があります。