アクセスの透明性ログの把握と使用

このページでは、アクセスの透明性ログエントリの内容とそれらを表示して使用する方法について説明します。

アクセスの透明性ログの詳細

アクセスの透明性ログを既存のセキュリティ情報およびイベント管理（SIEM）ツールに統合すると、Google の担当者がお客様のコンテンツにアクセスした際の監査を自動的化できます。アクセスの透明性ログは、Google Cloud Console で Cloud Audit Logs とともに確認できます。

アクセスの透明性ログエントリに含まれる詳細は次のとおりです。

  • 対象となるリソースとアクション。
  • 操作の時刻。
  • アクションの理由（カスタマー サポート リクエストに関連付けられたケース番号など）
  • コンテンツを操作している人についてのデータ（たとえば、Google 担当者の所在地など）

アクセスの透明性を有効にする

Google Cloud 組織でアクセスの透明性を有効にする方法については、アクセスの透明性を有効にするをご覧ください。

アクセスの透明性ログの表示

Google Cloud 組織のアクセスの透明性を構成したら、ユーザーまたはグループにプライベート ログ閲覧者のロールを割り当てることで、アクセスの透明性ログにアクセス可能なユーザーについての制御を設定できます。詳細については、Cloud Logging アクセス制御ガイドをご覧ください。

アクセスの透明性ログを表示するには、次の Google Cloud Observability ロギング フィルタを使用します。

logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Faccess_transparency"

ログ エクスプローラでアクセスの透明性ログを表示する方法については、ログ エクスプローラの使用をご覧ください。

また、Cloud Monitoring API または Cloud Functions を使用してログをモニタリングすることもできます。ご利用にあたっては、Cloud Monitoring のドキュメントをご覧ください。

オプション: ログベースの指標を作成し、ログによって明らかになる問題を適切なタイミングで認識できるよう、アラートポリシーを設定します。

アクセスの透明性ログエントリのサンプル

アクセスの透明性ログエントリの例を次に示します。

{
 insertId:  "abcdefg12345"
 jsonPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.TransparencyLog"
  location: {
   principalOfficeCountry:  "US"
   principalEmployingEntity:  "Google LLC"
   principalPhysicalLocationCountry:  "CA"
  }
  principalJobTitle: "Engineering"
  product: [
   0:  "Cloud Storage"
  ]
  reason: [
    detail:  "Case number: bar123"
    type:  "CUSTOMER_INITIATED_SUPPORT"
  ]
  eventId: "asdfg12345asdfg12345asdfg12345"
  accesses: [
   0: {
    methodName: "GoogleInternal.Read"
    resourceName: "//googleapis.com/storage/buckets/BUCKET_NAME/objects/foo123"
    }
  ]
  accessApprovals: [
   0: "projects/123/approvalRequests/abcdef12345"
  ]
 }
 logName:  "projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Faccess_transparency"
 operation: {
  id:  "12345xyz"
 }
 receiveTimestamp:  "2017-12-18T16:06:37.400577736Z"
 resource: {
  labels: {
   project_id:  "1234567890"
  }
  type:  "project"
 }
 severity:  "NOTICE"
 timestamp:  "2017-12-18T16:06:24.660001Z"
}

ログフィールドの説明

フィールド 説明
insertId ログの一意の識別子。
@type アクセスの透明性ログ識別子。
principalOfficeCountry アクセス者の永久デスクがある国の ISO 3166-1 alpha-2 国コード、場所が確認できない場合は ??、Google 担当者の所在地が人口の少ない国の場合は 3 文字の大陸識別子。
principalEmployingEntity アクセスしている Google 担当者を採用しているエンティティ（Google LLC など）
principalPhysicalLocationCountry アクセス元の国の ISO 3166-1 alpha-2 国コード、場所が確認できない場合は ??、Google の担当者の所在地が人口の少ない国の場合は 3 文字の大陸識別子。
principalJobTitle アクセスしている Google 担当者のジョブ ファミリー。
product アクセスされた、お客様の Google Cloud プロダクト。
reason:detail 理由の詳細。サポート チケット ID など。
reason:type アクセスの理由タイプ（例: CUSTOMER_INITIATED_SUPPORT)）。
accesses:methodName 行われたアクセスの種類。例: GoogleInternal.ReadmethodName フィールドに表示されるメソッドの詳細については、accesses: methodName フィールドの値をご覧ください。
accesses:resourceName アクセスされたリソースの名前。
accessApprovals アクセスを承認したアクセス承認リクエストのリソース名が含まれます。これらのリクエストは、除外とサポート対象サービスの対象になります。

