証明書サービスを使用してワイヤレス LAN のセキュリティを保護する

トピック

	はじめに
	証明書要件を定義する
	証明機関の階層を設計する
	証明書プロファイルを構成する
	証明書管理計画を作成する
	要約

はじめに

前の章では、公開キー基盤 (PKI) に基づいた安全なワイヤレス ソリューションの論理設計について説明しました。 この章では、このソリューションのために Microsoft® Windows® 2003 証明書サービスに基づいた PKI を設計するプロセスを説明します。 導入コストおよび管理コストを低く抑えるため、このソリューションは比較的単純に設計されており、セキュリティで保護されたワイヤレス クライアントおよびワイヤレス ローカル エリア ネットワーク (WLAN) インフラストラクチャの証明書を発行するのに適しています。

ただし、第 1 の目的はセキュリティで保護された WLAN をサポートする PKI の設計ですが、PKI が組織の全体的なセキュリティ インフラストラクチャの重要な構成要素になる可能性もある点、つまり、今後この環境で他のさまざまなアプリケーションによって使用される可能性がある点にも注意する必要があります。 このインフラストラクチャへの投資を保護するため、ソリューションの設計は拡張可能になっています。 つまり、この設計があらゆる種類の証明書の発行に適しているとは限りませんが、将来的に機能と容量を追加すれば、ここで取り上げるセキュリティ要件よりも広範な要件を満たすことができます。

この章の目的は、主に 3 つあります。 第 1 に、ソリューションの設計上の決定とその理由について説明します。 第 2 に、その決定が組織の PKI に適しているかどうかを判断できるように、背景となる計画について説明します。 第 3 に、このソリューションの範囲外のセキュリティ ニーズにも対応できるように、基本のソリューションを拡張する方法を紹介します。

この章で「このソリューションでは...のオプションを使用します。」や「この設計では...を使用します。」などの表現が使われている場合は、このソリューションの設計の一部として決定し、構築ガイドおよび運用ガイドで実装される事項を指します。

「...を決定する必要があります。」などの表現が使われている場合は、自分の組織の要件に基づいて何かを決定する必要がある事項を表します。 この表現は主として、組織の幅広いセキュリティ ニーズに対応するためソリューションを拡張する方法について説明している箇所で使われます。 このため、一部のトピックには詳細な説明を付けて手順の意味がわかるようにし、他の文書を参照する手間が省けるようになっています。

章の前提条件

PKI の一般的な原則と用語をよく理解している必要があります。 このテクノロジについて知識がない場合は、この章の最後の「関連情報」で紹介されている記事等をお読みください。

先へ進む前に、「Microsoft Windows Server™ 2003 Deployment Kit」の「Designing a Public Key Infrastructure」(英語) に目を通しておくことをお勧めします。 この資料の入手方法については、この章の最後の「関連情報」を参照してください。 この章は「Deployment Kit」の「Designing a Public Key Infrastructure」の章の構成に従っているため、その資料に記載されている関連する背景情報や詳細な説明を参照しやすくなっています。

Windows Server 2003 PKI の計画および設計方法に関するその他の詳細情報についても、「関連情報」にリンクが用意されています。

章の概要

組織の現在および将来のニーズに対応する PKI を計画し、展開するのは容易ではありません。 通常、PKI は 1 つの独立したセキュリティ上の問題を解決するために装備されるものではありません。 組織が PKI を展開する場合、それは内部の多数あるセキュリティ要件に対応するためばかりでなく、外部の顧客またはビジネス パートナーとの作業上必要なビジネス セキュリティ要件に対応するためでもあります。

次のフローチャートは、この章の構成を表したものです。

図 4.1: 証明書サービスを計画する手順を示す章の構成

手順は主に次の 4 つになります。

ページのトップへ

証明書要件を定義する

このセクションでは、PKI が証明書を発行する目的と、それぞれの目的別のセキュリティ要件について説明します。

Certificate Practices Statements (CPS) を作成する

PKI を設計するとき、組織内で証明書が発効され、使用される方法について決定したことを記録する必要があります。 こうした決定を証明書ポリシーと呼び、その内容を記録したドキュメントを証明書ポリシー ステートメントおよび CPS (Certificate Practices Statements) と言います。

正式な用語としては、証明書ポリシー (CP) は PKI の運用方針を定めた規則です。 たとえば、共通のセキュリティ要件を持つ特定のクライアントまたはアプリケーションのグループに対して証明書を適用できるかどうかが記載されています。 CPS (CertificatePracticesStatements) は、発行した証明書を管理する際に組織が使用する運用方法に関する規定です。 CPS には、組織の証明書ポリシーが組織のシステム アーキテクチャと運用手順における解釈方法を記述します。 CP は、組織全体で共有されるドキュメントです。 一方 CPS は、個々の CA 固有のドキュメントです (複数の CA で同一のジョブが実行される場合、たとえば、複数のサーバーに CA の負荷を分散してパフォーマンスや障害許容力を向上させている場合などでは、CPS が共有されることもあります)。

組織や証明書の用途によっては、CP と CPS は、法律文書または法的な放棄声明文書とみなされることがあります。 これらを作成する場合は通常、法律の専門家の助言を必要としますが、これについてはここでは説明しません。 ただし、どちらの文書も PKI の一部として作成する場合に厳格な要件はありません。 これらの文書を作成する特定の法的または商業的理由がない場合は、公式な証明書ポリシー ステートメントと CPS を作成して管理する必要はありません。

公式な CP または CPS が必要ない場合でも、証明書ポリシーと運用方法は文書化する必要があります。 証明書ポリシーは組織のセキュリティ ポリシー全体の一部であり、運用方法はセキュリティ管理手順の一部となります。 これを非公式の CPS と言います。

