SQL Server权限体系
权限两个字，一个权力，一个限制。在软件领域通俗的解释就是哪些人可以对哪些资源做哪些操作。在SQL Server中，”哪些人”，“哪些资源”,”哪些操作”则分别对应SQL Server中的三个对象，分别为主体(Principals),安全对象(Securables)和权限(Permissions)，而权力和限制则是对应了SQL Server中的GRENT和DENY。对于主体，安全对象和权限的初步理解，见下图：
主体
“主体”是可以请求 SQL Server 资源的实体。主体可以是个体，组或者进程。主体可以按照作用范围被分为三类:
- Windows级别主体：包括Windows 域登录名和Windows 本地登录名。
- 服务器级别主体：包括服务器登录名和服务器角色。
- 数据库级别主体：包括数据库用户、数据库角色、固定数据库角色以及应用程序角色。
可以看到主体包括登录名以及角色。
角色
角色可以看成是权限的集合体，为了方便权限管理，可以把一些常用权限赋予角色，然后再把角色赋予相关用户，则这些用户就继承了橘色中的所有权限。一般情况下，数据库会内置一些角色，用户也可以创建自定义角色。对角色进行权限管理的方式与对用户进行权限管理的方式是相同的。
角色在SQL Server中被分为三类，分别为:
- 内置角色----这类角色在服务器安装时已经默认存在，其权限是固定的，并且不能被删除
- 用户自定义角色----这类角色由用户按照需求自定义创建
- 应用程序角色----这类特殊角色用于管理应用程序的数据访问
角色也分为两个方面：
- 服务器级别的角色，用于数据库服务器方面的控制权限
- 数据库级别的角色，用于数据库中数据的控制权限。
（1）服务器级别的角色
服务器级角色的权限作用域为服务器范围。例如创建、修改、删除数据库，管理磁盘文件，添加或删除数据库连接等等，都是需要服务器上的权限才能进行操作。
固定服务器角色具有一组固定的权限，并且适用于整个服务器范围。 它们专门用于管理 SQL Server，且不能更改分配给它们的权限。 可以在数据库中不存在用户帐户的情况下向固定服务器角色分配登录。
服务器级别的对象，只能包含登录名。定义了服务器角色，你定义的登陆用户就有了相应的执行权限。先来看一下服务器级别的固定角色：
| 服务器角色 | 含义 |
|---|---|
| sysadmin | 可以在服务器上执行任何活动 |
| serveradmin | 可以更改服务器范围的配置选项和关闭服务器 |
| securityadmin | 管理和审核登录用户。具有 GRANT、DENY 和 REVOKE 服务器和数据库级别的权限。此外，还可以重置 SQL Server 登录名的密码 |
| processadmin | 管理SQL Server运行的进程 |
| setupadmin | 可以使用 T-SQL 语句添加和删除连接服务器，并可以执行某些系统存储过程（如 sp_serveroption） |
| bulkadmin | 可以运行 BULK INSERT 语句 |
| diskadmin | 用于管理磁盘文件 |
| dbcreator | 可以创建、更改、删除和还原任何数据库 |
| public | public角色不同于其它角色在于其权限可以被修改，每个 SQL Server 登录名都属于 public 服务器角色。无法将用户、角色或组指派给它，因为默认情况下它属于该角色，且public不能被删除 |
（2）数据库级别的角色
数据库级角色的权限作用域为数据库范围。例如可以访问哪个数据库，可以访问哪个数据库中的哪些数据表、哪些视图、哪些存储过程等等，都需要数据库上的权限才能进行操作。
SQL Server存在两种类型的数据库级角色：数据库中预定义的“固定数据库角色”和可以创建的“用户定义的数据库角色”。
固定数据库角色是SQL Server预定义的数据库角色，具有数据库级别的管理权限，并且存在于每个数据库中。db_owner 数据库角色的成员可以管理固定数据库角色成员身份。自定义数据库角色是当固定数据库角色不能满足要求时，可以自定义数据库角色。
数据库级别的对象，只能包含数据库用户名。先来看一下数据库级别的固定角色：
| 数据库角色 | 含义 |
|---|---|
| db_owner | 可以执行数据库中技术所有动作的用户，执行所有的配置活动和维护活动 |
| db_securityadmin | 管理数据库安全，可以修改角色成员身份和管理权限。向此角色中添加主体可能会导致意外的权限升级 |
| db_accessadmin | 可以为 Windows 登录名、Windows 组和 SQL Server 登录名添加或删除数据库访问权限 |
| db_backupoperator | 可以备份数据库 |
| db_ddladmin | 可以在数据库中运行任何数据定义语言 (DDL) 命令 |
| db_datawriter | 可以在所有用户表中添加、删除或更改数据 |
| db_datareader | 可以从所有用户表中读取所有数据 |
| db_denydatawriter | 不能添加、修改或删除数据库内用户表中的任何数据 |
| db_denydatareader | 不能读取数据库内用户表中的任何数据 |
| public | public角色不同于其它角色在于其权限可以被修改，每个数据库用户、角色或组都属于public数据库角色。无法将用户、角色或组指派给它，因为默认情况下它属于该角色，且public不能被删除 |
登录账号和数据库用户
SQL Server的服务器和数据库是两个层次的概念，SQL Server的用户也分为两种，一种是服务器登陆账号，另一种是数据库用户。
一个人要操作SQL Server数据库，首先要为其创建服务器登陆账号，使得他可以登录到服务器上，然后还要在要操作的数据库上创建和这个登陆账号对应的数据库用户。
可以给登陆账号赋予相应权限，使得这个账号可以执行指定的管理服务器的任务。也可以给数据库用户赋予相应权限，使得这个数据库用户可以在这个数据库中执行指定的操作。
服务器登陆账号分为为Windows验证及SQL Server验证两种。
- Windows身份验证模式：把Windows的操作系统用户添加为SQL Server服务器登陆账号，SQL Server并不参与验证。SQL Server完全相信Windows的验证结果，所以用此方式登录SQL Server时并不需要提供密码。
- SQL Server和Windows身份验证模式：这种模式即允许由Windows来验证主体身份，又允许SQL Server来验证主体身份，当由SQL Server验证主体身份时，需要用户名和密码来确认主体身份，和使用什么Windows账户半毛钱关系都没有，是在服务器上创建的另外一种独立账号。
登录名
登录名是服务器级别的主体，但无论是上述哪个层级的主体，因为需要登录到SQL Server实例，所以每一个层级的主体都需要一个与之对应的登录名。对于Windows级别的主体来说，Windows用户会映射到登录名。对于数据库级别的主体来说，其用户必须映射到登录名中。而登录名可以不映射到数据库用户，如图所示登录名的映射关系：
在图中实例层级的登录名中，我们看到除了自定义添加的用户之外，还有一些由系统添加的登录名。
- 以”##”开头和结尾的用户是SQL Server内部使用的账户，由证书创建，仅供内部系统使用，不应该被删除。
- sa 登录名是服务器级的主体。 默认情况下，该登录名是在安装实例时创建的。从 SQL Server 2005 开始，sa 的默认数据库为“master”。 sa账户可以认为是超级管理员用户，拥有一切特权，可以在SQL Server中为所欲为，并且不能够被删除。因此sa作为分配权限的起点（也就是SA账户在最开始时给予了其他主体对于安全对象的权限）。因此对于Sa的密码要设置的尽可能复杂，否则Sa登录名被盗取后果不堪设想。
- NT AUTHORITYNETWORK SERVICE和NT AUTHORITYSYSTEM账户是和启动SQL Server这个Windows服务的账户有关，如果使用本地登录账户或是网络账户启动SQL Server服务，请不要删除这两个账户。
- BUILDINAdministrator账户是与本地管理员组关联的登录名，默认属于sysadmin角色。这个账户使得任何属于本地管理员的账户都可以获得对SQL Server的完全控制权。
数据库用户
数据库用户是数据库级别的主体,被用于访问数据库层面的对象。每一个数据库用户都必须要一个与之对用的登录名。数据库用户的信息存在数据库中，而登录名存在实例级别的Master数据库中(但SQL SERVER2012的Contained Database允许将登录名也存在数据库级别)。通常来说，数据库层级的用户可以和映射的登录名不一致，但由于这种做法会引起混淆，因此并不推荐，如下图所示。
默认情况下，每个数据库都带有4个内置用户，如下图所示：
- dbo用户：dbo用户是Database Owner的简称，如果说SA是实例级别的老大，那DBO就是数据库级别的老大，是数据库的拥有者。这个用户也同样不能被删除，登录名sa自动映射为数据库用户dbo。每一个表创建时如果没有指定Schema，则默认在dbo这个schema下。
- guest 用户：guest用户是一个来宾账户，这个账户允许登录名没有映射到数据库用户的情况下访问数据库。默认情况下guest用户是不启用的，但不能删除。可通过撤消该用户的 CONNECT 权限将其禁用。
--允许guest用户连接权限
GRANT CONNECT TO guest
--收回guest的连接权限
REVOKE CONNECT TO guest
-
INFORMATION_SCHEMA 和 sys：它们都作为用户出现在目录视图中。 这两个实体是 SQL Server 所必需的。 它们不是主体，不能修改或删除它们。
安全对象
安全对象是SQL Server数据库引擎授权系统控制对其访问的资源。安全对象分别属于3个层次：服务器、数据库、架构。
不同的范围包含不同的安全对象，详见下图。
架构(schema)及其管理
在SQL Server 2000中的构架是和用户绑定的，比如我新建用户Jack，SQL Server自动分配一个叫Jack构架，用户Jack并不能改变这个选项，而由Jack所建的任何对象都在Jack之下。比如新建一个表，则为Jack.Table1。当Jack如果离职时，这对管理来说简直是一场噩梦。
从SQL Server2005开始，数据库用户不再等同于架构，允许用户和构架分离。而在Oracle中，用户与模式还是等同的(在Oracle中，schema一般翻译为模式)。所以以往 SQL Server 内的对象命名是“服务器.数据库.用户名.对象”，但如今的对象命名改为“服务器.数据库.Schema.对象”
架构是与创建它的数据库用户无关的命名空间，也可以说，架构是数据库对象的容器，独立于创建它们的数据库用户而存在。架构有一下特点：
- 多个数据库用户可以共享一个默认的架构；
- 单个架构可以包含多个数据库用户拥有的对象；
- 架构的所有权和架构内的安全对象可以转移；
- 对象可以在不同的架构之间移动；
- 可以删除数据库用户，而不删除相应架构中的对象。
架构所有者和权限
通过用户架构分离，可实现管理数据库对象权限的更大灵活性。，因为对象不再绑定到用户账号上，所以你根本不用担心当一个账号被删除时需要变换对象的拥有者。
默认情况下，当开发人员创建了一个对象时，该对象并不属于开发人员而属于一个数据库架构。
任何数据库主体都可以拥有架构，并且一个主体可拥有多个架构。每个架构都有其所有者，但是所有者和架构名是不绑定的。所以当一个用户拥有一个架构，并且这个用户必须从数据库中删除时，可以不用破坏任何代码而仅仅是将架构的所有者变一下。
可以对架构应用安全规则，安全规则将由架构中的所有对象继承。 如果设置了对架构的访问权限，则当新对象添加到架构时，新对象会自动应用这些权限。注意：用户不从架构继承权限，架构权限由架构中包含的数据库对象继承。
内置架构
SQL Server创建了十个预定义的架构，它们与内置数据库用户和角色具有相同的名称。这些架构主要用于向后兼容性。如果您不需要与固定数据库角色具有相同名称的架构，则可以删除它们。您不能删除下列架构：
- dbo：dbo 是新创建的数据库的默认架构。 dbo 架构由 dbo 用户帐户拥有。 默认情况下，使用 CREATE USER命令创建的用户的默认架构为 dbo，但是分配了 dbo 架构的用户不继承 dbo 用户帐户的权限。
- guest
- sys：为系统对象而保留的。
- INFORMATION_SCHEMA：为系统对象而保留的。
如果从模型数据库中删除这些架构，它们将不会显示在新数据库中。