インターフェースデータセキュリティのための10のソリューション

大家好呀，我是捡田螺的小男孩。

我们日常开发中，如何保证接口数据的安全性呢？个人觉得，接口数据安全的保证过程，主要体现在这几个方面：一个就是数据传输过程中的安全，还有就是数据到达服务端，如何识别数据，最后一点就是数据存储的安全性。今天跟大家聊聊保证接口数据安全的 10 个方案。

1.メッセージの平文転送を防ぐデータ暗号化。

ご存知のように、データはネットワーク転送中に簡単にキャプチャされます。HTTPプロトコルを使用している場合、クリアテキストで送信されるため、ユーザーのデータは他の人に簡単にアクセスできます。データの暗号化が必要です。

1.1データを暗号化する方法は？

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

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

**非対称暗号化 ** 非対称暗号化アルゴリズムには、2つの鍵（公開鍵と秘密鍵）が必要です。**公開鍵と秘密鍵はペアであり、公開鍵でデータを暗号化すると、対応する秘密鍵のみが復号化できます。

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

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

1.2皆さん、HTTPSの原理をご存知ですか？

インタビューでもよく聞かれます：

クライアントはHTTPリクエストを開始し、サーバのポート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.トークン認証認証メカニズム

毎日の開発では、当社のウェブサイトやアプリは、** ユーザーがログインする必要があります。では、非ログインインターフェイスである場合、どのようにセキュリティを確保し、ユーザー IDを確認するのでしょうか？** トークン ** 認証メカニズムを使用できます。

3.1トークンの認証スキーム

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

** トークンログイン承認のフローチャートは以下のとおりです。

ユーザー名とパスワードを入力し、ログイン要求を開始する
サーバーはパスワードを検証し、検証が通過するとグローバルに一意なトークンを生成します。
将token存储在redis中，其中key是token，value是userId或者是用户信息，设置一个过期时间。
把这个token返回给客户端
用户发起其他业务请求时，需要带上这个token
后台服务会统一拦截接口请求，进行token有效性校验，并从中获取用户信息，供后续业务逻辑使用。如果token不存在，说明请求无效。

3.2トークンを安全に保つ方法？トークンはハイジャックされる？

** トークンを安全に保つには？**

比如说，我如果拿到token，是不是就可以调用服务器端的任何接口？可以从这几个方面出发考虑：

トークンは合理的な有効期間を設定する
httpsプロトコルの使用
トークンは再び暗号化できます
機密情報にアクセスする場合、トークンを追加するだけでは不十分であり、通常はホワイトリストが再構成されます。

トークンといえば、Jwt（JSON Web Token）を思い浮かべる人もいるかもしれませんが、実際にはトークンの一種です。興味のある人は知ることができます。

4. タイムスタンプtimestamp timestampタイムアウトメカニズム

数据是很容易抓包的，假设我们用了https和加签，即使中间人抓到了数据报文，它也看不到真实数据。但是有些不法者，他根本不关心真实的数据，而是直接拿到抓取的数据包，进行恶意请求（比如DOS 攻击），以搞垮你的系统。

我们可以引入时间戳超时机制，来保证接口安全。就是：用户每次请求都带上当前时间的时间戳timestamp，服务端接收到timestamp后，解密，验签通过后，与服务器当前时间进行比对，如果时间差大于一定时间 (比如 3 分钟)，则认为该请求无效。

リプレイ攻撃を防ぐためのタイムスタンプ+ノンス

时间戳超时机制也是有漏洞的，如果是在时间差内，黑客进行的重放攻击，那就不好使了。可以使用timestamp+nonce方案。

nonce指唯一的随机字符串，用来标识每个被签名的请求。我们可以将每次请求的nonce参数存储到一个“set 集合”中，或者可以 json 格式存储到数据库或缓存中。每次处理 HTTP 请求时，首先判断该请求的nonce参数是否在该“集合”中，如果存在则认为是非法请求。

然而对服务器来说，永久保存nonce的代价是非常大的。可以结合timestamp来优化。因为timstamp参数对于超过3min的请求，都认为非法请求，所以我们只需要存储3min的nonce参数的“集合”即可。

6. 制限フローメカニズム

ユーザーが実際のユーザーであり、悪意のある頻繁なインターフェイスを呼び出してシステムをクラッシュさせたい場合は？この場合、アクセス制限が必要になります。

常用的限流算法有令牌桶和漏桶算法。大家可以看下我的这篇文章，面试必备：4 种经典限流算法讲解

可以使用Guava的RateLimiter单机版限流，也可以使用Redis分布式限流，还可以使用阿里开源组件sentinel限流。比如说，一分钟可以接受多少次请求。

7. ブラックリストのメカニズム

真のユーザーの悪意のある要求を発見した場合、あなたはブラックリストのメカニズムを作り、そのユーザーを黒にします。一般的に、競合他社や善意のないユーザーがシステムに手を差し伸べたいと思っています。したがって、セキュリティを確保するためには、一般的な業務システムにブラックリストメカニズムが必要です。ブラックリストからのリクエストでは、エラーコードを返します。

8.ホワイトリストの仕組み

ブラックリストシステムでは、ホワイトリストシステムを作成することもできます。以前は、私が担当していた法人振替システムでは、外部の商人が当社のシステムにアクセスしたい場合、事前にネットワークホワイトリストを申請する必要がありました。その時点で、オペレーションと保守はIPネットワークのホワイトリストを要求し、ホワイトリスト内のリクエストのみが転送システムにアクセスできます。

9.データ脱感作マスキング

パスワード、または携帯電話番号、IDカードなどの機密情報については、一般的に脱感作マスクを再表示する必要があり、パスワードの場合は暗号化してデータベースに保存する必要があります。

携帯電話番号やIDカード情報については、日常の開発では、ログチェック時に表示されるものはマスクでなければなりません。目的は、これらのユーザー情報を漏洩しないようにすることですが、ログを見ることができるのは開発と保守のみですが、まだそれを防ぐ必要があります。

对于密码保存到数据库，我们肯定不能直接明文保存。最简单的也需要MD5处理一下再保存，Spring Security中的 BCryptPasswordEncoder也可以，它的底层是采用SHA-256 +随机盐+密钥对密码进行加密，而SHA和MD系列是一样的，都是hash摘要类的算法。

10. データパラメータの正当性のチェック。

インターフェイスデータのセキュリティ保証は、私たちのシステムも必要であり、データの正当性検証、簡単に言えば、IDカードの長さ、携帯電話番号の長さ、それが数字であるかどうかなどのパラメータ検証です。

まとめまとめまとめ

本稿では、インターフェースのデータセキュリティを確保する10の方法を紹介する。子供たちは、他のプログラムがある場合は、コメントエリアでコメントし、一緒に学ぶことができます。