PKI の使用目的に基づいて、公式なポリシー ステートメントと CPS を作成するかどうかを判断する必要があります。 公式な CPS が必要な場合、それを公開して CA 証明書にその参照情報を記載しなければならないことがあります。 このソリューションには公式な CPS の記述方法に関するガイドはありませんが、CPS を公開する方法については、「第 7 章 : 公開キー基盤を実装する」を参照してください。 通常、非公式な CPS を公開する必要はありません。

この章の以降のセクションでは、決定事項を CPS に文書化することを指示する内容の記載が何度も登場します。 この手順は、公式な CPS の場合も非公式な CPS の場合も同様です。

CPS の作成方法に関するその他の資料については、この章の最後にある「関連情報」を参照してください。

証明書の用途を特定する

PKI の設計プロセスの最初の手順は、証明書を使用する用途をリストにして特定することです。 用途ごとに、必要な証明書の種類とおおよその数を記載する必要があります。 この段階では、証明書の詳細を指定する必要はないので、簡単に記述します。

セキュリティで保護されたワイヤレス ソリューションに使用する場合は、ワイヤレス クライアント用の証明書、および Windows Remote Authentication Dial-In User Service (RADIUS) サーバー用の証明書が必要です。 Microsoft RADIUS サーバーは Windows Server のコンポーネントであり、インターネット認証サービス (IAS) と呼ばれる役割を果たします。

必要な証明書の種類を、次の表に示します。 このソリューションでは必ずしも必要ではありませんが、PKI はドメイン コントローラに対しても証明書を発行します (Windows Server 2003 Enterprise CA がフォレスト内にインストールされている場合、これが既定の設定です)。

表 4.1: セキュリティで保護されたワイヤレス ソリューションの証明書要件

将来的には、次の表に挙げた用途に対しても証明書を発行できるように PKI を拡張することができます。

表 4.2: 将来可能になる証明書要件

証明書クライアントを定義する

前のセクションで挙げた用途に対して、証明書を使用するクライアントを定義する必要があります。 ここで言う "クライアント" とは、PKI によって発行される証明書を使用する人員、ソフトウェア プロセス、またはデバイスのことを指します。 たとえば、ユーザー、サーバー、ワークステーション、ネットワーク デバイスも、ここで言うクライアントになります。 発行された証明書が使用される経緯について理解するには、証明書のサブジェクト (またはエンド エンティティ) とその他の証明書ユーザーという 2 つの主なカテゴリにクライアントを分けて考える必要があります。

エンド エンティティとは、PKI によって発行された証明書を持つクライアントです。 証明書のサブジェクトフィールドまたはサブジェクトの別名フィールドには、クライアントがその証明書の所有者であることを示す 1 つ以上のエントリ (ホスト名、電子メール アドレス、ディレクトリの識別名など) が登録されます。 もう 1 つのカテゴリである証明書ユーザーは、たとえば、エンド エンティティの証明書を確認するか、またはディレクトリで検索する必要があるクライアントですが、必ずしも PKI によって発行された証明書を持っているとは限りません。

この違いを一般的な例で説明すると、インターネットのユーザーが安全な Web サイトで買い物をした場合、このユーザーはその Web サイトの SSL (Secure Sockets Layer) 証明書のユーザーということになります。 しかし、この Web サイトは証明書のエンド エンティティであり、その ID (www.woodgrovebank.com) は証明書のサブジェクトフィールドにエンコードされます。 証明書のサブジェクトだけが証明書の秘密キーを使用することができ、証明書の他のユーザーは使用できません。 注 : 証明書のサブジェクトは、ほとんどの場合その証明書自体のユーザーであり、通常は他の証明書のユーザーでもあります。

注 : 技術用語としては "エンド エンティティ" が正しい用語ですが、この章では主に、より一般的な用語である "証明書のサブジェクト" を使用します。

証明書のサブジェクトと証明書のユーザーの両方について、次の質問に回答することにより、各クライアントの種類を分類する必要があります。

この分類は、多くの設計上の決定基準、たとえば証明書を発行する方法、特定の証明書に配置できる信頼のレベル、証明書失効情報を公開する方法などに影響します。

このソリューションでのクライアントの分類を、次の表に示します。

表 4.3: 証明書のサブジェクト (エンド エンティティ) の分類

このアプリケーションでは、証明書のユーザーが同一のクライアントになりますが、役割は予約済みです。 たとえば、IAS サーバーがクライアント証明書のユーザーになり、そのクライアント証明書を検証する必要があります。 この検証では通常、証明書が信頼されたルート CA にチェーンしていること、およびクライアントによって指定された署名がクライアントの証明書の公開キーと一致することの確認が行われます。 また、証明書の失効チェックも実施されます。 詳細については、「Troubleshooting Certificate Status and Revocation 」(英語) を参照してください。参照先については、この章の最後にある「関連情報」で紹介します。

表 4.4: 証明書のユーザーの分類

上記の表から、サポートする必要のあるプラットフォームと処理の種類を特定できます。 WLAN のシナリオには当てはまりませんが、環境内の他の用途で使用する場合、インターネット上のクライアントによる証明書の検索または検証機能がサポートされているか、または Windows 以外のプラットフォームからの登録機能がサポートされていることが必要な場合があります。 これらの事項は設計プロセスの初期段階で決定する必要があるため、どのような証明書要件が将来必要となるかを検討することは重要です。

このソリューションでは、将来の要件について次の事項を想定しています。

現時点では設計上これらの要件のすべてが満たされているわけではありませんが、対応することは簡単です。

証明書のセキュリティ要件を定義する

