原文链接：Identity Architect Ground Rules: Ten IAM Design Principles, By Prabath Siriwardena.

引言

在数字化转型时代，正确实施身份和访问管理（IAM）可以成为构建成功业务的关键催化剂。 IAM 解决了在日益异构的技术环境中确保资源被恰当访问的关键任务需求，并满足日益严格的合规要求。作为一种安全实践，IAM 是任何企业都必须承担的重要任务。它越来越与业务对齐，除了技术专业知识外，还需要具备业务技能。

IAM 系统包含多个组件：新建账户（或入职）、账户管理、身份治理、身份识别（或认证）、访问控制（或授权）和联邦认证。 IAM 是一个广泛的领域，因此这些组件可以进一步划分为具体的子组件。例如，账户创建本身关注用户账户的带内/带外创建、即使创建、审批工作流，而账户管理则涉及特权账户管理、凭证管理、用户/组/角色管理。

本白皮书将重点关注 IAM 架构师在从头构建 IAM 基础设施时必须考虑的低级设计原则。

规则一：使用不可变的私有标识符或者可变的公共标识符

在任何一个 IAM 系统中，用户由一个或多个标识符所标识。这些标识符可以包括用户名（用户自己选择）、电子邮件地址、电话号码、保险单号或系统中唯一的任何标识符。用户可以选择其中任何一个来证明自己并访问系统。例如，你可以使用电子邮件地址或电话号码登录 Facebook。你也可以拥有多个电子邮件地址，并使用其中任何一个。这些是你的公共标识符，你不会介意与他人共享。

这些公共标识符是可变的。用户应有权选择更改它们。你应该能够在不影响系统的情况下，更改电话号码、电子邮件地址等。有些系统或者运营商会回收电子邮件地址和电话号码，这可能会导致系统中在不同时间（而不是同时）注册了两个或更多用户使用相同的电子邮件地址或电话号码。

这就需要有一个不可变的私有标识符。私有标识符是系统生成的标识符，它在系统和时间上是唯一的，从不与用户分享，只在系统内部使用。系统中需要有一个地方将此私有标识符映射到给定用户的一个或多个公共标识符。除了这个映射表，用户的公共标识符在系统中从不用于任何引用，而仅使用私有标识符。在登录事件中，提供的公共标识符与对应的私有标识符匹配，并用于验证用户。所有的审计日志和分析都针对私有标识符保存。为了使分析仪表板和报告有意义，映射表可以用来找到用户更有意义、更易读的标识符，仅用于显示目的。

由于我们使用不可变的标识符维护给定用户的所有内部引用，公共标识符的更改对系统将没有任何影响。

规则二：将核心/静态个人身份信息（PII）与事务数据分离

根据 NIST 所定义的，个人身份信息（PII）是指任何由机构维护的关于个人的信息，包括任何可以用来区分或追踪个人身份的信息（例如姓名、社会安全号码、出生日期和地点、娘家姓或生物特征记录）或任何与个人相关联或可关联的信息（例如医疗、教育、财务或就业信息）。

静态（或接近静态）的 PII 包括你的名字、姓氏、电子邮件、电话号码、社会安全号码等。其他与您相关的事务数据包括医疗记录、教育/财务记录、登录模式等。在构建你的 IAM 基础设施时，事务数据必须与静态 PII 分离，并且这些数据可以用自动生成的不可变系统标识符来链接，如"规则一"中所述。

这种分离有助于独立扩展事务数据，而不依赖于静态 PII。你可以根据数据类型独立选择适合你需求的存储类型。此外，这种分离解决了数据隐私问题。你不需要担心加密任何事务数据，但需要加密 PII 和映射表（该表将 PII 映射到自动生成的不可变系统标识符）。当你被要求删除用户时，为了遵守隐私法规（如 GDPR），你只需要删除静态 PII 和相应的映射。这样就可以使相应的事务数据匿名化。

规则三：将生物识别信息与其他 PII 分离

Aadhaar 是印度政府的一个天马行空的构想，旨在保障居民拥有无法遗忘的身份信息的基本权利，它是世界上最大的生物识别数据集合。它收集了超过 10 亿印度居民的指纹和虹膜。除了生物识别信息，Aadhaar 还收集每位居民（不一定是公民）的姓名、出生日期、性别、地址、手机/电子邮件（可选），并将这些信息与相应的指纹和虹膜模式存储在一起。

