保护开发者凭据的最佳实践

了解保护开发者工作站以及防止凭据（包括 Google Cloud CLI OAuth 不记名 令牌、应用默认 凭据和本地密钥）被盗用和 滥用 Google Cloud 的最佳实践。

本文档适用于负责保护云资源免遭非法访问的安全团队或云架构师。了解可用于主动降低被盗用的开发者凭据的影响并在端点被盗用后修复环境的可用控制措施。

凭据被盗用的风险

如果攻击者获得访问 正当用户账号或服务帐号已使用 Google Cloud 或 gcloud CLI 进行身份验证的端点的权限，则可以破解凭据。然后，攻击者可以将这些令牌复制到他们控制的其他端点，以发出模拟合法身份的请求。即使您移除攻击者对遭破解端点的访问权限，攻击者仍然可以使用复制的令牌发出经过身份验证的 API 请求。为帮助降低此风险，您可以使用短期有效和情境感知的凭据来控制对系统的访问权限。

开发者凭据概览

开发者工作站上通常会找到以下 Google Cloud 凭据：

以下部分介绍了每种凭据类型的存储和使用方式。

gcloud CLI OAuth 令牌

gcloud CLI 使用 OAuth 2.0 访问 令牌对 Google Cloud API 请求进行身份验证。OAuth 流程因使用的凭据类型而异，但访问令牌和其他凭据通常可在本地访问。在每种情况下，访问令牌默认会在 60 分钟后过期，但 在延长生命周期 限制下，最长可持续 12 小时。 不过，其他凭据类型可能是永久性的。

当您 使用用户账号向 gcloud CLI 授权时， gcloud CLI 会启动三足式 OAuth 同意流程，以代表用户访问 Google Cloud API。用户完成同意流程后，gcloud CLI 会收到访问令牌以及使其能够请求新访问令牌的刷新令牌。长期有效的刷新令牌 在满足到期条件之前会一直保留。

当您 使用服务账号向 gcloud CLI 授权时， gcloud CLI 会启动二足式 OAuth 流程，以服务帐号身份访问 Google Cloud API。通过私钥文件激活服务帐号后，gcloud CLI 会使用此密钥定期请求访问令牌。长期有效的私钥存储在 gcloud CLI 配置中，在您停用或删除服务帐号密钥之前一直有效。

在 Google Cloud 环境（例如 Compute Engine 或 Cloud Shell）中运行 gcloud CLI 时，应用可以自动查找 凭证并 以服务 账号身份进行身份验证。例如，在 Compute Engine 中，像 gcloud CLI 这样的应用可以在元数据服务器中查询访问令牌。Google 会管理和轮替用于创建访问令牌的签名私钥，并且不会向应用公开长期有效的凭据。

应用默认凭据

应用使用应用默认凭证向 Google Cloud API 进行身份验证。开发者可以通过运行 gcloud auth application-default login 生成应用默认凭据。此命令会写入纯文本 JSON 文件（$HOME/.config/gcloud/application_default_credentials.json 或 %APPDATA%\gcloud\application_default_credentials.json），其中包含 OAuth 2.0 刷新令牌和客户端库的客户端凭据。

任何客户端库或自定义脚本都可以使用这些凭据来调用 Google Cloud API。

由于应用默认凭证以明文形式保存，因此在用户上下文中运行的任何不受信任的进程或脚本都可以直接访问该文件，或使用 gcloud auth application-default print-access-token 等命令检索有效的访问令牌。

典型的恶意软件通常以 ~/.config/gcloud/ 目录为目标，以收集 application_default_credentials.json。

如需了解详情，请参阅应用默认凭证。

服务账号密钥

服务账号密钥是从 Google Cloud 控制台下载的私有 JSON 密钥文件。应用使用这些密钥向 Google Cloud API 进行身份验证。服务账号密钥可以存储在以下位置：

  • 运行 gcloud auth activate-service-account 后的 gcloud CLI 配置目录
  • 本地文件系统
  • 内部代码库

开发者端点上的服务账号密钥不受两步验证的约束，没有会话限制，也不会自动过期。

窃取服务帐号密钥的攻击者可以创建服务帐号访问令牌，以保持永久性访问权限。

