Outlook Web App 安全性：通过多因素身份验证 (MFA) 保护 Exchange

引言

大多数关于远程访问安全的讨论都从VPN开始。几乎没有哪次讨论会从Outlook Web App（OWA）说起，考虑到OWA的实际本质——一个位于开放互联网上的企业邮箱登录表单，可通过任何设备上的任何浏览器从任何地方访问——这种忽视显得颇为奇怪。 无需配置VPN客户端，无需绕过防火墙规则，也无需通过任何网络分段进行跳转——只需一个用户名字段、一个密码字段，以及Exchange服务器决定接受的任何内容。

对于攻击者而言，这几乎就是一条直通邮箱的捷径。 OWA 登录凭据一旦被盗，无需进行横向移动便已构成威胁——它本身就是危险的，且威胁立竿见影，因为邮箱本身就是攻击目标。企业邮箱入侵无需恶意软件，无需漏洞利用，也不会触发大多数针对网络入侵设计的检测工具。它只需要一组有效的凭据，以及一个仅要求输入这些信息的登录页面。

为何本地部署和混合部署的 Exchange 无法免费获得多因素身份验证

这种困惑是可以理解的，因为使用 Exchange Online 的 Microsoft 365 租户确实几乎自动获得了强身份验证——Entra ID 条件访问策略可以在会话令牌签发之前，就在身份层要求多因素身份验证，而且这种保护无需任何 Exchange 特定的配置即可扩展到 Outlook 网页版。仅在纯云环境中工作过的安全团队会合理地认为，Web 邮件的多因素身份验证就是 Exchange 的工作方式。

而本地和混合部署的 Exchange 并未继承这种行为。Exchange Server 自身的身份验证堆栈——负责处理 OWA 和 Exchange 管理中心的“客户端访问服务”角色——会根据 Active Directory 验证用户名和密码，如果没有额外配置，这就是整个身份验证决策的全部内容。 本地 OWA 登录中并未内置原生的第二因素验证。混合部署进一步加剧了这一复杂性：部分邮箱可能已被迁移至 Exchange Online 并受条件访问保护，而其他邮箱仍保留在本地，除非已明确配置混合现代身份验证或其他 MFA 解决方案，否则仍可能依赖 Exchange Server 自身的身份验证路径。 组织完全可能认为其电子邮件“受 MFA 保护”——因为租户层面确实如此——但实际上，相当一部分邮箱仍处于仅依赖密码的本地 OWA 环境中。

这正是运营层面需要关注的安全漏洞——并非因为本地 Exchange 在设计上本身安全性较低，而是因为它将添加第二重身份验证的责任完全推给了 Exchange 管理员，且没有默认的备用方案。

被攻破的 OWA 或 EAC 账户实际上能给攻击者带来什么

如果仅将其视为“普通的电子邮件”，人们很容易低估单个 OWA 凭据的价值。实际上，被入侵的邮箱账户是一个立足点，从中可以延伸出多条不同的攻击路径。

商业电子邮件欺诈（BEC）是造成经济损失最直接的攻击形式。

企业电子邮件欺诈（BEC）是造成经济损失最直接的攻击方式。据美国联邦调查局（FBI）互联网犯罪投诉中心记录，2025年美国报告的BEC损失总额达30.46亿美元，仅次于投资欺诈，位列损失金额第二高的类别，涉及约24,768起投诉——每起经确认的事件平均损失超过12万美元。 BEC 攻击的特点在于不涉及恶意软件，也没有恶意链接供安全过滤器拦截；攻击者潜伏在合法邮箱内，从合法地址发送邮件，通常在现有邮件线程中回复，并篡改银行转账账号或附上重定向的发票。 邮件流规则使得该技术事后更难被察觉——拥有邮箱访问权限的攻击者可以创建收件箱规则，悄无声息地转发或删除包含“发票”、“电汇”或“付款”等词汇的邮件，在欺诈对话平行进行的同时，使账户所有者无法察觉账户已被入侵。

代理访问权限进一步加剧了风险。

代理访问权限进一步加剧了风险。高管助理和财务团队成员通常因正常工作流程需要，持有高管邮箱的代理或“以…身份发送”权限，这意味着只要一名助理的账户遭到入侵，攻击者就能利用该账户发送看似直接来自首席财务官（CFO）或首席执行官（CEO）的通信，而无需触及该高管本人的凭证。

数据泄露是更隐蔽的风险

数据泄露是一种更隐蔽的风险，对于受监管的组织而言，往往后果更为严重。一个邮箱中会积累多年的附件、内部备忘录、人力资源往来信件以及客户通信记录，一旦攻击者通过身份验证，便可通过 OWA 自身的界面访问所有这些内容——无需额外的数据外泄工具，因为攻击者可以利用 OWA 的合法功能访问并下载邮箱内容。

方案 1：直接对 OWA 和 EAC 登录应用多因素身份验证

最针对性的修复方案是直接解决特定的风险面，而不触及与 Active Directory 相关的其他任何内容。Outlook Web App 和 Exchange 管理中心的 MFA作为 Exchange 客户端访问服务角色的组件进行安装，它位于现有的 OWA 和 EAC 登录页面之前，而不是直接替换 Exchange 的身份验证机制。 安装完成后，用户首先使用常规的 AD 用户名和密码进行身份验证，然后完成第二步身份验证——例如，输入来自身份验证器应用或硬件令牌的一次性密码 (OTP)，或批准一条推送通知——之后才会授予会话权限。

