数据库课堂笔记5-数据库安全
本文根据UETSC数据库课程整理而成
计算机安全$数据库安全
- 数据库的一大特点：数据共享，但数据共享必然带来数据库的安全性问题；
- 数据库系统中的数据共享是在DBMS统一的严格的控制之下的共享，即只允许有合法使用权限的用户访问允许他存取的数据；
- 数据库系统的安全保护措施是否有效是数据库系统主要的性能指标之一；
- 数据库的安全性和计算机系统的安全是紧密联系、互相支持的；
数据库安全
保护数据库，防止因用户非法使用数据库造成数据泄露、更改或破坏
数据库保密
数据保密是指用户合法地访问到机密数据后能否对这些数据保证不泄密。
通过制订法律道德准则和政策法规来保证。
计算机安全
保护计算机系统中的硬件、软件及数据，防止其因偶然或恶意的原因使系统遭到破坏，数据遭到更改或泄露等。
立体防御：进不来、看不见、搞不掉、跑不了
自主访问控制（DAC)
- 对用户访问数据库中各种资源（包括表、视图、程序等）的权利（包括创建、查询、更新、执行等）的控制；
- C2级， 灵活
- 权限是指允许某个用户以某种方式访问一些数据对象；
- 同一用户对于不同的数据对象有不同的存取权限，不同的用户对同一对象也有不同的权限，用户还可将其拥有的存取权限转授给其他用户。
具有CONNECT特权的用户可以与数据库连接，能根据授权进行数据库中数据的查询、更新，能创建视图。
具有RESOURCE特权的用户除具有CONNECT特权外，还能创建表、索引，修改表结构，能将自己创建的数据对象的访问权授予其他用户或从其他用户那儿收回，对自己创建的数据对象能进行跟踪审查。
具有DBA特权的用户能进行所有的数据库操作。
操作授权
授权就是赋予用户一定的操作数据对象的权利。
授权可以由DBA授予，也可以由数据对象的创建者授予
GRANT {all privileges|privilege{. privilege….}}
ON [TABLE] tablename|viewname
TO [PUBLIC|user_name{,user_name…}]
[WITH GRANT OPTION]
ALL PRIVILEGES是所有权限的总称
数据对象可以是基本表，也可以是视图
用户名可以代表单一用户也可以代表一组用户，当代表一组用户时我们称为角色。PUBLIC是所有数据库用户的总称；
WITH GRANT OPTION，受权者可以将此权限转授给其他用户；
一个用户如果是表的创建者，他就自动拥有了对所创建表的所有权利以及将该表权利授予其他用户的权利，而且不能取消。
授权实例
假定用户WangPing创建了表RecipeDetail, Medicine, RecipeMaster,并且WangPing执行如下授权命令。
GRANT SELECT ON RecipeDetail TO LiXia；
GRANT SELECT ON RecipeMaster TO LiXia WITH GRANT OPTION；
GRANT UPDATE（Mprice） ON Medicine TO WangHao；
GRANT REFERENCE（Mno）ON Medicine TO ZhangYang；
GRANT INSERT，DELETE ON RecipeDetail TO MengFan WITH GRANT OPTION；
LiXia能够对RecipeDetail和RecipeMaster执行查询语句，并能将RecipeMaster的查询权限授予DengTian：
GRANT SELECT ON RecipeMaster TO DengTian；
WangHao只能修改Medicine表中的Mprice列的值。
视图授权
- 对视图也应可以授权。
- 要授予其他用户与访问视图相关的权利，授权者必须拥有该视图（而且在视图所引用基本表或视图上有必要的权限）或已经通过WITH GRANT OPTION被授予了这些权限。
- 若要在一个视图上授予插入、删除或更新权限，视图必须是可更新的。
用户要建立视图，首先必须要有对所引用基本表或视图的SELECT权利。 - 一个用户如果是视图的创建者，并不意味着他对视图拥有所有的权力。他对视图建立过程中所引用的基本表或视图所拥有的权限就是他对视图所拥有的权限
视图授权示例：假定医院的一位员工Jian希望能看到患者到科室看病的信息，但他不具有查阅医生处方的权限，即他没有对RecipeMaster表的授权。
(1)CREATE VIEW Recipe-Doctor AS
(SELECT Pname,Ddeptno
FROM RecipeMaster,patient,doctor
WHERE patient.Pno= RecipeMaster.Pno AND
RecipeMaster.Dno=doctor.Dno);
(2)GRANT SELECT ON Recipe-Doctor TO Jian;
(3)Jian可以执行如下查询语句：
SELECT * FROM Recipe-Doctor
- 创建视图要成功，创建者首先必须要拥有对RecipeMaster、patient、doctor的SELECT权限，否则，视图的创建请求将被拒绝。
- 若视图创建者的SELECT权限被回收，则视图被删除。
- 若视图创建者获得了新的基本表的权限，则他对所创建的视图自动获得新的权限。
角色授权
创建角色
CRETAE ROLE Admin;
对角色授权：同用户授权一样
GRANT SELECT ON RecipeMaster TO Admin;
GRANT Admin TO LiXia;
CREATE ROLE Manager;
GRANT Admin to Manager;
GRANT Manager TO WangHao;
收回权限
收回权限格式
REVOKE [WITH GRANT OPTION FOR]{ALL PRIVILEGES|privilege{. Privilege….}}
ON [TABLE] tablename|viewname
FROM [PUBLIC|user_name{,user_name…}]
[RESTRICT|CASCADE]
示例：若WangPing在授权后，发现用户的权限分配不恰当，就可以执行如下命令收回部分用户的操作权限：
REVOKE SELECT ON RecipeDetail FROM LiXia；
REVOKE UPDATE（Mprice）ON Medicine FROM WangHao；
REVOKE GRANT OPTION FOR SELECT ON RecipeMaster FROM LiXia；
RESTRICT与CASCADE
从一个用户那里收回权限可能导致其他用户也失去该权限。这一行为称为级联回收CASCADE。在大多数数据库系统中，级联回收是默认行为 。
可以指定RESTRICT方式：REVOKE SELECT ON RecipeMaster FROM LiXia RESTRICT；
强制访问控制（MAC)
- 强制访问控制（MAC）的特征
对所有主体（系统中的活动实体，如用户）及其所控制的客体（如进程、文件、基表、视图等）实施强制访问控制
B1级，严格
每一个数据对象被标以一定的密级，每一个用户也被授予某一个级别的许可证，对于任意一个对象，只有具有合法许可证的用户才可以存取 - 在MAC中，DBMS所管理的全部实体被分为主体和客体两大类
主体是系统中的活动实体
DBMS所管理的实际用户
代表用户的各进程
客体是系统中的被动实体，是受主体操纵的
文件， 基表， 索引， 视图 - 敏感度标记（Label）
对于主体和客体，DBMS为它们每个实例（值）指派一个敏感度标记；
敏感度标记级别：绝密，机密， 可信，公开；
主体的敏感度标记称为许可证级别，客体的敏感度标记称为密级；
MAC机制就是通过对比主体的Label和客体的Label，最终确定主体是否能够存取客体。 - 强制存取控制规则
仅当主体的许可证级别大于或等于客体的密级时，该主体才能读取相应的客体。
仅当主体的许可证级别小于或等于客体的密级时，该主体才能写相应的客体。
DAC与MAC关系
- DAC与MAC共同构成DBMS的安全机制
- 先进行DAC检查，通过DAC检查的数据对象再由系统进行MAC检查
- 只有通过MAC检查的数据对象方可存取。