通过

数据保护

数据保护可保护敏感信息免受未经授权的访问、外泄和在整个数据生命周期中的滥用。 实现发现和分类以建立数据清单、加密来保护传输中的数据和静态数据，以及严格的密钥和证书管理，以保持加密完整性。 这种分层方法符合零信任原则和深度防御策略。

如果没有全面的数据保护，组织将面临数据泄露、法规处罚和敏感信息外泄造成的声誉损害。

下面是数据保护安全域的三大核心支柱。

了解数据并对数据进行分类： 发现敏感信息并应用一致的标签，以实现基于风险的控制。

相关控件：

使用加密保护数据： 使用新式加密标准对传输中的数据和静态数据实施全面的加密。

相关控件：

管理加密基础结构： 使用自动轮换和全面的审核日志记录为加密密钥和证书建立严格的生命周期管理。

相关控件：

DP-1：发现、分类和标记敏感数据

Azure Policy： 请参阅 Azure 内置策略定义：DP-1。

安全原则

通过发现、分类和标记所有存储库中的数据来建立和维护敏感数据的综合清单。 这使基于风险的访问控制、加密策略和监视能够防范未经授权的访问和外泄。

待缓解风险

威胁参与者利用缺乏可见性和不一致的敏感数据处理来外泄或滥用高价值信息。 未发现、分类或标记敏感数据时：

  • 未跟踪的受管制数据： （PCI、PHI、PII）存储在非托管位置（影子 IT）会绕过所需的加密、保留或监视控制。
  • 超特权访问： 广泛的用户/服务访问仍然存在，因为未识别敏感度和业务影响。
  • 副本激增： 将数据复制到分析、测试或导出管道，将敏感内容分散到较低信任的环境中。
  • 法医盲点： 由于缺少或不正确的敏感度元数据，事件响应程序无法快速确定爆炸半径的范围。
  • 自动化失败： 治理（DLP、条件访问、加密工作流）无法触发且没有一致的标记。

缺乏基础分类会增加停留时间，扩大横向移动机会，并提升监管和声誉暴露。

MITRE ATT&CK

  • 侦查（TA0043）：通过枚举存储帐户、架构目录和分类元数据来定位高价值存储库，以收集受害者的身份信息和数据资产（T1596）。
  • 发现（TA0007）：帐户和权限枚举（T1087，T1069）用于揭示过度的角色绑定，从而实现水平或垂直数据访问升级。
  • 集合（TA0009）：通过提取未标记的 Blob 容器或缺少跟踪标记的非托管导出的方式，从云存储（T1530）中收集数据。
  • 数据窃取（TA0010）：通过没有标签/策略管理的临时导出端点（T1567）进行网络服务上的数据窃取。
  • 数据外泄（TA0010）：通过脚本化分页/循环实现自动化数据外泄（T1020），从而悄无声息地收集被错误分类的数据集。

DP-1.1：发现、分类和标记敏感数据

使用 Microsoft Purview 构建一个全面的数据映射，用于在整个数据资产中自动发现、分类和标记敏感信息。 通过实施 Microsoft Purview 信息保护，在数据到处流动时应用随附的持久性文档级加密和使用权限，从而扩展防护，超越基础设施级别加密。 此基础功能使下游安全控制（如数据丢失防护、条件访问和加密策略）能够基于数据敏感度而不是单独位置运行。

数据发现和分类：

  • 部署 Microsoft Purview ，以跨 Azure、本地、Microsoft 365 和多云环境发现、分类和标记敏感数据。
  • 使用 Microsoft Purview 数据映射 自动扫描和编录数据源，包括 Azure 存储、Azure SQL 数据库、Azure Synapse Analytics 和其他受支持的服务。
  • 启用 Purview 数据映射中的 敏感度标签 ，以基于数据内容模式和组织策略自动应用分类标签（例如机密、高度机密、PII、PHI）。

文档级加密和保护：

  • 部署 Microsoft Purview 信息保护 ，以基于敏感度标签对文档和电子邮件应用持久加密和使用权限。 配置标签以自动加密文件、应用水印、限制转发、设置到期日期，甚至在数据离开组织后撤销访问权限。
  • 启用 Azure Rights Management Service（Azure RMS） 作为基础保护技术，加密文档和电子邮件，并应用使用策略（如仅查看、无复制、无打印），这些策略不受数据存储或共享位置的变化而改变。

数据库分类和集成：

  • 对于 Azure SQL 数据库，启用SQL 数据发现和分类功能，以识别、分类和标记包含敏感数据的列，例如信用卡号、社会安全号码或健康记录。
  • 将分类元数据与下游控件集成：在 Microsoft Purview 中配置数据丢失防护（DLP）策略，在 Entra ID 中应用条件访问规则，并根据敏感度标签强制实施加密策略。
  • 建立定期扫描计划，以随着数据资产的发展，持续发现新创建的或修改的敏感数据资产。

实现示例

一个全球金融服务组织部署Microsoft Purview 数据映射，用于跨 200 多个 Azure 存储帐户、50 个 SQL 数据库和 Synapse Analytics 工作区自动发现和分类敏感数据。

挑战： 组织缺乏对敏感数据在其快速增长的 Azure 数据资产中驻留的位置的可见性。 手动数据分类不一致、治理强制延迟，并造成了合规性差距。 如果没有自动发现，受监管的数据（PHI、PII、PCI）在非托管位置仍然不受保护，数据丢失防护策略无法适当触发。

解决方案方法：

  • 为数据发现部署Microsoft Purview 数据映射： 创建 Purview 帐户并注册数据源（Azure 存储帐户、SQL 数据库、Synapse Analytics 工作区），使用托管标识身份验证配置数据映射以扫描源，向目录架构授予扫描标识读取权限（db_datareader角色），并检测敏感列。
  • 配置分类和敏感度检测： 设置扫描规则以检测敏感模式（例如 SSN、信用卡号、医疗记录号、SWIFT 代码），根据数据分类策略定义自定义分类规则（“机密 - 内部”用于业务敏感数据，“高度机密 - 受监管”用于 PHI/PCI/PII 数据），配置自动标记阈值（在单个资产中检测到≥3个 PII 模式时应用“高度机密”），根据数据重要性建立扫描计划（例如，生产环境每周扫描，存档每月扫描），配置警报，以便在发现新的高敏感度数据时通知安全团队。
  • 为文档级加密部署 Microsoft Purview 信息保护： 使用保护设置在 Purview 合规性门户中创建敏感度标签（公共：不加密，仅视觉标记;内部：水印，无转发限制;机密：使用 Azure RMS 加密，仅允许员工查看/编辑，阻止转发/打印;高度机密 - 受监管：使用 Azure RMS 进行加密， 仅查看访问权限、无复制/打印/转发、90 天过期、可吊销访问权限）、通过标签策略（范围：财务、法律、行政部门）向用户发布敏感度标签（财务、法律、行政部门），配置自动标记策略以自动应用标签（≥10 个 SSN →“高度机密 - 管控”，≥5 个信用卡号→“高度机密 - 受监管”），为存储在 SharePoint 中的标记文档启用 Azure RMS 保护， OneDrive 和 Azure 存储帐户配置 Office 应用程序的客户端标签，以在保存/发送之前提示用户对文档进行分类。

结果： Purview 数据映射自动扫描在第一周内识别了超过 15,000 个包含受管制数据的数据资产，减少了从几个月到几天的发现时间。 信息保护自动标记在 72 小时内将加密应用于 8,500 个文档。 即使数据移动到非托管设备，敏感度标签也开启了对数据资产的持续可见性和持久保护。

严重性级别

必须具有。

控件映射

  • CIS 控件 v8.1： 3.2、3.7、3.13
  • NIST SP 800-53 Rev.5： RA-2、SC-28
  • PCI-DSS v4： 3.2.1、12.3.1
  • NIST CSF v2.0： PR.DS-1, PR.DS-5
  • ISO 27001：2022： A.8.11
  • SOC 2： CC6.1

DP-2：监视针对敏感数据的异常和威胁

Azure Policy： 请参阅 Azure 内置策略定义：DP-2。

安全原则

监视敏感数据访问和传输活动，发现异常，这些异常指示未经授权的外泄、内部威胁或泄露的帐户。 使用行为基线和数据敏感度上下文检测异常模式，例如大型传输、异常访问时间或意外的数据移动。

待缓解风险

攻击者和恶意内部人员尝试使用隐秘或低信号行为外泄、暂存或探测敏感数据。 如果没有与数据敏感度相关的持续上下文感知异常监视：

  • 静默数据泄露： 由于缺少基线，批量导出、大型结果集或增量窃取未被检测到。
  • 内部人员滥用： 合法凭据执行异常的序列（时间、容量、位置），以规避粗略监控。
  • 暂存和枚举： 攻击者将架构/标签与优先级对应，以在大规模提取之前识别高价值目标。
  • 生活在陆地上的查询： 标准管理工具在正常作噪音中屏蔽侦察。
  • 跨存储逃避： 跨多个服务的分布式访问可规避单个存储阈值和关联。

