Chap.4 数据库安全性
4.1 数据库安全性概述
我们知道, 数据库的一大特点是数据可共享, 但是显然, 数据共享必然会带来数据库的安全问题. 这就引出了我们本章的主题: 数据库安全 .
我们先给数据库安全性做出一个定义:
保护数据库以防止不合法使用所造成的数据泄露、更改或破坏.
4.1.1 数据库的不安全因素
这跟我们之前写过的一些安全方面的主要风险比较像, 从数据库而言, 基本上就分为以下几个方面:
- 对数据库内数据的恶意存取 / 破坏
- 重要或敏感的数据被泄露
- 安全环境(系统本身)不安全
4.1.2 安全标准简介
首先是数据库刚刚发展起来的时候, 美国国防部就针对数据库的安全性发表了 TCSEC(Trusted Computer System Evaluation Criteria) 标准.
在此后, 20世纪90年代, 由于不同标准差异明显, 因此各机构联合, 提出了 CC(Common Criteria) 标准, 它的好处是结构开放, 表达形式通用. 目前已经基本上在各个方面替代了 TCSEC 以及基于其的各种变种.
我们这里大概从访问控制的角度来说一下这几个标准的区别:
- D级: 最低级别, 任何不符合C1及以上的系统均归为此类
- C1级: 能够支持自主访问控制(DAC)
- C2级: 将C1级的自主访问控制进一步细化, 能够支持用户的审计和身份隔离( 这通常是安全产品的最低等级 )
- B1级: 实现了强制访问控制(MAC), 也就是通过安全标识对主体 / 客体进行标识.
- B2级: 提供结构化保护, 对系统中的所有实体做到了DAC / MAC全覆盖
- B3级: 提供 安全域 , 提供更强的审计跟踪能力, 并具有系统恢复过程
- A1级: 提供B3级的同时给出系统的具体实现说明
在随后提出的CC标准中, 对这几个标准进行了细化定义, 我们这里给个图:
4.2 数据库安全性控制
在计算机系统中, 安全措施是一层层设置的.
显然, 我们主要关注的是左侧的两层, 至于操作系统相关的问题, 数据库管理系统DBMS无法过多涉及.
数据库安全性控制的常用方法有以下几种:
- 用户标识 / 鉴定(同信安中的 身份认证 )
- 存取控制(同信安中的 访问控制 )
- 视图
- 审计
- 数据加密
4.2.1 用户身份鉴别
这一部分基本上依赖系统本身的安全措施, 包括:
- 静态口令
- 动态口令
- 生物特征
- 智能卡
等认证方式.
4.2.2 访问控制
访问控制机制的组成包括两步:
- 定义用户权限
- 合法权限检查
这两部分也一并组成了数据库的访问控制子系统.
访问控制的具体策略其实非常多
这些访问控制我们是整理过的, 详见 访问控制策略
其中, 数据库比较多涉及的其实是自主访问控制和强制访问控制, 现代的数据库基本上也支持基于角色的访问控制.
4.2.3 自主访问控制方法
自主访问控制即人工授予某个用户是否具有某个客体的某些访问权限.
在SQL中, 通过 GRANT 和 REVOKE 语句来授予 / 收回用户的权限.
GRANT语句的一般语法为:
GRANT <权限>[,<权限>]...
ON <对象类型> <对象名>[,<对象类型> <对象名>]…
TO <用户>[,<用户>]...
[WITH GRANT OPTION];
其实我们能看出来, 权限名(也就是操作类型)就是我们上一章费劲巴力写的SQL的各种操作.
我们看几个具体的例子, 还是使用与上一章相同的例子, 这里我们把三个表再给一下:
(1)把查询Student表权限授给用户U1 ( 最普遍的情况 )
GRANT SELECT
ON TABLE Student
TO U1;(2)把对Student表和Course表的全部权限授予用户U2和U3 ( 所有权限 )
GRANT ALL PRIVILIGES
ON TABLE Student, Course
TO U2, U3;(3)把对表SC的查询权限授予所有用户 ( 所有用户 )
GRANT SELECT
ON TABLE SC
TO PUBLIC;(4)把查询Student表和修改学生学号的权限授给用户U4 ( 对某个具体列的权限授予 )
GRANT SELECT, UPDATE(Sno)
ON TABLE Student
TO U4;(5)把对表SC的INSERT权限授予U5用户，并允许他再将此权限授予其他用户 ( 权限下放 )
GRANT INSERT
ON TABLE SC
TO U5
WITH GRANT OPTION再来看收回权限
其实跟授予权限很类似, 就是把GRANT换成了REVOKE.
(1)把用户U4修改学生学号的权限收回
REVOKE UPDATE(Sno)
ON TABLE Student
TO U4(2)把用户U5对SC表的INSERT权限收回 ( 存在权限下放的情况时 )
REVOKE INSERT
ON TABLE SC
TO U5 CASCADE注意
当使用CASCADE关键字时, 这个用户以及被他授予对应下方权限用户的权限均会被收回.
比如U5给了U6插入权限, 那么这时U6的插入权限会被一并收回.
如果不加CASCADE, 而用户又有下方权限时, 操作会被拒绝.当然, 如果U6还有另一个人的授权, 而这个人的权限正常存在, 则U6的权限不会被收回.
4.2.4 创建用户时赋予权限
有些读者可能会想能不能在创建数据库用户的时候就直接把权限给了.
很遗憾, 事实上, 创建用户并不在SQL标准中, 因此各个系统的实现差距比较大. 但是通常可以通过三个关键字来规定用户的大致身份:
CREATE USER <username>
[WITH][DBA|RESOURCE|CONNECT];我们对这仨词解释一下:
- DBA: 数据库超级用户(也就是数据库管理员), 用有该数据库的全部权限并可以将其赋予给其它用户.
- RESOURCE: 能创建基本表和视图, 称为所创建对象的属主, 但是不能创建模式.
- CONNECT: 初始没有任何权限, 只能登录数据库.
4.2.5 数据库角色
之所以说数据库还涉及到基于角色的访问控制, 就在这了.
数据库为了方便对用户赋予权限, 提供了 角色 这一概念.
角色是被命名的一组与数据库操作相关的权限.
其实其思路就是基于角色的访问控制.
角色的创建非常简单:
CREATE ROLE <角色名>随后就可以对这个角色名进行权限授予 / 收回了. 具体方法跟对用户授予权限 / 方法几乎一致, 把用户名改成角色名即可:
GRANT <权限>[,<权限>]…
ON <对象类型>对象名
TO <角色>[,<角色>]…随后, 由于角色是权限集合嘛, 就可以直接把角色赋予某个别的角色 / 或者直接赋予某个用户:
GRANT <角色1>[,<角色2>]…
TO <角色3>[,<用户1>]…
[WITH ADMIN OPTION]注意
实际上, 读者不要把角色当成什么高端的玩意, 回归到定义上, 它就是一个权限的集合, 因此自然可以赋予给其它的角色(权限集合) / 具体用户, 也自然能够收回.
4.2.6 强制访问控制
这玩意本质上就是对访问者和被访问客体进行分级, 然后根据这个分级来决定访问者是否具有访问权限.
在数据库中通常可以搭配上述几种方式一块使用.
4.3 审计
所谓审计, 其实就是在发生什么事情的时候, 都在某个位置记一笔.
当前主流的数据库系统基本上对审计机制都进行了支持.
针对设置主体不同, 可以分为:
- 用户级审计(只能针对自己创建的基本表和视图进行审计)
- 系统级审计(只能由管理员设置, 对数据库登录 / 授权 / 收回权限等操作均有记录)
在SQL中, 审计的设置与去除通过 AUDIT 和 NO AUDIT 来实现:
给个例子:
(1)对修改SC表结构或修改SC表数据的操作进行审计
AUDIT ALTER, UPDATE
ON SC;(2)取消对SC表的一切审计
NOAUDIT ALL
ON SC; 注意
审计功能同样不在SQL标准中, 因此不同的系统对于其的实现(包括语法)都天差地别, 上述语法是基于自身实现了审计机制的Oracle数据库进行的.
4.4 数据加密
数据加密我们也比较熟悉了, 在这里讲数据库采用的两种:
- 透明存储加密: 内核级加密保护方式, 对用户而言是透明的.
- 在内模式层级加密(即磁盘加密), 数据库应用程序不需要做任何修改.
- 性能好, 完备性高
- 非透明存储加密:
- 通过多个加密函数实现
至于其它的传输加密等额外加密, 我们这里就不提了.
