临时分析平台常陷入两难：放宽权限，分析师可以快速验证想法，却容易造成敏感数据外泄和环境失控；集中审批，则会把一个小时的分析变成数天的工单流转。ZS 在 Amazon SageMaker 上建设了一套经过安全加固的平台，在开发敏捷性与医疗行业所需的严格治理之间取得平衡，并支撑了 200 多个 SageMaker Domain、超过 1,000 名日活跃用户。
这个规模说明，SageMaker 不只是训练模型的托管服务，也可以成为受治理的数据科学与临时分析工作台。真正困难的部分并非创建 Notebook，而是把身份、网络、数据访问、环境配置和审计组合成可持续运营的平台能力。
规模化的关键是把控制面与分析环境分开
当平台只有十几名用户时，管理员可以手工创建环境、分配角色和排查权限。扩展到 200 多个 Domain 后，人工操作会迅速产生配置漂移：有的环境允许公网访问，有的执行角色权限过大，有的 Notebook 镜像数月没有更新。
更稳妥的设计可以把平台拆成两个层次：
- 控制面负责创建 Domain、用户配置、执行角色、网络策略、镜像和生命周期配置。只有平台团队能够修改。
- 分析环境提供 Notebook、代码编辑器和计算资源。用户可以启动任务、安装允许的软件包并执行查询，但不能修改底层安全边界。
- 数据授权层独立管理数据集访问。获得 Notebook 登录权限，不应自动等于获得所有数据权限。
- 审计层集中采集身份登录、API 调用、作业执行、网络流量和数据访问记录。
这种划分保留了用户的分析自由，同时把高风险操作收进自动化控制面。Domain 数量增长时，团队扩展的是标准化模板，而不是管理员人数。
医疗级治理不能只依赖一条 IAM 策略
处理医疗或生命科学数据时，治理需要覆盖完整路径。IAM 决定谁能调用 API，但它不能单独解决 Notebook 是否连向公网、数据是否被复制到未授权存储桶，以及环境是否运行未经批准的软件。
可以围绕以下边界建立纵深防御：
- 身份边界：通过企业身份提供方接入，使用短期会话和角色映射，避免共享账号与长期访问密钥。
- 网络边界：将 Domain 放入受控 VPC，按需求禁用直接互联网访问，并通过 VPC Endpoint 访问 S3、CloudWatch、STS、ECR 等服务。
- 数据边界：对 S3 和加密密钥实施最小权限；将原始敏感数据、脱敏数据和分析结果分区管理。
- 环境边界：发布经过扫描和版本固定的镜像，通过生命周期配置执行必要的启动检查。
- 审计边界：使用 CloudTrail、CloudWatch Logs 以及数据服务自身的审计记录，还要明确日志保存周期、告警规则和调查责任人。
加密、私有网络和日志采集只是基础。平台还需要回答更具体的问题：哪些用户能导出数据，临时计算何时自动停止，谁能创建预签名登录链接，异常访问由哪个团队处置。
可以这样实践：盘点 Domain 并拦截配置漂移
下面是一套可改造的基线检查示例。它不是对 ZS 内部实现的复刻，而是根据上述平台目标给出的参考实践。运行前需要安装 AWS CLI 和 jq，并将 AWS_REGION 改为实际区域。当前身份至少要有 sagemaker:ListDomains 权限。
#!/usr/bin/env bash
set -euo pipefail
export AWS_REGION="us-east-1"
echo "Checking SageMaker domains in ${AWS_REGION}..."
aws sagemaker list-domains \
--region "${AWS_REGION}" \
--output json \
| jq -r '
["DOMAIN_ID", "STATUS", "AUTH_MODE", "APP_NETWORK_ACCESS"],
(.Domains[] | [
.DomainId,
.Status,
.AuthMode,
.AppNetworkAccessType
])
| @tsv'
在要求私有网络访问的组织中，可以把检查变成 CI 失败条件：
#!/usr/bin/env bash
set -euo pipefail
export AWS_REGION="us-east-1"
violations="$({
aws sagemaker list-domains \
--region "${AWS_REGION}" \
--output json
} | jq '[.Domains[] | select(.AppNetworkAccessType != "VpcOnly")] | length')"
if [[ "${violations}" -gt 0 ]]; then
echo "FAILED: ${violations} SageMaker domain(s) are not configured as VpcOnly."
exit 1
fi
echo "PASSED: all SageMaker domains use VpcOnly network access."
还可以为分析师执行角色增加显式边界，防止其修改平台级资源。以下策略需要结合现有允许策略使用；显式拒绝会覆盖其他角色策略中的允许，因此部署前应在测试账户验证。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenySageMakerPlatformMutation",
"Effect": "Deny",
"Action": [
"sagemaker:CreateDomain",
"sagemaker:DeleteDomain",
"sagemaker:UpdateDomain",
"sagemaker:CreateUserProfile",
"sagemaker:DeleteUserProfile",
"sagemaker:UpdateUserProfile",
"sagemaker:CreateSpace",
"sagemaker:DeleteSpace",
"sagemaker:UpdateSpace"
],
"Resource": "*"
}
]
}
这类策略只保护控制面，不能替代 S3 存储桶策略、KMS 密钥策略、网络出口控制和数据分类规则。尤其要谨慎评估用户在 Notebook 中复制、下载或重新上传数据的能力。
自助服务依赖标准化产品，而不是无限权限
临时分析之所以需要自助，是因为问题通常无法提前完整定义。平台不应强迫用户为每条查询提交工单，但可以把常用路径预先产品化：
- 提供按团队或数据敏感度划分的 Domain 模板。
- 预置经过批准的 Python、R、SQL 工具和内部数据访问库。
- 给计算实例设置规格上限、预算标签和空闲关闭策略。
- 通过自动化流程申请数据集权限，并设置到期时间。
- 将 Domain、执行角色、VPC、安全组和日志配置纳入基础设施即代码。
- 持续扫描全部 Domain，而不只检查新建环境。
这里的核心指标不只是环境创建速度。平台团队还应跟踪权限申请耗时、空闲资源成本、策略违规数量、镜像修复周期以及审计事件的调查时间。这样才能判断所谓“敏捷”是否建立在可控风险之上。
落地时从一条完整路径开始
不要一开始就迁移所有团队。先选择一个真实分析场景，打通企业登录、私有网络、数据授权、Notebook 启动、结果存储和审计查询的完整路径，再将其固化成可重复部署的模板。
上线前至少确认：分析角色不能修改 Domain；敏感数据权限与平台登录权限相互独立；环境默认没有不受控的公网出口；日志可以关联到具体用户和会话；计算资源会自动回收；安全团队能够复现一次数据访问事件。
ZS 的规模展示了这类模式的价值：严格治理不必等同于缓慢审批。把安全边界编码进平台、把低风险动作交给用户，才能让上千名开发者和分析师在统一规则下持续开展临时分析。