云技术是IT产业界的一场技术变革。云给市场带来一种更加便宜、更加高效、更加灵活的IT解决方案。云的解决方案已经被越来越多的用户所认可和采纳。我国政府明确提出云技术是我国未来信息化产业发展的重点领域。

在我国云技术依旧处于成长期阶段。据统计 2017年中国云计算机市场规模已经达到2602亿美元，增长率为18.5%，预计到2020年公有云规模将达到4114亿美元。随着云业务相关技术的成熟。安全成为云下一阶段主要面临的挑战。

现今成熟的云平台已经基本解决用户身份、凭证、系统漏洞、拒绝服务等多类安全问题。但在数据泄露上还有很多不足。除去内鬼造成数据泄露外，最常见的是由于数据读取权限设置细粒度不足导致。RDS做为云上数据主要存储场景，如何做细粒度控制，将成为各个云厂商面临的重要挑战。对于行存数据库，行控是最关键的细粒度控制。加强RDS的行控能力，是杜绝数据泄露的有效手段。  

行控-RDS安全缺失

RDS是云上数据库的简称。大部分中小企业用户的核心数据会存储在RDS中。RDS大部分是MySQL数据库。我们走访了大量云厂商，简化掉复杂的云机制，大部分云厂商租给中小企业的RDS其实是以数据库实例为单位出租的。在一台实体物理机上有多个虚拟机，每台虚拟机上有多个进程。每个进程对应一个mysqld。每个mysqld都对应不同的端口和数据库配置文件。每一个启动的Mysqld都对应一个实例。用户租用的RDS就是一个数据库实例。每个用户通过云平台访问到自己被分配的数据库实例中。

这种以实例为单位切割RDS和用户的方式，依赖数据库自身的特点。有效规避了，因为用户误操作导致数据库崩溃，而影响到另一用户使用数据库的问题。同时由于从实例层就分割，可以有效的保障不同用户的数据存储的逻辑位置是相互分离，避免了恶意读取或修改他人数据的问题。

早先云上业务模型较为简单，随着业务的复杂度上升。只依赖数据库自身的权限切割，难以满足用户对数据库中数据的细粒度控制需求。很多现场需求中，客户要求同一张表中区分出保密数据、敏感数据和公开数据。不同的用户访问表，只能访问到当前用户有权限访问的数据。例如下图表中红色框对应的是保密数据、蓝色对应的是敏感数据、黑色对应的是公开数据。数据库账号分为三种:第一种是可以访问保密数据、敏感数据和公开数据的tom账号、第二种是只能访问敏感数据和公开数据的 cat账号。第三种是只能访问公开数据的dog账号。

RDS上数据库账号的权限控制只能到表级，而现实中省级数据中心从各个地方采集到的数据不会因为安全级别不同，而汇总到不同的表中。所以RDS现在的权控体系和客户的安全需求产生了一定的差距。如果能让RDS从表变成行控，则会解决此类安全需求。

一.  RDS行控-视图法

RDS数据库最简单实现行控的方法是采用视图+触发器的方法来，限制用户访问全部表。整体思路是假设有表A是用来记录数据的。我们给表A重名成表B。在创建视图A。利用数据库语法不区分视图和表的特性。使原来对表A（改名成表B）的操作迁移到视图A上进行。而视图A，在读取表B的时候，完成了对表B内容的过滤。防止保密数据被用户读取。

上述虽然解决了读的问题，但同是也引起了写的问题。于是引入触发器C当写视图A的时候，再通过触发器C。把写视图A的操作变成写表B。具体流程如下图所示：

红色部分是准备阶段。准备阶段首先会把表A重名成表B。接着会根据表B建立视图A。最后会部署触发器C解决针对视图A的写，转移到表B上。

绿色部分是读过程，当用户读取数据时，首先会访问视图A。视图A中有过滤的对象，保证从B中读取的数据已经剔除保密数据。最后返回给用户使用。

