第4章:数据库安全性

第4章:数据库安全性

基于SQLServer学习使用,与MySQL有略微差别!

4.1、数据库安全性控制

对数据库进行安全性控制的常用机制

  1. 用户标识和鉴定
  2. 存取控制
  3. 视图机制
  4. 审计
  5. 数据加密

4.2、用户标识和鉴定

  • 系统提供的最外层安全保护措施
  • 基本方法
    • 系统提供一定的方式让用户标识自己的名字或身份。
    • 每次用户要求进入系统时,由系统核对用户提供的身份标识。
    • 通过鉴定后才提供系统使用权。

4.3、存取控制

4.3.1、存取控制概述

  • 存取控制机制作用

    • 只允许用户来存取允许他存取的数据。
    • 不允许用户存取的数据,该用户无法接触。
  • 存取控制机制的实现方式

    • 授权
  • 存取控制机制的组成

    • 定义存取权限
      • 在数据库系统中,为了保证用户只能访问他有权存取的数据,必须预先对每个用户定义存取权限,这些权限最终被存放在数据字典中,被称安全规则或授权规则
    • 检查存取权限
      • 每当用户发出存取数据库的操作请求后,DBMS查找数据字典,根据安全规则进行合法权限检查,若用户的操作请求超出了定义的权限,系统将拒绝执行此操作。
  • 存取权限定义和存取权限检查机制一起组成了DBMS的安全子系统

  • 常用存取控制方法

    • 自主存取控制(Discretionary Access Control ,简称DAC)
    • 强制存取控制(Mandatory Access Control,简称 MAC)(一般用于军用系统,对安全性要求非常高)

4.3.2、自主存取控制(DAC)

  • 自主存取控制方法

    • 同一用户对于不同的数据对象有不同的存取权限
    • 不同的用户对同一对象也有不同的存取权限
    • 用户还可将其拥有的存取权限转授(传播)给其他用户
  • 定义存取权限称为授权

  • 谁可以授权

    • DBA(数据库管理员)、表的建立者(即表的属主)、拥有一定权限的其他用户
  • 如何授权

    • SQL语句:grant

下面主要讲述的是对 SQLServer 中的用户进行的授权操作:

  • Login(登录)(服务器级别)
    是服务器一级的概念,表示登录某个服务器的凭证,比如在服务器A上有一个数据库,那么想要访问该数据库,第一步要做的事情就是先登录到持有该数据库的服务器A上。

  • User(用户)(数据库级别)
    有了一个Login,表明你可以登录持有数据库的服务器A ,并不表明你能够访问数据库,你只有成为数据库的User,才能访问该数据库。

  • Login和User的关系

    • 每个User必须对应一个Login。
    • 每个Login可以对应多个User,前提是User在不同的数据库中
graph LR C{Login} C --> D[User1] C --> E[User2] C --> F[User3]

1、创建登录语法::

create login <登录名> with password = <'密码'>

示例:

-- 在管理员权限下运行
create login U1login with password = '123' 

2、创建用户语法:

create user <用户名> for login <登录名>

示例:

create user U1 for login U1login 
  • 授予用户对某个数据对象具有某种操作权限,称之为对象授权
  • 在SQLServer中还有另外一种授权——语句授权

3、grant 对象授权语句语法:

grant <权限>[, <权限>, ... ]
	on <对象名>[, <对象名>, …]
	to <用户>[, <用户>, ...]
	[with grant option];
  • 指定了 with grant option 子句:获得权限的用户还可以把这种权限再授予别的用户。
  • 没有指定 with grant option 子句:获得权限的用户只能使用该权限,不能传播该权限

注意:授权时如果有 with grant option,回收权限时要带着 cascade,代表级联操作

可以授予的<权限>:

对于基本表而言:

  • insert、delete、update、select
  • all

对于视图而言:

  • insert、delete、update、select
  • all

对于属性列而言:

  • select、update
  • all

示例:

-- 把查询student表的权限授给用户U1
grant select on student to u1
-- 把查询sc表的sno列的权限授给用户U1
grant select(sno) on sc to u1
-- 把查询SC表的cno、grade列的权限授给用户U1
grant select(cno,grade) on sc to u1
grant select(cno), select(grade) on sc to u1
-- 把查询course表的cpno列的权限授给用户U1,允许U1传播该权限
grant select(cpno) on course to u1 with grant option
-- U1可以执行下面操作
grant select(cpno) on course to U2;

-- 把删除course表中元组的权限授给用户U1
grant delete on course to u1
-- U1是否可以执行下面操作?
delete from course where cname = '物理' 
-- 不可以,因为U1没有对course的cname 的查询(select)权限
grant select(cname) on course to u1

4、grant 语句授权的一般格式:

grant <权限>[, <权限>, ... ]
	to <用户>[, <用户>, ...]
	[with grant option];

<语句权限>:

  • create database
  • create table
  • create view

示例:

-- 把创建表的权限授给用户U1
grant create table to U1;
-- 把创建视表的权限授给用户U2,允许用户传播该权限
grant create table to U2 with grant option

5、收回对象权限语法:

revoke <权限>[, <权限>, …] 
	on <对象名>[, <对象名>, …]
	from <用户>[, <用户>, …]
	[cascade]

示例:

-- 授予用户U1查询 sc 表的sno列的权限
grant select(sno) on sc to u1
-- 把用户U1查询SC表的sno列的权限收回
revoke select(sno) on sc from u1
-- 把查询course表的权限授予用户U1,允许用户传播该权限
grant select on course to u1 with grant option
-- 把上面授予用户U1查询course表的权限收回
revoke select on course from u1 				-- 【错误】
revoke select on course from u1 cascade -- 【正确】 级联撤销

