TCSEC（Trusted Computer System Evaluation Criteria）
TCSEC（Trusted Computer System Evaluation Criteria）は、米国国防総省がコンピュータシステムのセキュリティ機能と、その機能を信頼できる根拠を評価するために定めた基準です。表紙の色から「Orange Book（オレンジブック）」と呼ばれます。
1983年版に続き、1985年にDoD 5200.28-STDとして発行されました。NISTが公開する資料は2000年に撤回された歴史資料であり、現在の製品選定にそのまま適用する新しい認証基準ではありません。NISTの公開情報、TCSEC原文・序文
TCSECは何を評価するのか
TCSECは、誰がどの情報へアクセスできるかというセキュリティ方針、それを実行する機能、利用者の識別や監査、設計・検証・文書化などを評価します。機密情報の不適切な開示を防ぐことに重点がありますが、単に「機密性の機能があるか」だけを見る基準ではありません。
中心となる概念がTCB（Trusted Computing Base）です。セキュリティ方針を実現するハードウェア、ソフトウェア、ファームウェアの組み合わせを指します。たとえばアクセス制御を担うOSの仕組みも評価に関わります。「製品が安全そうか」という印象ではなく、保護の仕組みと、その実装を信頼できる証拠を扱うのが特徴です。TCSEC原文・序論
D・C・B・Aの評価区分
TCSECはD、C、B、Aの4区分に分かれ、具体的なクラスはD、C1、C2、B1、B2、B3、A1の7つです。上位クラスではアクセス制御の範囲に加え、設計や検証への要求も厳しくなります。
クラス | 主な特徴 |
|---|---|
D | 評価は受けたものの、上位クラスの要件を満たさないシステム。一定の安全性を保証する合格点ではありません。 |
C1 | 利用者とデータの分離、任意アクセス制御を中心とした保護。 |
C2 | より細かな任意アクセス制御、利用者ごとの責任追跡、監査、資源の再利用時の保護など。 |
B1 | C2を土台に、機密ラベルと強制アクセス制御を導入。 |
B2 | 強制アクセス制御の範囲を広げ、形式的な方針モデル、TCBの構造化、隠れチャネルの分析などを要求。 |
B3 | TCBの複雑さを抑え、アクセスの仲介と改ざん防止を徹底。監査や回復に関する要求も強化。 |
A1 | 機能面ではB3相当。設計仕様の形式的な検証、厳格な構成管理や配布管理などで保証を高めます。 |
この表は各クラスの特徴を要約したもので、認定要件の全文ではありません。TCSEC原文・各クラスの要件
C2とB1、B3とA1は何が違うのか
C2とB1の大きな違いは、ラベルに基づく強制アクセス制御です。 任意アクセス制御では、権限を持つ利用者などがアクセスを許す相手を設定します。強制アクセス制御では、システムが定めた方針とラベルに従って可否を決め、利用者の判断だけではその制約を変えられません。B1は、より厳格な情報の取り扱いを求める場面を考える手がかりになります。
B3とA1の違いは、機能の数よりも保証の方法です。 A1では形式的な設計仕様と検証などが求められます。「A1なら攻撃を受けない」「実装全体に欠陥がないと数学的に証明された」という意味ではありません。TCSEC自身も、製品の評価と、特定の利用環境で運用を承認する判断を区別しています。TCSEC原文・A1および評価の位置づけ
Common Criteria（CC）・EALとの違い
現在のセキュリティ評価を調べる際には、Common Criteria（コモンクライテリア）も確認すると、歴史的な区分との違いを理解できます。CCでは、評価対象（TOE）と解決するセキュリティ上の問題を明確にし、次の二つを分けて扱います。
セキュリティ機能要件（SFR）：対象がどのような保護機能を提供するか。
セキュリティ保証要件（SAR）：その機能が要件を満たすと、どのように確認するか。
共通する製品群への要求はPP、個別の評価対象についての要求はSTという文書で示されます。EAL1〜EAL7は保証要件をまとめた段階であり、製品の安全性を単純に点数化したものではありません。そのため「C2はEAL2」「A1はEAL7」のように、名前や数字だけで換算してはいけません。CC:2022 Part 1・評価の枠組み、CC:2022 Part 5・EAL
製品選定では評価ラベル以外に何を見るべきか
TCSECやCCを知る実務上の価値は、「評価された」という一言を具体的に確認できることです。製品資料に評価の記載があったら、次の順序で調べます。
対象を確認する：どの製品・バージョン・機能が評価対象なのか。
前提を確認する：想定する脅威、利用者、接続先、運用環境は自社と合うか。
評価の範囲を読む：必要な保護機能と、その検証方法が資料に含まれているか。
実際の運用を確認する：推奨構成、設定、更新、権限管理を自社で維持できるか。
これは評価資料を読むための確認例です。過去に評価された製品であっても、別バージョンや異なる構成へ結果をそのまま当てはめることはできません。クラス名を覚えるだけでなく、評価された範囲と実際に使う範囲を照合することが大切です。
関連する仕組みはリファレンスモニター、運用側の責任分担はシステムオーナーで解説しています。
確認日：2026年9月12日。TCSEC 1985年版とCC:2022の一次資料を参照しています。
