防范 Microsoft 365 遭受本地攻击

  • 项目

许多客户将其企业专用网络连接到 Microsoft 365，使其用户、设备和应用程序能够从中受益。 不过，这些专用网络可能会遭到攻击者以多种已广为记载的方式入侵。 许多组织将 Microsoft 365 看作一个令人忧虑的系统。 防范已遭入侵的本地基础结构对其造成影响至关重要。

本文介绍如何配置系统以帮助保护 Microsoft 365 云环境免受本地入侵，包括以下元素：

  • Microsoft Entra 租户配置设置
  • 如何将 Microsoft Entra 租户安全连接到本地系统
  • 需要采取哪些折衷方案才能以防范云系统遭受本地入侵的方式运行系统

Microsoft 强烈建议你实施本指南。

本地环境中的威胁源

Microsoft 365 云环境受益于功能丰富的监视和安全基础结构。 Microsoft 365 使用机器学习和人工智能来查看全球流量。 它可以快速检测攻击，并允许你近乎实时地重新进行配置。

混合部署可将本地基础结构连接到 Microsoft 365。 在此类部署中，许多组织向本地组件委托信任，以做出关键的身份验证和目录对象状态管理决策。 如果本地环境遭到入侵，这些信任关系就成了攻击者入侵 Microsoft 365 环境的契机。

两个主要威胁向量是联合身份验证信任关系和帐户同步。这两个向量都可以向攻击者授予对云的管理访问权限。

  • 联合身份验证信任关系，例如安全断言标记语言 (SAML) 身份验证，用于通过本地标识基础结构向 Microsoft 365 进行身份验证。 如果 SAML 令牌签名证书已泄露，则拥有该证书的任何人都可以利用联合身份验证来仿冒你云中的任何用户。

    我们建议在向 Microsoft 365 进行身份验证时尽可能地禁用联合身份验证信任关系。

  • 帐户同步可用于修改在 Microsoft 365 中拥有管理特权的特权用户（包括其凭据）或组。

    建议确保同步的对象持有的特权不超越 Microsoft 365 中用户的特权。 可以以直接的方式或通过将其包含在受信任角色或组中来控制特权。 确保这些对象在受信任的云角色或组中没有直接或嵌套的分配。

防范 Microsoft 365 遭受本地入侵

为了解决上述威胁，我们建议遵循下图所示的原则：

Reference architecture for protecting Microsoft 365, as described in the following list.

  1. 完全隔离 Microsoft 365 管理员帐户。 这些帐户应该：

    • 主控 Microsoft Entra ID。
    • 使用多重身份验证进行身份验证。
    • 受 Microsoft Entra 条件访问保护。
    • 仅使用 Azure 托管的工作站进行访问。

    这些管理员帐户在使用上受到限制。 在 Microsoft 365 中，不应有任何本地帐户拥有管理特权。

    有关详细信息，请参阅关于管理员角色。 另请参阅 Microsoft 365 的角色 Microsoft Entra ID。

  2. 从 Microsoft 365 管理设备。 使用 Microsoft Entra 加入和基于云的移动设备管理 (MDM) 来消除对本地设备管理基础结构的依赖关系。 这些依赖关系可能会侵害设备和安全控制。

  3. 确保没有任何本地帐户对 Microsoft 365 拥有提升的特权。 某些帐户会访问需要 NTLM、LDAP 或 Kerberos 身份验证的本地应用程序。 这些帐户必须位于组织的本地标识基础结构中。 确保这些帐户（包括服务帐户）未包含在特权云角色或组中。 另外，确保对这些帐户所做的更改不会影响云环境的完整性。 特权本地软件不得影响 Microsoft 365 特权帐户或角色。

  4. 使用 Microsoft Entra 云身份验证消除对本地凭据的依赖关系。 始终使用强身份验证，例如 Windows Hello、FIDO、Microsoft Authenticator 或 Microsoft Entra 多重身份验证。

具体安全建议

以下部分提供了有关如何实施上述原则的指导。

隔离特权标识

在Microsoft Entra ID 中，具有特权角色的用户（例如管理员）是用于构建和管理剩余环境部分的信任的根。 实施以下做法可以最大程度地减轻入侵所造成的影响。

有关详细信息，请参阅保护特权访问。 另请参阅 Microsoft Entra ID 中面向管理员的安全访问做法。

使用云身份验证

凭据是主要的攻击向量。 实施以下做法，使凭据更安全：

限制和弊端

混合帐户密码管理需要密码保护代理和密码写回代理等混合组件。 如果本地基础结构遭到入侵，攻击者可以控制这些代理所在的计算机。 这种漏洞不会使云基础结构受到侵害。 但是，云帐户无法防范这些组件遭到本地入侵。

