情報セキュリティ国際評価基準とは？ 10分でわかりやすく解説

UnsplashのKiwihugが撮影した写真      

情報セキュリティ製品やサービスを導入するとき、「この製品は信用できるのか」「第三者が評価しているのか」を判断するのは簡単ではありません。こうした課題に対して、製品のセキュリティ機能と、その実装が適切であることを第三者が評価・認証する枠組みとして知られているのが、いわゆる情報セキュリティ国際評価基準です。

本記事では、代表例であるCommon Criteria（コモンクライテリア）を中心に、何を評価する制度なのか、どんな文書と手順で評価が進むのか、調達や選定でどう使えばよいのかを、初学者でも迷わない粒度で整理します。読み終える頃には、「認証マークの意味」と「自社の用途で確認すべきポイント」を切り分けて判断できるようになります。

情報セキュリティ国際評価基準とは

情報セキュリティ国際評価基準の位置づけ

「情報セキュリティ国際評価基準」という言い方は、実務ではISO/IEC 15408（Common Criteria）と、その評価方法を定めたISO/IEC 18045に代表される、第三者評価・認証の枠組みを指して用いられることが多い表現です。ポイントは、製品やシステム（ソフトウェア／ハードウェア／アプライアンス等）を“対象”として評価する点にあります。

よく似た言葉に、組織の運用体制を評価するISMS（ISO/IEC 27001）がありますが、これは「組織のマネジメント（人・プロセス）」の認証です。一方、Common Criteriaは基本的に「製品・システム（モノ）」が評価対象です。両者は目的が違うため、どちらか一方だけで万全と考えないことが重要です。

情報セキュリティ国際評価基準の定義

情報セキュリティ国際評価基準（Common Criteria）は、情報セキュリティ製品やシステムについて、「どんなセキュリティ機能を提供するのか（機能要件）」と、「それが適切に設計・実装・検証されているといえる根拠（保証要件）」を、第三者が確認するための国際的な枠組みです。

重要なのは、評価が「何となく安全そう」ではなく、文書化された要件と証拠（エビデンス）に基づいて進むことです。これにより、調達側は比較しやすくなり、提供側は説明責任を果たしやすくなります。

情報セキュリティ国際評価基準の目的

情報セキュリティ国際評価基準が目指すのは、主に次の3点です。

1. 製品・システムのセキュリティ主張を、第三者評価によって分かりやすく示すこと
2. 開発・検証プロセスの透明性を高め、品質向上を後押しすること
3. 国・地域をまたぐ調達で、評価結果を一定範囲で通用させること

ただし、認証は万能の「合格証」ではありません。対象範囲（どこまでが評価対象か）と想定する利用環境（前提条件）を読まずにロゴだけで判断すると、期待と現実がズレる可能性があります。

情報セキュリティ国際評価基準が必要とされる背景

サイバー攻撃は高度化し、製品・サービスの内部は複雑になりました。その結果、利用者が「中身の実装」を直接検証するのは現実的ではありません。クラウドやサプライチェーンの普及で、調達先が国内外に広がるほど、共通言語での比較・説明が必要になります。

国際評価基準は、こうした状況で「第三者が一定の手順で確認した」という事実を、調達判断に取り込むための手段として利用されます。

情報セキュリティ国際評価基準の歴史

Common Criteriaは、米国の評価基準（TCSEC）や欧州各国の基準（ITSEC）など、各地域で発展してきた評価の考え方を統合し、国際的に通用する枠組みとして整備されてきました。現在も、技術の進歩や脅威動向に合わせて文書体系・運用が更新され続けています。

情報セキュリティ国際評価基準（Common Criteria）の全体像

評価で「何を」確認するのか

Common Criteriaでは、評価対象をTOE（Target of Evaluation：評価対象）として定義し、TOEが満たすべき要件と、要件を満たしている根拠を整理します。ここでの要点は、次の2つに分けて理解することです。

• セキュリティ機能要件：アクセス制御、監査（ログ）、暗号、識別・認証など、製品が提供するセキュリティ機能
• 保証要件：設計・実装・テスト・脆弱性分析など、主張した機能が「その通りに実装されている」といえる根拠の深さ

この枠組みは、「機能があるか」だけでなく「その機能が確からしく実装・検証されているか」に踏み込む点が特徴です。

必ず押さえたい文書：PP・ST・TOE

認証や評価の説明で頻出する用語は、最初に整理しておくと読みやすくなります。

• PP（Protection Profile：保護プロファイル）：ある製品カテゴリ（例：ファイアウォール等）に対して、「満たすべき要件」を定義した文書
• ST（Security Target：セキュリティターゲット）：個別製品（TOE）について、「何を満たす」と主張するかを定義した文書
• TOE（Target of Evaluation）：実際に評価される製品・システム（バージョン、構成、前提条件を含む）

調達側が読み解く際は、まずSTに書かれたTOEの範囲（どのモジュール・どの構成が対象か）を確認し、その上で「自社の利用形態が前提条件から外れていないか」を見ます。

評価レベル（EAL）をどう理解するか

Common Criteriaでは、評価の深さを示すパッケージとしてEAL（Evaluation Assurance Level）が知られています。一般にEALは1〜7の段階で説明され、数字が大きいほど要求される保証活動が厳格になります。

