mcpField
A
azure-confidential-computing

azure-confidential-computing

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

关于 azure-confidential-computing

azure-confidential-computing 是为 Azure 敏感工作负载设计机密计算架构的技能，适用于多方数据协作、受监管场景及敏感 AI 训练或推理。它涵盖可信执行环境、远程证明和基于证明的密钥释放。

主要功能

  1. 01选择机密 VM、AKS 容器或 GPU
  2. 02使用 Azure Attestation 验证 TEE
  3. 03配置密钥安全释放策略
  4. 04规划机密 AI 训练与推理
  5. 05使用机密账本记录审计

适用场景

  1. 01隔离需防云运营方检查的工作负载
  2. 02在多方数据上开展联合分析
  3. 03保护敏感 AI 模型及训练数据
  4. 04为密钥释放设置硬件证明条件

安装

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

$npx skills add https://github.com/vinayaklatthe/microsoft-security-skills --skill azure-confidential-computing

安装后在 Claude Code 中输入/azure-confidential-computing确认已加载。

详细介绍

Azure Confidential Computing

机密计算是数据保护的第三大支柱——使用中的数据—— 它与静态数据加密和传输中加密相辅相成。Azure Confidential Computing 使用基于硬件的 可信执行环境（TEE），使工作负载在加密内存中运行，宿主机（以及 Microsoft）无法检查这些内存；同时通过加密证明，在释放机密信息前，向远程依赖方证明 TEE 的状态。

适用场景

  • 多方数据协作，各方必须基于彼此的数据进行计算，但不能看到对方的数据（数据净室、反欺诈联盟、联合分析）。
  • 受监管的工作负载，要求与云运营商的访问隔离（国防，以及某些金融／医疗保健场景）。
  • 敏感 AI 训练／推理，其中模型权重或训练数据是核心资产。
  • 必须以硬件为信任根，并提供证明证据的加密操作。

以下场景不要使用此技能：普通静态数据 CMK（azure-key-vault）、通用应用加密，或非 Azure TEE／仅使用 Intel SGX 的设计。

部署形式

部署形式硬件最适合的场景
Confidential VMs（DCasv5/ECasv5）AMD SEV-SNP整体 VM TEE 的 Linux/Windows 工作负载迁移
Confidential VMs（DCesv5/ECesv5）Intel TDXVM 的信任域隔离
AKS 上的机密容器Kata Containers + AMD SEV-SNP容器工作负载、按 Pod 提供 TEE
机密 GPU VM（NCC H100 v5）NVIDIA H100 + Intel TDX机密 AI 训练／推理
应用 Enclave（Intel SGX、DCsv2/3）Intel SGX特定用途的 Enclave；属于旧式模式，在新构建中较少使用
Azure Confidential Ledger硬件支持的仅追加账本防篡改审计日志

方法

  1. 验证威胁模型。 机密计算可防范：

    • 云运营商（主机管理员）检查内存。
    • 同租户侧信道读取（在硬件缓解措施的限制范围内）。
    • 快照／磁盘映像外泄与内存转储相结合的攻击。 它无法防范应用程序漏洞、自有代码的供应链攻击，或客户内部人员的访问。

  2. 选择合适的形式。

    • 现有 VM 工作负载需要处理敏感数据，且不想更改代码 → 机密 VM (SEV-SNP) 是最简单的选择。
    • 具有不同敏感级别的 K8s 集群 → AKS 上的机密容器，仅为需要 TEE 的 Pod 启用保护。
    • 机密 GPU（使用敏感数据进行 LLM 训练／推理） → NCC H100 v5。
    • 使用秘密协议进行多方计算 → 使用支持 SGX 的代码（仅在需要比整个 VM 更细粒度的 TEE 时）。

  3. 部署 Microsoft Azure Attestation。 MAA 服务会颁发签名证明令牌，描述 TEE 状态（CPU 型号、固件版本、安全版本）。 依赖方（你的应用、Key Vault）会在信任工作负载前验证这些令牌。

  4. 配置安全密钥释放（SKR）。 Azure Key Vault Premium / Managed HSM 支持密钥释放策略，可要求 release 操作必须通过已验证的 MAA 令牌。工作流如下：

    1. 机密工作负载向 MAA 请求证明。
    2. 工作负载向 Key Vault 出示令牌。
    3. Key Vault 根据已配置的策略进行验证（允许的 TEE 类型、固件版本、所有者身份）。
    4. 密钥被释放到 TEE 内存中。 这是实现“即使是 Microsoft 也无法读取此密钥——只有在正确硬件上运行的正确工作负载才能使用它”的基础。

  5. AKS 上的机密容器 — 使用 Confidential Container 附加组件。 通过支持证明的 init 容器配置 Pod 安全性；Pod 通过证明后，再使用 SKR 获取敏感机密。

  6. 机密 AI 模式。 两种常见形式：

    • 机密推理：模型权重在磁盘上保持加密状态；加载到 TEE 内存中；客户端流量在 TEE 内终止。适用于专有模型。
    • 机密训练：以加密形式上传训练数据；仅向通过证明的训练作业释放密钥；使用数据所有者的密钥加密训练出的模型产物。
    • 多方场景：各方的数据和模型分别位于独立 TEE（或共享 TEE）中；仅在提供通过证明的证据后释放输出。

  7. 高完整性审计（监管日志、IoT 信任）使用 Confidential Ledger。 不要将其用于高吞吐量的常规日志记录——它采用仅追加、区块链支持的方式，延迟更高。

  8. 运维。 监控证明失败（固件漂移、硬件更新）。 定期审查 SKR 策略——安全版本号的要求会随时间收紧。

