持续访问 Google Cloud 的最佳实践

Last reviewed 2025-08-08 UTC

本文档提供了一些建议,可帮助您持续访问 Google Cloud 资源。业务连续性旨在确保您的组织即使在中断(例如停电或灾难)期间也能维持基本运营。此目标包括在关键服务和基础设施不可用时,员工仍可继续访问。

本文档面向负责 Identity and Access Management (IAM) 以及维护对 Google Cloud的安全访问权限的安全或可靠性专业人员。本文档假定您已熟悉 Cloud Identity、Google Workspace 和 IAM 管理。

为帮助您为中断做好准备并确保持续访问,本文档概述了您可以实施的以下建议步骤。您可以选择执行全部或部分步骤,但我们建议您按以下顺序执行这些步骤。

  1. 设置紧急访问权限:启用对Google Cloud 资源的最后手段访问权限。

    我们建议您为所有Google Cloud 组织设置紧急访问权限,无论您在业务持续性方面有何具体要求。

  2. 为重要用户提供身份验证替代方案:如果贵组织使用单点登录 (SSO),则影响外部身份提供方 (IdP) 的任何中断都可能会影响员工进行身份验证和使用Google Cloud的能力。

    为了减少 IdP 中断对组织的总体影响,请为业务关键型用户提供替代身份验证方式,以便他们继续访问 Google Cloud 资源。

  3. 使用备用 IdP:为了让所有用户在 IdP 中断期间都能访问 Google Cloud资源,您可以维护备用 IdP。

    备用 IdP 有助于进一步最大限度地减少中断的影响,但对于某些组织而言,此选项可能不划算。

以下各部分将介绍这些推荐的步骤和最佳实践。

设置紧急访问权限

紧急访问的目的是启用对Google Cloud 资源的最后手段访问权限,并防止您完全失去访问权限的情况。

紧急访问用户的特征如下:

  • 这些用户是您在 Cloud Identity 或 Google Workspace 账号中创建的用户。
  • 他们拥有超级用户权限,可为用户提供足够的访问权限来解决影响 Cloud Identity、Google Workspace 或Google Cloud 资源的任何配置错误。
  • 它们不与组织中的特定员工相关联,并且不受常规用户账号的“Joiner, Mover, and Leaver (JML)”生命周期限制。
  • 它们不受 SSO 的约束。

以下部分介绍了在管理和保护紧急访问用户时应遵循的推荐最佳实践。

为每个环境创建紧急访问用户

对于托管生产工作负载的 Google Cloud 环境,紧急访问至关重要。对于用于测试或预演目的的 Google Cloud 环境,失去访问权限仍然会造成干扰。

为确保能够持续访问所有 Google Cloud 环境,请在 Cloud Identity 或 Google Workspace 中为每个环境创建并维护紧急访问用户。

确保紧急访问冗余

单个紧急访问用户是单点故障。在这种情况下,安全密钥损坏、密码丢失或账号中止可能会导致无法访问账号。为降低此风险,您可以为每个 Cloud Identity 或 Google Workspace 账号创建多个紧急访问用户。

紧急访问用户拥有很高的权限,因此请勿创建过多的紧急访问用户。 对于大多数组织,我们建议为每个 Cloud Identity 或 Google Workspace 账号设置至少 2 位、最多 5 位紧急访问用户。

为紧急访问权限用户使用单独的组织部门

紧急访问用户需要特殊配置,并且不受您可能针对其他用户账号遵循的 JML 生命周期约束。

为了将紧急访问用户与常规用户账号分开,请为紧急访问用户使用专用组织部门 (OU)。通过单独的组织部门,您可以仅对紧急用户应用自定义配置。

使用 FIDO 安全密钥进行两步验证

使用 Fast IDentity Online (FIDO) 安全密钥进行两步验证。

由于紧急访问用户是 Cloud Identity 或 Google Workspace 账号中的高权限用户,因此您必须使用两步验证来保护这些用户。

在 Cloud Identity 和 Google Workspace 支持的双重验证方法中,我们建议您使用 FIDO 安全密钥。此方法可防范钓鱼式攻击,并提供强大的安全性。为确保所有紧急访问用户都使用 FIDO 安全密钥进行两步验证,请执行以下操作:

  • 在包含紧急访问用户的组织部门中,配置两步验证,以仅允许安全密钥作为身份验证方法。
  • 为所有紧急访问用户启用两步验证。
  • 为每位紧急访问用户注册至少两个 FIDO 安全密钥。

为每位用户注册多个密钥有助于降低因安全密钥损坏而无法访问账号的风险。这样一来,用户在紧急情况下至少能访问其中一个密钥的可能性也会增加。

可以为多位紧急访问用户使用同一组安全密钥。不过,最好为每位紧急访问用户使用不同的安全密钥。