异常检测不足会削弱事件响应效率，导致从侦查阶段升级到大规模数据泄露，几乎没有阻碍。

MITRE ATT&CK

  • 集合（TA0009）：通过敏感的容器中异常的大规模读取或广泛的扇出读取，从云存储（T1530）获取的数据。
  • 凭据访问（TA0006）：有效帐户（T1078）滥用泄露凭据或内部凭据与合法流量基线混合。
  • 数据泄露（TA0010）：使用经过精心设计的脚本化、受限查询，实现自动数据泄露（T1020），以避免触发警报阈值。
  • 外泄（TA0010）：将数据外泄到攻击者控制的区域或账户中的云存储（T1567.002），以便稍后检索。
  • Command & Control / Exfiltration （TA0011/TA0010）：应用程序层协议（T1071）通过普通 DB/API 调用隧道敏感行。
  • 发现（TA0007）：系统/服务发现（T1082，T1046）枚举终结点，以绘制更高值存储的横向移动路径。

DP-2.1：为数据服务启用威胁检测

部署 Microsoft Defender 服务，以跨数据存储和数据库平台提供实时威胁检测和异常监视。 这些服务使用行为分析和威胁智能来识别可疑活动，例如 SQL 注入尝试、异常查询模式、异常数据访问量以及传统访问控制无法检测到的潜在外泄指标。

为数据服务启用威胁检测：

DP-2.2：监视和防止数据外泄

实施主动的数据泄漏防护控制和行为监视，以检测和阻止未经授权的数据传输，在它们成功之前。 将基于策略的 DLP 与内部风险管理、SIEM 关联和自动响应相结合，以创建一种深层防御方法，从而停止跨多个渠道的外泄尝试，同时提供事件调查的取证证据。

部署 DLP 和内部风险控制：

  • 使用 Microsoft Purview 数据丢失防护 （DLP） 策略通过监视和阻止未经授权的跨 Azure 服务、Microsoft 365 和终结点传输机密数据来防止敏感数据外泄。
  • 部署 Microsoft Purview Insider Risk Management ，以使用机器学习和行为分析检测有风险的用户行为。 监视指标，包括异常数据下载、将文件复制到 USB/个人云存储、在正常工作时间之外访问敏感资源，或辞职日期前的数据访问高峰。 内部风险管理将来自 Microsoft 365、Azure、HR 系统和安全工具的信号相关联，以识别潜在的数据盗窃或策略违规行为。

配置监视和响应：

  • 配置数据服务的 诊断日志 并将其路由到 Azure Monitor 或 Microsoft Sentinel，以建立行为基线并检测与正常访问模式的偏差。
  • 将数据服务日志与 Microsoft Sentinel 集成，以创建分析规则，用于检测异常数据访问模式，例如批量下载、非工作时间访问或可疑查询行为。
  • 使用 Azure 逻辑应用 或 Microsoft Sentinel playbook 实现自动化事件响应工作流，以在检测到数据外泄尝试时隔离已泄露的标识、撤销访问权限并通知安全团队。

注意： 对于基于主机的 DLP 要求，请从 Azure 市场部署 Microsoft Purview 终结点 DLP 功能或第三方解决方案，以强制实施终结点级数据保护控制。

实现示例

医疗保健提供商启用了 Microsoft Defender for Storage 和 Defender for SQL，以监测 Azure 存储帐户和 SQL 数据库中患者数据的异常和威胁。

挑战： 组织在检测未经授权的数据访问和外泄尝试方面遇到了盲点。 传统的外围防御错过了内部威胁，服务主体执行批量下载。 如果没有行为分析和异常情况检测，可疑的访问模式在较长时间内被忽视，增加了漏洞风险和停留时间。

解决方案方法：

  • 启用 Microsoft Defender for Storage： 在订阅级别为包含敏感数据的存储帐户启用 Defender for Storage，配置恶意软件扫描以检测和隔离 Blob 存储中的恶意文件，使用 Purview 敏感信息类型启用敏感数据威胁检测，以识别 PHI/PII 模式，设置每事务扫描限制或每月上限来控制成本，对包含托管医疗成像和 EHR 导出的生产存储帐户的资源组应用保护。
  • 启用 Microsoft Defender for SQL： 在 Azure SQL 数据库和 SQL 托管实例的订阅级别启用 Defender for SQL，使用定期扫描配置漏洞评估，并指定存储帐户进行扫描结果，设置电子邮件通知以提醒安全团队识别的漏洞，使高级威胁防护能够检测 SQL 注入尝试、异常查询模式、来自不熟悉区域的异常访问， 和潜在的数据外泄。
  • 与 Microsoft Sentinel 集成： 使用数据连接器将 Microsoft Defender for Cloud 连接到 Microsoft Sentinel、配置诊断设置（为存储作和 SQL 审核日志启用诊断日志、路由到 Log Analytics 工作区）、创建 Sentinel Analytics 规则以检测异常（在 1 小时内批量下载 >10 GB 的警报、非工作时间数据库访问、可疑查询模式），配置自动响应 playbook 以隔离已泄露的标识， 撤销存储访问权限，并通知安全团队。
  • 部署 Microsoft Purview Insider Risk Management 进行行为威胁检测： 启用内幕风险管理并配置策略模板（在辞职前30-90天检测异常文件下载，常规数据泄漏监视 USB/云存储复制，对具有高优先级角色用户的数据泄漏进行增强监控），配置风险指示器和阈值（累积文件下载量警报，非工作时间访问激增，组合多个风险信号的序列检测）， 集成数据源（Azure 活动日志、Microsoft 365 审核日志、Defender for Cloud Apps、HR 系统、终结点 DLP 事件），将警报分类工作流配置为中等/高严重性警报的专用调查队列路由。

结果： Defender for Storage 在 48 小时内检测到来自受损服务主体的异常批量下载活动。 自动响应在几分钟内隔离标识并通知 SOC，将检测时间从几天缩短到 15 分钟以下。 内部风险管理标记了一位即将离职的员工，因为其下载的研究数据量远超个人基线并存储在个人云上，从而实现了快速干预。

严重性级别

必须具有。

控件映射

  • CIS 控件 v8.1： 3.13
  • NIST SP 800-53 Rev.5： AC-4、SI-4
  • PCI-DSS v4： 3.2.1、10.4.1
  • NIST CSF v2.0： DE.CM-1, PR.DS-5
  • ISO 27001：2022： A.8.11、A.8.16
  • SOC 2： CC6.1、CC7.2

DP-3：加密传输中的敏感数据

Azure Policy： 请参阅 Azure 内置策略定义：DP-3。

安全原则

使用强加密（如 TLS 1.2 或更高版本）保护传输中的数据，以防止拦截、篡改和未经授权的访问。 定义强制加密的网络边界和服务范围，在考虑基于数据敏感度的内部网络保护的同时，优先考虑外部和公用网络流量。

待缓解风险

未加密或弱保护的网络通道可能导致敏感数据暴露于拦截、篡改和降级滥用。 缺少强制的新式传输加密（TLS 1.2+）：

  • 被动拦截： 网络观察程序以纯文本形式捕获凭据、令牌、API 有效负载或管控数据。
  • 中间人： 攻击者更改查询、注入有效负载或收获会话材料。
  • 协议降级： 旧式回退（SSL/TLS < 1.2，纯文本 HTTP/FTP）支持利用已弃用的密码套件。
  • 会话劫持： 通道完整性缺失可能导致令牌重放或 Cookie 被盗，从而实现横向移动。
  • 完整性操纵： 篡改会破坏分析或引发欺诈交易。
  • 难以识别的横向路径： 内部纯文本流量在获得立足点之后成为侦察数据。

未能在传输中强制强加密放大破坏爆炸半径，加速凭据泄露，并破坏零信任假设。

MITRE ATT&CK

  • 凭据访问（TA0006）：未受保护的凭据（T1552）在纯文本或降级的 TLS 会话中被截获，导致令牌/会话材料暴露。
  • 集合（TA0009）：网络嗅探（T1040）收集经过弱密码或明文路径的 API 有效负载和机密数据。
  • 外泄（TA0010）：通过合法 API 终结点通过 Web 服务（T1567）流式传输结构化数据。
  • 防御逃避（TA0005）：中间攻击者（T1557）强制 TLS 降级或插入拦截代理以查看/修改流量。
  • 命令和控制（TA0011）：非应用层协议（T1095）还原为传统或较少检查的传输方式，以规避监控。

DP-3.1：对数据服务和应用程序强制实施 TLS 加密

在所有面向客户的服务和数据平台上建立现代传输层安全标准，以防止拦截、篡改和中间人攻击。 跨存储、Web 应用程序、数据库和 API 网关强制实施最低 TLS 1.2 或 1.3，同时禁用向加密降级攻击公开数据的旧协议和弱密码套件。

