访问控制权限模型分析梳理

1. 概述

权限模型（Access Control Models）是信息安全领域用于管理资源访问的核心机制。它们定义了谁（主体）可以对什么（客体）进行哪些操作（如读、写、执行）。常见的模型包括DAC、MAC、RBAC、ABAC等。这些模型可单独使用或组合（如RBAC与ABAC的混合）。选择模型取决于系统需求，如灵活性、安全性、复杂度和规模。

几种主要模型的分析。

模型名称	全称	核心原理	优点	缺点	典型使用场景
DAC	Discretionary Access Control (自主访问控制)	用户（资源所有者）自行决定谁能访问其资源，通常基于访问控制列表 (ACL)。例如，文件所有者设置权限。	灵活性高，用户自主管理；易于实现。	安全性低，易受恶意用户影响（如病毒传播）；不适合高安全环境。	个人文件系统（如Windows NTFS、Unix文件权限）；小型协作工具。
MAC	Mandatory Access Control (强制访问控制)	系统强制执行基于标签的安全策略（如机密级别：公开、秘密、绝密）。主体和客体都有标签，访问需匹配规则。	高安全性，防止信息泄露；适合多级安全。	灵活性差，用户无法 override；管理复杂。	军事/政府系统（如SELinux、AppArmor）；高保密环境如银行核心系统。
RBAC	Role-Based Access Control (基于角色的访问控制)	用户分配角色，角色绑定权限。权限不直接赋给用户，而是通过角色间接管理。支持角色继承和会话。	易于管理大规模用户；符合最小权限原则；便于审计。	角色爆炸问题（太多角色）；静态，不易处理动态上下文。	企业应用（如ERP系统、HR软件）；云平台（如AWS IAM角色）。
ABAC	Attribute-Based Access Control (基于属性的访问控制)	基于主体、客体、环境和操作的属性（如用户部门、时间、位置）动态评估策略。通常用XACML语言定义规则。	高度灵活，支持动态决策；细粒度控制。	复杂，实现和性能开销大；策略管理困难。	云服务（如Azure AD）；IoT系统；需要上下文感知的场景如远程访问。
Rule-Based	Rule-Based Access Control (基于规则的访问控制)	定义一组规则（如IP过滤、时间限制），访问请求匹配规则通过。常与防火墙结合。	简单直接；易于自动化。	规则冲突可能；不适合复杂权限。	网络防火墙（如iptables）；API网关（如Kong）。
Capability-Based	Capability-Based Access Control (基于能力的访问控制)	用户持有"能力"（token-like），能力直接授予对特定资源的访问权，无需检查所有者。	高效，减少中央检查；支持分布式系统。	能力泄露风险；撤销困难。	操作系统（如Capsicum in FreeBSD）；分布式文件系统（如Google's Spanner）。

2. 详细分析

• DAC的使用：在日常开发中，常用于文件共享系统。实现示例：在Python中使用os.chmod设置文件权限。但在多用户环境中，易导致权限滥用，因此常与审计日志结合。
• MAC的使用：适用于严格分级系统，如在Linux上启用SELinux。策略文件定义标签，系统内核强制执行。缺点是调试复杂，但可防止越权（如root用户也受限）。
• RBAC的使用：最流行模型。在数据库中存储用户-角色-权限表。示例：在Spring Security中配置@PreAuthorize("hasRole('ADMIN')")。扩展时可添加角色层次（如admin继承user）。
• ABAC的使用：现代趋势，支持AI驱动决策。使用Policy Decision Point (PDP)评估属性。示例：在OAuth2中结合JWT token的claims进行属性检查。适合微服务架构，但需优化规则引擎以避免延迟。
• 混合模型：实际项目中常混合使用，如RBAC+ABAC（称为RBAC扩展），角色提供粗粒度，属性提供细粒度。示例：AWS使用角色（RBAC）+条件键（ABAC）。

3. 实施建议

