保护服务帐号的最佳做法

服务帐号与用户帐号不同,服务帐号既是资源,又是主帐号

  • 作为主帐号,您可以向服务帐号授予对资源(例如 Cloud Storage 存储分区)的访问权限。
  • 作为资源,服务帐号可以访问,并且可能会被其他主帐号(例如用户或群组)模拟

为保护服务帐号,请考虑其双重性质:

  • 由于服务帐号是主帐号,因此您必须限制其权限,以降低被盗用服务帐号可能造成的潜在危害。
  • 由于服务帐号是一种资源,因此您必须防止它被盗用。

服务帐号可能被滥用的方式有以下几种:

  • 提升权限:不法分子可能会通过模拟服务帐号而访问他们无权访问的资源。
  • 仿冒:不法分子可能会使用服务帐号模拟来模糊其身份。
  • 不可否认性:不法分子可能会使用服务帐号代表其执行操作,以此来隐藏其身份和操作。在某些情况下,可能无法跟踪不法分子的这些操作。
  • 信息披露:不法分子可能会从存在的某些服务帐号派生有关基础架构、应用或进程的信息。

本指南介绍限制服务帐号权限和缓解这些主要风险的最佳做法。

限制服务帐号权限

服务帐号是主帐号,可以获得对常规用户帐号等资源的访问权限。

不对默认服务帐号使用自动角色授予功能

当您首次在 Google Cloud 项目中启用 API 时,某些 Google Cloud 服务会创建默认服务帐号。默认情况下,这些服务帐号会被授予 Cloud 项目的 Editor 角色 (roles/editor),这样他们可以读取和修改 Cloud 项目中的所有资源。授予此角色是为了方便您使用,但这对于服务帐号正常工作并不是必需的:如需访问 Cloud 项目中的资源,Google Cloud 服务使用服务代理,而不是默认服务帐号。

如需防止默认服务帐号自动被授予 Editor 角色,请为您的组织启用停用默认服务帐号的自动 IAM 授权 (constraints/iam.automaticIamGrantsForDefaultServiceAccounts) 限制条件。如需将该限制条件应用于多个 Cloud 项目,请在文件夹或组织节点上配置该限制条件。应用该限制条件不会从现有默认服务帐号中移除 Editor 角色。

将服务帐号关联到虚拟机实例时,请勿依赖于访问权限范围

将服务帐号附加到虚拟机实例后,您可以指定一个或多个访问权限范围。通过访问权限范围,您可以限制虚拟机可以访问的服务。除了 Identity and Access Management (IAM) 政策外,还会应用这些限制。

访问权限范围的粒度较粗。例如,使用 https://www.googleapis.com/auth/devstorage.read_only 范围,您可以限制对 Cloud Storage 只读操作的访问权限,但不能限制对特定存储分区的访问权限。因此,访问权限范围不是适合精细 IAM 政策的替代项。

创建一个专用服务帐号并使用精细 IAM 政策来限制服务帐号可以访问的资源,而不是依赖于访问权限范围。

避免使用群组向服务帐号授予资源访问权限

在组织中,多个员工履行类似或重叠的工作职责是很常见,因此需要类似的资源访问权限。借助群组,您可以利用这些类似的访问权限来减少管理开销。

服务帐号应供应用使用。多个应用履行相同的职责,因此访问权限要求相同或类似是很少见的情况。相反,应用往往是唯一的,并且每个应用需要访问的资源通常都各不相同。

使用群组为服务帐号授予对资源的访问权限可能会导致一些不良后果:

  • 群组数激增,每个群组只包含一个或几个服务帐号。
  • 权限蔓延:随着时间的推移,群组被授予越来越多的资源的访问权限,但每个群组成员只需要一部分资源的访问权限。

除非群组的用途明确定义,否则最好避免使用群组;而是直接为服务帐号授予所需的资源访问权限。

避免使用全网域授权

全网域授权功能使服务帐号能够模拟 Cloud Identity 或 Google Workspace 帐号中的任何用户。通过全网域授权功能,服务帐号可以在 Google Workspace 和 Cloud Identity 中执行特定管理任务,也可以从 Google Cloud 外部访问不支持服务帐号的 Google API。

全网域授权功能不会限制服务帐号模拟特定用户,但它允许模拟 Cloud Identity 或 Google Workspace 帐号中的任何用户(包括超级用户)。因此,允许服务帐号使用全网域授权功能可能会使服务帐号很容易成为提升权限攻击的目标。

