PEAP およびパスワードでワイヤレス LAN のセキュリティを保護する

  • [アーティクル]

第 2 章: ワイヤレス LAN のセキュリティの実装を計画する

公開日: 2004年9月7日

トピック

概要
章の前提条件
ワイヤレス LAN のセキュリティのしくみ
対象組織のプロファイル
設計条件
WLAN アーキテクチャ
大規模組織向けに拡張する
ソリューション アーキテクチャのバリエーション
要約
参照情報

概要

この章では、セキュリティ保護された WLAN (ワイヤレス ローカル エリア ネットワーク) のソリューション設計全般について説明します。ソリューションのデザイン、およびソリューション設計の理由について十分に理解してもらうことを目的とします。この章では、設計を組織の特定ニーズに適合させるのに役立つ十分な情報も得られます。

この章では初めに、802.1X および保護された拡張認証プロトコル (PEAP) を使用してネットワーク アクセスをセキュリティ保護するしくみについて説明します。次に、ソリューションの対象組織について説明した後、それらの対象組織にとって重要な要件のいくつかについて考察します。

章の中盤では、ネットワークの設計、インターネット認証サービス (IAS) サーバーの配置、ハードウェアとソフトウェアの選択、証明書の入手、およびクライアント構成を始めとする WLAN ソリューションの設計について説明します。セキュリティ保護のない WLAN から 802.1X および PEAP への移行方法についても概説します。

章の後半では、基本ソリューション設計のバリエーションについて説明します。これらの設計バリエーションの最も重要な点は、大規模組織での使用状況に合わせたソリューションの拡張方法です。この点について詳細に説明します。その他にも、次の設計オプションについても概説します。

  • ワイヤード LAN のセキュリティに対応した IAS インフラストラクチャを再利用する。

  • IAS を使用してリモート アクセス認証を行う。

  • SOHO 環境に WLAN を展開する。

ページのトップへ

章の前提条件

セキュリティ保護された WLAN の実装計画の一部として、組織内に適切なスキル セットを確保したうえで、展開に影響する決定には適切な人に関与してもらえるようにしておく必要があります。

この章をできるだけ有効に活用する場合は、次のトピックについて詳しく理解しておくことをお勧めします。

  • ワイヤレス LAN に関するネットワーキングの概念

  • Microsoft® Windows® 2000 または Windows Server 2003

  • Microsoft Active Directory® ディレクトリ サービスの概念 (たとえば、Active Directory ドメインとフォレスト、管理ツール、グループ ポリシーの使用、ユーザーやグループなどの Active Directory オブジェクトの操作)

  • 証明書サービス、および公開キー基盤 (PKI) の概念

  • セキュリティに関する一般概念 (たとえば、認証、承認、暗号化)

  • Windows のセキュリティ機能 (たとえば、ユーザー、グループ、監査、アクセス制御リスト (ACL))

  • グループ ポリシーを使用した、セキュリティ設定の適用

    注: このソリューションは詳しい技術的知識がなくても実装できますが、MCSE (Microsoft Certified Systems Engineer) の資格を取得するか、それと同等な知識および経験がある方が理想的です。

ページのトップへ

ワイヤレス LAN のセキュリティのしくみ

WLAN のセキュリティ保護の各種方法については、「はじめに: ワイヤレス LAN のセキュリティに対応した戦略を選択する」で詳しく説明しました。802.1X を使用した WLAN に対する厳正な認証、および動的 WEP (Wired Equivalent Privacy) または WPA (WiFi Protected Access) を使用したネットワーク トラフィックの暗号化に重点を置いて説明します。その説明の要点は、次のとおりです。

  • 当初の 802.11 WLAN セキュリティ スキームは、WEP (Wired Equivalent Privacy) と呼ばれており、攻撃者がネットワーク キーを発見してネットワークを遮断できるというセキュリティ上の深刻な欠陥があります。ここで、このスキームが "戦略的 WEP" と呼ばれているのは、固定ネットワーク アクセスおよび WLAN の全メンバ間で共有される暗号化キーが使用されるためです。

  • IEEE 802.1X の使用によって、WLAN 用の厳正なアクセス管理機構が実現されます。この IEEE 802.1X は、セキュリティ保護された拡張認証プロトコル (EAP) メソッドと組み合わせて使用する必要があります。EAP メソッドの選択によって、ユーザーおよびコンピュータを WLAN に対して認証する際に使用できる資格情報の種類が定義されます。

  • マイクロソフトは、パスワード認証用 PEAP と MS CHAP v2、および証明書認証用 EAP-TLS (Transport Layer Security) の使用をサポートすると共に、推奨します。

  • PEAP は、セキュリティ保護されたチャンネル内で別の EAP メソッド (たとば、MS-CHAP v2) を保護する手段です。パスワード ベースの EAP メソッドに対する攻撃を防ぐには、PEAP を使用することが不可欠です。

  • WLAN トラフィックに対する強力なデータ保護は、動的 WEP または WPA によって実現できます。データ保護用のマスター暗号化キーは、802.1X 認証プロセスの一部として生成されます (ただし、動的 WEP と WPA とでは、これらのキーの使用方法が異なります)。

  • 静的 WEP と動的 WEP とでは、重大な違いがあります。動的 WEP に使用される暗号化アルゴリズムは静的 WEP と同じものですが、暗号化キーは間断なくリフレッシュされるため、静的 WEP に対する既知の攻撃を阻止します。動的 WEP からはネットワーク データ保護メカニズムが参照されるだけであるため、ネットワーク認証は 802.1X で別に処理されます。

PEAP およびパスワードを使用した場合の 802.1X の動作

パスワード ベースの WLAN 認証の場合、マイクロソフトは PEAP と MS-CHAP v2 の併用をサポートします。図 2.1 に、PEAP と MS-CHAP v2 を併用した場合の 802.1X の動作を示します。

図 2.1 ワイヤレス LAN に対する 802.1X および PEAP 認証

拡大表示する この図は、次の 4 つの主要コンポーネントを示します。

  • ワイヤレス クライアント: これは、ネットワーク リソースへのアクセスを必要とするアプリケーションを実行するコンピュータまたはデバイスです。ユーザーまたはコンピュータは、ネットワークに対するクライアントの認証に使用される資格情報を所有できます。クライアントが保持する WLAN ネットワーク アダプタは、802.1X および動的 WEP または WPA の暗号化をサポートする必要があります。多くのネットワーク標準のドキュメントでは、クライアントは "ステーション (STA)" と呼ばれます。

    クライアントが WLAN へのアクセス許可を取得するためには、事前にいくつかの帯域外操作で認証サービス (RADIUS サーバーおよびディレクトリ) を使用して、一連の資格情報に同意する必要があります。この場合、WLAN に接続する前に、ユーザーおよびコンピュータのドメイン アカウントが作成されます。クライアントは、そのパスワードおよびドメイン コントローラ (ディレクトリ) が、パスワード検証の可能なものであることを認知します。また、WLAN 名および使用する認証方法を含んだ適切な WLAN 設定を使用して、クライアントを事前設定しておく必要もあります。

    注: 厳密に言うと、帯域外で資格情報の 1 セット (ユーザーまたはコンピュータのどちらか) にのみ同意する必要があります。たとえば、ユーザー資格情報を使用して WLAN に接続した後で、コンピュータをドメインに参加させる必要があります。ただし、このソリューションでは、WLAN にアクセスする前にユーザー アカウントとコンピュータ アカウントの両方が存在することを前提とします。

  • ワイヤレス アクセス ポイント (AP): ワイヤレス AP は、WLAN へのアクセスを制御し、内部 LAN へのクライアント接続をブリッジする機能です。ワイヤレス AP は、802.1X、および動的 WEP または WPA の暗号化をサポートする必要があります。AP は、ネットワーク標準用語で言う "ネットワーク アクセス サービス (NAS)" の役割を補助します。

    ワイヤレス AP および RADIUS サーバーも、確実な相互識別を可能にする共有シークレットを保持します。

  • RADIUS サーバーおよびディレクトリ: RADIUS サーバーは、ディレクトリを使用して WLAN クライアントの資格情報を検証します。RADIUS サーバーは、ネットワーク アクセス ポリシーに基づいて、承認を決定します。また、ネットワークへのクライアント アクセスに関するアカウンティングおよび監査情報も収集します。これは、ネットワーク標準用語で、認証サービス (AS) と呼ばれます。

  • 内部ネットワーク: これは、ワイヤレス クライアント アプリケーションがアクセスを取得する必要のある、セキュリティで保護されたネットワークです。

クライアントが要求を実行し、WLAN へのアクセスを許可された後、内部ネットワークへのアクセス許可を取得するための方法を以下に記述します。これらのステップ番号は、図 2.1 の中の番号に対応します。

  1. クライアント コンピュータがワイヤレス AP の範囲にあるときに WLAN への接続を試みるのは、その WLAN がワイヤレス AP 上でアクティブであって、しかもそのサービス セット識別子 (SSID) によって識別された場合です。SSID は WLAN の名前で、クライアントがこの WLAN 用の適切な設定値、および資格情報の種類を識別するために使用します。

  2. ワイヤレス AP は、セキュリティで保護された (802.1X 認証) 接続のみを許可するように構成されます。クライアントがその AP への接続を試みると、AP はクライアントに対してチャレンジを発行します。その後、制限付きチャンネルが AP によってセットアップされるため、クライアントは RADIUS サーバーとしか通信できなくなります (残りのネットワークへのアクセスはブロックされます)。RADIUS サーバーは、信頼されたワイヤレス AP (IAS サーバー上に RADIUS クライアントとして構成された AP) からの接続のみを受け付け、その RADIUS クライアントに共有シークレットを提供します。

    クライアントは 802.1X を使用した制限付きチャンネルを介して、RADIUS サーバーに対して認証を試みます。クライアントは PEAP ネゴシエーションの一部として、RADIUS サーバーとのトランスポート層セキュリティ (TLS) セッションを確立します。次の目的のために、PEAP の一部として TLS セッションを使用します。

    • RADIUS サーバーに対する認証をクライアントに許可します。これは、クライアントによって信頼される証明書を保持したサーバーとのみ、セッションが確立されることを意味します。

    • MS-CHAP v2 認証プロトコルをパケット スヌープから保護します。

    • TLS セッションのネゴシエーションは、クライアントおよび RADIUS サーバーで使用可能なキーを生成して、共通マスター キーを確立します。これらのキーを使用して、WLAN トラフィックの暗号化に使用されるキーが導出されます。

    クライアントは、PEAP チャンネル内でセキュリティ保護された状態で、MS-CHAP v2 の EAP プロトコルを使用して RADIUS サーバーに対して自身を認証します。この処理の間は、TLS トンネル内のトラフィックがクライアントおよび RADIUS サーバーにのみ見え、ワイヤレス AP には公開されません。

  3. RADIUS サーバーは、クライアント資格情報をディレクトリと照合してチェックします。クライアントが正常に認証された場合、クライアントによる WLAN の使用を承認するかどうかを決定するための情報が、RADIUS サーバーによって収集されます。RADIUS サーバーはディレクトリから取得した情報 (たとえば、グループ メンバシップ) と、そのアクセス ポリシーに定義された制約 (たとえば、WLAN アクセスが許可される日の時間) とを組み合わせて使用し、クライアントへのアクセス権限を付与または拒否します。RADIUS は、アクセスの決定内容を AP に中継します。

    クライアントがアクセス権限を付与された場合、RADIUS サーバーはクライアント マスター キーをワイヤレス AP に転送します。この時点で、クライアントと AP は、双方で受け渡しをする WLAN トラフィックの暗号化/復号化に使用可能な共通キー マテリアルを共有します。

    動的 WEP を使用してトラフィックを暗号化する場合は、マスター キーが暗号化キーとして直接使用されます。WEP キー リカバリ攻撃を阻止するには、これらのキーを定期的に変更する必要があります。定期的にキーが変更されるように、RADIUS サーバーは新しいキー セットの再認証および生成をクライアントに定期的に実施させます。

    WPA を使用して通信をセキュリティで保護する場合は、パケット転送のたびに変更されるマスター キー マテリアルを使用してデータ暗号化キーが導出されるため、WPA が頻繁な再認証を強制する必要なしに、キーのセキュリティが保証されます。

  4. その後、内部 LAN へのクライアント WLAN 接続が AP によってブリッジされ、クライアントが内部ネットワーク上のシステムと自由に対話できます。この時点で、クライアントと AP との間で送信されるトラフィックが暗号化されます。

  5. 以降、クライアントは IP アドレスが必要となった場合に、LAN 上のサーバーに動的ホスト構成プロトコル (DHCP) リースを要求できます。IP アドレスが割り当てられた時点で、クライアントは残りのネットワーク上にあるシステムと通常の通信を開始できます。

