条件访问基础策略：最先要建的 6 条

简短回答： 小型租户先建六条条件访问策略：管理员 MFA、全体用户 MFA、阻止旧式身份验证、保护安全信息注册、Azure 管理 MFA、访客 MFA。六条都要排除应急访问账号，除注册策略外，都先用仅报告（Report-only）模式创建，看完结果再逐条改为 On；注册策略无法在仅报告模式下测试，要改用试点组验证。下文按 CA001 至 CA006 编号，上线顺序不同，写在“先用仅报告模式测试”一节末尾。需要 Microsoft Entra ID P1，微软表示 Microsoft 365 Business Premium 的客户同样可以使用。

本文写给小型或中型 Microsoft 365 租户的管理员：已经有授权，但还没建立条件访问基线。每条策略都会给出适用对象、条件、授予控制和排除账号，然后是用仅报告模式安全上线的步骤。步骤已于 2026 年 10 月 28 日对照 Microsoft Learn 核对。

动手之前

建两个应急访问账号。 微软建议：仅云端账号、使用 onmicrosoft.com 域名、永久分配 Global Administrator 角色，登录方式用通行密钥（passkey，FIDO2）。把两个账号放进名为 EmergencyAccess 的组。
决定安全默认值怎么处理。 安全默认值与条件访问互相替代。依靠这些策略之前，先关闭安全默认值（Entra ID > Overview > Properties > Manage security defaults > Disabled）。
检查有没有微软管理的策略。 在 Entra ID > Conditional Access > Policies 里，Created by 一栏写着 Microsoft 的行，是微软以仅报告状态创建的。如果你不处理，微软会在引入后不少于 30 天启用它们。没有理由就不要再建一份同样规则的副本。微软管理的策略（例如“Multifactor authentication for all users”和“Block legacy authentication”）可能已经涵盖 CA003 和 CA001，请直接编辑它们的状态和排除项，不要重复创建。
定一个命名规范， 例如 CA001 到 CA006，加一句简短描述。
确认角色。 创建策略至少需要 Conditional Access Administrator。授权：Microsoft Entra ID P1 或 Microsoft 365 Business Premium；基于风险的策略需要 Entra ID P2。

下面所有操作都在 Microsoft Entra 管理中心（entra.microsoft.com）的 Entra ID > Conditional Access > Policies > New policy 下进行。你也可以从 Entra ID > Conditional Access > Create new policy from templates 开始。微软的模板默认以仅报告模式创建，而且针对用户的模板只会排除创建者本人，所以创建之后要打开策略，加入你的应急访问组。

六条策略

每条策略都按同样顺序：用户、目标资源、条件、授予控制、排除。

CA001：阻止旧式身份验证

用户： All users。
目标资源： All resources (formerly 'All cloud apps')。
条件： Client apps > Configure = Yes，只勾选 Exchange ActiveSync clients 和 Other clients。
授予： Block access。
排除： EmergencyAccess 组。必须继续使用旧式协议的账号，作为临时例外加入，并写明截止日期。
启用前： 先找出谁在用。进入 Entra ID > Monitoring & health > Sign-in logs，加上 Client App 列，按旧式协议筛选。交互式登录和 User sign-ins (non-interactive) 两个页签都要看。

CA002：管理员要求 MFA

用户： Include > Directory roles。微软的清单是 Global Administrator、Application Administrator、Authentication Administrator、Billing Administrator、Cloud Application Administrator、Conditional Access Administrator、Exchange Administrator、Helpdesk Administrator、Password Administrator、Privileged Authentication Administrator、Privileged Role Administrator、Security Administrator、SharePoint Administrator 和 User Administrator。
目标资源： All resources。
条件： 无。
授予： Grant access > Require multifactor authentication。微软建议管理员准备好之后，考虑通过身份验证强度（authentication strength）要求防钓鱼的 MFA。
排除： EmergencyAccess 组。
注意： 这条策略只涵盖内置角色，不对管理单元范围的角色和自定义角色强制执行。

CA003：全体用户要求 MFA

用户： All users。
目标资源： All resources (formerly 'All cloud apps')，不排除任何应用。微软建议把它作为基线。
条件： 无。如果要加可信网络例外（Network > Include Any network or location > Exclude All trusted networks and locations），请记录在案，因为它会削弱策略。
授予： Grant access > Require authentication strength > Multifactor authentication。
排除： EmergencyAccess 组；如果使用 Entra Connect 或 Cloud Sync，还要排除目录角色 Directory Synchronization Accounts；只有在用 CA006 单独覆盖访客时，才排除访客。

CA004：保护安全信息注册

