4.数据库安全性

概述

​ 数据库的一大特点是数据可以共享，而数据共享必然带来数据库的安全性问题

​ 为了保证安全，要求数据库系统中的数据共享不能是无条件的共享

​

​ 数据库的安全性是指保护数据库以防止不合法使用导致的数据泄露，更改或破坏

​ 系统安全保护措施是否有效是数据库系统安全主要的性能指标

数据库的不安全因素

• 非授权用户对数据库的恶意存取和破坏

• 数据库中重要或敏感的数据被泄露

• 安全环境的脆弱性

可信计算机系统标准

·1985年美国国防部正式颁布《DoD可信计算机系统评估准则》，检测TCSEC或DoD85
​不同国家在TCSEC的基础上各自建立了评估准则
​1993年，为了解决不同标准的概念和基础上的差异，创建了CC标准。
现在CC标准已经基本取代了TCSEC，成为全球性的的计算机安全评估的标注

TDI安全等级划分

  1991年美国国家计算机安全中心颁布了《可信计算机系统评估标准关于可信数据库系统的解释》，简称TDI
  TDI将TCSEC扩展到数据库管理系统，定义了数据库安全性级别评估的标准

​ TCSEC/TDI从安全策略，责任，保证，文档四个方面描述安全性级别划分的指标

​ 一共有四组七个等级

• A1
• B1,B2,B3
• C1,C2
• D1

A1安全性最高，D1安全性最低，高等级包括了低等级的所有安全措施

D：将一切不符合更高标准的系统归于D级，几乎没有专门的机制来保证安全

​ DOS系统是安全标准为D级的操作系统

C1：非常初级的自主安全保护

​ 能够实现用户和数据的分离，进行自主存取控制(DAC)，保护或限制用户权限的传播

​ 例如给不同用户设置权限，通过密码登录的系统

C2：安全产品的最低档次

​ 提供受控的存取保护，将C1级的DAC进一步细化，以个人身份注册负责，并实施审计和资源分离

​ Windows2000，Oracle7

B1：标记安全保护

​ 对系统的数据加以标记，对标记的主体和客体实施强制存取控制(MAC)，审计等安全机制

​ 达到B1标准才能称为"安全"，"可信的"产品

B2:结构化保护

​ 建立形式化的安全策略模型，并对系统内的所有主体和客体实施DAC和MAC

B3：安全域

​ 该级的TCB必须满足访问监控器的要求，审计的跟踪能力更强，并提供系统恢复过程(建立备份,数据被损坏根据备份恢复)

A1:验证设计

​ 提供B3级保护的同时给出系统的形式化设计说明和验证以确信各安全保护真正实现

​ （保证安全机制真正的启用并有效）

越安全的等级，系统开销也就越大

CC标准

​ 提出国际工人的表述信息技术安全性的结构，把信息产品的安全要求氛围安全功能要求，安全保证要求

​

数据库安全性控制

非法使用数据库的情况

• 编写合法程序绕过数据库管理系统及其授权机制‘
• 直接或编写应用程序执行非授权操作
• 通过多次合法查询数据库从中推导出一些保密的数据

数据库安全的具体措施如下：

用户身份鉴别

​ 用户身份鉴别，每一个用户在系统都有一个用户标识，每次用户要求进入系统时，由系统核对身份，通过鉴定后提供数据库管理系统的使用权限。

​ 用户身份鉴别时最外层的安全保护措施

用户标识的组成

​ 一般由用户名和用户标识号组成，用户标识号在系统的生命周期内是唯一的

用户身份鉴别方法

• 静态口令鉴别：静态口令(密码)由用户自己设定。除用户更改外不会改变
• 动态口令鉴别：口令是动态变化的，每次鉴别时均需使用动态产生的新口令登录数据库管理系统。即密码是一次性的(如验证码)
• 生物特征鉴别：通过生物特征进行认证，如指纹，虹膜认证等
• 智能卡鉴别：智能卡是一种不可复制的硬件，内置集成电路芯片，具有硬件加密功能

存取控制

​ 用户权限定义和合法权限检查机制一起组成数据库管理系统的存取控制子系统

​ (1)定义用户权限

​ 将用户权限登记到数据字典中，需要查询用户权限时在数据字典查询

​ DBMS提供适当的语言来定义用户权限，存放在数据字典中，称做安全规则或授权规则

​ (2)合法权限检测

​ 用户发出存取数据库操作请求时，DBMS查找数据字典，查询用户是否有足够的权限

常用的存取控制方法

• 自主存取控制DAC：