6、收回语句权限语法:

revoke <权限>[, <权限>, …] 
	from <用户>[, <用户>, …]
  [cascade]

示例:

-- 把创建表的权限授给用户U1
grant create table to U1;
-- 把上面授予用户U1创建表的权限收回
revoke create table from u1

SQLServer中的架构(了解即可)

架构的引入就是为了解决数据库对象太多不好管理的问题。这是数据库管理就变成了用户-架构-数据库对象的模式了

数据库对象:所有的表、视图、存储过程、触发器都称为数据库对象。
架构:微软的官方说明(MSDN): “数据库架构是一个独立于数据库用户的非重复命名空间,您可以将架构视为对象的容器”,因此,我们要访问一个数据库对象的时候,通常应该是引用它的全名“架构名. 对象名”。

架构(schema)
从 SQL Server 2005 开始,每个对象都属于一个数据库架构。可以在数据库中创建和更改架构,并且可以授予用户访问架构的权限。

架构的特点:

  1. 一个架构中不能包含相同名称的对象,相同名称的对象可以在不同的架构中存在。
  2. 一个架构必须有一个所有者。
  3. 一个数据库用户拥有多个架构。
  4. 架构的所有权可以改变。

创建架构:

create schema <架构名> authorization <所有者>

示例:

create schema schema2 authorization u1 -- 架构权限
grant create,insert table to u1 	     -- 创建表的权限
-- u1上运行
create table schema2.t2( c1 int )
insert into schema2.t2 values(100)

对于查询、删除,修改而言:

1)登陆数据库的权限

2)查询、删除、修改数据库对象的权限

对于新增而言:

1)登陆数据库的权限

2)架构的权限

3)查询、删除、修改数据库对象的权限

SQLServer中的角色

角色可以简化授权

数据库角色:数据库角色是权限的集合

创建角色:

create role <角色名>

示例:

-- 创建登录账号
create login u1login with password = '123'
-- 创建用户 u1
create user u1 for login u1login
-- 将数据库用户 u1 添加到数据库角色 role1 中,管理员下执行
sp_addrolemember 'role1', 'u1'

为角色授权与为用户的授权语法一致;

收回角色与为收回用户的权限语法一致;

4.3.3、强制存取控制(MAC)

在MAC方法中,DBMS所管理的全部实体被分为主体客体两大类

  • 主体:是系统中的活动实体
    • DBMS所管理的实际用户
    • 代表用户的各进程
  • 客体:是系统中的被动实体,是受主体操纵的
    • 文件

    • 基本表

    • 索引

    • 视图

对于主体和客体,DBMS为它们每个实例指派一个敏感度标记(Label)

  • 敏感度标记分成若干级别
    • 绝密(Top Secret)
    • 机密(Secret)
    • 可信(Confidential)
    • 公开(Public)
  • 主体的敏感度标记称为许可证级别(Clearance Level)
  • 客体的敏感度标记称为密级(Classification Level)

强制存取控制实现的基本原理:

? MAC机制就是通过对比主体的Label和客体的Label,最终确定主体是否能够存取客体
当某一主体凭借它的许可证级别注册进入系统后,系统要求他对任何客体的存取必须遵循下面两条规则:
(1)仅当主体的许可证级别>=客体的密级时,该主体才能读取相应的客体;(不上读)
(2)仅当主体的许可证级别<=客体的密级时,主体能写客体(不下写)

强制存取控制(MAC)特点:

  • MAC是对数据本身进行密级标记
  • 无论数据如何复制,标记与数据是一个不可分的整体
  • 只有符合密级标记要求的用户才可以操纵数据,从而提供了更高级别的安全性

自主存取控制(DAC)特点

  • 优点
    • 能够通过授权机制有效地控制其他用户对敏感数据的存取
  • 缺点
    • 可能存在数据的“无意泄露”
    • 仅仅通过对数据的存取权限来进行安全控制,而数据本身并没有安全性标记。

4.4、视图机制

原因:grant 语句不支持 where 条件(存取谓词)

? 假设现在有一张总的学生表,里面有各种系别的学生信息,有计算机系、数学系、外语系…,我们现在希望某一个用户只能查询某一系别的学生信息,而不是所有系的学生都可以看到,这时可以通过视图机制来实现权限控制!

假设我们希望用户 u2 只能查询计算机系的学生信息,那么我们只需要建立查询计算机系学生信息的视图,通过对视图进行权限控制,来把一些数据进行隐藏。

例如:

-- 先建立计算机系学生的视图CS_Student
CREATE VIEW CS_Student
	AS 
	SELECT * FROM Student 
			WHERE Sdept='CS'
grant SELECT ON CS_Student TO  U1
-- u2能检索、增删改计算机系学生的信息
GRANT ALL PRIVILIGES ON  
	CS_Student TO U2 

总之,视图机制通过把要保密的数据对无权存取这些数据的用户隐藏起来来实现

4.5、审计(Audit)

什么是审计?

  • 将用户对数据库的所有操作记录在审计日志(Audit Log)上面
  • DBA利用审计日志找出非法存取数据的人、时间和内容

C2以上安全级别的DBMS必须具有审计机制

posted on 2020-05-08 18:47  demo-arch  阅读(541)  评论(0)    收藏  举报