在算力中心中，一台 GPU 服务器可能同时服务多个团队：算法组在跑训练，业务组在做推理验证，外部合作方通过 API 调用模型。在这种混部环境下，数据安全与权限管理不是可选项，而是防止事故的最后一道防线——一旦出现模型权重泄露、训练数据被越权访问或用户隐私曝光，损失可能远超硬件采购成本。
本节聚焦三个核心环节：多租户隔离、数据加密、访问控制，给出可直接落地的方案与检查清单。
一、多租户隔离：谁的数据归谁
1. 隔离的四个层级
多租户隔离必须贯穿网络、存储、计算、身份四层，缺任何一环都会留下旁路风险。
| 层级 | 目标 | 典型实现 |
|------|------|----------|
| 网络隔离 | 阻止跨租户的非法网络访问 | VLAN/VxLAN 划分、Kubernetes NetworkPolicy、防火墙规则 |
| 存储隔离 | 确保训练数据、模型权重、日志互不可见 | 独立文件系统卷、Ceph/GlusterFS 租户命名空间、JuiceFS 目录级权限 |
| 计算隔离 | 防止 GPU 显存逃逸、容器逃逸、进程间干扰 | 容器化（Docker）+ GPU 虚拟化（MIG/NVIDIA vGPU）、独立 Pod 调度 |
| 身份与凭证隔离 | 每个租户拥有独立的账号体系和密钥，避免凭据共享 | LDAP/OIDC 集成、每个租户独立的 ServiceAccount、命名空间级别的 RBAC |
2. 实用的隔离策略
- 物理隔离（最强）
为高安全等级租户（如金融、政务）分配独立的 GPU 服务器或整机柜，不共享任何硬件资源。
- 逻辑隔离（最常用）
利用 Kubernetes 的 Namespace 对 Pod、Service、Secret 做资源隔离。每个租户分配独立 Namespace，配合 ResourceQuota 限制 CPU/内存/GPU 使用量，防止资源争抢。
- GPU 实例级隔离
NVIDIA MIG（Multi-Instance GPU）可将一张 A100/H100 物理切分为多个独立实例，每个实例拥有固定的显存、缓存和计算单元。即使两个 Pod 共享同一张 GPU，也无法互相访问显存。这是目前推荐的高密度多租户方案。
检查清单：
- [ ] 能否保证租户 A 的 Pod 无法 ping 通租户 B 的 Service IP？
- [ ] 是否启用了 NodeRestriction 和 PodSecurityPolicy/PodSecurity 准入控制，防止特权容器挂载宿主机路径？
- [ ] 对于敏感租户，是否配置了 GPU MIG 或指定 nodeSelector 绑定专属节点？
- [ ] 共享存储的权限位（755/750）是否按组划分，确保其他租户无读权限？
二、数据加密：静默态与传输态双保护
算力中心的数据生命周期包含三个加密窗：存储（at rest）、传输（in transit）、使用（in use）。前两者成本可控，必须落地；后者（机密计算）成本高昂，按需采纳。
1. 存储加密（At Rest）
- 模型权重加密：权重文件在分布式文件系统中以密文保存，仅训练节点通过挂载加密卷访问。可使用 LUKS 磁盘加密，或存储端加密（如 Lustre 加密、对象存储的 SSE-KMS）。
- 训练数据加密：原始语料、标注数据使用 AES-256 加密存储。密钥由 KMS（密钥管理服务）统一管理，禁止硬编码在脚本或镜像中。
- Checkpoint 加密：断点续训的模型快照同样加密，防止被窃取后进行参数逆向。
实用方案：在集群中搭建 Vault（HashiCorp Vault）或使用云厂商 KMS，配合 CSI（容器存储接口）Secret Store 驱动，实现自动化的加密卷挂载。
2. 传输加密（In Transit）
- 数据面通信：所有分布式训练通信（NCCL/RabbitMQ/ gRPC）应在 InfiniBand 或 RoCE 网络上启用 IPsec 或链路层加密。对于跨机房/跨地域数据传输，必须使用 TLS 1.3 隧道。
- 管理面通信：API 网关（如 Kubernetes apiserver）启用 TLS，禁用匿名访问；节点 SSH 仅允许密钥登录，且密钥定期轮换。
- 镜像拉取：私有仓库通过 HTTPS 服务，拉取凭证过期自动回收。
3. 使用态加密（Confidential Computing）
当需要保护正在训练 / 推理中的数据和模型（例如，租户不希望平台管理员看到显存中的明文），可以使用基于硬件的 TEE（可信执行环境），如 Intel SGX、NVIDIA Confidential Computing（H100 配合 AMD SEV-SNP 或 Intel TDX）。但这会带来显著的性能下降（约 5%-15%），且适配成本高，目前主要用于对合规有极端要求的场景。
三、访问控制：最小权限，持续审计
1. 认证（你是谁）
统一使用企业级身份源（LDAP、OIDC、SAML），避免本地账号。每个用户、服务账号、自动化脚本都应拥有唯一身份，并强制多因素认证（MFA）。
- 用户认证：DevOps 工程师、数据标注员、模型评估员通过 SSO 登录跳板机或 JupyterHub；
- 服务认证：训练任务的 ServiceAccount 绑定 RBAC，拥有只够读取自己的数据集和输出目录的权限；
- API 认证：对外部 API 消费者，分配独立的 API Key 或 JWT Token，按用途和频率分权。
2. 授权（你能做什么）
遵循最小权限原则（Least Privilege），即默认拒绝所有，只显式开放必要操作。
- 文件系统权限：
数据集目录：owner=租户组:r--（只读）
代码目录：owner=租户组:r-x（可读执行，禁止随意修改）
输出目录（权重、日志）：owner=租户组:rwx（全权）
公共基础镜像/环境：owner=admin:r-x（全局只读）
- Kubernetes RBAC：
为每个租户创建 Role（命名空间内）和 RoleBinding，禁止 list/secrets、delete/pods 等危险操作。生产 Namespace 禁止用户创建 Privileged Pod。
- 数据库/对象存储桶策略：
对不同 bucket 设置 IAM 策略，仅允许特定服务账号的读写操作，跨租户默认隔离。
3. 审计（你做了什么）
所有敏感操作必须留痕：
- 在 Kubernetes API 审计日志中记录谁、何时、对哪个资源执行了什么操作；
- 存储系统记录文件访问和删除日志，特别是模型权重文件下载；
- 训练平台（如 MLflow、Kubeflow）记录每次实验的参数、数据路径、执行者；
- 配置告警规则：如短时间内大量下载模型文件、非工作时间的高权限操作、多次失败登录尝试等，应有实时告警通知安全管理员。
4. 特别注意：大模型特有的风险
- 模型逆向攻击：攻击者通过大量调用推理 API，可能用模型输出还原训练数据中的隐私。应该实施推理频率限制、输出内容过滤（脱敏、关键词拦截）和差分隐私保障。
- 提示注入与越狱：外部租户通过精心构造的 Prompt 可能绕过安全限制。在 API 网关层集成内容安全策略，过滤危险指令，并限制模型系统 prompt 的可见性。
- 模型权重泄露：任何一次非授权下载都可能是灾难性的。权重文件应单独存储在加密卷，CI/CD 流程中不暴露明文凭据，废弃节点销毁前使用 DoD 标准擦除磁盘。
四、落地路线图
对于中小规模集群（几十卡），可以先从以下配置开始：
- 基础设施：所有节点加入统一身份域，搭建 Kubernetes + NetworkPolicy + 命名空间隔离。
- 存储：为每个租户创建独立的 CephFS subvolume 或 JuiceFS 目录，权限 750。
- 认证：集成 OIDC 到 JupyterHub、SSH 和 API 网关，关闭密码登录。
- 加密：存储卷启用 LUKS，网络使用 TLS，KMS 管理密钥。
- 监控：开启 Kubernetes 审计日志，接入 ELK/Splunk，配置基础告警。
随着规模扩大（百卡以上），逐步引入 MIG、机密计算、自动化密钥轮换和基于行为的异常检测系统。
安全是算力中心的生命线，没有它，所有的规模、性能和成本优化都等于零。将本节内容与第 20 章的环境搭建、第 21.1 节的日常运维结合，可形成从规划到运营的全闭环。