証明書のセキュリティは、証明書の保証レベルとも呼ばれます。 これは、証明書のサブジェクトを証明書自体にバインドする際の強度の尺度と見なすことができます。 証明書のセキュリティは、証明書を使用している人 (またはデバイス) が、証明書に記入されたサブジェクトと同一であると確信できる信頼度を表します。 この保証レベルは、主に次の 2 つの事項の尺度になります。

この 2 つは密接に関連しあっています。なぜなら、秘密キーの所有者の身元情報にまったく確信が持てない場合は、高価な秘密キー保護対策に投資するわけにはいかないからです。 同様に、広範なバックグラウンド チェックや DNA 指紋法も含めた高度な登録処理をしても、その後秘密キーが安全性の低い方法で格納されるのではほとんど効果がありません。

証明書の保証を高めるとコストがかかりますが、多くの場合、証明書を使用する場合に、このような保証が必要とは限りません。 正規のドメイン ユーザーに属する証明書の保証を高レベルに設定しない場合は、証明書の登録時の登録証拠としてドメインの資格情報を完全に受け入れることができます。

証明書ポリシー ステートメントと CPS には、使用する保証レベルの意味を記載する必要があります。

次の表は、このソリューションで使用する 3 種類の保証レベルを定義したものです。

表 4.5: 証明書の保証レベル

この表の分類には重なる部分もあります。 ここでの分類は、技術上の厳密な分類ではなくポリシーによる分類です。 組織では、証明書の処理方法に関してポリシーに記載された決定に基づき、分類の基準を定めます。 一般的には、高保証の証明書が利用されることはあまりなく、どちらかと言えば標準保証の証明書が利用されることの方が普通です。

重要 : この章では、"低価値" とか "低保証" の証明書という語の代わりに "標準価値" とか "標準保証" の証明書という語を使用します。前者はネガティブな響きがあり、"標準" の方が本来の意味に近いためです。

上の表で定義した保証の分類は、サブジェクトの種類別に分類するとさらに細分化できます。 一般的な分類は次のとおりです。

このように分類する理由は、通常サブジェクトの種類によって適用される証明書ポリシーがかなり異なるためです。つまり、証明書の発行、失効、または更新の際の条件はかなり異なります。 証明書を発行する計画がない分類対象についても、その分類に適用できる証明書ポリシーを記載しておくと、ポリシーと CPS を適切に準備できます。 次の表は、保証レベルごとの分類とサブジェクトごとの分類を組み合わせた結果を示したものです。

表 4.6: 証明書のセキュリティの分類

注 : 使用する必要がない分類は、作成しなくてかまいません。 分類の方法は、これより単純にすることも複雑にすることもできます。なお、このすべての組み合わせの証明書を発行する必要はありません。

技術的には、これらのさまざまな種類の証明書サブジェクトをすべて同じ方法で扱うことができます。 ただし、通常はサブジェクトの種類ごとに異なるセキュリティ ポリシーを定義します。たとえば、社内従業員は別の組織の職員とは別に扱われます。 異なる証明書ポリシー (および、さまざまな CPS での具体化) は、これらのさまざまな証明書の種類を発行する CA の構成方法の決定に影響します。 これについては、後述します。

さらに、最終的に同じ管理者が上記の 3 つの分類の証明書ユーザー (PKI 用語では "エンド エンティティ") に対して発行された証明書に責任を持つかどうかを検討する必要があります。 多くの組織では、コンピュータが正規のドメイン メンバであることを認定できる担当者と、パートナー企業の身元情報を認定できる担当者は同じではありません。 CPS には、この責任関係を記述する必要があります。

アプリケーションの証明書のセキュリティを定義する

前のセクションで定義した証明書のセキュリティ分類は、設計用の証明書の種類を分類する場合に使用できます。 その分類を、次の表に示します。

表 4.7: 証明書のセキュリティ要件

上記の大まかな要件を使用して、この章の後半の「証明書プロファイルを構成する」ではより詳細に特定の証明書プロファイルを構成します。

証明書の目的を組み合わせる

複数のアプリケーション機能 (または使用法) を組み合わせて 1 つの証明書にすることができます。これにより、1 つの証明書を使用して電子メールに署名したり、ネットワークにログオンしたり、アプリケーションへのアクセスを許可することができます。 複数の使用法を 1 つにまとめることができれば、証明書サーバーとディレクトリ サーバーにかかる管理コストおよびストレージ コストの削減につながります。

ただし、多目的の証明書には短所もあります。 たとえば、用途が異なると、証明書の承認プロセスも異なる場合があります。 複数の証明書を使用する理由はほとんどが技術的なものですが、通常は、用途によって証明書のセキュリティ レベルが異なることが最大の理由です。つまり、証明書と証明書のサブジェクトを結合する保証レベルはさまざまです。 このような違いは、次に示す事項のいずれかまたはすべてに存在します。

このため、複数の証明書使用法を組み合わせる場合、一般的にはセキュリティ レベルが同じものを組み合わせるのが最適です。 このソリューションで使用されるクライアント認証証明書には、IPsec やコンピュータ認証など、他の標準的な用途の使用法も含まれます。 他の証明書の使用法に対する要件を定義すると、それらの要件を組み込んで証明書を再発行できます。その場合、証明書の更新が必要となり証明書テンプレートの定義から始めることになる可能性があります。

ただし、IAS サーバー証明書は、中程度の保証の証明書であるとみなされます。 承認されていないサーバー証明書がもたらす脅威は、不正なクライアント証明書による脅威よりはるかに危険です。 したがって、サーバー証明書はより慎重に扱ってください。マイクロソフトでは、サーバー証明書に標準保証の用途の使用法を組み合わせることはお勧めしていません。

ページのトップへ

証明機関の階層を設計する

