早在笔者刚入行的那段时间，安全岗位基本分为两类，WEB安全工程师和Android安全工程师。聚焦应用安全漏洞，以及如何进行漏洞攻防的技术博弈。一般受限于当时对安全的认知，很少有人真正关注用户数据对企业的真正重要性。如今，随着GDPR、个人信息安全保护等一系列法规的实施，数据泄露的负面影响越来越大。为了更好的(avoid)protect(avoid)protect(back)public(pot)）数据安全的工作越来越吃香，那么数据安全有什么用呢？运维角度的数据安全从安全运维的角度，数据安全建设的必要性，在我们待过的公司里可能会有这样的对话注入。快速检查其他哪些应用程序使用此库，表中有哪些敏感字段以及影响了多少数据。”业务通常一脸天真地回应，“这张表没有敏感数据，不重要，我们现在就修复漏洞，把安全漏洞通知发给我就行，不要抄给我们领导。”Part2焦急的安全工程师收到来自暗网的监控告警。某公司数亿订单数据泄露。来自灵魂的拷问“有内幕吗？这是哪个数据库的数据？那么多敏感字段还是明文的，这次突发事件我好像在某处看到过这种字段，难道是上次的SQL注入拖后腿了？”出那么多数据，md业务还是骗了我测试数据。”如果上述类似对话经常发生在企业安全工程师的日常生活中，那么数据安全的建设一定还没有开始。感知与盲点数据安全是第一阶段密不可分的问题。数据在哪里？这就是我们常说的感知敏感数据的能力。只有知道敏感数据在哪里，才能将重要的精力和资源投入到资产上需要保护的数据上。从安全运营的角度考虑。part1在一个凉爽的秋日，SRC收到了SQL注入，RCE攻击了应用程序和库。安全工程师可以直接在安全中心看到漏洞被攻击的数据库和级别，什么表，什么级别。字段，有多少数据，拖放多少数据，风险等级直接量化。这些更准确的信息可以通过自动计费的方式将业务告警通知给安全部门，减少了安全工程师繁琐的排查过程和撕墙、业务查房的过程。Part2如果你在秋高气爽吃着火锅唱歌，突然发现暗网疑似数据泄露，赶紧通过安全中心调取数据字段，快速定位哪些股票存在隐患。应使用哪些应用程序进行快速应急响应。结合运营安全工程师的分析，可以进一步确定影响范围。原本毫无头绪的问题突然有了逐渐清晰的解决方向，不再像以前那样了。发现自己找不到像样的武器，又打不出劲，一秀腿就匆匆下场，台下观众纷纷嘲讽。数据安全数据安全在数据生命周期的六个阶段，根据公司基础设施的完善程度，安全团队根据自身团队的配置，选择性地选择从哪个环节入手，减少后续安全之间的沟通和业务成本，普及数据安全重要性的成本。从哪儿开始？笔者认为，数据安全的基础感知能力可以先与DB部门合作，也可以从业务端来开发。作为数据安全工程师，首先应该考虑如何实现自己的第一个小目标——“有基础的数据感知能力在哪里？”笔者认为从DB部门入手可以快速实现安全部门闭环运作和db部门协同工作，主要是因为db部门有你需要的数据资源，安全部门有对数据的需求分析分类分级。能力，两者的结果，能够以最短路径实现数据安全运行的闭环；但是从业务线出发，笔者认为成本会比较高，因为企业内部的业务部门从几千到几百不等，对安全的热情也是高低参差不齐，在资源有限的情况下数据安全初期，没必要在业务线投入宝贵的安全工程师（pilot除外），然后就没人反对了，最后无非就是安全同学被业务给坑了。”天天那么多数据库，有变化我有必要告诉你吗？”“你安全部门天天知道让我们业务干这个干那个，我们还能不能干自己的业务。”主动从top发现数据tobottom，从安全委员会推到业务线和db部门，建立完整的在线数据库系统流程，统一分类分级标准，数据分类可以根据用户的数据属性大致划分，比如用户信息，企业信息information,merchantinformation:按类别分类：动态识别数据的方法有很多，比如机器静态规则，机器学习，目标是不断提高敏感数据的识别率，最简单的方法可以直接遍历所有数据库表结构字段，遍历集中日志存储中心，对不同应用和不同的敏感数据进行自动审计ent数据库表。线下，通过数据安全团队，对线下分析数据进行分类、分级、标注数据库表级画像，完善一套基本的“数据资产”图谱。随着地图的权限管理和审计，可以逐步进行。资产不限于这个维度，需要由多个维度组成。安全团队已经实现了线上线下敏感数据的实时采集和感知，接下来的步骤就很明确了。数据的分级分类重点关注L3、L4级别的个人敏感信息，公司级别的敏感信息，以及敏感数据的加密存储。权限审计，数据库加解密等。更多的是场景，更多的是场景问题，数据溯源，场景的数据溯源流程大致如下，数据样本采集，数据样本特征分析（定位泄漏时间,定位字段,定位数量),确认泄漏源,确认泄漏的应用,我们需要从海量数据中提取特征,比如这批泄漏了哪些字段,该字段存在于哪些数据库表中同时，以及属于它的应用程序。定位调用时间，调用库表，依次调用应用。针对不同的数据泄露场景，安全工程师会在处理后的数据中有意添加一些“有色数据”。加入“有色数据”的好处是方便数据审计，方便数据溯源和采集特性。加密用于二级存储和分析的离线数据。各种数据脱敏（数据着色），二级数据着色的一般原理可以理解为：在不影响原有业务发展的情况下，将数据重新生成数据统计分析分析结果，比如业务需求“我们需要分析最近24小时各区域下单”，安全工程师需要对这个需求进行细化，细化后的业务需求为“业务需求订单转化率，关注的是整体占比，就是统计一个批次的百分比数据，但不关注某一领域的准确性。”比如小明使用的是联通手机号码185123123123，接下来几天我们保持联通属性185不变。位可以转换为“0”，即185123000，居住地址在市区不变，染色具体楼号，染色一批数据的性别比例，保持原来的男女性比例不变，这样这批数据在提供给业务方进行统计分析时不会有任何影响，同时也能保证用户数据的安全。这些都属于数据着色，区别在于不同的应用场景。对这方面感兴趣的同学可以参考美团关于数据差分隐私和数据着色技术的文章，非常值得一读。总结总之，笔者在开展数据安全工作中，踩过不少坑。总结起来，无非是受老三的限制，安全部门的规模，基础设施的程度，老板的重视程度（有没有出过事故），比如数据分散的时候，不统一。在数据总线的情况下，最好先不要异想天开的做权限管理，优先考虑那些可以占用资源少，可以闭环运行的任务，比如自动分类，分类，标记、加解密等，不断迭代安全部门。在数据安全方面的能力，丰富企业常见数据安全场景的解决能力，进而深挖标注着色权限管理，或许也是一个不错的选择。
