このガイドでは、プロジェクトまたは組織でデータアクセス監査ログの要素を有効にして構成する方法について説明します。監査ログの概要については、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 のロールが必要です。
- プロジェクト レベル: roles/owner
- フォルダレベル: roles/resourcemanager.folderAdmin
- 組織レベル: roles/resourcemanager.organizationAdmin
Cloud Console でのデータアクセス監査ログの構成
このセクションでは、Cloud Console を使用してデータアクセス監査ログを構成する方法について説明します。
API または gcloud
コマンドライン ツールを使用して、これらのタスクをプログラムで実行することもできます。詳細については、API を使用したデータアクセス監査ログの構成をご覧ください。
Cloud Console で監査ログ構成オプションにアクセスする方法は次のとおりです。
Cloud Console から、[IAM と管理] > [監査ログ] を選択します。
ページの上部にある既存の Google Cloud プロジェクト、フォルダ、組織を選択します。
監査ログを有効にする
データアクセス監査ログを有効にする方法は次のとおりです。
[監査ログ] ページのメインの表で、[タイトル] 列から 1 つ以上の Google Cloud サービスを選択します。
[ログタイプ] タブで、有効にするデータアクセス監査ログのタイプごとにボックスをオンにして、[保存] をクリックします。
監査ログが有効になると、表にチェックマークが表示されます。次の例では、Cloud Composer API サービスに対して [管理読み取り] と [データ読み取り] の監査ログが有効になっていることがわかります。
データアクセス監査ログを生成するすべての Google Cloud サービスの監査ログを有効にすることもできます。[監査ログ] ページのメインの表で、すべての Google Cloud サービスを選択します。
この一括構成方法は、現在利用可能な Google Cloud サービスにのみ適用されます。新しい Google Cloud サービスが追加されると、デフォルト監査構成が継承されます。
データアクセス監査ログの無効化
データアクセス監査ログを無効にする方法は次のとおりです。
[監査ログ] ページのメインの表で、1 つ以上の Google Cloud サービスを選択します。
[ログタイプ] タブで、無効にするデータアクセス監査ログの種類を選択し、[保存] をクリックします。
データアクセス監査ログが無効になっている場合は、表に灰色のダッシュが表示されます。有効になっているデータアクセス監査ログには緑色のチェックマークが表示されます。
ユーザー除外の設定
監査ログを生成するユーザーを制御するには、除外を設定します。除外されたユーザーを追加すると、選択したログタイプの監査ログがそのユーザーに対して作成されません。管理アクティビティ ログは、除外ステータスに関係なく常に生成されることに注意してください。
除外を設定する方法は次のとおりです。
[監査ログ] 構成ページのメインの表で、[タイトル] 列から 1 つ以上の Google Cloud サービスを選択します。
[除外ユーザー] タブを選択します。[除外されるユーザーを追加] に、選択したサービスの除外リストに追加するユーザーのメールアドレスを入力します。複数のユーザーを追加するには、[除外されるユーザーを追加] ボタンを必要な回数だけ選択します。
ユーザーに対して無効にするデータアクセス監査ログタイプのボックスを選択し、[保存] をクリックします。
除外されるユーザーをサービスに追加すると、表の [除外] 列の下に数が表示されます。
除外リストからユーザーを削除するには:
情報パネルの [除外ユーザー] タブに移動します。
ユーザー名の上にカーソルを置き、表示されるゴミ箱アイコンを選択します。
ユーザーの名前が取り消し線テキストで表示されたら、[保存] をクリックします。
除外されるユーザーの情報を編集するには:
情報パネルの [除外ユーザー] タブに移動します。
ユーザー名の右側にある展開矢印をクリックします。
ユーザーに適したデータアクセス監査ログのタイプを選択するか選択を解除し、[保存] をクリックします。
デフォルト構成の設定
プロジェクト、フォルダ、組織内のすべての新規および既存の Google Cloud サービスが継承する構成を指定できます。組織内のユーザーが使用を開始する新しい Google Cloud サービスが利用可能になった場合、このデフォルト構成を適用します。このサービスでは、他の Google Cloud サービス用に構成されている監査ログポリシーが継承され、データアクセス監査ログがキャプチャされます。
ページの上部にある [デフォルトの監査構成] をクリックします。
[ログタイプ] タブで、有効にするか無効にするデータアクセス監査ログのタイプごとにボックスをオンまたはオフにして、[保存] をクリックします。
[除外ユーザー] タブで、除外リストに追加するユーザーのメールアドレスを入力し、[保存] をクリックします。上記のユーザー除外の設定の手順に従います。
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 つのステップを行います。
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
ツールの 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
セクションは更新マスクに存在するため、このセクションはポリシーから削除されます。これは非常に有害であり、すべてのユーザーがプロジェクトにアクセスできなくなります。新しいポリシー オブジェクトで
etag
を省略した場合、ポリシーに対する同時変更を確認できなくなり、自分が行った変更によって他の誰かの変更が誤って上書きされてしまう可能性があります。