​ 不同的用户对不同的数据有不同的权限，用户可将其拥有的存取权限转给其他用户

​ C2级的数据库管理系统支持自主存取控制

• 强制存取控制MAC：

​ 一个数据对象被标记一个访问等级，每一个用户也被授予某种级别的许可证。对于任意一个对象，只有具有合法许可证才能够被存取

授予和收回用户权限

SQL中使用GRANT和REVOKE语句向用户授予或收回对数据的操作权限

GRANT授予权限，REVOKE收回权限

1.GRANT语句

​ 格式：

​ GRANT <权限>[,<权限>]......

​ ON <对象类型> <对象名> [,<对象类型> <对象名>]......

​ TO <用户>[,<用户>]......

​ [WITH GRANT OPTION];

将指定对象的某些权限授予指定的用户

• 授权者可以是数据库管理员(DBA),数据库创建者，拥有该权限的用户

• 权限可以是ALL PRIVILIGES，表示对象的所有权限

• 用户可以是PUBLIC，表示所有用户

• WITH GRANT OPTION关键字：加了关键字，用户可以把这种权限传递给其他用户，不加用户只能使用权限，不能传递权限

• SQL标准不允许循环授权，被授权者不能把权限再传递给授权者或更高级

例1：把查询Student表的权限授予用户U1，并允许其将此权限授予给其他人

​ GRANT SELECT

​ ON TABLE Student

​ TO U1

​ WITH GRANT OPTION;

例2：把查询Student表和修改学生学号的权限授给用户U4

​ GRANT SELECT,UPDATE(Sno)

​ ON TABLE Student

​ TO U4;

• 对属性列的授权时必须明确指出对应的属性列名

2.REVOKE语句

​ REVOKE <权限>[,<权限>]......

​ ON <对象类型> <对象名> [,<对象类型> <对象名>]......

​ FROM <用户>[,<用户>]......

将指定的用户对于指定对象的某些权限收回

例1：将用户U4修改学生学号的权限收回

​ REVOKE UPDATE(Sno)

​ ON TABLE Student

​ FROM U4;

例2：将用户U5对SC表插入权限收回

​ REVOKE INSERT

​ ON TABLE SC

​ FROM U5 CASCADE;

• 收回INSERT权限时应该使用CASCADE，否则拒绝执行该语句
• 使用关键字CASCADE，表示把U5用户及其授予给其它用户的权限全部收回

创建数据库的权限

​ 上面是对数据库进行操作的权限，现在我们来说一下创建数据库的权限

<---------------------------------以后再补充这部分---------------------------------------->

数据库角色

​ 数据库角色是指被命名的一组与数据库操作相关的权限，角色是权限的集合

​ 可以为一组具有相同权限的用户创建一个角色，简化授权过程

​ (角色可以理解为用户的权限模板，使用这个模板给用户固定权限)

​ SQL中用CREATE ROLE创建角色，再用GRANT和REVOKE语句设置角色的权限

• 创建角色：

​ CREATE ROLE <角色名>;

• 设置角色权限：

​ GRANT <权限>[,<权限>]......

​ ON <对象类型> <对象名> [,<对象类型> <对象名>]......

​ TO <用户>[,<用户>]......

• 将一个角色授予其他角色或用户

​ GRANT <角色1> [,<角色2>]

​ TO <用户1> [,<角色3>]

​ [WITH GRANT OPTION];

WITH GRANT OPTION，获得该角色的角色或用户可以把这种权限授予个及其他角色

角色权限收回

​ REVOKE <权限>[,<权限>]......

​ ON <对象类型> <对象名> [,<对象类型> <对象名>]......

​ FROM <角色>[,<角色>]......

执行者是角色的创建者，这个角色的拥有者(如果有足够权限)

例：通过一个角色将一组权限授予一个用户

首先创建一个角色R1

CREATE ROLE R1;

为R1赋予权限

GRANT SELECT,INSERT,UPDATE

ON TABLE Student

TO R1;

将角色设置给用户

GRANT R1

TO U1,U2,U3

回收U1的权限

REVOKE R1

FROM U1

​ 一个用户在数据库中应该作为什么样的角色(普通用户，管理者等)，就把这个角色的权限给他，以简化一项项权限授予的过程

强制存取控制方法

​ 以上都属于自主存取控制方法

​ 自主存取控制方法可能存在数据"无意泄露"的风险，因为这种机制仅仅通过对数据的存取权限来进行安全设置，而对数据本身没有安全性标记