如果您可以直接通过服务帐号或使用 OAuth 同意流程来完成任务,请避免使用全网域授权功能。

如果您无法避免使用全网域授权功能,请限制服务帐号可以使用的 OAuth 范围集。虽然 OAuth 范围不会限制服务帐号可以模拟的用户,但会限制服务帐号可以访问的用户数据类型。

使用凭据访问边界来缩小访问令牌权限范围

Google 访问令牌是不记名令牌,这意味着其使用与任何特定应用都无关。如果您的应用将访问令牌传递给其他应用,则其他应用可以按照与您的应用相同的方式来使用令牌。同样,如果访问令牌泄露给不法分子,则他们可以使用该令牌来获取访问权限。

由于访问令牌是不记名令牌,因此您必须防止它们泄露或显示给未经授权方。您可以限制泄露的访问令牌授予访问权限的资源,从而限制该泄露的访问令牌可能造成的潜在损害。此过程称为缩小权限范围。

每当您将访问令牌传递给其他应用或您的应用的不同组件时,使用凭据访问边界可缩小访问令牌权限范围。设置访问边界,以便令牌能够授予足够的对所需资源的访问权限,但不能授予更多。

使用角色建议来确定未使用的权限

首次部署应用时,您可能不确定该应用实际需要的角色和权限。因此,您为该应用的服务帐号授予的权限可能在数量上会超出其实际需要的权限。

同样,应用的访问权限要求可能会随着时间的推移而变化,并且您可能不需要最初授予的某些角色和权限。

使用角色建议来确定应用实际使用的权限以及可能未使用的权限。调整受影响资源的 IAM 政策,以确保仅授予应用实际需要的访问权限。

使用横向移动数据分析来限制横向移动

横向移动是指一个项目中的服务帐号有权模拟另一个项目中的服务帐号。例如,服务帐号可能是在项目 A 中创建的,但具有在项目 B 中模拟服务帐号的权限。

这些权限可能导致项目之间发生一系列模拟,这些模拟会为主帐号授予对资源的意外访问权限。例如,主帐号可以模拟项目 A 中的服务帐号,然后使用该服务帐号模拟项目 B 中的服务帐号。如果项目 B 中的服务帐号有权模拟组织中其他项目中的其他服务帐号,则主帐号可以继续使用服务帐号模拟从一个项目移动到另一个项目,从而在移动时获取权限。

Recommender 提供了横向移动数据分析,可帮助您缓解此问题。横向移动数据分析可识别允许一个项目中的服务帐号模拟另一个项目中的服务帐号的角色。如需了解如何直接查看和管理横向移动数据分析,请参阅管理横向移动数据分析

一些横向移动数据分析与角色建议相关联。您可以应用这些建议,以减少项目之间的横向移动。如需了解具体方法,请参阅查看和应用建议

防范提升权限威胁

未被授予任何角色、无法访问任何资源且未与任何防火墙规则关联的服务帐号通常价值有限。为服务帐号授予对资源的访问权限之后,服务帐号的价值会提高:该服务帐号对您更为有用,但它也会更容易成为提升权限攻击的目标。

例如,假设一个对包含敏感信息的 Cloud Storage 存储分区具有完整访问权限的服务帐号。在这种情况下,该服务帐号实际上与 Cloud Storage 存储分区本身一样重要:不法分子可能会尝试控制该服务帐号,而不是试图直接访问存储分区。如果该尝试成功,不法分子可能会通过模拟该服务帐号来提升其权限,进而能够访问存储分区中的敏感信息。

涉及服务帐号的提升权限方法通常分为以下几个类别:

  • 直接模拟:您可能无意中向用户授予模拟服务帐号或为服务帐号创建服务帐号密钥的权限。如果服务帐号比用户本身的权限更高,则用户可以使用该功能提升其权限并获取用户无法访问的资源的访问权限。
  • 间接模拟:如果用户无法直接模拟服务帐号,则当 CI/CD 流水线、虚拟机实例或用户可以访问的其他自动化系统使用该服务帐号时,用户可能可以间接执行此操作:如果系统未实现适当的访问权限限制,则用户可以让系统执行他们自己无法执行的操作,从而提升他们的权限。
  • IAM 政策、群组或自定义角色修改:无权访问特权服务帐号的用户可能仍有权修改服务帐号、所属的 Cloud 项目或文件夹的 IAM 政策。然后,用户可以扩展其中一个 IAM 政策,以向自己授予(直接或间接)模拟服务帐号的权限。

