了解和使用 Access Transparency 日志

本页面介绍了 Access Transparency 日志条目的内容，以及如何查看和使用它们。

Access Transparency 日志详情

Access Transparency 日志可以与现有的安全信息和事件管理 (SIEM) 工具集成，以便在 Google 员工访问您的内容时自动执行审核。除了 Cloud Audit Logs 日志之外， Google Cloud 控制台中还提供 Access Transparency 日志。

Access Transparency 日志条目包含以下类型的详细信息：

受影响的资源和操作。
操作的执行时间。
执行该操作的原因（例如，与客户支持请求有关的案例号）。
有关对内容采取操作的人员的数据（例如，Google 员工所在的位置）。

启用 Access Transparency

如需了解如何为 Google Cloud 组织启用 Access Transparency，请参阅启用 Access Transparency。

查看 Access Transparency 日志

为 Google Cloud组织配置 Access Transparency 后，您可以通过为用户或组分配 Private Logs Viewer 角色来控制哪些人可以访问 Access Transparency 日志。如需了解详情，请参阅 Cloud Logging 访问权限控制指南。

如需查看 Access Transparency 日志，请使用以下 Google Cloud Observability 日志记录过滤器。

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

如需了解如何在日志浏览器中查看 Access Transparency 日志，请参阅使用日志浏览器。

您还可以使用 Cloud Monitoring API 或使用 Cloud Run 函数来监控日志。要开始使用，请参阅 Cloud Monitoring 文档。

可选：创建一个基于日志的指标，然后设置一个提醒政策，以便及时了解这些日志中出现的问题。

Access Transparency 日志条目示例

以下是一个 Access Transparency 日志条目的示例。

