数据库的安全性

安全性

安全性保护手段

  • 用户标识与鉴别
  • 自主存取控制
  • 强制存取控制
  • 视图
  • 审计和数据加密

数据库的安全性是指保护数据库防止因用户非法使用数据库造成数据泄露、更改或破坏

数据库安全保护分层

  • 物理层
  • 人际层
  • 网络层
  • 操作系统层
  • 数据库系统层

物理层的安全性是指计算机系统所位于的节点必须物理上受到保护,以防止入侵者强行闯入或暗中潜入(保护机房之类的)

人际层,对用户的授权应该格外小心,以减少授权用户因为利益将数据泄密或给入侵者提供访问机会的可能性(重要信息的访问权限不可以随便授权给用户)

网络层,几乎所有的数据库系统都允许通过网络进行远程访问,因此不管是在因特网还是在企业私有网络内,网络软件的安全性和物理安全性一样重要

操作系统层,DBMS是建立在操作系统支持之上的,因此操作系统安全性方面的弱点有可能成为对数据库进行未授权访问的一种手段

数据库系统层,指的是数据库层面采用相应的安全措施,保证数据是安全的

数据库安全保护的任务

  • 防止未经过授权的人员访问数据,确保敏感信息没有被不需要知道的人读取到
  • 防止未经过授权的人员删除和修改数据
  • 监视对数据的访问和更改等使用情况

用户标识与鉴别

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

基本做法是为每一个进入DBMS的用户分配一个用户标识符,并在整个DBMS的生命周期实现用户标识符的唯一性

用户标识常分为两级

  • 操作系统级

由操作系统提供一定的方式,让用户标明自己的身份,当用户要进入系统时,由操作系统进行确认

  • 数据库管理系统级

DBA为每个申请使用数据库的用户创建一个用户标识符和确认自己身份的方式,当用户要访问数据库时,由数据库管理系统核对用户提供的身份标识和口令验证

  • 口令

口令的长度,复杂度和最常使用期限

  • 更新方式的用户标识和鉴别

使用动态产生的新口令登录数据库管理系统,比如短信密码或动态令牌方式

利用只有用户具有的物品鉴别用户:可以使用磁卡、IC卡等作为用户身份的凭证,但必须有相应的读卡设备

利用用户的个人特征鉴别用户:指纹、视网膜、声波、人脸等

自主存取控制

其主要思想是通过授权使得有资格的用户获得访问数据库的权限,而未被授权的用户不能够访问数据库

存取控制有两种

  • 自主存取控制DAC

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

基本所有DBMS都支持DAC

  • 强制存取控制MAC

每一个数据对象都被标记一定的个密级,每个用户也被授予某一许可证级别,只有具有一定许可证级别的用户才能访问具有一定密级的数据对象

MAC比较严格,只有安全级别比较高的DBMS才提供对他的支持

存取控制的任务

授权和合法权限检查

授权

DCL中提供了相应的授权语句,允许用户自主的定义存取权限,并将用户的授权登记在数据字典中

合法权限检查

当用户发出存取数据库的操作请求后,DBMS将查找数据字典,根据用户权限进行合法权限的检查,如果用户的操作请求超出了自身的权限,系统将拒绝执行此操作

上表是存取控制的数据对象以及对象上的操作类型

权限的授予与回收

SQL语句如下:

grant <权限列表> on <对象名> to <用户/角色列表> [with grant option]

将一种或者多种存取权限赋予一个或者多个用户或角色

可选项with grant option表示被授权的用户可以将权限转授予给他人,缺省时,不可以转授予

权限列表是:select, insert, update, delete, references, all privileges

对象名可以是基本表或者视图

用户/角色列表:可以是数据库合法用户、所有用户public或者角色的列表

上面是一些例子

回收授权

revoke <权限列表>on <对象名> from <用户/角色列表> {cascade | restrict}

如果用户或角色列表转授予给其他人权限,使用restrict会报错,不会回收权限,如果使用cascade则会连带着回收其他人被此用户/角色转授予的权限

角色

SQL-99支持角色

使用角色进行授权必须先创建角色,将数据库对象上的存取权限授予角色,才能够将角色授予用户,使得用户拥有角色所具有的所有存取权限

SQL-99允许收回赋予角色的存取权,收回授予用户的角色

创建的语法如下:

create role <角色名>

如下面的例子:

角色授权语法如下:

grant <角色列表> to <用户/角色列表> [with admin option] 

角色列表是一个或多个角色名,中间用逗号隔开

用户角色列表是一个或多个角色名或用户名,中间用逗号隔开

可选项表示是否具有转授权权限

收回角色权限:

revoke all priviliges on Loan,Borrower from Teller;

收回角色:

revoke <角色列表> from <用户/角色列表> {cascade | restrict}

强制存取控制

自主存取控制无法阻止副本的非授权传播

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

  • 主体是系统中的活动实体,可以是DBMS管理的实际用户或代表用户的各个进程
  • 客体是系统中的被动实体,是受主体操纵的对象。如文件、基本表、索引、视图等

对于主体和客体,DBMS为它们每个实例值指派一个敏感度标记,敏感度标记分为若干级别:

  • 绝密
  • 机密
  • 秘密
  • 公开

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

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

MAC机制就是通过对比主体和客体之间的敏感度标记,确定主体是否能够存取客体

当某一用户或主体注册进入系统时,系统要求他对任何客体的存取必须遵循下面两条规则:

  • 仅当主体的许可证级别大于等于客体的密级时,该主体才能够读取相应的客体
  • 仅当主体的许可证级别小于等于客体的密级时,该主体才能够写相应的客体
  • MAC比DAC具有更高的保护级别,因此支持MAC的系统必须支持DAC,由DAC与MAC共同构成了DBMS安全机制
  • 同时支持二者保护的系统称为多级安全系统
  • 在多级安全系统中,系统首先进行DAC检查,对通过DAC检查的允许存取的数据对象,再由系统自动进行MAC检查,只有通过MAC检查的访问才是允许的

视图与授权

  • 视图可以隐蔽一些不希望用户看到的数据
    • 可以与授权结合,限制用户只能访问所需要的数据,实现一定程度上的安全保护
  • 利用视图实现安全保护的基本思想是:
    • 首先通过定义视图屏蔽掉一部分需要对某些用户保密的数据
    • 然后在视图上定义存取权限,将对视图的访问权限授予这些用户而不允许他们直接访问定义视图的基本表

注意

创建视图的用户不一定能够获得该视图上的所有权限

为了有效阻止用户透过视图越权访问数据库,创建视图的用户在视图上所获得的权限不能够超过他在定义视图的基本表上拥有的权限

下面是一个例子:

其他安全手段

审计和数据加密等

审计日志记录了谁、什么时间、操作了哪些数据、操作前后的值是什么。利用审计日志中的追踪信息,可以重现导致数据库现有状况的一系列事件,找出非法存取数据的用户,时间和内容等。由于审计需要消耗大量的空间和时间,因此DBMS通常将其作为可选特征。

  • 1
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

_南明_离火_

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值