数据库---安全性和完整性

数据库的安全性

数据库的不安全因素

• 数据库的安全性是指保护数据库以防止不合法使用所造成的数据泄露、更改或破坏。

• 非授权用户对数据库的恶意存取和破坏。
  数据库中重要或敏感的数据被泄露。
  安全环境的脆弱。

数据库安全性控制

• 计算机系统的安全模型
  
• 数据库管理系统的安全性控制模型
  

用户身份鉴别

• 静态口令：一般由用户自己设定，简单，易被攻击，安全性较低。
• 动态口令鉴别：较安全。一次一密。
• 生物特征鉴别：生物特征指生物体唯一具有的、可测量、识别和验证的稳定生物特征。安全性较高。
• 智能卡鉴别：智能卡是一种不可复制的硬件，内置集成电路的芯片，具有硬件加密功能。实际应用中一般采用个人身份识别码PIN和智能卡结合的方式。

存取控制

• 存取控制主要包括定义用户权限（并将用户权限登记到数据字典中）和合法权限检查两部分。用户权限和合法权限检查机制一起组成了数据库管理系统的存取控制子系统。

自主存取控制方法DAC

• 自主存取控制方法中，用户对不同的数据库对象有不同的存取权限，不同的用户对同一对象也有不同的权限。用户可以将其拥有的权限转授给其他用户。较灵活。

• 强制存取控制方法：每个数据库对象被标有一定的密级，每个用户被授予一个级别的许可证，较严格。

• 用户权限由数据库对象和操作类型组成。定义用户存取权限就是定义用户可以在哪些数据库对象上进行哪些类型的操作。

  定义存取权限称为授权。

  用户权限定义和合法权检查机制一起组成了DBMS的安全子系统。
  

授权：授予与收回

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

  将对指定操作对象的指定操作权限授予指定的用户。

  发出GRANT语句的可以是DBA，数据库对象创建者（即属主Owner）或者是拥有该权限的用户。

  按受权限的用户可以是一个或多个具体用户，也可以是PUBLIC（全体用户）

  若指定了WITH GRANT OPTION子句，则获得该权限的用户可以把这种权限授予其他用户。不允许循环授权。

  对属性列的授权时必须明确指出相应属性列名（权限（列名））

• REVOKE
  授予的权限可以由DBA或其他授权者用REVOKE语句收回。

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

  CASCADE：系统收回直接或间接从某用户处获得的权限。

  DBA拥有所有对象的所有权限，可以将不同的权限授予不同的用户。

  用户对自己建立的基本表拥有全部的操作权限并且可以用GRANT子句把其中某些权限授予其他用户。

• 创建数据库模式的权限
  对数据库模式一类的数据库对象的授权由DBA在创建用户时实现。

  CREATE USER < username>
  [WITH][DBA | RESOURCE | CONNECT]

  只有系统的超级用户有权建立一个新的数据库用户。新创建的用户有三种权限：CONNECTION（默认，只能登陆数据库），RESOURCE（能创建基本表和视图，称为所创建对象的属主，不能创建模式，不能创建新的用户）和DBA（可以创建新的用户，模式，基本表和视图，拥有对所有数据库对象的存取权限）。

数据库角色

• 数据库角色是被命名的一组与数据库操作相关的权限，角色是权限的集合。可以为一组具有相同权限的用户创建一个角色，可以简化授权的过程。

• 角色的创建：CREATE ROLE <角色名>

• 角色的授权
  GRANT <权限>［，<权限>］…
  ON <对象类型>对象名
  TO <角色>［，<角色>］…

• 将一个角色授予其他的角色或用户
  GRANT <角色1>［，<角色2>］…
  TO <角色3>［，<用户1>］…
  [WITH ADMIN OPTION]

  一个角色所拥有的权限是授予他的所有角色所拥有的权限的总和。

• 角色权限的收回
  REVOKE <权限>［，<权限>］…
  ON <对象类型> <对象名>
  FROM <角色>［，<角色>］…

强制存取控制方法MAC

• 自主存取控制方法可能存在数据的“无意泄露”，这种机制仅仅通过对数据的存取权限来进行安全控制，而数据本身并无安全性标记。可以通过对系统控制下的所有主客体实施强制存取控制策略来解决。

  强制存取控制（MAC)是指系统为保证更高程度的安全性采取的强制存取检查手段。适用于对数据有严格而固定密级分类的部门。

  所有的实体被分为主体和客体两大部分。主体是系统中的活动实体，包括DBMS所管理的实际用户和代表用户的各进程。客体是系统中的被动实体，是受主体操纵的包括文件、基本表、索引、视图等。

  DBMS为他们的实例指派一个敏感度标记（Label）。敏感度标记被分成若干个等级（绝密（Top Secret）、机密（Secret）、可信（Confidential）、公开（Public））。密级的次序是TS>=S>=C>=P。

  主体的敏感度标记称为许可证级别（Clearance Level），客体的敏感度标记称为密级（Classification Level）。强制存取控制机制就是通过对比主体的敏感度标记和客体的敏感度标记，最终确定主体是否能够存取客体。

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

  仅当主体的许可证级别小于或等于客体的密级时，该主体才能写相应的客体。用户可以为写入的数据赋予高于自己许可证级别的密级。这样一旦数据被写入，用户自己也不能在读该数据对象。

  MAC是对数据本身进行标记，无论数据如何复制，标记与数据是一个不可分割的整体。

