手册

从传统的边界模型开始零信任转型。

→优先遵循“显式验证”原则。基于所有可用数据点（身份、设备、位置、服务、数据、异常）对每个访问请求进行身份验证和授权。

原因: 显式验证是零信任的基石。所有其他控制措施（最小权限、假设泄露）都建立在永不信任、始终验证这一核心原则之上。

参考↗

设计针对完整勒索软件攻击链的全面防御措施。

→结合使用特权访问工作站 (PAWs) 以防止凭据盗窃和横向移动，并采用不可变备份架构（Azure Backup 不可变保管库，MUA）以实现弹性恢复。

原因: 这解决了预防（PAWs 阻止攻击）和恢复（如果预防失败，不可变备份确保业务连续性），从而提供了真正的弹性。

将威胁建模集成到具有短冲刺的敏捷开发生命周期中。

→使用 STRIDE 方法实施增量威胁建模。将其集成到冲刺规划中，随着架构演进而更新模型，并将其用作安全审查的关卡。

原因: 在敏捷环境中，威胁建模必须是持续的，而不是一次性事件，才能有效。增量更新使安全与开发速度保持一致。

以分阶段方法实施零信任，以实现快速见效。

→遵循零信任快速现代化计划 (RaMP) 的优先级：1. 身份与访问管理，2. 端点与设备，3. 应用程序，4. 网络与基础设施。

原因: 保护身份可实现最显著的即时风险降低，并构成了所有其他零信任支柱的控制平面。

根据业务影响而非仅仅 CVSS 分数来优先处理漏洞修复。

→使用 Microsoft Security Exposure Management 对已识别的关键资产执行攻击路径分析。优先修复那些可为高价值目标提供可行攻击路径的漏洞。

原因: 攻击路径分析将漏洞与业务风险相结合，确保修复工作集中于对组织构成最大威胁的风险。

在拥有多个 Azure 订阅的大型企业中强制执行一致的安全基线。

→在根管理组实施与 MCSB 对齐的 Azure Policy 计划。使用 Microsoft Defender for Cloud 在所有继承的订阅中进行持续合规性监控。

原因: 管理组级别的策略分配为所有当前和未来的订阅提供了可扩展的、继承的防护措施，默认确保了统一的安全基线。

为具有区域数据驻留要求的全球公司设计安全运营中心 (SOC)。

→部署多工作区 Microsoft Sentinel 架构。将数据保留在区域 Log Analytics 工作区中以满足驻留需求。使用 Azure Lighthouse 进行集中管理，并使用跨工作区查询进行统一威胁搜寻。

原因: 该模型平衡了集中式安全运营和全球可见性与本地数据驻留合规性，避免了数据传输违规。

参考↗

利用 Microsoft Defender XDR 和 Microsoft Sentinel 优化 SOC 运营。

→在 Sentinel 中启用 Microsoft Defender XDR 连接器以实现双向事件同步。使用 Defender XDR 进行 M365/端点事件的深度自动化调查。使用 Sentinel 进行与第三方源的跨域关联和高级搜寻。

原因: 这种“强强联合”的方法利用了两个平台的优势：XDR 用于 Microsoft 生态系统内的集成自动化响应，SIEM 用于广泛的跨平台可见性和关联。

实施事件响应自动化，同时避免因误报引入过高风险。

→在 Sentinel 中设计分层自动化策略。完全自动化低风险操作（丰富信息、通知）。对中等风险操作（阻止 IP）使用人工审核工作流。将高影响操作（禁用帐户）保留为手动执行。

原因: 分层自动化平衡了响应速度与适当的监督，最大限度地提高了 SOC 处理常见任务的效率，同时防止自动化操作造成重大的运营中断。

在本地、Azure、AWS 和 GCP 之间建立统一的安全监控平面。

→使用 Microsoft Sentinel 作为中央 SIEM。通过 Azure Arc 载入本地/多云服务器。使用原生 Sentinel 数据连接器连接 AWS 和 GCP 服务。在所有环境中启用 Microsoft Defender for Cloud。

原因: Azure Arc 将 Azure 控制平面扩展到任何基础设施，为混合云和多云资产提供单一管理界面，用于安全管理（Defender for Cloud）和监控（Sentinel）。

确保管理审计日志的长期、防篡改保留以满足合规性要求。

→配置诊断设置，将 Azure 活动日志导出到专用的 Log Analytics 工作区和不可变的 Azure 存储帐户。将这些资源放置在单独的、受限的安全/管理订阅中。

原因: 不可变存储 (WORM) 可防止日志篡改。单独的管理订阅将日志与工作负载管理员隔离，防止受损的管理员掩盖其踪迹。