使用实体安全控制措施来保护凭据和安全密钥

存储紧急访问用户的凭据和安全密钥时,您必须在提供严密保护与在紧急情况下确保可用性之间取得平衡:

  • 防止未经授权的人员访问紧急访问用户凭据。紧急访问用户只能在紧急情况下使用这些凭据。
  • 确保授权人员在紧急情况下能够以最短的延迟时间访问凭据。

我们建议您不要依赖基于软件的密码管理工具。最好依靠实体安全控制措施来保护紧急访问用户的凭据和安全密钥。

在选择要应用哪些实体安全控制措施时,请考虑以下因素:

  • 提高可用性
    • 将密码副本存储在多个实体位置,例如不同办公室中的多个保险库。
    • 为每位紧急访问用户注册多个安全密钥,并将每个密钥存放在相关的办公地点。
  • 提高安全性:将密码和安全密钥存储在不同的位置。

避免使用自动化功能进行密码轮替

自动轮替紧急访问用户的密码似乎很有益。不过,这种自动化可能会增加安全风险。紧急访问用户拥有超级用户权限。如需轮换超级用户账号的密码,自动化工具或脚本也必须拥有超级用户权限。此要求可能会导致这些工具成为攻击者的理想目标。

为确保您不会削弱整体安全态势,请勿使用自动化功能来轮换密码。

使用安全系数高的密码

为帮助保护紧急访问用户,请确保他们使用安全系数高的长密码。如需强制执行最低密码复杂度要求,请使用专用 OU(如前所述),并实施密码要求

除非您手动轮换密码,否则请为所有紧急访问用户停用密码过期功能

从访问权限政策中排除紧急访问用户

在紧急情况下,情境感知访问权限政策可能会导致即使是紧急访问用户也无法访问某些资源。为缓解此风险,请从访问权限政策中的所有访问权限级别中排除至少一位紧急访问用户

这些豁免有助于确保至少有一位紧急访问用户可以持续访问资源。在紧急情况下或情境感知访问政策配置错误时,这些紧急访问用户可以保持其访问权限。

为紧急访问用户事件设置提醒

紧急事件之外的任何紧急访问用户活动都可能表明存在可疑行为。如需接收与紧急访问用户活动相关的任何事件的通知,请在 Google 管理控制台中创建报告规则。创建报告规则时,您可以设置如下条件:

  • 数据源:用户日志事件。
  • 条件构建器标签页中的属性:使用属性和运算符为包含紧急访问用户和事件的组织部门创建过滤条件。

    例如,您可以设置属性和运算符,以创建类似于以下条件语句的过滤器:

    Actor organizational unit Is /Privileged
    
    AND
    
    (Event Is Successful login OR Event Is Failed login OR Event Is Account
    password change)
    
  • 阈值:每 1 小时,当计数 > 0 时

  • 操作:发送电子邮件通知

  • 电子邮件收件人:选择包含安全团队相关成员的群组

为关键用户提供身份验证替代方案

如果贵组织使用单点登录 (SSO) 让员工向 Google 服务进行身份验证,那么第三方身份提供商的可用性就变得至关重要。IdP 出现任何中断都可能会导致员工无法访问必要的工具和资源。

虽然紧急访问有助于确保管理员持续拥有访问权限,但无法满足员工在 IdP 发生中断时的需求。

为了降低 IdP 中断的潜在影响,您可以配置 Cloud Identity 或 Google Workspace 账号,以便为关键用户使用身份验证回退。您可以采用以下回退方案:

  • 在正常操作期间,您允许用户使用单点登录进行身份验证。
  • 在 IdP 出现中断期间,您可以选择性地为这些关键用户停用 SSO,并允许他们使用您预先配置的 Google 登录凭据进行身份验证。

以下部分介绍了在外部 IdP 发生中断时允许关键用户进行身份验证的推荐最佳实践。

重点关注特权用户

为了让关键用户在 IdP 发生中断时进行身份验证,用户必须拥有有效的 Google 登录凭据,例如:

  • 使用密码和安全密钥进行双重身份验证。
  • 通行密钥。

如果您为通常使用 SSO 的用户预配 Google 登录凭据,可能会通过以下方式增加运营开销和用户摩擦:

  • 您可能无法自动同步用户密码,具体取决于您的 IdP。因此,您可能需要要求用户手动设置密码。
  • 您可能需要要求用户注册通行密钥或启用两步验证。单点登录用户通常无需执行此步骤。

为了平衡不间断访问 Google 服务的好处与额外开销,请重点关注具有特权的用户和业务关键型用户。这些用户更有可能从不间断的访问中获益匪浅,但他们可能只占您总体用户群的一小部分。

利用此机会启用单点登录后验证

