Google 身份管理概览

所有 Google 服务(包括 Google Cloud、Google Marketing Platform 和 Google Ads)都依赖于 Google 登录对用户进行身份验证。本文档介绍了 Google 登录进行身份验证和身份管理所依赖的网域模型。网域模型可帮助您了解 Google 登录在企业环境中的工作原理、身份的管理方式,以及如何促进与外部身份提供商 (IdP) 集成。下图展示了这些实体的交互方式。

网域模型概览。

如图所示,模型的中心是 Google 登录所用的 Google 身份。Google 身份与许多其他实体相关,这些实体在管理身份方面具有相关性:

  • 面向消费者的 Google 包含与面向消费者的 Google 服务(如 Gmail)相关的实体。
  • 面向组织的 Google 包含由 Cloud IdentityG Suite 管理的实体。 这些实体与管理公司身份的相关度最高。
  • Google Cloud 包含特定于 Google Cloud 的实体。
  • 外部包含将 Google 与外部 IdP 集成的相关实体。

图中的实线箭头表示实体互相引用(常规连接器)或互相包含(菱形连接器), 而虚线箭头表示联合关系。

Google 身份

身份、用户和用户帐号在身份管理中发挥着至关重要的作用。这 3 个术语密切相关,有时甚至可互换使用。但在涉及身份管理时,需要区分这些概念:

  • “身份”是一个名称,用于唯一标识与 Google 服务进行交互的人员。Google 将电子邮件地址用于此用途。使用者的电子邮件地址会被视为其 Google 身份。

    验证使用者与身份之间关联关系的过程称为身份验证或登录,此过程旨在证明使用者确实拥有此身份。

    一个使用者可能拥有多个电子邮件地址。由于 Google 服务使用电子邮件地址作为身份,因此该使用者会被视为拥有多个身份。

  • “用户帐号”是一种数据结构,用于跟踪特定身份与 Google 服务交互时应该应用的特性、活动和配置。用户帐号不是即时创建的,但需要在首次登录前进行预配。

    用户帐号由未对外部公开的 ID 进行标识。因此,界面或 API 要求您通过其关联的身份(如 alice@gmail.com)间接引用用户帐号。尽管存在这种间接性,但所有数据和配置详细信息仍与用户帐号相关联,而与身份无关。

在大多数情况下,用户帐号和身份之间是一对一的关系,这使得它们容易混淆。但是,情况并非总是如此,如以下边缘用例所示:

  • 用户帐号和身份之间的关系不固定。 您可以更改用户帐号的主电子邮件地址,从而将另一个身份与该用户相关联。

    作为 Cloud Identity 或 G Suite 管理员,您甚至可以交换两个用户的主电子邮件地址。例如,如果您交换了 Alice (alice@example.com) 和 Bob (bob@example.com) 的主电子邮件地址,那么 Alice 将使用 Bob 的旧用户帐号,而 Bob 将使用 Alice 的旧用户帐号。由于数据和配置与用户帐号(而非身份)相关联,因此 Alice 现在会使用 Bob 的现有配置和数据(而 Bob 则会使用 Alice 的配置和数据)。下图展示了这种关系。

    Bob 和 Alice 的身份的关系。

    在非联合设置中,您还必须重置密码,以便 Alice 和 Bob 交换用户帐号。在 Alice 和 Bob 使用外部 IdP 进行身份验证的联合设置中,不需要重置密码。

  • 身份和用户之间可能并非一对一关系。一个消费者帐号可以有意与多个身份关联,如下图所示。

    一个身份也有可能代表两个不同的用户帐号。 我们建议您避免这种情况,但如果存在有冲突的用户帐号,仍可能会出现这种情况。 在这种情况下,系统会在身份验证过程中向用户显示投票屏幕,让用户选择要使用的用户帐号。

    Alice:用户和身份并不总是一一对应的。

Google 区分了两种类型的用户帐号:消费者帐号和受管用户帐号。以下部分更详细地介绍了这两种类型的用户帐号及其相关实体。

面向消费者的 Google

