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

第 4 章 : 公開キー基盤を設計する

最終更新日: 2005年5月24日

トピック

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

はじめに

前の章では、公開キー基盤 (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 の作成は開始できません。

• 証明機関の階層を設計する。 さまざまな要因に基づいて、証明機関 (CA) インフラストラクチャを作成する必要があります。 ここでは、信頼モデルを定義し、必要な CA の数、CA の管理方法、PKI の拡張方法 (CA を追加する、または他の組織との間に信頼を確立する) を決定します。 さらに、Active Directory® ディレクトリ サービスや Microsoft インターネット インフォメーション サービス (IIS) など、IT インフラストラクチャの他のテクノロジと PKI を統合する方法について説明します。

• 証明書プロファイルを構成する。 ここでは、使用する証明書の種類、証明書に関連付ける暗号化キーに必要な強度、証明書の有効期間、証明書の更新の可否を決定します。

• 証明書管理計画を作成する。 ここでは、証明書をエンド ユーザーに発行する方法、証明書要求の処理方法、証明書失効リスト (CRL) の管理および配布方法を決定します。

ページのトップへ

証明書要件を定義する

このセクションでは、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: セキュリティで保護されたワイヤレス ソリューションの証明書要件

用途	証明書の種類	証明書の数
セキュリティで保護された WLAN	ユーザー用クライアント認証証明書	WLAN へのアクセスが必要なすべてのユーザー
	コンピュータ用クライアント認証証明書	すべてのワイヤレス LAN コンピュータ
	IAS サーバー用サーバー認証証明書	すべての IAS サーバー
Active Directory	ドメイン コントローラ認証	フォレスト内のすべてのドメイン コントローラ

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

用途	証明書の種類	証明書の数
クライアント アクセス仮想プライベート ネットワーク (VPN)	コンピュータ クライアント認証 (IPsec)	すべてのリモート VPN クライアント
支社間の VPN	VPN サーバー認証 (IPsec)	すべての VPN ルーター
IP セキュリティ (IPsec)	コンピュータ クライアント認証	IPsec を必要とするすべてのクライアント コンピュータおよびサーバー コンピュータ
Web セキュリティ	イントラネット Web アプリケーションに対するユーザーの認証	すべてのユーザー
	イントラネット Web サーバー	セキュリティで保護されたイントラネット Web サーバー
暗号化ファイル システム (EFS)	EFS ユーザー	すべてのユーザー
	EFS データ復元	復元エージェント
セキュリティで保護された電子メール	Secure/Multipurpose Internet Mail Extensions (S/MIME) 署名および暗号化	すべての電子メール ユーザー
	キー復元	復元エージェント
スマート カード	スマート カード ログイン	ドメイン ユーザー
コード署名	内部コードとマクロ署名	コード リリース マネージャ

#### 証明書クライアントを定義する 前のセクションで挙げた用途に対して、証明書を使用するクライアントを定義する必要があります。 ここで言う "クライアント" とは、PKI によって発行される証明書を使用する人員、ソフトウェア プロセス、またはデバイスのことを指します。 たとえば、ユーザー、サーバー、ワークステーション、ネットワーク デバイスも、ここで言うクライアントになります。 発行された証明書が使用される経緯について理解するには、証明書のサブジェクト (または*エンド エンティティ*) とその他の証明書ユーザーという 2 つの主なカテゴリにクライアントを分けて考える必要があります。 エンド エンティティとは、PKI によって発行された証明書を持つクライアントです。 証明書の**サブジェクト**フィールドまたは**サブジェクトの別名**フィールドには、クライアントがその証明書の所有者であることを示す 1 つ以上のエントリ (ホスト名、電子メール アドレス、ディレクトリの識別名など) が登録されます。 もう 1 つのカテゴリである証明書ユーザーは、たとえば、エンド エンティティの証明書を確認するか、またはディレクトリで検索する必要があるクライアントですが、必ずしも PKI によって発行された証明書を持っているとは限りません。 この違いを一般的な例で説明すると、インターネットのユーザーが安全な Web サイトで買い物をした場合、このユーザーはその Web サイトの SSL (Secure Sockets Layer) 証明書のユーザーということになります。 しかし、この Web サイトは証明書のエンド エンティティであり、その ID (www.woodgrovebank.com) は証明書の**サブジェクト**フィールドにエンコードされます。 証明書のサブジェクトだけが証明書の秘密キーを使用することができ、証明書の他のユーザーは使用できません。 注 : 証明書の*サブジェクト*は、ほとんどの場合その証明書自体の*ユーザー*であり、通常は他の証明書のユーザーでもあります。 **注 :** 技術用語としては "エンド エンティティ" が正しい用語ですが、この章では主に、より一般的な用語である "証明書のサブジェクト" を使用します。 証明書のサブジェクトと証明書のユーザーの両方について、次の質問に回答することにより、各クライアントの種類を分類する必要があります。 - クライアントは人、コンピュータ、デバイス、またはソフトウェア プロセスか。 - 証明書を使用するプラットフォーム (オペレーティング システムのバージョン) は何か。 - クライアントのネットワーク上の位置はどこか。 たとえば、クライアントは内部 LAN に接続しているか、パートナーの組織内にあるのか、またはインターネット上にあるのか。 - クライアントはドメイン メンバか。 ドメイン メンバの場合、CA とは別のドメインまたはフォレストにあるのか。 ドメインは信頼できないものなのか。 - クライアントが処理する必要のある作業は何か。 たとえば、証明書の登録、証明書の署名、証明書の信頼の検証、ディレクトリ内の証明書の検索、証明書失効状況の確認などのどれか。 この分類は、多くの設計上の決定基準、たとえば証明書を発行する方法、特定の証明書に配置できる信頼のレベル、証明書失効情報を公開する方法などに影響します。 このソリューションでのクライアントの分類を、次の表に示します。 **表 4.3: 証明書のサブジェクト (エンド エンティティ) の分類**

証明書	クライアントの種類	プラットフォーム	場所	ドメイン	証明書の処理
ワイヤレス クライアントの認証	ユーザー	Windows XP	内部ネットワーク	ドメイン メンバ	– 登録 – 認証
ワイヤレス クライアントの認証	コンピュータ	Windows XP	内部ネットワーク	ドメイン メンバ	– 登録 – 認証
IAS サーバーの認証	コンピュータ	Microsoft Windows Server™ 2003	内部ネットワーク	ドメイン メンバ	– 登録 – 認証 – チャネルのセキュリティ保護

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

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

証明書	クライアントの種類	プラットフォーム	場所	ドメイン	証明書の処理
ワイヤレス クライアントの認証	– コンピュータ	Windows Server 2003	内部ネットワーク	ドメイン メンバ	– 検証 – 失効チェック
ワイヤレス クライアントの認証	– コンピュータ	Windows Server 2003	内部ネットワーク	ドメイン メンバ	– 検証 – 失効チェック
IAS サーバー認証	– ユーザー – コンピュータ	Windows XP	内部ネットワーク	ドメイン メンバ	– 検証

上記の表から、サポートする必要のあるプラットフォームと処理の種類を特定できます。 WLAN のシナリオには当てはまりませんが、環境内の他の用途で使用する場合、インターネット上のクライアントによる証明書の検索または検証機能がサポートされているか、または Windows 以外のプラットフォームからの登録機能がサポートされていることが必要な場合があります。 これらの事項は設計プロセスの初期段階で決定する必要があるため、どのような証明書要件が将来必要となるかを検討することは重要です。 このソリューションでは、将来の要件について次の事項を想定しています。 - Windows 以外のクライアントによる証明書の検証が必要になる可能性がある。 - インターネットで証明書の検証が必要になる可能性がある。 - Windows XP および Windows Server 2003 以外のプラットフォーム上で証明書のサブジェクトと証明書ユーザーの両方をサポートする必要がある。 現時点では設計上これらの要件のすべてが満たされているわけではありませんが、対応することは簡単です。 #### 証明書のセキュリティ要件を定義する 証明書のセキュリティは、証明書の保証レベルとも呼ばれます。 これは、証明書のサブジェクトを証明書自体にバインドする際の強度の尺度と見なすことができます。 証明書のセキュリティは、証明書を使用している人 (またはデバイス) が、証明書に記入されたサブジェクトと同一であると確信できる信頼度を表します。 この保証レベルは、主に次の 2 つの事項の尺度になります。 - 登録および証明書登録プロセスの正確性 : たとえば、本人自身がフォト ID を提示して証明書を取得したか、または電子メール アドレスの所有は十分だったか、などです。 - 秘密キーを格納する方法 : 秘密キーのコピーや侵害が困難になるほど、元の所有者である証明書のサブジェクトだけがその秘密キーを保有している確実性が高くなります。 この 2 つは密接に関連しあっています。なぜなら、秘密キーの所有者の身元情報にまったく確信が持てない場合は、高価な秘密キー保護対策に投資するわけにはいかないからです。 同様に、広範なバックグラウンド チェックや DNA 指紋法も含めた高度な登録処理をしても、その後秘密キーが安全性の低い方法で格納されるのではほとんど効果がありません。 証明書の保証を高めるとコストがかかりますが、多くの場合、証明書を使用する場合に、このような保証が必要とは限りません。 正規のドメイン ユーザーに属する証明書の保証を高レベルに設定しない場合は、証明書の登録時の登録証拠としてドメインの資格情報を完全に受け入れることができます。 証明書ポリシー ステートメントと CPS には、使用する保証レベルの意味を記載する必要があります。 次の表は、このソリューションで使用する 3 種類の保証レベルを定義したものです。 **表 4.5: 証明書の保証レベル**

レベル	登録要件	キーのストレージ要件
標準 (低)	ドメイン、その他のパスワード ベースの身元情報に依存する自動承認	ソフトウェア キー
中	証明書マネージャの承認、ビジュアル ID チェック (スマート カード)、または登録担当者の署名	ソフトウェア キーまたは耐タンパー性のハードウェア トークン (スマート カードまたは USB トークン)
高	候補にされた登録担当者の署名と証明書マネージャの承認	耐タンパー性のハードウェア トークン (スマート カードまたは USB トークン)

この表の分類には重なる部分もあります。 ここでの分類は、技術上の厳密な分類ではなくポリシーによる分類です。 組織では、証明書の処理方法に関してポリシーに記載された決定に基づき、分類の基準を定めます。 一般的には、高保証の証明書が利用されることはあまりなく、どちらかと言えば標準保証の証明書が利用されることの方が普通です。 **重要 :** この章では、"低価値" とか "低保証" の証明書という語の代わりに "標準価値" とか "標準保証" の証明書という語を使用します。前者はネガティブな響きがあり、"標準" の方が本来の意味に近いためです。 上の表で定義した保証の分類は、サブジェクトの種類別に分類するとさらに細分化できます。 一般的な分類は次のとおりです。 - コンピュータ別 : 実際に組織内にある任意のコンピュータ、またはデバイス - 内部ユーザー別 : 同等とみなされる正社員または職員 (契約スタッフなど) - 外部ユーザー別 : 組織の外部に存在する、業務上または法的な関連のあるその他のエンティティ (ビジネス パートナー、顧客など) このように分類する理由は、通常サブジェクトの種類によって適用される証明書ポリシーがかなり異なるためです。つまり、証明書の発行、失効、または更新の際の条件はかなり異なります。 証明書を発行する計画がない分類対象についても、その分類に適用できる証明書ポリシーを記載しておくと、ポリシーと CPS を適切に準備できます。 次の表は、保証レベルごとの分類とサブジェクトごとの分類を組み合わせた結果を示したものです。 **表 4.6: 証明書のセキュリティの分類**

証明書のセキュリティの分類	セキュリティの分類の特徴 (例)	証明書の種類 (例)
コンピュータ証明書
標準保証のコンピュータ証明書	– コンピュータのドメインの資格情報に基づいた自動承認 – 年度更新	– WLAN コンピュータ – IPsec
中程度の保証のコンピュータ証明書	– 証明書マネージャの承認が必要 – ソフトウェアでのキー ストレージ – 年度更新	– Web サーバー – IAS サーバー認証
高保証のコンピュータ証明書	– 証明書マネージャによる承認 – ハードウェア セキュリティ モジュール (HSM) でのキー ストレージ	– 証明機関 – セキュリティ保護されたタイム サービス – 登録機関
内部ユーザー証明書
標準保証の内部ユーザー証明書	– ユーザーのドメインの資格情報に基づいた自動承認 – 年度更新	EFS ユーザー
中程度の保証の内部ユーザー証明書	– 証明書マネージャまたは登録担当者の承認が必要 – スマート カードまたはソフトウェアでのキー ストレージ – 年度更新	– セキュリティ保護された電子メール – 低価値または中程度の価値の財務承認 – スマート カード ログオン – 内部コード署名 – データ復元エージェント – キー復元エージェント
高保証の内部ユーザー証明書	– 証明書のサブジェクトの物理的な ID 確認が必要 – 証明書マネージャの承認が必要 – 要求時に登録部門の署名が必要 – スマート カードでのキー ストレージ – 6 か月更新	– 高価値の財務承認 – 民間のコード署名
外部 (ユーザー) 証明書
標準保証の外部証明書	– 事前に割り当てられたパスワードに基づく自動承認 – 年度更新	クライアント認証 (インターネット Web サイトの認証)
中程度の保証の外部証明書	– 証明書マネージャの承認が必要 – スマート カードでのキー ストレージ – 6 か月更新	ビジネス対ビジネス (B2B) 財務承認
高保証の外部証明書	– 証明書のサブジェクトの物理的な ID 確認が必要 – 証明書マネージャの承認が必要 – 要求時に登録部門の署名が必要 – スマート カードでのキー ストレージ – 6 か月更新	非常に高価値の B2B トランザクション

**注 :** 使用する必要がない分類は、作成しなくてかまいません。 分類の方法は、これより単純にすることも複雑にすることもできます。なお、このすべての組み合わせの証明書を発行する必要はありません。 技術的には、これらのさまざまな種類の証明書サブジェクトをすべて同じ方法で扱うことができます。 ただし、通常はサブジェクトの種類ごとに異なるセキュリティ ポリシーを定義します。たとえば、社内従業員は別の組織の職員とは別に扱われます。 異なる証明書ポリシー (および、さまざまな CPS での具体化) は、これらのさまざまな証明書の種類を発行する CA の構成方法の決定に影響します。 これについては、後述します。 さらに、最終的に同じ管理者が上記の 3 つの分類の証明書ユーザー (PKI 用語では "エンド エンティティ") に対して発行された証明書に責任を持つかどうかを検討する必要があります。 多くの組織では、コンピュータが正規のドメイン メンバであることを認定できる担当者と、パートナー企業の身元情報を認定できる担当者は同じではありません。 CPS には、この責任関係を記述する必要があります。 ##### アプリケーションの証明書のセキュリティを定義する 前のセクションで定義した証明書のセキュリティ分類は、設計用の証明書の種類を分類する場合に使用できます。 その分類を、次の表に示します。 **表 4.7: 証明書のセキュリティ要件**

証明書の種類	セキュリティの分類	プラットフォーム	論理的な場所	承認	キー サイズ	有効期間
クライアント認証 - ユーザー	標準保証のコンピュータ証明書	–Windows XP –Windows Server 2003	内部	自動 (ドメイン認証)	中	中
クライアント認証 - コンピュータ	標準保証のユーザー証明書	–Windows XP –Windows Server 2003	内部	自動 (ドメイン認証)	中	中
IAS サーバー認証	中程度の保証のコンピュータ証明書	–Windows XP –Windows Server 2003	内部	手動	中	中

上記の大まかな要件を使用して、この章の後半の「証明書プロファイルを構成する」ではより詳細に特定の証明書プロファイルを構成します。 ##### 証明書の目的を組み合わせる 複数のアプリケーション機能 (または使用法) を組み合わせて 1 つの証明書にすることができます。これにより、1 つの証明書を使用して電子メールに署名したり、ネットワークにログオンしたり、アプリケーションへのアクセスを許可することができます。 複数の使用法を 1 つにまとめることができれば、証明書サーバーとディレクトリ サーバーにかかる管理コストおよびストレージ コストの削減につながります。 ただし、多目的の証明書には短所もあります。 たとえば、用途が異なると、証明書の承認プロセスも異なる場合があります。 複数の証明書を使用する理由はほとんどが技術的なものですが、通常は、用途によって証明書のセキュリティ レベルが異なることが最大の理由です。つまり、証明書と証明書のサブジェクトを結合する保証レベルはさまざまです。 このような違いは、次に示す事項のいずれかまたはすべてに存在します。 - 証明書の承認プロセス - キーの長さ - キーのストレージ メカニズム - 証明書の有効期間 このため、複数の証明書使用法を組み合わせる場合、一般的にはセキュリティ レベルが同じものを組み合わせるのが最適です。 このソリューションで使用されるクライアント認証証明書には、IPsec やコンピュータ認証など、他の標準的な用途の使用法も含まれます。 他の証明書の使用法に対する要件を定義すると、それらの要件を組み込んで証明書を再発行できます。その場合、証明書の更新が必要となり証明書テンプレートの定義から始めることになる可能性があります。 ただし、IAS サーバー証明書は、中程度の保証の証明書であるとみなされます。 承認されていないサーバー証明書がもたらす脅威は、不正なクライアント証明書による脅威よりはるかに危険です。 したがって、サーバー証明書はより慎重に扱ってください。マイクロソフトでは、サーバー証明書に標準保証の用途の使用法を組み合わせることはお勧めしていません。 [](#mainsection)[ページのトップへ](#mainsection) ### 証明機関の階層を設計する 組織の証明書ベースのアプリケーションをサポートするには、必要に応じて CA をリンクすることにより、証明書の発行、検証、更新、失効を担当するフレームワークを確立する必要があります。 一方 CA は、証明書のサブジェクトの認証、証明書の公開、および証明書失効情報の公開などを行う場合、基になる IT インフラストラクチャに依存します。 CA インフラストラクチャを確立する目的とは、組織にとって最適のセキュリティ レベルを維持しながら、ユーザーに信頼性の高いサービスを提供し、管理者に管理能力を与え、また現在と将来のニーズを満たす柔軟性を与えることです。 #### 信頼モデルを選択する CA インフラストラクチャを設計する最初の手順として、要件に最も適した信頼モデルを決定します。 基本モデルとして、階層信頼モデルとネットワーク信頼モデルの 2 つがあり、ハイブリッド信頼モデルではこの両方の要素を組み合わせることができます。 これらのモデルの詳細については、「関連情報」で紹介している「*Windows Server 2003 Deployment Kit*」の「Designing a Public Key Infrastructure」(英語) を参照してください。 このガイドのソリューションでは、階層信頼モデルを使用します。 その理由は次のとおりです。 - オンライン CA よりも高いセキュリティ レベルで、オフライン CA を扱うことができます。 オフライン CA の 1 つまたは複数のレイヤによって、発行された証明書の可能な信頼レベル全体が高まります。 - 階層は、ディレクトリがなくても簡単に動作します。この特徴は、内部ディレクトリにアクセスできない外部クライアントをサポートする場合に重要です。 ネットワーク信頼モデルでは一般的に、ユーザーが CA の相互証明書を検索して信頼連鎖を構築できるように、ディレクトリが必要です。 階層では信頼連鎖は常に明示的です。 - 保守とクライアントへの配布が必要な信頼アンカの数が少なくなり、ルート CA 証明書を証明書ユーザーに配布するだけですみます。 - ルート階層にも、常に、他の階層との間で相互証明することで、将来的に複数の信頼アンカ (またはルート) を組み込むオプションがあります。 たとえばこの設計で、組織の合併、または特殊な目的のための証明書の管理をそれぞれの部署に移管するなどの状況に対応することができます。 提案されているソリューションでは、単一ルートで十分です。 ##### サード パーティと内部ルートを比較する PKI の信頼アンカとして内部ルートを使用したり、民間の CA のサービスを使用することができます。 サードパーティ ルートを使用するということは、組織の発行 CA が民間のルート CA によって (通常は 1 つ以上の中間 CA を通じて) 認証されるということです。 したがって最終的に、この外部ルート CA では発行されたすべての証明書にそれぞれの信頼アンカが含まれています。 **注 :** このガイドでは明確に説明されていませんが、組織の証明書要件はどれも民間の CA にアウトソーシングすることができます。 その場合、オンサイト管理サービスを利用するか、証明書プロバイダから直接証明書を取得します。 多くの場合、このようなアウトソーシングは、組織が小規模であるとか証明書の使用法が非常に限定されている場合を除いて、財政上あまり実際的な方法ではありません。 アウトソーシングに関する決定は、内部ルートとサードパーティ ルートのいずれを使用するかという問題とはまったく関係ありません。ただし、この 2 つの問題は混同されることがよくあります。 内部発行証明書に民間ルートを使用する長所を次に示します。 - 外部団体 (セキュリティで保護された Web サイトにアクセスする顧客や署名された電子メールを受信するパートナー企業など) から見て、組織と安全な取引を実行する際の信頼性が高まります。 通常、サードパーティのルート CA は既に信頼されているため、証明書の信頼性について判断を行う必要がなくなります。 - 組織が専門のサービス プロバイダのノウハウ (証明書の使用に関連する技術的、法的、およびビジネス上の問題に関する知識) を利用することができます (ただし、証明書プロバイダがすべての証明書を発行している場合を除き、組織には証明書の発行と使用方法について責任があるため、CPS に記載する必要があります)。 ただし、この方法には次の短所があります。 - 一般的に、証明書ごとのコストが高くなります。 - 証明書プロバイダには、民間のルート CA が従属するすべての CA に対して、厳しいセキュリティ手段と監査手段が要求されます。 - 内部ユーザーとデバイスは、インターネット上で公開されているサードパーティの CA の CRL にアクセスできる必要があります。 - アプリケーションによっては、ルートに特定のパラメータまたは拡張子、および中間的な CA 証明書 (Microsoft Windows スマート カード ログオンなど) が必要となる場合がありますが、それらを証明書プロバイダから入手できないことがあります。 - 組織と証明書プロバイダとの間の民間契約では、下位 CA から発行できる証明書の種類が制限される場合があります。 たとえば、Web サーバー証明書が許可されない可能性があります。 - 民間のルート CA を信頼すると、組織のセキュリティ ニーズに対して信頼の範囲が広すぎる場合があります。 内部 CA に特殊なチェックや特別なレイヤを導入して、組織が発行した証明書と、同じルートに属する別の組織が発行した証明書を区別しなければならないことがあります。 このような短所があっても、組織外部のユーザーが信頼する証明書を数多く発行する必要がある場合は、民間ルートの下位に少なくとも PKI の一部を従属させることを検討する必要があります (ただし、この場合 2 つの別々の階層の作成が必要になることがあります)。 このソリューションでは、組織で使用される証明書の大半に、内部ルート CA に基づく階層を使用しています。 このアプローチには、次のような長所があります。 - 組織が直接、中心的な信頼アンカ (ルート CA) の制御と、証明書の発行および発行された証明書の使用を管理するセキュリティ ポリシーを維持することができます。 - 内部 PKI から比較的低コストで多数の証明書を発行できます。 - 発行できる証明書の種類に制限はありません。 - 内部証明書の信頼と外部証明書の信頼にあいまいさがありません。 - CRL および機関情報アクセス (AIA) の情報を、必要に応じて内部または外部に公開できます。 証明書ユーザーの信頼されたルートの管理が困難な場合は、外部ルートの利用を検討することをお勧めします。 このソリューションでは、次のサービスについて、サードパーティの証明書と外部ルートを利用することを提案しています。 - インターネット Web サーバー - 民間のコード署名 - 民間の文書署名 - 外部で信頼された安全な電子メール ##### 外部証明書の信頼を定義する 前のセクションでは、他の組織の証明書インフラストラクチャの信頼について説明しました。 証明書の信頼を組織内で制御する方法を決定するには、このテーマをさらに広げて検討する必要があります。 ここで言う "信頼" には、次の重要な 3 つの条件が含まれます。 - 信頼を置く人またはエンティティ。つまり、誰を信頼するか。 - 相手が行うと信頼している処理または動作。つまり、何が行われると信頼するか。 - 信頼を続ける時期。つまり、いつまで相手を信頼するか。 証明書の場合、"誰" とは証明書の発行機関を、"何" とは制御の対象となる証明書の使用法およびその他の特性を指します。 "いつまで" とは、ルート CA 証明書の有効期限か、場合によっては、作成する特殊な相互信頼証明書の有効期限のことを指します。 別の組織と新たなビジネス関係を確立する場合や、ユーザー向けの一部の機能を有効にする場合 (たとえば、Web 証明書を信頼することで、セキュリティで保護された HTTP セッションを許可するなど) には、組織が外部団体との間に築いている既定の信頼関係の変更が必要になる場合があります。 たとえば、次のような場合がそれに当たります。 - パートナー組織 (または新規の民間証明書プロバイダ) の CA 証明書を配布して、一部またはすべてのユーザーがパートナーまたは民間 CA 証明書を信頼できるようにする場合。 - 組織全体で CA 証明書を信頼する必要がない場合に、組織内で特殊な目的の CA または PKI の CA 証明書を配布する場合。 - クライアントのルート ストアにある既存の民間ルートを置き換え、信頼された証明書の使用法を制限できるようにする場合。 たとえば、電子メールおよびセキュリティ保護された Web サーバーの証明書に関してのみ所定の民間ルートを信頼し、スマート カード ログオンの証明書に関しては信頼しないというように決定する場合です。 上記の目標を達成するには、次のようないくつかの方法があります。 - 内部ルートと信頼の対象となる CA 証明書との間に限定従属関係 (相互証明とも呼ばれる) を作成します。 たとえば、内部 CA のいずれかによって外部 CA 証明書を再署名するなどの方法です。 この方法では、外部 CA が実質的に署名 CA の信頼された下位として内部 PKI に追加されます。 証明書の使用法とポリシー、サブジェクト名の種類、または発行ポリシーを厳密に限定したうえで、証明書の種類に制限を配置できます。 **重要 :** 限定従属または相互証明を使用する方法は複雑で、問題なく実装するのが最も難しい方法です。 この章の最後にある「関連情報」で紹介されているテクニカル ペーパー「*Windows Server 2003 を使用した相互証明および限定従属の計画と実装*」を参照してください。 - 証明書信頼リスト (CTL) を作成します。 これにより、信頼されたルート CA のリストを定義し、それらの CA を信頼する場合の目的 (たとえば、セキュリティで保護された電子メール) を指定することができます。 次に、Active Directory グループ ポリシー オブジェクト (GPO) を使用して CTL を展開します。 この方法は便利ですが、マイクロソフト独自の方法です。 CTL は、Windows 2000 以降を実行しているクライアントでのみ使用できます。 このオプションは、CTL GPO が適用されているドメインのクライアントにしか影響しません。 - ルート CA 証明書を (Configuration コンテナ内の) Active Directory の Trusted Certification Authorities ストアにインストールします。 これによって、フォレスト全体のすべてのユーザーとデバイスに対する無条件信頼がルート CA (およびすべての下位 CA) に作成されます。 ただし、無条件信頼を許可するには細心の注意が必要です。 この方法は、自分の組織が管理している CA に対してのみ使用してください。 - グループ ポリシーを使用して、信頼されたルート CA 証明書をユーザーまたはコンピュータのサブセットに展開します。 これは前のオプションと似ていますが、信頼されたルートを受け取る対象 (GPO が適用されるユーザーまたはコンピュータ) をかなり詳細に指定できます。 このオプションは、GPO が適用されているドメインのユーザーにしか影響しません。 - Microsoft Root Update サービスを使用します。 このサービスは、民間の証明書プロバイダが多数の人々に新規のルートを容易に配布できるようにすることを目的としています。 信頼されたルート CA を規制する場合は、このサービスを会社のすべてのシステムで無効にすることを検討してください。 - グループ ポリシーを使用してサードパーティの信頼されたルートを無効にします。 ここまで挙げてきた他の項目とは反対に、これは信頼を増やすのではなく、信頼を制限する方法です。 Windows を実行しているすべてのコンピュータ (および、そのコンピュータを使用するユーザー) は、インストールされるルートを既定で継承します (これは、さまざまなプラットフォームで動作する他のオペレーティング システムや Web ブラウザでも同様です)。グループ ポリシーを使用すると、このルートの信頼が自動的に適用される機能を無効にできます。 次に、前述のいずれかのメカニズムを使用して (制限の有無にかかわらず、セキュリティのニーズに応じて)、必要な信頼されたルートを選択して追加し直すことができます。 **注 :** 一部のルート証明書は無効にできません。 これは、オペレーティング システムがドライバ署名ポリシーなどに関する特定のルート証明書に依存しているためです。 このような必要なルートは、前述のグループ ポリシー設定で無効になることはありません。 このソリューションでは、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 階層全体のほんの一部分に限定することができます。 - 別々の証明書ポリシーを CA 階層の分岐全体に実装することができます。 - ルート CA キーを使用する回数が減り、その結果、キーが侵害される危険が少なくなります。 中間 CA にレイヤを追加すると PKI のセキュリティは全体的に向上しますが、これには複雑化、ハードウェアおよびソフトウェアの追加、管理コストの増大 (通常はハードウェアやソフトウェア ライセンスのコストよりはるかに大きくなります) といった問題が伴います。 大部分の用途では、セキュリティ要件として 3 階層を挙げるのは妥当ではありません。 このことは、特に CA キーが HSM で保護されている場合に当てはまります。 このガイドで定義するソリューションでは、2 階層を提案しています。 このソリューション設計では、優れたセキュリティとコストのバランスが妥当であり、また今後証明書を使用する可能性のあるさまざまな用途に対応できる柔軟性も備わっています (詳細については、この章の前のセクション「証明書要件を定義する」を参照してください)。 **注 :** 3 階層の使用を義務づける政府の法令または規制は、このガイドでは検討対象となっていません。 そのような規制がある場合は、当然その他の条件も異なってきます。 ##### 提案する CA 階層 次の図は、提案する階層を示したものです。 現在の実装は、ルート CA と 1 つの発行 CA で構成されています。 発行 CA は主に、コンピュータまたはユーザーに対しては標準保証 ("技術的" と言う場合もあります) 証明書を、コンピュータに対してはより高価値の証明書を発行します。 .gif) **図 4.2: 証明機関の階層** [拡大表示する](https://technet.microsoft.com/ja-jp/cc527050.04fig4-2_big(ja-jp,technet.10).gif) この設計を使用すると、セキュリティ保護されたワイヤレス LAN 認証 (802.1X) をサポートする完全な機能の PKI を展開でき、ハードウェア、ソフトウェア、管理にかかるコストも比較的低く抑えることができます。 **注 :** この単純なインフラストラクチャ設計は、いくつかの方法で拡張してさまざまな要件に対応させることができます。 これについては、「CA インフラストラクチャを拡張する」で説明します。 発行 CA は最初、次の種類の証明書を発行するように構成されます (上の図の太枠で囲まれた部分)。 - クライアント認証 - ユーザー - クライアント認証 - コンピュータ - IAS サーバー認証 最初の 2 つの証明書は標準保証の証明書です。ユーザーまたはコンピュータのドメインの資格情報に基づいて自動的に発行されます。 これらの証明書の所有は、有効なドメイン ユーザー名とパスワードを使用する場合ほどサブジェクトの束縛が強くありません。 ただし、ドメイン名とパスワードではなく証明書を使用することには、セキュリティ上の長所やその他の技術上の長所があります。 IAS サーバーは高度なセキュリティ機能を実行するため、IAS サーバー認証は中保証の証明書に分類されます。 この種類の証明書を発行する場合は、通常、要求の有効性のチェックなどが追加され、証明書マネージャの承認が必要になります。 **注 :** 後述の構築に関する章で、この種類の証明書を作成する方法が記載されていますが、そこでは証明書マネージャの承認が必要という要件は無効にされています。 これにより、IAS サーバーは有効期限の切れた証明書を自動的に更新し、証明書が失効したときにサービスが無効になる事態を回避します。 証明書要求を十分に検査して承認するプロセスが用意されている場合は、証明書マネージャの承認という要件を有効にすることを検討してください。 ##### CA のハードウェアおよびソフトウェア要件 ここでは、CA のハードウェアおよびソフトウェア要件について説明します。 ###### ルート CA ルート CA のハードウェア要件は最小限で済みます。 コンピュータの仕様は、Windows Server 2003 の実行に必要な最小要件を満たしていれば十分です。 ルート CA のハードウェアの重要な要件は、長期的な信頼性と保全性です。 ルート CA は通常、長期間使用されるコンピュータに設置しますが、ほとんどの場合電源はオフにしておきます。 このコンピュータの電源を*入れる*場合は、常に正常に起動することが必要です。 また、ハードウェア障害が起こった場合に対処できるように、そのコンピュータ モデルの生産終了後数年が経過したあとでも、コンポーネントの交換を容易に行える必要があります。 このような点を踏まえ、マイクロソフトでは次のことをお勧めします。 - サポートとハードウェアの長期保守で実績のある有名なメーカーを選択します。 そのベンダから交換部品を入手できる期間を確認します。 - できれば、ワークステーションやポータブル コンピュータではなくサーバーを使用します。サーバーの方が標準化されていることが多く、モデル チェンジもそれほど頻繁に行われないためです。 - ハードウェアに障害が発生して短時間で修復できない場合に、ルート CA の役割を引き継ぐことができる補助システムを用意しておくことを検討します。 - システムに障害が発生しても再構築できるように、元のインストール メディア、ドライバ、更新プログラムのコピーを作成します。 - HSM を使用してセキュリティを強化することを検討します。 ルート 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 のガイドラインの他に、次の事項について検討することをお勧めします。 - 冗長なネットワーク インターフェイス カード (NIC) により、NIC を組み合わせて使用します。 - 2 台の RAID 1 ボリュームが推奨する最小構成です。これで、CA ログを別の物理ストレージ ユニットに格納できます。 これにより、パフォーマンスが向上し、ハードウェア障害を復元できます。 - パフォーマンスを向上させるためには、2 台ではなく 3 台の RAID 1 ボリュームを使用して、オペレーティング システム、証明書サービス データベース、証明書サービス ログをそれぞれ別の物理ボリュームに格納することを検討します。 - パフォーマンスと復元性を向上させるには、IDE 上に高性能 SCSI ドライブおよびコントローラを搭載することを推奨します。 Active Directory とのやり取り以外にも、ディスク サブシステムのパフォーマンスが、CA のパフォーマンス全体を決定するうえで最も重要な要因となることがあります。 - 証明書の発行時の署名操作に対するセキュリティの強化とパフォーマンスの向上のために、HSM の使用を検討します。 ルート CA とは異なり、発行 CA では、編集可能な証明書テンプレートとユーザー証明書の自動登録をサポートするため Windows Server 2003 Enterprise Edition の追加機能が*必要となります*。 ###### 複数の発行 CA を使用してサービスを復元する ここでは、複数の発行 CA をインストールする技術的な理由について説明します。 さらに、異なる種類の証明書を登録するためにさまざまな発行 CA が必要な理由として、セキュリティ上の理由とポリシー上の理由があります。 この理由についてはこの章で後述します。 既に説明したいくつかの種類の証明書を何万ものクライアントに発行する場合、簡単な構成のハードウェアを使用した発行 CA が 1 つあれば十分です。つまり、純粋にパフォーマンス上の理由で複数の発行 CA を必要とすることはほとんどありません。 ただし、発行 CA の可用性を満たすために、複数の CA を展開して同じ種類の証明書を登録する必要があるかどうかは検討する必要があります。 CA には、多くのサービスに見られるような可用性の問題はありません。 クライアントは、証明書を使用または検証する際に CA にアクセスする必要がありません。 クライアントが CA に直接アクセスするのは、次の作業を行うために CA が必要になった場合だけです。 - 新しい証明書を登録する。 - 証明書を更新する。 - 証明書を無効にする。 - 新しい CRL を公開する。 - CA 証明書自体を更新する。 次の表に、各項目の可用性要件の詳細を示します。 **表 4.8: CA サービスの可用性要件**

CA サービス	可用性要件
登録サービス – 新しい証明書	場合によっては新しいユーザーがネットワークまたは証明書を必要とするその他のサービスにアクセスできなくなるため、ここでは可用性は重要な要因です。 CA をバックアップから復元するのにかかる時間が、新規ユーザーが証明書を登録するのにかかる時間よりも長いかどうか評価する必要があります。 ほとんどの組織では、CA の復元にかかるコストの方が、新たに CA を追加して管理するコストより安いと判断されます。 そうでない場合は、関連する証明書の種類ごとに複数の発行 CA が必要になります。
登録サービス – 証明書の更新	自動更新を使用した場合、既定値で以前の証明書が失効する 6 週間前に更新が行われます。 一方、CA のバックアップからの復元時間は、通常 1 時間単位で測定されます。 証明書を手動で更新する場合、そのまま所有者が更新します。 重要な証明書の更新時期が来ると所有者に警告する、自動警告システムを構築する方法もあります。 その他の点では、可用性の条件は新しい証明書の登録と同じです。
証明書を無効にする	通常、証明書を無効にできるのはその証明書を発行した CA だけであり、他の CA では無効にできません。 失効が時間重視の場合 (つまり、CA を復元する前に失効させる必要がある場合)、失効対象となる証明書のシリアル番号と (別のコンピュータに復元された) CA 秘密キーがわかれば、現在の CRL に失効エントリを挿入できます。 CRL には通常、1 日以上の待機時間があります。 CA の復元時間が次の CRL の公開までの間隔より短い場合は、手動で CRL を更新してもあまり意味はありません。
CRL を公開する	CRL は CA に対して一意です。別の CA を追加しても CRL 公開の復元性が向上するわけではなく、CRL 公開で障害が発生した場合の影響が最小に抑えられるだけです (これは、発行した証明書のすべてが、障害が発生した CRL に依存するわけではないためです)。 多くの証明書アプリケーションでは、最新の失効状況にアクセスできることが不可欠の条件です。 つまり、期限の切れていない CRL は、公開された CRL 配布ポイント (CDP) で使用できる必要があります。 これができない場合、失効が重要な意味を持つ証明書アプリケーションに障害が発生します。 CA の復元期間は、以前の CRL の失効と新規の CRL の発行が重なる期間よりも長くなることはありません。 まれにこのような状況が発生した場合は、CRL を再署名して有効期限を延長することができます。 この手順については、運用ガイドを参照してください。
CA 証明書を更新する	このサービスでは、発行 CA を追加して使用できません。 CA の復元時間が問題になるほど、この作業の処理が遅くなることはありません。 遅くなった場合でも、CA 証明書を 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 が高い保証レベルを備えている限り、保証レベルがより高い発行 CA をあとから追加すれば、より価値の高い証明書を自由に発行できます。 既存の標準保証の CA と平行して、高保証の CA を保持できます。 ただし、ルート CA を比較的セキュリティの低い環境にインストールして構成し、あとで高価値の証明書を発行する必要が生じた場合は、ルート CA を再インストールするか、新しいルート CA を作成する必要があります。

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

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

管理役割

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

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

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

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

役割名	セキュリティ グループ	範囲	説明
エンタープライズ PKI 管理者 (Enterprise PKI Administrator)	Enterprise PKI Admins	Active Directory フォレスト	PKI 全体に責任を持ち、エンタープライズ用の証明書の種類、アプリケーション ポリシー、信頼パスなどを定義する。
エンタープライズ PKI 発行者 (Enterprise PKI Publisher)	Enterprise PKI Publishers	Active Directory フォレスト	ディレクトリに対する信頼されたルート証明書、サブ CA 証明書、および CRL の公開を担当する。
CA 管理者 (CA Administrator)	CA Admins	CA	CA の構成を担当する。 多くの場合、エンタープライズ PKI 管理者および管理者役割と同じ担当者が兼務します。 証明書の使用法で指示されている場合は、CA ごとに複数の CA 管理者が割り当てられます。
管理者 (Administrator)	ローカル Administrators	CA	CA オペレーティング システムとサーバーを管理し、 CA のインストールと CA 証明書の更新を担当する。 通常、CA 管理者の役割の担当者と作業を分担します。
CA 監査人 (CA Auditor)	CA Auditor	CA	監査イベント ログやポリシーなど、CA の監査可能なイベントを管理する。
証明書マネージャ (Certificate Manager)	Certificate Manager	CA	手動による承認が必要な証明書について、要求の承認と証明書の失効を行う。 証明書の使用法で指示されている場合は、さまざまな CA の承認を複数の証明書マネージャが担当することができます。
登録機関 (Registration Authority) または 登録担当者 (Enrollment Officer)	[未定義]	証明書プロファイル	証明書マネージャの役割を拡張したもの。 帯域外 ID 検証後の、証明書要求の承認と署名を担当する。 人が担当することも、IT プロセスまたはデバイス (指紋スキャナやデータベースなど) に行わせることもできます。 証明書プロファイル (テンプレート) ごとに異なる登録機関を指定することも、複数の CA にまたがることもできます。
キー復元エージェント (Key Recovery Agent)	[未定義]	CA	CA データベース内のアーカイブ形式の秘密キーを解読するためのキーを保持する。
CA バックアップ オペレータ (CA Backup Operator)	CA Backup Operator	CA	CA サーバーのバックアップと復元、およびバックアップ メディアの安全な格納を担当する。

これらのセキュリティ グループは汎用的なドメイン グループとして実装され、発行 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 にまたがって存在します) を容易に管理できるという大きな利点があります。 - IAS でワイヤレス クライアントが認証される際、信頼された証明書のマッピングを実行するために Active Directory が必要となるため。 発行 CA が NTAuth ストアに登録されていないと、この処理は許可されません。 - 対応するユーザー オブジェクトまたはコンピュータ オブジェクトに対して証明書を自動公開できるため (ただし、このソリューションでは必要ありません)。 - 発行 CA では、証明書要求や発行する証明書に使用するサブジェクト名情報を取得できる、信頼済みのソースが必要となるため。Active Directory を利用すると、ディレクトリに保存されているユーザーやコンピュータの属性値に基づいて、これらの情報を入手できます。 - スマート カード ログオン用の証明書が将来必要になる可能性があるため。この場合、エンタープライズ 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 ドキュメント自体の代わりにはなりません)。 CP OID および CPS の URL が証明書にエンコードされる仕組みの詳細については、この章の最後の「関連情報」で紹介されている RFC 3280 文書「*Internet X.509 Public Key Infrastructure Certificate and CRL Profile*」(英語) を参照してください。 CP OID を取得し、CPS の公開先となる URL を決定したら、この情報を CA 証明書に含めることができます。 この手順については、「第 7 章 : 公開キー基盤を実装する」で説明します。 #### IT インフラストラクチャをサポートする このソリューションの PKI が正しく動作するためには、他のインフラストラクチャのサービスが必要です。 次の図では、主要なサービスとして Active Directory と IIS を示し、それらのサービスが CA および証明書クライアントとどのように連携しているかを説明しています。 .gif) **図 4.3: CA と IT インフラストラクチャの相互関係** [拡大表示する](https://technet.microsoft.com/ja-jp/cc527050.04fig4-3_big(ja-jp,technet.10).gif) 監視、警告、および管理のためのインフラストラクチャも、証明書サービスが正しく動作するためには非常に重要ですが、これらの要素はこの図には示されていません。 このインフラストラクチャについては、「第 11 章 : 公開キー基盤を管理する」で詳しく説明します。 次のセクションでは、Active Directory と IIS が PKI に提供するサービスについて説明します。 ##### Active Directory 「Active Directory 統合」で説明したように、Active Directory を利用すると、PKI に必要なさまざまなサービスが提供されます。 これには、証明書の公開、証明書の登録、証明書とアカウントのマッピング、信頼と構成に関する情報の保存などがあります。 エンタープライズ CA では、これらのサービスのすべてが自動的に提供されます。 また、オンラインのスタンドアロン CA でもこれらのサービスの一部を利用できます。 ただし、オフラインの CA では、Active Directory と直接やり取りして情報の保存や取得を行うことはできません。 このソリューションでは、オフラインのルート CA の CA 証明書が Active Directory の信頼されたルート ストアに公開されます。 この結果、ルート CA の証明書は、フォレスト内にある Active Directory のすべてのクライアントの信頼されたルート ストアに自動的に配布されます。 他にも、ルート CA では Active Directory を使用して次のような公開サービスを実行できます (ただし、このソリューションではこれらのサービスは使用しません)。 - CRL の公開 - フォレスト全体のドメイン クライアントにより、Active Directory に公開された CRL をローカルのドメイン コントローラから取得できます。 - 相互証明書のドメイン クライアントへの配布 - Active Directory に公開された相互証明書が、フォレスト内の Active Directory の各クライアントのローカルの証明書ストアに自動的に配布されます。 発行 CA では、「Active Directory 統合」で説明したすべてのサービスの実行に関して Active Directory を使用します。 ###### Active Directory クライアント以外のクライアントのために Active Directory を使用する 別の信頼されていない Active Directory フォレストのメンバである PKI クライアントや、どの Active Directory フォレストのメンバでもない PKI クライアントのサポートに関しては、いくつか考慮しなければならない事項があります。 このような外部クライアントから LDAP (Lightweight Directory Access Protocol) を使用して CA 証明書と CRL を取得できるようにする必要がある場合は、次の事項を考慮してください。 - 外部クライアントをサポートする場合、CDP パスと AIA パスに明示的な LDAP ホスト名を指定する必要があります。 詳細については、このあとの「CDP パスと AIA パスを構成する」を参照してください。 - 既定では、外部クライアントでは Active Directory に対して匿名 LDAP クエリは実行されません。 フォレストの **dsHeuristics** 値を変更して、匿名アカウントに明示的なアクセス許可を与える必要があります。 詳細については、この章の最後にある「関連情報」を参照してください。 **警告 :** この変更を行うと、フォレスト内のすべてのドメイン コントローラで匿名 LDAP が許可されます (ただし、認証されていないクライアントがアクセスできるのは、匿名アカウントに対して明示的にアクセス許可が与えられているアイテムにのみです)。 この変更を実施する前に、認証なしでディレクトリにアクセスできるようにした場合の影響を十分に検討してください。 - 外部クライアントは、ディレクトリ内に設定されている信頼されたルートに関する情報を継承しません。継承以外の方法でこの情報を外部クライアントに設定する必要があります。 ###### インターネット クライアントに関する考慮事項 組織の外部にあるクライアント (インターネット クライアントなど) の CDP および AIA を構成する場合にも、重要な考慮事項がいくつかあります。 これについては、このあとの「CDP パスと AIA パスを構成する」で説明します。 インターネット クライアントに対して証明書検索機能を提供する必要がある場合 (電子メール用の証明書の検索をサポートする場合など) は、インターネット クライアント用の LDAP ディレクトリを別途作成しなければならないことがあります。 セキュリティに影響するため、マイクロソフトでは、前のセクションで説明した内部の Active Directory フォレストへの匿名 LDAP を有効にする方法は用いないことを強くお勧めします。 代わりに、Active Directory フォレストを別途作成し、LDIFDE ツール、Microsoft Metadirectory Services などのメタディレクトリ製品、またはその他のディレクトリ同期製品を使用して、内部フォレストから情報をレプリケートしてください。 ##### インターネット インフォメーション サービス この設計では、IIS により PKI に対して次の 2 つのサービスが提供されています。 - CRL や CA 証明書などの CA 情報 (CPS ドキュメントを含む場合もあります) が公開されます。 - Web インターフェイスを使用して証明書を登録できます。これは特に Windows 以外のクライアントに便利な機能です。ただし、このソリューションではこの機能は使用しません。 ###### IIS を使用して CA 証明書を公開する このソリューションでは、ルート CA と発行 CA の両方の CDP と AIA に関する情報を Web サーバーに公開します。 HTTP ベースの公開を使用すると、必要な情報を取得できるクライアントの範囲を最大に広げることができます。 このような目的で IIS を発行 CA にインストールすることは一般的に行われていますが、必ずしも最良のアプローチであるとは限りません。 別の IIS サーバーを使用して CRL と CA に関する情報の公開を行える場合は、その IIS サーバーを使用することをお勧めします。 ユーザーが CA にアクセスする手段はできるだけ制限します。CA にプロトコルとサービスが追加されれば、そのたびに攻撃者がサーバーに侵入する入り口が増える可能性があるためです。 また、CA 上で IIS を使用すると、その CA をシャットダウンして保守を実施することができなくなります。この CA が多くのクライアントにとって唯一有効な CRL の場所になる可能性が高いためです。 構築ガイドでは、CRL と CA を公開する IIS をホストするために発行 CA を使用しています。 これは、構築プロセスを単純化し、追加ハードウェアに関する要件を減らすためです。 ただし、可能な場合は発行 CA と IIS は別々に配置することをお勧めします。 ###### IIS の登録ページを使用して証明書を登録する IIS の登録ページがあると、ドメイン以外のクライアントの登録、Windows 以外のクライアントの登録、Microsoft Internet Explorer 以外のブラウザ クライアントなど、さまざまな状況に利用できるため便利です。 ただし、Web 登録ページは CA に必須ではありません。 このソリューションでは、既定で登録ページが発行 CA にインストールされますが、別の Web サーバー (ASP ページをサポートするには IIS 5.0 以降を実行しているサーバーが必要) にインストールすることもできます。 登録ページがインストールされていると一部の登録タスクを簡略化できますが、必要がなければインストールする必要はありません。 Web 登録ページのインストールおよび使用方法の詳細については、この章の最後にある「関連情報」を参照してください。 #### CDP パスと AIA パスを構成する クライアントは、証明書が失効していないかどうかを確認するために、最新の CRL にアクセスする必要があります。 また、エンド エンティティ証明書が信頼されたルートにチェーンしていることを確認するため、CA 証明書を取得しなければならないこともあります。 各 CA は、証明書に 1 つ以上の URL をエンコードする必要があります。この URL は、クライアントがその証明書に関する情報を取得できる場所を示します。 各 CA の CDP および AIA に設定する対象は、証明書を使用するクライアントの種類によって異なります。 たとえば、証明書を使用するのは、Active Directory フォレストのメンバであるユーザーおよびコンピュータだけなのか、 あるいは、外部のユーザーやデバイスも証明書を使用する必要があるのかどうかということで変わってきます。 証明書クライアントの定義については、この章で既に説明しています。 ##### ルート CA このソリューションでは、ルート CA は次のように構成されます。 - CDP と AIA のプライマリ パス (最初に示されるパス) は HTTP URL です。 ルート CA の CRL のサイズは通常非常に小さく (1 ～ 2 KB)、公開の間隔が非常に長い (6 か月) ため、CRL を公開する場所を 1 つだけにしても、クライアントがこの CRL を取得する際に大きな制約となることはありません。 - セカンダリ パスは LDAP URL として構成され、HTTP 用の場所にバックアップを作成するために利用されます。 LDAP ホスト名は使用されません。そのため、証明書関連の情報が公開されたフォレストと同じフォレストに属するクライアントは、ローカル ドメイン コントローラからその情報を取得します。 このフォレストに属さないクライアントは、この場所にアクセスできません。 このように構成すると、Active Directory フォレストに属さないクライアントは既定で HTTP パスを使用するようになっているため、この CA および下位の CA の証明書を使用できるようになります。 ##### 発行 CA このソリューションでは、発行 CA は内部の Active Directory クライアントでの使用に合わせて最適化されます。 発行 CA は次のように構成されます。 - CDP と AIA の URL のプライマリ パスは、LDAP ディレクトリ パスです。 - CDP と AIA の URL に LDAP ホスト名は指定されません。そのため、クライアントはそれぞれの既定の LDAP サーバーを使用します。 クライアントが Active Directory クライアントである場合、既定の LDAP サーバーはローカル ドメイン コントローラです。 その他の LDAP クライアントからこれらの LDAP パスに対してクエリを実行すると、失敗することがあります。 この構成は、発行 CA と同じフォレストに属するクライアントに最適です。 Base CRL が毎週発行され、Delta CRL が毎日発行されます。 この 2 つの CRL はいずれも既定の場所が Active Directory のため、クライアントは最も近くにあるドメイン コントローラからこの CRL を取得します。 これにより障害許容力が向上し、ネットワーク トラフィックも最適化されます。 ###### 外部クライアントをサポートするために CDP と AIA を設定する 前のセクションで説明した構成は、別の Active Directory フォレストのメンバであるクライアントや、どの Active Directory フォレストのメンバでもないクライアント (ルーターなど) には最適なものではありません。 このような外部クライアントは LDAP 用の CDP や機関情報アクセス (AIA) にアクセスできないため、外部ユーザーによる失効情報および AIA 情報の確認が大幅に遅れる可能性があります。 このような遅れが原因で、外部ユーザーのアプリケーションに障害が発生する場合もあります。 Active Directory フォレストに属さないクライアントが証明書を使用する可能性がある場合は、LDAP URL ではなく HTTP URL がプライマリ パスとして使用されるように CDP 値と AIA 値を設定する必要があります。 外部クライアントが使用できる LDAP URL を組み込むには、次の手順に従います。 - CDP パスと AIA パスに明示的な LDAP ホスト名を設定します。この場合、既定の null パス (LDAP:///) は使用できません。 CA の CDP パスまたは AIA パスを変更するには、CA 証明書の再発行 (更新) が必要です。 - この章で既に説明した方法で、匿名 LDAP アクセスを有効にします。 ###### インターネット クライアントに関する考慮事項 インターネット上で使用できる証明書を組織外に配布する計画がある場合は、他にも考慮する必要がある事項がいくつかあります。 内部向けの LDAP URL を含む証明書は、内部 Active Directory および内部 CA の構造や名前に関する情報を外部に開示する恐れがあります。 これを回避するには、次のいずれかに従う必要があります。 - ルート CA の CDP 値と AIA 値、および証明書チェーンに含まれている下位 CA に、HTTP URL のみを設定します。 - 外部で使用する証明書は別の CA から発行します。 この CA では、HTTP 用の CDP URL と AIA URL のみを設定します。 どちらの場合も、CRL を取得できる HTTP 用のセカンダリの場所を用意して、プライマリの場所が利用できないときにはこの場所を代わりに使用できるようにする必要があります。 CRL と CDP の使用方法の詳細については、この章の最後にある「関連情報」で紹介されている資料を参照してください。 #### CA インフラストラクチャを拡張する 「証明書のセキュリティ要件を定義する」では、セキュリティ レベルやサブジェクトの種類に基づく証明書の分類について説明しました。 サブジェクトの種類を分類する主な理由として、サブジェクトの種類ごとに別の証明書ポリシーと運用規則 (CPS に記載) が適用される可能性が大きいことが挙げられます。 通常、CPS は CA ごとに適用されます。 それぞれ異なる種類のサブジェクトに適用される複数の異なるポリシーを単一の CA に用意することもできますが、そのようにした場合、CPS が複雑になり正しく実装することが困難になる可能性があります。 ポリシー要件とセキュリティ要件がそれぞれ異なる多様な証明書を発行できるように、このソリューションの PKI を拡張するには、主な種類のサブジェクトに対応する発行 CA を追加で作成します。 これについては、次の図で説明します。 **注 :** この図は、ここで説明してきた CA 階層を拡張する方法を示しているものにすぎません。 実際の組織では、将来のニーズに応じて、これよりも大幅に複雑にしなければならない場合や、もっと簡略にしなければならない場合があります。 追加の CA と証明書機能の設計は、実際のセキュリティ要件に基づいて行う必要があります。PKI の設計では、完全に正しい設計や完全に間違っている設計というものはありません。 PKI の拡張を他の証明書のニーズに対応するという点から考える場合は、この図に概略を示したような単純設計の PKI と同様のアプローチに従ってください。 .gif) **図 4.4: CA 階層を拡張する** [拡大表示する](https://technet.microsoft.com/ja-jp/cc527050.04fig4-4_big(ja-jp,technet.10).gif) この図では、この章で既に説明した単純な CA 階層を拡張して、多様な証明書要件に対応できるようにする方法を示しています。 新しく追加した CA と証明書機能はグレーの背景で表示されています。 この図では、高価値の証明書が使用されていること (鍵と錠前の記号で表示) と、内部ユーザー用および外部ユーザー用の証明書 CA がオンラインになった場合に標準のユーザー証明書を発行する役割を最初の CA から引き継ぐ仕組みについても説明されています。 CA インフラストラクチャを拡張するこの方法では、次のことが想定されています。 - CA インフラストラクチャ管理を一元化します。つまり、部門ごとや地域ごとに CA の制御を委任する必要はありません。 - 共通の証明書規格を組織全体で使用します。つまり、どの種類の証明書にも、組織全体で共通して受け入れられ合意される使用法とポリシーがあります。 - 既存の PKI との相互運用性は必要ありません。 - 上の図に示した証明書 (およびその他の必要な証明書) には、それぞれの種類ごとに別のセキュリティ レベルとポリシーを適用する必要があります。 上記の想定が実際の組織に当てはまらない場合は、ここに示した構造とは異なる構造が必要になることがあります。 CA インフラストラクチャを拡張する場合のさまざまなオプションとアプローチの詳細については、この章の最後で紹介している「Designing a Public Key Infrastructure」(英語) を参照してください。 ##### 限定従属 作成した証明書定義を使用して証明書テンプレートを定義すると、以後はカスタマイズを行わなくても証明書を発行することができます。 ただし、PKI を拡張する際には、CA が発行できる証明書の範囲を制限することもできます。これを行うには、発行 CA の証明書の委任を制限します。 この章で既に説明している限定従属を使用すると、自分の組織の CA インフラストラクチャと外部の組織の CA インフラストラクチャの間で相互証明書を作成して、自分の組織内で信頼の範囲と目的を制御することができます。 これと同じ手法を使用して、自分の組織の CA 階層内で証明書の種類や証明書の一部の属性を制限することもできます。 ここでは、その詳細については説明しません。 詳細については、この章の最後で紹介しているテクニカル ペーパー「*Windows Server 2003 を使用した相互証明および限定従属の計画と実装*」を参照してください。 このソリューションの PKI の場合、CA 階層内で限定従属を使用する必要はありません。 [](#mainsection)[ページのトップへ](#mainsection) ### 証明書プロファイルを構成する ここでは、この章で定義した要件に対応できるように証明書を構成する方法について説明します。 #### 証明書のパラメータを定義する 必要な証明書の種類ごとに、証明書プロファイルを文書に記録する必要があります。 次に、証明書テンプレートにプロファイル パラメータを設定します。このパラメータによって、CA が発行する証明書の種類が指定されます。 **注 :** 証明書テンプレートはスタンドアロン CA では使用されません。 証明書要求を作成するには、Certreq.exe などのツールを使用するか、Web 登録ページ上のフォームを使用するか、またはプログラムにより生成する必要があります。 スタンドアロン CA を使用する場合は、証明書の種類ごとに証明書プロファイルを定義し、スタンドアロン CA に証明書要求を作成する際にそのプロファイルを使用する必要があります。 証明書プロファイルの定義には、次のものがすべて含まれています。 - テンプレート名と表示名 (このための名前付けの基準を定義する必要があります) - 証明書キーの長さ - 証明書の有効期間 - オプションの証明書拡張機能 - 登録と更新のポリシー - 有効期間に関するポリシー - アプリケーションの使用法に関するポリシー - キーの使用法に関するポリシー - キーのアーカイブに関するポリシー - 証明書の承認 - サブジェクト名の作成 - 証明書登録エージェント - キーの作成 - キーと CSP の種類 キーの長さ、有効期間、キーの作成オプション、および登録と認証に関するポリシーはいずれも、この章の前のセクションで特定した、証明書に求められるセキュリティ レベルとアプリケーション要件に応じて決定されます。 #### 証明書とキーの有効期間を定義する 証明書の有効期間は、証明書の種類、組織のセキュリティ要件、業界の標準慣行、政府の規制などの多数の要因の影響を受けます。 一般に、キーが長いほど、証明書の有効期間とキーの有効期間が長くなります。 キーの長さとキーの種類には、次の制限があります。 - 互換性 - 一部の証明書アプリケーションでは、2048 ビットより長いキーはサポートされません。 キーの種類も互換性に影響する可能性があります。一般的には RSA キーが最も互換性に優れていますが、アプリケーションによってはこれ以外の種類のキーが必要になる場合もあります。 証明書アプリケーションは、証明書チェーンに含まれるすべての証明書を処理できる必要があるため、チェーンに含まれるすべての CA に関して、キーの長さとキーの種類の両方の互換性を考慮する必要があります。 - パフォーマンス - 短いキーを使用した場合よりも長いキーを使用した場合の方が、署名処理や暗号化処理を行う際に大きな処理能力が必要になります。 このため、証明書を発行する頻度が高い発行 CA では、一般的に 2048 ビットよりも長いキーを使用しないようにする必要があります。 - 記憶域 - キーが長くなると証明書のサイズが大きくなり、証明書データベース内で必要となる記憶域も増大します。 証明書が Active Directory に公開されている場合には、Active Directory 上で必要となる記憶域も増大します。 バックアップのサイズと時間もこれに比例して増加します。 証明書とキーの有効期間を決定するときには、キーが侵害に対してどの程度脆弱であるか、また侵害された場合もたらされる影響について検討する必要があります。 証明書とキーの有効期間の決定に影響する要因として、次のものがあります。 - 秘密キーの長さ - キーが長くなるほど解読が困難になるため、キーが長い場合はキーの有効期間を長くしても問題ありません。 - CA のセキュリティ - CA とその秘密キーのセキュリティを強化するほど、安全な有効期間は長くなります。 - 専用の暗号化ハードウェアの使用 - スマート カードや HSM を使用すると秘密キーのセキュリティが強化されるため、有効期間を長くしても問題ありません。 - 証明書のサブジェクトの信頼性 - 従業員および内部コンピュータ用の証明書は、外部ユーザーおよび外部コンピュータ用の証明書よりも有効期間を長くすることができます。 - CA キーを使用して署名した証明書の数 - キーの使用回数が増えて CA の公開キーの配布範囲が広がればそれだけ、キーが攻撃を受けたり解読されたりする可能性が大きくなります。 次の表に、このソリューションの CA とエンド エンティティのキーの有効期間と更新期間を示します。 **表 4.10: 証明書とキーの有効期間**

