本文介绍一个遵守零信任原则的条件访问体系结构。 该体系结构使用基于角色的方法来构成结构化条件访问框架。
条件访问零信任体系结构
首先需要选择体系结构。 建议考虑目标体系结构或零信任条件访问体系结构。 此图显示了相应的设置：
零信任条件访问体系结构是最适合零信任原则的体系结构。 如果在条件访问策略中选择了“所有云应用”选项，则所有终结点都受提供的授权控制（如已知用户和已知或合规设备）的保护。 但该策略不仅适用于支持条件访问的终结点和应用。 它适用于用户与之交互的任何终结点。
例如，在各种新版 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 还建议为不属于任何其他角色组的标识定义单独的角色。 这称为“Global”角色。 “Global”旨在强制实施不属于角色组的标识的策略，以及应该对所有角色强制实施的策略。
以下部分介绍了一些建议的角色。
全球
“全局”是一般性策略的角色/占位符。 它用于定义应用于所有角色或不应用于一个特定角色的策略。 请将其用于其他角色未涵盖的策略。 你需要使用此角色来保护所有相关方案。
例如，假设你要使用一个策略来阻止所有用户进行旧式身份验证。 可将此策略设为全局策略，而不是使用一组可能因角色不同而异的旧策略。
另举一例：你想要阻止给定的帐户或用户访问特定的应用程序，而该用户或帐户不属于任何角色。 例如，如果你在 Microsoft Entra 租户中创建一个云标识，则此标识将不属于任何其他角色，因为未为它分配任何 Microsoft Entra 角色。 你仍可能希望阻止该标识访问 Office 365 服务。
你可能希望阻止不属于任何角色组的标识进行任何访问。 或者，你可能只希望强制实施多重身份验证。
管理员
在此上下文中，管理员是具有任何 Microsoft Entra ID 或其他 Microsoft 365 管理员角色（例如，在 Microsoft Defender for Cloud Apps、Exchange、Defender for Endpoint 或 Compliance Manager 中）的任何非来宾标识、云或同步。 由于具有这些角色的来宾属于不同的角色，因此来宾将被排除在此角色之外。
某些公司为此角色所基于的敏感管理员角色创建了独立的帐户。 管理员最好是从特权访问工作站 (PAW) 使用这些敏感帐户。 但我们经常看到在标准工作站上使用管理员帐户，其中的用户只需在一台设备上的帐户之间切换。
你可能希望根据云管理员角色的敏感性进行区分，并将不太敏感的 Azure 角色分配到内部角色，而不是使用独立的帐户。 然后，可以改用即时 (JIT) 提升。 在这种情况下，用户将成为两组条件访问策略的目标，每个角色各有一组策略。 如果使用 PAW，则你还可能需要在条件访问中引入使用设备筛选器的策略来限制访问，以便仅允许管理员在 PAW 上操作。
开发人员
“开发人员”角色包含具有独特需求的用户。 它们基于同步到 Microsoft Entra ID 的 Active Directory 帐户，但需要对 Azure DevOps、CI/CD 管道、设备代码流和 GitHub 等服务进行特殊访问权限。 “开发人员”角色包括的用户可以是被视为内部的用户和被视为外部的其他人，但一个人应仅具有其中一个角色。
内部机制
“内部”包含已同步到 Microsoft Entra ID 的 Active Directory 帐户的所有用户，他们是公司的员工，并以标准最终用户角色工作。 建议将作为开发人员的内部用户添加到“开发人员”角色。
外部
此角色包含所有已同步到 Microsoft Entra ID 的 Active Directory 帐户的外部顾问。 建议将作为开发人员的外部用户添加到“开发人员”角色。
来宾
“来宾”角色包含拥有被邀请到客户租户的 Microsoft Entra ID 来宾帐户的所有用户。
GuestAdmins
“GuestAdmins”角色包含拥有分配了上述任何管理员角色的 Microsoft Entra ID 来宾帐户的所有用户。
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 维护， 它最初是由以下贡献者撰写的。
主要作者：
- Claus Jespersen | ID&Sec 首席顾问
若要查看非公开领英个人资料，请登录领英。