保证接口数据安全的十种方案
前言
大家好呀 ，保证我是接口捡田螺的小男孩 。
我们日常开发中 ，数据如何保证接口数据的安全安全性呢 ？个人觉得 ，接口数据安全的保证保证过程 ，主要体现在这几个方面：一个就是接口数据传输过程中的安全 ，还有就是数据数据到达服务端 ，如何识别数据 ，安全最后一点就是保证数据存储的亿华云安全性 。今天跟大家聊聊保证接口数据安全的接口10个方案 。
1.数据加密，数据防止报文明文传输 。安全
我们都知道 ，保证数据在网络传输过程中，接口很容易被抓包 。数据如果使用的是http协议 ，因为它是明文传输的 ，用户的数据就很容易被别人获取 。云计算所以需要对数据加密。
1.1 数据如何加密呢 ？常见的实现方式 ，就是对关键字段加密。比如 ，你一个登录的接口 ，你可以对密码加密 。一般用什么加密算法呢 ？简单点可以使用对称加密算法（如AES）来加解密 ，或者哈希算法处理（如MD5） 。
什么是对称加密 ：加密和解密使用相同密钥的加密算法 。
非对称加密 ：非对称加密算法需要两个密钥（公开密钥和私有密钥）。公钥与私钥是服务器租用成对存在的 ，如果用公钥对数据进行加密 ，只有对应的私钥才能解密 。
更安全的做法 ，就是用非对称加密算法（如RSA或者SM2） ，公钥加密 ，私钥解密 。
如果你想对所有字段都加密的话 ，一般都推荐使用https协议。https其实就是在http和tcp之间添加一层加密层SSL 。建站模板
1.2 小伙伴们，是否还记得https的原理呢 ？面试也经常问的 ，如下 ：
客户端发起Https请求，连接到服务器的443端口 。
服务器必须要有一套数字证书（证书内容有公钥 、证书颁发机构、失效日期等）。
服务器将自己的数字证书发送给客户端（公钥在证书里面 ，私钥由服务器持有） 。
客户端收到数字证书之后 ，会验证证书的香港云服务器合法性 。如果证书验证通过，就会生成一个随机的对称密钥 ，用证书的公钥加密 。
客户端将公钥加密后的密钥发送到服务器 。
服务器接收到客户端发来的密文密钥之后 ，用自己之前保留的私钥对其进行非对称解密，解密之后就得到客户端的密钥 ，然后用客户端密钥对返回数据进行对称加密 ，酱紫传输的源码库数据都是密文啦 。
服务器将加密后的密文返回到客户端 。
客户端收到后 ，用自己的密钥对其进行对称解密 ，得到服务器返回的数据 。
日常业务呢 ，数据传输加密这块的话 ，用https就可以啦，如果安全性要求较高的，比如登陆注册这些 ，需要传输密码的 ，密码就可以使用RSA等非对称加密算法 ，对密码加密 。如果你的业务 ，安全性要求很高 ，你可以模拟https这个流程 ，对报文 ，再做一次加解密 。
2. 数据加签验签
数据报文加签验签，是保证数据传输安全的常用手段 ，它可以保证数据在传输过程中不被篡改。以前我做的企业转账系统 ，就用了加签验签 。
2.1 什么是加签验签呢？数据加签 ：用Hash算法（如MD5 ，或者SHA-256）把原始请求参数生成报文摘要 ，然后用私钥对这个摘要进行加密 ，就得到这个报文对应的数字签名sign（这个过程就是加签） 。通常来说呢，请求方会把数字签名和报文原文一并发送给接收方 。
验签 ：接收方拿到原始报文和数字签名（sign）后 ，用同一个Hash算法(比如都用MD5)从报文中生成摘要A 。另外 ，用对方提供的公钥对数字签名进行解密 ，得到摘要B，对比A和B是否相同，就可以得知报文有没有被篡改过 。
其实加签 ，我的理解的话 ，就是把请求参数 ，按照一定规则，利用hash算法+加密算法生成一个唯一标签sign。验签的话，就是把请求参数按照相同的规则处理 ，再用相同的hash算法 ，和对应的密钥解密处理 ，以对比这个签名是否一致 。
再举个例子 ，有些小伙伴是这么实现的 ，将所有非空参数（包含一个包AccessKey ，唯一的开发者标识）按照升序 ，然后再拼接个SecretKey（这个仅作本地加密使用 ，不参与网络传输，它只是用作签名里面的） ，得到一个stringSignTemp的值 ，最后用MD5运算，得到sign 。
服务端收到报文后，会校验 ，只有拥有合法的身份AccessKey和签名Sign正确，才放行 。这样就解决了身份验证和参数篡改问题，如果请求参数被劫持 ，由于劫持者获取不到SecretKey（仅作本地加密使用 ，不参与网络传输） ，他就无法伪造合法的请求啦
2.2 有了https等加密数据 ，为什么还需要加签验签有些小伙伴可能有疑问，加签验签主要是防止数据在传输过程中被篡改 ，那如果都用了https下协议加密数据了 ，为什么还会被篡改呢？为什么还需要加签验签呢 ？
数据在传输过程中被加密了 ，理论上，即使被抓包 ，数据也不会被篡改 。但是https不是绝对安全的哦 。可以看下这个文章 ：可怕 ，原来 HTTPS 也没用 。还有一个点：https加密的部分只是在外网 ，然后有很多服务是内网相互跳转的 ，加签也可以在这里保证不被中间人篡改 ，所以一般转账类安全性要求高的接口开发，都需要加签验签
3.token授权认证机制
日常开发中 ，我们的网站或者APP ，都是需要用户登录的 。那么如果是非登录接口 ，是如何确保安全，如何确认用户身份的呢？可以使用token授权机制 。
3.1 token的授权认证方案token的授权认证方案 ：用户在客户端输入用户名和密码 ，点击登录后 ，服务器会校验密码成功 ，会给客户端返回一个唯一值token ，并将token以键值对的形式存放在缓存（一般是Redis）中 。后续客户端对需要授权模块的所有操作都要带上这个token ，服务器端接收到请求后 ，先进行token验证 ，如果token存在 ，才表明是合法请求。
token登录授权流程图如下 ：
我们如何保证token的安全呢 ？
比如说，我如果拿到token，是不是就可以调用服务器端的任何接口 ？可以从这几个方面出发考虑 ：
token设置合理的有效期使用https协议token可以再次加密如果访问的是敏感信息 ，单纯加token是不够的 ，通常会再配置白名单说到token ，有些小伙伴们可能会想起jwt ，即（JSON Web Token），其实它也是token的一种。有兴趣的小伙伴可以去了解一下哈 。
4. 时间戳timestamp超时机制
数据是很容易抓包的 ，假设我们用了https和加签，即使中间人抓到了数据报文 ，它也看不到真实数据 。但是有些不法者，他根本不关心真实的数据，而是直接拿到抓取的数据包 ，进行恶意请求（比如DOS攻击） ，以搞垮你的系统 。
我们可以引入时间戳超时机制 ，来保证接口安全 。就是 ：用户每次请求都带上当前时间的时间戳timestamp ，服务端接收到timestamp后，解密 ，验签通过后，与服务器当前时间进行比对 ，如果时间差大于一定时间 (比如3分钟) ，则认为该请求无效 。
5.timestamp+nonce方案防止重放攻击
时间戳超时机制也是有漏洞的 ，如果是在时间差内 ，黑客进行的重放攻击，那就不好使了 。可以使用timestamp+nonce方案 。
nonce指唯一的随机字符串 ，用来标识每个被签名的请求。我们可以将每次请求的nonce参数存储到一个“set集合”中 ，或者可以json格式存储到数据库或缓存中 。每次处理HTTP请求时 ，首先判断该请求的nonce参数是否在该“集合”中 ，如果存在则认为是非法请求 。
然而对服务器来说 ，永久保存nonce的代价是非常大的 。可以结合timestamp来优化 。因为timstamp参数对于超过3min的请求 ，都认为非法请求 ，所以我们只需要存储3min的nonce参数的“集合”即可 。
6. 限流机制
如果用户本来就是就是真实用户 ，他恶意频繁调用接口 ，想搞垮你的系统呢？这种情况就需要接入限流了 。
可以使用Guava的RateLimiter单机版限流 ，也可以使用Redis分布式限流 ，还可以使用阿里开源组件sentinel限流 。比如说 ，一分钟可以接受多少次请求 。
7. 黑名单机制
如果发现了真实用户恶意请求,你可以搞个黑名单机制，把该用户拉黑 。一般情况 ，会有些竞争对手 ，或者不坏好意的用户 ，想搞你的系统的 。所以 ，为了保证安全 ，一般我们的业务系统 ，需要有个黑名单机制。对于黑名单发起的请求 ，直接返回错误码好了。
8.白名单机制
有了黑名单机制 ，也可以搞个白名单机制啦。以前我负责的企业转账系统 ，如果有外面的商户要接入我们的系统时 ，是需要提前申请网络白名单的 。那时候运维会申请个IP网络白名单，只有白名单里面的请求 ，才可以访问我们的转账系统 。
9.数据脱敏掩码
对于密码 ，或者手机号 、身份证这些敏感信息 ，一般都需要脱敏掩码再展示的，如果是密码 ，还需要加密再保存到数据库 。
对于手机号 、身份证信息这些，日常开发中，在日志排查时，看到的都应该是掩码的 。目的就是尽量不泄漏这些用户信息 ，虽然能看日志的只是开发和运维 ，但是还是需要防一下 ，做掩码处理。
对于密码保存到数据库 ，我们肯定不能直接明文保存 。最简单的也需要MD5处理一下再保存 ，Spring Security中的 BCryptPasswordEncoder也可以 ，它的底层是采用SHA-256 +随机盐+密钥对密码进行加密，而SHA和MD系列是一样的 ，都是hash摘要类的算法 。
10. 数据参数一些合法性校验 。
接口数据的安全性保证，还需要我们的系统 ，有个数据合法性校验 ，简单来说就是参数校验 ，比如身份证长度 ，手机号长度 ，是否是数字等等。
总结
本文给大家介绍了10种保证接口数据安全的方案 。