由 FBI 运行的美国综合自动指纹识别系统（IAFIS）是另一个大型生物识别数据库，其中包括指纹、面部图像和其他身体特征，如身高、体重、发色、眼色，甚至疤痕和纹身。该数据库包含超过 7000 万份犯罪记录和 3400 万份民事记录，执法人员可以365天7*24小时访问这些记录。

生物识别信息有两种常见的使用场景：身份识别和身份验证。生物识别身份识别回答“你是谁”这个问题，通常适用于需要识别个人的情况。组织会从该个人那里采集生物识别信息，然后在生物识别存储库中进行搜索，以尝试正确识别该人。这在许多国际机场都会发生。它会采集你的虹膜和指纹，并尝试与你的记录进行匹配。

生物识别身份验证则回答“你能证明你是谁吗”这个问题，主要与数字场景中的身份验证相关。它进行一对一匹配，查看你的生物识别信息是否与声称身份的人相符。大多数企业使用生物识别信息作为第二因素来验证用户身份。这里我们需要关注的一个关键问题是如何存储生物识别数据。生物识别注册和匹配是由专门的生物识别引擎完成的。生物识别引擎将生物识别模板存储在用户的记录中。这里我们必须将 PII 与生物识别数据分离，最简单的方法是获取不可变私有标识符（这是一个假名）的哈希值，并将其与生物识别数据一起存储。采集生物识别数据的人将无法将其与相应用户的 PII 关联起来。即使攻击者获得了 PII 和生物识别数据存储，他/她仍然需要遍历所有的不可变私有标识符，对其进行哈希处理，然后找到匹配项。请记住，我们对 PII 匹配表中的私有标识符进行了加密，因此攻击者还需要获取相应的密钥，这使得攻击者更加困难。

规则四：外部化访问控制规则

访问控制规则反映了业务需求。它们应该以这样的方式呈现，即能够将业务需求的变化吸收到访问控制规则中，并且影响和工作量都要最小化。实现这一目标的关键基础是将你的访问控制规则外部化，以便你对它们有更多控制，并且这些规则可以独立于应用程序代码发展。另一个重要方面是职责分离。在企业中，决定访问控制规则的不是应用程序开发人员，也不是身份架构师，而是业务本身。这不是技术决策，而是业务决策。此外，在生产部署中，配置访问控制规则的不是开发人员或架构师，而是 IAM 管理员或系统管理员。因此，外部化规则有助于你在没有重大障碍的情况下实现这一目标。

一旦规则被外部化，你必须考虑如何最好地表示它们以及如何执行它们。作为身份架构师，你需要构建一个用于策略管理、策略执行、策略评估和策略存储的架构。如果你计划从头开始构建，我们推荐使用 XACML，因为它提供了一个参考架构、一种策略语言和一个请求/响应协议。 XACML 参考架构定义了一个策略管理点（PAP）、策略决策点（PDP）、策略执行点（PEP）、策略信息点（PIP）及其之间的交互。 XACML 的策略语言是基于 XML 的。它在功能上非常丰富，但并不是很简单，工具支持需要一些工作量。

XACML 请求/响应模型可以是基于 XML 的，也可以是基于 JSON 的——并且 PEP 和 PDP 之间的交互可以通过 REST API 标准化。然后，你首先需要关注访问控制需求，然后决定如何将这些需求表示为策略。始终优先选择标准，但你不需要仅仅因为它是标准而使用它，即使它过度满足了你的需求。此外，还要查看周围的其他内容，例如，AWS 开发了自己的基于 JSON 的策略语言来控制对 AWS 资源的访问。

如果你打算构建自己的策略语言（类似于 AWS 所做的），你需要清楚地识别和区分规则与数据。例如，假设你需要有一条策略，规定医生只能查看属于他/她的病人的记录。你不应该将医生的名字和所有属于他的病人的名字放入策略本身。这是动态变化的数据。你只需要在策略中提供某种参考，并提供一些策略信息点（PIPs）来解释这些参考，获取数据，并将数据输入策略引擎。再次强调，构建策略引擎是有成本的，因此你也可以考虑开发自己的 DSL（领域特定语言）并编写一个翻译器，将其运行在成熟的 XACML 引擎上或者甚至规则引擎上。

