SQL账号管理超级详细Word格式.docx
《SQL账号管理超级详细Word格式.docx》由会员分享,可在线阅读,更多相关《SQL账号管理超级详细Word格式.docx(11页珍藏版)》请在冰豆网上搜索。
新建登陆名
这样简单创建一个登录名。
只能登陆数据库服务器,但不能操作里面的人一个数据库。
创建登录名后,用户只能够通过登录名访问整个SQLServer2005,而不是当中的某个数据库。
还有给这个用户服务访问某个数据库的权限。
也就是为所有访问的数据库中卫该用户建立一个数据库账户。
【3.2】:
固定的服务器角色与固定的数据库角色
固定的服务器角色名称
权限
bulkadmin
该角色有些怪异。
它被明确创建出来,用于执行BULKINSERT语句的权限,否则的话,只能由具有sysadmin权限的人来执行BULKINSERT语句。
坦白地说,我不明白为什么该语句不能像其他事情那样通过GRANT命令来授予权限,但它的确没有。
要记住,即使把一个用户加入到了bulkadmin组中,也只是给了他们访问那个语句的权限,对于运行该语句的表,并没有授予用户访问那个表的权限。
这意味着不仅需要把用户添加到bulkadmin中,而且,对于想要用户能在其上执行BULKINSERT的表,还要授予(GRANT)用户INSERT许可权限。
此外,对于将在BULKINSERT语句中引用的所有表,还要确保用户拥有正确的到那些表的SELECT访问权限
dbcreator
该角色仅限于创建和更改、删除、还原任何数据库
diskadmin
管理磁盘文件(指派给了什么文件组、附加和分离数据库,等等)
processadmin
能够管理SQLServer中运行的进程——必要的话,该角色能够终止长时间运行的进程
securityadmin
对于专门创建出来用于管理登录名、读取错误日志和创建数据库许可权限的登录名来说,该角色非常便利。
在很多方面,该角色是典型的系统操作员角色——它能够处理多数的日常事务,但是,却不具备一个真正无所不能的超级用户所拥有的那种全局访问
serveradmin
该角色能设置服务器范围的配置选项或关闭服务器。
尽管它在范围上相当有限,但是,由该角色的成员所控制的功能对于服务器的性能会产生非常重大的影响
setupadmin
该角色仅限于管理链接服务器和启动过程,并且可以执行系统存储过程
sysadmin
该角色能够执行SQLServer上的任何操作。
本质上,任何具有这种角色成员身份的人都是那个服务器上的sa。
这种服务器角色的创建为微软提供了某一天去除sa登录的能力——实际上,联机丛书把sa称作本质上为遗留物的东西
值得注意的是,在SQLServer上,Windows的Administrators组被自动映射到sysadmin角色中。
这意味着服务器的Administrators组中的任何成员同时也具有对SQL数据的sa级别的访问权限。
如果需要,你可以从sysadmin角色中删除Windows的administrators组,以提高安全性、防范漏洞
固定的数据库角色名称
固定的数据库角色与相应的权限
db_owner
该角色表现得就好像它是所有其他数据库角色中的成员一样。
使用这一角色能够造就这样的情形:
多个用户可以完成相同的功能和任务,就好像他们是数据库的所有者一样
db_accessadmin
实现类似于securityadmin服务器角色所实现功能的一部分,只不过这一角色仅局限于指派它并创建用户的单个数据库中(不是单个的权限)。
它不能创建新的SQLServer登录账户,但是,该角色中的成员能够把Windows用户和组以及现有的SQLServer登录账户加入到数据库中
db_datareader
能够在数据库中所有的用户表上执行SELECT语句,但可以操作临时表
db_datawriter
能够在数据库中所有的用户表上执行INSERT、UPDATE和DELETE语句
db_ddladmin
能够在数据库中添加、修改或删除对象
db_securityadmin
securityadmin服务器角色的数据库级别的等价物。
这一数据库角色不能在数据库中创建新的用户,但是,能够管理角色和数据库角色的成员,并能在数据库中管理语句和对象的许可权限
db_backupoperator
备份数据库(打赌你不会想到那样一个角色!
)
db_denydatareader
提供一种等同于在数据库中所有表和视图上DENYSELECT的效果
db_denydatawriter
类似于db_denydatareader,只不过这里影响的是INSERT、UPDATE和DELETE语句
Public
每个数据库用户都属于public数据库角色。
当尚未对莫个用户授予特定权限或角色的时候,则该用户将继承public角色的权限
【4】角色与权限的概念区别
【权限是针对用户而言的,若用户想对SQLServer进行某种操作,就必须具备使用该操作的权限,而角色是指用户对SQLServer进行的操作类型。
角色根据权限划分可以分为:
固定的服务器角色与固定的数据库角色。
】
1、用户User:
最终操作人员,权限的最终受益者,控制权限控制权限实际上就是控制用户的权限,而不是角色或者用户组的权限
2、用户组UserGroup:
是相对垂直而言的。
比如说采购部这个用户组实际上是由采购部的业务员(暂且定义都为用户)组成的,具有上下级的明确关系;
采购部只能查看属于采购部的文档,销售部只能查看属于销售部的文档,带有强烈的部门(组)性质,但是采购部业务员虽然都是属于同一个部门,但是却不一定有着相同的权限,比如说经理和一般业务员的权限肯定存在差异
3、角色Role:
用户组是带有一种垂直既自上而下的性质,而角色的范围则没有带着那么浓厚的垂直关系,而是带有比较明显的水平(交叉)性质;
比方说现定义一个角色:
经理,这个经理包含了各个部门的经理,而不单单是采购部经理或者是销售部经理,很明显这个‘经理’角色显然同时具有各部门的经理的权限,也就是说这时候如果各部门经理们只是处于该‘经理’角色,那么采购部经理不但具有采购部经理的操作权限,同时也被赋予了其他各部门经理的权限,这个时候各个部门经理的权限是一致的,但是这样势必造成权限的拥堵或者混乱,此时刚才提到的第一个对象:
用户就派上用场了,几个部门经理同属于‘经理’角色情况下又想他们之间的权限有区别,你只能对每个部门经理(身份为:
用户)单独授权了,当然你也可以根据该用户身处的用户组和角色之间的关联关系或者排斥关系来确认用户的最终权限。
CREATELOGINMRWITHPASSWORD=’MrSoft’
ALTERLOGINMRWITHPASSWORD=”MingRiSoft’
DROPLOGINlogin_name
特定对象:
可以进一步定义对象搜索
特定类型的所有对象:
可以指定应包含在基础列表中的对象类型
属于该架构的所有对象:
用于提那家由“架构名称”框中指定架构拥有的所有对象。
这是一种以数据库为单位的授权方式
登录名对不同数据库的操作权限