本文介绍符合零信任原则的条件访问体系结构。 该体系结构使用基于角色的方法形成结构化的条件访问框架。
条件访问零信任体系结构
首先需要选择体系结构。 建议考虑“目标”或“零信任条件访问”体系结构。 此图显示了相应的设置：
零信任条件访问体系结构是最适合零信任原则的体系结构。 如果在条件访问策略中选择 所有云应用 选项，则所有终结点都受提供的授权控制（如已知用户和已知或合规设备）的保护。 但是，该策略不仅适用于支持条件访问的终结点和应用。 它适用于用户与之交互的任何终结点。
例如，设备登录流终结点用于各种新的 PowerShell 和 Microsoft Graph 工具。 设备登录流提供了一种允许从无法显示登录屏幕的设备（例如 IoT 设备）登录的方法。
基于设备的登录命令在给定设备上运行，并向用户显示代码。 此代码在另一台设备上使用。 用户转到 https://aka.ms/devicelogin 并指定其用户名和密码。 从其他设备登录后，该用户上下文中的 IoT 设备成功登录。
此登录面临的挑战是它不支持基于设备的条件访问。 这意味着，如果你为所有云应用应用了需要已知用户和已知设备的基线策略，则任何人都无法使用工具和命令。 对于基于设备的条件访问，还有其他应用程序存在相同的问题。
另一个体系结构（面向 体系结构）基于仅针对要在条件访问策略中保护的各个应用的原则构建。 在这种情况下，所有云应用以前涵盖的终结点的设备登录（例如对 Microsoft Entra ID 的图形调用）不受条件访问策略的保护，因此它们将继续工作。
使用设备登录作为区分这两种体系结构的示例时，可以使用设备登录进行身份验证。 如果每个应用程序是可面向的，因此可以在需要基于设备登录的条件访问策略中排除设备登录可能允许一个或多个单个应用程序。
面向 体系结构的挑战是，你可能忘记保护所有云应用。 即便如此，你也会选择条件访问策略中的所有可选应用程序。 你可以保留对无法选择不受保护的应用程序的访问权限。 示例包括访问 Office 门户、Azure EA（企业协议）门户和安全信息门户，这些门户都是非常敏感的门户。
另一个考虑因素是，随着Microsoft和合作伙伴发布新功能以及 IT 管理员将各种应用程序与 Microsoft Entra ID 集成，Office 365 和 Microsoft Entra 应用的数量会随着时间的推移而增加。 仅当具有一种机制来检测任何支持条件访问的新应用并自动对其应用策略时，才能保护对所有此类应用程序的访问。 创建和维护此类脚本可能很困难。
此外，任何一个条件访问策略支持的最大应用数约为 250。 在收到超过有效负载的错误之前，你可能可以添加多达 600 个应用，但该数字不受支持。
条件访问角色
有多种方法可用于构建条件访问策略。 一种方法是基于所访问资源的敏感度来构建策略。 实际上，此方法可能难以实现，这样仍可保护对各种用户资源的访问。
例如，可以定义条件访问策略，该策略需要已知用户和已知设备才能访问需要来宾和员工访问的敏感资源。 来宾尝试从托管设备访问时，访问请求将不起作用。 需要调整条件访问策略以满足这两个要求，这通常会导致满足不太安全要求的策略。
另一种方法是尝试根据用户所在的组织位置定义访问策略。 此方法可能会导致许多条件访问策略，并且可能不可管理。
更好的方法是为具有相同需求的一组用户构建与常见访问需求相关的策略，并将一组访问需求捆绑在角色中。 角色是共享常见企业属性、职责、体验、目标和访问权限的标识类型。
了解各种角色如何访问企业资产和资源是制定全面零信任战略不可或缺的一部分。
此处显示了来自Microsoft的一些建议的条件访问角色：
Microsoft还建议为不属于任何其他角色组的标识定义单独的角色。 这称为全局角色。 全局旨在针对不属于角色组的标识强制执行策略，以及应对所有角色强制执行的策略。
以下部分介绍一些建议的角色。
全局
全局是一般性质的策略的角色/占位符。 它用于定义适用于所有角色或不适用于一个特定角色的策略。 将其用于其他角色未涵盖的策略。 需要此角色来保护所有相关方案。
例如，假设你想要使用一个策略来阻止所有用户的旧身份验证。 你可以将其设为全局策略，而不是使用可能因各种角色而异的一组旧策略。
另一个示例：你想要阻止给定帐户或用户从特定应用程序，并且该用户或帐户不属于任何角色。 例如，如果在 Microsoft Entra 租户中创建云标识，则此标识不属于任何其他角色，因为它未分配任何Microsoft Entra 角色。 你仍可能希望阻止标识访问 Office 365 服务。
你可能想要阻止任何角色组未涵盖的标识的所有访问。 或者，你可能只想强制实施多重身份验证。
管理员
在此上下文中，管理员是具有任何Microsoft Entra ID 或其他 Microsoft 365 管理员角色（例如，在 Microsoft Defender for Cloud Apps、Exchange、Defender for Endpoint 或 Compliance Manager）的任何非来宾标识、云或同步。 由于具有这些角色的来宾包含在不同的角色中，因此来宾将被排除在此角色之外。
某些公司具有此角色所基于的敏感管理员角色的单独帐户。 以最佳方式，管理员从特权访问工作站使用这些敏感帐户（PAW）。 但是我们经常看到，管理员帐户在标准工作站上使用，用户只需在一台设备上的帐户之间切换。
你可能希望根据云管理员角色的敏感度进行区分，并将不太敏感的 Azure 角色分配给内部人员角色，而不是使用单独的帐户。 然后可以使用 Just-In-Time（JIT）提升。 在这种情况下，用户针对的是两组条件访问策略，每个角色都有一组条件访问策略。 如果使用 PAW，可能还需要引入在条件访问中使用设备筛选器来限制访问的策略，以便仅允许管理员访问 PAW。
开发人员
开发人员角色包含具有唯一需求的用户。 它们基于同步到 Microsoft Entra ID 的 Active Directory 帐户，但需要对 Azure DevOps、CI/CD 管道、设备代码流和 GitHub 等服务进行特殊访问。 开发人员角色可以包含被视为内部用户，而其他人被视为外部用户，但用户应仅属于其中一个角色。
内部
内部包含已同步到 Microsoft Entra ID 的 Active Directory 帐户、公司员工以及从事标准最终用户角色工作的所有用户。 建议将开发人员的内部用户添加到开发人员角色。
Externals
此角色包含所有已同步到 Microsoft Entra ID 的 Active Directory 帐户的外部顾问。 建议将开发人员的外部用户添加到开发人员角色。
来宾
来宾拥有已邀请到客户租户的 Microsoft Entra 来宾帐户的所有用户。
GuestAdmins
GuestAdmins 角色包含分配了上述任何管理员角色的 Microsoft Entra 来宾帐户的所有用户。
Microsoft365ServiceAccounts
此角色包含云（Microsoft Entra ID）基于用户的服务帐户，这些帐户用于访问 Microsoft 365 服务（如果没有其他解决方案满足需求），例如使用托管服务标识。
AzureServiceAccounts
此角色包含云（Microsoft Entra ID）基于用户的服务帐户，当没有其他解决方案满足需求（例如使用托管服务标识）时，用于访问 Azure（IaaS/PaaS）服务。
CorpServiceAccounts
此角色包含具有以下所有特征的基于用户的服务帐户：
- 源自本地 Active Directory。
- 用于本地或另一个（云）数据中心（例如 Azure）中基于 IaaS 的虚拟机。
- 同步到访问任何 Azure 或 Microsoft 365 服务的 Microsoft Entra 实例。
应避免这种情况。
WorkloadIdentities
此角色包含计算机标识，例如Microsoft Entra 服务主体和托管标识。 条件访问现在支持保护从这些帐户访问资源，但条件和授予控制措施在哪些方面存在一些限制。
访问模板卡
建议使用访问模板卡来定义每个角色的特征。 下面是一个示例：
每个角色的模板卡都提供用于为每个角色创建特定条件访问策略的输入。
条件访问指南
查看 条件访问框架，其中包含基于所创建角色的组策略的结构化方法。
贡献
本文由Microsoft维护。 它最初由以下参与者编写。
主体作者：
- 克劳斯·杰斯珀森 |首席顾问 ID&秒
若要查看非公共LinkedIn配置文件，请登录到LinkedIn。