如果您拥有一个类似 alice@gmail.com 的 Gmail 电子邮件地址,那么您的 Gmail 帐号就是一个消费者帐号。同样,如果您在 Google 登录页面上使用创建帐号链接,并且在注册时提供自己的自定义电子邮件地址(如 alice@example.com),则生成的帐号也是消费者帐号。

消费者帐号

消费者帐号由使用者自己创建,主要用于私人用途。消费者帐号的创建者对帐号以及使用该帐号创建的所有数据拥有完全控制权。使用者在注册时使用的电子邮件地址将成为消费者帐号的主电子邮件地址,并用作其身份。使用者可以向消费者帐号添加电子邮件地址。这些电子邮件地址将用作辅助身份,也可用于登录。

当消费者帐号使用的主电子邮件地址与 Cloud Identity 或 G Suite 帐号的主网域或辅助网域相对应时,此消费者帐号也称为“非受管用户帐号”。 由于您无法将 gmail.com 添加为您的 Cloud Identity 或 G Suite 帐号的网域,因此只有非 Gmail 消费者帐号可以成为非受管用户帐号。

消费者帐号可以是任意数量的群组的成员。

面向单位的 Google

如果您的单位使用 Google 服务,则最好使用受管用户帐号。这些帐号被称为“受管”帐号,因为其生命周期和配置可由单位完全控制。

受管用户帐号是 Cloud Identity 和 G Suite 的一项功能。

Cloud Identity 或 G Suite 帐号

Cloud Identity 或 G Suite 帐号是用户、群组、配置和数据的顶层容器。当公司注册 Cloud Identity 或 G Suite 并与租户的概念对应时,系统会创建 Cloud Identity 或 G Suite 帐号。

Cloud Identity 和 G Suite 共用一个通用技术平台。两款产品使用同一组 API 和管理工具,并共用帐号这一概念作为用户和群组的容器;此容器通过域名进行标识。在管理用户、群组和身份验证方面,这两款产品大致相同。

帐号包含群组以及一个或多个单位部门。

单位部门

单位部门 (OU) 是用户帐号的子容器,可让您将 Cloud Identity 或 G Suite 帐号中定义的用户帐号细分为不相交的分组,以方便管理。

单位部门以分层方式进行组织。每个 Cloud Identity 或 G Suite 帐号都有一个根级单位部门,您可以在此根据需要创建更多单位部门。 您还可以嵌套单位部门。

Cloud Identity 和 G Suite 可让您按单位部门应用特定配置,例如许可分配两步验证。 这些设置会自动应用于单位部门中的所有用户,子单位部门也会继承这些设置。因此,单位部门在管理 Cloud Identity 和 G Suite 配置方面起着至关重要的作用。

一个用户帐号不能同时属于多个单位部门,因此单位部门与群组不同。 虽然单位部门在将配置应用于用户帐号时很有用,但不能用于管理访问权限。如需管理访问权限,我们建议您使用群组。

虽然单位部门类似于 Google Cloud 文件夹,但这两个实体的用途不同,并且彼此无关。

受管用户帐号

受管用户帐号的作用与消费者用户帐号类似,但其由 Cloud Identity 或 G Suite 帐号管理员完全控制。

受管用户帐号的身份由其主电子邮件地址定义。 主电子邮件地址必须使用与添加到 Cloud Identity 或 G Suite 帐号的主网域、辅助网域或别名网域对应的网域。受管用户帐号可以有其他别名电子邮件地址辅助电子邮件地址,但这些地址不会被视为身份,也不能用于登录。例如,如果 Alice 使用 alice@example.com 作为她的主电子邮件地址,并将 ally@example.com 配置为别名电子邮件地址,将 alice@gmail.com 配置为辅助电子邮件地址,则 Alice 只能使用 alice@example.com 进行登录。

受管用户帐号包含在单位部门中,可以是任意数量群组的成员。

受管用户帐号应由真人用户(而非机器用户)使用。机器用户帐号是由应用或虚拟机 (VM) 实例(而非真人)使用的特殊帐号。Google Cloud 为机器用户提供服务帐号。 (本文档稍后会详细介绍服务帐号。)

