各類常見安全問題的解決方案和突發(fā)安全問題的應急預案
在日常生產(chǎn)生活中，我們常說，“安全第一”、“安全無小事”。圍繞著安全問題，在各行各業(yè)都有對各類常見安全問題的解決方案和突發(fā)安全問題的應急預案。在互聯(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ǎng)數(shù)據(jù)傳輸及APP層可能出現(xiàn)的安全問題進行分析，并給出一些常見的應對措施。
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)絡購物的收貨地址、姓名、手機號等就適合用該加密方式，常用的對稱加密算法有DES、AES，下面以AES為例說明對稱加密的過程。
在該加解密中，對于秘鑰K的生成需要加解密雙方共同制定并妥善保管。通常，我們會把該秘鑰K存儲在需要使用加解密程序的進程內(nèi)，便于在程序使用時直接進行使用。
1.2 不可逆加密
不可逆加密，即不需要解密出明文，如：用戶的密碼。不可逆加密常用的算法有RES、MD5等，在此以MD5為例進行說明。但大家都知道，MD5算法是存在碰撞的，即不同的明文通過MD5加密后，存在相同的密文。因此，直接使用MD5對密碼進行加密在生產(chǎn)上是不嚴謹?shù)?，通常還需要配合鹽（salt）進行使用。對于鹽的使用，也有一定的技巧，一種鹽值是固定的，即所有的明文在進行加密時都使用相同的鹽進行加密；另一種是結(jié)合具體的業(yè)務場景，用可變鹽值，比如：就密碼加密而言，可以把用戶名的部分或全部作為鹽值，和密碼進行一起加密后存儲。
2 微服務接口
微服務的安全，需要從請求鑒權(quán)和請求容量限制這2個方面來考慮。對于請求鑒權(quán)，可以設置請求IP黑名單的方式，對該IP的所有請求或全部放行或全部拒絕，該方式的粒度較粗。而如果要做得較細粒度一些，可以針對具體的API進行token鑒權(quán)，相比粗粒度該方式會控制得比較精準；
<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> 復制代碼
除了對請求鑒權(quán)外，在實際的生產(chǎn)中，還可以對請求容量進行限制，對請求容量進行限制時，可以按QPS進行限制，也可以對每天的最大請求次數(shù)進行限制。在jsf平臺管理端，可以對具體的方法進行請求的QPS限流。
3 數(shù)據(jù)傳輸
數(shù)據(jù)傳輸主要分為數(shù)據(jù)通過前端APP的請求，進入到服務網(wǎng)關(guān)前和進入服務網(wǎng)關(guān)后這倆部分，對于數(shù)據(jù)已經(jīng)進入服務網(wǎng)關(guān)后，這屬于機房內(nèi)的數(shù)據(jù)傳輸，通常這類加密意義不大，對這類的數(shù)據(jù)傳輸?shù)陌踩枰⑾鄳膬?nèi)部安全機制及流程規(guī)范，通過制度措施來保證。而數(shù)據(jù)在進入服務網(wǎng)關(guān)前，對數(shù)據(jù)的安全傳輸有哪些可做的。在數(shù)據(jù)請求進入服務網(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服務端驗證的過程如下：
SSL客戶端向SSL服務端發(fā)送隨機消息ClientHello的同時把自己支持的SSL版本、加密算法、秘鑰交換算法、MAC算法等信息一并發(fā)送；
SSL服務端收到SSL客戶端的請求后，確定本次通信采用的SSL版本及加密組件和MAC算法，并通過ServerHello發(fā)送給SSL客戶端；
SSL服務端將攜帶自己公鑰信息的數(shù)字證書通過Certificate發(fā)送給SSL客戶端；
SSL服務端通過ServerHelloDone消息通知SSL客戶端版本和加密組件協(xié)商結(jié)束，開始進行秘鑰交換；
SSL客戶端驗證SSL服務端發(fā)送的證書合法后，利用證書中的公鑰加密隨機數(shù)生成ClientKeyExchange發(fā)送給SSL服務端；
SSL客戶端發(fā)送ChangeCipherSpec消息，通知SSL服務端后續(xù)將用協(xié)商好的秘鑰及加密組件和MAC值；
SSL客戶端計算已交互的握手消息的hash值，利用協(xié)商好的秘鑰和加密組件加密hash值，并通過Finished消息發(fā)送給SSL服務端，SSL服務端用相同的方法計算已交互的hash值，并與Finished消息進行對比，二者相同且MAC值相同，則秘鑰和加密組件協(xié)商成功；
同樣地，SSL服務端也通過ChangeCipherSpec消息通知客戶端后續(xù)報文將采用協(xié)商好的秘鑰及加密組件和MAC算法；
SSL服務端端計算已交互的握手消息的hash值，利用協(xié)商好的秘鑰和加密組件加密hash值，并通過Finished消息發(fā)送給SSL客戶，SSL客戶端用相同的方法計算已交互的hash值，并與Finished消息進行對比，二者相同且MAC值相同，則秘鑰和加密組件協(xié)商成功；
通過上面的這個交互過程，我們可以看出，在使用SSL的過程中，除了客戶端（瀏覽器）跟服務器之間的通訊外，其他的任何第三方想要獲取到協(xié)商的秘鑰是比較困難的。即使有比較厲害的人獲取到了，基于目前用戶在某個網(wǎng)站上的時效性，會影響我們對應秘鑰的時效性，因此，造成的破壞性也比較有限。
4 APP
在APP層的安全問題，需要結(jié)合服務端一并來解決，在這主要介紹驗證碼這種形式。驗證碼作為一種人機識別手段，其主要作用是區(qū)分正常人操作還是機器的操作，攔截惡意行為。當前互聯(lián)網(wǎng)中，大多數(shù)系統(tǒng)為了更好地提供服務，通常都需要用戶進行注冊。注冊后，用戶每次在使用系統(tǒng)時需要進行登錄，登錄過程中，為了防止系統(tǒng)非法使用，通常都需要用戶進行登錄操作，登錄過程中，常用的驗證方式主要通過驗證碼進行驗證，當前比較常用的驗證碼有以下幾種類型。
4.1 短信驗證碼
目前用得比較廣泛的一種驗證碼形式，輸入有效的手機號后，系統(tǒng)給手機號發(fā)送相應的短信驗證碼完成驗證。
4.2 語音驗證碼
通過輸入有效的手機號，系統(tǒng)給手機號撥打電話后，用語音播報的方式完成驗證碼的驗證。
4.3 圖片驗證碼
較傳統(tǒng)的驗證碼驗證方式，由系統(tǒng)給出驗證碼在頁面顯示，在進行頁面提交時，驗證碼一并提交到系統(tǒng)后臺驗證。
4.4 語義驗證碼
比較新穎的一種驗證碼形式，但是該種方式相比較而言對用戶不是特別友好，需要慎用。
除了上述的幾種目前常用的驗證碼外，還有文本驗證碼、拼圖驗證碼、問題類驗證碼等，在此就不再一一列舉，大家如果感興趣可以自己去搜索、學習。
這主要從系統(tǒng)的架構(gòu)上，分析了日常工作中我們所接觸到的比較常見的一些安全問題及其應對措施，在實際工作的安全問題遠不止這里提到的內(nèi)容。希望在日常工作中，我們大家都繃緊安全的神經(jīng)，時刻關(guān)注自己工作中的各類潛在的安全問題，爭取把安全問題消滅在系統(tǒng)發(fā)布前。
5 參考文獻
SSL是如何加密傳輸?shù)臄?shù)據(jù)的：
有軟官網(wǎng)
名詞解釋：
SSL：（Secure Socket Layer，安全套接字層），位于可靠的面向連接的網(wǎng)絡層協(xié)議和應用層協(xié)議之間的一種協(xié)議層。SSL通過互相認證、使用數(shù)字簽名確保完整性、使用加密確保私密性，從而實現(xiàn)客戶端和服務器之間的安全通訊。該協(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。
參考鏈接：https://www.jiaruvip.com/author