このフィールドは、アクセスされたリソースに対してアクセス承認が有効になっている場合にのみ入力されます。2021 年 3 月 24 日より前に公開されたアクセスの透明性ログには、このフィールドは入力されません。
logName ログの場所の名前。
operation:id ログクラスタ ID。
receiveTimestamp ロギング パイプラインによってアクセスが受信された時刻。
project_id アクセスされたリソースに関連するプロジェクト。
type アクセスされたリソースのタイプ（project など）。
eventId 単一のアクセス イベントの理由（単一のサポートケースなど）に関連付けられた一意のイベント ID。同じ理由に記録されるすべてのアクセスに同じ event_id 値が設定されます。
severity ログの重大度。
timestamp ログが書き込まれた時刻。

accesses:methodNames フィールドの値

アクセスの透明性ログの accesses:methodNames フィールドには、次のメソッドが表示されます。

  • 標準メソッド: これらのメソッドは List、Get、Create、Update、Delete です。詳細については、標準メソッドをご覧ください。
  • カスタム メソッド: カスタム メソッドは、5 つの標準メソッド以外の API メソッドを指します。一般的なカスタム メソッドには、Cancel、BatchGet、Move、Search、Undelete があります。詳しくは、カスタム メソッドをご覧ください。
  • Google 内部メソッド: accesses:methodNames フィールドには、次の GoogleInternal メソッドが表示されます。
メソッド名 説明 Examples
GoogleInternal.Read 正当なビジネス上の理由で、お客様のコンテンツに対して行われた読み取りアクションを示します。読み取りアクションは、Google Cloud サービスの管理専用に設計された内部 API を使用して行われます。このメソッドでは、お客様のコンテンツは変更されません。 IAM 権限の読み取り。
GoogleInternal.Write 正当なビジネス上の正当な理由で、お客様のコンテンツに対して行われた書き込みアクションを示します。書き込みアクションは、Google Cloud サービスの管理専用に設計された内部 API を使用して行われます。このメソッドでは、お客様のコンテンツや構成を更新できます。
  • リソースの IAM 権限を設定する。
  • Compute Engine インスタンスを一時停止する。
GoogleInternal.Create ビジネス上の正当な理由で、お客様のコンテンツに対して行われた作成アクションを示します。作成アクションは、Google Cloud サービスの管理専用に設計された内部 API を使用して行われます。このメソッドにより、新しい顧客コンテンツが作成されます。
  • Cloud Storage のバケットを作成する
  • Pub/Sub トピックの作成
GoogleInternal.Delete Google Cloud サービスの管理専用に設計された内部 API を使用して、お客様のコンテンツに対して行われた削除アクションを示します。このメソッドでは、お客様のコンテンツや構成が変更されます。
  • Cloud Storage オブジェクトを削除する。
  • BigQuery テーブルを削除する。
GoogleInternal.List 正当なビジネス上の正当な理由で、お客様のコンテンツに対して行われたリスト アクションを示します。リスト アクションは、Google Cloud サービスの管理専用に設計された内部 API を使用して行われます。このメソッドでは、お客様のコンテンツや構成は変更されません。
  • お客様の Compute Engine インスタンスを一覧表示する。
  • お客様の Dataflow ジョブを一覧表示する。
GoogleInternal.SSH 正当なビジネス上の理由で、お客様の仮想マシンで実行された SSH アクションを示します。SSH アクセスは、Google Cloud サービスの管理専用に設計された内部 API を使用して行われます。このメソッドでは、お客様のコンテンツと構成を変更できます。 Compute Engine または Google Distributed Cloud の停止を復旧するための緊急アクセス。
GoogleInternal.Update 正当なビジネス上の理由で、お客様コンテンツに対して行われた変更を示します。更新アクションは、Google Cloud サービスの管理専用に設計された内部 API を使用して行われます。このメソッドでは、お客様のコンテンツや構成が変更されます。 Cloud Storage 内の HMAC キーを更新する。
GoogleInternal.Get 正当なビジネス上の理由で、顧客コンテンツに対して実行されたゲット アクションを示します。ゲット アクションは、Google Cloud サービスの管理専用に設計された内部 API を使用します。このメソッドでは、お客様のコンテンツや構成は変更されません。
  • リソースの IAM ポリシーを取得する。
  • お客様の Dataflow ジョブを取得する。
