mcpField
P
purview-customer-key

purview-customer-key

github.com/vinayaklatthe安全17842 次安装19 周前更新
代码仓库

关于 purview-customer-key

面向有密钥主权或高敏感文档保护要求的组织，讲解 Microsoft Purview Customer Key 与 Double Key Encryption（DKE）的设计和运维。它对比租户范围的服务端密钥控制与按文档应用的客户端加密，并说明各自对服务功能的影响。

主要功能

  1. 01比较 Customer Key 与 DKE
  2. 02规划 Azure Key Vault 根密钥
  3. 03设计数据加密策略与密钥轮换
  4. 04部署并维护 DKE 服务
  5. 05规划密钥撤销和恢复流程

适用场景

  1. 01满足监管机构的密钥托管要求
  2. 02通过撤销密钥实现加密销毁
  3. 03保护不应被服务端读取的敏感文档
  4. 04评估 DKE 对搜索和 eDiscovery 的影响

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/vinayaklatthe/microsoft-security-skills --skill purview-customer-key

安装后在 Claude Code 中输入/purview-customer-key确认已加载。

详细介绍

Microsoft Purview 客户密钥与双密钥加密

Microsoft 已使用 Microsoft 管理的密钥对静态存储的 M365 数据进行加密。这些额外控制措施让受监管或对主权有要求的客户能够自行持有密钥：

  • 客户密钥 — 客户提供的根密钥（位于 Azure Key Vault HSM 中）用于包装 Exchange、SharePoint、OneDrive、Teams（聊天/文件）和 Purview 的服务数据加密密钥。撤销密钥 → Microsoft 将无法再解密 → 服务数据路径会被加密擦除。
  • 双密钥加密（DKE） — 由敏感度标签驱动的客户端加密，其中一个密钥由客户在自托管密钥释放服务中持有。Microsoft 永远不会看到该密钥；服务端功能（搜索、电子数据展示、Copilot）无法读取内容。

本技能涵盖这两种方式——何时使用哪一种、架构以及实际运维情况。

适用场景

  • 监管要求持有加密密钥（金融行业主权要求、国防、部分欧盟公共部门）。
  • 加密擦除要求（通过撤销密钥实现可验证的销毁）。
  • 对敏感度最高的文档进行保护，使 Microsoft 或任何服务端进程即使暂时也无法读取。

请勿将此技能用于 Azure 资源加密（azure-key-vault）、通用敏感度标签推广（purview-information-governance）或 GRC 框架（compliance-manager）。

客户密钥与 DKE — 审慎选择

功能客户密钥DKE
范围所选 M365 服务中的所有数据按文档逐个应用，由标签驱动
加密位置服务端，透明进行客户端，上传前
Microsoft 能读取内容以提供服务功能吗？可以（直到密钥被撤销）不可以
电子数据展示、搜索、Copilot、DLP 能处理内容吗？可以不可以
密钥保管Azure Key Vault HSM（客户订阅）客户托管的密钥释放服务（本地或你的云）
能否通过撤销密钥进行加密擦除？可以（整个服务范围）可以，通过销毁密钥逐个处理文档
使用场景主权要求、监管机构的全面要求仅限最重要的文档

经验法则： 客户密钥适用于整个租户的主权要求。DKE 适用于必须对内部跨租户功能也保持不透明的 0.1% 文档（董事会会议记录、并购草案、武器设计）。

方案

客户密钥

  1. 预配 Azure Key Vault，分别部署在两个独立的 Azure 订阅/区域中（成对使用）。 必需设置：

    • 基于 HSM 的密钥（RSA 2048+）。
    • 启用软删除，启用清除保护（否则客户密钥入门流程会拒绝继续）。
    • 恢复级别：Recoverable+ProtectedSubscription。
    • 将诊断日志发送到专用的长期保留 Log Analytics 工作区。

  2. 为每项服务创建两个根密钥——每个区域一个。M365 需要两个密钥均可用于包装/解包。丢失一个密钥仍可恢复；两个都丢失则会导致不可恢复的加密擦除。

  3. 为每项服务创建数据加密策略（DEP）（Exchange/SharePoint 等），并引用这两个根密钥。将 DEP 分配给租户或单个邮箱/网站（Exchange 支持按邮箱分配；SharePoint 在该地理区域内按租户分配）。

  4. 轮换密钥，每年一次（或按策略要求），方法是添加新密钥版本；Microsoft 会自动重新包装。只要旧版本仍可能在使用，就绝不要删除。

  5. 撤销操作手册（核心所在）。 明确记录：由谁授权、执行什么命令、通知谁，以及对客户的影响。先在非生产租户中演练撤销。只有实际撤销才能实现加密擦除——请确保具备相应治理措施。

  6. 监控。 对 Key Vault 访问策略、密钥权限或 M365 服务主体分配的任何变更发出警报。