对数据服务和应用程序强制实施 TLS：

  • 为 Azure 存储帐户强制实施 安全传输 (仅 HTTPS)，以确保所有客户端连接都使用 TLS 1.2 或更高版本执行 blob、文件、队列和表操作。
  • 对于托管在 Azure 应用服务上的 Web 应用程序，启用“仅限 HTTPS”设置，并将 最低 TLS 版本配置为 1.2 或 1.3 ，以防止降级攻击并确保新式加密标准。
  • 将 Azure 应用程序网关 配置为对前端侦听器和后端连接加密（端到端 TLS）强制实施 TLS 1.2/1.3 最低版本。
  • 对于 Azure SQL 数据库和其他 PaaS 数据服务，请验证“需要安全连接”或等效设置是否强制实施加密连接;拒绝纯文本连接。
  • 对于 API 管理、Azure Front Door 和其他网关服务，请配置最低 TLS 版本策略以强制实施 TLS 1.2 或更高版本，并禁用弱密码套件。

注意： Azure 使用 MACsec（第 2 层）和 TLS（第 7 层）自动加密 Azure 数据中心之间的所有流量。 默认情况下，大多数 Azure PaaS 服务都启用 TLS 1.2+ ，但验证具有客户可配置策略的服务的最低 TLS 版本设置（存储、应用服务、应用程序网关、API 管理、Front Door）。

DP-3.2：安全远程访问和文件传输协议

消除在操作活动中公开凭据和敏感数据的明文管理权限和遗留文件传输协议。 将不安全的协议（FTP、未加密的 RDP/SSH）替换为新式加密的替代方法，并通过集中式堡垒路由特权访问，以消除管理接口的直接 Internet 公开。

保护远程管理协议：

  • 若要远程管理 Azure 虚拟机，请专门使用安全协议：
    • Linux VM： 将 SSH（端口 22）与基于密钥的身份验证配合使用;禁用密码身份验证。
    • Windows VM： 使用启用了网络级别身份验证（NLA）的 RDP over TLS（端口 3389）。
    • 特权访问： 通过 Azure Bastion 路由管理连接，以消除公共 IP 公开，并通过 TLS 提供基于浏览器或本机客户端的访问。

安全文件传输协议：

  • 对于文件传输作，请使用安全协议并禁用旧版替代方法：
  • 使用 Azure Policy 在整个环境中强制实施安全传输策略，并监视 TLS 版本要求的符合性。

实现示例

电子商务平台在所有面向客户的服务中强制实施 TLS 1.3 最低版本，以满足 PCI-DSS 4.0 要求。

挑战： 旧版 TLS 1.0/1.1 协议和弱密码套件暴露了客户支付数据以拦截攻击。 在不同应用程序层次上实施不一致的 TLS 强制措施，导致出现安全缺口，攻击者可以借此降级连接。 如果不强制实施集中式 TLS 策略，手动配置偏移允许不安全的协议保留在生产环境中。

解决方案方法：

  • 为 TLS 1.3 配置 Azure 应用服务： 将面向客户的 Web 应用程序和 API 的最低 TLS 版本设置为 1.3，使仅 HTTPS 模式能够自动将所有 HTTP 流量重定向到 HTTPS，验证托管证书或自定义证书是否使用强密码套件。
  • 为端到端 TLS 配置 Azure 应用程序网关： 使用 SSL 策略 AppGwSslPolicy20220101 配置前端 HTTPS 侦听器（使用 CustomV2 策略最低 TLS 1.3），上传 TLS 证书或与 Key Vault 集成，以便进行证书管理，为 HTTPS 连接配置后端设置（在端口 443 上将后端协议设置为 HTTPS），如果后端应用服务使用 Azure 托管证书，请将最低 TLS 版本设置为 1.2 进行后端连接）， 使用启用 TLS 的设置创建将 HTTPS 侦听器链接到后端池的路由规则。
  • 为 Azure 存储强制实施安全传输： 启用“需要安全传输”设置，为 blob、文件、队列和表操作强制仅限使用 HTTPS，将所有存储连接的最低 TLS 版本设置为 1.2，确保所有 SAS 令牌和共享密钥只能通过 HTTPS 连接使用。
  • 为 Azure Bastion 配置安全远程访问： 在中心 VNet 中部署 Azure Bastion，以通过 TLS 1.2 提供基于浏览器的 RDP/SSH 访问，从 VM 中删除公共 IP，并通过 Bastion 专门路由所有管理访问权限。

结果： Azure 存储帐户拒绝服务边界上的 HTTP 连接，应用程序网关为使用 TLS 1.2 后端加密的前端连接强制实施 TLS 1.3，Azure Bastion 消除了 VM 管理的公共 IP 公开。

严重性级别

必须具有。

控件映射

  • CIS 控件 v8.1： 3.10
  • NIST SP 800-53 Rev.5： SC-8
  • PCI-DSS v4： 4.2.1、4.2.2
  • NIST CSF v2.0： PR.DS-2
  • ISO 27001：2022： A.8.24
  • SOC 2： CC6.1、CC6.7

DP-4：默认启用静态数据加密

Azure Policy： 请参阅 Azure 内置策略定义：DP-4。

安全原则

默认启用静态加密，防止通过基础存储、物理媒体盗窃、快照泄露或基础结构访问泄露来保护数据免受未经授权的访问。 加密通过确保数据在绕过存储级别安全性时仍然受到保护，从而补充访问控制。

待缓解风险

未加密或选择性加密的存储层允许具有带外访问（基础结构泄露、被盗媒体、快照滥用）的攻击者大规模获取敏感数据。 没有默认加密：

  • 从原始媒体收集数据： 被盗的磁盘、备份或非托管快照公开完整的纯文本数据集。
  • 特权边界侵蚀： 平台管理员或泄露的主机代理可以读取不存在加密隔离的租户数据。
  • 无提示复制和外泄： 未加密的副本（测试、分析、导出）成为低摩擦外泄通道。
  • 完整性篡改： 攻击者修改休眠数据（恶意 DLL、配置或引用数据），以触发后期入侵。
  • 法规不合规： 缺乏系统加密会破坏许多行业认证所需的保证。
  • 无密钥恢复暴露： 灾难恢复映像和冷存档在可恢复的纯文本中无限期地保留敏感内容。

未能强制实施普遍的静态数据加密会增加数据泄露规模，使法医调查的范围复杂化，并放大下游运营和法律风险。

MITRE ATT&CK

  • 集合（TA0009）：从云存储（T1530）提取未加密的快照、副本或分离磁盘的数据。
  • 防御规避（TA0005）：指标删除（T1070），在访问脱机媒体/快照后编辑或清除日志。
  • 影响（TA0040）：数据销毁（T1485）损坏未加密的休眠资产以破坏下游进程。
  • 影响（TA0040）：抑制系统恢复（T1490）删除或更改未加密的备份和恢复目录。
  • 影响 （TA0040）：数据操纵（T1565）通过巧妙地修改存储的引用或配置数据，导致后期逻辑错误。

DP-4.1：默认启用静态数据加密

确保 Azure 中存储的所有数据都是静态加密的，以防止未经授权访问基础结构泄露、被盗媒体或未经授权的快照。 虽然大多数 Azure 服务默认启用加密，但验证虚拟机、存储帐户和数据库的覆盖范围，并启用其他加密层（主机加密、基础结构加密、机密计算和列级加密），以满足法规和数据主权要求。

为 VM 和存储启用加密：

  • 为 Azure 虚拟机启用 主机加密 ，以便在数据到达 Azure 存储之前加密临时磁盘、OS 磁盘缓存、数据磁盘缓存和临时 OS 磁盘。 在订阅级别注册 EncryptionAtHost 功能，并使用支持的 VM 大小（例如 DSv3、Easv4、Dadsv5 系列）部署 VM。
  • 为需要其他加密层的 Azure 存储帐户启用 基础结构加密（双重加密 ）。 这提供了两层 AES-256 加密，在服务和基础结构级别使用不同的密钥- 在存储帐户创建期间进行配置，因为创建后无法启用它。

部署机密计算和列级加密：

  • 部署具有机密磁盘加密的 Azure 机密 VM，以便处理高度管控的工作负荷，其中包括出口管制或敏感数据。 将 DCasv5/DCadsv5 系列（AMD SEV-SNP）或 ECasv5/ECadsv5 系列（Intel TDX）与 vTPM 绑定的磁盘加密密钥配合使用，以确保数据在处理过程中保持加密状态。
  • 对于 Azure SQL 数据库，实现 Always Encrypted 为高度敏感数据（SSN、信用卡号、医疗记录）提供客户端列级加密，即使在数据库管理员、云操作员和高特权但未经授权的用户中，数据仍保持加密状态。 使用具有安全 enclave 的 Always Encrypted（Intel SGX）在加密列上启用更丰富的查询。

监视并强制实施加密合规性：

  • 通过在订阅或管理组范围内分配“虚拟机应启用主机加密”、“存储帐户应具有基础结构加密”和“应在订阅或管理组范围内启用 SQL 数据库上的透明数据加密”等内置策略来强制使用 Azure Policy 进行加密。
  • 使用 Azure Resource Graph 在环境中查询和清点加密配置，识别没有主机加密的 VM、没有基础结构加密的存储帐户，或者未启用 TDE 的数据库。

