如果你做安全，迟早会碰到橙皮书。TCSEC 就是那本封面橙色的老标准。它不新，但很多现代安全评估的思路都能在它身上找到影子。

一句话结论

TCSEC 全称 Trusted Computer System Evaluation Criteria，中文常译为《可信计算机系统评估准则》，也有译作《可信计算机系统评价标准》。它是美国国防部标准，编号 DoD 5200.28-STD，1983 年 8 月 15 日首次发布，1985 年修订。因为封面是橙色，俗称橙皮书，属于彩虹系列。

TCSEC 为什么会出现

• 1970 年代，美国国防部需要为军事指挥控制系统采购计算机。问题很现实：机密信息和非机密用户可能在同一台机器上，怎么保证不串？
• 当时没有统一的安全评估方法。厂商说自己的系统安全，采购方很难验证。
• 于是 NCSC 推出 TCSEC，希望用标准化方式评估、分类、选择可信计算机系统。
• NCSC 是国家计算机安全中心，属于 NSA。

它关心哪些安全能力

TCSEC 评估的重点不只是“有没有密码”。它看一整套东西：

• 安全策略：系统按什么规则决定谁能访问什么。
• 身份识别与认证：用户是谁，怎么证明。
• 自主访问控制 DAC：资源所有者可以分配权限。
• 强制访问控制 MAC：系统根据标签强制限制访问。
• 审计：谁在什么时候做了什么，能不能追责。
• 安全保证：安全机制是否可靠，是否经过分析和验证。
• 文档与持续保护：设计、测试、维护、版本升级都要有据可查。

七个等级，从 D 到 A1

TCSEC 把可信级别分成四类七级。高等级包含低等级要求。级别越高，功能越强，保证要求也越重。

• D：最小保护。评估过，但没达到任何更高级别。基本没有像样的安全要求。早期 MS-DOS 常被拿来举例。
• C1：自主安全保护。要求登录，用户和数据分离，有基本自主访问控制。但保护较弱，特权用户可以绕过。实际使用不多。
• C2：受控访问保护。商业系统最常提到的级别。要求更细的访问控制、审计、对象重用控制、登录控制。Windows NT 3.51、Solaris 等曾拿到 C2 或相应评估。
• B1：标记安全保护。开始进入强制访问控制。主体和客体都有敏感标签，系统按标签强制执行访问规则。IBM MVS 是 B1 的经典例子。
• B2：结构化保护。强制访问控制覆盖所有对象。要求可信路径、最小特权、隐蔽信道分析、形式化安全策略模型。可信计算基要能系统化分析。
• B3：安全域。要求硬件分离保护安全域，代码开发过程受约束，比如模块化、分层、数据隐藏。还要有可信恢复。XTS-200、XTS-300 是 B3 例子。
• A1：验证设计。最高级。功能上满足 B3，还要形式化验证。安全模型要数学证明一致，隐蔽信道要形式化分析，顶层规范和实际代码要能对应。极少系统达到，波音 MLS LAN 是少数例子。

补充一句：C2 在商业上最常被提，B 级以上才真正要求强制访问控制，A1 是天花板。

三个真实应用场景

TCSEC 不是纸面标准，它真的影响过采购和产品方向。

• 军事指挥控制系统。TCSEC 最早就是为 WWMCCS 这类系统服务的。空军军事空运司令部需要处理机密信息，同时让不同权限的人使用系统，这直接催生了多级安全需求。
• 政府采购要求。很多美国联邦机构曾把 TCSEC 验证写进采购条件。厂商想卖产品给政府，就得做评估。这推动了操作系统安全功能的发展。
• 网络与操作系统评估。美国海军分析过 Windows NT 3.51 在军事网络中能否满足 C2 级信任要求。Trusted Mach 则瞄准 B3。IBM MVS、XTS 系列、波音 MLS LAN 也都是评估案例。
• 商业安全认证。C2 后来成了商业安全的事实门槛。很多企业采购安全操作系统时，会问“有没有 C2 评估”。