双密钥加密

  1. 确定文档范围。 DKE 会影响这些文档的搜索、DLP、Copilot 和电子数据展示。请将范围限制在一个规模较小、定义明确的集合内。

  2. 部署 DKE 服务。

    • 容器化的 .NET 服务（由 Microsoft 发布的映像）。
    • 托管在你自己的环境中（本地、AWS、GCP，或 M365 租户之外的 Azure）。
    • 最终用户客户端可通过 HTTPS 访问；使用客户端证书或通过 IdP 进行 OAuth 授权。
    • 高可用性：至少部署在两个区域/AZ。服务中断 = 用户无法打开受 DKE 保护的文档。

  3. 生成并加载密钥。 每个 DKE 标签都指向服务中的一个密钥。应按分类规划密钥，而非按文档规划（否则运维负担过重）。

  4. 在 Purview 中创作 DKE 敏感度标签，选择 DKE 加密选项并填写服务终结点 URL。

  5. 向目标用户组发布标签（法务、并购、董事会等）。用户会在 Office 中看到新的标签选项；应用该标签后，客户端会通过 DKE 服务触发加密。

  6. 以书面形式向用户说明权衡。 无法搜索、无法获取 Copilot 摘要、无法进行第三方扫描，也无法自动转录带有 DKE 标签的文档。

  7. 严格保管 DKE 密钥的备份。 丢失 DKE 密钥 = 永久丢失所有受该密钥保护的文档。

防护措施

  • Customer Key + 两个根密钥均丢失 = 数据丢失。 Microsoft 无法恢复。应像保管 HSM 根密钥一样严格保管这些密钥。
  • 软删除和清除保护是强制要求，且不可撤销。 提前规划 Key Vault 治理。
  • DKE 会按设计影响服务端功能。 不要承诺可对 DKE 内容进行电子数据展示或使用 Copilot。
  • DKE 服务是可用性的硬性依赖。 服务中断 = 文档访问中断。必须具备高可用性、监控和待命支持。
  • Customer Key 不会以不同方式加密传输中的 Microsoft 数据——传输仍使用 TLS。Customer Key 用于控制包装密钥，而非更改传输加密方式。
  • 通过撤销 Customer Key 进行密码学销毁会影响整个 DEP 范围。 这是个粗放的手段；如果涉及多租户，请与法务和客户协调。
  • 这两种控制都需要高级许可证。 确定范围前，请确认 SKU 和附加组件。
  • HYOK（Hold Your Own Key，基于 AD RMS） 是 DKE 的早期前身；Microsoft 当前的前瞻性指导是使用 DKE。不要为新的 HYOK 方案做架构设计。

常见反模式

  • “在单个区域使用一个 Key Vault 来部署 Customer Key”——单点故障 = 服务中断。始终使用两个区域。
  • “在生产环境中撤销 Customer Key 来‘测试’”——这曾导致整个租户的服务数据中断；恢复需要联系 Microsoft。只能在测试租户中演练。
  • “对每位高管的邮箱都启用 DKE”——整个用户群体的电子数据展示请求都会失败。请谨慎使用。
  • “将 DKE 服务部署在单个 VM 上”——服务中断 = 用户无法打开最敏感的文档。
  • “在内部将 Customer Key 宣传为‘额外加密’”——它是密钥保管控制，而非更强的加密。应说明其实际价值（撤销、数据主权）。
  • “将 DKE 密钥备份到管理员的 OneDrive”——这会彻底破坏整个模型。
  • “混淆 Customer Key 和 Customer Lockbox”——它们是不同的产品。Customer Lockbox = 审批 Microsoft 工程师的访问；Customer Key = 密钥保管。

示例提示词

  • 为 Exchange Online 和 SharePoint 规划 Customer Key 部署，适用于多地域租户——设计 Key Vault 拓扑和 DEP。
  • 编写 Customer Key 撤销操作手册，包含授权步骤和对客户的影响。
  • 为 12 位董事使用的董事会会议纪要设计 DKE——服务架构、高可用性和用户沟通。
  • 针对金融监管机构的数据主权要求，比较 Customer Key 与 DKE。
  • 制定 Customer Key 密钥轮换计划，并提供 ISO 27001 审计证据。
  • 创作 DKE 标签并在法务部门的 5 位用户中试点；找出受影响的工作流。
  • 估算在 1% 的 SharePoint 内容中采用 DKE 的成本和运维影响。

Microsoft Learn

评论

支持 Markdown