2019大数据产业峰会|中国信通院廖璇：安全数据检测技术研究

在从生命周期的视角备份与恢复，删除数据等等。在实际检测过程中，我这边也发现，实际上虽然梳理出了这么多框架，但是在检测过程中各个层级的依赖关系并不是那么明显，而且关联度其实没有我们想象的那么高，并不是简单的说数据隐私安全我们上层做好了，你的平台安全、基础安全就没有问题，也不一定会出问题，也不是说我的基础设施，我的大数据里面基础设施做好了，就一定能够保护数据的隐私不被泄露，我想这就是我们今天在这里要探讨的数据安全检测的一个明显的特点，就是每个环节的每个点都有可能出相应的问题，以及即使你的业务看起来正常，但是存在相应的隐蔽的数据通路和相应的数据捷径、数据获取的捷径，这里我也不再做展开，后面的片子有一些简单的案例来进行相应的阐述。

如何进行相应的数据分析，并确实地反映业务的真实情况，我这里有一个简单的方式方法，这里也分享给大家，实际上就需要你把你分析的业务进行完整示图的表述，画图是最有效的帮你理清思路跟分析的方法，最简单，最有效。这里我举了一个典型的运营商的场景，以及在办理运营商业务的时候，运营商的系统会涉及到哪些方面，以及在各个系统关联的时候，我们需要关注哪些点，通过这个示图我们可以看到从用户的登录，再到CRM系统里面，再到BOSS系统里面，再到计费环节里面，再到专门的客户关系环节以及划单的环节，涉及到数据流转，数据生产经营以及用户保护到底会有哪些环节。比方说网厅系统是为用户侧提供业务办理、业务查询的功能，我们把网厅需要做的业务进行相应的分析，同时我通过网厅的数据，我的积分系统和BOSS系统是如何连接的，相应的划单数据到了BOSS系统、到CRM系统里面如何计算用户的消费、如何计算用户的数据，通过这个示图可以进行相应的分析。

我简单列举了一些目前我们测试的防止跟方法的维度，包括一些环节的管理要求，这里面有一些测试步骤，通过测试步骤相应的结果的判定以及通用性的技术要求，我们需要按步骤怎么做，最后实际上达到的效果是什么，就是防护手段效果的验证，在我们梳理的业务整个示图来看，我能够对整个业务环节，包括数据环节，包括整个业务流程，数据安全的风险点的识别，网厅是有什么样的风险点？关注的是什么？我有网站、我有App，同时我的BOSS系统可能还有一些对外接口的调用，我跟哪些系统有关联，在这个关联环节中，我是否可以利用一些系统原生的漏洞或者是一些设计的缺陷，来切入到数据安全的风险识别上面来看，比方说BOSS积分系统可以理解权限获取任意用户的详单信息，以及在网厅系统调用的时候，我网厅的外部服务器、App服务器可控，同时利用该权限可以获取相应的业务查询接口来查询用户的详单，以及在大量的计费数据库的时候，我们可以利用BOSS系统的权限，获得任意用户的详单，来获取最终对网源数据的采集，这个分析完之后我们就能够给相应的客户或者是给相应的监管机构梳理出整个的分析跟评价结果，也是同样站在数据整个生命周期的角度，同时站在公司以及管理的层面，以及技术的层面，一个人员的维度进行象限的划分。在制度管理角度，在整个生命周期有哪些缺失，比方说告知义务是缺失的，权限管理是缺失的，共享保护是缺失的，安全保护跟事件报告是缺失的，通过上一步是完全可以分析出来的，技术工具方面，在采集、存储、处理、传输阶段有哪些风险点，整张报表就是为之后解决数据安全风险、数据原生安全问题提供给具体的风险点的切入。

还记得刚才我提到的框架吧？包括数据的隐私环节实际上都有各个条块，通过各个条块，我再给大家做一些简单的举例，包括数据隐私安全，传统的安全检测存储过程中数据的保密性、完整性是什么样的？我的加密数据是否可被还原？实际上不仅仅是能够通过我们的一些黑白灰和检测能发现的，实际上需要把原数据取出，来判断相应的加密的方式方法，是否成功、是否有效，以及你可以尝试对原数据进行还原，来判断他的数据即使被窃取之后不会被非法滥用，还原出明文数据等。

