文章目录
第四章——数据库的安全性
先上图!!
数据库安全性控制
计算机系统中安全措施是一级一级层层设置的
身份鉴别(☆)
当用户使用SQL SERVER时,需要经过两个安全性阶段,身份验证和权限认证阶段
- 身份验证阶段: 用户在SQL SERVER上获得任何数据库访问权限之前,必须首先登录到SQL SERVER并且是合法的,否则服务器将拒绝用户登录
- 权限验证阶段: 身份验证阶段只能验证用户是否具有连接到SQL SERVER的权限,通过身份验证后,需要验证用户是否具有访问服务器数据的权限,为此需要为每个数据库建立用户,并将账户映射到登录账户,并为用户分配对象的访问权限
创建登录名
[例1] 创建一个sql server验证模式的登录名
create login Zhangsan
with password='123456'
[例2] 创建一个windows验证模式的登录名
create login [win2k3\Administrator]
from windows
同一个数据库可以拥有多个用户,同一个用户也可以同时访问多个数据库
[例3] 创建具有默认架构的数据库用户
create user dbUserl for login zhangsan
with default_schema=student;
存取控制
目的:
确保只授权给有资格用户访问数据库的权限
组成:
- 定义用户权限
- 合法权限检查
两类方法:
- 自主存取控制
- 强制存取控制
自主存取控制方法
缺点:
可能存在数据的“无意泄露”
原因:
这种机制仅仅通过对数据的存取权限来进行安全控制,而数据本身并无安全性标记
解决:
对系统控制下的所有主客体实施强制存取控制策略
用户权限的组成
- 数据库对象
- 操作类型
授权与收回(☆)
grant
将指定操作对象的指定操作权限授予指定的用户
GRANT语句的一般格式:
GRANT <权限>[,<权限>]…
ON <对象类型> <对象名>[,<对象类型> <对象名>]…
TO <用户>[,<用户>]…
[WITH GRANT OPTION];
指定WITH GRANT OPTION子句,则获得某种权限的用户还可以把这种权限再授予其他用户
发出grant:
- 数据库管理员
- 数据库对象创建者
- 拥有该权限的用户
[例4.1] 把查询 Student 表权限授给用户 U1
grant select
on student
to u1;
[例4.2] 把对Student表和Course表的全部权限授予用户U2和U3
grant all privileges
on student,course
to u2,u3;
[例4.3] 把对表SC的查询权限授予所有用户
grant select
on sc
to public
[例4.4] 把查询Student表和修改学生学号的权限授给用户U4
grant update(sno),select
on student
to u4;
对属性列的授权是必须明确指出响应属性列名
[例4.5] 把对表SC的INSERT权限授予U5用户,并允许他再将此权限授予其他用户
grant insert
on sc
to u5
with grant option;
执行例4.5后,U5不仅拥有了对表SC的 INSERT 权限, 还可以传播此权限:
[例4.6]
GRANT INSERT
ON SC
TO U6
WITH GRANT OPTION;
同样,U6还可以将此权限授予U7:
[例4.7]
GRANT INSERT
ON SC
TO U7;
但U7不能再传播此权限。
revoke收回
授予的权限可以由数据库管理员或其他授权者用 REVOKE 语句收回
REVOKE语句的一般格式为:
REVOKE <权限>[,<权限>]…
ON <对象类型> <对象名>[,<对象类型><对象名>]…
FROM <用户>[,<用户>]…[CASCADE | RESTRICT];
[例4.8] 把用户U4修改学生学号的权限收回
revoke update(sno)
on student
from u4;
[例4.9] 收回所有用户对表SC的查询权限
revoke select
on sc
from public;
[例4.10] 把用户U5对SC表的INSERT权限收回
revoke insert
on sc
from u5 cascade;
--将用户U5的INSERT权限收回的时候应该使用CASCADE,否则拒绝执行该语句
--如果U6或U7还从其他用户处获得对SC表的INSERT权限,则他们仍具有此权限,系统只收回直接或间接从U5处获得的权限
3.创建数据库模式的权限
数据库管理员在创建用户时实现
CREATE USER语句格式
CREATE USER <username>
[WITH][DBA|RESOURCE|CONNECT];
注:CREATE USER不是SQL标准,各个系统的实现相差甚远
数据库角色(☆)
被命名的一组与数据库操作相关的权限
- 角色是权限的集合
- 可以为一组具有相同权限的用户创建一个而角色
- 简化授权的过程
角色的创建
-
创建
CREATE ROLE <角色名> -
给角色授权
GRANT <权限>[,<权限>]…
ON <对象类型>对象名
TO <角色>[,<角色>]… -
将一个角色授予其他的角色或用户
GRANT <角色1>[,<角色2>]…
TO <角色3>[,<用户1>]…
[WITH ADMIN OPTION]
- 该语句把角色授予某用户,或授予另一个角色
- 授予者是角色的创建者或拥有在这个角色上的ADMIN OPTION
- 指定了WITH ADMIN OPTION则获得某种权限的角色或用户还可以把这种权限授予其他角色
一个角色的权限:直接授予这个角色的全部权限加上其他角色授予这个角色的全部权限
- 角色权限的收回
REVOKE <权限>[,<权限>]…
ON <对象类型> <对象名>
FROM <角色>[,<角色>]…
- 用户可以回收角色的权限,从而修改角色拥有的权限
- REVOKE执行者是
角色的创建者
拥有在这个(些)角色上的ADMIN OPTION
[例4.11] 通过角色来实现将一组权限授予一个用户。
--首先创建一个角色
create role r1;
--给r1授予这些权限
grant select,update,insert
on student
to r1;
--将这个角色授权给u1,u2,u3;使他们具有角色r1所具有的的全部权限
grant r1
to u1,u2,u3;
--可以一次性通过r1来回收u1的这三个权限
revoke r1
fron u1;
[例4.12] 角色的权限修改
grant delete
on student
to r1;
--在r1原来的基础上增加了delete权限
强制存取控制方法
- 保证更高程度的安全性
- 用户不能直接感知或进行控制
- 适用于对数据有严格而固定密级分类的部门
在强制存取控制中,数据库管理系统所管理的全部实体被分为主体和客体两大类
- 主体是系统中的活动实体:
数据库管理系统所管理的实际用户
代表用户的各进程 - 客体是系统中的被动实体,受主体操纵:
文件、基本表、索引、视图
敏感度标记(Label)
- 对于主体和客体,DBMS为它们每个实例(值)指派一个敏感度标记
- 敏感度标记分成若干级别
绝密(Top Secret,TS)
机密(Secret,S)
可信(Confidential,C)
公开(Public,P)
TS>=S>=C>=P - 主体的敏感度标记称为许可证级别
- 客体的敏感度标记称为密级
强制存取控制规则
(1)仅当主体的许可证级别大于或等于客体的密级时,该主体才能读取相应的客体
(2)仅当主体的许可证级别小于或等于客体的密级时,该主体才能写相应的客体
自主存取控制与强制存取控制共同构成数据库管理系统的安全机制
先进行自主存取控制检查,通过自主存取控制检查的数据对象再由系统进行强制存取控制检查,只有通过强制存取控制检查的数据对象方可存取。
视图机制(☆)
视图机制把要保密的数据对无权存取这些数据的用户隐藏起来,对数据提供一定程度的安全保护
- 视图机制更主要的功能在于提供数据独立性,其安全保护功能太不精细,往往远不能达到应用系统的要求。
- 间接实现了支持存取谓词的用户权限定义
[例4.14] 建立计算机系学生的视图,把对该视图的SELECT权限授于王平,把该视图上的所有操作权限授于张明。
--先建立计算机系学生的视图cs
create view cs
as
select *
from student
where sdept='CS';
--授权
grant select
on cs
to 王平;
grant all priviliges
on cs
to 张明;
审计(☆)
审计日志:
将用户对数据库的所有操作记录在上面;
DBA利用审计日志找出非法存取数据的人、时间和内容
数据加密
防止数据库中的数据在存储过程中和传输中失密的有效手段
机密的方法:
- 替换方法
- 置换方法
- 混合方法