从 Active Directory 同步的本地帐户在 Microsoft Entra ID 中标记为永不过期。 本地 Active Directory 密码设置通常会减轻此项设置的作用。 如果 Active Directory 实例遭到入侵且禁用了同步，则请设置 EnforceCloudPasswordPolicyForPasswordSyncedUsers 选项来强制实施密码更改。

预配从云进行用户访问

“预配”是指在应用程序或标识提供者中创建用户帐户和组。

Diagram of provisioning architecture shows the interaction of Microsoft Entra ID with Cloud HR, Microsoft Entra B 2 B, Azure app provisioning, and group-based licensing.

我们建议采用以下预配方法：

  • 从云 HR 应用到 Microsoft Entra ID 的预配。 这种预配可隔离本地入侵。 这种隔离不会中断从云 HR 应用到 Microsoft Entra ID 的“加入者-转移者-离开者”循环。

  • 云应用程序。 尽可能部署 Microsoft Entra 应用预配，而不是本地预配解决方案。 在出现本地违规时，此方法可以防范某些软件即服务 (SaaS) 应用受到恶意黑客配置文件的影响。 有关详细信息，请参阅什么是 Microsoft Entra ID 中的应用程序预配。

  • 外部标识。 使用 Microsoft Entra B2B 协作以减少与合作伙伴、客户和供应商进行外部协作的本地帐户的依赖项。 认真评估与其他标识提供者的任何直接联合。 有关详细信息，请参阅 B2B 协作概述。

    我们建议通过以下方式限制 B2B 来宾帐户：

    • 将来宾访问权限限制为浏览目录中的组和其他属性。 使用外部协作设置来限制来宾读取他们不属于的组的能力。
    • 阻止对 Azure 门户进行访问。 可以指定极少量的必要例外项。 创建涵盖所有来宾和外部用户的条件访问策略。 然后实施某个策略来阻止访问。 请参阅条件访问。

  • 断开连接的林。 使用 Microsoft Entra 云预配连接到断开连接的林。 此方法无需建立可能扩大本地违规所造成影响的跨林连接或信任。 要了解详情，请参阅什么是 Microsoft Entra Connect 云同步。

限制和弊端

用于预配混合帐户时，来自云 HR 系统的 Microsoft Entra ID 依赖于使用本地同步来完成从 Active Directory 到 Microsoft Entra ID 的数据流。 如果同步中断，Microsoft Entra ID 中不会提供新员工记录。

使用云组进行协作和访问

使用云组可将协作和访问与本地基础结构分离。

  • 协作。 将 Microsoft 365 组和 Microsoft Teams 展开新型协作。 取消配置本地通讯组列表，将通讯组列表升级为 Outlook 中的 Microsoft 365 组。
  • 访问。 使用 Microsoft Entra 安全组或 Microsoft 365 组授权访问 Microsoft Entra ID 中的应用程序。
  • Office 365 许可。 使用基于组的许可，通过仅限云的组预配到 Office 365。 此方法可将组成员身份控制与本地基础结构分离。

应将用于访问的组的所有者视为特权标识，以避免在发生本地入侵时接管成员身份。 接管包括对本地组成员身份的直接操控，或者对可能影响 Microsoft 365 中动态组成员身份的本地属性的操控。

从云中管理设备

使用 Microsoft Entra 功能安全地管理设备。

使用移动设备管理策略部署已加入 Microsoft Entra 的 Windows 10 工作站。 启用 Windows Autopilot 以实现全自动化预配体验。 请参阅 计划 Microsoft Entra 加入实现 和 Windows Autopilot。

  • 使用 Windows 10工作站。
    • 弃用运行 Windows 8.1 和更低版本的计算机。
    • 请勿将具有服务器操作系统的计算机部署为工作站。
  • 使用 Microsoft Intune 作为所有设备管理工作负载的授权来源。 参见 Microsoft Intune。
  • 部署特权访问设备。 有关详细信息，请参阅设备角色和配置文件。

工作负载、应用程序和资源

  • 本地单一登录 (SSO) 系统

    弃用任何本地联合身份验证和 Web 访问管理基础结构。 将应用程序配置为使用 Microsoft Entra ID。

  • 支持新式身份验证协议的 SaaS 和业务线 (LOB) 应用程序

    使用 Microsoft Entra ID 进行 SSO。 配置为使用 Microsoft Entra ID 进行身份验证的应用越多，遭受本地入侵的风险就越小。 有关详细信息，请参阅什么是 Microsoft Entra ID 中的单一登录。

  • 旧式应用程序

    可对不支持新式身份验证的旧式应用程序启用身份验证、授权和远程访问。 使用 Microsoft Entra 应用程序代理。 或者，使用安全混合访问合作伙伴集成通过网络或应用程序交付控制器解决方案来启用这些功能。 请参阅 使用 Microsoft Entra ID 保护旧版应用。

    选择支持新式身份验证的 VPN 供应商。 将其身份验证与 Microsoft Entra ID 集成。 发生本地入侵时，可以使用 Microsoft Entra ID 通过禁用 VPN 来禁用或阻止访问。

  • 应用程序和工作负载服务器

    需要服务器的应用程序或资源可迁移到 Azure 基础结构即服务 (IaaS)。 使用 Microsoft Entra 域服务分离对本地 Active Directory 实例的信任和依赖关系。 若要实现这种分离，请确保用于 Microsoft Entra 域服务的虚拟网络未连接到企业网络。 请参阅 Microsoft Entra 域服务。

    使用凭据分层。 应用程序服务器通常被视为第 1 层资产。 有关详细信息，请参阅企业访问模型。

