你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
有关标识和访问管理的建议
适用于此 Azure Well-Architected Framework 安全清单建议：
| SE：05 | 在所有工作负载用户、团队成员和系统组件 (IAM) 实施严格、有条件且可审核的标识和访问管理。 根据需要将访问权限限制为 独占。 对所有身份验证和授权实现使用现代行业标准。 限制和严格审核不基于标识的访问。 |
|---|
本指南介绍对尝试访问工作负载资源的标识进行身份验证和授权的建议。
从技术控制的角度来看， 标识始终是主要外围。 此范围不仅包括工作负载的边缘。 它还包括工作负载内的各个组件。 典型标识包括：
人类。 应用程序用户、管理员、操作员、审核员和不良参与者。
系统。 工作负载标识、托管标识、API 密钥、服务主体和 Azure 资源。
匿名。 尚未提供任何证据证明其所属的实体。
定义
| 术语 | 定义 |
|---|---|
| 身份验证 (AuthN) | 一个过程，用于验证标识是谁或它所说的内容。 |
| 身份验证 (AuthZ) | 验证标识是否有权执行请求的操作的过程。 |
| 条件性访问 | 一组允许基于指定条件的操作的规则。 |
| IdP | 标识提供者，如Microsoft Entra ID。 |
| 角色 | 具有一组职责和操作的工作职能或职务。 |
| 预共享密钥 | 一种在提供者和使用者之间共享并通过安全且一致的机制使用的机密类型。 |
| 资源标识 | 为平台管理的云资源定义的标识。 |
| 角色 | 定义用户或组可以执行的操作的一组权限。 |
| 范围 | 允许角色操作的不同组织层次结构级别。 也是系统中的一组功能。 |
| 安全主体 | 提供权限的标识。 它可以是用户、组或服务主体。 任何组成员都获得相同级别的访问权限。 |
| 用户标识 | 人员（如员工或外部用户）的标识。 |
| 工作负载标识 | 应用程序、服务、脚本、容器或工作负荷的其他组件的系统标识，用于向其他服务和资源进行身份验证。 |
注意
可以将标识与其他类似的标识分组到名为 安全主体的父级下。 安全组是安全主体的一个示例。 这种分层关系简化了维护并提高一致性。 由于标识属性不是在个人级别处理的，因此也减少了出错的可能性。 在本文中，术语 “标识 ”包括安全主体。
标识提供者的角色
标识提供者 (IdP) 是一种云托管服务，它以数字标识的形式存储和管理用户。
利用受信任的 IdP 提供的功能 进行标识和访问管理。 不要实现自定义系统来替换 IdP。 IdP 系统通过每天跨多个租户捕获数十亿个信号，根据最新的攻击途径频繁改进。 Microsoft Entra ID 是 Azure 云平台的 IdP。
身份验证
身份验证是验证标识的过程。 请求标识需要提供某种形式的可验证标识。 例如：
用户名和密码。
预先共享的机密，例如授予访问权限的 API 密钥。
共享访问签名 (SAS) 令牌。
TLS 相互身份验证中使用的证书。
验证过程应尽可能由 IdP 处理。
授权
授权是一个允许或拒绝已验证标识请求的操作的过程。 该操作可能是操作性的，或与资源管理相关。
授权要求向标识分配权限，需要使用 IdP 提供的功能执行此操作。
关键设计策略
若要全面了解工作负载的标识需求，需要对流、工作负荷资产和角色以及资产和角色将执行的操作进行编目。 策略必须涵盖所有用例，这些用例处理 到达工作负载或其组件的流 (由外向内访问) ，以及从工作负载到其他源的流 (从内到外访问) 。
每个用例可能都有自己的一组控件，你需要用假设违规思维模式进行设计。 根据用例或角色的标识要求，确定条件性选项。 避免对所有用例使用一种解决方案。 相反，控件不应过于精细，导致不必要的管理开销。
需要记录标识访问线索。 这样做有助于验证控制措施，并且可以使用日志进行合规性审核。
确定要进行身份验证的所有标识
由外向内的访问。 标识设计必须对出于各种目的访问工作负载的所有用户进行身份验证。 例如，通过调用 API 访问应用程序的最终用户。
在粒度级别上，工作负载的组件可能还需要从外部进行访问。 例如，需要通过门户访问或访问计算以运行命令的操作员。
两者都是具有不同角色 的用户标识 示例。
由内向外的访问。 应用程序需要访问其他资源。 例如，从数据平台读取或写入数据平台、从机密存储中检索机密，以及将遥测记录到监视服务。 它甚至可能需要访问第三方服务。 这些访问需求需要 工作负载标识，这使应用程序能够针对其他资源对自身进行身份验证。
该概念适用于组件级别。 在以下示例中，容器可能需要访问部署管道才能获取其配置。 这些访问需求需要 资源标识。
所有这些标识都应由 IdP 进行身份验证。
下面是如何在体系结构中实现标识的示例：
确定授权操作
接下来，需要知道每个经过身份验证的标识尝试执行的操作，以便对这些操作进行授权。 操作可以按所需的访问类型进行划分：
数据平面访问。 数据平面中发生的操作会导致数据传输，以便进行由内向外或外向内访问。 例如，应用程序从数据库读取数据并将数据写入数据库、提取机密或将日志写入监视接收器。 在组件级别，将映像拉取或推送到注册表或从注册表推送映像的计算被视为数据平面操作。
控制平面访问。 控制平面中发生的操作会导致创建、修改或删除 Azure 资源。 例如，对资源属性的更改。
应用程序通常以数据平面操作为目标，而操作通常同时访问控制和数据平面。 若要确定授权需求，请记下可以对资源执行的操作。 有关每个资源允许的操作的信息，请参阅 Azure 资源提供程序操作。
提供基于角色的授权
根据每个标识的责任，授权应允许的操作。 不得允许标识执行超出其需要执行的操作。 在设置授权规则之前，需要清楚地了解发出请求的人员或内容、允许该角色执行哪些操作，以及它可以在多大程度上执行此操作。 这些因素导致将标识、角色和范围组合在一起的选择。
以工作负载标识为例。 应用程序必须具有对数据库的数据平面访问权限，因此必须允许对数据资源执行读取和写入操作。 但是，应用程序是否需要对机密存储进行控制平面访问？ 如果工作负荷标识被恶意参与者入侵，那么在保密性、完整性和可用性方面，会对系统产生什么影响？
角色分配
角色是分配给标识的一 组权限 。 分配仅允许标识完成任务的角色，而不再允许该角色。 当用户的权限仅限于其工作要求时，可以更轻松地识别系统中的可疑或未经授权的行为。
提出如下问题：
- 只读访问权限是否足够？
- 标识是否需要权限才能删除资源？
限制用户、应用程序或服务对 Azure 资源的访问级别可以减少潜在的攻击面。 如果仅授予执行特定任务所需的最低权限，则成功攻击或未经授权的访问的风险将显著降低。 例如，安全团队只需要对所有技术环境的安全属性进行只读访问。 该级别足以评估风险因素、识别潜在缓解措施并报告风险。
在某些情况下，由于组织结构和团队组织的原因，用户需要更多的访问权限。 各种角色之间可能存在重叠，或者单个用户可能会执行多个标准角色。 在这种情况下，请使用基于业务函数的多个角色分配，而不是为其中每个用户创建自定义角色。 这样做会使角色更易于管理。
避免专门引用个别资源或用户的权限。 细化和自定义权限会产生复杂性和混淆，因为它们不会将意图传递给类似的新资源。 这会创建难以维护的复杂旧配置，并且对安全性和可靠性都产生负面影响。
权衡：精细访问控制方法可以更好地审核和监视用户活动。
角色还具有 关联的范围。 该角色可以在允许的管理组、订阅、资源组、资源范围或其他自定义范围内运行。 即使标识具有有限的一组权限，扩大范围以包括标识的工作职能之外的资源也是有风险的。 例如，对所有源代码和数据进行读取访问可能很危险，必须进行控制。
使用基于角色的访问控制 (RBAC) 将角色分配给标识。 始终使用 IdP 提供的 RBAC 来利用使你能够一致地应用访问控制并严格撤销访问控制的功能。
使用内置角色。 它们旨在涵盖大多数用例。 自定义角色功能强大，有时也很有用，但对于内置角色不起作用的情况，应将其保留。 自定义会带来复杂性，从而增加混乱，并使自动化更复杂、更具挑战性、更脆弱。 这些因素均可对安全性产生负面影响。
授予从最低权限开始并添加更多基于操作或数据访问需求的角色。 技术团队必须有明确的指导才能实现权限。
如果要对 RBAC 进行精细控制，请根据上下文（例如操作和属性）在角色分配上添加条件。
做出条件访问选择
不要为所有标识提供相同级别的访问权限。 根据两个main因素做出决策：
时间。 标识可以访问环境的时间长度。
权限。 权限级别。
这些因素并非互斥。 具有更多特权和无限访问持续时间的已泄露标识可以更好地控制系统和数据，或者使用该访问权限继续更改环境。 将这些访问因素限制为预防措施和控制爆炸半径。
实时 (JIT) 方法仅在需要时提供所需的权限。
JEA) (Just Enough Access 仅提供所需的权限。
尽管时间和特权是主要因素，但还有其他条件适用。 例如，还可以使用访问来源的设备、网络和位置来设置策略。
使用强大的控制来筛选、检测和阻止未经授权的访问，包括用户标识和位置、设备运行状况、工作负载上下文、数据分类和异常等参数。
例如，你的工作负载可能需要由供应商、合作伙伴和客户等第三方标识访问。 他们需要适当的访问权限级别，而不是你向全职员工提供的默认权限。 明确区分外部帐户可以更轻松地防止和检测来自这些向量的攻击。
你选择的 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。 员工和企业资源。
Microsoft Entra 外部 ID。 合作 伙伴。
Azure AD B2C。 客户。
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) 群集中的应用程序服务使用工作负载标识向解决方案中的其他组件进行身份验证。
“托管标识”。 客户端角色中的系统组件使用系统托管标识，包括生成代理。
人类标识。 用户和操作员身份验证委托给本机、B2B 或 B2C) (Microsoft Entra ID 或 Microsoft Entra ID。
预共享机密的安全性对任何应用程序都至关重要。 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：配置筛选
安全清单
请参阅完整的建议集。
反馈
即将发布：在整个 2024 年，我们将逐步淘汰作为内容反馈机制的“GitHub 问题”，并将其取代为新的反馈系统。 有关详细信息，请参阅：https://aka.ms/ContentUserFeedback。
提交和查看相关反馈