互联网企业 如何创造数据安全体系
发布时间：2022-07-04 05:01:17 所属栏目：安全 来源：互联网
导读：互联网企业 如何创建数据安全体系？ 一、背景 Facebook数据泄露事件一度成为互联网行业的焦点，几百亿美元市值瞬间蒸发，这个代价足以在地球上养活一支绝对庞大的安全团队，甚至可以直接收购几家规模比较大的安全公司了。 虽然媒体上发表了很多谴责的言论，
|
互联网企业 如何创建数据安全体系？ 一、背景 Facebook数据泄露事件一度成为互联网行业的焦点，几百亿美元市值瞬间蒸发，这个代价足以在地球上养活一支绝对庞大的安全团队，甚至可以直接收购几家规模比较大的安全公司了。 虽然媒体上发表了很多谴责的言论，但实事求是地讲，Facebook面临是一个业界难题，任何一家千亿美元的互联网公司面对这种问题，可能都没有太大的抵抗力，仅仅是因为全球区域的法律和国情不同，暂时不被顶上舆论的浪尖罢了。但是全球的趋势是越来越重视隐私，在安全领域中，数据安全这个子领域也重新被提到了一个新的高度，所以笔者就借机来说一下数据安全建设。（按照惯例，本文涉及敏感信息的部分会进行省略处理或者一笔带过。 ） 二、概念 这里特别强调一下，“隐私保护”和“数据安全”是两个完全不同的概念，隐私保护对于安全专业人员来说是一个更加偏向合规的事情，主要是指数据过度收集和数据滥用方面对法律法规的遵从性，对很多把自身的盈利模式建立在数据之上的互联网公司而言，这个问题特别有挑战。有些公司甚至把自己定义为数据公司，如果不用数据来做点什么，要么用户体验大打折扣，要么商业价值减半。GDPR即将实施，有些公司或将离场欧洲，就足见这件事的难度不容小觑。当然市场上也有一些特别推崇隐私保护的公司，他们很大程度上并不能真正代表用户意愿，而只是因为自家没有数据或缺少数据，随口说说而已。 三、 数据采集 数据泄露有一部分原因是用户会话流量被复制，尽管有点技术门槛，但也是发生频率比较高的安全事件之一，只是是很多企业没有感知到而已。下面从几个维度来说明数据采集阶段的数据保护。 流量保护 全站HTTPS是目前互联网的主流趋势，它解决的是用户到服务器之间链路被嗅探、流量镜像、数据被第三方掠走的问题。这些问题其实是比较严重的，比如电信运营商内部偶有舞弊现象，各种导流劫持插广告（当然也可以存数据，插木马），甚至连AWS也被劫持DNS请求，对于掌握链路资源的人来说无异于可以发动一次“核战争”。即使目标对象IDC入侵防御做的好，攻击者也可以不通过正面渗透，而是直接复制流量，甚至定向APT，最终只是看操纵流量后达到目的的收益是否具有性价比。 广域网流量未加密的问题也要避免出现在“自家后院”——IDC间的流量复制和备份同步，对应的解决方案是跨IDC流量自动加密、TLS隧道化。 四、前台业务处理 鉴权模型 在很多企业的应用架构中，只有在业务逻辑最开始处理的部分设置登录态校验，后面的事务处理不再会出现用户鉴权，进而引发了一系列的越权漏洞。事实上越权漏洞并不是这种模型的全部危害，还包括各种K/V、RDS（关系型数据库）、消息队列等等，RPC没有鉴权导致可任意读取的安全问题。 在数据层只知道请求来自一个数据访问层中间件，来自一个RPC调用，但完全不知道来自哪个用户，还是哪个诸如客服系统或其他上游应用，无法判断究竟对当前的数据（对象）是否拥有完整的访问权限。绝大多数互联网公司都用开源软件或修改后的开源软件，这类开源软件的特点是基本不带安全特性，或者只具备很弱的安全特性，以至于完全不适用于海量IDC规模下的4A模型（认证、授权、管理、审计）。 外面防御做的很好，而在内网可以随意读写，这可能是互联网行业的普遍现状了。主要矛盾还是鉴权颗粒度和弹性计算的问题，关于这个问题的解决方案可以参考笔者的另外一篇文章《初探下一代网络隔离与访问控制》，其中提到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为了泄愤，把数据库拖走或者删除这种危险动作。通常大型互联网公司都会有数据库访问层组件，通过这个组件，可以审计、控制危险操作。 五、 ROI和建设次第 对于很多规模不大的公司而言，上述数据安全建设手段可能真的有点多，对于小一点公司即便什么事不干可能也消化不了那么多需求，因为开源软件和大多数的开发框架都不具备这些能力，需要DIY的成分很高，所以我们梳理一下前置条件，优先级和ROI，让数据安全这件事对任何人都是可以接受的，当然这种情况其实也对应了一些创业空间。 基础 账号、权限、日志、脱敏和加密这些都是数据安全的基础。同时还有一些不完全是基础，但能体现为优势的部分：基础架构统一，应用架构统一，如果这两者高度统一，数据安全建设能事半功倍。 日志收集 日志是做数据风控的基础，但这里面也有两个比较重要的因素： 办公网络是否BeyondCorp化，这给数据风控提供了极大地便利； 服务化，所有的数据调用皆以API的形式，给日志记录提供了统一的形式。 数据风控 在数据安全中，“放之四海皆准”的工作就是数据风控，适用于各类企业，结合设备信息、账号行为、查询/爬(读)取行为做风控模型。对于面向2C用户类，2B第三方合作类，OA员工账号类都是适用的。具体的策略思想笔者打算在后续文章《入侵防御体系建设》中详细描述。 （编辑：财气旺网 - 财气网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