规则五：确保低信任平面没有写访问权限

网络中的每个组件都有一个信任级别。 IAM 部署中的关键组件包括身份提供者（IdP）、身份存储（ldap/数据库）、元数据/策略存储、网关（策略执行点），以及最终的服务提供者。这些组件中的每一个或一些可以在不同的信任平面上。

身份提供者和身份存储不必在同一个信任平面上。然而，在大型企业中，可能会有多个身份提供者。

例如，WSO2 曾合作过的美国最大的通信和网络基础设施服务提供商之一的公司，他们在其企业身份存储上部署了核心身份提供者。在这种情况下，身份提供者和身份存储部署在同一个信任平面上。这个身份提供者是其企业身份基础设施的骨干——唯一的可信来源——由企业 IT 团队管理。我们参与的项目是其中一个部门的项目，在这个部门里身份提供者部署在不同的信任平面上。该部门下部署的所有服务提供者/应用程序只信任其自己的身份提供者。部署在部门级别的身份提供者（称为本地身份提供者）在信任级别上低于企业身份提供者和企业身份存储。因此，它不能直接写入高信任平面的身份提供者。两个身份提供者之间的通信通过 SAML 2.0 Web SSO 实现。服务提供者/应用程序所需的所有附加用户属性集中在本地身份提供者处捕获，并即时（JIT）配置。同样，即使在同一个部门内，本地身份提供者和服务提供者也在不同的信任平面上。服务提供者只能获得身份提供者 API 的只读访问权限。

在不同信任平面上构建和设计 IAM 基础设施有助于根据信任级别分散责任和所有权。

规则六：将 B2C 与 B2E 和 B2B 分离

在 B2E 的 IAM 中，新建账号是雇主的责任，而在 B2C 中，新建账号主要是自助完成。换句话说，对于员工来说，HR 部门发起员工的入职新建账号过程，并且是用户账户的所有者，而对于客户来说，在大多数情况下，新建账号通过自助注册完成。可能是一个全新的客户，也可能是一个现在想使用公司在线服务的现有客户。让我给你举几个后者的例子。

WSO2 最近与美国一家著名的寿险公司合作。这些保险代理人销售保险政策；为了在线支付和索赔，客户必须通过公司网站注册。客户注册表要求提供一些最少的详细信息，如保单号码、社会安全号码、姓名和出生日期，并且用户提供的信息将自动与系统中已记录的用户数据（在原始保单售出之后）进行验证。

另一家是向个人和医疗机构销售医疗设备的公司，允许他们通过公司网站注册以使用在线服务。就像前一个例子一样，医疗设备是由销售代理销售的，所有客户数据都记录在 Salesforce 中。当客户决定在线注册时，客户输入的数据将与 Salesforce 中已记录的数据进行验证。

WSO2 还与西海岸的一家公司合作，这家公司正在构建企业级虚拟数据中心。他们遵循与前一个例子中解释的相同模式。他们首先也是在销售代理在 Salesforce 中维护客户记录，然后客户可以通过公司在线门户提供先前记录在 Salesforce 中的相同信息进行注册。客户入职过程中有很多例子和变体。除了上述情况，还有许多与 WSO2 合作的公司向新客户开放用户注册。大多数这些公司允许客户通过已知的公共身份提供者进行注册。这大大降低了注册的初始门槛，并且有多项研究证实，与已知的公共身份提供者（如 Facebook、Google、Microsoft Live）集成后，用户注册的成功率显著提高。

B2E/B2B IAM 也统称为劳动力 IAM。劳动力 IAM 是面向内部的。劳动力 IAM 关注 B2E（企业对员工）和 B2B（企业对企业）互动。劳动力 IAM 的目标是通过利用身份数据来减少与新员工、合作伙伴和供应商的入职和离职相关的风险和成本，而客户 IAM（或 B2C）的目的是通过获取和留住客户来推动收入增长。

