数据库安全性

发表于 Waline： 阅读次数： 本文字数： 5.7k 阅读时长 ≈ 21 分钟

数据库安全性概述

数据库的「共享性」是其核心特征之一，但这不可避免地带来了「安全性」问题。数据共享不能是无条件的，特别是对于敏感信息（如军事机密、商业秘密、个人隐私等）。

数据库安全性定义

数据库安全性是指保护数据库，防止因用户非法使用数据库造成的数据泄露、更改或破坏，确保数据的机密性、完整性和可用性。

系统安全保护措施的有效性是衡量数据库管理系统性能的关键指标之一。

数据库面临的安全威胁

对数据库系统的破坏通常来自以下几个方面：

  1. 非授权用户的访问和破坏：
    • 威胁：黑客或恶意用户通过窃取、猜测或破解合法用户的身份凭证（用户名、密码）来访问数据库，进行数据窃取、篡改或删除。内部人员滥用合法权限也属于此类。
    • 对策：用户身份鉴别、多因素认证、访问控制（自主与强制）、视图机制、审计。
  2. 数据库中重要或敏感数据的泄露：
    • 威胁：即使是授权用户，也可能通过多次合法的、低权限的查询，「推导」（Inference）；或者数据在存储、传输过程中被截获。
    • 对策：强制访问控制（MAC）、数据加密（存储与传输）、推理控制、审计日志分析。
  3. 安全环境的脆弱性：
    • 威胁：数据库的安全性依赖于整个计算机系统的安全性，包括硬件、操作系统、网络环境等。这些基础环境的漏洞可能被利用来绕过或破坏数据库的安全机制。
    • 对策：建立可信计算基，加强操作系统和网络安全，进行整体安全评估。

TCB

可信计算基（Trusting Computing Base, TCB）是指系统中所有保护机制的集合，包括硬件、固件、软件和策略，它们共同负责强制执行系统安全策略。TCB 必须是可信的，即它的行为是可预测且满足安全需求的。

数据库安全标准简介

为了规范和评估计算机系统的安全性，特别是数据库系统的安全性，国际和国内都制定了一系列标准。

早期标准：TCSEC

  • TCSEC(Trusted Computer System Evaluation Criteria)：1985 年由美国国防部发布，俗称「橘皮书」。
    • 目标：为计算机系统提供安全评估的等级标准。
    • 核心思想：按系统提供的安全保护能力（可靠性、可信度）划分等级。
    • 等级划分：从低到高分为 D, C1, C2, B1, B2, B3, A1。
等级 名称 核心特征
D 最小保护（Minimal Prot.） 不满足更高等级要求
C1 自主安全保护（Discretionary Security Prot.） 用户/数据分离，自主访问控制
C2 受控的存取保护（Controlled Access Prot.） C1 基础上，更细粒度 DAC，对象重用，审计
B1 标记安全保护（Labeled Security Prot.） C2 基础上，强制访问控制，数据标记
B2 结构化保护（Structural Prot.） B1 基础上，形式化安全策略模型，系统结构化，隐蔽信道分析
B3 安全域（Security Domains） B2 基础上，可信路径，系统恢复，更强审计与访问监控
A1 验证设计（Verified Design） B3 基础上，形式化设计说明与验证，可信分发
  • 自主访问控制（DAC）：数据属主可以自主决定将访问权限授予其他用户。
  • 强制访问控制（MAC）：系统根据主体（用户/进程）的许可证级别和客体（数据）的密级强制实施访问规则，用户无法改变。

现代标准：Common Criteria (CC)

  • 背景：TCSEC 之后，欧洲（ITSEC）、加拿大（CTCPEC）、美国（FC）等也推出了各自的标准。为统一标准，1993 年开始联合制定 Common Criteria(CC)。
    • 地位：1999 年 CC V2.1 被 ISO 采纳为国际标准（ISO/IEC 15408），已基本取代 TCSEC，成为信息技术产品安全评估的主要标准。中国于 2001 年采用 CC V2.1 作为国家标准（GB/T 18336-2001，后有更新版本）。
    • 核心结构：
      • 安全功能要求（Security Functional Requirements, SFRs）：描述产品应具备的安全行为（如身份识别、审计、访问控制等）。
      • 安全保证要求（Security Assurance Requirements, SARs）：描述为确保产品安全功能正确实施所需采取的措施（如开发过程、测试、文档等）。
    • 评估保证级（Evaluation Assurance Level, EAL）：CC 定义了 7 个预定义的保证包（EAL1-EAL7），级别越高，保证程度（评估的深度和严格性）越高。
