数据库系统概论（十六）数据库安全性（安全标准，控制，视图机制，审计与数据加密）

---

前言

• 在前几期博客中，我们探讨了 SQL 连接查询，单表查询，嵌套查询，集合查询，基于派生表的查询，数据插入，修改与删除，空值的处理，视图技术等知识点。
• 从本节开始，我们将深入讲解 SQL 中数据库安全性的知识点。

我的个人主页，欢迎来阅读我的其他文章
https://blog.csdn.net/2402_83322742?spm=1011.2415.3001.5343
我的数据库系统概论专栏
https://blog.csdn.net/2402_83322742/category_12911520.html?spm=1001.2014.3001.5482

---

一、数据库安全性

1. 什么是数据库安全性？

• 数据库安全性就像是给数据库配备的“安全保镖”，其主要任务是防止非法用户对数据库进行访问，阻止非法操作导致的数据泄露、被篡改或者遭到破坏。

举个简单的例子，银行的用户储蓄数据、医院的患者医疗档案等都属于敏感信息，必须通过数据库安全性措施来确保它们的安全。

2. 为何会存在安全问题？

数据库的显著特点之一是数据共享，但这种共享并非毫无条件。如果不加以限制，军事机密、企业的市场营销策略等敏感数据就可能被别有用心的人获取。

• 所以，数据共享必须建立在安全的基础之上，这就需要借助一系列的安全机制来实现。

二、安全标准的发展

数据库安全问题日益受到关注，各国纷纷制定了相关的安全标准，这些标准的发展大致经历了以下几个阶段：

1. 早期的“开拓者”：TCSEC标准

• 诞生背景：1985年，美国国防部发布了《可信计算机系统评估准则》（TCSEC），这是首个针对计算机系统安全的评估标准，后来又推出了针对数据库的扩展标准TDI（紫皮书）。
• 安全级别划分（从低到高）：
  • D级（最低保护）：这类系统几乎没有任何安全机制，就像一个不设门禁的仓库，任何人都能随意进出。例如DOS系统，在安全性方面几乎没有专门的保障措施。
  • C1级（自主安全保护）：实现了用户和数据的初步分离，允许用户自主设置权限，就好像给仓库上了一把普通的锁，只有拥有钥匙（权限）的人才能进入。现在的大多数商业系统基本都能达到这个级别。
  • C2级（受控存取保护）：在C1级的基础上进一步细化，要求用户进行身份注册，就如同仓库管理员会记录每个进入者的身份，并且对操作进行审计。例如Windows 2000和Oracle 7就符合这个级别。
  • B级（强制存取控制）：这是“安全产品”的级别，采用强制存取控制（MAC），就像仓库对不同重要程度的物品设置了不同的进入权限，只有符合特定级别的人才能接触相应的物品。其中：
    • B1级：要求对数据进行标记（如“机密”“公开”），并实施强制访问控制，例如Trusted Oracle 7数据库。
    • B2级：需要建立形式化的安全模型，对系统内的所有主体（用户、进程等）和客体（数据、文件等）都进行严格控制。
    • B3级：具备更强的审计和恢复能力，确保系统在出现问题时能够及时恢复。
  • A1级（最高级别）：不仅要达到B3级的要求，还需要对系统的设计进行形式化验证，就像经过严格的数学证明一样，确保安全机制确实有效。

2. 走向国际统一：CC标准

• 发展历程：由于各国的标准存在差异，1993年，美国、欧洲、加拿大等国家和地区联合开展了CC项目，旨在统一安全标准。1999年，CC成为国际标准（ISO 15408），2001年我国也采用其作为国家标准，如今它已成为评估信息产品安全性的主要标准。
• 核心特点：
  • 将安全要求分为两类：
    • 安全功能要求：规定了产品需要具备哪些安全功能，例如访问控制、加密等。
    • 安全保证要求：关注产品的开发过程和测试，确保安全功能是可靠的。
  • 评估保证级（EAL）：从EAL1到EAL7共7个级别，级别越高，安全性越强，并且与TCSEC级别有对应关系：

    评估保证级	特点	对应TCSEC级别
    EAL1	仅进行功能测试	无对应（安全性较低）
    EAL2	进行结构测试	C1级
    EAL3	系统地测试和检查	C2级
    EAL4	系统地设计、测试和复查	B1级
    EAL5	半形式化设计和测试	B2级
    EAL6	半形式化验证的设计和测试	B3级
    EAL7	形式化验证的设计和测试	A1级

3. TCSEC和CC标准有什么不同？

维度	TCSEC	CC标准
适用范围	主要针对美国政府和军方系统	是国际通用标准，适用于各类信息产品
安全要求	级别划分较粗，侧重于强制存取控制	明确区分功能要求和保证要求，更加全面
评估方式	以级别划分（如C1、B1）	以评估保证级（EAL）划分，更具灵活性
现状	逐渐被CC标准取代	成为主流标准，广泛应用于全球

