SQL Server安全（6/11）：执行上下文与代码签名（Execution Context and Code Signing）

在保密你的服务器和数据，防备当前复杂的攻击，SQL Server有你需要的一切。但在你能有效使用这些安全功能前，你需要理解你面对的威胁和一些基本的安全概念。这篇文章提供了基础，因此你可以对SQL Server里的安全功能充分利用，不用在面对特定威胁，不能保护你数据的功能上浪费时间。

---

SQL Server决定主体是否有需要的许可执行代码的基本方式是它的执行上下文角色。这都是复杂的可能性，主体有执行代码的许可，但没有代码访问的潜在对象的许可，例如表里的数据。这篇文章会探寻SQL Server执行上下文，所有权链接接，模拟，还有向你展示下如果通过T-SQL代码控制数据访问。

执行上下文

当用户执行一个存储过程或其它数据库代码时，SQL Server检查确保，不仅用户有运行存储过程的许可，而且有代码访问使用数据库对象的许可。没有这类许可检查，有些人会很容易创建可以读取表，使用执行代码访问不需要其它的对象代码。这会是重大的安全漏洞。

这个许可检查过程不发生的唯一例外是代码的所有者也是代码访问的所有潜在对象的所有者。在这个共同所有权下，SQL Server验证调用者在代码上有EXECUTE许可，不会继续检查许可。

例如，如果在存储过程中的嗲吗访问三个表和四个视图，SQL Server在执行代码前进行这些概念上的步骤：

1. 在代码上验证调用者有EXECTUTE许可。如果调用者没有，返回一个错误并不再继续。
2. 检查代码的所有者是否也有代码访问对象的许可。如果共同所有权（common ownership）存在的话，停止检查并执行代码。
3. 如果共同所有权（common ownership）不存在的话，检查确保调用者代码访问的对象上有许可。如果调用者在一个或多个对象上没有许可，返回一个错误且不执行代码。
4. 如果调用者有所有需要的许可，执行代码。否则，返回错误且不执行代码。

在代码调用其它带按摩或访问其它对象的地方，共同所有权继续检查，即轮流调用其它代码或访问其它对象。只要链里的所有对象有同样的所有者，许可检查就不需要。但只要链里的一个对象比要访问它的对象多出不同的所有者，在那个对象上的许可就检查了。

在这钟情形里的对象所有权被称为所有权链接接（ownership chain），因为你不需要担心代码执行的安全上下文。这也是SQL Server的早期版本有拥有所有对象的特定dbo角色的直接原因。但任何时候你有共同所有权和许可来访问一切，你就违法了最小特权许可，暴露你的数据在不需要的安全危机里。

幸运的是，在SQL Server里你可以修改代码的安全执行上下文。

提示：

这篇文章会探寻执行在存储过程上的执行上下文和代码签名，但它们同样对大多数用户自定义函数也支持。

修改执行上下文

一般你不想调用者的许可用来在破坏的所有权链接接里验证许可。有时你想代码好像完全被另一个用户执行一样，通过另一个用户的许可在访问的所有的对象上验证许可。这称为切换代码的执行上下文。这让你使用SQL Server颗粒度许可的优点，对潜在的对象保持完全的许可控制，但还是给不同用户执行代码的能力。

在SQL Server里，当你定义任何类型的用户自定义函数（行内表值函数除外），存储过程和触发器，你可以使用EXECUTE AS子句作为对象定义的一部分，表示这个代码应该在指定用户的安全上下文下运行。

EXECUTE AS有4个可用选项：

• EXECUTE AS CALLER:默认用户向下兼容。代码在调用者的上下文里执行，调用者必须同时有执行代码和访问潜在对象的许可。实际的操作取决于所有权链接接上是否损坏或完好。
• EXECUTE AS = ‘username’ and EXECUTE AS = ‘loginname’:代码在指定用户或登录的上下文里运行，因此指定的用户或登录必须在所有的潜在对象上有许可。在这个情况下，调用者必须满足下列之一：
  • 在代码上有EXECUTE许可
  • 是sysadmin或db_owner，或者在服务器或数据库上有CONTROL SERVER许可，或者对于用户有模仿（impersonate）许可。