EAL 名称 描述 近似 TCSEC
EAL1 功能测试（Functionally Tested） 基本功能测试 -
EAL2 结构测试（Structurally Tested） 设计信息分析，白盒测试 C1
EAL3 系统地测试和检查（Methodically Tested…） 更严格开发过程控制，测试覆盖率 C2
EAL4 系统地设计、测试和复查（Methodically Designed…） 良好商业实践，独立脆弱性分析 B1
EAL5 半形式化设计和测试（Semiformally Designed…） 形式化模型，半形式化设计，更深入渗透测试 B2
EAL6 半形式化验证的设计和测试（Semiformally Verified…） 高度结构化开发，半形式化验证 B3
EAL7 形式化验证的设计和测试（Formally Verified…） 形式化方法贯穿，全面独立测试与验证 A1

数据库安全性控制机制

DBMS 通过一系列机制来保障数据库的安全。这些机制通常是分层实施的。

graph LR
    subgraph DBMS 安全控制
        direction LR
        SQLProc[SQL 处理层] --> AccessCtrl{存取控制};
        AccessCtrl -- DAC --> DACCheck[自主访问控制检查];
        AccessCtrl -- MAC --> MACCheck[强制访问控制检查];
        AccessCtrl -- Inference --> InferenceCtrl[推理控制];
        SQLProc --> Audit[审计];
        SQLProc --> IntrusionDetection[入侵检测];
    end
    subgraph 数据库安全性控制
        direction LR
        User[用户] --> Auth{用户身份鉴别};
        Auth -- 合法 --> DBMSSec[DBMS 安全控制];
        DBMSSec -- 操作 --> OS[操作系统安全];
        OS -- 存储/读取 --> EncryptDB[(加密存储的数据库)];
    end


    style EncryptDB fill:#f9f,stroke:#333,stroke-width:2px

存取控制流程

  1. 身份鉴别：用户连接数据库时，DBMS 首先验证用户身份。
  2. 访问控制：用户执行 SQL 操作时，DBMS 在 SQL 处理层进行权限检查。
    • 自主访问控制（DAC）：检查用户是否被授予了对操作对象的相应权限。
    • 强制访问控制（MAC）：如果启用，进一步检查用户的许可证级别与数据对象的密级是否符合 MAC 规则。
    • 推理控制：防止通过合法查询推导出未授权信息。
  3. 审计：记录用户访问行为和系统关键操作。
  4. 入侵检测：分析异常行为模式，发出警报。

常用安全性控制方法

  • 用户标识和身份鉴别（Authentication）
  • 存取控制（Access Control）
  • 视图机制（View, Mechanism）
  • 审计（Audit）
  • 数据加密（Encryption）

用户身份鉴别（Identification & Authentication）

这是数据库安全的第一道防线。

  • 用户标识（Identification）：确认用户的身份，通常是用户名或用户 ID，在系统生命周期内应唯一。
  • 身份鉴别（Authentication）：核实用户声称的身份是否属实。

常用鉴别方法：

  1. 静态口令（Static Password）：用户设定固定密码。最常用但也最不安全，易被猜测、窃取。
  2. 动态口令（Dynamic Password/One-Time Password, OTP）：每次鉴别使用不同的、动态生成的口令（例如，通过令牌硬件或手机 App 生成）。安全性较高。
  3. 生物特征（Biometrics）：使用用户的生理或行为特征进行认证，如指纹、虹膜、人脸识别、声纹等。唯一性强，不易伪造，但成本较高，且涉及隐私问题。
  4. 智能卡（Smart Card）：内置芯片的物理卡，可存储密钥或执行加密运算，通常需要配合 PIN 码使用。提供硬件级安全。

存取控制（Access Control）

在身份鉴别之后，确保授权用户只能访问其被允许访问的数据和执行被允许的操作。