証明書のサブジェクト	キーの長さ	キーの有効期間	更新間隔
ルート CA	4096 ビット	16 年	8 年
発行 CA	2048 ビット	8 年	4 年
エンド エンティティ	1024 ～ 2048 ビット	6 か月～ 2 年	有効期間の 90%

キーの長さに関しては、1024 ビットのキーは現在、暗号解読技術によっては実質上解読できないと考えられています。 このようなキーの場合、上の表でエンド エンティティに対して示されている 2 年という期間よりはるかに長い期間を安全な有効期間とすることができます。 512 ビットのキーは、セキュリティ要件の非常に低い用途で使用する場合を除き、一般的に安全とは考えられていません。 したがって、このソリューションでは 512 ビットのキーは使用しません。 発行 CA のキーの強度はセキュリティ要件とパフォーマンス要件の間の妥協点です。 これと同じサイズ (強度) を持つキーの有効期間は、現在では 4 年という更新期間よりはるかに長いものになっています。 ルート CA の場合、現実的なパフォーマンス上の制限が存在しないため、キーの強度は最大 16 K ビットに設定することができます。 ただし、このソリューションでは、互換性の都合上これよりかなり低いレベルに設定しています。 それでも、4096 ビットのキーの安全な有効期間は、8 年という更新期間よりずっと長いものです。 RSA キーはすべての CA で使用されます。ただし、エンド エンティティのキーの種類は、アプリケーション要件に応じて決まります。 証明書の更新はキーを変更せずに行うことができますが、これは通常の状況下ではお勧めしません。 このソリューションでは、証明書を更新するたびに新しいキーのペアが生成されます。 CA が発行した証明書の有効期間は、発行 CA の残存有効期間およびルートを含めたすべての上位 CA の残存有効期間を超えることはできません。 たとえば、CA の証明書が 6 か月後に期限切れになる場合、その CA では有効期間が 6 か月以内の証明書しか発行できません。 そのため、このソリューションでは、有効期間の半分が経過したときに CA 証明書の更新が行われるようにします。 CA で発行されるどの証明書も、有効期間は、発行 CA の証明書の有効期間の半分以下になります。 この結果、エンド エンティティ、発行 CA、およびルート CA の最大有効期間はそれぞれ 4、8、16 年になり、順に倍増する形になります。 このソリューションでは、エンド エンティティの証明書の最大有効期間が 2 年を超えることはありません。 そのため、この証明書の有効期間の階層に大きな影響を与えることなく、中間 CA 層を追加で導入することが可能です。 #### セキュリティ要件を証明書のパラメータにマップする 次の表は、この章の前のセクションで特定した証明書の種類を挙げ、各種類ごとのセキュリティ カテゴリと証明書プロファイルのパラメータとの対応を示したものです。 **表 4.11: 証明書のパラメータ**

