在混合环境中对员工用户进行身份验证

Last reviewed 2022-10-02 UTC

本文是多篇系列文章中的第一篇,该系列介绍了如何将您的身份管理解决方案扩展到 Google Cloud,以便您的员工能够在混合计算环境中进行身份验证并使用服务。

该系列包含以下部分:

简介

管理用户账号以及控制员工对应用和计算资源的访问是企业 IT 部门的关键职责。为了确保一致性和管理效率,大多数企业将身份管理视为核心功能,并使用统一系统来管理身份。企业最常依赖 Microsoft Active Directory 域服务 (AD DS) 来实现此目的。

作为混合策略的一部分,当您向 Google Cloud 扩展 IT 环境时,您希望在一个地方集中管理所有身份。统一的身份管理系统可以最大限度地减少账号管理和访问权限控制方面的管理工作量。此外,该系统也有助于确保用户和应用在混合环境中安全地进行身份验证。

本文介绍将 Google Cloud 与身份管理系统相集成的各种途径,可以帮助您根据自己的需要选择最合适的方法。

虽然大多数讨论也适用于 Google Workspace,但本文主要关注 Cloud Identity

评估混合身份管理需求

将身份管理系统扩展到 Google Cloud 的最佳方法取决于多种因素:

  • 您的组织中的身份池
  • 用于为您的员工身份提供身份验证服务的身份提供方
  • 您希望员工用户能够在 Google Cloud 上访问的资源和应用
  • 您的业务连续性要求

以下各部分分别探讨了这些因素的影响。

身份

集成 Google Cloud 和身份管理系统时,要考虑的第一个因素是如何管理和区分不同的身份类型。大多数组织使用以下类型的身份:

  1. 员工身份是您管理的组织员工的身份。此类身份用于登录工作站、访问电子邮件或使用公司应用。
  2. 外部身份是您管理的非员工(例如需要获得公司资源访问权限的承包商或合作伙伴)的身份。
  3. 访客身份是由需要访问公司资源的客户或合作伙伴等其他方管理的身份。
  4. 客户身份是您为了让用户与您的网站或面向客户的应用进行交互而管理的用户身份。
  5. 工作负载身份是您为了使应用能与其他应用或底层平台进行交互而管理的身份。

通常,员工身份会构成一个单独的身份池,其中,每个员工都具有单一身份,并且所有身份都使用相同的系统以同样的方式进行管理。但情况并非必然如此,比方说,在经历公司合并或收购后,您可能拥有多个员工身份池,每个池使用不同的系统以不同的方式进行管理。从技术上讲,这意味着您可能需要将多个 LDAP 源、Active Directory 林或 Azure AD 租户与 Google Cloud 集成在一起。

集成多个池会增加与 Google Cloud 集成的复杂性。因此,您应该评估以下事项:

  • 所有身份池是否都需要访问 Google Cloud,还是只有部分身份池需要访问?
  • 所有身份池是否都应具备对 Google Cloud 中同一组织的访问权限,还是每个身份池应具备对不同组织的访问权限?
  • 是否有选项用来减少池数量,例如在 Active Directory 林之间建立跨林信任?

外部身份的处理方式通常与员工身份类似,以下情况除外:

  • 外部身份的账号可能仅在有限的时间内有效。
  • 默认情况下,外部身份被授予的权限可能较少。
  • 外部身份可由单独的 LDAP 目录、Active Directory 林或 Azure AD 租户管理。

与外部身份不同,访客身份由其他方(而非您)进行管理。在 Google Workspace 等 SaaS 应用中,访客身份可以免去为客户或合作伙伴维护外部身份的需要。在本地环境中,访客身份较为罕见。

本文重点介绍员工身份和外部身份。

如果您使用过 Google Ads 等服务,那么您的部分员工可能已拥有一个与其员工身份无关联的 Google 账号,这意味着其拥有两个身份。如果是这样,请考虑合并这些身份

身份提供商

需要考虑的第二个因素是身份提供商。身份提供方 (IdP) 是为您的工作负载提供身份验证服务,并最终决定某个用户是否通过了身份验证的系统。

除了提供身份验证服务外,身份提供方通常还会管理身份的生命周期。但情况并非必然如此,因为身份也可能通过单独的人力资源系统预配。

常见的身份提供商包括:

  • Active Directory (AD DS)
  • Azure Active Directory (Azure AD)
  • ForgeRock、Okta 或 Ping Identity 等 IDaaS 提供商
  • 其他 LDAP 目录,包括 Active Directory 轻量级目录服务 (AD LDS)

