了解和使用 Access Transparency 日志
本页面介绍了 Access Transparency 日志条目的内容,以及如何查看和使用它们。
Access Transparency 日志详情
Access Transparency 日志可以与现有的安全信息和事件管理 (SIEM) 工具集成,以便在 Google 员工访问您的内容时自动执行审核。Access Transparency 日志 与 Cloud Audit Logs 一起提供。
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 |
包含已批准访问权限的 Access Approval 请求的资源名称。这些请求须遵守例外情况和受支持的服务。 只有为 访问的资源在此日期之前发布的 Access Transparency 日志 2021 年 3 月 24 日不会填充此字段。 |
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 methods:以下
GoogleInternal
方法可以出现在accesses:methodNames
字段中:
方法名称 | 说明 | 示例 |
---|---|---|
GoogleInternal.Read |
表示对客户内容执行的读取操作,具有有效的业务理由。读取操作是使用专门用于管理 Google Cloud 服务的内部 API 执行的。此方法不会更改客户内容。 | 读取 IAM 权限。 |
GoogleInternal.Write |
表示对客户内容执行的写入操作具有有效的业务理由。写入操作是使用专门用于管理 Google Cloud 服务的内部 API 执行的。此方法可以更新客户内容和/或配置。 |
|
GoogleInternal.Create |
表示对客户内容执行的创建操作,并具有有效的业务理由。创建操作是使用专门用于管理 Google Cloud 服务的内部 API 执行的。此方法会创建新的客户内容。 |
|
GoogleInternal.Delete |
表示使用专为管理 Google Cloud 服务而设计的内部 API 对客户内容执行的删除操作。该方法会更改客户内容和/或配置。 |
|
GoogleInternal.List |
表示对客户内容执行的列表操作具有有效的业务理由。列表操作是使用专门用于管理 Google Cloud 服务的内部 API 执行的。此方法不会更改客户内容或配置。 |
|
GoogleInternal.SSH |
表示在客户虚拟机上执行的 SSH 操作具有有效的业务理由。SSH 访问是使用专门用于管理 Google Cloud 服务的内部 API 进行的。该方法可能会更改客户内容和配置。 | 紧急访问权限,可在 Compute Engine 或 Google Distributed Cloud 的服务中断中恢复服务。 |
GoogleInternal.Update |
表示对客户内容进行了修改,并且具备有效的业务理由。更新操作是使用专门用于管理 Google Cloud 服务的内部 API 执行的。该方法会更改客户内容和/或配置。 | 更新 Cloud Storage 中的 HMAC 密钥。 |
GoogleInternal.Get |
表示对客户内容执行了 get 操作,且具有有效的业务理由。get 操作使用专为管理 Google Cloud 服务而设计的内部 API 进行。此方法不会更改客户内容或配置。 |
|
GoogleInternal.Query |
表示对客户内容执行的查询操作具有有效的业务理由。查询操作是使用专门用于管理 Google Cloud 服务的内部 API 执行的。此方法不会更改客户内容或配置。 |
|
只有经过授权的人员才能进行 GoogleInternal
访问,只有经过授权的人员才能对其进行正当、可审核的访问。某个方法的存在并不代表所有角色都具备这个能力。想要增强对项目或组织的管理员权限的控制的组织可以激活 Access Approval,以根据访问权限详细信息批准或拒绝访问。例如,对于拥有 Customer Support
角色的 Google 员工提出的请求,Access Approval 用户可以选择仅允许具有 CUSTOMER_INITIATED_SUPPORT
理由的请求。如需了解详情,请参阅 Access Approval 概览。
如果某个事件符合严格的紧急访问条件,Access Approval 可以将该紧急访问记录为状态为 auto approved
的事件。Access Transparency 和 Access Approval 专为在紧急访问场景中实现不间断日志记录而设计。
如果您希望对工作负载进行更多数据安全控制,我们建议您使用 Assured Workloads。Assured Workloads 项目提供增强型功能,例如数据驻留、主权控制,以及对 Compute Engine 中的机密计算等功能的访问权限。对于外部管理的加密密钥,它利用 Key Access Justifications 功能。
理由原因代码
指 Google 发起的系统管理和
问题排查。Google 人员出于以下原因可以执行此类访问:
是指 Google 为维持系统可靠性而发起的访问。Google
用户出于以下原因进行此类访问:
原因
说明
CUSTOMER_INITIATED_SUPPORT
客户发起的支持,例如“Case Number:####”。
GOOGLE_INITIATED_SERVICE
THIRD_PARTY_DATA_REQUEST
Google 按照法律要求或司法程序发起的访问,包括 Google 在客户要求的情况下按照司法程序访问客户自己的数据。
GOOGLE_INITIATED_REVIEW
Google 发起的针对安全性、欺诈、滥用或合规性目的访问,包括:
GOOGLE_RESPONSE_TO_PRODUCTION_ALERT
Monitoring Access Transparency 日志
您可以使用 Cloud Monitoring API 监控 Access Transparency 日志。要开始使用,请参阅 Cloud Monitoring 文档。
您可以设置基于日志的指标,然后设置一项提醒政策,以便及时了解这些日志中呈现的问题。例如,您可以创建一个基于日志的指标, Google 员工访问您的内容,然后在 通过此监控,您可以了解 超过指定的阈值。