规划 Microsoft Entra 验证 ID 颁发解决方案
对颁发解决方案进行规划很重要，这样除了凭据的颁发外，还可以全面了解解决方案的体系结构和业务影响。 如果还未这样做，建议查看 Microsoft Entra 验证 ID 体系结构概述，了解基础信息。
指南范围
本文介绍有关规划可验证凭据颁发解决方案的技术方面的内容。 用于可验证凭据的 Microsoft 解决方案遵循万维网联合会 (World Wide Web Consortium, W3C) 可验证凭据数据模型 1.0 和分散式身份识别符 (Decentralized Identifier, DID) V1.0 标准，可以与非 Microsoft 服务进行互操作。 但是，此内容中的示例反映了可验证凭据的 Microsoft 解决方案堆栈。
超出此内容范围外的内容可参阅与颁发解决方案不直接相关的支持性技术文章。 例如，可验证凭据颁发解决方案中会用到网站，但不会详细介绍如果规划网站部署。
解决方案组件
在规划颁发解决方案时，你必须设计一个使颁发者、用户和验证程序之间能够交互的解决方案。 下图显示了颁发体系结构的组件。
Microsoft VC 颁发解决方案体系结构
Microsoft Entra 租户
运行 Microsoft Entra 验证 ID 服务的先决条件是其托管在 Microsoft Entra 租户中。 Microsoft Entra 租户为解决方案中的 Azure 资源提供了一个标识和访问管理 (IAM) 控制平面。
每个租户使用多租户 Microsoft Entra 验证 ID 服务，并且具有分散式标识符 (DID)。 分散式身份识别符可证明颁发者拥有分散式身份识别符中包含的域。 使用者和验证者使用分散式身份识别来验证颁发者。
Microsoft Azure 服务
Azure Key Vault 服务存储颁发者密钥，这些密钥在启动 Microsoft Entra 验证 ID 颁发服务时生成。 密钥和元数据用于执行凭据管理操作并提供消息安全性。
每个颁发者都有用于签名、更新和恢复的单个密钥集。 此密钥集用于生成的每个可验证凭据的每个颁发。
Microsoft Entra 验证 ID 服务用于存储凭据元数据和定义；具体而言，即凭据的规则及其显示定义。
显示定义确定声明如何显示在持有者的钱包中，还包括品牌和其他元素。 显示定义可以本地化为多种语言。 请参阅如何自定义可验证凭据。
规则是颁发者定义的模型，用于描述可验证凭据的所需输入。 规则还定义了受信任的输入源，以及 VC 中存储的从输入声明到输出声明的映射。 根据规则定义中所定义的证明类型，输入声明可能来自不同的提供者。 输入声明可能来自 OIDC 身份提供商、id_token_hint 或在发行期间通过钱包中的用户输入发布的自我断言声明。
- 输入 - 是规则文件中供客户端使用的模型的子集。 子集必须描述该组输入，在何处获取输入，以及为获取可验证凭据要调用的终结点。
Microsoft Entra 验证 ID 服务
Microsoft Entra 验证 ID 服务使你能够根据配置来颁发和撤销 VC。 服务：
预配分散式标识符 (DID)。 每个颁发者有每个租户的相应的 DID。
向 Key Vault 预配密钥集。
存储供颁发服务和 Microsoft Authenticator 使用的配置元数据。
为颁发者和验证程序 Web 前端提供 REST API 接口
信任系统
Microsoft Entra 验证 ID 目前支持 Web 作为信任系统 DID Web，其中 DID 文档托管在证书颁发者 Web 服务器上。
Microsoft Authenticator 应用程序
Microsoft Authenticator 是移动应用程序。 Authenticator 可协调用户、Microsoft Entra 已验证 ID 服务和用于颁发 VC 的协定之间的交互。 它相当于一个数字钱包，VC 的持有者将 VC 存储在其中，包括 VC 使用者的私钥。 Authenticator 也是用于展示 VC 的验证机制。
颁发业务逻辑
你的颁发解决方案包含一个 Web 前端，用户在其中请求 VC、身份存储和或其他属性存储以获取有关使用者的声明的值，以及其他后端服务。
Web 前端通过生成深层链接或 QR 码向使用者的钱包提供颁发请求。 基于协定的配置，可能还需其他组件才能满足创建 VC 的要求。
这些服务提供的支持角色不一定需要与 Microsoft Entra 验证 ID 颁发服务集成。 此层通常包括：
与 Open ID Connect (OIDC) 兼容的服务用于获取颁发 VC 所需的 id_token。 现有标识系统（例如 Microsoft Entra ID 或 Azure AD B2C）可提供 OIDC 兼容服务，与标识服务器等自定义解决方案可提供一样。
属性存储 — 属性存储可能在目录服务之外，并提供颁发 VC 所需的属性。 例如，一个学生信息系统可能会提供与所获学历有关的声明。
额外中间层服务包含有关查找、验证、账单的业务规则以及颁发凭据所需的其他运行时检查和工作流等。
若要详细了解如何设置 Web 前端，请参阅配置 Microsoft Entra ID 以颁发可验证凭据教程。
凭据设计注意事项
凭据设计根据你的特定用例而定。 用例确定：
互操作性要求
用户需要进行身份证明以获取其 VC 的方式
凭据中所需的声明
是否需要撤销凭据
凭据用例
使用 Microsoft Entra 验证 ID 时，最常见的凭据用例包括：
身份验证：基于多个条件颁发凭据。 多个条件可能包括验证由政府颁发的文档（如护照或驾照）的真实性、将该文档中的信息与其他信息关联，例如：
用户的自拍
有效性验证
这种凭据适用于身份加入方案，包括新员工、合作伙伴、服务提供商、学生方案以及身份验证至关重要的其他方案。
聘用/成员证明：颁发凭据以证明用户与机构之间的关系。 这种凭据适用于访问关联度不大的企业对企业应用程序，例如向员工或学生提供折扣的零售商。 VC 的一个主要价值是可移植性：颁发后，用户可以在许多方案中使用 VC。
有关更多用例，请参阅可验证凭据用例 (w3.org)。
凭据互操作性
在设计过程中，研究特定于行业的架构、命名空间，以及可一致化的身份识别符，旨在实现可能的最大互操作性和使用率。 可在 Schema.org 和 DIF - 声明和凭据工作组中找到示例。
通用架构领域的标准尚处于萌芽阶段。 此类工作的一个示例是适用于教育任务组的可验证凭据。 我们鼓励你进行调研，为你组织所在行业中萌芽阶段的标准的完善作出贡献。
凭据类型和属性
建立凭据用例后，需要确定凭据类型和凭据中要包含的属性。 验证者可读取用户展示的 VC 中的声明。
所有的可验证凭据都必须在其规则定义中声明其类型。 凭据类型可将可验证凭据架构与其他凭据区分开，并确保颁发者与验证者之间的互操作性。 若要指示凭据类型，请提供该凭据所满足的一种或多种凭据类型。 每种类型都是唯一的字符串。 通常，URI 用于确保全局唯一性。 URI 不必可寻址。 将它视为字符串。 例如，康托索大学所颁发的文凭凭据可能会声明以下类型：
| 类型 | 用途 |
|---|---|
https://schema.org/EducationalCredential |
声明 Contoso 大学所颁发的文凭中包含由 schema.org EducationaCredential 对象定义的属性。 |
https://schemas.ed.gov/universityDiploma2020 |
声明 Contoso 大学所颁发的文凭中包含由美国教育部定义的属性。 |
https://schemas.contoso.edu/diploma2020 |
声明康托索大学所颁发的文凭中包含由康托索大学定义的属性。 |
除了你的方案可能适用的行业特定标准和架构外，还应考虑以下方面：
最小化专用信息量：使用最少量的必要专用信息来满足用例需求。 例如，对于一个为员工和校友提供折扣的电子商务网站，要满足该网站的 VC 要求，所需展示的凭据只需含有名字和姓氏声明。 不需含有招聘日期、职位、部门等其他信息。
优先使用抽象化声明：每个声明都应满足需求，同时尽量减少详细信息。 例如，对于名为“ageOver”的声明来说，离散值（如 13、21、60）比出生日期声明更加抽象。
规划可撤销性：建议定义一个索引声明，以支持凭据查找和撤销机制。 每个协定只能定义一个索引声明。 需要注意的是，索引声明的值不存储在后端，只存储声明值的哈希。 有关详细信息，请参阅撤销之前颁发的可验证凭据。
有关凭据属性的其他注意事项，请参阅可验证凭据数据模型 1.0 (w3.org) 规范。
规划质量属性
规划性能
与任何解决方案一样，你必须规划性能。 需要关注的重要因素是延迟和可伸缩性。 在发布周期的初始阶段，不应担心性能问题。 但是，当颁发解决方案的采用会导致颁发许多可验证凭据时，性能规划对于解决方案可能就很关键了。
下面提供了规划性能时需要考虑的方面：
部署了 Microsoft Entra 验证 ID 颁发服务的 Azure 区域有欧洲西部、欧洲北部、美国西部 2、美国中西部、澳大利亚和日本。 如果 Microsoft Entra 租户驻留在欧盟，则 Microsoft Entra 验证 ID 服务也位于欧盟。
若要限制延迟，请在前面所列区域部署颁发前端网站和密钥保管库。
基于吞吐量的模型：
VC 颁发服务遵循 Azure 密钥保管库服务限制。
对于 Azure 密钥保管库，每个 VC 颁发都涉及三个签名操作：
一个用于来自网站的颁发请求
一个用于创建的 VC
还有一个用于协定下载
无法控制限制；但建议阅读 Azure Key Vault 限制指南。
如果计划大规模推出和载入 VC，请考虑批量创建 VC，以确保不超过限制。
在规划性能时，需要确定要监视的内容，以便更好地了解解决方案的性能。 在定义 VC 颁发监视策略时，除了应用程序级网站监视之外，还应考虑以下事项：
对于可伸缩性，考虑实现以下各项的指标：
定义颁发过程的逻辑阶段。 例如：
初始请求
QR 码或深层链接的提供
属性查找
调用 Microsoft Entra 验证 ID 颁发服务
凭据颁发
基于阶段定义指标：
请求总数（容量）
每个时间单位的请求数（吞吐量）
所花时间（延迟）
使用以下链接监视 Azure 密钥保管库：
监视用于业务逻辑层的组件。
规划可靠性
若要规划可靠性，我们建议：
定义了可用性和冗余目标后，请使用以下指南了解如何实现目标：
对于前端和业务层，解决方案可以通过无限多种方式来展现。 与其他解决方案一样，对于标识的依赖项，请确保依赖项可复原并受到监视。
如果发生了 Microsoft Entra 验证 ID 颁发服务或 Azure 密钥保管库服务不可用这种很少发生的情况，整个解决方案都会变得不可用。
规划合规性
组织可能有与行业、交易类型或运营国家/地区相关的特定合规性需求。
数据驻留：Microsoft Entra 验证 ID 颁发服务会部署到 Azure 区域的子集。 该服务仅用于计算功能。 不会在 Microsoft 系统中存储可验证凭据的值。 但是，在颁发 VC 时，在颁发过程中会发送和使用个人数据。 使用 VC 服务不应影响数据驻留要求。 如果在身份验证过程中要存储任何个人信息，应采用符合合规性要求的方式和区域进行存储。 如需查看 Azure 相关指南，请访问 Microsoft 信任中心网站。
撤销凭据：确认组织是否会需要撤销凭据。 例如，当员工离开公司时，管理员可能需要撤销其凭据。 有关详细信息，请参阅撤销之前颁发的可验证凭据。
过期凭据：确定凭据的过期方式。 例如，如果颁发 VC 作为驾照证明，那么该 VC 可能会在几年后过期。 其他 VC 的有效期可以较短，以确保用户定期回来更新其 VC。
规划操作
规划操作时，开发一个用于故障排除、报告和区分所支持各种客户的架构是至关重要的。 此外，如果由运营团队负责执行 VC 吊销，则必须定义该流程。 流程的每个步骤都应具有关联性，以便可以确定可以将哪些日志项与每个唯一的颁发请求相关联。 对于审核，建议分别捕获每次凭据颁发尝试。 具体而言：
生成客户和支持工程师可根据其需要引用的唯一事务 ID。
设计一种机制，将 Azure 密钥保管库事务日志与解决方案颁发部分的事务 ID 相关联。
如果你是代表多个客户颁发 VC 的身份验证服务，请根据客户或合同 ID，针对面向客户的报告和计费，进行监视并缓解相关问题。
如果你是代表多个客户颁发 VC 的身份验证服务，请在面向客户的报告和计费、监视和缓解中使用客户或合同 ID。
规划安全
在考虑与设计相关的一些注意事项时（侧重于安全性），我们有以下几项建议：
对于密钥管理：
创建用于 VC 颁发的专用密钥保管库。 限制 Microsoft Entra 验证 ID 颁发服务和颁发服务前端网站服务主体的 Azure Key Vault 权限。
将 Azure 密钥保管库视为高特权系统 - Azure 密钥保管库为客户颁发凭据。 建议将 Azure 密钥保管库权限设置为最高，即任何人的权限都不得高于此权限。 管理员只能在指定时间访问密钥保管库。 有关使用 Azure 密钥保管库的最佳做法的详细信息，请参阅密钥保管库的 Azure 安全性基线。
对于代表颁发前端网站的服务主体：
定义一个专用服务主体以授权访问 Azure 密钥保管库。 如果网站位于 Azure 上，建议使用 Azure 托管标识。
将代表网站和用户的服务主体视为单个信任边界。 虽然可以创建多个网站，但颁发解决方案只有一个密钥集。
对于安全性记录和监视，我们有以下几项建议：
启用针对 Azure 密钥保管库的日志记录和警报，以跟踪凭据颁发操作、密钥提取尝试、权限更改，以及监视和发送配置更改警报。 有关详细信息，请参阅如何启用密钥保管库的日志记录。
在安全信息与事件管理 (SIEM) 系统中存档日志，例如在 Microsoft Sentinel 中长期保留日志。
通过执行以下操作来缓解欺骗风险
实施 DNS 验证，以帮助客户识别颁发者品牌。
对最终用户有意义的域名。
最终用户认可的受信任品牌。
减轻分布式拒绝服务 (distributed denial of service, DDOS) 和密钥保管库资源耗尽的风险。 触发 VC 颁发请求的每一个请求都会生成密钥保管库签名操作，操作量的累积会趋近服务限制。 建议在生成颁发请求之前，先通过包含身份验证或验证码来保护流量。
有关管理 Azure 环境的指南，建议查看 Microsoft 云安全基准以及使用 Microsoft Entra ID 保护 Azure 环境。 这些指南提供了管理基础 Azure 资源（包括 Azure 密钥保管库、Azure 存储、网站和其他 Azure 相关服务和功能）的最佳做法。
其他注意事项
完成 POC 后，收集生成的所有信息和文档，并考虑删除颁发者配置。
有关实现密钥保管库和操作的详细信息，请参阅使用密钥保管库的最佳做法。 若要详细了解如何使用 Active Directory 保护 Azure 环境，请参阅使用 Microsoft Entra ID 保护 Azure 环境。