900字范文 > 【吐血整理】数据库的安全性

【吐血整理】数据库的安全性

时间：2022-05-26 15:06:49

相关推荐

【吐血整理】数据库的安全性

本文主讲数据库的安全性，欢迎阅读~

📋目录

前言：一、数据库安全性概述二、数据库安全性控制1. 用户身份鉴别2. 存取控制3. 自主存取控制方法4. 授权：授予与回收5. 数据库角色6. 强制存取控制方法三、视图机制四、审计（Audit）五、数据加密

前言：

数据库的一大特点是数据共享

数据共享必然带来数据库的安全性问题

数据库系统中的数据共享不能是无条件的共享

数据库的安全性：

保护数据库以防止不合法使用所造成的数据泄露、更改或破坏

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

一、数据库安全性概述

1 . 数据库的不安全因素

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

猎取用户名和用户口令，然后假冒合法用户偷取、修改甚至破坏用户数据。

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

黑客和敌对分子千方百计盗窃数据库中的重要数据，一些机密信息被暴露。

③安全环境的脆弱性

数据库安全性与计算机系统安全性紧密联系（计算机硬件、操作系统、网络等安全性）

2 . 安全标准简介

CC（Common Criteria）：，CC V3.1 ISO/IEC15408-

CC评估等级分为EAL1、EAL2、EAL3、EAL4、EAL5、EAL6和EAL7共七个等级，等级越高，表示通过认证需要满足的安全保证要求越多，系统的安全特性越可靠。

国际标准化组织（International Organization for Standardization，ISO）

二、数据库安全性控制

非法使用数据库的情况：

① 编写合法程序绕过DBMS及其授权机制

②直接（或编写应用程序）执行非授权操作

③ 通过多次合法查询数据库从中推导出一些保密数据

计算机系统中，安全措施是一级一级层层设置的：

①用户标识鉴定用户身份，合法用户准许进入系统

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

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

④数据以密文形式存储到数据库中

（ps：数据以密文形式存储在数据库中，即使前三层被攻破，最后看到的是密文的话，是比较有安全性的）

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

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

数据库管理系统安全性控制模型：

1. 用户身份鉴别

①静态口令鉴别

静态口令一般由用户自己设定，这些口令是静态不变的（例如自己设置的各种登陆密码即静态口令）

②动态口令鉴别

口令是动态变化的，每次鉴别时均需使用动态产生的新口令登录数据库管理系统，即采用一次一密的方法（例如有的地方每次登陆需要手机短信验证，每次发的验证码就是动态口令~）

③生物特征鉴别

通过生物特征进行认证的技术，生物特征如人脸、指纹等（现在这个技术比较普遍啦，很多智能手机上都有指纹识别和人脸识别）

④智能卡鉴别

智能卡是一种不可复制的硬件，内置集成电路的芯片，具有硬件加密功能（例如：IC银行卡，IC卡是以芯片作为介质的银行卡，与磁条卡相比，芯片卡安全性高，卡内敏感数据难以被复制）

2. 存取控制

存取控制机制组成：

定义用户权限

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

用户发出存取数据库操作请求，DBMS查找数据字典，进行合法权限检查

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

— — — — — — — — — — — — — — — — — — — — — — — —

常用存取控制方法：

自主存取控制（DAC）

用户对不同的数据对象有不同的存取权限

不同的用户对同一对象也有不同的权限

用户还可将其拥有的存取权限转授给其他用户强制存取控制（MAC）

每一个数据对象被标以一定的密级

每一个用户也被授予某一个级别的许可证

对于任意一个对象，具有合法许可证的用户才可以存取

3. 自主存取控制方法

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

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

关系数据库系统中存取控制对象：

（ps：ALL PRIVLEGES即全部权限）

4. 授权：授予与回收

① GRANT 授予

GRANT <权限>[,<权限>]... ON <对象类型> <对象名>[,<对象类型> <对象名>]…TO <用户>[,<用户>]...[WITH GRANT OPTION];

