第六讲 安全性

6.1安全性概述

安全性
数据库安全性是指保护数据库,防止因用户非法使用数据库造成数据泄露、更改或破坏

数据库安全性保护分层:

  • 物理层:计算机所在的节点必须物理上受到保护
  • 人际层
  • 网络层
  • 操作系统层
  • 数据库系统层

数据库安全保护的任务

  • 防止未经过授权的人员访问数据,确保敏感信息没有被不“需要知道”的人员读取
  • 防止未经过授权的人员删除和修改数据
  • 见式对数据的访问和更改等使用情况

6.2用户标识与鉴别

用户标识与鉴别是系统提供的最外层的安全保护措施,其基本方法是:系统提供一定的方式让用户标识自己的名字或身份;系统内部记录着所有合法用户的标识;每次用户要求进入系统(与数据库连接)时,由系统核对用户提供的身份标识;通过鉴别的合法用户才能进入系统,建立数据库连接

口令
对于一个口令来说,口令越长,破解的可能性就越小,就越安全,而口令越长约不方便用户记忆,在安全性和方便性之间折中一下,一般要求口令不能少于6位,口令复杂度是口令安全性的一个重要因素,用户为了方便记忆,一般喜欢使用容易记忆的数字,单词或者自己的用户名作为自己的口令,这种口令十分脆弱,如果进行暴力猜测攻击很快就可以破解,所以安全口令的要求一般如下:口令不能全部是数字;口令不能包含用户名;口令不能包含字典中的单词;口令最好是数字、字母一积特殊符号组合。口令使用时间越长越危险,所以需要设定口令使用时限。

更新方式的用户标识与鉴别

  • 使用动态产生的新口令登陆数据库管理系统,比如短信密码或者动态令牌方式
  • 利用只有用户具有的物品鉴别用户:可以使用磁卡、IC卡等作为用户身份的凭证,但必须有相应的读卡设备。例如,银行广泛使用磁卡+密码鉴别储户身份,允许合法的储户访问储蓄信息
  • 利用用户的个人特征鉴别用户:指纹、视网膜等

6.3自主存取权限

自主存取控制主要内容:

  • 存取控制的任务
  • 数据对象和存取权限
  • 权限的授予和回收
  • 角色

存取控制的任务
授权:DCL中提供了相应的授权语句,允许用户自主地定义存取权限,并将用户的授权登记再数据字典中。
合法权限检查:当用户发出存取数据库的操作请求后,DBMS将查找数据字典,根据用户权限进行合法权限的检查;如果用户的操作请求超出了自身的权限,西永将拒绝执行此操作

数据对象和存取权限
存取控制的数据对象及对象上的操作类型
权限的授予和回收
授权语句GRANT,语句格式:GRANT<权限列表>ON<对象名>TO<用户/角色列表>[WITH GRANT OPTION]
将一种或多种存取权限赋予一个或多个用户或角色
可选项WITH GRANT OPTION,表示获得权限的用户还可以吧他获得的权限转授给其他用户;缺省时,获得权限的用户不能传播权限

//把查询Students表权限授予所有用户∶
	GRANT SELECT ON Students TO PUBLIC;
//将对Students和Courses表的所有权限授予用户U1和U2∶
	GRANT ALLPRIVILIGES ON Students, Courses TO U1,U2;
//如果允许U1和U2转授权限,可以加可选项︰
	GRANT ALL PRIVILIGES ON Students, Courses TO U1,U2WITH GRANT OPTION;
//把对表SC的插入元组权限和修改成绩(Grade )的权限授予用户U3:
	GRANT INSERT,UPDATE (Grade) ON SC TO U3;

回收授权
收回授权使用REVOKE语句,其语句的常用形式如下:

REVOKE <权限列表> ON <对象名> FROM <用户/角色列表>
{CASCADE | RESTRICT}

假设在Students上的UPDATE授权传播如图所示
Students上的UPDATE授权

REVOKE UPDATE ON Students FROM U2 RESTRICT;
REVOKE UPDATE ON Students FROM U2 CASCADE;

注意:U1授予U4的Students上的UPDATE权限并未收回

角色

  • SQL-99支持角色
  • 使用角色进行授权必须先创建角色,将数据库对象上的存取权限授予角色,才能将角色授予用户,使得用户拥有角色所具有的所有存取权限
  • SQL-99允许收回赋予角色的存取权,收回授予用户的角色
  • 创建角色使用如下形式的语句:CREATE ROLE <角色名>
CREATE ROLE Teller; //创建一个名为Teller的角色
GRANT ALL PRIVILIGES
ON Account, Loan, Depositor, Borrower TO Teller;
//将表Account, Loan, Depositor和Borrower上的所有存取权授予角色Teller

使用角色授权
使用如下语句将一个或多个角色授予一个或多个用户/角色:GRANT <角色列表> TO <用户/角色列表> [WITH ADMIN OPTION]

  • 其中<角色列表>是一个或多个角色名,中间用逗号隔开;
  • <用户/角色列表>是一个或多个用户名或角色名,中间用逗号隔开
  • 可选项WITH ADMIN OPTION允许获得角色授权的用户转授角色权限;缺省时不能转授
	CREATE ROLE Manager; //创建一个名为Manager的角色
	GRANT Teller TO LiMing, ZhangHua, Manager
//将角色Teller授予用户LiMing、ZhangHua和角色Manager
	GRANT ALL PRIVILIGES ON Branch TO Manager
//将关系Branch上的所有权限授予角色Manager
//若WangWanli是经理,可使用如下语句将角色Manager授予WangWanli,并允许他将Manager角色转授予其他人:
	GRANT Manager TO WangWanli WITH ADMIN OPTION;

