• 数据库安全性与完整性设计与实现
  • 数据库描述
  • 数据库安全性设计描述
  • 安全性的实现过程与验证过程
  • 数据库完整性设计描述
  • 完整性的具体实现与验证过程
  • 问题分析
  • 实验感想

数据库安全性与完整性设计与实现

数据库描述

根据我国的行政机关人事基本信息管理体系，建立数据库针对有关人员、部门、职务、职级等基本信息进行管理。
数据库ER图设计如下：

逻辑模型如下：

生成的PDM如下：

登录openGauss，使用管理员账户omm登录系统数据库postgres并建立数据库test_20201230以及其所属管理员账户dboper。详细信息查询如下：

数据库安全性设计描述

由于初始化用户omm在openGauss中不允许运程登录，仅可本地登录。因此该账户的使用在严格的本地行为监控下，可以避免诸如修改表中数据等“监守自盗”行为的发生。
为方便直观的使用可视化工具DATa studio，因此建立类omm账户“dboper”，假设其为系统管理员，用于安全模型的创建以及后续查询工作。

整个安全模型创建分为两层：

• 管理员层
• 游客层

游客层设计较为简单：游客仅被赋予部分信息查询权限（体现行政机关人员简历的公开透明）。具体设计为：

• 创建部门下职级与职务视图；
• 创建部门下人员信息视图（包含其职务/职级，姓名，出生年月，性别）；
• 创建角色并分别赋予以上三个视图的查询权限；
• 创建两个账户：user1、user2和user3，分别赋予以上角色。

管理员层则利用dboper账户创建三权分立安全模型。该模型关键在于三个角色创建：安全管理员、系统管理员和审计管理员。

• 安全管理员：用于创建数据管理用户，不可审，不可管；
• 系统管理员：用于对创建的用户进行赋权，不可审，不可创建用户；
• 审计管理员：用于审计安全管理员、系统管理员、普通用户实际的操作行为。

通过三权分立建立角色模型实现权限的分派，且三个管理员角色独立行使权限，相互制约制衡。使得整个系统得权限不会因为权限集中而引入安全风险。

安全性的实现过程与验证过程

1.首先利用dboper账户对三权角色以及需要的账户进行创建（创建时不赋予角色登录权限）

其中三权角色为：systemm、safe、audit；
和游客角色：userm1、userm2；

2.对创建的角色分别赋权

• 对安全管理员safe角色赋权

GRANT CREATE  ON DATABASE test_20201230 TO safe;

• 对审计管理员aduits角色赋权

GRANT pg_read_server_files TO audit_admin; -- 允许访问服务器文件，用于访问审计日志  
GRANT USAGE ON SCHEMA audit TO audit_admin; -- 允许访问审计日志表
...

由于openGauss审计功能暂时不能授权使用，故此处只能暂时假设审计功能已完成。

• 对系统管理员systemm角色赋权

GRANT ALL PRIVILEGES ON DATABASE test_20201230 TO systemm; 
REVOKE CREATE ON DATABASE test_20201230 FROM systemm; 
REVOKE pg_read_server_files FROM systemm;  
REVOKE USAGE ON SCHEMA audit FROM systemm;...

由于审计功能暂时不能授权使用，故此处只能暂时假设审计功能已收回。

建立三个游客视图
部门下职级视图：

CREATE VIEW de_p_r (dname,dtype,pname) AS SELECT dname,dtype,pname FROM department,have2,post WHERE department.dno=have2.dno AND have2.pno=post.pno;

部门下职务视图：

CREATE VIEW de_p_r2 (dname,dtype,rname) AS SELECT dname,dtype,rname FROM department,have1,rank WHERE department.dno=have1.dno AND have1.rno=rank.rno;

部门下员工信息视图：

CREATE VIEW de_e AS SELECT DISTINCT dname,dtype,ename,ebirth,esex,pname,rname FROM department,empolyeer,danren,pinyong,post,rank WHERE department.dno=empolyeer.dno AND danren.eno=empolyeer.eno AND danren.pno=post.pno AND pinyong.rno=rank.rno; 

将游客视图查询权赋权给角色

GRANT SELECT ON de_p_r TO userm1;
GRANT SELECT ON de_p_r2 TO userm2;
GRANT SELECT ON de_e TO userm3;

3.创建对应账户并将角色授予账户，同时对账户做验证

• 利用系统管理员账户dboper创建安全管理员账户root_safe,并将安全管理员角色授予该账户
  首先创建好该账户后验证该账户并无权限：
  
  接着将角色授予该账户
  
  使用该安全管理员账户创建所需的游客账户user1，user2和user3.
  
  同时验证游客账户此时并无视图查看权限
  
  此时创建系统管理员账户root_system并登录测试无权限
  
  将systemm角色授予该账户
  
  验证权限：对游客账户依次授权
  
  游客账户查看视图验证权限
  
  
  
  由于审计权限暂时不能授权，故无法验证。

数据库完整性设计描述

数据库完整性包括：实体完整性、参照完整性以及用户自定义完整性。

实体完整性和参照完整性已经在数据库设计时完成不再赘述，下面有具体的设计实现。

针对于该系统，设计自己的完整性如下：

对于员工职级或职务发生变化时，一般情况下网上信息会立刻同步。故设计：当在danren表以及pinyong表中插入数据时，无论时间是什么，都会更改为系统当前时间。

完整性的具体实现与验证过程

实体完整性与参照完整性具体实现如下：

自定义完整性验证如下：
建立函数

CREATE OR REPLACE FUNCTION set_drdate() RETURNS trigger AS $$
BEGIN
 NEW.drdate := CURRENT_TIMESTAMP;
 RETURN NEW;
END;
$$ LANGUAGE plpgsql;

建立触发器

CREATE TRIGGER new_danren_trigger
BEFORE INSERT ON danren
FOR EACH ROW
EXECUTE PROCEDURE set_drdate();

验证

可以看到插入的时间被强行改到了当前系统时间

问题分析

• 数据库插件pgaudit未能正确加载
  • 查看表内audit_enabled值
    
    值为on但是却无法使用AUDIT审计指令。
• 触发器问题
  • openGauss 数据库使用的是类 PostgreSQL 语法，按照 PostgreSQL 的语法规范，触发器的定义需要使用EXECUTE FUNCTION 而不是 AS BEGIN。
    OpenGauss 和 PostgreSQL 语法结构大部分是相似的，但是在某些细节方面略有不同。

实验感想

此次试验感觉上来说还是比较复杂的。从整体安全性的设计到实现再到完整性的设计以及实现，最后再一一验证，过程中遇到了不少的问题，每一个点都很值得深入去思考。尤其是触发器部分，其中还涉及到了存储过程，很值得去深入研究。以及审计部分，很遗憾没有时间去研究配置，但很庆幸找到了不少知识盲区，之后会利用额外的时间去一一解决。整体来说，本次实验收获颇丰。