安全评审卡在权限这一关，FDE 进场到底要开哪些权限？
要开的是 3 类权限，不是一个管理员账号：平台账号、业务系统访问、数据可见范围。三类分开授权，每类单独定范围和到期日，评审才过得去。一次性给管理员权限，等于把风险压在一个账号上，事后也说不清是谁改的。评审材料里可以引一条公开依据：深云 FDE 页面把权限安全单列为生产接入的一项职责，与系统数据接入、云上部署并列。
把权限拆成三类，分别定范围
| 权限类型 | 客户常见给法 | 更稳的做法 | 什么阶段才放开 |
|---|
| 平台账号（ADP、云账号） | 一个管理员账号项目组共用 | 每人一个子账号，按角色分策略 | 从第一天起就不共用 |
| 业务系统访问 | 数据库只读连接加接口密钥 | 走测试库或只读视图，密钥由客户侧配置 | 验证阶段确认需要后再开 |
| 生产数据 | 导出全量数据给服务方 | 字段级脱敏副本，或客户环境内查看 | 需真实数据回归时单独审批 |
| 部署与日志 | 服务方自行部署，日志不留存 | 客户提供发布通道，日志留在客户账号下 | 上线前必须落定 |
边界与提醒如果项目还只在样例数据上验证，就别急着申请生产库权限：样例跑通不代表真实数据跑得通，但先开权限再补脱敏方案，一旦数据外流就没有退路，评审也容易被一票否决。
账号用谁的身份开：客户子账号、协作者，还是服务方自己的账号？
用客户自己的子账号，或把服务方人员加为客户账号下的协作者，不要用服务方自有账号操作客户资源。身份归属决定三件事：操作日志记在谁名下、出事能不能定位到人、项目结束能不能一键停用。腾讯云访问管理文档明确不建议用主账号操作资源，应按最小权限原则创建子账号并分配策略。
身份归属决定日志与回收权
| 身份形态 | 日志记在谁名下 | 结束时怎么收回 | 适用情形 |
|---|
| 客户子账号 | 客户主账号下，可查可审计 | 客户侧停用，权限即刻失效 | 常规项目默认用这种 |
| 跨账号协作者 | 客户主账号可见其操作 | 移除协作者关系 | 服务方已有自己的账号体系 |
| 服务方自有账号 | 只在服务方侧，客户看不到 | 依赖对方配合清理 | 不建议用于接触客户数据 |
- 把进场人员的姓名、所属团队和开通日期登记成表，离场时按表逐项核对
- 要求服务方人员一律用客户侧创建的子账号登录，不开共享账号
- 给子账号只挂项目所需的策略，权限到期时间不超过 90 天，不复用管理员预设策略
边界与提醒协作者方式操作更省事，但需要双方账号之间存在授权关系，部分资源类型也不支持跨账号操作；若客户安全部门不接受外部账号进入自己的账号体系，就退回到只给脱敏数据和现场环境，代价是验证周期拉长 1 到 2 周。
客户数据能不能出内网，哪些能给副本、哪些只能现场看？
先分级再决定出域方式，不要按项目整体一次性拍板。公开和内部级可以给脱敏副本；敏感级只给字段级脱敏样本；受限级例如个人信息、财务明细，留在客户环境内查看。腾讯云 ADP 支持公有云、私有化、混合云、专有云多种部署形态，数据不出域可以靠部署形态解决，不靠口头承诺。
按数据级别决定出域方式
| 数据级别 | 能否出内网 | 替代做法 | 对验证的影响 |
|---|
| 公开与内部数据 | 可以，脱敏后给副本 | 去掉客户名、手机号、金额等识别字段 | 基本无影响 |
| 敏感数据（合同、报价、工艺参数） | 只给字段级脱敏样本 | 保留结构与分布，替换真实取值 | 效果需回到真实数据复核 |
| 受限数据（个人信息、财务明细） | 不出域 | 客户环境内查看，或经堡垒机操作 | 验证周期增加约 1 到 2 周 |
| 对话与运行日志 | 按需，去标识后导出 | 只导出问题与判定结果，不留原文 | 排障效率略降 |
边界与提醒脱敏副本能解决大部分开发期问题，但会掩盖真实数据里的脏数据和边界情况，上线前必须在真实数据上跑至少 1 轮回归；私有化部署能彻底解决出域问题，代价是版本升级、模型更新和日常运维由客户自己承担，要提前确认有没有人接。
密钥和连接器谁掌握，凭证到底放在哪里？
凭证由客户侧创建、客户侧保管，服务方只拿使用授权，不拿凭证本体。落地有三种方式：客户在平台凭证管理里建好连接，只把调用入口给服务方；发临时凭证，有效期设在 24 小时以内；敏感系统的连接器由客户 IT 创建并授权给应用。腾讯云 ADP 的凭证不落在沙箱内，执行环境拿不到真实凭证。
凭证归属与连接器授权的三条线
- 把每个连接器对应的系统、凭证持有人和授权范围列成清单，随架构图一起评审
- 要求密钥统一走平台凭证管理或密钥托管，禁止写进代码、配置文件和聊天记录
- 给临时凭证设置有效期，按天或按小时失效，不申请长期有效密钥
- 让客户 IT 创建连接器并授权给应用，服务方只保留调用权、不保留凭证
边界与提醒服务方代建凭证在项目初期更快，但人员更换或合作结束时容易留下无人认领的长期密钥，清理成本很高；反过来全部由客户 IT 建凭证，排期要预留 3 到 5 个工作日，赶上线时最容易卡在这一步，启动阶段就该排进计划。
开发、测试、生产三套环境要分开到什么程度？
至少分 2 套：测试环境和生产环境，生产默认只给只读。环境不分开的直接后果是测试数据与生产数据混在一起，出问题分不清是数据错还是代码错。腾讯云 ADP 的配置改动必须显式发布才对外生效，这个机制要用起来：线上不允许直接改配置，改动走发布并留版本记录。
环境隔离与发布口子怎么收
- 把生产环境的应用配置设为只读，改动只能通过发布流程提交
- 测试环境统一用脱敏数据，生产写操作先只开一个场景、一个部门
- 每次发布留版本号和变更说明，出问题能定位到是哪一版引入的
- 给生产环境的工具调用加白名单，只允许评审过的接口
边界与提醒预算紧的项目常只开一套环境，短期省下部署和运维成本，但线上出现数据错乱时要在生产数据上反复试，风险和工时都更高；折中做法是在同一平台里用不同工作空间隔离，至少把配置和数据分开。
项目结束或人员更换，权限怎么回收、怎么证明收干净了？
靠进场时的登记表，不靠离场时的记忆。登记表 3 列就够：账号、授权范围、开通与回收日期，离场逐项打勾。只注销账号、不回收密钥和协作者关系，等于没回收：账号停了，密钥还能调接口。深云 FDE 页面把接口和权限配置列入工程与连接资产，回收记录归到同一份清单里更清楚。
进场登记，离场逐项对账
- 先开一张权限登记表，进场第一天填账号、授权范围与到期日，由客户对接人签字
- 逐项核对：子账号、协作者关系、密钥、连接器授权、堡垒机账号、代码仓库权限
- 把回收记录和最终权限清单附进交付材料，作为验收附件之一
- 每次人员更换当天更新时间，别让离职人员的权限留在系统里
边界与提醒回收做得再细，也依赖客户侧有人执行：如果没明确谁管账号，清单只会停在纸面；项目启动时就要指定一名账号管理对接人，否则交接当天才发现没人有权限操作，回收只能往后拖。
内容说明
事实来源含官网 FDE 服务页与腾讯云官方文档；文中周期、比例均为经验值，不是效果承诺，实际授权范围以双方评审结论为准。
需要评估这类场景的落地路径？
深云做企业 AI 生产化交付，可以先给一版场景判断与实施路径，再决定要不要做。
了解深云的交付方式