企业网络安全之隐私保护

会员服务 ·

企业网络安全之隐私保护

2019 年 6 月 25 日 计算机与网络安全

一次性付费进群，长期免费索取教程，没有付费教程。

教程列表见微信公众号底部菜单

进微信群回复公众号：微信群；QQ群：460500587

微信公众号：计算机与网络安全

ID：Computer-network

隐私保护诞生于互联网时代，而移动互联网、物联网发展起来后进一步提升了这方面的需求，对于业务规模比较大的公司，尤其是2C市场和全球化的公司，隐私保护成了安全建设中的必要选项。

隐私保护逐渐兴起主要有几方面的原因：

● 互联网和移动互联网兴起，大批的厂商承载了上亿网民的个人数据，这些个人数据的泄露不仅影响业务运营，影响品牌，加剧用户流失，实际上在立法较成熟的国度和区域也触到了法律。当前无论是移动互联网、物联网，还是互联网+，这些只是整个人类社会信息化程度加深的中途片段，信息化是全球趋势，所以从这个层面讲，个人数据会越来越多，承载个人数据的媒介和平台会越来越多，隐私保护将会发展成为和信息安全同级别的热门领域，对于没有搭上互联网这波的老牌安全从业者可以考虑往这个方向转。

● 国家间的对抗从实体战争发展成网络信息战，维度不同了，自然更重视国家的数据，从欧盟宣布废弃安全港协议就可见一斑，美国商企动不动就以法律取证等各种借口把欧盟成员国公民的个人数据拷到美国去，各国大佬们都觉得这样太没安全感了。大家都知道数据这个东西对安全和情报的影响太大了，不得不严肃对待。

个人、企业、国家这3个层次决定了隐私保护的重要性，对于互联网企业而言，隐私保护在业务角度有如下诉求：

● 防止盗号，撞库，用户（玩家）数据泄露，数据被供应商和分包商非法倒卖。

● 防止信息过度搜集，以及在用户不知情、无选择权的情况下被收集和存储。

● 有跨境业务时，需要遵从当地的合规性要求，否则不能准入。主要是按照当地的管理要求在允许的范围内以约定的方式处理数据，譬如由客户自己选择数据中心的位置，合同结束时删除数据，在数据的生命周期内给客户提供查询、修改、删除数据的接口。

● 跨境数据传输需要通过专门的法律框架。

● 有完整的安全体系和技术措施保护数据。

● 设置专职的隐私保护职位（高管）。

● 供应链上下游环节对隐私保护的遵从性。

● 提供审计的手段。

● 法律承诺，违约赔偿和违约责任。

国内的互联网公司在业务全球化方面的进程多数还比较低，有在海外开展业务的会明显感觉到隐私保护的压力。

1、数据分类

隐私保护强调的是个人数据PII（Personally Identifiable Information），这与纯粹的服务器数据保护仍有差别。

在安全管理中强调的是区别业务和资产权重以投入不同的成本做风险控制，BCM强调的是基于不同业务的RTO和RPO做持续性管理和业务恢复策略，隐私保护对数据分类的要求更细，以便对数据的全生命周期提供不同的保护、访问控制和加密策略。

以手机的云端存储为例，云端备份数据属于非结构化数据，其中通讯录、待办事项等属于结构化数据，它们的保密需求相同，但是技术实现手段可能就不一样。

再以电商平台账号为例，用户名，昵称属于公开信息，收货地址属于非公开信息，而支付卡号属于机密信息，它们都是结构化数据，但在产品设计与实现的时候需要分类进行保护。

从更高维度看，很多企业都做开放平台，通过API把数据开放给第三方应用，里面就涉及更抽象的数据分类分级，对供应链上下游的数据提取者赋予特定的访问控制策略。

2、访问控制

访问控制（Identity & Access Management，IAM）示意图如图1所示。

图1 IAM示意图

典型的IAM应该包含如下几方面的元素：

1）谁（定义角色）

2）对哪些资源（定义对象）

3）拥有（定义“允许”还是“拒绝”）

4）哪些具体权限（定义增删改查和其他的操作）

5）有效期是多久（定义失效时间）

在此基础上还可以继续添加：组策略、通配符、根据条件触发或定义访问控制策略、多因素认证等。

3、数据隔离

