了解电子邮件安全部署

电子邮件仍然是个人与组织之间进行关键任务沟通的重要渠道。这也使电子邮件成为攻击者利用的理想途径——用于接管账户、窃取数据以及访问内部系统。减少垃圾邮件、抵御网络钓鱼和恶意软件攻击对组织安全至关重要。超过 90% 的网络安全事件始于电子邮件攻击。

Cloudflare 电子邮件安全是一项市场领先的解决方案，可通过多种部署方式满足各组织的不同需求。本文档概述了 Email Security 的不同部署方法，以及选择特定模式的原因。

无论业务规模大小，电子邮件仍然是所有企业的重要通信渠道。然而，电子邮件也是网络攻击（包括网络钓鱼、垃圾邮件和恶意软件）的主要目标。为了保护您组织的敏感数据和声誉，强大的电子邮件安全解决方案必不可少。

Cloudflare 电子邮件安全提供全面的工具和技术套件，旨在保护您的电子邮件基础架构免受各种威胁。通过实施 Cloudflare 电子邮件安全，您可以显著增强组织的安全状况，并减轻与通过电子邮件传播的攻击相关的风险。

此参考架构提供了有关如何部署和配置 Cloudflare 电子邮件安全以优化您的电子邮件安全状况的详细概述。此参考架构将深入探讨关键组件和最佳实践，以确保将此解决方案无缝集成到您现有的 IT 基础架构中。

本参考架构面向希望使用 Cloudflare 保护业务各方面安全的 IT 或安全专业人员，适用于以下受众：

• IT 安全专业人员：负责设计、实施和管理电子邮件安全解决方案的安全工程师、架构师和管理员。
• 网络工程师：管理网络基础设施和电子邮件网关的网络工程师。
• 云架构师：设计和实施基于云的电子邮件安全解决方案的云架构师。
• 安全和 IT 决策者：需要了解电子邮件安全的技术方面并做出明智决策的经理和高管。

无论您是经验丰富的安全专家还是电子邮件安全领域的新手，本文档都将为您提供有效部署和管理 Cloudflare 电子邮件安全所需的信息。

为了更好地了解 Cloudflare 的基准知识，我们推荐以下资源：

• 什么是 Cloudflare？ | 网站 ↗（5 分钟阅读）或 视频 ↗（2 分钟）
• Cloudflare 博客 ↗ | 电子邮件安全 ↗和网络钓鱼 ↗
• CISA | 网络钓鱼指导：在第一阶段停止攻击循环 ↗

在本参考架构结束时，您将了解 Cloudflare 如何保护您的电子邮件以及在选择部署方式时应考虑哪些因素。您将了解 Cloudflare 电子邮件安全解决方案中涉及的特定组件、技术和配置。这包括它如何与现有的电子邮件基础架构集成并利用基于云的服务。

Cloudflare 电子邮件安全是解决网络钓鱼攻击的现代方法。Cloudflare 解决方案建立在利用弹性服务的 AI 和机器学习的基础之上，此外还受益于 Cloudflare 广泛的威胁情报网络。Cloudflare 电子邮件安全被设计为唯一真正的云弹性服务，具有共享情报和监督学习 ↗，能够支持可用于电子邮件的任何部署方法。但是，选择正确的部署模型对于最大化电子邮件安全的优势至关重要。

本文档将讨论以下部署方法以及在哪里使用它们：

• Inline 或 MX
• Microsoft 365 API 集成
• 使用自动移动日记（Journaling）或 BCC
• 混合部署

在选择部署选项之前，重要的是考虑您的需求和期望的体验。当我们是主要钓鱼防护时，最佳实践通常是采用 MX 部署。关键原因如下：

• 传递前的补救措施允许我们通过附加到主题/正文、对 Cloudflare 远程浏览器隔离应用 URL 重写，以及将消息发送到垃圾邮件文件夹或下游电子邮件隔离来微调消息的传递方式。这使您可以在设计时考虑到特定的用户体验。
• 我们可以在邮件被 ServiceNow 或归档解决方案等消费电子邮件的系统处理之前将其移除。
• 我们消除了停留时间风险——即邮件送达收件箱与从收件箱移出之间的时间差。
• 我们支持混合部署，例如 Microsoft 365 与 Microsoft Exchange 的组合，或 Microsoft 365 与 Google Workspace 的组合。

