我有 10種 保證接口數(shù)據(jù)安全的方案
大家好呀，我是小富~
我們?nèi)粘ｉ_發(fā)中，如何保證接口數(shù)據(jù)的安全性呢？個(gè)人覺得，接口數(shù)據(jù)安全的保證過程，主要體現(xiàn)在這幾個(gè)方面：一個(gè)就是數(shù)據(jù)傳輸過程中的安全，還有就是數(shù)據(jù)到達(dá)服務(wù)端，如何識(shí)別數(shù)據(jù)，最后一點(diǎn)就是數(shù)據(jù)存儲(chǔ)的安全性。今天跟大家聊聊保證接口數(shù)據(jù)安全的10個(gè)方案。
1.數(shù)據(jù)加密，防止報(bào)文明文傳輸。
我們都知道，數(shù)據(jù)在網(wǎng)絡(luò)傳輸過程中，很容易被抓包。如果使用的是http協(xié)議，因?yàn)樗敲魑膫鬏數(shù)模脩舻臄?shù)據(jù)就很容易被別人獲取。所以需要對(duì)數(shù)據(jù)加密。
1.1 數(shù)據(jù)如何加密呢？
常見的實(shí)現(xiàn)方式，就是對(duì)關(guān)鍵字段加密。比如，你一個(gè)登錄的接口，你可以對(duì)密碼加密。一般用什么加密算法呢？簡(jiǎn)單點(diǎn)可以使用對(duì)稱加密算法（如AES）來加解密，或者哈希算法處理（如MD5）。
什么是對(duì)稱加密：加密和解密使用相同密鑰的加密算法。
非對(duì)稱加密：非對(duì)稱加密算法需要兩個(gè)密鑰（公開密鑰和私有密鑰）。公鑰與私鑰是成對(duì)存在的，如果用公鑰對(duì)數(shù)據(jù)進(jìn)行加密，只有對(duì)應(yīng)的私鑰才能解密。
更安全的做法，就是用非對(duì)稱加密算法（如RSA或者SM2），公鑰加密，私鑰解密。
如果你想對(duì)所有字段都加密的話，一般都推薦使用https協(xié)議。https其實(shí)就是在http和tcp之間添加一層加密層SSL。
1.2 小伙伴們，是否還記得https的原理呢？
面試也經(jīng)常問的，如下：
客戶端發(fā)起Https請(qǐng)求，連接到服務(wù)器的443端口。 服務(wù)器必須要有一套數(shù)字證書（證書內(nèi)容有公鑰、證書頒發(fā)機(jī)構(gòu)、失效日期等）。 服務(wù)器將自己的數(shù)字證書發(fā)送給客戶端（公鑰在證書里面，私鑰由服務(wù)器持有）。 客戶端收到數(shù)字證書之后，會(huì)驗(yàn)證證書的合法性。如果證書驗(yàn)證通過，就會(huì)生成一個(gè)隨機(jī)的對(duì)稱密鑰，用證書的公鑰加密。 客戶端將公鑰加密后的密鑰發(fā)送到服務(wù)器。 服務(wù)器接收到客戶端發(fā)來的密文密鑰之后，用自己之前保留的私鑰對(duì)其進(jìn)行非對(duì)稱解密，解密之后就得到客戶端的密鑰，然后用客戶端密鑰對(duì)返回?cái)?shù)據(jù)進(jìn)行對(duì)稱加密，醬紫傳輸?shù)臄?shù)據(jù)都是密文啦。 服務(wù)器將加密后的密文返回到客戶端。 客戶端收到后，用自己的密鑰對(duì)其進(jìn)行對(duì)稱解密，得到服務(wù)器返回的數(shù)據(jù)。
日常業(yè)務(wù)呢，數(shù)據(jù)傳輸加密這塊的話，用https就可以啦，如果安全性要求較高的，比如登陸注冊(cè)這些，需要傳輸密碼的，密碼就可以使用RSA等非對(duì)稱加密算法，對(duì)密碼加密。如果你的業(yè)務(wù)，安全性要求很高，你可以模擬https這個(gè)流程，對(duì)報(bào)文，再做一次加解密。
2. 數(shù)據(jù)加簽驗(yàn)簽
數(shù)據(jù)報(bào)文加簽驗(yàn)簽，是保證數(shù)據(jù)傳輸安全的常用手段，它可以保證數(shù)據(jù)在傳輸過程中不被篡改。以前我做的企業(yè)轉(zhuǎn)賬系統(tǒng)，就用了加簽驗(yàn)簽。
2.1 什么是加簽驗(yàn)簽?zāi)兀?span style="display: none;">
數(shù)據(jù)加簽：用Hash算法（如 MD5，或者SHA-256）把原始請(qǐng)求參數(shù)生成報(bào)文摘要，然后用私鑰對(duì)這個(gè)摘要進(jìn)行加密，就得到這個(gè)報(bào)文對(duì)應(yīng)的數(shù)字簽名sign（這個(gè)過程就是加簽）。通常來說呢，請(qǐng)求方會(huì)把數(shù)字簽名和報(bào)文原文一并發(fā)送給接收方。
驗(yàn)簽：接收方拿到原始報(bào)文和數(shù)字簽名（ sign）后，用同一個(gè)Hash算法(比如都用MD5)從報(bào)文中生成摘要A。另外，用對(duì)方提供的公鑰對(duì)數(shù)字簽名進(jìn)行解密，得到摘要B，對(duì)比A和B是否相同，就可以得知報(bào)文有沒有被篡改過。
其實(shí)加簽，我的理解的話，就是把請(qǐng)求參數(shù)，按照一定規(guī)則，利用hash算法+加密算法生成一個(gè)唯一標(biāo)簽sign。驗(yàn)簽的話，就是把請(qǐng)求參數(shù)按照相同的規(guī)則處理，再用相同的hash算法，和對(duì)應(yīng)的密鑰解密處理，以對(duì)比這個(gè)簽名是否一致。
再舉個(gè)例子，有些小伙伴是這么實(shí)現(xiàn)的，將所有非空參數(shù)（包含一個(gè)包
AccessKey，唯一的開發(fā)者標(biāo)識(shí)）按照升序，然后再拼接個(gè)SecretKey（這個(gè)僅作本地加密使用，不參與網(wǎng)絡(luò)傳輸，它只是用作簽名里面的），得到一個(gè)stringSignTemp的值，最后用MD5運(yùn)算，得到sign。服務(wù)端收到報(bào)文后，會(huì)校驗(yàn)，只有擁有合法的身份
AccessKey和簽名Sign正確，才放行。這樣就解決了身份驗(yàn)證和參數(shù)篡改問題，如果請(qǐng)求參數(shù)被劫持，由于劫持者獲取不到SecretKey（僅作本地加密使用，不參與網(wǎng)絡(luò)傳輸），他就無法偽造合法的請(qǐng)求啦
2.2 有了https等加密數(shù)據(jù)，為什么還需要加簽驗(yàn)簽
有些小伙伴可能有疑問，加簽驗(yàn)簽主要是防止數(shù)據(jù)在傳輸過程中被篡改，那如果都用了https下協(xié)議加密數(shù)據(jù)了，為什么還會(huì)被篡改呢？為什么還需要加簽驗(yàn)簽?zāi)兀?/p>
數(shù)據(jù)在傳輸過程中被加密了，理論上，即使被抓包，數(shù)據(jù)也不會(huì)被篡改。但是https不是絕對(duì)安全的哦。可以看下這個(gè)文章：可怕，原來 HTTPS 也沒用。還有一個(gè)點(diǎn)：
https加密的部分只是在外網(wǎng)，然后有很多服務(wù)是內(nèi)網(wǎng)相互跳轉(zhuǎn)的，加簽也可以在這里保證不被中間人篡改，所以一般轉(zhuǎn)賬類安全性要求高的接口開發(fā)，都需要加簽驗(yàn)簽
3.token授權(quán)認(rèn)證機(jī)制
日常開發(fā)中，我們的網(wǎng)站或者APP，都是需要用戶登錄的。那么如果是非登錄接口，是如何確保安全，如何確認(rèn)用戶身份的呢？可以使用token授權(quán)機(jī)制。
3.1 token的授權(quán)認(rèn)證方案
token的授權(quán)認(rèn)證方案：用戶在客戶端輸入用戶名和密碼，點(diǎn)擊登錄后，服務(wù)器會(huì)校驗(yàn)密碼成功，會(huì)給客戶端返回一個(gè)唯一值token，并將token以鍵值對(duì)的形式存放在緩存（一般是Redis）中。后續(xù)客戶端對(duì)需要授權(quán)模塊的所有操作都要帶上這個(gè)token，服務(wù)器端接收到請(qǐng)求后，先進(jìn)行token驗(yàn)證，如果token存在，才表明是合法請(qǐng)求。
token登錄授權(quán)流程圖如下：
用戶輸入用戶名和密碼，發(fā)起登錄請(qǐng)求 服務(wù)端校驗(yàn)密碼，如果校驗(yàn)通過，生成一個(gè)全局唯一的 token。將 token存儲(chǔ)在redis中，其中key是token，value是userId或者是用戶信息，設(shè)置一個(gè)過期時(shí)間。把這個(gè) token返回給客戶端用戶發(fā)起其他業(yè)務(wù)請(qǐng)求時(shí)，需要帶上這個(gè) token后臺(tái)服務(wù)會(huì)統(tǒng)一攔截接口請(qǐng)求，進(jìn)行 token有效性校驗(yàn)，并從中獲取用戶信息，供后續(xù)業(yè)務(wù)邏輯使用。如果token不存在，說明請(qǐng)求無效。
3.2 如何保證token的安全？token被劫持呢？
我們?nèi)绾伪ＷCtoken的安全呢？
比如說，我如果拿到token，是不是就可以調(diào)用服務(wù)器端的任何接口？可以從這幾個(gè)方面出發(fā)考慮：
token設(shè)置合理的有效期 使用https協(xié)議 token可以再次加密 如果訪問的是敏感信息，單純加token是不夠的，通常會(huì)再配置白名單
說到token，有些小伙伴們可能會(huì)想起jwt，即（JSON Web Token），其實(shí)它也是token的一種。有興趣的小伙伴可以去了解一下哈。
4. 時(shí)間戳timestamp超時(shí)機(jī)制
數(shù)據(jù)是很容易抓包的，假設(shè)我們用了https和加簽，即使中間人抓到了數(shù)據(jù)報(bào)文，它也看不到真實(shí)數(shù)據(jù)。但是有些不法者，他根本不關(guān)心真實(shí)的數(shù)據(jù)，而是直接拿到抓取的數(shù)據(jù)包，進(jìn)行惡意請(qǐng)求（比如DOS攻擊），以搞垮你的系統(tǒng)。
我們可以引入時(shí)間戳超時(shí)機(jī)制，來保證接口安全。就是：用戶每次請(qǐng)求都帶上當(dāng)前時(shí)間的時(shí)間戳timestamp，服務(wù)端接收到timestamp后，解密，驗(yàn)簽通過后，與服務(wù)器當(dāng)前時(shí)間進(jìn)行比對(duì)，如果時(shí)間差大于一定時(shí)間 (比如3分鐘)，則認(rèn)為該請(qǐng)求無效。
5.timestamp+nonce方案防止重放攻擊
時(shí)間戳超時(shí)機(jī)制也是有漏洞的，如果是在時(shí)間差內(nèi)，黑客進(jìn)行的重放攻擊，那就不好使了。可以使用timestamp+nonce方案。
nonce指唯一的隨機(jī)字符串，用來標(biāo)識(shí)每個(gè)被簽名的請(qǐng)求。我們可以將每次請(qǐng)求的nonce參數(shù)存儲(chǔ)到一個(gè)“set集合”中，或者可以json格式存儲(chǔ)到數(shù)據(jù)庫或緩存中。每次處理HTTP請(qǐng)求時(shí)，首先判斷該請(qǐng)求的nonce參數(shù)是否在該“集合”中，如果存在則認(rèn)為是非法請(qǐng)求。
然而對(duì)服務(wù)器來說，永久保存nonce的代價(jià)是非常大的。可以結(jié)合timestamp來優(yōu)化。因?yàn)?code style="font-size: 14px;word-wrap: break-word;padding: 2px 4px;border-radius: 4px;margin: 0 2px;background-color: rgba(27,31,35,.05);font-family: Operator Mono, Consolas, Monaco, Menlo, monospace;word-break: break-all;color: rgb(239, 112, 96);">timstamp參數(shù)對(duì)于超過3min的請(qǐng)求，都認(rèn)為非法請(qǐng)求，所以我們只需要存儲(chǔ)3min的nonce參數(shù)的“集合”即可。
6. 限流機(jī)制
如果用戶本來就是就是真實(shí)用戶，他惡意頻繁調(diào)用接口，想搞垮你的系統(tǒng)呢？這種情況就需要接入限流了。
常用的限流算法有令牌桶和漏桶算法。大家可以看下我的這篇文章，面試必備：4種經(jīng)典限流算法講解
可以使用Guava的RateLimiter單機(jī)版限流，也可以使用Redis分布式限流，還可以使用阿里開源組件sentinel限流。比如說，一分鐘可以接受多少次請(qǐng)求。
7. 黑名單機(jī)制
如果發(fā)現(xiàn)了真實(shí)用戶惡意請(qǐng)求,你可以搞個(gè)黑名單機(jī)制，把該用戶拉黑。一般情況，會(huì)有些競(jìng)爭(zhēng)對(duì)手，或者不壞好意的用戶，想搞你的系統(tǒng)的。所以，為了保證安全，一般我們的業(yè)務(wù)系統(tǒng)，需要有個(gè)黑名單機(jī)制。對(duì)于黑名單發(fā)起的請(qǐng)求，直接返回錯(cuò)誤碼好了。
8.白名單機(jī)制
有了黑名單機(jī)制，也可以搞個(gè)白名單機(jī)制啦。以前我負(fù)責(zé)的企業(yè)轉(zhuǎn)賬系統(tǒng)，如果有外面的商戶要接入我們的系統(tǒng)時(shí)，是需要提前申請(qǐng)網(wǎng)絡(luò)白名單的。那時(shí)候運(yùn)維會(huì)申請(qǐng)個(gè)IP網(wǎng)絡(luò)白名單，只有白名單里面的請(qǐng)求，才可以訪問我們的轉(zhuǎn)賬系統(tǒng)。
9.數(shù)據(jù)脫敏掩碼
對(duì)于密碼，或者手機(jī)號(hào)、身份證這些敏感信息，一般都需要脫敏掩碼再展示的，如果是密碼，還需要加密再保存到數(shù)據(jù)庫。
對(duì)于手機(jī)號(hào)、身份證信息這些，日常開發(fā)中，在日志排查時(shí)，看到的都應(yīng)該是掩碼的。目的就是盡量不泄漏這些用戶信息，雖然能看日志的只是開發(fā)和運(yùn)維，但是還是需要防一下，做掩碼處理。
對(duì)于密碼保存到數(shù)據(jù)庫，我們肯定不能直接明文保存。最簡(jiǎn)單的也需要MD5處理一下再保存，Spring Security中的 BCryptPasswordEncoder也可以，它的底層是采用SHA-256 +隨機(jī)鹽+密鑰對(duì)密碼進(jìn)行加密，而SHA和MD系列是一樣的，都是hash摘要類的算法。
10. 數(shù)據(jù)參數(shù)一些合法性校驗(yàn)。
接口數(shù)據(jù)的安全性保證，還需要我們的系統(tǒng)，有個(gè)數(shù)據(jù)合法性校驗(yàn)，簡(jiǎn)單來說就是參數(shù)校驗(yàn)，比如身份證長度，手機(jī)號(hào)長度，是否是數(shù)字等等。
總結(jié)
本文給大家介紹了10種保證接口數(shù)據(jù)安全的方案。小伙伴們，如有還有其他方案的話，可以在留言區(qū)評(píng)論哈，一起交流學(xué)習(xí)。
如果這篇文章對(duì)您有所幫助，或者有所啟發(fā)的話，幫忙掃描下發(fā)二維碼關(guān)注一下，您的支持是我堅(jiān)持寫作最大的動(dòng)力。求一鍵三連：點(diǎn)贊、轉(zhuǎn)發(fā)、在看。