學習轉載：存儲加密和傳輸加密的審計要點
存儲加密和傳輸加密的審計要點
近年來，隨着移動互聯網的高速發展，在人們享受網絡帶來便利的同時，信息安全也逐漸成爲大衆關注的熱點。
2021年落地的《中華人民共和國個人信息保護法》中第五十一條中明確提到，對於個人信息處理者的義務：採取相應的加密、去標識化等安全技術措施。2016年頒佈的《中華人民共和國網絡安全法》中第二十一條也對加密處理有所提及：採取數據分類、重要數據備份和加密等措施。
除去法律在廣義上提出的加密要求，常見的數據安全標準如：ISO/IEC 27002、GB/T 22239-2019 網絡安全等級保護、PCI DSS中均對於數據傳輸以及數據存儲有具體的加密要求。
本文將分別羅列出上述數據安全標準對於存儲加密與傳輸加密的要求原文，以及在筆者過去的審計工作中，對於不同場景下的審計要點總結。
數據安全標準篇
常見的數據安全標準以及具體的技術要求點呈現如下:
第一個:《ISO/IEC 27002:2022 Information security, cybersecurity and privacy protection - Information security controls》
要求8.24 其他信息
a）機密性：使用信息加密來保護存儲或傳輸的敏感或關鍵信息。
原文：confidentiality: using encryption of information to protect sensitive or critical information, either stored or transmitted.
第二個:《Payment Card Industry Data Security Standard version 4.0》
要求8.3.2
在傳輸和存儲所有系統組件期間，使用強效加密算法使所有驗證因素不可讀。
原文：Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components.
第三個:《GB/T 22239-2019信息安全技術 網絡安全等級保護安全設計技術要求》
要求9.1.2.2 通信傳輸
b) 應採用密碼技術保證通信過程中數據的保密性；
要求9.1.4.8 數據保密性
a) 應採用密碼技術保證重要數據在傳輸過程中的保密性，包括但不限於鑑別數據、重要業務數據和重要個人信息等；
b) 應採用密碼技術保證重要數據在存儲過程中的保密性，包括但不限於鑑別數據、重要業務數據和重要個人信息等。
審計實戰篇
對於傳輸加密，運維工程師需要查看瀏覽器地址欄的HTTPS證書判斷加密強度；對於存儲加密，研發工程師需要關注代碼中對敏感數據調用的加密方法。審計過程中，涉及數據存儲與數據傳輸兩方面的加密場景遠不止於此，審計師不僅需要關注加密強度、加密算法、密鑰長度，還需要判斷並定位加密環節的全生命週期，如密鑰的生成、分配、存儲、替換、銷燬等環節。
企業實際生產環境中涉及數據存儲與數據傳輸的場景紛繁複雜，部分場景甚至涉及多處加密方案的部署，因此無法將安全合規建設寄託於“一招鮮，喫遍天”的解決方案。企業如何自查才能更有效的滿足安全合規要求？筆者結合過去經驗，依次梳理出幾大經典場景並展開描述，希望爲從業者在實操環節起到拋磚引玉的作用。
存儲加密的場景
場景1：常規網絡設備與常見操作系統的密碼加密存儲
在傳統的用戶登錄系統過程中，多采用“用戶名+密碼”的登錄方式，即根據用戶輸入的一串固定的靜態密碼來實現用戶身份鑑別。目前仍有大部分場景使用該驗證方式，如登錄操作系統、應用軟件、網絡設備、安全設備等。
儘管場景不同，但系統對密碼的處理方式大致相似。用戶設定密碼之後，大多數系統會對其執行不可逆的單向散列操作，包括但不限於MD5、SHA-1、SHA-2（SHA-256、SHA-512）等方式；除此之外，部分系統也支持對密碼進行可逆的加密處理，如3DES、AES（AES-128、AES-256）、RSA（RSA-2048、RSA-4096）等方式。
對於網絡設備和Linux操作系統，審計師通常會在命令行界面使用root權限賬戶執行查詢命令，根據返回的結果來判斷密碼存儲選用的加密方案。拿Linux和採用Linux內核開發的系統舉例，輸入cat /etc/shadow後，機器會輸出密文狀態的密碼及加密方案，可以根據“$$”之間的數字判斷加密方案。
對於原生Linux系統，也可以根據系統版本不同，分別執行命令見表。系統直接反饋密碼加密存儲方案，見圖2。
場景2：常見安全設備的密碼存儲加密
在筆者曾經參與過的審計項目中，大部分企業會部署4A認證設備（認證Authentication、授權Authorization、賬號Account、審計Audit）、堡壘機或跳板機等安全設備，用於工程師進行運維操作前的統一身份認證。無論上述安全設備是軟件部署或硬件設施，原理均爲將目標機器登錄時配置的靜態密碼或私鑰託管至安全設備，工程師在安全設備上完成身份認證後，可根據預先配置的資源訪問權限，支持免密碼輸入的方式自動跳轉到權限內的目標機器。此過程至少涉及到三處存儲加密的場景，羅列如下：
-
目標機器的靜態密碼加密存儲在安全設備上；
-
目標機器的私鑰加密存儲在安全設備上；
-
用於登錄安全設備的靜態密碼加密存儲在安全設備上。
場景1和場景2中涉及的加密算法多爲對稱加密算法，場景3則常見於對密碼執行單向散列算法。對於開源的安全設備，可通過閱讀源代碼的方式查看上述場景中分別對應的加密算法；對於一些商業軟件，由於商業機密等原因，廠商大多無法告知相關配置信息，因此審計師可以通過廠商公開的白皮書來確定密碼加密強度。
場景3：常見數據庫軟件與應用服務系統對密碼的存儲加密
在數據安全的審計中，審計師也需要關注應用系統的密碼加密存儲方案。篇幅有限，此處僅提及三處經典場景，羅列如下：
-
數據庫軟件，用戶登錄密碼加密存儲方案；
-
應用服務器，可訪問數據庫的配置文件，登錄數據庫的用戶名和密碼加密存儲方案；
-
Web應用，如果支持用戶登錄操作，用戶登錄密碼存儲在數據庫表中的加密存儲方案。
近幾年，筆者發現越來越多的企業在生產環境中單獨部署一臺服務器作爲配置中心，對用於訪問數據庫的配置文件進行加密存儲。每次應用服務器訪問數據庫前，單獨通過腳本去配置中心拉取對應的配置文件，調用解密接口服務後，獲得明文密碼，完成後續作業。
傳輸加密的場景
場景1：使用SSH協議進行設備和服務器管理
日常運維工作中，除去運維工程師在機房通過網線直連的控制檯（console）方式對生產環境進行維護，更多常見於（遠程控制）非控制檯（non-console）的方式，即通過網絡接口的邏輯訪問執行運維作業。在對生產環境非Windows OS設備的遠程訪問中，不同的網絡協議對應的加密方案見表。
基於傳輸加密的出發點，大部分企業已由Telnet協議整改爲SSH v2協議，FTP或TFTP協議升級爲SFTP協議。其中SSH協議於2006年由v1升級至v2，在v1支持的3DES、Blowfish加密算法的基礎上，新版本v2捨棄了DES和IDEA加密算法，增加了AES、CAST-128及RC4加密算法。
在客戶端與服務端建立SSH協議後，雙方共同協商一個會話密鑰對傳輸數據進行加密。客戶端和服務端默認支持全部加密算法，包括弱加密算法，因此筆者會建議企業對服務端的/etc/ssh/sshd_config進行加固，通過配置服務端指定的強加密算法的方式完成對SSH協議的加固。加固方案如下，對該配置文件進行編輯，在最後一行處增加下列內容：
shellCiphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,aes192-cbc,aes256-cbc
場景2：使用遠程桌面協議（RDP）進行Windows服務器運維
對於將生產環境部署在Windows服務器的企業，日常運維工作則是建立在客戶端與服務端的RDP協議上，目前微軟已將各Windows OS對於安全協議的支持情況發佈在官網，見表4。
注：Windows Server 2008及2008 R2可通過安裝補丁包的方式啓用TLS1.1/1.2
Windows OS的支持多種TLS密碼套件，具體選用的套件按照默認的優先級順序依次啓用，支持用戶通過安裝補丁包的方式添加新的密碼套件並更改優先級。
加密方案則由服務端進行配置。進入註冊表路徑，查看Security Layer在路徑\HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\MinEncryptionLevel的鍵值，不同鍵值對應關係見表。
場景3：使用HTTPS協議進行設備或系統管理
HTTPS協議是由HTTP協議與SSL/TLS協議共同構建而成，後者作用於TCP協議之上，HTTP協議之下，實現數據加密傳輸與身份認證的功能。SSL v1問世於1995年3月，截止至今，已升級至TLS v1.3。隨着版本的升級，協議的安全性也在不斷加強，舊版本也因自身存在的安全問題逐漸退出歷史舞臺。在2016年發佈的PCI DSS v3.2.1中，就已經明確要求2018年6月30後禁止支持SSL協議及早期TLS協議（即TLS v1.0）。
對HTTPS協議的審計關注點是當前網站或接口配置的SSL/TLS協議版本，需要審計師確定數據流量走向並梳理出部署HTTPS證書的位置，包括但不限於WAF設備、負載均衡設備、Web服務器等，確認設備後根據配置信息來判斷當前HTTPS協議是否支持不安全的SSL/TLS版本。
同Windows OS，HTTPS協議對於密碼套件的選擇也是按照默認的優先級順序依次啓用。目前HTTPS協議支持用戶配置多種加密套件，如密鑰交換算法、身份交換算法、加密算法、加密密鑰長度、加密模式等，具體的加密套件構成見圖。
加密套件的配置原則與SSH協議加固方案類似：放棄弱算法，如DES、MD5、RC4、IDEA；選用強算法，如ECDHE、RSA、AES、SHA256或以上。
總結
數據傳輸和數據存儲安全是企業信息安全的一道至關重要的防線，每一處的加密強度的提升都可以看做是企業邁向信息安全的一小步，正所謂不積跬步無以至千里，本文對部分關鍵環節中存儲加密及傳輸加密存在的風險及控制措施進行研究、分析，希望能夠爲企業數據合規建設提供一些思路和方向，提高信息安全管理效率及效果。