用途：本技能针对 Microsoft Purview 的 Customer Key 与双密钥加密（DKE），帮助在合规或主权要求下由客户自持加密密钥。Microsoft 默认已用其管理的密钥对 M365 静态数据加密，这两项控制让受监管客户自行掌握密钥。
主要能力：Customer Key 使用客户提供的根密钥（存于 Azure Key Vault HSM）包装 Exchange、SharePoint、OneDrive、Teams（聊天/文件）及 Purview 的服务数据加密密钥；吊销密钥后 Microsoft 无法解密，实现服务数据路径的加密粉碎。DKE 是敏感度标签驱动的客户端加密，一把密钥由客户自托管密钥发布服务持有，Microsoft 看不到该密钥，服务端功能（搜索、eDiscovery、Copilot）无法读取内容。
使用方式：Customer Key 需在两个独立 Azure 订阅/区域部署 Key Vault，启用 HSM 密钥（RSA 2048+）、软删除与清除保护，恢复级别为 Recoverable+ProtectedSubscription，每服务每区域各建根密钥，创建数据加密策略（DEP）并分配，按年轮换密钥版本，并制定吊销运行手册。DKE 需部署容器化 .NET 服务（Microsoft 发布镜像）于自有环境，通过 HTTPS 供客户端访问，至少两个区域/AZ 保证高可用，按分类而非按文档规划密钥，在 Purview 中编写 DKE 敏感度标签并发布给目标用户组。
适用场景：监管强制持有密钥（金融主权、国防、部分欧盟公共部门）、需要可证明销毁的加密粉碎、以及连 Microsoft 或任何服务端进程都不得读取的最高敏感文档。
限制：Customer Key 丢失两把根密钥即数据不可恢复；软删除与清除保护不可逆；DKE 按设计破坏服务端功能，不可承诺 eDiscovery 或 Copilot；DKE 服务是硬性可用性依赖，故障即文档无法打开；Customer Key 不改变传输加密（仍为 TLS）；吊销影响整个 DEP 范围；两者均为高级许可，需先确认 SKU；HYOK 为旧方案，新架构应选 DKE。常见反模式包括单区域 Key Vault、生产环境测试吊销、对全体高管启用 DKE、DKE 服务单 VM、将 DKE 密钥备份到管理员 OneDrive，以及混淆 Customer Key 与 Customer Lockbox。
参考：Customer Key 概览 https://learn.microsoft.com/purview/customer-key-overview ；DKE 概览 https://learn.microsoft.com/purview/double-key-encryption 。