如何從系統(tǒng)架構(gòu)分析安全問題

作者 |京東云開發(fā)者-廖宗雄

在日常生產(chǎn)生活中，我們常說，“安全第一”、“安全無小事”。圍繞著安全問題，在各行各業(yè)都有對各類常見安全問題的解決方案和突發(fā)安全問題的應(yīng)急預(yù)案。在互聯(lián)網(wǎng)、軟件開發(fā)領(lǐng)域，我們?nèi)粘９ぷ髦袑Ω黝惓Ｒ姷陌踩珕栴}又有哪些常見的解決方案呢？在此，結(jié)合經(jīng)典架構(gòu)圖做一個梳理。

經(jīng)典架構(gòu)圖 下面，結(jié)合上述的經(jīng)典架構(gòu)圖，對數(shù)據(jù)存儲、微服務(wù)接口、外網(wǎng)數(shù)據(jù)傳輸及 APP 層可能出現(xiàn)的安全問題進行分析，并給出一些常見的應(yīng)對措施。

1 數(shù)據(jù)存儲

為了保證數(shù)據(jù)存儲的安全，對于敏感數(shù)據(jù)在進行存儲時，需要進行加密存儲，同時，敏感數(shù)據(jù)建議在全公司進行收口管理，便于統(tǒng)一管理。對敏感數(shù)據(jù)進行加密存儲時，常見的加密方式有可逆加密和不可逆加密，分別適用于不同的敏感數(shù)據(jù)。

1.1 可逆加密或?qū)ΨQ加密

可逆加密，即通過對密文進行解密后，能把密文解密還原出明文。對稱加密算法加密和解密用到的密鑰是相同的，這種加密方式加密速度非?？?，適合經(jīng)常發(fā)送數(shù)據(jù)的場合，缺點是密鑰的傳輸比較麻煩。比如：網(wǎng)絡(luò)購物的收貨地址、姓名、手機號等就適合用該加密方式，常用的對稱加密算法有 DES、AES，下面以 AES 為例說明對稱加密的過程。

在該加解密中，對于秘鑰 K 的生成需要加解密雙方共同制定并妥善保管。通常，我們會把該秘鑰 K 存儲在需要使用加解密程序的進程內(nèi)，便于在程序使用時直接進行使用。 1.2 不可逆加密 不可逆加密，即不需要解密出明文，如：用戶的密碼。不可逆加密常用的算法有 RES、MD5 等，在此以 MD5 為例進行說明。但大家都知道，MD5 算法是存在碰撞的，即不同的明文通過 MD5 加密后，存在相同的密文。因此，直接使用 MD5 對密碼進行加密在生產(chǎn)上是不嚴謹?shù)?，通常還需要配合鹽（salt）進行使用。對于鹽的使用，也有一定的技巧，一種鹽值是固定的，即所有的明文在進行加密時都使用相同的鹽進行加密；另一種是結(jié)合具體的業(yè)務(wù)場景，用可變鹽值，比如：就密碼加密而言，可以把用戶名的部分或全部作為鹽值，和密碼進行一起加密后存儲。

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

除了對請求鑒權(quán)外，在實際的生產(chǎn)中，還可以對請求容量進行限制，對請求容量進行限制時，可以按 QPS 進行限制，也可以對每天的最大請求次數(shù)進行限制。在 jsf 平臺管理端，可以對具體的方法進行請求的 QPS 限流。 3 數(shù)據(jù)傳輸數(shù)據(jù)傳輸主要分為數(shù)據(jù)通過前端 APP 的請求，進入到服務(wù)網(wǎng)關(guān)前和進入服務(wù)網(wǎng)關(guān)后這倆部分，對于數(shù)據(jù)已經(jīng)進入服務(wù)網(wǎng)關(guān)后，這屬于機房內(nèi)的數(shù)據(jù)傳輸，通常這類加密意義不大，對這類的數(shù)據(jù)傳輸?shù)陌踩枰⑾鄳?yīng)的內(nèi)部安全機制及流程規(guī)范，通過制度措施來保證。而數(shù)據(jù)在進入服務(wù)網(wǎng)關(guān)前，對數(shù)據(jù)的安全傳輸有哪些可做的。在數(shù)據(jù)請求進入服務(wù)網(wǎng)關(guān)前，通常我們有基于 SSL 協(xié)議的傳輸加密以及現(xiàn)在普遍通用的 HTTPS 加密。

HTTPS 也是 HTTP 和 SSL 協(xié)議的結(jié)合體，所以在數(shù)據(jù)傳輸中，SSL 協(xié)議扮演了至關(guān)重要的角色。那 SSL 協(xié)議的工作過程是怎么樣的，他是怎么保證數(shù)據(jù)傳輸過程中的安全的呢？下面為大家解析一下 SSL 協(xié)議的工作過程。

SSL 客戶端與 SSL 服務(wù)端驗證的過程如下：

SSL 客戶端向 SSL 服務(wù)端發(fā)送隨機消息 ClientHello 的同時把自己支持的 SSL 版本、加密算法、秘鑰交換算法、MAC 算法等信息一并發(fā)送；

