公開日: 2006年12月25日
ダウンロード
『Get the Secure Wireless Access Point Configuration』(英語) をダウンロードする
トピック
はじめに
この文書は、中規模ビジネス セキュリティ ガイダンスの一部として提供されています。 Microsoft は、次の情報を得ることでさらにセキュリティが強化され、より生産性の高いコンピュータ環境が皆様の組織で実現されることを望んでいます。
要点
ワイヤレス ローカル エリア ネットワーク (WLAN) は、ビジネスの分野において論議の対象となってきました。多くの企業では、既に何らかの形で WLAN を導入しているか、少なくともワイヤレス技術の導入の是非が議論されています。 どちらにしても、ワイヤレス ネットワークを導入している企業においては、そのソリューションのセキュリティ面に不安があることが多く、一方で、ワイヤレス技術を導入していない企業は、生産性の低さや節減できるインフラストラクチャのコストについての懸案項目を抱えたままです。
また、IEEE 802.11 WLAN セキュリティ プロトコルの第一世代で、よく知られているセキュリティの欠陥が見つかったため、技術を導入する決定権を持つ多くの人が、過去におけるワイヤレス技術のセキュリティだけでなく、今日もワイヤレス技術に残るセキュリティの欠陥にも不安を抱いているのは、自然なことと言えます。 長年にわたって数々の回避策が講じられてきましたが、それらのワイヤレスのセキュリティ問題に対する主なソリューションは、非常に高額であるか、そのソリューション自身に欠陥がありました。
多くの開発が行われ、初期のワイヤレス ネットワークとその技術は成熟し、高速でより安定した環境を提供できるようになりました。ワイヤレス通信をセキュリティで保護するいくつかの標準も確立されました。 最新のワイヤレス セキュリティ プロトコルの IEEE 802.11i 標準をベースにした WPA と WPA2 によって、最も過酷なセキュリティ環境においても、ワイヤレス トラフィックを強力に保護できるようになりました。 これらの現在の標準が適切に設定されていれば、中規模のビジネス環境で、より安全で、信頼性の高いワイヤレス環境を保つことができます。
概要
この文書は主に 4 つのセクションで構成されています。それぞれのセクションは、中規模のビジネスにおけるワイヤレス ネットワークのセキュリティ強化に必要な効果的なソリューションの設計と導入に必要とされる詳細情報に重点を置いています。 次のセクションに分かれています。
- はじめに。 このセクションでは、この文書の大まかな概要と対象となる読者の説明に加え、この文書の要点について述べます。
- 定義。 このセクションでは、この文書で使用されている専門用語の理解を深めるために、その詳細と定義について説明します。
- 課題。 このセクションでは、中規模のビジネスがワイヤレス ネットワークについて検討する際に、対応する必要のあるいくつかの共通の課題について説明します。また、この文書で取り上げるソリューションの背景についても説明します。
- ソリューション。 このセクションでは、セキュリティ保護されたワイヤレス インフラストラクチャの計画、開発、導入、サポートに必要なガイダンスを段階的に詳細にわたって説明します。 ソリューションについてのセクションは、さらに次の 3 つのサブセクションに分かれています。
- WLAN セキュリティの評価。 このセクションでは、ソリューションの計画を開発する上で、基礎となる必須の情報と、採用できる選択肢を説明します。
- セキュリティ保護された WLAN ソリューションの開発。 このセクションでは、評価段階で習得した知識を活用して、ソリューションの基礎を決定し、計画を立て、導入を実施します。
- 展開と管理。 このセクションでは、この文書で概要を示している、セキュリティ保護されたワイヤレス ネットワーク ソリューションの管理と検証をサポートする情報と共に、実際のソリューションを、詳細に、段階的に説明します。
対象読者
この文書の対象となる読者は、中規模のビジネスで、セキュリティ保護されたワイヤレス インフラストラクチャの実現のために、Wi-Fi Protected Access (WPA) または Wi-Fi Protected Access 2 (WPA2) の導入を検討している、技術スタッフ、技術の導入担当者、および技術管理者です。 この文書は、読者がワイヤレス デバイス、基本的なネットワーク概念、Microsoft® Windows Server™ 2003、インターネット認証サービス (IAS)、証明書サービス、Active Directory® ディレクトリ サービス、およびグループ ポリシーの設定とアプリケーションに関する一般的な技術的知識を持っていることを前提としています。
定義
読者は、この文書で使われている専門用語および概念について理解または精通している必要があります。
AES。 Advanced Encryption Standard (AES) は、対称ブロック データ暗号化技術を採用しており、WPA2 に含まれています。
EAP。 拡張認証プロトコル (EAP) は、802.1X 標準です。これにより、開発者は RADIUS サーバーとワイヤレス アクセス ポイント間で認証データをパスすることができます。 EAP には、 EAP MD5、EAP-TLS、EAP-TTLS、LEAP、PEAP などのさまざまな種類があります。
EAP-TLS。 EAP Transport Layer Security (EAP-TLS) は、802.1X 標準に基づき、マイクロソフトが開発しました。認証にデジタル証明書を使用し、現在は、802.11i 認証の業界標準になっています。
IEEE 802.1X。IEEE 802.1X は、サプリカント (クライアント)、認証システム (ワイヤレス アクセス ポイント)、および認証サーバー (RADIUS) 間の EAP カプセル化処理を制御しています
IEEE 802.11。IEEE 802.11 標準には、無線ネットワーク通信を制御し、2.4 GHz の帯域で 20+ Mbps のトラフィックを提供する 802.11g 標準から WPA2 暗号化と認証を制御する 802.11i 標準まで、さまざまな仕様が含まれています。
IEEE 802.11i。IEEE 802.11 から IEEE 802.11i 標準に加えられた変更は、元の認証プロセスをセキュリティ保護するために (EAP)、AES のブロック暗号を活用するセキュリティの手法 (WAP2) を指定するようになった点です。これにより、ワイヤレス セキュリティ標準および仕様に以前存在していた欠陥が補われます。
MS-CHAP v2。マイクロソフト チャレンジ ハンドシェイク認証プロトコル バージョン 2 (MS-CHAP v2) は、パスワード ベースのチャレンジ/レスポンス方式で、MD4 と DES 暗号化を使用した相互認証プロトコルです。 PEAP (PEAP-MS-CHAP v2) と組み合わせて使用することでセキュリティ保護されたワイヤレス通信を実現できます。
PEAP。 保護された拡張認証プロトコル (PEAP) は、TLS で暗号化および保護された安全なチャネルを作成することで、クリア テキストの EAP 送信を用いてセキュリティの問題に対応する、EAP 通信の 1 種です。
SSID。 サービスセット ID (SSID) は、WLAN 環境で用いられる識別子で、クライアントが、WLAN へのアクセスに必要な正しい設定と資格情報を識別するために使用します。
TKIP。 Temporal Key Integrity Protocol (TKIP) は、ワイヤレス ネットワーク用の WPA 暗号化規格の一部です。 TKIP はWEP の次世代のプロトコルで、パケットごとにキー ミキシングを行い、WEP 規格で見つかっている欠陥を補っています。
WEP。 Wired Equivalent Privacy (WEP) は IEEE 802.11 標準の規定の 1 つで、64 ビットまたは 128 ビットの RC4 暗号化を使用しています。 2001年に、WEP には、主に、RC4 ストリーム暗号の初期化ベクトルが短すぎるという問題のために、RC4 キーが容易に受動的な傍受によりデコーディングされるという重大な欠陥があることがわかりました。
WLAN。 ワイヤレス ローカル エリア ネットワークです。
WPA。 WEP 規格に脆弱性が発見されたことを受けて、Wi-Fi Protected Access (WPA) は、相互運用性を備えたワイヤレス セキュリティ仕様として 2003 年に発表されました。 この標準は IEEE 802.11 標準のサブセットで、認証の機能と TKIP を使用したデータの暗号化を提供します。
WPA2。WPA2 は 2004 年 9 月に Wi-Fi Alliance によって発表された、2004 年 6 月に認可された IEEE 802.11i 仕様と完全に相互運用性を持つ WPA の新しいバージョンとして認定されました。以前のバージョンと同様に、WPA2 は IEEE 802.1X/EAP 認証または PSK テクノロジをサポートしていますが、Advanced Encryption Standard (AES) と呼ばれる Counter-Mode/CBC-MAC Protocol (CCMP) を利用した新しい高度な暗号化メカニズムが採用されています。
課題
多くの組織が生産性や共同作業の向上につながるワイヤレス技術の利点を認識しつつも、その導入については躊躇しています。なぜなら、ワイヤレス ネットワークにより間違いなく自分たちの環境にもたらされるワイヤレス ネットワークの脆弱性について、当然浮かび上がる懸念事項があるからです。 さらに混乱を招く理由として、ワイヤレス通信をセキュリティ保護するためのさまざまな方法が提案されていること、また、それらの方法の効果について述べた報告書が錯綜していることが挙げられます。
ワイヤレス技術は、導入することによるセキュリティ面での問題だけでなく、そもそも導入するべきかどうかという問題などがあり、多くの議題を中規模の企業に投げかけています。 この文書で説明するワイヤレス ネットワークに関する一般的な課題は、次のとおりです。
WLAN を導入するかどうかの決定
ワイヤレスのリスクの理解とリスクの軽減
WLAN 環境のセキュリティによる保護方法の決定
適切な WLAN セキュリティ オプションの選択
ワイヤレス ネットワーク導入におけるセキュリティ レベルの検証
既存の資産のワイヤレス セキュリティ ソリューションへの組み込み
承認されていないワイヤレス デバイスの接続の検出と防止
ソリューション
このセクションでは、中規模のビジネス環境に適したセキュリティ保護されたワイヤレス ソリューションの設計、開発、導入、およびサポートについて説明します。 前述のとおり、ワイヤレス技術の利用には多くの懸念事項があります。 しかし、それぞれの懸念事項を適切な導入により解決すれば、ワイヤレス ネットワークの利点を最も効果的かつ安全に享受することができます。
WLAN セキュリティの評価
ワイヤレス技術は現在では迅速かつ安全に中規模ビジネスに導入できるまでに発達していますが、検討しなればならない性質の異なる問題が多数あるうえに、ワイヤレス ネットワークのセキュリティ保護にはさまざまな方法があります。 このセクションでは、ワイヤレス ネットワークをセキュリティ保護するための一般的な方法を数多く説明します。それぞれの環境に最適なソリューションを選べるようにサポートし、それぞれのアプローチの賛否について述べています。
ワイヤレス ネットワークの利点
WLAN テクノロジの導入には、2 つの異なる面での利点があります。 それは、ビジネス上と運用上の 2 つの利点です。 運用上の利点には低コストの管理と設備投資の削減があります。一方、ビジネス上の利点には生産性の向上、さらに効果的なビジネス プロセス、および将来的な新たな事業の拡大性などがあります。
ビジネス上の利点
WLAN テクノロジを利用することで得られる最も重要なビジネス上の利点は、社員にとっての柔軟性と機動性です。 ワイヤレス ネットワークなら、社員はデスクに拘束されることもなく、社内を比較的容易に動き回ることができます。 このように自由に動き回れることにより、次のような利点が生まれます。
営業など、社外で働く社員が容易にいろいろなオフィスを回ったり、自分のオフィスに戻ったりでき、オフィスに戻ったときにはそのまま社内のネットワークに接続することができます。 接続はほぼ瞬時に行われ、ネットワーク ポートを探す必要もなく、もつれたケーブルを整理する必要もありません。つまり、時間を大幅に節約することができ、ケーブルのからまったネットワークに頭を痛めることもないのです。
技術スタッフは、社内にいても、ミーティング中であっても、自分のデスクから離れていても、いつでも管理しているシステムを監視することができます。 ラップトップや Tablet PC、または持ち運びの可能なコンピュータなどのポータブル テクノロジを利用すれば、企業の IT スタッフはどのような作業のニーズにも即座に応えることができます。
情報はいつでも誰でも得ることができます。 会議の出席者がコピーをとったり、デスクに資料を取りに行ったりなどで会議が遅れることもなくなります。 プレゼン資料は、見づらいプロジェクタに写したりせずに、コンピュータ上で共有することができます。また、ミーティングではインタラクティブなテクノロジを利用して、離れたオフィスや在宅勤務の人も参加することができます。
オフィス全体のシステムを再構築する場合でも、ネットワーク ケーブルの配線を考慮する必要がなく、素早く簡単にシステムを変えることができるため、組織の柔軟性は非常に高くなります。
ワイヤレス技術により技術の利用の幅は新たに広がり、ビジネス環境に新しいアプリケーションやソリューションがもたらされます。 また、パーソナル デジタル アシスタント (PDA) などのデバイスや Tablet PC などを使えば、シームレスにネットワークにつなげることができます。 これまで IT に関して制限のあった社員やビジネス機能も、ネットワーク接続の恩恵を受けることができるのです。ランチ ルームでも、組み立て現場でも、病室でも、小売店でも、レストランでも、さらには工場の現場からでも、簡単に利用できるテクノロジ ソリューションにより、今までにないレベルの高い生産性を得ることができます。
運用の長所
ワイヤレス技術の運用上の長所も幅広く、特定のビジネスの形態や設備によって異なります。 いくつかの長所は次のようなものが挙げられます。
ケーブルでつなぐネットワーク構造に対する依存度が低くなるため、ネットワークの設定にかかるコストは大幅に削減されます。 以前はネットワーク接続は実用的でありませんでしたが、WLAN テクノロジによりコストをかけずに、屋外や離れたオフィスでも接続できるようになります。
ネットワーク スケーラビリティはさらに応答性に優れ、さまざまなレベルの要求に効果的に応えることができます。なぜなら、ネットワーク ポートを増やすよりも、アクセス ポイントを設定または他の場所へ移動させる方がずっと簡単だからです。
また、設備投資を節減することもできます。ワイヤレス ネットワークの設定には、ケーブルでつなぐネットワークのような永久に必要な機器が必要ないからです。 これにより、どのような事情のオフィスの拡大や移転も、より柔軟に行うことができます。 また、高速ワイヤレス (802.11a/g/n) もイーサネットやトークン リング ケーブルに代えて導入でき、コスト削減に効果的です。
ワイヤレス ネットワークの脆弱性
ワイヤレス ネットワークのさまざまなセキュリティ ソリューションのセキュリティ レベルを理解するには、ワイヤレス ネットワークで起こる可能性のある一般的な問題について理解することが重要です。 従来のネットワークにおける脆弱性や攻撃プロファイルについてはよく知られています。しかしワイヤレス ネットワークには、従来のネットワーク以上にリスクの高い脆弱性があります。
表 1. 一般的なWLAN セキュリティにおける脅威
| 脅威 | 説明 |
|---|---|
| ネットワーク盗聴によるデータの漏えい | セキュリティで保護されていないワイヤレス トラフィックへの盗聴攻撃は、機密データやユーザー情報の漏えいを招き、さらには身元情報が盗まれる可能性があります。 巧妙な攻撃者ならネットワーク盗聴による情報をもとに、本来なら攻撃を受けにくいシステムまで攻撃してくる可能性があります。 |
| 送信データの傍受と変更 | ネットワーク リソースにアクセスできる攻撃者なら、不正なシステムをネットワークに埋め込み、それによって正当なシステム間でやり取りされている経路上でデータを傍受、変更することができます。 |
| 詐称 | 内部ネットワークにアクセスすることにより、攻撃者はデータを偽装することができるようになり、それにより正当なトラフィックであるかのように見せかけます。 このような攻撃には偽の電子メール メッセージなどがあります。この偽の電子メール メッセージは外部のソースとの通信に比べ、内部ユーザーに信じられてしまうことが多く、ソーシャル エンジニアリング攻撃やトロイの木馬を侵入させるチャンスを与えてしまいます。 |
| サービス拒否 (DoS) | どのようなセキュリティ ソリューションが導入されていても、WLAN は、その固有の性質上、意図的または偶発的に DoS 攻撃を受けやすいものです。 このような破壊活動は、電子レンジなどの簡易な機器や、無差別にトラフィックを送ってネットワークをあふれさせるように設定された 1 セットの機器があれば容易にもたらされる可能性があります。 |
| フリー ロード (リソースの盗難) |
侵入者は、自由にインターネットにアクセスしたいだけかもしれません。 直接的に悪意があったり危害を加えたりする意図がなかったとしても、このような活動は、正等なユーザーがネットワークに接続するスピードを低下させたり、マルウェアを侵入させてしまう、管理の手が届かない経路になってしまう可能性があります。 |
| 偶発的な脅威と管理外の接続 | セキュリティ保護されていない WLAN では、ワイヤレス ネットワークに対応したデバイスを持っていれば、単にそれを起動するだけで、誰でも内部ネットワークに接続することができます。 このような管理されていないデバイスは、既にセキュリティ侵害を受けている可能性もあります。また、攻撃者はネットワーク攻撃に都合の良い脆弱なポイントをつかんでいるかもしれません。 |
| 不正な WLAN アクセス ポイント | ワイヤレス ネットワークを導入していない企業でも、管理されていないワイヤレス ネットワークから受ける、セキュリティ面での脅威に対して脆弱な面があります。 ワイヤレス ハードウェアは比較的低コストです。そのため、どのような社員でも、組織の環境内で、管理も保護もされていないネットワークをセットアップすることができます。 |
| 機能 | WPA および WPA2 | 静的 WEP | VPN | IPSec |
|---|---|---|---|---|
| 強力な認証 (注を参照) | あり | なし | あり。 共有キー認証をしようしていない場合のみ。 |
あり。証明書または Kerberos 認証を使用している場合。 |
| 強力なデータ暗号化 | あり | なし | あり | あり |
| 透過的な接続と再接続 | あり | あり | なし | あり |
| ユーザー認証 (注を参照) | あり | なし | あり | なし |
| コンピュータの認証 (注を参照) | あり | あり | なし | あり |
| ブロードキャストとマルチキャスト トラフィックの保護 | あり | あり | あり | なし |
| 追加する必要があるネットワーク デバイス | あり。RADIUS サーバー。 | なし | あり。VPN と RADIUS サーバー。 | なし |
| パケットに加え、WLAN へのアクセスのセキュリティによる保護 | あり | あり | なし | なし |
| コンポーネント | 要件 |
|---|---|
| CPU | 733 MHz 以上の CPU 1 個 |
| メモリー | 256 MB RAM |
| Network Interface | なし (または無効にする) |
| ディスク記憶域 | IDE 規格または SCSI 規格の RAID コントローラ RAID 1 単一ボリューム (ドライブ C) として設定された 18 GB の HDD 2 台 データ転送用のローカルのリムーバブル記憶域 (ルート証明書) |
上の表に示したとおり、Windows Server 2003 Standard Edition の一般的な要件に基づいたルート CA には極めて最小限の要件しかないため、必要に応じて、既に使われていない旧式のプラットフォーム上に構築したり、仮想マシンとして作成することさえ可能です。 ラップトップは、コンピュータ ルームで、回線を切断して物理的に安全を確保することが容易なため、ラップトップの使用が効果的だということに気づく方も多いでしょう。 ルート CA の作成方法にかかわらず、必要に応じて、該当のコンピュータが正常に起動および復元できることを確認しておくことが重要です。
発行証明書機関のハードウェア要件も同様ですが、追加のストレージ要件があり、サーバーはネットワークに接続している必要があります。 このサーバーは、発行されたすべての証明書を保存する必要があるため、1,000 ユーザごとに、少なくとも 2 GB のハード ドライブ容量を用意することを推奨します。
Radius サーバーには、WLAN 機能を維持する重要な役目があり、また短期間に発生する多数の認証の要求を処理できる能力が必要とされるため、サーバー要件はより複雑です。 このため、ワイヤレス クライアントの多い環境においては、強固なハードウェア プラットフォームが必要となる可能性があります。 また、証明書機関には Windows Server 2003 Standard Edition を使用すれば十分ですが、Standard Edition は RADIUS クライアントを 50 までしかサポートできないため、IAS サーバーは Enterprise Edition の使用が必要となる場合があります。
このような理由から、IAS をドメイン コントローラにインストールすることが推奨されています。IAS をドメイン コントローラにインストールすると、ドメイン コントローラに必要とされる仕様を満たしている、既存の強固なサーバー プラットフォームを利用することで、サーバー ハードウェアを追加で用意する必要性を低減できるためです。また、ドメイン コントローラ上で IAS を運用することで、ユーザー認証で発生するドメイン コントローラと IAS 間のネットワーク トラフィックが減少するため、IAS のパフォーマンスは事実上向上します。
RADIUS サーバーの要件を決定する際には、フェールオーバー、冗長性、および遠隔地での使用も考慮に入れる必要があります。 IAS サーバーは最小要件は 2 台ですが、多数の支社を抱える企業では、それらの支社のいくつかに IAS サーバーが必要になることがあります。 企業によっては、サーバーの冗長性を高めるために、または負荷分散のために、より高度な要件が必要になる場合もあります。
多機能サーバーを RADIUS サーバーとして使用することは推奨されていませんが、RADIUS サーバーに加わわる可能性のある追加的な負荷や、こういった要求が発生する理由について検討してみることは重要です。 RADIUS サーバーは、極めて短い時間内にすべてのワイヤレス クライアントが接続を要求してくるような状況でも対処できるように、拡張機能を備えていることが必要です。
証明書
WLAN をセキュリティ保護するために採用した WPA アプローチがどの方式であっても、証明書は、ソリューションの一部であるため、何らかの形で証明書は必要になります。 PEAP は、認証サーバー上でのみ証明書を必要とします。そのため、単純にサード パーティの証明書サービスを使用して必要な証明書を発行するという方法も可能です。この方法を用いれば、PKI の実装は必要ありません。 これが、証明書インフラストラクチャをサポートする十分な専門技術やリソースが確保できない場合がある、より小規模な組織に対して、PEAP 方式が推奨される主な理由です。
証明書サービスを用いた EAP-TLS の Windows サポートによる実装では、証明書の発行をサポートする基礎となる PKI を必要としません。ただし、すべてのクライアントは、RADIUS サーバーと認証を確立するために、証明書を持つ必要があるので、サード パーティの証明書を使用は、小規模なビジネス以外の環境では、コストの節減になります。 PEAP と証明書サービスを組み合わせて使う場合も、同様に考慮する必要があります。
組織が既に PKI を導入している場合は、意思決定のプロセスはいくぶん容易になることが考えられます。なぜなら、PKI のコンポーネントが既に適切な場所に配備されている場合、その資産を使用すれば、WLAN セキュリティで最も安全な選択肢を採用できるからです。 たとえ PKI が実装されていなくても、中規模のビジネスにおいては、証明書インフラストラクチャに投資した方が、次のようなその他のアプリケーションを用いることに比べても、より賢い選択であることが理解されるはずです。
コード署名
セキュリティ保護された電子メール メッセージング
セキュリティ保護された Web コンテンツ配信
VPN セキュリティ
暗号化ファイル サービス
総合的に考えると、EAP-TLS または PEAP 方式の証明書サービスを用いるアプローチが、中規模のビジネスにとって最適な方法であると言えます。そのため、この文書では重点的に取り扱っています。
Certificate Practices Statements (CPS) を作成する
PKI の導入計画の初期段階では、証明書がビジネス環境でどのように利用されるのかを文書化する必要があります。 こういった意思決定はプロセスが進むにつれて変更する場合がありますが、公式な証明書ポリシー ステートメントに文書化しておくことは重要です。
正式には、証明書ポリシーは PKI の運用方針を定めた規則です。 この規則には、共通のセキュリティ要件を持つ、固有の組織のグループやアプリケーションに対する、証明書の適用に関する情報が含まれます。 証明書運用規定には、発行される証明書を管理するために企業が従う運用方法が概説されています。 証明書運用規定には、ビジネス システム インフラストラクチャと運用手順ポリシーに関して、証明書ポリシーがどのように解釈されるかが説明されています。 証明書ポリシーは、組織全体に適用される文書ですが、証明書運用既定は個別の CA を対象としています。ただし、同じ役割を果たす複数の CA がある場合は、共通の証明書運用既定を利用することもできます。
一部の企業にとっては、これらの規定は、企業が属している業界を統制する法規制に従って作成する必要のある法的な書類であり、作成にあたっては法務担当者のサポートが必要です。 しかし、このような法規制に従う必要がない企業でも、やはりこの種の文書を作成することは有効です。
証明機関の階層
この文書で提示されているソリューションの設計図では、単一の内部ルートの階層信頼モデルを使用しています。 このアプローチには多くの利点と欠点があります。そのため、この特定のアプローチが実装されるビジネス環境に適しているかどうかを決定するために、より綿密な議論が必要とされる場合もあります。 このトピックの詳細については、「Windows Server 2003 Deployment Kit 」の「Designing a Public Key Infrastructure」(英語) の章を参照してください。
.gif)
図 2. 証明機関の階層
ルート証明機関のセキュリティ保護
ルート CA が安全な "オフライン"(ネットワークに接続していない) の状態でなければ、EAP-TLS の Microsoft 実装は機能しません。 エンタープライズのルート CA 構成ではなく、このようなスタンドアロンのルート CA 構成を使用することには相応のセキュリティ上の理由があり、通常、すべての PKI 実装へのアプローチで推奨される方法です。
このようなアプローチはリソースの無駄のように思われるため、ネットワークに決して接続しないルート CA を作成するために使用されたハードウェアの、少なくとも一部を、企業が再展開できる手法がいくつかあります。 これらの提案のいくつかは、次のようなものです。
ルート証明書を作成し、発行 CA に配布した後、ルート CA からハード ドライブを取り外し、再度必要になるまで安全に保管しておくことができます。 この方法の短所は、CA が必要になったときに、これらのドライブに対応するハードウェアを取り出し、再利用する必要があることです。
ルート証明書を作成し、発行 CA に配布した後、バックアップを通じてサーバーのイメージを記録し、テープや他のオフライン メディアに保存することができます。これにより、サーバー ハードウェアは再利用することができます。 この方法の短所も 1 番目の方法と同様で、必要になったときに、ハードウェアを再度利用できるように設定しなければなりません。
仮想サーバー、仮想 PC、その他の仮想マシン ソフトウェアを使用してルート CA を作成し、ルート証明書を作成して配布した後に、仮想マシン イメージをオフラインのストレージに保存するか、以後再度必要になる場合はアーカイブもできます。 一般的な標準プラットフォーム (組織で使用されている標準的なデスクトップなどのハードウェア要件を満たすシステム) をこのアプローチに使用する場合、ルート CA が再度必要になった場合に、必要なハードウェアを取り出してくるのがより容易になります。
昨年度のラップトップ上にオフライン ルート CA を構築し、コンピュータ ルームの安全な場所に保管します。 これにより、どちらにしろ捨ててしまうハードウェア リソースを活用することができます。
インターネット認証
インターネット認証サービス (IAS) は RADIUS およびプロキシ サーバーの Microsoft 実装です。 IAS は、さまざまな種類のネットワーク接続に対して、集中化認証、承認、およびアカウンティングを実行します。 IAS は、他の RADIUS サーバーと共に用いることで認証と承認の用途で使用でき、また、 ルーティングとリモート アクセス サーバーのような他の VPN サーバーや、ワイヤレス アクセス ポイントのような他のネットワーク インフラストラクチャと共に用いることで、アカウンティング フォワーダとして使用することができます。
IAS インフラストラクチャの導入計画を検討する際に、IAS ベースの RADIUS インフラストラクチャの価値が、単一の分離されたネットワークにアクセスを提供する目的ではないため、利点を得られるということが重要です。 つまり、IAS インフラストラクチャを計画および導入する際には、Active Directory のような集中アカウント データベースなどの、ネットワーク アクセス管理の集中サービスを使用するかどうかを決める必要があります。また、現在と将来の企業のニーズを満たすかどうかも検討する必要があります。 結局、IAS インフラストラクチャの導入は、個々に進めるのではなく、戦略的に行う必要があるということです。
この文書では、セキュリティ保護されたワイヤレス インフラストラクチャに関連する、IAS の計画と導入についてのみ説明します。 IAS の計画と展開の際の他の選択肢については、「Internet Authentication Service」(英語) ホーム ページの「Deployment Resources」のセクションを参照してください。
既存の RADIUS 実装
このソリューションは、既存の RADIUS サーバー実装と統合できますが、この文書ではそのプロセスについては説明しません。 ほとんどの場合、この文書に記載されている機能を利用するために IAS を使用するほうが利点があります。 この目的を達成するためには、コアとなる RADIUS サーバーとして使用するために、古いプラットフォームを Windows 2003 Server にアップグレードするか、既存の RADIUS サーバーを、新しい Windows Server 2003 ベースの RADIUS サーバーへのプロキシ RADIUS トラフィックに変更することも可能です。
既存の RADIUS インフラストラクチャを Windows Server 2003 ベースの RADIUS サーバーに移行する場合の詳細な計画のガイドについては、「IAS Technical Reference」(英語) ページを参照してください。またはMicrosoft Account Representative または該当する Microsoft Consulting Services の担当者に問い合わせてください。
RADIUS サーバーのフェールオーバーと負荷分散
RADIUS は、すべての 802.1X ワイヤレス セキュリティ ソリューションの重要なコンポーネントであるため、ワイヤレス ネットワークの可用性は、RADIUS サーバーの可用性により異なります。 このため、ワイヤレス ネットワークをサポートする RADIUS ソリューションは、有線のネットワークと同等の可用性とパフォーマンスを提供するために、高い信頼性、応答性、および冗長性が必要になります。こうした理由から、IAS を既存のドメイン コントローラにインストールすることが一般的に推奨されます。
負荷分散の戦略を決定する前に、802.1X はワイヤレス アクセス ポイントと RADIUS サーバー間で、RADIUS (EAP-RADIUS) 内に EAP を 実装することを理解することが重要です。 RADIUS は UDP を使用しますが、EAP は RADIUS 内でトンネルされるセッション指向のプロトコルです。 これは、1 つの認証操作から成る複数の EAP-RADIUS パケットは、特定の認証が失敗した、同じ RADIUS サーバーまたは他のサーバーに戻る必要があることを意味します。
ワイヤレス ネットワークでは、IAS サーバーの負荷分散とフェールオーバーに対しては 2 つのアプローチがあります。 1 つは、RADIUS サーバー グループと IAS プロキシ サーバーを共に使用する方法で、もう 1 つは、ワイヤレス アクセス ポイントのハードウェア設定を使用して、プライマリおよびセカンダリ RADIUS サーバーを構成する方法です。 次の表にそれぞれのアプローチの長所と短所を示します。
表 4. EAP の RADIUS フェールオーバーと負荷分散
| 方法 | 長所 | 短所 |
|---|---|---|
| RADIUS サーバー グループによる IAS プロキシ |
|
|
| ワイヤレス アクセス ポイントでのプライマリおよびセカンダリ RADIUS サーバーの設定 |
|
|
規模の大きい企業では、RADIUS サーバーの負荷を分散するために、RADIUS サーバー グループに構成した RADIUS プロキシを使用することを検討してください。 これにより、重み値および優先順位に加え、RADIUS トラフィックのタイプや RADIUS 属性など、変更可能な多数の構成項目に基づいてトラフィックの分散が可能になり、柔軟性がある程度確保できます。 このタイプのアーキテクチャでは、認証要求の応答で高い柔軟性とスケーラビリティを実現でき、管理上の手間も減ります。
ワイヤレス アクセス ポイントに組み込まれた RADIUS サーバーの簡易なフェールオーバー機能は、ほとんどの組織にとって十分なレベルの復元性を提供しますが、プロキシ サーバー グループを使用した場合ほど高度なソリューションではありません。 ただし、このアーキテクチャから RADIUS プロキシ サーバーベースのフェールオーバーと負荷分散のソリューションへの移行は比較的簡単なため、このソリューションでは、規模が拡大した場合でも対応できます。 ワイヤレスの使用範囲が狭い場合や限られている場合のみを考慮すればよい組織では、このソリューションの実装は簡単で効果的ですが、ワイヤレス ネットワークの規模が広がり複雑になるにつれて、管理と実装の作業は多くなります。これは、各デバイスで入念な監視を行い、すべてのサーバー間で効果的な負荷分散を維持できるようにする必要があるためです。
.gif)
図 3. RADIUS WLAN のフェールオーバーと負荷分散方法
.gif){kind=link}
ワイヤレス アクセス ポイントの組み込み機能を使用した負荷分散では、図 3 に示すように、各拠点のワイヤレス アクセス ポイントの約半分で、通常はプライマリ RADIUS サーバーを使用し、障害発生時には別の RADIUS サーバーをセカンダリとして使用するように構成します。残りのワイヤレス アクセス ポイントでは、プライマリとセカンダリの割り当てを逆にします。オーバーヘッドが明らかに高くなる場合は、一部のアクセス ポイントにかかる負荷が他のアクセス ポイントよりも高くなっているため、効果的なレベルの負荷分散を実現して維持するには、十分な監視が必要になります。
RADIUS のログ要件
IAS サーバーでは、2 つのタイプのオプションのイベントをログに記録できます。
認証の試行の成功および失敗
RADIUS 認証とアカウント情報
認証イベントは、WLAN へのアクセスを試行したときにデバイスとユーザーによって生成され、IAS によって Windows Server 2003 システム イベント ログに記録されます。 認証イベントは、トラブルシューティングに役に立つだけでなく、セキュリティ監査と侵入検出システムの一部としても役に立ちます。 最初の段階では、成功したイベントと失敗したイベントの両方に対して認証イベントを有効にする必要がありますが、最終的には、フィルタ処理して必要なイベントのみを有効にしてください。これは、システム イベント ログのオーバーフローを防止するためです。 RADIUS 認証要求のログ記録を使用して有効にすると、これらのイベントをセキュリティ用に使用する必要がなくなります。
集中 IAS サーバーまたは分散 IAS サーバー
中規模企業の多くは、遠隔地にある施設に対して高速で復元性の高い WAN 接続を備えています。また、RADIUS トラフィックは WAN リンクおよびダイヤルアップ接続で機能するように設計されているため、帯域幅をあまり使用しません。このため、このような中規模の企業では、設計の開始点として集中 IAS サーバー アーキテクチャを検討すべきです。 冗長性と高速の WAN を備えた基盤となるインフラストラクチャが既に構築されている場合、集中型の設計は費用対効果も高くなります。
ただし、混雑した接続で 802.1X 認証の完了を待っている間に、DHCP トラフィックなどの他の通信がタイムアウトする可能性があるため、このような場合は、既存の WAN リンクの現在の容量を注意して分析し、集中型の設計が最適かどうかを判断する必要があります。 集中 IAS アーキテクチャの使用を検討する場合は、クライアント接続以外についても考慮する必要があります。これは、ネットワークのアクセス権とグループ メンバシップを特定する間にタイムアウトになるのを回避するために、IAS サーバーとドメイン コントローラ間の通信に堅牢なネットワーク接続が必要になるためです。
一部の企業では、冗長性のある高帯域の WAN 接続と高度なネットワーク装置に伴う費用のため、集中型のアーキテクチャを利用できない場合があります。 このような企業で特に非集中のサーバー インフラストラクチャが既に構築されている場合は、分散型の IAS 設計を選択します。
次の図に示すように、集中型と分散型の 2 つを混在させる方法もあります。この方法では、このインフラストラクチャをサポートできるサイトで、IAS サーバーの戦略的な配置が可能になり、基本的なサーバー ベースを持たない支社に対して、配置したサーバーから認証を行うことができます。
.gif)
図 4. 混在型 IAS WLAN インフラストラクチャのアプローチ
.gif){kind=link}
このガイドでは、ローカルおよびリモートの要求を処理できる 2 つの RADIUS サーバーを備えた大規模なハブ オフィスを構成するためのガイダンスと、必要に応じて単一サーバーを備えた支社オフィスを持つ大規模な本社オフィスを構成するためのガイダンスを提供して、集中型、分散型、混在型の 3 つの方法すべてについて説明します。
注 サーバー インフラストラクチャを備えていない支社オフィスでは、WLAN へのアクセスは WAN の可用性に依存します。
IAS サーバーの配置および配置に関する考慮事項
WLAN サービスへのアクセシビリティを維持するには、独立した Active Directory フォレストごとに 2 つ以上の RADIUS サーバーが必要になります。 このような基本的な要件以外にも、必要なサーバーの数の特定や、それらのサーバーが他のサーバー機能と配列が可能であるかどうかの確認など、考慮する事項がいくつかあります。
一般的に、IAS サーバーの配置はドメイン コントローラの配置の後に行う必要があります。つまり、あるオフィスが別のオフィスとの高速の WAN リンクを使用して、既にドメイン サービスを利用している場合は、リモート RADIUS サーバーも使用する必要があります。 ドメイン コントローラを既に持つ大規模なオフィスでは、使用可能な WAN リンクに応じて、フェールオーバー機能を持つ RADIUS サーバーを別の場所に 1 台以上配置する必要があります。 ローカル ユーザー認証の信頼性と、過剰なトラフィックが発生した場合の認証に使用されるドメイン コントローラの配置を考慮して、RADIUS サーバーの配置を計画する場合は、WAN リンクの容量を注意して評価する必要があります。 また、パフォーマンス向上のために、RADIUS サーバーは、フォレストのルート ドメインに配置する必要があります。これにより、Kerberos の動作が最適化されます。
また、一部の小規模のオフィスでサーバー ハードウェアを追加するスペースまたはインフラストラクチャがなく、遠隔地に追加のサーバーを配置する必要がある場合に、それが可能かどうかも検討する必要があります。 このような問題に対応するには、IAS サーバーを Active Directory ドメイン コントローラと同じ場所に配置します。 次の表に、このアプローチの長所と短所を示します。
表 5. IAS とドメイン コントローラを同じ場所に配置する場合の考慮事項
| IAS の場所 | 長所 | 短所 |
|---|---|---|
| ドメイン コントローラと同じ場所に配置 |
|
|
| IAS Web サーバーを別に配置 |
|
|
この表に示すように、多くの組織は、各自のサーバーとドメイン コントローラ機能の分離に関して、既存のポリシーを持っていますが、この理由は、組織のサーバーがネットワーク環境に不可欠であるためです。 また、IAS サービスをドメイン コントローラ上に配置することに伴い、セキュリティ上の問題も発生します。この問題は、両方の管理グループ間の作業を分離する場合に発生しますが、これは、IAS 管理は本来ローカルの Windows 管理者グループ機能と切り離されていないためです。 このような問題は、IAS サービスが同じ場所に配置可能かどうかを決定する前に検討する必要があります。しかしこの点を除けば、同じ場所に配置することにはパフォーマンス上の利点があります。コスト上の利点についてはいうまでもなく、遠隔地であればなおさらのことです。
支社オフィスにサーバー ハードウェアを追加することに伴うコスト上の問題を相殺するには、支社オフィスにある既存のドメイン コントローラを IAS サーバーとして直接使用するか、仮想マシンを既存のドメイン コントローラに追加して使用します。
サーバーの負荷とハードウェア要件を見積もる
潜在的なサーバーの負荷を評価および計画する場合は、最悪のシナリオを想定して行います。 特に、フェールオーバー イベント中の短時間に、すべての WAN ユーザーが認証を実行する必要が生じた場合を想定します。 当然、最適な設計は、復元に必要な最低限の数のサーバーを展開し、同時に将来の成長に備えてスペースを確保しておくことです。
IAS サーバーの負荷と要件を計画する場合、次の情報を考慮する必要があります。
認証とアカウンティングを必要とするユーザーおよびデバイスの数
EAP タイプや再認証の頻度などの認証オプション
ログ記録の詳細や IAS ソフトウェア追跡などの RADIUS オプション
EAP-TLS 方式の証明書サービスを持つ WPA または WPA2 を使用するこのソリューションで重要なのは、WEP とは異なり、WPA と WPA2 ではセッション キー更新のための強制的な再認証の必要性が減り、これにより、この処理に伴うオーバーヘッドを軽減できることです。 また、EAP-TLS では、初回の認証時に CPU を消費する公開キー操作が必要になりますが、その後のログオンでは、高速再接続用にキャッシュされた資格情報を使用します。キャッシュされた資格情報の有効期限は、既定で 8 時間です。 クライアントがアクセスポイント間を移動すると、再認証が行われることも重要な点です。再認証は、ある RADIUS サーバーに対して認証を行うワイヤレス アクセス ポイントから、別の認証サーバーに対して認証を行うワイヤレス アクセス ポイントに移動した場合に行われます。この処理は、認証サーバーごとに 1 回のみ実行され、ユーザーには透過的です。
IAS サーバーの容量を見積もる場合、負荷の目安として 1 秒あたりの認証数を使用すると便利です。 次の表は、Intel Pentium 4 2 GHz CPU を搭載し、Active Directory 機能を持つ IAS サーバーの 1 秒あたりの認証の容量を概算で示しています。
表 6. 1 秒あたりの認証
| 認証タイプ | 1 秒あたりの認証数 |
|---|---|
| 新しい EAP-TLS 認証 | 36 |
| オフロード カード サポートを使用する新しい EAP-TLS 認証 | 50 |
| 高速再接続による認証 | 166 |
| 構成項目 | リファレンス | 設定 |
|---|---|---|
| Active Directory フォレストの DNS 名 | ||
| フォレスト ルートの識別名 (DN) | Pkiparams.vbs | |
| ドメインの NetBIOS 名 | ||
| ルート CA ワークグループの NetBIOS 名 | ||
| ルート CA のサーバー名 | ||
| 発行 CA のサーバー名 | ||
| ルート CA の X.500 CN | ||
| 発行 CA の X.500 CN | ||
| CA 証明書の公開に使用される Web サーバーの完全修飾ホスト名 | Pkiparams.vbs |
| 構成項目 | リファレンス | 設定 |
|---|---|---|
| 管理役割を担うセキュリティ グループ | ||
| 公開キー サービス構成コンテナの管理者 | ca_setup.wsf | Enterprise PKI Admins |
| CRL と CA 証明書をエンタープライズ設定コンテナに公開する権限を持つ管理グループ | ca_setup.wsf | Enterprise PKI Publishers |
| CA を構成および維持する管理グループ。それ以外のすべての CA 役割の割り当ておよび CA 証明書の更新に関する権限もコントロールします。 | ca_setup.wsf | CA Admins |
| 証明書の登録および失効の要求を承認する管理グループ (CA 担当者の役割) | ca_setup.wsf | Certificate Managers |
| CA の監査ログおよびセキュリティ ログを管理する管理グループ | ca_setup.wsf | CA Auditors |
| CA のバックアップを管理する管理グループ | ca_setup.wsf | CA Backup Operators |
| IIS の構成 | ||
| CA 証明書および CRL 情報の公開に使用する IIS 仮想ディレクトリ名 | Pkiparams.vbs | pki |
| IIS 仮想ディレクトリに対応する、発行 CA 上の物理パス | C:\CAWWWPub | Pkiparams.vbs |
| ルート CA と発行 CA に共通するパラメータ | ||
| 証明書サービス要求ファイルのドライブおよびパス | C:\CAConfig | Pkiparams.vbs |
| 証明書サービス データベース ログのドライブおよびパス | %windir%\System32\CertLog | |
| ルート CA の設定 | ||
| ルート CA キーの長さ (「注」を参照) | 4096 | |
| ルート CA 証明書の有効期間 (年) | Pkiparams.vbs | 16 |
| ルート CA から発行された証明書の有効期間 (年) | Pkiparams.vbs | 8 |
| ルート CA における CRL 発行間隔 (月) | Pkiparams.vbs | 6 |
| CRL 重複期間 (日) | Pkiparams.vbs | 10 |
| ルート CA における Delta CRL 発行間隔 (時間、0 の場合は発行されない) | Pkiparams.vbs | 0 |
| 発行 CA の構成 | ||
| 証明書サービス データベースのドライブおよびパス | D:\CertLog | |
| 発行 CA キーの長さ | 2048 | |
| 発行 CA 証明書の有効期間 (年) | Pkiparams.vbs | 8 |
| 発行 CA 証明書に対する最長の有効期限 (年) | Pkiparams.vbs | 4 |
| 発行 CA における CRL 発行間隔 (日) | Pkiparams.vbs | 7 |
| CRL 重複期間 (日) | Pkiparams.vbs | 4 |
| 発行 CA における Delta CRL 発行間隔 (日、0 の場合は発行されない) | Pkiparams.vbs | 1 |
| Delta CRL 重複期間 (日) | Pkiparams.vbs | 1 |
| その他 | ||
| インストール スクリプトのパス | C:\MSSScripts |
`Sysocmgr /i:sysoc.inf /u:C:\MSSScripts\OC_AddIIS.txt`
このコマンドは、次のようにオプション コンポーネント マネージャに対して、自動インストール ファイル C:\\MSSScripts\\OC\_AddIIS.txt で指定されているコンポーネント設定を使用するように指示します。
```
[Components]
complusnetwork = On
iis_common = On
iis_asp = On
iis_inetmgr = On
iis_www = On
```
**注** この構成ファイルでは、Active Server Pages (ASP) が有効になっていますが、証明書サービスの Web 登録ページが不要な場合は、ASP を無効にする必要があります。無効にするには、**iis\_asp = on** の行を削除してから sysocmgr.exe を実行します。この設定は、後で必要になったときに有効にすることもできます。
次のコマンドを入力してオプション コンポーネント マネージャを再度実行し、インストールされているコンポーネントが前述のコンポーネントと一致しているかどうかを確認します。
sysocmgr /i:sysoc.infアプリケーション サーバーのサブコンポーネントのうち、上記以外のサブコンポーネントは不要なため、選択する必要はありません。
機密情報アクセス (AIA) と CRL 配布ポイント (CDP) を公開できるように、発行 CA 上の IIS を設定する
HTTP を使用して CA 証明書 と CRL を公開するときに使用する仮想ディレクトリを、IIS 上に作成する必要があります。CA 証明書は機密情報アクセス (AIA)、CRL の発行ポイントは CRL 配布ポイント (CDP) とも呼ばれます。
IIS 上に仮想ディレクトリを作成するには
IIS サーバーにローカル管理者権限でログオンします。
CA 証明書と CRL を格納するための C:\CAWWWPub というフォルダを作成します。
次の表に従って、フォルダにセキュリティを設定します。
表 9. 仮想ディレクトリに対するアクセス許可の設定
| ユーザーまたはグループ | アクセス許可 | 許可または拒否 |
|---|---|---|
| Administrators | フル コントロール | 許可 |
| System | フル コントロール | 許可 |
| Creator Owners | フル コントロール (サブフォルダとファイルのみ) | 許可 |
| Users | フォルダ内容の読み取りと一覧表示 | 許可 |
| IIS_WPG | フォルダ内容の読み取りと一覧表示 | 許可 |
| Internet Guest Account | 書き込み | 拒否 |
| グループ名 | 目的 |
|---|---|
| Enterprise PKI Admins | 公開キー サービス構成コンテナの管理者 |
| Enterprise PKI Publishers | CRL と CA 証明書をエンタープライズ設定コンテナに公開する権限を持っています。 |
| CA Admins | CA に関する全面的な管理権限 (他の役割をどのメンバに割り当てるかを決定する権限など) を持っています。 |
| Certificate Managers | 証明書の発行と失効を管理します。 |
| CA Auditors | CA に関する監査データを管理します。 |
| CA Backup Operators | CA のキーとデータをバックアップおよび復元するアクセス許可を持っています。 |
| 管理役割 | グループ メンバシップ |
|---|---|
| CA Administrator | Enterprise PKI Admins、CA Admins、Certificate Managers、Administrators |
| CA Auditor | CA Auditors、Administrators |
| CA Backup Operator | CA Backup Operators |
| 組織単位 | 目的 |
|---|---|
| Certificate Services | 親 OU。 |
| \-Certificate Services Administration | CA およびエンタープライズ PKI 構成を管理する管理グループを格納します。 |
| \-Certificate Template Management | 個々の証明書テンプレートを管理するためのグループを格納します。 |
| \-Certificate Template Enrollment | 同名のテンプレートに対する登録および自動登録のアクセス許可を持つグループを格納します。 テンプレート自体を変更せずに、これらのグループの制御を適切な個人に委任できます。 |
| \-Certificate Services Test Users | 一時テスト用アカウントを格納します。 |
Enterprise Admins セキュリティ グループのメンバとしてログオンします。
[Active Directory サイトとサービス] MMC スナップインで、[表示] メニューから [Services] ノードを表示し、Public Key Services サブコンテナを選択して、そのプロパティを開きます。
[セキュリティ] タブで、Enterprise PKI Admins セキュリティ グループを追加し、このグループにフル コントロール権限を付与します。
詳細ビューで、このグループのアクセス許可を編集し、フル コントロール権限の適用先として、このオブジェクトとすべての子オブジェクトを選択します。
Servicesコンテナを選択し、そのプロパティを開きます。
[セキュリティ] タブで、Enterprise PKI Admins セキュリティ グループを追加し、このグループにフル コントロール権限を付与します。
詳細ビューで、このグループのアクセス許可を編集し、フル コントロール権限の適用先として、このオブジェクトのみを選択します。
Enterprise PKI Admins グループにアクセス権限を付与するには
Enterprise Admins セキュリティ グループのメンバとしてログオンします。
[Active Directory サイトとサービス] MMC スナップインで、[Services] ノードを表示し、Public Key Services の下の AIA コンテナのプロパティを開きます。
[セキュリティ] タブで、Enterprise PKI Publishers セキュリティ グループを追加し、このグループに次のアクセス許可を付与します。
読み取り
書き込み
すべての子オブジェクトの作成
すべての子オブジェクトの削除
詳細ビューで、このグループのアクセス許可を編集し、これらのアクセス許可の適用先として、[このオブジェクトとすべての子オブジェクト] を選択します。
次のコンテナに対して、手順 2 ～ 4 を繰り返します。
Public Key Services\CDP
Public Key Services\Certification Authorities
Cert Publishers グループにアクセス許可を付与する
Cert Publishers セキュリティ グループには、ドメイン内のすべてのエンタープライズ CA のコンピュータ アカウントが属しています。 このグループの用途は、ユーザー オブジェクト、コンピュータ オブジェクト、および前の手順で述べた CDP コンテナ内のオブジェクトに対して、アクセス許可を付与することです。 CA をインストールする場合は、そのコンピュータ アカウントをこのグループに追加する必要があります。
Enterprise PKI Admins グループのメンバがエンタープライズ CA をインストールできるようにするには、このグループに対するアクセス許可を変更する必要があります。
Cert Publishers グループのメンバを変更する権限を付与するには
発行 CA のインストール先ドメインにおける Domain Admins グループのメンバとしてログオンします。
Active Directory ユーザーとコンピュータ MMC スナップインを開きます。
MMC の [表示] メニューで、[詳細設定] が選択されていることを確認します。
Cert Publishers グループを選択し、そのプロパティを表示します。このグループは既定で Users コンテナの下にあります。
[セキュリティ] タブで、Enterprise PKI Admins グループを追加し、[詳細] をクリックします。
一覧で Enterprise PKI Admins グループを選択し、[編集] をクリックします。
[プロパティ] タブをクリックし、[適用先] ボックスで [このオブジェクトのみ] が選択されていることを確認します。
一覧をスクロールして、[許可] 列でメンバの書き込みオプションのチェックボックスをオンにします。
各ダイアログ ボックスで [OK] をクリックして変更結果を保存し、すべてのダイアログ ボックスを閉じます。
\証明書サービス コンポーネントをインストールする前に、発行 CA サーバーを再起動します。 これにより、発行 CA 用サーバーで、そのアクセス トークンに新しく登録されたグループ メンバシップを検出できるようになります。
Enterprise PKI Admins グループを復元するアクセス許可を付与する
証明書サービスのインストール プロセスでは、エンタープライズ CA が配置されるドメインのファイルとディレクトリを復元するユーザー権限が必要です。 具体的には、テンプレート上のセキュリティ記述子とその他のディレクトリ オブジェクトを結合する場合に、この権限が必要になります。これにより、ドメインの PKI オブジェクトに正しいアクセス許可を設定できます。 あらかじめ用意されている Administrators、Server Operators、Backup Operators のドメイン グループは、既定でこの復元権限を持っています。
CA のインストールには Enterprise PKI Admins グループが使用されるため、このグループにファイルとディレクトリの復元ユーザー権限を付与する必要があります。
Enterprise PKI Admins グループに復元権限を付与するには
発行 CA のインストール先ドメインにおける Domain Admins グループのメンバとしてログオンします。
Active Directory ユーザーとコンピュータ MMC スナップインを開きます。
[ドメイン コントローラ OU] を選択し、その OU のプロパティを開きます。
[グループ ポリシー] タブで、[既定のドメイン コントローラ ポリシー GPO] を選択し、[編集] をクリックします。
[コンピュータの構成]、[Windows の設定]、[セキュリティの設定]、[ローカル ポリシー]、[ユーザー権利の割り当て] を選択し、[ファイルとディレクトリの復元] をダブルクリックします。
Enterprise PKI Admins グループを一覧に追加します。
ダイアログ ボックスを閉じ、GPO 編集 MMC を閉じます。
注 ドメイン コントローラ上で [ファイルとディレクトリの復元] ユーザー権限を設定する GPO が他にもある場合、[Default Domain Controllers Policy] ではなく優先度の最も高い GPO に対してこの処理を実行する必要があります。 ユーザー権限の設定は累積型ではなく、このユーザー権限が設定されている GPO のうち最後に適用される GPO のみが有効になります。
ルート証明機関サーバーを展開する
前述のように、多くの企業には文書化されたサーバー構築プロセスが既にあるため、このガイドでは、Windows Server 2003 のインストール手順を段階的に説明しません。 ただし、ルート CA サーバーは、侵害されないようにネットワークには決して接続しないという点で、他のサーバーと多少異なります。
このため重要なのは、構築プロセス中にルート CA サーバーをネットワークに接続しないことと、ある時点で誤って接続されないようにするために、ネットワーク アダプタを無効にしておくことです。 また、このサーバーはネットワークに接続されないため、ワークグループに属することも重要な点です。このワークグループ名は、インストール前に選択して記録してください。
注 ルート CA を構築してオフライン状態にした場合でも、ネットワーク環境内では一意の名前にします。
CAPolicy.inf ファイル
ルート CA サーバーに対して必要なサーバー ハードウェアを割り当て、オペレーティング システムをインストールしたら、次に、capolicy.inf ファイルを作成します。 capolicy.inf ファイルは、ルート CA の作成に必要です。これは、キーの長さや証明書の有効期限など、自己署名されたルート CA 証明書の特性がルート CA により指定されるためです。
CRL と AIA の情報はルート CA 証明書では必要ないため、CRLDistributionPoint および AuthorityInformationAccess パラメータを capolicy.inf ファイルで Empty に設定します。
CAPolicy.inf ファイルを作成するには
メモ帳などのテキスト エディタでプレーンテキスト ファイルを作成し、次のテキストを入力します。
[version] Signature=”$Windows NT$” [Certsrv_server] RednewalKeyLength=4096 RenewalValidityPeriod=Years RenewalValidityPeriodUnits=16 [CRLDistributionPoint] Empty=true [AuthorityInformationAccess] Empty=trueこの CA に対して定義される証明書運用規定 (CPS) がある場合、次の記述を capolicy.inf ファイルに書き込みます。この実装に固有の値は斜体で置き換えてあります。
[CAPolicy] Policies=company CPS name [company CPS name] OID=the.company.OID URL=”https://www.companyurl.com/cpspagename.htm”このテキスト ファイルを %windir%\CApolicy.inf として保存します (Windows がインストールされたフォルダの絶対パス、C:\Windows などで %windir% を置き換えます)。 この手順を完了するには、管理者または同等のアクセス許可を持つアカウントで、このファイルを Windows フォルダに保存する必要があります。
証明書サービスのソフトウェア コンポーネントをインストールする
CA ソフトウェア コンポーネントをインストールするには、Windows コンポーネント ウィザードを使用します。 インストールを完了するには、Windows Server 2003 インストール メディアが必要であることに注意してください。
証明書サービスをインストールするには
ローカル Administrators グループのメンバとしてログオンし、オプション コンポーネント マネージャを実行します (または、[コントロール パネル] ウィンドウの [プログラムの追加と削除] をクリックし、[Windows コンポーネントの追加と削除] をクリックします)。
sysocmgr /i:sysoc.inf証明書サービス コンポーネントを選択します ([はい] をクリックして名前の変更の警告メッセージを閉じます)。
スタンドアロンのルート CA として CAの種類を選択し、カスタム設定を使用するようになっていることを確認してください。
[公開キーと秘密キーの組] ダイアログ ボックスで、キーの長さ以外は、4096に設定されている既定値のままにしておきます。CSPの種類は、Microsoft Strong Cryptographic Provider です。
次のフィールドに、必須フェーズで収集した情報を特定する証明機関を入力します。
CA の共通名 :
識別名のサフィックス :
有効期間 : 8 年間
この時点で、CSP によりキー ペアが生成され、ローカル コンピュータのキー ストアに書き込まれます。
注 以前にこのシステムに CA をインストールした場合、前のインストール時の秘密キーを上書きしてもよいかどうかを警告するダイアログ ボックスが表示されます。 再度キーを使用しないことを確認してから、次に進みます。
証明書データベース、データベース ログ、および構成フォルダの場所を既定値のままにします。 この時点で、オプション コンポーネント マネージャにより、証明書サービス コンポーネントがインストールされます。この処理には Windows Server 2003 インストール メディアが必要です。
[OK] をクリックして、IIS に関する警告を閉じ、インストールを続行します。
ルート CA プロパティの設定
ルート CA の設定時に、環境に固有のパラメータが使用されます。ルート CA の設定手順については、このセクションで説明します。 これらのパラメータは、作業を進める前に収集しておく必要があります。これらのパラメータについては、このガイドの前半にある必要条件のセクションに記載されています。
ルート CA プロパティを設定するには
CA サーバーにローカル Administrators グループのメンバとしてログオンします。
C:\MSSScripts\pkiparams.vbs スクリプトをカスタマイズして、次の変更を加えます。
AD_ROOT_DN 設定の値を変更し、Active Directory フォレストのルート ドメインの DN に一致させます。
HTTP_PKI_VROOT 設定を変更し、以前設定した IIS 仮想ディレクトリに HTTP パスを一致させます。
次のスクリプトを実行します。
Cscript //job:RootCAConfig C:\MSSScripts\ca_setup.wsf
管理者の役割を設定する
監査者や証明書マネージャなどの管理者の役割を使用するために、以前に作成したセキュリティ グループを役割に対応付ける必要があります。
注 中規模企業の多くは、このガイドで既に説明した単純な委任モデルを使用しますが、役割の分類を細かく設定する必要がある場合に対応できるように、ここでは柔軟なモデルについて説明します。
ルート CA の管理役割を設定するには
証明機関管理コンソールで、[プロパティ] をクリックします。
[セキュリティ] タブをクリックして、次の表のローカル セキュリティ グループを追加し、それぞれにアクセス許可を追加します。
表 13. CA アクセス許可のエントリ
| グループ | アクセス許可 | 許可または拒否 |
|---|---|---|
| CA Admins | CA の管理 | 許可 |
| Certificate Managers | 証明書の発行と管理 | 許可 |
ルート CA 証明書と CRL をディスクに転送する
Active Directory、IIS 証明書公開サーバー、および CRL 公開サーバーに公開できるように、CA からルート CA 証明書と CRL をコピーする必要があります。 この例では、ディスクを使用する場合について述べていますが、USB ドライブなどのポータブル メディアを使用することもできます。
ルート CA 証明書と CRL をディスクにコピーするには
ローカル CA Admins グループのメンバとしてルート CA にログオンし、ポータブル メディアをサーバーに挿入します。
次のスクリプトを実行して、CA 証明書をディスクにコピーします。
Cscript //job:GetCACerts C:\\MSSScripts\\CA\_Operations.wsf次のスクリプトを実行して、CA CRL をディスクにコピーします。
Cscript //job:GetCRLs C:\\MSSScripts\\CA\_Operations.wsfこのディスクにラベルを付けて日付を入れ、後で使用できるように保存します。
ルート CA 情報を公開する
発行 CA をインストールする前に、ルート CA の証明書を Active Directory の信頼されたルート ストアに公開して、ルート CRL を Active Directory の CDP コンテナに公開する必要があります。 このプロセスでは、すべてのドメイン メンバによりルート CA の証明書が各自の信頼されたルート ストアにインポートされ、ルート CA により発行された証明書の取り消し状況を確認できるようになります。
発行 CA には、必須の Certutil.exe、certadm.dll および certcli.dll ライブラリがインストールされているため、この手順を実行するには発行 CA の使用が最適です。ただし、certutil.exe およびサポートする DLL ファイルが Windows Server 2003 ベースのシステムにインストールされている場合は、任意のメンバ サーバーを使用できます。
ルート CA 証明書と CRL を Active Directory に公開するには
前述の要件に合うドメイン メンバのコンピュータに、Enterprise PKI Admins グループのメンバとしてログオンし、ルート CA 証明書と CRL を保存するために使用したディスクを挿入します。
次のスクリプトを実行して、CA 証明書を Active Directory に公開します。
Cscript //job:PublishCertstoAD C:\\MSSScripts\\CA\_Operations.wsf次のスクリプトを実行して、CRL を Active Directory に公開します。
Cscript //job:PublishCRLstoAD C:\\MSSScript\\CA\_Operations.wsf
ルート CA 証明書と CRL を Web サーバーに公開する
CDP と AIA の URL の HTTP バージョンがこの CA によって発行された証明書の拡張機能で指定されているため、この処理は必要です。 これらの拡張機能が存在する場合、設定された URL への CRL と証明書の発行を受け付ける必要があります。
注 この処理は、CDP および AIA 公開 Web サーバーが発行 CA に存在するかどうかには依存しませんが、仮想ディレクトリが、IIS を指定するために既に設定されたディレクトリ (C:\CAWWWPub) に一致していると仮定します。 異なるパスが選択されている場合は、PKIParams.vbs スクリプトの WWW_LOCAL_PUB_PATH の値を変更する必要があります。
ルート CA 証明書と CRL を Web URL に公開するには
ローカル管理者または同等のアカウントで Web サーバーにログオンします。
ルート CA 証明書と CRL ディスクが挿入されていることを確認します。
次のスクリプトを実行して、CA 証明書を Web サーバーのフォルダに公開します。
Cscript //job:PublishRootCerttoIIS C:\\MSSScripts\\CA\_Operations.wsf次のスクリプトを実行して、CA CRL を Web サーバーのフォルダに公開します。
Cscript //job:PublishRootCRLstoIIS C:\\MSSScripts\\CA\_Operations.wsf
発行証明機関サーバーを展開する
ルート CA をインストールして、その証明書を公開したら、発行 CA サーバーを展開できます。 証明書サービスのインストールでは、発行 CA、ルート CA、Active Directory、および Web サーバーの間で複雑な作業を行います。 これらの関係を次の図に示します。各作業を行う場合に、この図を参照すると便利です。
.gif)
図 5. 証明書のインストール プロセス
.gif){kind=link}
この図に示す各作業の番号の内容は、次のとおりです。
リムーバブル メディアを使用して、ルート CA 証明書と CRL を Active Directory に公開します。
リムーバブル メディアを使用して、ルート CA 証明書と CRL を Web サーバーに公開します。
証明書サービスのソフトウェアをインストールします。これにより、リムーバブル メディアを使用するルート CA への送信が必要な証明書の要求が生成されます。ルート CA ではこの要求に基づいて証明書が発行されます。
リムーバブル メディアを使用して、対応する発行 CA 証明書をインストールします。
発行 CA 証明書と CRL を Web サーバーに公開します。
x. この処理は、エンタープライズ CA のインストール ルーチン中に自動的に実行されます。
発行 CA 用の CApolicy.inf ファイルを準備する
CAPolicy.inf ファイルは、発行 CA には必要ありませんが、CA で使用されるキー サイズを変更する場合は必要になります。 Capolicy.inf ファイルは、発行 CA を設定する前に作成する必要がありますが、必要に応じて、後でファイルを追加して CA 証明書を更新することも可能です。
CAPolicy.inf ファイルを作成するには
ローカル Administrator または同等のアカウントで、発行 CA サーバーにログオンします。
メモ帳などのテキスト エディタでプレーンテキスト ファイルを作成し、次の情報を入力します。
\[Version\] Signature= “$Windows NT$” \[Certsrv\_Server\] RenewalKeyLength=2048この CA に対して CPS が定義されている場合、次の行を Capolicy.inf ファイルに書き込みます。
[CAPolicy] Policies=policyname [policyname] OID=the.org.oid URL=”https://the.org.url/TheCPSPage.htm”注 二重引用符で囲まれた部分は、組織固有の情報で置き換える必要があります。
%windir%\Capolicy.inf としてファイルを保存します (%windir% の部分は、C:\Windows などの Windows インストール フォルダへの絶対パスで置き換えます)。
証明書サービスのソフトウェア コンポーネントをインストールする
証明書サービスをルート CA にインストールする場合と同様に、この手順では、Windows Server 2003 のインストール用メディアと Windows コンポーネント ウィザードを使用する必要があります。
証明書サービスをインストールするには
ローカル Administrators グループまたは同等のグループのメンバとしてサーバーにログオンし、オプション コンポーネント マネージャを実行します。
sysocmgr /i:sysoc.inf証明書サービス コンポーネントを選択します ([OK] をクリックして名前の変更の警告メッセージ ボックスを閉じます)。
"エンタープライズの下位 CA" として CAの種類を選択して、カスタム設定を使用するようになっていることを確認します。
[公開キーと秘密キーの組] ダイアログ ボックスで、次の設定以外は既定値のままにしておきます。
キーの長さ – 2048 ビット
CSP の種類 – Microsoft Strong Cryptographic Provider
次のように情報を定義する証明機関を入力します。
CA の共通名
識別名のサフィックス
有効期間 : (親 CA により定義)
この時点で、CSP によりキー ペアが生成され、ローカル コンピュータのキー ストアに書き込まれます。
証明書データベース、データベース ログ、および構成フォルダの場所を次のように入力します (推奨)。
証明書データベース : D:\CertLog
証明書データベース ログ : %windir%\System32\CertLog
共有フォルダ : 無効
パフォーマンスと復元性を確保するために、可能であれば CA データベースとログを物理的に別のボリュームに保存します。 証明書データベースとデータベース ログは、両方ともローカルの NTFS 形式のドライブに保存します。
この時点で、証明書要求ファイルが生成されます。このファイルはディスクにコピーします。 オプション コンポーネント マネージャにより、証明書サービス コンポーネントがインストールされます。この処理には Windows Server 2003 インストール メディアが必要です。
[OK] をクリックして、IIS に関する警告を閉じ、インストールを続行します。 セットアップ ウィザードに、続行する前に親の CA 証明書が必要であることを示す通知が表示されます。
ルート CA に証明書の要求を送信する
この時点で、署名された要求に対するルート CA および発行 CA により発行された証明書に、発行 CA 証明書の要求を取得する必要があります。
ルート CA に証明書のリクエストを送信するには
証明書マネージャ グループのメンバのアカウントで、ルート CA にログオンします。
証明書要求ファイルの格納に使用するディスクが、ドライブにあることを確認します。
証明機関管理コンソールで、CA の [タスク] メニューの [新しい要求の送信] をクリックします。次に、発行 CA から転送されたリクエストを送信します。
[発行した証明書] コンテナで、新しく発行された証明書を検索して開きます。
証明書の詳細が正しいことを確認してから、[ファイルにコピー] をクリックして、この証明書をファイルにエクスポートします。 このファイルを PKCS#7 ファイルとしてディスクに保存し、オプションを選択してチェーンにすべての可能な証明書を含めます。
発行 CA の証明書情報を更新する
ルート CA 証明書は、Active Directory の信頼されたルート ストアに既に公開されているため、ここでは、この情報が発行 CA によりダウンロードされ、証明書がルート ストアに配置されたことを確認します。
発行 CA の証明書の信頼情報を更新および確認するには
ローカル管理者または同等のアカウントで、発行 CA にログオンします。
コマンド プロンプトで、次のコマンドを実行します。
certutil –pulseこれにより、CA は、信頼された新しいルート情報をディレクトリからダウンロードし、信頼されたルート ストアにルート CA 証明書を配置します。 この処理は必ずしも必要ではありませんが、作業を進める前に、前の公開の処理が正常に完了したことを確認できます。
mmc.exe を実行して、"証明書スナップイン" を追加します。
管理する証明書ストアとして "コンピュータ アカウント" を選択します。
ルート CA 証明書が、信頼されたルート証明機関のフォルダに存在することを確認します。
発行 CA に証明書をインストールする
ルート CA からの署名された応答は、既に PKCS#7 証明書パッケージとして作成されているため、発行 CA にインストールできます。 CA 証明書を Active Directory の NTAuth ストア (CA をエンタープライズ CA として特定) に公開するには、Enterprise PKI Admins グループおよびローカル Administrators グループの両方のメンバのアカウントを使用して、CA 証明書を発行 CA にインストールする必要があります。 エンタープライズ PKI Admins グループは CA 証明書をディレクトリにインストールする権限、ローカル Administrators グループは CA サーバーに証明書をインストールする権限を持っています。 前述の単純な管理モデルを使用している場合、CAAdmin の役割は、両方のグループのメンバになります。
発行 CA 証明書をインストールするには
Enterprise PKI Admins グループとローカル Administrators グループのメンバのアカウントを使用して、発行 CA にログオンします。
ルート CA により発行された署名済みの証明書が保存されているディスクを挿入します。
証明機関管理コンソールで、CA の [タスク] メニューの [証明書のインストール] をクリックし、ディスクから発行 CA 証明書をインストールします。
この時点で、CA を開始します。
発行 CA プロパティを設定する
次の手順では、環境に固有のパラメータを設定します。これらのパラメータの値は、発行 CA の必要条件のセクションに記載されています。 この処理を続ける前に、必要条件の手順で収集した組織固有の情報がルート CA の C:\MSSScripts\pkiparams.vbs ファイルに挿入済みで、これらの変更が発行 CA に転送されていることを確認しておくことが重要です。
発行 CA プロパティを設定するには
発行 CA サーバーにローカル Administrators グループのメンバとしてログオンします。
C:\MSSScripts\pkiparams.vbs の変更が、このセクションで既に説明した各環境固有の設定に一致しているかどうかを確認します。
次のスクリプトを実行します。
Cscript //job:IssCAConfig C:\\MSSScripts\\ca\_setup.wsf
発行 CA の管理役割を設定する
このガイドで説明している管理役割を使用するには、その管理役割がセキュリティ グループと対応している必要があります。 前述のように、中規模企業の多くでは簡略化された役割でも十分ですが、柔軟性を最大限に活かして責任を区分できるようにするために、このプロセスでは、詳細な役割を使用します。
発行 CA の管理役割を設定するには
発行 CA サーバーにローカル Administrators グループのメンバとしてログオンします。
証明機関管理コンソールで、[プロパティ] をクリックして CA のプロパティを編集します。
[セキュリティ] タブをクリックして、次の表のドメイン セキュリティ グループを追加し、それぞれにアクセス許可を追加します。
表 14: 発行 CA のアクセス許可
| グループ | アクセス許可 | 許可または拒否 |
|---|---|---|
| CA Admins | CA の管理 | 許可 |
| Certificate Managers | 証明書の発行と管理 | 許可 |
発行 CA 情報を公開する
証明書と CRL は発行 CA から Active Directory に自動的に公開されますが、CA 証明書と CRL の HTTP CDP および AIA パスへの公開は自動的には行われません。 CA 証明書の HTTP CDP および AIA パスへの公開を自動化するには、そのタスクを実行するようスケジュールされたジョブが必要です。
CA 証明書はほとんど更新されないため、次の手順に従って手動で AIA に公開します。
発行 CA の証明書を公開するには
公開先の Web サーバー フォルダへの書き込みアクセス許可を持つアカウントで、発行 CA にログオンします。
Web サーバー フォルダの公開先パスに一致するように C:\MSSScripts\PKIParams.vbs の WWW_REMOTE_PUB_PATH パラメータを更新します。
Web サーバーがリモート サーバー上にある場合は、Web サーバー フォルダが共有され、UNC パスがその共有フォルダに記録されていることを確認します。
Web サーバーが CA と同じサーバーにある場合には、Web サーバー フォルダのローカル パスを書き留めておきます (既定値はローカル パス C:\CAWWWPub)。
次のスクリプトを実行して、CA 証明書を Web サーバーに公開します。
Cscript //job:PublishIssCertsToIIS C:\MSSScripts\CA_Operations.wsf
注 この手順は内部 Web サーバーを念頭に設計されています。 このソリューションは、通常インターネット ファイアウォールで保護されている Windows ネットワークのファイル共有を使用するため、インターネットに接続された Web サーバーに証明書を公開する場合は、追加の手順が必要になります。
CRL は CA 証明書よりも頻繁に公開されるため、Web サーバーへ自動的に公開する方法が必要です。
CRL の公開を自動化するには
ローカル Administrators のメンバであるアカウントで発行 CA にログオンします。
このサーバーから Web サーバー フォルダにアクセスできることを確認します。
Web サーバーがリモートである場合、発行 CA にファイル システム フォルダ (アクセスの変更の許可) および共有フォルダ (共有アクセスの許可) への書き込みアクセスを許可する必要があります。 リモート Web サーバーがフォレストのメンバである場合は、エンタープライズ CA が証明書と CRL を公開できるように、ドメインの Cert Publishers グループを使用してアクセス許可を付与します。
次のコマンドを実行して、CRL をコピーするようにスケジュールしたジョブを作成します。
注 次のコードの抜粋は、読みやすくするために一部を複数行で表示していますが、 実際は 1 行で入力する必要があります。
schtasks /creat /tn “Publish CRLs” /tr “cscript.exe //job:PublishIssCRLsToIIS C:\ MSSScripts\CA_Operations.wsf” /sc Hourly /ru “System”
不要な発行 CA テンプレートを削除する
使用されない証明書に対応するテンプレートは、一般的に削除することをお勧めします。これにより、不要な証明書が誤って発行されるのを防ぐことができます。 これらのテンプレートはディレクトリ内に常にあるため、必要に応じて簡単に再作成できます。
発行 CA から不要なテンプレートを削除するには
CA Admins ドメイン グループのメンバとしてログオンします。
証明機関管理コンソールで、証明書テンプレートのコンテナを選択します。
次のテンプレートの種類を削除します。
EFS 回復エージェント
基本 EFS
Web サーバー
コンピュータ
ユーザー
下位の証明機関
管理者
インターネット認証
このセクションには、このガイドで説明するセキュリティ保護された WLAN ソリューションに対応するための、RADIUS インフラストラクチャの実装に役立つ詳細情報が記載されています。 このガイドで実装されている RADIUS インフラストラクチャは、Windows Server 2003 インターネット認証サーバー (IAS) に基づいています。
RADIUS インフラストラクチャの設計
次の表は、このガイドで述べている必要な情報を収集するためのワークシートとして使用できます。 この情報の中には、このガイドに付属しているスクリプトを使用して設定するものや、対応するセクションの内容に従って手動で設定するものがあります。
ユーザー定義の構成情報の必要条件
次の表は各組織に固有の情報の一覧です。 作業を進める前に、これらの情報が収集、決定、および記録されていることを確認します。
表 15. ユーザー定義の構成設定
| 構成項目 | 設定 |
|---|---|
| Active Directory フォレストのルート ドメインの DNS 名 | |
| ドメインの NetBIOS 名 | |
| プライマリ IAS サーバー名 | |
| セカンダリ IAS サーバー名 |
| 構成項目 | 設定 |
|---|---|
| IAS の構成を制御する管理グループの完全な名前 | IAS Admins |
| IAS 認証とアカウンティング要求のログを確認するグループの完全な名前 | IAS Security Auditors |
| インストール スクリプトのパス | C:\MSSScripts |
| IAS 構成のエクスポート バッチ ファイル | IASExport.bat |
| IAS 構成のインポート バッチ ファイル | IASImport.bat |
| IAS RADIUS クライアント構成のエクスポート バッチ ファイル | IASClientExport.bat |
| IAS RADIUS クライアント構成のインポート バッチ ファイル | IASClientImport.bat |
| 構成バックアップ ファイルのパス | D:\IASConfig |
| IAS 認証および監査要求ログの場所 | D:\IASLogs |
| RADIUS 要求ログの共有名 | IASLogs |
マルチドメイン環境では、これらのグループは IAS サーバーが置かれるドメインと同じドメインに作成されます。
必要なグループを作成したら、これらのグループが IAS 構成タスクを実行できるように、次の手順で構成する必要があります。
IAS Admins ドメイン グローバル グループを、各 IAS サーバー上のローカル Administrators グループに追加します。
IAS がドメイン コントローラにインストールされている場合は、IAS Admins グループをドメインの Administrators グループに追加する必要があります。
IAS Admins と IAS Security Auditors のグループには、適切なユーザー アカウントを割り当てる必要があります。
サーバー システム セキュリティ設定を構成する
前述のように、このガイドでは、多くの中規模企業が既にサーバー強化の手順とポリシーを確立していることを前提としています。 そのため、このソリューションで必要なサーバーをセキュリティで保護するプロセスについては詳細に説明しません。 サーバー強化のポリシーまたは手順が確立されていない場合や、IAS サーバーのセキュリティ保護に関する詳細情報が必要な場合は、『Windows 2003 セキュリティ ガイド』を参照してください。
IAS をインストールおよび構成する
ここでは、IAS のサーバーへのインストール方法について説明します。 インストールと構成の各手順は、指示に従って、それぞれの IAS サーバーで実行することが重要です。
IAS をインストールするには、Windows オプション コンポーネント マネージャでネットワーク サービス、インターネット認証サービス コンポーネントを選択します ([コントロール パネル] の [Windows コンポーネントの追加と削除] からアクセス可能)。 プロセスを簡略化するため、次のスクリプトを使用します。
sysocmgr /i:sysoc.inf /u:C:\MSSScripts\OC_AddIAS.txt
**Active Directory で IAS を登録する**
IAS サーバーは、認証が必要となるドメイン内で、それぞれの IAS サーバーのコンピュータ アカウントを RAS および IAS サーバー セキュリティ グループのメンバとし、登録する必要があります。 このグループのメンバになることにより、ドメイン内のすべてのユーザーやコンピュータ アカウントのプロパティをリモートからアクセスして読み取るために必要なアクセス許可が IAS サーバーに付与されます。
**Active Directory で IAS を登録するには**
1. IAS サーバーを登録する必要があるドメインに対してドメイン管理者権限を持つアカウントで、それぞれの IAS サーバーにログオンします。
2. 既定のドメインには、コマンド プロンプトで次のコマンドを実行します。
`netsh ras add registeredserver`
3. 既定のドメイン以外には、コマンド プロンプトで次のコマンドを実行します。
`netsh ras add registeredserver domain = DomainName`
**注** IAS サーバー コンピュータ オブジェクトは、Active Directory ユーザーとコンピュータ MMC スナップインを使用して、RAS および IAS サーバー セキュリティ グループに追加することもできます。
**IAS データ ディレクトリを作成およびセキュリティ保護する**
IAS サーバーに構成データとログ データを格納するには、いくつかのディレクトリ要件があります。 これらのディレクトリの作成および保護の構成プロセスを容易に行うには、コマンド プロンプトで次のバッチ ファイルを実行します。
`C:\\MSSScripts\\IAS\_Data.bat`
**注** このバッチファイルを実行する前に、%*DomainName*% エントリを編集および置換し、特定の環境の NETBIOS ドメイン名をこのバッチファイルに反映させる必要がある場合もあります。
###### プライマリ IAS サーバーを構成する
プライマリ IAS サーバーとして動作するように選択したサーバーは、以降のすべての IAS サーバーの設定を構成するテンプレートとして機能するため、環境内の他の IAS サーバーよりも前に構成する必要があります。
**認証要求とアカウンティング要求のログを記録する**
既定では、IAS は RADIUS 認証およびアカウンティング要求のログを記録しますが、セキュリティ イベントを記録し、調査が必要な場合に利用できるように有効にする必要があります。
**認証およびアカウンティング要求のログを設定するには**
1. \[インターネット認証サービス\] MMC スナップインで、\[リモート アクセスのログ\] をクリックし、\[ローカル ファイル\] のプロパティを表示して \[ログの作成方法\] を表示します。
2. アカウンティング要求と認証要求を選択します。
3. ログ ファイルのディレクトリが D:\\IASLogs に設定されていること、および \[データベース互換\] 形式が選択されていることを確認してください (これにより、ログを Microsoft SQL Server™ などのデータベースに直接インポートできます)。
##### WLAN 802.1X 認証
ここでは Windows Server 2003 および Windows XP SP1 プラットフォームでの 802.1X プロトコル仕様を使用した WLAN セキュリティの実装プロセスについて説明します。 この説明には、Active Directory グループの構成、X.509 証明書の展開、IAS サーバーの設定変更、WLAN グループ ポリシーの展開に関する情報が含まれており、このガイドが基本とする 802.1X EAP-TLS の実装をサポートするワイヤレス アクセス ポイントの設定に関するヒントも含まれています。
###### セキュリティで保護された WLAN の環境を準備する
これで、基本となる証明書および RADIUS インフラストラクチャが設定されたため、実際の 802.1X 固有の設定手順を実行できます。 次の必要条件の設定についてまとめた表は、実際の実装前に必要となる情報収集プロセスに役立ちます。 この設定の中には手動で有効にするものがあり、その他の設定はこのガイドで提供するスクリプトの一部となっています。
**ユーザー定義の構成設定の必要条件**
次の表は、セキュリティ保護された WLAN の実装のこのフェーズを続ける前に、収集および決定する必要がある組織固有のパラメータの一覧です。 空欄はそれぞれの環境固有の設定を記録するために使用できます。
**表 17. ユーザー定義の設定の必要条件**
<p> </p>
<table style="border:1px solid black;">
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th style="border:1px solid black;" >構成項目</th>
<th style="border:1px solid black;" >設定</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="border:1px solid black;">Active Directory フォレストのルート ドメインの DNS 名</td>
<td style="border:1px solid black;"> </td>
</tr>
<tr class="even">
<td style="border:1px solid black;">NetBIOS ドメイン名</td>
<td style="border:1px solid black;"> </td>
</tr>
<tr class="odd">
<td style="border:1px solid black;">プライマリ IAS サーバー名</td>
<td style="border:1px solid black;"> </td>
</tr>
<tr class="even">
<td style="border:1px solid black;">セカンダリ IAS サーバー名</td>
<td style="border:1px solid black;"> </td>
</tr>
</tbody>
</table>
**ソリューション定義の構成設定の必要条件**
次の表は、特に必要でない限り、変更する必要のない設定の一覧です。 必要なスクリプトの変更を含むこれらのパラメータを変更する前に、変更による影響または依存関係を完全に理解および想定していることを確認します。
**表 18. ソリューション定義の構成の設定**
<p> </p>
<table style="border:1px solid black;">
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th style="border:1px solid black;" >構成項目</th>
<th style="border:1px solid black;" >設定</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="border:1px solid black;">802.1X ユーザー認証証明書の展開を制御する Active Directory グローバル グループ</td>
<td style="border:1px solid black;">AutoEnroll Client Authentication – User Certificate</td>
</tr>
<tr class="even">
<td style="border:1px solid black;">802.1X コンピュータ認証証明書の展開を制御する Active Directory グローバル グループ</td>
<td style="border:1px solid black;">AutoEnroll Client Authentication – Computer Certificate</td>
</tr>
<tr class="odd">
<td style="border:1px solid black;">802.1X 認証証明書を必要とする IAS サーバーを含む Active Directory グローバル グループ</td>
<td style="border:1px solid black;">AutoEnroll RAS and IAS Server Authentication Certificate</td>
</tr>
<tr class="even">
<td style="border:1px solid black;">ワイヤレス ネットワークへのアクセスを許可されているユーザーを含む Active Directory グローバル グループ</td>
<td style="border:1px solid black;">Remote Access Policy – Wireless Users</td>
</tr>
<tr class="odd">
<td style="border:1px solid black;">ワイヤレス ネットワークへのアクセスを許可されているコンピュータを含む Active Directory グローバル グループ</td>
<td style="border:1px solid black;">Remote Access Policy – Wireless Computers</td>
</tr>
<tr class="even">
<td style="border:1px solid black;">Wireless Users グループと Wireless Computers グループの両方を含む Active Directory ユニバーサル グループ</td>
<td style="border:1px solid black;">Remote Access Policy – Wireless Access</td>
</tr>
<tr class="odd">
<td style="border:1px solid black;">ワイヤレス ネットワークのプロパティの構成が必要なコンピュータを含む Active Directory グローバル グループ</td>
<td style="border:1px solid black;">Wireless Network Policy – Computer</td>
</tr>
<tr class="even">
<td style="border:1px solid black;">ユーザー クライアント認証用の証明書を生成するために使用される証明書テンプレート</td>
<td style="border:1px solid black;">Client Authentication – User</td>
</tr>
<tr class="odd">
<td style="border:1px solid black;">コンピュータ クライアント認証用の証明書を生成するために使用される証明書テンプレート</td>
<td style="border:1px solid black;">Client Authentication – Computer</td>
</tr>
<tr class="even">
<td style="border:1px solid black;">IAS で使用されるサーバー認証証明書を生成するために使用される証明書テンプレート</td>
<td style="border:1px solid black;">RAS and IAS Server Authentication</td>
</tr>
<tr class="odd">
<td style="border:1px solid black;">インストール スクリプトのパス</td>
<td style="border:1px solid black;">C:\MSSScripts</td>
</tr>
<tr class="even">
<td style="border:1px solid black;">構成バックアップ ファイルのパス</td>
<td style="border:1px solid black;">D:\IASConfig</td>
</tr>
<tr class="odd">
<td style="border:1px solid black;">IAS 認証および監査ログのパス</td>
<td style="border:1px solid black;">D:\IASLogs</td>
</tr>
<tr class="even">
<td style="border:1px solid black;">ポリシー名</td>
<td style="border:1px solid black;">Allow Wireless Access</td>
</tr>
<tr class="odd">
<td style="border:1px solid black;">Active Directory GPO 名</td>
<td style="border:1px solid black;">Wireless Network Policy</td>
</tr>
<tr class="even">
<td style="border:1px solid black;">上記 GPO 内のワイヤレス ネットワーク ポリシー</td>
<td style="border:1px solid black;">Client Computer Wireless Configuration</td>
</tr>
</tbody>
</table>
**WLAN アクセスに必要な Active Directory グループを作成する**
ワイヤレス認証証明書登録、リモート アクセス ポリシー、およびワイヤレス ネットワーク グループ ポリシーの実装に必要なグループを作成するため、次のスクリプトは Active Directory セキュリティ グループを作成するアクセス許可を持つアカウントで実行する必要があります。
`C:\\MSSScripts\\wl\_tools.wsf`
**注** マルチドメイン構成のフォレスト環境では、このグループをワイヤレス ユーザーと同じドメインに作成する必要があります。
**DHCP 設定を確認する**
ワイヤレス ネットワークに対応するには、ワイヤレス固有のスコープで DHCP サーバーを構成し、ワイヤード (有線) クライアントより短い IP アドレスのリース時間を設定する必要があります。 次に、DHCP サーバー管理者に連絡して、DHCP サーバーが適切に構成されていることを確認します。 ワイヤレス LAN の DHCP 計画の詳細については、「[Windows Server 2003 Deployment Kit](https://www.microsoft.com/windowsserver2003/techinfo/reskit/deploykit.mspx)」(英語) を参照してください。
###### WLAN 認証証明書を構成する
このガイドで説明している EAP-TLS ベースの WLAN セキュリティを実装するには、次の種類の証明書を作成および展開する必要があります。
- Client Authentication – Computer
- Client Authentication – User
- RAS and IAS Server Authentication
**IAS サーバー認証の証明書テンプレートを作成する**
EAP-TLS プロトコル ハンドシェイク中に、クライアントに対してコンピュータを認証するには、IAS サーバーにサーバー証明書が必要です。 証明書サービス管理者は、次の手順を実行して、IAS サーバーで使用できる認証証明書テンプレートを作成する必要があります。
**サーバー認証の証明書テンプレートを作成するには**
1. CA 管理グループのアカウントで発行 CA にログオンし、証明書テンプレート MMC を実行します。
2. RAS および IAS サーバーの証明書テンプレートの複製を作成します。 \[新しいテンプレートのプロパティ\] の \[全般\] タブで、\[テンプレート表示名\] フィールドに「RAS and IAS Server Authentication」と入力します。
3. \[拡張機能\] タブで、発行ポリシーに \[サーバー認証\] (OID 1) のみが含まれていることを確認します。
4. さらに \[拡張機能\] タブで、発行ポリシーを編集し、\[中保証\] ポリシーを追加します。
5. \[サブジェクト名\] タブで、\[Active Directory の情報から構築する\] を選択します。 また、\[サブジェクト名の形式\] が \[共通名\] に設定されており、\[代わりのサブジェクト名に次の情報を含める\] で、\[DNS 名\] のみが選択されていることを確認します。
6. \[要求処理\] タブで、\[CSP\] をクリックし、\[以下の CSP のどれか 1 つ\] が選択されていること、および \[Microsoft RSA SChannel Cryptographic Provider\] のみが選択されていることを確認します。
7. \[セキュリティ\] タブで、\[読み取り\]、\[登録\]、および \[自動登録\] のアクセス許可を持つ **AutoEnroll RAS and IAS Server Authentication Certificate** セキュリティ グループを追加し、この証明書テンプレートを登録または自動登録するアクセス許可を持つ他のグループをすべて削除します。
**注** セキュリティ上、比較的有用性が高いと考えられるため、この証明書を証明書マネージャの承認を要求するように設定することは有用です。 この値を有効にすることで承認されていない IAS サーバーが登録されないようにすることができますが、証明書が発行され、自動で IAS サーバーから送られた後、手動で承認する必要があります。
**ユーザー認証の証明書テンプレートを作成する**
エンド ユーザーは、EAP-TLS ハンドシェイク中に IAS サーバーを認証するためのユーザー証明書が必要です。 証明書サービス管理者として指定されたアカウント所有者は次の手順で進める必要があります。
**ユーザー認証の証明書テンプレートを作成するには**
1. 発行 CA サーバーで証明書テンプレート MMC スナップインを起動します。
2. 認証済みセッション テンプレートの複製を作成し、新規テンプレートの\[全般\] タブで、\[テンプレート表示名\] フィールドに「Client Authentication – User」と入力します。
3. \[要求処理\] タブで、\[CSP\] を選択し、\[Microsoft BaseDSS Cryptographic Provider\] チェック ボックスをオフにします。
4. \[サブジェクト名\] タブで、\[Active Directory の情報から構築する\] が選択されていることを確認します。 \[サブジェクト名の形式\] で \[共通名\] を選択します。 \[代わりのサブジェクト名に次の情報を含める\] で、\[ユーザー プリンシパル名(UPN)\] のオプションのみが選択されていることを確認します。
5. \[拡張機能\] タブで、\[アプリケーション ポリシー\] に \[クライアント認証\] (OID 2)のみが含まれていることを確認します。 また、発行ポリシーを編集し、\[低保証\] ポリシーを追加します。
6. \[セキュリティ\] タブで、\[読み取り\]、\[登録\]、および \[自動登録\] のアクセス許可を持つ **AutoEnroll Client Authentication – User Certificate** セキュリティ グループを追加します。 また、登録または自動登録するアクセス許可を持つ他のグループをすべて削除する必要があります。
**コンピュータ認証の証明書テンプレートを作成する**
この証明書は IAS サーバーの認証時に EAP-TLS ハンドシェイク中にコンピュータが使用します。 証明書サービス管理者は次のタスクを実行する必要があります。
**コンピュータ認証の証明書テンプレートを作成するには**
1. 発行 CA サーバーで、証明書テンプレート MMC スナップインを起動します。
2. ワークステーション認証テンプレートの複製を作成します。 新しいテンプレートの\[全般\] タブで、\[テンプレート表示名\] フィールドに「Client Authentication – Computer」 と入力します。
3. \[サブジェクト名\] タブで、\[Active Directory の情報から構築する\] が選択されていることを確認します。 \[サブジェクト名の形式\] で \[共通名\] を選択します。 \[代わりのサブジェクト名に次の情報を含める\] で、\[DNS 名\] のオプションのみが選択されていることを確認します。
4. \[拡張機能\] タブで、アプリケーション ポリシーを編集し、\[クライアント認証\] (OID 2) のみが含まれていることを確認します。 また、発行ポリシーを編集し、\[低保証\] ポリシーを追加します。
5. \[セキュリティ\] タブで、\[読み取り\]、\[登録\]、および \[自動登録\] のアクセス許可を持つ AutoEnroll Client Authentication – Computer Certificateセキュリティ グループを追加します。 アクセス許可を持つ他のグループはすべて削除する必要があります。
**CA に WLAN 認証証明書を追加する**
これで認証書テンプレートの構成が終了しました。登録を有効にするため、証明書テンプレートを CA に追加する必要があります。 そのため、証明書サービス管理者は次のタスクを実行する必要があります。
**CA に証明書テンプレートを追加するには**
- 発行 CA で、証明機関 MMC スナップインを起動し、\[証明書テンプレート\] フォルダを右クリックして、\[新規作成\] をクリックします。次に \[発行する証明書テンプレート\] をクリックします。 次の証明書を選択し、\[OK\] をクリックします。
- Client Authentication – Computer
- Client Authentication – User
- RAS and IAS Server Authentication
**IAS サーバー証明書を登録する**
サーバー認証証明書の IAS サーバーへの展開は、比較的簡単で自動化されています。
**IAS サーバーを登録するには**
1. Active Directory ユーザーとコンピュータ MMC スナップインを起動して、IAS コンピュータ アカウントを AutoEnroll RAS and IAS Server Authentication Certificate セキュリティ グループに追加します。
2. IAS サーバーを再起動し、ローカル Administrators グループのメンバとしてログオンします。
3. コマンド プロンプトで、GPUPDATE /force を実行します。
4. MMC を開き、証明書スナップインを追加します。 メッセージが表示されたら、\[コンピュータ アカウント\] オプションを選択し、\[ローカル コンピュータ\] を選択します。
5. コンソール ツリーから \[証明書 (ローカル コンピュータ)\] を選択し、\[操作\] メニューの \[すべてのタスク\] をクリックし、\[証明書を自動登録する\] をクリックします。
**注** 証明書マネージャの承認を必要とするオプションが有効になっている場合、CA 管理者はその要求の正当性を確認し、証明書を発行する必要があります。
**自動登録用のグループにユーザーとコンピュータを追加する**
WLAN 接続が必要なユーザーとコンピュータを認証し、ワイヤレス接続でネットワークにアクセスできるようにするには、ユーザーとコンピュータの証明書を発行する必要があります。 これらの証明書の発行および更新のプロセスは、設定済みの自動登録グループにより、エンド ユーザーに対して透過的です。
自動登録グループにユーザーとコンピュータを追加するには、Active Directory ユーザーとコンピュータ MMC スナップインを使用して、ユーザー アカウントを AutoEnroll Client Authentication – User Certificate グループに追加し、コンピュータを AutoEnroll Client Authentication – Computer Certificate グループに追加します。 終了後、コンピュータを再起動してネットワークに再度ログオンすると、該当のユーザーにユーザーとコンピュータの証明書が発行されます。
**注** このソリューションでは、カスタム グループを使用して、証明書を受け取ることができるユーザーとコンピュータを制御します。 すべてのユーザーとコンピュータに証明書が必要な場合は、Domain Users を AutoEnroll Client Authentication – User Certificate グループに追加し、Domain Computers を AutoEnroll Client Authentication –Computer Certificate グループに追加します。
###### WLAN アクセス インフラストラクチャを構成する
プライマリ IAS サーバーに、WLAN へアクセスするワイヤレス クライアントの認証と承認を決定するリモート アクセス ポリシーと接続要求設定を構成する必要があります。 これらの設定は他の IAS サーバーにも複製する必要があります。さらに、ワイヤレス アクセス ポイントなどの RADIUS クライアントから接続できるように、各 IAS サーバーを一意に構成する必要があります。 この後、ワイヤレス アクセス ポイント自体が IAS サーバーを 802.1X ネットワークへの認証および承認のソースとして使用するように構成する必要があります。
**WLAN の IAS リモート アクセス ポリシーを作成する**
プライマリ IAS サーバーのインターネット認証サービス MMC スナップインを使用して、次のように IAS にリモート アクセス ポリシーを構成します。
**リモート アクセス ポリシーを作成するには**
1. \[リモート アクセス ポリシー\] フォルダを右クリックし、新しいリモート アクセス ポリシーを作成するメニューを選択します。
2. 新しいポリシーに "Allow Wireless Access"という名前を付け、ウィザードで \[一般的なシナリオ用の標準ポリシーを設定する\] を選択します。
3. アクセス方法として \[ワイヤレス\] を選択します。
4. グループに基づいてアクセス許可を付与し、Remote Access Policy – Wireless Access セキュリティ グループを使用します。
5. Extensible Authentication Protocol (EAP) の種類として \[スマート カードまたはその他の証明書\] を選択し、次に IAS にインストールされているサーバー認証証明書を選択します。
6. ウィザードを終了します。
7. Allow Wireless Access ポリシーのプロパティを開き、\[プロファイルの編集\] をクリックします。
8. \[詳細設定\] タブで、Ignore-User-Dialin-Properties 属性を追加し、それを"True"に設定します。次に Termination-Action 属性を追加し、それを"RADIUS 要求"に設定します。
**注** Allow Wireless Access ポリシーはユーザーが作成したポリシーや既定のアクセス ポリシーと共存することができますが、正常に機能させるため、既定のリモート アクセス ポリシーは \[リモート アクセス ポリシー\] フォルダの Allow Wireless Access ポリシーの後に置く必要があります。
**IAS に RADIUS クライアントを追加する**
RADIUS プロトコルで認証およびアカウンティング サービスを利用できるようにするには、ワイヤレス アクセス ポイントと RADIUS プロキシを RADIUS クライアントとして IAS に追加する必要があります。
**IAS に RADIUS クライアントを追加するには**
1. インターネット認証サーバー MMC スナップインを起動します。
2. \[RADIUS クライアント\] フォルダを右クリックし、\[新しい RADIUS クライアント\] をクリックします。
3. ワイヤレス アクセス ポイントのフレンドリ名と IP アドレスを入力します。
4. クライアント製造元の属性で RADIUS の標準を選択し、このワイヤレス AP 用の共有シークレットを入力します。 その後、\[要求はメッセージ認証属性を含んでいる必要がある\] を選択します。
**注** このプロセスは各 IAS サーバーに対して行い、それぞれのサーバーに一意のワイヤレス アクセス ポイント クライアントと共有シークレットがあることを確認する必要があります。 このプロセスを簡略化するため、このガイドには共有シークレットの生成に使用できるスクリプトが用意されています。システムの復元が必要になった場合に備えて、共有シークレットは安全な場所に格納できます。 このスクリプトを使用するには、コマンド プロンプトで次のコマンドを実行します。
```
Cscript //job:GenPWD
C:\MSSScripts\wl_tools.wsf /client:ClientName
```
###### 複数の IAS サーバーに構成を展開する
プライマリ IAS サーバーで次の項目を設定したら、**netsh** コマンドを使用してテキスト ファイルにエクスポートできます。 エクスポートしたテキスト ファイルは、環境内で同様の役割を持つ各 IAS サーバーにインポートできるため、環境内の構成が共通になります。
エクスポート可能な構成設定は、次のとおりです。
- サーバー設定
- ログ設定
- リモート アクセス ポリシー
- RADIUS クライアント
- 構成全体
各 IAS サーバーの RADIUS クライアントと共有シークレットのリストは一意になるため、この情報はそれぞれのサーバーで個々に構成し、個別にバックアップしておく必要があります。 また、完全な構成ダンプには、重要な機密情報が格納されています。この情報が盗まれると、ワイヤレス ネットワークへのアクセスに使用できるため、注意して保護する必要があります。
**プライマリ IAS サーバー構成をエクスポートする**
他の IAS サーバーに複製するには、次の設定をテキスト ファイルにエクスポートする必要があります。
- サーバー構\\成
- ログ設定
- リモート アクセス ポリシー
- 接続要求ポリシー
このプロセスを簡略化するため、このガイドには、**netsh** コマンドを含むバッチ ファイルが用意されています。コマンド プロンプトで次のバッチ ファイルを実行すると、共通の構成情報を D:\\IASConfig ディレクトリのテキスト ファイルにエクスポートできます。
<codesnippet language displaylanguage containsmarkup="false">C:\\MSSScripts\\IASExport.bat
プライマリ IAS サーバーから構成情報をインポートする
前述のように、IAS では netsh コマンドを使用してサーバー間で構成状態を転送します。 このプロセスにより、効率的な展開が可能になり、構成プロセス中のエラー発生を減らすことができます。 プライマリ IAS サーバーの構成情報をエクスポートしたら、次に、セカンダリ IAS サーバーに構成状態をインポートします。
プライマリ IAS の構成状態を他の IAS サーバーにインポートするには
プライマリ IAS サーバーの D:\IASConfig ディレクトリにあるすべての構成ファイルを、別の IAS サーバーの対応する D:\IASConfig ディレクトリにコピーします。
次のバッチ ファイル (このガイドで提供) をセカンダリ サーバーのコマンド ラインで実行して構成状態をインポートします。
C:\\MSSScripts\\IASImport.bat
ワイヤレス アクセス ポイントおよびクライアント
ワイヤレス アクセス ポイントを構成する手順は、対象となるデバイスの製造元やモデルによって大きく異なります。 ただし、一般にワイヤレス AP のベンダは、次の項目についてデバイスを構成する詳細な手順を用意しています。
802.1X ネットワーク設定
プライマリ RADIUS サーバー アドレスの構成
セカンダリ RADIUS サーバー アドレスの構成
プライマリ RADIUS サーバーと共有される RADIUS シークレット
セカンダリ RADIUS サーバーと共有される RADIUS シークレット
特定のブランドやモデルのワイヤレス機器の設定手順については、ベンダの説明書またはサポート Web サイトを参照してください。
WLAN 認証証明書を展開する
ここでは、Windows XP ベースのクライアントで自動証明書登録を有効化するために必要となる、重要な構成タスクについて説明します。 前のセクションでは、ポリシーとテンプレートを有効化して証明書インフラストラクチャの証明書自動登録をサポートする方法について述べましたが、Windows XP のこの機能のサポートは既定では無効になっています。 証明書自動登録のサポートを有効にするには、グループ ポリシーを使用して正確に設定する必要があります。 セキュリティ グループを使用して自動登録を制御すると、ドメイン内のすべてのユーザーとコンピュータで自動登録機能を使用できるようになり、各タイプの証明書を受け取るユーザーをセキュリティ グループで設定できます。
ドメイン内のすべてのユーザーとコンピュータに自動登録を許可するには
GPO を作成するアクセス許可と GPO をドメインにリンクするアクセス許可を持つするアカウントを使用してログオンします。
Active Directory ユーザーとコンピュータで、ドメイン オブジェクトを選択して右クリックし、[プロパティ] をクリックします。
[グループ ポリシー] タブで、[新規作成] をクリックして、GPO の名前 (「ドメイン PKI ポリシー」など) を入力します。
[編集] をクリックし、[コンピュータの構成]、[Windows の設定]、[セキュリティの設定] を選択して、その下の [公開キーのポリシー] を選択します。
[詳細] ペインで、[自動登録の設定] をダブルクリックします。
次の項目が選択されていることを確認します。
証明書を自動的に登録する
有効期限が切れた証明書を更新、保留中の証明書を更新、および破棄された証明書を削除する
証明書テンプレートを使用する証明書を更新する
ユーザーの自動登録の設定のために、"コンピュータの構成\Windows の設定\セキュリティの設定\公開キー ポリシー" で手順 5 と 6 を繰り返します。
GPO を閉じます。
その GPO の優先順位が、既定のドメイン ポリシー GPO より高いことを確認します。
このプロセスを各ドメインで繰り返します。これらのドメインがマルチドメイン フォレストにある場合は、証明書自動登録が有効になります。
注 ユーザーが移動プロファイルを使用せず、自動登録が全面的に許可されている場合、証明書はユーザーがログオンしているすべてのコンピュータに発行されます。 これは、管理ユーザーがサーバーにログオンする場合に不要になる場合があります。 これを防止するには、サーバーに対して GOP を作成して、自動登録を無効にすることをお勧めします。 また、すべてのユーザーが自動登録できると不都合な場合、自動登録が必要なユーザーのサブセットを含んだ OU に GPO をリンクさせることができます。
ユーザーとコンピュータが WLAN にアクセスできるようにする
ユーザーとコンピュータが WLAN にセキュリティで保護された状態でアクセスできるようにする最後の手順には、Active Directory オブジェクトに対して実行する必要のある操作も含まれます。 これらの操作には、アカウント許可の変更、グループのアクセス許可の変更、および WLAN グループ ポリシー設定の実装などがあります。
リモート アクセス ポリシー グループにユーザーを追加する
IAS ベースのリモート アクセス ポリシーは、Active Directory ベースのセキュリティ グループを使用して、ユーザーとコンピュータが WLAN への接続の確立を承認されているかどうかを判別します。 前述のセクションで作成済みのセキュリティ グループは次のとおりです。
Remote Access Policy – Wireless Users
Remote Access Policy – Wireless Computers
Remote Access Policy – Wireless Access
ユーザーとコンピュータを WLAN アクセス グループに追加するには
Active Directory ユーザーとコンピュータ MMC スナップインを開きます。
Remote Access Policy – Wireless Users グループを追加し、Remote Access Policy – Wireless Computers グループを Remote Access – Wireless Access グループに追加します。
WLAN へのアクセスが許可されたユーザーを Remote Policy – Wireless Users グループに追加します。
WLAN へのアクセスが許可されたコンピュータを Remote Policy – Wireless Users グループに追加します。
注 すべてのユーザーとコンピュータに既定で WLAN へのアクセスを許可することを優先する場合、Domain Users と Domain Computers グループを対応するポリシー グループに追加することで管理を簡略化できます。
Active Directory WLAN グループ ポリシーを作成する
グループ ポリシーを使用すると、802.1X および 802.11 標準に関連したワイヤレス ネットワーク ポリシーの設定を含む Windows Server 2003 のグループ ポリシー MMC として、クライアント コンピュータの WLAN 構成を自動で実行できます。
ワイヤレス ネットワーク グループ ポリシーを作成するには
Windows Server 2003 を使用したサーバーまたは Windows Server 2003 Administration ツールをインストールしたワークステーションで、Active Directory ユーザーとコンピュータ MMC スナップインを開きます。
[グループ ポリシー] タブで、ドメイン オブジェクトのプロパティを選択し、[新規作成] をクリックして、GPO の [ワイヤレス ネットワーク ポリシー] に名前を付けます。
[プロパティ] をクリックし、[セキュリティ] タブで Wireless Network Policy – Computer security グループに、[読み取り] および [グループ ポリシーの適用] のアクセス許可を付与します。 また、[グループ ポリシーの適用] アクセス許可を GPO の Authenticated Users から削除します。
[全般] タブで、ポリシー オブジェクトについて [ユーザーの構成の設定を無効にする] を選択し、表示される警告メッセージで [はい] を選択します。 変更を適用し、GPO のプロパティ ウィンドウを閉じます。
[編集] をクリックし、[コンピュータの構成]、[Windows の設定]、[セキュリティの設定]、[ワイヤレス ネットワーク (IEEE 8011) ポリシー] を選択します。
ナビゲーション ウィンドウで、[ワイヤレス ネットワーク (IEEE 8011) ポリシー] オブジェクトを選択し、次に [アクション] メニューの [ワイヤレス ネットワーク ポリシーの作成] をクリックします。 ウィザードを使用して、ポリシーに "Client Computer Wireless Configuration"という名前を付けます。 [プロパティの編集] オプションが選択されている状態で、[終了] をクリックしてウィザードを閉じます。
Client Computer Wireless Configurationポリシーの [優先するネットワーク] タブで、[追加] を選択し、ワイヤレス ネットワークのネットワーク名またはサービス セット識別子 (SSID) を入力します。
[IEEE 801X] タブをクリックし、[スマート カードまたはその他の証明書] の EAP 設定を開きます。 [信頼されたルート証明機関] で IAS サーバー証明書を発行した PKI のルート CA 証明書を選択します。
Client Computer Wireless Configuration のプロパティとグループ ポリシー オブジェクト エディタを閉じます。
注 現在 WPA2 は GPO の使用に対応していません。 しかし、WPA2 の GPO は Windows Vista および Longhorn ではサポートされる予定で、現在リリースされている Windows に関しても更新プログラムの提供が予定されています。
WLAN グループ ポリシーのセキュリティ グループにコンピュータを追加する
Active Directory ベースのセキュリティ グループを使用して、802.11 および 802.1X の設定を自動的に構成するためのワイヤレス ネットワーク ポリシーが適用されているコンピュータを判別します。 この設定は、ワイヤレス アクセス ポイントに 802.1X を設定して WLAN を有効にする前に展開する必要があります。 これにより、クライアント コンピュータがワイヤード (有線) ネットワークに接続する機会が少ない場合でも、クライアント コンピュータはコンピュータベースのグループ ポリシーをダウンロードして適用する機会を得ることができます。
WLAN ネットワーク インターフェイス アダプタ (nic) をインストールすると、正しいワイヤレス ネットワーク グループ ポリシーが自動的に取得されて適用されるため、グループ ポリシーの設定は、WLAN ネットワーク インターフェイス アダプタ (nic) をインストールする前でも適用できます。
ワイヤレス ネットワーク グループ ポリシーのグループにコンピュータを追加するには、Active Directory ユーザーとコンピュータ MMC スナップインを使用して、認証されたコンピュータ オブジェクトを Wireless Network Policy – Computer group に追加します。
注 クライアント コンピュータのワイヤレス ネットワーク GPO 設定は、次のコンピュータ グループ ポリシーの更新期間中に更新されるため、注意が必要です。 更新するには、GPUPDATE /force コマンドを実行します。
WPA2 クライアント要件
このガイドで説明しているソリューションは、Windows XP Professional SP2 または Windows XP Tablet Edition を使用するワイヤレス対応のクライアント コンピュータ用に設計されています。 これらのバージョンの Windows は、組み込み 802.1X と WLAN をサポートしています。 また、Windows XP ベースのクライアントには証明書の自動登録と更新機能があり、証明書インフラストラクチャと併用した場合、このような証明書ベースのソリューションで特に費用対効果が上がります。
Windows XP SP2 では、WPA の組み込みサポートが提供されますが、Windows XP SP2 ベースのクライアントで IEEE 802.11i WPA2 を有効にするには、追加の更新プログラムをインストールする必要があります。 追加の更新プログラムとダウンロードの手順の詳細については、の「Service Pack 2 で Windows XP のワイヤレス提供サービス情報要素 (WPS IE) アップデートが入手できる Wi-Fi 保護アクセス 2 (WPA2)」を参照してください。
まとめ
従来のワイヤレス セキュリティ標準が業界標準に使用されなくなった理由を検討すると同時に、それらの脆弱性に対処するための無数のソリューションを検討することで、中規模のビジネス環境におけるワイヤレス ネットワークのセキュリティを向上させるソリューションが明確になりました。 これで、中規模企業はこのような有用性の高い技術を効率的に導入することが可能となり、このガイドで提供している証明書サービス ソリューションを備えた WPA または WPA2 の EAP-TLS を利用することによって、信頼性と安全性が高まり、企業の生産性は大幅に向上します。 このガイドで提供している詳細な手順に従ってそのツールを利用することで、中規模企業は信頼性と高い安全性を備えたワイヤレス ソリューションを得ることができます。このソリューションにより、ネットワークのエンド ユーザーへのサービスを中断させることなく、生産性が向上します。