你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
标识和访问管理的建议
适用于此 Azure 架构良好的框架安全清单建议：
| SE：05 | 在所有工作负荷用户、团队成员和系统组件中实施严格的、有条件和可审核的标识和访问管理（IAM）。 根据需要将访问权限限制为 独占访问。 对所有身份验证和授权实现使用现代行业标准。 限制和严格审核不基于标识的访问。 |
|---|
本指南介绍了对尝试访问工作负荷资源的标识进行身份验证和授权的建议。
从技术控制的角度来看， 标识始终是主要外围。 此范围不仅包括工作负荷的边缘。 它还包括工作负荷中的单个组件。 典型标识包括：
人类。 应用程序用户、管理员、操作员、审核员和不良参与者。
系统。 工作负荷标识、托管标识、API 密钥、服务主体和 Azure 资源。
匿名。 没有提供任何证据的实体。
定义
| 条款 | 定义 |
|---|---|
| 身份验证 (AuthN) | 验证标识是谁或它所说的过程。 |
| 身份验证 (AuthZ) | 验证标识是否有权执行请求的操作的过程。 |
| 条件性访问 | 一组规则，允许基于指定条件执行的操作。 |
| IdP | 标识提供者，例如Microsoft Entra ID。 |
| Persona | 具有一组职责和操作的职务或职务。 |
| 预共享密钥 | 提供程序和使用者之间共享的机密类型，通过安全且已同意的机制使用。 |
| 资源标识 | 为平台管理的云资源定义的标识。 |
| 角色 | 定义用户或组可以执行的操作的一组权限。 |
| 范围 | 允许角色运行的不同级别的组织层次结构。 也是系统中的一组功能。 |
| 安全主体 | 提供权限的标识。 它可以是用户、组或服务主体。 任何组成员都获得相同的访问权限级别。 |
| 用户标识 | 人员的标识，例如员工或外部用户。 |
| 工作负载标识 | 用于向其他服务和资源进行身份验证的应用程序、服务、脚本、容器或其他工作负荷组件的系统标识。 |
注意
可以在名为 安全主体的父级下将标识与其他类似标识分组。 安全组是安全主体的示例。 这种分层关系简化了维护和提高一致性。 由于标识属性在单个级别未处理，因此也会减少错误几率。 在本文中，术语 标识 包含安全主体。
标识提供者的角色
标识提供者（IdP）是一种云托管服务，用于将用户存储和管理为数字标识。
利用受信任的 IdP 为标识和访问管理提供的功能。 不要实现自定义系统来替换 IdP。 通过每天跨多个租户捕获数十亿个信号，IdP 系统经常根据最新的攻击途径进行改进。 Microsoft Entra ID 是 Azure 云平台的 IdP。
身份验证
身份验证是验证标识的过程。 请求标识需要提供某种形式的可验证标识。 例如：
用户名和密码。
预共享机密，例如授予访问权限的 API 密钥。
共享访问签名 (SAS) 令牌。
TLS 相互身份验证中使用的证书。
尽可能多地由 IdP 处理验证过程。
授权
授权是允许或拒绝已验证标识请求的操作的过程。 该操作可能是操作性的，或与资源管理相关。
授权要求你向标识分配权限，需要使用 IdP 提供的功能来执行此操作。
关键设计策略
若要全面了解工作负荷的标识需求，需要对流、工作负荷资产和角色进行目录，以及资产和角色将执行的操作。 策略必须涵盖处理 到达工作负荷或其组件（外部访问）的流的所有用例，以及从工作负荷到其他源（内部访问）的流。
每个用例可能都有自己的一组控件，你需要用假设违规思维模式进行设计。 根据用例或角色的标识要求，确定条件选择。 避免对所有用例使用一个解决方案。 相反，控件不应如此精细，因此会产生不必要的管理开销。
需要记录标识访问线索。 这样做有助于验证控件，并且可以使用日志进行合规性审核。
确定身份验证的所有标识
由外向内的访问。 标识设计必须针对各种目的对访问工作负荷的所有用户进行身份验证。 例如，通过调用 API 访问应用程序的最终用户。
在精细级别，工作负荷的组件可能还需要从外部进行访问。 例如，需要通过门户访问或访问计算以运行命令的操作员。
两者都是具有不同角色的用户标识的示例。
由内向外的访问。 应用程序需要访问其他资源。 例如，从数据平台读取或写入数据平台、从机密存储检索机密，并将遥测数据记录到监视服务。 它甚至可能需要访问第三方服务。 这些访问需要 工作负荷标识，使应用程序能够针对其他资源自行进行身份验证。
概念适用于组件级别。 在以下示例中，容器可能需要访问部署管道才能获取其配置。 这些访问需要 资源标识。
所有这些标识都应由 IdP 进行身份验证。
下面是如何在体系结构中实现标识的示例：
确定授权操作
接下来，需要了解每个经过身份验证的标识尝试执行的操作，以便可以对这些操作进行授权。 操作可以除以所需的访问类型：
数据平面访问。 在数据平面中发生的操作会导致数据传入或外部访问进行数据传输。 例如，从数据库读取数据并将数据写入数据库、提取机密或将日志写入监视接收器的应用程序。 在组件级别，从注册表拉取或推送映像的计算被视为数据平面操作。
控制平面访问。 在控制平面中发生的操作会导致创建、修改或删除 Azure 资源。 例如，对资源属性的更改。
应用程序通常以数据平面操作为目标，而操作通常同时访问控制和数据平面。 若要确定授权需求，请注意可在资源上执行的操作。 有关每个资源的允许操作的信息，请参阅 Azure 资源提供程序操作。
提供基于角色的授权
根据每个标识的责任，授权应允许的操作。 不得允许标识执行超过它需要执行的操作。 在设置授权规则之前，需要清楚地了解发出请求的人员或内容、允许该角色执行哪些操作，以及该角色可以执行的操作程度。 这些因素导致组合标识、角色和范围的选择。
以工作负荷标识为例。 应用程序必须具有对数据库的数据平面访问权限，因此必须允许对数据资源的读取和写入操作。 但是，应用程序是否需要对机密存储进行控制平面访问？ 如果工作负荷标识被不良参与者入侵，那么在保密性、完整性和可用性方面，对系统的影响会是什么？
角色分配
角色是分配给标识的一 组权限 。 分配仅允许标识完成任务的角色，并且不再分配。 当用户的权限仅限于其作业要求时，更容易识别系统中的可疑或未经授权的行为。
提出如下问题：
- 只读访问权限是否足够？
- 标识是否需要权限才能删除资源？
限制用户、应用程序或服务对 Azure 资源的访问权限级别可减少潜在的攻击面。 如果仅授予执行特定任务所需的最低权限，则成功攻击或未经授权的访问的风险会显著减少。 例如，安全团队只需要对所有技术环境的安全属性进行只读访问。 该级别足以评估风险因素、识别潜在缓解措施并报告风险。
在某些情况下，由于组织结构和团队组织，用户需要更多的访问权限。 不同角色之间可能存在重叠，或者单个用户可能执行多个标准角色。 在这种情况下，请使用基于业务功能的多个角色分配，而不是为每个用户创建自定义角色。 这样做会使角色更易于管理。
避免专门引用个别资源或用户的权限。 精细和自定义权限会产生复杂性和混淆，因为它们不会将意图传递给类似新资源。 这可以创建复杂的旧配置，难以维护和对安全性和可靠性产生负面影响。
权衡：精细访问控制方法可更好地审核和监视用户活动。
角色还具有 关联的范围。 该角色可以在允许的管理组、订阅、资源组或资源范围或其他自定义范围内运行。 即使标识具有有限的一组权限，扩大范围以包括标识的作业功能之外的资源是有风险的。 例如，对所有源代码和数据进行读取访问可能很危险，必须控制。
使用基于角色的访问控制（RBAC）将角色分配给标识。 始终使用 IdP 提供的 RBAC 来利用使你能够一致地应用访问控制的功能，并严格撤销它。
使用内置角色。 它们旨在涵盖大多数用例。 自定义角色功能强大，有时很有用，但对于内置角色不起作用的方案，应保留这些角色。 自定义会带来复杂性，从而增加混乱，并使自动化更复杂、更具挑战性、更脆弱。 这些因素均可对安全性产生负面影响。
授予从最低权限开始的角色，并根据操作或数据访问需求添加更多角色。 技术团队必须有明确的指导才能实现权限。
如果要对 RBAC 进行精细控制，请基于上下文（如操作和属性）在角色分配上添加条件。
做出条件访问选择
不要为所有标识提供相同的访问权限级别。 根据两个主要因素做出决策：
时间。 标识可以访问环境的时间。
特权。 权限级别。
这些因素不是相互排斥的。 具有更多特权和无限访问权限的已泄露标识可以更好地控制系统和数据，或使用该访问权限来继续更改环境。 将这些访问因素限制为预防措施和控制爆炸半径。
恰时 （JIT） 方法仅在需要时提供所需的权限。
Just Enough Access （JEA） 仅提供所需的权限。
虽然时间和特权是主要因素，但还有其他适用条件。 例如，还可以使用从中发起访问来设置策略的设备、网络和位置。
使用强控制来筛选、检测和阻止未经授权的访问，包括用户标识和位置、设备运行状况、工作负荷上下文、数据分类和异常等参数。
例如，可能需要通过供应商、合作伙伴和客户等第三方标识访问工作负荷。 他们需要适当的访问权限级别，而不是向全职员工提供的默认权限。 通过明确区分外部帐户，可以更轻松地防止和检测来自这些途径的攻击。
你选择的 IdP 必须能够提供这种差异，提供内置功能，以基于最低特权授予权限，并提供内置的威胁情报。 这包括监视访问请求和登录。Azure IdP Microsoft Entra ID。 有关详细信息，请参阅本文的 Azure 便利化部分 。
保护关键影响帐户
管理标识引入了一些影响最大的安全风险，因为它们执行的任务需要对这些系统和应用程序进行特权访问。 泄露或滥用可能会对业务及其信息系统产生不利影响。 管理安全性是最重要的安全领域之一。
为保护特权访问免受顽固攻击者的攻击，必须采取一种完整且周密的方法，将这些系统与风险隔离。 下面是一些策略：
尽量减少关键影响帐户的数量。
使用单独的角色 ，而不是提升现有标识的权限。
使用 IdP 的 JIT 功能避免永久或永久访问 。 对于打破玻璃的情况，请遵循紧急访问过程。
使用新式访问协议 ，例如无密码身份验证或多重身份验证。 将这些机制外部化到 IdP。
使用 条件访问策略强制实施密钥安全属性。
停用未使用的管理帐户 。
跨环境使用单个标识，并将单个标识与用户或主体相关联。 跨云和本地环境的标识一致性可减少人为错误和由此产生的安全风险。 管理资源的两个环境中的团队都需要一致的权威源才能满足安全保证。 请与中心标识团队协作，确保混合环境中的标识已同步。
风险：存在与同步高特权标识相关的风险。 攻击者可以完全控制本地资产，这可能会导致云帐户成功泄露。 通过筛选可添加到攻击面的帐户来评估同步策略。
建立用于管理标识生命周期的过程
对标识的访问不得超过标识访问的资源。 确保在团队结构或软件组件发生更改时禁用或删除标识的过程。
本指南适用于源代码管理、数据、控制平面、工作负荷用户、基础结构、工具、数据、日志、指标和其他实体的监视。
建立标识治理过程 ，以管理数字标识、高特权用户、外部/来宾用户和工作负荷用户的生命周期。 实施访问评审，以确保标识离开组织或团队时，将删除其工作负荷权限。
保护基于非实体的机密
应用程序机密（如预共享密钥）应被视为系统中的易受攻击点。 在双向通信中，如果提供商或使用者遭到入侵，可能会带来重大安全风险。 这些密钥也可能很繁重，因为它们引入了操作流程。
如果可以，请避免使用机密 ，并考虑使用基于标识的身份验证来访问应用程序本身，而不仅仅是对应用程序的资源进行访问。
以下列表提供了指南摘要。 有关详细信息，请参阅 有关应用程序机密的建议。
将这些机密视为可从机密存储中动态拉取的实体。 它们不应在应用程序代码、IaC 脚本、部署管道或任何其他项目中进行硬编码。
请确保你能够 撤销机密。
应用处理密钥轮换和过期等任务的操作做法。
有关轮换策略的信息，请参阅自动轮换具有两组身份验证凭据的资源的机密和教程：更新密钥库中的证书自动轮换频率。
保护开发环境安全
所有代码和脚本、管道工具和源代码管理系统都应被视为工作负荷资产。 应通过自动化和对等评审来限制 对写入的访问。 对源代码的读取访问权限应仅限于 需要了解的角色。 代码存储库必须具有版本控制， 对等方的安全代码评审 必须是与开发生命周期集成的常规做法。 你需要准备好一个定期扫描资源并识别最新漏洞的过程。
使用工作负荷标识授予对部署环境（例如 GitHub）资源的访问权限。
维护审核线索
标识管理的一个方面是确保系统可审核。 审核将验证假设泄露策略是否有效。 维护审核线索可帮助你：
验证是否使用强身份验证对标识进行身份验证。 任何操作都必须可 跟踪，以防止否认性攻击。
检测弱身份验证协议或缺少身份验证协议 ，并深入了解用户和应用程序登录的见解。
根据安全性和 符合性要求 评估从标识到工作负荷的访问，并考虑你设置的用户帐户风险、设备状态和其他条件和策略。
跟踪进度或偏离 合规性要求。
大多数资源都具有数据平面访问权限。 你需要知道访问资源的标识及其执行的操作。 可以使用该信息进行安全诊断。
有关详细信息，请参阅 有关安全监视和威胁分析的建议。
Azure 便利化
建议始终使用考虑所有可用数据点并使用条件访问的新式身份验证协议。 Microsoft Entra ID 在 Azure 中提供标识和访问管理。 它涵盖 Azure 的管理平面，并与大多数 Azure 服务的数据平面集成。 Microsoft Entra ID 是与工作负荷订阅关联的租户。 它跟踪和管理标识及其允许的权限，并简化了整体管理，以最大程度地降低监督或人为错误的风险。
这些功能本机集成到用户段的相同Microsoft Entra 标识和权限模型：
Microsoft Entra ID。 员工和企业资源。
Azure AD B2C。 Customers.
Microsoft Entra 联合兼容性列表。 第三方联合解决方案。
可以使用 Microsoft Entra ID 通过Microsoft身份验证库（MSAL）或平台功能（例如 Web 应用的身份验证）对自定义应用程序进行身份验证和授权。 它涵盖 Azure 的管理平面、大多数 Azure 服务的数据平面以及应用程序的集成功能。
可以通过访问 Microsoft Entra ID 中的新增功能来保持最新状态。
Azure 支持打开的协议，如 OAuth2 和 OpenID Connect。 建议使用这些标准身份验证和授权机制，而不是设计自己的流。
Azure RBAC
Azure RBAC 表示Microsoft Entra ID 中的安全主体。 所有角色分配都通过 Azure RBAC 完成。 利用提供所需大部分权限的内置角色。 有关详细信息，请参阅 Microsoft Entra 内置角色。
下面是一些用例：
通过将用户分配到角色，可以控制对 Azure 资源的访问。 有关详细信息，请参阅 Microsoft Entra ID 中基于角色的访问控制概述。
可以使用 Privileged Identity Management 为与高影响标识关联的角色提供基于时间的和基于审批的角色激活。 有关详细信息，请参阅 什么是 Privileged Identity Management？。
有关 RBAC 的详细信息，请参阅 Azure RBAC 的最佳做法。
有关基于属性的控件的信息，请参阅 什么是 Azure ABAC？。
工作负载标识
Microsoft Entra ID 可以处理应用程序的标识。 与应用程序关联的服务主体可以决定其访问范围。
有关详细信息，请参阅什么是工作负荷标识？
使用托管标识时，服务主体也会抽象化。 优点是 Azure 管理应用程序的所有凭据。
并非所有服务都支持托管标识。 如果无法使用托管标识，可以使用服务主体。 但是，使用服务主体会增加管理开销。 有关详细信息，请参阅什么是 Azure 资源的托管标识？
资源标识
托管标识的概念 可以扩展到 Azure 资源。 Azure 资源可以使用托管标识向支持 Microsoft Entra 身份验证的其他服务进行身份验证。 有关详细信息，请参阅 可以使用托管标识访问其他服务的 Azure 服务。
条件性访问策略
条件访问描述用于做出访问决策的策略 。 若要使用条件访问，需要了解用例所需的限制。 通过根据操作需求设置访问策略来配置Microsoft Entra 条件访问。
有关详细信息，请参阅 条件访问：用户、组和工作负荷标识。
组访问管理
请勿向特定用户授予权限，而是将访问权限分配给 Microsoft Entra ID 中的组。 如果组不存在，请与标识团队协作创建一个组。 然后，可以在 Azure 外部添加和删除组成员，并确保权限是最新的。 还可以将组用于其他目的，例如邮件列表。
有关详细信息，请参阅 使用Microsoft Entra ID 中的组进行安全访问控制。
威胁检测
Microsoft Entra ID 保护可以帮助你检测、调查和修正基于标识的风险。 有关详细信息，请参阅 什么是标识保护？。
威胁检测可以采取响应可疑活动的警报或主动搜索活动日志中的异常事件的形式。 Microsoft Sentinel 中的用户和实体行为分析（UEBA）可以轻松检测可疑活动。 有关详细信息，请参阅 使用 UEBA 识别高级威胁。
混合系统
在 Azure 上， 不要将帐户同步到在现有 Active Directory 中具有高特权的 Microsoft Entra ID。 此同步在默认Microsoft Entra Connect Sync 配置中被阻止，因此只需确认尚未自定义此配置。
有关在 Microsoft Entra ID 中进行筛选的信息，请参阅 Microsoft Entra Connect Sync：配置筛选。
标识日志记录
在 Azure 资源 上启用诊断设置以发出可以用作审核线索的信息。 诊断信息显示哪些标识尝试访问哪些资源和这些尝试的结果。 收集的日志将发送到 Azure Monitor。
示例
以下示例演示标识实现。 不同类型的标识一起使用以提供所需的访问级别。
标识组件
系统托管标识。 Microsoft Entra ID 提供对不面向用户的服务数据平面（例如 Azure 密钥库 和数据存储）的访问权限。 这些标识还通过 RBAC 控制工作负荷组件、部署代理和团队成员的 Azure 管理平面的访问。
工作负载标识。 Azure Kubernetes 服务 （AKS） 群集中的应用程序服务使用工作负荷标识向解决方案中的其他组件进行身份验证。
“托管标识”。 客户端角色中的系统组件使用系统托管标识，包括生成代理。
人类标识。 用户和操作员身份验证委托给 Microsoft Entra ID 或 Microsoft Entra ID（本机、B2B 或 B2C）。
预共享机密的安全性对于任何应用程序都至关重要。 Azure 密钥库为这些机密（包括 Redis 和第三方机密）提供安全存储机制。
轮换机制用于帮助确保机密不会泄露。 OAuth 2 和 OpenID Connect Microsoft 标识平台实现的令牌用于对用户进行身份验证。
Azure Policy 用于确保标识组件（如密钥库）使用 RBAC 而不是访问策略。 JIT 和 JEA 为人工操作员提供传统的站立权限。
通过Azure 诊断或通过代码组件的代码跨所有组件启用访问日志。
相关链接
- 教程：自动轮换具有两组身份验证凭据的资源的机密
- 教程：更新密钥库中的证书自动轮换频率
- Microsoft Entra ID 有哪些新功能？
- Microsoft Entra 内置角色
- Microsoft Entra ID 中基于角色的访问控制概述
- 什么是工作负荷标识？
- 什么是 Azure 资源的托管标识？
- 条件访问：用户、组和工作负荷标识
- Microsoft Entra Connect Sync：配置筛选
安全清单
请参阅完整的建议集。