存取控制机制组成：

  1. 权限定义：定义用户对哪些数据对象（如表、视图、列）可以执行哪些操作（如 SELECT, INSERT, UPDATE, DELETE）。用户对某一数据对象的操作权力称为权限（Privilege/Authority）。DBMS 提供特定语言（通常是 SQL 的 DCL 部分）来定义权限。
  2. 权限登记：将定义好的用户权限存储在数据字典或系统目录中，形成安全规则或授权规则。
  3. 合法权限检查：当用户发出数据库操作请求时，DBMS 查询数据字典，检查用户是否具有执行该操作所需的权限。

这两个部分共同构成了 DBMS 的存取控制子系统。

存取控制方法：DAC 与 MAC

  1. 自主存取控制（Discretionary Access Control, DAC）
    • 特点：用户可以自主地将自己拥有的权限（特别是对自己创建的对象的权限）授予或收回给其他用户。灵活性高。
    • 实现：主要通过 SQL 的 GRANT 和 REVOKE 语句实现。
    • 对应标准：通常达到 TCSEC C2 级别。
    • 缺点：权限管理可能分散混乱，存在数据被恶意或无意传播的风险（例如，用户 A 授予 B，B 授予 C，A 可能无法控制 C 的访问）。
  2. 强制存取控制（Mandatory Access Control, MAC）
    • 特点：系统为所有主体（用户、进程）和客体（数据对象）分配安全属性（如许可证级别和密级），并强制执行固定的安全策略（如 Bell-LaPadula 模型的「上读不下写」规则的变体）。用户不能改变这些规则。安全性高，控制严格。
    • 实现：需要在 DBMS 内核层面实现，对数据进行标记，并检查主体和客体的标签。
    • 对应标准：通常需要达到 TCSEC B1 及以上级别。
    • 适用场景：对数据有严格、固定密级分类的场景（如军事、政府部门）。

自主存取控制详解

权限的组成要素

  • 数据库对象：权限作用的目标，如表、视图、列、模式等。
  • 操作类型：对对象可以执行的动作，如 CREATE, ALTER, DROP, SELECT, INSERT, UPDATE, DELETE, REFERENCES 等。

关系数据库中的主要权限：

对象类型 对象示例 主要权限
数据库模式 Schema CREATE SCHEMA
基本表 CREATE TABLE, ALTER TABLE, DROP TABLE
视图 CREATE VIEW, DROP VIEW
索引 CREATE INDEX, DROP INDEX
数据 基本表、视图 SELECT, INSERT, UPDATE, DELETE, REFERENCES, ALL PRIVILEGES
特定列 SELECT(col), INSERT(col), UPDATE(col), REFERENCES(col)

REFERENCES 权限

REFERENCES 权限允许用户在创建表时定义外键（Foreign Key）约束，引用被授权表的主键或唯一键。这涉及到跨表的完整性，因此需要单独授权。

用户获得对某个客体的存取权限主要通过以下方式：

  1. 成为属主：对象的创建者自动成为该对象的属主，并拥有对其的所有操作权限。系统通常控制所有权的转移。
  2. 被授予权限：拥有权限的用户（包括属主、DBA 或获得转授权限的用户）可以通过 GRANT 语句将权限授予其他用户。

访问控制检查流程：

graph LR
    Start{用户 S 请求<br>以方式 A 访问对象 O} --> CheckDBA{S 是 DBA？};
    CheckDBA -- 是 --> Pass[通过检查];
    CheckDBA -- 否 --> CheckOwner{S 是 O 的属主？};
    CheckOwner -- 是 --> Pass;
    CheckOwner -- 否 --> CheckPrivilege{S 是否拥有<br>在 O 上执行 A 的权限？};
    CheckPrivilege -- 是 --> Pass;
    CheckPrivilege -- 否 --> Fail[权限检查失败];

    style Pass fill:#cfc,stroke:#333,stroke-width:2px
    style Fail fill:#f99,stroke:#333,stroke-width:2px
授权：GRANT 语句

GRANT 语句用于将对象的操作权限授予用户或角色。

语法：