用户： All users。排除 All guest and external users（Temporary Access Pass 对访客不适用）和 EmergencyAccess 组。
目标资源： User actions > Register security information。
条件： Locations > Configure = Yes，包括 Any location，排除 All trusted locations。
授予： Grant access > Require authentication strength，选择内置或自定义的强度。
排除： 同上。
注意： 需要启用合并注册（combined registration）。给新入职员工签发 Temporary Access Pass，让他们能满足注册时的 MFA 要求。微软页面说明，自 2026 年 7 月 6 日起，针对 Register security information 的策略，在用户注册 Windows Hello for Business 或 macOS Platform SSO 凭据时也会生效。

CA005：Azure 管理要求 MFA

用户： All users。
目标资源： Select resources > Windows Azure Service Management API。涵盖 Azure 门户、Microsoft Entra 管理中心、Azure PowerShell 和 Azure CLI。
条件： 无。
授予： Grant access > Require multifactor authentication。
排除： EmergencyAccess 组。
注意： 微软自己也对 Azure 登录强制 MFA，并且说明这包括应急账号。仍然建议保留这条策略，让你自己的规则可见、可测试。

CA006：访客和外部用户要求 MFA

用户： Include > Select users and groups > Guest or external users，并选择你使用的访客类型。
目标资源： All resources，或访客需要的应用。
条件： 无。
授予： Grant access > Require authentication strength > Multifactor authentication。先检查跨租户访问设置里的入站 MFA 信任。
排除： EmergencyAccess 组。
注意： 微软说明，身份验证强度目前只适用于通过 Microsoft Entra ID 验证的访客。对于电子邮件一次性密码、SAML/WS-Fed、Google 联合和个人 Microsoft 账号的访客，请使用 Require multifactor authentication 授予控制。

先用仅报告模式测试

创建每条策略时，把 Enable policy 设为 Report-only，再选择 Create。
至少收集一个完整工作周的登录，让月末或每周的任务也出现。CA001 等得越久越好。“一周”只是作者的建议，不是微软给出的数字。
打开策略，看 Policy impact（需要 Security Reader 或更高角色），它显示 24 小时、7 天或 1 个月内对交互式登录的影响。
打开 Entra ID > Monitoring & health > Sign-in logs，选一条登录，在 Report-only 页签查看每条策略的结果：Success、Failure 或 User action required。
如果有 Entra ID P1，并有接收登录日志的 Log Analytics 工作区，可以用 Conditional Access Insights and Reporting 工作簿一次比较大量登录。
补上缺口：加排除、把扫描仪改用现代身份验证、让落后的人注册 MFA 方法。
把 Enable policy 从 Report-only 改为 On，一次一条，每条之间隔一两天。如果策略改为 On 后登录出现问题，用应急访问账号登录，把该策略改回 Report-only 或 Off。

微软的仅报告页面说明，User actions 范围内的项目无法在仅报告模式下评估。CA004 就属于这一类，所以要先指派给试点组、再逐步扩大，而不是依赖仅报告结果。

大多数小型租户适用的上线顺序：CA002（管理员）、CA005、CA001（完成旧式身份验证排查后）、CA003、CA006，最后是 CA004。

常见错误

没有应急访问账号，或者没有排除。 一条有问题的策略可能把所有人锁在外面，包括你自己。每季度测试这些账号。
排除过多。 对“IT 团队”或“董事”的排除会变成漏洞。排除只留给应急账号和确实无法避免的服务账号。
用模板却不改排除。 模板只排除创建策略的那个人。
没看仅报告的结果就启用。 登录日志会显示本来会被阻止的是谁。
忘了服务账号和同步账号。 Entra Connect 或 Cloud Sync 账号需要排除 Directory Synchronization Accounts。把用于脚本的用户账号换成托管标识或工作负载标识。
遗留经典策略。 经典条件访问策略已于 2024 年 7 月 10 日停止执行。请重建为现代策略（Entra ID > Conditional Access > Classic policies），再停用旧的。

如何确认生效

在登录日志里打开一条最近登录的 Conditional Access 页签，确认每条策略的结果是 Success 或 Not applied，与预期一致。
在 Conditional Access 里用 What If 工具，选测试用户、应用和客户端类型，看会套用哪些策略。
用测试用户在隐私窗口登录，确认出现 MFA 提示。
用测试邮箱尝试旧式协议连接，确认被阻止。
用应急账号登录，确认仍然可用，并记录日期。
查看 Conditional Access 的 Overview 和 Coverage 页签，了解哪些应用还没有策略覆盖。

租户里已经有一批条件访问策略，怎样审计它们？

上面六条策略是给“还什么都没有”的租户准备的。我们接触到的大多数租户并不是这种情况：两三年前有人建过一批策略，后来为某个项目又加了几条，之后再没有人完整读过这个列表。审计一个已有的策略集合，和从零搭建是两件事。你要问的不是“应该有哪些策略”，而是“现有的策略是否仍然在做负责人以为它在做的事”。在 Microsoft Entra 管理中心的 Entra ID > Conditional Access > Policies 里逐条打开，另开一个标签页放登录日志（Entra ID > Monitoring & health > Sign-in logs，按 Conditional Access 筛选），按下面的清单逐条核对。记下策略名、状态和发现，这些记录就是报告的底稿。

