DBA如何巧用“三十六计”保障数据库安全?

Posted 51CTO技术栈

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了DBA如何巧用“三十六计”保障数据库安全?相关的知识,希望对你有一定的参考价值。

今晚 8 点,绿地酒店旅游集团信息技术部总监金勇杰将在《大咖·来了》告诉你 IT 管理者的秘诀。


直播主题:《IT 管理者的自我认知和沟通方式》

主讲人:绿地酒店旅游集团 IT 总监 金勇杰

直播时间:2019 年 12 月 26 日 20:00(今晚)

免费报名方式:长按识别下方二维码

长按识别左侧二维码报名

● 与观看直播链接相同


第 9 期出席《大咖来了》直播栏目的嘉宾是贝壳找房技术总监侯圣文,分享主题为《数据安全之数据库安全黄金法则》,过程中以 Oracle 数据库安全加固为例,详尽阐述了如何把管理混乱数据库规范化的三十六大黄金法则。


侯圣文,北京大学理学硕士,现任贝壳找房技术总监,Oracle ACE 总监,阿里云 MVP,OCM 联盟创始人,中国 Oracle 用户组(ACOUG)核心成员,中国 Cloudera 用户组(ACCUG)创始人,TiDB 用户组 TUG 联合创始人,恩墨学院创始人,ITPUB 资深版主,DataGURU 专家团成员,《SQL 和 PL/SQL 深度编程》译者。


1

数据库安全运筹帷幄三十六计


根据多年在数据行业摸爬滚打,积淀下来的经验心得,分享一个“向左向右”的理论。

DBA如何巧用“三十六计”保障数据库安全?

在数据库安全领域,左,是走为上计,相当于逃跑机制,当没有有效安全机制来保证数据库安全时,一旦发生重大故障,最后只能被动离开。


右,是运筹帷幄之决胜千里之外,相当于把很多安全的动作前置,避免数据库出现问题后束手无策。向左还是向右,答案显而易见。


接下来我们再分析下当前数据现状,如下图:

DBA如何巧用“三十六计”保障数据库安全?

管理规范的数据库除了数据库名不同,其他都相同,所谓相同是指安全加固的方式与保障规范,只有规范化才能工具化,只有工具化才能产品化,只有产品化才能过渡到真正无人职守的状态下依然智能加固。


反之,管理混乱的数据库除了数据库名字相同,其他都不同,所谓不同是指配置零乱、存在各种部署问题,也就存在着各种安全风险和漏洞。


那么如何把管理混乱数据库规范化,达到运筹帷幄的状态呢?这里总结了三十六大黄金法则分享给大家,如下图所示:

DBA如何巧用“三十六计”保障数据库安全?

以实际生产对环境的安全加固深厚经验为依据,在不同阶段、针对不同维度进行拆分,把三十六计分为胜战计、敌战计、攻战计、混战计和败战计五个方向。


2

胜战计


何为胜战计?以不战而驱人之兵者,是为胜战。在实际生产环境下,运维过程中,故障在所难免,需要做好成分的准备和规范,就可以有效减少故障、规避和绕过故障。这个方向总共有八计,下面我们逐一进行详尽阐述。


第一计

有效的备份重于一切

DBA如何巧用“三十六计”保障数据库安全?

对于一个 DBA 或数据安全的捍卫者,如果没有进行有效备份,当遇到重大故障的时候,能做的也只有走为上计,这种是多方都不希望发生的状态。


所以,要有效备份,有备无患,这样当灾难来临的时候,才能够做到心中有底,手中不慌。


所谓的灾难就是数据被误删除、修改、篡改,只要有备份,才会有恢复的可能性。虽存在时效性的问题,数据量越恢复成本就会越高,也可能不会瞬间恢复,但如建有完备的灾备方案,恢复时间会很好把控。


没有备份是唯一让 DBA 或者数据安全员在梦中惊醒的事,因为数据本身就是业务,数据本身就是生产环境最核心的资产,要用敬畏之心面对生产数据库。


第二计

制定应急预案和进行演习

DBA如何巧用“三十六计”保障数据库安全?