WLAN に対するコンピュータおよびユーザーを認証する

これまでは、クライアント (ユーザーまたはコンピュータ) が WLAN に正常に接続する方法について説明してきました。Windows XP は、ユーザーとコンピュータの両方を個別に認証します。コンピュータは最初に起動したときに、そのコンピュータのドメイン アカウントおよびパスワードを使用して、WLAN に対して認証します。WLAN に対してコンピュータを認証した後、前述したすべてのステップが実行されます。コンピュータを固有の資格情報を使用して WLAN に接続させると、ログインするユーザーが存在しない場合でも、そのコンピュータの管理が可能になります。たとえば、グループポリシー設定を適用して、ソフトウェアおよび修正プログラムをコンピュータに配布することも可能になります。

ユーザーがコンピュータにログオンすると、同じ認証/承認プロセスが再び繰り返されますが、今度はユーザーの名前およびパスワードが使用されます。コンピュータの WLAN セッションはユーザーのセッションで置き換えられます。このことは、この 2 つのセッションが同時にはアクティブにならないことを意味します。また、権限のないユーザーが、許可されたコンピュータを WLAN へのアクセスに使用できないことも意味します。

注: Windows XP では、この動作をオーバーライドして、コンピュータの資格情報またはユーザー資格情報のどちらか一方だけが使用されるように指定できますが、この設定はお勧めできません。前者のコンピュータ資格情報のみが使用された場合、ユーザーは承認なしで WLAN に接続できます。後者のユーザー資格情報が使用された場合、ユーザーがログオンするまでは、コンピュータから WLAN への接続が禁止されるため、一部のコンピュータ管理機能が中断されます。

ページのトップへ

対象組織のプロファイル

このソリューションは、従業員数 100 ～ 200 人の小規模ビジネス向けに設計されています。組織は架空のものですが、その特徴および要件は、広範な実調査から導き出されています。このような現実の要件は、設計時に行われた選択、およびガイダンスのスタイルとスコープを形作る助けになっています。

このソリューションが 100 ～ 200 人の小規模組織だけに限られたものではないという点を理解することは重要です。設計が単純でしかも使用されているコンポーネントがスケーラビリティを備えていることから、同じ PEAP ベースの WLAN ソリューションはユーザー数が数千にも達するきわめて大規模な組織にも、またきわめて小規模な組織にも容易に対応できます。対象組織の特徴を理解することにより、設計の前提条件を理解して、自身の組織に適合させるためのより望ましい位置に立つことができます。

大規模組織でのソリューションの使用については、この章の「大規模組織向けに拡張する」を参照してください。きわめて小規模な組織では、必要なコンポーネントをすべて 1 台の既存サーバー上にインストールすることも可能です。

組織のレイアウト

次の図に、組織の物理的および情報技術 (IT) レイアウトを示します。

図 2.2 対象組織の物理的および IT レイアウト

拡大表示する IT システムおよびユーザーの大半を収容する大規模な本社が 1 つ存在します。ここには、Active Directory ドメイン コントローラがすべて配置されます。本社では、ファイアウォール サーバー経由でインターネットに接続できます。内部ネットワークに接続された WLAN クライアントおよびワイヤレス AP も、いくつか存在します。

また、ローカル IT サービスが若干しか用意されていない 1 つまたは複数の辺境オフィスも存在しますが、これらのオフィスでは本社へのネットワーク接続の余地はありません。このオフィスには、少数のクライアント (その全クライアントがワイヤレスの可能性もある) が存在し、WLAN クライアントを本社のアプリケーションおよびデータに接続できるビジターを本社から頻繁に迎えています。

オフィス間の広域ネットワーク (WAN) 接続を提供する手段としては、専用回線 (たとえば、T1－1.5Mbps) が使用されるか、DSL (デジタル加入者回線) インターネット接続、およびインターネット経由で仮想プライベート ネットワーク (VPN) のルータ ツー ルータ回線が使用されます。一般的に、WAN 接続は障害回復力を備えていません。

注: オフィス間の WAN 接続がインターネット経由で VPN 接続によって提供される場合は、インターネット上の脅威から守るファイアウォールが各オフィスに装備されているのが一般的です。このファイアウォールの存在は WLAN の説明には無関係であるため、明瞭にするためにここでは省略しました。

IT 環境

この組織の Active Directory は、少なくとも 2 つのドメイン コントローラを備えた単一ドメイン フォレストです。Active Directory は、ドメインに対してユーザーを認証し、ディレクトリ サービスおよび認証サービスを一部のアプリケーション (たとえば、電子メール用 Microsoft Exchange Server や Outlook®) に提供します。ドメイン コントローラは、最近、Windows 2000 Server から Windows Server 2003, Standard Edition にアップグレードされました。ドメイン コントローラは、一部のレガシー アプリケーション用にドメイン ネーム システム (DNS)、DHCP、Windows インターネット ネーム サービス (WINS) などの追加サービスも実行します。

IT システムは主としてマイクロソフト テクノロジであり、クライアント コンピュータ上には Windows XP、サーバー システム上には Windows Server 2003 が搭載されます。また、Windows 2000 を実行するサーバーもいくつか存在しており、企業ではアプリケーションのテストおよびサポートを見込んでアップグレードを予定します。この組織は、特に自社の販売スタッフ、流通スタッフ、およびウェアハウス スタッフ用モバイル システム (Windows XP, Tablet Edition や Pocket PC 2003 など) への投資を開始しました。

重要なサーバー アプリケーションとしては、Microsoft Exchange Server、SQL Server (一部の基幹業務アプリケーションを実行)、インターネット インフォメーション サービス (IIS)、Windows SharePoint™ Services などがあります。

アプリケーションをクライアント コンピュータに配置する際には、Active Directory のグループ ポリシーが使用されます。オペレーティング システム用修正プログラムの配布には、Microsoft Software Update Services (SUS) および自動更新機能が使用されます。

サーバー システム上では、Windows イベント ログ、パフォーマンス ログ、アプリケーション ログを日常的に点検することによって、システム監視が直接実行されます。ハードウェアおよびソフトウェアに関する重要な警告は電子メール経由で IT 管理者に送信され、システム コンソール上に警告が表示されます。

組織には、IT 計画、サービス提供、および日々のサポートに当たる常勤の IT スタッフが 2 人います。IT 管理者と IT サポート エンジニアは、両者とも最新の MCSE 認定を取得し、数年にわたる IT 経験を積んでいます。

ページのトップへ

設計条件

前に説明した組織での WLAN ソリューションの条件としては、一般的に以下のような種類があります。これらの条件は、組織の広範なカテゴリを網羅するように拡張されました。残りの章に提示されている設計には、これらの条件が明示的に使用されます。

表 2.1: WLAN ソリューションの設計条件

設計要素 条件
セキュリティ要件 - ワイヤレス クライアントの堅牢な認証と承認 - 承認されているクライアントにネットワーク アクセスを許可し、承認されていないアクセスを拒否する堅牢なアクセス制御 - ワイヤレス ネットワーク トラフィックの高強度な暗号化 (128 ビット) - 暗号化キーのセキュリティ保護された管理
スケーラビリティ － サポートされる最小ユーザー数と最大ユーザー数 25 ～ 5000 人以上の WLAN ユーザー さまざまな規模の WLAN に応じた認証の負荷については、表 2.2 を参照してください。
スケーラビリティ － サポートされるサイトの数 ベーシック: ローカル ドメイン コントローラおよび IT サービスを使用した単一の大規模サイト。ドメイン コントローラを使用しない 1 つまたは複数の小規模サイト。必要とされる最小ユーザー数は 25 です。 ハイ エンド: 複数のドメイン コントローラを使用した単一の中央サイト。単一ドメイン コントローラを使用した大規模オフィスや、本社への WAN 接続 (障害回復力あり) が可能な大規模オフィス。ドメイン コントローラを使用しない複数の小規模オフィス (WAN が障害回復力を持たないことを想定)。最大許容ユーザー数は 5000 です。 大規模組織での使用については、「付録 A: エンタープライズで PEAP を使用する」を参照してください。
可用性要件 ワイヤレス AP、IAS、またはドメイン コントローラを複数使用することで、大規模オフィスでの単一コンポーネントの障害に対して WLAN の障害回復力が提供されます。冗長接続性がインストールされない限り、小規模オフィスの WLAN は、WAN の障害を受けやすくなります。
プラットフォームのサポート サーバー プラットフォーム: Windows Server 2003, Standard Edition、または Enterprise Edition (IAS および証明機関 (CA) インストールの場合)。Standard Edition は、1 サーバーにつき最大 50 のワイヤレス AP (RADIUS クライアント) をサポートします。 クライアント プラットフォーム: Windows XP Professional または Tablet Edition、Pocket PC 2003
拡張性 (他のアプリケーション用ソリューション コンポーネントの再利用) 他のネットワーク アクセス アプリケーション (リモート アクセス VPN、802.1X ワイヤード ネットワーク アクセス、およびファイアウォール認証) は、同じ認証インフラストラクチャによるサポートが可能です。
IT 組織の要件 ソリューションのインストールおよび管理には、IT プロフェッショナルの最新の MCSE 認定またはそれと同等な知識を持ち、IT 業界での 2 ～ 3 年の経験が必要です。
管理性要件 健全な操作を維持するには、ソリューションを最小限に管理するだけで済みます。 警告は電子メールまたは Windows イベント ログを介して送信 (または他の警告タイプをトリガーするように変更) されます。 IAS コンポーネントを監視する手段としては、Windows 監視ソリューション (イベント ログおよびパフォーマンス カウンタを使用)、RADIUS ログ機能、および簡易ネットワーク管理プロトコル (SNMP) 管理システムがあります。
標準への準拠 ソリューションは、次の規格をサポートします。 - IEEE 802.11 (a、b、または g) ネットワーク標準 - PEAP および MS-CHAP v2 を使用した IEEE 802.1X 認証。他の EAP メソッド (たとえば、証明書ベースの EAP-TLS や PEAP-EAP-TLS) との併用が可能です。 - キーが動的に設定された WEP および WPA WLAN の保護 - 将来の機能および規格 (たとえば、802.11i) - RADIUS での RFC 2865 および RFC 2866 に対するサポート

次の表に、さまざまな規模の組織に応じた WLAN 認証要件を示します。"1 秒あたりの新規認証" は安定負荷の一部で、ワイヤレス AP 間をユーザーが移動するときの、1 日につき 1 ユーザーあたり平均 4 回の新規の完全な認証を想定します。"1 秒あたりの新規認証の最大値" 列は、すべてのユーザーが 30 分の間に認証を必要とする場合に予想される負荷を示しています (たとえば、始業時間の開始直後)。"1 秒あたりの再認証" 列には、動的 WEP キーの更新を強制する、定期的な再認証数が示されます。

表 2.2: WLAN 認証要件

