10 种保证接口数据安全的方案！

深藏阁楼爱情的钟 2023-10-01 23:34 14阅读 0赞

我们日常开发中，如何保证接口数据的安全性呢？

个人觉得，接口数据安全的保证过程，主要体现在这几个方面：一个就是**数据传输**过程中的安全，还有就是数据到达服务端，如何**识别数据**，最后一点就是**数据存储的安全性**。

今天跟大家聊聊保证接口数据安全的 10 种方案。

### 1. 数据加密，防止报文明文传输 ###

我们都知道，数据在网络传输过程中，很容易被抓包。如果使用的是 http 协议，因为它是明文传输的，用户的数据就很容易被别人获取。所以需要对数据加密。

#### 1.1 数据如何加密呢？ ####

常见的实现方式，就是对**关键字段**加密。比如，一个登录的接口，你可以对**密码**加密。一般用什么加密算法呢？简单点可以使用**对称加密算法**（如`AES`）来加解密，或者哈希算法处理（如`MD5`）。

> 什么是**对称加密**：加密和解密使用相同密钥的加密算法。

![023eb195862653d9054219b852e4b6a8.png][]

> **非对称加密**：非对称加密算法需要两个密钥（公开密钥和私有密钥）。**公钥与私钥是成对存在的**，如果用公钥对数据进行加密，只有对应的私钥才能解密。

更安全的做法，就是用**非对称加密算法**（如`RSA`或者`SM2`），公钥加密，私钥解密。

![7c5ca80accd995fa44e574a908224a15.png][]

如果你想对所有字段都加密的话，一般都推荐使用 **https 协议**。`https`其实就是在`http`和`tcp`之间添加一层加密层 SSL。

#### 1.2 是否还记得 https 的原理呢？ ####

面试也经常问的，如下：

![49182124b3e94a809e6de4a29901f344.png][]

1.  客户端发起 https 请求，连接到服务器的 443 端口。
2.  服务器必须要有一套数字证书（证书内容有公钥、证书颁发机构、失效日期等）。
3.  服务器将自己的数字证书发送给客户端（公钥在证书里面，私钥由服务器持有）。
4.  客户端收到数字证书之后，会验证证书的合法性。如果证书验证通过，就会生成一个随机的对称密钥，用证书的公钥加密。
5.  客户端将公钥加密后的密钥发送到服务器。
6.  服务器接收到客户端发来的密文密钥之后，用自己之前保留的私钥对其进行非对称解密，解密之后就得到客户端的密钥，然后用客户端密钥对返回数据进行对称加密，这样子传输的数据都是密文啦。
7.  服务器将加密后的密文返回到客户端。
8.  客户端收到后，用自己的密钥对其进行对称解密，得到服务器返回的数据。

日常业务呢，数据传输加密这块的话，用 **https** 就可以啦，如果安全性要求较高的，比如登录注册这些，需要传输密码的，密码就可以使用`RSA`等非对称加密算法，对密码加密。如果你的业务安全性要求很高，你可以模拟 https 这个流程，对报文再做一次加解密。

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

数据报文加签验签，是**保证数据传输安全的常用手段**，它可以保证数据在**传输过程中不被篡改**。以前我做的**企业转账系统**，就用了加签验签。

#### 2.1 什么是加签验签呢？ ####

*  **数据加签**：用 Hash 算法（如`MD5 或者 SHA-256`）把原始请求参数生成报文摘要，然后用私钥对这个摘要进行加密，就得到这个报文对应的数字签名`sign`（这个过程就是**加签**）。通常来说，请求方会把**数字签名和报文原文**一并发送给接收方。

![0c276f5eb3a02df973127099a735137a.png][]

*  **验签**：接收方拿到原始报文和数字签名（`sign`）后，用**同一个 Hash 算法（**比如都用 MD5）从报文中生成摘要 A。另外，用对方提供的公钥对数字签名进行解密，得到摘要 B，对比 A 和 B 是否相同，就可以得知报文有没有被篡改过。

![5086e20bb8a8915b64bb7d2150201eb2.png][]