三、数据库安全性控制

1. 第一层防线：用户身份鉴别

为什么需要这一步？
就像进入银行需要先证明“你是你自己”，数据库也需要确认用户身份，防止陌生人闯入。
常见的鉴别方法：

1. 静态口令（最基础）
   • 比如设置“密码”（如“user123”），但容易被破解（像家门钥匙可能被偷配）。
2. 动态口令（更安全）
   • 比如手机短信验证码、APP生成的动态数字（每分钟一变），像每次进门都需要新钥匙。
3. 生物特征（高级）
   • 指纹、人脸、虹膜识别（独一无二），类似“只有本人指纹才能开门”。
4. 智能卡（硬件辅助）
   • 比如银行卡+密码，必须同时拥有卡和密码才能访问（像“钥匙+密码锁”双重保障）。

2. 第二层防线：存取控制（决定能看什么、做什么）

（1） 自主存取控制（DAC）

核心思想：用户自己决定“谁能访问我的数据，能怎么访问”，类似“老师给学生发作业权限”。

• 权限类型（以学生成绩表为例）：
  • 查询（SELECT）：允许查看成绩。
  • 修改（UPDATE）：允许修改分数。
  • 删除（DELETE）：允许删除记录。
• 如何授权/回收？
  • 授权语句（GRANT）：

    GRANT SELECT ON TABLE 成绩表 TO 学生A;  -- 允许学生A查询成绩
    

  • 回收语句（REVOKE）：

    REVOKE UPDATE ON TABLE 成绩表 FROM 学生B;  -- 禁止学生B修改成绩
    

• 特点：灵活但有漏洞。比如老师不小心把“修改权限”给了学生，可能导致数据被误改或泄露。

（2）数据库角色：批量管理权限的“快捷方式”

为什么需要角色？
当有多个用户需要相同权限时，逐个授权太麻烦。比如“财务部员工”都需要访问工资表，可创建一个“财务角色”，一次性授权给所有人。

• 步骤示例：
  1. 创建角色：

     CREATE ROLE 财务角色;
     

  2. 给角色授权：

     GRANT SELECT, UPDATE ON TABLE 工资表 TO 财务角色;  -- 角色拥有查询和修改权限
     

  3. 将角色授予用户：

     GRANT 财务角色 TO 张三, 李四, 王五;  -- 三人自动获得角色权限
     

  4. 回收角色权限：

     REVOKE 财务角色 FROM 张三;  -- 张三失去财务相关权限
     

优点：像“给一群人发相同钥匙”，管理效率高。

（3）强制存取控制（MAC）：严防死守的密级管理

为什么需要MAC？
DAC的漏洞在于“用户可能无意泄露数据”。比如：

• 财务人员A有权限访问“绝密级”工资表，但他复制了一份表并“不小心”分享给公开用户，DAC无法阻止（因为A有复制权限）。
  MAC如何解决？
  给数据和用户都打上“密级标签”，强制规定：
• 读规则：用户的密级 ≥ 数据密级，才能读取（比如“机密级”用户只能读“机密级”或更低的数据）。
• 写规则：用户的密级 ≤ 数据密级，才能写入（比如“机密级”用户只能往“机密级”或更高密级的数据里写，防止高权限用户误改低密级数据）。
  类比场景：
• 军队中，只有“上校”（高密级用户）能读取“绝密文件”（高密级数据），且不能将绝密内容写入“公开文件”（低密级数据），避免敏感信息泄露。

MAC与DAC的配合：

1. 先进行DAC检查：判断用户是否有“查询/修改”等权限（如“学生A是否有权限查成绩”）。
2. 再进行MAC检查：判断用户密级是否符合数据密级（如“学生A的密级是否≥成绩表的密级”）。

总结：DAC是“权限开关”，MAC是“密级门禁”，双重保障更安全。

3. 其他安全手段

1. 审计（Audit）
   • 记录用户对数据库的所有操作（如“谁查了工资表，何时查的”），像“监控摄像头”，用于事后追踪问题。
2. 数据加密
   • 将数据变成乱码（如“123456”加密为“!@#$%^”），即使数据被窃取，没有密钥也无法破解，类似“给文件上密码锁”。
3. 视图（View）
   • 隐藏敏感数据，只给用户看部分内容。比如给普通员工的“工资视图”只显示自己的工资，不显示他人工资，像“透过小孔看风景，只能看到部分”。

总结

层次	手段	作用描述
最外层	用户身份鉴别	拦住无关人员，确认“你是谁”
第二层	自主存取控制（DAC）	灵活分配权限，决定“你能做什么”
第三层	强制存取控制（MAC）	按密级严格管控，防止“无意泄露”
辅助层	审计、加密、视图等	记录操作、加密数据、隐藏敏感信息，全方位加固

