ch24 存取控制

数据库安全最重要的一点就是确保只授权给有资格的用户访问数据库的权限,同时令所有未被授权的人员无法接近数据,这主要通过数据库系统的存取控制机制实现。
image.png

  1. 在自主存取控制方法中,用户对于不同的数据库对象有不同的存取权限,不同的用户对同一对象也有不同的权限,而且用户还可将其拥有的存取权限转授给其他用户。因此自主存取控制非常灵活
  2. 在强制存取控制方法中,每一个数据库对象被标以一定的密级,每一个用户也被授予某一个级别的许可证。对于任意一个对象,只有具有合法许可证的用户才可以存取。强制存取控制因此相对比较严格

自主存取控制 DAC

image.png
用户权限是由两个要素组成的:数据库对象和操作类型。定义一个用户的存取权限就是要定义这个用户可以在哪些数据库对象上进行哪些类型的操作。在数据库系统中,定义存取权限称为授权(authorization)。
image.png
列权限包括SELECT、REFERENCES、INSERT、UPDATE,其含义与表权限类似。需要说明的是,对列的UPDATE权限指对于表中存在的某一列的值可以进行修改。当然,有了这个权限之后,在修改的过程中还要遵守表在创建时定义的主码及其他约束。列上的 INSERT权限指用户可以插入一个元组,对于该插入的元组,授权用户可以插入指定的值(因为已经给了对应的列的选权限了),其他列或者为空,或者为默认值(因为没有给对应的列的权限)。在给用户授予列INSERT权限时,一定要包含主码的INSERT权限,否则用户的插入动作会因为主码为空而被拒绝。
INSERT INTO customers (customer_id, customer_name) VALUES (NULL, 'John Doe');
在这个例子中,我们向名为customers的表格中插入了一行数据。由于我们没有被授予主码的INSERT权限,所以我们无法为主码指定一个值。因此,我们将主码的值设置为NULL。但是,由于主码为空,这个插入操作将被拒绝。

授权:授予与收回

GRANT

image.png
其语义为:将对指定操作对象的指定操作权限授予指定的用户。发出该GRANT语句的可以是数据库管理员,也可以是该数据库对象创建者(即属主owner),还可以是已经拥有该权限的用户。接受权限的用户可以是一个或多个具体用户,也可以是PUBLIC,即全体用户
如果指定了 WITH GRANT OPTION子句,则获得某种权限的用户还可以把这种权限再授予其他的用户
如果没有指定 WITH GRANT OPTION子句,则获得某种权限的用户只能使用该权限,不能传播该权限。
SQL标准允许具有WITH GRANT OPTION的用户把相应权限或其子集传递授予其他用户,但不允许循环授权,即被授权者不能把权限再授回给授权者或其祖先
image.png
image.png
image.png
GRANT语句

  • 可以一次向一个用户授权
  • 可以一次向多个用户授权,如例4.2
  • 可以一次传播多个同类对象的权限,如例4.2
  • 可以一次完成对基本表和属性列这些不同对象的授权,如例4.4

REVOKE

image.png
image.png
SQL提供了非常灵活的授权机制。数据库管理员拥有对数据库中所有对象的所有权限,并可以根据实际情况将不同的权限授予不同的用户。
用户对自己建立的基本表和视图拥有全部的操作权限,并且可以用GRANT 语句把其中某些权限授予其他用户。被授权的用户如果有“继续授权”的许可,还可以把获得的权限再授予其他用户。
所有授予出去的权力在必要时又都可以用REVOKE 语句收回。
可见,用户可以“自主”地决定将数据的存取权限授予何人、决定是否也将“授权”的权限授予别人。因此称这样的存取控制是自主存取控制。

创建数据库模式的权限

GRANT和 REVOKE 语句向用户授予或收回对数据的操作权限。对创建数据库模式类的数据库对象的授权则由数据库管理员在创建用户时实现。
CREATE USER语句一般格式如下:
CREATE USER<username>[WITH] [DBA|RESOURCE|CONNECT];
对CREATE USER语句说明如下:

  • 只有系统的超级用户才有权创建一个新的数据库用户。
  • 新创建的数据库用户有三种权限:CONNECT、RESOURCE和DBA。

