SQL SERVER用户管理安全策略

网上看了篇“安全规划”，在单位试着实施了，果然不错，在此总结下经验。

 

大原则是：windows组－sqlserver登录－db访问－role操作
1、
用户加入一个windows组sqlserver users，并为该组（而不是为单独的用户）创建一个合法的sqlserver登录，使用户通过该组来获得登录server的权限。
2、
用户再加入db-name users组，通过查询分析器，sp_grantdbaccess使组获得访某个数据库的访问权限。
注意：db_name users组并没有访问sql server的权限。用户是通过sqlserver users组来获得访问server的权限。
3、
在DB中创建有操作权限的role，通过sp_addrolemember使db_name users组下面的用户帐户/子组加入特定role中，使用户通过成为role的成员来获得的“真正的”操作权限。

注意：2、3步必须由查询分析器，而无法由企业管理器来实现。

 

 

具体实施过程：
1、
建立组sqlserver users和sqlserver denied users，把所有用户加入前者，并为两组分别建立一个合法登录，一个“允许访问”，一个“拒绝访问”，此处不对“”服务器角色“和”数据库角色“进行任何设置。这样所有用户便可获得访问server的权限。反之亦然。

2、
建立各类起管理功能的组，如systemAdmin，可对该些组分别建立登录。对于操作服务器的各个组，我们可以用sp_addsrvrolemember存储过程把各个登录加入到合适的服务器角色：如SQL Server Administrators成为Sysadmins角色的成员。

3、
最重要的,是建立db_name users组，把需要访问某个数据库的用户全加入该组。如果人员庞大，可根据人员业务性质再建立子组，再把子组加入到该db_name users组中。
4、
通过查询分析器，（sp_grantdbaccess '组名','SQL内部名'） 使db_name users组获得对某个数据库的访问权限。（因为db_name users组并不是sqlserver中的有效登录，不能使用企业管理器。）此时，各组的用户只获得了概念上的“数据库访问权限”，而不能做任何有意义的操作。

5、
在每一个数据库中，根据操作需求创建具有不同权限的角色。

6、
通过（sp_addrolemember '角色名','用户名/子组名'），使db_name users组下面的特定用户帐户/子组加入特定角色中，通过成为角色的成员来获得的“真正的”操作权限。

 

这样建立的安全策略，应用灵活，业务变动时管理方便。
具体业务应用举例：
1、有新员工加入。
将该员工帐户加入到sqlserver users组和相应的db_name users组（或子组）中，使其获得访问server和db的权限。
再把他加入到特定角色中，获得相应的操作权限。

2、员工在同一部门，但调任不同工作，即对同一DB的不同对象及权限发生变化。
若无子组：在DB中修改－－从原有角色中直接删除该员工帐户，将其加入到另一个角色中。
若有子组：在windows中修改－－只需将员工从原有子组中删除，加入到另一个子组中。

3、员工调任不同部门，即对不同DB权限发生变化。
若无子组：DB和Windows中都要进行修改－－从原来的db_name users删除该用户帐户，将其加入到其他db_name users组中，再分配到不同角色中。
若有子组：只在windows中修改－－从原子组中删除该帐户，将其加入到其他db_name users组的子组中。因为角色由子组担当，不需要重新分配角色。

注意：
在WINDOWS组中的改变，企业管理器中并不反映，在原DB的“用户”中仍可见到已不属于该db_name users组的用户。但实际上SQL SERVER能察觉windows中组成员的改变，并禁止该用户访问原DB。却没有在企业管理器中表现出来，没有实现自动更新，为管理方便只好到企业管理器中手工删除该用户名称。是为缺点！

4、员工离开公司。
windows中，直接从sqlserver users组中删除该员工帐号，该用户即无法访问server。
尽管用户仍为db_name users组的成员，仍有访问某DB的权限，但外门既已关，内门开着也无妨。只是为管理方便起见，最好还是删一下，以正视听。