在接口传输数据时候经常遇到的三种场景：
假设你所在的公司业务是A，公司还有一个业务是B，公司外第三方业务是C这里只考虑http协议
场景1：C需要和A传递数据
场景2：A需要传递数据到第三方C
场景3：业务A和业务B之间传递数据
都是接口的数据传递，对于接口的安全认证机制，比较常用的是basic认证（可爆破），jwt认证（需要交互）、token认证等等。但是要是不用认证呢？怎么保护一个数据的可靠传输？
问题来了，针对这三种场景来设计一个安全的接口需要注意哪些安全问题呢？
先分析场景1：第三方需要把敏感数据传递给业务A
这个场景中是第三方的敏感数据，考虑安全的三要素：机密性、完整性、可靠性
机密性：首先数据不能泄露，保证只有A业务能接收到数据信息，常用的安全方案有加密完整性：保证数据在传输过程中不被外接篡改，常用的https传输协议可靠性：保证只有A业务能收到，并且是经过可靠性验证的，常用的签名保护，IP白名单
这样可以组合一起，解决方案：
方案1：双方通过https、双向IP白名单机制保护通道安全，双方交换随机数，生成一个对称密钥做数据加密，通过hash算法做签名保护？
方案2：双方通过https、双向IP白名单机制保护通道安全，业务C生成公私钥提供个业务A，业务C通过私钥对要传递的数据进行加密，业务A通过公钥进行解密
方案3：双方通过https、双向IP白名单机制保护通道安全，业务A生成公私钥，将公钥给到业务C，业务C用公钥对数据进行加密，然后传给业务A解密
方案4：双方通过https、双向IP白名单机制保护通道安全，在方案2和方案3基础上再增加一个公私钥对，也就是业务A有公私钥，业务C有公私钥，业务C将公钥给到业务A，业务A将公钥给到业务C，业务C通过业务A的公钥对数据进行加密，并且用自己的私钥进行签名，业务A收到后用业务C的公钥进行验签，确定是业务C过来的数据，并且用自己的私钥解密数据。
方案5：双方通过https、双向IP白名单机制保护通道安全，业务C生成公私钥对，将公钥发给业务A，业务A生成对称密钥，通过业务C的公钥加密传递给业务C，业务C通过对称密钥进行数据加密，通过私钥进行签名，业务A收到数据后通过公钥验签，并且通过对称密钥解密出数据
方案6：双方通过https、双向IP白名单机制保护通道安全，业务A生成公私钥，将公钥给到业务C，业务C使用公钥对对称密钥进行加密，传递给业务A，然后利用对称加密对数据进行加密传输，业务A解密数据获取到数据。
对这几个方案来分析下：
在方案2中与公私钥加解密的使用不太一致，是相反的，私钥加密，公钥解密，但是增加了双向IP验证和https之后，该方案感觉并没有问题。但是总是觉得奇怪一些。方案3中是谁接受数据谁生成公私钥对，但是一旦存在多个第三方业务C，例如C1、C2、C3等等，是否需要生成多个公私钥对呢，还是只用一个就可以呢？若是只用一个，数据的来源判断只有通过IP来判断吗？方案4看来比较全面，有签名，有数据加解密，有安全通道等等。这个若是无法做IP白名单和https的话，若是被截获了公钥，攻击者可以作为中间人来发起攻击获取数据的。方案5看起来没啥问题，但是考虑下若是没有https，没有IP白名单的话，是不是数据可以被攻击者获取到，这个方案依赖对称密钥加解密数据，但是攻击者截获业务C的公钥后，是不是可以伪造成业务A了方案6看来也很安全，但是并没有任何用处，为啥不直接用公钥加密数据呢？看起来通过https协议和IP白名单是比较关键的，若是无法做到IP白名单限制，可能方案就得需要重新考虑了
对于场景2呢？我们自己的数据要传递给第三方。是不是还可以按照上面的方案进行呢？
首先方案4肯定是可以的，都是双方生成公私钥对，流程也是一样的
对于数据来说，是我们自己业务的敏感数据，若是业务A生成公私钥，需要把公钥给到业务方，我们用私钥进行数据加密，但是公钥是可以泄露的，这个总觉得是有些奇怪
若是第三方生成公私钥对，将公钥给到业务A，业务A用公钥加密传输数据，这个说起来比较正常，而且对于多个第三方业务来说，只要自己生成公私钥对，把公钥都给到业务A中，业务A根据不同的公钥对数据进行加密，并通过对应的ip发给第三方，第三方用私钥解密出来，这个看起来并没有什么问题
场景3呢，自己公司的不同业务之间的互相调用？对于http协议的是否只考虑内部IP白名单即可？
看来只有具体问题具体分析，不过看来可以总结出一个，谁接收数据谁生成公私钥是不是比较好？
我估计大家看完了，会更加迷惑了
还没有评论，来说两句吧...