GRANT <权限列表> ON <对象类型> <对象名> TO <用户或角色列表> [WITH GRANT OPTION];
  • <权限列表>：一个或多个权限名（如 SELECT, UPDATE(列名)），或 ALL PRIVILEGES。
  • <对象类型>：TABLE, VIEW, SCHEMA 等。
  • <对象名>：具体对象的名字。
  • <用户或角色列表>：一个或多个用户名、角色名，或 PUBLIC（代表所有用户）。
  • WITH GRANT OPTION：允许被授权者将获得的这些权限（包括 GRANT OPTION 本身）再授予其他用户。如果没有此选项，被授权者不能传播权限。

授权者：

  • 数据库管理员。
  • 数据库对象的属主。
  • 已拥有该权限并带有 WITH GRANT OPTION 的用户。

示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
-- 1. 授予用户 U1 查询 Student 表的权限
GRANT SELECT ON TABLE Student TO U1;

-- 2. 授予用户 U2 和 U3 对 Student 表和 Course 表的所有权限
GRANT ALL PRIVILEGES ON TABLE Student, Course TO U2, U3;

-- 3. 授予所有用户查询 SC 表的权限
GRANT SELECT ON TABLE SC TO PUBLIC;

-- 4. 授予用户 U4 查询 Student 表及修改学号的权限
GRANT SELECT, UPDATE(Sno) ON TABLE Student TO U4;
-- 注意：对列授权时必须明确指出列名

-- 5. 授予用户 U5 对 SC 表的 INSERT 权限，并允许其转授权
GRANT INSERT ON TABLE SC TO U5 WITH GRANT OPTION;

-- 6. 用户 U5 将获得的 SC 表 INSERT 权限及转授权限授予 U6
-- （假设 U5 执行此命令）
GRANT INSERT ON TABLE SC TO U6 WITH GRANT OPTION;

-- 7. 用户 U6 将获得的 SC 表 INSERT 权限授予 U7 (无转授权限)
-- （假设 U6 执行此命令）
GRANT INSERT ON TABLE SC TO U7;
-- 此时 U7 获得 INSERT 权限，但不能再授予他人

循环授权

WITH GRANT OPTION 的存在理论上可能导致循环授权（如 U1 →\to U2 →\to U1），但 DBMS 通常会检测并阻止或处理这种情况。重要的是理解权限的传播链。

回收权限：REVOKE 语句

REVOKE 语句用于从用户或角色处收回已经授予的权限。

语法：

REVOKE <权限列表> ON <对象类型> <对象名> FROM <用户或角色列表> [CASCADE | RESTRICT];
  • CASCADE：级联回收。不仅收回指定用户的权限，还收回由该用户通过 WITH GRANT OPTION 授予出去的所有相关权限。
  • RESTRICT：限制回收。如果该用户已将权限授予其他用户，则 REVOKE 操作失败。
    • 这是某些系统的默认行为，但 SQL 标准和不同 DBMS 实现可能不同，需查阅具体文档。

执行者：

  • 原授权者（DBA、属主、授予该权限的用户）。

示例：

1
2
3
4
5
6
7
8
9
10
11
12
-- 8. 收回用户 U4 修改 Student 表学号的权限
REVOKE UPDATE(Sno) ON TABLE Student FROM U4;

-- 9. 收回所有用户对 SC 表的查询权限
REVOKE SELECT ON TABLE SC FROM PUBLIC;

-- 10. 收回用户 U5 对 SC 表的 INSERT 权限，并级联收回其授予的权限
REVOKE INSERT ON TABLE SC FROM U5 CASCADE;
-- 效果：U5 的 INSERT 权限被收回。
--   由于使用了 CASCADE，U6 从 U5 处获得的 INSERT 权限也被收回。
--   进而，U7 从 U6 处获得的 INSERT 权限也被收回。
--   如果 U6 或 U7 还从其他用户（非 U5 授权链）获得了 INSERT 权限，则该权限不受影响。
创建用户与模式权限

非标准 SQL

CREATE USER 语句并非 SQL 标准的一部分，具体语法和功能在不同 DBMS 中差异很大。以下为通用概念。

通常，只有 DBA 或具有特定系统权限的用户才能创建新用户。创建用户时，可以指定其默认权限级别：

  • CONNECT：最低权限，仅允许用户连接（登录）到数据库，不能创建任何对象。
  • RESOURCE：允许用户创建表、视图等对象（并成为其属主），但通常不能创建模式或新用户。
  • DBA：最高权限（超级用户），可以执行任何操作，包括创建用户、模式、所有对象，以及授予/回收任何权限。