您可能在使用多个系统(而非仅使用一个系统)来管理不同的用户池,以便处理外部账号或为相同的用户池提供不同的身份验证服务。使用多个身份提供商来管理相同用户池的示例包括:

  • 将 Active Directory 与 Azure AD 相联合
  • 将 Active Directory 与 ForgeRock、Okta 或 Ping Identity 等 IDaaS 提供商相联合
  • 带 AD LDS 副本的 Active Directory

如需在 Google Cloud 上使用您的身份提供方,您可采用下列两种基本方法:

  • 将您的身份提供方与 Cloud Identity 联合:通过与 Cloud Identity 联合,您可以让 Google 成为员工用户可以使用以及 Google Cloud 上部署的应用可以依赖的额外身份提供方。您无需为每个用户维护 Google 身份,而是借助联合关系来自动维护身份。此联合关系还有助于确保您的身份提供商始终为可靠的数据源。
  • 将您的身份提供商扩展到 Google Cloud:您可以允许部署在 Google Cloud 上的应用重复使用您的身份提供商,具体方法是直接连接到该提供商,或在 Google Cloud 上维护该提供商的副本。

根据其他身份管理因素,您可能需要结合使用上述两种方法来支持您的混合使用场景。

资源

需要考虑的第三个因素是您计划向员工用户授予对哪些 Google Cloud 资源的访问权限。此因素涉及 Google Cloud 本身 - 您必须允许相关负责团队使用 Google Cloud 控制台gcloud CLI 或 API 来管理 Google Cloud。

其他资源可能包括:

这些资源的差异在于,它们是必须可以还是不能使用 Google 作为身份提供商。下面几部分将介绍这三种情况。

必须使用 Google 作为身份提供商的资源

必须使用 Google 作为身份提供方的资源包括 Google Cloud 控制台、gcloud CLI、通过 IAP 进行保护的应用以及其他 Google 工具和服务。如需向员工用户授予对这些资源的访问权限,您必须为每个用户预配 Google 身份。

单独维护 Google 身份这种做法与统一身份管理的理念背道而驰。因此,授权用户访问任何此类资源意味着,您必须将您的身份提供商与 Google Cloud 相联合

将您的身份提供商与 Google Cloud 相联合后,请考虑将 Google 用作更多资源的身份提供商,包括可能使用其他方式对用户进行身份验证的应用。

可以使用 Google 作为身份提供商的资源

可以使用 Google 作为身份提供方(但目前尚未这样做)的资源包括:

  • 您计划在 Google Cloud 上部署的、面向员工用户的新应用。
  • 您计划直接原样迁移改进并迁移到 Google Cloud 的、面向员工用户的现有应用。

这些应用能否使用 Google 作为身份提供方取决于您用于身份验证和授权的协议。

Web 单点登录协议

Google 支持多种用于处理身份验证、授权和单点登录的行业标准协议。支持的协议包括:

  • OAuth 2.0,此协议适用于移动客户端、胖客户端和其他非浏览器应用。
  • OpenID Connect 1.0 (OIDC),此协议适用于基于浏览器的应用。
  • SAML 2.0,此协议适用于集成第三方应用。

对于您计划开发的应用,OAuth 2.0 或 OIDC 应为首选协议。这两种协议被广泛采用,您可以利用许多经过充分测试的库和工具。此外,依赖这些协议意味着您可以选择使用 Google 作为身份提供商,并可根据需要灵活地切换身份提供商。

如果您拥有使用 SAML、OAuth 2.0 或 OIDC 的应用,只需进行少量代码更改或无需代码更改即可将其切换至使用 Google 作为身份提供商。

LDAP

轻量级目录访问协议 (LDAP) 是用途最广、最为可靠的身份验证和授权协议之一。应用可以通过多种方式使用 LDAP 进行身份验证和授权。两种最常见的方案是:

  1. 使用 LDAP 进行身份验证并查询用户信息:在此方案中,应用并不使用单点登录方式,而是会向用户显示要求输入用户名和密码的登录表单,然后使用提供的凭据尝试 LDAP bind 操作。如果尝试成功,凭据会被视作有效。系统可从目录中查询有关用户的更多信息(例如名称和群组成员资格),并利用这些信息来授权访问。

  2. 使用 SAML 进行身份验证,使用 LDAP 查询用户信息:在此方案中,应用使用单点登录协议对用户进行身份验证(应用通常使用 SAML 来实现此目的)。用户通过身份验证后,应用使用 LDAP 服务器查询名称和群组成员资格等其他用户信息。

