有做平台的朋友问我，接口开了给第三方，怎么保证安全？我说先看你的密钥放在哪里，放在代码里的就等于公开了。接口安全，一半靠密钥管得好。
密钥不能硬编码
把密钥直接写在代码里，是接口安全最常见的问题。代码一旦被人看到、被人上传到公开仓库，密钥就等于送出去了。
我们的做法是把密钥放在配置文件或者环境变量里，而且配置文件不进代码仓库。部署的时候单独配置，谁都不许把密钥提交上去。
还有一条，密钥不能出现在日志里。请求日志里带上完整的密钥，等于把钥匙挂在门口，这一点开发时容易疏忽。
权限要分粒度
给第三方的密钥，不该有全部权限。只读的接口给只读的密钥，别提货的也能改你的数据。
我们的建议是按用途分配密钥：查数据的一把、下单的一把，另外还有退款单独一把。哪把出了问题，影响范围可控。
还要能按来源限制。给某个合作方的密钥，可以限定只能从他们的固定 IP 调用。这样即使密钥泄露，别人也用不了。
密钥要能换
密钥用久了要换，出问题更要马上换。换密钥这件事，必须在设计的时候就考虑到。
我们的做法是支持同时有两个有效密钥。新密钥启用后，给对接方一段时间过渡，老密钥再停用。这样换密钥不会让对方停摆。
还有一条是密钥要有记录：什么时候发的、给谁的、什么时候停用。谁在用哪些密钥，心里要有数，别发出去就忘了。
还有一种是密钥泄露之后的补救。真要泄了，先停用那把密钥，再查调用记录，看有没有异常的请求。补救动作要提前想好，出事的时候才不慌。
密钥管理的疑问，一次讲明白
密钥多久换一次
建议一年一换，或者对接方有人员变动时立即换。发现异常要马上换。
能不能只用一个密钥
不建议。不同用途分开用，一个泄露不至于全部受影响。
怎么判断密钥泄露了
看调用日志。异常的调用频率、异常的来源 IP，都可能是密钥被滥用的信号。
常斌定的调子，我们内部一直这么讲：密钥一旦写进代码里，就当它已经泄露了，早点换掉。
先把密钥的规矩定下来
我的建议是在开放接口之前，把密钥的存放、权限，还有更换这三条规矩写清楚。规矩定了，接口开放才不会出事。
我们从 2009 年入行算起，十七年只做这一件事。信服无限接手接口这块时，会把密钥管理当成必查项。真正落地之前，告诉我你的接口要开放给什么类型的合作方。我们按风险给方案，先看你的合作方类型。