- 运维系统A 想要 通过口令系统B 查询服务器X口令
- 系统B 根据 IP 判断是否在白名单中，如果是就返回对应的结果
- 假设黑客控制了系统A，只需要系统A 的 IP 不需要业务，就可以通过 系统B 获取所有服务器的口令
所以后台间的身份认证就不能只是基于 IP
后台间身份认证架构
基于用户 Ticket ：适用于安全性高的场景
- 当用户通过 SSO 登录上应用，用户的所有请求都带上对应的 Ticket
- 系统A 向 系统B 发送请求时，除了请求参数，还有就是用户的 Ticket
- 系统B 先根据 Ticket 向 SSO 请求验证 Ticket 是否合法
- 验证成功后，才会根据处理对应的请求，返回对应的结果
如果系统特别多的话，对 SSO 有点压力； 不过设置每个系统的安全级别，如果安全性低，可以不用每次都请求验证，如果安全级别高,可以考虑以这样的方式进行后台间的验证。
基于 APPKey ：适用于安全性一般的场景
APPID: 应用的唯一标识 APPKey: 账号 APPSecret：口令或者秘钥
每个应用可以有多个 APPKey 和 APPSecret, 每个 APPKey 有不同的权限，比如 APPKey1 是只读，APPKey2 是读写等
- 应用1 将和应用2 协商的 APPKey 和 APPSecret 发送给应用2
- 应用2 接收到参数，从数据库中查询是否有对应的值，确认对应的权限
- 应用2 确认后返回给 应用1 对应的 Token 值
Token 有过期时间，超过时间，需要重新获取新的 Token 再次访问
基于 HMAC
HMAC的全称是Hash-based Message Authentication Code（散列运算消息认证码），是加密和HASH算法的结合，可以视为HASH算法的安全加强版。HMAC是不可逆的加密摘要。
- 发送方: 将消息和秘钥 key 进行 HMAC计算 得出 HMAC1, 发送 消息和 HMAC1.
- 接收方: 将接收到消息和秘钥 key 也进行相同的 HMAC 计算得出 HMAC2, 如果 HMC1 不等 HMC2 ，则表示验证失败，否则是成功。
为了防止消息重放，可以在消息上加上时间戳，先校验时间戳是否超时，比如超过 1s，则表示消息重放，不执行对应的消息。然后再通过 HMAC 计算
交互数据安全
基于Ticket 、AppKey架构，后台之间交互的口令、ID 如何保证安全呢？
同上一篇文章《用户身份认证Authenticate》juejin.cn/post/723434…
- 口令本身不要太简单
- 口令加盐加密，因为是后台间的交互，所以不用慢速加盐散列。
基于非对称加密算法
好处：
- 公钥可以在网络上传递，私钥不在网络上传递
- 公钥加密的数据，只能私钥解开；私钥加密的数据，只能公钥解开
缺点：
- 加解密速度慢，只能做少量的加解密，比如 SSL 中的握手确认对称加密的密钥
- 私钥需要特殊的保护
