“数据门”事件频发 如何避免人为因素导致数据泄露？

前段时间，某酒店集团数据泄露引起轩然大波，泄露的数据中包含了用户姓名、手机号、邮箱、身份证号等多项信息。卖家对这个约5亿条数据打包出售价格为8比特币或520门罗币。

而关于此次信息泄露事件的原因，目前尚未定论。据悉，由于集团某程序员将服务器及数据库信息泄露到了Github，导致被黑客利用，通过弱密码攻击攻陷了酒店服务器和数据库体系。不过这一说法目前只是推断。

内部管控不严泄密加上黑客攻击成为了这场数据泄露事件的主要原因。

外部攻击我们尚可加防，内部运维我们应该如何自防呢？在日常的数据库使用过程当中，运维人员在数据分析、线上问题排查、临时修正数据等多个环节均可直接接接触数据库中的数据，也就是说这些环节都有可能出现问题。

传统数据库安全管控方案漏洞频出

传统的人为数据安全管控方案有两种，集权管理和分权管理。使用集权管理方案需要在业务代码使用账号之外，创建独立的读写账号、只读账号，只给与DBA、运维等特定的人员，但是这种方案的弊端在于，对于有些需要快速响应查看数据进行决策的场景，繁琐的步骤将直接影响研发效率。

在日常数据库使用过程中，应用代码的在线服务访问是最主要的一种方式，但人员基于数据分析、线上问题排查、新需求变更结构、临时修正数据等各种诉求也需要直接接触数据库。

如果采用分权管理，创建独立的读写账号、只读账号，分发到一线负责人，相较于集权管理，效率有一定的提升，但是接触数据库账号密码人员较多，人员变动时需要及时变更账号密码信息确保安全。

这两种方案不仅本身存在弊端，且在大批量管理时，实施难度也将成指数级放大。如此一来，企业还能如何避免人为因素导致的数据泄露事件发生呢？

阿里云数据管理DMS企业版针对此问题，提供了从访问源头开始防护的完善、成熟的数据安全访问解决方案。

DMS企业版高效保障数据安全，提升研发效率

与传统的数据访问方案相比，DMS企业版消除了人员瓶颈，在保障数据安全的前提下也兼顾了企业的研发效率。DMS企业版主要从访问和变更两个方面进行安全管控。

在访问方式上，区别于传统方案，无需直连数据库，只需提前录入需要管理的数据库实例、接触数据库的人员，当需要访问数据库、表的时候，可直接在产品内按需申请或由数据owner主动授权，具备权限后登录DMS企业版即可直接访问数据库，不再接触任何数据库的账号密码。

在访问权限粒度上也设定了相应的规范，若无对应权限则不可大量数据导出、不可提交数据变更（DML、DDL等）操作，避免了数据被大量泄漏。同时，DMS企业版支持了特有的字段级别权限管控，方便企业在身份证、银行卡、密码等敏感信息上进行精细化的管理。

DMS企业版对于保障访问性能安全也做了特别的处理，比如数据库级别阀值禁止全表扫描管控，当表空间大于一定值执行计划不走索引则禁止发起查询；用户级别单天查询行数、次数上限管控；产品内单次查询返回行数上限管控等，全方位保障访问安全。

变更安全管控主要加入了实例级别变更流程管控、任务调度负载管控以及数据变更update、delete默认备份前镜像，如果遇到异常情况可快速恢复，并且避免了元数据锁争用阻塞数据库、避免thread_running过高时调度加重负载。

除此以外，DMS企业版还提供了云账号准入、企业人员准入、企业内网准入三层登录安全保障；在开启内网准入（访问IP白名单）管控后，即使企业内人员变更流失账号未及时回收，但由于人员已不能再登录企业内网环境这无疑又是一道安全保障。

值得注意的事，在人员账号都精细化按需使用后，账号无共用，产品内人员的每一个操作都将可被溯源。公司内（尤其是上市公司）固定周期的操作审计将是重要的数据支撑来源。

数据安全任重道远

数据安全任重道远，企业内数据作为一个企业的核心资产、赖以生存的命脉，数据安全是重中之重；也是最值得持续投入改进、不断加强的一个方向。DMS企业版将不断努力，助力企业完善数据安全管理。

最后附上【数据安全管理小建议】

1）禁止弱密码的存在，即使生产服务使用的数据库账号密码如有可能建议定期更换

2）禁止敏感信息的大量接触，敏感信息严格限制可接触人员

3）禁止公开企业内数据库访问方式、服务器IP等敏感信息

4）设置数据库服务器的可访问IP白名单，来源管控

5）设置数据库账号的可访问IP白名单，来源管控

更多详情可移步：企业数据库DevOps解决方案

作者：云攻略小攻