条件访问策略

使用 Microsoft Entra 条件访问来解释信号，并使用这些信号做出身份验证决策。 有关详细信息，请参阅条件访问部署计划。

监视器

将环境配置为防范 Microsoft 365 遭受本地入侵后，主动监视环境。 有关详细信息，请参阅什么是 Microsoft Entra 监视？

要监视的方案

除了特定于你组织的任何场景外，还要监视以下关键场景。 例如，应该主动监视对业务关键型应用程序和资源的访问。

  • 可疑活动

    监视所有 Microsoft Entra 风险事件以查找可疑活动。 请参阅如何：调查风险。 Microsoft Entra ID 保护以原生方式与 Microsoft Defender for Identity 集成。

    定义网络命名位置，以免基于位置的信号产生干扰性的检测结果。 请参阅在条件访问策略中使用位置条件。

  • 用户和实体行为分析 (UEBA) 警报

    使用 UEBA 获取有关异常情况检测的见解。 Microsoft Defender for Cloud Apps 在云中提供 UEBA。 请参阅调查风险用户。

    可以从 Azure 高级威胁防护 (ATP) 集成本地 UEBA。 Microsoft Defender for Cloud Apps 读取 Microsoft Entra ID 保护发出的信号。 请参阅连接到 Active Directory 林。

  • 紧急访问帐户活动

    监视使用紧急访问帐户的任何访问活动。 请参阅 在 Microsoft Entra ID 中管理紧急访问帐户。 创建警报以便于调查。 此监视必须包含以下操作：

    • 登录
    • 凭据管理
    • 对组成员身份进行的任何更新
    • 应用程序分配

  • 特权角色活动

    配置并审查 Microsoft Entra Privileged Identity Management (PIM) 生成的安全警报。 每当直接分配用户时就生成警报，以此监视 PIM 外部的特权角色直接分配。 请参阅安全警报。

  • Microsoft Entra 租户范围的配置

    对租户范围的配置所做的任何更改都应在系统中生成警报。 这些更改包括但不限于以下更改：

    • 已更新自定义域
    • 在 Microsoft Entra B2B 中对允许列表和阻止列表做出的更改
    • Microsoft Entra B2B 通过直接联合或社交登录对允许的标识提供者（SAML 标识提供者）做出的更改
    • 条件访问或风险策略的更改

  • 应用程序对象和服务主体对象

    • 可能需要条件访问策略的新应用程序或服务主体
    • 添加到服务主体的凭据
    • 应用程序同意活动

  • 自定义角色

    • 对自定义角色定义做出更新
    • 新建的自定义角色

日志管理

定义日志存储和保留策略、设计与实施方案，促使工具集保持一致。 例如，可将安全信息和事件管理 (SIEM) 系统视为 Microsoft Sentinel、常用查询以及调查和取证 playbook。

  • Microsoft Entra 日志。 始终如一地遵循诊断、日志保留和 SIEM 引入等设置的最佳做法，引入生成的日志和信号。

    日志策略必须包括以下 Microsoft Entra 日志：

    • 登录活动
    • 审核日志
    • 风险事件

    Microsoft Entra ID 提供登录活动日志和审核日志的 Azure Monitor 集成。 请参阅 Azure Monitor 中的 Microsoft Entra 活动日志。

    使用 Microsoft Graph API 引入风险事件。 请参阅使用 Microsoft Graph 标识保护 API。

    可以将 Microsoft Entra 日志流式传输到 Azure Monitor 日志。 请参阅将 Microsoft Entra 日志与 Azure Monitor 日志集成。

  • 混合基础结构操作系统安全日志。 由于对外围应用造成的影响，应该存档所有混合标识基础结构操作系统日志，并将其作为第 0 层系统认真监视。 包括以下元素：

    • 应用程序代理

    • 密码写回代理

    • 密码保护网关计算机

    • 装有 Microsoft Entra 多重身份验证 RADIUS 扩展的网络策略服务器 (NPS)

    • Microsoft Entra Connect

      必须部署 Microsoft Entra Connect Health 以监视标识同步。 请参阅 什么是 Microsoft Entra Connect。

后续步骤