組織の証明書ベースのアプリケーションをサポートするには、必要に応じて CA をリンクすることにより、証明書の発行、検証、更新、失効を担当するフレームワークを確立する必要があります。 一方 CA は、証明書のサブジェクトの認証、証明書の公開、および証明書失効情報の公開などを行う場合、基になる IT インフラストラクチャに依存します。

CA インフラストラクチャを確立する目的とは、組織にとって最適のセキュリティ レベルを維持しながら、ユーザーに信頼性の高いサービスを提供し、管理者に管理能力を与え、また現在と将来のニーズを満たす柔軟性を与えることです。

信頼モデルを選択する

CA インフラストラクチャを設計する最初の手順として、要件に最も適した信頼モデルを決定します。 基本モデルとして、階層信頼モデルとネットワーク信頼モデルの 2 つがあり、ハイブリッド信頼モデルではこの両方の要素を組み合わせることができます。 これらのモデルの詳細については、「関連情報」で紹介している「Windows Server 2003 Deployment Kit」の「Designing a Public Key Infrastructure」(英語) を参照してください。

このガイドのソリューションでは、階層信頼モデルを使用します。 その理由は次のとおりです。

提案されているソリューションでは、単一ルートで十分です。

サード パーティと内部ルートを比較する

PKI の信頼アンカとして内部ルートを使用したり、民間の CA のサービスを使用することができます。 サードパーティ ルートを使用するということは、組織の発行 CA が民間のルート CA によって (通常は 1 つ以上の中間 CA を通じて) 認証されるということです。 したがって最終的に、この外部ルート CA では発行されたすべての証明書にそれぞれの信頼アンカが含まれています。

注 : このガイドでは明確に説明されていませんが、組織の証明書要件はどれも民間の CA にアウトソーシングすることができます。 その場合、オンサイト管理サービスを利用するか、証明書プロバイダから直接証明書を取得します。 多くの場合、このようなアウトソーシングは、組織が小規模であるとか証明書の使用法が非常に限定されている場合を除いて、財政上あまり実際的な方法ではありません。 アウトソーシングに関する決定は、内部ルートとサードパーティ ルートのいずれを使用するかという問題とはまったく関係ありません。ただし、この 2 つの問題は混同されることがよくあります。

内部発行証明書に民間ルートを使用する長所を次に示します。

ただし、この方法には次の短所があります。

このような短所があっても、組織外部のユーザーが信頼する証明書を数多く発行する必要がある場合は、民間ルートの下位に少なくとも PKI の一部を従属させることを検討する必要があります (ただし、この場合 2 つの別々の階層の作成が必要になることがあります)。

このソリューションでは、組織で使用される証明書の大半に、内部ルート CA に基づく階層を使用しています。 このアプローチには、次のような長所があります。

証明書ユーザーの信頼されたルートの管理が困難な場合は、外部ルートの利用を検討することをお勧めします。 このソリューションでは、次のサービスについて、サードパーティの証明書と外部ルートを利用することを提案しています。

外部証明書の信頼を定義する

前のセクションでは、他の組織の証明書インフラストラクチャの信頼について説明しました。 証明書の信頼を組織内で制御する方法を決定するには、このテーマをさらに広げて検討する必要があります。 ここで言う "信頼" には、次の重要な 3 つの条件が含まれます。

証明書の場合、"誰" とは証明書の発行機関を、"何" とは制御の対象となる証明書の使用法およびその他の特性を指します。 "いつまで" とは、ルート CA 証明書の有効期限か、場合によっては、作成する特殊な相互信頼証明書の有効期限のことを指します。

別の組織と新たなビジネス関係を確立する場合や、ユーザー向けの一部の機能を有効にする場合 (たとえば、Web 証明書を信頼することで、セキュリティで保護された HTTP セッションを許可するなど) には、組織が外部団体との間に築いている既定の信頼関係の変更が必要になる場合があります。 たとえば、次のような場合がそれに当たります。

上記の目標を達成するには、次のようないくつかの方法があります。

このソリューションでは、CA 上のルート証明書の更新サービスを無効にしています。 組織内の他のコンピュータでもこのサービスを無効にするかどうかを検討する必要があります。 また、グループ ポリシーを使用して、すべてのドメイン ユーザーの既定のサードパーティ ルートを無効にすることも検討してください。 これについては、「第 7 章 : 公開キー基盤を実装する」で詳しく説明します。

このソリューションでは、PKI のルート CA 証明書は Active Directory にインポートすることでクライアントに配布されます。これについては、次のセクションで説明します。

ルート CA 証明書の配布

ルート CA 証明書は、Active Directory フォレストのメンバに自動的に配布されます。 CA 証明書を Certification Authorities コンテナにインポートすることによって、フォレスト内のすべてのドメインのメンバ (コンピュータおよびユーザー) は、この証明書を各自のローカルな信頼されたルート CA ストアにインストールします。 この方法は、フォレスト全体を信頼範囲にする必要がある内部ルート CA に対してお勧めします。

また通常は、内部ルートと平行して、より限定された信頼範囲のルートを配布する必要があります。 詳細については、この章の以降のセクション「CA インフラストラクチャを拡張する」を参照してください。

ルート CA 証明書を他のプラットフォーム上、またはフォレスト外部のユーザーとコンピュータに配布するには、証明書を手動でインストールするか、別の配布方法を使用する必要があります。

証明機関の役割を定義する

信頼モデルを定義し、ルート CA の戦略を選択したら、残りの CA インフラストラクチャを計画します。 それには、組織内で CA が果たすさまざまな役割を定義する必要があります。 CA は、ルート CA または下位 CA として構成できます。 下位 CA は、発行 CA または中間 CA (発行 CA とルート CA の中間にある信頼手順) になります。

ルート CA