劳动力 IAM 的关键挑战是打破企业中的身份孤岛，并构建一个统一的身份平台，从而提高生产力、安全性、治理、监督、合规性和监控。最终，这将减少所有 B2E 和 B2B 互动的风险和成本。最近，我们与美国一家大型分析公司合作，帮助他们从当前相当随意的 IAM 系统迁移到优化的模型。关键挑战是提出一个跨所有应用程序构建统一身份系统的模型。他们有超过 30 个身份存储供多个应用程序使用，同一个用户在每个身份存储中重复存在，没有关联标识。需要注意的是，B2C、B2E 和 B2B IAM 模型各自有其设计目标和挑战。没有一体化的解决方案。此外，你需要独立构建这些 IAM 模型，不在员工和客户之间共享相同的身份存储和身份提供者。如果你有需要客户和员工同时访问的应用程序，你需要考虑采用联合模型。

规则七：确保属性共享的持久化假名

在 IAM 基础设施中运行的身份提供者的一个关键责任是作为唯一的可信来源。公司网络中的所有其他组件（以及更广泛的网络）都信任身份提供者发布的断言。这些断言可以是身份验证断言、属性断言或授权断言。断言与经过身份验证的主体绑定。身份提供者在此处应该使用什么主体标识符来表示经过身份验证的用户？要回答这个问题，请参阅规则 1。

正如名称所示，公共可变标识符是可变的。如果使用其中一个作为主体标识符，那么在身份提供者端更改该属性后，服务提供者将难以关联用户。那使用私有不可变标识符（作为主体标识符）呢？再一次，正如名称所示，它应该是私有的，不应在外部共享。

推荐的方法是按用户或按服务提供者使用持久化假名。每个用户对每个服务提供者都会有一个不同的假名，并在身份提供者处映射到其私有不可变标识符。每个服务提供者可以使用此假名作为关联句柄。这也解决了一些隐私问题。如果在多个服务提供者之间共享相同的标识符，那么这些服务提供者就可以一起发现你的行为/访问模式。这在公司环境中可能不是关键问题，但如果你正在构建一个公共身份提供者，这将是一个关键问题。

规则八：标准规则 - 随意修复，但不要破坏！

需要注意的是，今天没有任何身份产品仅通过支持开放身份标准就能获得竞争优势，因为这是任何身份产品的基本要求和期望。也就是说，如果你构建的身份产品不支持开放标准，那么它本质上就是注定失败的。

标准不是孤立产生的——在标准机构下有许多委员会，如 W3C、IETF、OpenID Foundation、OASIS、Kantara Initiative 等，这些委员会由聪明的人组成，他们孜孜不倦地讨论身份领域的现存问题，构建解决方案，并将其标准化。一旦你定义了自己的问题，你应该花些时间看看现有的身份标准如何帮助你构建解决方案。同样，不要被标准驱动，而是被你自己的问题陈述驱动，总有改进的空间。如果你觉得你的问题没有得到妥善解决，不要犹豫，构建一个解决方案来解决问题，如果你愿意，你可以将你的解决方案提交给标准机构，看看如何将其标准化。这通常是身份标准演变的方式。

让我们来看看今天身份领域使用的一些关键标准——对于身份联合和单点登录，SAML 2.0 Web SSO、OpenID Connect、WS-Federation 是主要的标准。SAML 作为一个标准仍然占据主导地位，但在过去几年中，大多数新的开发项目都使用 OpenID Connect。OpenID Connect 是建立在 OAuth 2.0 之上的标准。对于细粒度访问控制，唯一可用的标准是 XACML，这在本文中已经详细讨论过了。对于配置管理，SCIM 是主要的标准，而 OAuth 2.0 及其周围的多个配置文件是保护 API 和一般访问委托的关键标准。OpenID Foundation 下的 FAPI（金融 API）工作组正在围绕 OAuth 2.0 构建一套标准，主要针对金融应用。用户管理访问（UMA）是另一个在 Kantara Initiative 下开发的显著标准。UMA 尝试在访问委托周围构建一个丰富的、高度解耦的生态系统，并建立在 OAuth 2.0 之上。身份架构师还必须考虑 IETF 下 JOSE 工作组的工作，因为多个标准如 JWS（JSON Web 签名）、JWE（JSON Web 加密）、JWK（JSON Web 密钥）都在该工作组下开发。