对于在线应用的后台数据存储而言，敏感数据（例如用户库、口令、密保、支付等）应考虑分表分库存储，应尽量减少一个上层应用出现漏洞时的影响，例如某个应用出现SQL注入时，它应该只能影响那个应用对应的库，而不是全部的数据。大型网站的后台数据存储几乎都是分片的（Sharding），从安全上应考虑敏感数据的集中存储，过于分散会加大监控的成本，因为“如果所有的都重要那就等于没有一样是重要的”，如图2所示。

图2 大型互联网的数据库分片

对于终端设备，应考虑沙箱级隔离（参见图3），屏蔽非法程序的恶意访问，或合法程序的非授权越界访问（B厂的App访问A厂App的个人数据）。容器本身使用TPM（可信计算）等技术。

图3 IOS沙箱示意图

在云的虚拟化环境中，一般情况用VPC隔离。但对于GovCloud这种保密要求极高的系统也采用了物理隔离。物理隔离虽然有点跟云计算一切资源皆可共享的理念有点不搭调，但在安全上却是真实的需求。AWS全球节点如图4所示。

图4 AWS全球节点

4、数据加密

对于结构化数据，比如用户注册的身份证号、信用卡信息在持久化时需要考虑选择性字段加密，目前可以使用的技术包括TDE（Transparent Data Encryption，透明数据加密）和应用级加密，对于非结构化数据，例如，文件、图片一般使用自实现的文件加密或磁盘块加密。在数据传输过程中TLS成了目前事实上的标准。

（1）TDE透明数据加密

TDE的原理如图5所示。

图5 TDE的原理图

TDE可对数据和日志文件执行实时I/O加密和解密，这种加密使用数据库加密密钥（DEK），该密钥存储在数据库引导记录中以供恢复时使用。DEK是使用存储在服务器的master数据库中的证书保护的对称密钥，或者是由EKM（扩展密钥管理模块）保护的非对称密钥。TDE保护对象为静态数据（相对于内存中的热数据而言），即数据和日志文件。开发人员可以使用AES和3DES加密算法来加密数据，且无需更改现有的应用程序。

目前只有Oracle和微软的SQL Server支持TDE，在互联网行业普遍流行去IOE的时代，MySQL是实际上的关系型数据库选择标准，所以TDE将会有一定局限性。

（2）应用加密

对于大部分使用MySQL的数据库，可以使用应用级的加密，例如下面的SQL语句：

INSERT INTO Customers (CustomerFirstName,CustomerLastName) VALUES