ルート CA には、どの組織にとっても非常に重要な役割があります。 つまり、組織内のすべてのユーザーとデバイスによって明示的に信頼されるという役割です。 多くのセキュリティ決定事項 (ある人物にログオンを許可するか、電子メールを信頼するか、1 千万ドルのセキュリティ取引を許可するかなど) は、最終的にこのルートのセキュリティと、ルートの識別情報を提供する秘密キーにかかっています。 多数の処理がこのルートに依存しているため、ルート キーと証明書を変更する作業は非常に複雑でエラーの発生につながりやすい処理であり、長期間にわたってアプリケーションとユーザーに対するサービスが断続的に失われる可能性があります。

このため、ルート CA の秘密キーは可能な限り保護することが非常に重要です。 変更する場合の最良の方法の 1 つとしては、CA をネットワークから切断して、その CA へのアクセスを最小限に抑えます (この保護措置に加えて、サーバーへの物理的なアクセスを制限する相応の措置を併せる必要があります)。 CA キーの保護をさらに強化するには、専用のハードウェア セキュリティ モジュール (HSM) を使用します。 これらの方法により、オフライン CA のキーのセキュリティが強化されるだけでなく、オンライン CA のセキュリティも大幅に向上します。

このガイドで定義するソリューションでは、オフライン ルート CA を使用します。

重要 : ルート CA に HSM を使用して CA キーのセキュリティを向上させることを検討してください。 CA のインストール後に HSM を追加することもできますが、最初に HSM を導入する方がはるかに簡単で、より安全です。 HSM をあとで設置した場合、多くのベンダでは既存のキーをインポートできるようにしますが、新しいキーで CA を更新する必要があります。

中間 CA と発行 CA

ルート CA をオフラインにすると、そこから毎日証明書を発行することができなくなります。 日常的に使用する証明書の発行に使用できる CA を作成する場合、ルート CA に代わって下位 CA が証明書を発行することを認定します。 これにより、下位 CA はルート CA キーをセキュリティの脅威にさらすことなく、ルート CA の信頼性を継承できます。

この処理はさらに細分化して行うこともできます。 下位 CA は、直接証明書を発行する代わりに、その上の層の CA がエンド エンティティ (ユーザーおよびコンピュータ) に発行することを認定します。 この方法だと、ルート CA キーにセキュリティ レイヤが追加されるだけでなく、複数の 下位 CA の間でリスクを分散させることができます。 たとえば、ある中間 CA は内部発行 CA を認定し、別の中間 CA は外部証明書を発行する CA を認定します。 この方法には次のような利点があります。

中間 CA にレイヤを追加すると PKI のセキュリティは全体的に向上しますが、これには複雑化、ハードウェアおよびソフトウェアの追加、管理コストの増大 (通常はハードウェアやソフトウェア ライセンスのコストよりはるかに大きくなります) といった問題が伴います。 大部分の用途では、セキュリティ要件として 3 階層を挙げるのは妥当ではありません。 このことは、特に CA キーが HSM で保護されている場合に当てはまります。

このガイドで定義するソリューションでは、2 階層を提案しています。 このソリューション設計では、優れたセキュリティとコストのバランスが妥当であり、また今後証明書を使用する可能性のあるさまざまな用途に対応できる柔軟性も備わっています (詳細については、この章の前のセクション「証明書要件を定義する」を参照してください)。

注 : 3 階層の使用を義務づける政府の法令または規制は、このガイドでは検討対象となっていません。 そのような規制がある場合は、当然その他の条件も異なってきます。

提案する CA 階層

次の図は、提案する階層を示したものです。 現在の実装は、ルート CA と 1 つの発行 CA で構成されています。 発行 CA は主に、コンピュータまたはユーザーに対しては標準保証 ("技術的" と言う場合もあります) 証明書を、コンピュータに対してはより高価値の証明書を発行します。

図 4.2: 証明機関の階層
拡大表示する

この設計を使用すると、セキュリティ保護されたワイヤレス LAN 認証 (802.1X) をサポートする完全な機能の PKI を展開でき、ハードウェア、ソフトウェア、管理にかかるコストも比較的低く抑えることができます。

注 : この単純なインフラストラクチャ設計は、いくつかの方法で拡張してさまざまな要件に対応させることができます。 これについては、「CA インフラストラクチャを拡張する」で説明します。

発行 CA は最初、次の種類の証明書を発行するように構成されます (上の図の太枠で囲まれた部分)。

最初の 2 つの証明書は標準保証の証明書です。ユーザーまたはコンピュータのドメインの資格情報に基づいて自動的に発行されます。 これらの証明書の所有は、有効なドメイン ユーザー名とパスワードを使用する場合ほどサブジェクトの束縛が強くありません。 ただし、ドメイン名とパスワードではなく証明書を使用することには、セキュリティ上の長所やその他の技術上の長所があります。

IAS サーバーは高度なセキュリティ機能を実行するため、IAS サーバー認証は中保証の証明書に分類されます。 この種類の証明書を発行する場合は、通常、要求の有効性のチェックなどが追加され、証明書マネージャの承認が必要になります。

注 : 後述の構築に関する章で、この種類の証明書を作成する方法が記載されていますが、そこでは証明書マネージャの承認が必要という要件は無効にされています。 これにより、IAS サーバーは有効期限の切れた証明書を自動的に更新し、証明書が失効したときにサービスが無効になる事態を回避します。 証明書要求を十分に検査して承認するプロセスが用意されている場合は、証明書マネージャの承認という要件を有効にすることを検討してください。

CA のハードウェアおよびソフトウェア要件

ここでは、CA のハードウェアおよびソフトウェア要件について説明します。

ルート CA

