学习转载：存储加密和传输加密的审计要点
近年来，随着移动互联网的高速发展，在人们享受网络带来便利的同时，信息安全也逐渐成为大众关注的热点。
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或以上。
数据传输和数据存储安全是企业信息安全的一道至关重要的防线，每一处的加密强度的提升都可以看做是企业迈向信息安全的一小步，正所谓不积跬步无以至千里，本文对部分关键环节中存储加密及传输加密存在的风险及控制措施进行研究、分析，希望能够为企业数据合规建设提供一些思路和方向，提高信息安全管理效率及效果。