本博客地址：https://security.blog.csdn.net/article/details/121619552

一、引子

在专栏开篇作中我有提到数据安全架构中的5A概念，5A概念中的其中一个A是资产保护，因此，本篇我们来聊聊资产保护相关的东西。

资产保护就是保护资产全生命周期的安全性。资产包括数据与资源两大类，其中对数据的保护是资产保护的重中之重。保护范围包括数据的生成、使用、流转、传输、存储在内的全生命周期的安全管控，以数据的安全使用、安全传输、安全存储、安全披露、安全流转与跟踪为目标。

二、安全存储

首先是存储加密，加密是防止原始数据被窃取之后导致里面的敏感信息泄露的典型手段，比如数据库文件被拖走。如果数据经过加密，则即使黑客拿到了数据库文件，也会因为无法解密而保护原始信息不泄露。

对于加密存储，这其中的一个问题就是哪些数据需要做加密？对于这个问题，我们结合当前的各项监管政策和国际、国内的合规要求，以及加解密对业务场景的适配度，建议如下：

● 敏感个人信息以及涉及个人隐私的数据，需要加密存储。
● 口令、加解密密钥、私钥，需要加密存储。
● 有明确检索、排序、求和等运算需求的业务数据，不需要加密存储。

对于其他场景，则需要结合业务实际情况进行判断。

这里科普一下字段加密和静态加密：

● 字段加密：是指在应用层加密后再写入数据库，数据库管理员通过控制台查询，看到的也是密文，因此字段加密的安全性高，可以防DBA。
● 静态加密：通常是指存储侧自动完成的底层加密，开发人员不用关注底层加密细节，继续按照之前未加密的方式进行读写，应用层看到的是明文，数据库管理员通过控制台查询，看到的也是明文，不能防DBA。

在实践中，加密后会产生一个问题，就是对加密后的数据进行检索。这个问题目前还没有很好的解决方案，一般的折中性做法是：

● 添加关键词（Keyword）用于辅助检索，首先根据关键词缩小范围，然后对单个或相关的记录执行解密。
● 增加辅助字段，缩小范围。

而对于结构化数据（数据库、Key-Value等），加密主要有两种方式：

● 字段加密：数据在入库前加密，直接向数据库中写入字段密文。
● 静态加密：加密仅在存储系统内部自动完成，应用系统还是继续使用明文。

上面每种方式分别又有两种管理密钥的方式：

● 自管理密钥。
● KMS（密钥管理系统）。

这几种方式都可以防止黑客在主机层窃取数据库文件后导致的数据泄露。对比的话，如下：

加密方式	密钥管理	优缺点
字段加密	KMS	应用系统需要改进且改进难度较大；最安全，可防止DBA泄密
字段加密	应用自管理	应用系统需要改进且改进难度较大；可防止DBA泄密，但入侵可能导致加密密钥泄露，安全性次之
静态加密	KMS	应用系统不需要改进，存储系统改进后适合大规模推广；用于结构化数据加密时不能防止DBA泄密，安全性中等；用于非结构化数据加密时配合权限控制，安全性较好
静态加密	应用自管理	应用系统不需要改进，存储系统改进后一般自用，不适合大规模推广；安全性中等，不能防止DBA泄密

安全上一般首先使用字段加密，并通过KMS来实现。

三、安全传输

安全传输的目的就是保障传输过程中的安全性，既要达到保密的效果，也要确定传输的内容完整无误，即没有被篡改。

对于web应用，安全传输可通过部署全站HTTPS来实现。而对于客户端或手机APP，除了可以使用HTTPS和后台通信，还可以使用基于预共享密钥的认证加密机制。

数据的安全传输主要有以下两种方式：

● 应用层数据不加密，通道加密：建立一个安全的隧道，然后通过这个隧道传输明文内容（如HTTPS）。
● 应用层数据加密，通道不加密：直接在不安全的网络上，传输加密的内容（如AES-GCM）。

这里两个方案首选HTTPS，当然条件允许的话，既有通道加密又有数据加密也是极好的。

对于HTTPS证书，在申请的时候可以选择：

● 单域名证书：通过证书的“使用者”字段指定域名。
● 多域名证书：通过证书的“使用者可选名称”列出所有适用的域名。
● 通配型证书：通配型证书使用通配符*表示任意子域名。

这里需要注意的是，通配符匹配的域名中不包括小数点，例如*.example.com可以用于aaa.example.com、bbb.example.com等域名，但不能用于ccc.aaa.example.com。如果需要用于ccc.aaa.example.com，可以申请适用于*.aaa.example.com的通配型证书，或者单独为该域名申请单域名证书。

除了证书外，TLS协议安全也是安全传输的重要一环。对于TLS协议安全，一般有如下建议：

● 禁止使用SSL的全部版本（SSLv1～SSLv3）以及TLS 1.0版本，建议使用TLS 1.2或以上版本。
● 密码算法应只使用前向安全算法，这可保障当前会话的加密密钥泄露时不会影响到历史通信记录的安全性。
● 启用HSTS，强制浏览器跳转到HTTPS。

这里科普一下前向安全算法：

前向安全就是在长期密钥（或称为主密钥）泄露之后，以后的通信安全无法保证，但不会导致过去的会话密钥泄露（因为长期密钥产生的用于加密数据的临时密钥会随时间更新），或者说能够保护过去的通信不受长期密钥在将来泄露的影响，从而保障了历史通信的安全（被监听到的历史加密数据无法被解密）。

四、展示与脱敏安全

数据脱敏，即按照一定的规则对数据进行变形、隐藏或部分隐藏处理，让处理后的数据不会泄露原始的敏感数据，实现对敏感数据的保护，例如手机号脱敏后可为138********。

在需要展示一些比较敏感的数据，特别是个人信息的时候，需要执行严格的脱敏，防止用户个人信息泄露。展示的位置包括网页、PC客户端软件、手机APP等。

另外，当业务确实需要使用明文信息怎么办呢？例如如员工查询其他同事的手机号码、客服人员核对用户身份等。

针对这些业务规则允许查询的场景，基于受控的原则，可以在脱敏的信息旁边添加一个查询按钮（或者直接点击脱敏信息本身触发新的请求），允许有需要的员工查询，但一次只能查询一条明文记录。所谓受控，就是让风险在可以接受的范围之内，允许被授权的员工查询，但是在正常业务场景下，需要查询的次数是有限的，且系统会记录查询日志。如果发生用户信息泄露事件，日志信息可用于追溯。

五、完整性校验

一般情况下，可用于完整性校验的手段包括：

● 单向散列：多用于文件下载，用户通过把下载文件的散列值跟网站上公布的散列值进行比对来判断文件是否被篡改。
● HMAC：多用于后台消息传递时的完整性校验，但对消息本身没有加密保护。
● AES-GCM：在保障身份认证、数据加密的同时，提供完整性保障。
● 数字签名（即使用私钥加密）：由于篡改后会导致无法解密，从而也保障了完整性。