以下部分介绍了保护服务帐号免遭提升权限威胁的最佳做法。

避免让用户模拟权限高于用户自身的服务帐号

通过模拟服务帐号,用户可以获取对服务帐号可访问的部分或全部资源的访问权限。如果服务帐号具有的访问权限比用户广泛,则服务帐号的权限实际上高于用户。

授予用户模拟权限更高的服务帐号的权限是一种特意让用户提升其权限的方式,这类似于在 Linux 上使用 sudo 工具或在 Windows 上使用进程提升。除非您面对必须临时提升权限的情况,否则最好避免让用户模拟权限更高的服务帐号。

使用户能够模拟服务帐号的权限包括:

  • iam.serviceAccounts.getAccessToken
  • iam.serviceAccounts.getOpenIdToken
  • iam.serviceAccounts.actAs
  • iam.serviceAccounts.implicitDelegation
  • iam.serviceAccountKeys.create
  • iam.serviceAccountKeys.get
  • deploymentmanager.deployments.create
  • cloudbuild.builds.create

具有其中一些权限的角色包括(但不限于):

  • Owner (roles/owner)
  • Editor (roles/editor)
  • Service Account User (roles/iam.serviceAccountUser)
  • Service Account Token Creator (roles/iam.serviceAccountTokenCreator)
  • Service Account Key Admin (roles/iam.serviceAccountKeyAdmin)
  • Service Account Admin (roles/iam.serviceAccountAdmin)
  • Workload Identity User (roles/iam.workloadIdentityUser)
  • Deployment Manager Editor (roles/deploymentmanager.editor)
  • Cloud Build Editor (roles/cloudbuild.builds.editor)

在将上述任何角色分配给用户之前,请先问自己:

  • 用户通过模拟服务帐号可以获取当前 Cloud 项目内部和外部的哪些资源的访问权限?
  • 此访问权限级别是否合理?
  • 是否有足够的保护措施来控制用户在哪些情况下可以模拟服务帐号?

如果无法确认所有问题,请勿分配角色。而是应考虑为用户提供其他权限较低的服务帐号。

避免让用户更改权限更高的服务帐号的 IAM 政策

服务帐号的 IAM 政策会捕获允许使用或模拟服务帐号的用户。拥有特定服务帐号的 iam.serviceAccounts.setIamPolicy 权限的用户可以修改或扩展 IAM 政策。包含该权限的角色包括:

  • Owner (roles/owner)
  • Security Admin (roles/iam.securityAdmin)
  • Service Account Admin (roles/iam.serviceAccountAdmin)

具有 iam.serviceAccounts.setIamPolicy 权限的角色可让用户完全控制服务帐号:

  • 该用户可以授予自己模拟服务帐号的权限,这样便有权访问与服务帐号相同的资源。
  • 该用户可以向其他用户授予相同或类似的对该服务帐号的访问级别:

在将上述任何角色分配给用户之前,请先问自己用户通过模拟服务帐号可以获取当前 Cloud 项目内部和外部的哪些资源的访问权限?如果服务帐号具有的访问权限超出用户,请勿允许用户更改服务帐号的 IAM 政策

不允许用户创建或上传服务帐号密钥。

借助服务帐号密钥,应用或用户可以以服务帐号的身份进行身份验证。与其他形式的服务帐号模拟不同,使用服务帐号密钥不需要以前任何形式的身份验证,即拥有服务帐号密钥的任何人都可以使用该密钥。

使用服务帐号密钥进行身份验证的实际结果与其他模拟形式类似。如果您授予用户对服务帐号密钥的访问权限,或授予其创建新服务帐号密钥的权限,则用户可以模拟服务帐号,并可以访问该服务帐号可访问的所有资源。

创建上传服务帐号密钥需要 iam.serviceAccountKeys.create 权限,Service Account Key Admin (roles/iam.serviceAccountKeyAdmin) 和 Service Account Key Editor (roles/editor) 角色具有此权限。