虽有备份,但恢复过程中,发现备份介质不可用怎么办?所以一定要制定应急预案,确保方案有效可执行的同时,一定要坚持进行演习,没有演练预案全是纸上谈兵。


还有就是就算没有真实的故障,每季度或半年一年做介质的有效性验证,避免在恢复过程中消耗时间。


第三计

建立容灾或异地备份

DBA如何巧用“三十六计”保障数据库安全?

在实际生产环境中,生产机房往往是在同一个地点,虽把备份放到本地服务器,出现极端的情况怎么办,如因为自然原因,整个机房毁掉,依然起不到有效保障。


很多特殊情况都是一定要保证数据留存性的,如银行级、电信级,绝对不允许数据丢失,那么就需要建立容灾站点或异地备份。


第四计

数据归档和读写分离

DBA如何巧用“三十六计”保障数据库安全?

任何一个生产环境,随时间推移,业务增加,数据会越来越多,导致数据库的读写和性能会越来越差,积累到一定程度便会影响生产环境的正常使用,故一定要做数据归档。


数据归档既可以把数据做离线保存、防止数据丢失的同时,又使得主生产数据库性能得到一个最大保障。


读写分离是一定要做的,把主站点做一定的拆解放到另一个站点,这样另外读库的动作就可以在另外站点进行,写库动作可以在主库进行操作。


切记要建立数据归档机制,比如对数据进行分级,哪些是生产环境主操作数据,哪些是可以做归档。需要在架构上做优先的设计之后,再去实现读写分离。


第五计

测试和生产环境隔离

DBA如何巧用“三十六计”保障数据库安全?

DBA 经常会犯的问题就是主操设备既用来生成又进行测试,这样会存在很大风险,一旦不小心连错库,就直接威胁到生产环境的数据安全。


这里强烈建议一定要做网络级的隔离,切记绝对一定不能在生产环境中进行测试。


这些还需要注意两点,一个是数据库应处于应用系统的最后端,并进行保护,另一个是避免将其置于对外的访问链接之下,需要内网环境下对其进行操作。


第六计

部署标准和完善的监控体系

DBA如何巧用“三十六计”保障数据库安全?

故障在所难免,要第一时间发现并解决问题,这就需要有一套部署标准和完善的监控体系。


监控的目的是为了预警,为了更早的发现故障,不需要等业务反馈不能用或数据丢失,被动进行处理,那就为时已晚。


第七计

制订规范并贯彻执行

经过逐年累月的实践会有很多经验,把这些归纳总结,制定成规范且贯彻执行,是减少故障的基础。基于全面的规范可推动开发和运维人员更加标准化。


一旦标准化成型,就有了参照,有了基线,进而未来才能进行工具化、产品化建设,待数据盘点后,智能化运维或安全加固的策划也将成为可能。


第八计

运维自动化和智能化

如何做到运维自动化呢?就是把运维的各种策略和变更尽可能用脚本或工具管理进行实现,这也是未来必然要走的路径,每个企业都应该投放精力、人力、财力进行建设,之后真的会极大的节省大量人工成本。


从工具化,转到自动化,之后在进行智能化的探索推进运维体系的持续提升,直到所有故障都可以在业务无感知的情况下提前处理,不需要人工干预。


到了那时候,运维人员就可以做更多预测性、盘点性工作,向业务侧倾斜,充分体现出自身对业务和产品的价值。


根据多年数据安全行业经验把这些计策总结出来,以方便大家进行参考,当然这些计策必须可以在实际生产环境当中落地实践,欲知余下二十八计,请戳视频连接:


以上是关于DBA如何巧用“三十六计”保障数据库安全?的主要内容,如果未能解决你的问题,请参考以下文章

[Linux]运维三十六计--腾讯两位大神的总结

全新印刷版《DevOps 三十六计》图书等你来拿

微服务架构三十六计

《DevOps三十六计》值得买么,买了也白买?

[机缘参悟-65]:《兵者,诡道也》-7-三十六计解读-败战计

「预售」拿到《DevOps 三十六计》那一刻,我哭了