让高敏感数据销声匿迹：一种用户无感知的数据防泄露招式
发布时间：2021-05-22 21:33:55 所属栏目：安全 来源：互联网
导读：HTTP 协议 HTTP(Hyper Text Transfer Protocol)协议是超文本传输协议的缩写，它是从WEB服务器传输超文本标记语言(HTML)到本地浏览器的传送协议，位于 OSI 网络模型中的应用层 HTTP 是一个基于TCP/IP通信协议来传递数据的协议，传输的数据类型为 HTML 文件、
|
HTTP 协议
HTTP(Hyper Text Transfer Protocol)协议是超文本传输协议的缩写，它是从WEB服务器传输超文本标记语言(HTML)到本地浏览器的传送协议，位于 OSI 网络模型中的应用层
HTTP 是一个基于TCP/IP通信协议来传递数据的协议，传输的数据类型为 HTML 文件、图片文件、查询结果等。
HTTP协议一般用于 B/S 架构。浏览器作为 HTTP 客户端通过 URL 向 HTTP 服务端即 WEB 服务器发送所有请求。
HTTP 特点
HTTP 协议支持客户端/服务端模式，也是一种请求/响应模式的协议
简单快速： 客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST
灵活： HTTP允许传输任意类型的数据对象。传输的类型由Content-Type加以标记。
无连接： 限制每次连接只处理一个请求。服务器处理完请求，并收到客户的应答后，即断开连接，但是却不利于客户端与服务器保持会话连接，为了弥补这种不足，产生了两项记录http状态的技术，一个叫做Cookie,一个叫做Session。
无状态： 无状态是指协议对于事务处理没有记忆，后续处理需要前面的信息，则必须重传。
HTTP 中间人攻击
HTTP 协议使用起来确实非常的方便，但是它存在一个致命的缺点：不安全。
我们知道 HTTP 协议中的报文都是以明文的方式进行传输，不做任何加密，这样会导致中间人攻击
例如：小明 JAVA 贴吧发帖，内容为 我爱JAVA：
被中间人进行攻击，内容修改为 我爱PHP
从整体信息化的发展来看，数据安全被重视相对是滞后的，大多行业都是信息系统已经运行了好多年，基于此开展数据安全相关工作，难度还是很大的。尤其是行业里针对高敏感数据的管控，例如明星数据、高级别领导数据、高管数据等，这些数据与普通人员的数据一般是混在一起的，全量管控会影响业务的便捷性，若不管控，一旦发生泄露，对企业的损失会非常大。
现有高敏感数据管控方案解析
进入大数据时代后，数据价值越来越高，受利益的驱使，类似事件时有发生。那么，针对这类高敏感人员的信息我们该如何加强管控?就此事，我通过走访调研了多家数据安全厂商，收集到了三个方案，并进行了弊端分析。
方案一：单独再部署一套应用，例如“VIP系统”，这样可以将高敏感数据和普通敏感数据进行隔离，有针对性的进行保护，由专门的团队进行维护，缩小数据使用的范围。
这样的高敏感数据管控方案其实存在一些弊端，首当其冲带来的问题就是运营成本的增加，一方面需要投入一套软硬件资源，另一方面需要组织人员进行运营、维护;
同时还会有重复投入的现象出现，很多时候为保证安全，需要分别为这两套系统配置数据安全产品和能力，这就造成了大量的重复投入;
另外，从价值最大化的层面来看，这样的管控模式下由于存有高敏感数据的应用系统一般不敢轻易对外提供服务，这在无形中就形成了数据孤岛，不利于数据价值的发挥;
方案二：对高敏感数据进行打标，在数据生成的时候对数据进行敏感级别判定，并做打标处理，这样可以很清晰地道哪些是高敏感数据，可以有针对性的授权，加入一些数据加密或数据脱敏的安全手段，当数据被使用时通过敏感标识来采取相应的安全技术手段予以保护。
很明显，这个方式不会造成重复投入，投入成本相比也会低很多，做好权限管控的话，高敏感数据还是可以向外共享的。但该方案会导致应用系统改造量大,数据生成时需要判断，授权时需要单独处理，使用时需要进行数据加密或数据脱敏处理，这些改动的工作会很大，甚至会改动顶层设计;
另一方面，高敏感数据与普通敏感数据一样，有很多使用场景，例如：数据更新、删除、分析、校验、查询等，这些场景都会接触到高敏感数据，采用这种方案会影响数据的便捷使用;
还有就是由于逻辑复杂，会造成明显的性能损耗。敏感数据的每次使用都需要进行判断，看是普通数据、普通敏感数据
、还是高敏感数据，判断后还需要调用相应的安全接口对数据进行处理，当数据访问峰值出现时，可能会造成宕机;
另外，为保证安全，降低泄露风险，需要对高敏感数据进行数据加密和数据动态脱敏处理，这样更加重了性能的损耗和数据使用的便捷性。
方案三：对高敏感数据进行匿名化处理，匿名处理后的数据不影响使用，同时也很好的对高敏感数据进行保护，为了保证匿名后的数据在需要时可以再逆向回原始数据，可以将对应关系进行保留。
相比前两种方案，方案三对数据业务的影响是最小的，应用改动量也不会很大，貌似看上去是最合适的，但其存在一致命的问题，即：为保证匿名后的数据可以逆向回来，需要将对应关系进行保管，一旦对应关系被篡改或删除，则数据将永远恢复不了;
还有就是这样做会影响数据价值发挥，匿名化后的数据可以很好的防止泄露，但也阻碍了数据的应用，一些有针对性的服务功能将很难实现，如果每次都进行逆向处理，频繁的对数据进行逆向处理，还是会增加泄露的概率。
从源头探寻高敏感数据“隐身”之道
以上三种方案都是从如何管控入手，虽然存在一些弊端，但还是可以起到很大作用的。我们不妨换个思路，将高敏感数据隐藏，让使用者不知道高敏感数据的存在，顺着这个思路，我设计了一下方案：
首先，重定向数据库，让应用系统不直接访问数据库，需要先访问协议解析工具，协议解析工具对访问协议进行解析，得出“谁想访问哪些数据，要做什么”。然后，将协议解析出来的结果与高敏感数据特征进行比对，确认该用户是否可以访问，若不可以访问，则通过改写返回结果的协议将高敏感数据剔除;若可以访问，则不予处理，直接放行。
另外，在这个过程中，需要产生两张数据表，分别是高敏感数据特征表和有权限的用户表，这两张表对于安全管控至关重要，出于安全考虑，应专人专岗负责，且内部不要公开，知道的人越少，安全系数越高，管理员定期录入和更新表中的数据即可。
 （编辑：PHP编程网 - 黄冈站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330482号