WITH GRANT OPTION子句:

指定：可以再授予

没有指定：不能传播

语义：将对指定操作对象的指定操作权限授予指定的用户（即写了WITH GRANT OPTION的话，TO之后的用户能继续传播相应的权限）

— — — — — — — — — — — — — — — — — — — — — — — —

这里举例需要用到很多用户，所以咱们先来新建几个用户：

关于如何创建登录名和用户，在查阅了大量资料和自己实践后，我写了一篇博客（做了基础的讲解和示范）：SQL Server 创建登录名和用户名【详细介绍】

这里我采用如下格式在STUDENT数据库下创建了U1~U7用户及对应的登录名：

CREATE LOGIN U1 WITH PASSWORD = 'henry626626', DEFAULT_DATABASE = STUDENT;CREATE USER U1 FOR LOGIN U1;

用以下SQL语句可查看当前数据库下的所有用户：

exec sp_helpuser;

好了~创建成功啦，接下来一大波例子来袭👣

— — — — — — — — — — — — — — — — — — — — — — — —

🌟来看例 1：把查询Student表权限授给用户U1：

GRANT SELECT ON TABLE Student TO U1;

不是，这第一个例子就这么不友好吗……

这里T-SQL中是不支持上面的标准SQL的写法的，将TABLE去掉后方能正常运行：

GRANT SELECT ON Student TO U1;

如下图查看用户U1确实被授予了查询Student表的权限：

🌟来看例 2：把对Student表和Course表的全部权限授予用户U2和U3：

GRANT ALL PRIVILIGES ON TABLE Student, Course TO U2, U3;-- 有了刚才的经验教训我去掉了TABLEGRANT ALL PRIVILIGES ON Student, Course TO U2, U3;

emmm，这……（T-SQL和标准SQL要不干脆干一架算了😶）

因为提示的是"PRIVILIGES"附近有语法错误，所以我查看了SQL官方文档：GRANT (Transact-SQL)，发现T-SQL中是有PRIVILEGES这个参数的，其解释是：包含此参数是为了符合 ISO 标准。请不要更改 ALL 的行为。emm（人类迷惑行为？😅，诶，等等我的单词好像写错了，是PRIVILEGES）

然后有如下图中的报错，原来是因为ON后面只能跟一个对象，所以我将其拆分成了两个SQL语句：

GRANT ALL PRIVILEGESON StudentTO U2, U3GRANT ALL PRIVILEGESON CourseTO U2, U3

这会儿提示的是：ALL 权限已不再推荐使用，并且只保留用于兼容性目的。它并不表示对实体定义了 ALL 权限。官方文档中对参数ALL有以下讲解，很不错👏！

很明显，这里的例子中安全对象是表Student和Course，所以授予了U2和U3相应的权限（这里以U2为例查看）

🌟来看例 3：把对表SC的查询权限授予所有用户：

GRANT SELECT ON TABLE SC TO PUBLIC;-- T-SQL如下GRANT SELECT ON SC TO PUBLIC;

这里的PUBLIC即表示授权给所有的用户~

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

GRANT UPDATE(Sno), SELECT ON TABLE Student TO U4;-- T-SQL如下GRANT UPDATE(Sno), SELECT ON Student TO U4;

注意：在对属性列授权时必须明确指出相应属性列名，如这里授予修改学生学号的权限，但是如果不加(Sno)那就成了授予修改整个表的权限了，，啥都能改，这不行哈

🌟来看例 5：把对表SC的INSERT权限授予U5用户，并允许他再将此权限授予其他用户：

GRANT INSERT ON TABLE SC TO U5WITH GRANT OPTION;-- T-SQL如下GRANT INSERT ON SC TO U5WITH GRANT OPTION;

加上WITH GRANT OPTION后，U5不仅拥有了对表SC的INSERT权限，还可以传播此权限

🌟来看例 6：使用登录名U5登录后执行如下语句（因为在一个数据库中登录名和用户名是一一对应的，所以登录U5后切换至STUDENT数据库进行如下操作实验），将权限授予给U6：