使用用户名的EXECUTE AS只能应用于服务器范围的DDL触发器，且要登录到触发器。否则，提供的用户名必须是有效的数据库用户名称。

• EXECUTE AS SELF:这是创建存储过程的当前用户的缩写。和EXECUTE = [myUserName]等效。SQL Server目录村里写代码的实际用户ID。
• EXECUTE AS OWNER:这是在指定用户的安全上下文运行的另一个变体，在这个情况下，代码所有者在代码执行时间，而不是在创建时间。如果在数据库里，拥有者在代码创建后修改了，这表示代码会在和首次创建代码的不同用户的许可执行。

当你在SSMS里运行代码时，在会话的执行上下文里，有两种EXECUTE AS的变体可以作为语句使用。它们是EXECUTE AS LOGIN = ‘loginname’ 和EXECUTE AS USER = ‘username’。当用户登录到SQL Server实例时，会话开始，那个时候的执行上下文设置为登录的用户，用作许可检查。EXECUTE AS 修改会话期间执行上下文，直到用户执行了REVERT语句。

通过EXECUTE AS修改安全上下文的任何时间，代码创建者或会话用户在语句里指定的用户必须有模仿（impersonate）许可。你永远不需要模拟自己的许可，例如EXECUTE AS SELF。

使用EXECUTE AS子句

在数据库里，假设你有Vendor表。表在SchemaUserTable架构里定义，属于UserTable用户。代码6.1定义了范文这个表的存储过程。在SchemaUserProc定义的存储过程，属于UserProc用户。因为表和存储过程在属于不同用户的不同架构里定义，存在断开的所有权链接接。

 USE ExecuteContextDB;
 GO
 CREATE PROC SchemaUserProc.VendorAccessProc @state CHAR(2)
 AS
     SELECT * FROM SchemaUserTable.Vendor WHERE state = @state;
 GO

代码6.1：创建在一个在一个架构里访问不同架构里的表的存储过程，这里架构有不同的拥有者。

提示：

下面的代码会创建登录、数据库、用户和这个部分使用的架构，同样也会在Vendor表里插入一些记录。先运行下列带代码再运行代码6.1。

 -- Create the logins and database for this demo
 USE master;
 GO

 IF SUSER_SID('UserProc') IS NOT NULL DROP LOGIN UserProc;
 IF SUSER_SID('UserTable') IS NOT NULL DROP LOGIN UserTable;
 IF SUSER_SID('RealUser') IS NOT NULL DROP LOGIN RealUser;
 GO
 CREATE LOGIN UserProc WITH password = 'Y&2!@37z#F!l1zB';
 CREATE LOGIN UserTable WITH password = 'Y&2!@37z#F!l1zB';
 CREATE LOGIN RealUser WITH password = 'Y&2!@37z#F!l1zB';
 GO

 IF DB_ID('ExecuteContextDB') IS NOT NULL DROP DATABASE ExecuteContextDB;
 CREATE DATABASE ExecuteContextDB;
 GO
 USE ExecuteContextDB;
 GO

 -- Create the users
 CREATE USER UserProc;
 CREATE USER UserTable;
 CREATE USER RealUser;
 GO

 -- Create the schemas
 CREATE SCHEMA SchemaUserProc AUTHORIZATION UserProc;
 GO
 CREATE SCHEMA SchemaUserTable AUTHORIZATION UserTable;
 GO

 -- Create a table and a proc in different schemas to ensure that
 -- there is no ownerhship chaining.
 CREATE TABLE SchemaUserTable.Vendor
     (ID INT, name VARCHAR(50), state CHAR(2), phno CHAR(12));
 GO
 SET NOCOUNT ON
 GO
 INSERT INTO SchemaUserTable.Vendor VALUES (1,'Vendor1','AK','123-345-1232');
 INSERT INTO SchemaUserTable.Vendor VALUES (2,'Vendor2','WA','454-765-3233');
 INSERT INTO SchemaUserTable.Vendor VALUES (3,'Vendor3','OR','345-776-3433');
 INSERT INTO SchemaUserTable.Vendor VALUES (4,'Vendor4','AK','232-454-5654');
 INSERT INTO SchemaUserTable.Vendor VALUES (5,'Vendor5','OR','454-545-5654');
 INSERT INTO SchemaUserTable.Vendor VALUES (6,'Vendor6','HI','232-655-1232');
 INSERT INTO SchemaUserTable.Vendor VALUES (7,'Vendor7','HI','453-454-1232');
 INSERT INTO SchemaUserTable.Vendor VALUES (8,'Vendor8','WA','555-654-1232');
 INSERT INTO SchemaUserTable.Vendor VALUES (9,'Vendor9','AK','555-345-1232');
 GO