WLAN ユーザー数 1 秒あたりの新規認証 1 秒あたりの新規認証の最大値 1 秒あたりの再認証
100 > 0.1 0.1 0.1
1000 0.1 0.6 1.1
10,000 1.4 5.6 11.1
これらの数字については、この章で後述する IAS サーバー規模の変更についての説明を参照してください。 [](#mainsection)[ページのトップへ](#mainsection) ### WLAN アーキテクチャ ここでは、ソリューションのアーキテクチャについて説明します。 #### ネットワーク設計 次の図に、本社の基本的なネットワーク レイアウトを示します。 ![](images/Dd362890.PEAP_203(ja-jp,TechNet.10).gif) **図 2.3 本社のネットワーク レイアウト** [拡大表示する](https://technet.microsoft.com/ja-jp/dd362890.peap_203_big(ja-jp,technet.10).gif) この図に示されているのは、ワイヤレス クライアント、複数のワイヤレス AP、Active Directory ドメイン コントローラ上で実行されている 2 台の IAS サーバー、DHCP サーバー、その他のネットワーク接続されたサーバー、クライアント、およびデバイスです。1 つまたは複数のレイヤ 2 スイッチを使用して、単一の LAN 上に WLAN クライアント以外の全アイテムが接続されます。このサイトでは、内部ネットワーク全体で単一のサブネットが使用されます。インターネットおよび他のオフィスへの接続 (図には示してありません) は、ファイアウォールを介してルーティングされます。 大規模な組織ほど、単一サイト内にルーティングされた環境を持つ傾向が強くなります。これは認証インフラストラクチャには影響を与えませんが、残りのネットワークへのワイヤレス AP の接続方法には影響を与える可能性があります。サイト全体にわたって複数の AP 間をユーザーが容易に移動できるようにするために、ワイヤレス AP および WLAN クライアントをすべて同じ IP サブネット上に配置するのが通常の慣行となっています。これにより、ユーザーがワイヤレス AP 間を移動しても依然として同じ IP アドレスを維持することが可能になります。このトピックの詳細は、このガイドでは説明しません。このトピックの詳細については、「*Windows Server 2003 Deployment Kit*」の「Deploying a Wireless LAN」(英語) の章を参照してください。 ネットワーク設計時には、次の環境を実現する必要があります。 - ワイヤレス AP がプライマリ IAS サーバーとセカンダリ IAS サーバーの両方への接続性を備えていること。IAS サーバーとは異なる VLAN/サブネット上に AP がある場合は、これらのサブネット間でトラフィックがルーティング可能でなければなりません。 - WLAN クライアントが DHCP サーバーへの接続性を備えていること。各サーバーが同じサブネット上に配置されていない場合は、そのサブネット用にスコープが定義された DHCP へのクライアント DHCP 要求を、DHCP/BOOTP リレー エージェントに転送させる必要があります。また、各クライアントは通常のネットワーク サービス (たとえば、ドメイン コントローラやファイル サーバーなど) への接続性も備えていなければなりません。 ##### ワイヤレス ネットワーク ハードウェアを選択する ワイヤレス AP とワイヤレス ネットワーク アダプタが次の機能をサポートすることを確認してください。 - 動的 WEP を使用する場合は 128 ビットの WEP 暗号化方式。WPA を使用する場合は TKIP 暗号化方式 (RC4) または AES 暗号化方式。 - 802.1X 認証 - 動的キーの更新 (WEP 暗号化方式のみ)。 - WPA のサポート (WPA のサポートを取得するために、動的 WEP を使用する場合でも、ファームウェア アップデートの提供についての明確な確約をベンダから取得する必要があります)。 サポートが必要とされる物理的な場所全体で、WLAN クライアントに対するカバレッジが提供されるように、適切なワイヤレス AP が必要です。また、ワイヤレス AP に障害が発生した場合に備えて、すべての場所に適切なバックアップ カバレッジが存在するように、ワイヤレス AP の配置を計画する必要もあります。ワイヤレス AP の配置の詳細については、「*Windows Server 2003 Deployment Kit*」の「Deploying a Wireless LAN」(英語) の章を参照してください。このキットは、この章の最後に記述されている「参照情報」にも掲載されます。また、章末で説明する記事「Recommendations for IEEE 802.11 Access Points」(英語) も参照してください。 #### IAS サーバーを配置する IAS サーバーの配置の目標は、実装コストおよび管理コストの低減を維持しながら、障害回復力を備えた WLAN サービスを達成することです。単一のコンポーネントの障害に対する障害回復力を備えた WLAN サービスには、次の特徴があります。 - WLAN カバレッジの必要なすべての物理ゾーンで、複数のワイヤレス AP が必要です。 - プライマリ IAS サーバーまたはこのサーバーへのネットワーク接続に障害が発生した場合に備えて、各ワイヤレス AP からバックアップ IAS サーバーへの通信を可能にしておく必要があります。 - IAS クライアントおよび WLAN クライアント上のサービス (たとえば、Active Directory、DHCP、DNS) も障害回復力を提供するものでなければなりません。 これらのうちの 2 つ目の特徴は、IAS サーバーの配置計画にとってきわめて重要です。このソリューションには、既存のドメイン コントローラ上に IAS が配置してあります。これにより、最高のパフォーマンス構成が得られると共に、実装コストおよび管理コストが比較的低くなります。すべての規模の組織に対する一般的な推奨事項として、ドメイン コントローラがある全サイト (ただし、一部のドメイン コントローラの上に IAS をインストールすると済む場合もあります) に IAS を配置しておく必要があります。 次の図に、組織内での IAS サーバーの配置を示します。IAS は、本社にある 2 つの既存ドメイン コントローラ上に配置されます。ネットワーク CA (この章の後半にある「IAS サーバー用の証明書を取得する」を参照) も、これらのドメイン コントローラの 1 つにインストールされます。本社の AP はすべて、これらの IAS サーバーが使用できるように構成されます。 ![](images/Dd362890.PEAP_204(ja-jp,TechNet.10).gif) **図 2.4 本社と支社のインフラストラクチャ** [拡大表示する](https://technet.microsoft.com/ja-jp/dd362890.peap_204_big(ja-jp,technet.10).gif) この組織には、ローカル ドメイン コントローラを使用しない小規模な支社があります。このサイト内のワイヤレス AP は、本社にある 2 台の IAS サーバーをすべての認証要求に使用します。これは、本社への WAN 接続に障害が発生した場合、WLAN に対してユーザーを認証できないことを意味します。このことは、多くの組織にとって容認できないリスクであると言えます。 このリスクを解消するには、冗長 WAN 接続またはローカル IAS ドメイン コントローラをインストールしておく必要があります。このインストールは、このタイプのオフィスにとって法外なコストのように思えるかもしれませんが、WAN の障害発生時にドメイン コントローラへのアクセスができないと、他のほとんどのネットワーク サービス (たとえば、ローカル ファイル サーバー) にも障害が発生する可能性あります。これに対処しておくことは、これらのサービスおよびローカル WLAN の信頼性の面でメリットになります。ドメイン コントローラを支社に配置する方法については、この章で後述する「大規模組織向けに拡張する」を参照してください。 WAN の接続性の信頼性がきわめて低くしかもローカル ドメイン コントローラを配置する小規模オフィスの場合、スタンドアロン WLAN を配置することに決めてもよいでしょう。詳細については、この章の後半の「SOHO 環境」を参照してください。 ##### RADIUS サーバーに AP を割り当てる IAS サーバーにワイヤレス AP をすべて割り当てる必要があります。各ワイヤレス AP には、プライマリ RADIUS サーバーおよびセカンダリ RADIUS サーバーが必要です。これにより、プライマリ サーバーに障害が発生したり、接続不能になった場合にワイヤレス AP がセカンダリ RADIUS サーバーを使用できます。次の図に、このプライマリ RADIUS サーバーおよびセカンダリ RADIUS サーバーの配置を示します。 ![](images/Dd362890.PEAP_205(ja-jp,TechNet.10).gif) **図 2.5 プライマリ IAS サーバーとセカンダリ IAS サーバー間での AP の均衡化** この図は、別個のプライマリ IAS サーバーおよびセカンダリ IAS サーバーを使用した、各ワイヤレス AP の構成を示します。これにより、サーバー間の負荷分散が可能になります。ローカル IAS サーバーを使用しないサイト内のワイヤレス AP は、本社内の IAS サーバーを使用して、プライマリ IAS サーバーおよびセカンダリ IAS サーバーと同じパターンに従います。 サイト内のワイヤレス AP に 1 台のローカル IAS サーバーのみが使用されている場合、ローカル サーバーを常にプライマリ サーバーにする必要があります。また、本社にあるサーバー (または、IAS サーバーへの接続が信頼性の高い他の適切な場所) をセカンダリ サーバーにする必要があります。これについては、次の図で説明します。 ![](images/Dd362890.PEAP_206(ja-jp,TechNet.10).gif) **図 2.6 ローカル IAS サーバーおよびリモート IAS サーバーを使用した AP の構成** [拡大表示する](https://technet.microsoft.com/ja-jp/dd362890.peap_206_big(ja-jp,technet.10).gif) 複数の AP がある場合は、IAS サーバーへの AP の割り当てを注意して記録する必要があります。この記録を使用して、すべての AP にプライマリ サーバーおよびセカンダリ サーバーが割り当てられていることと、使用可能な全サーバーに AP の負荷が分散されていることを確認します。 **注:** プライマリ IAS サーバーが使用不可能な場合、ワイヤレス AP はすべてセカンダリ IAS サーバーにフェールオーバーされます。ただし、ほとんどの AP は再び使用可能になっても、自動的に元のプライマリが使用されるようにはなりません (AP がフォールバックするのは、セカンダリに障害が発生した場合だけです)。両方の IAS サーバーが同じ場所にある場合、このことは重大な問題ではありません。全サーバーにわたって負荷が均一になるだけです。ただし、セカンダリ IAS がリモートの場合、プライマリに一時的な障害が発生した場合は、最適化されていない WAN リンクを介して AP 認証がすべてセカンダリに任せられることがあります。 AP が指定されたプライマリ サーバーに自動的に復帰しない場合は、障害後に AP が復旧したときにローカル IAS サーバーの使用を開始するように、AP を手動でリセットする必要があります。一時的なネットワークの状況が、AP がセカンダリ RADIUS サーバーへフェールオーバーする原因になる可能性があるため、IAS サーバー アプリケーション ログ内の認証要求イベントをチェックすることによって、無効な IAS が使用されている AP を確認しておく必要があります。 ##### ドメイン コントローラと IAS の配置 このソリューションでは、既存のドメイン コントローラ上に IAS がインストールされます。これにより実装コストの低減が維持され、それぞれのメンバ サーバー上に IAS を使用した場合に比べてパフォーマンスが向上します。パフォーマンスが向上するのは、IAS がネットワークの遅延を発生することなしに、同じコンピュータ上で Active Directory を使用して処理できるためです。 ドメイン コントローラ上への IAS のインストールに関しては、いくつかの警告を認識しておく必要があります。これらの警告は多くの組織にとって重要性のないものですが、考慮に入れたうえで IAS をインストールしてください。 - 全ドメイン コントローラ上に IAS がインストールされるように選択しない場合は、当然、全ドメイン コントローラ用の単一構成を設定できません。 - IAS 管理とドメイン管理は、強制的には分離できません。ドメイン コントローラ上に IAS をインストールした場合、IAS 管理者がビルトイン ドメイン管理者グループのメンバになる必要があります。 - ドメイン コントローラの機能に対して高い負荷がかかると、IAS のパフォーマンスに悪影響を与えます。またその逆に、IAS の機能に対して高い負荷がかかると、ドメイン コントローラのパフォーマンスに悪影響を与えます。ドメイン コントローラと IAS を別のサーバーに配置することにより、これらのサービスの個々のパフォーマンスおよび操作をより詳細に制御できるようにする必要があります。 #### IAS のソフトウェアおよびハードウェア要件 対象組織のユーザー数が 100 ～ 200 人の場合、Windows Server 2003 の推奨ハードウェア仕様を使用する限り、サーバーに対する IAS の負荷が問題になることはまずないでしょう。ただし、大規模な組織の場合、IAS の負荷を考慮に入れる必要があります。既存のドメイン コントローラ上で IAS を実行する場合、この考慮事項は特に重要です。 IAS への負荷は、次の設定による影響を受けます。 - RADIUS 認証を必要とするユーザーおよびデバイスの数。 - EAP タイプや再認証の頻度などの、認証オプションの選択。 - RADIUS のログ機能が有効になっているかどうか。 前述の「設計条件」の表 2.2 で示した数字を使用して、所定のユーザー数から予測可能な、秒あたりの認証数を推定できます。ユーザーが正常に認証されるときの定常状態の負荷、およびピーク時の "最悪な場合" の負荷を考慮する必要があります。この表から数字を推定した場合、200 ユーザーによって生じる定常状態負荷の大きさは、完全な認証 (50 秒毎に 1 回) と高速な再認証 (10 秒毎に 1 回) を下回ります。機能停止後 (全ユーザーを即座に WLAN に接続し直す必要のある場合) に全ユーザーの認証所要時間のみが相当大きな数字に達しますが、それ以外はきわめて小さい数字です。この最高最低のピークは、通常 30 分以上かかる、1 日の開始時のログオンに比べて、はるかに極端になります。 認証オプションは、IAS サーバーの負荷に大きく影響します。開始時のログオンでは CPU 負荷の高い公開キー操作が PEAP などのプロトコルによって実行されます。その後の再認証ではキャッシュされたセッション情報が使用されますが、いわゆる "高速再接続" が可能になります。動的 WEP を使用する場合、新しい暗号化キーを生成するために、クライアントが 15 ～ 60 分おきに再認証されます。ただし、WPA を使用した再認証をかなり低い頻度で実施する必要がある場合は、再認証は一般的に 8 時間おきに実施されます。 次の表に、別個のサーバー上に Active Directory が配置された、Windows Server 2003 が稼働する Intel Pentium 4 2 GHz サーバー上の IAS の認証数 (秒あたりの概数) を示します。 **注:** 次の表の情報は、Microsoft Solutions for Security によって実施されたテストから得られたものです。この情報は保障なく提供されているものであるため、パフォーマンスの比較には使用せず、キャパシティ プランニングを立てるためのガイドラインとしてのみ使用してください。 **表 2.3: 1 秒あたりの認証数**

認証の種類 新規の認証 高速再接続による認証
PEAP 認証数/秒 36 166
200 ユーザーの認証時間 6 秒 2 秒
1000 ユーザーの認証時間 30 秒 7 秒
これらの数字は RADIUS のログ機能を有効化し、別個のサーバー上で Active Directory を実行した状態で算出したものです。これらの両方の要因によって IAS のパフォーマンスが低減するため、これらの数字は悲観的推定値であると見なすことができます。 これらの数字からわかるように、このタイプのサーバーでは、ネットワークに対して 200 WLAN ユーザーを 6 秒で認証し、1000 ユーザーを 30 秒で認証できます。 ##### Windows Server 2003, Standard または Enterprise Edition を使用する このソリューションは、全 IAS サーバーに Windows Server 2003, Standard Edition を使用します。これにより、サーバー ライセンスのコストが低く維持され、Windows Server 2003 が Standard Edition であるか Enterprise Edition であるかに関係なく、既存のサーバー上に配置することが可能になります。 Windows Server 2003, Standard Edition の IAS では、各サーバーが 50 RADIUS クライアントおよび 2 RADIUS サーバー ルーティング グループしかサポートできないという制約があります。 **注:** RADIUS クライアントは、WLAN クライアントと同じではありません。RADIUS クライアントはワイヤレス AP だけでなく、RADIUS 認証サービスを利用する他のネットワーク アクセス サーバー (たとえば、VPN サーバーやファイアウォール) も参照します。 対象組織のユーザー数が 1 ～ 200 人の場合は、1 サーバーあたり最大 50 AP あれば十分です。大規模組織の場合 (特に大規模オフィスや、サテライト オフィスの多くが 1 ～ 2 台のハブ IAS サーバーに通じる場所では)、この制限は重大なものと考えられます。 1 ワイヤレス AP あたり 15 ユーザーを想定した場合、Windows Server 2003, Standard Edition 上の単一 IAS サーバーは、約 750 ユーザーをサポートできることになります。この計算は、サーバーをプライマリ RADIUS サーバーまたはセカンダリ RADIUS サーバーとして使用する AP の総数を考慮したものです。そのため、2 台のサーバーでサポートされる AP は 100 台ではなく 50 台です。IAS サーバーのいずれかで AP を 50 台サポートする必要がある場合、Windows Server 2003, Enterprise Edition を使用してください。また、大規模オフィスおよびハブ オフィスには Windows Server 2003, Enterprise Edition を使用し、小規模オフィスにはWindows Server 2003, Standard Edition を使用して、2つのエディションを混合させて対応することも可能です。 #### IAS の構成 IAS 設定は、次の 4 つのカテゴリに大別できます。 - IAS サーバー設定 - RADIUS ログ設定 - リモート アクセス ポリシー - 接続要求ポリシー これらのカテゴリについては、次のサブセクションで詳しく説明します。これらの設定はすべて、このソリューションに使用されているすべての IAS サーバーに共通です。これにより、この設定を 1 台の IAS サーバー上に構成して、他の IAS サーバーにコピーすることが可能となっています。この技術は、「第 5 章: ワイヤレス LAN のセキュリティ インフラストラクチャを構築する」で、IAS 設定値が組織内の全サーバー間での整合性の維持を保証する目的で使用されます。 さらに、各 IAS サーバーは 1 つまたは複数のワイヤレス AP を RADIUS クライアントとして構成しています。RADIUS クライアントについては、前述の「RADIUS サーバーに AP を割り当てる」を参照してください。サーバーごとに RADIUS クライアントのセットがそれぞれ異なるのが一般的であるため、他の設定と同様に、サーバー間では複製されません。 ##### IAS サーバー設定 このカテゴリには、次の機能が含まれています。 - Windows イベント ログへの認証要求のログ記録。このソリューションでは、正常終了と障害の両方のログ記録が有効化されます。 **注:** 要求のログ記録については、この章で後述する「RADIUS ログ機能」を参照してください。 - サーバーが RADIUS 認証とアカウンティング要求をリスンするユーザー データグラム プロトコル (UDP) ポート。このソリューションは、認証用にデフォルト RADIUS ポート 1812 を、アカウンティング用に RADIUS ポート 1813 をそれぞれ使用します。 ##### RADIUS ポリシー IAS ポリシーは、ネットワークに対するアカウントの認証および承認を制御します。ポリシーには次の 2 種類があります。 - リモート アクセス ポリシー (RAP) - 接続要求ポリシー (CRP) RAP が制御するのは、ネットワークに対する接続の方法、またその接続を承認するかどうかです。RAP には、与えられた接続要求にそのポリシーを適用するかどうかを決定する、一連のフィルタ条件が含まれています。フィルタ条件としては、たとえば、クライアントがメンバになる必要のある Windows セキュリティ グループの指定、要求側クライアントの接続形態 (たとえば、ワイヤレスか VPN か) の指定、クライアントが接続を試みる時刻の指定などがあります。各 RAP 用にポリシー アクションがあり、接続要求を "許可" または "拒否" するように設定されます。**RAP 条件フィルタに一致する接続要求は、ポリシー アクション設定に従って、ネットワークへのアクセスを許可または拒否されます。 RAP には、許可された接続 (RAP プロファイルと呼ばれる) に適用される一連のパラメータも含まれています。これらのパラメータには、この接続で使用できる認証方法、クライアントに IP アドレスを割り当てる方法、および再認証が要求される前にクライアントが接続状態のままになる時間があります。IAS 上に複数の RAP を存在させることもできます。この場合は、一致する RAP が要求を許可または拒否するまで、RAP に対して各接続要求が優先度順に評価されます。 このソリューションでは、RAP が次の表に示すように構成されます。 **表 2.4: リモート アクセス ポリシーの構成**

構成項目 設定
ポリシー名 Allow Wireless LAN Access
ポリシー タイプ 許可
RAP 構成  
NAS ポート タイプの一致 IEEE 802.11 ワイヤレス その他のワイヤレス
Windows グループの一致 Wireless LAN Access
RAP プロファイル  
ダイヤルインの制限 － クライアント タイムアウト 60 分 (動的 WEP) 8 時間 (WPA)
IP アドレスの割り当て IP の割り当てはサーバーの設定によって異なります。
IP フィルタリング なし
認証 EAP 以外をすべて無効化
認証 － EAP タイプを使用 保護された EAP (PEAP)
認証 － PEAP EAP タイプを使用 EAP MS-CHAP v2
認証 － 高速再接続 有効
RADIUS 属性 Ignore-User-Dialin-Properties = "True" Termination Action = "RADIUS-Request"

条件フィルタは、すべてのワイヤレス クライアント、およびドメイン グループの Wireless LAN Access のすべてのメンバに対して一致する必要があります。マルチリンクや MPPE (Microsoft Point-to-Point Encryption) 暗号化設定など、WLAN アクセスに無関係なパラメータは、この表には記載してありません。これらのセキュリティ グループを RAP と併用する方法の詳細については、この章で後述する「WLAN ユーザーとコンピュータの管理モデル」を参照してください。

ダイヤルインの制限 － クライアント タイムアウト設定は、ソリューションのセキュリティおよび信頼性に影響を及ぼすことがあります。表中に記載された異なった値を使用する理由については、この章で後述する「動的 WEP 用のセキュリティ オプション」を参照してください

RADIUS 属性 "Ignore-User-Dialin-Properties" を使用すると、ネットワーク アクセス権限のユーザー別制御をバイパスできます。ユーザー別およびグループ別のアクセス制御については、この章で後述する「WLAN ユーザーとコンピュータの管理モデル」を参照してください。

接続要求ポリシーは、特定の RADIUS サーバーで要求を処理するか、その要求を別の RADIUS サーバー (RADIUS プロキシという) に送信するかを制御します。RADIUS プロキシが一般的に使用されるのは、RADIUS サーバーが自身で要求を処理するための情報を持たないために、その要求を権限のある RADIUS サーバー (たとえば、別の Active Directory フォレスト内のサーバーに) に転送しなければならない場合です。RADIUS プロキシは、このソリューションには使用されていないため、このガイドでは説明しません。

リモート アクセス ポリシー、接続要求ポリシー、および RADIUS プロキシの使用方法の詳細については、この章の最終に記述されている「参照情報」を参照してください。

RADIUS ログ機能

2 種類のオプション情報をログに記録するように IAS サーバーを構成することができます。

  • 成功した認証イベントおよび拒否された認証イベント

  • RADIUS 認証とアカウンティング情報

WLAN デバイスおよびユーザーから生成された成功した認証イベントと拒否された認証イベントは、IAS サーバー上の Windows Server 2003 システム イベント ログに記録することができます。認証に関する問題に対してトラブルシューティングを行う際には、認証イベント ログ情報が非常に役に立ちます。ただし、この情報は、セキュリティ監査および警告にも使用できます。

最初の段階では、成功および拒否イベントのログ記録を有効にしておき、システムが安定したら、成功イベントを無効にすることを検討してください。WLAN アクセス イベントが成功した場合、システム イベント ログが膨大化しますが、監査目的に必要になることもあります。

Microsoft Operations Manager (MOM) などの監視/警告ツールを使用する場合、システム イベント ログ内の IAS 認証失敗イベントについて警告するためのルールを追加することを考慮に入れる必要があります。代わりに eventquery.vbs などのイベント ログ クエリ ツールを使用してイベント ログをチェックして認証の失敗がないかどうかを調べることもできます (オンライン ヘルプの「Eventquery.vbs」を参照)。単一イベントは一般的に重要でありませんが、そのようなイベントが連続して発生した場合は、侵入が試みられたことを示します。

IAS には、RADIUS 要求ログの形式で認証およびネットワーク アクセス セッション情報を記録する機能もあります。一般的に RADIUS ログ機能を使用するのは、ネットワーク使用量に対して (たとえば、インターネット サービス プロバイダ (ISP) として接続時間に基づいて) 課金する必要のある場合、または特殊な (ただし、ほとんどの目的に対応する目的から、イベント ログに記録済みの認証イベントで既にカバーされた) セキュリティ監査情報を必要とする場合です。

RADIUS ログ機能の詳細については、この章の最後に記述されている「参照情報」を参照してください。

IAS のセキュリティ

ドメイン コントローラ使用時と同様のセキュリティ対策を実施して IAS を処理する必要があります。ネットワークのセキュリティ保護された制御は、IAS インフラストラクチャのセキュリティには依存しません。IAS のセキュリティ向上の目的として実装可能な、簡単な方法としては、次のものがあります。

  • RADIUS クライアント (ワイヤレス AP) 用の強固なパスワードの使用。ソリューションには、辞書攻撃を困難にする真の意味でのランダムなパスワードを生成するスクリプトが含まれています。

  • すべての RADIUS クライアント用 RADIUS Message Authenticator の有効化による、ワイヤレス AP の IP アドレスのなりすまし阻止。この RADIUS Message Authenticator はこのソリューションで有効化されます。

  • サーバー セキュリティ設定が適切であることの確認。詳細については、「第 3 章: 環境を準備する」を参照してください。

  • サーバーに最新のセキュリティ修正プログラムを適用し、現行の最新の修正プログラムを常に維持することの保証。詳細については、「第 3 章: 環境を準備する」を参照してください。

  • 強固なドメイン アカウント設定の使用。特に、強固なパスワードおよび通常のパスワードの変更が励行されるようにする必要があります。ブロック パスワード推測攻撃がブロックされるように、ドメイン アカウント ロックアウトを有効化することを考慮に入れる必要もあります。ただし、ユーザー アカウントをタイムリーにアンロックするサポート リソースを確保する場合は、アカウント ロックアウトのみを有効化する必要があります。

  • IPSec を使用して RADIUS トラフィックをセキュリティ保護し、ワイヤレス AP および IAS サーバー間の相互認証を強化することを検討します。ただし、ワイヤレス AP によっては、この用途に IPSec の使用をサポートしていないものもあります。

IAS セキュリティ対策の詳細については、この章の最後に記述されている「参照情報」を参照してください。

WLAN ユーザーとコンピュータの管理モデル

このソリューションの WLAN へのアクセスは、ドメイン セキュリティ グループを使用して制御されます。ドメイン ユーザー オブジェクトのダイヤルイン プロパティを使用して、個人に対してアクセスを許可または拒否することも可能ですが、多数のユーザーの管理は面倒です。

このソリューションでは、きわめて単純なスキーマを使用して、すべてのドメイン ユーザーおよびコンピュータから WLAN へのアクセスを可能にします。多くの組織にとって、ドメイン メンバシップによるアクセス制御は強力かつ十分な制御であり、WLAN 関連の追加的な管理オーバーヘッドを最小限に抑えます。しかし、組織に必要な制御をより多く与えるためには、セキュリティ グループを使用して、WLAN へのアクセスを誰に許可するかを定義しておくとよいでしょう。

「RADIUS ポリシー」で説明したように、IAS リモート アクセス ポリシーには、Wireless LAN Access グループの全メンバに WLAN アクセスを許可するためのフィルタ条件を使用します。次の表に、Wireless LAN Access グループのメンバシップを示します。

表 2.5: Wireless Access グループによる、すべてのユーザーおよびコンピュータのアクセス許可

最上位のユニバーサル グループ (RAP でアクセス権限の付与) 第 1 レベルのメンバ (ドメイン グローバル グループ) 第 2 レベルのメンバ (ドメイン グローバル グループ)
Wireless LAN Access Wireless LAN Users Domain Users
Wireless LAN Access Wireless LAN Computers Domain Computers
1 列目のグループ「Wireless LAN Access」の 2 つのメンバ (「Wireless LAN Users」および「Wireless LAN Computers」) は、2 列目に記載してあります。これらの "第 1 レベル" グループは自身のメンバ (3 列目に示した "第 2 レベルのメンバ") を持ちます。それぞれ Domain Users グループ、および Domain Computers グループです。ネストしたグループをこのように配置することで、ドメイン内の全ユーザーおよびコンピュータからの WLAN への接続が可能になります。 全ユーザーおよびコンピュータから WLAN へのアクセス許可が組織にとって寛大すぎる場合は、これらのグループから Domain Users または Domain Computers、あるいはその両方を削除するとよいでしょう。この削除を行った場合は、Wireless LAN グループに特定のユーザーおよびコンピュータ アカウントを追加しておく必要があります。Wireless LAN Access グループ構造をこのように使用する方法を示したのが、次の表です。 **表 2.6: ワイヤレス アクセス グループによる、選択されたユーザーおよびコンピュータのアクセス許可**

最上位のユニバーサル グループ (RAP でアクセス権限の付与) 第 1 レベルのメンバ (ドメイン グローバル グループ) 第 2 レベルのメンバ (ドメイン グローバル グループ)
Wireless LAN Access Wireless LAN Users User1
User2 User3
Wireless LAN Access Wireless LAN Computers Computer1
Computer2
Computer3

これらのセキュリティ グループをマルチドメイン フォレスト内で使用する方法の詳細については、この章で後述する「大規模組織向けに拡張する」を参照してください。

IAS サーバー用の証明書を取得する

IAS サーバーは、WLAN クライアントを認証するための証明書を保持する必要があります。IASサーバーとクライアント間に TLS 暗号化トンネルを作成するには、サーバー証明書が必要です。TLS は、サーバーとクライアント間での認証処理の保護に役立ちます。

注: TLS は、同様の Secure Sockets Layer バージョン 3.0 (SSL 3.0) をベースとした RFC 標準です。両方とも、Web トラフィックのセキュリティ保護を目的に HTTPS (Hypertext Transfer Protocol, Secure) の一部として一般的に使用されます。

埋め込み CA と民間の CA の相違点

これらの証明書を提供するために、CA を自分でインストールするか、民間証明書プロバイダから証明書を購入するかを選択できます。選択肢は両方とも有効であり、どちらか一方を他よりも優先して選択しても、WLAN ソリューションにとって技術上の大きな違いはありません。

次の表に、自社製 CA を使用した場合と民間プロバイダから証明書を購入した場合の、主な長所/短所の比較を示します。

表 2.7: 自社製 CA または民間の証明書を使用した場合の長所/短所

自社製 CA 民間の CA
証明書あたりのコストが不要 証明書あたりのコストが必要
CA ソフトウェアのインストールおよび管理が必要 サーバー ソフトウェアが不要
登録と更新が自動化されている 証明書の登録処理、手動インストールが比較的複雑になる
独自 CA の管理の複雑度とコストに応じて、引数のバランスが左右されます。セットアップのコストが低くて管理が単純なローカル CA であれば、多くの場合は外部の証明書を購入するよりも魅力的な提案と言えます。 このソリューションでは、単純な自社製 CA を使用して、証明書が提供されます。このガイドの中で用語 "埋め込み CA" と "ネットワーク CA" が使用されているのは、特殊用途向けの (つまり、基本的にはユーザーと管理者からは参照不可能で、1 種類の証明書を発行する) CA であることを示すためです。このソリューションの CA の機能が限定されていることは、ユーザーまたは管理者による介入をほとんどまたはまったく必要とせずにインストールして使用できるという意味です。このソリューションでは、たとえば CA は有効期間が 25 年の証明書を発行するといったことも可能であるため、ソリューションの有効期間中は証明書を更新する必要がありません。IAS サーバー証明書の登録および更新が自動化されているため、証明書を手動で配布せずに済みます。 これを外部の証明書を使用した場合と比較してみましょう。全 IAS サーバーの証明書を毎年または 1 年おきに更新することを思い出す必要があります。各 IAS サーバーに対して証明書要求を手動で作成する必要が生じるたびに、その要求を民間の CA に送信した後、発行済みの証明書を取得して手動でインストールしなければなりません。この作業をしておかないと、ユーザーは WLAN に接続できません。多くの組織において、この管理オーバーヘッドは、このソリューションに使用されている説明済みの単純な内部 CA よりもはるかに面倒なものです。 ##### ソリューション CA の制約 このソリューションには、IAS サーバーに証明書を発行するための、特別な CA 構成が使用されます。この特殊なニーズを満たすことのみを目的に設計されたものであるため、一般目的の証明機関としては不適切です。 デジタル証明書は、セキュリティ保護された電子メールや Web 閲覧、IPSec (IP Security)、仮想プライベート ネットワーク (VPN)、暗号化ファイル システム (EFS) など、多くのアプリケーションで使用されます。これらの各アプリケーションのセキュリティ要件はそれぞれ固有のものです。これらのアプリケーションに関しては、組織のセキュリティ要件も独自の固有なものとなることでしょう。これらの理由から、ソリューション CA を他の目的には使用しないように強く推奨します。 前述したアプリケーションまたは他の証明書アプリケーションを使用する予定がある場合は、そのような要件を核として証明書インフラストラクチャを設計します。検討事項としては、次のものがあります。 - ソリューション CA は、自己署名のルート CA であるため取り消しはできません (発行済み証明書の取り消しが必要となるのは、CA キーが危害を受けた場合です)。 - 業界固有または国固有の規則によっては、一部またはすべての証明書タイプに複数の CA 階層を使用することを義務付けているものもあります。 - 高度なセキュリティ証明を使用するために、ドメイン コントローラ上に CA をインストールすることはお勧めしていません。 より一般的な PKI アーキテクチャの設計に必要な詳細計画については、必携ソリューション「ワイヤレス LAN のセキュリティ強化 (Windows Server 2003 証明書サービス)」の「第 4 章: 公開キー基盤を設計する」を参照してください。 Windows Server 2003 の Standard Edition 上に CA をインストールした場合に適用される制約も数多くあることも覚えておいてください。Standard Edition でサポートされている機能は、Windows Server 2003, Enterprise Edition に比べると制限されますが、このソリューションの用途には十分適しています。Windows Server 2003, Enterprise Edition で使用できない主な機能は、次のとおりです。 - **コンピュータとユーザーの両方の証明書の自動登録**: 自動証明書要求サービス (Windows 2000 Server および Windows Server 2003, Standard Edition で使用) でサポートされているのは、コンピュータ証明書の自動登録のみです。ユーザー証明書は、自動で登録できません。 - **バージョン 2 証明書テンプレート**: Windows Server 2003 および Windows XP で使用されている証明書タイプの多くには、バージョン 2 のテンプレートの高度な機能が使用されます。ただし、Windows Server 2003, Standard Edition をベースとした CA は、バージョン 2 のテンプレートでは証明書を発行できません。 - **編集可能な証明書テンプレート**: バージョン 1 のテンプレートを修正したり、作成したりしても、新しい証明書タイプを作成できません。 - **キーのアーカイブはサポートされていません**。 これらの機能のいずれかが必要な場合は、Windows Server 2003, Enterprise Edition のより高度な機能をベースとした CA が必要です。Enterprise Edition と Standard Edition の相違点の詳細については、この章の最後に記述されている「参照情報」に掲載されている文書「Windows XP Professional と Windows Server 2003 の PKI 拡張機能」を参照してください。 ただし、現時点で他のタイプの証明書に対する明確な要件がないのであれば、将来的にもオプションをクローズせずに、このソリューションに記述されている CA を配置することができます。以降のステージで、証明書に関する他の要件を確認したら、このソリューションと共により高性能な PKI を配置できます。その後、それらを並行して実行することも、新しい PKI からすべての証明書を発行するように移行することも可能です。 #### WLAN クライアント WLAN ソリューションは、いくつかの異なるタイプの WLAN クライアントを明示的にまたは暗黙的にサポートします。このソリューションのサポート対象は、Windows XP, Professional Edition、Windows XP, Tablet Edition、および Pocket PC 2003 クライアントです。ソリューションを使用してこれらのクライアントを構成し、使用する方法に関する特別なガイダンスについては、「第 6 章: ワイヤレス LAN クライアントを構成する」を参照してください。PEAP-MS-CHAP v2 を使用した 802.1X をサポートする他のタイプのクライアントの使用方法については、このガイドでは説明しません。それ以外にも、一部のタイプのクライアント (たとえば、Windows 2000 Professional) が機能しますが、それらのクライアントの構成方法についてはこのガイドでは説明しません。また、それらのクライアントについては、Microsoft Solutions for Security チームがこのソリューションでのテストを実施していません。 ##### Windows XP このソリューションでは、Windows XP, Professional Edition および Windows XP, Tablet Edition が完全にサポートされます。Windows XP クライアントはすべて Service Pack 1 以降で更新する必要があります。コンピュータは、IAS サーバーと同じドメインのメンバ、または同じフォレスト内の別のドメインのメンバでなければなりません。コンピュータが自身を WLAN に対して認証し、グループ ポリシーで指定された WLAN 設定をダウンロードするには、ドメイン メンバシップが必要です。 コンピュータにユーザーがログオンしていない場合、WLAN に対してコンピュータ認証が使用されます。これにより、コンピュータはグループ ポリシー オブジェクト (GPO) 設定の取得、スタートアップ スクリプトの実行、および修正プログラムのダウンロードを可能にします。このコンピュータ認証は、ユーザー ログオンの初期ステージの間も必要です。ユーザーがユーザー プロファイルのロードの実行が完了するまでは、WLAN に対して認証を開始できません。そのため、ユーザーがログオンする前に、コンピュータがネットワークへの既存の接続を保持していないと、ログオン スクリプト、他の GPO 設定、およびローミング プロファイルは機能しなくなります。 ドメイン メンバでない Windows XP コンピュータをこのソリューションでも使用する場合の注意点は、次のとおりです。 - WLAN クライアント設定は手動で構成する必要があります。 - WLAN に対するコンピュータ認証の実現は困難です。 - WLAN に対するユーザー認証には、別個のユーザー名およびパスワードのプロンプトが必要です。このプロンプトからユーザーが自分のドメイン (WLAN) 資格情報を入力します。 ワイヤレスを使用してすべてのクライアント コンピュータ上のパーソナル ファイアウォールを有効化することも強くお勧めします。 ##### Pocket PC 2003 Pocket PC 2003 は、802.1X および PEAP をサポートしますが、WLAN の全機能を取得するには、デバイスのベンダおよびマイクロソフトからアップデートを取得する必要があります。2003 以前のバージョンの Pocket PC を使用することも可能ですが、以前のバージョンについては、マイクロソフトから 802.1X のビルトイン サポートは提供されていません。Pocket PC デバイス ベンダから特定のサポートを取得するか、サードパーティ製 WLAN クライアント ソフトを使用してください。 Pocket PC システムはコンピュータ ドメイン アカウントの概念を持たず、ユーザー資格情報を使用して WLAN に対して常に認証されます。ユーザーは通常、WLAN に接続するたびに自分のドメイン ユーザー名およびパスワードの入力を要求されます。資格情報を保存しておくと、デバイスを自動で接続することが可能になりますが、Pocket PC デバイス上にきわめて強固なセキュリティ機能を装備していない限り、これはお勧めできません。 さらに、Pocket PC はグループ ポリシーを理解しないため、このグループ ポリシーを使用して WLAN 設定値を自動的に設定することはできません。WLAN の構成を手動で設定します。 ##### その他の 802.1X クライアント Windows XP および Pocket PC 2003 以外のクライアントが 802.1X および PEAP MS CHAP v2 をサポートする場合、このソリューションと連携動作することができます。Windows 2000 クライアントは、Windows 2000 Microsoft 802.1X Authentication Client を使用してサポートされます。Windows 2000 Microsoft 802.1X Authentication Client の取得方法の詳細については、この章の最後に記述されている「参照情報」を参照してください。Windows 2000 以外の Windows クライアント (Windows NT 4.0、Windows 9**x、Windows Me など) は、Microsoft Premier Support から入手可能なクライアントでサポートされます。これらのプラットフォームに対応したクライアントを取得することも、マイクロソフト以外のネットワーク ソフトウェア ベンダから提供されている他のプラットフォームに対応したクライアントを取得することもできます。 詳細については、「付録 C: サポートされるオペレーティング システムのバージョン」も参照してください。 ##### WPA のサポート ここで説明する WLAN ソリューションは、動的 WEPの代わりに WPA (WiFi Protected Access) WLAN 保護機能の使用をサポートします。WPA は、常に WEP よりも優先されます。これは、WPA を使用するとより適切なキー管理が可能になるだけでなく、より強力なネットワーク暗号化アルゴリズムを実装することも可能となるためです。ハードウェア (ワイヤレス AP およびネットワーク アダプタ) で必要なサポートが提供されている場合、WPA により AES 暗号化方式の使用もサポートされます。 WPA を使用すると、動的キー設定に比べて多くの長所が得られますが、その使用方法についての注意点がいくつかあります。その注意点は、次のとおりです。 - Windows Server 2003 Service Pack 1 以降でのみ、WPA 上での WLAN クライアント設定値の構成が GPO でサポートされます。 - Windows XP 以外のシステムをクライアントでサポートできません。マイクロソフトは Pocket PC 2003 については WPA によるサポートの提供を予定していますが、Windows 2000 および他のマイクロソフト クライアントはサポート対象外です (これらのクライアントについては、WPA によるサポートがマイクロソフト以外のベンダから提供される可能性があります)。 - 既存の WLAN 機器 (ワイヤレス AP やクライアント ネットワーク アダプタ) をアップグレードしても、WPA がサポートされない場合があります。また、新規にハードウェアを購入して配置する場合には、法外なコストがかかる可能性もあります。 GPO および Pocket PC 2003 での WPA に対するサポートは近日中に提供され、WPA は選択可能なオプションになる予定です。それまでは、動的 WEP と 802.1X 認証とを組み合わせて使用することで、引き続き WLAN に対する保護がきわめて高いレベルで実現されます。これは、このソリューションでのデフォルト選択肢です。WPA の詳細については、この章の最後に記述されている「参照情報」を参照してください。 #### 既存の WLAN から移行する 既存のワイヤレス ネットワークが存在する場合、ユーザーと環境への影響を最小限に抑えるために、あらかじめ移行計画を立てておく必要があります。 多くの組織では、ネットワーク認証や暗号化なしで 802.11 ベースの WLAN を稼働させています。一方、共有キー暗号化方式を使用した静的 WEP (Wired Equivalent Privacy) を実装し、MAC (媒体アクセス制御) アドレス フィルタ機能と組み合わせて使用する組織もあります。 これらのいずれかの WLAN から 802.1X でセキュリティ保護された WLAN への移行処理のシナリオでは、次の処理を実行する必要があります。 1. **IAS サーバーへの証明書の配置**: IAS サーバーへ証明書を配置する方法の詳細については、このガイドの「第 4 章: ネットワーク証明機関を構築する」を参照してください。 2. **IAS サーバー上でのワイヤレス ネットワークのリモート アクセス ポリシーの構成**: ワイヤレス ネットワークのリモート アクセス ポリシーを構成する処理については、このガイドの「第 5 章: ワイヤレス LAN のセキュリティ インフラストラクチャを構築する」を参照してください。 3. **新しい WLAN 用の WLAN 構成のクライアント コンピュータへの配置**: 新規の 802.1X 対応ネットワークには、新規のネットワークサービス セット識別子 (SSID) が必要です。SSID が設定してある場合、新規の WLAN 用ネットワーク設定を Active Directory GPO により配置できます。LAN アクセスを不定期にしか行わないモバイル コンピュータにも確実に構成を渡すために、WLAN グループ ポリシーはワイヤレス AP の再構成を行う前に展開する必要があります。詳細については、「第 6 章: ワイヤレス LAN クライアントを構成する」を参照してください。 4. **802.1X セキュリティを必要とするワイヤレス AP の構成**: 通常はサイト単位 (たとえば、ビル単位やキャンパス単位) で構成するのが最も望ましく、この構成は時間外に実施するか、WLAN の機能停止についての適切な警告をユーザーに出して実施します。サイト上の全 AP の IAS 用に RADIUS クライアント エントリを作成し、AP の RADIUS エントリ用 IAS サーバーのアドレスを使用して AP を構成して、最後に 802.1X 認証クライアントだけが許可されるように AP を切り替えます。ロールバックを容易にするために、この処理を開始する前にワイヤレス AP 設定のバックアップを作成しておく必要があります。バックアップの作成により、緊急事態が発生した場合に復旧が可能になります。 このタイプのロールアウトは、ユーザー側の混乱を最小限に抑えます。また、なんらかの障害が発生した場合、サイトを容易にロールバックできます。AP の切り替え中は、ユーザーが必然的になんらかの問題に遭遇するものです。そのため、移行に関する情報をユーザーに絶えず提供して、通常より多くのサポートの問い合わせに応じる準備をしておく必要があります。 どのような移行計画の場合もそうであるように、計画およびテストは慎重に実行してください。初期の問題を解決するために徹底的にテストしておかないと、クライアント コンピュータとワイヤレス AP の構成に関する処理が環境に悪影響を与えるおそれがあります。 セキュリティ保護されていない WLAN および静的 WEP WLAN からの移行計画、または独自の WLAN セキュリティ スキーマからの移行計画については、このガイドでは詳しく説明しません。これらはすべて基本的に同様であり、上述のパターンに従います。ただし、移行計画についてさらに多くの支援が必要な場合、マイクロソフトのパートナーに問い合わせてください。また、最寄りのマイクロソフト支社に問い合わせると、お客様の地区のマイクロソフトのパートナーまたは Microsoft Consulting Services に連絡できます。 [](#mainsection)[ページのトップへ](#mainsection) ### 大規模組織向けに拡張する ここでは、大規模組織 (たとえば、ユーザー数が数千にも達する組織) でこのソリューションを使用する場合の重要ないくつかの考慮事項について説明します。エンタープライズでの PEAP およびパスワード認証の使用については、「付録 A: エンタープライズで PEAP を使用する」を参照してください。 #### IAS サーバーを配置する WLAN をサポートする場所の数を増やした場合は、IAS サーバーからこれらのワイヤレス AP へのサービス提供方法を決める必要があります。基本的には、次の 2 つの方法があります。 - **中央 IAS サーバーを少数使用**: すべての WLAN 認証トラフィックに対処する中心的な IAS サーバーを少数 (2 台あれば十分であると想定) 使用します。辺境のオフィスと IAS サーバー間の WAN 接続に障害回復力のあることを確認する必要があります。 - **IAS サーバーを各オフィスに分散**: オフィスの規模には下限があります。これは経済的な意味になりますが、原則として独自のドメイン コントローラの配置が可能な程度の十分大規模なオフィスであれば IAS をローカルに配置 (通常は、ドメイン コントローラ上にインストール) できます。 ネットワークの障害回復力への投資は多大なコストのかかるオプションのように思えるかもしれませんが、このコストを多数の分散 IAS サーバーの管理にかかる管理コストと突き合わせて比較検討する必要があります。既存のドメイン コントローラと同じ物理サーバー上に IAS がインストールされている場合、各 IAS インスタンスの管理になんらかのコストが生じます。実際問題として、ほとんどの大規模組織では、この 2 つのハイブリッドが次の方法で使用されます。 - IAS サーバーを集中化して、想定できるすべての場所で WAN の障害回復力に投資する。 - WAN の障害回復力が達成不可能または法外なコストがかかる各オフィスに IAS を分散させる。 - 接続性が低いきわめて小規模なオフィスや従業員ホーム オフィスでは、事前共有キー (PSK) WPA WLAN を使用する。 IAS 集中化戦略は、この章で前述の「IAS サーバーを配置する」で図示しました。次の図に、支社でのローカル ドメイン コントローラおよび IAS の使用状況を示します。この図に示す大規模な辺境のオフィスは、前の図 2.4 で示した本社へ WAN でリンクされます。 ![](images/Dd362890.PEAP_207(ja-jp,TechNet.10).gif) **図 2.7 ローカル ドメイン コントローラおよび IAS を装備した大規模な支社** [拡大表示する](https://technet.microsoft.com/ja-jp/dd362890.peap_207_big(ja-jp,technet.10).gif) このサイトでは、ローカル IAS サーバーがプライマリ RADIUS サーバーとして使用され、本社にある IAS サーバーの 1 台がセカンダリ RADIUS サーバーとして使用されるように AP が構成されています。これは、ローカル IAS サーバーまたは WAN への接続性が失われた場合でも、WLAN クライアントの認証が可能であることを意味します。 ただし、障害回復力を備えた WAN 接続性を持つ場合 (たとえば、複数の WAN がそれぞれ異なるプロバイダとリンクされているなど)、支社に追加のサーバーを配置しても影響はほとんどありません。複雑さが増すと共に、管理オーバーヘッドが上乗せされるだけです。 #### 複数ドメイン 基本的なソリューション設計は、複数ドメイン フォレストに透過的にスケーリングします。複数ドメインでソリューションを使用するときに考慮すべき重要な点は、次のとおりです。 - IAS サーバーは、WLAN へアクセスするユーザーまたはコンピュータを持つ各ドメインで登録する必要があります。詳細については、「第 5 章: ワイヤレス LAN のセキュリティ インフラストラクチャを構築する」を参照してください。 - サーバー設定および自動証明書要求設定用の GPO は、IAS サーバーがインストールされているすべてのドメインにインポートする必要があります。詳細については、「第 3 章: 環境を準備する」および「第 4 章: ネットワーク証明機関を構築する」を参照してください。 - クライアント コンピュータの WLAN 設定を制御する GPO は、WLAN にアクセスするクライアント コンピュータが存在する各ドメインで作成する必要があります。詳細については、「第 6 章: ワイヤレス LAN クライアントを構成する」を参照してください。 - IAS がリモート アクセス ポリシーのフィルタに使用するセキュリティ グループは、複数ドメインをサポートするように構成する必要があります。 最初の 3 つの項目はほとんど自明です。これらを複数ドメイン用に構成する処理については、後述します。セキュリティ グループの使用方法はやや複雑であるため、次で詳しく説明します。 ##### 複数ドメインでのセキュリティ グループを使用する 次の表に、複数ドメイン フォレストの「WLAN ユーザーとコンピュータの管理モデル」で説明されている、セキュリティ グループを系統立てて編成する方法を示します。 **表 2.8: ワイヤレス アクセス グループによる、すべてのユーザーおよびコンピュータの許可**

最上位のユニバーサル グループ (RAP でアクセス権限の付与) 第 1 レベルのメンバ (ドメイン グローバル グループ) 第 2 レベルのメンバ (ドメイン グローバル グループ)
RootDom\Wireless LAN Access UserDom1\Wireless LAN Users UserDom1\Domain Users
RootDom\Wireless LAN Access UserDom2\Wireless LAN Users UserDom2\Domain Users
RootDom\Wireless LAN Access UserDom3\Wireless LAN Users UserDom3\User1
UserDom3\User2
UserDom3\User2
RootDom\Wireless LAN Access UserDom1\Wireless LAN Computers UserDom1\Domain Computers
RootDom\Wireless LAN Access UserDom2\Wireless LAN Computers UserDom2\Domain Computers
RootDom\Wireless LAN Access UserDom3\Wireless LAN Computers UserDom3\HR Computers
UserDom3\Finance Computers

この表は、「WLAN ユーザーとコンピュータの管理モデル」の表と同じグループのネスト状の構成を示したものです。1 列目にリストされたグループのメンバは 2 列目にリストされます。同様に、2 列目にリストされたグループのメンバは 3 列目にリストされます。

表中の例には架空の名前が使用されます。たとえば、RootDom は IAS サーバーがインストールされているドメインの名前であり、UserDom1 および UserDom2 は WLAN へのアクセスを許可されたユーザーおよびコンピュータが含まれている他のドメインです。

ここに示した例では、UserDom1 および UserDom2 からのユーザーおよびコンピュータはすべて WLAN へのアクセスを暗黙的に許可されます。なぜなら、これらのドメインからの Domain Users グループおよび Domain Computers グループは、同じドメインの Wireless LAN Users グループおよび Wireless LAN Computers グループのメンバであるためです。ただし、UserDom3 からのユーザーは個々に UserDom3 の Wireless LAN Users グループに追加されます。コンピュータは、ビジネス ユニットのセキュリティ グループ (たとえば、人事部門にあるすべてのコンピュータ) を使用してアクセス権限を付与されます。

その後、各ドメインのグローバル グループ (つまり、Wireless LAN Users グループおよび Wireless LAN Computers グループ) は、ユニバーサル グループ Wireless LAN Access のメンバとして追加されます。この後者のグループの全メンバは、リモート アクセス ポリシーで WLAN へのアクセス権限を付与されます。

PKI アーキテクチャ

前の「IAS サーバー用の証明書を取得する」で説明したように、アプリケーションの多くが証明書を利用できます。スタンドアロン CA がこのソリューションに対して適当であっても、大規模組織の多様なニーズを満たす見込みがあまりないことは、注意すべき重要な点です。このガイドで説明されている CA を実装する前に、これらのシナリオに適切な代替の PKI アーキテクチャについてだけでなく、将来的に取得する可能性のある証明書の、他の用途についても詳細に検討してください。

PKI 計画の詳細については、必携ソリューション「ワイヤレス LAN のセキュリティ強化 (Windows Server 2003 証明書サービス)」の「第 4 章: 公開キー基盤を設計する」を参照してください。そのソリューションで説明されている PKI は、このガイドにある CA に比べると精巧ですが、たとえば CA が 2 つしか使用されていないという点では、やはり比較的単純です。ただし、証明書に関するかなり広範なニーズに応じるための基盤となるように設計されています。

たとえば、このような精巧な PKI を実装しないことを決定した場合でも、やはり、このガイドの「第 4 章: ネットワーク証明機関を構築する」にあるガイダンスを利用できますが、その章にある指示を次のように変更することを考えることも必要です。

  • CA をドメイン コントローラ上にインストールする代わりに固有のサーバーにインストールします。

  • Windows Server 2003, Enterprise Edition を使用することで、将来さらに柔軟に対応できます。

  • 自動証明書要求サービスを使用する代わりに、Windows Server 2003 自動登録を使用します。自動登録の使用方法については、Windows Server 2003, Enterprise Edition の製品マニュアルを参照してください。

  • "コンピュータ" テンプレートを使用する代わりに、"RAS および IAS サーバー" 証明書テンプレートを使用するか、IAS サーバー証明書用の顧客証明書タイプを作成します。

    注: 証明書テンプレート名の中の "RAS" は、Remote Access Service (リモート アクセス サービス) の略称です。

これらの実施方法については、Windows Server 2003 製品マニュアルの公開キー基盤 (PKI) に関するセクションの他、必携ソリューション「ワイヤレス LAN のセキュリティ強化 (Windows Server 2003 証明書サービス)」の「第 4 章: 公開キー基盤を設計する」、「第 7 章: 公開キー基盤を実装する」、および「第 9 章: 802.1X を使用してワイヤレス LAN セキュリティを実装する」のガイダンスを参照してください。

ページのトップへ

ソリューション アーキテクチャのバリエーション

ここでは、コア デザインのバリエーションについて説明します。ソリューションのデフォルト セキュリティ設定の代替、IAS サーバーを使用したワイヤード/リモート アクセス認証、ゲスト WLAN の作成、およびホーム オフィスなどのきわめて小規模な環境への WLAN の配置については、次のサブセクションで説明します。

動的 WEP 用のセキュリティ オプション

この章で前述した「PEAP およびパスワードを使用した場合の 802.1X の動作」では、ソリューションで動的 WEP 暗号化方式を使用する方法について説明しました。動的 WEP のセキュリティは、定期的な間隔で暗号化キーを更新する独自機能によって、WEP プロトコルに対する既知の攻撃を阻止します。IAS ではクライアント セッション タイムアウトを使用して各ワイヤレス クライアント用のキーが一定間隔で更新されるようにしており、これによりクライアントに WLAN に対する再認証が強制されます。

セッション タイムアウト値を減らすとセキュリティが向上しますが、信頼性およびパフォーマンスは低下する可能性があります。タイムアウトが 60 分の場合、ほとんどの情況に対して十分適応できる (11 Mbps の 802.11b ネットワークに確実に対応する) セキュリティが提供されます。通常、攻撃者が WEP キーを復元してしまえる十分なデータは、60 分ではワイヤレス クライアントから転送できません。

最近の研究によると、同じキーで暗号化された 100 万 ～ 500 万のネットワーク パケットのキャプチャで、静的 WEP キーが復元できるということです。このことは、AT&T Labs の Adam Stubblefield、John Ioannidis および Aviel D. Rubin 著の技術論文「Using the Fluhrer, Mantin, and Shamir Attack to Break WEP」(英語) に記載されています。この章の最後に記述されている「参照情報」を参照してください。

注: 100 万パケットという統計は、比較的脆弱なキー ("ユーザーにとって覚えやすいパスフレーズ") を使用して、静的 WEP WLAN をテストして得られたものであるため、動的 WEP WLAN に直接には当てはまりません。一般的な静的 WEP WLAN とは異なり、動的 WEP には強固でランダムな暗号化キーが使用されているため、作者が使用したキーの 1 つを最適化させる効果はかなり低くなっています。ただし、注意しすぎて過ちを犯し、動的 WEP WLAN へのセキュリティの脅威を評価するのに 100 万のパケットという悲観的な数字を使用するくらいであれば、セキュリティ上の習慣としては万全です。

通常は 100 万パケットが約 500MB のデータ (平均パケット サイズは想定 500 バイト) に相当します。暗号化したデータをセキュリティ保護するには、これを越える量のデータがクライアントから送信される前に各クライアントのキーが強制的に更新されるように、セッション タイムアウトを設定しておく必要があります。

クライアント ネットワークが一般的な用途 (電子メール、Web 閲覧、ファイル共有など) に使用されている場合、平均データ転送速度は 160Kbps 以下になります。この転送速度では、パケット サイズとして 500 バイトが想定されているため、攻撃者がクライアントの現在の暗号化キーを復元するための十分なデータを蓄積するのに、約 7 時間かかることになります。

注: ラボの条件では、500 Mb を 7 時間未満 (11 Mbps の WLAN では約 10 分、54 Mbps の WLAN では 3 分未満) で転送することが可能です。ただし、ここで想定するのは、WLAN を排他的に使用していて、非承認 UDP パケットを一方向へストリーミングする単一クライアントです。実際の WLAN では、このシナリオまたはそれに近いなんらかの事態は、まず起こらないでしょう。

セッション タイムアウトが 60 分であれば、ほとんどの組織には十分適しています。つまり、各キーがリフレッシュされる前に平均的なクライアントから約 15 万パケットが転送され、WEP キーの解読に必要なパケットのしきい値は 100 万未満であるということです。ただし、次の理由 (1 つまたは複数) によって、もっと短いタイムアウト値を使用しなければならない場合もあります。

  • 比較的短期間で大量のデータを WLAN 経由で送受信するワイヤレス クライアントを保有する場合は、タイムアウトを、単一のクライアントが 75 MB の送受信に要する時間よりも短い持続時間に設定する必要があります。この場合、WEP キーの復元に必要なデータ量の 20 パーセントを下回るため、より安全率が高くなります。

  • 802.11a または 802.11g の 54 Mbps WLAN を使用すると、所定の時間でより多くのパケットをもっと容易に転送することが可能になります。これらの高速 WLAN では、セッション タイムアウトを 15 分に減らしても十分です。

  • WEP キー解読技術の有能性が著しく向上すると、WEP キーの復元に必要なデータが少量で済みます。たとえば、キーの復元を 10 万パケットだけを使用して可能にする暗号解読技術が新たに発見された場合には、暗号化キーの更新前にワイヤレス クライアントがこの限度に達するのを阻止するために、セッション タイムアウトを短くしておく必要があります。

  • 専門家レベルのセキュリティ ニーズがある場合は、WEP に対する理論的攻撃さえ成功するしきい値を下回るように (前述したように 10 分ないし 3 分に) タイムアウトを短くします。ただし、この決定については、ここで後述する注意点も考慮して比較検討する必要があります。このレベルの予防策が必要な機密なデータについては、WLAN に対して WPA (Wi-Fi Protected Access) データ保護のみを使用し、IP セキュリティを使用してワイヤード LAN 経由で転送されるデータの保護に役立てることも考慮してください。

セッション タイムアウトを短くした場合の主な短所としては、次の 2 つがあります。

  • WLAN 信頼性の低下: WLAN セッションのタイムアウトが非常に短い場合、ドメイン コントローラまたは IAS サーバーとの通信が一時的に失われると、クライアントが再認証に失敗して WLAN との接続が切断される可能性があります。

  • IAS サーバー上の負荷の増大: タイムアウトが短いほど、クライアント IAS サーバーおよびドメインコントローラでの再認証が必要とされる頻度が増えます。結果として、IAS サーバーおよびドメイン コントローラ上の負荷が増大します。IAS がクライアント認証セッションをキャッシュするため、負荷の増大が著しいのは、通常、膨大な数のワイヤレス クライアントを保有する組織のみ、または使用されているセッション タイムアウト値が非常に短い場合のみに限定されます。

その他のネットワーク アクセス サービス

このソリューションで使用される RADIUS 設計は、他のネットワーク アクセス サーバーに対応した認証、承認、およびアカウンティング サービス (たとえば、802.1X ワイヤード ネットワーク認証、VPN 認証、リモート アクセス認証) を提供できます。

802.1X ワイヤード ネットワーク認証

802.1X ワイヤード ネットワーク認証は、基本的な RADIUS 設計に変更を加える必要のない、最も単純なアプリケーションです。広く分散されたワイヤード (有線) ネットワーク インフラストラクチャを持つ組織では、企業ネットワークの不正利用の管理が困難な場合があります。たとえば、ビジターによるラップトップ接続を禁止したり、従業員が承認されていないコンピュータをネットワークに追加できないようにすることは、一般的に困難です。データセンターなどのネットワークの一部は、高セキュリティ ゾーンとして指定される場合があり、そのようなネットワーク上で許可されるのは承認されたデバイスのみです。これは企業のコンピュータを使用する従業員が除外される可能性もあります。

次の図に、ワイヤード (有線) ネットワーク アクセス ソリューションと設計の統合を示します。

図 2.8 802.1X ワイヤード認証の使用

拡大表示する 太い境界線付きのボックスは、802.1X ワイヤード コンポーネントを表します。他のボックスには、関連するサービスが含まれています。この図を図 2.4 と比較してください。この図2.8 に示してあるのは本社だけです。

802.1X 対応のネットワーク スイッチは、コア ソリューション内のワイヤレス AP と同じ役割を果たし、同じ RADIUS インフラストラクチャを使用してクライアントを認証し、適切なネットワーク セグメントに対するアクセスを承認します。この方法には、企業ディレクトリ内のアカウント管理を中央集中化できるという明確な長所がありますが、ネットワーク アクセス ポリシーは従来どおり、ネットワーク セキュリティ管理者によって管理されます。

VPN およびリモート ダイヤルアップ認証

RADIUS コンポーネントを利用できるその他のネットワーク アクセス サービスとして、VPN とリモート ダイヤルアップがあります。特に大規模な組織では、RADIUS プロキシの追加など、現状の設計になんらかの追加を行わなければならない場合があります。次の図に、拡張されたソリューションを示します。

図 2.9 VPN をサポートするための RADIUS コンポーネントの拡張

拡大表示する このバリアント内の VPN サーバーは、コア デザインのワイヤレス AP と機能的に同じ役割を果たします。VPN サーバーはクライアントの認証要求を RADIUS インフラストラクチャに渡します。RADIUS の要求を内部 IAS サーバーに直接に渡すことも可能ですが、組織の多くは、RADIUS プロキシのレイヤをさらに追加して特別なセキュリティ レイヤを提供し、要求を内部 IAS サーバーに転送することの方を好みます。

このソリューションでは、ワイヤード ネットワーク セキュリティを使用した場合と同様、同じ長所 (既存のインフラストラクチャの再利用、およびアカウント管理の一元化) を得ることができます。スマート カードベースのユーザー認証を利用するなど、さらに拡張することも可能です。マイクロソフト提供の内部リモート アクセス VPN ソリューション (企業の自社スタッフ用) でも、ユーザー認証用スマート カードを使用したほぼ同じ VPN および RADIUS アーキテクチャを使用します。

ダイヤルアップ リモート アクセスも、Windows Server 2003 の Routing and Remote Access の VPN 機能の代わりに、ダイヤルアップのサーバー機能を使用することで同様に機能します。

IAS を使用することで得られる、VPN およびリモート ダイヤルアップの両方に対する大きな長所は、Windows Server 2003 Network Access Quarantine Control が利用可能になることです。Quarantine Control では、ルーティングとリモート アクセス サーバー (RRAS)、および Windows 拡張リモート アクセス クライアント (Connection Manager) の機能を使用して、クライアント コンピュータのセキュリティ状態に基づいてアクセスを許可または拒否します。これは、接続時にクライアントに対してチェックを実行 (たとえば、クライアントが最新のアンチウイルス ソフトウェアを使用するか、また企業が承認したオペレーティング システム ビルドを実行するかなどを確認) することで機能します。クライアントがこれらのチェックに失敗した場合、RADIUS サーバーは、そのクライアントによるネットワーク アクセスを拒否します。このため、認証されたユーザーやコンピュータであっても、企業ネットワークに対して想定されるセキュリティ上の脅威を引き起こした場合は、アクセスが拒否されます。

Windows Server 2003 の検疫機能の詳細については、この章の最後に記述されている「参照情報」を参照してください。

クライアント コンピュータをブートストラップする

ほとんどのワイヤレス コンピュータには、ワイヤード ネットワーク インタフェースも備わっています。これにより、クライアントが比較的容易に WLAN に接続する前にドメインへの参加、および WLAN 設定のダウンロードが可能となっています。しかし、必ずしもそうとは限りません。ハンドヘルド デバイスに既存で装備されているのはワイヤレスのみで、ワイヤード ネットワーク アダプタは装備されていません。これは、WLAN への接続の前に、クライアントのブートストラップに関する問題が発生することを意味します。これは、WLAN への接続に必要な設定および資格情報が得られないためです。

組織がワイヤード 802.1X とワイヤレス 802.1X セキュリティの両方を使用することを決定した場合、問題はいっそう面倒になります。これは、クライアントが最初に適切な資格情報および設定を持たない限り、ワイヤード LAN に接続できないためです。

ワイヤード LAN を使用して設定および資格情報を取得できない場合、クライアント コンピュータをブートストラップするには、次の 2 つの主な方法があります。

  • ゲスト LAN を使用し、代替の認証されたの接続 (たとえば、VPN 接続) を使用して、資格情報および設定を取得する。

  • クライアントを手動で構成する。

マイクロソフトが現在サポートするのは、2 つ目のオプションだけです。マイクロソフトは、"ゲスト" WLAN を使用して、クライアント コンピュータの WLAN 構成のブートストラップに適したワイヤレス プロビジョニング サービスをリリースする予定です。それまでは、クライアント コンピュータのブートストラップを完了するための単純な方法は、手動による構成です。クライアント コンピュータ環境を構成してドメインに参加させるには、コンピュータの構成ユーザーが、そのコンピュータ上のローカル管理者グループのメンバになる必要があります。

手動による構成でコンピュータをブートストラップするには

  1. 適切な WLAN SSID 用の WLAN 設定を手動で構成します。

  2. 有効なユーザー ドメイン資格情報を使用して、WLAN へ接続します。コンピュータがドメインに参加するまでは、コンピュータ アカウントでの接続はできません。

  3. コンピュータをドメインに参加させて再起動します。

  4. 再起動後は、クライアントがコンピュータ アカウントを使用して WLAN に接続し、WLAN の GPO 設定値をダウンロードできます。これらの設定値は、手動で構成された設定のみを上書きします。

  5. これで、ユーザーとコンピュータの両方が WLAN に接続できるようになりました。

SOHO 環境

IAS インフラストラクチャを使用したユーザー認証が不可能かつ非実用的な場所に、WLAN を配置する必要が生じる場合もあります。たとえば、定期的に在宅勤務するユーザーの自宅兼オフィスや、法人ネットワークへの接続の信頼性がきわめて低いまたは低帯域幅の小規模オフィスなどです。

以前なら、これに対する唯一のソリューションは、静的 WEP セキュリティを構成しておき、WLAN をあえて攻撃するほどの果敢な仕業を受けないことを望むくらいでした。それよりもはるかに優れたソリューションは、PSK モードで WPA を使用することです。WPA セキュリティは、従来の AP ではサポートされていませんでしたが、現バージョンの Wi-Fi 認定のワイヤレス AP はすべて、WPA セキュリティと共に出荷されるようになりました。WPA で提供されているセキュリティ上の価値を得るには、使用している AP が WPA の PSK をサポートすることを確認する必要があります。静的 WEP とは異なり、暗号化されたトラフィックからは WPA 認証キーを復元できません。このため、攻撃者によるネットワーク遮断はきわめて困難になります。強固な WPA キーの使用および定期的変更のトレーニングをユーザーに受けさせ、WPA キーの定期的変更を怠った場合のセキュリティ上の影響を理解してもらうようにする必要があります。WPA PSK を実装するには、ワイヤレス AP、ワイヤレス ネットワーク アダプタ、および WPA をサポートするクライアント オペレーティング システム (たとえば、Windows XP) が必要です。RADIUS サーバーなどの、サーバーのインフラストラクチャは必要ありません。

ページのトップへ

要約

この章では、最初に 802.1X ワイヤレス LAN のセキュリティのしくみについて説明しました。設計に焦点を当てるために、ソリューションの対象組織の図のほか、その組織における WLAN ソリューションに対する重要な設計基準も掲載しています。さらに、選択された WLAN 設計の主要な側面について説明しました。この設計では、ネットワーク、IAS サーバーの配置と IAS の構成、証明書の使用、および各種のワイヤレス クライアントをカバーしました。また、既存 WLAN からの移行に関する要点についても説明しました。

章の最後の 2 つの項では、基本設計の重要なバリエーションについて説明しました。最初に、大規模組織用にソリューションを拡張する方法について説明し、コア ソリューションから発展させた主要ポイントの処理方法について説明しました。次に、同じ基本認証インフラストラクチャを使用して他のネットワーク サービス (たとえば、リモート アクセス、VPN、ワイヤード ネットワーク セキュリティ) をサポートする方法、およびクライアントをブートストラップする際や SOHO 環境に WLAN を配置する際の、面倒な問題に対する対処方法について図示して説明しました。

次の章では、ソリューションの実装を開始します。ネットワーク、Active Directory、および WLAN コンポーネントの配置に対するサーバー セキュリティの準備に役立ちます。

ページのトップへ

参照情報

ここでは、この章の内容に関連する重要な補足情報やその他の参考資料を紹介します。

ページのトップへ