CREATE USER命令中如果没有指定创建的新用户的权限,默认该用户拥有CONNECT 权限。

  • 拥有CONNECT权限的用户不能创建新用户,不能创建模式,也不能创建基本表,只能登录数据库。由数据库管理员或其他用户授予他应有的权限,根据获得的授权情况他可以对数据库对象进行权限范围内的操作。
  • 拥有RESOURCE权限的用户能创建基本表和视图,成为所创建对象的属主,但不能创建模式,不能创建新的用户。数据库对象的属主可以使用GRANT 语句把该对象上的存取权限授予其他用户。
  • 拥有DBA权限的用户是系统中的超级用户,可以创建新的用户、创建模式、创建基本表和视图等;DBA拥有对所有数据库对象的存取权限,还可以把这些权限授予一般用户。

image.png

数据库角色

数据库角色是被命名的一组与数据库操作相关的权限,角色是权限的集合。因此可以为一组具有相同权限的用户创建一个角色,使用角色来管理数据库权限可以简化授权的过程。
image.png
image.png
R1相当于一个权限的集合
image.png

自主存取控制缺点

离散,分布式的,各管各的权限。收回了A的权限,但是A可能从其他方面拿到了权限。
可能存在数据的“无意泄露”

  • 原因:这种机制仅仅通过对数据的存取权限来进行安全控制,而数据本身并无安全性标记
  • 解决:对系统控制下的所有主客体实施强制存取控制策略

自主存取控制(MAC)能够通过授权机制有效地控制对敏感数据的存取。但是由于用户对数据的存取权限是“自主”的,用户可以自由地决定将数据的存取权限授予何人,以及决定是否也将“授权”的权限授予别人。在这种授权机制下,仍可能存在数据的“无意泄露”。
比如,甲将自己权限范围内的某些数据存取权限授权给乙,甲的意图是仅允许乙本人操纵这些数据。但甲的这种安全性要求并不能得到保证,因为乙一旦获得了对数据的权限,就可以将数据备份,获得自身权限内的副本,并在不征得甲同意的前提下传播副本。造成这一问题的根本原因就在于,
这种机制仅仅通过对数据的存取权限来进行安全控制,而数据本身并无安全性标记。要解决这一问题,就需要对系统控制下的所有主客体实施强自主存取控制(MAC)

强制存取控制 MAC

不再让权限管理成为离散式的,而是统一放在一起综合考量。
数据对象:数据库、表……
将用户、数据拆分为不同级别,以某种明确的方式定义两者的读写映射。
1679992684606.png
适用于:密级明确,因为灵活性低,所以适合有明确标准的

实体

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

  • 主体是系统中的活动实体
    • 数据库管理系统所管理的实际用户
    • 代表用户的各进程
  • 客体是系统中的被动实体,受主体操纵
    • 文件、基本表、索引、视图

敏感度标记

image.png
小兵(低权限)可以写可信的,通报给上级 — 由下至上可以写
将军讨论时,写信不小心泄漏到公开信(小兵)— 由上至下不可以写
机密同一级别:红军发起,那么蓝军也能看到 — 需要使用不同存取控制方式

强制存取控制规则

强制存取控制规则

  • 仅当主体的许可证级别大于或等于客体的密级时,该主体才能读取相应的客体
  • 仅当主体的许可证级别小于或等于客体的密级时,该主体才能写相应的客体
  • 强制存取控制(MAC)是对数据本身进行密级标记,无论数据如何复制,标记与数据是一个不可分的整体,只有符合密级标记要求的用户才可以操纵数据。

    假如A的级别大于B,即A拥有的保密信息等级更高,此时如果A有对B的写入权限,那么很可能会将保密信息写入B,B的等级较低,会将保密信息传播,造成泄密。
    所以只有小于等于时才能写入,保证秘密不向下传播扩散,只向上保留。
    EX1:校长知道的东西最多,大家说的话,校长都能看见.但是,校长看见了A的悄悄话,想要告诉跟A一个宿舍的B,却办不到,因为第二条规则。意思是校长只能把A说的发布给跟他同级的或者比他级别还高的。这就是保证秘密不向下传播扩散,只向上保留。

DAC + MAC