应用范围在安装时通过 Active Directory 组成员身份进行设置：管理员可以立即要求所有用户启用 MFA，也可以在规划全面部署期间，先为单个 AD 组（例如试点组，或具体而言是拥有 Exchange 管理中心访问权限的组）启用该功能。 这种区分在实际应用中至关重要，因为 EAC 账户带来的组织风险远高于单个邮箱；拥有 EAC 访问权限的管理员账户可以创建邮件流规则、修改权限，或在整个 Exchange 环境中导出数据，这正是为何即使全面用户部署需要更长时间，保护 EAC 登录安全也往往被列为优先事项。

会话行为是可配置的，而非固定的。管理员可以设置系统重新提示用户输入新一次性密码（OTP）的频率——例如，在连续使用 OWA 12 小时后提示一次——从而在反复身份验证带来的操作摩擦与共享或未受管设备上长期存在的无人看管会话风险之间取得平衡。 该组件支持 HOTP、TOTP 以及挑战-响应式的 OCRA，为使用不同类型 OTP 令牌的组织提供了灵活性。

方案 2：在 Active Directory 层级实施 MFA，将 OWA 与其他所有服务一并覆盖

在部署针对 OWA 的专用组件之前，值得思考一个更具体的问题：OWA 是否真的是唯一仍仅凭密码进行身份验证的、与 Active Directory 关联的服务？对于大多数本地环境而言，诚实的答案是否定的——Winlogon、RDP 以及通常与内部 LDAP 关联的应用程序也处于相同境地，除了 Active Directory 强制执行的密码策略之外，没有任何其他保护措施。

目录级别的多因素身份验证通过在 Active Directory 本身进行集成（而非在每个单独服务的登录页面上），解决了这一更广泛的漏洞。 与一系列独立的多因素身份验证部署（例如：OWA 专用组件、RDP 专用代理、VPN 专用 RADIUS 代理，且每个都需要独立安装、配置和维护）不同，目录级集成通过将静态密码替换为基于时间的动态密码，改变了用户凭据在 Active Directory 中的运作方式，从而使连接到 AD 的服务能够使用相同的动态凭据，而无需为每个服务单独部署多因素身份验证组件。 OWA 之所以被涵盖，并非因为它被专门选中，而是因为它与其他所有指向 AD 的服务一样，现在都必须满足相同的动态凭据验证要求。

这种权衡与方法 1 恰恰相反：以更广泛的覆盖范围为代价，换取对整个环境中 AD 身份验证行为的更深远改变，这通常比针对单个 OWA 组件的方案需要更周密的测试和分阶段部署。 在两者之间做出正确选择确实取决于范围——如果某组织唯一未受保护的与 AD 连接的入口是 OWA，则无需触及目录即可解决该问题；而如果某组织发现 OWA、RDP 和 Winlogon 均仅依赖密码认证，则存在更广泛的问题，仅靠单服务修复无法解决。

目录级机制如何在不依赖终端代理的情况下运行

目录级多因素身份验证（MFA）背后的机制本身就值得深入理解，因为它解释了为何该机制无需在单个工作站或服务器上安装任何软件，就能覆盖所有连接到 AD 的服务。

动态强密码认证（Dynamic Strong Password Authentication）的工作原理是修改存储在 Active Directory 中的密码本身，而非在每个终端拦截认证流量。用户的静态密码将被基于 TOTP 的轮换动态密码所取代，该密码会按照管理员配置的间隔（该值必须是 30 秒的倍数）自动更新。 当前的动态密码通过 TOTP 算法生成，用户可通过 Protectimus SMART 应用或受支持的聊天机器人获取。由于更改直接在目录中进行，任何基于 AD 进行身份验证的客户端或服务（如 Winlogon、RDP、OWA、LDAP 绑定应用程序）都会自动使用当前的动态密码，而无需该服务知晓任何变更。

这正是该方案在关键意义上实现“无代理”的核心所在：无论是笔记本电脑、RDP 主机还是 Exchange 客户端访问服务器上，均无任何软件运行以检查第二重身份验证。目录本身即是执行点。相应的权衡在于，由于该组件需要与域控制器直接集成，因此它作为本地部署的一部分运行，而非纯云服务。

选择适用范围：仅限 Webmail，还是整个 AD 环境

这两种方法都解决了根本问题——仅凭密码已不足以进行身份验证——但它们在技术栈的不同层面上解决了这个问题，因此正确的选择取决于对现有环境的客观评估，而非默认偏好。

如果 OWA 和 EAC 确实是仅凭密码仍通过 AD 进行身份验证的唯一服务——VPN 已通过 RADIUS 覆盖，RDP 已锁定，且没有其他遗留应用程序在暗中信任 AD 凭据——那么针对 OWA 的组件可以在对目录中运行的其他任何服务造成最小干扰的情况下，填补这一特定漏洞。 如果清点发现存在多个暴露的服务（这在 IT 团队实际排查时更为常见），则目录级别的多因素身份验证（MFA）能够通过单一集成点封堵所有漏洞，而无需为每个服务分别部署独立的 MFA 产品。

无论哪种情况，FBI关于BEC（商业电子邮件欺诈）损失的数据都指向同一个根本事实：对于任何运行Exchange的组织——无论是本地部署、混合部署还是其他部署方式——在开放的互联网上，企业邮箱仅凭密码登录已不再是一种可行的防御策略。