如果这些需求不重要，或者您使用的分层安全系统不包括另一个基于 API 的解决方案，那么我们的 API 方法可以快速有效地部署，而无需更改您的邮件流。如果您想要 API 的优势而没有 API 限流的风险，那么 Journal/BCC 是最佳选择，因为摄取方法不使用 API 调用。但是，如果您想要 MX 部署的保护以及 API 内部消息传递的优势，那么我们的混合部署是理想的选择。

如果您的需求发生变化，请知道您可以灵活地根据需要更改部署方法，而无需重新购买我们的解决方案。唯一的警告是 Advantage 和 CyberSafe 客户仅限于 Inline 部署，而 Enterprise 许可受益于所有功能。

在确定具体部署方式之前，Cloudflare 建议您审阅所有选项、评估您的需求，并在必要时咨询您的客户团队。

通过 Inline 部署，发往一个或多个域的所有电子邮件在送达用户收件箱之前都会先经过 Cloudflare 过滤。Cloudflare 可以部署在电子邮件处理链中的任意位置。作为第一个跳数部署时，您需要更新域的 DNS MX 记录以指向 Cloudflare。如果您希望 Cloudflare 在现有 SEG（Secure Email Gateway，安全电子邮件网关）之后检查邮件，也可以将其插入处理链作为其中一跳，并将处理后的邮件转发到下游下一跳。根据策略，若邮件被标记为垃圾邮件、恶意邮件、批量邮件等，将被阻止和/或隔离。

上图描述了以下内容：

1. 电子邮件基于 MX 记录 ↗到达 Cloudflare。
2. Cloudflare 检查电子邮件正文、标头和附件，并分配适当的处置方式：
   • 恶意
   • 垃圾邮件
   • 批量
   • 可疑
   • 欺骗
   • 清洁
3. 应用任何策略，例如允许或阻止某些域。
4. 隔离高风险电子邮件
5. 所有由 Cloudflare 分配了处置方式的消息都将添加标头 X-CFEmailSecurity-Disposition。下游系统可以使用此标头来执行任何特殊处理（重新路由、外部隔离等）。
6. 转发所有有效的电子邮件流量。
7. 可以对消息应用主题和/或正文修改，以向最终用户添加有关处置方式的可见信息。

从安全的角度来看，Inline 部署是首选的部署方法，因为它会扫描每封电子邮件并阻止恶意内容到达用户收件箱。这消除了用户的所有暴露风险。

• 在发送到用户邮箱之前，系统会对邮件进行处理和拦截。
• Inline 部署允许您修改消息，添加主题或正文标记，例如将 [SPAM] 或 [EXTERNAL SPAM] 附加到主题。
• 提供高可用性和自适应邮件池：即使下游服务不可用，Cloudflare 也会继续将传入电子邮件排队接收；当下游服务恢复后，队列中的邮件将恢复投递。
• 未被隔离但已分配处置方式的邮件会收到 X-header，可用于下游高级处理。
• 与所有邮件系统兼容，包括 Microsoft Exchange On-Prem、Postfix、Lotus Notes、Google Workspace、Microsoft 365 等。

在通过 Inline 部署部署电子邮件安全之前，您需要考虑以下事项：

1. 将邮件先流入 Microsoft Exchange 或 Microsoft 365，再通过邮件流规则发送到 Email Security 解决方案进行扫描/修复，然后再回到 Microsoft 365 的重定向部署不受 Microsoft 支持。虽然 Cloudflare 在技术上可以支持这种模式，但会导致发件人归因和投递问题。
2. 如果 Cloudflare 将成为 MX，则需要更改 DNS。如果有许多域，则需要更新每个 DNS 区域。
3. 如果未将 Cloudflare 部署为 MX，例如传统 SEG（Mimecast/ProofPoint）背后的 Inline，Inline 部署可能会增加 SMTP 架构的复杂性。
4. Inline 部署可能需要在多个解决方案和 MTA 上重复策略。例如，Cloudflare、SEG 和 MTA 处理允许策略的方式显著不同，同一封邮件可能都需要例外处理。
5. 在分层部署中，某些供应商（例如 Mimecast 和 Barracuda）只能作为 MX 运行。在这种情况下，您可以在这些供应商之后配置 Cloudflare Inline。
6. 使用 Mimecast 时，建议禁用 URL 重写，因为这会使 Cloudflare 无法解码和抓取 URL。如果保持启用此功能，我们的链接跟踪功能将限于域信誉和寿命。

