齐治数据库访问控制系统DSG如何从源头防止删库跑路
发布日期：2023-02-13 作者： 来源： 分享：
C公司外包员工小王，通过堡垒机中的Navicat访问ERP系统数据库，进行一般性的数据操作之后，最后删除表A的某行错误数据时，因为疏忽，执行了删除整表的操作！这一误操作对C公司业务产生了严重的负面影响。小王被外包公司开除了。但是，C公司数据库管理员也没能撇清责任，相关人员被降职降薪，并通报批评。如何从源头防止类似事件发生，成为C公司管理层迫切需要解决的问题。数据已成为越来越多企业的核心资产，删库事件的频繁发生也让企业越来越重视数据安全，想要预防风险，建立完善的权限管理体系。
数据库现状及风险
出于对内部风险管理的要求，以及对外满足政策合规的需求，十几年来，齐治的堡垒机客户一直希望齐治能够从源头解决数据安全问题。但无论怎么努力，堡垒机始终无法100%识别“小王”的“表A”“删除”操作，但是在努力的过程中，我们发现了根本原因：堡垒机是“系统”层的门禁，无法100%精确识别其中夹带的“数据库”层行为。要精确控制删库操作，必须100%识别“小王”的身份，100%识别“删除”的操作，100%识别“表A”的数据，建立“数据库”层门禁，这才是堡垒机客户一直想要的。齐治推出数据库访问控制系统DSG，作为传统堡垒机的一个延续，真正意义上实现了用户与数据库的“操作”隔离：用户的操作先提交给DSG，DSG进行SQL语义解析与安全检查后，再连接真实的数据库进行安全的操作，从源头上防止删库跑路事件。DSG的核心思路在于：控制人的数据库操作行为。与传统数据安全产品（数据库防火墙、数据库防水坝）相比，DSG的最大差别在于DSG是管人的操作行为——什么人？在什么时候？操作了什么指令？而传统数据安全产品看不到人的信息，管控停留在指令层面，而不是行为层面。举例来说：用户要管控外包的数据导出行为。数据导出的行为是怎么发生的？是通过客户端采用SQL指令去把数据查询出来，实际上底层是select指令。导出行为对于数据库防火墙来说只能看到SQL指令，它根本不知道这个指令上面是一个导出的行为，如果把指令全部阻断，那些正常的数据查询操作就没法放过，这两者之间是有明显区别的，DSG则是控制数据库操作的行为。而网络流量解决方案也因为不能区分人员和应用访问，存在追溯难、误控率高的问题。DSG从身份认证、权限管控、数据库操作、数据保护（动态脱敏和数据导出控制）、操作审计等多个维度控制人的数据库操作行为。多维度的管控优于较少维度的管控，决定了DSG的管控能力远大于传统数据安全产品。传统解决方案由于在认证、授权、访问控制、审计存在局限性，导致权限颗粒度过粗或过细、误控率高、效率低、难追溯等诸多问题。
再回到文章开头的场景：外包员工小王，通过堡垒机单点登录到DSG，在DSG中通过Navicat客户端访问ERP数据库，进行一般性的数据操作之后，最后删除表A的某行错误数据时，因为疏忽，执行了删除整表的操作！此时，DSG精确识别到小王删除表A数据的操作为高危行为，阻断了Navicat的操作，并提示小王通过DSG Web客户端进行双人复核数据删除，小王也马上意识到刚才操作的危险性；小王切换到Web客户端进行删除操作，并及时纠正删整表的SQL指令，经过复核员确认之后，安全地删除了某行数据，防止了删库事件的发生。误删数据以及恶性删库跑路事件的发生，员工只是其中因素之一，我们需要合适的技术方案，加上合理的管理机制，才能从源头防止删库事件的发生。
