GMTC全球大前端技术大会(北京站)门票9折特惠截至本周五,点击立减¥480 了解详情
写点什么

数据安全建设踩坑经验谈:核心是数据,但治的是人

2020 年 7 月 18 日

数据安全建设踩坑经验谈:核心是数据,但治的是人

这次分享主要分为三部分:


  1. 我们如今这个 DT 时代的安全现状;

  2. 当前企业数据所面临的威胁;

  3. 结合 58 到家这两年的实践谈数据安全建设。


一、DT 时代安全现状

首先看看我们今天所处的整个互联网安全现状。如今我们已经从 IT 时代步入 DT 时代,DT 时代就是指数据技术。事实证明最近几年大数据越来越重要,数据已经成为企业的核心。


例如共享单车,传统观念上可能只是代步工具,但现在的共享单车一般都有感应器和定位装置,这时它就不仅是一辆单车了,可能我们走到什么地方,共享单车的 App 就可以告诉我们附近有什么商圈、酒店、餐馆,在什么地方买东西可能还可以用移动支付。当视角从单车走到了其他行业,就开始跨界关联了,另外车辆调度也是需要数据算法支撑的,同理还有外卖等行业。


然而新事物发展必然是有利也有弊的,数据技术也不例外,数据改变生活,但同时也给我们带来一些威胁。相信大家都有感触,今天网购个东西,明天一堆诈骗电话、骚扰信息接踵而来,什么海景房、小额贷款、各种培训等等每天就好像狗皮膏药天天骚扰我们。


下面这张图是摘录的 2018 年部分数据泄密事件,可以看到今天我们的数据并不安全,几乎每个月都有发生数据泄露事件。



另外国家和国际方面对数据安全的法律法规也越来越严,近些年陆续出台了许多安全合规制度。可见在数据技术时代,数据安全的保障已经是每个企业需要承担的责任和义务。



二、企业数据安全威胁

2018 年波洛蒙研究所做了一个企业内部威胁成本报告,发现内部问题占比最高,企业数据安全威胁主要来自内部。



为了找到 58 到家内部的威胁,我们在内部做了一些调研。58 到家主营业务是家庭服务行业,是一个连接劳动者和用户的平台,而且用户很垂直,例如月嫂、育儿嫂对应的用户就是母婴家庭,另外也会有一些明星客户、商务客户等,因为服务总要落到线下,就会涉及到客户的一些家庭信息。所以不论是我们的客户信息、服务人员信息(因为家政服务人员都是我们自己培训出来的),以及员工信息、财务数据等等,这些都是我们要保护的数据。



需要保护哪些东西找到了,接下来就是见招拆招,从哪些人能够接触到这些数据、什么环境能够接触到这些数据等场景去考虑,详见下图:



  • 恶意入侵:来自外部的入侵或攻击,这是所有公司都有可能会遇到的问题;

  • IT 管理:运维、DBA、BI、特权账户等权限大、掌握的数据量也大;

  • 业务人员:这类人员比较难以管控,因为群体大,并且他们本身拿到的就是一些明文数据;

  • 合作方:直接拿到的也是明文数据,而且本身就有权限,只不过是看他们需不需要读取这么多数据而已。


三、数据安全探索实践

以上分析了我们需要保护的数据以及威胁来源,接下来具体看看我们 58 到家在数据安全上的探索。


安全治理的前提是基础安全要做好,基础安全就像房子的根基,如果根基不稳的话也就谈不上后面的盖大楼了,所以数据安全的前提还是要先做一些基础安全的保障,包括以下这些部分:



接下来是 58 到家在数据安全的体系化建设上的整体指导思路,整个体系的核心是数据,治理的对象是人。



首先要知道数据在哪,这就需要做到数据发现,要知道哪些库里面存在着敏感数据。其次要对已知的数据做好对应的分类分析。把前两项处理好后,再考虑哪些人能够访问这些数据,做好认证和权限的管控。再之后就要考虑做好对应监控和审计工作。最后当我们发现违规或泄密时,要能及时做好事中的阻断和事后的溯源。


早期的数据分类发现是通过人工的方式实现,但这样无法做到及时更新,后来慢慢的采取了一些自动化的数据发现技术,并在过程中进行敏感数据的自动打标。


接着在认证权限这块,58 到家目前人员打通了 HR 系统、SSO 系统、权限系统、业务系统,特别是针对业务人员的管控问题,我们首先对员工做了身份统一处理。从员工入职开始就匹配人员角色,分配角色权限并增加统一认证。同时,在运行过程中会有监控规则,比如涉及敏感数据权限时,需要对应的审批,审批过程会自动进行职责分离,敏感权限分析等自动化分析,在使用过程中还会有对应审计;员工离职时,其相应的角色权限也会被一并清除。