根据可能的攻击模式优先进行安全控制投资。

→将现有安全控制映射到 MITRE ATT&CK 框架。分析与行业相关的威胁情报，识别可能的攻击者使用的常见 TTPs。优先弥补针对这些特定 TTPs 的检测/预防差距。

原因: 这种以威胁为导向的方法确保安全投资直接解决最可能和最具影响力的攻击向量，最大限度地降低风险。

管理 Azure、AWS 和 GCP 中身份的过度权限（权限蔓延）。

→部署 Microsoft Entra 权限管理 (CIEM)。使用它来持续发现权限、评估风险（权限蔓延指数），并生成调整权限大小以强制实施最小权限的建议。

原因: CIEM 是一个专门的解决方案，用于解决多云权限的复杂性，提供仅靠原生云 IAM 工具无法实现的可见性和自动化分析。

设计一个程序来检测内部员工的数据外泄或破坏行为。

→实施 Microsoft Purview Insider Risk Management。与 HR 系统集成，根据员工事件（例如，辞职）触发策略。根据风险指标配置策略，并在初始分析期间使用假名化来保护隐私。

原因: 有效的内部风险管理需要将技术信号（例如，批量下载）与 HR 背景（例如，员工离职日期）相关联，Purview 的设计宗旨正是在尊重隐私的同时完成此任务。

为标准的 Azure 中心辐射型拓扑设计网络安全。

→在中心 VNet 中部署 Azure Firewall Premium 进行集中流量检查（包括 IDPS 和 TLS 检查）。使用用户定义路由 (UDR) 强制隧道化来自辐射的流量。使用 NSG 在辐射内进行微细分。在中心启用 Azure DDoS Protection。

原因: 这种分层架构提供了深度防御：中心提供集中式威胁防护，辐射提供微细分，边缘提供容量攻击防护。

参考↗

设计架构以防止攻击者从受损工作站移动到关键服务器（第 0 层）。

→实施分层管理模型。为不同级别的管理（第 0、1、2 层）使用独立的专用帐户和特权访问工作站 (PAWs)。强制规定第 0 层凭据绝不能在较低层系统上使用。

原因: 这创建了凭据隔离边界，使得在较低层资产（如用户工作站）上窃取凭据不可能导致较高层资产（如域控制器）的泄露。

保护具有无法运行安全代理的旧设备的运营技术 (OT) 环境。

→使用被动、无代理网络传感器部署 Microsoft Defender for IoT。根据 Purdue 模型实施网络分段，在 IT 和 OT 之间创建 DMZ。将 Defender for IoT 警报集成到 Microsoft Sentinel。

原因: 被动网络监控提供了对 OT 特定协议和威胁的可见性，而不会影响敏感的旧工业系统。分段可遏制威胁并控制 IT/OT 数据流。

为 Azure Kubernetes Service (AKS) 工作负载设计深度防御安全。

→将 Microsoft Defender for Containers（注册表扫描、运行时威胁检测）与 Azure Policy for AKS（准入控制以强制执行无特权容器等安全标准）和网络策略（用于 pod 到 pod 的微细分）相结合。

原因: 容器安全需要多层方法：注册表中的“左移”、部署时的预防性防护措施（准入控制）、运行时网络隔离以及运行时威胁检测。

参考↗

设计本地数据中心与 Azure 之间高度安全且高性能的连接。

→使用带专用对等的 ExpressRoute 作为主连接，并使用站点到站点 VPN 作为故障转移备份。在 ExpressRoute 上启用 MACsec 或 IPsec 加密。使用 Private Endpoints 访问 Azure PaaS 服务。

原因: ExpressRoute 提供私有专用连接，绕过公共互联网。Private Endpoints 确保 PaaS 流量也脱离互联网。ExpressRoute 上的加密提供了深度防御。

为包含敏感数据的 Azure 存储帐户设计最高安全性。

→禁用公共访问和匿名访问。使用 Private Endpoints 进行网络访问。使用托管标识进行应用程序身份验证。使用客户管理的密钥 (CMK) 强制加密。启用 Microsoft Defender for Storage 进行威胁检测。

原因: 这种分层方法解决了所有关键安全向量：网络暴露（Private Endpoints）、凭据管理（托管标识）、加密控制（CMK）和运行时威胁（Defender for Storage）。

对本地和多云服务器应用一致的安全管理和治理。

→将服务器载入 Azure Arc。这扩展了 Azure 控制平面，允许通过 Microsoft Defender for Cloud (CSPM/CWP) 进行管理，应用 Azure Policy（包括来宾配置），并使用如 Update Management 等服务。

原因: Azure Arc 是在混合和多云服务器资产中创建单一管理和安全平面的基础技术。

