SQL Server ->> Database Promgramming Object Security Control（数据库编程对象安全控制）

对于SQL Server内编程对象的安全控制是今天我在思考的问题。在MSDN上找到了几篇有用的文章。

首先微软推荐了三种做法：

1）第一种做法是在SQL Server中对一个应用程序对应创建应用程序角色。做法是在客户端开启连接请求到SQL Server服务器的时候指定ApplicationRole名字和密码。这种做法需要做的工作少而且后期维护的成本低，但是前提是比较简单而且密码是暴露在客户端的。它无法完成在存储过程中的不同代码片段进行权限控制。

2）第二种做法是使用EXECUTE AS表达式加上WITH COOKIE字句来针对某个代码块切换当前用户执行上下文到某个权限更高/低的用户的执行上下文，然后通过REVERT表达式切换回caller。它的前提是要授权某个用户对于另外一个用户具有IMPERSONATE的权限。这种做法得出好处是对安全控制更加细化，细化到当前过程中的某个代码片段的身份。而缺点是加大了编码的复杂性，需要开发人员在开发时的配合。

3）第三种方法是对存储过程/函数/触发器进行证书签名，这样当存储被调用的时候，SQL Server就会把caller的权限和证书签名的用户的权限做一个合集，从而不需要切换执行上下文。当中需要创建一个证书以及一个和证书相关联的数据库用户（与login无关联），然后对数据库用户授权数据库对象的访问权限。而存储过程的签名（非对称）其实就是对存储过程代码产生hash值，然后用生成的私钥进行加密。在每次执行的时候用公钥解压得到存储过程的hash值，然后和现有存储过程的hash值进行比对，如果不一致就说明上次加密后存储过程本身受到修改，这个时候会报错。每次修改存储过程需要对存储过程重新签名。

说了这么多，做法有多种：

1）以前的项目经验是将Database Role与Windows Active Directory的Security Group结合来控制Windows登陆用户对于数据库实体对象和编程对象的访问权限控制。但是这种做法的弊端。管理成本有点高。需要得到AD的某个组织单位的管理权限，可以添加修改AD的用户。小项目还行。

2）第二种做法之前写过文章讲REVERT。这种做法在某些场景是很好用的。对权限的控制是最到位的。只是要对开发人员的培训。在大型项目中挺不错。把所有的权限控制都放到存储过程中控制。这样我们可以只给应用程序层最小的权限。这样最大程度避免了权限泄露（overflow）的可能。是我觉得三者中最不错的解决方案。有一点需要说明一下，我一直以为这种EXECUTE AS USER的做法其实是复制了login的权限。其实不是。这里是站在database层面的。于是我做了一个测试，login1对DB1和DB2中各自的A表都没有写入权限，login2对DB1和DB2中各自的A表都有写入权限。现在login2各自映射到DB1和DB2中的user1。假设在DB1中创建一个存储过程sp1，EXECUTE AS USER = 'user1'对DB1和DB2中个各自的A表插入一行记录（对DB2库中的A表插入数据采用[db].[schema].[table]这种引用方法）。我设想是既然我impersonate了DB1中user1的身份，那么我按道理来说，两个数据库的user1都是代表了login1，其实我也相当于impersonate了DB2中user1的身份，那么即便说存储过程是存在DB1中，我对DB2中表进行数据插入也是没问题的。事实相反。那么仔细来思考这个问题，其实我这么想是错的。如果真是这样，那必然会存储巨大的安全隐患。不可能说某个login对A数据库没有访问或者对象的访问权限，而你可以通过impersonate某个库中的用户然后顺带获得这个用户所映射的login的权限去其他数据库进行数据库对象操作。这其实是个非常危险的想法。这个在EXECUTE AS (Transact-SQL)中已经做了说明。这个这里不做demo了，前面的SQL Server ->> EXECUTE AS LOGIN/USER和Revert表达式已经讲了。

3）第三种做法是针对整个存储过程范围而言，而有其他另一种做法是通过在创建或者修改存储过程的时候添加WITH EXECUTE AS 'user'来针对整个存储过程进行上下文切换。前者相比较后者的优势是不需要切换执行上下文，这样我们可以追踪真实的caller，对于audit是很有帮助的，保留原始/真实身份信息。还有一点是它是以一种权限合并的方式合并了caller和证书用户的权限。而缺点是因为对存储过程进行了签名，每次修改都需要重新签名。

4）第一种做法我没试过，不过从它自身的缺点来看，应该没有后两者好。

参考：

Creating Application Roles in SQL Server

Customizing Permissions with Impersonation in SQL Server

Signing Stored Procedures in SQL Server

Tutorial: Signing Stored Procedures with a Certificate