为用户分配包含 iam.serviceAccountKeys.create 权限的任何角色之前,请考虑这样做之后用户可以通过模拟服务帐号来获取当前 Cloud 项目内部和外部哪些资源的访问权限。不允许用户为比其拥有更多权限的服务帐号创建服务帐号密钥。

如果您的 Cloud 项目完全不需要服务帐号密钥,请对 Cloud 项目或所属文件夹应用停用服务帐号密钥创建功能停用服务帐号密钥上传功能组织政策限制条件。这些限制条件会阻止所有用户创建和上传服务帐号密钥,包括具有服务帐号的 iam.serviceAccountKeys.create 权限的用户。

请勿在 Cloud 项目或文件夹级层向服务帐号授予访问权限

服务帐号属于资源,是资源层次结构的一部分。因此,您可以在以下任何级层管理服务帐号的访问权限:

  • 单个服务帐号
  • 所属的 Cloud 项目
  • Cloud 项目祖先实体中的文件夹
  • 组织节点

在 Cloud 项目级层或资源层次结构的更高级层管理访问权限有助于减少管理开销,但也可能会导致过度授权。例如,如果您为用户授予 Cloud 项目中的 Service Account Token Creator 角色,则用户可以模拟 Cloud 项目中的任何服务帐号。能够模拟任何服务帐号意味着用户可能会获取这些服务帐号可以访问的所有资源的访问权限,包括该 Cloud 项目外部的资源。

为避免此类过度授权,请勿在 Cloud 项目或文件夹级层管理服务帐号的访问权限;而是要分别管理每个服务帐号的访问权限。

请勿从关联了特权服务帐号的计算资源上受保护程度较低的来源运行代码

当您将服务帐号附加到计算资源(例如虚拟机实例或 Cloud Run 应用)后,在该资源上运行的进程可以使用元数据服务器来请求访问令牌和 ID 令牌。这些令牌允许进程模拟服务帐号并代表其访问资源。

默认情况下,并非只有特定进程或用户才能访问元数据服务器。相反,在计算资源上执行的任何代码都可以访问元数据服务器并获取访问令牌。此类代码可能包括:

  • 应用的代码。
  • 由最终用户提交的代码(如果您的应用允许任何服务器端脚本评估)。
  • 从远程源代码库读取的代码(如果计算资源属于 CI/CD 系统)。
  • 由 Cloud Storage 存储分区提供的启动和关停脚本
  • 由虚拟机管理器分配的客机政策

如果代码是由用户提交的,或者是从远程存储位置读取的,则您必须确保它可信,并且远程存储位置至少与关联的服务帐号一样受保护。如果与服务帐号相比,远程存储位置受到妥善保护的效果欠佳,则不法分子可能可以提升其权限。不法分子可以通过将使用服务帐号权限的恶意代码注入到该位置来实现此目的。

限制对关联了特权服务帐号的虚拟机的 shell 访问权限

一些计算资源支持交互式访问,并使用户能够获取对系统的 shell 访问权限。例如:

  • Compute Engine 可让您使用 SSH 或 RDP 登录虚拟机实例。
  • Google Kubernetes Engine 可让您使用 kubectl exec 在 Kubernetes 容器中运行命令或启动 shell。

如果虚拟机实例关联了特权服务帐号,则任何对系统具有 shell 访问权限的用户都可以模拟该特权服务帐号并代表其访问资源。为防止用户滥用此功能来提升其权限,您必须确保 shell 访问权限至少与关联的服务帐号一样受保护。

对于 Linux 实例,您可以使用 OS Login 强制 SSH 访问权限比对关联的服务帐号的访问权限更具限制性:如需连接到启用了 OS Login 的虚拟机实例,用户不仅必须有权使用 OS Login,而且还必须具有对关联的服务帐号的 iam.serviceAccounts.actAs 权限。

相同级别的访问权限控制不适用于使用基于元数据的密钥的虚拟机实例或 Windows 实例:将 SSH 密钥发布到元数据请求 Windows 凭据需要虚拟机实例元数据的访问权限和关联服务帐号的 iam.serviceAccounts.actAs 权限。但是,发布 SSH 密钥或获得 Windows 凭据后,后续登录不需要进行任何其他 IAM 权限检查。

同样,如果虚拟机实例使用自定义 Linux 可插入式身份验证模块进行身份验证,或者虚拟机实例是 Active Directory 网域的成员,则无权模拟服务帐号的用户可能有权登录。

