IT用語集 2024/12/03

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

コラム

UnsplashのKiwihugが撮影した写真

「情報セキュリティ国際評価基準」と呼ばれることが多い領域の中心は、IT製品やシステムのセキュリティ機能と、その実装・検証の妥当性を第三者が評価する枠組みです。中心になるのはCommon Criteria（CC、ISO/IEC 15408）で、調達や選定では、その評価方法であるISO/IEC 18045、各国の認証制度、相互承認の範囲まで含めて確認します。

Common Criteriaは組織の管理体制を認証する制度ではなく、製品やシステムを評価する枠組みです。認証ロゴだけで判断を終えるのではなく、TOEの範囲、前提条件、STの主張内容まで確認して、自社の用途に合うかを見分けます。

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

正式名称と位置づけ

「情報セキュリティ国際評価基準」は、Common Criteriaそのものの正式名称ではありません。実務では、主にCC（Common Criteria）またはISO/IEC 15408を中心に、評価方法のISO/IEC 18045、各国・地域の認証制度、相互承認の仕組みまで含めた領域を指す通称として使われます。

IPAの説明では、CC（ISO/IEC 15408）は、情報技術に関連した製品及びシステムが適切に設計され、その設計が正しく実装されていることを評価するための国際標準規格です。評価対象はソフトウェアだけでなく、ハードウェア、ファームウェア、システム全体まで含まれます。

ISMSとの違い

似た言葉としてISMS（ISO/IEC 27001）がありますが、こちらは組織の情報セキュリティマネジメントを対象にした認証です。一方、Common Criteriaは、製品やシステムがどのセキュリティ機能を持ち、その機能がどの根拠にもとづいて評価されたかを扱います。

そのため、ISMS認証がある企業の製品であっても、個別製品のセキュリティ機能まで自動的に保証されるわけではありません。逆に、Common Criteria認証があっても、導入企業の運用体制まで評価済みになるわけではありません。両者は置き換え関係ではなく、確認対象が異なります。

調達前に押さえたい見方

調達や選定でまず確認したいのは、次の3点です。

何が評価対象か：製品全体なのか、特定バージョン・特定構成なのか
何を主張しているか：アクセス制御、監査、暗号、識別・認証など、どの機能を評価しているか
どんな前提で成り立つか：管理者運用、物理配置、接続条件など、自社で満たすべき条件があるか

この3点を見ないまま認証の有無だけで比較すると、導入後に「評価済みだと思っていた範囲」と「実際に確認されていた範囲」がずれやすくなります。

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

評価で確認する内容

Common Criteriaでは、評価対象をTOE（Target of Evaluation）として定義し、TOEが満たすべき要件と、その要件を満たしている根拠を整理します。見る観点は大きく二つです。

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

CCの特徴は、機能の有無だけでなく、「その機能がどの資料と評価手順によって確認されたか」まで扱うところです。

PP・ST・TOEの関係

認証資料を読むときに最初に整理したい用語は、PP、ST、TOEです。

PP（Protection Profile：保護プロファイル）：TOE種別のセキュリティニーズを実装に依存せず定義した文書
ST（Security Target：セキュリティターゲット）：個別のTOEについて、セキュリティ要件を実装依存で定義した文書
TOE（Target of Evaluation）：実際に評価対象となる製品・システム。バージョン、構成、前提条件まで含めて特定されます

調達側は、まずSTでTOEの範囲を確認し、その後で自社の利用形態が前提条件から外れていないかを照合します。PPへの適合主張があっても、STに書かれた対象範囲が自社の想定構成と違えば、そのまま判断材料にはなりません。

評価レベル（EAL）の読み方

EAL（Evaluation Assurance Level）は、事前に定義された保証尺度のポイントを表す形式的なパッケージです。CCではEAL1からEAL7までの事前定義パッケージが用意されています。

ただし、EALは「数字が大きいほどどの環境でも安全」という意味ではありません。読解の要点は次のとおりです。

数字は、どの深さまで保証活動を求めたかを読むための材料です
用途適合は、EAL単体ではなく、STの主張内容と前提条件と合わせて判断します
製品カテゴリによっては、EALの高さだけでなく、PPまたはcPP（collaborative Protection Profile）への適合が重く見られることがあります

評価プロセスの流れ

Common Criteriaの評価は、一般に次の流れで進みます。

開発者が、ST、設計資料、テスト結果、脆弱性対応に関する資料などの評価用エビデンスを準備する
評価機関が、提出資料の分析、テスト、脆弱性評定を実施する
認証機関が、評価結果を確認し、認証の可否を判断する
認証後は、証明書や認証報告書などの情報が公開され、調達側が参照できる状態になる