Cisco 提供了一种独特的功能，可以使用连接器将其作为 MX 或通过可支持的发夹部署在 Cloudflare 之后与 Cloudflare 集成。在所有其他考虑因素中，此部署的功能与 Inline 相同。请参阅 Cisco as MX Record 和 Cisco - Email security as MX Record。

另一种方法是通过 Microsoft 365 Graph API 集成。在此模型中，电子邮件直接投递到用户收件箱，Cloudflare 随后接收邮件副本、扫描并根据处置方式移动邮件。

此过程通过订阅授权域上的所有用户邮箱来执行。您可以在授权过程中选择范围应限于“仅收件箱”还是“所有文件夹”。发送到邮箱后，订阅会触发 Microsoft 365 中的一项操作，该操作会向 Cloudflare 发送一封电子邮件副本，以便对其进行扫描并分配处置方式。一旦分配了处置方式，我们的解决方案将查看自动移动策略并执行所需的操作。

上图描述了以下内容：

1. 电子邮件通过现有路由直接发送到用户收件箱。
2. Cloudflare 通过电子邮件供应商 API 检索邮件进行检查，检查正文、标头和附件，并分配适当的处置方式：
   • 恶意
   • 垃圾邮件
   • 批量
   • 可疑
   • 欺骗
   • 清洁
3. 应用任何策略，例如允许或阻止某些域。
4. 系统执行根据处于 Cloudflare 端预定的有关要求实行移置操作，并且具有执行这些指令选项可选用以针对前项判定加以归位排置：
   • 收件箱
   • 垃圾
   • 垃圾桶
   • 软删除（用户可恢复）
   • 硬删除（管理员可恢复）

在正常情况下，从投递到收件箱到发出移动请求，此过程通常在 2–3 秒内完成。Google 或 Microsoft 365 对执行移动操作所需时间不提供 SLA。如果移动操作未成功，解决方案会每 5 分钟重试多次。

• 在复杂的电子邮件架构中添加保护的简单方法，无需更改邮件流操作。
• 适用于 Microsoft 365 的无代理部署。
• 微软这边的包含像是 Microsoft 365 Defender/ATP 等这类软件机制则可对邮件优先先走一步干预及影响。
• 此方法可用于概念验证 (Proof of Value)，在不更改邮件流的情况下收集和报告电子邮件。在此场景中，您可以将修复策略留空，以防止采取任何操作。

在通过 API 部署部署电子邮件安全之前，您需要考虑以下事项：

• 取决于 API 基础架构，Microsoft 365 或 Google 的中断和维护窗口会增加邮件在收件箱中的停留时间，因为邮件在投递到用户之前无法被扫描或修复。这是所有 API 供应商的共同限制。
• Microsoft 365 可能会在逐个服务的基础上限制对 Graph API 的 API 请求。Graph 中的 Mail API 位于 Outlook 服务部分中。威胁行为者可能会滥用这些限制，从而在功能上禁用任何基于 API 的部署，从而提供额外的攻击窗口。限制如下：
  • 10 分钟内 10,000 个 API 请求
  • 4 个并发请求
  • 5 分钟内上传（PATCH、POST、PUT）150 MB
  • 参考 Outlook 服务限制 ↗
• Gmail API 受到每日使用限制（适用于从您的应用程序发出的所有请求）和每用户速率限制的约束。每个限制都以配额单位或表示 Gmail 资源使用情况的抽象计量单位来标识。主要请求限制说明如下：
  • 每用户速率限制为每用户每秒 250 个配额单位，移动平均值（允许短暂突发）。
  • 每个方法配额使用量基于根据所调用的方法，请求所消耗的配额单位数量。
  • 例如，messages.get 和 messages.attachments.get 消耗 5 个配额单位。参考每方法配额使用量 ↗
• 需要对邮箱具有读/写访问权限，某些安全/电子邮件团队可能不允许此权限。
• 只有 Microsoft 365 提供真正的 API 支持。Google 允许 API 修复，但仍需要合规规则通过 SMTP 投递邮件进行扫描。本地 Exchange 需要 PowerShell，不支持用于自动移动的 API。
• 根据 Microsoft 365/Google 的要求，邮件在发送后不能被修改。这意味着我们无法执行 URL 重写以实现 Cloudflare电子邮件链接隔离，或者在电子邮件主题或正文末尾追加文本。这些功能只能在使用 Inline 部署时使用。

BCC/日记与 API 部署非常相似，区别在于邮件如何送达 Cloudflare。与 API 一样，邮件首先投递到收件箱，但同时会将账户特定的电子邮件地址添加到邮件中，以便通过 SMTP 将副本传输到 Cloudflare 进行评估。