注意： 许多 Azure 服务（Azure 存储、Azure SQL 数据库、Azure Cosmos DB）默认在基础结构层启用了静态数据加密，使用服务管理的密钥每两年自动轮换一次。 如果未默认启用加密，请根据技术可行性和工作负荷要求在存储、文件或数据库级别启用加密。

实现示例

一家跨国制造公司在其 Azure 环境中标准化静态加密，以保护 ERP 数据、供应链应用程序和工程商业机密。

挑战： 加密覆盖不一致使得敏感数据容易受到基础结构入侵和快照盗窃的影响。 临时磁盘数据和临时存储保持未加密状态，从而造成合规性差距。 如果没有系统加密强制实施，工程贸易机密和供应链数据可以通过被盗的磁盘、未经授权的快照或泄露的主机代理公开。

解决方案方法：

  • 为 Azure 虚拟机启用主机加密： 在订阅级别注册 EncryptionAtHost 功能，使用支持的 VM 大小（DSv3、Easv4、Dadsv5 系列）为 VM 启用主机加密功能，加密涵盖临时磁盘、OS 磁盘缓存、数据磁盘缓存和临时 OS 磁盘。
  • 为 Azure 存储启用基础结构加密（双重加密）： 验证 Azure 存储服务加密（SSE）是否已启用（默认情况下为 AES-256 加密），以便敏感存储帐户在创建存储帐户期间启用基础结构加密（创建后无法启用），结果：使用不同密钥的 AES-256 加密的两层。
  • 为高度管控的工作负荷部署 Azure 机密 VM： 选择合适的机密 VM 系列（AMD SEV-SNP 的 DCasv5/DCadsv5 系列或 Intel TDX 的 ECasv5/ECadsv5 系列），启用通过平台管理密钥实现的机密磁盘加密（将磁盘加密密钥绑定到 VM 的虚拟 TPM），启用安全启动和 vTPM 进行验证，部署于处理出口管制技术数据或高度管控的 PII 的工作负荷上，其中数据在处理过程中必须保持加密状态。
  • 为敏感数据库列实现 Always Encrypted： 在 Azure SQL 数据库中识别需要列级加密的高度敏感列（如 SSN、CreditCardNumber、MedicalRecordNumber），生成列加密密钥（CEK）和列主密钥（CMK），将 CMK 存储在 Azure Key Vault 中，使用 CEK 加密数据列，CMK 则用于加密 CEK。启用具有安全区域（Intel SGX）的 Always Encrypted，以支持对加密数据进行更丰富的查询。可以使用确定性加密（用于等值查找）或随机加密（用于最大安全性）加密敏感列。配置应用程序连接字符串时，启用“列加密设置=Enabled”以实现透明加密/解密。
  • 使用 Azure Resource Graph 进行清单加密配置： 在不使用基础结构加密的情况下查询没有加密的 VM 和存储帐户的加密状态，将结果导出到 CSV，并将修正任务分配给资源所有者。

结果： 主机级加密解决了之前由于临时磁盘数据未加密而导致的合规性差距。 具有两个加密层的基础结构加密保护工程文件。 通过保密虚拟机 (Confidential VMs)，导出控制的数据即使对于云管理员也仍然保持加密状态。 Always Encrypted 受保护的敏感数据库列 — 数据库管理员确认无法从加密列读取纯文本，以满足符合性要求。

严重性级别

必须具有。

控件映射

  • CIS 控件 v8.1： 3.11
  • NIST SP 800-53 Rev.5： SC-28
  • PCI-DSS v4： 3.5.1、3.6.1
  • NIST CSF v2.0： 公关。DS-1
  • ISO 27001：2022： A.8.24
  • SOC 2： CC6.1

DP-5：根据需要在静态加密中使用客户管理的密钥选项

Azure Policy： 请参阅 Azure 内置策略定义：DP-5。

安全原则

当法规合规性、合同要求或数据敏感度要求直接控制加密密钥生命周期（包括密钥生成、轮换和吊销机构）时，请使用客户管理的密钥。 确保有适当的密钥管理过程来处理运营开销。

待缓解风险

在监管、合同或隔离保证要求租户控制的情况下，完全依赖服务管理的密钥会带来合规性和集中风险。 缺乏适当治理的客户自管密钥（CMK）：

  • 监管保证不足： 如果无法证明密钥的监护权、轮换节奏或吊销权限，审核员可能会拒绝加密控制的证据。
  • 吊销延迟： 无法快速撤销或轮换被攻破的平台密钥，会在凭据或供应链事件后增加暴露风险的窗口。
  • 管辖权暴露： 数据主权要求可能需要租户自营或由 HSM 支持的密钥，如若缺失，将影响区域部署的可行性。
  • 跨租户爆炸半径： 当加密隔离不足时，多租户平台密钥泄露可能会影响广泛的数据集。
  • 影子扩散： 缺乏生命周期治理的零散 CMK 部署会导致过时、孤立或弱小的密钥。
  • 操作脆弱性： 轮换自动化水平较低或缺乏依赖项映射会导致应用程序在密钥更新期间中断。

不当或省略的 CMK 使用会削弱加密保证，并破坏敏感工作负荷的战略合规性定位。

MITRE ATT&CK

  • 凭据访问（TA0006）：由弱保护或不当分段的平台密钥公开的未受保护的凭据（T1552）。
  • 影响（TA0040）：为影响而加密的数据（T1486）利用 CMK 轮换/吊销使数据不可访问。
  • 影响（TA0040）：数据操作（T1565）修改加密状态元数据以使保护层脱同步。
  • 外泄（TA0010）：将数据传输到云帐户（T1537）重新加密并将数据集导出到攻击者控制的存储中。
  • 外泄（TA0010）：通过 Web 服务（T1567）进行外泄，在正常服务模式下协调大量启用了密钥的批量导出。

DP-5.1：根据需要在静态数据加密中使用客户管理的密钥选项

当法规合规、数据主权要求或合同义务需要对加密密钥的保管、轮换时间表和撤销权限进行直接控制时，应实施客户管理的密钥。 对于需要绝对控制权的工作负载（即使 Microsoft 也无法解密数据），请实施双密钥加密（DKE），其中您的组织在 Azure 之外维护第二个加密密钥。 使用 Azure Key Vault 或托管 HSM 来保持加密控制，同时平衡密钥生命周期管理、灾难恢复规划与密钥管理错误可能对服务可用性造成的影响所带来的操作复杂性。

评估 CMK 要求并配置密钥基础设施：

  • 评估法规、合规性或业务要求，以确定哪些工作负载需要 客户管理的密钥（CMK）， 而不是平台管理的密钥。 常见驱动因素包括直接密钥监护的数据主权、审核要求或合同义务。
  • 预配 Azure Key Vault （标准或高级版）或 Azure Key Vault 托管 HSM 以存储和管理客户管理的加密密钥。 对需要 FIPS 140-3 级别 3 验证的硬件保护的工作负荷使用托管 HSM。
  • 使用 密钥生成 功能在 Azure Key Vault 中生成加密密钥，或使用 “自带密钥”（BYOK） 从本地 HSM 导入密钥，以实现最大可移植性和控制性。

配置 CMK 并建立密钥层次结构：

  • 对于极端的控制要求，请实施 双重密钥加密（DKE）， 其中敏感文档需要两个密钥进行解密：一个由 Microsoft （Azure RMS） 管理，另一个密钥由组织在本地或你自己的外部密钥管理服务中独占管理。 使用 DKE 时，即使通过法律程序强制执行，Microsoft 也无法解密您的数据，因为您掌握了解密所需的第二个密钥。
  • 通过引用 Key Vault 密钥 URI 配置 Azure 服务（Azure 存储、Azure SQL 数据库、Azure Cosmos DB、Azure 磁盘加密等）以使用 CMK。 启用 自动密钥轮换 策略以减少手动作负担。
  • 建立 密钥加密密钥（KEK）和数据加密密钥（DEK）层次结构， 其中 KEK（存储在 Key Vault 中）对 DEK（服务使用）进行加密，最大限度地减少密钥轮换对服务可用性的影响。
  • 记录关键生命周期过程，包括密钥轮换计划、泄露密钥的吊销过程、密钥停用工作流和灾难恢复过程。 将密钥管理集成到组织变更管理流程中。

注意： 客户管理的密钥需要持续的作投资，包括密钥生命周期管理、访问控制管理、监视和灾难恢复规划。 在采用 CMK 之前确保作就绪情况，因为不正确的密钥管理可能会导致数据不可用或丢失。

实现示例

受监管的金融机构跨 Azure 服务部署了客户管理的密钥（CMK），以满足对交易数据和客户财务记录的直接加密控制要求。

