このガイドでは、プロジェクトまたは組織でデータアクセス監査ログの要素を有効にして構成する方法について説明します。監査ログの概要については、Cloud Audit Logging をご覧ください。
管理アクティビティの監査ログはすべての Google Cloud Platform サービスに対して有効になっており、構成できません。
構成の概要
データアクセス監査ログ（BigQuery 用を除く）は、デフォルトで無効になっています。データアクセス監査ログの特定の要素を有効にして構成することができます。
組織。組織内の既存のプロジェクトとフォルダおよび新規のプロジェクトとフォルダのすべてに適用される組織内のデータアクセス監査ログを有効にして構成できます。
フォルダ。フォルダ内の既存のプロジェクトと新規のプロジェクトすべてに適用されるフォルダ内のデータアクセス監査ログを有効にして構成できますが、プロジェクトの組織で有効になっているデータアクセス監査ログを無効にすることはできません。
プロジェクト。個々のプロジェクトに対してデータアクセス監査ログを構成できますが、プロジェクトの組織またはフォルダで有効になっているデータアクセス監査ログを無効にすることはできません。
デフォルト構成。データアクセス監査ログの作成を開始する将来の GCP サービスに適用されるデフォルトのデータアクセス監査ログ構成を、組織、フォルダ、またはプロジェクトで指定できます。
サービス。監査ログを収集する対象のサービスを指定できます。たとえば、Compute Engine の監査ログを使用するものの、Cloud SQL の監査ログは使用しないことが可能です。監査ログを生成できる GCP サービスのリストについては、監査ログ付きの Google サービスをご覧ください。
情報の種類。監査ログに含める情報の種類を指定できます。データアクセス監査ログ情報には次の 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.setIamPolicyCloud 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内のポリシーを編集し、データアクセス監査ログの構成のみを追加または変更します。編集したポリシーの例（ここでは 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
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}
- resource:
現在のポリシーを編集します。
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: 編集済みのポリシー オブジェクト
- updateMask:
- resource:
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を省略した場合、ポリシーに対する同時変更を確認できなくなり、自分が行った変更によって他の誰かの変更が誤って上書きされてしまう可能性があります。
ご不明な点がありましたら、Google の