企业加密方案指南

本文不讨论加密算法,密码模式之类。只谈在企业应用中的加密应用,比如何时在数据库加密最佳,何时对应用加密,什么数据适合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,基于权限的特定字段。

图片 1.png

二、加密层

   可以用4层结构理解加密层,应用在DB上,DB在文件上,文件在存储卷上。可以在这里每层做加密,也可以全加密。但加密引擎所在位置,一定是安全性和性能要求最高的位置。越往上安全性越高,复杂性和性能成本也高。

   耦合越高,复杂性降低,安全性和可靠性就弱。构建加密需要在安全性、复杂性、性能之间平衡,尤其在大型分布式环境中这就更重要了。

图片 2.png

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、应用

   处理数据的都是应用,当需要细粒度控制的时候,就需要应用层对数据元素进行加解密,当然这个代价也比较高,需要对应用多做验证测试,但对有些系统来说这就是必不可少的,比如涉及到财务和人事的系统,其他不这么高敏感的则可以在静止数据上做加密,也就是文件或数据加密,一般都是足够的。

六、决策树

   前面说的这些都可以不用看

图片 1.png

发表评论

已有 2 条评论

取消
Loading...

填写个人信息

姓名
电话
邮箱
公司
行业
职位
css.php