• DAC与MAC共同构成DBMS的安全机制。实现MAC时要首先实现DAC。

  较高安全性级别提供的安全保护要包含较低级别的所有保护。

视图机制

• 把要保密的数据对无权存取这些数据的用户隐藏起来，对数据提供一定程度的安全保护。间接实现了支持存取谓词的用户权限定义。

审计

• 将用户对数据库的所有操作记录下来放入审计日志（Audit Log）中。审计员可以利用审计日志监控数据库中的各种行为，重现导致数据库现有状况的一系列事件，找出非法存取数据的人、时间和内容。

  能对普通和特权用户行为、各种表操作、身份鉴别、自主和强制访问控制等操作进行审计。既能审计成功操作，也能审计失败操作。

  审计设置以及审计日志一般都存储在数据字典中。必须把审计开关打开（把系统参数audit_trail设为true），才可以在系统表SYS_AUDITTRAIL中查看到审计信息。

• 审计事件
  服务器事件：数据库服务器的启动、停止、数据库服务器配置文件的重新加载。

  系统权限：对系统拥有的结构或模式对象进行操作的审计。

  语句事件：

  模式对象事件：对特定模式对象上进行的操作的审计。

• 审计功能
  基本功能，提供多种审计查阅方式：基本的、可选的、有限的等等。

  提供多套审计规则，审计规则一般在数据库初始化时设定，以方便审计员管理。

  提供审计分析和报表功能。

  审计日志管理功能，包括为了防止审计员误删审计记录，审计日志必须先转储后删除。

  系统提供查询审计设置及审计记录信息的专门视图。

• 用户级审计任何用户可设置的审计，主要是用户针对自己创建的数据库表或视图进行审计，记录所有用户对这些表或视图的一切成功和（或）不成功的访问要求以及各种类型的SQL操作。

  系统级审计只能由DBA设置，用以监测成功或失败的登录要求、监测GRANT和REVOKE操作以及其他数据库级权限下的操作。

• AUDIT语句：设置审计功能
  NOAUDIT语句：取消审计功能

数据加密

• 防止数据库中数据在存储和传输中失密的有效手段

• 加密的基本思想：根据一定的算法将原始数据（明文）变换为不可直接识别的格式（密文），从而使得不知道解密算法的人无法获知数据的内容。

• 存储加密

  透明存储：内核级加密保护方式，对用户完全透明。在数据写到磁盘时对数据进行加密，授权用户读取数据时再对其进行解密。数据库的应用程序不需要做任何的修改，只需要在创建表语句中说明需要加密的字段即可。

  非透明存储：通过多个加密函数实现。

• 传输加密
  
  
  
  

其他安全性保护

• 数据库安全机制的设计目标：试图破坏安全的人所花费的代价 >> 得到的利益
  
  
  
  

数据库的完整性

• 完整性是指数据的正确性和相容性。
  正确性：符合现实世界的语义，反应当前实际情况。

  相容性：数据库同一对象在不同的关系表中的数据是符合逻辑的。

• DBMS有关数据完整性的功能
  提供定义完整性约束条件的机制。由SQL的DDL语言来实现，作为数据库模式的一部分存入数据字典。

  提供完整性检查的方法：一般在执行更新操作后开始检查，也可以在事务提交时检查。

  违约处理

• 完整性定义和检查控制由RDBMS实现，不必由应用程序来完成。

实体完整性

• 关系模型的实体完整性CREATE TABLE中用PRIMARY KEY定义。

  单属性构成的码：定义为列级约束条件或定义为表级约束条件。

  对多个属性构成的码只能定义为表级约束条件。

• 插入或对主码列进行更新操作时，RDBMS按照实体完整性规则自动进行检查。包括：检查主码值是否唯一，如果不唯一则拒绝插入或修改。检查主码的各个属性是否为空，只要有一个为空就拒绝插入或修改。

  检查记录中主码值是否唯一的一种方法是进行全表扫描，但十分耗时。

  为了避免全表扫描，RDBMS一般会在主码上建立一个索引（B+树）。

参照完整性

