Azure Key Vault Managed HSM 的外部密钥管理能力进入公共预览，重点不只是“又多了一个密钥功能”，而是把云上加密密钥的控制权进一步推向企业自己手里。Managed HSM 本身已经提供单租户、FIPS 140-3 Level 3 硬件安全模块，密钥在 HSM 中生成和保存，微软无法访问密钥材料；外部密钥管理的预览，则让那些对主权、合规、职责分离要求更高的团队，有机会重新设计密钥生命周期和访问边界。
这次变化解决的是“谁真正控制密钥”
很多团队上云以后，默认会接受云服务托管密钥的便利性：创建资源、启用加密、交给平台处理。问题出现在受监管行业、跨境数据、政府和大型企业场景里：审计人员问的不是“有没有加密”，而是：
- 密钥材料在哪里生成？
- 谁能使用密钥？
- 云厂商能不能接触密钥？
- 某个业务、区域或团队是否能被单独授权或撤权？
Managed HSM 的回答比较明确：密钥生成并存储在单租户 HSM 中，客户控制访问策略，微软没有密钥材料访问权。外部密钥管理进入公共预览后，值得关注的是它把这种控制模型继续扩展到更严格的密钥治理场景。对于已经在做 BYOK、HYOK、分级密钥管理或本地 HSM 对接的组织，这类能力通常会影响架构基线，而不只是影响某个加密开关。
Managed HSM 和普通 Key Vault 不是同一个取舍
Azure Key Vault 和 Azure Key Vault Managed HSM 都能管理密钥，但它们面向的风险模型不同。Managed HSM 更像是给核心加密根密钥、平台级密钥和高敏感业务密钥准备的隔离边界。
可以从几个问题判断是否需要把密钥放进 Managed HSM：
- 是否要求单租户硬件安全模块？
- 是否明确要求 FIPS 140-3 Level 3 级别的 HSM？
- 是否需要证明云服务提供商无法访问密钥材料？
- 是否有细粒度职责分离，例如安全团队管理密钥，业务系统只能使用特定 key 进行加解密或签名？
- 是否需要为未来的外部密钥管理或更严格主权模型预留空间？
如果答案大多是否，普通 Key Vault 可能更简单、更便宜，也更容易接入。如果答案大多是肯定的，Managed HSM 才是更贴近问题的工具。
可以这样实践：用 Azure CLI 建一个最小 Managed HSM 演练环境
下面示例用于演练 Managed HSM 的基本资源创建和密钥操作。外部密钥管理仍处于公共预览，具体命令、区域和功能开关应以你租户中 Azure CLI 与 Azure 门户实际可见能力为准；这里先把 HSM、权限和密钥使用链路跑通。
运行前需要替换：
SUBSCRIPTION_ID：你的 Azure 订阅 IDOBJECT_ID：将被授予 HSM 管理权限的 Entra ID 用户或组对象 IDLOCATION：支持 Managed HSM 的 Azure 区域HSM_NAME：全局唯一的 Managed HSM 名称
#!/usr/bin/env bash
set -euo pipefail
SUBSCRIPTION_ID="00000000-0000-0000-0000-000000000000"
RESOURCE_GROUP="rg-hsm-preview-demo"
LOCATION="eastus"
HSM_NAME="mhsm-demo-$RANDOM"
ADMIN_OBJECT_ID="00000000-0000-0000-0000-000000000000"
KEY_NAME="app-root-key"
az login
az account set --subscription "$SUBSCRIPTION_ID"
az group create \
--name "$RESOURCE_GROUP" \
--location "$LOCATION"
az keyvault create \
--hsm-name "$HSM_NAME" \
--resource-group "$RESOURCE_GROUP" \
--location "$LOCATION" \
--administrators "$ADMIN_OBJECT_ID"
HSM_URI="https://${HSM_NAME}.managedhsm.azure.net"
az keyvault role assignment create \
--hsm-name "$HSM_NAME" \
--role "Managed HSM Crypto Officer" \
--assignee "$ADMIN_OBJECT_ID" \
--scope "/keys"
az keyvault key create \
--hsm-name "$HSM_NAME" \
--name "$KEY_NAME" \
--kty RSA-HSM \
--size 3072
az keyvault key show \
--hsm-name "$HSM_NAME" \
--name "$KEY_NAME" \
--query "{name:name, keyType:key.kty, operations:key.key_ops}" \
--output table
echo "Managed HSM URI: $HSM_URI"
这个脚本做了三件事：创建资源组、创建 Managed HSM、创建一个 HSM 保护的 RSA key。它不是外部密钥管理的完整生产落地方案，但适合作为团队内部验证权限模型、密钥命名、审计流程和自动化脚本风格的起点。
如果你想把它接入应用，可以先按“应用只使用密钥，不管理密钥”的原则拆分身份。例如，应用托管身份只拿到加密/解密所需角色，安全管理员才拥有创建、轮换、禁用密钥的权限。
应用侧不要把 HSM 当成普通配置中心
Managed HSM 的核心价值是保护密钥材料，不是替代所有 secret 管理。应用接入时，建议把边界画清楚：
- 数据库密码、API token、连接字符串仍应按普通 secret 生命周期管理。
- 根密钥、包装密钥、签名密钥、信封加密使用的 KEK，才更适合放入 Managed HSM。
- 应用代码不应该导出私钥材料，而应调用 HSM 执行加密、解密、签名、验签等操作。
- 权限授予应绑定托管身份或工作负载身份，避免长期凭据。
一个常见模式是信封加密：应用生成数据密钥加密业务数据，再用 HSM 中的密钥包装数据密钥。这样大块数据不直接进 HSM，HSM 负责保护关键密钥链。
下面是一个“可以这样实践”的伪项目结构，用来约束团队分工。它不是 Azure 官方外部密钥管理配置格式，而是适合放进平台工程仓库的治理清单：
# hsm-key-inventory.yaml
# 假设：平台团队用这份清单驱动 Terraform/Bicep/CLI 自动化。
managed_hsm:
name: mhsm-prod-core
purpose: production root encryption keys
administrators:
- group: security-key-admins
key_users:
- identity: app-payments-prod
allowed_keys:
- payments-kek-v1
allowed_operations:
- wrapKey
- unwrapKey
- identity: app-ledger-prod
allowed_keys:
- ledger-signing-v1
allowed_operations:
- sign
- verify
keys:
- name: payments-kek-v1
type: RSA-HSM
size: 3072
rotation_policy: 180d
owner: payments-platform
- name: ledger-signing-v1
type: RSA-HSM
size: 3072
rotation_policy: manual-approval
owner: finance-platform
这类清单的价值不在 YAML 本身，而在于它让安全团队、平台团队和应用团队对“谁能用哪个 key 做什么操作”有共同语言。
采用前的检查清单
公共预览能力适合验证设计，不适合无脑压进关键生产链路。建议按下面顺序推进：
- 确认目标区域、订阅、租户策略是否支持 Managed HSM 以及外部密钥管理预览能力。
- 先跑通 HSM 创建、密钥创建、角色分配、审计日志采集。
- 把密钥管理员和密钥使用者拆成不同 Entra ID 组或托管身份。
- 为每个 key 定义用途、owner、轮换周期、停用流程和应急联系人。
- 在非生产环境演练密钥禁用、轮换、误授权回滚和应用降级路径。
- 评估成本、区域可用性、延迟，以及 HSM 调用失败时业务系统的行为。
Managed HSM 外部密钥管理的公共预览，最值得投入的地方不是马上改造所有加密逻辑，而是把密钥主权从口号变成可审计、可自动化、可演练的控制面。对高合规系统来说，这一步往往比多写一层加密代码更重要。