拥有权限 创建用户 创建模式 创建表 登录数据库 数据查询/操纵
DBA 可以 可以 可以 可以 可以
RESOURCE 不可以 不可以 可以 可以 可以
CONNECT 不可以 不可以 不可以 可以 需单独授权
数据库角色

角色（Role）是被命名的一组与数据库操作相关的权限集合。

角色的目的是简化权限管理。可以将一组权限授予一个角色，再将该角色授予多个用户，而不是为每个用户单独授予所有权限。修改角色的权限会自动影响所有被授予该角色的用户。

角色操作：

  1. 创建角色： 
    CREATE ROLE <角色名>;
  2. 给角色授权： 
    GRANT <权限列表> ON <对象> TO <角色名>;
  3. 将角色授予用户或其他角色： 
    GRANT <角色 1> [, <角色 2>] TO <用户或角色 3> [, ...] [WITH ADMIN OPTION];
    • WITH ADMIN OPTION：允许被授权者（用户或角色 3）将授予的角色（角色 1、角色 2）再授予其他用户或角色。

WITH GRANT OPTION vs. WITH ADMIN OPTION

  • WITH GRANT OPTION 用于授予对象权限时，允许被授权者转授这些对象权限。
  • WITH ADMIN OPTION 用于授予角色时，允许被授权者转授这个角色本身。
  1. 回收角色的权限： 
    REVOKE <权限列表> ON <对象> FROM <角色名>;
  2. 回收用户/角色的角色： 
    REVOKE <角色 1> [, <角色 2>] FROM <用户或角色 3> [, ...];
    • 执行者：角色的创建者，或拥有该角色 ADMIN OPTION 的用户/角色。
    • 级联回收：回收角色时，通常不会级联回收系统权限。对象权限是否级联回收取决于 DBMS 实现和 REVOKE 权限时的 CASCADE/RESTRICT 选项。

示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
-- 1. 使用角色 R1 授予一组权限给多个用户
--- 1.1. 创建角色 R1
CREATE ROLE R1;

--- 1.2. 授予 R1 对 Student 表的 SELECT, UPDATE, INSERT 权限
GRANT SELECT, UPDATE, INSERT ON TABLE Student TO R1;

--- 1.3. 将角色 R1 授予用户王平、张明、赵玲
GRANT R1 TO 王平, 张明, 赵玲;
--- 现在这三位用户都拥有了 R1 所包含的对 Student 表的权限

--- 1.4. 一次性回收王平通过 R1 获得的权限
REVOKE R1 FROM 王平;

-- 2. 修改角色 R1 的权限（增加 DELETE）
GRANT DELETE ON TABLE Student TO R1;
-- 所有拥有 R1 角色的用户（张明、赵玲）现在也自动获得了 DELETE 权限

-- 3. 修改角色 R1 的权限（减少 SELECT）
REVOKE SELECT ON TABLE Student FROM R1;
-- 所有拥有 R1 角色的用户（张明、赵玲）现在失去了 SELECT 权限

强制存取控制详解

MAC 弥补了 DAC 中数据本身无安全性标记的缺点，提供更高级别的保护。

核心概念：

  1. 主体（Subject）：系统中的活动实体，通常是用户进程。
  2. 客体（Object）：系统中的被动实体，受主体操纵的数据，如表、视图、文件。
  3. 敏感度标记（Label）：系统为每个主体和客体实例指派一个安全级别标签。
    • 主体标签：称为许可证级别（Clearance Level）。
    • 客体标签：称为密级（Classification Level）。
    • 标签级别：通常定义一个有序集合。
      • 例如：绝密（Top Secret, TS）⩾机密（Secret, S）⩾可信（Confidential, C）⩾公开（Public, P）\text{绝密（Top Secret, TS）} \ge \text{机密（Secret, S）} \ge \text{可信（Confidential, C）} \ge \text{公开（Public, P）}。
  4. 强制规则（Rules）：系统强制执行的访问规则，基于主体和客体的标签。最常见的模型是 Bell-LaPadula 模型：
    • 简单安全规则（Simple Security Property, 下读）：仅当主体的许可证级别大于或等于客体的密级时，主体才能读取该客体。（No Read Up）
    • *-规则（*-Property, 上写）：仅当主体的许可证级别小于或等于客体的密级时，主体才能写入该客体。（No Write Down）
    • 这个规则旨在防止信息从高密级流向低密级，例如基层特工可以提交情报到高级别库，但无法查看其他情报。