为特权用户配置替代身份验证时,可能会产生意想不到的额外开销。为了帮助抵消这种开销,您还可以为这些用户启用 SSO 后验证。

默认情况下,为用户设置 SSO 后,他们无需执行两步验证。虽然这种做法很方便,但如果 IdP 遭到入侵,任何未启用 SSO 后验证的用户都可能成为凭据伪造攻击的目标。

SSO 后验证有助于您减轻 IdP 遭到入侵的潜在影响,因为用户必须在每次尝试 SSO 后执行两步验证。如果您为特权用户配置了 Google 登录凭据,那么在单点登录后进行验证有助于在不增加额外开销的情况下提升这些用户账号的安全态势。

为特权用户使用单独的组织部门

在外部 IdP 发生中断期间可以进行身份验证的特权用户需要特殊配置。此配置与常规用户和紧急访问用户的配置不同。

为帮助您将具有相关权限的用户与其他用户账号分开,请为具有相关权限的用户使用专用组织部门。此单独的组织部门有助于您仅向这些具有特权的用户应用自定义政策,例如单点登录后验证。

单独的组织部门还有助于您在 IdP 发生中断时,有选择地为具有管理员权限的用户停用单点登录。如需为组织部门停用 SSO,您可以修改 SSO 配置文件分配

使用备用 IdP

在 IdP 中断期间,为关键用户提供身份验证替代方案有助于减少身份提供商服务中断对组织的影响。不过,此缓解策略可能不足以维持完整的运营能力。许多用户可能仍然无法访问基本应用和服务。

为了进一步降低 IdP 故障的潜在影响,您可以故障转移到备用 IdP。您可以采用以下备份方案:

  • 在正常运营期间,您允许用户使用 SSO 和主要 IdP 进行身份验证。
  • 在 IdP 中断期间,您可以更改 Cloud Identity 或 Google Workspace 账号的 SSO 配置,以切换到备用 IdP。

备用 IdP 无需来自同一供应商。创建备用 IdP 时,请使用与主 IdP 的配置相匹配的配置。为确保备用 IdP 允许所有用户进行身份验证并访问 Google 服务,备用 IdP 必须使用主 IdP 用户群的最新副本。

备用 IdP 有助于提供全面的应急访问权限。不过,您必须权衡这些优势与备用 IdP 可能带来的额外风险。这些潜在风险包括:

  • 如果备用身份提供商的安全性不如主要身份提供商,那么在故障切换期间, Google Cloud 环境的整体安全状况也可能会变差。
  • 如果主 IdP 和备用 IdP 在 SAML 断言的签发方式上有所不同,则 IdP 可能会让用户面临欺骗攻击的风险。

以下部分介绍了在将备用 IdP 用于应急访问时建议采用的最佳实践。

为备用 IdP 创建单独的 SAML 配置文件

借助 Cloud Identity 和 Google Workspace,您可以创建多个 SAML 配置文件。每个 SAML 配置文件可以引用不同的 SAML IdP。

为了最大限度地减少故障转移到备用 IdP 所需的工作量,请提前为备用 IdP 准备 SAML 配置文件:

  • 为您的主要 IdP 和备用 IdP 分别创建 SAML 配置文件。
  • 配置单点登录配置文件分配,以便在正常运营期间仅分配主 IdP 的 SAML 配置文件。
  • 修改 SSO 配置文件分配,以便在 IdP 发生中断时使用备用 IdP 的 SAML 配置文件。请勿更改各个 SAML 配置文件设置。

使用现有的本地 IdP

您无需预配额外的 IdP 作为备用 IdP。请改为检查您是否可以使用现有的本地 IdP 来实现此目的。例如,贵组织可能使用 Active Directory 作为身份的权威来源,还可能使用 Active Directory 联合身份验证服务 (AD FS) 进行单点登录 (SSO)。在这种情况下,您或许可以使用 AD FS 作为备用 IdP。

这种重用方法有助于限制费用和维护开销。

准备备用 IdP 以处理所需负载

当您将身份验证切换到备用 IdP 时,备用 IdP 必须处理主 IdP 通常处理的所有身份验证请求。

在部署和调整备用 IdP 的大小时,请注意预期请求的数量取决于以下因素:

例如,如果会话时长介于 8 到 24 小时之间,那么在员工开始工作日的上午时段,身份验证请求可能会激增。

定期测试故障切换过程

为确保单点登录故障切换流程可靠运行,您必须定期验证该流程。测试故障切换过程时,请执行以下操作:

  • 手动修改一个或多个组织部门或群组的单点登录配置文件分配,以使用备用 IdP。
  • 验证使用备用 IdP 的 SSO 是否按预期运行。
  • 验证签名证书是否是最新的。

后续步骤

贡献者

作者:Johannes Passing | 云解决方案架构师

其他贡献者:Ido Flatow | 云解决方案架构师