如何设计一个安全的对外接口？

谁践踏了优雅 2023-03-12 12:28 61阅读 0赞

![format_png][]

![format_png 1][]

## 前言    ##

最近有个项目需要对外提供一个接口，提供公网域名进行访问，而且接口和交易订单有关，所以安全性很重要；这里整理了一下常用的一些安全措施以及具体如何去实现。

## 安全措施 ##

个人觉得安全措施大体来看主要在两个方面：

1.  一方面就是如何保证数据在传输过程中的安全性；
2.  另一个方面是数据已经到达服务器端，服务器端如何识别数据，如何不被攻击；下面具体看看都有哪些安全措施。

### 1.数据加密 ###

我们知道数据在传输过程中是很容易被抓包的，如果直接传输比如通过http协议，那么用户传输的数据可以被任何人获取；所以必须对数据加密，常见的做法对关键字段加密比如用户密码直接通过md5加密；现在主流的做法是使用https协议，在http和tcp之间添加一层加密层(SSL层)，这一层负责数据的加密和解密；

### 2.数据加签 ###

数据加签就是由发送者产生一段无法伪造的一段数字串，来保证数据在传输过程中不被篡改；你可能会问数据如果已经通过https加密了，还有必要进行加签吗？数据在传输过程中经过加密，理论上就算被抓包，也无法对数据进行篡改；但是我们要知道加密的部分其实只是在外网，现在很多服务在内网中都需要经过很多服务跳转，所以这里的加签可以防止内网中数据被篡改；

### 3.时间戳机制 ###

数据是很容易被抓包的，但是经过如上的加密，加签处理，就算拿到数据也不能看到真实的数据；但是有不法者不关心真实的数据，而是直接拿到抓取的数据包进行恶意请求；这时候可以使用时间戳机制，在每次请求中加入当前的时间，服务器端会拿到当前时间和消息中的时间相减，看看是否在一个固定的时间范围内比如5分钟内；这样恶意请求的数据包是无法更改里面时间的，所以5分钟后就视为非法请求了；

### 4.AppId机制 ###

大部分网站基本都需要用户名和密码才能登录，并不是谁来能使用我的网站，这其实也是一种安全机制；对应的对外提供的接口其实也需要这么一种机制，并不是谁都可以调用，需要使用接口的用户需要在后台开通appid，提供给用户相关的密钥；在调用的接口中需要提供 appid+密钥，服务器端会进行相关的验证；

### 5.限流机制 ###

本来就是真实的用户，并且开通了appid，但是出现频繁调用接口的情况；这种情况需要给相关appid限流处理，常用的限流算法有令牌桶和漏桶算法；

### 6.黑名单机制 ###

如果此appid进行过很多非法操作，或者说专门有一个中黑系统，经过分析之后直接将此appid列入黑名单，所有请求直接返回错误码；

### 7.数据合法性校验 ###

这个可以说是每个系统都会有的处理机制，只有在数据是合法的情况下才会进行数据处理；每个系统都有自己的验证规则，当然也可能有一些常规性的规则，比如身份证长度和组成，电话号码长度和组成等等；

## 如何实现 ##

以上大体介绍了一下常用的一些接口安全措施，当然可能还有其他我不知道的方式，希望大家补充，下面看看以上这些方法措施，具体如何实现；

### 1.数据加密 ###

现在主流的加密方式有对称加密和非对称加密

1.  **对称加密**：对称密钥在加密和解密的过程中使用的密钥是相同的，常见的对称加密算法有DES，AES；优点是计算速度快，缺点是在数据传送前，发送方和接收方必须商定好秘钥，然后使双方都能保存好秘钥，如果一方的秘钥被泄露，那么加密信息也就不安全了；
2.  **非对称加密**：服务端会生成一对密钥，私钥存放在服务器端，公钥可以发布给任何人使用；优点就是比起对称加密更加安全，但是加解密的速度比对称加密慢太多了；广泛使用的是RSA算法；

两种方式各有优缺点，而https的实现方式正好是结合了两种加密方式，整合了双方的优点，在安全和性能方面都比较好；

对称加密和非对称加密代码实现，jdk提供了相关的工具类可以直接使用，此处不过多介绍；关于https如何配置使用相对来说复杂一些，可以参考本人的之前的文章HTTPS分析与实战

