删库背后，是权限管控的缺失

“删库”事件过去了，微盟原计划28号恢复商家服务，这事儿就算渐渐淡出了人们的视野，如今又好巧不巧被创始人的魔幻舆论推得一浪更比一浪高。

观众吃瓜一时爽，企业也纷纷顺着热点蹭上来，踩着别人的错误往上爬，还能花样踢腿加劈叉。整个安全圈一片喜气洋洋。

实际上大家彼此心知肚明，这次事件只需要最简单的双人复核就能避免，多一次打扰，少亏12亿。那么为什么最初级的操作也做不到呢?

一、原因分析篇

有人指出这次“删库”原因是微盟没有使用堡垒机，仅仅如此吗?

爱因斯坦说，问题往往不会在它发生的那个层面得到解决。

现在很多互联网公司对自己的技术非常有信心，为了节省成本，会选择基于开源软件自主研发安全产品。但在设计产品和管理产品的过程中，难免缺乏专业经验。

专业的人做专业的事。脱离钱去谈安全，就有可能丢了**还套不着狼。

“删库”这么狗血的事情已经在历史上重演很多次了，有蓄意破坏的，也有失手误删的，归根结底，都是人的因素。当你大门敞开，这库就迟早要删，即便现在没有动机，也不能保证没有手误的可能。

人永远存在犯错的可能性，而安全又是一个神奇的四两拨千斤的问题，任何一点小错误都有发展成大规模破坏的潜力。因此运维安全的第一步，就是对“人”的权限管控。

构建成熟的权限管控体系，才能最小化排除人的不稳定因素。

二、整体方案篇

数据中心内的运维安全体系分为身份验证，授权，访问控制，审计和主机防护5个方面，而其中的授权+访问控制实现权限管控。从字面意义上理解：授权就是授予相应的人相应的权限(人+账号+资产)，访问控制就是在人在获得权限之后允许做哪些事情不允许做哪些事情(时间+地点+操作)。二者本质上是一个授予和执行的关系。

1. 授权-修桥铺路

在数据中心内，根据业务场景的不同有三种授权通道：工单申请、动态授权、静态授权。

(1) 工单授权

操作人员根据每天需要处理的事务向部门领导提交工单申请，包括：服务器IP、账号、运维事项、时间范围等，领导审批后操作人员才可在堡垒机中查看到申请的访问权限。

• 优点：按需供给，通过流程严格控制访问权限。
• 缺点：需要紧急处理事务时，流程审批耗时会耽误处理时机。

(2) 静态授权

对于人员固定，访问目标固定且低风险的访问权限可以使用静态授权，如：张三每周一至周五早上9点到10点之间都需要对备份机做巡检，巡检用到的账号是一个只读的低权账号。

在执行授权的过程中，通常会伴随常规策略设置，定义基础权限，主要包括人、账号、资产，偶尔也会涉及到事件、地点、操作等策略配置。

• 优点：权限管控粒度细
• 缺点：配置过程相对复杂且难调整

(3) 动态授权

相对于静态授权的条目多，配置复杂，动态授权提供了一种按属性，按标签的更便捷的配置方式。例如：按用户部门(系统，数据库，网络)，角色(管理员，值班员)，设备类型(主机，数据库，中间件)，业务系统(网银，手机银行)等，根据标记自动生成访问权限，实现动态授权。

• 优点：配置灵活，组合条件多
• 缺点：权限查看和搜索比较麻烦

2. 访问控制-分道限速

授权阶段足以满足登陆访问的基础需求了，然而不足以将“人”的风险降至最低。访问控制则是对“人的行为”进行风险控制的强力补充。

通过时间策略、源地址策略、操作规则的进一步设置，连同人、账号、资产的基础权限，形成六维细粒度权限管控体系，实现权限最小化管理。

• 时间条件：按时间维度缩小权限范围，比如：2020年1月1日9:00 -10：00，每周一至周五00:00-02:00
• 源地址条件：按IP地址为度缩小权限范围，比如：只允许在192.168.1.10-20地址范围访问
• 操作条件：按指令，剪贴板上下行，磁盘映射，文件传输上下行等缩小权限范围，比如：不允许支持rm -rf *，只允许文件上传不允许下载
• 控制动作：当触发以上规则时系统执行相应的动作，比如：不阻断但发邮件报警，阻断并发syslog，等待管理员审批等。

目前常见的几种权限管控包括：ACL(基于黑白名单)【1】、RBAC(基于角色)【2】、ABAC(基于属性)【3】，在不同的业务场景下，适配不同的技术手段。

三、结语

不得不承认，权限管控是一件干起来十分吃力又不讨好的事情，安全本身看不见效果。即便是比较好的自动化平台，至少也需要人来审批。从前期准备到后期运用，很容易形成成本升高、效率却降低的局面。

的确，树上的果子摘下来就能吃，何必要洗一遍呢?

但最近这个世界在告诫我们，你不知道那个果子有没有被果蝠碰过。

愿大家身体健康，也愿行业更健康。

Reference：

• 【1】ACL(Access Control List)访问控制表，基于白名单和黑名单提供决策依据，其中，白名单用于允许，黑名单用于拒绝。通过访问控制模块，对数据进行匹配，命中则执行设定的动作。比较常见的场景：传统防火墙策略。
• 【2】RBAC(Role-BasedAccess Control)基于角色的访问控制，常见于软件管理系统的用户分权。与ACL中一一对应的授权执行关系不同，RBAC引入了角色(role)，与操作权限和资源权限相关联，适合在操作权限和资源权限控制简单，且相对固化，但人员变更频繁的场景下使用。比较常见的场景：数据库的用户角色(role)管理。
• 【3】ABAC(Attribute-BasedAccess Control)基于属性的访问控制，常见于分布式业务场景的用户分权。ABAC是一种贴近自然语言的权限控制模型，抽取异构场景的共性属性，用属性的自然组合来解决权限控制问题。针对复杂、分布式、动态、细粒度的权限管控要求，ABAC拥有难以取代的优势。