Bad Rabbit病毒引发的企业数据安全的思考与应对方案

十月底,欧洲地区爆发新型勒索病毒Bad Rabbit,感染范围包含俄罗斯、乌克兰、德国等多个东欧国家。据国内网络安全企业介绍,该病毒伪装成Adobe flash player欺骗用户安装,感染后会在局域网内扩散。目前国内暂时还没有感染到该病毒,但国家通信管理局今日也已广泛提醒国内用户及时采取应对措施,密切关注病毒演变情况,积极防范。

在过去的一年里,比特币勒索,WannaCry病毒等给很多企业带来了严重的损失,这一次bad rabbits再次敲响警钟。

数据是企业的重要资产,企业的核心数据更是企业最重要的资产之一,保障核心数据的安全是信息建设和运维过程中最重要的工作。数据的篡改和泄露给企业造成的损失是不可估量的。在信息安全形势日益严峻的国内外形势下,数据安全,尤其是中央企业的数据安全更加关键。

业务快速发展引发的数据安全隐患

随着业务快速增长和信息化建设不断发展,企业的数据库规模越来越大,数据在成为企业核心资产的同时,其被违规访问、删除、修改、复制等安全问题也成为了企业IT最大的威胁,企业基于数据库的安全防护也成为越来越迫切的课题。

对于电网行业来讲,数据的安全不但关系着电力业务的正常开展,而且直接关系到每一个用户的信息安全,因此保障安全、促进发展成为贯穿科学建立电力数据安全技术体系,促进电力业务发展的根本原则

南网某网省公司在深入信息化建设的过程中,建立了以“6+1核心系统”为中心的业务系统生态圈,系统的整合集中给运维管理带来了极大的便利,也促进了企业的业务变革和创新。然而,由于各个系统之间的数据流向错综复杂,随着业务的发展数据量的增加,数据安全问题日益暴露出来,核心数据的副本难易控制,运维人员的操作无法跟踪,核心系统面临着关系难说清、安全难管控、运维难管理三大安全难题。

从数据库的安全生态角度来讲,安全可以分为五大方面:软件安全备份安全访问安全防护安全管理安全。确保使用正版安全的软件以及做有效的数据备份的安全管理的前提,除此之外,在数据库的安全防护层面,确保数据的访问来源和访问方式安全可控,以及加强企业内部的安全管理流程,都是必不可少的环节。

而目前对于该网省集团来说,随着业务系统变得复杂,在数据交互安全(防护安全)和管理安全上面临很大的隐患。

技术为本,安全管控

基于日常运维过程中面临的困境和行业信息化发展现状,集团内部打算从两方面加强企业的数据安全管控。

1、通过建立中间库,通过中间库隔离外围系统与核心系统之间的DBLink对外围系统对核心库的访问进行隔离

2、创建数据运维平台对数据库操作进行严格管控和审计

中间库的数据隔离

通过创建中间库隔离外围系统对核心数据库的访问,外围系统的数据访问请求创建DBlink到中间库,外围系统的数据访问需求按照访问范围、访问频率、访问目的等要素进行审核后同步到中间库,外围系统从中间库获取所需数据,同时对中间库进行细粒度审计,严格管控外围系统对中间库的访问。这样,不仅避免了外围系统对核心库运行的影响,中间库也能完全掌握数据的流向。

这对平台的稳定性、安全性、并发性、易管理性都有较高的要求。

从技术角度来讲,在保障核心系统安全稳定运行的情况下,部分核心数据能够被必要的外围系统获取到,需要在技术上保证同步技术的可行性。 从管控平台上,需要统一服务标准和流程,要实现易操作和易维护。 从基础架构角度,接入平台作为核心系统和外围系统的交互枢纽,是整个数据流的关键环节,为了保证接入平台的安全稳定高性能运行,需要基础数据库架构具有开放式、高可靠性、高性能、可扩展性、易管理性的特点。

基于以上的考虑因素,在其服务商云和恩墨专家的建议下,计划采用分布式存储架构是实现中间库的高可用。同时建立数据运维平台对日常操作进行管控,数据运维平台整体功能架构如下:

在服务和应用层面实现对数据的安全保护,针对当前系统DBlink流向复杂的问题,首先对系统化进行全方位的审计,包括数据库层面比如用户权限、SQL等审计,操作系统审计等,避免无权或没有必要的重复访问。同时对DBlink进行封装,保证相似任何情况下,核心数据都不会直接暴露出来,访问者只能看到其结果展示。

在支撑层面实现平台的高性能和高可用。基于zData的分布式管理平台,通过多台X86服务器配合InfiniBand交换机、InfiniBand HCA 卡及PCIe闪存卡协同工作,能够极大提升计算能力、IO吞吐能力,同时,降低维护成本。

对于展现层、应用层和服务层的操作,指定统一的标准和操作规范。对不同的操作人员进行合理的分组和权限分配,避免应用层的非法访问。

开发数据库运维平台实现管理安全

针对管理的安全问题,建立企业核心数据接入平台,保证核心数据的安全可控,在管理理念、管理方法、管理规范上进行全面提升,实现低成本、高效率的运维能力。这既是企业核心数据安全的迫切需求,也符合目前信息系统建设大环境的方向。

1、严格管控对生产库的DML/DDL高危操作