特别是对于不使用 OS Login 的虚拟机实例,请考虑通过 Identity-Aware Proxy 控制 shell 访问权限。仅向应有权模拟关联到虚拟机实例的服务帐号的用户授予 IAP-Secured Tunnel User 角色

将元数据服务器访问权限仅限于所选用户和进程

将服务帐号关联到虚拟机实例后,部署在虚拟机上的工作负载可以访问元数据服务器来请求服务帐号的令牌。默认情况下,对元数据服务器的访问权限不仅限于虚拟机上的任何特定进程或用户:即使以低权限用户运行的进程(例如,Linux 上的 nobody 或 Windows 上的 LocalService)都可以拥有对元数据服务器的完整访问权限,并且可以获取服务帐号的令牌。

如需将元数据服务器访问权限仅限于特定用户,请配置客机操作系统的主机防火墙,以仅允许这些用户打开与元数据服务器的出站连接。

在 Linux 上,您可以使用 --uid-owner--gid-owner 选项来设置仅应用于特定用户或群组的 iptables 规则。在 Windows 上,您可以使用 Set-NetFirewallSecurityFilter 命令来自定义防火墙规则,以将该规则应用于选定的用户或群组。

防范仿冒威胁

借助工作负载身份联合,您可以在 Cloud 项目与外部身份提供商之间建立单向信任关系。建立此信任关系后,您可以将从外部身份提供商获取的凭据交换为 Security Token Service (STS) 令牌。然后,您可以使用该 STS 令牌访问或模拟服务帐号。

STS 令牌与访问令牌不同,STS 令牌不对应于某个特定的 Google 身份。此外,STS 令牌并不一定对应于外部身份提供商中的某个特定身份,而是代表一组特性。根据这些特性的含义,它们可能对应于外部身份提供商中的一个或多个身份。

如果由 STS 令牌表示的特性有歧义或使用不当,则可能会使得不法分子能够仿冒其身份。以下部分介绍了帮助您防范此类仿冒威胁的最佳做法。

不允许修改特性映射

工作负载身份联合使用特性映射来选择外部身份提供商提供的哪些特性应该嵌入到 STS 令牌中,以及特性名称应如何进行转换。配置特性映射是在外部身份提供商与 Google Cloud 之间设置信任关系的关键步骤。

特性映射对于使用工作负载身份联合的安全性也至关重要:如果您已授予联合主帐号或主帐号集模拟服务帐号及之后更改特性映射的权限,则您可以更改哪些用户有权访问该服务帐号。

修改特性映射需要 iam.googleapis.com/workloadIdentityPoolProviders.update 权限。具有此权限的角色包括:

  • Owner (roles/owner)
  • IAM Workload Identity Pool Admin (roles/iam.workloadIdentityPoolAdmin)

如果不法分子有权修改特性映射,则他们可能可以更改映射规则,导致其仿冒身份并获取对服务帐号的访问权限。为防止此类恶意修改,请确保只有少数管理用户有权修改特性映射。

请考虑创建一个专用 Cloud 项目来管理工作负载身份池,以限制用户无意中在资源层次结构中的更高级层分配了以上某个角色的风险。

请勿依赖于不稳定或不具有权威性的特性

使用工作负载身份联合时,您会信任外部身份提供商对用户进行身份验证,并将有关经过身份验证的用户的准确信息报告回 Google Cloud。

身份提供商使用特性来传达有关经过身份验证的用户的信息。虽然其中部分特性通常保证具有权威性,但其他特性可能不具有权威性:例如,外部身份提供商可能会将用户名和用户 ID 同时嵌入 OpenID Connect ID 令牌中。这两个特性可唯一标识用户,并且看似可以互换。但是,外部身份提供商可能允许用户更改用户名,同时保证其用户 ID 稳定并具有权威性。

如果特性映射依赖于不稳定或不具有权威性的特性,则不法分子可能可以通过修改外部身份提供商中的用户个人资料来仿冒其身份。例如,他们可能将其用户名更改为近期在外部身份提供商中删除的用户的用户名,但仍有权访问 Google Cloud 上的服务帐号。

为防范此类仿冒攻击,请确保特性映射仅依赖于外部身份提供商保证其稳定且具有权威特性的特性。

防范信息泄露威胁

避免在服务帐号电子邮件地址中披露机密信息