优点和缺点

先说优点。

• 它是第一个正式的计算机安全评估方法。在它之前，安全更多靠厂商自说自话。
• 它引入了评估等级和保证要求。信任不能只靠声明，要有分析、测试和文档。
• 它提出的安全策略、问责、审计、文档等主题，今天仍然是安全框架的核心。
• 它推动了操作系统安全功能的发展，比如审计、访问控制、标签、可信路径。

再说缺点。

• 偏重机密性。TCSEC 为保护政府机密信息设计，对完整性和可用性覆盖很少。企业关心数据准确和业务连续，这套标准就不够用。
• 主要面向独立操作系统。网络、分布式系统、应用软件很难直接套用。
• 美国中心。它反映美国军方需求，国际通用性和商业互操作性有限。
• 评估贵且慢。流程资源密集，政府赞助但资源有限，能评的产品不多。
• 功能和保证混在一起。TCSEC 把“系统能做什么”和“系统做得有多可靠”绑在同一个等级里，不便于比较不同功能需求的产品。
• 后来被取代。TCSEC 最终被 Common Criteria 取代。2005 年起，Common Criteria 正式成为替代标准。

评估流程怎么走

TCSEC 的评估由 NCSC 通过 Trusted Product Evaluation Program 管理。大致分三个阶段。

• 申请。厂商提交产品。如果政府没有需求，申请可能被拒。
• 初步技术审查。厂商和评估团队讨论进度、开发流程、评估计划，确定何时分配评估团队。
• 评估。评估分三部分，每部分都要技术评审委员会 TRB 批准后才能进入下一部分。
  • 设计分析：严格审查系统文档，不直接看源码。
  • 测试分析：评估测试覆盖，运行厂商提供的测试。
  • 最终评审：形成评估报告，批准后给出评级。

还有一个 Ratings Maintenance Program，简称 RAMP。它允许厂商在新版本中维持已有评级。厂商需要有经过培训的 Vendor Security Analyst。如果产品结构发生大变化，可能触发完整重评。

今天怎么应用 TCSEC 的思路

今天你不太可能直接拿 TCSEC 去做认证，但它的思路很实用。如果你在设计高安全系统，可以这样借：

• 先写清楚安全策略。保护什么，防谁，机密性、完整性、可用性各占多重。
• 给资产和用户定级。不同级别用不同标签和访问规则。
• 把功能要求和保证要求分开写。别只列功能，也要问证据够不够。
• 该上强制访问控制就上。高敏感场景里，DAC 不够，标签和 MAC 更可靠。
• 审计、最小特权、可信路径、对象重用这些控制，能上就上。
• 文档要齐。安全策略模型、顶层规范、测试计划、评估报告，都是保证的一部分。
• 做独立评审和持续维护。版本升级、结构变化后，要重新评估。

和 Common Criteria 的关系

TCSEC 后来被 ITSEC 和 Common Criteria 逐步取代。Common Criteria 由美国、加拿大、欧洲等合作推动，标准编号 ISO/IEC 15408。它吸收了 TCSEC 和 ITSEC 的经验，把功能要求和保证要求分开，引入保护轮廓 Protection Profiles，还支持国际互认。

但 TCSEC 的影响没有消失。今天讲评估保证等级、讲安全功能与安全保证分离、讲信任需要证据，这些都能追溯到橙皮书。

总结

TCSEC 是老兵，不是废纸。它的问题很明显，偏机密性、偏操作系统、评估贵、被 CC 取代。但它的贡献也很明显，它第一次把计算机安全评估做成了体系。

如果你在做安全架构、合规、操作系统安全或高保障系统，花点时间翻翻 TCSEC 的等级划分，不会亏。很多今天看起来新的问题，橙皮书里早就问过了：你的安全策略是什么？谁能访问什么？有没有审计？保证够不够？文档和验证做了吗？

这些问题，放到今天依然扎心。