了解和使用 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 表示使用专门用于管理服务的内部 API 对客户内容执行的删除操作。 Google Cloud 此方法会更改客户内容和/或配置。
  • 删除 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 人员出于以下原因可以执行此类访问：

  • 执行因支持请求或调查比较复杂而需要进行的技术调试。
  • 修复技术问题，例如存储故障或数据损坏。
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 中创建提醒政策，从而了解指定时间段内的访问次数是否超过指定阈值。

后续步骤