四、视图机制

1. 为什么需要视图？

• 场景：老师想让学生只能看到自己的成绩，而看不到全班成绩表。
• 传统授权的局限：GRANT SELECT ON 成绩表 TO 学生 会让学生看到整个表的数据，无法只允许查看某一行（如自己的成绩）。
• 视图的作用：视图就像一扇“窗户”，可以从完整的数据表中“截取”部分数据（行或列），用户通过视图只能看到窗户内的内容。

2. 如何用视图实现安全控制？

示例：计科专业老师只能查看本专业学生信息

1. 创建计科学生视图（只包含计算机科学与技术专业的学生）：

   CREATE VIEW 计科学生视图 AS 
   SELECT * FROM 学生表 WHERE 专业='计算机科学与技术';
   

   这个视图相当于从“学生表”中切出一个“计科学生”的小窗口。
2. 授权：
   • 给小明老师授权只能查询视图：

     GRANT SELECT ON 计科学生视图 TO 小明;
     

     小明通过视图只能看到计科学生的数据，看不到其他专业学生。
   • 给系主任张三授权所有权限：

     GRANT ALL PRIVILEGES ON 计科学生视图 TO 张三;
     

     张三可以通过视图增删改查计科学生数据，但同样看不到其他专业数据。

3. 核心优势

• 隐藏敏感数据：通过视图屏蔽无关行/列，比如工资表中只让员工看到自己的工资列。
• 与授权结合：视图相当于“数据过滤器”，授权决定“谁能看”，视图决定“能看什么”。

五、审计

1. 什么是审计？

• 类比：超市安装监控摄像头，记录所有顾客的行为，以便事后追查盗窃或纠纷。
• 数据库中的审计：开启审计后，数据库会自动记录用户的所有操作（如查询、修改、删除），包括：
  • 谁操作的（用户账号）
  • 何时操作的（时间戳）
  • 操作了什么数据（如表名、列名）
  • 数据前后的变化（如修改前工资是5000，修改后是6000）

2. 审计有什么用？

• 追踪非法操作：如果工资表被篡改，通过审计日志可以查到是谁在几点修改了数据。
• 合规要求：金融、医疗等行业必须记录操作日志，满足监管要求。
• 性能分析：通过分析日志，发现高频操作或慢查询，优化数据库。

3. 审计的类型和适用场景

• 用户级审计：用户自己设置，监控自己创建的表。比如小王对自己的“报销表”开启审计，查看谁修改过。
• 系统级审计：只有管理员（DBA）能设置，监控整个数据库。比如银行DBA开启对“转账表”的审计，防止内部人员篡改交易记录。
• 注意：审计会增加存储和性能开销，默认不开启，仅在高安全需求场景（如银行、政府）使用。

4. 数据库对审计的支持

• SQL Server：2008版本后自带审计功能，可记录登录、语句执行等。
• MySQL：企业版收费提供审计，社区版需用第三方插件（如MariaDB Audit Plugin）。
• 示例：对“成绩表”的修改操作开启审计：

  -- 打开审计开关
  SET AUDIT_TRAIL TO ON;
  -- 对成绩表的更新和删除操作进行审计
  AUDIT UPDATE, DELETE ON 成绩表;
  

六、数据加密

1. 为什么需要数据加密？

• 场景：数据在硬盘存储时被偷，或在网络传输时被截获。如果数据是明文（如“张三工资8000”），攻击者可直接读取；如果是密文（如“@#$%&*”），则无法理解。
• 核心思想：将明文（原始数据）通过算法变成密文（乱码），只有拥有密钥的人才能解密回明文。

2. 加密的时机和方法

• 按阶段划分：
  • 传输加密：数据在网络中传输时加密（如从客户端到数据库服务器），防止中途被截获。类似快递包裹用密码锁封装。
  • 存储加密：数据存到硬盘时加密，防止硬盘被盗后数据泄露。类似行李箱用密码锁锁住。
• 按算法划分：
  • 对称加密（如DES）：加密和解密用同一把钥匙（密钥），速度快但密钥需保密。类似“一把钥匙开一把锁”。
  • 非对称加密（如RSA）：用公钥加密，私钥解密，密钥成对出现。公钥可公开，私钥需保密。类似“用锁头锁门，用钥匙开门”。

3. 简单加密示例：凯撒密码（替换法）

• 明文：I love you
• 加密规则：每个字母后移3位（如A→D，B→E）。
• 密文：L oryh brx
• 解密：每个字母前移3位，还原为明文。

4. 数据库中的加密实现

