一、接入控制基础

什么是接入控制

接入控制，说白了就是一套「谁可以做什么」的规则。

我在车联网项目里摸爬滚打这么多年，见过太多因为接入控制没做好而出的事故。有一次，一个测试脚本误操作了生产环境的车辆控制接口，差点让一批在途车辆同时急刹车。嗯，从那以后，我对接入控制的理解就深刻多了。

从技术角度看，接入控制是一种安全机制。它决定了一个实体（比如一个设备、一个用户、一个服务）能否访问另一个实体（比如一个API、一个文件、一个控制指令）。

你想想看，车联网系统里，车辆的控制指令能随便发吗？当然不能。一个非法指令可能导致车辆失控，后果不堪设想。

接入控制的目标

接入控制的目标其实很明确，就三个：

• 机密性：确保敏感信息不被未授权的人看到。比如车辆的位置数据、用户的驾驶习惯。
• 完整性：确保数据不被非法篡改。比如车辆固件版本、OTA升级包。
• 可用性：确保合法用户能正常使用系统。比如车主能正常远程解锁车门。

我个人习惯把这三个目标记成「CIA三原则」。每次设计接入控制方案时，我都会问自己：这个方案能不能同时满足这三个目标？

接入控制的三要素

接入控制的核心，就是三个要素：主体、客体、操作。

我画了一张图，帮你理解这三者的关系：

这张图很直观。主体发起操作请求，操作作用于客体，接入控制决策层根据规则决定允许还是拒绝。

1. 主体

主体就是发起访问的实体。在车联网场景下，主体可以是：

• 用户：车主、管理员、维修技师
• 设备：T-Box、车载中控、手机APP
• 服务：OTA升级服务、远程诊断服务、数据采集服务

我记得有一次做T-Box接入设计，发现同一个设备在不同场景下应该有不同的权限。比如T-Box在出厂模式下只能上报数据，不能接收控制指令。这个细节很容易被忽略。

2. 客体

客体就是被访问的资源。常见的有：

• 车辆控制接口：车门解锁、空调开关、车窗升降
• 数据资源：车辆状态数据、行驶轨迹、用户信息
• 系统功能：OTA升级、远程诊断、固件刷写

3. 操作

操作就是主体对客体执行的动作。常见的操作类型：

操作类型	说明	车联网示例
读取	获取数据但不修改	查询车辆位置、读取故障码
写入	修改数据或状态	更新车辆配置、修改用户偏好
执行	触发一个动作	远程解锁、启动空调、OTA升级
删除	移除数据或资源	删除诊断日志、注销设备

你可能会问：为什么要把操作分这么细？

原因很简单。一个维修技师可能需要读取故障码（读操作），但绝对不能让他执行远程解锁（执行操作）。如果不区分操作类型，要么权限太大，要么权限太小，都不合适。

三要素如何协同工作

三要素不是各自为战的。它们通过接入控制策略绑定在一起。

举个例子：

• 主体：车主手机APP（设备ID: APP_001）
• 客体：车辆VIN: LSVAU2A38N2100001
• 操作：执行「远程解锁」

接入控制引擎会检查：APP_001 是否有权限对 VIN:LSVAU2A38N2100001 执行「远程解锁」操作。如果策略允许，就放行；否则拒绝。

这个检查过程，我习惯叫它「权限匹配」。说白了就是查表——查主体-客体-操作这个三元组是否在授权列表里。

嗯，这里要注意：权限匹配不是简单的字符串比较。实际项目中，主体可能有角色继承关系，客体可能有层级结构。比如「管理员」角色继承「操作员」角色的所有权限，这就需要在匹配时考虑继承关系。

我个人习惯用「最小权限原则」来设计三要素的绑定关系。什么意思呢？就是只给主体完成工作所需的最小操作权限，多一个都不给。这样即使某个主体被攻破，损失也能控制在最小范围。

好了，接入控制的基础就讲到这里。三要素是后续所有接入控制模型（DAC、MAC、RBAC、ABAC）的基石。把这个搞懂了，后面的内容就顺了。