• 选择依据：小型系统用DAC/RBAC；高安全用MAC/ABAC；动态环境用ABAC。
• 最佳实践：遵循最小权限原则（Least Privilege）；定期审计权限；使用工具如Open Policy Agent (OPA)统一管理多模型。
• 潜在风险：权限膨胀（权限过多导致漏洞）；配置错误（如默认全开权限）。
• 工具推荐：身份管理 - Keycloak/OAuth；策略引擎 - OPA；监控 - ELK Stack。

4. 权限模型的表格设计

DAC（自主访问控制） → 基于 ACL（Access Control List）

　　　　核心思想：每个资源（对象）拥有自己的权限列表，由资源拥有者决定谁能访问。

表名	说明	主要字段	关系说明
resources	资源表（文件、文章、记录等）	id, owner_id, name, type...	-
acls	访问控制列表（ACL）	id, resource_id, subject_id（用户/组ID）, subject_type（user/group）, permission（read/write/execute/delete）, granted_by（授予者）	多对一关联 resource

CREATE TABLE resources (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    owner_id BIGINT NOT NULL,           -- 资源拥有者（用户ID）
    name VARCHAR(255) NOT NULL,
    type ENUM('file','post','record') NOT NULL
);

CREATE TABLE acls (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    resource_id BIGINT NOT NULL,
    subject_id BIGINT NOT NULL,         -- 用户ID 或 组ID
    subject_type ENUM('user','group') NOT NULL,
    permission ENUM('read','write','execute','delete','all') NOT NULL,
    granted_by BIGINT,                  -- 谁授予的权限（可选，用于审计）
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (resource_id) REFERENCES resources(id) ON DELETE CASCADE
);

RBAC（基于角色的访问控制） → 最常用模型

　　　　核心思想：用户 → 角色 → 权限

　　

表名	说明	主要字段	关系说明
users	用户表	id, username...	-
roles	角色表	id, name, description	-
permissions	权限表（细粒度操作）	id, code（唯一标识，如 user:view）, name, resource, action	-
user_roles	用户-角色关联（多对多）	user_id, role_id	多对多
role_permissions	角色-权限关联（多对多）	role_id, permission_id	多对多

CREATE TABLE roles (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(50) UNIQUE NOT NULL,
    description VARCHAR(255)
);

CREATE TABLE permissions (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    code VARCHAR(100) UNIQUE NOT NULL,   -- 如 user:view, post:delete
    name VARCHAR(100) NOT NULL,
    resource VARCHAR(50),
    action VARCHAR(20)
);

CREATE TABLE user_roles (
    user_id BIGINT NOT NULL,
    role_id BIGINT NOT NULL,
    PRIMARY KEY (user_id, role_id),
    FOREIGN KEY (role_id) REFERENCES roles(id)
);

CREATE TABLE role_permissions (
    role_id BIGINT NOT NULL,
    permission_id BIGINT NOT NULL,
    PRIMARY KEY (role_id, permission_id),
    FOREIGN KEY (role_id) REFERENCES roles(id),
    FOREIGN KEY (permission_id) REFERENCES permissions(id)
);

ABAC（基于属性的访问控制） → 最灵活但最复杂

　　　　核心思想：不依赖固定角色，而是根据主体属性 + 客体属性 + 环境属性 + 操作动态评估。

　　　　常见实现方式有两种：

• • • 策略表 + 属性表（纯数据库实现，较重）
    • 外部策略引擎（如 OPA、Casbin）+ 数据库只存属性

表名	说明	主要字段
attributes	属性定义表	id, name, type（user/object/environment）, description
user_attributes	用户属性值	user_id, attribute_id, value
object_attributes	资源属性值	object_id, object_type, attribute_id, value
policies	策略表（核心）	id, name, effect（allow/deny）, description
policy_rules	策略规则（一条策略可有多条规则）	policy_id, attribute_id, operator（=,>,in等）, value
policy_actions	策略允许的操作	policy_id, action（read/write/delete）
policy_targets	策略适用的资源范围	policy_id, resource_type, resource_id（可选）

CREATE TABLE attributes (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(100) UNIQUE NOT NULL,
    category ENUM('subject','resource','environment','action')
);