証明書の種類	発行ポリシー	承認方法	キー	有効期間	キー ストレージ	キーのエクスポート	CSP
クライアント認証 - ユーザー	低	自動 (ドメイン認証)	1024	1 年	ソフトウェア	なし	指定
クライアント認証 - コンピュータ	低	自動 (ドメイン認証)	1024	1 年	ソフトウェア	なし	指定
IAS サーバー認証	中	手動 (証明書マネージャ)	1024	1 年	ソフトウェア	なし	指定

**注 :**  「**発行ポリシー**」欄の「低」とは、証明書サービスの定義済みの証明書ポリシーが "低保証" であることを指します。 これは、この章で既に説明した標準保証または標準セキュリティ レベルと同じです。 「**CSP** (暗号化サービス プロバイダ)」欄の「指定」とは、その証明書の種類で許可される CSP をテンプレートで指定して、クライアントでは指定されないようにする必要があることを意味します。 クライアント コンピュータ証明書とサーバー証明書には、CSP に関する明確な要件があります。 #### 証明書の要件を証明書テンプレートのパラメータにマップする アプリケーションでは、多くの場合、証明書が正確に構成されていると想定されます。 サブジェクト名が特定の方式で書式設定されていること、特定のアプリケーション ポリシー OID が含まれていること、および証明書が特定の発行ポリシーに従って発行されていることが必要な場合もあります。 他に要件がない場合も、少なくともキーの使用法が正しく定義されていることが求められます。 アプリケーションの所有者 (またはベンダ) からこれらに対応するパラメータをすべて入手して、証明書プロファイルを定義する必要があります。 次のいくつかの表は、このソリューションに必要な証明書と、対応するアプリケーション要件を示したものです。 それぞれの表には、証明書テンプレートに構成する内容として、証明書のプロパティと CA パラメータの両方が示されています。 使用可能なプロパティがすべて記載されているわけではありません。 **注 :** 次に示す証明書は、それぞれビルトイン テンプレートのいずれかを基にしています。 元のテンプレートを編集するのではなく、ビルトイン テンプレートのコピーを作成し、そのコピーを編集して必要な値を設定してください。 このようにしておくと、元のテンプレートが変更されていないことがわかっているため、必要に応じてテンプレートを元の状態に簡単に戻すことができます。 **表 4.12: クライアント認証 - ユーザー**

