一、说明

本篇文章主要说一说SQLServer数据库中访问控制控制点的测评项的理解，再阅读本篇文章前，请先阅读等保测评2.0：SQLServer访问控制（上），SQLServer权限的基本知识在本篇文章内就不重复叙述了。

二、测评项

a)应对登录的用户分配账户和权限；

b)应重命名或删除默认账户，修改默认账户的默认口令； 

c)应及时删除或停用多余的、过期的账户，避免共享账户的存在；

d)应授予管理用户所需的最小权限，实现管理用户的权限分离； 

e)应由授权主体配置访问控制策略，访问控制策略规定主体对客体的访问规则； 

f)访问控制的粒度应达到主体为用户级或进程级，客体为文件、数据库表级； 

g)应对重要主体和客体设置安全标记，并控制主体对有安全标记信息资源的访问。

三、测评项a

a)应对登录的用户分配账户和权限；

3.1. 测评项要求1

如果从字面意思来看，就是一个废话，用户都登录账户了，自然就存在着账户。

这里的意思是应该是你本来就存在“多个账户”，然后当用户使用时要适当的“分配账户”给用户，而账户再拥有不一样的权限，这样就实现了将权限通过账户分配给用户（自然人）。

所以，该测评项就需要SQLServer中存在两个账户，且这两个账户的权限不一样。

在SQLServer中，所谓的账户就是登录名：

3.2. 测评项要求2

在测评要求中测评实施如下：

在SQLServer中，其默认账户不少，主要应该关注那种会造成权限失控的账户或角色。

sa登录名

sa登录名，是SQLServer的默认登录名，强制（无法更改的）属于服务器角色sysadmin的成员，拥有服务器的所有权限。

对于这个测评项，所谓的限制权限就是直接禁用sa登录名，这个倒不是一定需要，看业务需求。

服务器角色public

服务器角色public，默认存在，且不能删除。

SQLServer所有登录名均为服务器角色public的成员，也即所有登录名均拥有服务器角色public的权限。

默认情况下，服务器角色public的权限仅为查看任意数据库：

所以默认情况下，服务器角色public的权限就基本已经实现最小化了，核查一下即可。

数据库角色public

数据库角色public，默认存在，且不能删除。

所有数据库用户默认为数据库角色public的成员，也即所有数据库用户均拥有数据库角色public的权限。

默认情况下，数据库角色public的不拥有任何架构，查看某数据库角色或数据库用户拥有的架构的语句为如下：

SELECT * FROM  sys.schemas WHERE principal_id = DATABASE_PRINCIPAL_ID('public')

也可以用过图形化界面查看，不过感觉不如SQL语句，因为存在滑动条，还得滚动滑动条才能看到全部情况：

默认情况下，数据库角色public拥有数据库中一部分系统视图的选择权限，不具备对用户自建表的权限，其查询语句如下：

select  princ.name
,       princ.type_desc
,       perm.permission_name
,       perm.state
,       perm.state_desc
,       perm.class_desc
,       object_name(perm.major_id)
from    sys.database_principals princ
left join
        sys.database_permissions perm
on      perm.grantee_principal_id = princ.principal_id
where princ.name='public'

注意：sys.database_permissions视图里存储的是数据库主体如数据库用户、数据库角色对具体的数据库对象如数据库表、架构等存在的直接权限。

间接权限不会显示在里面，如数据库用户A属于数据库角色B，那么A就拥有B的权限，但sys.database_permissions视图中A的权限数据不会有变化。

对于直接权限，也可以通过界面查看：

嗯，从现有的角度来看，数据库角色public也没拥有啥权限，比如对于sys.all_columns就没有权限，也就无法得知用户自建表的结构，应该算是权限最小化了。

数据库用户guest

数据库用户guest默认存在，且不能删除。

SQLServer中对于某一个登录名而言，如果某个数据库中无映射的数据库用户，那么将会映射到数据库Guest用户中。

数据库用户guest默认拥有架构guest：

数据库用户guest默认不属于其它数据库角色（除了public），用户新建的数据库中对于数据库默认也不具备任何权限：

不过在master数据库中具有选择权限：

对于数据库用户guest而言，默认情况也是最小权限。

总结

对于这些默认服务器角色、数据库用户 、数据库角色，主要检查是否仅拥有小的权限。

四、测评项b