• 在CREATE TABLE中用FOREIGN KEY短语定义哪些列为外码，用REFERENCES短语指明这些外码参照哪些表的主码。

  在表级定义参照完整性。

  FOREIGN KEY（< 列名>）REFERENCES 表名（<列名>）[ON DELETE|UPDETE CASCADE|NO ACTION

被参照表	参照表	违约处理
可能破坏参照完整性	<=插入元组	拒绝
可能破坏参照完整性	<=修改外码值	拒绝
删除元组=>	可能破坏参照完整性	拒绝/级联删除/设为空值
修改主码值=>	可能破坏参照完整性	拒绝/级联修改/设为空值

• 拒绝：一般设置为默认策略。

  级联操作：当删除或修改被参照表的一个元组导致与参照表的不一致时，删除或修改参照表中的所有导致不一致的元组。

  设为空值：当删除或修改被参照表的一个元组导致与参照表的不一致时，将参照表中的所有造成不一致的元组的对应属性设置为空值。外码只有在不是主属性时才能被设置为空值。

用户定义的完整性

• 属性上的约束条件
  列值非空（NOT NULL）
  列值唯一（UNIQUE）
  检查列值是否满足一个布尔表达式（CHECK）

  插入元组或修改属性的值时，RDBMS检查属性上的约束条件是否被满足，如果不满足则操作被拒绝执行。

• 元组上的约束条件
  在CREATE TABLE时可以用CHECK短语定义元组上的约束条件，即元组级的限制。同属性值限制相比，元组级的限制可以设置不同属性之间的取值的相互约束条件 。

  插入元组或修改属性的值时，RDBMS检查元组上的约束条件是否被满足，如果不满足则操作被拒绝执行。

完整性约束命令子句

• CONSTRAINT <完整性约束条件名>
  ［NOT NULL|NUIQUE|PRIMARY KEY短语|FOREIGN KEY短语|CHECK短语］

• ALTER TABLE 表名
  DROP CONSTRAIN 约束名

  ALTER TABLE 表名
  ADD 完整性约束命令子句

域中的完整性限制

• 域完整性：关系中的列必须满足某种特定的数据类型或约束。可以强制域完整性限制类型、限制格式或限制值的范围等。

• 可以用CREATE DOMAIN语句建立一个域以及该域应该满足的完整性约束条件，然后就可以用域来定义属性。

  数据库中不同的属性可以来自同一个域，当域上的完整性约束条件改变使只要修改域的定义即可。

断言

• 通过声明断言来指定更具有一般性的约束。可以定义涉及多个表或聚集操作的比较复杂的完整性约束。断言创建以后，任何涉及关系的操作都会触发RDBMS对断言的检查，任何使断言不为真值的操作都会被拒绝执行。若断言很复杂，则系统在检测和维护时的开销较高。

• CREATE ASSERTION< 断言名>< CHECK子句>
  CHECK子句中的约束条件与WHERE子句的条件表达式类似。

  DROP ASSERTION< 断言名>

触发器

• 触发器（Trigger）是用户定义在关系表上的一类由事件驱动的特殊过程。一旦定义，触发器将被保存在数据库服务器中。任何用户对表的增删改查均由服务器自动激活相应的触发器，在RDBMS核心层进行集中地完整性控制。

  触发器类似于约束，可以进行更为复杂的检查和操作，具有更精细和更强大的数据控制能力。

• 触发器又叫做事件-条件-动作规则。当特定的系统事件发生时，对规则的条件进行检查，若条件成立则执行规则中的动作，否则不执行该动作。

定义触发器

• CREATE TRIGGER <触发器名>
  {BEFORE | AFTER} <触发事件> ON <表名>
  REFERENCING NEW|OLD ROW AS< 变量>
  FOR EACH {ROW | STATEMENT}
  [WHEN <触发条件>]
  <触发动作体>

  只有表的拥有者可以创建触发器，触发器的数量由RDBMS在设计时确定。

  触发器的名字可以包含或不包含模式名。同一模式下，触发器的名字必须是唯一的，并且触发器名和表名必须在同一模式下。

  触发器只能建立在基本表上，当基本表的数据发生变化时，将激活定义在该表上响应触发事件的触发器。该表也称为触发器的目标表。

  触发事件：INSERT、DELETE、UPDATE

  触发器类型：行级触发器（FOR EACH ROW），语句级触发器（FOR EACH STATEMENT）。

  触发条件：触发条件为真。若省略WHEN触发条件，则触发器动作体在激活触发器之后立即执行。

  触发动作体：可以是一个匿名PL/SQL过程块（BEGIN…END），也可以是对已创建存储过程的调用。如果是行级触发器，用户可以在过程体中使用NEW和OLD引用UPDATE/INSERT事件之后的新值和UPDATE/DELETE时间之前的旧值，若是语句级触发器，可以引用的变量由OLDTABLE和NEWTABLE。

激活触发器

• 触发器的执行，是由触发事件激活，并由数据库服务器自动执行。一个数据表上可能定义了多个触发器。同一个表上的多个触发器激活时的执行顺序为：执行该表上的BEFORE触发器；激活触发器的SQL语句；执行该表上的AFTER触发器。

  对同一个表上的BEFOR或AFTER触发器，遵循谁先创建，谁先执行的原则。

删除触发器

• DROP TRIGGER <触发器名> ON <表名>;

  触发器必须是一个已经创建的触发器，并且只能由具有相应权限的用户删除。