証明書のパラメータ	必要な値
証明書テンプレート名	クライアント認証 - ユーザー
Active Directory の公開	なし
キー使用法	デジタル署名
キーのアーカイブ	なし
キーの最小サイズ	1024
サブジェクト名	共通名
サブジェクトの別名	ユーザー プリンシパル名
アプリケーション ポリシー/拡張キー使用法	クライアント認証
暗号化サービス プロバイダ (CSP)	Microsoft Base Cryptographic Provider v1.0 Microsoft Enhanced Cryptographic Provider v1.0
元のテンプレート	認証されたセッション

**表 4.13: クライアント認証 - コンピュータ**

証明書のパラメータ	必要な値
証明書テンプレート名	クライアント認証 - コンピュータ
Active Directory の公開	なし
キー使用法	デジタル署名 キーの暗号化
キーのアーカイブ	なし
キーの最小サイズ	1024
サブジェクト名	共通名
サブジェクトの別名	DNS 名
アプリケーション ポリシー/拡張キー使用法	クライアント認証
暗号化サービス プロバイダ (CSP)	Microsoft RSA SChannel Cryptographic Provider
元のテンプレート	ワークステーション認証

**表 4.14: 802.1X サーバー認証**

証明書のパラメータ	必要な値
証明書テンプレート名	802.1X サーバー認証
Active Directory の公開	なし
キー使用法	デジタル署名 キーの暗号化
キーのアーカイブ	なし
キーの最小サイズ	1024
サブジェクト名	共通名
サブジェクトの別名	DNS 名
アプリケーション ポリシー/拡張キー使用法	サーバー認証
暗号化サービス プロバイダ (CSP)	Microsoft RSA SChannel Cryptographic Provider
元のテンプレート	RAS および IAS サーバー