防护措施

  • 机密计算并非万能解法。 应用安全、供应链卫生和身份管理仍是首要事项。TEE 提高的是抵御主机运营商攻击的门槛，而不是抵御你自身攻击的门槛。
  • 密钥释放策略必须设定安全版本号下限。 否则，过时／存在漏洞的固件也能通过证明并获取密钥。
  • 机密 VM 与常规 VM 在功能上存在差异。 提交前验证快照、备份、ASR、自定义扩展。
  • 性能开销虽小，但确实存在。 内存加密会带来几个百分点的开销；机密 GPU 还有额外开销。请进行基准测试。
  • AKS 中的机密容器需要谨慎设计映像。 不要将机密信息烘焙到映像中；应使用 SKR。
  • 部分区域／SKU 受限。 机密 GPU 和 TDX-VM SKU 并非在所有区域都可用。请按区域制定计划。
  • 不要混淆 Customer Key / CMK 与机密计算。 两者解决的问题不同（静态数据的密钥托管与运行时内存保护）。
  • 证明证据有时效限制。 令牌会过期；请在应用中设计刷新机制。

常见反模式

  • “将机密硬编码在映像中的机密 VM”——TEE 保护的是运行时内存，而不是映像。请使用 SKR。
  • “SKR 策略允许任何未设置固件最低版本要求的 AMD SEV-SNP”——会接受存在漏洞的固件，违背设计初衷。
  • “将机密容器作为通用的‘额外安全’选项”——增加了运维复杂性，却没有带来相称的威胁模型收益。仅用于明确的敏感工作负载。
  • “将机密账本用作只追加日志存储”——吞吐量级别不匹配。应将其用于高完整性、低容量的监管／审计链。
  • “将仅支持 SGX 的设计强行用于整台 VM 的场景”——代码重写成本高；请使用机密 VM。
  • “未经过测试便对机密 VM 执行快照和还原”——工作流可能无法保留对已证明状态的预期；请进行测试。
  • “将机密计算宣传为‘比 CMK 更强的加密’”——这属于不同的控制类别。请准确传达。

示例提示词

  • 设计一个多方欺诈联盟：4 家银行提交加密数据，并在机密 GPU VM 中训练联合模型，密钥仅在通过证明后释放。
  • 将受监管的 Linux 工作负载迁移到机密 VM（SEV-SNP），并验证备份和灾难恢复。
  • 机密 AKS 集群：哪些 Pod 需要 TEE、如何配置 SKR 以提供每个 Pod 的机密，以及证明流程。
  • 配置 Key Vault Managed HSM，并设置基于机密 VM 证明和固件最低版本要求的 SKR 策略。
  • 为我们的工作负载组合比较机密 VM（SEV-SNP）和（TDX）。
  • 为机密 GPU H100 上的专有 LLM 设计机密推理方案。
  • 针对数据主权要求做出选择：客户密钥还是机密计算。

Microsoft Learn

评论

支持 Markdown