挑战： 合规审计员要求证明加密控制，包括密钥监护权、轮换权限以及吊销能力。 服务管理的密钥无法提供租户控制的密钥生命周期的证据。 如果没有客户管理的密钥，组织就缺乏在安全事件期间快速撤销访问权限的能力，并且无法满足区域部署的数据主权要求。

解决方案方法：

  • 预配 Azure Key Vault 托管 HSM： 创建已经通过 FIPS 140-3 级别 3 验证的托管 HSM，至少具有 3 个 HSM 分区以确保高可用性。通过导出安全域并使用仲裁密钥激活托管 HSM（这些密钥被拆分为存储在地理分布的离线保管库中的密钥片段）。生成加密密钥（命名为 KEK-Prod-2024 的 RSA-4096），并执行以下密钥操作：包裹密钥、解包密钥、加密、解密。
  • 为 Azure 服务配置客户管理的密钥： 对于 Azure 存储将存储帐户配置为使用 CMK 加密类型，请选择 Key Vault 托管 HSM 作为密钥源，使用托管 HSM 加密服务加密用户角色启用用户分配的托管标识;对于 Azure SQL 数据库，请将 SQL 数据库配置为使用客户管理的密钥作为 TDE 保护程序，从托管 HSM 中选择密钥，启用自动轮换;对于 Azure Cosmos DB，为 Cosmos DB 帐户启用客户管理的密钥，选择“托管 HSM 密钥”，授予 Cosmos DB 托管标识访问权限。
  • 实现自动密钥轮换： 使用 90 天轮换频率配置轮换策略，启用自动轮换，配置过期通知（过期前 7 天警报），为密钥即将过期指标创建 Azure Monitor 警报，以通知安全团队。
  • 为合规性启用审核日志记录：启用托管 HSM 的诊断日志记录功能（AuditEvent 日志），将日志发送到用于分析的 Log Analytics 工作区，并实现日志不可变存储（用于防篡改审核追踪的 90 天保留期），查询密钥访问日志以监视 Encrypt、Decrypt、WrapKey 和 UnwrapKey 操作。
  • 记录关键生命周期过程： 创建紧急吊销操作手册（密钥吊销步骤、事件响应联系人、使用安全域仲裁密钥的恢复过程）、通过桌面推演按季度测试操作手册，将 CMK 操作集成到 IT 服务管理更改审批工作流中。

结果： RSA-4096 KEK 在托管 HSM 中对 Azure 存储、SQL 数据库和 Cosmos DB 的服务级别 DEK 进行加密。 通过仅重新加密 DEK，季度自动轮换可最大程度地减少停机时间。 即使出现完整的区域故障，安全域法定人数也能确保灾难恢复。

严重性级别

应该有。

控件映射

  • CIS 控件 v8.1： 3.11
  • NIST SP 800-53 Rev.5： SC-12、SC-28
  • PCI-DSS v4： 3.5.1、3.6.1、12.3.2
  • NIST CSF v2.0： PR.DS-1、ID.AM-3
  • ISO 27001：2022： A.8.24
  • SOC 2： CC6.1

DP-6：使用安全密钥管理过程

Azure Policy： 请参阅 Azure 内置策略定义：DP-6。

安全原则

实现控制完整密钥生命周期的安全密钥管理过程：生成、分发、存储、轮换和吊销。 使用具有强访问控制的专用密钥保管库服务、维护加密标准、强制分离职责，并确保在泄露时定期轮换密钥并及时撤销密钥。

待缓解风险

弱加密密钥或非托管加密密钥生命周期会降低加密提供的保证，并可能导致系统性泄露。 没有结构化密钥生成、轮换、保护和吊销：

  • 密钥蔓延和孤立： 未跟踪的密钥超出业务需求而仍然存在，意外保留了解密权限。
  • 过时加密： 不频繁的密钥更新会增加算法降级、暴力攻击或侧信道攻击的风险。
  • 权限超额： 缺少角色分离允许管理员既管理又使用密钥，这可能导致内部滥用。
  • 未检测到的漏洞： 缺乏完整性监控或版本记录，掩盖了密钥是否遭到恶意替换。
  • 失败的吊销： 在疑似数据泄露事件后，事件响应无法通过密码学手段阻止数据访问。
  • 层次结构不一致： 缺少 KEK/DEK 分层会扩展旋转爆破半径，并增加停机时间。

缺乏密钥管理将加密转变为时间点控制，而不是针对不断演变的威胁的持续缓解措施。

MITRE ATT&CK

  • 凭据访问（TA0006）：密码存储（T1555）中的凭据，提取存储不当或缓存的密钥材料，或者利用广泛的密钥管理 RBAC 角色来非法访问或轮换密钥的有效帐户（T1078）。
  • 防御逃避（TA0005）：削弱加密（T1600），通过继续使用已弃用的算法或使用不足的密钥大小来降低加密强度。
  • 影响（TA0040）：数据销毁（T1485）进行破坏性清除或处理不当的吊销事件。
  • 影响（TA0040）：数据操纵（T1565）通过替换或更改密钥版本来重定向或禁用加密流。

DP-6.1：建立密钥管理策略和基础结构

通过建立集中式密钥存储、定义加密标准，并根据工作负荷敏感度选择适当的保护级别，为加密密钥管理构建治理基础。 将 Azure Key Vault 部署为密钥操作的单一事实来源，同时实施全面的审核日志记录，以便出于合规和取证目的跟踪所有密钥访问和管理更改。

建立集中式密钥管理基础结构：

  • 使用 Azure Key Vault 作为集中式加密密钥管理服务来控制完整的密钥生命周期：生成、分发、存储、轮换和吊销。
  • 定义并强制实施指定最低加密标准的 密钥策略 ：
    • 键类型： RSA（建议：4096 位或 3072 位最小值）或 EC（P-256、P-384、P-521 曲线）。
    • 关键操作： 根据最低特权原则限制允许的操作（加密、解密、签名、验证、密钥封装、密钥解封）。
    • 有效期： 设置激活和过期日期以强制使用时间绑定密钥。

选择适当的密钥保管库层：

  • 根据工作负荷的安全性和符合性要求选择适当的 Key Vault 层：
    • 受软件保护的密钥（标准 SKU 和高级 SKU）： 已验证 FIPS 140-2 级别 1
    • 受 HSM 保护的密钥（高级 SKU）： FIPS 140-2 级别 2 已验证（共享多租户 HSM 后端）
    • 托管 HSM： FIPS 140-3 级别 3 已验证（专用单一租户 HSM 池）
  • 为了增强安全性，请使用Azure Key Vault 托管 HSM，实现单租户环境下 FIPS 140-3 三级认证的 HSM 保护。 托管 HSM 支持用于备份和灾难恢复的 加密域 。
  • 配置 Azure Key Vault 日志记录，并将日志路由到 Azure Monitor 或 Microsoft Sentinel，以跟踪所有密钥访问、轮换事件和管理操作，以满足审核和合规性要求。

DP-6.2：实现关键生命周期自动化

自动化密钥轮换并建立密钥层次架构，以减少操作负担，最大限度地降低人为错误风险，并支持快速更换密钥，确保服务不受中断。 实现 KEK/DEK 模式，通过重新加密小型密钥捆绑包来替代整个数据集的加密，并集成灾难恢复程序，以维护在区域故障或灾难性事件中密钥的可用性。

实现自动密钥轮换：

  • 在 Azure Key Vault 中实现 自动密钥轮换 策略：
    • 根据符合性要求配置轮换频率（常见间隔：90 天、180 天或每年）。
    • 启用轮换通知，以便在密钥过期前向运营团队发出警报。
    • 配置自动轮换以生成新的密钥版本，而无需手动干预。

建立密钥层次结构和 BYOK：

  • 建立密钥 层次结构 ，分隔密钥加密密钥（KEK）和数据加密密钥（DEK）：
    • 在具有受限访问控制的 Azure Key Vault 中存储 KEK。
    • 生成由 KEK 加密的服务级别 DEK，最大限度地减少密钥轮换的爆破半径。
    • 轮换 KEK 只需要重新加密 DEK（而不是整个数据集），从而在零停机的情况下实现有效的密钥轮换。
  • 对于 “自带密钥”（BYOK） 方案，在本地 FIPS 140-2 级别 2+ HSM 中生成密钥，并使用 BYOK 传输密钥机制安全地将密钥导入 Azure Key Vault 或托管 HSM，从而维护密钥来源和保管的加密证明。

实现灾难恢复过程：

  • 在次要区域创建具有地理复制功能的 Key Vault。
  • 备份和还原密钥，以跨区域保持密钥可用性。
  • 使用定义的 RTO/RPO 目标记录和测试灾难恢复过程。

DP-6.3：强制分离密钥访问职责

通过将密钥管理角色与加密作角色分开来防止内部威胁和特权滥用，确保任何一个标识都无法创建密钥并将其用于数据加密或解密。 实施持续监视以检测异常密钥访问模式，并维护全面的关键清单，以便在安全事件或合规性审核期间进行快速影响评估。

