從系統架構分析安全問題及應對措施

在日常生產生活中，我們常說，“安全第一”、“安全無小事”。圍繞著安全問題，在各行各業都有對各類常見安全問題的解決方案和突發安全問題的應急預案。在網際網路、軟體開發領域，我們日常工作中對各類常見的安全問題又有哪些常見的解決方案呢？在此，結合經典架構圖做一個梳理。

下面，結合上述的經典架構圖，對資料儲存、微服務介面、外網資料傳輸及APP層可能出現的安全問題進行分析，並給出一些常見的應對措施。

1 資料儲存

為了保證資料儲存的安全，對於敏感資料在進行儲存時，需要進行加密儲存，同時，敏感資料建議在全公司進行收口管理，便於統一管理。對敏感資料進行加密儲存時，常見的加密方式有可逆加密和不可逆加密，分別適用於不同的敏感資料。

1.1 可逆加密或對稱加密

可逆加密，即通過對密文進行解密後，能把密文解密還原出明文。對稱加密演算法加密和解密用到的金鑰是相同的，這種加密方式加密速度非常快，適合經常傳送資料的場合，缺點是金鑰的傳輸比較麻煩。比如：網路購物的收貨地址、姓名、手機號等就適合用該加密方式，常用的對稱加密演算法有DES、AES，下面以AES為例說明對稱加密的過程。

在該加解密中，對於祕鑰K的生成需要加解密雙方共同制定並妥善保管。通常，我們會把該祕鑰K儲存在需要使用加解密程式的程序內，便於在程式使用時直接進行使用。

1.2 不可逆加密

不可逆加密，即不需要解密出明文，如：使用者的密碼。不可逆加密常用的演算法有RES、MD5等，在此以MD5為例進行說明。但大家都知道，MD5演算法是存在碰撞的，即不同的明文通過MD5加密後，存在相同的密文。因此，直接使用MD5對密碼進行加密在生產上是不嚴謹的，通常還需要配合鹽（salt）進行使用。對於鹽的使用，也有一定的技巧，一種鹽值是固定的，即所有的明文在進行加密時都使用相同的鹽進行加密；另一種是結合具體的業務場景，用可變鹽值，比如：就密碼加密而言，可以把使用者名稱的部分或全部作為鹽值，和密碼進行一起加密後儲存。

2 微服務介面

微服務的安全，需要從請求鑑權和請求容量限制這2個方面來考慮。對於請求鑑權，可以設定請求IP黑名單的方式，對該IP的所有請求或全部放行或全部拒絕，該方式的粒度較粗。而如果要做得較細粒度一些，可以針對具體的API進行token鑑權，相比粗粒度該方式會控制得比較精準；

<jsf:consumer id="setmentService" interface="com.jd.lfsp.jsf.service.SetmentService"
                  protocol="jsf" alias="${jsf.consumer.alias}" timeout="${jsf.consumer.timeout}" retries="0">
        <jsf:parameter key="token" value="${jsf.consumer.token}" hide="true" />
</jsf:consumer>

除了對請求鑑權外，在實際的生產中，還可以對請求容量進行限制，對請求容量進行限制時，可以按QPS進行限制，也可以對每天的最大請求次數進行限制。在jsf平臺管理端，可以對具體的方法進行請求的QPS限流。

3 資料傳輸

資料傳輸主要分為資料通過前端APP的請求，進入到服務閘道器前和進入服務閘道器後這倆部分，對於資料已經進入服務閘道器後，這屬於機房內的資料傳輸，通常這類加密意義不大，對這類的資料傳輸的安全需要建立相應的內部安全機制及流程規範，通過制度措施來保證。而資料在進入服務閘道器前，對資料的安全傳輸有哪些可做的。在資料請求進入服務閘道器前，通常我們有基於SSL協議的傳輸加密以及現在普遍通用的HTTPS加密。

HTTPS也是HTTP和SSL協議的結合體，所以在資料傳輸中，SSL協議扮演了至關重要的角色。那SSL協議的工作過程是怎麼樣的，他是怎麼保證資料傳輸過程中的安全的呢？下面為大家解析一下SSL協議的工作過程。

SSL客戶端與SSL服務端驗證的過程如下：

