论数据库运维的全流程管控技术

本文讲的是 论数据库运维的全流程管控技术,“重建设 轻管理”一直是我国各行业信息化发展的主要困境,这个问题在数据库系统的建设、管理工作中同样存在。近年来,这种局面造成的后果已开始明显显现:各类来自内部或第三方外包人员的数据泄露、丢失和被篡改事件频频发生,由此导致的珍贵数据资产损失和相关系统功能瘫痪等情况,如同紧箍咒一般,三不五时地刺激着运维部门本就紧绷的神经。

数据库运维安全现状

数据库运维人员需要承担数据库系统的权限分配、故障处理、性能优化、数据迁移备份等工作任务。这些关键环节中,如果出现任何纰漏,都可能导致不可逆的数据资产损失或其他不良后果。

由于缺乏细粒度的管控手段,数据库运维工作普遍存在内部人员、甚至第三方外包人员间的账号共享、主机共享、高权限账户滥用等情况;加之人工操作无法保证100%的准确度,数据库日常运维操作面临以下一系列安全风险:

操作身份不明确
操作过程不透明
操作内容不可知
操作行为不可控
操作事故不可溯等
面向不同的数据库运维场景,操作申请人、执行人、审批人、操作对象、操作内容各不相同,如何提高对数据库运维操作的把控力?实现“透明化”管理是运维主管心目中的最佳答案。因此,专业的数据库安全运维系统应运而生。

事前审批——为运维管理者提供专业的统一平台

为了规范内部人员及第三方外包人员对数据库的访问管控,不少企业的管理部门已制定相关要求,这里概括为以下几个重点:

  1. 通过认证机制进行运维人员身份鉴别,这是解决数据库账号共享、运维主机共享场景下,运维人员精准身份鉴别及权限划分的问题,认证机制可以包括发放口令码及动态令牌两种方式,双因素认证机制相对更严谨。
  2. 涉及数据库的批量操作(批量查询、批量导入导出、批量为客户开通、取消或变更业务等),运维人员必须执行相应的审批流程,由相关主管审批后方可执行。涉及超权限的数据库运维操作,运维人员需要额外提交申请,由相关主管审批后授权操作。
  3. 涉及业务投诉、统计取数、批量业务操作、批量数据修复等需求进行的客户敏感数据查询、变更等操作前,运维人员必须取得业务管理部门的相关公文,并执行审批流程。执行操作时,对极高敏感度的数据操作,需要保证多人在场、多人协作方式以确保操作安全性。
  4. 需要对所有审批流程的操作工单整理备案,记录操作原因和工单编号,并由专人负责审核。

我们看到管理要求中对运维操作的事前审批进行了重点要求,在实际落地中,目前大多数单位的普遍做法是由运维人员通过纸质申请单或办公OA系统填写工单,说明运维操作事项,提交相关领导审批。纯纸质化办公模式存在的问题很明显:效率低、成本高、资料保存和查询困难、不便于多人协同办公等,而类似OA系统的审批平台,不仅功能细化程度不够,对于数据库运维操作的申请归根结底还要依靠审批人的判断,人工把握操作风险,OA系统仅仅解决了流程上的问题。

综上,在审批环节中,专业的数据库安全运维系统应该能够提供两方面的能力:其一,必须能够整合审批流程,为内部运维人员、第三方外包人员、业务主管等多角色提供细致统一的审批平台,能够提供对操作人、操作对象、操作内容、操作时间、相关审批人等等细粒度的申请条件,使审批过程清晰、透明。

基于人性化设计,考虑审批人的职位不同,需要能够支持技术化或业务化的申请模式,专业的安全运维系统需要支持多种申请提交方式,如:提交完整操作语句、提交“时间+对象+操作”的条件组合,以禁止某些高危操作和敏感表访问的方式进行审批授权,提交指定时间和周期的执行脚本。此外,另一个重要能力是,应当能够提供对申请内容的智能分析能力,能够对操作申请进行风险预估和异常行为评测,为审批者提供决策依据,在操作前最大可能的降低运维事故概率。

事中管控——实现透明化管理的关键发力点

目前数据库运维工作的管理模式重在事前审批,审批通过后则由运维人员自行安排操作执行,也可能由其他人员代操作,整个操作过程不定因素很多:

运维人员实际操作是否与申请一致?
实际操作人是谁?
出现误操作,如何追溯?
如何管控来自内部或第三方运维人员有意无意的高危操作?
堡垒机是目前大多数企业的普遍解决方案。而事实上,由于缺乏对数据库通讯协议的精确解析能力,堡垒机只能实现对操作人身份、操作目标库等最基本的身份识别,这其中差了最关键的一环:对操作内容、操作过程的有效管控。因此,对执行过程进行透明化管控是数据库安全运维系统的重要使命。

当申请人执行操作事项时,专业的数据库运维系统应当能够结合操作前的申请事项,通过与申请内容的细化匹配以及自身的智能分析,帮助管理者进行实时的运维过程监控;自动根据预设置的风险控制策略,结合对数据库访问的实时监控信息,进行语句特征检测及审计规则检测,任何尝试的数据库攻击、违反安全策略或有悖于申请事项的疑似危险操作,都会被检测到并实时阻断或告警。

此外同样重要的一点是,真正有价值的产品绝不能对用户原有的工作习惯产生过多影响。比如当运维人员需要其他人进行代理操作时,用户依然可以通过第三方工具登录数据库进行操作。通过运维系统提供的操作口令码进行简单认证,口令通过者只能执行其申请的操作内容,未经口令认证者同样无法操作敏感数据;在不改变原有工作习惯的基础上,防止越权操作及违规操作。

以上,针对运维人员的操作行为做出严格的事中控制,实现了对敏感数据操作的权限控制,但是运维人员仍可以看到敏感数据,我们如何保证运维人员不会通过拍照、截屏等方式获取敏感数据?在查询结果中加入敏感数据遮蔽的功能正是基于这样的考虑,重点在于遮蔽效果必须是动态的,对于具有不同权限的访问人员执行不同的遮蔽策略,在不影响正常运维、开发工作的前提下,防止运维人员泄露敏感数据。

事后追责——让运维管理者有据可查

事后追责和审查取证是数据库运维管控的最后一环,这里需要运维系统对存储的申请与执行的操作记录进行数据分析,通过运维人员和审批人的行为记录形成可视化的统计分析。提供各维度的报表系统,当出现安全事故后,能够精确定位到违规操作的实际执行人、审批人,为事后追责和审察取证提供无可争辩的准确依据。

至此,数据库安全运维系统完成了对整个运维过程的全流程管控,通过引入这样的专业运维管控系统,实现了事前审批、事中控制、事后追踪三步重要环节的透明化管理,为企业数据库系统“重建设轻管理”的现实问题,给出了令人满意的答案。另一方面,这样自动化的智能管控技术,更是对数据库运维人员的解放,高强度的工作量硬撑了一年,别让不经意间的数据安全事故成了压垮运维人员的最后一根稻草。

时间: 2024-11-03 16:38:07

论数据库运维的全流程管控技术的相关文章

数据库运维原则

一.数据库运维工作总原则 1.能不给数据库做的事情不要给数据库,数据库只做数据容器. 2.对于数据库的变更必须有记录,可以回滚. 二.权限相关 总原则,以最低粒度控制权限. SELECT权限:所有开发人员均可拥有自己业务范围内的表权限. INSERT/UPDATE/DELETE权限:所有项目经理可以拥有自己业务范围内的表权限. Structure权限:数据库管理员可以拥有. Administration权限:系统管理员和数据库管理员可以拥有. 程序访问权限:根据IP和系统名建立用户名,只拥有必须

美团数据库运维自动化系统构建之路

美团点评技术沙龙由美团点评技术团队主办,每月一期.每期沙龙邀请美团点评及其它互联网公司的技术专家分享来自一线的实践经验,覆盖各主要技术领域. 目前沙龙会分别在北京.上海和厦门等地举行,要参加下一次最新沙龙活动?赶快关注微信公众号"美团点评技术团队". 本次沙龙主要围绕数据库相关的主题,内容包括美团数据库自动化运维系统构建.点评侧MySQL自动化服务平台RDS.美团数据库中间件.和小米高级DBA带来的Redis Cluster的大规模运维实践. 讲师简介 宁龙,美团网高级DBA,现负责美

从一个简单的约束看规范性的SQL脚本对数据库运维的影响