强制职责分离：

  • 实现基于角色的访问控制（RBAC）或访问策略，以强制分离职责：
    • 密钥管理员的单独角色（谁可以创建/轮换/删除密钥，但无法执行加密作）。
    • 为密钥关键用户（可以执行加密/解密操作但无法管理密钥）设置单独的角色。
    • 示例角色：Key Vault Crypto Officer（管理员）、Key Vault Crypto User（应用程序/用户）。
  • 验证没有单个标识同时具有管理密钥和操作密钥访问权限，以防止权限滥用。

监视密钥访问和维护清单：

  • 将密钥访问监视与 Microsoft Sentinel 集成，以检测异常：
    • 异常的密钥访问模式（来自不熟悉的 IP 地址或区域的访问）。
    • 大容量密钥操作（在短时间内进行过多操作）。
    • 非工作时间管理更改（工作时间外密钥删除或轮换）。
  • 维护密钥库存，跟踪密钥的名称、用途、轮换计划和依赖服务。 在安全评审期间定期查看清单。

实现示例

医疗保健 SaaS 提供程序使用 Azure Key Vault Premium SKU 集中管理加密密钥，并在其多租户平台中使用受 HSM 保护的密钥进行 PHI 加密。

挑战： 跨开发团队的零碎密钥管理导致关键蔓延、不一致的轮换做法，以及安全事件期间跟踪密钥使用情况的难度。 过度广泛的 RBAC 权限允许管理员管理和使用密钥，从而造成内部风险。 由于缺乏自动轮换和职责分离，组织面临着密钥泄露窗口期延长和审计合规性失效的问题。

解决方案方法：

  • 使用受 HSM 保护的密钥预配 Azure Key Vault Premium： 使用高级层创建 Azure Key Vault 以支持受 HSM 保护的密钥，启用清除保护以防止在保留期内永久删除，启用具有 90 天保留期的软删除，以允许恢复意外删除的密钥，生成 RSA-3072 受 HSM 保护的加密密钥（KEK-PHI-Prod），并采用硬件支持的密钥类型。
  • 实现自动密钥轮换策略： 使用 180 天轮换频率配置轮换策略，启用自动轮换并将通知设置为过期前 30 天发出警报，创建 Azure Monitor 作组，以便在密钥临近过期时通知安全运营团队，配置轮换操作以自动生成新的密钥版本。
  • 配置 RBAC 职责分离： 将 Key Vault Crypto Officer 角色分配给安全团队成员（权限：管理密钥生命周期，但无法执行加密/解密作），将 Key Vault Crypto User 角色分配给应用程序托管标识（权限：仅执行没有密钥管理权限的加密/解密作），通过确保标识没有加密官员和加密用户角色来验证职责分离。
  • 建立 KEK/DEK 层次结构以快速轮换密钥： 在应用程序代码（AES-256 密钥）中生成应用程序级数据加密密钥（DEK），以加密患者数据、将加密的 DEK 与加密数据一起存储，使用 Key Vault KEK 通过 WrapKey作包装/加密 DEK，在解密患者数据时使用 UnwrapKey作检索和解包 DEK，好处是：轮换 KEK 只需要重新加密 DEK 而不是整个患者数据库。
  • 将 Key Vault 日志与 Microsoft Sentinel 集成： 为 Key Vault 启用诊断设置并将日志发送到 Log Analytics 工作区，创建 Sentinel 分析规则以检测异常的密钥访问模式、批量密钥作、非工作时间的管理更改。
  • 从本地 HSM 自带密钥（BYOK）传输： 从 Key Vault 下载 BYOK 传输密钥，将密钥从本地 HSM 导出并使用 Key Vault 的 BYOK 传输公钥进行包装，维护加密的密钥来源证明，将包装后的密钥导入到 Key Vault，在无明文暴露的情况下到达并受 HSM 保护。

结果： RSA-3072 密钥每 180 天轮换一次自动通知。 RBAC 分离可防止特权滥用。 KEK/DEK 层次结构通过仅对 DEK 进行重新加密来实现快速轮换。 软删除可恢复意外删除的密钥。 Microsoft Sentinel 检测异常，例如不熟悉的 IP 访问或非工作时间修改。

严重性级别

必须具有。

控件映射

  • CIS 控件 v8.1： N/A
  • NIST SP 800-53 Rev.5： IA-5、SC-12、SC-28
  • PCI-DSS v4： 3.6.1、8.3.2
  • NIST CSF v2.0： PR.AC-1、PR.DS-1
  • ISO 27001：2022： A.8.24、A.8.3
  • SOC 2： CC6.1、CC6.2

DP-7：使用安全证书管理过程

Azure Policy： 请参阅 Azure 内置策略定义：DP-7。

安全原则

通过集中流程管理证书生命周期，包括清单、自动续订、强加密标准和及时吊销。 确保在过期前跟踪、监视和续订关键服务的证书，以防止服务中断和维护安全的加密通信。

待缓解风险

管理不善的证书生命周期会导致服务中断、削弱加密通道以及允许模拟。 无需集中清单、策略强制和自动续订：

  • 意外过期： 失效的证书会触发生产中断、中断 API、联合身份验证或客户端信任路径。
  • 弱加密持久性： 旧密钥大小/签名算法（例如 SHA-1、RSA < 2048）仍保留在弃用之外。
  • 通配符和自签名滥用： 范围广泛或未经管理的自签名证书可能导致侧向伪装和传输层安全协议 (TLS) 降级风险。
  • 未检测到的安全漏洞： 被盗的私钥允许透明的中间人攻击或流量解密，直到进行密钥轮换。
  • 影子证书： 在批准的 CA 之外的未经批准的发布破坏了治理，并增加了吊销盲区。
  • 手动续订错误： 不一致的替换排序会导致信任链不匹配和部分环境偏移。

证书管理不足会降低加密保证，并跨关键服务引入可靠性和安全性不稳定。

MITRE ATT&CK

  • 防御逃避（TA0005）：颠覆信任控制（T1553）颁发或引入欺诈/恶意证书以绕过验证。
  • 资源开发（TA0042）：开发功能（T1587）为未来的入侵阶段伪造证书或工具。
  • 防御逃避（TA0005）：削弱加密（T1600）继续使用过时的签名算法，从而减少验证保证。
  • 凭据访问（TA0006）：未受保护的凭据（T1552）从不安全的文件存储或进程内存中提取私钥。
  • 持久性（TA0003）：修改身份验证过程（T1556）重写基于证书的身份验证流以嵌入长期访问。

DP-7.1：建立证书策略和 CA 集成

定义证书治理标准并集成受信任的证书颁发机构，以确保整个基础结构的加密质量和自动颁发一致。 建立策略，强制实施新式密钥大小、签名算法和有效期，同时消除自签名证书和通配符证书等风险做法，从而在私钥遭到入侵时扩展攻击面。

建立证书管理基础结构：

  • 使用 Azure Key Vault 集中管理完整的证书生命周期：创建、导入、续订、轮换、吊销和安全删除。
  • 在 Azure Key Vault 中定义 证书策略 以强制实施组织安全标准：
    • 键类型和大小： RSA 2048 位最小值（建议：3072 位或 4096 位用于长期证书）：EC P-256 或更高版本用于椭圆曲线证书。
    • 签名算法： SHA-256 或更强（禁止 SHA-1 和 MD5）。
    • 有效期： 公共 TLS 证书最多 397 天（每个 CA/浏览器论坛基线要求）：建议缩短持续时间（90 天），以降低暴露。
    • 证书颁发机构： 仅使用批准的集成 CA（DigiCert、GlobalSign）或组织的专用 CA。

集成证书颁发机构：

  • 将与 Azure Key Vault 集成的合作伙伴证书颁发机构用于公共 TLS/SSL 证书：
    • DigiCert： 机构验证型（OV）TLS/SSL 证书
    • GlobalSign： 组织已验证 （OV） TLS/SSL 证书
  • 对于专用/内部服务，请将组织的内部证书颁发机构（例如 Active Directory 证书服务 - ADCS）与 Azure Key Vault 集成，以便自动颁发证书。
  • 避免在生产环境中使用自签名证书和通配符证书：
    • 自签名证书： 缺少第三方验证，不能通过公共 CRL/OCSP 吊销，并且被新式浏览器/客户端拒绝。
    • 通配符证书： 如果被破坏，范围越广，风险越大；请改用包含显式 FQDN 的使用者可选名称 (SAN) 证书。

注意： 对于简单的方案，可以使用 Azure 应用服务托管证书（自定义域的免费自动续订证书）。

DP-7.2：实现自动证书续订

通过自动执行在过期前触发的续订工作流并在依赖服务之间无缝更新证书，而无需手动干预，从而消除由过期证书导致的服务中断。 配置 Azure 服务，以便使用托管标识从 Key Vault 自动检索续订的证书，减少作苦苦，并消除在假日或员工过渡期间忘记手动续订的风险。