Cloudflare 收到邮件后会扫描并确定处置方式。邮件分配处置方式后，解决方案会查看 API 授权和自动移动策略并执行所需操作。此方法受 API 限流影响较小，因为 Microsoft 365 和 Google 的 API 仅用于修复邮件。

在概念验证期间，此部署可与任何允许添加 BCC 收件人的 Email Security 解决方案或邮件平台配合使用，以了解现有解决方案遗漏而 Cloudflare 会阻止的内容。

• 在复杂的电子邮件架构中添加保护的简单方法，无需更改邮件流操作。
• 适用于 Microsoft 365 的无代理部署。Microsoft 365 会在发送后将电子邮件传输给 Cloudflare，并且可以为 API 授权配置补救策略，以便将带有处置方式的电子邮件移出收件箱。
• Google 利用 BCC 合规规则，这些规则可以与 API 授权结合使用，以便在发送后移动电子邮件。这提供了与上面详细介绍的 API 部署相同的结果。
• Microsoft 365 和 Google 先对邮件进行处理。这提供了更分层的方案，在 Cloudflare 之外还利用 Microsoft 365/Google 的安全能力。
• 您可以控制受检查的消息范围（外部、内部或两者兼有）
• 此方法可用于概念验证，在不更改邮件流的情况下收集和报告电子邮件，且无需预先配置 API 授权。如果为 Microsoft 365 或 Google 配置了 API，您应将修复策略留空以防止采取任何操作。

在通过 BCC/Journaling 部署部署电子邮件安全之前，您需要考虑以下事项：

• 与 API 相同的限制。
• 依靠 Google 或 Microsoft 365 通过 SMTP 传送消息。
• 可能需要在 Microsoft 365 中使用连接器以促进直接通信。
• 根据 Microsoft 365/Google 的要求，邮件在发送后不能被修改。这意味着我们无法执行 URL 重写以实现 Cloudflare 电子邮件链接隔离，或者在电子邮件主题或正文末尾追加文本。这些功能只能在使用 Inline 部署时使用。

Mixed 对外部电子邮件使用 Inline 部署，对内部电子邮件使用 BCC/日记。通过同时使用两种部署方法，但在 BCC/日记模式下将 Cloudflare 配置为两跳 (two hops)，此场景为外部邮件提供 MX 投递的所有额外优势，同时修复来自内部来源的恶意邮件。以下是一些有帮助的场景。

混合部署结合了 Inline 部署针对外部电子邮件的优势和 BCC/Journaling 针对内部电子邮件的优势。

当您选择混合部署时，您需要考虑以下因素：

• 由于缺少电子邮件认证、发送服务器和投递路径等信息，内部邮件检测受到限制。只能分析邮件正文中的内容。
• 在对内部邮件使用“Protecting Users with impersonation registry（冒充注册表保护用户）”时，误报率可能更高。

Cloudflare 提供基于持续分析和提交的自动化工作流。这些功能使 Cloudflare 能够在投递后使用 API 自动移动策略移动邮件。这最适合与钓鱼提交或第三方用户提交配合使用。

Cloudflare 在仪表板中优先处理管理员提交的误报和漏报。这种方法可加快审查速度，并帮助 Cloudflare 主动识别和纠正可能影响多个用户的问题，从而改善整体产品体验。建议管理员审查用户提交，识别所有相关邮件，并通过 Cloudflare 仪表板提交已验证的误报/漏报。这些提交将被审查，并用于改进未来的机器学习模型、检测和引擎。

总而言之，电子邮件安全主要提供三大部署模型：API、BCC/Journaling 和 Inline（或 MX）。Inline 是首选部署模型，因为它在恶意邮件到达用户收件箱之前对其进行过滤和修复，从而消除停留时间风险并允许使用 URL 重写和邮件修改等功能。

API 和 BCC/日记模型是投递后解决方案，直接与 Microsoft 365 或 Google Workspace 等平台集成，在邮件进入用户邮箱后进行扫描和自动移动。这些投递后方法更易于部署且无需更改邮件流，但存在 API 限流风险以及无法修改邮件内容（如主题或正文）等限制。

最后，混合部署结合了 Inline 对外部电子邮件保护的优势（对消费电子邮件的系统（如 CRM 或工单系统）至关重要）与 BCC/日记对内部电子邮件评估的优势。