规则九：启用自表达凭证

这一点看似基础，但涉及的多个方面却是大多数人很少关注的。通常，组织在构建系统时不会考虑这一点，而在需要升级系统以支持更安全的哈希算法时会遇到挑战。

在任何 IAM 基础设施中，保护用户凭证是一个关键方面。这些凭证可以是密码或任何类型的密钥。例如，在 OAuth 2.0 中，你需要担心保护客户端密钥、访问令牌和刷新令牌。在 IAM 基础设施中存储的凭证有两种类型：你自己拥有（或签发）的凭证和你使用的凭证。第一种包括你签发的密码和 OAuth 密钥。你存储用于访问第三方系统的凭证则属于第二种。例如，启用 Facebook 登录所需的 API 密钥，或访问 Salesforce/Google Apps API 以配置用户的 API 密钥。

第一种凭证可以通过加盐哈希保护，而第二种类型应该通过加密保护。换句话说，当你对凭证进行哈希时，请确保将哈希算法绑定到哈希凭证本身。这样，当你尝试验证凭证时，凭证本身就是自表达的。这种方法有很多好处——比如说，如果你只有一个系统级的哈希算法（你无论如何都需要有一个）。所有用户的密码都使用系统级的哈希算法进行哈希处理。现在假设你需要将哈希算法更改为更安全的算法。对于新用户来说，这不会是个问题，因为所有新凭证将使用新的哈希算法进行存储和验证。但是，对于现有用户的所有凭证验证都会失败，而且没有直接的方法进行批量迁移。这就是这种方法的陷阱。如果你让凭证自表达，那么你就知道如何独立验证每一个凭证。此外，通过这种方法，如果你发现任何凭证存储使用的哈希算法与系统设置不同，你可以在验证时重新哈希并更新系统。

对于任何哈希数据，哈希算法是最重要的。例如，2012 年 LinkedIn 被攻破，密码数据被盗。当时，LinkedIn 使用 MD5 哈希算法存储密码。这是一个非常糟糕的主意，因为早在 1996 年就发现了 MD5 的缺陷，而在 2005 年，其作者也停止推荐使用它。密码存储的首选算法是 PBKDF2 NIST 标准密钥派生函数。这是一种单向算法，可以有意配置为相对缓慢地处理。GPU 破解设备和其他超级计算资源可以每秒尝试数十亿次哈希。当使用经过适当配置的有意缓慢算法时，同一硬件上的数十亿次尝试将变成每秒仅几千次尝试。

规则十：将特权账户视为不同的物种

特权账户是管理员登录服务器、交换机、防火墙、路由器、数据库服务器以及他们必须管理的许多应用程序的方式。在 IAM 基础设施中，有多种场合会使用到特权账户。数据库凭证、身份存储凭证（活动目录）、IAM 管理员凭证（可能访问基于 Web 的管理控制台以执行 IAM 管理功能），以及其他第三方系统/服务账户（访问 IAM API 以执行管理功能）都属于特权账户的范畴。

Forrester 估计，80% 的安全漏洞涉及特权凭证。可以理解的是，入侵者在获取员工设备访问权限后，会尝试监视网络并安装键盘记录器以获取更高权限的凭证（例如 root 或管理员）。与个人账户相比，特权凭证为大规模数据盗窃提供了更大的空间。有了特权凭证，攻击者可以转储整个数据库，绕过网络流量限制，删除日志以隐藏其活动，并更轻松地外传数据。

特权身份管理（PIM）是 IAM 中的一个关键领域，有专门的供应商构建支持 PIM 的产品。在构建任何严肃的 IAM 基础设施时，你需要关注系统如何与 PIM 产品集成。此外，还需要有 PIM 系统以符合行业规定，如 SOX、PCI-DSS、HIPAA、FISMA、BASEL III 等。

结论

本文的目标是涵盖对从头构建 IAM 基础设施的身份架构师有帮助的关键基础。这里讨论的规则并不是全部，但会为架构师提供一个坚实的基础，使他们在开始之前必须考虑这些关键规则。

「你的肯定是我不懈前行的动力」

[译]身份架构细则：十个IAM设计原则

引言