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

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

数据库运维安全现状

数据库运维人员需要承担数据库系统的权限分配、故障处理、性能优化、数据迁移备份等工作任务，这些关键环节中，如果出现任何纰漏，都可能导致不可逆的数据资产损失或其他不良后果。由于缺乏细粒度的管控手段，数据库运维工作普遍存在内部人员、甚至第三方外包人员间的账号共享、主机共享、高权限账户滥用等情况，加之人工操作无法保证100%的准确度，数据库日常运维操作面临以下一系列安全风险：

操作身份不明确

操作过程不透明

操作内容不可知

操作行为不可控

操作事故不可溯等

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

图1.数据库安全运维系统的全流程管控模式

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

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

1、运维人员身份鉴别：通过双因素认证机制，解决数据库账户共享、运维主机共享的场景下的运维人员精准身份鉴别及权限划分。认证机制包括：

审批口令码：运维人员提交申请并通过后获得审批码，当运维人员登录数据库后，需提交审批码，方可继续执行获准的运维操作。

动态令牌：运维人员在登录数据库后，通过输入动态令牌显示的数字，校验自身身份，校验通过后，方可执行与自身身份相符的运维操作。

2、涉及数据库的批量操作（批量查询、批量导入导出、批量为客户开通、取消或变更业务等），运维人员必须执行相应的审批流程，由相关主管审批后方可执行。涉及超权限的数据库运维操作，运维人员需要额外提交申请，由相关主管审批后授权操作。

3、涉及业务投诉、统计取数、批量业务操作、批量数据修复等需求进行的客户敏感数据查询、变更等操作前，运维人员必须取得业务管理部门的相关公文，并执行审批流程。执行操作时，对极高敏感度的数据操作，需要保证多人在场、多人协作方式以确保操作安全性。

4、需要对所有审批流程的操作工单整理备案，记录操作原因和工单编号，并由专人负责审核。

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

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

基于人性化设计，考虑审批人的职位不同，需要能够支持技术化或业务化的申请模式，专业的安全运维系统需要支持多种申请提交方式，如：提交完整操作语句、提交“时间+对象+操作”的条件组合，以禁止某些高危操作和敏感表访问的方式进行审批授权，提交指定时间和周期的执行脚本。此外，另一个重要能力是，应当能够提供对申请内容的智能分析能力，能够对操作申请进行风险预估和异常行为评测，为审批者提供决策依据，在操作前最大可能的降低运维事故概率。此外，在审批时应当提供对下一步操作执行过程的校验机制，以确保操作人与操作内容的安全性。目前，使用校验码是最为周全的方法，审批通过后系统随机生成一串口令，在后续的操作中，通过识别口令码进行身份验证，确保操作人的身份安全性。

图2.数据库运维操作的申请方式

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

我们都清楚运维人员的工作强度：他们真的太忙了！不是蹲在机房调试服务器，就是穿梭在各业务部门之间处理系统故障，自然，手头的系统运维操作被突然打断也是常有的事。同时兼顾多个数据库的日常维护工作，运维人员的电脑界面总是铺满了多个工作窗口，这样多交叉、多并行的工作性质，误操作的发生在所难免。曾有运维人员向我们讲述过自己最惊心动魄的运维事故：某天，在例行的数据库表内数据删除操作时，一个走神，语句中where条件后没加“id=”，而是直接键入了某个数字，短短几秒间，几百万条数据被删除，事后的数据恢复工作进行了整晚，依然没有抢救回全部数据，核心数据库文件的丢失导致关键服务完全瘫痪。现在，运维部门同事都不敢在白天进行核心数据库的运维操作，生怕忙中出错。辛苦一整年，一键误操作却功亏一篑。

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

运维人员实际操作是否与申请一致？

实际操作人是谁？

出现误操作，如何追溯？

如何管控来自内部或第三方运维人员有意无意的高危操作？

堡垒机是目前大多数企业的普遍解决方案。而事实上，由于缺乏对数据库通讯协议的精确解析能力，堡垒机只能实现对操作人身份、操作目标库等最基本的身份识别，这其中差了最关键的一环：对操作内容、操作过程的有效管控。因此，对执行过程进行透明化管控是数据库安全运维系统的重要使命。

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

图3.数据库安全运维系统的工作架构

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

以上，针对运维人员的操作行为做出严格的事中控制，实现了对敏感数据操作的权限控制，但是运维人员仍可以看到敏感数据。所以，在此基础上，DBController增加了敏感数据遮蔽功能，可以最大程度从运维侧规避数据泄露风险，数据库安全运维系统通过灵活的配置，实现敏感数据动态屏蔽，让具有不同访问数据库权限的人员看到不同的数据，既不影响正常运维、开发工作，有防止了敏感数据泄露。

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

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

图4.数据库安全运维系统的应用场景

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

生成海报

免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。