紫色部分是写过程，当用户写入数据时，首先会向视图A写。视图A会利用触发器C把写操作转移给表B。最终表B被写入数据。

利用视图+触发器可以解决一部分RDS行控的需求。实际上这种方案，虽然可以做到应用透明，但只适合保密数据特征明显、分类清晰。数据安全层级不复杂的场景。数据安全层级复杂会导致整个设计思路过度复杂，性能等问题也会暴露，在某些场景下这种方案完全不能使用。

二.  RDS行控-改SQL法

除了上述这种完全依赖数据库自身机制实现RDS行控的方案外。还有些使用了改SQL的方式。在向数据库发包的过程中，通过一个过滤组件，对SQL语句进行改写。也可以达到过滤保密数据的目的。

如上图所示当用户访问表A时，经过一个客户配过策略的过滤器。过滤器会把SQL语句select * from A 改写成 Select * from A where部门 ！=财务部 。保证财务部（保密数据）不会被非授权用户查询到。从而达到RDS行控的目的。

这种方法本质是在数据之外，添加额外的控制产品达到增强数据库权控的目的。这种方法比视图法更加灵活、复杂度低、不会造成数据异常。部署起来也更加简单。但根据策略修改SQL的性能和准确性，在某些复杂场景下可能会存在一些问题。

三.  RDS行控-过滤法

这种针对结果集的过滤方案是现在云上最常用的方法。用户在访问数据库目标表后，通过一个结果集过滤器，按照用户的需求对保密数据进行删除，最终显示公开数据。

这种方案好处是，在应用侧部署对数据库影响小。可以做成支持多种数据库的通用方案。但问题是这种方案是把数据库的行控制转移到应用去做，这个过程中就可能已经出现数据泄露。而且由于过滤的方法基本是关键字算hash的方法。这种方法天生存在被hash碰撞的安全风险。把数据库的行控能力迁移到应用中做是一种工程的手段，并不会加强RDS的安全性，甚至还给数据泄露留下伏笔。并且效率也是需要着重考虑的问题。

四.  RDS行控-安全标签法

安全标签法主要是在RDS上做的一种安全增强功能。这种方案是通过在目标表中添加伪列实现的。给表中的每一行添加伪列，伪列标明这一行的安全等级。给数据库账号添加可以访问的安全等级的标签。只有账号拥有足够安全等级的标签才可以访问到相关的数据。

表会在用户设完策略后新加伪列这一列，如上图的第三列，伪列专门标记出每一行的安全等级。安全标签法可以让用户灵活的自定义安全等级。做出更适合实际应用场景的安全级别。安全标签策略应该处在数据库语法解析中。首先判断数据库账号和表以及操作之间的权限关系。如果通过权限检查，就应该通过安全标签部分，识别真正能读取的数据范围。然后生成执行计划。最后执行sql，拿到结果，完成整个查询过程。查询的内容符合查询用户所支持的安全等级。

上述四种方法：视图法、改SQL法、过滤法和安全标签法都在一定程度上可以实现RDS的行控需求。这四种方法使用的场景各不相同。但总体来说视图法设置较为复杂、灵活性低是四种方法中适用面最窄的实现RDS行控的方案。其次改SQL法虽然灵活性比视图法强，但容易被存储过程等其他SQL执行方式绕过，也难以成为适应性高的RDS行控解决方案。过滤法是现在使用最广泛的RDS行控解决方案。这种方式虽然在一定程度上解决了视图法和改SQL法存在的问题。但由于权控被前移到应用侧，数据库还是会返回敏感数据。依旧存在较大的安全风险。但这种方案只能认为是RDS行控的工程解决方案。并不是一种彻底的解决方案。相比前三种方案安全标签法是最佳的RDS行控增强方案。这个方案有广阔的适用空间，同时真正把权控做在数据库中。避免了数据库到应用传递过程中出现的数据泄露问题。