• 库内加密：在数据库内部自动完成加密和解密，用户感觉不到（透明加密）。比如数据写入硬盘前自动加密，读取时自动解密。
• 库外加密：在客户端或应用层先加密数据，再存入数据库。数据库存储的是密文，但需要应用自己管理密钥。
• 优缺点对比：

  方式	优点	缺点
  库内加密	对应用透明，操作简单	依赖数据库厂商，可能影响性能
  库外加密	灵活性高，适合定制化需求	需自行管理密钥，增加开发成本

5. 总结三层安全手段

手段	核心功能	类比场景
视图机制	限制数据可见范围，屏蔽敏感行/列	用窗户限定能看到的风景
审计	记录所有操作，用于事后追踪和安全分析	超市监控摄像头记录顾客行为
数据加密	防止数据在存储和传输中被窃取或泄露	给文件加密码锁，防止被偷看

七、其它安全性保护（了解就好）

1. 推理控制

1.1 什么是推理控制？

• 场景引入：假设数据库中有两张表：
  • 公开表：记录职工号、姓名、职务（如“张三，程序员”）。
  • 机密表：记录职工号、工资（如“张三，月薪20000”）。
  • 普通用户只能访问公开表，但通过“职务→工资”的常识（如“程序员的平均工资约15000-25000”），可能推断出张三的工资属于该范围，甚至结合其他同事数据精准推算出具体数值。
• 定义：推理控制是防止用户利用公开数据和背景知识，间接推断出敏感数据的安全机制，解决MAC（强制存取控制）未覆盖的“逻辑漏洞”。

1.2 为什么需要推理控制？

• MAC的局限：MAC通过密级限制直接访问（如工资表设为“机密”，普通用户无法直接查询），但无法阻止用户通过公开数据“间接推理”机密信息。

• 示例：

  职工号	姓名	职务	（公开）
  001	张三	高级工程师
  002	李四	实习生

  职工号	工资	（机密）
  001	30000
  002	5000

  • 用户已知“高级工程师工资远高于实习生”，即使看不到工资列，也能推断001的工资高于002，可能进一步通过行业数据估算具体数值。

1.3 常用的推理控制方法

• 方法1：基于函数依赖的推理控制
  • 禁止公开数据中存在与敏感数据的“固定关联”。
  • 例：如果“职务→工资范围”是强关联（如“实习生工资固定为5000”），则隐藏“职务”或“工资”中的一方，避免用户通过函数关系（职务→工资）推断。
• 方法2：基于敏感关联的推理控制
  • 打乱公开数据与敏感数据的关联，增加推理难度。
  • 例：在公开表中不显示“职务”，改为“岗位编号”（如“岗位A、岗位B”），且岗位编号与工资无明确对应关系，用户无法通过岗位推断工资。

2. 经济学角度的安全考量：没有绝对安全，只有性价比最优

2.1 为什么没有“绝对安全”的系统？

• 技术层面：任何加密算法或安全措施都可能被破解（如量子计算可能破解RSA加密），只是时间和成本问题。
• 现实层面：投入无限资源追求绝对安全不现实。例如：
  • 保护“明天的天气预测”数据，投入百万级加密措施显然不合理，因为数据过了今天就失去价值。

2.2 什么是“经济上安全”的系统？

• 标准1：破译成本＞信息价值
  • 若黑客破译数据的成本（如购买设备、雇佣专家的费用）超过数据本身的价值，则系统是安全的。
  • 例：保护“某公司明天的股票交易策略”，若策略带来的收益预期为10万元，而破译需要花费20万元，黑客会因“不划算”放弃攻击。
• 标准2：破译时间＞信息生命周期
  • 若数据在被破译前已失去时效性，则系统是安全的。
  • 例：保护“双十一促销活动细节”，活动结束后数据价值骤降，即使一周后被破译，也不会造成损失。

2.3 如何应用经济学思维设计安全方案？

• 步骤1：评估数据价值和生命周期
  • 敏感数据（如用户隐私）：价值高、生命周期长，需投入较高安全成本（如AES-256加密、定期密钥更换）。
  • 临时数据（如临时验证码）：价值低、生命周期短，使用简单加密（如Base64编码）即可。
• 步骤2：平衡成本与收益
  • 小企业无需采购千万级的加密硬件，选择云服务商提供的标准化加密服务（如阿里云SSL证书）更经济。
  • 金融机构则需投入高成本实现“量子加密+多重审计”，因为数据泄露的损失可能远超防护成本。

---

以上就是这篇博客的全部内容，下一篇我们将继续探索更多精彩内容。

我的个人主页，欢迎来阅读我的其他文章
https://blog.csdn.net/2402_83322742?spm=1011.2415.3001.5343
我的数据库系统概论专栏
https://blog.csdn.net/2402_83322742/category_12911520.html?spm=1001.2014.3001.5482

非常感谢您的阅读，喜欢的话记得三连哦