SSL 服務(wù)端收到 SSL 客戶端的請求后，確定本次通信采用的 SSL 版本及加密組件和 MAC 算法，并通過 ServerHello 發(fā)送給 SSL 客戶端；

SSL 服務(wù)端將攜帶自己公鑰信息的數(shù)字證書通過 Certificate 發(fā)送給 SSL 客戶端；

SSL 服務(wù)端通過 ServerHelloDone 消息通知 SSL 客戶端版本和加密組件協(xié)商結(jié)束，開始進行秘鑰交換；

SSL 客戶端驗證 SSL 服務(wù)端發(fā)送的證書合法后，利用證書中的公鑰加密隨機數(shù)生成 ClientKeyExchange 發(fā)送給 SSL 服務(wù)端；

SSL 客戶端發(fā)送 ChangeCipherSpec 消息，通知 SSL 服務(wù)端后續(xù)將用協(xié)商好的秘鑰及加密組件和 MAC 值；

SSL 客戶端計算已交互的握手消息的 hash 值，利用協(xié)商好的秘鑰和加密組件加密 hash 值，并通過 Finished 消息發(fā)送給 SSL 服務(wù)端，SSL 服務(wù)端用相同的方法計算已交互的 hash 值，并與 Finished 消息進行對比，二者相同且 MAC 值相同，則秘鑰和加密組件協(xié)商成功；

同樣地，SSL 服務(wù)端也通過 ChangeCipherSpec 消息通知客戶端后續(xù)報文將采用協(xié)商好的秘鑰及加密組件和 MAC 算法；

SSL 服務(wù)端端計算已交互的握手消息的 hash 值，利用協(xié)商好的秘鑰和加密組件加密 hash 值，并通過 Finished 消息發(fā)送給 SSL 客戶，SSL 客戶端用相同的方法計算已交互的 hash 值，并與 Finished 消息進行對比，二者相同且 MAC 值相同，則秘鑰和加密組件協(xié)商成功；

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

4 APP在 APP 層的安全問題，需要結(jié)合服務(wù)端一并來解決，在這主要介紹驗證碼這種形式。驗證碼作為一種人機識別手段，其主要作用是區(qū)分正常人操作還是機器的操作，攔截惡意行為。當前互聯(lián)網(wǎng)中，大多數(shù)系統(tǒng)為了更好地提供服務(wù)，通常都需要用戶進行注冊。注冊后，用戶每次在使用系統(tǒng)時需要進行登錄，登錄過程中，為了防止系統(tǒng)非法使用，通常都需要用戶進行登錄操作，登錄過程中，常用的驗證方式主要通過驗證碼進行驗證，當前比較常用的驗證碼有以下幾種類型。

4.1 短信驗證碼 目前用得比較廣泛的一種驗證碼形式，輸入有效的手機號后，系統(tǒng)給手機號發(fā)送相應(yīng)的短信驗證碼完成驗證。

4.2 語音驗證碼 通過輸入有效的手機號，系統(tǒng)給手機號撥打電話后，用語音播報的方式完成驗證碼的驗證。

4.3 圖片驗證碼 較傳統(tǒng)的驗證碼驗證方式，由系統(tǒng)給出驗證碼在頁面顯示，在進行頁面提交時，驗證碼一并提交到系統(tǒng)后臺驗證。

4.4 語義驗證碼 比較新穎的一種驗證碼形式，但是該種方式相比較而言對用戶不是特別友好，需要慎用。 除了上述的幾種目前常用的驗證碼外，還有文本驗證碼、拼圖驗證碼、問題類驗證碼等，在此就不再一一列舉，大家如果感興趣可以自己去搜索、學習。 這主要從系統(tǒng)的架構(gòu)上，分析了日常工作中我們所接觸到的比較常見的一些安全問題及其應(yīng)對措施，在實際工作的安全問題遠不止這里提到的內(nèi)容。希望在日常工作中，我們大家都繃緊安全的神經(jīng)，時刻關(guān)注自己工作中的各類潛在的安全問題，爭取把安全問題消滅在系統(tǒng)發(fā)布前。

5 參考文獻

SSL 是如何加密傳輸?shù)臄?shù)據(jù)的：

［技術(shù)每日說］ - SSL 是如何加密傳輸?shù)臄?shù)據(jù)的！ 名詞解釋：

SSL：（Secure Socket Layer，安全套接字層），位于可靠的面向連接的網(wǎng)絡(luò)層協(xié)議和應(yīng)用層協(xié)議之間的一種協(xié)議層。SSL 通過互相認證、使用數(shù)字簽名確保完整性、使用加密確保私密性，從而實現(xiàn)客戶端和服務(wù)器之間的安全通訊。該協(xié)議由兩層組成：SSL 記錄協(xié)議和 SSL 握手協(xié)議。

HTTPS：（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標的 HTTP 通道，簡單講是 HTTP 的安全版（HTTP+SSL）。即 HTTP 下加入 SSL 層，HTTPS 的安全基礎(chǔ)是 SSL，因此加密的詳細內(nèi)容就需要 SSL。

作者：廖宗雄