### 2.数据加签 ###

数据签名使用比较多的是md5算法，将需要提交的数据通过某种方式组合和一个字符串，然后通过md5生成一段加密字符串，这段加密字符串就是数据包的签名，可以看一个简单的例子：

str：参数1={参数1}&参数2={参数2}&……&参数n={参数n}$key={用户密钥};
    MD5.encrypt(str);

注意最后的用户密钥，客户端和服务端都有一份，这样会更加安全；

### 3.时间戳机制 ###

解密后的数据，经过签名认证后，我们拿到数据包中的客户端时间戳字段，然后用服务器当前时间去减客户端时间，看结果是否在一个区间内，伪代码如下：

long interval=5*60*1000；//超时时间
    long clientTime=request.getparameter(clientTime);
    long serverTime=System.currentTimeMillis();
    if(serverTime-clientTime>interval){
        return new Response(超过处理时长)
    }

### 4.AppId机制 ###

生成一个唯一的AppId即可，密钥使用字母、数字等特殊字符随机生成即可；生成唯一AppId根据实际情况看是否需要全局唯一；但是不管是否全局唯一最好让生成的Id有如下属性：

1.  **趋势递增**：这样在保存数据库的时候，使用索引性能更好；
2.  **信息安全**：尽量不要连续的，容易发现规律；

关于全局唯一Id生成的方式常见的有类snowflake方式等；

### 5.限流机制 ###

常用的限流算法包括：固定窗口计数器算法、滑动窗口计数器算法、漏桶限流、令牌桶限流

#### 固定窗口计数器算法 ####

规定我们单位时间处理的请求数量。比如我们规定我们的一个接口一分钟只能访问10次的话。使用固定窗口计数器算法的话可以这样实现：给定一个变量counter来记录处理的请求数量，当1分钟之内处理一个请求之后counter+1，1分钟之内的如果counter=100的话，后续的请求就会被全部拒绝。等到 1分钟结束后，将counter回归成0，重新开始计数（ps：只要过了一个周期就讲counter回归成0）。

这种限流算法无法保证限流速率，因而无法保证突然激增的流量。比如我们限制一个接口一分钟只能访问10次的话，前半分钟一个请求没有接收，后半分钟接收了10个请求。

![format_png 2][] 固定窗口计数器算法

#### 滑动窗口计数器算法 ####

算的上是固定窗口计数器算法的升级版。滑动窗口计数器算法相比于固定窗口计数器算法的优化在于：它把时间以一定比例分片比如一分钟分为6个区间，每个区间为10s。每过一定区间的时间，就抛弃最前面的一个区间，如下图所示。如果当前窗口的请求数量超过了限制数量的话，就拒绝后续请求。

![format_png 3][]

很显然：当滑动窗口的格子划分的越多，滑动窗口的滚动就越平滑，限流的统计就会越精确。

![format_png 4][] 滑动窗口计数器算法

#### 漏桶算法 ####

我们可以把发请求的动作比作成注水到桶中，我们处理请求的过程可以比喻为漏桶漏水。我们往桶中以任意速率流入水，以一定速率流出水。当水超过桶流量则丢弃，因为桶容量是不变的，保证了整体的速率。如果想要实现这个算法的话也很简单，准备一个队列用来保存请求，然后我们定期从队列中拿请求来执行就好了。

![format_png 5][] 漏桶算法

#### 令牌桶算法 ####

令牌桶算法也比较简单。和漏桶算法算法一样，我们的主角还是桶（这限流算法和桶过不去啊）。不过现在桶里装的是令牌了，请求在被处理之前需要拿到一个令牌，请求处理完毕之后将这个令牌丢弃（删除）。我们根据限流大小，按照一定的速率往桶里添加令牌。

![format_png 6][] 令牌桶算法

具体基于以上算法如何实现，Guava提供了RateLimiter工具类基于基于令牌桶算法：

RateLimiter rateLimiter = RateLimiter.create(5);

以上代码表示一秒钟只允许处理五个并发请求，以上方式只能用在单应用的请求限流，不能进行全局限流；这个时候就需要分布式限流，可以基于redis+lua来实现；

### 6.黑名单机制 ###

