数据库16-数据库安全

数据库安全

概念

数据共享必然带来数据安全问题，我们认为只允许有合法使用权限的用户允许访问他存取的数据；

数据库系统的安全保护措施是否有效是数据库系统主要的指标，数据库的安全性和计算机系统的安全是紧密联系、互相支持的；

数据库可能的破坏方式

• 数据库被无意破坏
  • 并发存取引起的数据异常
  • 数据分布存储的不一致问题
  • 逻辑错误造成更新事务未遵守数据一致原则
  • 事务处理中系统崩溃
• 数据库被恶意破坏
  • 未经授权的读取，修改和破坏数据

对策：

• 针对无意破坏：完整性约束控制，并发控制，数据库恢复
• 针对恶意破坏：数据库访问控制，身份鉴定，安全审计，数据加密

数据库安全性：保护数据库，防止因为用户非法使用造成数据的泄露，破坏或更改；

数据的保密：用户合法访问到机密数据后能否保证不泄密，需要指定法律等规则保证；

计算机系统安全性：

• 保护系统中的硬件，软件和数据，防止因为偶然或恶意的原因使得系统被破坏，数据更改或泄露；
• 需要建立立体防御：进不来、看不见、看不懂、改不掉、跑不了
• 可能包括三类安全性问题：技术安全，管理安全和政策法律

数据库系统的安全框架：

• 网络系统层次
  • 物理层面上避免入侵者进行物理破坏；
  • 网络层面上采用防火墙、入侵检测技术等手段阻止外部入侵。
• 操作系统层次
  • 操作系统安全策略、安全管理策略和数据安全
• 数据库系统层次
  • 用户标识和鉴别、存取控制、数据分级、视图机制、审计、数据加密

自主访问控制

概念

主体(Subject): 提出访问资源具体请求，是某一操作动作的发起者, 可能是某一用户，也可以是用户启动的进程、服务和设备等

客体(Object): 被访问资源的实体，所有可以被操作的信息、资源、对象都可以是客体, 可以是信息、文件、记录等集合体，也可以是网络上硬件设施

控制策略(Attribution):主体对客体的相关访问规则集合，即属性集合, 访问策略体现了一种授权行为，也是客体对主体某些操作行为的默认

自主访问控制的特点：

• 控制方式是自主的
  • 由客体的属主对自己的客体进行管理
  • 由属主自己决定是否将自己的客体访问权或部分访问权授予其他主体
  • 在自主访问控制下，用户可以按自己的意愿，有选择地与其他用户共享他的文件
• 可以在主体之间相互转让权限的访问控制
  • 对用户访问数据库中各种资源（包括表、视图、程序等）的权利（包括创建、查询 、更新、执行等）的控制
  • 一个用户建立了一个数据对象就自动具有了对这个数据对象的所有权利
  • 同一用户对于不同的数据对象有不同的存取权限，不同的用户对同一对象也有不同的权限，用户还可将其拥有的存取权限转授给其他用户
• C2级，灵活

权限

• 访问数据权限
  • SELECT:允许读取数据，不能修改数据
  • INSERT：允许插入新数据，不能修改已有数据
  • UPDATE：允许修改数据，不能删除数据
  • DELETE：允许删除数据
• 修改模式权限
  • INDEX：允许建立/删除索引
  • CREATE：允许建立表
  • ALTER：允许对表属性增加删除
  • DROP：允许删除表
• 其他
  • CONNECT: 允许连接数据库
  • REFERENCE:允许根据表的完整性约束中引用一个参照关系
  • USAGE: 授权用户使用指定域
  • TRIGGER：授权用户定义表中触发器
  • EXECUTE：授权用户执行函数/过程
  • UNDER：授权用户建立类的子类

授权

赋予用户一定权利，已操作数据对象

• 对象创建者自动拥有其所有权限
• 授权可由DBA授予，也可以由对象创建者授予

语法如下：

GRANT {all privileges|privilege{. privilege….}}
 ON [TABLE] tablename|viewname
 TO [PUBLIC|user_name{,user_name…}]
 [WITH GRANT OPTION]

授权的粒度：用于指定可以操作的数据对象的范围

• 关系数据库中的数据对象粒度：数据库/表/属性列/行
• 它是衡量授权机制是否灵活的一个重要指标
• 授权定义中数据对象的粒度越细，即可以定义的数据对象的范围越小，授权子系统就越灵活 ，但系统定义与检查权限的开销会相应增大
• 能否提供与数据值有关的授权反映了授权子系统精巧程度