#### 証明書テンプレートを作成する Windows Server 2003 の Active Directory には、あらかじめ定義された証明書テンプレートのセットが含まれており、一般的な機能を多数使用できるようになっています。 エンタープライズ CA は、インストールした際にこれらのビルトイン証明書の中の数種類が発行されるように、既定で構成されています。 すべてのビルトイン テンプレートについての説明は、Windows Server 2003 Enterprise Edition の製品ドキュメントに記載されています (正確な資料については、この章の最後にある「関連情報」を参照してください)。 このガイドで紹介しているソリューションでは、このような既定のテンプレートのほとんどを CA から削除します。正確に言うと、証明機関管理コンソールのテンプレート フォルダから削除します。ただし、テンプレート定義はディレクトリから削除しないでください。 定義済みテンプレートが組織のニーズを満たす場合は、これを使用してもかまいません。これらのテンプレートは、証明書ベースの Windows アプリケーション (暗号化ファイル システム、VPN 認証など) の大部分に対応しています。 その他の種類の証明書を発行する必要がある場合は、通常は、組織の要件に合わせて調整したテンプレートを作成した方がよい結果が得られます。 その機能をよく理解せずに定義済みテンプレートを使用すると、意図しなかった機能を有効にしてしまう危険性があります。 たとえば、コンピュータ証明書は単純なクライアント認証を目的とした証明書ですが、Web サーバー証明書としても使用できます。 新しいテンプレートを作成するには、証明書プロファイルの要件を満たす定義済みテンプレートを見つけ、そのテンプレートのコピーを作成して、これをベースに新しいテンプレートを作成します。 テンプレートの構成は、このセクションで定義した証明書プロファイルに対応する属性を選択するだけの単純な作業です。 **注 :** 新しいテンプレートを何も利用せずに最初から作成することはできません。既存のテンプレートのコピーを作成し、それに必要な変更を加えてください。 また、コンピュータ テンプレートはコンピュータ テンプレートから、ユーザー テンプレートはユーザー テンプレートから作成する必要があり、この 2 つを取り替えることはできません。 テンプレートを作成したり修正したときは、構成管理システムにテンプレート パラメータの詳細情報を記録しておく必要があります。 [](#mainsection)[ページのトップへ](#mainsection) ### 証明書管理計画を作成する 組織で使用する証明書を構成したら、その有効期間を通じて証明書を管理するための計画を作成する必要があります。 証明書管理計画の作成では、次の事項について決定する必要があります。 - 新規証明書および証明書更新の要求を行う方法 - 証明書をユーザー アカウントにマッピングする方法 - CRL の管理と配布を行う方法 - 暗号化されたデータの復元に使用する方針 #### 登録方法と更新方法を選択する 証明書を登録するには、いくつかの異なる方法を使用できます。使用できる方法は次のとおりです (次の方法はすべて、証明書の更新にも使用できます)。 - Windows 自動登録 - 証明書の登録ウィザード (通常は、証明書管理コンソールから起動) を使用したオンライン登録 - アプリケーションまたはスクリプトから CryptoAPI または CAPICOM インターフェイスを使用して行うオンライン登録 - Certreq.exe ツールを使用した要求の作成と送信ならびに発行された証明書の取得 **注 :** 上記の 4 つの方法は、それぞれ異なるインターフェイスを使用していますが、最終的につながるオンライン登録インターフェイスは同じです。 - Web ページ登録 - 手動のオフライン登録 (上述の方法のいずれかを使用して行う要求ファイルの生成、CA への取り込み、証明機関管理コンソールを使用した要求の送信、管理コンソールを使用した要求の取得を含む) 上記の方法はすべて、状況に応じて有効かつ適切に使用できます。 このソリューションでは、次の登録方法を使用します。 - Windows 自動登録。 可能な場合は、証明書管理の負担が減るという点でこの方法の使用をお勧めします。 自動登録は、手動の承認を必要とする証明書にも使用できます (ただし、登録エージェントの署名が必要な場合は別です)。 証明書は即座に発行されませんが、要求が CA に送信され、承認されたあとに登録が完了します。 - 手動のオフライン登録。 この方法は、ルート CA ですべての証明書の登録と更新を行う場合に使用します。 これらの方法はいずれも、より複雑なシナリオ (たとえば、証明書要求が CA に送信される前に第三者による署名を必要とするなど) には適切ではありません。 また、RPC ベースのオンライン登録も、Windows 以外のプラットフォーム (ルーターなど) ではほとんどサポートされていません。 証明書要求でサブジェクト名またはサブジェクトの別名を定義する必要がある場合 (Active Directory で生成するのではない場合) も、自動登録はできません。 このようなより高度な要件に対応するには、次のいずれかの方法を検討する必要があります。 - CAPICOM スクリプトを作成してスタンドアロンのクライアント コンピュータ上で (たとえば、ログイン スクリプトの一部として) 実行します。 - コマンド プロンプトから、またはバッチ ファイルで certreq.exe を実行することにより、要求を生成して送信し、発行された証明書を取得してインストールします。 - CAPICOM を使用して、要求の作成と送信を行うカスタム Web ページ (ASP または Microsoft ASP.NET) を作成します。 この最後の方法では、幅広いクライアントに対して登録サービスを提供したり、複数の段階からなる高度なプロセス (要求を承認するために複数の署名を必要とするプロセスなど) を組み込んだりすることができます。 #### 証明書を識別情報にマッピングする 証明書と証明書に指定されたサブジェクトとのマッピングについては、説明が長くなるため、この章では扱いません。 ただし、この問題に関して検討が必要な重要事項を 2 つ、ここに挙げておきます。 - 証明書を発行する前に、証明書のサブジェクトの身元を確認する方法 - ディレクトリが提供する情報の中から、証明書のサブジェクトの識別情報を見つける方法 1 つ目は、証明書の登録処理方法に関連した問題です。 これについては、次のセクション「証明書ポリシーを作成する」で説明します。 2 つ目は、証明書のユーザー (アプリケーションやサービス) が、証明書のサブジェクトの識別情報を他の使用できる識別情報に正しくマッピングする方法に関連した問題です。 後者の例を次に示します。 - ドメイン コントローラが、ユーザーをドメインにログオンさせたり、アクセス トークンを生成したりするために、ユーザーのスマート カード証明書からユーザーを特定する方法 - 電子メール ユーザーが、セキュリティで保護された電子メールの送信先とするユーザーの証明書を見つける方法 証明書のほとんどは、登録プロセスの中で Active Directory のセキュリティ プリンシパル (ユーザーとコンピュータ) に自動的にマッピングされます。 Active Directory により証明書のサブジェクト名およびサブジェクトの別名が定義され、証明書と証明書に指定されたセキュリティ プリンシパルの間に暗黙のマッピングが作成されます。 サブジェクトの別名には、ユーザーの場合は UPN または電子メール名、コンピュータやコンピュータ プロセスの場合はサービス プリンシパル名 (SPN) または DNS ホスト名などが含まれます。 UPN 値と SPN 値は、Active Directory フォレスト内では一意の値です。 電子メールと DNS 名はグローバルに一意である必要がありますが、これは Active Directory によって強制的に行われるわけではありません。 IIS や IAS などその他の Windows サービスでは、ユーザーまたはコンピュータの識別情報への証明書マッピングも実行されます。 **注 :** 証明書マッピングは、証明書の公開とは関係ありません。 証明書マッピングとは、証明書の特定の属性 (通常はサブジェクトの別名) によってディレクトリ内のオブジェクトを 1 つ、一意に特定することです。 IAS サーバーではこの仕組みによって、提示された証明書からユーザーまたはコンピュータの身元を判断します。 IAS では、ディレクトリ内で証明書を検索するのではなく、このような暗黙のマッピングを利用します。 証明書の公開とその結果行われる証明書の検索では、ディレクトリ内の証明書が実際に格納されている場所が、ユーザー オブジェクトまたはコンピュータ オブジェクトの属性として示されます。 ユーザーは、ディレクトリ内の特定の人物を検索し、その人物に属する証明書を取得することができます。 \[Active Directory ユーザーとコンピュータ\] 管理コンソールを使用すると、他の証明書を手動でユーザー オブジェクトまたはコンピュータ オブジェクトにインポートしてマッピングすることも可能です。 逆に、次の例のように、ディレクトリ オブジェクトに直接マッピングする必要がない場合も数多くあります。 - 主な識別子が Web サイトの DNS ホスト名である Web サーバー - 証明書が、対応する Active Directory オブジェクトのないエンティティに対して発行されている場合 (たとえば、ルーターや他の組織から来たユーザーなど) このガイドのソリューションでは、エンド エンティティはすべて、Active Directory ユーザーまたは Active Directory コンピュータに直接 (かつ暗黙的に) マッピングされています。 CA は、必ずしもコンピュータ オブジェクトにマッピングされている必要がないという、特殊なケースです。 ただし、CA もほとんどの場合、Active Directory AIA および信頼された証明機関コンテナ内の証明機関オブジェクトに常にマッピングされています。 #### 証明書ポリシーを作成する 証明書の承認方法は、少なくとも各証明書セキュリティ カテゴリ (高、中、標準) ごとに定義する必要があります。マイクロソフトでは、証明書のサブジェクト カテゴリ (コンピュータ、内部ユーザー、外部ユーザー) ごとに定義することもお勧めしています。 これより細かいレベルでポリシーを定義する必要が生じることはほとんどありません。 これらのポリシー決定事項は、証明書ポリシー ステートメントと CPS の記載事項の一部として文書化してください。 さまざまな証明書ポリシーによって、証明書の登録で使用される証明書承認プロセスと秘密キーのセキュリティ レベルが示されます。 OID を使用してこれらを証明書にエンコードし、さまざまなポリシーを表すことができます (必須ではありません)。 厳密な承認プロセスは、発行される証明書の価値に反映されます。 承認プロセス (または登録プロセス) の目的は、証明書の要求者が証明書のサブジェクトと同一エンティティであることを適切な信頼レベルで保証することです。 キーのセキュリティ強度は、秘密キーの秘密が守られることに対する、また証明書のサブジェクトを専有していることに対するユーザーの信頼度の指標となります。 このソリューションで使用する証明書の保証レベルは、この章の「証明書のセキュリティ要件を定義する」で既に定義しています。 自分が発行した証明書の保証レベルは、その保証レベルに対応した証明書ポリシー OID を証明書に含めることによって提示できます。 アプリケーション (およびユーザー) は、特定の証明書がどの程度信頼できるかを証明書ポリシーにより判断できます。 前のセクションで定義した 3 つの保証レベルは、Windows Server 2003 の定義済みの 3 つの証明書ポリシー (証明書テンプレート MMC の発行ポリシーと同義) に対応しています。 次の表は、このソリューションでそれぞれの証明書ポリシーが使用される方法を詳細に示したものです。 少なくとも中または高保証の証明書の証明書テンプレートにポリシー OID を含めると、保証の高い証明書を容易に見分けることができます。 証明書ポリシーを持たない証明書は、標準保証と見なされます。 **表 4.15: 証明書発行ポリシーのレベル**

