NCSC-TG-015《A Guide to Understanding Trusted Facility Management》（彩虹书·棕色卷）
文件：NCSC-TG-015(Brown).pdf，47 页，文本型 PDF 出品：美国国家安全计算机中心（NCSC），1989 年 6 月，主要作者 Virgil D. Gligor 博士（马里兰大学） 系列地位：TCSEC（橙皮书）配套技术指南”彩虹系列”之一，编号 NCSC-TG-015，解读”可信设施管理（Trusted Facility Management, TFM）“这一操作性保证要求。
一句话主旨
TCSEC 从 B2 级起强制要求”可信设施管理”，其核心是管理员职能与操作员职能分离（B2）、安全相关职能与非安全相关职能分离（B3）——通过职能、接口、权限、数据库四个维度的分离，防止人为失误、越权和恶意行为破坏 TCB 用来执行安全策略的数据。
1. 问题背景：管理角色的三类固有弱点（第 2 章）
所有行政角色共有的三类通用弱点（与具体系统无关）：
- 未授权的硬件/软件配置修改 —— 可在系统生命周期任何阶段发生
- 行政角色被渗透 —— 通常因标识鉴别、TCB 保护或角色分离机制薄弱所致
- 行政权限滥用 —— 粗心或故意滥用管理权限，可同时造成 TCB 与用户安全违规，破坏面极大
对策不是消灭角色，而是通过职能分离把每种角色的爆炸半径限制在其最小权限内。
2. TCSEC 各级要求速览（第 3 章）
| 级别 | 可信设施管理核心要求 |
|---|---|
| C1–B1 | 无 TFM 要求 |
| B2 | 管理员/操作员职能必须分离；TCB 管理程序满足模块化、最小权限；管理角色用逻辑隔离的存储对象；B2 全部标识鉴别与审计要求逐一适用于每个管理用户；TCB 须支持独立的 Operator 与 Administrator 职能 |
| B3 | 在 B2 之上：安全相关行政职能必须与非安全相关职能分离；安全相关职能严格限于”有效履行安全角色所必需”；安全人员所有行为必须审计；安全管理员角色须经显式可审计动作方可担任；可信路径要求适用于管理用户；非安全相关职能原则上移出 TCB |
| A1 | 在 B3 之上叠加配置管理与可信分发要求；另需保证系统从安全状态启动、运行中断后恢复安全运行 |
B2 还要求 Trusted Facility Manual（可信设施手册）：面向系统管理员，说明受控职能与权限、审计文件维护、审计记录结构、保护特性交互、安全重建 TCB 的流程等。
3. 两大分离原则的实现要点（第 4 章）
4.1 管理员 vs 操作员分离
- 目的：限制不可信/出错代码对 TCB 安全数据的破坏；防止操作员借用管理员权限与数据库。
- 实现方式：管理员/操作员只能执行经过验证的受信代码；执行管理职务的人须另设普通账户；分离必须能证明”阻止执行不可信代码”。
- 数据库也要分离：管理员对共享库（如系统安全概况）有写权限，操作员仅需读——操作员的写权限应被消除；分离后还可用管理员的安全数据库对操作员职能做一致性校验。
- 角色关系是功能层级：管理员可随时降级扮演操作员，反之不行。
管理员的安全相关职能：定义/修改用户与系统安全特性（密级上下限、标签映射）、系统编程（配置/分发/安装/TCB 维护）、审计职能。 操作员的安全相关职能：启停外设并在管理员限定范围内设置设备密级、装载标签介质、崩溃后恢复用户文件、启停系统、例行维护 TCB 数据库（备份等，但不得改文件内容）。
4.2 安全相关 vs 非安全相关职能分离
- 依据（B3 原文）：“Security Administrator 所执行的职能必须被识别；行政人员必须经过一个独立的、可审计的动作才能担任安全管理员角色；该角色中的非安全职能须严格限于必需。”
- 理由：非安全职能所需信任度更低；其缺陷只应导致拒绝服务，不应导致安全/完整性违规。
4.3 与其他 TCSEC 要求的交叉
- SFUG（用户安全指南）面向普通用户，Trusted Facility Manual 只面向管理用户。
- 管理用户通常多级访问，须**-clearance 到系统最高密级**；管理角色代码须审查特洛伊木马/后门。
- 多班次系统允许多人同角色，但禁止共享角色口令——否则个人问责失效。
4. 六类行政角色职能分工（第 5 章，本文精华）
推荐把管理员职责细分到不同信任等级的角色（TCSEC 不强制，但强烈建议）：
| 角色 | 安全相关 | 核心职能 | 关键约束 |
|---|---|---|---|
| 安全管理员 Security Administrator | 是 | 标识鉴别参数（登录超时、失败次数、口令策略）；用户/组账户定义；MAC 标签映射、密级上下限、无标签数据导入打标、重分类；DAC 权限初始化与所有权变更；一致性校验；切断账户 | 修改四种数据库（安全概况、标签映射、文件系统层次、系统配置库）必须用受信编辑命令+可信路径；所有动作审计 |
| 系统程序员 System Programmer | 是（最高权限） | 可信系统分发与主副本、系统配置参数、TCB 非常规维护（补丁、可信恢复、修复损坏标签） | 唯一”部分动作可能不可审计”的角色（因其动作先于审计系统装载）；应尽量限定在维护模式；建议在开发机而非在役机上改 TCB；任何 TCB 代码修改都可能使系统评级失效 |
| 审计员 Auditor | 是 | 审计事件选择开关、审计文件管理（创建/清空/压缩/后处理）、隐蔽信道延迟与随机化参数设定 | 审计数据须定级 System High；审计员数据库须与其他角色严格分离——否则安全管理员可滥权后自删证据（TCSEC 虽不强制分离，指南强烈建议） |
| 安全操作员 Secure Operator | 是 | 启停系统并设时钟；在管理员限定范围内设设备密级；定位损坏文件（salvager 隔离直至修复）；TCB 数据库例行备份；装卸标签介质 | 不得有修改文件内容权限；不建议挂载无标签介质 |
| 账户管理员 Account Administrator | 否（非安全角色） | 记账文件、计费、账户启停、统计报表 | 所有输出须标记最高密级，否则可能通过账单泄露涉密信息 |
| 操作员 Operator | 否 | 用户卷备份、性能计量、响应用户请求、调整可见资源配额 | 可在 System Low–System High 间切换授权 |
其他可选角色：分析员 Analyst——可信到可给导入数据打标，但打标不得超过其最高 Clearance，行为按普通用户审计。
角色支配关系（role dominance，5.8 节）
- 系统程序员支配所有角色 → 也是脆弱度最高的角色。
- 审计员必须与其余所有角色严格分离（掌握包括管理员在内所有用户的行为数据）。
- 安全管理员支配安全操作员、账户管理员、分析员和普通用户；被支配角色彼此分离。
- 同角色用户互不支配：共享职能与数据库，但安全概况彼此不相交，保证个人问责。
- 层级关系可借 Biba / Clark-Wilson 强制完整性模型来设计。
5. 其他 TCSEC 要求对 TFM 的影响（第 6 章）
- 安全策略：管理数据库的共享关系各异——标签映射仅安全管理员私有；审计日志仅审计员私有；用户注册表安全管理员读写、审计员/安全操作员/账户管理员只读；口令文件由登录受信进程读、改密进程读写。现有 MAC/DAC 机制支撑不了时需新增机制（受限命令处理器、安全管理员不可修改的受限组等）。
- 问责：管理员鉴别必须个人级而非角色级；B3+ 可信路径须保证管理用户与其命令/进程之间无中间人；除维护模式的系统程序员外，一切管理功能使用必须审计。
- 保证：隐蔽通道分析和系统完整性测试对 TFM 不适用（管理角色人已审查、代码已审查）；TCB 接口定义与结构化要求（模块化/抽象/信息隐藏/分层）全部适用；最小权限要求管理数据库保护到单文件/单特权粒度，特权 TCB 调用按”按需”与进程绑定；非易失存储须原子更新，且至少一个管理角色有恢复能力。
可行动点 / 工程启示
- 设计任何多角色权限系统（运维平台、医疗设备软件、CI/CD）时的通用清单：①管理职能与日常操作职能分离；②安全配置动作须经显式可审计的”担任角色”动作；③审计角色与被审计的管理角色必须互斥；④最高权限角色（部署/DBA/root）限定在维护模式并双人规则；⑤同角色多人禁止共享凭据。
- “角色支配 + 同角色互不支配”是比 RBAC 角色继承更早成型的角色设计模型，可直接用于 RBAC 权限矩阵设计评审。
- 任何对已认证/已注册系统（相当于 TCSEC 评级）核心代码的现场修改都会使认证失效——医疗器械软件变更控制同理（可关联临床质谱仪注册项目的变更管理）。
关联
- NCSC-TG-007-Burgundy-设计文档化 —— 同系列（勃艮第卷，安全设计文档化指南）
- CSC-STD-003-85可信数据库系统解释-彩虹书节选 —— 同系列（红书配套，可信数据库解释）
- 隐蔽信道建模新方法-PRINCETON-2005 —— 本文中审计员负责隐蔽信道参数设定的延伸研究
- 形式化方法-裘宗燕-课程讲义 —— 文中建议用形式化安全/完整性模型定义角色分离