云资源、域名和第三方账号建议放在谁名下？

结论：核心账号都应放在客户实际经营主体名下，并由至少两名客户内部管理员掌握恢复方式；滚水科技使用实名子账号和最小权限协作，不共享超级管理员密码。临时代办必须书面约定迁移日期、费用和退出步骤。

账号挂在开发人员或外包公司名下，开发期可能少几次认证配合，但域名续费、支付结算、应用上架、数据迁移和供应商更换都会受制于原经办人。真正重要的不只是“密码现在给了谁”，而是实名认证主体、注册人、合同与发票主体、恢复邮箱和手机号能否由客户持续控制。个人员工账号同样不理想，因为离职、手机号停用或劳动争议都可能让企业失去入口。

在约定交付物、接管方式与责任边界时，还可以对照 你们如何保证系统的安全性？包括数据安全、接口安全、服务器安全？；这些内容补充了需要放在同一项决策中考虑的上下文。

建议按资产逐项确定主体与操作权限：

数字资产	建议注册或签约主体	日常操作方式	交付时必须核验
云服务器、数据库、对象存储与 CDN	客户企业账号	滚水科技使用独立 IAM 子账号或角色	账单、根账号、备份、日志和工单权限均由客户掌握
域名、DNS 与证书	客户企业；注册联系人使用企业可持续邮箱	分配 DNS 或证书管理权限	注册人信息、续费、转移锁、恢复方式和到期提醒
微信小程序、公众号、应用商店	实际运营及持有资质的客户主体	开发者或协作者角色	主体认证、管理员、签名证书、上架材料与版本权限
支付、短信、地图、推送等第三方服务	依法承担业务与结算责任的客户主体	按功能授予 API 和运营权限	合同、余额、配额、回调域名、密钥轮换和停用方法
代码仓库、监控与工单平台	客户组织空间	成员账号按项目分组	仓库所有权、历史记录、告警接收人和离职回收流程

域名尤其不能只看“谁知道登录密码”。ICANN 的 域名注册人资源 说明了注册人通过注册服务机构管理域名并承担相应权利与责任。企业应确保注册人和联系信息真实可维护，恢复邮箱使用公司域名或受控企业邮箱，续费至少配置两名接收人；还要记录注册商、域名到期日、自动续费付款方式、转移锁状态和授权码获取流程。DNS 变更权限可交给技术团队，但域名所有权和账号恢复不应一并交出。

云平台不应多人共用根账号。客户内部保留根账号或最高权限并启用多因素认证，开发、部署、财务和审计使用各自身份；滚水科技只取得完成约定任务所需的角色，生产数据读取、账单管理和删除资源等高风险权限分开审批。NIST 的 零信任架构 SP 800-207 强调不因网络位置或资产归属而默认信任，项目实践中对应到持续验证身份、限制权限和记录操作，而不是“进了公司账号就什么都能做”。

支付、小程序和应用商店账号还涉及资质与业务责任，不能为了上架方便长期借用滚水科技或个人主体。API 密钥应存放在客户控制的密钥管理环境，交接时轮换一次，旧密钥立即撤销；签名证书、私钥和恢复码要加密保管并设置双人接触机制，不能发在群聊或写进源码。供应商人员离场时，应按清单停用账号、撤销令牌、移除设备会话并检查最近登录记录。

如果客户公司尚未设立，概念验证阶段可以使用隔离的测试账号或由滚水科技短期代管非生产资源，但合同必须写明哪些资源是临时的、产生的费用由谁承担、正式主体何时完成认证、历史数据和域名能否迁移，以及逾期如何处理。支付商户、生产个人信息和正式应用上架不宜建立在无法迁出的临时主体上。迁移前还应确认平台是否允许主体变更；若不允许，就要新开客户账号并安排停机或双跑窗口。

一份有效的账号资产清单至少包含平台名称、账号 ID、认证主体、内部负责人、第二管理员、计费方式、续费日、恢复渠道、MFA 保管、滚水科技权限、数据位置、密钥轮换日和退出步骤。验收不能只让客户看截图，而要由客户管理员亲自登录，新增和撤销一个协作账号，查看账单与日志，恢复一份备份，并演练域名解析或密钥轮换。详细的交付原则可参阅 透明交付标准。

滚水科技主张“资产归客户、权限按职责、操作可审计、合作可退出”。这既保留研发效率，也避免客户被账号绑定。