代码6.2在存储过程上授予EXECUTE许可给真正的用户，RealUser，它会运行代码。

 -- Grant permissions on the stored procedure
 GRANT EXECUTE ON SchemaUserProc.VendorAccessProc TO RealUser;
 GO

代码6.2：在新的存储过程上授予EXECUTE许可。

在SSMS里，你可以运行EXECUTE AS作为临时修改安全上下文的在查询窗体里运行的代码语句。使用代码6.3修改安全上下文为RealUser来运行存储过程获得在位于阿拉斯加的供应商列表。

 EXECUTE AS user = 'RealUser';
 EXEC SchemaUserProc.VendorAccessProc 'AK';

代码6.3：修改执行上下文，以RealUser运行存储过程。

执行这个代码引起了下列错误：

在对象Vendor上，SELECT许可被拒绝，数据库 'ExecuteContextDB'，架构 'SchemaUserTable'。

问题是所有权链接接断开了——存储过程的所有者和表的所有者不同——RealUser在Vendor表上没有SELECT许可。这里有SQL Server如何从概念上分析情况：

• 调用者是RealUser，它有EXECUTE许可。通过！
• 存储过程的所有者是UserProc。表的所有者是UserTable。这表示有断开的所有权链接接，因此检查调用者RealUser，在代码里有进行操作的许可。
• RealUser在Vendor表上没有SELECT许可，抛出错误。失败！

你可以在存储过程定义里使用EXECUTE AS子句来修正问题，假设你是存储过程的创建者，在这个情况里想允许RealUser运行代码。首先，使用代码6.1显示的REVERT语句来撤销安全上下文的RealUser切换，返回你自己的安全上下文：

 REVERT;

代码6.4:恢复用户运行SSMS的原始安全上下文

接下来，修改存储过程来包含EXECUTE AS子句使用UserTable的安全上下文来运行存储过程，它在表上拥有SELECT许可，如代码6.5所示。

 ALTER PROC SchemaUserProc.VendorAccessProc @state CHAR(2)
 WITH EXECUTE AS 'UserTable'
 AS
     SELECT * FROM SchemaUserTable.Vendor WHERE state = @state;
 GO

代码6.5：修改存储过程，在运行时间使用EXECUTE AS修改运行上下文

提示：

在这个例子里，UserTable通过成员资格拥有在Vendor表上的SELECT许可。但成员资格没有必要用来执行上下文切换工作。例如，可以通过表拥有者授予用户EXECUTE AS user许可。

然后修改安全上下文为UserTable，再次尝试运行存储过程，使用代码6.6。

 EXECUTE AS user = 'RealUser';
 EXEC SchemaUserProc.VendorAccessProc 'AK';
 REVERT;

代码6.6：测试修改后的存储过程来看看RealUser现在能否执行代码。

这次调用成功，因为当SQL Server在所有权链接接检查许可时——还是断开的——它发现UserTable有需要的SELECT许可。结果如插图6.1所示。

插图6.1：在不同的用户安全上下文下运行存储过程的结果

代码签名

使用EXECUTE AS子句修改T-SQL代码段的安全上下文只是解决断开所有权链接接问题的一种方法。另一个方法是使用证书或非对称匙的签名代码。这个技术授予代码本身许可，不需要你修改运行上下文或取决于调用者的许可。而且通过证书的使用或非对称匙的严格控制，你还是可以控制哪个主体能利用运行代码的许可。

这个方式的方法是你创建一个安全，加密的证书或非对称匙，然后创建与证书或匙关联的用户。这是特别的用户类型，不关联登录。你分配需要的许可来运行到用户的存储过程，然后使用ADD SIGNATURE语句分配证书或匙到存储过程。存储过程使用证书或匙关联的用户许可。