由于运维工作的需要,二、三线运维人员对数据库有DML/DDL的权限,这部分操作对于核心数据的安全威胁较大,因此对这部分操作实现审批流程,只有通过业务审批、技术审批的DML/DDL操作才能执行,同时在执行前会对数据进行强制备份,备份数据安装任务标识存储到中间库中,提供高效的恢复机制。

2、采用工具箱将日常重复的工作进行封装,规范日常查询,管控频繁的查询工作

对于运维工作中需要频繁对数据库进行查询的工作,经过调研发现这部分工作的查询语句不多,可以进行固化,因此将这部分查询语句进行封装,以服务的形式提供给运维人员使用,运维人员在对数据库查询时不再需要编写SQL语句,只需要选择对于的查询服务并输入相应变量即可,服务通过权限授予运维人员,对服务的调用都会被记录日志。这样既管控了运维人员频繁查询工作,也防止低效的SQL语句对生产库造成的冲击。

3、对于需要频繁进行查询即更新的运维工作,通过SQL解析器进行高效的执行

在网省内部的数据运维工作中有部分特殊的操作,比如数据治理工作,该项工作需要频繁的对生产库进行查询、修改,这部分工作对于核心数据的安全威胁较高,但是查询语句不能固化、更新操作不能走审批流程。针对类似的需求,数据运维平台提供SQL解析器功能,在SQL解析器中可以直接编写并运行增删改查语句,但是增删改查的操作权限会按需授予用户,同时通过对象黑白名单控制用户能操作哪些对象,对于非法的语句会被直接阻断,同时在SQL解析器中的操作都会记录操作日志。

在IT 技术高度发达的今天,风险是无处不在、层出不穷的。当今IT 安全建设的重点已经从传统的网络安全、系统安全等领域转向了如何加强 IT 系统核心的数据库安全防范。而对于IT核心的数据库系统,采取主动防护,将可以帮助我们监控、分析和屏蔽很多未知风险。

多重保护,杜绝隐患

除了在技术上进行安全管控之外,网省集团还在以下方面重点加强安全措施:

1、组织保障 比如成立领导小组,统一管理各项接轨工作;建立管控机制,协调工作资源与进度;设立专门的项目负责小组等。 2、制度保障 比如工作汇报机制、完善跟踪检查和监督机制、完善绩效管理机制、建设常态交流机制等。

该电网集团通过核心数据接入平台对数据的交互及数据运维工作进行统一管控,技术与管理双重加强,既能防止数据库的内部误操作导致的数据不安全,也能防范来自外围数据库的攻击。

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2017-11-25

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏即时通讯技术

阿里技术分享:深度揭秘阿里数据库技术方案的10年变迁史

本文原题“阿里数据库十年变迁,那些你不知道的二三事”,来自阿里巴巴官方技术公号的分享。

1365
来自专栏Golang语言社区

小米数据工场的技术架构和小团队如何玩转大数据

本文是WOT2016互联网运维与开发者大会的现场干货, 新一届主题为WOT2016企业安全技术峰会将在2016年6月24日-25日于北京珠三角JW万豪酒店隆重...

3445
来自专栏数据库新发现

积极拥抱互联网化 北京电信核心数据库完成跨平台迁移

“变化,无论是突如其来的,还是循序渐进的,有时都会淘汰你认为理所当然的一切。忽略这一现实,就像近年来许多领导者那样会带来毁灭性的后果。”商业大师拉里·博西迪在...

642
来自专栏CSDN技术头条

微服务与单一整体式架构的优劣浅析

责编/钱曙光,关注架构和算法领域 开发者要么出于本能,要么很快就能在痛苦中发觉:即便一个很小的变化也能改变一切。就像攀岩那样,每次挪移都会影响到未来的抉择,因此...

1987
来自专栏用户3246163的专栏

为什么DDD是设计微服务的最佳实践

在本人的前一篇文章《不要把微服务做成小单体》中,现在很多的微服务开发团队在设计和实现微服务的时候觉得只要把原来的单体拆小,就是微服务了。但是这不一定是正确的微服...

662
来自专栏BestSDK

什么样的大数据平台架构,才是最适合你的?

技术最终为业务服务,没必要一定要追求先进性,各个企业应根据自己的实际情况去选择自己的技术路径。   它不一定具有通用性,但从一定程度讲,这个架构...

9366
来自专栏FreeBuf

验证安全2.0时代:极验验证码评测

*本文属“WitAwards 2016年度安全评选”专题报道,未经许可禁止转载 验证码的英文是CAPTCHA,其全称为Completely Automated ...

2277
来自专栏CSDN技术头条

随笔|关于数据感悟

➤明确技术与业务的关系 知识和发明来自实践和生产的实际需要,OSI的7层模型再美、再学院化也没有干过TCP/IP。 切莫强求技术驱动,技术职责第一要务是做好深度...

1845
来自专栏DevOps时代的专栏

案例 | 从一次严重的系统停机事件说起....

本文根据John Rzeszotarski和Chris McFee在DOES16(DevOps企业峰会16)的演讲《Banking on DevOps》整理而成...

17410
来自专栏包子铺里聊IT

Facebook 的技术故事

如同每一个大型IT公司,Facebook 的技术架构演化史也是极为丰富。和 Google 一切 Infrastructure 从零研发的策略不同,最初的 Fac...

2726

扫码关注云+社区