証明書 (発行) ポリシー	登録要件	キー ストレージの最小要件
低 (標準)	正常なドメイン認証に依存する自動承認。 スタンドアロン CA の場合、これは認証されない承認のレベルです。つまり、CA は要求元に関するチェックを何も行わずに (または最小限のチェックで) 証明書を発行します。	ソフトウェア キー
中	証明書マネージャによる承認。 証明書要求を承認する前に証明書マネージャが行うチェックの種類について、ポリシーの中で定義する必要があります。	ソフトウェア キーまたはハードウェア キー。 ソフトウェア キーを使用する場合は、強力なキー保護の使用を検討してください。ただし、アプリケーションで使用できない場合は別です (たとえば、コンピュータ証明書は強力なキー保護を使用できません)。
高	候補にされた登録担当者の署名と証明書マネージャの承認。 要求が承認される前に登録担当者と証明書マネージャが行うチェックの種類について、定義する必要があります。	耐タンパー性のハードウェア トークン。 たとえば、ユーザー用のスマート カードまたはユニバーサル シリアル バス (USB) 暗号化トークン、コンピュータ用の HSM など。

注 : 組織の要件に応じて、証明書ポリシーおよび保証レベルの定義を変更して、レベルを高くしたり低くしたりすることができます。

証明書失効ポリシーを定義する