群组

您可以通过群组将多个用户捆绑在一起。您可以使用群组管理邮寄名单,也可以为多个用户应用共同的访问权限控制设置或配置。

Cloud Identity 和 G Suite 按电子邮件地址(例如 billing-admins@example.com)标识群组。与用户的主电子邮件地址类似,群组电子邮件地址必须使用 Cloud Identity 或 G Suite 帐号的主网域、辅助网域或别名网域之一。除非将群组用作邮寄名单,否则电子邮件地址无需与邮箱对应。身份验证仍使用用户的电子邮件(而非群组电子邮件),因此用户无法使用群组电子邮件地址登录。

群组可以将以下实体作为成员:

  • 用户(受管用户帐号或消费者帐号)
  • 其他群组
  • 服务帐号

与单位部门不同,群组不能作为容器:

  • 用户或群组可以是任意数量群组的成员,而不仅仅是一个群组。
  • 删除群组不会删除任何成员用户或群组。

群组可以包含任何 Cloud Identity 或 G Suite 帐号的成员以及消费者帐号。您可以使用禁止单位外部的成员设置,将成员限制为同一 Cloud Identity 或 G Suite 帐号的用户帐号。

外部身份

通过联合 Cloud Identity 或 G Suite 帐号与外部 IdP,您可以让员工使用现有身份和凭据登录 Google 服务。

在最基本的层面上,联合需要使用 SAML 设置单点登录,从而将 Cloud Identity 或 G Suite 中的身份关联到由外部 IdP 管理的身份。如需关联像 alice@example.com 这样的身份并允许其通过单点登录的方式登录 Google,您必须满足以下两个前提条件:

  • 您的外部 IdP 必须识别身份 alice@example.com 并允许将其用于单点登录。
  • 您的 Cloud Identity 或 G Suite 帐号必须包含一个使用 alice@example.com 作为身份的用户帐号。此用户帐号必须在首次进行单点登录之前就已存在。

您无需在 Cloud Identity 或 G Suite 中手动创建和维护用户帐号,只需将基于 SAML 的单点登录与自动用户预配相结合即可自动执行此过程。自动用户预配的概念是将外部权威来源中的所有或部分用户和群组同步到 Cloud Identity 或 G Suite。

根据您选择的 IdP,基于 SAML 的单点登录和自动用户预配可能会由同一软件组件处理,也可能需要单独的组件。因此,网域模型区分了“SAML 身份提供商”和“外部权威来源”

外部 SAML 身份提供商

外部 IdP 是唯一的身份验证系统,可为您的员工提供跨应用的单点登录体验。它位于 Google 外部,因此称为“外部身份提供商”

当您启用单点登录时,Cloud Identity 或 G Suite 会将身份验证决策中继到 SAML IdP。就 SAML 而言,Cloud Identity 或 G Suite 充当服务提供商,其信任 SAML 身份提供商以其名义验证用户的身份。

每个 Cloud Identity 或 G Suite 帐号最多可以代表一个外部 IdP。多个 Cloud Identity 或 G Suite 帐号可以代表不同的 SAML IdP,但单个 Cloud Identity 或 G Suite 帐号不可能使用多个 SAML IdP。

常用的外部 IdP 包括 Active Directory Federation Services (AD FS)、Azure AD、Okta 或 Ping Identity。

外部权威来源

身份的权威来源是您用来创建、管理和删除员工身份的唯一系统。它位于 Google 外部,因此称为“外部权威来源”

在外部权威来源中,用户帐号和群组可以自动预配到 Cloud Identity 或 G Suite。 预配可以由权威来源本身或预配中间件进行处理。

若要使自动用户预配生效,必须为用户预配 SAML IdP 能够识别的身份。如果您在身份之间进行映射(例如将 Cloud Identity 或 G Suite 中的身份 alice@example.com 映射到 SAML IdP 中的 u12345@corp.example.com),则 SAML IdP 和预配中间件必须执行相同的映射。

外部用户帐号