ルート CA のハードウェア要件は最小限で済みます。 コンピュータの仕様は、Windows Server 2003 の実行に必要な最小要件を満たしていれば十分です。 ルート CA のハードウェアの重要な要件は、長期的な信頼性と保全性です。 ルート CA は通常、長期間使用されるコンピュータに設置しますが、ほとんどの場合電源はオフにしておきます。 このコンピュータの電源を入れる場合は、常に正常に起動することが必要です。 また、ハードウェア障害が起こった場合に対処できるように、そのコンピュータ モデルの生産終了後数年が経過したあとでも、コンポーネントの交換を容易に行える必要があります。

このような点を踏まえ、マイクロソフトでは次のことをお勧めします。

ルート CA では、Windows Server 2003 Enterprise Edition の追加機能は必要ありません。 したがって、このガイドのソリューションでは Windows Server Standard Edition を使用しています。

発行 CA

発行 CA にはパフォーマンス要件がありますが、通常、発行 CA の動作は非常に限られているため、比較的低い要件になっています。 過負荷状態になった場合でも、たとえばエンタープライズ CA の場合、CA 自体ではなく Active Directory とのやり取りが制約になることが、パフォーマンス測定により示されています。 したがって、ハードウェアのパフォーマンス要件は非常に小さいものです。 ルート CA の場合と同様に、信頼性と保全性がハードウェアを選択する際の不可欠な要因です。

証明書サービスは Active Directory と同じデータベース テクノロジを使用するため、大部分は同じパフォーマンス ガイドラインを適用できます。 ほとんどの組織に適したガイドラインとして、Active Directory のドメイン コントローラに使用するのと同じハードウェア仕様を使用することをお勧めします。

CA のパフォーマンスの詳細については、この章の最後に紹介されている「Designing a Public Key Infrastructure」の「CA Capacity, Performance, and Scalability」セクション (英語) を参照してください。

「第 7 章 : 公開キー基盤を実装する」に、推奨するハードウェア プロファイルが記載されています。 発行 CA に使用するサーバー ハードウェアを指定する場合は、前述のルート CA のガイドラインの他に、次の事項について検討することをお勧めします。

ルート CA とは異なり、発行 CA では、編集可能な証明書テンプレートとユーザー証明書の自動登録をサポートするため Windows Server 2003 Enterprise Edition の追加機能が必要となります。

複数の発行 CA を使用してサービスを復元する

ここでは、複数の発行 CA をインストールする技術的な理由について説明します。 さらに、異なる種類の証明書を登録するためにさまざまな発行 CA が必要な理由として、セキュリティ上の理由とポリシー上の理由があります。 この理由についてはこの章で後述します。

既に説明したいくつかの種類の証明書を何万ものクライアントに発行する場合、簡単な構成のハードウェアを使用した発行 CA が 1 つあれば十分です。つまり、純粋にパフォーマンス上の理由で複数の発行 CA を必要とすることはほとんどありません。 ただし、発行 CA の可用性を満たすために、複数の CA を展開して同じ種類の証明書を登録する必要があるかどうかは検討する必要があります。

CA には、多くのサービスに見られるような可用性の問題はありません。 クライアントは、証明書を使用または検証する際に CA にアクセスする必要がありません。 クライアントが CA に直接アクセスするのは、次の作業を行うために CA が必要になった場合だけです。

次の表に、各項目の可用性要件の詳細を示します。

表 4.8: CA サービスの可用性要件

注 : 上の表では、CA の復元時間と CA の可用性が、エンド ユーザーにサービスを提供する CA の機能に影響を与える要因となっています。 これは、サーバーの障害に限定されません。 実際に、サイト間のネットワーク停止は最も可能性の高いサービス障害の例です。 必要なサービスの可用性レベルを決定する際には、ユーザーへのサービス提供に影響する可能性のある、すべての要因について検討する必要があります。

CA のバックアップと復元がうまく管理できている限り、複数の CA を使用してサービスの障害許容力を強化するかどうかを判断するうえでの基準は、登録要件と一部の更新要件のみとなります。 その他の CA を追加する場合のインストール コストおよび管理コストを、サービスを使用できない場合にかかるコストと比較して検討する必要があります。

複数の発行 CA を利用した場合、可用性が向上するだけでなく証明書発行のパフォーマンスも向上するため、CRL のサイズを半減できます。 ただし、これらの要素はいずれも、このガイドのソリューションでは重要ではありません。 このソリューションでは、CA を慎重に管理し、十分なバックアップ手順と回復手順を組み込むことで、障害許容力の問題を解決しています。 そのため、このソリューションで必要な発行 CA の数は 1 つだけになります。

HSM を使用して CA キーを保護する

このガイドで説明している基本ソリューションのセキュリティを強化する重要な方法の 1 つは、HSM を使用してすべての CA の秘密キーを保護することです。 HSM は多くの場合多大なコストがかかり、CA サーバーのコストを超えることもあります。ただし、HSM を組織の環境に導入することで得られるセキュリティ レベルはかなり高度なものです。 この方法を採用すると、CA キー操作の実施を許可されたユーザーのみに制限できます。 機密性の高い操作 (CA キーのエクスポートやバックアップなど) を保護するには、通常、複数のスマート カードを使用します。 この方法は、ソフトウェアベースのキーのみに依存する方法より安全です。ソフトウェアベースのキーは、ローカルの Administrators グループまたは Backup Operators グループのメンバであれば誰でも、CA からコピーできるためです。

HSM を採用すると、多くのセキュリティ上の利点が得られるだけでなく、CPU の負荷が専用の暗号化加速プロセッサに分散されるため、CA の処理速度も向上します。

CA のセキュリティ

ここでは、オペレーティング システムと物理的なセキュリティ、セキュリティの監査と監視、役割を使用した CA の管理責任の委任など、CA のセキュリティについて説明します。

オペレーティング システムのセキュリティ