状況によっては、有効期限が切れる前に証明書を無効にしなければならない場合もあります。 証明書を失効させるためのポリシーを作成するには、次の作業を行います。

• 証明書失効の正当な理由となる条件を定義します。

• CRL の公開場所を選択します。

• 使用する予定の CRL の種類を 1 つまたは複数選択します。

• CRL の公開スケジュールを作成します。

証明書ポリシーの一部には、証明書失効の正当な理由となる条件の定義が含まれます。 失効の条件は、証明書の種類によって変わる場合があり、さらに保証レベルやサブジェクトの種類、CA が異なると、ほとんどの場合失効条件は変わります。

証明書を失効させる際の失効理由コードの使用方法についても、文書化する必要があります。 次の表では、それぞれの理由コードについて説明しています。

表 4.16: 証明書の失効コード

理由コード	説明
キー侵害	証明書の秘密キーが危害を受けました (または、危害を受けた疑いがあります)。
CA 侵害	CA の秘密キーが危害を受けました (または、危害を受けた疑いがあります)。
認証の情報が変更 (危害なし)	サブジェクトが別の組織に移動しました。
廃棄	この証明書に代わる新しい証明書が発行されました。
利用中止	CA の運用が中止されました。
一時中止	証明書の使用を一時的に停止する必要があります (たとえば、ユーザーがスマート カードを置き忘れ、なくなったかどうかが確かでない場合)。
指定なし	該当する理由コードがありません。

**重要 :** 理由コードの "一時中止" は、完全に正当な状況でなければ使用しないでください。 証明書の一時中止を行ったあとに中止を解除すると、ある特定の時点の証明書の失効状態を確認することがほとんど不可能になります (つまり、その証明書による署名の有効性を確認できなくなります)。 失効手続きの一部として、次の質問に対する答えを確実に文書化しておくことをお勧めします。 これらは通常、変更管理ログまたはインシデント管理ログに記録します。 - この証明書の失効理由は何か。 - この証明書の失効を要求したのは誰か。 - この証明書は再び必要になるか (署名の確認、メッセージの解読など)。 その場合、その必要性は何か (署名の確認、メッセージの解読、通常利用など)。 - 管理者として、証明書を失効させる担当者に義務付ける特別な要件はあるか (失効の担当者は証明書マネージャでなければならないなど)。 - 証明書を失効させるときに使用する、組織内で文書化された操作手順 (バックアップなど) があるか。 証明書の失効を左右する技術的なパラメータも多数あります。 これらについても CA ポリシーの一部として文書化しておくことをお勧めします。 次の表では、このソリューションのルート CA および発行 CA に関するパラメータを示します。 **表 4.17: ルート CA の証明書失効パラメータ**

パラメータ	選択値	理由
CRL 公開場所 (CDP)	内部 Web サーバーへの HTTP パス	Web サーバーに公開されると、LDAP の場所へのバックアップが可能になり、非 LDAP クライアントが CRL にアクセスできるようになります。
	Active Directory CDP コンテナへの LDAP パス	すべてのドメイン コントローラに公開されると、すべてのドメイン ユーザーが容易にローカル アクセスできるようになります。
CRL の種類	Base CRL のみ	発行される証明書の数が少ないため、Delta CRL を使用する利点がありません。
公開スケジュール	6 か月	これにより発行 CA の証明書の失効が困難になるため、発行 CA のセキュリティにおける信頼が必要になります。 しかし、このように期間を長くすると、ルート CA の管理は最小限に保たれます。
CRL 重複期間 (新しい CRL が公開されてから古い CRL の期限が切れるまでの期間)	10 日	これにより、ルート CA から新しい CRL を取得する際にある程度のエラーが許されるようになります。

**表 4.18: 発行 CA の証明書失効パラメータ**

パラメータ	選択値	理由
CRL 公開場所 (CDP)	Active Directory CDP コンテナへの LDAP パス (Base CRL と Delta CRL の両方)	すべてのドメイン コントローラに公開されると、すべてのドメイン ユーザーが容易にローカル アクセスできるようになります。 (Active Directory への Delta CRL の公開については、後述の注を参照)
	内部 Web サーバーへの HTTP パス	Web サーバーに公開されると、LDAP の場所へのバックアップが可能になり、非 LDAP クライアントが CRL にアクセスできるようになります。
CRL の種類	Base CRL Delta CRL	Delta CRL は、失効情報が公開されるまでの遅延を比較的短くしつつ、CRL 取得トラフィックを最適化するのに有用です。
公開スケジュール	Base CRL - 7 日	Delta CRLを認識しないシステムでも比較的新しい失効情報を取得できるようにするために、この間隔は十分確保する必要があります。
	Delta CRL - 1 日	Delta CRL を使用できる最近のクライアントは、これによって失効の遅延を比較的小さくできます。
Base CRL 重複期間 (新しい CRL が公開されてから古い CRL の期限が切れるまでの期間)	4 日	これにより、Base CA をスケジュールどおりに公開できない場合、CA の復元にある程度のエラーが許されるようになります。 4 日という期間は、週末に祭日が重なる金曜日の夜に CA に障害が発生して、次の火曜日まで誰も気づかないという最悪のケースを想定して選択されたものです。
Delta CRL 重複期間	1 日	Delta CRL のサービスはそれほど重要ではないため、Delta CRL の公開に失敗しても最悪の事態にはなりません。 このパラメータは、重複期間が Active Directory のレプリケーションの潜在期間より大きくなるように設定されています。

