条件访问和 PIM 如何真正阻止攻击？

密码策略阻止猜测攻击。但对于被盗的会话令牌、钓鱼式 MFA 提示或一个已经拥有全局管理员权限两年之久的常驻管理员账户，它们无能为力。条件访问和特权身份管理（PIM）是 Azure AD / Entra ID 中真正解决这些漏洞的两个控制项，它们结合使用效果最好。

条件访问在幕后的工作原理

条件访问是一个在登录时评估的 if-this-then-that 引擎。"如果"端（信号）包括用户/组成员身份、设备合规状态、网络位置、登录风险（来自身份保护）、访问的应用程序和客户端应用类型（浏览器 vs. 旧版协议）。"那么"端（控制）包括：要求 MFA、要求兼容设备、要求已批准的客户端应用、完全阻止访问或要求接受使用条款。

一项在几乎每个租户中都重要的策略是：阻止旧版身份验证。POP、IMAP 和较旧的 SMTP 等协议不支持现代 MFA 挑战，因此是凭证填充工具首先尝试的。在阻止前，检查按"客户端应用 = 其他客户端"筛选的登录日志——你通常会发现某个旧版扫描器或老式多功能打印机仍在使用基本身份验证。

第二项值得从第一天就拥有的策略是：对所有用户要求 MFA，仅用排除组来处理破玻璃账户。不要仅将 MFA 范围限定为"管理员"。被破坏的标准用户账户是攻击者在特权提升开始前获得首个立足点的方式。

登录风险与用户风险——不同的信号，不同的响应

身份保护（Entra ID P2 的一部分）生成两个不同的风险评分，容易混淆：

• 登录风险 ——这个特定的身份验证尝试看起来异常（不可能的旅行、匿名 IP、不熟悉的登录属性）。
• 用户风险 ——该账户因与身份本身相关的原因被标记（泄露的凭证在违规语料库中被发现、已确认的破坏活动）。

响应登录风险的条件访问策略通常应该用 MFA 挑战——如果真实用户能完成挑战，就允许通过。响应用户风险的策略应该强制重置密码，因为如果凭证本身已经泄露，MFA 单独无法帮助。

为什么常驻管理员访问权限是更大的问题

即使条件访问滴水不漏，一个永久持有全局管理员的账户也是目录中明显可见的目标。任何破坏它的人都会继承完整的租户控制权，无需任何额外步骤。PIM 移除了"永久"这部分。

使用 PIM，管理员角色被分配为合格而非活跃。用户必须显式激活角色，这会触发必需的理由、可选的批准工作流、MFA 重新确认和一个时间限制的窗口——通常为 1 到 8 小时——之后角色自动停用。没有人，包括账户所有者，除非正在积极使用，否则不拥有常驻全局管理员。

实际可用的最小 PIM 配置

• 高于帮助台管理员的每个角色：合格，非永久。
• 全局管理员和特权角色管理员：需要来自另一个管理员的批准，而不仅仅是自我激活。
• 激活 MFA 必需，无例外。
• 最大激活时长 4 小时强制人们对真正独立的工作会话重新激活，这也产生更清晰的审计日志。
• 每 90 天对所有合格分配进行访问评审——账户因一个项目添加，否则永远不会移除。

团队在这方面做错的地方

最常见的失败不是策略设计，而是排除列表。一个具有不断增长的"排除这些用户，因为应用不支持 MFA"组的条件访问策略最终会排除一半的租户。将排除作为积压项目跟踪，带有所有者和移除日期，而不是永久的存储桶。

第二个失败是从未实际测试过的破玻璃账户。两个应急账户，从条件访问和 PIM 中排除，使用长随机密码离线存储和任何登录警报——有人应该每季度尝试登录到它们以确认它们仍然有效。

条件访问和 PIM 不是合规审计的复选框。它们是钓鱼凭证成为不便和成为完整租户妥协之间的区别。如果你作为蓝队建设的一部分映射身份控制，Korra Studio 的云和蓝队部分涵盖检测方面——身份保护风险事件在 Sentinel 中的实际外观以及如何对不可能的 PIM 激活模式进行警报。