【数据库系统原理】第35篇：自主访问控制与强制访问控制：权限传递与安全标记

目录

一、安全与可靠性的边界：从故障容错到恶意防范

二、自主访问控制的基本模型：主体、客体与权限

三、GRANT与REVOKE：权限的授予与回收

四、角色机制：权限管理的抽象层

五、自主访问控制的局限：特洛伊木马与权限泄漏

六、强制访问控制：安全标记与Bell-LaPadula模型

七、多级安全数据库的实现：标记在粒度上的锚定

八、两种机制的协同部署：纵深防御

九、结语：信任的边界

一、安全与可靠性的边界：从故障容错到恶意防范

此前八篇文章——从事务的ACID属性到ARIES恢复算法，从锁机制到MVCC，从检查点到影子分页——构建了数据库可靠性的完整保障体系。这套体系的共同前提假设是：系统中的所有操作者都是善意的，故障来自硬件、软件或环境因素，而非来自恶意行为。我们假设事务的发起者不会故意绕过完整性约束，假设SQL查询的提交者不会蓄意窥探无权访问的数据。

然而，当数据库暴露在开放网络环境中，面对多租户共享、多应用接入、多角色协作的复杂生态时，这一善意假设便不再成立。财务数据必须对人力资源部门屏蔽，客户隐私信息必须对分析查询脱敏，核心配置表必须对普通应用账户只读。数据库系统必须内置一套独立于事务逻辑之外的安全机制，对每一次数据访问进行身份验证与权限裁决。

数据库安全机制的技术基石是访问控制——系统在接收到每个SQL请求时，判断发出该请求的主体是否有权执行所请求的操作。访问控制的实现路径分为两大范式：自主访问控制将权限管理权授予数据的所有者，用户之间可以相互传递权限；强制访问控制将权限判定权收归系统，依预设的安全标记强制裁决，用户无权绕过或传递。两者不是竞争关系，而是互补关系——大多数企业级数据库系统同时部署两种机制，形成纵深防御。

二、自主访问控制的基本模型：主体、客体与权限

自主访问控制的名称源自其核心特征：数据属主对自己拥有的数据享有自主的管理权，可以决定谁能够以何种方式访问这些数据。这种控制是“自主”的，因为权限的授予与回收完全由属主自行决定，系统不干涉属主的权限管理选择。

在形式化模型中，自主访问控制涉及三个基本要素。主体是发起访问请求的实体——通常是数据库用户或角色。客体是被访问的数据对象——表、视图、列、存储过程等。权限是主体对客体可以执行的操作类型——SELECT（读取）、INSERT（插入）、UPDATE（更新）、DELETE（删除）、REFERENCES（创建外码引用）、EXECUTE（执行存储过程）等。

权限的存储采用访问矩阵模型。矩阵的行对应主体，列对应客体，矩阵元素为主体对客体的权限集合。例如，矩阵中(用户张三, 表员工)位置的值为{SELECT, INSERT}，表示张三对员工表有查询和插入权限。访问矩阵在理论上是简洁的，但在实践中，大型数据库可能拥有数千用户和数万对象，访问矩阵将极其稀疏且难以高效存储和管理。

工程实现中，访问矩阵通常以两种等价形式存储：按列存储——每个对象附带一个访问控制列表，记录哪些用户对该对象拥有哪些权限；按行存储——每个用户附带一个能力列表，记录该用户对哪些对象拥有哪些权限。关系数据库系统普遍采用访问控制列表方式，因为权限检查发生在访问对象时——系统在打开表之前查询该表的访问控制列表，判断当前用户是否有权执行所请求的操作。这一查询以对象为索引，自然匹配访问控制列表的存储方式。

三、GRANT与REVOKE：权限的授予与回收

SQL语言通过两条DCL语句——GRANT和REVOKE——为自主访问控制提供了语法接口。这两条语句在第9篇的DCL概述中曾被简要提及，此处展开其完整语义与权限传递模型。

GRANT语句的基本语法为：

sql

GRANT 权限列表 ON 对象 TO 用户列表 [WITH GRANT OPTION];

这条语句将指定对象上的指定权限授予指定用户。可选项WITH GRANT OPTION赋予被授权者将所获权限进一步授予其他用户的权力——这正是“权限传递”的机制核心。如果张三将员工表的SELECT权限授予李四并附带WITH GRANT OPTION，李四就可以进一步将此SELECT权限授予王五。

REVOKE语句的语法与之对称：

sql

REVOKE [GRANT OPTION FOR] 权限列表 ON 对象 FROM 用户列表 [CASCADE | RESTRICT];

