最佳实践｜数据泄漏事件频发的背后：企业如何才能保障数据安全？

 

8月14日，一名攻击者在黑客论坛上声称，窃取了美国电信运营商T-Mobile的服务器数据，约1亿用户个人数据，总计106GB数据，其中包括T-Mobile的客户关系管理（CRM）数据库，姓名、电话、出生日期、驾驶执照号码和社会保险号码。8月17日，T-Mobile承认发生数据泄漏事件，据悉，受这次数据泄漏影响的用户超过4000多万。

 

除了T-Mobile外，今年以来美国管道、保险和肉类供应企业等相继遭遇网络攻击事件，且都是针对数据的攻击。根据公开报道，2020年全球数据泄漏的平均损失1145万美元，2019年数据泄漏事件达到7098起来，涉及151亿条数据记录，比2018年增幅284%。

 

由此可见，数据泄漏事件影响大、损失重。

 

众所周知，当前全球已逐渐进入数字化时代，数据已成为企业的核心生产要素，任何数据数据安全事件都是影响重大的。一旦出现数据安全事件，不仅对用户的使用体验和个人隐私带来威胁，且企业也可能面临重大损失及经营风险。数据安全防护已经日渐成为企业关注的重要诉求之一。

 

为帮助广大企业客户有效保护数据安全，阿里云数据库团队推出覆盖事前、事中及事后的全链路数据安全防护方案，并已服务了上万企业客户。

一、细粒度权限

数字经济高速发展的今天，依靠传统的DBA/运维单点响应所有人员对数据库的访问请求已经是极大的瓶颈也不现实了。

 

但是依靠数据库原生的账号权限管控能力，众多数据库类型只支持最细到表级别的授权，如果按照最小权限授予原则，不同人员访问不同数据那么就需要在数据库上建立众多的账号。

 

一旦这样的话，那么势必会遇到人员转岗、离职等情况，权限无法自动、有效的回收（因为账号一旦给出去也有可能被直接用于访问生产服务的代码配置里，若直接回收也有可能就影响了生产服务）；但不回收不更换肯定也是隐藏了数据泄露的风险的，极其容易出现人员离职后大量数据泄露、尤其是敏感数据泄露等问题。

 

那么是不是有好的办法来解决这些问题呢？

 

相比较于传统数据库访问方式在数据库上创建多个账号的方式，阿里云数据管理DMS提倡统一管理入口，仅需要给DMS创建一个专用账号，避免所有人员直接接触数据库账号密码，所有访问都通过产品按需申请、流程审批开通使用。

 

在这里我们支持库、表、字段多种对象粒度，查询、导出、变更多种操作类型进行组合，支持最细小时级别的授权灵活满足各种场景，比如项目协作排查问题只需要开通1个小时，开通1小时的权限则会在到期后自动回收。

 

同时，在使用过程中结合安全规则的配置，对SQL语法、影响行数等各方面都能有效的拦截进而保障数据库的服务安全，关于安全规则咱们会在后面的章节进一步介绍，这里暂时不做展开。

 

通过DMS的细粒度权限管控，同时也能满足安全合规需要定期更换数据库账号密码但不影响任何人员，也不用担心更换有未知风险，无需通知与沟通。

 

二、账号体系

 

到这里大家可能想问是不是只支持云账号登录？答案是否定的，目前企业域账号可以通过阿里云用户SSO/角色SSO来对接使用。

 

同时我们通过OpenAPI能支持员工入职、离职账号安全、自动化管控。

 

在人员入职环节中增加账号的创建与授权，在离职流程前置账号的回收清理，借助于产品规避了人员直接接触数据库账号密码，在人员变动时只需要回收人员的账号即可避免人员离职后再接触任何企业内的数据，同时，运维人员也无需频繁调整数据库账号。

 

下图是我们的一个最佳实践示例，供大家参考。

三、可控SQL请求

删库跑路到今天也不再是句玩笑话，而是真真实实的发生了。那么针对这种删库跑路、数据泄露等恶性事件，除了平时人员的管理之外，我们有没有可能在数据库操作的管控层面做到杜绝呢？

 