(AES_ENCRYPT('Ayazero',@key), AES_ENCRYPT('Ayaz3ro',@key);

加密后的字段不支持模糊查询，可能会影响应用的正常功能和程序开发，例如下面的语句可能就不行了：

SELECT CustomerFirstName, CustomerLastName from Customers WHERE

CustomerName LIKE 'Ay%';”

直接比较的语句需要变更为：

SELECT CustomerFirstName, CustomerLastName FROM Customers WHERE

CustomerFirstName = AES_ENCRYPT('Ayazero', @key);

在设计应用时，例如打算加密身份证字段，可以使用HMAC-SHA1将其变成哈希值，加密后的状态仍然是唯一的，与其他人的身份证哈希后产生的值一样的概率很小，查询时根据HMAC的哈希值与查询字符串经同样哈希函数处理后的值对比，则加密字段不用解密。

google已宣布2017年开始不再支持SHA-1这种不安全的算法，可以使用SHA-2等替代算法。

（3）FPE（保留格式加密）

传统加密算法会改变原明文字段的数据长度和数据类型，而FPE（保留格式加密）则要求加密前的明文与加密后的密文拥有相同数据长度和数据类型，其原理如图6所示。例如被拖库后，信用卡卡号字段实际上是加密的，但看上去仍然是数字明文，且长度与正常的卡号一致，如果攻击者拿这些卡号去盗刷会发现都不好用。FPE不仅可以解决敏感数据加密的问题，还可以解决将生产环境数据迁移到测试环境又不泄露用户数据的问题，除了持久化数据，FPE在数据传输过程中也一样可以使用。

图6 FPE（保留格式加密）机制

CipherCloud和Voltage Security是与AWS合作的两家数据加密解决方案提供商，他们的方案都支持FPE，并提供了一种近似透明的数据加密方式。FPE在数据写入数据库实例之前对原文进行加密或符号化，同时加密后的字段插入数据库原字段时不会改变表的数据结构。

（4）文件/磁盘加密

磁盘文件加密主要是针对非结构化数据，例如备份文件等。应用本身不需要关注加密过程，只需要将文件扔到加密存储介质上，高性能的磁盘加密一般都通过硬件加密芯片实现。它的通病是一旦密钥泄露就会失效，表1是对几种主流加密方式的对比。

表1 几种主流加密方式的对比

Apple的iCloud中对个人备份数据上传没有选择上述加密方式，而是自己现实了一种分块加密，如图7所示。

图7 iPhone手机备份使用分块加密

其原理是将整个备份切割成4M大小的块，分别加密每个块，然后保存到云端，它的好处是，因为文件本身已加密，所以不再需要第三方的磁盘级加密，只需要存储到任意的非加密介质就可以，例如亚马逊S3或微软Azure等平台，因为密钥和文件加密的元数据由Apple自己保存，所以把数据扔到第三方存储即使是被人下载了也无法解密，分块后可以提高上传的并发性能同时支持断点续传，Apple本身只保存有限的数据，而把大量的存储空间负担交给云平台，利用云平台的资源弹性伸缩最大化自己的ROI，否则为用户的备份数据建立海量存储是一件吃力不讨好的事。

（5）噪音混淆

上面的方法都比较“正统”，正统的方法通用性强，容易推动开发去实现，但是对攻击者来说获取数据的途径也很清晰，那就是拖库并获取密钥。在对抗比较激烈的场景中往往需要“守正出奇”，需要一些“歪点子”。

噪音混淆就是在正常的用户数据里掺入“噪声因子”，它并非一种加密算法（这里并不是在讨论K匿名、差分之类的话题），而是变换了形式让数据不再以原来的面貌出现。这种思路跟代码混淆如出一辙，对抗的效果上比较依赖于信息不对称，一旦信息不对称被打破，就会失效。

5、密钥管理

密钥是所有加密过程的“SSO”，是最大的单点问题，所以密钥本身的存储和管理可能比具体怎么加密更重要，而一旦密钥丢失，所有的数据将不可找回。

如图8所示，密钥管理基础设施（KMI）通常分两部分：密钥的存储，对密钥本身的访问授权管理。更上层的加密方法通常由应用自身去实现。

图8 分层的KMI架构

在海量用户服务体系下的密钥管理需要解决几个方面的问题：

● 单一的密钥无法支持海量架构，必须是多级层级密钥体系。

● 支持密钥的全生命周期管理：创建、激活、禁用、转换（创建新的密钥对当前时间点以后的数据进行加解密，保存老的密钥用以解密过去用该密钥加密的数据，在加密数据中标记对应的密钥版本以通知KMS用哪个密钥来解密）、分发、备份、销毁。

● 物理安全：防止云平台厂商，IDC托管方读取密钥。

理论上，在云计算环境中，如果没有使用基于密钥的数据加密，且对密钥信任与存储设备（HSM）拥有完全的控制权，都不能保障数据安全和隐私泄露的问题。

6、安全删除

对于加密数据或加密文件系统，不需要删除数据，只需要使用安全的方法删除加密密钥，对于非加密数据，需要使用安全的方法不仅格式化元数据，而且还要重写数据块，物理上可以使用消磁等手段。

7、匿名化

互联网环境里广告和推荐系统都依赖于跟踪用户偏好和历史行为做推荐，风控和业务数据挖掘类的BI系统也需要跟踪用户行为，如设备指纹、cookie、帆布指纹等各种技术都可以用来跟踪用户，在互联网尤其是移动互联网环境下，很多时候实际上并不需要确切的用户名就能跟踪到这个人，假如您手机的无线网卡的MAC地址是固定不变的，那无论何时何地，只要看到这个MAC地址就知道您大概在什么地方。

为了尽可能地解绑个人隐私和用户行为的关系，出现了匿名化的产品设计理念，例如苹果用一个UUID（Universally Unique Identifier，通用唯一识别码）作为用户标识，如下代码所示：

-(NSString*)

uuid

{

1. CFUUIDRef puuid = CFUUIDCreate( nil );

2. CFStringRef uuidString = CFUUIDCreateString( nil, puuid );

3. NSString * result = (NSString*)CFStringCreateCopy( NULL, uuidString);

4. CFRelease(puuid);

5. CFRelease(uuidString);

return

[result autorelease];

6. }