GoogleInternal.Query 正当なビジネス上の理由で、お客様のコンテンツに対して行われたクエリ アクションを示します。クエリ アクションは、Google Cloud サービスの管理専用に設計された内部 API を使用して行われます。このメソッドでは、お客様のコンテンツや構成は変更されません。
  • BigQuery クエリの実行。
  • お客様のコンテンツに対する AI Platform のデバッグ コンソールの検索。

GoogleInternal アクセスは、正当かつ監査可能なアクセスについて、承認されたユーザーに厳密に制限されます。メソッドの存在により、すべてのロールを使用できるわけではありません。プロジェクトまたは組織に対する管理アクセスの制御を強化したい組織は、Access Approval を有効にして、アクセスの詳細に基づいてアクセスを承認または拒否することができます。たとえば、Access Approval のユーザーは、Customer Support ロールを持つ Google 社員からのリクエストに対して、CUSTOMER_INITIATED_SUPPORT の理由があるリクエストのみを許可できます。詳細については、Access Approval の概要をご覧ください。

イベントが厳格な緊急アクセス基準を満たしている場合、Access Approval はその緊急アクセスを auto approved ステータスで記録できます。アクセスの透明性と Access Approval は、緊急アクセスシナリオで中断のないロギングを行うように特別に設計されています。

ワークロードに対するデータ セキュリティの制御を強化したい場合は、Assured Workloads を使用することをおすすめします。Assured Workloads プロジェクトでは、データ所在地、主権管理、Compute Engine での Confidential Computing などの機能へのアクセスなどの強化された機能が提供されます。外部管理の暗号鍵には、Key Access Justifications を利用します。

正当化理由コード

理由 説明
CUSTOMER_INITIATED_SUPPORT お客様が開始したサポート（例: 「ケース番号: ####」）。
GOOGLE_INITIATED_SERVICE

システム管理とトラブルシューティングのために Google が開始したアクセスを指します。Google の担当者がこの種のアクセスを行う理由は次のとおりです。

  • 複雑なサポート リクエストや調査に必要な技術的なデバッグを行う。
  • ストレージ障害やデータ破損などの技術的問題を解決する。
THIRD_PARTY_DATA_REQUEST 法的要請または法的手続きに対応するために Google が開始したアクセス（Google がお客様自身のデータにアクセスする必要がある法的手続きに対応する場合など）。
GOOGLE_INITIATED_REVIEW 次のようなセキュリティ、詐欺、乱用、コンプライアンスに関する目的で Google が開始したアクセス:
  • お客様のアカウントおよびデータの安全性とセキュリティを確保する
  • アカウントのセキュリティに影響を与える可能性のあるイベント（マルウェア感染など）によってデータが影響を受けるかどうかを確認する
  • お客様が Google 利用規約に準拠して Google サービスを使用しているかどうかを確認する
  • 他のユーザーやお客様からの申し立て、または不正行為の兆候を調査する
  • Google サービスが、関連するコンプライアンス制度（マネーロンダリング防止規制など）と一貫して使用されていることを確認する
GOOGLE_RESPONSE_TO_PRODUCTION_ALERT

システムの信頼性を維持するために Google が開始したアクセスを指します。Google の担当者がこの種のアクセスを行う理由は次のとおりです。

  • 疑わしいサービス停止がお客様に影響しないかどうかを調べて確認する。
  • 停電やシステム障害からのバックアップと復旧を確実に行う。

アクセスの透明性ログのモニタリング

Cloud Monitoring API を使用して、アクセスの透明性ログをモニタリングできます。ご利用にあたっては、Cloud Monitoring のドキュメントをご覧ください。

ログベースの指標を設定し、監査ログによって明らかになる問題を適切なタイミングで認識できるよう、アラート ポリシーを設定します。たとえば、Google の担当者がユーザーのコンテンツ アクセスをキャプチャするログベースの指標を作成し、特定の期間内のアクセス数が指定されたしきい値を超過したことを知らせるアラート ポリシーを Monitoring に作成できます。

次のステップ