CREATE TABLE user_attributes (
    user_id BIGINT NOT NULL,
    attribute_id BIGINT NOT NULL,
    value VARCHAR(255) NOT NULL,
    PRIMARY KEY (user_id, attribute_id)
);

CREATE TABLE object_attributes (
    object_id BIGINT NOT NULL,
    object_type VARCHAR(50) NOT NULL,
    attribute_id BIGINT NOT NULL,
    value VARCHAR(255) NOT NULL,
    PRIMARY KEY (object_id, object_type, attribute_id)
);

CREATE TABLE policies (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(100) NOT NULL,
    effect ENUM('allow','deny') NOT NULL
);

-- 规则示例：部门=销售 且 时间在工作日 且 操作=read
CREATE TABLE policy_conditions (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    policy_id BIGINT NOT NULL,
    attribute_id BIGINT NOT NULL,
    operator ENUM('=','!=','>','<','in','contains'),
    value VARCHAR(255)
);

MAC（强制访问控制） → 高安全场景

　　　　核心思想：系统强制基于安全标签（如机密级别：公开、内部、秘密、绝密）决定访问。

　　　　

表名	说明	主要字段
security_levels	安全级别定义	id, name（UNCLASSIFIED, CONFIDENTIAL, SECRET, TOP_SECRET）, level_value（数字越大越密）
users	用户表（扩展）	... + clearance_level_id（许可级别）
objects	资源表（扩展）	... + classification_level_id（分类级别） + compartments（可选：项目A、项目B等）
compartments	范畴/类别（需知原则）	id, name
object_compartments	资源所属范畴（多对多）	object_id, compartment_id

　　　　

**　　　　访问规则示例**（Bell-LaPadula模型）：

• • • 读：主体许可级别 ≥ 客体分类级别 且 主体范畴包含客体所有范畴
    • 写：主体许可级别 ≤ 客体分类级别 且 主体范畴 ⊆ 客体范畴

CREATE TABLE security_levels (
    id INT PRIMARY KEY,
    name VARCHAR(50) UNIQUE NOT NULL,
    level_value INT NOT NULL  -- 数字越大越密
);

CREATE TABLE compartments (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(50) UNIQUE NOT NULL
);

-- 用户许可级别（clearance）
ALTER TABLE users ADD clearance_level_id INT REFERENCES security_levels(id);

-- 资源分类级别
ALTER TABLE objects ADD classification_level_id INT REFERENCES security_levels(id);

-- 资源所属范畴（多对多）
CREATE TABLE object_compartments (
    object_id BIGINT NOT NULL,
    compartment_id BIGINT NOT NULL,
    PRIMARY KEY (object_id, compartment_id)
);

Capability-Based（基于能力的访问控制）

　　　　核心思想：用户持有"能力令牌"（Capability），令牌直接指向资源+操作，无需查中央权限表。

表名	说明	主要字段
capabilities	能力令牌表	id, token（唯一字符串或UUID）, user_id, resource_id, resource_type, permissions（JSON或多字段）, expires_at, revoked
capability_scopes	能力作用范围（可选）	capability_id, scope（特定记录ID等）

CREATE TABLE capabilities (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    token VARCHAR(255) UNIQUE NOT NULL,     -- JWT 或 UUID
    user_id BIGINT NOT NULL,
    resource_id BIGINT NOT NULL,
    resource_type VARCHAR(50) NOT NULL,
    permissions JSON NOT NULL,              -- ["read","write"]
    expires_at TIMESTAMP,
    revoked BOOLEAN DEFAULT FALSE,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

总结：

模型	推荐场景	表数量	复杂度	灵活性	性能
DAC	文件系统、个人资源共享	2-3	低	高	高
RBAC	企业级SaaS、中后台系统	4-6	中	中高	高
ABAC	云服务、IoT、需要上下文的场景	6+	高	极高	中
MAC	军事、政府、高保密系统	4-6	中高	低	高
CapBAC	分布式系统、微服务、临时授权	2-4	中	高	高