迁移到Microsoft Defender for Office 365 - 阶段 3：载入
阶段 1：准备 |
阶段 2：设置 |
阶段 3：开始使用 |
|---|---|---|
| 你在这里！ |
欢迎使用阶段 3：将迁移加入到 Microsoft Defender for Office 365！ 此迁移阶段包括以下步骤：
- 开始加入安全团队
- (可选) 免除试点用户按现有保护服务进行筛选
- 优化欺骗智能
- 优化模拟保护和邮箱智能
- 使用用户报告的消息中的数据来度量和调整
- (可选) 将更多用户添加到试点并循环访问
- 将 Microsoft 365 保护扩展到所有用户，并关闭 SCL=-1 邮件流规则
- 切换 MX 记录
步骤 1：开始加入安全团队
如果组织有安全响应团队，现在可以开始将Microsoft Defender for Office 365集成到响应流程中，包括票证系统。 此过程本身是一个完整的主题，但有时被忽视。 尽早让安全响应团队参与进来，可确保在切换 MX 记录时，组织已准备好应对威胁。 需要做好事件响应准备才能处理以下任务：
- 了解新工具并将其集成到现有流中。 例如：
- 隔离邮件管理员管理非常重要。 有关说明，请参阅 以管理员身份管理隔离的邮件和文件。
- 通过邮件跟踪，可以查看邮件在进入或离开Microsoft 365 时发生的情况。 有关详细信息，请参阅 Exchange Online 中的新式 Exchange 管理中心中的邮件跟踪。
- 识别可能已进入组织的风险。
- 优化和自定义组织流程的 警报 。
- 管理事件队列并修正潜在风险。
如果你的组织购买了Microsoft Defender for Office 365计划 2，他们应开始熟悉和使用威胁资源管理器、高级搜寻和事件等功能。 有关相关训练，请参阅 https://aka.ms/mdoninja。
如果安全响应团队收集和分析未筛选的邮件，则可以将 SecOps 邮箱配置为接收这些未筛选的邮件。 有关说明，请参阅 在高级传递策略中配置 SecOps 邮箱。
SIEM/SOAR
有关与 SIEM/SOAR 集成的详细信息，请参阅以下文章：
如果组织没有安全响应团队或现有流程流，可以使用此时间熟悉Defender for Office 365中的基本搜寻和响应功能。 有关详细信息，请参阅 威胁调查和响应。
RBAC 角色
Defender for Office 365中的权限基于基于角色的访问控制 (RBAC) ，并在 Microsoft Defender 门户中的权限中进行了说明。 以下是需要记住的要点：
- Microsoft Entra角色向 Microsoft 365 中的所有工作负载授予权限。 例如，如果将用户添加到Azure 门户中的安全管理员，则他们在任何地方都有安全管理员权限。
- Email & Microsoft Defender门户中的协作角色向Microsoft Defender门户和Microsoft Purview 合规门户授予权限。 例如，如果在Microsoft Defender门户中将用户添加到安全管理员，则他们只能在Microsoft Defender门户和Microsoft Purview 合规门户中拥有安全管理员访问权限。
- Microsoft Defender门户中的许多功能都基于 Exchange Online PowerShell cmdlet，因此需要相应角色中的角色组成员身份 (技术上讲，角色组尤其) Exchange Online (，以便访问相应的Exchange OnlinePowerShell cmdlet) 。
- Microsoft Defender门户中Email &协作角色与Microsoft Entra角色不等效，并且对于安全操作 (例如预览角色和搜索和清除角色) 非常重要。
通常，只有一部分安全人员需要其他权限来直接从用户邮箱下载邮件。 这需要安全读取器默认没有的其他权限。
步骤 2： (可选) 免除试点用户按现有保护服务进行筛选
虽然不需要此步骤，但应考虑将试点用户配置为绕过现有保护服务的筛选。 此操作允许Defender for Office 365处理试点用户的所有筛选和保护职责。 如果不从现有保护服务中免除试点用户，Defender for Office 365仅对其他服务 (筛选已) 筛选的消息的未命中有效操作。
注意
如果当前保护服务提供链接包装，但你想要试用安全链接功能，则明确需要执行此步骤。 不支持链接的双重包装。
步骤 3：优化欺骗智能
检查 Spoof 智能见解 ，了解允许或阻止哪些内容是欺骗，并确定是否需要重写系统判断进行欺骗。 某些业务关键型电子邮件源可能在 DNS (SPF、DKIM 和 DMARC) 中配置错误的电子邮件身份验证记录，并且你可能在现有保护服务中使用替代来掩盖其域问题。
欺骗智能可以从 DNS 中没有适当的电子邮件身份验证记录的域中拯救电子邮件，但该功能有时需要帮助来区分良好的欺骗和恶意欺骗。 重点介绍以下类型的消息源：
- 超出 连接器增强筛选中定义的 IP 地址范围的消息源。
- 消息数最多的消息源。
- 对组织影响最大的邮件源。
在配置用户报告设置后，欺骗智能最终会自行调整，因此不需要完美无缺。
步骤 4：优化模拟保护和邮箱智能
在“ 不应用任何操作 模式”中有足够的时间观察模拟保护的结果后，可以在防钓鱼策略中单独打开每个模拟保护操作：
- 用户模拟保护：隔离Standard和 Strict 的消息。
- 域模拟保护：隔离Standard和 Strict 的消息。
- 邮箱智能保护：将邮件移动到收件人的“垃圾邮件”Email文件夹中，以便Standard;将邮件隔离为“严格”。
在不对消息执行操作的情况下监视模拟保护结果的时间越长，需要识别的允许或块的数据就越多。 考虑在启用每个保护之间使用延迟，该保护足够重要，足以允许观察和调整。
注意
频繁和持续地监视和优化这些保护非常重要。 如果怀疑误报，请调查原因，并仅在必要时使用替代，并且仅针对需要它的检测功能使用替代。
优化邮箱智能
尽管邮箱智能配置为对 确定为模拟尝试的邮件不执行任何操作，但它已打开并了解试点用户的电子邮件发送和接收模式。 如果外部用户与试点用户联系，则邮箱智能不会将来自该外部用户的邮件标识为模拟尝试， (从而减少误报) 。
准备就绪后，执行以下步骤，允许邮箱智能对检测到模拟尝试的邮件进行操作：
在具有Standard保护设置的防钓鱼策略中，更改“如果邮箱智能检测到模拟用户”的值，将邮件移动到收件人的垃圾邮件Email文件夹。
在具有“严格保护”设置的防钓鱼策略中，将 “如果邮箱智能检测到并模拟用户” 的值从 更改为 “隔离邮件”。
若要修改策略，请参阅在 Defender for Office 365 中配置反钓鱼策略。
观察结果并进行任何调整后，请转到下一部分以隔离用户模拟检测到的邮件。
优化用户模拟保护
在基于“Standard”和“严格”设置的反钓鱼策略中，将“如果邮件被检测为用户模拟”的值更改为“隔离邮件”。
检查 模拟见解 ，查看用户模拟尝试阻止的内容。
若要修改策略，请参阅在 Defender for Office 365 中配置反钓鱼策略。
观察结果并进行任何调整后，请转到下一部分，以隔离域模拟检测到的邮件。
优化域模拟保护
在基于Standard和严格设置的反钓鱼策略中，将“如果邮件被检测为域模拟”的值更改为“隔离邮件”。
检查 模拟见解 ，查看域模拟尝试阻止的内容。
若要修改策略，请参阅在 Defender for Office 365 中配置反钓鱼策略。
观察结果并根据需要进行任何调整。
步骤 5：使用用户报告的消息中的数据来度量和调整
当试点用户报告误报和误报时，消息将显示在Microsoft Defender门户“提交”页的“用户报告”选项卡上。 可以将错误识别的消息报告给Microsoft进行分析，并根据需要使用信息来调整试点策略中的设置和异常。
使用以下功能监视和循环访问 Defender for Office 365 中的保护设置：
如果组织对用户报告的消息使用第三方服务，则可以将这些数据集成到反馈循环中。
步骤 6： (可选) 将更多用户添加到试点并循环访问
发现并修复问题后，可以 (将更多用户添加到试点组，并相应地免除这些新试点用户，使其不受现有保护服务) 的扫描。 现在执行的测试越多，以后需要处理的用户问题就越少。 这种“瀑布”方法允许针对组织较大部分进行优化，并让你的安全团队有时间适应新的工具和流程。
Microsoft 365 会在组织策略允许高置信度钓鱼邮件时生成警报。 若要识别这些消息，可以使用以下选项：
- 威胁防护状态报告中的替代。
- 在威胁资源管理器中筛选以识别消息。
- 在“高级搜寻”中筛选以识别消息。
检查不必要的替代也是一个好主意。 换句话说，看看Microsoft 365 对消息提供的判决。 如果 Microsoft 365 做出了正确的判决，则大大减少或消除替代需求。
步骤 7：将 Microsoft 365 保护扩展到所有用户，并关闭 SCL=-1 邮件流规则
准备好将 MX 记录切换为指向 Microsoft 365 时，执行本部分中的步骤。
将试点策略扩展到整个组织。 从根本上讲，可通过不同的方法来扩展策略：
使用预设的安全策略，在Standard保护配置文件和严格保护配置文件之间划分用户 (确保) 涵盖所有人。 预设的安全策略在创建的任何自定义策略或任何默认策略之前应用。 可以关闭单个试点策略，而无需删除它们。
预设安全策略的缺点是，创建许多重要设置后无法更改这些策略。
更改在试点期间创建和调整的策略的范围，以包括所有用户 (例如，所有域中的所有收件人) 。 请记住，如果同一类型的多个策略 (例如，反钓鱼策略) 单独应用于同一用户 (组成员身份或电子邮件域) ，则仅应用优先级最高 (最低) 的策略设置，并停止处理该类型的策略。
关闭 SCL=-1 邮件流规则， (无需删除) 即可将其关闭。
验证以前的更改是否已生效，并且现在是否为所有用户正确启用了Defender for Office 365。 此时，现在允许Defender for Office 365的所有保护功能为所有收件人处理邮件，但现有保护服务已扫描该邮件。
可以在此阶段暂停，以便进行更大规模的数据记录和优化。
步骤 8：切换 MX 记录
注意
- 切换域的 MX 记录时，更改最多可能需要 48 小时才能在整个 Internet 中传播。
- 建议降低 DNS 记录的 TTL 值，以实现更快的响应和可能的回滚 (（如果需要) ）。 切换完成并验证后，可以还原到原始 TTL 值。
- 应考虑从更改使用频率较低的域开始。 在移动到更大的域之前，可以暂停和监视。 但是，即使这样做，仍应确保策略涵盖所有用户和域，因为辅助 SMTP 域在策略应用程序之前已解析为主域。
- 从技术上讲，单个域的多个 MX 记录将起作用，允许你进行拆分路由，前提是你已遵循本文中的所有指南。 具体而言，应确保策略应用于所有用户，SCL=-1 邮件流规则仅应用于通过现有保护服务的邮件，如 设置步骤 3：维护或创建 SCL=-1 邮件流规则中所述。 但是，此配置引入了使故障排除更加困难的行为，因此我们通常不建议这样做，尤其是在较长时间内。
- 在切换 MX 记录之前，请验证是否未在从保护服务到 Microsoft 365 的入站连接器上启用以下设置。 通常，连接器将配置以下一个或多个设置：
- 并要求合作伙伴用于向Office 365进行身份验证的证书上的使用者名称与此域名 (RestrictDomainsToCertificate)
- 如果电子邮件未从此 IP 地址范围 (RestrictDomainsToIPAddresses) 则拒绝电子邮件，如果连接器类型为 “合作伙伴 ”并且已打开其中任一设置，则切换 MX 记录后，所有发送到域的邮件传递都将失败。 在继续操作之前，需要禁用这些设置。 如果连接器是用于混合的本地连接器，则无需修改本地连接器。 但是，你仍然可以检查是否存在合作伙伴连接器。
- 如果当前邮件网关还提供收件人验证，则可能需要检查域在 Microsoft 365 中配置为权威。 这可以防止不必要的退回邮件。
准备就绪后，切换域的 MX 记录。 可以一次性迁移所有域。 或者，可以先迁移不太常用的域，然后再迁移其余域。
随时可以在此处暂停和评估。 但请记住：关闭 SCL=-1 邮件流规则后，用户可能会有两种不同的检查误报体验。 越早提供单一、一致的体验，用户和技术支持团队在必须排查缺少的消息时，他们就会越满意。
后续步骤
恭喜！ 你已完成迁移到 Microsoft Defender for Office 365！ 由于你遵循了此迁移指南中的步骤，因此邮件直接传递到 Microsoft 365 的前几天应该会更加顺利。
现在开始Defender for Office 365的正常操作和维护。 监视和watch与你在试点期间遇到的类似但规模更大的问题。 欺骗智能见解和模拟见解最有用，但请考虑使以下活动经常发生：