视图授权

• 对视图也应可以授权
• 要授予其他用户与访问视图相关的权利，授权者必须拥有该视图（而且在视图所引用基本表或视图上有必要的权限）或已经通过WITH GRANT OPTION被授予了这些权限
• 若要在一个视图上授予插入、删除或更新权限，视图必须是可更新的
• 用户要建立视图，首先必须要有对所引用基本表或视图的SELECT权利

收回权限

从一个用户那里收回权限可能导致其他用户也失去该权限。这一行为称为级联回收 CASCADE。在大多数数据库系统中，级联回收是默认行为。

语法如下：

REVOKE [WITH GRANT OPTION FOR]{ALL PRIVILEGES|privilege{. Privilege….}}
 ON [TABLE] tablename|viewname
 FROM [PUBLIC|user_name{,user_name…}]
 [RESTRICT|CASCADE]

示例：

GRANT SELECT ON RecipeDetail TO LiXia；
GRANT SELECT ON RecipeMaster TO LiXia WITH GRANT OPTION；
GRANT UPDATE（Mprice） ON Medicine TO WangHao；
GRANT REFERENCE（Mno）ON Medicine TO ZhangYang；
GRANT INSERT，DELETE ON RecipeDetail TO MengFan WITH GRANT 
OPTION；
REVOKE SELECT ON RecipeDetail FROM LiXia；
REVOKE UPDATE（Mprice）ON Medicine FROM WangHao；
REVOKE GRANT OPTION FOR SELECT ON RecipeMaster FROM LiXia；
REVOKE SELECT ON RecipeMaster FROM LiXia RESTRICT；

授权图

用授权图来表示授权在用户之间的传递，图中的结点表示用户，如果用户$i$将权限传递给了$j$，则在图中增加一条 边$i\to j$。图的根是DBA 或对象创建者

用户具有授权当且仅当存在从授权图的根到代表该用户的结点的路径;

上述示例的授权图和收回权限图如下：

授权方法

RBAC方法：基于角色的授权

根据管理中相对稳定的职权和责任来划分角色

• 将访问许可权分配给一定的角色
• 用户通过饰演不同的角色获得访问许可权。

角色可以看作是一组操作的集合，不同的角色具有不同的操作集。

角色是访问控制中访问主体和受控对象之间的一座桥梁（授权模板）；

角色与用户关系：一个用户可经授权而拥有多个角色，一个角色可有多个用户组成 ；

角色与许可关系：每个角色拥有多种许可，每个许可也可以授权给多个不同的角色，每个操作可施加与多个客体，每个客体可接受多个操作；

例如

• 创建角色CREATE ROLE Admin;

• 角色授权GRANT SELECT ON RecipeMaster TO Admin;

• 角色授权给用户或其他角色：

  GRANT Admin TO LiXia;
   CREATE ROLE Manager;
   GRANT Admin to Manager;
   GRANT Manager TO WangHao;

强制访问控制

MAC的特征：

• 对所有主体（系统中的活动实体，如用户）及其所控制的客体（如进程、文件、基 表、视图等）实施强制访问控制
• B1级，严格
• 每一个数据对象被标以一定的密级，每一个用户也被授予某一个级别的许可证，对 于任意一个对象，只有具有合法许可证的用户才可以存取

敏感度标记（Label）

• 对于主体和客体，DBMS为它们每个实例（值）指派一个敏感度标记
• 敏感度标记级别：绝密，机密，可信，公开
• 主体的敏感度标记称为许可证级别，客体的敏感度标记称为密级
• MAC机制就是通过对比主体的Label和客体的Label，最终确定主体是否能够存取客体

强制存取控制规则

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

DAC与MAC共同构成DBMS的安全机制

• 先进行DAC检查，通过DAC检查的数据对象再由系统进行MAC检查
• 只有通过MAC检查的数据对象方可存取。

审计

审计是一种事后追责手段，体现在以下操作：

• 启用一个专用的审计日志（Audit Log），将用户对数据库的所有操作记录在上面
• DBA可以利用审计日志中的追踪信息，找出非法存取数据的人
• C2以上安全级别的DBMS必须具有审计功能，体现“跑不了”

审计负荷：

• 审计很费时间和空间
• DBA可以根据应用对安全性的要求，灵活地打开或关闭审计功能 ，执行SET AUDIT ON/OFF