有了这种认证和权限之后,下面讲一下我们是如何做好事中或事后的监控、溯源和阻击的。


我们的监控体系主要分成三块,一是堡垒机日志、Binlog 和 Gltlab 日志,会对其中的敏感操作进行审计,若发生敏感操作则会发出告警或阻断;二是基于业务人员做的,首先会对包括 Nginx-Lua、SSO 日志、AMS 日志、VPN 日志、上网行为日志在内的日志做数据过滤,把发现的敏感接口推荐出来,然后基于这些接口做了一些引擎和规则的判断,包括一些场景的录用等做了在线分析和离线分析,同时集成到 SOC 上去做一些告警,联动防火墙等做一些阻断;三是鉴权分析和被动扫描这块,主要是用于降低业务人员的一些行为风险,比方说违规操作、访问数据异常、账户盗用、登录异常以及一些接口的异常等。



这个系统上线之后,帮助我们发现了不少内部人员违规读取数据的问题,我们也都一一做了相应的处理。当然我们也踩过不少坑,最后跟大家分享下这些坑,给大家一些避坑建议。


坑 1、监督 &赋能: 很多安全部门都会有一种自己是监督人的心态,但这样跟业务沟通时会让他们产生抵触心理,觉得安全的人是来挑事儿的,导致很多东西无法推进,得不偿失。所以我们应该把自己作为服务方,去给业务赋能,让业务产生信赖,甚至会主动找我们做些介入。


坑 2、闭门造车 &多部门协作: 起初我们安全自己做了很多东西,但做好后真正要上线时,发现需要其他部门做些对应的协助,可能就会有不太乐意的情况。所以涉及到跨部门的项目,做之前一定要提前做好规划和沟通。


坑 3、抓主要矛盾: 我刚到 58 到家的时候比较心急什么都想做,包括基础安全、数据安全、业务安全等等,但做了一堆东西后发现这样反而什么都没做好。所以还是应该先做好基础安全,然后根据公司自身的需求再一步步做其他安全建设。


坑 4、先技术 &技术管理并重: 起初我们认为能用技术解决的就不要去扯别的,后来我们发现如果没有制定明确的制度,会导致很多权限问题,有时就算发现了异常也很难追究清楚,所以前期制定好明确的规章制度还是非常有必要的。


坑 5、黑猫白猫能抓老鼠就是好猫: 只要能满足自身需求,无论是自研也好、采购也好、开源改造也好,都是可以的。而且也未必要使用一些高大上的技术,比如说我们的数据安全分析平台原本是打算用机器学习的,但实际上我们内部数据访问量其实没那么大,后来我们发现利用统计学的一些规则直接就可以解决问题,没必要用到 AI 算法等。所以归根到底,只有适合自己的才是最好的。


Q&A


Q1:告警规则的制定有要求吗?


A: 告警规则的话我们的做法是先收集一些互联网数据风险案例,同时和内审、监察聊下他们处理的一些内部历史案例,最后再结合业务场景脑暴列出一些违规行为,制定一些对应的规则;至于规则的阀值的话,前期可以设置低点,慢慢根据历史数据最终逐步给角色或者细化到每个人去画像。


Q2:有基于日志的告警方案吗?


A: 目前我们自己用的告警的话是使用的内部架构提供的,一个封装好的服务。不过我们之前也做过一些其它的,例如使用 ES 做一些告警。有个开源的 Elastalert 你可以看下。


Q3:怎么给老板衡量做安全的投入产出?


A: 这个问题其实是所有安全团队都会遇到的问题,相对业务来说安全本身是支出部门,想要讲清楚这个比较难,不过又恰恰是很重要的。


这块我的经验是如果是基础安全的话,比如我们发现并解决了多少问题,这些问题如果是被外界获取,可能带来哪些损失。如果是 SDL 的投入,至少能够保证我们做完这些项目需求评估后,要保证不会出现除 0 day 以外的高危安全问题。


如果是数据安全相关的话,这个其实还算比较好讲的,就是我们发现了多少违规或者泄密,挽回了多少损失。


Q4:你们安全团队多大?与运维、大数据的关系?


A: 安全团队的话去年相对规模大一点,近 10 人。今年年初有所调整,目前的规模要小一些;现在安全团队和运维、大数据都是并行的兄弟部门。也是因为目前安全团队相对较小,所以和运维以及 BI 还有 DBA、架构、配置管理等等各部门都会有一些合作一些项目。


Q5:怎么做数据脱敏的?敏感数据访问的审批和执行怎样才能快点?