配置自动续订：

  • 通过在 Azure Key Vault 中配置生存期作以在指定百分比的证书生存期内触发续订，从而启用 自动证书续订 ：
    • 建议的触发器：有效期的 80-90%（例如，397 天证书的有效期约为 318 天）。
    • 操作：自动续订（Key Vault 请求从 CA 续订，无需手动干预）。
  • 配置通知联系人，以在自动续订触发之前通知管理员即将过期的证书。

启用自动证书绑定：

  • 对于支持自动证书轮换的 Azure 服务（Azure 应用服务、Azure 应用程序网关、Azure Front Door），请将这些服务配置为使用具有相应 Key Vault 访问策略的托管标识或服务主体从 Key Vault 中自动检索更新的证书：
    • 续订时，Azure 服务将自动绑定新的证书版本（通常在 24 小时内，无需重启服务）。
  • 对于无法自动使用 Key Vault 证书的应用程序，请通过运行手册和监视警报实现手动证书轮换工作流，以防止与过期相关的服务中断。
  • 维护 Azure Key Vault 中所有证书的清单，跟踪证书名称、用途、到期日期、依赖服务和续订状态。

DP-7.3：监视证书生命周期并处理吊销

通过自动监控、资产清查和仪表板，持续监测证书的健康状况。这些工具显示出即将过期、使用已弃用加密技术或缺乏妥善管理的证书。 建立已泄露证书的快速吊销过程，并与行业威胁情报集成，在证书中间人攻击之前主动阻止已泄露的证书颁发机构颁发的证书。

配置监视和警报：

  • 为证书过期事件配置 Azure Monitor 警报 ：
    • 在过期前 30 天创建警报（警告通知）。
    • 在过期前 7 天创建警报（这是关键警报，将其升级到安全团队）。

维护证书清单和仪表板：

  • 使用 Azure Resource Graph 查询证书清单：
    • 查询即将过期的证书（在 30/60/90 天内）。
    • 查询自签名证书。
    • 使用已弃用算法（例如 SHA-1）查询证书。
  • 使用可视化效果创建证书审核仪表板（例如 Power BI）：
    • 按时间周期划分的证书过期时间表。
    • 按资源组划分的自签名证书计数。
    • 使用已弃用的加密标准的证书。
  • 在安全评审会议期间定期查看证书审核仪表板（建议：季度）。

建立吊销过程：

  • 为已泄露或停用的证书建立证书吊销过程：
    • 文档吊销过程（禁用 Key Vault 中的证书，通知依赖服务）。
    • 维护证书泄露场景事件响应的运行手册。
    • 监视行业公告，及时拦截已泄露的根证书或中间 CA 证书。

实现示例

一家拥有 200 多个面向公众的 Web 应用程序的企业，使用与 DigiCert 集成的 Azure Key Vault 作为其证书颁发机构进行集中式证书生命周期管理。

挑战： 当证书意外过期时，手动证书续订过程导致多个生产中断。 私钥泄露时，通配符证书会创建过多的爆炸半径。 跨团队的分片证书管理导致影子证书、不一致的加密标准，并在安全事件期间延迟吊销。 如果没有自动续订和集中库存，组织将面临合规性故障和服务中断。

解决方案方法：

  • 配置证书颁发机构与 Azure Key Vault 的集成： 使用 API 凭据将 DigiCert（或其他合作伙伴证书颁发机构）添加到 Key Vault，以便自动证书请求。
  • 创建强制实施安全标准的证书策略： 定义证书策略，使用证书名称（www-contoso-com-2024）、颁发者（DigiCert）、使用者（CN=www.contoso.com）、DNS 名称（SAN: www.contoso.com, api.contoso.com, portal.contoso.com - 避免使用通配符证书）、密钥类型（RSA 4096 位）、签名算法（SHA-256）、有效期（每个 CA/浏览器论坛基线最多 397 天），为自动更新配置生存期操作（在证书生存期的 80% 设置触发器，约为 397 天证书的 318 天左右），操作：自动更新（密钥保管库将向 DigiCert 请求续订，无需人工干预）。
  • 为 Azure 服务配置自动证书绑定： 对于 Azure 应用服务从 Key Vault 导入证书，请使用 Key Vault 机密用户角色分配用户分配的托管标识，启用自动证书更新（应用服务在续订后 24 小时内绑定新证书版本，无需重启）：对于 Azure 应用程序网关配置侦听器以从 Key Vault 检索证书，使用 Key Vault 机密用户和证书用户角色分配用户分配的托管标识，应用程序网关在 Key Vault 续订证书时会自动检索更新的证书。
  • 配置证书过期警报： 在 Azure Monitor 中创建两个警报规则 - 30 天过期警告（向平台工程 Slack 通道发送通知）、7 天过期严重警报（打开 Jira 票证以手动评审并向安全团队发送电子邮件）。
  • 消除通配符证书，改用 SAN 证书： 审核 Key Vault 中的现有通配符证书（*.contoso.com），替换为包含显式 DNS 名称（www.contoso.com, api.contoso.com）的 SAN 证书。这样做的好处是，如果私钥遭到泄露，只有列出的 FQDN 会受到影响（而不是所有子域名）。
  • 监视证书过期时间： 使用 Azure Resource Graph 查询证书清单并识别即将过期的证书（在 30 天内）、自签名证书或使用已弃用的 SHA-1 签名算法的证书，在安全评审会议期间每季度查看仪表板。

结果： 自动证书续订在 80% 有效期触发。 Azure 应用服务和应用程序网关在 24 小时内通过托管标识检索更新的证书（无需重启）。 Azure Monitor 警报在过期前通知平台工程团队。 SAN 证书替换通配符证书，从而减少泄露的爆炸半径。

严重性级别

必须具有。

控件映射

  • CIS 控件 v8.1： N/A
  • NIST SP 800-53 Rev.5： IA-5、SC-12、SC-17
  • PCI-DSS v4： 3.6.1、8.3.2
  • NIST CSF v2.0： PR.AC-1、ID.AM-3
  • ISO 27001：2022： A.8.3
  • SOC 2： CC6.1、CC6.2

DP-8：确保密钥和证书存储库的安全性

Azure Policy： 请参阅 Azure 内置策略定义：DP-8。

安全原则

通过深度防御控制加强密钥保管库服务的安全性：最低特权访问、网络隔离、全面的日志记录和监控、备份和恢复功能，以及在需要时提供 HSM 支持的保护。 密钥保管库是保护用于加密和身份验证的加密密钥和证书的关键基础结构。

待缓解风险

密钥和证书存储库的泄露使上游加密、签名和标识保证失效。 没有强化的保管库访问、监视和隔离：

  • 密钥外泄： 被盗的 KEK /HSM 材料允许批量解密存储的数据和流量拦截。
  • 影子管理访问权限： 过于宽泛的RBAC或策略配置不当可能导致非法密钥导出、清零或版本回滚。
  • 无提示篡改： 恶意密钥替换可实现透明中间人或伪造代码/签名。
  • 网络暴露： 公共终结点的滥用行为（如凭证填充、API 探测）增加了暴力攻击或令牌重播的攻击面。
  • 意外破坏性作： 缺少软删除/清除保护会导致不可逆的加密数据丢失。
  • 审核世系不足： 缺乏不可变日志会损害事件响应和法规证据需求。
  • 未分段租赁： 混合的应用程序密钥在单个身份被盗后扩大了横向攻击扩展范围。

存储库弱点迅速传播到依赖工作负荷的系统性机密性、完整性和可用性故障中。

MITRE ATT&CK

  • 凭据访问（TA0006）：通过配置错误的保管库角色或网络策略获取的未受保护的凭据/凭据存储（T1552/T1555）。
  • 防御逃避（TA0005）：中间人攻击（T1557）捕获用于密钥/证书拦截的保管库流量，或削弱加密（T1600）通过将强密钥替换为由攻击者控制的更弱的密钥。
  • 特权提升（TA0004）：有效帐户（T1078）利用过于广泛的保管库操作员权限来枚举和更改机密。
  • 影响（TA0040）：数据销毁/抑制恢复（T1485/T1490）执行破坏清除序列，防止还原。

DP-8.1：实现 Key Vault 的访问控制

通过强制实施严格的基于标识的访问控制来保护基础结构的加密基础，防止未经授权的密钥访问，将管理权限限制为合理的时间窗口，并通过托管标识消除凭据存储。 实现密钥管理员和密钥用户之间的职责分离，以防止任何单一泄露的标识管理和利用加密材料。

实现 RBAC 并职责分离：

  • 为 Key Vault 实现 Azure RBAC 以强制实施最低特权访问控制：
    • 对于 Azure Key Vault 托管 HSM： 在单个密钥、机密和证书级别使用 本地 RBAC，使用内置角色（包括托管 HSM 加密官、加密用户、加密审核员）。
    • 对于 Azure Key Vault 标准/高级版： 为每个应用程序或环境创建专用保管库，以强制实施逻辑分离，并分配具有特定于应用程序的作用域的 RBAC 角色（Key Vault 管理员、机密官、证书官员）。
  • 强制分离职责：将密钥管理（谁可以创建/轮换密钥）与加密作（谁可以使用密钥进行加密/解密）分开。