如需了解详情，请参阅 管理服务帐号的最佳实践。

SSH 密钥

SSH 密钥用于向 Compute Engine 实例进行身份验证。 开发者可以使用 gcloud compute ssh 生成 SSH 密钥。此命令会在 ~/.ssh/google_compute_engine 中生成本地私钥。SSH 密钥是长期有效的。

攻击者可以使用窃取的 SSH 密钥访问虚拟机，然后查询元数据服务器以提取关联的服务帐号令牌。此攻击会绕过外部边界防火墙。

请考虑使用 OS Login 及两步验证，而不是使用 SSH 密钥。如需了解详情，请参阅 强制执行两步验证以进行远程服务器访问。

浏览器 Cookie

浏览器 Cookie 会对向 Google Cloud 控制台和 Cloud Shell 发出的 Web HTTP 请求进行身份验证。当用户登录 Google Cloud 控制台时，系统会自动创建浏览器 Cookie。

Cookie 存储在本地工作站上的浏览器配置文件目录中。例如，Google Chrome 会将 Cookie 存储在 Linux 上的 ~/.config/google-chrome/ 或 Windows 上的 %LOCALAPPDATA%\Google\Chrome\User Data 中。

浏览器 Cookie 是长期有效的凭据，只有在用户退出登录、会话超时或管理员在管理控制台中重置用户会话时才会失效。

窃取这些 Cookie 的攻击者可以将其导入另一个浏览器，以 劫持有效的 Google Cloud 控制台会话，从而绕过身份验证。

如需降低会话 Cookie 被窃取的风险，请设置服务的会话时长 Google Cloud 。

员工身份联合访问令牌

开发者可以使用员工身份联合通过外部 身份提供方进行身份验证，以便访问 Google Cloud 资源。

如需使用联合身份登录，开发者可以使用登录配置文件 （使用 gcloud iam workforce-pools create-login-config 命令创建）并登录 gcloud CLI。通过外部身份提供方进行身份验证后，Security Token Service 会将授权代码交换为短期有效的联合访问令牌和 OAuth 刷新令牌。

gcloud CLI 会将凭据元数据和刷新令牌存储在本地凭据数据库中，并将有效的访问令牌缓存在 gcloud CLI 配置目录中。联合访问令牌是短期有效的凭据，会在设定的时间（默认 60 分钟）后过期。

破解端点的攻击者可以提取有效的联合访问令牌，或使用 gcloud auth print-access-token 模拟员工主体。如果员工身份具有模拟权限，攻击者还可以请求服务帐号访问令牌以提升权限。

为降低风险，请将员工身份池的会话时长配置为必要的最低时长，并使该时长与外部身份提供方的重新身份验证和会话超时政策保持一致。如需详细了解如何存储和管理凭据，请参阅使用工作负载身份联合的最佳实践。

凭据被盗用的影响

如果攻击者成功破解了端点，则 OAuth 令牌等凭据是有价值的目标，因为它们可让攻击者保留或提升其访问权限。

开发者在编写和调试代码时可能有合法需求来查看自己的凭据。例如，使用不受支持的客户端 库时，开发者可能需要使用 REST 请求向 Google Cloud 服务进行 身份验证。开发者可以通过各种方法查看凭据，包括：

但是，攻击者可能会在破解端点后使用上述相同的方法。

如果攻击者破解了端点，则主要威胁是攻击者可以使用经过身份验证的身份的合法凭据运行 gcloud CLI 命令或其他代码。此外，攻击者可能会将凭据复制到他们控制的其他端点以保留其访问权限。 此凭据发生盗用时，会存在一个次要威胁。即使您移除了对遭破解的端点的访问权限，攻击者仍然可以使用长期有效的凭据获得永久性访问权限。

