手册

实施一种假设泄露并要求对每个请求进行验证的安全模型。

→采用 Zero Trust 安全模型。

原因: 基于三个核心原则运行：显式验证、使用最小特权访问和假设泄露。它是一种战略方法，而非单一产品。

参考↗

定义云服务的安全所有权边界。

→应用共享责任模型 (Shared Responsibility Model)。客户始终负责：信息与数据、设备（端点）、账户与身份。

原因: 云提供商的责任从 IaaS 到 PaaS 再到 SaaS 递增，但客户始终保留对其数据和访问管理的责任。

防止单一安全层失效。

→在物理、身份、边界、网络、计算、应用和数据层实施多层安全策略（纵深防御 Defense in Depth）。

原因: 一个层面的泄露会被后续层面减缓或遏制，从而降低攻击的总体风险和影响。

区分验证用户身份和授予用户权限。

→使用身份验证 (AuthN) 来验证身份（证明您是您所声称的人）。使用授权 (AuthZ) 来确定已验证身份的访问权限（您被允许做什么）。

原因: 身份验证必须始终在授权之前发生。用户可以被验证身份，但未被授权访问特定资源。

在数据存储和传输时保护其机密性。

→对存储数据（例如，在磁盘上、数据库中）使用静态加密 (Encryption at Rest)。对通过网络传输的数据（例如，TLS/SSL）使用传输中加密 (Encryption in Transit)。

原因: 防御不同的威胁向量。静态加密可以缓解存储介质的物理盗窃，而传输中加密则可以防止窃听。

从单个控制平面管理云和本地资源的用户身份及访问。

→使用 Microsoft Entra ID 作为集中式身份提供商。

原因: 为身份提供单一事实来源，在混合环境中实现单点登录 (SSO)、多重身份验证 (MFA) 和一致的访问策略。

对应用程序和数据强制实施动态的、基于风险的访问控制。

→配置 Microsoft Entra 条件访问策略。

原因: 这是 Zero Trust 策略引擎。它评估信号（用户、位置、设备运行状况、风险）以强制执行决策，例如要求 MFA、限制会话访问或阻止访问。

参考↗

最大限度地减少与长期管理特权相关的安全风险。

→为 Azure 和 Microsoft 365 角色实施 Microsoft Entra Privileged Identity Management (PIM)。

原因: 提供即时 (JIT) 访问，要求用户在需要时激活角色。激活可能需要 MFA、理由和/或批准，从而大大减少攻击面。需要 Entra ID P2。

消除基于密码的攻击向量，如网络钓鱼和密码喷射。

→实施无密码身份验证方法，例如 Windows Hello for Business、FIDO2 安全密钥或 Microsoft Authenticator 应用。

原因: 通过依赖生物识别技术或绑定到物理设备的加密密钥，提供比密码更安全、更用户友好的替代方案。

为用户提供用于本地和云资源的单一身份。

→使用 Microsoft Entra Connect 将本地 Active Directory 与 Microsoft Entra ID 同步。

原因: 创建通用用户身份，在混合环境中实现无缝单点登录 (SSO) 和一致的访问管理。

允许外部合作伙伴访问公司资源，而无需为其创建和管理账户。

→使用 Microsoft Entra B2B（企业对企业）协作。

原因: 邀请外部用户作为访客，他们使用自己的公司或社交身份进行身份验证，从而减少管理开销和安全风险。

主动检测并自动响应基于身份的威胁。

→启用 Microsoft Entra ID Protection。

原因: 使用机器学习检测身份风险（例如，凭据泄露、来自匿名 IP 的登录）。风险信号可用于条件访问，以触发自动响应，例如强制重置密码或 MFA。

使 Azure 托管的应用程序能够访问其他 Azure 资源，而无需在代码中管理凭据。

→将托管标识分配给 Azure 资源（例如，VM、App Service）。

原因: 消除了开发人员处理机密、连接字符串或证书的需要。Azure 自动管理身份的生命周期。

减少服务台工作量，并使用户能够自行解决账户锁定或忘记密码的问题。

→在 Microsoft Entra ID 中配置自助式密码重置 (SSPR)。

原因: 允许用户在使用预先注册的方法（例如，电话、身份验证器应用、安全问题）验证身份后安全地重置密码。

定期验证用户对应用程序和特权角色的访问是否仍然必要。

→安排定期 Microsoft Entra 访问评审。

原因: 自动化访问评审过程，通过删除不必要的访问权限，确保随着时间的推移保持最小特权原则。

聚合企业范围内的安全数据以进行威胁检测并自动化事件响应。

→部署 Microsoft Sentinel。

原因: 作为云原生的安全信息和事件管理 (SIEM) 平台，用于数据收集和分析；并作为安全编排、自动化和响应 (SOAR) 平台，使用 Playbook 进行自动化操作。

参考↗

持续评估和强化云资源的安全配置。

→使用 Microsoft Defender for Cloud 的云安全态势管理 (CSPM) 功能。

原因: 提供安全分数、可操作的安全建议，并跟踪针对监管标准的合规性，以改善整体安全态势。

保护虚拟机 (VM)、容器和数据库等云和混合工作负载免受高级威胁。

→在 Microsoft Defender for Cloud 中启用特定的 Defender 计划（云工作负载保护 - CWP）。

原因: 提供高级的、针对工作负载的威胁检测和保护功能，例如服务器的端点检测和容器注册表的漏洞扫描。

调查并响应跨越端点、电子邮件、身份和云应用程序的复杂攻击。

→使用 Microsoft 365 Defender。

原因: 提供扩展检测和响应 (XDR) 解决方案，将来自多个 Microsoft Defender 产品的警报关联到单个事件中，提供统一的调查和响应体验。

