← ホームへ戻る

コモンクライテリア(CC)とは?IT製品のセキュリティ評価基準を徹底解説

現代のITインフラにおいて、製品のセキュリティ性能を客観的に証明することは極めて重要です。そこで世界的に活用されているのが、コモンクライテリアCommon Criteria, CC)です。これは正式には「情報技術セキュリティ評価基準」と呼ばれ、国際規格であるISO/IEC 15408として標準化されています。

コモンクライテリアは、単に「安全であるか」を判定するものではなく、ベンダーが主張するセキュリティ機能が正しく実装され、適切に検証されているかを厳格なプロセスで確認するためのフレームワークです。これにより、ユーザーは製品のセキュリティレベルを共通の尺度で比較し、導入判断に活用することができます。

Key Facts

  • 国際標準規格:ISO/IEC 15408として定義されており、世界的に認められた評価基準である。
  • 客観的な検証:独立した試験機関が、ベンダーの主張(セキュリティターゲット)を検証する。
  • EAL(評価保証レベル):1から7までの段階があり、数値が高いほど検証の厳格さと深さが増す。
  • 相互承認:CCRA(共通基準相互承認協定)により、締結国間では評価結果が相互に認められる。
  • 適用範囲:OS、ファイアウォール、データベース、スマートカードなど多岐にわたるIT製品が対象となる。

コモンクライテリアの仕組みと構成要素

コモンクライテリアの最大の特徴は、評価の基準を柔軟に設定できる点にあります。製品ごとに異なる役割があるため、一律の基準ではなく、以下の構成要素を用いて評価を定義します。

評価の対象と定義書

まず、評価される製品やシステム自体をTOE(Target of Evaluation:評価対象)と呼びます。このTOEがどのようなセキュリティ特性を持つかを記述した文書がST(Security Target:セキュリティターゲット)です。ベンダーはSTの中で、自社製品がどのような機能を備えているかを宣言します。

また、特定の製品カテゴリー(例:ネットワークファイアウォール)に対して共通の要件を定義したテンプレートのようなものがPP(Protection Profile:保護プロファイル)です。STは、このPPに準拠する形で作成されることが一般的です。

セキュリティ要件の2つの柱

評価基準は大きく分けて「機能」と「保証」の2つの側面から構成されています。

  • SFR(Security Functional Requirements:セキュリティ機能要件):「ユーザー認証を行う」「アクセス権限を制限する」など、製品が具体的に提供すべきセキュリティ機能のことです。
  • SAR(Security Assurance Requirements:セキュリティ保証要件):開発プロセスやテスト手法など、「機能が正しく実装されていることをどう証明するか」という検証プロセスの要件です。

評価保証レベル(EAL)の考え方

コモンクライテリアでは、検証の厳格さをEAL(Evaluation Assurance Level)という数値で表します。EAL 1からEAL 7まであり、数字が大きくなるほど、ソースコードの解析や詳細な設計レビューなど、より深いレベルでの検証が行われます。

ここで重要なのは、「EALが高い=セキュリティ機能が強力である」という意味ではないという点です。EALはあくまで「主張された機能が正しく実装されていることが、どれだけ厳格に検証されたか」という保証の度合いを示すものです。したがって、低レベルのEALであっても十分な機能を持つ製品はありますし、高レベルのEALであっても機能自体がシンプルである場合があります。

認証の価値と限界

コモンクライテリアの認証を受けることで、ベンダーは第三者機関による客観的な証拠に基づいたセキュリティ性能を証明できます。これは特に政府機関や重要インフラへの導入において、調達基準として重視されます。

しかし、認証が「絶対的な安全」を保証するわけではありません。認証はあくまで「評価時の構成(Evaluated Configuration)」に基づいたものです。例えば、OSが認証を受けていても、その後の脆弱性修正パッチの適用状況や、想定外の運用環境ではセキュリティリスクが残ります。ユーザーは認証結果を信頼しつつも、継続的なアップデートや適切な設定管理を行う必要があります。

歴史と国際的な連携

コモンクライテリアは、かつて各国で個別に運用されていた基準(米国のTCSEC/オレンジブック、欧州のITSEC、カナダのCTCPEC)を統合して誕生しました。これにより、国をまたいで製品を輸出入する際の重複評価というコスト負担が軽減されました。