MAC 规则解释

假设有用户 A (许可证级别 Secret) 和用户 B (许可证级别 Confidential)，以及文件 X (密级 Secret) 和文件 Y (密级 Confidential)。

  • 读取：
    • A 可以读 X（Secret⩾Secret\text{Secret} \ge \text{Secret}）
    • A 可以读 Y（Secret⩾Confidential\text{Secret} \ge \text{Confidential}）
    • B 不可以读 X（Confidential<Secret\text{Confidential} < \text{Secret}）
    • B 可以读 Y（Confidential⩾Confidential\text{Confidential} \ge \text{Confidential}）
  • 写入：
    • A 可以写 X（Secret⩽Secret\text{Secret} \le \text{Secret}）
    • A 不可以写 Y（Secret>Confidential\text{Secret} > \text{Confidential}）
    • B 可以写 X（Confidential⩽Secret\text{Confidential} \le \text{Secret}）
    • B 可以写 Y（Confidential⩽Confidential\text{Confidential} \le \text{Confidential}）

特点：

  • 数据本身带有密级标记，标记与数据不可分割。
  • 访问控制是强制性的，用户无法更改。
  • 适用于需要严格、固定密级分类的环境。

DAC 与 MAC 的结合：通常，一个安全的 DBMS 会同时支持 DAC 和 MAC。用户的访问请求需要首先通过 DAC 检查（是否有权限），然后通过 MAC 检查（是否符合密级规则）。只有两者都通过，访问才被允许。

graph LR
    Request[SQL 请求] --> DAC{DAC 检查};
    DAC -- 通过 --> MAC{MAC 检查};
    DAC -- 失败 --> Deny[拒绝访问];
    MAC -- 通过 --> Allow[允许访问];
    MAC -- 失败 --> Deny;

    style Allow fill:#cfc, stroke:#333, stroke-width:2px
    style Deny fill:#f99, stroke:#333, stroke-width:2px

视图机制（View Mechanism）

视图是从一个或多个基本表导出的虚拟表。它本身不存储数据，而是存储查询定义。视图在数据库安全中扮演重要角色：

  • 提供访问控制：可以将表的部分行（基于 WHERE 子句）或部分列（基于 SELECT 列表）定义为视图，然后只将视图的权限授予用户，从而隐藏了用户不需要或无权访问的数据。
  • 简化权限管理：对视图授权比对复杂的基表授权更简单直观。
  • 实现基于谓词的权限：视图的 WHERE 子句可以实现复杂的、基于数据内容的访问控制。

示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
-- 为计算机系（CS）学生创建视图，并授权
--- 1. 创建视图 CS_Student
CREATE VIEW CS_Student AS
SELECT Sno, Sname, Sage -- 只选择部分列
FROM Student
WHERE Sdept = 'CS'; -- 只选择部分行

--- 2. 授予王平查询此视图的权限
GRANT SELECT ON CS_Student TO 王平;
--- 王平只能查询 CS 系学生的学号、姓名、年龄

--- 3. 授予张明对该视图的所有权限（SELECT, INSERT, UPDATE, DELETE）
GRANT ALL PRIVILEGES ON CS_Student TO 张明;
--- 张明可以通过视图操作 CS 系学生的数据（受限于视图定义和基表约束）

视图更新限制

并非所有视图都是可更新的。如果视图涉及聚合函数、GROUP BY、DISTINCT、多表连接（且不满足特定条件）等，可能无法通过视图进行 INSERT, UPDATE, DELETE 操作。

审计（Audit）