这两种方案的主要区别在于,第一种方案中,应用和 LDAP 服务器都需要访问用户的密码,以便验证凭据。在第二种方案中,应用和服务器不需要访问用户的密码;应用可以通过专用服务用户来执行其 LDAP 查询。

借助安全 LDAP,您可以使用 LDAP 协议访问 Cloud Identity 中的用户和群组信息。如果 Google 是您的主要身份提供商,安全 LDAP 可帮助您同时支持这两种方案。但是,如果您将 Cloud Identity 与外部身份提供商相集成,则 Cloud Identity 不会保留用户密码的副本。这样的话,只能通过安全 LDAP 实现第二种方案。

Kerberos 和 NTLM

如果您计划将基于 Windows 的工作负载迁移到 Google Cloud,则其中一些应用可能会依赖集成式 Windows 身份验证 (IWA),而不是使用标准协议。在 Microsoft IIS 上运行的基于 ASP.NET 的应用通常会选择 IWA。IWA 受欢迎的原因在于,已使用网域凭据登录其 Windows 工作站的用户可以通过它获得无缝的单点登录体验。

IWA 依赖于 NTLMKerberos。它要求用户的工作站和运行应用的服务器加入同一 Active Directory 域或信任网域。

依赖 NTLM 和 Kerberos 的一项后果是,使用 IWA 的应用无法使用 Google 作为身份提供商。但是,您仍可重构应用以使用 OIDC。OIDC 不要求用户的工作站或服务器加入网域。因此,重构可以简化部署并帮助您寻求替代部署选项

鉴于 IWA 可提供无缝的单点登录体验,使用 OIDC 来代替 IWA 似乎会导致用户体验降级。但是,情况并非必然如此。若能确保用户可以无缝登录到 AD FS 或 Azure AD,便可避免上述情况。

下图通过一个简化示例展示了如何使用 Cloud Identity、AD FS 和 IWA 来实现 Web 应用的无缝单点登录:

如何使用 Cloud Identity、AD FS 和 IWA 实现 Web 应用的无缝单点登录

  1. 用户通过网络浏览器请求受保护的页面。
  2. Web 应用使用 OIDC(OIDC 身份验证流程)启动登录。此流程将浏览器重定向到 Google 登录端点。
  3. Google 登录端点将 Google 登录页面返回给用户,提示其输入电子邮件地址。
  4. 用户输入其电子邮件地址。
  5. Google 登录端点根据电子邮件地址识别 Cloud Identity 账号并确认该账号已配置为使用 SSO。然后,登录端点使用 AD FS 启动 SAML 登录。
  6. AD FS 配置为使用 IWA,请求浏览器提供 Kerberos 票证,这会触发浏览器请求底层 Windows 操作系统获取合适的票证。
  7. 除非已缓存了合适的票证,否则 Windows 会联系 Active Directory 密钥分发中心 (KDC),并请求根据用户登录 Windows 时获取的票证授予票证 (TGT) 发出合适的服务票证。
  8. 浏览器将新获取的票证提供给 AD FS。
  9. AD FS 通过检查该票证的加密签名验证该票证,从该票证中提取用户身份,然后向 Google 登录端点颁发 SAML 令牌。
  10. Google 登录端点使用此 SAML 令牌中的身份验证信息完成 OIDC 登录,并向 Web 应用颁发 OpenID Connect 令牌。
  11. 当用户通过身份验证后,该受保护的页面可以返回给用户。

SSH 公钥身份验证

如果您计划在 Google Cloud 上运行 Linux 虚拟机,则可能需要对这些机器进行 SSH 访问。对于 SSH 访问,最常用的身份验证方法是公钥身份验证。

与之前讨论的单点登录协议不同,SSH 公钥身份验证不会依赖某一集中式身份提供商来做出身份验证决策。相反,其身份验证决策具有分散化的特点,即每台机器会根据一组已获授权的本地公钥来处理身份验证。

您可以使用 OS Login 弥合分散式 SSH 公钥身份验证与集中式身份管理之间的差距。OS Login 通过以下方式将 SSH 密钥的生命周期与用户账号的生命周期相关联:

  • 在用户账号被创建或用户首次尝试使用 SSH 时,发布 SSH 公钥。
  • 将用户的公钥预配给用户有权访问的机器。
  • 在撤消账号访问权限、停用账号或删除账号时取消预配用户的公钥。

使用 OS Login 实际上使 Cloud Identity 成为 Linux 实例的 IdP。

不能使用 Google 作为身份提供方的资源

