《数据库系统概论》4——数据库安全性

最新推荐文章于 2023-04-17 22:08:21 发布

箬渊凡

最新推荐文章于 2023-04-17 22:08:21 发布

阅读量713

点赞数

分类专栏：数据库学习笔记文章标签：数据库学习

本文链接：https://blog.csdn.net/m0_65036580/article/details/129359150

版权

数据库学习笔记专栏收录该内容

10 篇文章 2 订阅

订阅专栏

问题的提出：

数据库的一大特点是数据可以共享
数据共享必然带来数据库的安全性问题
数据库系统中的数据共享不能是无条件的共享
数据库的安全性是指保护数据库以防止不合法使用所造成的数据泄漏、更改和破坏
系统安全保护措施是否有效是数据库系统主要的性能指标之一

数据库安全性概述

数据库的不安全因素

非授权用户对数据库的恶意存取和破坏
- 一些黑客和犯罪分子在用户存取数据库时猎取用户名和用户口令，然后假冒合法用户偷取、修改甚至破坏用户数据
- 数据库管理系统提供的安全措施主要包括用户身份鉴别、存取控制和视图等技术
数据库中重要或敏感的数据被泄露
- 黑客和敌对分子千方百计盗窃数据库中的重要数据，一些机密信息被暴露
- 数据库管理系统提供的主要技术有强制存取控制、数据加密存储和加密传输等
- 审计日志分析
安全环境的脆弱性
- 数据库的安全性与计算机系统的安全性紧密联系
  - 计算机硬件、操作系统、网络系统等安全性
- 建立一套可信计算机系统的概念和标准

安全标准简介

1985年DoD正式颁布TCSEC（DoD85）

不同国家建立在TCSEC概念上的评估准则：

欧洲——ITSEC

加拿大——CTCPEC

美国——FC

以上四种联合行动解决原标准中概念和技术上的差异，称为CC项目，目前CC已基本取代了TCSEC成为评估信息产品安全性的主要标准

TCSEC标准

1991年4月美国NCSC颁布TDI

TDI又称紫皮书，将TCSEC扩展到数据库管理系统
TDI中定义了数据库管理系统的设计与实现中需要满足和用于进行安全性级别评估的标准

TCSEC/TDI标准的基本内容——从四个方面来描述安全性级别划分的指标：

安全策略
责任
保证
文档

按系统可靠或可信程度逐渐增高

各安全级别之间具有一种偏序向下兼容的关系，即较高安全性级别提供的安全保护要包含较低级别的所有保护要求，同时提供更多或更完善的保护能力

D级：

将一切不符合更高标准的系统均归为D级
典型例子：DOS是安全标准为D的操作系统
- DOS在安全性方面几乎没有什么专门的机制来保护

C1级

非常初级的自主安全保护
能够实现对用户和数据的分离，进行自主存取控制（DAC），保护或限制用户权限的传播
现有的商业系统稍作改进即可满足

C2级

安全产品的最低档次
提供受控的存取保护，将C1级的DAC进一步细化，以个人身份注册负责，并实施审计和资源隔离
达到C2级的产品在其名称中往往不突出“安全”这一特色
典型例子：Windows2000，Oracle7

B1级

标记安全保护。“安全”或“可信的”产品
对系统的数据加以标记，对标记的主体和客体实施强制存取控制、审计等安全机制
B1级典型例子
- 操作系统
- 数据库

B2级

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

B3级

安全域
该级的TCB必须满足访问监控器的要求，审计跟踪能力更强，并提供系统恢复过程

A1级

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

CC标准

提出国际公认的表达信息技术安全性的结构
把信息产品的安全要求分为
- 安全功能要求
- 安全保证要求

CC文本组成

简介和一般模型
- 有关术语、基本概念和一般模型以及与评估有关的一些框架
安全功能要求
- 列出了一系列类，子类和组件
安全保证要求
- 列出了一些列保证类、子类和组件
- 提出了评估保证级，从EAL1至EAL7共分为七级

数据库安全性控制

非法使用数据库的情况

编写合法程序绕过数据库管理系统及其授权机制
直接或编写应用程序执行非授权操作
通过多次合法查询数据库从中推导出一些保密数据
计算机系统中，安全措施是一级一级层层设置

计算机系统的安全模型

用户↔DBMS↔OS↔DB

系统根据用户标识坚定用户身份，合法用户才准许进入计算机系统

数据库管理系统还要进行存取控制，只允许用户执行合法操作

操作系统有自己的保护措施

数据以密码形式存储到数据库中

存取控制流程

首先，数据库管理系统对提出SQL访问请求的数据库用户进行身份鉴别，防止不可信用户使用系统
然后，在SQL处理层进行自助存取控制和强制存取控制，进一步可以进行推理控制
还可以对用户访问行为和系统关键操作进行审计，对异常用户行为进行简单入侵检测