原文:从一个简单的约束看规范性的SQL脚本对数据库运维的影响   之前提到了约束的一些特点,看起来也没什么大不了的问题,http://www.cnblogs.com/wy123/p/7350265.html以下以实际生产运维中遇到的一个问题来说明规范的重要性. 如下是一个简单的建表脚本,表面上看起来并没有什么问题.其中创建了3个约束,一个主键约束,一个唯一约束,一个默认值约束,该脚本执行起来没有任何问题. USE Test GO if exists(select 1 from sys.table

专访平安科技数据库技术专家梁海安:数据库运维未来很大一部分工作会被平台或工具代替

杭州·云栖大会将于2016年10月13-16日在云栖小镇举办,在这场标签为互联网.创新.创业的云计算盛宴上,众多行业精英都将在这几天里分享超过450个演讲主题. 为了帮助大家进一步了解这场全球前言技术共振盛会的内容,采访了各个论坛的大咖,以飨读者. 以下为正文: 梁海安,平安科技数据库管理技术专家.2006年毕业后即加入平安科技数据库团队,十年Oracle运维管理经验,近几年主要负责PostgreSQL运维管理.目前主要负责平安科技PostgreSQL推广,整体数据库监控平台建设,自动化运维,数

IT运维亟待管理流程化

进入21世纪,积极推进数据大集中是国内银行业的一项重大举措,目的是实现银行集约化管理,降低经营风险.然而,数据大集中就像是将全世界的桥梁都整合成一座桥梁一样,它在方便银行经营管理的同时,也给银行的IT运维 提出了巨大的挑战.一方面数据中心集中了几乎所 有的应用和系统,技术 复杂度和关联度今非昔比:另一方面运维人员的高度集中和专业化也带来了运维管理的高度复杂性.虽然这些年银行在安全设备的应用上越来越多,安全手段的采用也越来越多,但安全状况却不见好转.一些银行的IT管理人员经常纳闷:我们已经在安全方

高效运维之Redis集群技术及Codis实践

这篇是<中生代>转载的一个关于运维的文章.作者是触控科技运维总监萧田国.文章在运维圈子流传甚广.特别也发在社区,分享给感兴趣的朋友. 前言 诚如开篇文章所言,高效运维包括管理的专业化和技术的专业化.前两篇我们主要在说些管理相关的内容,本篇说一下技术专业化.希望读者朋友们能适应这个转换,谢谢. 互联网早在几年前就已进入Web 2.0时代,对后台支撑能力的要求,提高了几十倍甚至几百倍.在这个演化过程中,缓存系统扮演了举足轻重的角色. 运维进化到今天,已经不是重复造轮子的时代.所以,我们在架构优化和

Postgresql数据库运维笔记

1. 对象创建 研发.测试无权创建.删除数据库和表,也无权修改表结构,都由DBA统一操作 a)创建数据库: CREATE DATABASE dbsample           --数据库名不能与现有库重复,pg严格区分大小写,因此请统一小写命名,不能使用特殊字符(@ # &等),不能以数字开头,可以以字母和下划线开头,不能超过63个字符 WITH OWNER = postgres                    --指定数据库的属主为postgres       ENCODING = '

运维前线:一线运维专家的运维方法、技巧与实践1.6 运维自动化系统的实现

1.6 运维自动化系统的实现 挑战自动化的极致场景(可视化),是运维人员对极致的追求.极致的自动化是运维事务全流程的自动化,运维事务全流程自动化是包含了一次应用完整交付所涉及的所有资源的自动化能力,比如说DNS资源.负载均衡资源.数据库资源.服务器资源.配置资源等.下面将列举几个典型的运维自动化系统以供大家参考. 1.6.1 DNS管理系统 DNS是Web形态下的一个重要入口,用户服务的访问严格依赖于这个服务入口.现在一般被称为GSLB(全局服务负载均衡调度),目前是CDN服务中的重要服务节点.

《IT运维之道》——13.3 数据库

13.3 数据库 数据库是一个单位或是一个应用领域的通用数据处理系统,它存储的是属于企业和事业部门.团体和个人的有关的数据集合.数据库中的数据是从全局观点出发建立的,按一定的数据模型进行组织.描述和存储.其结构基于数据间的自然联系,从而可提供一切必要的存取路径,且数据不再针对某一应用,而是面向全组织,具有整体的结构化特征. 数据库中的数据是为众多用户所共享其信息而建立的,已经摆脱了具体程序的限制和制约.不同的用户可以按各自的用法使用数据库中的数据:多个用户可以同时共享数据库中的数据资源,即不同的