如何为什么中黑我们这边不讨论，我们可以给每个用户设置一个状态比如包括：初始化状态，正常状态，中黑状态，关闭状态等等；或者我们直接通过分布式配置中心，直接保存黑名单列表，每次检查是否在列表中即可；

### 7.数据合法性校验 ###

合法性校验包括：

1.  **常规性校验** ：包括签名校验，必填校验，长度校验，类型校验，格式校验等；
2.  **业务校验** ：根据实际业务而定，比如订单金额不能小于0等；

## 总结 ##

本文大致列举了几种常见的安全措施机制包括：数据加密、数据加签、时间戳机制、AppId机制、限流机制、黑名单机制以及数据合法性校验；当然肯定有其他方式，欢迎补充。

![format_png 7][]

*  [ MySQL性能优化(一)：MySQL架构与核心问题][MySQL_MySQL]
 *  [ MySQL性能优化(二)：选择优化的数据类型][MySQL]
 *  [MySQL性能优化(三)：深入理解索引的这点事][MySQL 1]
 *  [MySQL性能优化(四)：如何高效正确的使用索引 ][MySQL 2]
 *  [MySQL性能优化(五)：为什么查询速度这么慢][MySQL 3]
 *  [MySQL性能优化(六)：常见优化SQL的技巧][MySQL_SQL]  
    
 *  [微服务架构下的核心话题 (一)：微服务架构下各类项目的顺势崛起][Link 1]
 *  [微服务架构下的核心话题 (二)：微服务架构的设计原则和核心话题][Link 2]
 *  [微服务架构下的核心话题 (三)：微服务架构的技术选型][Link 3]

![format_png 8][]

喜欢就点个"在看"呗，留言、转发朋友圈

[format_png]: /images/20230312/5ed16498638240ad87b720b52b6dbe47.png
[format_png 1]: /images/20230312/de30c977783a46c18732fefab06f593d.png
[format_png 2]: /images/20230312/4e258f8152bb45c1896936f940d12729.png
[format_png 3]: /images/20230312/b82839b69ec14a73b428ca413db85ae0.png
[format_png 4]: /images/20230312/a98705e06eba480bb68175d5ce4f7ea3.png
[format_png 5]: /images/20230312/7f921beaee5a4525982c65891ee4886e.png
[format_png 6]: /images/20230312/35b9b1d398434282be87c305edd0502c.png
[format_png 7]: /images/20230312/96504172b781420fad29ac11b61f8ea6.png
[MySQL_MySQL]: http://mp.weixin.qq.com/s?__biz=MzA5MzUwOTY4NQ%3D%3D&chksm=905d89ffa72a00e9afbacdd1984a40e6371372c5de1c623d28a6c900947fc78511c36fac73b7&idx=1&mid=2247485605&scene=21&sn=f9ec97eb5b49e2724d74b29e2d96afad#wechat_redirect
[MySQL]: http://mp.weixin.qq.com/s?__biz=MzA5MzUwOTY4NQ%3D%3D&chksm=905d89e9a72a00ffd26b7bd32b10213ddd72e16d05e10aca8df42919db494289de2686ad1263&idx=1&mid=2247485619&scene=21&sn=c5a033c1046a279ce285573321bcc858#wechat_redirect
[MySQL 1]: https://blog.csdn.net/xcbeyond/article/details/104858619
[MySQL 2]: http://mp.weixin.qq.com/s?__biz=MzA5MzUwOTY4NQ%3D%3D&chksm=905d885ba72a014d2cb27ffacabecd5e4d28ef4cc2e033915c72a74b468db119eac07d0f3d74&idx=1&mid=2247485697&scene=21&sn=48e3a4ab43ffb5bbdd8b763dae391da0#wechat_redirect
[MySQL 3]: https://blog.csdn.net/xcbeyond/article/details/105375386
[MySQL_SQL]: https://blog.csdn.net/xcbeyond/article/details/105600038
[Link 1]: https://blog.csdn.net/xcbeyond/article/details/97503091
[Link 2]: https://blog.csdn.net/xcbeyond/article/details/98392304
[Link 3]: https://blog.csdn.net/xcbeyond/article/details/102511891
[format_png 8]: /images/20230312/f82062c8bab6437893a21cd5631832c3.png