2018-09-15
首发专栏：飞哥安全观
本文不讨论加密算法，密码模式之类。只谈在企业应用中的加密应用，比如何时在数据库加密最佳，何时对应用加密，什么数据适合token化，如何把加密组件组合在一起。
在学校里，加密一直都是信息安全课程的主要内容。实际工作中，从密码到数据库到文件，也都用到加密进行保护。加密是每个安全人员的基本知识技能，也是安全保障的重要手段。
随着合规要求，企业上云，加密的需求也越来越多。但无论是安全人员和开发，真正能够说清楚加密方案的并不多。线上正在跑的生产进行数据加密，应该怎么同步？涉及到用户地址信息的加密，是在应用，还是在数据库或者存储里？是不是应该token化而不是AES加密？密钥怎么管理？–这些问题回到本质上来，是你在防范什么威胁，以及是否符合合规要求。
本文不讨论加密算法，密码模式之类。只谈在企业应用中的加密应用，比如何时在数据库加密最佳，何时对应用加密，什么数据适合token化，如何把加密组件组合在一起。
一、先搞清楚加密系统
课本里谈到加密，上来就是密钥，算法，模式，Bob和Alice的密码学故事，对称和不对称区别，这些基础当然很重要，但在实际工作中，重点就不在这里了，你要考虑的是把这些技术组合起来保护数据的方法，如果你的方案不对路子，多强大的算法也没用。
1、 加密系统组成
由三个部分组成：
（1）数据：要加密的对象，数据的位置对加密方案有很大影响。
（2）加密引擎：这个组件实际处理加解密操作。
（3）密钥管理：处理密钥，传递给加密引擎。
数据在哪里，加密在哪里，如何组合，是很多加密方案常见错误，这些组合决定了最终的安全性。
在基本加密系统里，这三个组件可能都在同一个系统，比如个人的全盘加密软件，密钥、引擎、数据都在同一个硬件，硬件丢了也就丢了引擎和KEY。这里的KEY，一般是用一个密码来保护，如果电脑在运行的情况下被盗，内存中的KEY就可能被盗。但对于更复杂的企业应用来说，这些组件是在不同的系统里的，这就增加了复杂性。
实际应用中会把这三个组件解耦，比如加密引擎是在应用里，数据在DB，密钥是专用设施管理。又或者DB里用的是TDE透明加密，引擎和数据在一个系统，但密钥在其他地方。
2、在哪里加密
所有的数据加密都是由数据所在位置来定义，层次上是：
（1）应用收集数据
（2）DB保存数据
（3）数据存储在文件
（4）文件驻留在存储卷（硬盘或虚拟存储等）
所有的数据都在这个层次中流动，加密越靠近应用安全性越高，但复杂度也更高，而且有些时候根本不可能做到。整个加密必然在这里的某一层进行，也就是你要决定在哪层加密。
3、为什么加密
做加密，无非三个原因：
（1） 数据移动，可能是物理，也可能是虚拟。
（2） 职责分离，例如防止运维人员看到数据。
（3） 有人要求你加密。
比如有人说，你必须加密所有手机号码。但这里又可以分解来看，目的是什么？目的如果是即使DBA账号被盗，数据也是安全的。存储层加密在这个需求里就没用，因为账号被盗之后，仍然可以在DB这一层访问。单独加密文件也没用，因为账号被授权在DB里工作，在这里数据不是加密的。
那在DB里加密呢？这就取决于密钥在哪，如果密钥也在数据库里，等于也没用，因此密钥必须在其他地方。也可以在应用层就做加密，完全脱离了DB。所以一个加密需求，一定要清楚威胁是什么，进一步来考虑实现，这个例子里需要防范的是DBA，那就要清楚DBA可以在什么位置访问解密数据。
4、Tokenization和Data Masking
除了加密，也有一些替代方案：
Tokenization：用随机的片段数据替换敏感数据，数据可以是相同格式。比如看起来是信用卡号，但实际上是随机的无效卡号。真正的敏感数据和token映射存在另外一个严格受控的数据库里，不敏感的token可以在整个系统中流转。
Data Masking：用随机数据取代敏感数据，和Tokenization不同，这两个数据并不存储对照。Masking可以是单向的，用在测试环境，也可用在动态Masking，基于权限的特定字段。
二、加密层
可以用4层结构理解加密层，应用在DB上，DB在文件上，文件在存储卷上。可以在这里每层做加密，也可以全加密。但加密引擎所在位置，一定是安全性和性能要求最高的位置。越往上安全性越高，复杂性和性能成本也高。
耦合越高，复杂性降低，安全性和可靠性就弱。构建加密需要在安全性、复杂性、性能之间平衡，尤其在大型分布式环境中这就更重要了。
1、应用层加密
数据在应用层进行加密，发给后端server，然后将加密数据存在db或文件钟。应用可以完全控制谁能看到什么内容，不需要依赖底层，密钥位于服务器或KMS。密钥独立管理增加安全性，简化管理，并且可以保证密钥数据的备份、恢复、同步之类的工作。
2、DB加密
关系型数据库一般提供透明加密和列加密两种。列加密位于应用向DB插入时。透明加密位于写入数据库时，在存储在文件或磁盘之前。加密和密钥不需要应用处理，数据库系统直接处理读取写入时的加解密操作，而且性能较好。
需要更细粒度的控制数据，可以对单个列、表进行加密，只有经过认证的用户才能访问，但需要修改应用和数据库。
这两个方法对开发的负担都比较小，但控制粒度也较弱。
业界也有第三方提供的透明数据库加密产品，在职责分离上有进一步增强作用。
3、文件加密
有些应用是不用数据库的，直接在文件中存数据，数据写到文件时进行透明加密，操作系统和第三方都可以提供这种加密，加解密对应用透明。用户验证身份后请求文件时则进行解密，验证失败则给出无用加密数据。文件加密通常用于保护应用中的“静止数据”，也是很多大数据平台的加密方法。
4、磁盘/卷加密
现在很多磁盘和存储都带有自动数据加密功能，磁盘加密是在数据写入磁盘时，未经过验证的身份/应用解密，企业级密钥管理一般依赖KMS，可进行密钥轮换。
5、权衡
前面说了，加密层越高越安全，代价是难以集成，需要动代码。在应用层加密可以充分利用身份验证、授权和业务流程来保证安全，但在现实中，这种精确的控制是难以实现成本高。
透明加密比应用层加密快，代价是相对来说安全较弱。
三、密钥管理
加密方案的核心是正确部署组件，这里对这个安全影响最大的是密钥管理。但实际上有很多加密是没有专门密钥管理的，可以武断地说，没有专用密钥管理的加密方案都不是好方案，任何时候方案里都要考虑具备专用的密钥管理。
1、密钥管理设施：
（1）、HSM或其他硬件密钥设备，有最高物理安全性，在金融和某些涉密机构，这是必选项，在各大云厂商也是标配。硬件根信任是最安全的选择，而且可以有硬件加速能力。
（2）、虚拟设备（实例）加密，可以不受物理地址限制，在所需要的地方运行，降低成本提高灵活性的同时，安全性也有降低。目前已知的问题，在某些虚拟化应用中可以从内存中提取密钥，也就是需要有内存保护方案。虚拟设备经过安全特殊加固，有的云安全允许用HSM作为硬件信任根，然后将密钥分发给虚拟设备，可以实现分布式方案的性能提高。
（3）、密钥管理软件，可以在专用设备上运行，也可在虚拟机运行，和虚拟设备的区别是需要自己安装密钥管理软件，安全性相对又弱一些，毕竟服务器/操作系统/虚拟化都是有漏洞的。
（4）、密钥管理软件即服务（SaaS）。云厂商密钥管理都是基本服务能力了，既支持公有云加密，也可以用来对私有云、混合云加密。
2、客户端访问
对客户端来说，则需要三个功能，分别是密钥生成、获取和生命周期（比如过期和密钥更换）。从操作上来说则需要访问控制，可以允许某个应用密钥获取但不允许密钥生成。整个访问也分为三种形式：
（1）agent：一个专用的agent处理密钥，一般是针对特定场景，例如原生全盘加密，特定备份加密，各种数据库加密等。有的agent设计时除了加密，也会进一步增强，比如每次使用后从内存中擦除密钥。
（2）API：KMS允许应用来访问，API需要考虑平台的支持，代码语言的支持以及易用性。
（3）协议和标准支持：KMS可以支持专有或开放协议，例如agent，只要在协议上达成一致就可以支持。开放协议目前用的不多，但将来会是发展方向。
四、其他功能考虑
除了以上的基本组件，加密方案还需要在不同环境下具备其他的服务支持能力，在企业环境中常见的需求包括：
1、 集中管理
密钥在一个统一位置更有利于集中保护，统一服务界面，统一密钥策略，访问控制，身份集成，以实现整个密钥的生态治理。整个系统环境越大越复杂，就越需要统一管理。
2、格式保留加密
加密是把数据加扰到不可读状态来保护，格式保留加密（FPE）也扰码到数据不可读，但保留原始数据格式，例如用FPE加密11位手机号，加密结果也是11位数字，这种加密至少也是AES级的，很难破解，原始数据在没有密钥的情况下难以恢复。FPE的好处是避免改代码和数据库来适应加密后的数据格式。
Tokenization和FPE的区别在，FPE加密混淆了敏感信息，Tokenization把数据完全转移到另外一个位置。如果业务需要加密后的数据（可能用于解密场景），那么用FPE。但说实话，大多数场景的解密需求都是伪需求，可以通过其他方式来解决。
3、Tokenization
Tokenization是用非敏感占位符（也就是token）替换敏感数据的方法，创建的token和替换值格式基本相同，token一般是随机或半随机。例如token后的手机号是个假号，在另外一个库里存着这个token和真实号码的对照表，也就是Tokenization后，你的数据库里都是假数据， 减少了数据流转过程中的风险。
Tokenization也可以半随机，例如需要手机号的前三位标识运营商，则可以保留前三位，把后面的8位token化。这种方法在金融界对银行卡号的处理上极为普遍应用。
4、Masking
Masking也是利用非敏感值取代敏感数据，但Masking在保护敏感数据同时又能够保留聚合数据值。例如姓名的全部随机替换，出生日期的偏移，或者员工薪酬的交换，这样可以让数据分析正常运行并具备有意义的结果，同时保护数据。
Masking在原数据基础上产生一份新数据，这叫静态Masking，国内称之为静态脱敏。对应的则是动态脱敏，当数据从db或文件读取时，实时Masking，原文件不变，只有输出结果改变，可以根据用户的身份，例如风控人员得到的是真实数据，普通客服得到的是替换数据。这时候可以把动态脱敏起到一个代理作用。
从整个行业来看，Tokenization，Masking，FPE也不断的在进步，之间的界限也逐渐模糊。但这些方法，都能在不改变应用的前提下保护敏感数据。
五、场景
给几个不同场景下的建议：
1、数据库
数据库加密的需求一般是防范管理员，支持多租户，合规要求。数据库加密的优选是：
最好是应用加密，在数据进到DB之前就进行加密。
其次是字段加密，但如果是为了防范DBA，这种加密就没用了。
如果字段加密不可行，则可使用透明加密，透明加密对于保护存储中的数据是优选，即使数据量较大，性能也几乎不受影响。
2、云存储
公有云里面，加密是数据安全的主要控制手段，来保证用户对数据的控制能力，即使是云厂商也不能获取数据。但对SaaS来说就尴尬了，目前能够支持SaaS加密的可选项还不多，最常见的是对存储加密。很多云厂商也都支持用户自己管理密钥提供进一步的保障。
3、合规
合规里卖的最好的方案，大概就是加密和Tokenization了。比如PCI明确safe harbor来鼓励加密，而在策略上又包括限制管理员，防止批量查询，限制数据展现等。因此合规控制关注的是，特权用户（可以访问的数据），职责分离（管理员无法获取敏感数据），以及数据移动安全性，合规里一般还会包括数据访问量限制，可疑监控和响应等要求。
4、三方支付
支付行业一般被看作合规的一个分支。对这个行业来说银行卡信息是核心数据，但每个卡号在不同数据库中存储就意味着风险和更高成本，而实际上大多数明文卡号需求都是伪需求。尽可能的删除卡号数据，以消除数据泄漏风险，合规责任也会减轻。银联，apple都在这方面进行了实践。
5、应用
处理数据的都是应用，当需要细粒度控制的时候，就需要应用层对数据元素进行加解密，当然这个代价也比较高，需要对应用多做验证测试，但对有些系统来说这就是必不可少的，比如涉及到财务和人事的系统，其他不这么高敏感的则可以在静止数据上做加密，也就是文件或数据加密，一般都是足够的。
六、决策树
前面说的这些都可以不用看
专栏