1. SSL客戶端向SSL服務端傳送隨機訊息ClientHello的同時把自己支援的SSL版本、加密演算法、祕鑰交換演算法、MAC演算法等資訊一併傳送；
2. SSL服務端收到SSL客戶端的請求後，確定本次通訊採用的SSL版本及加密元件和MAC演算法，並通過ServerHello傳送給SSL客戶端；
3. SSL服務端將攜帶自己公鑰資訊的數字證書通過Certificate傳送給SSL客戶端；
4. SSL服務端通過ServerHelloDone訊息通知SSL客戶端版本和加密元件協商結束，開始進行祕鑰交換；
5. SSL客戶端驗證SSL服務端傳送的證書合法後，利用證書中的公鑰加密隨機數生成ClientKeyExchange傳送給SSL服務端；
6. SSL客戶端傳送ChangeCipherSpec訊息，通知SSL服務端後續將用協商好的祕鑰及加密元件和MAC值；
7. SSL客戶端計算已互動的握手訊息的hash值，利用協商好的祕鑰和加密元件加密hash值，並通過Finished訊息傳送給SSL服務端，SSL服務端用相同的方法計算已互動的hash值，並與Finished訊息進行對比，二者相同且MAC值相同，則祕鑰和加密元件協商成功；
8. 同樣地，SSL服務端也通過ChangeCipherSpec訊息通知客戶端後續報文將採用協商好的祕鑰及加密元件和MAC演算法；
9. SSL服務端端計算已互動的握手訊息的hash值，利用協商好的祕鑰和加密元件加密hash值，並通過Finished訊息傳送給SSL客戶，SSL客戶端用相同的方法計算已互動的hash值，並與Finished訊息進行對比，二者相同且MAC值相同，則祕鑰和加密元件協商成功；

通過上面的這個互動過程，我們可以看出，在使用SSL的過程中，除了客戶端（瀏覽器）跟伺服器之間的通訊外，其他的任何第三方想要獲取到協商的祕鑰是比較困難的。即使有比較厲害的人獲取到了，基於目前使用者在某個網站上的時效性，會影響我們對應祕鑰的時效性，因此，造成的破壞性也比較有限。

4 APP

在APP層的安全問題，需要結合服務端一併來解決，在這主要介紹驗證碼這種形式。驗證碼作為一種人機識別手段，其主要作用是區分正常人操作還是機器的操作，攔截惡意行為。當前網際網路中，大多數系統為了更好地提供服務，通常都需要使用者進行註冊。註冊後，使用者每次在使用系統時需要進行登入，登入過程中，為了防止系統非法使用，通常都需要使用者進行登入操作，登入過程中，常用的驗證方式主要通過驗證碼進行驗證，當前比較常用的驗證碼有以下幾種型別。

4.1 簡訊驗證碼

目前用得比較廣泛的一種驗證碼形式，輸入有效的手機號後，系統給手機號傳送相應的簡訊驗證碼完成驗證。

4.2 語音驗證碼

通過輸入有效的手機號，系統給手機號撥打電話後，用語音播報的方式完成驗證碼的驗證。

4.3 圖片驗證碼

較傳統的驗證碼驗證方式，由系統給出驗證碼在頁面顯示，在進行頁面提交時，驗證碼一併提交到系統後臺驗證。

4.4 語義驗證碼

比較新穎的一種驗證碼形式，但是該種方式相比較而言對使用者不是特別友好，需要慎用。

除了上述的幾種目前常用的驗證碼外，還有文字驗證碼、拼圖驗證碼、問題類驗證碼等，在此就不再一一列舉，大家如果感興趣可以自己去搜索、學習。

這主要從系統的架構上，分析了日常工作中我們所接觸到的比較常見的一些安全問題及其應對措施，在實際工作的安全問題遠不止這裡提到的內容。希望在日常工作中，我們大家都繃緊安全的神經，時刻關注自己工作中的各類潛在的安全問題，爭取把安全問題消滅在系統釋出前。

5 參考文獻

SSL是如何加密傳輸的資料的：
[技術每日說] - SSL是如何加密傳輸的資料的!

名詞解釋：

• SSL：（Secure Socket Layer，安全套接字層），位於可靠的面向連線的網路層協議和應用層協議之間的一種協議層。SSL通過互相認證、使用數字簽名確保完整性、使用加密確保私密性，從而實現客戶端和伺服器之間的安全通訊。該協議由兩層組成：SSL記錄協議和SSL握手協議。
• HTTPS：（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標的HTTP通道，簡單講是HTTP的安全版（HTTP+SSL）。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。

---

作者：廖宗雄