即使存储过程使用EXECUTE AS语句修改执行上下文，你还是可以使用这个技术。代码签名的常见情形是，修改执行上下文到代码需要执行的最多许可的运行上下文，然后使用代码签名添加一个或多个额外许可。

和往常一样，需要通过实例来演示下这个技术。代码6.7创建再次从ExecuteContextDB数据库的Vendor表获取数据。UnsignedProc存储过程没有签名，因此当RealUser运行它的时候会失败。SignedProc存储过程会签名，对于RealUser用户会正常运行。

 CREATE PROC SchemaUserProc.UnsignedProc @state CHAR(2)
 AS
     SELECT * FROM SchemaUserTable.Vendor WHERE state = @state;
 GO
 CREATE PROC SchemaUserProc.SignedProc @state CHAR(2)
 AS
     SELECT * FROM SchemaUserTable.Vendor WHERE state = @state;
 GO

 GRANT EXECUTE ON SchemaUserProc.UnsignedProc TO RealUser;
 GRANT EXECUTE ON SchemaUserProc.SignedProc TO RealUser;
 GO

代码6.7：创建唯一的存储过程并对RealUser在它们上面授予EXECUTE许可

但这次，我们不是通过修改运行上下文授予SELECT许可，我们会创建一个证书，如代码6.8所示。代码然后创建从证书创建一个用户，对用户在Vendor表上授予SELECT许可。最后，代码使用ADD SIGNATURE语句添加证书到SignedProc存储过程。注意只有SignedProc拿到签名；UnsignedProc还是没签名。

 CREATE CERTIFICATE MyCertificate
     ENCRYPTION BY PASSWORD = 'SZ6T4O^ff&1Kr3s?m\*'
     WITH SUBJECT = 'Certificate to sign SignedProc';
 GO

 CREATE USER MyCertificateUser
     FROM CERTIFICATE MyCertificate;

 GRANT SELECT ON SchemaUserTable.Vendor TO MyCertificateUser;
 GO

 ADD SIGNATURE TO SchemaUserProc.SignedProc BY CERTIFICATE MyCertificate
     WITH PASSWORD = 'SZ6T4O^ff&1Kr3s?m\*';
 GO

代码6.8：实现证书和分配许可到代码的代码

最后，到测试签名架构代码的时候了，如代码6.9所示。结果如插图6.2所示，UnsignedProc有断开的所有权链接接，RealUser在Vendor表上没有SELECT许可，因此执行失败。SignedProc通过使用代码签名授予SELECT许可，成功执行返回三条阿拉斯加的数据。

 EXECUTE AS USER = 'RealUser';

 -- Can't run UnsignedProc
 EXEC SchemaUserProc.UnsignedProc 'AK';
 -- Can run SignedProc
 EXEC SchemaUserProc.SignedProc 'AK';

 REVERT;

代码6.9：测试使用证书签名的代码

插图6.2：测试在UnsignedProc和SignedProc存储过程代码签名的结果

配置这个有点复杂，但安全上受益非常值得。使用正确的话，这个技术剔除了用户在潜在对象上需要的SELECT许可和存储过程上的EXECUTE许可。很可能这不是你在存储过程或用户自定义函数里广泛使用的，但当处理断开的所有权链接接且没有方便的拥有需要许可的主体时，它漂亮的解决了一些安全问题。

小结

在SQL Server里创建存储过程和用户自定义函数的最简单方法是用完整的所有权链接接来是实现它们，代码的所有者也拥有代码访问的所有数据库对象。但通常这并不可行，当在SQL Server实例里对象的成员资格在多个主体间分发的时候。这篇文件介绍了你可以处理断开的所有权链接接的两个技术，通过修改执行上下文和使用代码签名分配许可。这些技术是免费赠送的，因此你可以对单个存储过程或函数一起使用它们。那样的话，你可以处理你面对的任何许可架构，来保持你的数据库及它的数据库尽可能的安全。

原文链接

http://www.sqlservercentral.com/articles/Stairway+Series/121476/