参考↗

保护远程员工对互联网/SaaS 应用程序和私有企业应用程序的访问。

→实施 Microsoft 的 Global Secure Access。使用 Microsoft Entra Internet Access 作为 SaaS/互联网流量的安全 Web 网关 (SWG)。使用 Microsoft Entra Private Access 作为零信任网络访问 (ZTNA) 解决方案，以取代传统的 VPN。

原因: 这提供了一个统一的、以身份为中心的 SSE 解决方案，无论用户位置或资源类型如何，都能应用一致的安全策略，符合现代零信任原则。

为 Azure 虚拟机设计全面保护。

→启用 Microsoft Defender for Servers Plan 2，其中包括 Defender for Endpoint (EDR)。使用即时 (JIT) VM 访问默认关闭管理端口。使用 Azure Bastion 实现安全、基于代理的管理访问，无需公共 IP。

原因: 这提供了分层防御：JIT 和 Bastion 减少了攻击面，而 Defender for Servers 为工作负载本身提供了高级威胁检测和响应 (EDR)。

在数据处理（使用中数据）期间保护高度敏感数据，防止特权访问，包括云管理员的访问。

→在 AKS 上使用 Azure 机密计算 VM（例如，基于 AMD SEV-SNP）或机密容器。这创建了一个基于硬件的可信执行环境 (TEE)，其中数据和代码在执行期间被加密和隔离。

原因: 机密计算解决了静态数据加密或传输中数据加密未涵盖的最终数据状态（使用中），即使面对管理程序和主机操作系统也能提供保护。

强化复杂的本地 Active Directory 环境以抵御有针对性的攻击。

→优先实施分层管理模型以防止横向移动。部署受保护用户安全组和身份验证策略隔离区，以保护特权帐户免受凭据盗窃攻击（例如，Pass-the-Hash）。

原因: 这些控制措施解决了最常见且最具影响力的 AD 攻击向量：横向移动和凭据盗窃。它们比 LDAP 签名等一般强化措施更为关键。

为 Azure 和 Microsoft Entra ID 管理员实施零信任特权访问。

→部署 Microsoft Entra Privileged Identity Management (PIM)。将所有常驻特权分配转换为“符合条件”。配置有时限的激活、关键角色的审批工作流以及强制访问审查。

原因: PIM 是实现 Azure/Entra 角色即时 (JIT) 和最小权限访问的核心 Microsoft 服务，消除了常驻特权访问的重大风险。

参考↗

设计可扩展且可管理的条件访问策略结构。

→实施分层框架，包括所有用户的基线策略、敏感应用程序的增强策略以及特权访问的严格策略。使用命名位置和设备合规性等信号来减少受信任场景的摩擦。

原因: 单一的、庞大的策略是难以管理的。分层方法将控制强度与风险级别相匹配，在需要时提供强大的安全性，同时不会给日常任务带来不必要的摩擦。

自动化和治理完整的身份生命周期（入职、调动、离职）。

→使用 Microsoft Entra ID 治理。实施 HR 驱动的预配、用于自动化的 Entra ID 生命周期工作流、用于访问包（捆绑角色权限）的权限管理，以及用于证明的定期访问审查。

原因: 这提供了一个端到端、自动化的治理解决方案，确保正确授予访问权限，随着角色变更进行修改，并在终止时及时撤销，从而解决了陈旧帐户和权限蔓延的风险。

管理不同类型外部用户（合作伙伴、客户）的安全访问。

→对合作伙伴和承包商使用受跨租户访问策略管辖的 Microsoft Entra B2B 协作。对面向客户的应用程序使用 Microsoft Entra B2C，提供一个独立的、可扩展的目录，具有可定制的用户旅程。

原因: B2B 和 B2C 专为不同的外部身份场景而构建。使用正确的工具可以避免将所有外部用户一视同仁（例如，为他们创建内部帐户）所产生的安全和可伸缩性问题。

在 Microsoft 365 和 Azure 中一致地保护敏感数据。

→部署 Microsoft Purview 信息保护。使用自动化分类（敏感信息类型、可训练分类器）应用敏感度标签。配置标签以在数据所在的任何位置强制执行保护（加密、访问限制）。

原因: 以数据为中心的保护遵循数据本身。大规模自动化分类是确保跨大型数据资产实现一致标签和保护的唯一可行方法。

保护内部和外部 API 免受常见威胁。

→部署 Azure API Management 作为统一网关。使用 OAuth 2.0 强制实施强身份验证。配置速率限制和请求验证策略。为运行时威胁检测启用 Microsoft Defender for APIs。