数据库安全性控制的常用方法

用户标识和鉴定
存取控制
视图
审计
数据加密

用户身份鉴别

系统提供的最外层安全保护措施

用户识别：由用户名和用户标识号组成（用户标识号在系统整个生命周期内唯一）

用户身份鉴别方法：

静态口令鉴别
- 静态口令一般由用户自己设定，这些口令是静态不变的
动态口令鉴别
- 口令是动态变化的，每次鉴别时均需使用动态产生的新口令登录数据库管理系统，即采用一次一密的方法
生物特征鉴别
- 通过生物特征进行认证的技术，生物特征如指纹、虹膜和掌纹等
智能卡鉴别
- 智能卡是一种不可复制的硬件，内置集成电路的芯片，具有硬件加密功能

存取控制

存取控制机制组成

定义用户权限，并将用户权限等级到数据字典中
- 用户对某一数据对象的操作权利称为权限
- DBMS提供适当的语言来定义用户权限，存放在数据字典中，称作安全规则或授权规则
合法权限检查
- 用户发出存取数据库操作请求
- DBMS查找数据字典，进行合法权限检查

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

常用存取控制方法：

自主存取控制（DAC）
- C2级
- 用户对不同的数据对象有不同的存取权限
- 不同的用户对同一对象也有不同的权限
- 用户还可将其拥有的存取权限转授给其他用户
强制存取控制
- B1级
- 每一个数据对象被标以一定的密级
- 每一个用户也被授予某一个级别的许可证
- 对于任意一个对象，只有具有合法许可证的用户才可以存取

自主存取控制方法

通过SQL的GRANT语句和REVOKE语句实现

用户权限组成

数据对象
操作类型

定义用户存取权限：定义用户可以在那些数据库对象上进行那些类型的操作

定义存取权限称为授权

授权：授予与回收

GRANT

一般格式：

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

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

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

[WITH GRANT OPTION]

语义：将对指定操作对象的指定操作权限授予指定的用户

发出GRANT

数据库管理员
数据库对象创建者
拥有该权限的用户

按受权限的用户

一个或多个具体用户
PUBLIC（即全体用户）

WITH GRANT OPTION子句：

指定：可以再授权
未指定：不能传播

不允许循环授权

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

U3可以传播这个权限

REVORK

授权的权限可以由数据库管理员或其他授权者用REVOKE语句收回

REVOKE语句的一般格式为：

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

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

FROM <用户>[,<用户>]...[CASCADE | RESTRICT];

在MySQL中不可以级联收回权限

数据库管理员：

拥有所有对象的所有权限
根据实际情况不同的权限授予不同的用户

用户：

拥有自己建立的对象的全部的操作权限
可以使用GRANT把权限授予其他用户

被授予的用户

如果具有“继续授权”的许可，可以把获得的权限再授予其他用户

所有授予出去的权利在必要时又都可以用REVOKE语句收回

创建数据库模式的权限

数据库管理员在创建用户时实现

CREATE USER语句格式：

CREATE USER <username>

[WITH][DBA|RESOURCE|CONNECT];

注：CREATE USER不是SQL标准，各个系统的实现相差甚远

CREATE USER语句格式说明

只有系统的超级用户才有权创建一个新的数据库用户
新创建的数据库用户有三种权限——CONNECT、RESOURCE和DBA
如果没有指定创建的新用户的权限，默认该用户拥有CONNECT权限。拥有CONNECT权限的用户不能创建新用户，不能创建模式，也不能创建基本表，只能登陆数据库
拥有RESOURCE权限的用户能创建基本表和视图，成为所创建对象的属主。但不能创建模式，不能创建新的用户
拥有DBA权限的用户是系统中的超级用户，可以创建新的用户，创建模式，创建基本表和视图等；DBA拥有对所有数据库对象的存取权限，还可以把这些权限授予一般用户

数据库角色

数据库角色：被命名的一组与数据库操作相关的权限

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

角色的创建

CREATE ROLE <角色名>

给角色授权

GRANT <权限>,<权限>

ON <对象类型>对象名

TO<角色>,<角色>

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

GRANT<角色1>,<角色2>

TO<角色3>,<用户1>

[WITH ADMIN OPTION]

该语句把角色授予某用户，或授予另一个角色
授予者是角色的创建者或拥有在这个角色上的ADMIN OPTION
指定了WITH ADMIN OPTION则获得某种权限的角色或用户还可以把这种权限授予其他角色

一个角色的权限：直接授予这个角色的全部权限加上其他角色授予这个角色的全部权限

角色权限的收回

REVOKE <权限>,<权限>

ON<对象类型><对象名>

FROM<角色>,<角色>

用户可以回收角色的权限，从而修改角色拥有的权限
REVOKE执行者是
- 角色的创建者
- 拥有在这个角色上的ADMIN OPTION

