《安全性管理》PPT课件.ppt

第9章 SQL Server的安全性管理,逯燕玲 戴红 李志明 主编,2019年7月30日星期二,2,9.1 SQL Server的安全性机制 9.2 SQL Server的登录模式 9.3 SQL Server用户标识和鉴别 9.4 角色与权限 9.5 数据库的并发控制,第9章 SQL Server的安全性管理,2019年7月30日星期二,3,9.1 SQL Server的安全性机制,SQL Server数据库系统的安全机制 SQL Server的安全机制可划分为三个层次 数据库管理系统级安全性 控制用户登录到数据库管理系统的安全机制。 数据库级安全性 用户通过认证后，还需具备访问许可（Permission）权限才能够访问SQL Server 中的数据 权限设置通过用户账号来实现以及使用角色代替用户组来简化安全性管理 数据库对象级安全性 在权限范围内对服务器上的数据库进行各种操作的权限 主要是针对数据库对象，如表、视图、存储过程和自定义函数等。,2019年7月30日星期二,4,数据库管理系统级安全性控制SQL Server 的登录认证 SQL Server支持两种认证方式 Windows认证模式 混合认证模式,9.2 SQL Server的登录模式,2019年7月30日星期二,5,以Windows NT或2000的安全性来确定用户登录的账号是否正确 利用NT或2000本身具有的管理登录、验证用户合法性的能力 允许SQL Server使用NT或2000的用户名和口令登录验证用户的合法性 系统管理员将安全认证模式设为Windows认证模式，以授权给可访问NT或2000的合法用户，而直接成为SQL Server的合法登录用户 连接SQL Server时不需在输入账号和密码 在安装SQL Server后，系统中预设了三个账户，分别为 BUILTINAdministrators 网络名Administrator sa,表示在NT或2000中只要属于Administrators组的账号都允许登录SQL Server,网络域名Administrator表示所属网络域中的Administrator账号才能登录SQL Server,Windows认证模式,2019年7月30日星期二,6,混合认证模式 由SQL Server自身来执行验证工作 Windows认证和SQL Server 认证两种认证模式都可用 SQL Server 认证模式 SQL Server 自己执行认证处理 用户在连接SQL Server 时必须提供登录名和密码 登录信息存储在系统表syslogins中 若输入的登录信息与系统表syslogins 中的某条记录相匹配则表明登录成功,2019年7月30日星期二,7,注意下列三种情况 若用户在登录SQL Server时未给出用户登录名，则SQL Server会自动使用 Windows认证模式 若SQL Server被设置为Windows认证模式，则用户在登录时输入的具体登录 名会被SQL Server忽略 若SQL Server运行在Windows 95/98桌面版上时，则Windows认证模式无效,2019年7月30日星期二,8,通过SQL Server企业管理器进行认证模式的设置,2019年7月30日星期二,9,用企业管理器新建SQL Server 登录用户,2019年7月30日星期二,10,若选择为Windows身份验证，可单击“名称”文本框后的“”按钮，打开Windows用户组和用户列表,选择一个用户名，单击“添加”及“确定”按钮，回到“新建登录”对话框中,2019年7月30日星期二,11,注 选择Windows认证模式 在“名称” 处输入的账号必须是Windows已建的登录者或组 “名称”的格式为Windows网络名称用户名或Windows主机名用户名 选择Windows认证模式且使用了NT网络 在“域”中输入登录账号或组所属的域 若未使用NT网络，则在“域”中输入登录账号所属的NT主机名 选择Windows认证模式且登录账号是Windows NT或Windows 2000中的内建用户组，如：Administrators 必须在“域”中输入BUILTIN 而不是NT主机名或NT网络域名,2019年7月30日星期二,12,使用系统存储过程新建和管理SQL Server 登录,2019年7月30日星期二,13,续前表,2019年7月30日星期二,14,续前表,2019年7月30日星期二,15,续前表,2019年7月30日星期二,16,数据库级安全性 数据库用户 用来指出哪一个用户可以访问哪一个数据库 在一个数据库中，用户账号唯一标识一个用户 用户对数据的访问权限以及对数据库对象的所有关系都是通过用户账号来控制。 数据库中的用户账号与登录账号是两个不同的概念,9.3 SQL Server用户标识和鉴别,2019年7月30日星期二,17,guest用户,2019年7月30日星期二,18,利用SQL Server企业管理器创建新数据库用户,2019年7月30日星期二,19,在创建和维护SQL Server登录账号时，先将该登录账号映射为一个数据库用户,用户账号总是基于数据库的，故两个不同数据库中可以有两个相同的用户账号,2019年7月30日星期二,20,利用系统存储过程创建和管理新数据库用户,2019年7月30日星期二,21,续前表,2019年7月30日星期二,22,数据库对象级安全性-权限和角色 将登录账户映射为数据库用户账户后，该用户可以访问该数据 其访问数据库的权限取决于其所属的角色以及所授予的权限 权限 规定该用户能够对哪些数据库对象执行哪（些）种操作，以及能够访问和修改哪些数据 角色 管理员可将某些用户设置为某一角色，只对角色进行权限设置，便可实现对所有具有该角色的用户的权限的设置，减少了管理员的工作量 如 缺省情况下，一个新数据库用户的权限具有public 角色 public 是一个特殊的数据库角色，含在每个数据库中，包括 master、msdb、tempdb、model 和所有用户数据库 每个数据库用户都属于它，并且无法除去该角色 public 角色可以自动获取数据库用户的所有默认权限,9.4 角色与权限,2019年7月30日星期二,23,权限分类 对象权限和语句权限 对象权限 针对表、视图、存储过程 决定了能对表、视图、存储过程执行哪些操作，包括UPDATE、DELETE、INSERT、EXECUTE 语句权限 用户是否具有权限来执行某一语句 这些语句通常是一些具有管理性的操作，如创建数据库、表、存储过程等,2019年7月30日星期二,24,对象权限,语句权限,REFERENCES表示允许别的表的所有者引用本表的列作为外键约束,2019年7月30日星期二,25,利用企业管理器管理权限 面向单一用户的权限设置,2019年7月30日星期二,26,面向数据库对象的权限设置,2019年7月30日星期二,27,使用GRANT、REVOKE和DENY三种命令来管理权限 GRANT ：把权限授予某一用户，使该用户对该对象可以执行操作或运行某些语句 将语句权限授予用户 将对象权限授予用户,GRANT ALL | ,n TO ,n,GRANT ALL|,n (,) ON | | ON (,n) | ON | ON TO ,n WITH GRANT OPTION ,ALL表示授予该用户所有的对象权限,WITH GRANT OPTION 表示该权限的被授予者可以向其它用户授予这些权限,2019年7月30日星期二,28,REVOKE：取消用户对某一对象或语句的权限（经过GRANT 语句授予的），不允许该用户执行针对数据库对象的某些操作或不允许其运行某些语句 DENY ：禁止用户对某一对象或语句的权限，明确禁止其对某一对象执行某些操作或运行某些语句 REVOKE 和 DENY 语法格式与GRANT 语法格式相同,2019年7月30日星期二,29,例：使用GRANT命令将表对象权限授予用户 -将对于职员表的查询、增删改的操作权限授予用户FirstDBUser GRANT SELECT,INSERT,UPDATE,DELETE ON 职员表 TO FirstDBUser 执行效果,2019年7月30日星期二,30,例：使用GRANT命令将列权限授予用户 -将查询办公室表和修改Address列的权限授予用户FirstDBUser GRANT SELECT,UPDATE(Address) ON 办公室 TO FirstDBUser,2019年7月30日星期二,31,执行效果,2019年7月30日星期二,32,用角色统一授予和管理权限 服务器角色,2019年7月30日星期二,33,使用企业管理器添加成员到固定服务器角色中 查看服务器角色权限,sysadmin角色的所有权限,2019年7月30日星期二,34,使用存储过程管理服务器角色的成员,2019年7月30日星期二,35,数据库角色 固定数据库角色 SQL Server预定义的、具有所有管理和访问数据库的权限 SQL Server管理者不能对其所具有的权限进行任何修改 SQL Server中的每一个数据库中都有一组固定数据库角色 数据库角色,2019年7月30日星期二,36,2019年7月30日星期二,37,使用企业管理器添加成员到固定数据库角色中 注：此时添加到数据库角色中的是数据库用户,2019年7月30日星期二,38,使用SQL Server 企业管理器创建数据库角色,注：“权限”按钮处于禁用状态，只有重新进入”新建角色”对话框该按钮才可用。当新建数据库角色创建成功，可以通过以上步骤重新进入，此时“权限”为可用状态，单击按钮弹出“数据库角色属性”对话框，进行角色权限设置。,2019年7月30日星期二,39,管理数据库角色所使用的系统存储过程,2019年7月30日星期二,40,续前表,2019年7月30日星期二,41,Public数据库角色 一个特殊的数据库角色 数据库中的每个用户都属于 public 数据库角色,2019年7月30日星期二,42,SQL Server 安全控制的其他手段 使用视图为用户提供局部数据 -列级安全控制视图 CREATE VIEW 教师基本信息_Stu AS SELECT 教师编号,姓名,性别,职称,电子邮件 FROM 教师基本信息 -行级安全控制视图，只包含01班的成绩信息 CREATE VIEW 成绩单_SpeClass AS SELECT S.姓名,C.课程名,SC.成绩 FROM 学生成绩 AS SC JOIN 学生基本信息 AS S ON(S.学号 = SC.学号) JOIN 课程基本信息 AS C ON(SC.课程号=C.课程号) WHERE left(S.学号,2)=01 -班号为学号的前2个字符 -使用视图屏蔽其他班学生成绩,2019年7月30日星期二,43,视图与权限结合 将访问视图的权限授予给用户,使该用户不具有访问视图所引用的基本表的权限,但其仍可以从中查看相应的数据信息 用户对表的整体结构不需要了解，只需要建立一个视图将该用户在该表中可以访问的列包含其内，并将SELECT查询权限授予该用户，则该用户可使用SELECT查询视图而获取他要/可获取的信息,2019年7月30日星期二,44,使用存储过程作为安全机制 例如：创建一个存储过程，包含查询“成绩单_SpeClass”的语句 -存储过程与视图的结合 CREATE PROCEDURE成绩单_SpeClass_SP AS SELECT * FROM 成绩单_SpeClass 将存储过程的EXEC权限授予用户 GRANT EXEC ON 成绩单_SpeClass TO FirstDBUser,2019年7月30日星期二,45,实现步骤 以FirstUser身份登录连接SQL Server，执行视图“成绩单_SpeClass”的查询语句，系统报告其无SELECT视图的权限 重新以sa或Windows的Administrator身份登录连接SQL Server，建立视图“成绩单_SpeClass”、存储过程“成绩单_SpeClass_Sp”及将存储过程的权限授予用户FirstDBUser 再以FirstUser身份登录连接SQL Server，执行存储过程“成绩单_SpeClass_Sp”，得到视图的查询结果,2019年7月30日星期二,46,并发控制概述 数据库中的数据因其具备共享性而可以为多个用户或程序（事务）同时使用 可以被多个用户或程序使用的数据库称为多用户数据库 日常生活中例子 银行数据库系统 飞机订票数据库系统 若这多个事务一个个顺序执行，即在一个事务执行完成后，再执行下一个事务，称为串行操作 串行操作最大的问题是效率低 在单处理机系统中，事务轮流占用处理机来交叉运行，对于用户感觉上是同时在处理多个事务，从而部分地实现了并行操作 而在多处理机的系统中，每个事务可运行在不同的处理机上，能够做到真正地“并行”运行多个事务 目前多个事务在单处理机上交叉并行运行为最普遍的方式 在多个事务并发地对数据库中的同一个数据进行操作的过程中，若对并发操作不做任何控制，则会产生多种不一致问题,9.5 数据库的并发控制,2019年7月30日星期二,47,例:并发操作中的不一致问题,2019年7月30日星期二,48,并发操作的不一致性(3种) 丢失更新（Lost Update） 甲、乙两个事务读取同一个数据并进行更新，事务乙的更新结果破坏了事务甲的更新结果。(上例) 污读（Dirty Read） 事务甲更新了数据D，事务乙读了事务甲更新后的数据D，事物甲因为某种原因而被撤消，事务回滚修改无效，数据D恢复原值，但事务乙并不知道，所以其得到的数据与数据库中实际数据内容不一致，即事务乙读了“脏”数据。 不能重读（Unrepeatable Read） 事务甲读取数据D，接着事务乙也读取数据D，并更新了数据D，事务甲再次读取数据D以进行校验，但得到的结果不同于其第一次读取的结果，即两次读取值不一致。,2019年7月30日星期二,49,污读,2019年7月30日星期二,50,不能重读,2019年7月30日星期二,51,不一致问题产生的原因 因为并发操作使事务之间的隔离性遭到破坏 事务在执行过程中受到其他事务的干扰，不能独占数据 并发控制的目的 在一定的并发程度的前提下，合理调度并发事务，避免并发事务之间相互干扰造成数据的不一致性 并发控制的主要方法 封锁（Locking）,2019年7月30日星期二,52,封锁（Locking） 基本思想 甲事务要修改数据D，在修改前必须锁定D，使其他事务不能读取或修改D，直到甲事务修改完并写回数据，再解除封锁后方可访问数据D。这样就避免了丢失甲的修改。 基本封锁类型 排它性封锁（称X封锁） 如果事务T建立对某个数据目标的排它性封锁，则只有事务T能对该数据读取或修改，其他任何事物均不能对该数据目标进行读取或修改。 共享性封锁（称S封锁） 又称保护性封锁，事务T对数据目标建立了共享性封锁，则事务T和其他事务均可对该数据目标读取，但其他事务不得对数据目标进行更新。,2019年7月30日星期二,53,共享性封锁和排它性封锁的相互作用可以用相容矩阵来表示,2019年7月30日星期二,54,运用这两种封锁可以建立以下封锁协议 PX协议 任何事务T要对数据目标D进行修改，必须对D进行X封锁，然后读取并进行修改，如果不能得到这种封锁，必须等待直到取得封锁权才能对D进行操作。 此协议可以防止更新丢失。 PXC协议 在PX协议基础上，进一步规定建立X封锁的事务T要保留封锁权直到事务T完全结束为止。可以防更新丢失，还可以防止因事务T的撤消而造成污读数据。 PS协议 事务T要读取数据D必须对D实现S封锁，然后读取D，如果进一步企图更新D时，S封锁升级为X封锁。可以防止更新丢失，又可以提高并发程度。 PSC协议 在PS协议基础上，进一步规定建立S封锁的事务T要保留封锁直到事务T完全结束为止。可以防止事务T对数据D有两次以上读取时出现数据不一致，同时又比PXC协议有较高的并发程度。,2019年7月30日星期二,55,封锁的粒度（Granularity ） 封锁的数据的目标的大小叫封锁的粒度，大到可以为整个数据文件或整个数据库，小到可以是单条记录或字段值。 封锁粒度愈细则并发程度愈高，但因封锁数目多而造成开销越大 封锁粒度愈粗则并发程度愈差，但因封锁数目少而进行的封锁检查少，则开销越小 确定封锁粒度和封锁时间的原则 安全的封锁应做到 比最小的数据请求具有较多的数据单元 安全的保持应做到 比最短请求时间具有较长时间的封锁,2019年7月30日星期二,56,死锁及消除方法 死锁：并发操作中的一种状态，即在多个事务并发执行的过程中，其中两个或多个并行的事务同时处于等待状态，其中每一个都在等待其他的事务释放封锁的状态。,2019年7月30日星期二,57,死锁是可以避免的 但因为代价太大，所以一般系统允许发生死锁 只是在可能出现死锁的情况下，发现并消除死锁。 诊断死锁是否发生的一般方法 建立等待图 利用超时机制来检测死锁状态,2019年7月30日星期二,58,建立等待图 检查该图的有向边是否形成环路 一个典型的等待图如图所示，结点表示正在执行的事务，有向边表示等待 当事务Ti要加锁数据目标，而该目标已被Tj封锁，就从Ti到Tj画一条有向边 当Tj释放封锁，就删除这条边 显然图中显示的状态从T1到T1形成了一个环路，此时说明发生死锁 利用超时机制来检测死锁状态 检测死锁状态的时机 可以是当一个封锁请求造成等待时，检查是否发生死锁 也可以用周期的形式来检查死锁，但某些死锁发现较晚 也可以不进行死锁检查，系统可以利用超时机制，简单假定如果一事务在超过给定的时间间隔后还要等待，这个事务就被认定是进入死锁状态,2019年7月30日星期二,59,解除死锁 最常用方法 选择一个“牺牲品” 回滚 “牺牲品”是 死锁事务之一 造成死锁的