​ 只有外部保护，没有内部保护，一旦绕过权限的安全设置，就会引发问题

​ 强制存取控制方法对系统控制下的所有主客体，实施强制存取控制策略

主体和客体

主体：系统中的活动实体。如用户或访问数据库的程序的进程

客体：系统中的被动实体，包括受主体操控的文件，表，索引，视图等

敏感度标记

对于主客体，DBMS为它们每个实例都设置一个敏感度标记

敏感度标记相当于分类，分为若干登记：

• 绝密TS(Top Secret)
• 机密S(Secret)
• 可信C(Confidential)
• 公开P(Public)

​ TS>S>C>P

​ 主体的敏感度标记称为许可证级别

​ 客体的敏感度标记称为密级

强制存取控制规则

1.仅当主体的许可证级别≥客体的密级时，该主体才能读取该客体

2.仅当主体的许可证级别≤客体的密级时，主体才能写相应的客体

视图

​ 我们创建视图时就说过，视图是一个虚表

​ 用户在访问视图时，视图会根据用户的权限屏蔽掉一些信息，为数据库提供一定程度的安全保护

审计

根据用户的操作，判断用户是否违法，对其进行处理

审计的结构

• 审计日志：启用一个专用的审计日志，将用户对数据库的所有操作记录在上面

  审计设置和审计日志一般存放在数据字典中

• 审计员：审计员利用审计日志监控数据库中的各种行为，找出非法存取数据的用户，事件以及内容

​ 由于审计功能开销大，所以C2级别以上的DBMS才必须具有审计功能,低等级的数据库没有必要

​ 若想使用审计功能，需要将系统参数audit_trail设置为true，才能在系统表SYS_AUDITTRAIL中查看到审计信息

​ 审计系统提供的是一种事后检查的安全机制，只有在事情发生后才能判断是否违法

审计事件

审计日志记录什么样的事件？：

1.服务器事件：审计数据库服务器发生的事件

2.系统权限：对系统拥有的结构或模式对象进行操作的审计，要求该操作的权限是通过系统权限获得的

3.语句事件：对SQL语句，如DDL(数据定义)，DML(数据操作)，DQL(数据查询)，DCL(数据控制)

4.模式对象事件：对也定模式对象上进行的SELECT和DML操作

审计功能

• 基本功能：提供多种审计查阅方式
• 多套审计规则：对审计事件进行规定，一般在初始化设定
• 提供审计分析和报表功能
• 审计日志管理功能

​ 防止审计员误删审计及记录，审计日志必须先转储再删除

​ 对转储的审计记录文件提供完整性和保密性保护

​ 只允许审计员查询和转储审计记录，不允许任何用户新增，删除，更改审计记录等

• 提供查询审计设置及审计记录信息的专门视图

审计分类

• 用户级审计：

​ 任何用户都可以设置的审计，主要针对用户自己创建的数据库的表，视图等进行审计

• 系统级审计：

​ 只能由DBA设置，检测成功或失败的登录要求，监测授权和收回操作，以及其他数据库权限下的操作

审计设置语句

AUDIT语句设计审计功能

NOAUDIT语句取消审计功能

例1：对修改SC表结构或修改SC表数据的操作进行审计

​ AUDIT ALTER,UPDATE

​ ON SC

​ 设置后，对SC表的ALTER和UPDATE操作都会被记入审计日志，供审计员检查

例2：取消对修改SC表结构或修改SC表数据的操作进行审计

​ NOAUDIT ALTER,UPDATE

​ ON SC

数据加密

​ 数据加密时防止数据库中数据在存储和传输中失密的有效手段

​ 加密的基本思想是根据一定的算法，将原始数据变换为不可直接识别的格式，即密文

​

​ 数据加密包括存储加密和传输加密

存储加密

数据存放在硬盘上读取时对其进行加密

透明存储加密

​ 内核级加密保护方式：提供一段封装好的程序，根据标记自动对数据进行加密/解密，用户不知道数据时加密的密文

​ 数据在写到磁盘时对数据进行加密，授权用户读取数据时，根据密钥对其进行解密

​ 数据库的应用程序不需要做任何修改，只需在创建表语句说明需要加密的字段即可

非透明数据加密

​ 用户自己通过多个加密函数实现数据加密

传输加密

数据在网络中进行传输时进行加密

链路加密

在数据链路层进行加密

传输信息由报头和报文两部分组成，报文和报头均加密

端到端加密

在发送端加密，接收端解密

对报文进行加密，不加密报头

所需密码设备数量相对较少，容易被被非法监听