联系用户
确认用户是否发起了身份验证尝试，并确定他们是否批准了任何意外提示。
← 返回工程笔记本MFA 疲劳：
安全运营
MFA 疲劳：
遏制与应对
重复的 MFA 提示用户未启动应被视为潜在的身份安全事件，而不仅仅是令人烦恼的身份验证问题。
身份MFA事件响应Microsoft Entra ID身份验证
场景
用户说：
“我没有那样做。”
用户报告收到重复的 MFA 提示，即使他们没有主动登录。直接的诱惑可能是对身份验证器应用程序进行故障排除或假设提示是意外的。
但是意外的 MFA 请求可能表明有人正在尝试使用用户的身份进行身份验证，并且已到达登录过程的 MFA 阶段。
此时，该问题应被视为潜在的身份安全事件，而不是常规身份验证支持。
第一反应
前 15 分钟
早期目标是确定该活动是否合法，减少继续访问的机会，并保留足够的证据以了解发生的情况。
控制账户
如果提示不是由用户发起的，则将该活动视为可疑活动并开始遏制，然后再继续正常故障排除。
查看身份验证活动
检查最近的登录、身份验证尝试、位置、设备、应用程序、故障和其他可用的身份信号。
使现有访问无效
当怀疑受到威胁时，撤销活动会话并要求新的身份验证，以便现有访问不能简单地继续。
调查
证据应该回答的问题
目标是重建身份正在做什么，而不是仅依赖用户对提示的记忆。
01
MFA请求是用户发起的吗？
02
用户是否批准了任何意外的身份验证提示？
03
是否有从陌生设备或地点成功登录的情况？
04
重复的失败是否来自同一来源？
05
最近注册了新的身份验证方法吗？
06
该帐户是否访问了平时不使用的应用程序？
07
其他用户是否表现出类似的身份验证行为？
08
是否有证据表明凭据可能已在其他地方暴露？
响应生命周期
收容。调查。恢复。提升。
收容
在花费太多时间调查整个故事之前，停止潜在的未经授权的访问。
调查
审查身份活动并确定该事件是否代表失败的滥用、成功的妥协或合法行为。
恢复
仅在凭证、会话、MFA 方法和账户状态经过审核后恢复正常访问。
改善
利用该事件来确定可以降低未来风险的策略、培训、监控或访问控制更改。
操作环境
安全仍需支持用户
在操作环境中，帐户可能与电子邮件、财产系统、协作工具、文件访问以及用户执行工作所需的其他服务绑定。
这并不意味着收容应该被推迟。这意味着响应应包括沟通、所有权、恢复计划以及对可能受到影响的业务流程的了解。
目标不仅仅是锁定帐户。它是为了降低风险、了解发生的情况并安全地将用户恢复到正常操作。
教训
这个场景强化了什么
01
重复的 MFA 提示不应自动被视为常规用户支持问题。
02
重复出现意外的 MFA 提示可能表明攻击者已达到身份验证的第二阶段，但需要登录证据来确定实际发生的情况。
03
当身份泄露可能时，遏制和调查应该同时进行。
04
用户确认很重要，但身份日志提供了技术证据。
05
解决的事件应该留下文件和更强大的控制环境。