数据库复习八
# 问题提出
- 数据库的一大特点是可以共享
- 数据共享必然带来数据库的安全性问题
- 数据库系统中的数据共享不能是无条件的共享
# 数据库安全性
数据库安全性:保护数据库以防止不合法使用所造成的数据泄露、更改或破坏
# 数据库安全性概述
- 非授权用户对数据库的恶意存取和破坏
- 数据库中重要或敏感的数据被泄露
- 安全环境的脆弱新
# 数据库安全性控制
计算机系统中,安全措施一级一级层层设置
数据库安全性控制的常用方法:
- 用户标识和鉴别
- 存取控制
- 视图
- 审计
- 数据加密
# 用户标识与鉴别
系统提供的最外层安全保护措施
口令:系统核对口令以鉴别用户身份
# 存取控制
存取控制机制组成
- 定义用户权限:
- 用户对某一数据对象的操作权利称为权限
- DBMS 提供适当的语言来定义用户权限,存放在数据字典中,称作安全规则或授权规则
- 合法权限检查
- 用户发出存取数据库操作请求
- DBMS 查找数据字典,进行合法权限检查
用户权限定义和合法权检查机制一起组成了 DBMS 的存取控制子系统
常用存取控制方法:
- 自主存取控制
- C2 级
- 灵活
- 强制存取机制
- B1
- 严格
# 自主存取控制方法
通过 SQL 的 GRANT 语句和 REVOKE 语句实现
用户权限组成
- 数据对象
- 操作类型
定义用户权限:定义用户可以在那些数据库对象上进行哪些类型的操作
定义存取权限称为授权
关系数据库系统中存取控制对象
对象类型 | 对象 | 操作类型 |
---|---|---|
数据库模式 | 模式 | CREATE SCHEMA |
基本表 | CREATE TABLE,ALTER TABLE | |
视图 | CREATE VIEW | |
索引 | CREATE INDEX | |
数据 | 基本表和视图 | SELECT,INSERT,UPDATE,DELETE,REFERENCES,ALL PRIVILEGES |
属性列 | SELECT,INSERT,UPDATE,DELETE,REFEREMCES,ALL PRIVILEGES |
# 授权与回收
GRANT
GRANT 语句一般格式
GRANT <权限>[,< 权限 >]...
ON <对象类型> < 对象名 >,[< 对象类型 >< 对象名 >]...
TO <用户>[,< 用户 >]...
[WITH GRANT OPTION];
发出 GRANT
- DBA
- 数据库对象创建者 (即属主 Owner)
- 拥有该权限的用户
按受权限的用户
- 一个或多个具体用户
- PUBLIC (全体用户)
WITH GRANT OPTION 子句:
- 子句:可以再授予
- 没有指定:不能传播
不允许循环授权
例:把查询 Student 表权限授权给用户 U1
GRANT SELECT | |
ON TABLE Student | |
TO U1; |
把对 Student 表和 Course 表的全部权限授予用户 U2 和 U3
GRANT ALL PRIVILEGES | |
ON TABLE Student | |
TO U2,U3; |
把对表 SC 的查询权限授予所有用户
GRANT SELECT | |
ON TABLE SC | |
TO PUBLIC; |
把查询 Student 表和修改学生学号的权限授予给用户 U4
GRANT UPDATE(Sno) SELECT | |
ON TABLE Student | |
TO U4; |
对属性列的授权时必须明确指出相应属性列名
把对表 SC 的 INSERT 权限授予 U5 用户,并允许他再将此权限授予其他用户:
GRANT INSERT | |
ON TABLE SC | |
TO U5 | |
WITH GRANT OPTION; |
REVOKE
授予的权限可以由 DBA 或其他授权者用 REVOKE 语句收回
REVOKE 语句的一般格式为:
REVOKE <权限>[,< 权限 >]...
ON <数据类型> < 对象名 > ,...
FROM <用户>[,< 用户 >]
[CASCADE|RESTRICT];
例:把用户 U4 修改学生学号的权限收回
REVOKE UPDATE(Sno) | |
ON TABLE Student | |
FROM U4; |
收回所有用户对 SC 表的查询权限
REVOKE SELECT | |
ON TABLE SC | |
FROM PUBLIC; |
把用户 U5 对 SC 表的 INSERT 权限收回
REVOKE INSERT | |
ON TABLE SC | |
FROM U5 CASCADE; |
- 将用户 U5 的 INSERT 权限回收的时候必须级联 (CASCADE) 收回
- 系统只收回直接或间接从 U5 出获得的权限
# 创建数据库模式的权限
DBA 在创建用户时实现
CREATE USER 语句格式
CREATE USER < username >
[WITH] [DBA|RESOURCE|CONNECT]
# 数据库角色
数据库角色:被命名的一组与数据库操作相关的权限
- 角色是权限的集合
- 可以为一组具有相同权限的用户创建一个角色
- 简化授权的过程
角色的创建:
- CREATE ROLE <角色名>
# 强制存取控制方法
自主存取控制缺点:
- 可能存在数据的 "无意泄露"
- 原因:这种机制仅仅通过对数据的存取权限来进行安全性控制,而数据本身并无安全性标记
- 解决:对系统控制下的所有主客体实施强制存取控制策略
强制存取控制:
- 保证更高程度的安全性
- 用户不能直接感知或进行控制
- 适用于对数据有严格而固定密集分类的部分
- 军事部门
- 政府部门
主体是系统中活动实体
- DBMS 所管理的实际用户
- 代表用户的各个进程
客体是系统的被动实体,是受主体操控的
- 文件
- 基本表
- 索引
- 视图
敏感度标记:
- 绝密
- 机密
- 可信
- 公开
主体敏感度标记称为许可证级别
客体的敏感度标记称为密级
强制存取控制规则:
- 仅当主体的许可证级别大于或等于客体的密级时,该主体才能读取相应客体
- 仅当主题的许可证级别小于或等于客体的密级时,该主体才能写相应的客体
DAC 与 MAC 共同构成 DBMS 的安全机制
实现 MAC 时要首先 DAC
- 原因:较高安全性级别提供的安全保护要包含较低级别的所有保护
例题:
1、安全性控制的防范对象是 (B),防止他们对数据库数据的存取
A. 不合语义的数据
B. 非法用户
C. 不正确的数据
D. 不符合约束的数据
2、在强制存取控制机制中,当主体的许可证级别等于客体的密级时,主体可以对客体进行如下操作 (D)。
A. 读取
B. 写入
C. 不可操作
D. 读取、写入
# 视图机制
要把保密的数据对无权存取这些数据的用户隐藏起来,对数据提供一定程度的安全保护
例:建立计算机系学生的视图,把对该视图的 SELECT 权限授予王平,把该视图上的所有操作权限授予张明
先建立计算机系学生视图 CS_Student
CREATE VIEW CS_Student | |
AS | |
SELECT * | |
FROM Student | |
WHERE Sdept='CS'; |
在视图上进一步定义存取权限
GRANT SELECT | |
ON CS_Student | |
TO 王平; | |
GRANT ALL PRIVILEGES | |
ON CS_Student | |
TO 张明; |
# 审计
什么是审计:
- 审计日志:将用户对数据库的所有操作记录在上面
- DBA 利用审计日志:找出非法存取数据的人、时间和内容
- C2 以上安全级别的 DBMS 必须具有
审计分为:
- 用户级审计
- 针对自己创建的数据库表或视图进行审计
- 记录所有用户对这些表或视图的一切成功和 (或) 不成功的访问要求以及各种类型的 SQL 操作
- 系统级审计
- DBA 设置
- 监测成功或失败的登录要求
- 监测 GRANT 和 REVOKE 操作以及其他数据库级权限下的操作
AUDIT 语句:设置审计功能
NOAUDIT 语句:取消审计功能
例:对修改 SC 表结构或修改 SC 表数据的操作进行审计:
AUDIT ALTER,UPDATE | |
ON SC; |
取消对 SC 表的一切审计
NOAUDIT ALTER,UPDATE
ON SC;
数据库安全审计系统提供了一种 (C) 的安全机制
A. 事前检查
B. 事发时追踪
C. 事后检查
D. 事前预测
# 数据加密
防止数据库中数据在存取或传输中失密的有效手段
加密基本思想
- 根据一定算法将原始数据 —— 明文变换为不可直接识别的格式 —— 密文
加密方法:
- 存储加密
- 透明存取加密
- 内核级加密保护形式,对用户完全透明
- 将数据在写到磁盘时对数据进行加密,授权用户读取数据时再对其进行解密
- 数据库的应用程序不需要做任何修改,只需在创建表语句中说明需加密的字段即可
- 内核级加密方法:性能较好,安全完备性较高
- 非透明存取加密
- 通过多个加密函数实现
- 透明存取加密
- 传输加密
- 链路加密
- 在链路层进行加密
- 传输信息由报头和报文两部分组成
- 报文和报头均加密
- 端到端加密
- 在发送端加密,接收端解密
- 只加密报文不加密报头
- 所需密码设备数量相对较少,容易被非法监听者发现并从中获取敏感信息
- 链路加密
- 库内加密
- 库外加密
库内加密模式 | 库外加密模式 | |
---|---|---|
加解密执行者 | DBMS | 专门的密码服务器或客户端 |
对数据库应用是否透明 | 是 | 否 |
服务器端性能影响 | 服务器运行负担大 | 基本无影响 |
密钥管理 | 库内存储,风险大 | 专门保护,风险小 |
是否影响 DBMS 功能 | 完全不影响 | 影响索引等部分功能 |
密码服务能力 | 提供的算法等密码服务能力受 DBMS 限制 | 可以灵活地变更,提供多种密码服务 |
# 其他安全性保护
- 推理控制
- 处理强制存取控制未解决的问题
- 避免用户利用能够访问的数据推知更高密级的数据
- 隐藏密道
- 处理强制存取控制未解决的问题
# OpenGauss 数据库安全
- 客户端接入认证
- 管理用户及权限
- 设置数据库审计