ただし、実務上の注意点があります。

• EALは「強いほど安全」という単純な序列ではなく、“どれだけ厳密に検証したか”の目安です。
• 製品カテゴリによっては、EALよりもPPへの適合（PP準拠）が重視される運用が一般的です。
• 評価の意味は、必ずST（何を評価したか）とセットで読み取ります。

評価プロセスの流れ

Common Criteriaの評価は、一般に次のような流れで進みます。ここでは「誰が何をするか」が分かるように整理します。

1. 開発者（ベンダー）が、STや設計資料、テスト結果、脆弱性対応方針など、評価に必要なエビデンスを準備する。
2. 評価機関（評価ラボ）が、提出物の確認、分析、テスト等を通じて、要件への適合性を評価する。
3. 認証機関（スキーム）が、評価結果を審査し、認証の可否を判断する。
4. 認証された場合、認証情報（証明書等）が公開され、調達側が参照できる状態になる。

ここで大切なのは、評価機関・認証機関が開発者から独立した第三者として運用される点です。評価の客観性は、この構造で担保されます。

認証制度（スキーム）と相互承認

国ごとに存在する「認証制度」

Common Criteriaは国際標準に基づく枠組みですが、実際の認証は各国・地域のスキーム（認証制度）が運用します。日本では、JISEC（Japan Information Technology Security Evaluation and Certification Scheme）として制度が運用されています。

海外にも、米国のNIAPなど、各国の制度が存在します。調達で「どこの認証か」が問題になる場合があるのは、制度の運用ルールや公開情報の形式が国ごとに異なるためです。

相互承認は「何でも無条件に通る」わけではない

Common Criteriaの評価結果は、CCRA（Common Criteria Recognition Arrangement）といった枠組みのもとで、一定の範囲で相互承認されます。これにより、開発者は市場展開をしやすくなり、調達側は参照できる選択肢が増えます。

一方で、相互承認の考え方は運用上の制約があります。たとえば、製品カテゴリや評価の形態（PP準拠など）によって、承認の扱いが異なることがあります。調達や要件定義に使う場合は、「どの制度の、どの評価形態の認証なのか」まで踏み込んで確認するのが安全です。

どんな製品・業界で活用されるのか

対象となりやすい製品例

Common Criteriaの評価対象になりやすいのは、調達や規制の観点で「根拠」を示したい製品カテゴリです。例として、次のようなものが挙げられます。

• ファイアウォール／UTM
• 侵入検知・侵入防止（IDS/IPS）
• 暗号モジュールを含む製品（ただし暗号の評価は別制度が関わる場合があります）
• 認証・ID関連製品（認証器、ICカード、関連システムなど）
• OSや仮想化基盤など、基盤として広く利用される要素

ただし、評価対象は常に「製品全部」ではありません。バージョンや構成、オプション、運用前提によって範囲が限定されるため、STの確認が欠かせません。

活用されやすい業界・用途

政府調達、重要インフラ、金融、医療など、説明責任が強く求められる領域で参照される傾向があります。理由は単純で、「第三者評価」という形式が、要件の説明と監査対応の両面で使いやすいからです。

導入・調達で失敗しないためのチェックポイント

「認証がある＝自社の用途で安全」とは限らない

認証は強い判断材料ですが、次の3点を見落とすと誤解が起きます。

• TOEの範囲：自社で使う構成（クラスタ構成、冗長化、特定オプション等）が評価対象に含まれているか
• 前提条件：運用上の制約（管理者権限の管理、ログの保護、更新手順など）が満たせるか
• 主張の内容：STで主張していない機能を、認証のイメージで補っていないか

調達要件に落とし込むときの考え方

調達要件として使うなら、次の順番で整理するとブレにくくなります。

1. 自社の脅威と守るべき資産を整理し、「必要な機能」と「必要な保証」の方向性を決める。
2. 対象カテゴリで一般的なPP（または同等の要件体系）があるかを確認する。
3. 候補製品について、STと証明書を参照し、TOE範囲と前提条件が合うかを比較する。

この手順を踏むと、「認証の有無」だけでなく、自社の条件に合うかという観点で選定できます。

よくある誤解

• 誤解：「EALが高いほど、どんな環境でも安全」
  → 実態：検証の厳密さの指標であり、用途適合は別問題です。
• 誤解：「認証がある＝運用体制も万全」
  → 実態：主に製品評価であり、組織運用（ISMS等）とは別軸です。
• 誤解：「認証ロゴがあれば比較は終わり」
  → 実態：STのTOE範囲・前提条件を読んで初めて比較が成立します。

まとめ

情報セキュリティ国際評価基準（Common Criteria）は、情報セキュリティ製品・システムについて、提供するセキュリティ機能と、その実装が適切である根拠（保証）を第三者が評価・認証するための国際的な枠組みです。調達側にとっては製品比較と説明責任の助けになり、提供側にとっては信頼性を示す手段になります。

一方で、認証は万能ではありません。判断の精度を上げるには、STで定義されたTOEの範囲、前提条件、主張している内容を確認し、自社の利用条件に照らすことが欠かせません。認証を「ゴール」ではなく、「選定の根拠を厚くする材料」として使うことで、導入後のギャップを減らし、実務に活きる選定につながります。