一些资源无法直接将 Google 用作身份提供商。但通过结合使用下面两种方法,您仍然可以在 Google Cloud 上容纳这些资源:

如果资源依赖的协议不受 Google 身份提供商支持,则该资源无法使用 Google 作为身份提供商。此类协议包括:

  • 用于身份验证的 LDAP:尽管您可以使用安全 LDAP 更加方便地通过 LDAP 查询 Cloud Identity 中的用户信息,但当与外部身份提供商联合时,Cloud Identity 不支持使用 LDAP 进行身份验证。

    为了让应用使用 LDAP 进行身份验证,您可以公开复制本地 LDAP 目录,也可以将您的 Active Directory 扩展到 Google Cloud

  • WS-Trust、WS-Federation:特别是在使用 AD FS 时,您可能仍会依赖 WS-Trust 或 WS-Federation 来处理基于令牌的身份验证。除非您可以将受影响的应用改为使用 SAML 或 OpenID Connect,否则最好向 Google Cloud 公开您的本地 AD FS,并让应用直接使用 AD FS。

  • OpenID Connect 与特定于 AD FS 的声明:AD FS 和 Google 支持 OpenID Connect。如果您一直在使用 AD FS 作为 OpenID Connect 提供商,则可能依赖于某些 Google 不支持的特定于 AD FS 的声明。如果是这样,请考虑向 Google Cloud 公开您的本地 AD FS,并让受影响的应用直接使用 AD FS。

  • Kerberos、NTLM:如果您的某些应用使用 Kerberos 或 NTLM 进行身份验证,您也许能将其修改为使用 OpenID Connect 或 SAML。如果无法实现,您可以将相关应用部署到已加入网域的 Windows 服务器上,并将您的本地 Active Directory 复制到 Google Cloud 或向 Google Cloud 公开这些内容。

  • Windows 虚拟机:如果您在 Google Cloud 上运行 Windows 工作负载,则必须能够通过远程桌面协议 (RDP)、远程桌面网关或其他方式登录这些虚拟机。如果某用户对创建了虚拟机的 Google Cloud 项目具有写入权限,则 Google Cloud 允许该用户创建用户账号和密码,这会在该虚拟机的本地 Security Account Manager (SAM) 数据库中创建一个账号。至关重要的是,生成的 Windows SAM 账号不会与用户的 Google 账号相关联,并且这两种账号的生命周期互不相关。如果您暂停或删除用户的 Google 账号,Windows SAM 账号不受影响,并可继续提供对虚拟机的访问权限。

    如果您拥有的 Windows 虚拟机数量以及必须能够登录这些机器的用户数量较为适中,那么让用户生成 Windows 用户账号和密码不失为一种可行的方法。但当管理大量 Windows 服务器时,最好将本地 Active Directory 扩展到 Google Cloud,并将各个服务器加入网域。如果您依赖于网络级别身份验证,同样需要将服务器加入网域。

可用性

需要考虑的最后一个因素是可用性。对您的许多工作负载而言,对用户进行身份验证的能力很可能至关重要,因此身份提供商服务中断可能造成深远的影响。应采用哪种方法来确保适当的可用性取决于您打算如何使用 Google Cloud 以及它如何融入您的混合策略。

分布式工作负载

为了充分利用每个计算环境提供的独特功能,您可以使用混合多云端方法,跨环境分配工作负载。这些环境彼此之间可能相互依赖,这种依赖性对工作负载的可用性至关重要。依赖项可能包括 VPN 隧道、互连、彼此通信的应用或跨计算环境访问数据的系统。

在将您的外部身份提供商联合或扩展到 Google Cloud 时,请确保外部身份提供商和进行身份验证所需的其他系统的可用性达到或超过其他关键依赖项的可用性。这意味着您可能既需要以冗余方式部署外部身份提供商及其依赖项,又需要确保有冗余的网络连接。

冗余工作负载

如果您使用 Google Cloud 来确保业务连续性,则 Google Cloud 上的工作负载会镜像您的计算环境中的部分工作负载。这种设置的目的在于,当发生故障时,一个计算环境可以接替另一个环境继续运行。因此,您需要考虑这些环境之间的所有依赖项。

如果让 Google Cloud 依赖在本地运行的外部身份提供商,则会生成一个依赖项。该依赖项可能会危害让 Google Cloud 成为计算环境的独立副本这一意图。

请试着将您的身份提供商复制到 Google Cloud,以防本地计算环境的服务中断或 Google Cloud 与本地网络之间的连接中断影响到 Google Cloud 上的任何工作负载。

后续步骤