この連携を具体化したのがCCRA(Common Criteria Recognition Arrangement)です。この協定により、加盟国間で評価結果を相互に承認し合う仕組みが構築されています。近年では、より実効性を高めるため、個別のEAL指定よりも、共同で作成した保護プロファイル(cPP)への準拠を重視する方向へとシフトしています。

コモンクライテリアの概要まとめ

コモンクライテリアの主要概念まとめ
用語 英語表記 役割・意味
評価対象 TOE 検証を受ける製品やシステムそのもの
セキュリティターゲット ST 製品のセキュリティ特性を定義した文書
保護プロファイル PP 製品カテゴリー共通のセキュリティ要件定義
機能要件 SFR 製品が提供すべき具体的なセキュリティ機能
保証要件 SAR 実装の正しさを証明するための検証プロセス
評価保証レベル EAL 検証の厳格さを表す指標(1〜7段階)

Frequently Asked Questions

EAL 7の製品が最も安全だと言えますか?

いいえ、そうとは限りません。EALは「検証の深さ」を示すものであり、「機能の豊富さ」や「絶対的な安全性」を示すものではないからです。用途に合わせて適切なEALレベルの製品を選択することが重要です。

認証を受けた製品に脆弱性が見つかった場合はどうなりますか?

認証は特定の構成での検証結果であるため、運用後の脆弱性発見は起こり得ます。ベンダーはパッチを提供して対応しますが、認証自体が自動的に取り消されるわけではありません。ただし、評価構成に重大な影響がある場合は、再評価や証明書の取り下げが行われることがあります。

暗号化アルゴリズムの正しさはCCで評価されますか?

基本的に、暗号実装の詳細な検証はCCの範囲外であり、FIPS 140-2などの暗号専用規格で評価されます。ただし、最近では保護プロファイル(PP)を通じて、暗号要件をCC評価に組み込む傾向が強まっています。

オープンソースソフトウェア(FOSS)はCC認証を受けにくいのでしょうか?

伝統的なCCの保証要件(SAR)はウォーターフォール型の開発モデルを前提としていたため、アジャイル開発を行うオープンソースプロジェクトとは相性が悪いという指摘があります。しかし、評価手法の改善により、こうした開発モデルへの適応が議論されています。

CCRAとは具体的にどのようなメリットがある仕組みですか?

CCRA(共通基準相互承認協定)により、例えば米国で認証を受けた製品が、他の中加盟国でもその評価結果を認められます。これにより、ベンダーは国ごとに異なる評価を受けるコストを削減でき、ユーザーは国際的な基準で製品を選定できます。

References

  1. "Common Criteria - Communication Security Establishment". Archived from the original on 2021-02-01. Retrieved 2015-03-02.
  2. "Common Criteria Certified Products". Retrieved 2023-12-30.
  3. "Indian Common Criteria Certification Scheme (IC3S) Overview". Retrieved 2023-12-30.
  4. "Members of the CCRA". The Common Criteria Portal. Archived from the original on 2008-08-22.
  5. "Arrangement on the Recognition of Common Criteria Certificates in the field of Information Technology Security" (PDF). 2014-07-02. Retrieved 2023-12-30.
  6. "Common Criteria Management Committee Vision Statement" (PDF). 2012-09-01. Retrieved 2023-12-30.
  7. "Versions of Windows obtain Common Criteria EAL level 4+". Network Information Security & Technology News. 2005-12-14. Archived from the original on 2006-10-14.
  8. Under Attack: Common Criteria has loads of critics, but is it getting a bum rap Archived 2021-04-23 at the Government Computer News, retrieved 2007-12-14
  9. Wheeler, David (2006-12-11). "Free-Libre / Open Source Software (FLOSS) and Software Assurance / Software Security" (PDF). Retrieved 2023-12-30.
  10. Wäyrynen, J.; Bodén, M.; Boström, G. (2004). "Security Engineering and eXtreme Programming: An Impossible Marriage?". Extreme Programming and Agile Methods - XP/Agile Universe 2004. Lecture Notes in Computer Science. Vol. 3134. pp. 117–128. :10.1007/978-3-540-27777-4_12.  .