Wiz Research 披露的 CosmosEscape 并不是一次普通的数据库密钥泄露。攻击链从 Azure Cosmos DB 的 Gremlin 沙箱逃逸，最终获得一个平台级密钥，可读写该服务中的所有数据库。微软在两天内封堵入口，但来源摘要指出，直到 2026 年 7 月才移除该密钥。这个事件真正棘手的地方，在于客户能否通过配置降低风险，以及哪些问题只能由云服务商从架构上解决。
平台级密钥改变了威胁边界
多数团队会把 Cosmos DB 风险建模为“某个账户的密钥被盗”：攻击者拿到连接字符串后，只能访问对应账户。常见补救措施包括轮换密钥、限制公网访问、检查日志并迁移到身份认证。
CosmosEscape 展示的是另一类风险：平台内部存在跨租户、跨数据库的高权限凭据，而攻击链能够越过沙箱边界触及它。此时，客户账户自己的主密钥并不是根因。即使客户定期轮换账户密钥，也无法撤销一个由服务商持有的平台级密钥。
这意味着责任需要按控制面拆开：
- 客户负责身份权限、网络入口、应用凭据和监控告警。
- 云服务商负责沙箱隔离、租户边界以及平台级秘密的生命周期。
- 客户配置可以减少可利用面和后续影响，但不能修复服务内部的隔离缺陷。
因此，“客户本来可以做什么”不能简化为一张安全配置清单。更准确的问题是：哪些措施能阻断攻击链，哪些只能缩短驻留时间，哪些对平台级越权完全无效。
客户侧措施仍然有价值，但要说明边界
关闭不必要的公网访问、减少长期密钥、采用最小权限身份，可以拦截大量常规入侵，也可能限制平台漏洞被利用后的横向路径。不过，这些措施是否能够阻止 CosmosEscape 本身，取决于平台内部请求是否仍受客户网络策略和数据面授权约束；来源摘要没有提供足够细节来作出确定结论。
密钥轮换同样需要分层理解。轮换客户账户的主密钥，可以使泄露的连接字符串失效，却不能使服务商内部的平台级密钥失效。真正的修复必须由微软关闭入口、撤销高权限密钥，并重新设计相应的信任关系。
监控也不是万能答案。如果平台级访问没有进入客户可见的数据面日志，客户无法仅靠 SIEM 证明“未被访问”。事件响应报告应明确区分“没有发现异常证据”和“确认没有发生访问”。
可以这样实践：盘点 Cosmos DB 暴露面
下面脚本不会声称能够修复 CosmosEscape。它用于检查当前订阅中的 Cosmos DB 账户是否仍允许公网访问、是否禁用了本地密钥认证，并在发现高风险配置时返回非零退出码。运行前需要安装 Azure CLI，并通过 az login 登录；如果有多个订阅，请修改 SUBSCRIPTION_ID。
#!/usr/bin/env bash
set -euo pipefail
SUBSCRIPTION_ID="${SUBSCRIPTION_ID:-00000000-0000-0000-0000-000000000000}"
az account set --subscription "$SUBSCRIPTION_ID"
accounts_json="$(az cosmosdb list --output json)"
printf '%s' "$accounts_json" | jq -r '
["ACCOUNT", "RESOURCE_GROUP", "PUBLIC_NETWORK", "LOCAL_AUTH_DISABLED"],
(.[] | [
.name,
.resourceGroup,
(.publicNetworkAccess // "Unknown"),
((.disableLocalAuth // false) | tostring)
]) | @tsv
'
risky_count="$(printf '%s' "$accounts_json" | jq '
[ .[]
| select(
(.publicNetworkAccess // "Enabled") != "Disabled"
or (.disableLocalAuth // false) != true
)
] | length
')"
if [ "$risky_count" -gt 0 ]; then
echo "Found $risky_count Cosmos DB account(s) requiring review." >&2
exit 1
fi
echo "No accounts matched the selected exposure checks."
脚本依赖 jq。Ubuntu 可以执行 sudo apt-get install jq，macOS 可以执行 brew install jq。不要看到检查通过就直接判定环境安全：还应核对私有端点、虚拟网络规则、诊断日志、托管身份和应用权限。
如果应用已经完成基于身份的访问改造，可以这样关闭某个账户的本地密钥认证：
RESOURCE_GROUP="rg-production"
ACCOUNT_NAME="cosmos-production"
az cosmosdb update \
--resource-group "$RESOURCE_GROUP" \
--name "$ACCOUNT_NAME" \
--disable-local-auth true
执行前必须验证所有工作负载、运维脚本和灾备流程都不再依赖连接字符串，否则会直接造成服务中断。不同 Cosmos DB API 对数据面身份认证的支持也应按实际账户类型核对。
重构成本不能只按修复时长计算
两天封堵入口与移除平台级密钥是两类工作。前者可以通过禁用功能、增加检查或部署临时规则完成；后者可能涉及依赖梳理、兼容迁移、凭据替换和跨区域发布。旧密钥存在得越久，潜在影响窗口和审计压力就越大，但仅凭摘要无法判断延迟的具体工程原因。
采用托管云数据库时，可以把以下项目纳入评审：
- 记录哪些安全控制属于客户、云服务商或双方共同负责。
- 优先使用短期身份令牌和最小权限角色，减少长期账户密钥。
- 对公网访问、本地认证和诊断日志建立持续合规检查。
- 在事件响应手册中加入云服务商密钥撤销、取证证据和客户通知流程。
- 要求高权限平台秘密具备轮换、快速吊销和完整审计能力。
CosmosEscape 的核心教训不是“客户配置得还不够多”，而是共享责任必须建立在可验证的技术边界上。客户应该收紧自己能够控制的部分，同时承认并管理那些只能由云服务商消除的平台风险。