b)应重命名或删除默认账户，修改默认账户的默认口令；

SQLServer中默认的登录名是sa，虽然好像有方法可以修改sa的用户名，但似乎不应该强制被测评单位实现。

至于默认口令，sa不存在默认口令，初始口令是在安装数据库时设置的。

五、测评项c

c)应及时删除或停用多余的、过期的账户，避免共享账户的存在；

首先说一说多余账户，一般是先访谈，问对方某账户是干啥用的。

如果对方答不上来，你自己通过核查也无法判断，那么这就是多余账户（或者叫不明用途的账户）。

而避免存在共享账户，即不能多人使用同一个账户。

但如果一人使用多个账户的话，虽然不属于共享账户的情况，但是一人使用多个账户的情况意义何在？有存在多余账户的嫌疑。

六、测评项d

d)应授予管理用户所需的最小权限，实现管理用户的权限分离；

数据库和操作系统有些不一样的地方在于，数据库中的对象和应用程序的业务逻辑关联比较大。

除了一般意义上的数据库的管理账户，大概率还存在着一些应用程序使用的账户。

比如某应用程序功能模块连接数据库时使用的登录名只对某数据库的某些视图或者存储过程存在权限，等等。

对于要如何实现测评项的要求，个人感觉没有通用的要求模板，只要不是一个sa登录名从头用到尾（即只使用最高权限账户），或多或少都能符合一点要求，也就是部分符合。

那么怎么才算是符合呢？应该要根据应用程序业务复杂程度来判断吧，应用程序业务越复杂或者越庞大，则数据库账户的权限就应该划分得越细致。

如果不是特别简单的业务，比如只有一个数据库的那种，至少应该将权限先设置到数据库权限一级，而不是服务器权限一级。

也即权限直接针对具体的数据库，而不是对整个服务器具备权限。

至于具体的权限，如果仅仅针对该测评项，其实服务器角色和数据库角色中就有现成的模板，不是很需要自己创建角色：

看上图，比如数据库角色中，有具备纯写权限的角色、纯读权限的角色、备份数据库权限的角色等等。

至于如何查看某登录名在服务器、数据库、表（视图、存储过程）各个层级具体拥有的权限，可以看看这篇文章：数据库权限检查，另外再看看等保测评2.0：SQLServer访问控制（上），就差不多了。

七、测评项e

e)应由授权主体配置访问控制策略，访问控制策略规定主体对客体的访问规则；

所谓授权主体，即只有某个账户或者某一类账户具有权限来设置其它账户的权限。

可能拥有此类权限的账户为如下：

1.sa：默认账户，属于sysadmin角色，拥有服务器全部权限；

2.属于sysadmin角色的账户，拥有服务器全部权限；

3.数据库中属于db_owner角色的账户，拥有该数据库的全部权限；

4.某架构拥有者（用户或角色），可以设置该架构的权限；

5.db_securityadmin角色，为固定数据库角色，它的成员可以修改角色成员身份和管理权限。

6.直接被授予该权限的用户或角色。

这里就要看被测评方是否设置了这类角色了。

八、测评项f

f)访问控制的粒度应达到主体为用户级或进程级，客体为文件、数据库表级；

就是看权限控制粒度，对于客体，要看是否达到了数据库表的级别，也即单独对数据库表设置权限（视图、存储过程也可以），或者至少是否达到了架构级别（当然，不能只存在一个架构）。如果仅达到了数据库级别或者服务器级别的权限，那肯定是不符合要求的。

对于主体，要看是权限的设置是否直接针对某个登录名，在数据库级别，就要看是否直接针对某数据库用户。

九、测评项g

g)应对重要主体和客体设置安全标记，并控制主体对有安全标记信息资源的访问。

SqlServer自身应该不具备这个功能，可能要依靠操作系统或者第三方的什么软件来实现了。

关于安全标记，可以看看等保测评2.0：Windows访问控制中测评项g中的内容。

十、总结

其实测评项方面的理解相对于等保测评2.0：Windows访问控制没有什么新内容，这里主要是结合SQLServer的基础知识写了一些东西。

其实我也没有写得很明确，如果很明确的话应该以测评项指导书的格式来写。

但是这东西是没有一个固定的标准的，再说各个测评机构肯定都有自己的测评项指导书，我这里也就不献丑了。

*本文作者：起于凡而非于凡，转载请注明来自FreeBuf.COM