使用托管标识和 JIT 访问：

  • 使用 Azure 资源的 托管标识 （应用服务、VM、Azure Functions 等）访问 Key Vault，而不是将凭据存储在应用程序代码或配置文件中。 托管标识消除了凭据存储和轮换复杂性。
  • 实现 Azure AD Privileged Identity Management （PIM）， 以便对 Key Vault 进行实时管理访问：
    • 为 Key Vault 管理员角色配置符合条件的分配（而不是永久分配）。
    • 需要理由说明、MFA 和审批才能激活。
    • 设置最大激活持续时间（例如 8 小时）。
    • 定期进行访问评审，以便于撤销不必要的常驻权限。

DP-8.2：强化 Key Vault 网络安全

通过虚拟网络中的专用终结点路由所有 Key Vault 访问，从而消除暴露于互联网的攻击面，防止凭据填充、暴力破解和来自外部威胁行为者的侦察。 如果 CI/CD 方案无法避免公共访问，请实施严格的 IP 允许列表和防火墙规则，以创建尽可能小的公开窗口。

部署专用链接并配置防火墙：

  • 使用 Azure 专用链接 保护对 Azure Key Vault 的网络访问，以便从 VNet 建立专用连接，而无需向公共 Internet 公开 Key Vault。
  • 配置 Key Vault 防火墙 ，以限制对特定 IP 范围或 VNet 的访问，以便在专用链接不可行的情况下：
    • 尽可能禁用公共访问（Key Vault 只能通过专用终结点访问）。
    • 如果需要公共访问（例如 CI/CD 管道），则仅允许使用窄 IP 允许列表从所选网络进行访问。
  • 创建 专用 DNS 区域并将专用 DNS 区域 （例如） privatelink.vaultcore.azure.net链接到 VNet，以确保专用终结点的 DNS 解析正确。

DP-8.3：启用 Key Vault 保护和监控

实现深层防御保护，通过软删除和清除保护来防止不可逆转的加密数据丢失，并对需要 FIPS 验证安全性的生产工作负荷使用 HSM 支持的密钥。 使用 Microsoft Defender for Key Vault 和 Microsoft Sentinel 部署全面的监视，以检测针对加密基础结构的异常访问模式、异常密钥作和管理异常，这些异常指示泄露、内部威胁或侦察活动。

启用软删除和清除保护：

  • 在所有 Azure Key Vault 上启用 软删除 和 清除保护 ，以防止意外或恶意删除密钥、机密和证书：
    • 软删除允许在保留期内恢复（默认值：90 天）。
    • 清除保护可防止在保留期内永久删除。
    • 使用内置策略通过 Azure Policy 强制实施这些设置：“密钥保管库应已启用软删除”和“密钥保管库应已启用清除保护”（deployIfNotExists 效果）。
  • 实施密钥生命周期策略以避免加密擦除数据：
    • 在清除加密数据之前，请验证加密密钥是否在所需的数据保留期内保留。
    • 退役密钥时，请使用 禁用 操作而不是 删除 操作，以防止意外数据丢失，同时维护密钥元数据以进行审核。
    • 为灾难恢复方案创建和测试 Key Vault 备份 过程。

使用由 HSM 支持的密钥和 BYOK：

  • 对需要强加密保护的生产工作负荷使用 HSM 支持的密钥 ：
    • Azure Key Vault Premium： 由 FIPS 140-2 级别 2 验证的 HSM（共享多租户）保护的 RSA-HSM 和 EC-HSM 密钥。
    • Azure Key Vault 托管 HSM： 由 FIPS 140-3 级别 3 验证的 HSM（专用单租户池）保护的 RSA-HSM 和 EC-HSM 密钥。
  • 对于 “自带密钥”（BYOK） 方案，在本地 FIPS 140-2 级别 2+ HSM 中生成密钥，并使用 BYOK 传输密钥机制安全地将密钥导入 Azure Key Vault，维护密钥来源和保管的加密密钥证明。

启用监视和威胁检测：

  • 为 Azure Key Vault 启用 诊断日志记录，并将日志路由到 Azure Monitor、Log Analytics 或 Microsoft Sentinel，以捕获所有管理平面和数据平面操作。 监视可疑活动，包括异常密钥访问模式、失败的身份验证尝试和管理更改。
  • 启用 Microsoft Defender for Key Vault ，以检测异常访问模式、异常密钥作以及凭据滥用、可疑密钥检索或管理异常等潜在威胁。 将 Defender for Key Vault 警报与事件响应工作流集成。
  • 将 Key Vault 日志与 Microsoft Sentinel 集成，以创建分析规则，用于检测异常情况，例如异常区域访问、潜在的暴力尝试或可疑的管理作。 实现自动化响应剧本来隔离受损的身份并通知安全团队。

注意： 所有 Key Vault SKU 设计都阻止密钥导出;加密作在安全 HSM 边界内执行。 切勿在 Azure Key Vault 外部以纯文本形式导出或存储密钥。

实现示例

一家跨国公司为其 Azure Key Vault 基础结构实现了深层防御安全性，保护 500 多个微服务的加密密钥、API 机密和 TLS 证书。

挑战： 过度广泛的 RBAC 权限允许开发人员直接访问生产 Key Vault，从而造成内部风险和合规性违规。 公共互联网的暴露启用了凭据填充攻击和侦察尝试。 如果不进行全面的监视和自动响应，则未检测到可疑密钥访问模式。 缺少软删除和清除保护可能导致事件期间永久加密数据丢失。

解决方案方法：

  • 部署专用 Key Vault 进行逻辑分段： 为每个环境和商业部门创建 Key Vault，使用命名约定 kv-{businessunit}-{environment}-{region} （例如，kv-finance-prod-eastus2、kv-finance-dev-eastus2），并在每个环境下部署在独立的资源组中以强制实施隔离（泄露的开发服务主体无法访问生产密钥）。
  • 为最低特权访问配置 RBAC： 对于非生产密钥保管库（开发/过渡）将 Key Vault 机密用户（只读）分配给开发人员安全组 - 开发人员可以在开发/暂存中读取机密，但对生产 Key Vault 具有零访问权限;对于生产密钥保管库，请将 Key Vault 机密用户分配到 CI/CD 服务主体（Azure DevOps 管道托管标识），将范围限制为特定的命名机密，无需交互式开发人员访问生产密钥。
  • 使用 Azure 专用链接强化网络安全： 为 Key Vault 部署专用终结点（选择 VNet 和子网，创建专用 DNS 区域 privatelink.vaultcore.azure.net 并链接到 VNet），配置 Key Vault 防火墙（禁用公共访问，令密钥保管库仅可通过专用终结点访问。如果 CI/CD 需要公共访问，则仅允许从选定的网络访问，且这仅限于已批准的 Azure VNet 子网和 CI/CD 代理 IP 地址范围）。
  • 启用 Microsoft Defender for Key Vault： 在订阅级别启用 Microsoft Defender for Key Vault，Defender 监视异常活动，包括异常地理访问、可疑枚举（快速列表操作指示侦察活动）、异常管理操作（批量删除机密信息）。
  • 与 Microsoft Sentinel 集成，实现自动响应： 将 Microsoft Defender for Cloud 数据连接器添加到 Sentinel，为异常区域访问、潜在的暴力破解、可疑的管理操作等创建 Sentinel Analytics 规则，配置自动响应剧本以禁用可疑身份并通知安全团队。
  • 将诊断日志流式传输到 Log Analytics：为 Key Vault 启用诊断日志记录，使用 AuditEvent（所有密钥/机密/证书操作）、AllMetrics（使用频率、延迟），发送到 Log Analytics 工作区并保留 2 年，为异常检测创建自定义 KQL 查询，包括潜在的暴力攻击检测（5 分钟内 10 次未授权尝试），禁用软删除操作（破坏指示器）。
  • 使用 Azure AD PIM 实现按需管理员访问权限： 为 Key Vault 管理员角色配置合格的分配（将安全团队成员添加为合格的非永久性分配，要求激活时提供理由和进行 MFA 验证，设置最大激活持续时间为 8 小时，需高级安全架构师批准），对所有 Key Vault 管理员角色分配进行季度访问评审；撤销不必要的访问权限。

结果： 每个环境的专用密钥保管库强制分段。 RBAC 将开发人员限制为只读非生产环境访问。 Private Link 消除了公共互联网暴露。 Microsoft Defender 检测到异常。 Sentinel playbook 会自动禁用可疑标识。 PIM 支持按需管理员访问权限，显著减少了常驻权限。

严重性级别

必须具有。

控件映射

  • CIS 控件 v8.1： N/A
  • NIST SP 800-53 Rev.5： IA-5、SC-12、SC-17
  • PCI-DSS v4： 3.6.1、8.3.2
  • NIST CSF v2.0： PR.AC-1、PR.DS-1
  • ISO 27001：2022： A.8.3、A.8.24
  • SOC 2： CC6.1、CC6.2
  • Last updated on