我们假定外部身份提供商具有可跟踪姓名、特性和配置的用户帐号的概念。

权威来源(或预配中间件)应将所有(或部分)外部用户帐号预配到 Cloud Identity 或 G Suite,以便提供登录体验。在许多情况下,仅将用户特性的一部分(例如电子邮件地址、名字和姓氏)传播到 Cloud Identity 或 G Suite 就已足够,这样可以限制数据冗余。

外部群组

如果您的外部 IdP 支持群组的概念,则可以选择将这些群组映射到 Cloud Identity 或 G Suite 中的群组。

映射和自动预配群组是可选的,单点登录不需要这两个步骤,但如果您要重复使用现有群组来控制 G Suite 或 Google Cloud 中的访问权限,这两个步骤会很有用。

Google Cloud

与其他 Google 服务一样,Google Cloud 依靠 Google 登录对用户进行身份验证。Google Cloud 还与 G Suite 和 Cloud Identity 紧密集成,让您能够高效地管理资源。

Google Cloud 引入了组织节点、文件夹和项目的概念。这些实体主要用于管理访问权限和配置,因此它们仅与身份管理略微相关。但是,Google Cloud 还包含其他类型的用户帐号:服务帐号。服务帐号属于项目,其在身份管理中发挥着至关重要的作用。

组织节点

组织Google Cloud 资源层次结构中的根节点,也是项目和文件夹的容器。组织可帮助您按层次结构组织资源,并且对于集中高效地管理资源至关重要。

每个组织都属于一个 Cloud Identity 或 G Suite 帐号。组织名称来源于相应的 Cloud Identity 或 G Suite 帐号的主域名。

文件夹

文件夹是 Google Cloud 资源层次结构中的节点,可以包含项目、其他文件夹或两者的组合。您可以使用文件夹对共用相同 Identity and Access Management (IAM) 政策组织政策的资源进行分组。这些政策会自动应用于文件夹中的所有项目,子文件夹也会继承这些政策。

文件夹与单位部门类似但不相关。 单位部门可帮助您管理用户并为用户应用通用配置或政策,而文件夹可帮助您管理 Google Cloud 项目并为项目应用通用配置或政策。

项目

项目是资源的容器。 项目在管理 API、结算和管理资源访问权限方面发挥着至关重要的作用。

项目与身份管理相关,因为它们是服务帐号的容器。

服务帐号

“服务帐号”(即 Google Cloud 服务帐号)是一种特殊类型的用户帐号,旨在供应用和其他类型的机器用户使用。

每个服务帐号都属于一个 Google Cloud 项目。 与受管用户帐号一样,管理员可以完全控制服务帐号的生命周期和配置。

服务帐号也使用电子邮件地址作为其身份,但与受管用户帐号不同,电子邮件地址始终使用 Google 拥有的网域,例如 developer.gserviceaccount.com

服务帐号不参与联合,也没有密码。在 Google Cloud 上,您可以使用 IAM 控制服务帐号对计算资源(例如虚拟机或 Cloud Functions 函数)的权限,从而无需管理凭据。在 Google Cloud 之外,您可以使用服务帐号密钥让应用通过服务帐号进行身份验证。

Kubernetes 服务帐号

Kubernetes 服务帐号是 Kubernetes 的概念,在您使用 Google Kubernetes Engine (GKE) 时相关。 与 Google Cloud 服务帐号类似,Kubernetes 服务帐号供应用(而非真人)使用。

Kubernetes 服务帐号可用于在应用调用 Kubernetes 集群的 Kubernetes API 时进行身份验证,但无法在集群外部使用。它们无法被任何 Google API 识别,因此不能替代 Google Cloud 服务帐号。

将应用部署为 Kubernetes Pod 时,您可以关联 Pod 与服务帐号。 此关联可让应用使用 Kubernetes API,而无需配置或维护证书或其他凭据。

通过使用 Workload Identity,您可以关联 Kubernetes 服务帐号与 Google Cloud 服务帐号。此关联可让应用也向 Google API 进行身份验证,而无需维护证书或其他凭据。

后续步骤