CA のセキュリティは、Windows セキュリティ ポリシーを使用することで保護されます。 ポリシーは、「Windows Server 2003 セキュリティ ガイド」の証明機関サーバーの役割に基づいて設定されます。

この役割で使用されている設定の詳細については、「第 7 章 : 公開キー基盤を実装する」を参照してください。

ルート CA のセキュリティ設定は、セキュリティ テンプレートを使用して直接適用されるのに対し、発行 CA の設定は、グループ ポリシーを使用して適用されます。

物理的なセキュリティ

CA サーバーの物理的なセキュリティは、最も重要です。 基本的にサーバーへの物理的アクセスを制御できない場合、ネットワークやオペレーティング システムをいくら保護しても意味はありません。

ルート CA は、サーバーへのアクセスが厳しく制御されている場所に配置する必要があります。 この CA に実際にアクセスする必要はあまりなく (年に 2、3 回程度)、それ以外でサーバーの電源をオンにする必要はありません。 つまりこのサーバーは、安全な場所であれば、サーバー ルームにあるような標準的なコンピュータ設備がない部屋に設置することもできます (たとえば、ネットワーク、高度なサーバー設備、特別な電源/温度管理などは必要ありません)。

発行 CA も、物理的アクセスが厳しく制御されている場所に配置する必要があります。 攻撃者がコンピュータ システムに物理的にアクセスできる場合、そのセキュリティを侵害する方法は数多く存在するため (ネットワーク経由で実行可能な攻撃とはまた別です)、物理的なセキュリティは重要です。 このサーバーは常にオンライン状態にしておく必要があるため、標準的なコンピュータ サーバー ルームの設備 (空調設備、電源管理、防塵フィルタ、防火設備など) を備えた場所に設置します。

可能であれば、どちらのサーバーも火災や洪水など外的な災害による被害の心配がない場所を選んで設置してください。

バックアップ、キー マテリアル、およびその他の構成データに対する物理的なアクセスを制御し、物理的な安全性を確保することも同様に重要です。 自然災害や火災などによってサイト全体が使用できなくなった場合でも CA を復元できるように、この情報はサーバーとは別の場所に保管する必要があります。

CA のセキュリティ管理

証明書インフラストラクチャは、潜在的に非常に高価な資産です。 価値の高さは、現在だけでなく、5 年後またはそれより先の時点で、組織が証明書をどのような用途に使用するかによって決まります。 したがって、CA のインストール、構成、および管理を扱う際には、他の IT インフラストラクチャをインストールする場合に比べ、より厳しいセキュリティと検証手段を用いる必要があります。 そのための手段は、少なくともドメイン コントローラ用に設計されたものと同等である必要があり、 場合によっては、それよりも高度なレベルのセキュリティが必要になることもあります。

CA の信頼度は、その CA が安全に設定され管理されていると確信できる度合いによって決まります。 CA の秘密キーが密かにコピーされていることはないと保証できないなら、その CA が発行したと見られる証明書が偽造ではないと確信することはできません。

このような保証または信頼のレベルは、あとから向上させることは容易ではありません。このような特別なステータスを、CA に関するすべての作業に最初から組み込むことが必要です。 たとえば、CA へのすべてのアクセスが正当なものであったことを示す監査記録やその他の証拠があれば、CA の秘密キーは侵害されていないという事実をはるかに強く確信することができます。 たとえば、CA のすべての管理操作が、管理者以外の第三者によって目撃されているかビデオで録画されていれば、そのような証拠になります。 オフライン CA の場合は、ネットワークに接続されたことがないという事実により、セキュリティを破られたかもしれないという可能性は大幅に低下します。

特に、組織が発行した証明書の有効性をめぐって法的な争いになった場合、このような高いレベルの保証が必要です。 この場合、CA のセキュリティが破られていないことを示す証拠があれば、好ましい結果が得られる可能性ははるかに高くなります。 この件については、ここではこれ以上詳しく扱いません。詳細については、組織の監査担当および法律顧問にご相談ください。

CA の保証レベルを大幅に向上させる手段について、いくつか例を示します。

ルート CA サーバーの場合、このような対策は特に重要です。 発行 CA は、発行する必要のある証明書の種類に応じて、低保証のレベルにすることができます。 たとえば、CA が高価値の証明書を発行していない場合 (コンピュータやユーザーのネットワーク認証など標準証明書のみの場合)、この CA のセキュリティ レベルは、ドメイン コントローラに使用するほど高いものにする必要はありません。

ルート CA が高い保証レベルを備えている限り、保証レベルがより高い発行 CA をあとから追加すれば、より価値の高い証明書を自由に発行できます。 既存の標準保証の CA と平行して、高保証の CA を保持できます。 ただし、ルート CA を比較的セキュリティの低い環境にインストールして構成し、あとで高価値の証明書を発行する必要が生じた場合は、ルート CA を再インストールするか、新しいルート CA を作成する必要があります。

セキュリティの監視と監査

オペレーティング システムと証明書サービスの監査を、すべての CA 上で行います。 監査を効果的に行うには、監査作業や疑わしい項目を監視する必要があります。 証明書サービスの監査イベント エントリの重要性については、「第 11 章 : 公開キー基盤を管理する」を参照してください。

管理役割

証明書サービスを利用すると、管理役割の委任機能をさまざまに活用できます。 このソリューションでは、この機能を利用して柔軟性の高い PKI 管理方法を実現しています。 証明書サービスにより定義された中心的な管理役割はそれぞれ、ドメイン セキュリティ グループを使用するか、オフライン CA の場合はローカル セキュリティ グループを使用して実装されています。 さらに、このソリューションではあと 2 つの役割とセキュリティ グループが定義されており、これは Active Directory の PKI コンポーネントを介した管理業務の委任に使用されます。