审计现有条件访问策略时要检查的十件事

仍停在仅报告模式的策略。 看 State 一列。一条在仅报告模式下放了几个月的策略什么都没有强制，而建它的人往往已经忘了。合格的样子：每条策略要么是 On 并有理由，要么是 Off 并有理由；没有任何一条在测试期过后还停在 Report-only。
越来越大的排除组。 打开每条策略的 Users > Exclude，再打开这些组本身。2024 年只有两个成员的 EmergencyAccess 组，今天可能已经有九个人。合格的样子：排除项只限两个应急访问账号和有记录的服务账号，每一项都有负责人和复查日期。
与办公室实际地址不再一致的命名位置。 在 Entra ID > Conditional Access > Named locations 里，把受信任的 IP 段和各办公室现在实际使用的地址逐一对比。前一家运营商留下的网段，或者已经关闭的办公室的网段，对今天拿到那个地址的任何人来说都是受信任位置。合格的样子：每个网段都对应一个现有办公室或 VPN 出口，列表上有最后核对日期。
没有阻止旧式身份验证。 确认存在一条相当于 CA001 的策略且为 On，然后在登录日志里按 Client app 筛选 Exchange ActiveSync 和 Other clients，看是否还有东西能通过。合格的样子：阻止策略为 On，最近 30 天的旧式协议登录为零或都能解释。
没有登录频率或持久浏览器会话控制。 检查面向用户的策略里的 Session 控制。没有这些控制，共用或非托管机器上的令牌可以长时间有效。合格的样子：对非托管设备设定了登录频率，在设备不合规或非混合加入时禁用持久浏览器会话。
面向 All users 却没有排除应急访问账号的策略。 任何作用于 All users 而没有排除 EmergencyAccess 组的策略，都是等着一次错误改动就把所有人锁在外面。合格的样子：每条 All users 策略恰好排除这个组，并且应急账号按计划定期测试。
引用已淘汰设备型号的设备筛选规则。 打开 Conditions > Filter for devices 读一遍规则。围绕公司已不再使用的设备型号、操作系统版本或命名前缀写的筛选条件，会悄悄地什么都匹配不上，通常意味着它本该施加的控制已经不再生效。合格的样子：筛选条件用仍在维护的属性表达，例如合规状态或信任类型。
重复的微软管理策略。 Created by 一栏写着 Microsoft 的行，可能和 CA001 或 CA003 重复。两条规则相同、排除项不同的策略，结果没有人能预测。合格的样子：一条规则只有一条策略，微软管理的那份要么被采纳并编辑，要么被有意关闭。
把服务账号排除在外的管理员 MFA 策略。 打开相当于 CA002 的策略读排除项。持有管理员角色却没有 MFA 的服务账号，是从一个泄露的密码走到整个租户被接管最常见的路径。合格的样子：没有任何持有特权角色的人员或服务账号被排除；自动化改用托管标识或工作负载标识运行。
没有覆盖访客的策略。 检查是否有任何策略以 Guest or external users 为目标。两个项目之前的合作方访客，今天仍在 Teams 和 SharePoint 里占着位置。合格的样子：相当于 CA006 的策略为 On，跨租户访问设置有人复查，过期访客按计划清理。

每一条发现，只有在别人日后也能核对时才有用。把策略集合导出为 JSON（每条策略的 Download JSON 操作，或者 Graph API），保存一份带日期的登录日志样本，显示某个有代表性的用户的条件访问结果，并记录是谁在什么时候复查了排除组。这三样东西连同复查日期一起保存，就是在保险公司、审计方或客户问“访问是如何控制的”时可以用作证据的材料；单独一张策略列表截图不是。

这份清单是我们一次性 Microsoft 365 安全审计身份部分的主要内容：审计会逐条检查租户里每条策略、每个排除组和每个命名位置，并对照 CIS Microsoft 365 Benchmark 记录结果。配套文章MFA 缺口报告讲的是身份这一侧的另一半：哪些用户真正注册了 MFA，用的是什么方法。

FAQ

什么是条件访问（Conditional Access）？

它是 Microsoft Entra 的一项功能，按“如果……就……”的方式做访问决定：如果用户要访问 Microsoft 365 之类的资源，就必须满足某个要求，例如 MFA。微软在第一重验证完成之后才执行策略。

什么是 Microsoft Entra？

Microsoft Entra 是微软身份与访问类产品的品牌。Microsoft Entra ID（原 Azure Active Directory）是保存你 Microsoft 365 用户的目录。条件访问在 Microsoft Entra 管理中心的 Entra ID > Conditional Access 下配置。