审计功能用于记录数据库中发生的特定操作和事件，以便事后追踪、分析和问责。

  • 目的：监控用户行为，发现非法操作或潜在安全威胁，满足合规性要求。
  • 实现：启用审计日志（Audit Log/Audit Trail），记录指定事件的相关信息（如操作用户、时间、对象、操作类型、成功/失败状态等）。
  • 要求：TCSEC C2 及以上级别的 DBMS 必须提供审计功能。
  • 特点：
    • 可选性：审计会消耗系统资源（CPU、存储空间），DBA 可以根据需要开启或关闭，并配置审计范围。
    • 审计级别：通常分为用户级审计（用户审计自己创建的对象）和系统级审计（DBA 设置，监控系统范围事件）。
    • 审计事件类型：
      • 服务器事件：数据库启动、关闭、配置更改。
      • 系统权限：GRANT, REVOKE, CREATE USER 等 DCL/DDL 操作。
      • 语句事件：特定类型的 SQL 语句执行（如 SELECT, DELETE）。
      • 模式对象事件：对特定表、视图等对象的操作。
    • 审计日志管理：需要安全存储审计日志，防止篡改，定期转储，并提供查询分析工具。

审计 SQL 语句：

  • AUDIT：设置审计功能。 
    1
    2
    -- 对 SC 表的结构修改（ALTER）或数据修改（UPDATE）操作进行审计
    AUDIT ALTER, UPDATE ON SC;
  • NOAUDIT：取消审计功能。 
    1
    2
    -- 取消对 SC 表的 ALTER 和 UPDATE 操作的审计
    NOAUDIT ALTER, UPDATE ON SC;

数据加密（Data Encryption）

加密是防止数据在存储或传输过程中被非授权用户读取的最后一道防线。

  • 基本思想：使用加密算法和密钥（Key）将明文（Plaintext）转换为不可直接识别的密文（Ciphertext）。只有持有相应密钥和解密算法才能将密文还原为明文。

加密类型：

  1. 存储加密
    • 透明存储加密（Transparent Data Encryption, TDE）：
      • 方式：在 DBMS 内核层面实现。数据写入磁盘时自动加密，读出时自动解密。
      • 优点：对应用程序完全透明，无需修改代码。性能较好，安全完备性高。
      • 实现：通常在表空间或列级别配置。
    • 非透明存储加密：
      • 方式：通过 DBMS 提供的加密函数（如 ENCRYPT(), DECRYPT()）或在应用程序层面实现。
      • 缺点：需要修改应用程序或 SQL 查询来调用加解密函数。性能开销可能较大。
  2. 传输加密
    • 链路加密（Link Encryption）：
      • 方式：在物理层或链路层对整个通信链路进行加密（如 VPN）。
      • 特点：加密所有内容，包括报头和报文。对上层协议透明。
    • 端到端加密（End-to-End Encryption）：
      • 方式：在发送端应用程序（或协议栈较高层）加密数据，在接收端解密（如 SSL/TLS）。
      • 特点：通常只加密报文数据，报头（包含路由信息）不加密。需要两端协商密钥。安全性好，但元数据可能泄露。数据库连接通常使用 SSL/TLS 进行端到端加密。

其他安全性保护技术

  1. 推理控制（Inference Control）：
    • 问题：防止用户通过组合多个低权限查询结果，推断出其无权访问的高敏感度信息。常见于统计数据库。
    • 对策：限制查询结果的精度（如对小集合的统计查询返回近似值或拒绝查询）、数据扰动（添加噪声）等。
  2. 隐蔽信道控制（Covert Channel Control）：
    • 问题：防止信息通过非预期的、间接的途径泄露（如利用系统资源的使用模式、时间延迟等传递信息）。
    • 对策：通常在系统设计层面进行分析和限制，较难完全消除。
  3. 数据隐私保护（Data Privacy）：
    • 范围：更侧重于保护与个人身份相关的敏感信息（PII），涉及数据的收集、存储、处理、发布、销毁等全生命周期。
    • 要求：遵循相关法律法规（如 GDPR, CCPA），采取技术和管理措施（如匿名化、假名化、访问控制、用户同意管理等）。

小结

  • 随着数据共享的普及，数据库安全保密日益重要。
  • DBMS 必须提供一套完整有效的安全性机制。
  • 核心技术和方法包括：
    • 用户身份鉴别：确认用户身份。
    • 存取控制：通过 DAC（灵活）和 MAC（严格）控制用户权限。
    • 视图技术：提供数据子集访问，简化权限管理。
    • 审计技术：记录操作，用于监控和追溯。
    • 数据加密：保护存储和传输中的数据。
  • 此外，推理控制、隐蔽信道控制和数据隐私保护也是数据库安全的重要方面。