以微盟故障来细说数据安全
作者 |王晓波责编 | 伍杏玲出品 | CSDN(ID:CSDNnews)【CSDN 编者按】23日,微盟系统出现故障,大面积服务集群无法响应,生产环境及数据遭受严重破坏。据官方通告称...
作者 | 王晓波
责编 | 伍杏玲
出品 | CSDN(ID:CSDNnews)
【CSDN 编者按】23日,微盟系统出现故障,大面积服务集群无法响应,生产环境及数据遭受严重破坏。据官方通告称,“犯罪嫌疑人乃微盟研发中心运维部核心运维人员贺某,贺某于2月23日晚18点56分通过个人VPN登入公司内网跳板机,因个人精神、生活等原因对微盟线上生产环境进行了恶意的破坏。”
真实版的“删库跑路”,那么我们该如何保障数据安全呢?
提到数据的安全这个话题时,往往给人的第一感觉是:黑客攻击、系统漏洞等信息安全领域内的事情,和未知的坏人为攻击有关。
但是别忘了,有未知坏人来破坏你的前题是什么?数据安全的前题又是什么?是数据好好地被保存在服务器里,系统良好地运行正常功能,如果这个前题没有了,那所谓数据安全也有没有了,所以我认为数据安全应该先从最基本的数据存储来聊起。
这时可能会有人会问:存储数据有何难处?
别说其他的,就说最简单的关系型数据库,可选择的太多了:开源的、商业的、云原生的等等。这些数据库最基本的特点就是各种数据存储的保障能力、备份能力等。还有一些存储的物理介质带来的问题:如存储在什么服务器?服务器宕机了怎么办?服务器硬盘坏了怎么办?……
解决起来也有很多现成方案:各种商业服务器类型、公有云提供的开箱就用的服务等。
所以这事情看起来就像小学生上学一样,可以很简单地过快乐的每一天。数据存储很简单,还需要解决什么呢?但是真的那么简单吗?真的可以无脑地用起来吗?数据存储真是安全的吗?
从近些年发生的各类数据存储故障来看,很多问题是我们平时认为的没有技术难点,很简单、基础的事情没有做好。
比如微盟的故障,作为一个技术人,一定要看看这些故障,并从中总结。好让技术人员不再出现同样的错误,不再出现那句经典话:“一条系统指令,删库跑路。”但是在微盟官网上看到的故障公告,好像还真是一起“删库跑路”的事情。
为什么删库跑路的故事,时不时在技术圈里发生呢?到底是哪里不对?
细细想来,技术本身可能没有错。任何技术都有其优缺点和使用场景。那是不是数据库或者操作系统提供的这些“删库”指令有“罪”?当然不是,指令何罪之有,那是人有“罪”?人有没有罪那我就不知道了,因为我不是法官。但是我知道,数据的基础安全管理和技术体系建设一定给“罪”提供了必备的条件。那“罪”的条件在哪里?
人员分工
人员分工问题,从开发到运维再到DBA,这些能直接触达数据的人员,如何正确地分工?
这个问题的本质很简单,“各司其职”就能搞定。但事实上在大部分情况下,我们可能并没有做到各司其职,为什么?有可能是因为人力资源的问题,人不够,那就一个人多干一点。有可能是为了快,特别是开发人员总有一句话“我自己一分钟搞定,找运维找半天,人还没有懂要干啥”。也有可能是各个角色人员之间知识差异太大,大部分时间的交流是牛头不对马嘴,导致对数据本身的重要性的理解不一致。这样的可能性还有很多,基本是反映了人员分工不合理的情况下会发生一些本质是简单的但危害是极大的事情。本质上来说因为人很“乱”。
权限分配问题
权限分配问题,权限的“乱”比起人的“乱”要更危险,因为权限分配不合理的背后反映的是对数据的不了解,如果数据权限管理者本身对数据的无知,这可能是真正的“罪”根所在。一个合格的权限管理者应该如何去分配DBA们的权限呢?应该是数据的重要度、影响度、人员分工情况,合理的人员按照安全原则去分配。
比如负责日常运维的DBA和负责数据安全性备份的DBA是不是应该分两个权限?还有一种可能性是大部分情况下,根本没有“数据权限管理者”这角色的存在,认为这是无用的人,这种情况就是技术体系的“罪”了。
技术体系建设的完整性:一个技术团队起初可能只是几个志同道合的程序员在一起写代码,互相间的合作是无比的紧密和团结,各项目多是全能型队员,随着团队的扩大,人员增多,就出现了团队管理和团队分工。
在将管理做好的同时往往会忘记一件事情:“一个合理的技术体系建设”。
技术体系建设与技术管理不同,管理更多地让团队人员有效的协作,但技术体系建设更多是让团队能在一个明确并准确的技术方向上前进。一个缺乏技术体系的团队,它对技术选择和使用往往随意缺乏标准的。
比如在云上应该是自己部署自己的数据库服务,还是直接使用云提供的产品呢?这个各有各的好处,并没有错与对。要根据自己的场景和技术团队的能力去决策如何选择,但是当缺乏技术体系下,这个选择可能是随意的,随意选择必定带来的是意外情况的准备不足。所以一个良好的技术体系能让团队有足够的技术准备去面对未知事件。
定时故障演习
故障演习这件事,我估计很多人会说的,并且大部分技术人员,技术管理人员知道它的重要性。
如果认真地去看故障演习地实际的落地情况的话,可能会很伤心,因为在很多情况下,它只是变成了一句“口号”,根本没有演习到位,为什么?
因为演习很麻烦,搞不好就真变故障了,所以大部分情况多是点到为止。这个点到为止的时间长了,不就是让演习变成“口号”了吗?在缺乏有效故障演习的情况下,一旦发生致命故障,故障的恢复将会变成全靠“等”的状态。所以一个计划足够真实的故障演习是最好的预防故障方案。
还有很多的可能事件都是意外发生的原因,多是鸡毛蒜皮的小事。正是这些小事才是频频发生“删库跑路”的真正原因,大家平时对它的关注太少了,总是不以为然,小事积攒了自然变大坑了。
除了这“小事”之外,有没有“大事”要来解决问题呢?如果有,可能是从整个公司层面上来看:技术到底是什么?是变现需求的工具还是企业发展的原动力,或者只是一个必须要消耗的成本团队。角度不同,位置不同,得到的结果必然不同。
总的来说,类似“删库跑路”的事情最直接的问题是技术人员的职业操守问题,但所有的解决点如果只围绕着操守展开的话,那么这样事件可能还不会从行业内消失。
真正能解决这问题的原动力我想应该是:对技术的改革,用更好技术去避免类似问题,对团队管理的改革,用有效的技术团队管理方法来避免类似问题,对技术风险的有效识别,以提前避免类似问题,把信息技术提高到企业级的认识成度,用企业决策的高度来避免类似问题。
作者简介:王晓波,同程艺龙机票事业群CTO。专注于云计算,高并发互联网架构设计、分布式电子商务交易平台设计、大数据分析平台设计、高可用性系统设计。完成同程基础架构建设,私有云系统建设,主要基础中间件研发。拥有十多年丰富的业务技术架构,基础架构经验,深刻理解技术驱动力的重要性。
#欢迎扫码留言#
对于本次事件,你有哪些看法呢?
【End】
有奖调查 「中国远程办公调查问卷」来啦!长按图片参与???? 有奖调查,填完问卷,查看问卷末尾抽奖页面的进群规则,即可加入交流群‼️(注:进群后才产生中奖者)
???? 我们准备了 10 本 CSDN 精选的技术书籍等你来拿!每天第 6 名和第 8 名入群者即为中奖者(中奖后会有小助手私聊),快长按图片填写问卷吧!
推荐阅读
☞清华、北大、985 高校教师之间有啥关系?Neo4j 创建知识图谱一查便知
☞华为最新 5G 折叠机 MateXs 发布,起售价 19000 多元
你点的每一个在看,我认真当成了喜欢
猛戳“阅读原文”,参与调查!
更多推荐
所有评论(0)