これらの役割と、組織内の個々の IT 担当者は必ずしも 1 対 1 で対応しないことを理解する必要があります。 ほとんどの組織では、1 人の担当者が多くの役割を果たしています。 担当者を次の表のセキュリティ グループのいずれかまたはすべてに当てはめると、簡単に実装できます。 一方、組織の管理責任の区分がもっと複雑な場合は、それに対応する機能があります。

次の表は、実装する役割と実装先のセキュリティ グループとの対応を示したものです。

表 4.9: 中心となる証明書サービスの役割

これらのセキュリティ グループは汎用的なドメイン グループとして実装され、発行 CA とディレクトリに適用されます。 ルート CA の場合、同等のグループはローカル グループとして実装されます (オフライン CA の場合、Enterprise PKI Admins と Enterprise PKI Publishers に相当するものはありません)。 このソリューションでは、同じセキュリティ グループが企業内のすべての CA に対して使用されることを想定しています。 実際の組織に有効でない場合は、範囲が CA であるすべての役割について、CA ごとに別個のグループを実装してください (この場合、CA Admins を Issuing CA 1 にするなど、適切に名前を変更する必要があります)。

このソリューションでは、登録機関 (Registration Authorities) または登録担当者 (Enrollment Officer) とキーのアーカイブおよび復元が実装されていないため、これらの役割によってセキュリティ グループが定義されていません。

CA の役割は、1 つの CA 用に強制的に分離することができます。 これを行うと、複数の役割グループのメンバになっているユーザーは、すべての役割グループの権限にアクセスすることを拒否されます。 役割の分離は、このソリューションでは実装されていません。

Active Directory 統合

CA は、エンタープライズ モード (Active Directory 統合) またはスタンドアロン モードでインストールすることができます。 この 2 つのモードの主な違いは、エンタープライズ CA の場合、構成情報の保存に Active Directory を使用する必要があり、Active Directory を登録機関として使用できるとともに発行した証明書を自動的にディレクトリに公開できますが、 スタンドアロン CA の場合、証明書と CRL をディレクトリに公開できる点は同じでも、これに Active Directory は必要ありません。

この詳細を説明した参考資料については、この章の最後にある「関連情報」を参照してください。

ルート CA はオフライン状態であるため、スタンドアロン サーバーとしてのみ構成できます。 オフラインの中間 CA を組織の環境に展開する予定がある場合は、それらの CA についても同様です。

発行 CA は、次の理由からエンタープライズ CA として構成されます。

CA をドメインにインストールする

組織でマルチドメイン構成のフォレストが構築されている場合 (またはフォレストそのものが複数ある場合) は、CA をインストールするドメインを決定する必要があります。 この決定は、別のドメインの管理者に制御を委任する必要性の有無、組織の各部署への証明書の提供に影響する国または地域の規制の有無など、さまざまな要因の影響を受けます。

最も一般的なアプローチは、CA をフォレスト ルート ドメインまたは管理を目的として設けられた専用ドメインにインストールする方法です。 CA は、長期間にわたって安定して存在するドメインにインストールする必要があります (CA の名前、ドメイン メンバシップ、および DNS ドメイン名については、インストール後に変更することはできません)。 また、コンピュータ アカウントのセキュリティや整合性を保証できないドメインに CA をインストールすることは避ける必要があります。 複数の CA を同じドメインにインストールすれば一元管理が容易になりますが、必ずしもこのようにする必要はありません。

このソリューションでは、CA サーバー アカウントはフォレスト ルート ドメインにインストールされます (エンタープライズ発行 CA のみ)。単一のドメインで構成されているフォレストの場合は、そのドメインにインストールされます。

Certificate Practices Statements (CPS) を CA にマップする

CPS の公開を予定している場合は、CPS の範囲を決定する必要があります。 CPS は CA 階層の全体または一部を範囲として作成することができます。また、CA ごとに CPS を用意することもできます。

後者の方法を使用すると、柔軟性は最も高くなりますが、複数の CPS を管理する際に生じるオーバーヘッドが増加します。 標準的な方法は、個々の CA に対して、または証明書ポリシー、サブジェクトの種類、およびセキュリティ レベルが共通しているひとまとまりの CA に対して、CPS を作成する方法です。 これらの条件が CA 間で大幅に異なっている場合には、複数の CPS を使用しなければならないことがあります。 障害許容力やパフォーマンスの強化のためにまったく同じ CA が多数展開されている場合には、それらの CA の CPS は同じにする必要があります。

既に説明したように、CPS を作成しても非公開にしておくことは、完全に正当的な行為です。 たとえば、CPS に運用やセキュリティに関する内部向けの情報が含まれていると考えられる場合には、CPS を外部に対して非公開にできます。 また、重要な CA 運用ポリシーが記載されている CPS に関しては、内部向けの詳細な運用情報が開示されないように、簡略版の CPS を公開することができます。

CPS を公開し、その場所を CA 証明書に表示する場合は、国際標準化機構 (ISO) により組織に割り当てられている公式のオブジェクト識別子 (OID) 名前空間から、証明書ポリシー用の OID を取得する必要があります。 証明書ポリシーは組織に固有のものであるため、特定するにはグローバルに一意な OID が必要です。

この証明書ポリシーの OID (CP OID) は、組織の各証明書に証明書拡張子としてエンコードされます。 "証明書拡張子" とは、証明書のデータ フィールドの一種です。 この拡張子には URL が組み込まれており、その証明書を発行した CA に適用される CPS の場所を示します。

証明書の目的や出所を示すためのユーザーへの通知をテキストとして含めることもよく行われています (ただしこのテキストは 200 文字以内に制限されているため、CPS ドキュメント自体の代わりにはなりません)。<