{
 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`	Access Transparency 日志标识符。
`principalOfficeCountry`	访问者在其中具有永久服务台的国家/地区的 ISO 3166-1 二位字母国家/地区代码。如果位置未知，则为 `??`；如果 Google 员工身处低人口国家/地区，则为 3 字符大洲标识符。
`principalEmployingEntity`	雇用了 Google 员工进行访问的实体（例如 `Google LLC`）。
`principalPhysicalLocationCountry`	进行访问所在国家/地区的 ISO 3166-1 二位字母国家/地区代码。如果位置未知，则为 `??`；如果 Google 员工身处低人口国家/地区，则为 3 字符大洲标识符。
`principalJobTitle`	进行访问的 Google 员工的职位系列。
`product`	所访问的客户 Google Cloud 产品。
`reason:detail`	原因的详细信息，例如支持服务工单 ID。
`reason:type`	访问原因类型（例如 `CUSTOMER_INITIATED_SUPPORT)`。
`accesses:methodName`	进行了哪种类型的访问。例如 `GoogleInternal.Read`。如需详细了解 `methodName` 字段中可能显示的方法，请参阅 `accesses: methodName` 字段的值。
`accesses:resourceName`	被访问资源的名称。
`accessApprovals`	包含批准访问的访问审批请求的资源名称。这些请求受例外情况和支持的服务的约束。只有在为所访问的资源启用访问审批时，系统才会填充此字段。2021 年 3 月 24 日之前发布的 Access Transparency 日志不会填充此字段。
`logName`	日志位置的名称。
`operation:id`	日志集群 ID。
`receiveTimestamp`	日志记录流水线接收访问的时间。
`project_id`	与被访问资源相关联的项目。
`type`	被访问资源的类型（例如 `project`）。
`eventId`	与单个访问事件正当理由（例如，单个支持请求）相关联的唯一事件 ID。记录到同一正当理由的所有访问权限都具有相同的 `event_id` 值。
`severity`	日志严重性。
`timestamp`	写入日志的时间。

`accesses:methodNames` 字段的值

Access Transparency 日志的 accesses:methodNames 字段中可能会显示以下方法：

标准方法：这些方法包括 List、Get、Create、Update 和 Delete。如需了解详情，请参阅标准方法。
自定义方法：自定义方法是指 5 个标准方法之外的 API 方法。常见的自定义方法包括 Cancel、BatchGet、Move、Search 和 Undelete。如需了解详情，请参阅自定义方法。
GoogleInternal 方法：以下是 accesses:methodNames 字段中显示的 GoogleInternal 方法的示例：

方法名称	说明	示例
`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.Update`	表示对客户内容进行了修改，且具有正当的业务理由。更新操作通过专门为管理 Google Cloud 服务而设计的内部 API 进行。此方法会更改客户内容和/或配置。	更新 Cloud Storage 中的 HMAC 密钥。
`GoogleInternal.Get`	表示对客户内容执行了具有有效业务理由的获取操作。get 操作通过专门为管理 Google Cloud 服务而设计的内部 API 进行。此方法不会更改客户内容或配置。	检索资源的 IAM 政策。检索客户的 Dataflow 作业。
`GoogleInternal.Query`	表示对客户内容执行了查询操作，且具有有效的业务理由。查询操作通过专门为管理 Google Cloud 服务而设计的内部 API 进行。此方法不会更改客户内容或配置。	运行 BigQuery 查询。 AI Platform 调试控制台在客户内容中查找。

GoogleInternal 访问权限受到严格限制，仅授权人员可进行有正当理由且可审核的访问。方法的存在并不表示所有角色都可以使用该方法。如果组织希望增强对项目或组织管理员权限的控制，可以启用访问权限审批，以便根据访问权限详细信息批准或拒绝访问权限。例如，Access Approval 用户可以选择仅允许 Google 员工提出的请求具有 CUSTOMER_INITIATED_SUPPORT 理由。如需了解详情，请参阅访问审批概览。

如果某个事件符合严格的紧急访问条件，Access Approval 可以记录该紧急访问，并将其状态设为 auto approved。Access Transparency 和 Access Approval 专门设计用于在紧急访问场景中提供不间断的日志记录。

如果您希望对工作负载拥有更强大的数据安全控制权，建议您使用 Assured Workloads。Assured Workloads 项目提供增强的功能，例如数据驻留、主权控制，以及对 Compute Engine 中机密计算等功能的访问权限。它利用密钥访问理由来管理外部托管的加密密钥。

理由原因代码

原因	说明
`CUSTOMER_INITIATED_SUPPORT`	客户发起的支持，例如“Case Number：####”。
`GOOGLE_INITIATED_SERVICE`	指 Google 为进行系统管理和问题排查而发起的访问。Google 人员可能会出于以下原因进行此类访问：执行复杂支持请求或调查所需的技术调试。修复技术问题，例如存储故障或数据损坏。客户技术支持团队提供主动式支持。标记为“TAM 支持”并附有原因详情
`THIRD_PARTY_DATA_REQUEST`	Google 按照法律要求或司法程序发起的访问，包括 Google 在客户要求的情况下按照司法程序访问客户自己的数据。
`GOOGLE_INITIATED_REVIEW`	Google 发起的针对安全性、欺诈、滥用或合规性目的访问，包括：确保客户账号和数据的安全性。确认数据是否受到可能影响账号安全的事件（例如，恶意软件感染）的影响。确认客户是否按照 Google 服务条款使用 Google 服务。调查其他用户和客户的投诉，或其他可能表明存在滥用行为的迹象。检查 Google 服务的使用是否符合相关合规性制度（例如，反洗钱条例）。
`GOOGLE_RESPONSE_TO_PRODUCTION_ALERT`	指 Google 为维持系统可靠性而发起的访问。Google 人员可以出于以下原因进行此类访问：调查并确认疑似服务中断不会影响客户。确保在服务中断和系统故障时能够进行备份和恢复。

Monitoring Access Transparency 日志

您可以使用 Cloud Monitoring API 监控 Access Transparency 日志。要开始使用，请参阅 Cloud Monitoring 文档。

您可以设置基于日志的指标，然后设置一项提醒政策，以便及时了解这些日志中呈现的问题。例如，您可以创建一个基于日志的指标，用于捕获 Google 员工访问您的内容的情况，然后在 Monitoring 中创建提醒政策，从而了解指定时间段内的访问次数是否超过指定阈值。

后续步骤

了解如何查看和了解 Google Workspace 服务的 Access Transparency 日志。