强制存取控制方法

可能存在数据的“无意泄露”

原因：这种机制仅仅通过对数据的存取权限来进行安全控制，而数据本身并无安全性标记

解决：对系统控制下的所有主客体实施强制存取控制策略

强制存取控制：

保证更高程度的安全性
用户不能直接感知或进行控制
适用于对数据由严格而固定密集分类的部门
- 军事部门
- 政府部门

在强制存取控制中，数据库管理系统所管理的全部实体被分为主体和客体两大类

主体是系统中的活动实体

数据库管理系统所管理的实际用户
代表用户的各进程

客体是系统中的被动实体，受主体操控

文件、基本表、索引、视图

敏感度标记

对于主体和客体，DBMS为他们每个实例（值）指派一个敏感度标记
敏感度标记分为若干等级
- 绝密TS
- 机密S
- 可信C
- 公开P
- TS>=S>=C>=P
主体的敏感度标记称为许可证级别
客体的敏感度标记称为密级

强制存取控制规则

仅当主体的许可证级别大于或等于客体的密级时，该主体才能读取相应的客体
仅当主体的许可证级别小于或等于客体的密级时，该主体才能写相应的客体

强制存取控制是对数据本身进行密级标记，无论数据如何复制，标记与数据是一个不可分的整体，只有符合密级标记要求的用户才可以操纵数据

实现强制存取控制时要首先实现自主存取控制

原因：较高安全性级别提供的安全保护要包含较低级别的所有保护

自主存取控制欲强制存取控制共同构成数据库管理系统的安全机制

先进行自主存取控制检查，通过自主存取控制检查的数据对象，再由系统进行强制存取控制检查，只有通过强制存取控制检查的数据对象方可存取

视图机制

把要保密的数据对无权存取这些数据的用户隐藏起来，对数据提供一定程度的安全保护

间接的实现支持存取谓词的用户权限定义

审计

什么是审计：

启用一个专用的审计日志——将用户对数据库的所有操作记录在上面
审计员利用审计日志——监控数据库中的各种行为，找出非法存取数据的人，时间和内容
C2以上安全级别的DBMS必须具有审计功能

审计功能的可选性：

审计很费时间和空间
DBA可以根据应用对安全性的要求，灵活地打开或关闭审计功能
审计功能主要用于安全性要求较高的部门

审计事件

服务器事件
- 审计数据库服务器发生的事件
系统权限
- 对系统拥有的结构或模式对象进行操作的审计
- 要求该操作的权限是通过系统权限获得的
语句事件
- 对SQL语句，如DDL,DML,DQL及DCL语句的审计
模式对象事件
- 对特定模式对象上进行的SELECT或DML操作的审计

审计功能

基本功能
- 提供多种审计查阅方式
多套审计规则：一般在初始化设定
提供审计分析和报表功能
审计日志管理功能
- 防止审计员误删审计记录，审计日志必须先转储后删除
- 对转储的审计记录文件提供完整性和保密性保护
- 只允许审计员查阅和转储审计记录，不允许任何用户新增和修改审计记录等
提供查询审计设置及审计记录信息的专门视图

AUDIT语句和NO AUDIT语句

AUDIT语句：设置审计功能
NO AUDIT语句：取消审计功能

用户级审计

任何用户可设置的审计
主要是用户针对自己创建的数据库表和视图进行审计

系统级审计

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

数据加密

数据加密：

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

加密的基本思想：

根据一定的算法将原始数据——明文变换为不可直接识别的格式——密文

加密方法

存储加密
传输加密

存储加密：

透明存储加密
- 内核级加密保护方式，对用户完全透明
- 将数据在写到磁盘时对数据进行加密，授权用户读取数据时再对其进行解密
- 数据库的应用程序不需要做任何修改，只需在创建表语句中说明需加密的字段即可
- 内核级加密方法：性能较好，安全完备性较高
非透明存储加密
- 通过多个加密函数实现

传输加密

链路加密
- 在链路层进行加密
- 传输信息由报头和报文两部分组成
- 报文和报头均加密
端到端加密
- 在发送端加密，接收端解密
- 只加密报文不加密报头
- 所需密码设备数量相对较少，容易被非法监听者发现并从中获取敏感信息

基于安全套接层协议SSL传输方案的实现思路：

确认通信双方端点的可靠性
- 采用基于数字证书的服务器和客户端认证方式
- 通信时均首先向对方提供己方证书，然后使用本地的CA信任列表和证书撤销列表对接收到的对方证书进行验证
协商加密算法和密钥
- 确认双方端点的可靠性后，通信双方协商本次会话的加密算法和密钥
可信数据传输
- 业务数据在被发送之前将被用某一组特定的密钥进行加密和消息摘要计算，以加密形式的网络上传输
- 当业务数据被接受的时候，需用相同一组特定的密钥进行解密和摘要计算