申请免费个人网站和域名,设计头像 制作 免费,广州白云区今天的消息,页面设计的突出主体原则在保密你的服务器和数据#xff0c;防备当前复杂的攻击#xff0c;SQL Server有你需要的一切。但在你能有效使用这些安全功能前#xff0c;你需要理解你面对的威胁和一些基本的安全概念。这篇文章提供了基础#xff0c;因此你可以对SQL Server里的安全功能充分利用#xf…在保密你的服务器和数据防备当前复杂的攻击SQL Server有你需要的一切。但在你能有效使用这些安全功能前你需要理解你面对的威胁和一些基本的安全概念。这篇文章提供了基础因此你可以对SQL Server里的安全功能充分利用不用在面对特定威胁不能保护你数据的功能上浪费时间。 SQL Server决定主体是否有需要的许可执行代码的基本方式是它的执行上下文角色。这都是复杂的可能性主体有执行代码的许可但没有代码访问的潜在对象的许可例如表里的数据。这篇文章会探寻SQL Server执行上下文所有权链接接模拟还有向你展示下如果通过T-SQL代码控制数据访问。 执行上下文 当用户执行一个存储过程或其它数据库代码时SQL Server检查确保不仅用户有运行存储过程的许可而且有代码访问使用数据库对象的许可。没有这类许可检查有些人会很容易创建可以读取表使用执行代码访问不需要其它的对象代码。这会是重大的安全漏洞。 这个许可检查过程不发生的唯一例外是代码的所有者也是代码访问的所有潜在对象的所有者。在这个共同所有权下SQL Server验证调用者在代码上有EXECUTE许可不会继续检查许可。 例如如果在存储过程中的嗲吗访问三个表和四个视图SQL Server在执行代码前进行这些概念上的步骤 在代码上验证调用者有EXECTUTE许可。如果调用者没有返回一个错误并不再继续。检查代码的所有者是否也有代码访问对象的许可。如果共同所有权common ownership存在的话停止检查并执行代码。如果共同所有权common ownership不存在的话检查确保调用者代码访问的对象上有许可。如果调用者在一个或多个对象上没有许可返回一个错误且不执行代码。如果调用者有所有需要的许可执行代码。否则返回错误且不执行代码。在代码调用其它带按摩或访问其它对象的地方共同所有权继续检查即轮流调用其它代码或访问其它对象。只要链里的所有对象有同样的所有者许可检查就不需要。但只要链里的一个对象比要访问它的对象多出不同的所有者在那个对象上的许可就检查了。 在这钟情形里的对象所有权被称为所有权链接接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用户。因为表和存储过程在属于不同用户的不同架构里定义存在断开的所有权链接接。 1 USE ExecuteContextDB;
2 GO
3 CREATE PROC SchemaUserProc.VendorAccessProc state CHAR(2)
4 AS
5 SELECT * FROM SchemaUserTable.Vendor WHERE state state;
6 GO 代码6.1创建在一个在一个架构里访问不同架构里的表的存储过程这里架构有不同的拥有者。 提示 下面的代码会创建登录、数据库、用户和这个部分使用的架构同样也会在Vendor表里插入一些记录。先运行下列带代码再运行代码6.1。 1 -- Create the logins and database for this demo2 USE master;3 GO4 5 IF SUSER_SID(UserProc) IS NOT NULL DROP LOGIN UserProc;6 IF SUSER_SID(UserTable) IS NOT NULL DROP LOGIN UserTable;7 IF SUSER_SID(RealUser) IS NOT NULL DROP LOGIN RealUser;8 GO9 CREATE LOGIN UserProc WITH password Y2!37z#F!l1zB;
10 CREATE LOGIN UserTable WITH password Y2!37z#F!l1zB;
11 CREATE LOGIN RealUser WITH password Y2!37z#F!l1zB;
12 GO
13
14 IF DB_ID(ExecuteContextDB) IS NOT NULL DROP DATABASE ExecuteContextDB;
15 CREATE DATABASE ExecuteContextDB;
16 GO
17 USE ExecuteContextDB;
18 GO
19
20 -- Create the users
21 CREATE USER UserProc;
22 CREATE USER UserTable;
23 CREATE USER RealUser;
24 GO
25
26 -- Create the schemas
27 CREATE SCHEMA SchemaUserProc AUTHORIZATION UserProc;
28 GO
29 CREATE SCHEMA SchemaUserTable AUTHORIZATION UserTable;
30 GO
31
32 -- Create a table and a proc in different schemas to ensure that
33 -- there is no ownerhship chaining.
34 CREATE TABLE SchemaUserTable.Vendor
35 (ID INT, name VARCHAR(50), state CHAR(2), phno CHAR(12));
36 GO
37 SET NOCOUNT ON
38 GO
39 INSERT INTO SchemaUserTable.Vendor VALUES (1,Vendor1,AK,123-345-1232);
40 INSERT INTO SchemaUserTable.Vendor VALUES (2,Vendor2,WA,454-765-3233);
41 INSERT INTO SchemaUserTable.Vendor VALUES (3,Vendor3,OR,345-776-3433);
42 INSERT INTO SchemaUserTable.Vendor VALUES (4,Vendor4,AK,232-454-5654);
43 INSERT INTO SchemaUserTable.Vendor VALUES (5,Vendor5,OR,454-545-5654);
44 INSERT INTO SchemaUserTable.Vendor VALUES (6,Vendor6,HI,232-655-1232);
45 INSERT INTO SchemaUserTable.Vendor VALUES (7,Vendor7,HI,453-454-1232);
46 INSERT INTO SchemaUserTable.Vendor VALUES (8,Vendor8,WA,555-654-1232);
47 INSERT INTO SchemaUserTable.Vendor VALUES (9,Vendor9,AK,555-345-1232);
48 GO 代码6.2在存储过程上授予EXECUTE许可给真正的用户RealUser它会运行代码。 1 -- Grant permissions on the stored procedure
2 GRANT EXECUTE ON SchemaUserProc.VendorAccessProc TO RealUser;
3 GO 代码6.2在新的存储过程上授予EXECUTE许可。 在SSMS里你可以运行EXECUTE AS作为临时修改安全上下文的在查询窗体里运行的代码语句。使用代码6.3修改安全上下文为RealUser来运行存储过程获得在位于阿拉斯加的供应商列表。 1 EXECUTE AS user RealUser;
2 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切换返回你自己的安全上下文 1 REVERT; 代码6.4:恢复用户运行SSMS的原始安全上下文 接下来修改存储过程来包含EXECUTE AS子句使用UserTable的安全上下文来运行存储过程它在表上拥有SELECT许可如代码6.5所示。 1 ALTER PROC SchemaUserProc.VendorAccessProc state CHAR(2)
2 WITH EXECUTE AS UserTable
3 AS
4 SELECT * FROM SchemaUserTable.Vendor WHERE state state;
5 GO 代码6.5修改存储过程在运行时间使用EXECUTE AS修改运行上下文 提示 在这个例子里UserTable通过成员资格拥有在Vendor表上的SELECT许可。但成员资格没有必要用来执行上下文切换工作。例如可以通过表拥有者授予用户EXECUTE AS user许可。 然后修改安全上下文为UserTable再次尝试运行存储过程使用代码6.6。 1 EXECUTE AS user RealUser;
2 EXEC SchemaUserProc.VendorAccessProc AK;
3 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用户会正常运行。 1 CREATE PROC SchemaUserProc.UnsignedProc state CHAR(2)2 AS3 SELECT * FROM SchemaUserTable.Vendor WHERE state state;4 GO5 CREATE PROC SchemaUserProc.SignedProc state CHAR(2)6 AS7 SELECT * FROM SchemaUserTable.Vendor WHERE state state;8 GO9
10 GRANT EXECUTE ON SchemaUserProc.UnsignedProc TO RealUser;
11 GRANT EXECUTE ON SchemaUserProc.SignedProc TO RealUser;
12 GO 代码6.7创建唯一的存储过程并对RealUser在它们上面授予EXECUTE许可 但这次我们不是通过修改运行上下文授予SELECT许可我们会创建一个证书如代码6.8所示。代码然后创建从证书创建一个用户对用户在Vendor表上授予SELECT许可。最后代码使用ADD SIGNATURE语句添加证书到SignedProc存储过程。注意只有SignedProc拿到签名UnsignedProc还是没签名。 1 CREATE CERTIFICATE MyCertificate2 ENCRYPTION BY PASSWORD SZ6T4O^ff1Kr3s?m\*3 WITH SUBJECT Certificate to sign SignedProc;4 GO5 6 CREATE USER MyCertificateUser 7 FROM CERTIFICATE MyCertificate;8 9 GRANT SELECT ON SchemaUserTable.Vendor TO MyCertificateUser;
10 GO
11
12 ADD SIGNATURE TO SchemaUserProc.SignedProc BY CERTIFICATE MyCertificate
13 WITH PASSWORD SZ6T4O^ff1Kr3s?m\*;
14 GO 代码6.8实现证书和分配许可到代码的代码 最后到测试签名架构代码的时候了如代码6.9所示。结果如插图6.2所示UnsignedProc有断开的所有权链接接RealUser在Vendor表上没有SELECT许可因此执行失败。SignedProc通过使用代码签名授予SELECT许可成功执行返回三条阿拉斯加的数据。 1 EXECUTE AS USER RealUser;
2
3 -- Cant run UnsignedProc
4 EXEC SchemaUserProc.UnsignedProc AK;
5 -- Can run SignedProc
6 EXEC SchemaUserProc.SignedProc AK;
7
8 REVERT; 代码6.9测试使用证书签名的代码 插图6.2测试在UnsignedProc和SignedProc存储过程代码签名的结果 配置这个有点复杂但安全上受益非常值得。使用正确的话这个技术剔除了用户在潜在对象上需要的SELECT许可和存储过程上的EXECUTE许可。很可能这不是你在存储过程或用户自定义函数里广泛使用的但当处理断开的所有权链接接且没有方便的拥有需要许可的主体时它漂亮的解决了一些安全问题。 小结 在SQL Server里创建存储过程和用户自定义函数的最简单方法是用完整的所有权链接接来是实现它们代码的所有者也拥有代码访问的所有数据库对象。但通常这并不可行当在SQL Server实例里对象的成员资格在多个主体间分发的时候。这篇文件介绍了你可以处理断开的所有权链接接的两个技术通过修改执行上下文和使用代码签名分配许可。这些技术是免费赠送的因此你可以对单个存储过程或函数一起使用它们。那样的话你可以处理你面对的任何许可架构来保持你的数据库及它的数据库尽可能的安全。 原文链接 http://www.sqlservercentral.com/articles/StairwaySeries/121476/