如需授予服务帐号对另一个 Cloud 项目中的资源的访问权限,您可以向该资源的 IAM 政策添加角色绑定。与资源本身一样,IAM 政策是另一个 Cloud 项目的一部分,因此其可见性也由另一个 Cloud 项目控制。

查看 IAM 政策通常不被认为是一种特权操作。许多角色都具有所需的 *.getIamPolicy 权限,包括基本的 Viewer 角色。

有权查看 IAM 政策的用户也可以查看已授予资源访问权限的主帐号的电子邮件地址。对于服务帐号,电子邮件地址可向不法分子提供提示。

例如,IAM 政策可能包含针对电子邮件地址为 jenkins@deployment-project-123.gserviceaccount.com 的服务帐号的绑定。对于不法分子,此电子邮件地址不仅会显示 ID 为 deployment-project-123 的 Cloud 项目,还会显示 Cloud 项目运行 Jenkins 服务器。选择更通用的名称(如 deployer@deployment-project-123.gserviceaccount.com),您可以避免披露有关 deployment-project-123 中运行的软件类型的信息。

如果您向服务帐号授予访问控制不太严格的 Cloud 项目中的资源(例如沙盒或开发 Cloud 项目)的访问权限,请确保服务帐号的电子邮件地址不会披露任何信息。尤其是请勿披露机密信息或可能为攻击者提供提示的信息。

防范不可否认的威胁

每当您发现影响 Google Cloud 中某项资源的可疑活动时,Cloud Audit Logs 是非常重要的信息来源,可了解该活动发生的时间以及参与的用户。

每当 Cloud Audit Logs 指示服务帐号已执行某活动时,仅凭此信息可能不足以重建完整的事件链:您还必须能够了解哪个用户或应用导致服务帐号执行此活动。

此部分包含最佳做法,可帮助您保留不可否的审核跟踪记录。

为 IAM API 启用数据访问日志

为了帮助您识别和了解服务帐号模拟场景,Cloud Engine 等服务在 Cloud Audit Logs 中包含 serviceAccountDelegationInfo 部分。本部分指示了服务帐号是否被模拟以及被哪个用户模拟

并非所有服务都在其 Cloud Audit Logs 中包含模拟详细信息。如需记录所有模拟事件,您还必须为以下 API 启用数据访问日志

  • 包含服务帐号的所有 Cloud 项目中的 Identity and Access Management (IAM) API
  • 包含工作负载身份池的所有 Cloud 项目中的 Security Token Service API

启用这些日志,可确保每次在用户请求服务帐号的访问令牌或 ID 令牌时,都会向 Cloud Audit Logs 中添加一个条目。

确保 CI/CD 历史记录可与 Cloud Audit Logs 相关联

在成功验证代码更改并批准部署后,CI/CD 系统通常会使用服务帐号执行部署。通常,CI/CD 系统会保留进行部署的事件的历史记录。此历史记录可能包含相应代码审核、提交和流水线运行的 ID,以及有关部署批准者的信息。

如果部署修改了 Google Cloud 中的任何资源,则相关资源的 Cloud Audit Logs 会跟踪这些更改。Cloud Audit Logs 包含有关发起更改的用户或服务帐号的信息。但是,在由 CI/CD 系统触发的部署中,服务帐号本身通常不足以重建引起更改的整个事件链。

如需在 CI/CD 系统和 Google Cloud 中建立一致的审核跟踪,您必须确保 Cloud Audit Logs 记录可与 CI/CD 系统历史记录中的事件相关联。如果您在 Cloud Audit Logs 中遇到意外事件,则可以使用这种关联性来确定更改是否确实由 CI/CD 系统执行、为何执行以及由谁批准。

用于建立 Cloud Audit Logs 记录与 CI/CD 系统历史记录中事件之间关联的方法包括:

  • 记录 CI/CD 流水线每次运行时执行的 API 请求。
  • 每当 API 返回操作 ID 时,在 CI/CD 系统日志中记录该 ID。
  • 向 API 请求添加 X-Goog-Request-Reason HTTP 标头并传递 CI/CD 流水线运行的 ID。或者,将信息嵌入到 User-Agent 标头中,以将其捕获到 Cloud Audit Logs 中。

为帮助确保不可否认性,请配置日志文件并提交历史记录,使其是不可变的,并且不法分子无法追溯性地隐藏其跟踪记录。

后续步骤