（ps：登录名必须映射到数据库用户才能连接到数据库。一个登录名可以作为不同用户映射到不同的数据库，但在每个数据库中只能作为一个用户进行映射

）

GRANT INSERT ON TABLE SC TO U6WITH GRANT OPTION;-- T-SQL如下GRANT INSERT ON SC TO U6WITH GRANT OPTION;

🌟来看例 7：如上面的方法，U6还可以将此权限授予U7：

GRANT INSERT ON SC TO U7;

因为没有WITH GRANT OPTION，所以U7不能再传播此权限！！用登录名U7登录之后执行以下语句，系统报错：无法对对象 'SC' 执行查找，因为它不存在，或者您没有所需的权限，显然STUDENT数据库中是有SC表的，所以原因是U7不能传播该权限

— — — — — — — — — — — — — — — — — — — — — — — —

② REVOKE 回收

语句的一般格式为：

REVOKE <权限>[,<权限>]... ON <对象类型> <对象名>[,<对象类型><对象名>]…FROM <用户>[,<用户>]...[CASCADE | RESTRICT];

🌟来看例 1：把用户U4修改学生学号的权限收回：

REVOKE UPDATE(Sno)ON TABLE Student FROM U4;-- T-SQL如下REVOKE UPDATE(Sno)ON Student FROM U4;

U4修改学生学号的权限UPDATE(Sno)已成功收回~

🌟来看例 2：收回所有用户对表SC的查询权：

REVOKE SELECT ON TABLE SC FROM PUBLIC;-- T-SQL如下REVOKE SELECT ON SC FROM PUBLIC;

🌟来看例 3：把用户U5对SC表的INSERT权限收回：

REVOKE INSERT ON TABLE SC FROM U5 CASCADE ;-- T-SQL如下REVOKE INSERT ON SC FROM U5 CASCADE ;

因为U5还将该权限传播给了U6和U7，所以将U5的INSERT权限收回的时候应该使用CASCADE（级联收回），否则拒绝执行该语句

如果U6或U7还从其他用户处获得对SC表的INSERT权限，则他们仍具有此权限，系统只收回直接或间接从U5处获得的权限。如下如U6的该权限还从dbo获得，所以当收回U5授予的权限之后，他仍然具有对SC表的INSERT权限。

执行上面的SQL语句后：

5. 数据库角色

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

角色是权限的集合。可以为一组具有相同权限的用户创建一个角色（所以在修改权限等的操作时对角色ROLE修改即可，不用再去麻烦地对每一个用户修改）

它的优点是：简化授权的过程

— — — — — — — — — — — — — — — —

1.角色的创建

CREATE ROLE <角色名>

2.给角色授权

GRANT <权限>[,<权限>]… ON <对象类型>对象名 TO <角色>[,<角色>]…

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

GRANT <角色1>[,<角色2>]…TO <角色3>[,<用户1>]… [WITH ADMIN OPTION]

ps：该语句把角色授予某用户，或授予另一个角色，授予者是角色的创建者或拥有在这个角色上的ADMIN OPTION（即授予者能传播该权限）

指定了WITH ADMIN OPTION则获得某种权限的角色或用户还可以把这种权限授予其他角色（能继续传播该权限）

一个角色的权限：直接授予这个角色的全部权限 + 其他角色授予这个角色的全部权限（这和上面例子中用户权限可以叠加起来（来自很多用户授予）是一样的，即这里某个角色的权限可以来自很多角色）

4.角色权限的收回

REVOKE <权限>[,<权限>]…ON <对象类型> <对象名>FROM <角色>[,<角色>]…

用户可以回收角色的权限，从而修改角色拥有的权限

REVOKE执行者是：①角色的创建者；②拥有在这个（些）角色上的ADMIN OPTION

🌟来看例 1：通过角色来实现将一组权限授予一个用户：

步骤如下：

1）首先创建一个角色 R1

CREATE ROLE R1;