A: 数据脱敏的话,首先明确哪些是敏感的,然后确定哪些是可以完全脱敏的,那些是数据分析或者外部合作必须要是使用的。明确出来一些等级,然后根据不同需要,选择是动态还是静态,是可逆的还是不可逆的等等。


审批过程的化,还是要配合一些线上化的流程,刚刚分享里面有提到我们数据地图发现,这块打的一些标签。这块是如果对方申请导出内容不涉及敏感字段那自动通过,反之工单就需要按照不同环节就行流转。


Q6:如何保证数据可视化过程中不会数据泄露?


A: 这个多方面去处理吧,应用显示的话可以不显示全部的,例如 188(点击脱敏)9999;这样这个点击过程就可以做到记录,超频异常的话也可以告警。


对于拍照截图这样的其实只能依赖水印了,当然这个方面目前我们也只是明水印只是震慑作用。


安全侧还可以去做的点,就是今天提到的流量接口的监控了,还有一些权限的管控。


Q7:程序连接线上数据库,你们怎么避免开发人员接触线上数据库连接参数的?


A: 在到家的话,首先网络是有严格安全域划分的;部署是要通过统一部署平台的,也就是一般情况下开发人员是不需要访问线上主机或数据库的权限。另外应用调用数据时候不是直接使用密码连接数据库的,是使用 key 代替密码,通过 keycenter 系统中转的,这样数据库连接就是白名单形式,开发人员是没办法直接连接线上库的。


作者介绍


刘欢,58 到家安全负责人


  • CISP,曾参与政府、军工、运营商、银行、互联网企业等安全评估建设项目;

  • 现负责 58 到家集团安全防护体系的建设。


原文链接


https://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650791377&idx=2&sn=c9364b04a447fe0a573d55e4dcada6a5&chksm=f3f96844c48ee152e7938c3d0bc75e1378db4308d22a6cb24979148d9214881d10fb1575364b&scene=27#wechat_redirect


2020 年 7 月 18 日 10:001400

评论 1 条评论

发布
用户头像
学习了

2020 年 07 月 18 日 23:04
回复
没有更多了
发现更多内容

到手的股权,又没了 | 法庭上的CTO(2)

赵新龙

股权 CTO 28天写作

第七周作业

孤星

5 千字长文+ 30 张图解 | 陪你手撕 STL 空间配置器源码

herongwei

c++ 源码 内存 后端开发 stl

性能压测的时候,随着并发压力的增加,系统响应时间和吞吐量如何变化,为什么?

落朽

架构师训练营第11周课后作业

吴传禹

极客大学架构师训练营

系统性能的主要技术指标以及变化

皮蛋

Mybatis【5】-- Mybatis多种增删改查那些你会了么?

秦怀杂货店

Java mybatis JDBC

架构师训练营 - 第十一周总结

一个节点

极客大学架构师训练营

《Linux就该这么学》PDF版免费下载

计算机与AI

Linux

架构师训练营第 1 期第 11 周学习总结

好吃不贵

极客大学架构师训练营

架构师训练营 -week11-总结

大刘

极客大学架构师训练营

架构师训练营第 1 期第 11 周作业

好吃不贵

极客大学架构师训练营

java集合【10】——— LinkedList源码解析

秦怀杂货店

Java 集合 linkedlist

【Java基础】-- instanceof 用法详解

秦怀杂货店

Java

11.8作业

张荣召

架构师训练营第11周总结

吴传禹

极客大学架构师训练营

使用PicGo存储markdown图片(阿里云或者github)

秦怀杂货店

markdown 图床

Mybatis【6】-- Mybatis插入数据后自增id怎么获取?

秦怀杂货店

mybatis

11.2安全架构:加密与解密

张荣召

架构师训练营第 1 期第11周作业

业哥

从华为看VUCA时代如何让组织不断乘风破浪?

Alan

华为 战略思考 组织发展 组织活力

程序员入门之路

思想者杰克

程序人生

IT做得好的时候,是什么状态?

boshi

职业

第七周总结

孤星

11.1安全架构:Web攻击与防护

张荣召

月薪8k和月薪38K的程序员差距在哪里?学习Linux C/C++ 这些你就知道了

ShenDu_Linux

c++ Linux 程序员

JDBC【4】-- jdbc预编译与拼接sql对比

秦怀杂货店

sql JDBC

架构师训练营第七周作业

丁乐洪

JVM,JRE,JDK之间的区别和联系

入门小站

JVM

【java基础】-- java接口和抽象类的异同分析

秦怀杂货店

Java 接口

架构词典:缓存

lidaobing

缓存 架构

数据安全建设踩坑经验谈:核心是数据,但治的是人-InfoQ