在Azure SQL数据库中引入行级安全性

微软发布了一个Azure SQL数据库的预览版新特性，它称为行级安全性(RLS)。因为这个特性还是预览版，因此它还不适合用于生产负载，并且还没有得到全面支持。RLS可以根据用户执行一个查询的特征(如：分组成员或执行环境)来控制数据库表中行的访问。

在2015年4月，所有地区的V12部署都可以使用RLS。此外，这个特性也会出现在下一个本地版SQL Server中，即SQL Server 2016。由于微软已经全力投身于云优先的战略中，因此RLS等Azure特性出现在未来版本的SQL Server也在情理之中。

Oracle和DB2的DBMS产品在很多年前就有这个特性了。SQL Server用户一直在使用各种方法来处理行级安全性的需求。如果要将一个使用了RLS的应用程序后台从Oracle或DB2数据库迁移到SQL Server，则需要在迁移过程中在应用程序或数据库上增加很多代码。新的RLS特性仍然需要一定的实现工作，但是工作量已经减少了，因为过滤功能已经根据一个集中定义的安全功能逻辑而自动部署到基本表上了。

我们仍然需要一种方法将特定行的安全性“映射”到一个用户特征值上。它可能是一个具体的用户名或用户的数据库角色成员。目标数据库中每一个表都需要增加一个字段，或者让安全函数联合一个或多个帮助表，从而查找行的分配。安全逻辑可简单可复杂，具体取决于实际的需求。此外，如果一个有RLS的表联合了一个没有RLS的表，那么其结果集仍然会根据安全上下文进行过滤。

行级安全性的优点

粗略地看，它的主要优点似乎是增加安全性和可能简化查询。但是，简化查询可能是考虑使用RLS的主要原因。在启动RLS之后，系统会在更细粒度级别上限制用户的访问。如果用户身份信息受到攻击，那么可攻击范围将缩小，SQL注入攻击的影响也很小。例如，一个应用程序可能现在使用了下面的语句：

现在很容易通过一个SQL注入攻击将“A”改为“B”或其他的查询条件，从而直接查询数据库，得到其他不同的结果。在启动RLS之后，这种攻击是不可能生效的。

使用等级安全性

最终用户不会意识到RLS的存在。实现RLS需要一定的工作，但是完全不需要修改代码。事实上，它可以让查询变得更简单，因为用户已经限制为只能查询他们有访问权限的特定行数。要考虑在现有应用程序中实现RLS。

按照预期，要实现这一层安全性还需要完成一定的工作。这其中包括确定哪一些表需要修改，以及如何更高效地将用户身份映射到行级数据上。但是，这还不是全部开销;RLS的本质是在基础表的每一个查询上增加另一层判断逻辑，限制查询所返回的行数。这可能会影响访问该表的所有查询的性能。

许多全新特性都一样，它们通常也会有很多局限性。这个特性也不例外。RLS不兼容针对内存优化的表和变更数据捕捉。此外，如果不用RLS保护，Full Text Indices(全文索引)和DBCC SHOW_STATISTICS也可能“泄漏”信息。

RLS是一个等待已久的特性，它使微软数据平台产品在功能全面角度向Oracle和DB2靠近。在更多地了解特性及其在应用程序的实现方式之后，它的工作方式将变得更加清晰。表面上，RLS似乎只是一个在将应用程序从Oracle或DB2迁移过来时才需要的特性。但是，在现代环境中数据威胁是真实存在的，RLS有利于减小数据的潜在漏洞。它在用户感知不到的情况下限制返回的记录行数。虽然使用视图和触发器也能实现行级安全性，但是由于访问逻辑更加集中和靠近数据，因此这个新特性减小了应用程序的维护难度和复杂性，从而在实现上更加简单。