答案肯定是可以的，通过DMS有了统一访问入口的权限管控后，企业内所有用户对数据库的请求都从产品内发起，可以经过鉴权、语法校验、访问规则有效的来保障数据安全与数据库服务安全。

 

在数据访问安全上，咱们可以控制每次查询返回行数、每天查询返回行数、每天查询次数等可有效避免暴力拖库现象的发生；

目前在阿里内部我们对生产环境数据库实例一般控制单次查询返回行数上限为200条，测试环境数据库实例一般控制单次查询返回行数上限为500条，每人每天查询总次数上限2000次，每天查询总行数上限20000行。

 

同时，在数据库服务安全上，咱们可以控制每次查询超时时间、每次查询全表扫描大表空间阈值等可有效避免慢查询拖垮数据库的现象发生；

 

一般默认查询超时为60s，也可以根据需要进行适当的调整，比如在双十一大促期间我们会设置查询超时时间为5s，超过5s就自动取消查询避免峰值期间的负载叠加；对大表的全表扫描我们一般设置超过10G就不允许执行计划不走索引的SQL下发了。

 

另外，基于前面介绍的细粒度权限管控，最小权限授予使用的管理原则，企业内不仅可以规避不必要的敏感数据接触，同时对高危操作删库、删表等动作也都能有效拦截。

 

四、敏感数据管理

 

数据的泄露尤其是敏感数据的泄露将直接影响企业业务的发展，针对以往的数据泄露事件分析，常见的除了黑客攻击，更有超过50%以上的数据泄露事件是由于管理不善导致的内鬼所为或数据库信息被公开。

 

用户个人信息、银行卡号、身份证号、地址等敏感数据如何有效识别、有效管理呢？在企业成千上万甚至是上亿的数据字段里，怎么快速有效的识别、定位到敏感信息进行分类管控呢？

 

目前DMS产品内支持通过规则扫描字段命名或者抽样少量数据内容进行分类识别打标，针对打标好的敏感、机密字段有又可以统一设置各种加密算法，在查询时即使已经有了库、表权限，针对此类字段还需要额外申请字段权限才可以使用，否则对应字段会被加密，并且无法作为查询条件进行数据的过滤提取。

 

下面是一个示意截图，当有字段的明文权限时字段跟其他内容一样，如果只有半脱敏权限则会根据加密算法加密显示，如果没有权限则会全部星号显示。

五、灵活、差异化管控

 

在企业里不同业务的差异、甚至同一个业务不同环境的差异在管理策略上可能都是不一样的，传统的方案一般是企业内一刀切，那么势必会造成对有的业务太严格、有的业务又不够灵活，进而影响到研发效率。

 

那么今天通过DMS安全规则，我们可以支持企业内最细到单个数据库实例级别制定不一样的设计规范、研发流程、操作规范与审批流程。

 

比如每个业务新建的表都需要以业务缩写前缀来区分识别，建表的时候A业务必须有自增主键id、以及gmt_create、gmt_modified时间字段表示记录创建与最后更新时间，并且每个字段都需要有注释。B业务建表要求表上必须有created_at、updated_at 表示记录创建与最后更新时间字段。那么就可以通过2个安全规则来实现灵活的支持，哪个业务也不必强套另外一个业务的规范或者往通用规范上靠。

 

这里额外提一下，目前DMS内置了阿里巴巴内部运行的安全规范，同时企业也可以根据不同的业务按需定义符合企业的最佳安全规范，支持通过DSL语言扩展定义；凡是不满足规范定义内的操作，DMS均会拦截。

六、操作全方位审计

 

前面我们已经介绍了细粒度权限、SQL请求、敏感数据、安全规则这几个数据访问安全解决方案，最后我们再来看下作为访问安全最后一环的操作审计。在合规面前，所有行为要有据可循，有据可依。

 

通过DMS产品内的每一个操作我们都会详细记录，管理员、安全管理员进行随时通过页面或者OpeAPI获取进行分析、合规审计与问题排查，这个记录在企业上市合规审计、IT内审等环节中都有重大帮助作用。

 

下面这个是我们当前页面的一个截图供大家参考。

文章转自公众号：阿里云数据库