Red Hat Enterprise Linux Common Criteria FAQ
Common Criteria (共通評価基準) とは何ですか?
Common Criteria (CC) は、コンピューターセキュリティーソフトウェアを認定するための国際標準規格 (ISO/IEC 15408) です。 Protection Profiles を使用すると、Common Criteria によって定められた要件を満たす特定のレベルまでコンピューターシステムを保護できます。政府によって制定された Common Criteria の承認に関するアレンジメント には 26 カ国が署名しており、それぞれの国が互いの認証結果を相互に承認しています。
米国では、Common Criteria は National Information Assurance Partnership (NIAP) によって管理されています。 他の国には独自の CC 機関があります。 各機関は、製品の評価を実際に行う CC ラボを認定します。 ラボとベンダーからの証拠に基づいて認定機関によって認定されると、その認定は世界中で認められることになります。
認定には特定の保証レベルが割り当てられます。これは、大まかに言えばその認定の強度を表すものです。認定において、EAL4 レベルは EAL2 レベルよりも信頼性が高くなります。 通常、具体的に何が保証されているのか、つまり保護プロファイルという点よりも、保証レベルの方に注目が集まりがちです。
CC 認定は、非常に特殊なソフトウェアおよびハードウェア設定のセットを表しています。 ソフトウェアのバージョンおよびハードウェアのモデルとバージョンは重要であり、違いがあると認証が無効になります。
Common Criteria はどのような仕組みですか?
各国の Common Criteria 機関は、オペレーティングシステムやファイアウォールなど、特定の種類のソフトウェアごとに期待される基準のセットを策定しています。 これらの期待は 保護プロファイル と呼ばれます。Red Hat などのベンダーは、サードパーティーのラボと協力して、保護プロファイルをどのように満たしているかを文書化します。 評価対象となるすべての特定のハードウェアとソフトウェアである 評価対象 (TOE) が作成されます。 その後、提出に向けたパッケージの準備のために、ラボで数カ月もの月日が費やされます。 この状態は “in evaluation” (評価中) と呼ばれます。
パッケージが完成したら、関係機関に提出されます。 認証機関がそのパッケージを審査し、承認すると、その製品はその対象範囲において「Common Criteria 認定済み」となります。
Red Hat が Common Criteria を必要とする、または望んでいるのはなぜですか?
Common Criteria は、米国政府および他国の政府システム内で使用されるソフトウェアに必須です。 米国内の他の業界でも Common Criteria が求められる場合があります。 これはお客様にとって重要なことなので、Red Hat はこれらの基準を満たすために時間と労力を費やしています。
どの Red Hat 製品が Common Criteria の認定を受けていますか?
Red Hat Enterprise Linux と JBoss は、政府標準 に関する記事に記載されているさまざまなバージョンで Common Criteria を満たしています。 Fedora および CentOS オペレーティングシステムは RHEL に関連していますが、CC 認定されていないことに注意してください。 Common Criteria ポータル では、製品のどのバージョンがどのレベルで認定されているかに関する情報が提供されています。 Red Hat では、当社製品のすべての Red Hat Certifications and Accreditation のリストも提供しています。
RHEL のマイナーリリースは認定されていますか?
マイナーリリース、バグ修正、またはセキュリティー問題が発生すると、ほとんどのお客様は、最新の脅威に対するセキュリティーを維持するためにシステムにパッチを適用する必要があります。 技術的には、これはコンプライアンス違反を意味します。ほとんどのシステムでは、認定機関の認証局 (CA) が基本的なセキュリティー対策としてこれらの更新を要求します。 これが CC 認証の条件を損なうものであることは、すでに承知のとおりです。
Common Criteria 評価を特定のマイナーバージョンに関連付けることは、いくつかの理由から、非常に困難です。
まず、認定が特定のマイナーバージョンと完全に一致することはありません。 結局のところ、RHEL のマイナーバージョンというのは、絶え間なく続く更新の流れの中に設けられた、便宜上の通過点にすぎません。 たとえば、CC ターゲットは RHEL 6.2 から始まりましたが、評価された設定では必然的にパッケージが 6.2 バージョンから更新されることになります。 FIPS の場合、認定は RHEL のバージョンにはまったく関連付けられておらず、認定パッケージのバージョンに関連付けられています。 したがって、使用している RHEL のマイナーバージョンに関係なく、OpenSSH サーバーバージョン 5.3p1-70.el6 は認定されています。
これが 2 番目の理由につながります。 過去には、/etc/redhat-release の表示を CC のドキュメントと完全に一致させることだけを目的として、絶望的なほど古く、パッチも当たっていないシステムにプログラムを無理やり留まらせてしまうお客様もいらっしゃいました。 このようなポリシーは、RHEL 6.2、6.3、6.4 といった各バージョンに認定済みのパッケージが存在し得る可能性や、その認定済みパッケージに対してその後にセキュリティーパッチが適用されている可能性を無視してしまっています。 当社では、お客様が「バージョン X を使用しなければならない」と固定することを控えるようお勧めしています。 結局のところ、CC はそのような動作をするように設計されたものではありません。 CC は、プログラムが適切なパッチ適用およびエラータストラテジーを実施するための出発点または基準として扱われるべきだと考えています。
“in evaluation” (評価中) の製品でも使用できますか?
National Security Telecommunications and Information Systems Security Policy #11 (NSTISSP #11) に基づき、政府機関のお客様は、米国が承認した保護プロファイルを使用して認定された製品を優先的に選択しなければなりません。 それができない場合は、別のプロファイルで認定されたものを使用できます。 これもできない場合は、製品が “in evaluation” (評価中) であることを確認する必要があります。
Red Hat は、これまでに数多くの Common Criteria のプロセスを正常に完了させてきました。そのため、“in evaluation” (評価中) というステータスであっても、その確実性は言葉の響きほど不透明なものではありません。 製品が “in evaluation” (評価中) のステータスにある場合、最終的に認定が授与されるという確信は非常に高いものと言えます。 当社は、お客様とその CA および DAA と連携して、レビュー対象の C&A パッケージに関する決定を下すために必要な情報を提供します。
認定のタイミングについて懸念しています。今日、デプロイする必要があります。
Red Hat は、お客様が安心して利用できるバージョンの Red Hat Enterprise Linux を導入できるよう、最大限の配慮を行っています。 有効なサブスクリプションを所有していれば、その期間内は製品のどのバージョンでも使用することができます。 今すぐサブスクリプションを購入して、現在認定済みのバージョンをデプロイし、より新しいバージョンが認定されたタイミングでそちらへ移行することができます。その際、追加費用は一切かかりません。
NIAP の Web サイトで Red Hat の認定が見つからないのはなぜですか?
Red Hat Enterprise Linux 6 は、EAL4+ の OS 保護プロファイルに基づいて BSI によって認定されました。 これは、Common Criteria 相互承認条約に基づく NIAP の認証に相当します。相互承認に関する詳細は、CCRA の Web サイトを参照してください。 このサイトには、互いの評価を認め合う加盟国のリストが掲載されています。
CC 設定のシステムにパッチを適用し続けるには、どうすればよいですか?
yum アップデートツールのセキュリティープラグインを使用することで、お客様はセキュリティー修正のみを限定してインストールすることが可能です。 これにより、バグ修正や機能拡張のインストールを制限しつつ、セキュリティー問題に対する更新のみをシステムに適用できます。 その結果、セキュリティー更新の要件を満たしながら、より安定したシステム運用が可能になります。
セキュリティープラグインをインストールするには、root 認証プロンプトから以下を実行します。
# yum install yum-plugin-security
# yum updateinfo
# yum update --security
セキュリティー更新がシステムに追加されると、CC 評価済みの設定が変更され、システムは認定済みではなくなります。 これは、システムを構築するための推奨される方法です。つまり、CC から始めて、DISA 規制 に従ってパッチを適用します。 システムの C&A プロセスにおいて、CA および DAA と協議することで、ガイドラインや期待される基準を明確に確立することができます。
まだ不明な点があります。さらなるサポートが必要な場合の問い合わせ先を教えてください。
お客様、または潜在的なお客様が Red Hat 製品について質問がある場合は、いつでも Red Hat Support チームにご連絡ください。
Comments