保护用户设备（端点）免受恶意软件、勒索软件和其他复杂攻击。

→部署 Microsoft Defender for Endpoint。

原因: 提供预防性保护、泄露后检测 (EDR)、自动化调查和响应功能，以保护端点。

保护电子邮件和协作工具免受网络钓鱼、商业电子邮件泄露和恶意附件的侵害。

→实施 Microsoft Defender for Office 365。

原因: 为 Microsoft 365 服务提供高级威胁防护功能，例如安全附件（引爆室）和安全链接（URL 重写和扫描）。

检测针对本地 Active Directory 基础设施的攻击。

→部署 Microsoft Defender for Identity。

原因: 监控本地 AD 信号，以检测高级威胁、受损身份和恶意内部人员行为，这些行为通常是重大泄露的前兆。

发现员工使用的未经授权的云应用程序（“影子 IT”）并控制数据流向批准的应用程序。

→使用 Microsoft Defender for Cloud Apps。

原因: 作为云访问安全代理 (CASB)，提供对云应用程序使用情况的可视性、评估风险、强制执行策略并防御云中的威胁。

控制虚拟网络中 Azure 资源之间的网络流量。

→将网络安全组 (NSG) 应用于子网和/或网络接口。

原因: 作为基本的有状态数据包过滤防火墙，根据 IP 地址、端口和协议允许或拒绝流量。它是一种基本的网络安全控制。

使用智能、托管的防火墙服务集中保护所有虚拟网络资源。

→在中心 VNet 中部署 Azure Firewall。

原因: 一种完全托管的云原生防火墙即服务，提供基于威胁情报的过滤、高可用性和无限可扩展性。

保护 Azure 中的面向公众的应用程序免受分布式拒绝服务 (DDoS) 攻击的冲击。

→在虚拟网络上启用 Azure DDoS Protection Standard。

原因: 在默认基础设施级别保护之外，提供增强的缓解功能，包括自适应调整、攻击分析和成本保护。

提供对 Azure VM 的安全 RDP 和 SSH 访问，而无需将管理端口暴露给公共互联网。

→在虚拟网络中部署 Azure Bastion。

原因: 通过 Azure 门户提供安全的、基于浏览器的 TLS 连接到 VM，消除了 VM 上公共 IP 地址的需要，并减少了攻击面。

根据内容的敏感度对文档和电子邮件进行分类和保护，无论它们存储在何处或发送到何处。

→使用带有敏感度标签的 Microsoft Purview Information Protection。

原因: 标签应用随数据一起传输的持久保护（加密、内容标记、访问限制），确保数据在其整个生命周期中受到保护。

参考↗

防止用户意外或有意地将敏感信息（例如，信用卡号、PII）共享到组织外部。

→配置 Microsoft Purview 数据丢失防护 (DLP) 策略。

原因: DLP 策略可识别、监控并自动对 Microsoft 365 服务、端点和云应用程序中的敏感内容应用保护措施。

评估、管理和跟踪对 GDPR、HIPAA 和 ISO 27001 等行业法规和标准的合规性。

→使用 Microsoft Purview Compliance Manager。

原因: 提供一个集中式仪表板，包含合规性分数、预建评估模板和推荐的改进措施，以简化合规性管理。

自动将内容保留所需期限，并在出于业务或法规原因不再需要时将其删除。

→使用保留策略和保留标签实施 Microsoft Purview Data Lifecycle Management。

原因: 在 Microsoft 365 中强制执行数据治理策略，以管理内容生命周期、降低风险并遵守法规。

法律事务要求识别、保存和收集来自 Microsoft 365 的电子数据。

→使用 Microsoft Purview eDiscovery（标准版或高级版）。

原因: 提供工具来搜索相关内容，对其进行法律保留以防止修改或删除，并将其导出以供法律审查。

检测和调查员工可能的数据盗窃或安全策略违规行为。

→配置 Microsoft Purview Insider Risk Management。

原因: 关联来自 Microsoft 365 的各种信号，以识别潜在的内部风险活动，并提供工作流来调查和处理这些活动。

受监管的公司需要防止特定部门（例如，交易员和分析师）之间的沟通，以避免利益冲突。

→实施 Microsoft Purview Information Barriers。

原因: 强制执行策略，限制 Microsoft Teams、SharePoint 和 OneDrive 中定义的特定用户组之间的通信和协作。

创建跨本地、多云和 SaaS 环境的所有数据资产的全面、最新的映射。

→使用 Microsoft Purview Data Map 和 Data Catalog。

原因: 自动化数据发现、敏感数据分类和沿袭跟踪，以提供数据资产的整体视图，实现有效的治理。

检测、捕获并处理公司通信中的不当消息（例如，骚扰、分享机密）。

→部署 Microsoft Purview Communication Compliance。

原因: 通过使用机器学习检测电子邮件、Teams 和其他渠道中的策略违规行为进行审查，有助于最大程度地降低通信风险。

确保 Microsoft 支持工程师未经您明确、可审计的批准，无法访问您组织的数据。

→为 Microsoft 365 或 Azure 启用 Customer Lockbox。

原因: 为客户提供界面，以批准或拒绝来自 Microsoft 工程师的数据访问请求，在罕见的Azure 支持场景中赋予您最终控制权。

通过审查 Microsoft 365 中的用户和管理员活动来调查安全事件或合规性问题。

→搜索 Microsoft Purview 审计（标准版或高级版）日志。

原因: 提供跨 Exchange Online、SharePoint Online、OneDrive 和 Entra ID 等服务的统一活动审计跟踪，用于取证调查。