互联网企业应当如何建设数据安全体系？

　　外面防御做的很好，而在内网可以随意读写，这可能是互联网行业的普遍现状了。主要矛盾还是鉴权颗粒度和弹性计算的问题，关于这个问题的解决方案可以参考笔者的另外一篇文章《初探下一代网络隔离与访问控制》，其中提到Google的方法是内网RPC鉴权，由于Google的内网只有RPC一种协议，所以就规避了上述大多数安全问题。

　　对于业务流的鉴权模型，本质上是需要做到Data和App分离，建立Data默认不信任App的模型，而应用中的全程Ticket和逐级鉴权是这种思想下的具体实现方法。

　　服务化

　　服务化并不能认为是一个安全机制，但安全却是服务化的受益者。我们再来温习一下当年Bezos在Amazon推行服务化的一纸号令：

　　1)所有团队今后将通过服务接口公开他们的数据和功能。

　　2)团队必须通过这些接口相互通信。

　　3)不允许使用其他形式的进程间通信：不允许直接链接，不允许直接读取其他团队的数据存储，不支持共享内存模式，无后门。唯一允许的通信是通过网络上的服务接口调用。

　　4)他们使用什么技术并不重要。HTTP，Corba，Pubsub，自定义协议 – 无关紧要。贝索斯不在乎。

　　5)所有服务接口无一例外都必须从头开始设计为可外部化。也就是说，团队必须规划和设计能够将接口展示给外部开发人员。没有例外。

　　6)任何不这样做的人都会被解雇。

　　服务化的结果在安全上的意义是必须通过接口访问数据，屏蔽了各种直接访问数据的途径，有了API控制和审计就会方便很多。

　　内网加密

　　一些业界Top的公司甚至在IDC内网里也做到了加密，也就是在后台的组件之间的数据传输都是加密的，譬如Goolge的RPC加密和Amazon的TLS。由于IDC内网的流量比公网大得多，所以这里是比较考验工程能力的地方。对于大多数主营业务迭代仍然感觉有压力的公司而言，这个需求可能有点苛刻了，所以笔者认为用这些指标来衡量一家公司的安全能力属于哪一个档位是合理的。私有协议算不算?如果私有协议里不含有标准TLS(SHA256)以上强度的加密，或者只是信息不对称的哈希，笔者认为都不算。

　　数据库审计

　　数据库审计/数据库防火墙是一个入侵检测/防御组件，是一个强对抗领域的产品，但是在数据安全方面它的意义也是明显的：防止SQL注入批量拉取数据，检测API鉴权类漏洞和爬虫的成功访问。

　　除此之外，对数据库的审计还有一层含义，是指内部人员对数据库的操作，要避免某个RD或DBA为了泄愤，把数据库拖走或者删除这种危险动作。通常大型互联网公司都会有数据库访问层组件，通过这个组件，可以审计、控制危险操作。

　　六、数据存储

　　数据存储之于数据安全最大的部分是数据加密。Amazon CTO Werner Vogels曾经总结：“AWS所有的新服务，在原型设计阶段就会考虑到对数据加密的支持。”国外的互联网公司中普遍比较重视数据加密。

　　HSM/KMS

　　业界的普遍问题是不加密，或者加密了但没有使用正确的方法：使用自定义UDF，算法选用不正确或加密强度不合适，或随机数问题，或者密钥没有Rotation机制，密钥没有存储在KMS中。数据加密的正确方法本身就是可信计算的思路，信任根存储在HSM中，加密采用分层密钥结构，以方便动态转换和过期失效。当Intel CPU普遍开始支持SGX安全特性时，密钥、指纹、凭证等数据的处理也将以更加平民化的方式使用类似Trustzone的芯片级隔离技术。

　　结构化数据

　　这里主要是指结构化数据静态加密，以对称加密算法对诸如手机、身份证、银行卡等需要保密的字段加密持久化，另外除了数据库外，数仓里的加密也是类似的。比如，在Amazon Redshift 服务中，每一个数据块都通过一个随机的密钥进行加密，而这些随机密钥则由一个主密钥进行加密存储。用户可以自定义这个主密钥，这样也就保证了只有用户本人才能访问这些机密数据或敏感信息。鉴于这部分属于比较常用的技术，不再展开。