REVOKE收回已授予的权限。其复杂性在于权限可能已经通过授权链传播。如果张三授予李四，李四又授予王五，当张三收回李四的权限时，王五的权限是否应当随之消失？SQL标准通过CASCADE和RESTRICT选项来处理这一问题。CASCADE表示级联回收——收回李四的权限时，自动收回李四曾经授予他人的所有依赖权限，包括王五的权限。RESTRICT表示受限回收——如果李四已经将权限授予了王五（即存在依赖权限），则拒绝回收李四的权限，回收操作失败报错。

级联回收要求系统维护权限之间的依赖关系。每当用户A将权限授予用户B，系统在数据字典中记录一条授权记录，包含授权者、被授权者、权限类型、对象和授权时间。这些记录构成了一棵授权图——节点是用户，有向边从授权者指向被授权者，边的标签是权限和对象。REVOKE CASCADE操作在这棵图上执行级联删除，删除某条边时同时递归删除其所有后继边。

四、角色机制：权限管理的抽象层

如果权限只允许在用户之间直接授予和回收，用户数量增长将导致权限管理迅速失控。一个拥有数百用户和数百张表的数据库，如果每个用户的权限都需要逐一手动管理，管理负担将达到不可承受的程度。角色机制正是为解决这一管理复杂度而引入的抽象层。

角色是一个命名的权限集合。角色本身不登录数据库，它是一个抽象容器——将一组相关的权限打包为一个逻辑单元。用户的权限不直接逐条授予，而是通过将角色授予用户来间接赋予。一个用户可以拥有多个角色，一个角色也可以被授予多个用户。

角色的典型使用模式是岗位映射。企业数据库中通常创建与组织岗位对应的角色——财务经理、销售代表、系统管理员。每个角色被授予执行该岗位职责所需的全部权限。当一名新员工入职时，只需将其数据库用户账号授予对应的角色。当员工调岗时，只需收回旧角色、授予新角色，无需逐一调整数十条对象权限。

角色之间同样支持授予关系。一个角色可以被授予另一个角色，形成角色层次。例如，“部门经理”角色可以被授予“普通员工”角色的全部权限，外加额外的管理权限。这种角色继承关系通过将角色间的权限授予链在角色层次中向上传递来实现，进一步简化了权限管理的层次结构。

五、自主访问控制的局限：特洛伊木马与权限泄漏

自主访问控制赋予了数据属主灵活管理权限的自由，但这种自由同时埋下了安全隐患。最经典的攻击模型是特洛伊木马——一个被授权用户无意中执行了恶意程序，该程序利用用户的合法权限将数据泄露给未授权者。

设想以下场景：用户张三拥有表“员工薪资”的SELECT权限。张三下载并运行了一个表面上无害的数据库工具程序，该程序在后台执行以下操作——创建一个新表“泄露数据”，将SELECT * FROM 员工薪资的结果插入该表，然后通过GRANT将“泄露数据”的SELECT权限授予恶意用户李四。这一系列操作完全在张三的合法权限范围内执行，自主访问控制系统无法识别其为恶意行为——因为张三有权读取员工薪资，有权创建新表，有权将自己创建的表授予他人。

这就是自主访问控制的根本性缺陷：权限管理由用户自主决定，系统无法控制权限在主体之间的流动方向。一旦数据被合法地读取，它就可以通过创建副本和授予权限的方式流向任何未被属主预期的主体。自主访问控制保护的是“数据的访问入口”，而非“数据本身”——一旦数据被合法地从入口取出，它就脱离了原属主的控制。

这种对信息流动方向的无控制，正是强制访问控制所要解决的核心问题。

六、强制访问控制：安全标记与Bell-LaPadula模型

强制访问控制采取了与自主访问控制截然不同的哲学。在强制访问控制下，权限不由数据属主管理，而是由系统根据全局安全策略强制裁决。每个主体和每个客体都被分配一个安全标记，访问许可完全由安全标记之间的比较决定，用户无法通过GRANT或任何其他操作改变自己或他人的安全标记，也无法将自己读取到的数据传递给安全标记不匹配的其他用户。

强制访问控制的标准理论模型是Bell-LaPadula模型，由David Bell和Leonard LaPadula于1973年提出。该模型以模仿军事信息安全中的密级制度为基础，定义了信息单向流动的严格规则。

Bell-LaPadula模型为每个主体（用户）和客体（数据对象）分配一个安全级别。安全级别通常由密级和范畴两部分组成。密级构成一个严格的全序——例如绝密 > 机密 > 秘密 > 公开。范畴构成一组非序的分类标签——例如{核武器, 常规武器, 后勤}，彼此之间没有高低之分。一个安全标记由密级和范畴集共同构成。