image.png

ch25 视图机制、审计、数据加密及其他

视图机制

需求:学生信息分别给对应宿舍长

  • 把要保密的数据对无权存取这些数据的用户隐藏起来,对数据提供一定程度的安全保护
  • 间接地实现支持存取谓词的用户权限定义
  • 对数据进行筛选,获得对部分元组的权限

image.png

审计

  • 审计功能把用户对数据库的所有操作自动记录下来放入审计日志(auditlog)中。
  • 审计员可以利用审计日志监控数据库中的各种行为,重现导致数据库现有状况的一系列事件,找出非法存取数据的人、时间和内容等。还可以通过对审计日志分析,对潜在的威胁提前采取措施加以防范。

审计通常是很费时间和空间的,所以数据库管理系统往往都将审计设置为可选特征,允许数据库管理员根据具体应用对安全性的要求灵活地打开或关闭审计功能。审计功能主要用于安全性要求较高的部门。
可审计事件有服务器事件、系统权限、语句事件及模式对象事件,还包括用户鉴别、自主访问控制和强制访问控事件。换句话说,它能对普通和特权用户行为、各种表操作、身份鉴别、自主和强制访问控制等操作进行审计。它既能审计成功操作,也能审计失败操作。
记录:有意义的操作和数据库状态
作用:分析操作是否异常
image.png

审计事件

  • 服务器事件:审计数据库服务器发生的事件,包含数据库服务器的启动、停止、数据库服务器配置文件的重新加载。
  • 系统权限:对系统拥有的结构或模式对象进行操作的审计,要求该操作的权限是通过系统权限获得的。
  • 语句事件:对SQL语句,如DDL、DML、DQL(Data Query Language,数据查询语言)及 DCL语句的审计。
  • 模式对象事件:对特定模式对象上进行的SELECT 或 DML操作的审计。模式对象包括表、视图、存储过程、函数等。模式对象不包括依附于表的索引、约束、触发器、分区表等。

审计功能

  • 基本功能,提供多种审计查阅方式:基本的、可选的、有限的,等等。
  • 提供多套审计规则,审计规则一般在数据库初始化时设定,以方便审计员管理。
  • 提供审计分析和报表功能。
  • 审计日志管理功能,
    • 防止审计员误删审计记录,审计日志必须先转储后删除
    • 对转储的审计记录文件提供完整性和保密性保护
    • 只允许审计员查阅和转储审计记录,不允许任何用户新增和修改审计记;等等。
  • 系统提供查询审计设置及审计记录信息的专门视图。对于系统权限级别、语句级别及模式对象级别的审计记录也可通过相关的系统表直接查看。(就是说不同级别,不同类型的审计信息有不同的表专门查看)

审计级别

审计一般可以分为用户级审计和系统级审计。

  • 用户级审计是任何用户可设置的审计
    • 主要是用户针对自己创建的数据库表或视图进行审计
    • 记录所有用户对这些表或视图的一切成功和(或)不成功的访问要求以及各种类型的SQL操作。
  • 系统级审计
    • 只能由数据库管理员设置
    • 用以监测成功或失败的登录要求、监测授权和收回操作以及其他数据库级权限下的操作。

审计语句

image.png
审计设置以及审计日志一般都存储在数据字典中。必须把审计开关打开(即把系统参数 audit_trail 设为true),才可以在系统表SYS_AUDITTRAIL中查看到审计信息。
数据库安全审计系统提供了一种事后检查的安全机制。安全审计机制将特定用户或者特定对象相关的操作记录到系统审计日志中,作为后续对操作的查询分析和追踪的依据。通过审计机制,可以约束用户可能的恶意操作。

数据加密

image.png

存储加密

透明:需要软硬件资源
image.png

传输加密

image.png

其他安全性保护

推理控制:

  • 推理访问方式:通过自己的URL,推理别人的URL,得到别人的数据。解决:乱序映射或者权限控制
  • 推理数据内容:对答案,知道我的成绩,推理出他的成绩

隐蔽信道:附加需要传递的数据

  • 文件系统:要求传递图片 — 在图片中嵌入docx文档
  • 插入数据会产生0,1的结果返回,多次访问能够形成0 1 串

image.png