2）然后使用GRANT语句，使角色R1拥有Student表的 SELECT、UPDATE、INSERT权限

GRANT SELECT, UPDATE, INSERT ON TABLE Student TO R1;-- T-SQLGRANT SELECT, UPDATE, INSERT ON Student TO R1;

（ps：这里UPDATE和SELECT的权限在图中看不到，需要把滚动条拉到下面，我就不截图啦）

3）将这个角色授予夏雨，夏雪，夏冰雹。使他们具有角色R1所包含的全部权限

（首先，需要创建夏雨，夏雪，夏冰雹玲这三个用户，因为这里只是需要用于做角色的实验，所以我就不新建登录名啦~ 能让他们能被授予权限就ok，实在想创建登录名的小伙伴看我上面讲解用户时写的就行~）

GRANT R1 TO 夏雨, 夏雪, 夏冰雹;

emmm，T-SQL中不支持此写法，官方文档CREATE ROLE (Transact-SQL)中有相关介绍：

附上链接：ALTER ROLE (Transact-SQL)

所以咱们可以通过下面的SQL语句来为角色R1添加成员，相当于为成员授予了角色R1拥有的权限：

ALTER ROLE R1 ADD MEMBER 夏雨;ALTER ROLE R1 ADD MEMBER 夏雪;ALTER ROLE R1 ADD MEMBER 夏冰雹;

（ps：需要注意的是，一条SQL语句只能添加一个角色！！）

4）可以一次性通过R1来回收夏雨的这3个权限

REVOKE R1 FROM 夏雨;

同样的因为T-SQL不支持此写法，所以我们通过删除角色成员的方式来达到回收其权限的目的

ALTER ROLE R1 DROP MEMBER 夏雨;

🌟来看例 2：角色的权限修改：

GRANT DELETE ON TABLE StudentTO R1;-- T-SQLGRANT DELETE ON StudentTO R1;

使角色R1在原来的基础上增加了Student表的删除权限

🌟来看例 3：

REVOKE SELECT ON TABLE StudentFROM R1;-- T-SQLREVOKE SELECT ON StudentFROM R1;

使R1减少了SELECT权限

— — — — — — — — — — — — — — — — — — — — — — — —

6. 强制存取控制方法

自主存取控制缺点：可能存在数据的“无意泄露”

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

（自主存取控制能够通过授权机制有效地控制其他用户对敏感数据的存取。但是由于用户对数据的存取权限是“自主”的，用户可以自由地决定将数据的存取权限授予何人、决定是否也将“授权”的权限授予别人。在这种授权机制下，仍可能存在数据的“无意泄露”）

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

强制存取控制（MAC）：

·保证更高程度的安全性

·用户不能直接感知或进行控制

·适用于对数据有严格而固定密级分类的部门：军事部门、政府部门

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

·主体是系统中的活动实体，即：数据库管理系统所管理的实际用户

·客体是系统中的被动实体，即：文件、基本表、索引、视图

敏感度标记（Label）：对于主体和客体，DBMS为它们每个实例（值）指派一个敏感度标记（Label）

敏感度标记分成若干级别：

绝密（Top Secret，TS）
机密（Secret，S）
可信（Confidential，C）
公开（Public，P）
TS>=S>=C>=P

主体的敏感度标记称为许可证级别（Clearance Level）

客体的敏感度标记称为密级（Classification Level）

强制存取控制规则：

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

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

简单记作：向下读，向上写

就比如，某个TS（绝密）密级的主体把一个密级为TS的数据恶意地降为P（公开），然后把它写回。这样原来是TS密级的数据大家都可以读到了，这样就导致了TS密级数据的泄露
另一方面，如果许可证级别大于客体的密级能写的话也很可怕，因为上级（领导）能在大家不知道的情况下随意修改，这，，，肯定是不行的
至于为什么等于，是因为自己写的东西自己肯定也要能看到吖，不然自己写完就看不到了，写错了或是想再看看也没办法了，no way，，，