調達時に見たいのは、認証マークの有無だけではありません。証明書、認証報告書、ST、適用したPPやcPPまでたどれるかどうかで、確認のしやすさが変わります。

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

各国・地域の認証制度

Common Criteriaは国際標準に基づく枠組みですが、実際の認証は各国・地域の制度で運用されます。日本では、IPAが運用するJISEC（Japan Information Technology Security Evaluation and Certification Scheme）がその役割を担います。

海外にも米国のNIAPなどの制度があります。どの制度で認証されたかによって、公開情報の書式、参照しやすい報告書、調達での扱いが変わることがあるため、認証元まで確認したほうが判断しやすくなります。

CCRAの意味と限界

認証結果の相互承認には、CCRA（Common Criteria Recognition Arrangement）が関わります。これにより、参加国間で一定範囲の認証結果を参照しやすくなります。

ただし、相互承認は無条件ではありません。CCRA 2014では、cPP適合の証明書や、一定範囲の保証コンポーネントに関する証明書が承認対象です。つまり、「どの国の認証でも、どの保証レベルでも同じ扱いになる」という理解は正確ではありません。調達時は、認証制度、評価形態、承認範囲をセットで確認したほうが安全です。

どんな製品・業界で参照されるのか

対象になりやすい製品

Common Criteriaが参照されやすいのは、調達や監査で「第三者評価の根拠」を示したい製品カテゴリです。例としては、次のような製品が挙げられます。

ファイアウォールやUTM
IDSやIPS
認証・ID関連製品、ICカード関連製品、暗号機能を持つ製品
OS、仮想化基盤、保護対象資産を持つ基盤製品

IPAのCC概説でも、評価対象はセキュリティ専用製品に限らず、OS、データベース、グループウェアなどまで含みます。製品カテゴリだけでなく、どの構成がTOEとして切り出されているかまで確認しないと、比較の精度は上がりません。

参照されやすい業界・場面

政府調達、重要インフラ、金融、医療など、説明責任が強く求められる領域では参照されやすい傾向があります。背景にあるのは、製品選定の理由を外部へ説明しやすいこと、監査で確認材料として扱いやすいこと、海外製品を比較するときの共通の土台として使いやすいことです。

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

認証があっても、そのまま安全とは言えない理由

認証は強い判断材料ですが、それだけで自社環境に適合するとまでは言えません。見落としやすいのは次の点です。

TOEの範囲：自社で使う冗長化構成、オプション、連携モジュールが評価対象に含まれているか
前提条件：管理者権限の管理、ログ保護、設置条件、更新手順などを自社で守れるか
主張している内容：STで主張していない機能まで、認証の印象で補っていないか

調達要件へ反映するときの進め方

認証情報を調達要件へ反映するときは、次の順で整理するとぶれにくくなります。

守るべき資産、想定する脅威、必要な機能を整理する
対象カテゴリにPPまたはcPPがあるかを確認する
候補製品のST、証明書、認証報告書を読み、TOE範囲と前提条件を比較する
自社の運用条件で成立するかを、保守体制や更新手順まで含めて確認する

この手順を踏むと、認証の有無だけではなく、「自社の条件で使えるか」という判断軸まで持てます。

参照しやすい場面と、過信しやすい場面

Common Criteriaは、製品比較の根拠をそろえたい場面、調達要件の説明責任を果たしたい場面、監査で第三者評価の有無を確認したい場面では参照しやすい枠組みです。

一方で、運用設計、監視体制、インシデント対応、他製品との接続設計まで認証だけで代替できるわけではありません。製品評価で得られる確からしさと、導入後の運用責任は分けて考えたほうが誤解を避けやすくなります。

よくある誤解

誤解：「EALが高い製品なら、どの環境でも安全」
→ 実態：EALは保証活動の深さを示す材料で、用途適合や運用条件は別に確認します。
誤解：「認証があるなら、運用体制も十分」
→ 実態：Common Criteriaは主に製品やシステムの評価で、組織運用の認証とは別です。
誤解：「認証ロゴがあれば比較は終わる」
→ 実態：ST、TOE範囲、前提条件、認証報告書を見ないと比較の精度は上がりません。

まとめ

情報セキュリティ国際評価基準という言い方で扱われる中心は、Common Criteria（CC、ISO/IEC 15408）と、その評価方法ISO/IEC 18045、各国の認証制度、相互承認の仕組みです。役割は、IT製品やシステムのセキュリティ機能と、その実装がどの根拠で評価されたかを第三者の手順で示すところです。

調達や選定で確認したいのは、認証の有無だけではありません。STで定義されたTOEの範囲、前提条件、PPやcPPとの関係、認証制度の承認範囲まで読めると、認証を「ロゴ」ではなく比較材料として使いやすくなります。