如果攻击者设法破解了开发者凭据，则可以完成以下操作：

  • 冒充被盗用的用户或服务帐号。使用被破解的令牌的 API 流量会被记录为来自被破解的用户或服务帐号，因此很难区分日志中的正常活动和恶意活动。
  • 使用永久性 OAuth 刷新令牌（来自 gcloud CLI 或应用默认凭据）或与服务帐号关联的私钥无限期地请求访问令牌。
  • 使用用户的密码或两步验证绕过身份验证，因为令牌是在登录流程后授予的。
  • 使用窃取的 SSH 密钥访问 Compute Engine 实例，并查询元数据服务器以窃取关联的服务帐号令牌。
  • 使用窃取的浏览器 Cookie 劫持有效的 Google Cloud 控制台会话 ，而无需用户的密码或两步验证。
  • 使用窃取的联合访问令牌访问授予员工身份池的资源，或通过模拟服务账号提升权限。

降低风险的最佳实践

请实施以下部分中所述的控制措施，以帮助降低开发者凭据被破解的风险。如果您遵循了 中企业基础 蓝图 或着陆区设计 Google Cloud所述的安全方面的最佳实践，则您可能 已经实施了这些控制措施。

设置 Google Cloud 服务的会话时长

如需减少攻击者利用已破解令牌的时间，请设置服务的 会话时长 Google Cloud。对于新客户， 系统会自动强制执行 16 小时的默认会话时长。在 2023 年之前创建其 Google Cloud 组织的客户可能具有默认设置，即永不需要 重新进行身份验证。请查看此设置，确保您拥有会话时长介于 1 到 24 小时之间的重新身份验证政策。重新身份验证政策会强制用户定期使用其密码或安全密钥重新验证 gcloud CLI 身份。

Google Cloud 服务的会话时长是一项与 Google 服务的会话时长不同的 设置， 后者控制在 Google Workspace 服务中登录的 Web 会话，但 不控制对 Google Cloud的重新身份验证。如果您使用 Google Workspace 服务，请同时设置两者的会话时长。

配置 VPC Service Controls

在您的环境中配置 VPC Service Controls，以便确保只有源于您定义的边界内的 Google Cloud API 流量才可以访问 受支持的 资源。服务边界限制了被破解的凭据的作用，因为边界会阻止源于环境之外的攻击者控制的端点的受限服务请求。

配置 Chrome 企业进阶版

配置 Chrome 企业进阶版政策，以便帮助 保护 Google Cloud 控制台和 Google Cloud API。配置 Chrome 企业进阶版访问权限级别和绑定，以选择性地允许对每个 API 请求评估的属性，包括基于 IP 的访问权限或 针对双向 TLS 的基于证书的访问权限。使用泄露的授权凭据但不符合 Chrome 企业进阶版政策中定义的条件的请求将被拒绝。

Chrome 企业进阶版是以用户为中心的控制机制，可拒绝不符合定义的条件的用户 API 流量。VPC Service Controls 是以资源为中心的控制机制，定义了资源可在其中进行通信的边界。VPC Service Controls 适用于所有用户身份和服务账号身份，但 Chrome Enterprise 进阶版仅适用于您的组织内的用户身份。结合使用 Chrome 企业进阶版和 VPC Service Controls 时，会降低环境之外的攻击者控制的机器上被破解凭据的有效性。

强制执行两步验证以进行远程服务器访问

如果您允许开发者使用 SSH 访问 Compute Engine 资源， 请配置 OS Login 及两步 验证。这会强制执行一个额外的检查点，用户必须使用密码或安全密钥重新验证身份。此功能可以能阻止只有被破解的 OAuth 令牌但没有任何密码或安全密钥的攻击者。

使用远程桌面协议 (RDP) 访问 Compute Engine 上的 Windows 实例不支持 OS Login 服务，因此无法对 RDP 会话精细执行两步验证。使用 Identity-Aware Proxy (IAP) 桌面 或基于 Google Chrome 的 RDP 插件时，请完成以下操作：

限制服务帐号密钥的使用

使用服务帐号密钥进行身份验证时，密钥值与下载的密钥文件分开存储在 gcloud CLI 配置文件中。有权访问您的环境的攻击者可能会从 gcloud CLI 配置中复制密钥，或者从本地文件系统或内部代码库中复制密钥文件。因此，除了减少访问令牌被破解的方案之外，请考虑如何管理下载的服务账号密钥文件。