原因: API 安全需要一个网关作为策略执行点。将预防性控制（APIM 策略）与检测性控制（Defender for APIs）相结合，可为 API 特定攻击提供深度防御。

将安全性集成到 CI/CD 管道中，以尽早发现漏洞（“左移”）。

→实施 GitHub Advanced Security（或 Defender for DevOps）。将自动 SAST（代码扫描）、依赖项扫描 (SCA) 和秘密扫描直接集成到 CI 管道和拉取请求流程中。使用安全门来阻止存在关键漏洞的构建。

原因: 开发人员工作流程中的自动化扫描提供了快速反馈，允许在成本最低的时候尽早修复漏洞，而不会在生产前安全审查中造成瓶颈。

为应用程序机密、密钥和证书设计安全且可管理的解决方案。

→使用 Azure Key Vault。按应用程序或安全边界隔离保管库。使用 Azure 资源的托管标识访问保管库（无存储凭据）。启用软删除和清除保护。使用 Defender for Key Vault 进行监控。

原因: Key Vault 提供了一个集中式、硬件支持且可审计的机密存储。使用托管标识是消除如何保护用于访问保管库本身的凭据的“零机密”问题的关键组件。

为敏感的 Azure SQL 数据库实施分层安全。

→将透明数据加密 (TDE) 与客户管理的密钥 (CMK)、针对特定敏感列的 Always Encrypted、非特权用户的动态数据屏蔽、Microsoft Defender for SQL 进行威胁检测以及仅 Azure AD 身份验证相结合。

原因: 没有单一的控制措施是足够的。这种分层方法可保护静态数据（TDE）、使用中数据（Always Encrypted）、防止未经授权的查看（屏蔽）、免受威胁（Defender），并确保强身份验证（Azure AD）。

防止电子邮件、Teams、SharePoint 和终端设备上的数据丢失。

→部署 Microsoft Purview DLP。创建适用于 M365 服务和终端的统一策略。将 DLP 规则与敏感度标签对齐。使用 Endpoint DLP 控制托管设备上的操作（例如，阻止复制到 USB）。

原因: 统一的策略引擎确保了所有数据通道上的一致执行。Endpoint DLP 对于将保护从云端扩展到用户设备本身至关重要。

为组织的数据环境做好准备，以便安全部署 Microsoft 365 Copilot。

→在部署之前，重点关注信息治理。使用 SharePoint Advanced Management 等工具查找并修复过度共享的站点和文件。确保已制定并应用健全的数据分类和敏感度标签策略。

原因: Copilot 尊重现有权限。它快速呈现信息的能力使得预先存在的过度共享问题成为一个关键风险。“整理好您的数据资产”是安全部署 AI 的先决条件。

为业务关键型 Web 应用程序设计全面安全。

→使用带有 Web 应用程序防火墙 (WAF) 的 Azure Application Gateway，并将其置于预防模式。将 SAST/DAST 扫描集成到 CI/CD 管道中。为运行时监控启用 Microsoft Defender for App Service。将 App Service 放置在 Private Endpoint 上。

原因: 这在多个层面提供了保护：边缘（WAF）、代码中（SAST/DAST）、平台上（Defender）和网络中（Private Endpoint），解决了广泛的 Web 应用程序威胁。

设计 AKS 中微服务之间的相互访问以及对 Azure PaaS 服务的无凭据身份验证。

→实施 Azure AD Workload Identity 以允许 Kubernetes pod 获取 Azure AD 令牌。使用服务网格（例如 Istio、Linkerd）强制对集群内的所有服务到服务通信实施相互 TLS (mTLS)。

原因: 这种模式完全消除了应用程序环境中长期存在的机密（密码、密钥），显著改善了安全状况。Workload Identity 处理到 Azure 的南北向身份验证，而 mTLS 处理集群内的东西向身份验证。

满足存储加密密钥的严格合规性要求（例如，FIPS 140-2 Level 3）。

→使用 Azure Key Vault Managed HSM。这提供了一个专用、单租户、FIPS 140-2 Level 3 验证的 HSM，由 Microsoft 完全管理，但客户可以完全控制安全域。

原因: 为了达到最高级别的合规性和密钥控制，需要使用 Managed HSM，而不是使用共享、多租户 HSM（FIPS 140-2 Level 2）的标准/高级 Key Vault 层级。

保护应用程序开发过程免受受损依赖项或恶意代码注入等威胁。

→设计一个安全的管道，使用私有包注册表（例如 Azure Artifacts）、依赖项扫描 (SCA)、软件物料清单 (SBOM) 生成、工件签名和来源验证。

原因: 这解决了供应链的多个阶段：控制输入（私有注册表）、验证组件（SCA、SBOM）和确保输出的完整性（签名、来源）。