收回角色的权限
使用REVOKE语句可以回收授予角色的授权
下面语句可以收回角色Teller在关系Loan和Borrower上的所有存取权:REVOKE ALL PRIVILIGES ON Loan, Borrower FROM Teller;
该语句执行后,所有具有角色Teller的用户(LiMing和ZhangHua)都不能再对关系Loan和Borrower进行任何操作

//收回角色
//REVOKE语句还可以从一个或多个用户或角色收回角色:
	REVOKE <角色列表> FROM <用户/角色列表>{CASCADE | RESTRICT}
//如果LiMing不再担任出纳,则可以用如下语句收回他的Teller角色:
	REVOKE Teller FROM LiMing CASCADE;

6.4强制存取控制

自主存取控制存在的问题
例如:用户A将自己权限内的数据存取权转授给用户B,本来只是允许用户B本人操纵这些数据。但是,用户B复制了这些数据,并在未征得用户A的同意情况下传播副本给用户C,这就可能导致数据不安全

  • 在自主存取控制中,系统只是根据用户对数据库对象的存取权限
    来进行安全控制,而没有考虑数据库对象本身的安全等级
  • 自主存取控制不能阻止副本的非授权传播

强制存取控制
强制存取控制(Mandatory Access Control,简称MAC)是系统为保证更高程度的安全性所采取的强制存取检查手段
MAC是用户不能直接感知或进行控制的,适用于对数据有严格而固定密级分类的部门,如军事部门、政府部门等

主体与客体
在MAC 中,DBMS 所管理的全部实体被分为主体和客体两大类:

  • 主体是系统中的活动实体,可以是DBMS管理的实际用户或代表用户的各个进程
  • 客体是系统中的被动实体,是受主体操纵的对象。如文件、基本表、索引、视图等

敏感度标记
对于主体和客体,DBMS为它们的每个实例值指派一个敏感度标记(Label),敏感度标记分成若干级别

  • 绝密(Top Secret)、 机密(Secret)、 秘密(Confidential)、公开(Public)
  • 主体的敏感度标记称为许可证级别(Clearance Level)
  • 客体的敏感度标记称为密级(Classification Level)
  • MAC机制就是通过对比主体和客体的敏感度标记,确定主体是否能够存取客体

强制存取控制规则
当某一用户(或某一主体)注册进入系统时,系统要求他对任何客体的存取必须遵循下面两条规则:
(1) 仅当主体的许可证级别大于或等于客体的密级时,该主体才能
读取相应的客体
(2) 仅当主体的许可证级别小于或等于客体的密级时,该主体才能
写相应的客体
MAC与DAC
MAC比DAC具有更高的保护级别,因此支持MAC的系统必须支持DAC,由DAC与MAC共同构成了DBMS的安全机制
同时提供DAC和MAC保护的系统称为多级安全系统
在多级安全系统中,系统首先进行DAC检查,对通过DAC检查的允许存取的数据对象,再由系统自动进行MAC检查,只有通
过MAC检查的访问才是允许的

6.5视图与授权

基于视图的授权
视图可以隐蔽一些不希望用户看到的数据

  • 可以与授权结合,限制用户只能访问所需要的数据,实现一定程度的安全保护

利用视图实现安全保护的基本思想是:

  • 先通过定义视图,屏蔽掉一部分需要对某些用户保密的数据
  • 然后,在视图上定义存取权限,将对视图的访问权授予这些用户而不允许他们直接访问定义视图的基本表

需要说明的是:

  • 创建视图的用户不一定能够获得该视图上的所有权限
  • 为了有效地阻止用户透过视图越权访问数据库,创建视图的用户在视图上所获得的权限不能超过他在定义视图的基本表上所拥有的权限

例如,假设用户U对基本表T1拥有修改权(UPDATE),对基本表T2拥有读取数据权(SELECT),若用户U基于T1和T2创建了一个视图V,则用户U只能查询(SELECT)该视图

//假设WuDP信工院的教务员。只允许她对信工院学生的选课表SC进行访问,我们可以定义一个视图IE_SC,它仅包含信工院学生的选课纪录:
//1. 定义视图 : 
	CREATE VIEW IE_SC AS
	SELECT Sno, Cno, Grade
	FROM SC
	WHERE Sno IN
		( SELECT Sno
		FROM Students WHERE Dno=‘IE’ );
//2. 授权: 
	GRANT ALL PRIVILIGES ON IE_SC TO WuDP;

6.6其他安全手段

审计
审计启用一个专门的审计日志(Audit Log),自动记录所
有用户对数据库的更新操作(插入、删除和修改)。审计日
志记录如下信息:

  • 操作类型
  • 操作终端标识与操作者标识
  • 操作日期和时间
  • 操作涉及的数据
  • 数据的旧值和新值

数据加密
数据加密的基本思想:按照一定的加密算法,将原始数据(明文)变换成不可直接识别的格式(密文),使得不知道解密方法的人即使获得数据,也不知道数据的真实内容,从而达到保护数据的目的
合法用户使用数据时,可以使用解密算法还原数据
加密算法
一个好的加密技术应该具有下面的性质:

  • 对授权用户来说,加密数据和解密数据相对简单
  • 加密模式不应依赖于算法的保密,而是依赖于算法参数,即依赖于密钥
  • 对入侵者来说,确定密钥是极其困难的

数据加密
目前商品化的DBMS产品都提供了数据加密例行程序,根据用户要求自动对存储和传输的数据进行加密处理。即使没有提供这种加密程序的DBMS,也都会提供加密接口,以方便用户使用其他厂商提供的加密程序对数据进行加密
数据的加密和解密是比较费时的,并且占用大量的系统资源,因此一般只对高度机密的数据进行数据加密

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值