**注 :** 有効期間が比較的短い (1 日) Delta CRL を使用しているため、Active Directory のレプリケーションの最大待ち時間は、Delta CRL の公開期間の 50% より確実に短くする必要があります。 そうしないと、証明書クライアントが古い失効情報を使用することにつながるだけでなく、ネットワーク帯域幅の制限されたサイトへのディレクトリ レプリケーション トラフィックに悪影響を及ぼす可能性も出てきます。 Delta CRL の重複期間は、ディレクトリ情報をフォレスト全体にレプリケートするのに要する最大時間よりも長い値に設定してください。 Active Directory の潜在期間がこれより長いか、または余分なディレクトリ レプリケーション トラフィックの発生を望まない場合は、Delta CRL の公開期間を長くするか、Delta CRL のディレクトリへの公開を避ける必要があります。 Delta CRL の場所を変更する場合は、新しい Base CRL を発行する必要があります。 レプリケーションの潜在期間は、LDAP URL ではなく HTTP の場所を使用して Delta CRL を公開する場合は、通常それほど問題にはなりません。 #### キーとデータの復元を計画する キー復元とデータ復元は、このソリューションには含まれません。 このいずれかまたは両方を必要とする場合は、データ損失を避け、不注意による暗号化データの開示を防ぐため、慎重に計画を立てて管理する必要があります。 詳細については、「*Windows Server 2003 Deployment Kit*」の「Planning for Data Recovery and Key Recovery」および「Designing a Public Key Infrastructure」(英語)、ならびにマイクロソフトのテクニカル ペーパー「Windows Server 2003 でのキーのアーカイブと管理」を参照してください。 [](#mainsection)[ページのトップへ](#mainsection) ### 要約 この章では、セキュリティ保護されたワイヤレス LAN (WLAN) の公開キー基盤 (PKI) を設計するプロセスについて説明しました。 このガイドで詳しく紹介している PKI は、将来多くの組織で別のさまざまな用途にも使用されることを前提とし、そのことを念頭に置いたうえで設計されています。 この章で説明した設計は、将来発生する幅広い要件に対応して拡張できる十分な柔軟性を備えています。 ここに記載された内容を参考にすれば、WLAN アプリケーションで必要とされるよりもはるかに厳しいセキュリティ条件を満たすことができる安全な PKI を設計することができます。 この章で説明した設計上の決定事項は、構築ガイドおよび運用ガイドで PKI の実装に使用されます。 これについては、このソリューション ガイドの第 7 章から第 11 章で詳しく説明されています。 この設計ガイドの残りの章では、このソリューションの別のコア コンポーネントである RADIUS インフラストラクチャ (IAS で実装) および WLAN セキュリティ インフラストラクチャの設計について説明します。 #### 関連情報 以下の資料には、この章で説明したさまざまなトピックに関する詳細な背景情報やその他の関連情報が記載されています。 - 「*Windows Server 2003 Deployment Kit*」の「[Designing a Public Key Infrastructure](https://go.microsoft.com/fwlink/?linkid=4735)」https://go.microsoft.com/fwlink/?LinkId=4735 (英語) - Windows 2000 の PKI の概念の概要および証明書サービスの使用については、「[*Windows 2000 の公開キー基盤の概要*](https://www.microsoft.com/japan/technet/prodtechnol/windows2000serv/evaluate/featfunc/pkiintro.mspx)」https://www.microsoft.com/japan/technet/prodtechnol/windows2000serv/evaluate/featfunc/pkiintro.mspx を参照してください。 - Windows Server 2003 および Windows XP の PKI において拡張された PKI 機能の詳細については、「[*Windows XP Professional と Windows Server 2003 の PKI 拡張機能*](https://www.microsoft.com/japan/technet/prodtechnol/winxppro/plan/pkienh.mspx)」https://www.microsoft.com/japan/technet/prodtechnol/winxppro/plan/pkienh.mspx を参照してください。 - Windows Server 2003 の [Public Key Infrastructure (PKI)](https://www.microsoft.com/windowsserver2003/technologies/pki/default.mspx) に関する製品ドキュメントでは、証明書サービスの主要概念と管理作業について説明されています。https://www.microsoft.com/windowsserver2003/technologies/pki/default.mspx (英語) を参照してください。 - CPS (Certificate Practice Statement) の作成方法については、IETF Web サイトの RFC2527「[*Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework*](https://www.ietf.org/rfc/rfc2527.txt)」https://www.ietf.org/rfc/rfc2527.txt (英語) を参照してください。 - CPS の例については、VeriSign Web サイトの「[VeriSign Certification Practice Statement (CPS)](https://www.verisign.com/repository/cps/)」ページ https://www.verisign.com/repository/CPS/ (英語) を参照してください。 - 証明書ポリシーの OID および CPS の URL を証明書にエンコードする方法については、IETF Web サイトの RFC 3280「[*Internet X.509 Public Key Infrastructure Certificate and CRL Profile*](https://www.ietf.org/rfc/rfc3280.txt)」https://www.ietf.org/rfc/rfc3280.txt (英語) を参照してください。 - 限定従属の詳細については、テクニカル ペーパー「[*Windows Server 2003 を使用した相互証明および限定従属の計画と実装*](https://www.microsoft.com/japan/technet/prodtechnol/windowsserver2003/technologies/security/ws03qswp.mspx)」https://www.microsoft.com/japan/technet/prodtechnol/windowsserver2003/technologies/security/ws03qswp.mspx を参照してください。 - エンタープライズ CA とスタンドアロン CA の違いについては、証明書サービスに関する製品ドキュメントの「[Certificates and certification authorities](https://technet.microsoft.com/ja-jp/library/cc738346.aspx)」セクション https://technet2.microsoft.com/windowsserver/en/library/4ee4fe7e-136f-43fd-8bd3-f3d9766d82c91033.mspx (英語) を参照してください。 - Windows Server 2003 で匿名 LDAP アクセスを有効にする方法については、マイクロソフト サポート技術情報 Q326690「[Windows Server 2003 のドメイン コントローラでは Active Directory に対する匿名の LDAP 操作が無効になっている](https://support.microsoft.com/default.aspx?scid=326690)」https://support.microsoft.com/default.aspx?scid=326690 を参照してください。 - 証明書失効の詳細については、「[*Troubleshooting Certificate Status and Revocation*](https://www.microsoft.com/technet/prodtechnol/winxppro/support/tshtcrl.mspx)」https://www.microsoft.com/technet/prodtechnol/winxppro/support/tshtcrl.mspx (英語) を参照してください。 特に CDP 拡張機能に関するセクションが、この章の内容と関連しています。 - 証明書サービスの Web 登録ページのインストールおよび使用方法の詳細については、マイクロソフトの Web サイトの「[Windows Server 2003 の製品ドキュメント](https://www.microsoft.com/japan/windowsserver2003/proddoc/default.mspx)」ページ https://www.microsoft.com/japan/windowsserver2003/proddoc/default.mspx を参照し、"セキュリティ"、"公開キー基盤"、"証明書サービス"、"方法"、"証明機関のセットアップ" などの単語で検索してください。 - 証明書テンプレートの詳細については、「[*Windows Server 2003 での証明書テンプレートの実装および管理*](https://www.microsoft.com/japan/technet/prodtechnol/windowsserver2003/technologies/security/ws03crtm.mspx)」https://www.microsoft.com/japan/technet/prodtechnol/windowsserver2003/technologies/security/ws03crtm.mspx を参照してください。 - すべてのビルトイン証明書テンプレートの詳細については、Windows Server 2003 TechCenter の「[Troubleshooting](https://www.microsoft.com/technet/prodtechnol/windowsserver2003/troubleshooting/default.mspx)」セクション https://www.microsoft.com/technet/prodtechnol/windowsserver2003/troubleshooting/default.mspx にある Windows Server 2003 の製品ドキュメントを参照してください (英語)。 - 証明書の自動登録に関する詳細については、「[*Certificate Autoenrollment in Windows Server 2003*](https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/autoenro.mspx)」https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/autoenro.mspx (英語) を参照してください。 - Windows Server 2003 でのキーのアーカイブと管理の詳細については、「[*Windows Server 2003 でのキーのアーカイブと管理*](https://www.microsoft.com/japan/technet/prodtechnol/windowsserver2003/technologies/security/kyacws03.mspx)」https://www.microsoft.com/japan/technet/prodtechnol/windowsserver2003/technologies/security/kyacws03.mspx を参照してください。 - 証明書登録の高度なシナリオの詳細については、「[*Advanced Certificate Enrollment and Management*](https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/advcert.mspx)」https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/advcert.mspx (英語) を参照してください。 - Web 登録ページを使用した証明書登録の詳細については、「[*Windows 2000 および Windows Server 2003 証明書サービス Web 登録の構成とトラブルシューティング*](https://www.microsoft.com/japan/technet/prodtechnol/windowsserver2003/technologies/security/webenroll.mspx)」https://www.microsoft.com/japan/technet/prodtechnol/windowsserver2003/technologies/security/webenroll.mspx を参照してください。 - Windows Server 2003 PKI の実装の詳細については、「[Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure](https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws3pkibp.mspx)」https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws3pkibp.mspx (英語) を参照してください。 - その他の実装に関する情報については、「Microsoft Systems Architecture version 2.0 Implementation Guide」を参照してください。このマニュアルは、Microsoft Technet Web サイトの「[Windows Server System Reference Architecture](https://www.microsoft.com/resources/documentation/msa/2/all/solution/en-us/msa20ik/vmhtm1.mspx)」ページ https://www.microsoft.com/resources/documentation/msa/2/all/solution/en-us/msa20ik/vmhtm1.mspx からダウンロードできます (英語)。 [](#mainsection)[ページのトップへ](#mainsection) ##### 目次 - [概要](https://technet.microsoft.com/ja-jp/library/30f90d1c-7faa-432f-b6c8-d4927fe36229(v=TechNet.10)) - [ソリューションの概要](https://technet.microsoft.com/ja-jp/library/30b42da7-6df7-4c17-8f81-e3129a989221(v=TechNet.10)) - [第 1 章 : ソリューションの概要](https://technet.microsoft.com/ja-jp/library/178db46c-9580-45ec-8ca8-565f7eec6521(v=TechNet.10)) - [設計ガイドの概要](https://technet.microsoft.com/ja-jp/library/e6114a19-d2e2-4f4f-9354-9a973b9e3221(v=TechNet.10)) - [第 2 章 : セキュリティで保護されたワイヤレス LAN ネットワークの構築方針を決定する](https://technet.microsoft.com/ja-jp/library/798406d6-d739-4d18-879b-9ae061fa320a(v=TechNet.10)) - [第 3 章 : セキュリティ保護されたワイヤレス LAN ソリューション アーキテクチャ](https://technet.microsoft.com/ja-jp/library/40ad9fbf-71fc-4ade-af08-905a35ae95e8(v=TechNet.10)) - 第 4 章 : 公開キー基盤を設計する - [第 5 章 : ワイヤレス LAN のセキュリティに対応した RADIUS インフラストラクチャを設計する](https://technet.microsoft.com/ja-jp/library/e3e593bb-1c1d-40ad-97fc-3798b6869f18(v=TechNet.10)) - [第 6 章 : 802.1X を使用してワイヤレス LAN のセキュリティを設計する](https://technet.microsoft.com/ja-jp/library/75fadbd9-af34-4322-96ad-c609aaaa5907(v=TechNet.10)) - [構築ガイドの概要](https://technet.microsoft.com/ja-jp/library/2b673333-12a3-4bac-affe-207d148e68a0(v=TechNet.10)) - [第 7 章 : 公開キー基盤を実装する](https://technet.microsoft.com/ja-jp/library/70a59275-e4e0-4849-af0e-1af643e7b8fe(v=TechNet.10)) - [第 8 章 : RADIUS インフラストラクチャを実装する](https://technet.microsoft.com/ja-jp/library/83bbb839-cc8d-4724-affb-a6ae08237f29(v=TechNet.10)) - [運用ガイドの概要](https://technet.microsoft.com/ja-jp/library/9519ea6d-b101-4981-b836-1168f32c7f1f(v=TechNet.10)) - [第 9 章 : ワイヤレス LAN のセキュリティに対応したインフラストラクチャを実装する](https://technet.microsoft.com/ja-jp/library/cc527040.aspx) - [第 10 章 : 運用ガイドの紹介](https://technet.microsoft.com/ja-jp/library/75d535e0-e9ed-454c-98ec-2ed53ce54d52(v=TechNet.10)) - [第 11 章 : 公開キー基盤を管理する](https://technet.microsoft.com/ja-jp/library/9437df75-a375-40f2-9577-17755eec9545(v=TechNet.10)) - [第 12 章 : RADIUS およびワイヤレス LAN のセキュリティ インフラストラクチャを管理する](https://technet.microsoft.com/ja-jp/library/56beab30-3f67-4633-9074-f5f85241b1ab(v=TechNet.10)) - [テスト ガイドの概要](https://technet.microsoft.com/ja-jp/library/7e4b9c88-3b35-41f8-b81d-9546743da068(v=TechNet.10)) - [第 13 章 : テスト ガイド](https://technet.microsoft.com/ja-jp/library/4d249b34-b07e-46af-b8c7-e2ab85f0c26e(v=TechNet.10)) - [付録](https://technet.microsoft.com/ja-jp/library/c60be0d8-d416-41bd-b173-23bdcf56bcf0(v=TechNet.10)) - [付録 A: Windows のバージョン サポート表](https://technet.microsoft.com/ja-jp/library/d55ba82b-f689-4e8a-bddd-37ab55d9f4f1(v=TechNet.10)) - [付録 B: スクリプトとサポート ファイル](https://technet.microsoft.com/ja-jp/library/ecfc00f9-d0a2-44b0-b92e-73d714462bbe(v=TechNet.10)) - [付録 C: 配信ガイド](https://technet.microsoft.com/ja-jp/library/7fdf9700-34db-4b0f-92d1-f6a6d8dbe5e1(v=TechNet.10)) - [付録 D: WPA のサポート](https://technet.microsoft.com/ja-jp/library/cc527037.aspx) [](#mainsection)[ページのトップへ](#mainsection)