隔离的目标是限制单把密钥泄露后的损失上限
把所有策略共用一把全权限密钥，等于任何一个组件出问题，损失范围都是整个账户。隔离要回答的不是「密钥怎么藏」，而是「这把密钥最多能做什么、最多能动多少钱」。判断标准很直接：假设某把密钥今天被完整泄露，攻击者能做的操作和能触及的资金，是否在你事先接受的范围内。如果答案是「整个账户都能动」，隔离就还没有做。
权限按用途拆成只读、交易、提现三档，提现默认不开
多数交易所的 API 权限至少区分读取（行情、余额、订单查询）、交易（下单、撤单）和提现。具体名称和粒度因交易所而异，以其 API 管理页为准。通用做法是：行情采集、回测数据拉取、监控看板只给只读密钥；执行引擎才给交易权限；提现权限对量化场景几乎没有必要，应保持关闭。如果交易所支持合约、杠杆、划转等独立开关，也只开策略实际用到的那一项。需要资金调拨时，走人工操作或独立的、受额外验证保护的流程，不要放进策略进程能访问的密钥里。
子账户和 IP 白名单解决的是不同层面的风险
子账户限制的是资金边界：每个策略或每个资金池放在独立子账户，再给该子账户单独建密钥，策略出现异常下单时，影响面止于该子账户的余额。IP 白名单限制的是调用来源：即使密钥被拿走，来源地址不在名单内也无法调用。两者互补，不能互相替代。要注意，白名单依赖固定出口地址，如果执行节点是动态 IP 的容器或弹性实例，需要先通过固定出口网关解决，否则频繁改名单反而会让人倾向于关掉这个限制。部分交易所不提供子账户或对其有门槛，这种情况下可以用多个独立账户，或降低单账户资金量来补偿。
开发、测试、生产环境不能共用同一把密钥
常见的泄露来源不是黑客攻击，而是密钥被写进代码仓库、日志、截图或测试配置。因此至少拆出三类：开发与回测环境使用只读密钥或交易所提供的测试网密钥；预发布环境使用小额资金的独立子账户；生产环境使用专属交易密钥。密钥存放上，避免写入代码和镜像，优先使用环境变量注入或云厂商的密钥管理服务，并限制谁能读取。日志中对密钥和签名做脱敏，报错信息里也不要原样打印请求头。生产密钥不应出现在任何开发人员的本地机器上。
按策略限频与限额，让异常在平台和程序两侧都有出口
交易所的频率限制通常按密钥或 IP 计算，多个策略共用一把密钥，会让一个策略的重试风暴拖垮其他策略的下单，甚至触发风控封禁。独立密钥可以让限频故障互相隔离。在程序侧，还应在执行层设置单笔上限、单日累计上限和异常撤单开关，不要把风控完全寄托在交易所一侧。这些阈值应该由独立于策略逻辑的模块执行，策略代码不能自行绕过。
出现这些信号时，应立即停用并轮换密钥
以下情况不必等调查清楚，先停用并重建密钥：密钥出现在公开仓库或聊天记录里；交易所后台出现不认识的来源 IP 或调用记录；有人员离职或外包交接结束；服务器或 CI 账号发生入侵嫌疑。处置顺序建议是：先在交易所后台禁用或删除相关密钥，再撤销挂单、核对持仓与余额，然后查日志确认影响范围，最后用新密钥和新的来源限制恢复服务。即使没有事故，也应定期轮换，周期按资金规模和团队变动频率自行设定，并确保轮换流程可以不停机完成，否则没人愿意做。