2、访问控制模型：DAC、MAC、RBAC

好，咱们今天聊聊访问控制模型。这三个缩写——DAC、MAC、RBAC——在座舱系统里几乎是天天打交道的东西。说白了，它们就是决定「谁能碰什么」的一套规则。

我刚开始做座舱系统那会儿，总觉得这玩意儿不就是个权限开关嘛，后来踩了坑才明白，选错模型，系统可能直接崩给你看。你想想看，飞机在天上飞，座舱显示系统要是被误操作改了关键参数，那可不是闹着玩的。

2.1 自主访问控制（DAC）

DAC 的全称是 Discretionary Access Control。翻译过来就是「自主」——资源的主人说了算。

核心思想：谁创建了文件或数据，谁就有权决定谁能访问它。比如我写了一份飞行计划，我可以选择让副驾驶看，不让观察员看。

在座舱系统里，DAC 其实挺常见的。举个例子：

• 飞行员个人设置（座椅位置、显示亮度）——只有当前飞行员能改
• 飞行日志文件——机长可以授权副驾驶查看
• 临时航路修改——谁改的谁负责，其他人只能读

2.2 强制访问控制（MAC）

MAC 的全称是 Mandatory Access Control。这个就严格多了——系统说了算，用户没得选。

核心思想：每个主体（用户、进程）和客体（文件、数据）都有一个安全标签。系统根据标签的级别来决定是否允许访问。比如「绝密」级别的数据，只有「绝密」级别的用户才能看。

在座舱系统里，MAC 是安全底线。为什么？因为座舱系统涉及飞行安全，不能靠人的自觉性。

我举个例子：

• 飞行关键参数（空速、高度、姿态）——标签为「关键安全」，只有飞行控制模块能写
• 导航数据库——标签为「高完整性」，只有经过签名的更新才能写入
• 乘客娱乐系统——标签为「低安全」，不能访问任何飞行数据

安全级别	示例数据	可写主体	可读主体
绝密	飞行控制算法	飞控计算机	飞控计算机、安全审计
机密	导航数据库	导航系统、签名的更新	所有飞行系统
内部	飞行日志	机组人员	机组人员、地面维护
公开	乘客信息	客舱系统	所有人

为什么会这样？因为座舱系统要满足 DO-178C 的安全要求。MAC 模型能保证即使某个分区被攻破，攻击者也拿不到高安全级别的数据。

2.3 基于角色的访问控制（RBAC）

RBAC 的全称是 Role-Based Access Control。这个是目前最常用的模型——权限不直接给用户，而是给角色，用户通过扮演角色来获得权限。

核心思想：你是什么角色，就有什么权限。比如「机长」角色可以执行起飞操作，「副驾驶」角色只能辅助操作，「乘务员」角色根本碰不到飞行控制。

在座舱系统里，RBAC 是管理权限的利器。我参与过一个项目，座舱系统里有几十种操作权限，如果每个用户单独配，那维护成本高得吓人。用 RBAC 就简单了：

• 定义角色：机长、副驾驶、观察员、地面维护、客舱乘务员
• 给角色分配权限：机长有全部权限，副驾驶有部分权限，观察员只有只读权限
• 把用户分配到角色：今天飞这趟航班的是张三机长、李四副驾驶

举个例子，一个典型的 RBAC 配置：

角色: 机长
  权限:
    - 飞行控制: 全部（起飞、降落、自动驾驶）
    - 导航: 全部（修改航路、切换导航源）
    - 通信: 全部（切换频率、发送消息）
    - 系统设置: 全部（校准、配置）

角色: 副驾驶
  权限:
    - 飞行控制: 部分（不能执行起飞、降落）
    - 导航: 全部
    - 通信: 全部
    - 系统设置: 只读

角色: 观察员
  权限:
    - 飞行控制: 只读
    - 导航: 只读
    - 通信: 只读
    - 系统设置: 无

2.4 三种模型的对比与选择

好了，三种模型都讲完了。你可能会问：到底用哪个？

我的建议是：

• DAC：适合非关键、需要灵活性的场景。比如个人设置、临时数据共享。但别用在安全关键功能上。
• MAC：适合安全关键、需要强制隔离的场景。比如飞行控制、导航数据、安全审计。这是座舱系统的底线。
• RBAC：适合权限管理复杂、需要角色划分的场景。比如机组人员权限管理、地面维护权限。这是日常操作的主力。

实际项目中，往往是三种模型混用。比如座舱系统里：

• 核心飞行数据用 MAC 保护，谁都不能乱改
• 机组人员操作权限用 RBAC 管理，不同角色不同权限
• 个人设置用 DAC，飞行员自己说了算

好，这一章就到这儿。下一章咱们聊聊「安全审计与日志管理」，看看怎么把谁干了什么都记下来。