　　文件加密

　　对单个文件独立加密，一般情况下采用分块加密，典型的场景譬如在《互联网企业安全高级指南》一书中提到的iCloud将手机备份分块加密后存储于AWS的S3，每一个文件切块用随机密钥加密后放在文件的meta data中，meta data再用file key包裹，file key再用特定类型的data key(涉及数据类型和访问权限)加密，然后data key被master key包裹。

　　文件系统加密

　　文件系统加密由于对应用来说是透明的，所以只要应用具备访问权限，那么文件系统加密对用户来说也是“无感知”的。它解决的主要是冷数据持久化后存储介质可访问的问题，即使去机房拔一块硬盘，或者从一块报废的硬盘上尝试恢复数据，都是没有用的。但是对于API鉴权漏洞或者SQL注入而言，显然文件系统的加密是透明的，只要App有权限，漏洞利用也有权限。

　　七、访问和运维

　　在这个环节，主要阐述防止内部人员越权的一些措施。

　　角色分离

　　研发和运维要分离，密钥持有者和数据运维者要分离，运维角色和审计角色要分离。特权账号须回收，满足最小权限，多权分立的审计原则。

　　运维审计

　　堡垒机(跳板机)是一种针对人肉运维的常规审计手段，随着大型IDC中运维自动化的加深，运维操作都被API化，所以针对这些API的调用也需要被列入审计范畴，数量级比较大的情况下需要使用数据挖掘的方法。

　　工具链脱敏

　　典型的工具脱敏包括监控系统和Debug工具/日志。在监控系统类目中，通常由于运维和安全的监控系统包含了全站用户流量，对用户Token和敏感数据需要脱敏，同时这些系统也可能通过简单的计算得出一些运营数据，譬如模糊的交易数目，这些都是需要脱敏的地方。在Debug方面也出过Debug Log带有CVV码等比较严重的安全事件，因此都是需要注意的数据泄漏点。

　　生产转测试

　　生产环境和测试环境必须有严格定义和分离，如特殊情况生产数据需要转测试，必须经过脱敏、匿名化。

　　八、后台数据处理

　　数仓安全

　　目前大数据处理基本是每个互联网公司的必需品，通常承载了公司所有的用户数据，甚至有的公司用于数据处理的算力超过用于前台事务处理的算力。以Hadoop为代表的开源平台本身不太具备很强的安全能力，因此在成为公有云服务前需要做很多改造。在公司比较小的时候可以选择内部信任模式，不去过于纠结开源平台本身的安全，但在公司规模比较大，数据RD和BI分析师成千上万的时候，内部信任模式就需要被抛弃了，这时候需要的是一站式的授权&审计平台，需要看到数据的血缘继承关系，需要高敏数据仍然被加密。

　　在这种规模下，工具链的成熟度会决定数据本地化的需求，工具链越成熟数据就越不需要落到开发者本地，这样就能大幅提升安全能力。同时鼓励一切计算机器化&程序化&自动化，尽可能避免人工操作。

　　对于数据的分类标识、分布和加工，以及访问状况需要有一个全局的大盘视图，结合数据使用者的行为建立“态势感知”的能力。

　　因为数仓是最大的数据集散地，因此每家公司对于数据归属的价值观也会影响数据安全方案的落地形态：放逐+检测型 or 隔离+管控型。

　　匿名化算法

　　匿名化算法更大的意义其实在于隐私保护而不在于数据安全(关于隐私保护部分笔者打算另外单独写一篇)，如果说对数据安全有意义，匿名化可能在于减少数据被滥用的可能性，以及减弱数据泄漏后的影响面。

　　九、展示和使用

　　这个环节泛指大量的应用系统后台、运营报表以及所有可以展示和看到数据的地方，都可能是数据泄露的重灾区。

　　展示脱敏

（编辑：温州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!