查看更安全的 身份验证替代方案，以减少或消除 依赖于服务帐号密钥的用例。此外，还要强制执行 constraints/iam.disableServiceAccountKeyCreation 和 constraints/iam.disableServiceAccountKeyUpload 组织政策限制条件，以停用服务帐号密钥创建功能。

应用最小权限原则

设计 Identity and Access Management (IAM) 政策时，请考虑 最小 权限。仅在最小范围内向用户授予完成任务所需的角色。查看并 应用角色 建议，以 避免您的环境中具有未使用和过多角色的 IAM 政策。

保护您的端点

考虑攻击者如何获得端点（例如开发者工作站或 Compute Engine 实例）的物理访问权限或远程访问权限。 虽然解决被破解的凭据威胁的方案非常重要，但还要考虑攻击者破解可信端点的风险。如果攻击者有权访问可信端点，则可以直接在端点本身上运行 gcloud CLI 命令或其他代码。

虽然对开发者工作站的全面保护不在本文档的介绍范围内，但请评估您的安全工具与运营如何帮助保护端点以及监控端点是否被破解。请考虑以下问题：

  • 如何保护开发者工作站的物理安全性？
  • 如何识别和应对网络入侵？
  • 用户如何获取对 SSH 或 RDP 会话的远程访问权限？
  • 永久性凭据（如 SSH 密钥或服务帐号密钥）如何遭到破解？
  • 是否存在使用可能被短期有效凭据替换的永久性凭据的工作流？
  • 是否存在有人在其中可能读取其他用户的缓存 gcloud CLI 凭据的共享设备？
  • 用户是否可以通过非可信设备使用 gcloud CLI 进行身份验证？
  • 已批准的流量如何连接到 VPC Service Controls 边界内的资源？

确保您的安全运维能够解决上述每个问题。

使响应团队保持一致

提前确保负责突发事件响应的安全团队 在整个 Google Cloud 控制台和管理控制台中拥有适当的访问权限。 如果单独的团队负责管理 Google Cloud 控制台和管理控制台，您 突发事件期间响应可能会延迟。

如需评估和应对破解事件，请参阅 应对被破解的 Google Cloud 凭据。

监控凭据泄露

如需监控潜在的泄露情况，请考虑以下事项：

  • 使用异常检测或密钥扫描等工具扫描代码库中的密钥。

  • 在 Cloud Audit Logs 中，为以下内容配置提醒：

    • iamcredentials.googleapis.com 方法（例如 GenerateAccessToken、GenerateIdToken、SignJwt）以审核服务帐号令牌生成

      这些日志要求您启用数据访问日志。

    • protoPayload.authenticationInfo.serviceAccountDelegationInfo.firstPartyPrincipal.principalEmail 以审核用户和服务帐号模拟

    • sts.googleapis.com 交换请求，以获取异常身份断言

  • 在 Security Command Center 中，监控 Event Threat Detection 中的以下 威胁发现结果 ：

    • 持久性：新地理位置
    • 持久性：新用户代理
    • 持久性：新 API 方法
    • 评估：从匿名代理访问
    • 提升权限：针对管理员活动的服务账号异常模拟
    • 提升权限：针对管理员活动的异常服务账号模拟者
    • 初始访问权限：使用的服务账号密钥已泄露
    • 持久化：创建了服务账号密钥
    • 初始访问权限：可疑登录被阻止
    • 初始访问权限：账号因遭到盗用而被停用

    对于每种威胁，我们都提供了建议的调查 步骤，以帮助您做出响应。

  • 在 Google Workspace 和 Cloud Identity 中监控用户登录。 为了更好地对相关问题进行跟踪，请考虑将日志导出到 Cloud Logging。

  • 监控 Chrome 企业进阶版和 VPC Service Controls 中的日志，以了解使用窃取的令牌进行的边界外访问尝试。

  • 使用 Cloud Monitoring监控服务帐号密钥的异常使用。

确保您的安全运维中心 (SOC) 能够及时收到通知，并拥有快速响应可疑凭据泄露事件所需的策略方案、工具和访问权限。您还可以将 Security Command Center 与现有的 SIEM 集成，或将日志 导入 Google Security Operations 以进一步分析。

后续步骤