访问控制基于两条铁律。简单安全属性——亦称“不下读”——规定主体只能读取安全级别小于等于自身安全级别的客体。换言之，机密级用户不能读取绝密级文件，但可以读取机密级和秘密级文件。星属性——亦称“不上写”——规定主体只能写入安全级别大于等于自身安全级别的客体。换言之，机密级用户不能将数据写入秘密级文件——因为那将导致信息从高密级泄漏到低密级。

两条规则的组合产生了严格的信息单向流动约束。信息只能从低安全级别流向高安全级别，永远不能反向流动。一个机密级用户从秘密级文件中读取数据后，无法将该数据写入任何低于机密级的文件中。即使用户试图以恶意软件绕过——如自主访问控制场景中的特洛伊木马——强制访问控制系统也会在写入操作时依据星属性拒绝执行，从而从根本上杜绝了权限泄漏。

七、多级安全数据库的实现：标记在粒度上的锚定

将Bell-LaPadula模型映射到关系数据库，核心工程挑战在于安全标记的粒度——标记应该锚定在什么数据库对象层级上。

最基本的粒度为表级标记。整张表被赋予一个安全标记，表中的所有行继承该标记。这是实现复杂度最低的方案，但粒度最粗——无法在同一张表内区分敏感度不同的数据行。

更精细的粒度为行级标记。每行数据拥有独立的安全标记。同一张员工表中，“公开信息”行可以被所有用户读取，“薪资信息”行仅被高密级用户读取，“绩效评估”行仅被最高密级用户读取。用户执行SELECT * FROM 员工表时，系统在返回结果之前逐行检查安全标记，过滤掉用户无权读取的行，仅返回安全级别匹配的行。这种过滤对用户透明——用户不知道自己看到的是表的一个“子集”，以为员工表就是自己看到的大小。

行级标记结合列级标记可以实现更精细的多维控制。某些列的数据可以具有比行更高的安全标记，即使用户有权读取该行，也无权读取该行的特定列。

强制访问控制在商业数据库中的典型实现是Oracle Label Security和PostgreSQL的SE-PostgreSQL扩展。在这些系统中，管理员预先定义安全策略和标记集合，标记通过DDL语句附加到表和行上。查询时的标记过滤在查询执行引擎层面实现，与用户权限无关——即使以DBA身份登录，也无法绕过标记过滤读取超出自身安全级别的数据。

八、两种机制的协同部署：纵深防御

自主访问控制与强制访问控制并非二选一的替代关系。在企业级数据库安全架构中，两者协同部署，构成纵深防御体系。

自主访问控制负责粗粒度的入口控制——用户能否连接数据库，能否访问某张表，能否执行某种操作。它解决的是“谁能进哪个门”的问题，管理灵活、粒度可调，适应多变的业务需求。

强制访问控制负责细粒度的信息流控制——数据一旦进入系统，就在全局安全标记的约束下单向流动。它解决的是“数据进了门之后往哪里流”的问题，规则刚性、不可绕过，防范来自内部的权限泄漏和特洛伊木马攻击。

两者在访问裁决中的协作顺序是：当用户发出SQL请求时，系统首先执行强制访问控制检查——用户的安全标记是否允许读取/写入目标数据的安全标记。如果强制访问控制拒绝访问，操作直接失败，无需进一步检查。如果强制访问控制允许访问，系统再执行自主访问控制检查——该用户是否被GRANT了所请求的权限。两道检查都通过，操作才能执行。这种“先MAC后DAC”的检查顺序确保了强制性规则不可被自主权限所覆盖。

九、结语：信任的边界

访问控制的核心命题是信任——系统信任谁，在什么范围内信任，信任的边界在哪里。自主访问控制将信任赋予数据属主，属主自行决定将权限传递给谁。强制访问控制将信任赋予系统全局策略，用户无权传递信任。

这一分野并非设计者的任意选择，而是对两种安全威胁模型的各自回应。自主访问控制回应的是合作环境中的操作隔离——同事之间需要分工协作，但各自的职责范围需要清晰界定。强制访问控制回应的是对抗环境中的信息泄漏——系统中可能存在恶意程序或已被攻陷的账户，信息的流动方向必须在系统层面被不可绕过地约束。

下一篇，我们将从访问控制的授权与标记转向另一道安全防线——数据加密与审计追踪。当访问控制可能被绕过或配置失误时，加密为静态数据和传输数据提供最后一道保密屏障，审计日志则为事后追溯和合规审查留下了不可篡改的操作记录。安全不是单点防御，而是纵深层次的多重守护。