其实**加签**，按我的理解，就是把请求参数，按照一定规则，利用`hash`算法+加密算法生成一个**唯一标签**`sign`。**验签的话**，就是把请求参数按照相同的规则处理，再用相同的`hash`算法，和对应的密钥解密处理，以对比这个签名是否一致。

> 再举个例子，有些小伙伴是这么实现的，将所有非空参数（包含一个包`AccessKey`，**唯一的开发者标识**）按照升序，然后再拼接个`SecretKey`（这个仅作本地加密使用，不参与网络传输，它只是用作签名里面的），得到一个`stringSignTemp`的值，最后用 MD5 运算，得到`sign`。
> 
> 服务端收到报文后，会校验，只有拥有合法的身份`AccessKey`和签名`Sign`正确，才放行。这样就解决了身份验证和参数篡改问题，如果请求参数被劫持，由于劫持者获取不到`SecretKey`（仅作本地加密使用，不参与网络传输），他就无法伪造合法的请求啦。

#### 2.2 有了 https 等加密数据，为什么还需要加签验签？ ####

有些小伙伴可能有疑问，加签验签主要是防止数据在传输过程中被篡改，那如果都用了`https`下协议加密数据了，为什么还会被篡改呢？为什么还需要加签验签呢？

> 数据在传输过程中被加密了，理论上，即使被抓包，数据也不会被篡改。但是 **https 不是绝对安全**的。还有一个点：`https`加密的部分只是在外网，然后有很多服务是内网相互跳转的，加签也可以在**这里保证不被中间人篡改**，所以一般转账类安全性要求高的接口开发，都需要**加签验签**。

### 3. token 授权认证机制 ###

日常开发中，我们的网站或者 APP，都是需要**用户登录**的。那么如果是**非登录接口**，是如何确保安全，如何确认用户身份的呢？可以使用 **token** 授权机制。

#### 3.1 token 的授权认证方案 ####

**token 的授权认证方案**：用户在客户端输入用户名和密码，点击登录后，服务器会校验密码成功，会给客户端返回一个唯一值`token`，并将`token`以键值对的形式存放在缓存（一般是 Redis）中。后续客户端对需要授权模块的所有操作都要带上这个`token`，服务器端接收到请求后，先进行`token`验证，如果`token`存在，才表明是合法请求。

**token 登录授权流程图如下：**

![6ad602befcb8489ba1c87d3f29d2cf38.png][]

1.  用户输入用户名和密码，发起登录请求。
2.  服务端校验密码，如果校验通过，生成一个全局唯一的`token`。
3.  将`token`存储在`redis`中，其中`key`是`token`，`value`是`userId`或者是用户信息，设置一个过期时间。
4.  把这个`token`返回给客户端。
5.  用户发起其他业务请求时，需要带上这个`token`。
6.  后台服务会统一拦截接口请求，进行`token`有效性校验，并从中获取用户信息，供后续业务逻辑使用。如果`token`不存在，说明请求无效。

#### 3.2 如何保证 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 种保证接口数据安全的方案。小伙伴们，如果还有其他方案，可以在留言区评论哈，一起交流学习。

[023eb195862653d9054219b852e4b6a8.png]: https://img-blog.csdnimg.cn/img_convert/023eb195862653d9054219b852e4b6a8.png
[7c5ca80accd995fa44e574a908224a15.png]: https://img-blog.csdnimg.cn/img_convert/7c5ca80accd995fa44e574a908224a15.png
[49182124b3e94a809e6de4a29901f344.png]: https://img-blog.csdnimg.cn/49182124b3e94a809e6de4a29901f344.png
[0c276f5eb3a02df973127099a735137a.png]: https://img-blog.csdnimg.cn/img_convert/0c276f5eb3a02df973127099a735137a.png
[5086e20bb8a8915b64bb7d2150201eb2.png]: https://img-blog.csdnimg.cn/img_convert/5086e20bb8a8915b64bb7d2150201eb2.png
[6ad602befcb8489ba1c87d3f29d2cf38.png]: https://img-blog.csdnimg.cn/img_convert/6ad602befcb8489ba1c87d3f29d2cf38.png