在数据发布的限制安全检测里面，我们通过一些网络流量，包括传输环节的抓包跟分析中来看，即使做了简单的加密，但是通过一些还原，通过xss脚本和csrf的方法可以还原出手机号这种明文，以及再看一个典型的数据管理系统的例子来看，正常的业务设计一定是管理员登录或者是用户登录，一定天然带cookie、session，在开发阶段即使是覆盖所有开发阶段的设计是没有问题，但是通过实际检测来说，对cookie的伪造在某些系统里面你的设计是失效的，我可以通过解码出来的信息来判断你的cookie是否真正有效，你没有保证你的cookie、session、token不可被预测，我就可以伪造出来我想利用的信息来登录你的系统，通过篡改和伪造之后，我就能够绕过你的系统的天然的防护进行登录的认证，来查询相应的所有信息。

还有一个典型的场景，就是客户的环节，客户客服的环节实际上是能够针对整个网厅的，客服也是，相应的划单处理也是，打投诉电话也是。所有的客服环节在处理用户的业务的时候，一定是会有相应的客户信息提供的，以及客户信息的校验，在订单以及他们处理业务的时候提供相应的服务的时候，如果你的验证机制存在相应的逻辑漏洞，可以导致相应的重放以及绕过相应的客服来查询信息，在网约车场景里面大量的事实反映客服的权限，你即使在数据库里面设置了相应的判定标准，比方说不能批量读取上千条或者短时间内读取上百条的日志，但是通过客服正常的业务环节，如果我对他的权限，我对他的认证方式进行回放的话，实际上是可以达到批量查询的最终结果。同样可以截获数据包进行跳转越权访问其他的菜单功能，且权限较大。从低级的权限到客服经理的权限是完全可以达到的。即使在业务环节当中设置各种各样的横向或者纵向的权限隔离，即使安全做得再好，但是不切入到业务的真正的环节来看的话，实际上你的数据保护措施是失效的以及通过相应的功能点的越权，发现部分菜单参数存在遍历的情况。这里不再细讲。以及相应的功能点的越权，我跳过了你的实际业务的设计，我可以查询任意指定手机号的完整性，获取全网任意用户的敏感形成的订单等等，这也是网约车的场景。以及我们最常见的，无论是我们现在登网银也好，登网厅也好，用各类业务也好，我们的短信验证码的这种机制实际上在我们的这种检测跟发现的过程当中是存在各种各样的逻辑绕过的情况，实际上可以通过拦截浏览器这种返回包的形式来篡改它的校验值来浏览具体的话费详单。只要输入任何一个手机号，我发验证码，你也收到了验证码，但是系统设定的，判定这个验证码生效或者失效的过程中仅仅是通过一个反馈包就能验证后台需要校验的整套流程。还有相应的云桌面内部主机的访问策略不严格，导致天然的越权跟跨安全域的访问，以及软件代码，刚才老师也提到了，我们在数据保护的时候，我们喜欢加水印，我们来防止一些窥屏、防止截图，但是还得保证加水印的应用是真正有效的，即使你考虑到了加水印，但是你有没有考虑到加水印本身也是一种应用，也是一种代码的实现？如果你这个代码的实现包括应用能够被绕过，能够被消除的时候，你这个天然的节点，天然设计的，你脑子里设想的这种数据安全保护的场景是不存在的。在现实中我们也是做了一些相应的还原，即使前端页面加了水印，但是通过页面的修改或者欺骗服务器的形式能够导致你的水印功能失效，以及相应的到具体的水印可以被伪造，即使前端做了相应的数据的处理之数据的脱敏。但是我通过页面的原代码的查看，实际上在原代码中就是明文的，以及我们现在大数据的场景一定是虚拟化，云主机、云桌面内控的主机，存在原生系统自带的漏洞。大数据所依托的底层的基础设施实际上是失效的，以及数据访问控制，你并没有判断用户登录的真实状态就可以达到相应的我直接访问数据库的效果，直接访问主机的效果进行进一步的入侵。大数据运维的监管的平台、弱口令等等都是在具体的检测测试场景里面进行复现的。

（编辑：应用网_阳江站长网）

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