次の方法で共有

管理されていないクライアントからネットワークを保護する

公開日: 2006年12月25日

ダウンロード

『Get the Protecting a Network from Unmanaged Clients』(英語) をダウンロードする

トピック

はじめに

定義

課題

ソリューション

概要

付録 A : ネットワーク アクセスの保護

はじめに

この文書は、中規模ビジネス セキュリティ ガイダンスの一部として提供されています。 Microsoft は、次の情報を得ることでさらにセキュリティが強化され、より生産性の高いコンピュータ環境が皆様の組織で実現されることを望んでいます。

要点

セキュリティが重視される今日の環境において、中規模ビジネス ネットワークおよびネットワーク内のデータを高度に保護する方法は、非常に複雑な課題となっています。 企業のネットワーク資産および機密情報を保護するには、境界防御およびウイルス対策スイートに頼るだけでは十分とはいえません。 昨今では、セキュリティ組織および専門家は、意図的または偶発的であるかにかかわらず、内部ネットワークのリスクが外部からの脅威より危険な可能性があることを理解しています。

中規模ビジネスを危険にさらす無数の脆弱性に対処するために、膨大な時間とリソースの投資が、更新プログラムの管理、マルウェア対策ソリューション、および ID 管理イニシアチブなどの分野で行われてきました。 これらの投資が例外なく企業内で使われ、投資の効果を最大限にするには、企業は、効果的にセキュリティ ポリシーを実施する方法を手に入れる必要があります。

既存のセキュリティ ポリシーに準拠しているか判断する方法がないために、本質的なリスクがあるかどうかを検証されていないシステムを承認されていないコンピュータと呼びます。 承認されていないコンピュータは、システム管理者およびセキュリティ専門家にとって問題になる場合があります。 ポリシーに準拠していないシステムは、マルウェアへの感染からプラットフォームが攻撃を受ける可能性まで、数多くのリスクを引き起こします。 従来、こうしたシステムを管理してポリシーに準拠させるのは困難でした。

この文書では、セキュリティ ポリシーへの準拠を実施するために採用できる効果的な方法について説明します。 この方法により、リスク管理への取り組みから得られる利益を最大限に引き出し、中規模ビジネス ネットワークのセキュリティをさらに強化することで、信頼されていないコンピュータや管理されていないコンピュータが原因となるリスクを軽減することができます。

概要

この文書では、管理されていないコンピュータからの中規模ビジネス ネットワークの保護に関する概念および原則を、読者が容易に理解できるように、4 つの主なセクションに分けて詳細に説明しています。 これらの 4 つの主なセクションの概要を次に紹介します。

はじめに

このセクションでは、この文書の要点、構成の概要、および対象読者に関する情報を紹介します。

定義

このセクションでは、この文書で説明するソリューションを理解するために役立つ詳細および定義について説明します。

課題

このセクションでは、管理されていないコンピュータや信頼されていないコンピュータからネットワークを保護する方法を決定する際に、中規模ビジネスが直面する可能性がある共通の問題について説明します。 また、この文書で扱う問題に関する一般的な背景を紹介します。

ソリューション

このセクションでは、管理されていないコンピュータによって引き起こされる問題に対応するソリューションについて説明し、　企業で採用可能な方法を判別し、問題に対処するための計画の作成に関する課題について説明します。 また、ソリューションの導入および管理の方法に関する情報も提供します。

対象読者

この技術文書は、技術の専門家および技術管理者が、中規模ビジネス ネットワークを管理されていないデバイスによって引き起こされる脅威から保護する方法を理解し、適切な情報に基づいた判断を下すための情報を提供することを目的としています。 専門知識を持たない読者の方でも、この文書を読むことでこの特定のセキュリティ問題について理解を深めることができますが、この文書で説明する題材について完全に理解し、応用するためには、次の項目の基本知識が役に立ちます。

この文書で説明する具体的なテクノロジには、次が含まれます。

  • IEEE 802.1X 認証

  • IPSec ポリシー

  • ネットワークのセキュリティ

  • Microsoft® Systems Management Server 2003

  • Microsoft Windows Server™ 2003

  • Active Directory® ディレクトリ サービス

  • Microsoft Operations Management Server

  • Microsoft インターネット認証サービス

  • RADIUS Authentication

ページのトップへ

定義

このガイドでは、Microsoft Operations Framework (MOF) プロセス モデルおよび MOF セキュリティ管理サービス管理機能 (SMF) を使用します。

特に、この文書で紹介するソリューションでは、管理されていないコンピュータによって引き起こされる脅威に対するネットワーク セキュリティを向上するために、段階的に導入する方法ではなく、継続的に処理する方法の使用をお勧めしています。

特に、これらのソリューションを適用するには、次の図に示す手順が必要になります。

図 1. MOF の適用

図に示すように、管理されていないシステムによって引き起こされる問題に対応するには、テストと調整を繰り返す継続的なプロセスを踏む必要があり、単に計画と導入だけを行えばいいという問題ではありません。 中規模ビジネス ネットワークに影響を与える可能性がある脅威は常に変化しているため、ビジネス ネットワークを保護するためのシステムは、これらの脅威に絶えず適応し続ける必要があります。

この文書で説明するソリューションの適用は、次に概要を示すセキュリティ管理 SMF と連携して機能します。

  • ビジネス資産の露出度を評価し、セキュリティで保護する資産を特定する。

  • セキュリティで保護されていないデバイスによって引き起こされるリスクを許容レベルまで下げる方法を判別する。

  • セキュリティ リスクを軽減する計画を設計する。

  • セキュリティ メカニズムの有効性を監視する。

  • 有効性およびセキュリティ要件を定期的に再評価する。

MOF の詳細については、Microsoft TechNet Web サイトの「Microsoft Operations Framework」を参照してください。

セキュリティ管理 SMF の詳細については、「Security Management Functions」(英語) を参照してください。

リスク管理とは、組織の許容可能なリスク レベルを決定し、現在のリスクを評価して、許容可能なリスク レベルを実現する方法を見いだし、リスクを管理するプロセスです。 この文書ではリスク管理の概念についても扱いますが、リスク管理について詳細に議論することはそれだけで独立した題材となるため、この題材だけを専門に扱う文書を用意しています。 リスク分析およびリスク評価の詳細については、「セキュリティリスク管理ガイド」を参照してください。

ページのトップへ

課題

管理されていないコンピュータからネットワークを保護する場合、次に挙げるいくつかの課題があります。

  • 管理されていないコンピュータのネットワーク リソースへのアクセスをどうやって防ぐか。

  • 移動されることが多いコンピュータをどうやって更新プログラムおよびポリシーに準拠した状態に維持するか。

  • リモートからネットワークに接続するコンピュータにどうやって既存のセキュリティ ポリシーを適用するか。

  • 承認されていないワイヤレス デバイスからどうやってネットワークを保護するか。

  • ベンダのラップトップや個人のデバイスなど、管理されていないシステムがネットワークに接続されたときにどうやって検出するか。

  • パームトップやハンドヘルドなどのモバイル デバイスからどうやってネットワークを保護するか。

ページのトップへ

ソリューション

「課題」のセクションには、管理されておらず承認されていないコンピュータがネットワークに対して引き起こす脅威から保護する方法を考えるときに、明確にしておく必要がある数多くの要素を記載しました。 従来の有線の内部ネットワークを保護するだけでなく、ワイヤレス ネットワークおよびリモート アクセス パスのセキュリティを保護するための処置も取る必要があります。 承認されていないデバイスをネットワークに接続するすべての手段に対処するには、あらゆる範囲を包括的にカバーできるソリューションが必要です。

続くセクションでは、次の方法によって上記の課題に対処する方法について説明します。

  • IPSec ドメインおよびサーバー分離を使って、管理されていないコンピュータがネットワーク リソースにアクセスすることを防ぐ。

  • VPN 検疫を使って、リモートからネットワークに接続するコンピュータにセキュリティ ポリシーを実施する。

  • 802.1X 認証を使って、信頼されていないワイヤレス デバイスからネットワークを保護する。

  • SMS を使って、管理されていないコンピュータがネットワークに接続されたときに検出する。

注   この文書では、読者が中規模ビジネスのドメイン構造内にあるメンバ コンピュータに対して、既存のセキュリティ要件および更新プログラムの要件に準拠する手順を既に実施しており、ポリシーに準拠させながら非準拠のデバイスから保護するための方法を検証している場合を想定しています。 コンピュータをポリシーに準拠させる方法や WSUS または SMS の更新プログラム管理機能のような自動セキュリティ更新メカニズムの使用方法については、この文書では説明しません。

評価

このセクションでは、管理されていないコンピュータが中規模ビジネスに対して引き起こす問題に対処するための実施可能な対応策をいくつか紹介します。 また、これらの対応策を実施する前に、決定する必要がある項目について説明します。 ここで紹介する対応策は、いずれも中規模ビジネス ネットワークでネットワーク セキュリティのレベルを強化するのに役立ちます。 また、包括的な多層防御のアプローチの一部として実装する際は、対応策を組み合わせることで、「課題」セクションで説明した問題に対して、より高度な対応策を実施することができます。

IPSec を使用してドメインおよびサーバーを分離する

コンピュータとネットワークを物理的に分離することは新しいアイデアではありません。 この方法は、何年もの間、一般に開発およびテスト ネットワークが関係する場所でさまざまな形で行われてきました。 しかし、従来の物理的分離方法では、管理されたシステムを潜在的な危険性を持つ管理されていないデバイスから保護するという役割ではあまり役に立ちません。 このことは、モバイル コンピューティングが普及しつつあり、自動化された柔軟なソリューションへの需要が増加している現代のビジネス ネットワーク環境では特に当てはまります。 次の表は、過去に使用されてきた一般的な物理的分離方法、およびこの用途で使用する際の難点の概要を示しています。

表 1. ネットワーク分離方法

OSI の階層 手法 問題
第 1 層 信頼されているネットワークから分離する必要があるセグメントでは別の配線を使用する。
  • 新しい接続ごとに新しい配線を用意するコスト。

  • ユーザーの移動によって生じる新しいケーブルの配線を管理するための管理負荷の増加。

  • 柔軟性の不足およびビジネスの成長に伴う管理の困難さ。

  • 管理要件の増加に伴う不注意およびエラーの増加。
第 2 層 VLAN を使用して、信頼されているネットワークから分離された論理的サブネットを作成する。
  • VLAN をサポートするためのスイッチ ファブリックの更新に関連するコストの増加。

  • ネットワークの変更、ユーザーの移動、およびゲスト接続要求への応答の追跡のために生じる管理オーバーヘッドの増加。

  • 複数のユーザーが移動する、またはモバイル デバイスが使用される際の不注意およびエラーの発生。

この表からわかるように、現在のビジネス ネットワークでは、管理されていないシステムからネットワークを保護するためにコンピュータをセキュリティ標準に準拠させるには、より柔軟なソリューションが必要です。 この問題に対応するサードパーティ製ソリューションもありますが、すべての管理されたワークステーションにおいてクライアント側でのインストールを実施する必要があるため、ネットワークが複雑になります。 さいわい、現在のバージョンの Microsoft Windows は、この問題に対処するビルトイン機能を備えており、追加のソフトウェアをインストールしたり、管理者が多くを学習したりする必要はありません。

マイクロソフトのサーバーおよびドメインの分離により、IT 管理者は、ビルトインの Active Directory グループ ポリシーおよび IPSec を利用して、TCP/IP 通信を制限できます。この結果、次のような利益を得ることができます。

  • OSI モデルのネットワーク層を使用する。つまり、スイッチおよびルーターの境界をつなぐことができます。

  • スイッチ ファブリックおよび物理的なネットワーク制限からの開放。

  • Windows ベース コンピュータのビルトインの認証機能を活用することによるコスト削減。

  • 自動化により、ネットワークの変更およびユーザーの移動に関連する継続的な保守を必要としない。

  • 信頼されたコンピュータを認証する機能に加えて、信頼されたシステム間の通信を暗号化する機能を提供する。

  • 管理されていないデバイスからの接続を拒否することで、セキュリティ ポリシーを実施する。

  • 監査およびリソース管理機能の向上。

  • 攻撃が発生した際に即座に特定のリソースを分離する機能。

IPSec を使用した通信のセキュリティ保護に関する一般的な課題は、これらの課題に対して行われた近年の開発によって対応されています。 特に、ネットワーク アドレス変換 (NAT) は、Windows Server 2003 および Microsoft Windows XP Service Pack 2 (SP2) など、Microsoft Windows の現在のバージョンで利用できる NAT トラバーサル機能のおかげで問題ではなくなりました。 さらに、IPSec 非対応のプラットフォームも、構成可能な例外の一覧またはフォールバックの例外を使用して、これらのシステムでのクリア テキストによる通信を許可することでサポートしています。

ドメインおよびサーバーの分離ソリューションは、この文書で紹介するように、マイクロソフトの内部ネットワークでも使用されています。 マイクロソフトはこれらのソリューションを顧客に勧めるだけでなく、このソリューションによって実現する強力なセキュリティを自社で活用しています。また、ネットワークのセキュリティを強化して管理しやすいものにし、信頼できるコンピューティングを実現するこの方法をサポートする、長期のコミットメントを提示しています。

ドメインおよびサーバーの分離について理解する

簡単に言えば、分離されたネットワークを作成するには、各コンピュータに必要なアクセスの種類に基づいて、ビジネス ネットワーク内のさまざま種類のコンピュータを切り離す必要があるということです。 この場合、コンピュータの種類には 2 種類あります。 管理されているコンピュータと管理されていないコンピュータです。 ネットワーク分離を機能レベルで実現するには、基本的な 2 つの条件を満たす必要があります。 これらの条件は次のとおりです。

  • 分離されているネットワークに存在するコンピュータが、全ネットワーク内のすべてのコンピュータとの通信を開始することができる。これには、信頼されているネットワーク外のコンピュータも含まれます。

  • 分離されているネットワーク外にあるコンピュータは、信頼されているネットワーク外のコンピュータとのみ通信を開始することができ、信頼されているネットワーク内のコンピュータとは通信を開始することができない。

IPSec ドメインおよびサーバー分離では、グループ ポリシー設定を用いて既存のドメイン構造を利用します。 Windows XP、Windows 2000 Server、および Windows Server 2003 を使用するコンピュータでは、分離されたネットワークを作成するために必要な機能はすべて、あらかじめコンピュータに搭載されています。必要なグループ ポリシー設定が構成されている場合、新しいコンピュータを分離されたネットワークに挿入するプロセスは、そのコンピュータをドメインに追加するだけです。

図 2. Active Directory ドメインを使用したネットワーク分離

上の図に示すように、ドメインのメンバでないコンピュータは、すべて信頼できないと見なされるため、分離されたネットワークの外に置かれます。 分離されたネットワークの外にあるシステムは IPSec 通信を開始することができないため、分離されたドメイン内のシステムとの接続を確立することができません。 しかし、分離されたドメインのメンバは、分離されたネットワークの外のデバイスとクリア テキストによる通信を自由に確立することができます。

もちろん、多くの組織が、管理されており信頼できるにもかかわらず、Active Directory ドメイン内に存在しない、または何らかの理由から IPSec を使用できないが、分離されたネットワーク内のシステムと通信するビジネス ニーズがあるコンピュータおよびサーバーを持っています。 このジレンマを解決するために、次の図に示すように、例外の一覧を使用して、もう 1 つの分離されたグループ (または境界グループ) を作成できます。

図 3. ネットワーク分離と境界グループ

画像を画面全体に表示

このようなネットワーク分離モデルによって、ビジネス ネットワークのセキュリティのフットプリントを減らすことができます。 しかし、このソリューションだけでは、信頼されたシステムを、そのシステムを信頼された状態にしている標準に準拠した状態に維持することを保証できません。 このソリューションだけでは、包括的なネットワーク セキュリティ ソリューションとは言えないのです。 他のソリューションと共に使用することで、このソリューションは、より大規模で包括的なセキュリティ プロセスの実用的な一部分として、現代の中規模ビジネス ネットワークが対処する必要があるリスクを軽減できます。 特に、WSUS、SMS、MOM など、他のセキュリティ ソリューションと共に使用すると、この分離方法を使用して、分離されたネットワーク内でセキュリティ ポリシー準拠を強制することができます。

他の Active Directory ベースのセキュリティ ソリューションでは、信頼済みの分離されたネットワーク内でセキュリティ ポリシー準拠を継続的に保証するタスクを自動化することができます。 しかし、境界グループでは、境界グループ内のコンピュータが分離されたネットワーク ソリューション内の弱点にならないようにするために、異なる方法を使用する必要があります。 このようなコンピュータは、境界グループに追加する前にセキュリティ ポリシーに準拠していることを確認する必要があり、また、信頼されたシステムのセキュリティ ポリシー要件に継続的に準拠することを保証するための、自身に関連する特定のポリシーおよび手段を備えている必要があります。

IPSec について理解する

IPSec は、一般的なポリシー ベースの IP 層でのセキュリティ メカニズムを提供するインターネット プロトコルのセキュリティ標準で、ホスト別の認証に適しています。 IPSec ポリシーには、ホスト システムの受信/送信トラフィックのフローを制御するセキュリティ規則と設定が定義されます。 これらのポリシーは、ドメイン メンバへのポリシー割り当てのグループ ポリシー オブジェクト (GPO) を使用して、Active Directory で集中的に管理されます。 これにより、セキュリティで保護された通信をドメイン メンバ間で確立する機能が提供されます。この機能が、このソリューションの基礎となります。

IPSec ではインターネット キー交換ネゴシエーション プロトコルを使用して、2 台のホスト間で IPSec を使用して安全に通信する方法を決定するためのオプションをネゴシエートします。 2 台のホスト間で達した合意およびこのネゴシエーション方法を定義するさまざまなパラメータは、セキュリティ アソシエーションまたは SA と呼ばれます。 Microsoft Windows は、次に示す 3 つの IKE 方式の 1 つを使用する機能を備えています。

  • Kerberos Version 5 認証プロトコル

  • X.509 デジタル証明書および対応する RSA キーのペア

  • パスフレーズを使用した事前共有キー

注   PKI を認証方法として使用することもできますが、Windows 2000 ドメイン認証 (Kerberos) は IKE ネゴシエーション プロトコルに統合されているため、PKI を使用する方法はお勧めしません。

Windows の IKE ネゴシエーションは、IKE ネゴシエーション要求に応答しないコンピュータとの通信が許可されるように構成できます。 この機能は、クリア テキストへのフォールバックと呼ばれ、ロールアウト時に必要なだけでなく、境界グループ内のシステムが分離されたネットワークのメンバと通信できるようにするため、この状況において不可欠なものです。 IPSec で保護できないすべての通信はソフト セキュリティ アソシエーションと呼ばれ、セキュリティ ログの成功の監査イベントとして記録されます。

IPSec では、認証ヘッダー (AH) およびカプセル化セキュリティ ペイロード (ESP) オプションを使用することで、ネットワーク トラフィックの完全性および暗号化に対応する機能など、認証の他にも便利な機能を実行することができます。 AH を使用すると、パケットが転送中に変更されていないことを確認する機能を提供できますが、このタスクを実行するためにヘッダーを使用するため、ネットワーク アドレス変換 (NAT) との互換性が失われます。 ESP は、通常はトラフィックの暗号化に使用されますが、Null 暗号化モード (ESP/null) で使用できます。このモードでは、NAT 互換のデータの整合性チェックを実施できます。

IPSec は、トランスポート モードまたはトンネル モードという 2 つの異なるモードで機能することができます。 IPSec トランスポート モードは、2 台のホスト間のトラフィックのセキュリティを保護する方法としてお勧めします。 このモードは、元の IP ヘッダーの後ろにヘッダーを挿入し、次に AH または ESP でパケットの残りの部分を暗号化するだけで機能します。 トンネル モードは通常、元のパケットおよび IP ヘッダーが完全にカプセル化され、新しい IPSec ヘッダーによって元の IP ヘッダーが置き換えられるゲートウェイ ツー ゲートウェイ VPN トンネルに使用されます。

詳細については、マイクロソフト Web サイトの「Server and Domain Isolation」(英語) を参照してください。

多層防御

図 4. 論理的分離が組み込まれた多層防御モデル

上の図は、論理的分離と多層防御モデルとの対応関係を示しています。 ドメインおよびサーバーの分離は、ホスト ベースのファイアウォール同様に、ホスト コンピュータのセキュリティ保護に重点を置いているように見えますが、IPSec を用いてネットワーク通信の領域内に置かれています。 このソリューションは、ホストと内部ネットワークにわたって展開されていますが、これは「論理的分離」ソリューションであるため、いずれの内部にも完全には存在しているわけではありません。 このため、次の機能は対象範囲に含まれていません。

  • 論理的分離では、ルーターのようなネットワーク デバイスのセキュリティを保護できません。

  • 論理的分離では、ワイヤレス暗号化の 802.11i WPA およびワイヤレス アクセス制御の 802.1x EAP - TLS で実施できるような、ネットワーク リンクのセキュリティ保護を実施できません。

  • 論理的分離では、信頼されるコンピュータの資格情報およびドメイン ベースの IPSec ポリシーを持つシステムのみが制御対象となるため、ネットワーク上のすべてのホストに対してセキュリティを提供することはできません。

  • 論理的分離は、HTTPS および SSL で Web アプリケーションに対して実行できるような、アプリケーション レベルのパスをセキュリティで保護できる、自動的に構成可能な方法に適しておらず、この機能を備えていません。

論理的分離が包括的な多層防御ソリューション内で果たす役割を理解および考慮することが重要です。 このソリューションは、単独では中規模ビジネスのインフラストラクチャのすべての面をセキュリティで保護することはできません。 しかし、包括的なソリューションの一部として使用すると、このソリューションは非常に重要な役割を果たすことができます。

VPN 検疫サービスを使用して管理されていないリモート コンピュータからネットワークを保護する

ビジネス ネットワークにアクセスするために VPN ソリューションを使用するリモート システムは、セキュリティ ポリシーの観点から見ると、特有の問題を引き起こしてしまいます。 ほとんどのリモート アクセス ソリューションでは、リモート ユーザーの資格情報のみが検証され、リモート コンピュータがセキュリティ ポリシーに準拠しているかどうかは検証されません。 この検証方法は、古いマルウェア対策署名ファイル、古いセキュリティ更新プログラム、不適切なルーティング設定、および適切なファイアウォール保護の欠如などの問題に関係する脅威からネットワークを保護する処理を無効にする可能性があるため、問題があります。

Microsoft Windows Server 2003 ベースのネットワーク アクセス検疫制御では、接続を要求しているコンピュータの構成状態が、現在のセキュリティ ポリシー標準に準拠していることを確認できるまで、VPN へのリモート アクセスを延期することによってこの問題を解決しています。

VPN 検疫サービスを理解する

ネットワーク アクセス検疫制御は、Windows Server 2003 ファミリで提供される機能で、通常のリモート アクセス サービスを、接続を要求しているリモート コンピュータが管理者によって構成されたスクリプトによって検査および検証されるまで延期します。 通常、リモート セッションが開始されると、ユーザーは認証され、リモート コンピュータに IP アドレスが提供されますが、この時点で接続は検疫モードに置かれます。このモードでは、管理者によって提供されたスクリプトがリモート コンピュータ上で実行されるまでネットワーク アクセスが制限されます。 スクリプトが実行され、リモート コンピュータが構成されているネットワーク ポリシーに準拠していることがリモート アクセス サーバーに通知されると、検疫モードは解除され、リモート コンピュータはネットワークへのアクセスを許可されます。

リモート接続が検疫モードにある間は、次の制限を対象の接続に与えることができます。

  • 一連の検疫パケット フィルタを構成し、クライアントが開始または受信できるトラフィックの種類を制限できます。

  • 検疫セッション タイマを構成し、検疫モードでクライアントが接続された状態を維持できる時間を制限できます。

ネットワーク アクセス検疫制御は、セキュリティ ポリシーの実施を支援し、信頼されていないシステムが信頼されているネットワークに接続できないようにする包括的なセキュリティ ソリューションの一部として使用できます。 しかし、それ自体はセキュリティ ソリューションではないため、有効な資格情報を取得した悪意があるユーザーからの接続を防ぐことはできません。

注   ネットワーク アクセス検疫制御は、ネットワーク アクセス保護 (NAP) とは異なります。ネットワーク アクセス保護は、近日発売予定の Windows Server Longhorn オペレーティング システム ファミリに含まれる新しいポリシー適用プラットフォームです。 NAP の詳細については、この文書の最後の「付録 A : ネットワーク アクセス保護」を参照してください。

ネットワーク アクセス検疫制御コンポーネント

図 5. Windows ネットワーク アクセス検疫制御コンポーネント

画像を画面全体に表示

上の図は、ネットワーク アクセス検疫制御を使用する Windows リモート アクセス ソリューションの標準的なコンポーネントを示しています。 これらのコンポーネントは、次から構成されています。

  • 検疫対応リモート アクセス クライアント。 このコンポーネントは、Windows Server 2003 で提供される接続マネージャ管理キット (CMAK) で作成した CM プロファイルをサポート可能な Windows バージョンを実行しているコンピュータです。このサポートを提供している Windows のバージョンには、Windows 98 Second Edition 以降が含まれます。 これらのクライアント コンピュータは、通知コンポーネントがインストールされ、ネットワーク ポリシー要件スクリプトを保持しており、接続後の動作としてスクリプトを実行するように構成されている必要があります。

  • 検疫対応リモート アクセス サーバー。 このコンポーネントは、ルーティングとリモート アクセスを実行している Windows Server 2003 コンピュータで、インストールされているリスナ コンポーネントと共に、リスナ コンポーネント、MS-Quarantine-IPFilter および MS-Quarantine-Session-Timeout RADIUS ベンダ固有属性 (VSA) をサポートします。

  • 検疫対応 RADIUS サーバー。 このコンポーネントはオプションです。このコンポーネントは、Windows Server 2003 および IAS を実行しているリモート アクセス サーバーで、RADIUS 認証が MS-Quarantine-IPFilter および MS-Quarantine-Session-Timeout RADIUS VSA をサポートするように構成されているときに使用されます。

  • 検疫リソース。 これらのコンポーネントは、リモート クライアントが検疫モードでアクセスできるサーバーおよびサービスです。 通常、クライアントをポリシーに準拠させるために、DNS サービス、CM プロファイル、またはセキュリティ更新プログラム プロバイダを提供するサーバーから構成されます。

  • アカウント データベース。 通常、このコンポーネントにはリモート ユーザーのアカウントが格納され、ダイヤルイン プロパティが含まれる Active Directory ドメインです。

  • 検疫リモート アクセス ポリシー。 このポリシーは、リモート アクセス接続を発生させ、MS-Quarantine-IPFilter または MS-Quarantine-Session-Timeout 属性を指定するのに必要な条件を提供するために必要です。

多層防御

図 6. 多層防御およびネットワーク アクセス検疫制御

マイクロソフトの多層防御モデルを適用したこの図が示すように、VPN 検疫は、ホスト、内部ネットワーク、および境界と、このモデルの 3 層にわたっています。 このソリューションでは、クライアントのセキュリティは直接的には保護されませんが、セキュリティ ガイドラインを満たしていないリモート クライアントによってもたらされる可能性がある脅威から、サーバーを保護することができます。 また、効率的に動作するようにポリシー要件を満たし、更新プログラムを最新の状態に維持するように促進することで、リモート クライアントのセキュリティを間接的に保護します。

また、このソリューションは、ネットワークのパフォーマンスに悪影響を与える可能性があるマルウェアの伝播など、承認されていないリモート コンピュータが正しく構成されていない場合に引き起こされる可能性がある、破壊的な影響に対するネットワーク保護を強化します。 このソリューションでは、VPN (境界に位置) に対するブルート フォース攻撃が直接的に防御されないために、境界は無関係のように見えますが、攻撃者が対処する必要があるセキュリティの層を追加することで、攻撃者が認証資格情報を保持している場合でも、内部ネットワークに存在するリソースに直接アクセスできないようにしています。

802.1X 認証を使用して、管理されていないワイヤレス クライアントからネットワークを保護する

IEEE (Institute of Electrical and Electronic Engineers : 米国電気電子学会) 802.1X 標準は、ワイヤレス ネットワークが不正に使用されないように保護するタスクに適しています。 簡単に言えば、コンピュータがネットワーク上で通信することを承認されるように構成されていない限り、コンピュータは通信することができません。 このソリューションはワイヤレス ネットワーク上ではうまく機能しますが、この標準を有線ネットワークで使用しても、それほど効果的ではありません。 効果が限定されているために、この指示文書では中規模ビジネス ネットワークをセキュリティで保護するために、複数の方法を組み合わせて使用することを勧めています。 一般的なビジネス ネットワークの各局面に対処する最も効果的なソリューションを組み合わせて使用することで、堅牢な多層防御ソリューションを実装することができます。

IEEE 802.1X 認証を理解する

IEEE 802.1X 認証は、クライアントとネットワーク間で相互認証を要求するように構成できるポート ベースのアクセス制御メカニズムです。 この認証方法を実装すると、認証に失敗したデバイスは、該当するネットワークとの通信に参加できません。

802.1X では拡張認証プロトコル (EAP) がサポートされています。EAP には、現在のバージョンの Microsoft Windows に既定でサポートされている 3 種類のプロトコルを含む多くの種類があります。

  • EAP-MD5。MD5 を使って認証サーバーはチャレンジをクライアント (サプリカント) に送信し、サプリカントはこのチャレンジ要求を自身の識別子およびパスフレーズと組み合わせます。 このレスポンスは MD5 ハッシュに変換されて認証サーバーに送り返されます。認証サーバーは、レスポンスを解読して元のチャレンジと比較します。 このレスポンスが一致する場合は、認証が行われます。 この方法は、パスワード自身が送信されるためにサードパーティによって傍受および解読される可能性があるため、多くの実装において安全ではありません。

  • Protected EAP。 Protected EAP (PEAP) は、サーバー側の証明書およびクライアントからの認証情報 (ユーザー名およびパスワードなど) を使用して、相互認証を確立します。 この標準のマイクロソフトの実装では、MS-CHAPv2 を使用します。MS-CHAPv2 では、従来のドメイン アカウントとパスワード情報、および RADIUS サーバーを使用してこの認証を確立します。 この方法は通常、EAP-TLS 方式に伴う追加のインフラストラクチャ要件および管理要件に対応する余裕がない小規模な環境では十分なセキュリティを提供すると考えられています。

  • EAP-TLS。 この方法を使用して、認証サーバーはサプリカントとのトランスポート層でのセキュリティ (TLS) セッションを設定し、クライアントにデジタル証明書を送信します。 サプリカントは、この証明書を受信すると、検証を行い、これに応答して自身の証明書を送信します。次に、この証明書が認証サーバーで検証されます。 双方が互いの証明書を信頼する場合は、認証が行われます。 この方法は、PKI インフラストラクチャおよび RADIUS 認証サーバーがサポート可能なネットワークに最も適しています。 また、特に 802.11i WPA2 標準と共に使用すると、ワイヤレス ネットワークで利用できる最も安全なソリューションになります。

クライアントが認証する前に、クライアントが認証サーバーによって認証されるまで、クライアントは認証システム (ワイヤレス アクセス ポイントまたはネットワーク スイッチ) に依存する必要があります。 このため、最初の認証ハンドシェイクの間は、すべての通信が認証システムによってサプリカントと認証サーバーの間で転送されます。 認証が完了したら、サプリカントはネットワークに直接アクセスすることができます。

802.1X が有線ネットワークでは効果的でない理由

802.1X は、一般にワイヤレス ネットワークのセキュリティに対応していますが、有線ネットワークのセキュリティを保護するためにこの方法を実装することに関連していくつかの問題があります。 1 つ目の問題は、802.1X ではワイヤレス ネットワークでの実装をサポートする複数の Active Directory グループ ポリシー オブジェクトを保持していますが、有線ネットワークでは 802.1X 認証はサポートされないことです。 このため、802.1X でこのような実装を実現するには、相当量の管理オーバーヘッドが要求されます。 さらに、多くのスイッチ、ネットワーク印刷デバイス、その他の有線ネットワーク インフラストラクチャ デバイスでは 802.1X がサポートされていないため、多くの中規模ビジネス ネットワークでこの実装をサポートするには、高価なアップグレードを実装する必要がある可能性が高くなります。

このような実装に関連する管理コストおよびインフラストラクチャ コストに加えて、ワイヤレスに重点を置いたこの標準を有線ネットワークで使用するときに発生するセキュリティの不備もあります。 たとえば、802.1X 認証は接続が確立され、802.1X にハブが認識できる場合のみ行われるため、攻撃者は、認証されたコンピュータおよび攻撃に使用する「シャドウ」コンピュータと共にハブを内部ネットワークに接続だけすればよいことになります。

注   これらの固有の短所および脆弱性は、ワイヤレス ネットワークには影響を与えません。 802.1X セキュリティに関連するこれらの問題は、有線ネットワークで使用するときにのみ発生します。

これらの問題が、802.1X ではなく IPSec をドメインおよびサーバーの分離にお勧めする理由です。しかし、中規模ビジネス ネットワークで 802.1X を使用してはいけないという意味ではありません。 既に述べたように、802.1X はワイヤレスのセキュリティ問題に対応する重要なツールであり、IPSec ベースのネットワーク分離ソリューションを追加するだけでセキュリティを向上することができます。

多層防御

図 7. 802.1X ワイヤレス セキュリティを使用した多層防御

上の図に示すように、802.1X 認証を使用したワイヤレス セキュリティは、多層防御モデルのネットワーク層全体に対応しています。 ワイヤレス セキュリティが境界にも及んでいるように見えるかもしれませんが、ワイヤレス ネットワークは実際にはローカル ネットワークの一部であり、境界はインターネットのような外部ネットワークを扱います。 ワイヤレス セキュリティ方式の一部はホスト コンポーネントを含みますが、ワイヤレス セキュリティはホストを直接保護するように設計されていません。

SMS を使用して管理されていないシステムを検出および修正する

Microsoft Systems Management Server (SMS) 2003 は、ネットワーク上のコンピュータの管理、資産一覧情報の保守、およびソフトウェアと更新プログラムの配布を実施して、セキュリティ ポリシーへの準拠を維持し、プラットフォームおよびソフトウェア インストールの共通性を維持するために、数多く採用されています。 SMS 2003 のネットワーク検出およびインベントリ機能については、信頼されていないシステムがネットワークに接続されたときに検出する方法を提供するため、この文書でも中心的なトピックに含めて扱っています。 この機能は、管理されていないコンピュータの使用に対する応答として実装されているポリシーに応じて、修正を支援する手段も提供します。

この文書では、読者が SMS およびその他の方法を使って、すべてのセキュリティ更新プログラムを最新の状態に維持するなどして、ドメイン メンバのコンピュータをセキュリティ ポリシーに準拠させていることを想定しています。 このため、SMS 2003 およびその他のツールを使用する更新プログラム管理に関しては、この文書では解説しません。 これらのトピックおよびその他の SMS 関連の情報については、「Patch Management Using Systems Management Server 2003」のソリューション アクセラレータ (英語) または「Microsoft Systems Management Server」ページを参照してください。

既存の資産を検出および文書化する

既に SMS を実装した企業では、既存の資産の文書化、および管理されているシステムと管理されていないシステムのインベントリ作成は完了しているはずです。 このようなインベントリには、設計によって、またはそのクライアントの種類に適した作業エージェントがないために、SMS によって管理されていないコンピュータのセキュリティ更新プログラムの要件および手順についての情報が含まれています。 これらの管理されていないコンピュータには、セキュリティ境界 (DMZ、スクリーン サブネットとも呼ばれます) にあるデバイス、テスト コンピュータ、またはスタンドアロン デバイスが含まれます。

SMS で管理されていないデバイスの一覧を文書化して保持することは重要です。その理由は、セキュリティ要件を満たすためだけではなく、このような一覧を使用して新しいインベントリ情報と比較し、新しく検出したシステムが承認されているか、または未知のシステムであるかを判別する必要があるためです。 このような一覧を最新の状態に維持するには、管理できない新しいシステムをビジネス ネットワークに追加するプロセスを用意することが重要です。このプロセスには、情報の識別だけでなく、これらのシステムのセキュリティを維持するプロセス、および所有権の割り当てが含まれます。

SMS は、IP アドレスと名前以外には、このような管理されていないシステムに関する情報をあまり収集できない可能性がありますが、多くの場合、この情報だけでも新しいネットワーク デバイスが承認されているかどうかを判断するのに十分です。

導入

「評価」のセクションでは、中規模ビジネス ネットワークにおいては個々の機能を扱う個別のソリューションを組み合わせることが、ネットワークを保護するための最も包括的な方法であることを示しました。 ドメインおよびサーバーの分離では、有線ネットワークにおいて管理された既知のコンピュータのみが信頼されているリソースにアクセスできることを保証します。 VPN 検疫は、ローカル ネットワークに接続する頻度の低いリモート システムも確実にセキュリティ ポリシーに準拠させます。802.1X 認証は、ワイヤレス ネットワークのセキュリティを保護し、承認されたコンピュータのみが接続を確立できるようにします。 最後に、SMS を使用すると、信頼されたコンピュータをポリシーに準拠させ、信頼されていない承認されていないコンピュータがネットワークに接続されると、これを検出することができます。 これらすべてのソリューションを組み合わせて、承認されていない接続および承認されていないコンピュータからネットワークを保護します。

これらのソリューションを実装するための要件に関する説明に加えて、このセクションでは、各ソリューションがそれぞれの中規模ビジネス環境において最適な方法であることを確認するために扱う必要がある潜在的な問題の一部についても説明します。

IPSec を使用してドメインおよびサーバーを分離する

IPSec ベースのドメインおよびサーバーの分離を実装する計画を立てるには、このソリューションが特定のネットワーク環境に適しているどうかを判断し、実装計画を進めるために必要な情報を収集する必要があります。 IPSec ネットワークの分離の概念については、この文書の「評価」のセクションで紹介されています。 この方法の利点を理解できたら、この実装のために生じる可能性がある問題と比較して検討することができます。 このセクションでは、意志決定プロセスを支援するために、IPSec ベースのネットワーク分離の実装に伴う問題の一部と、このような実装の要件について説明します。

ネットワーク アーキテクチャを把握する

IPSec はインターネット プロトコル上に実装されるため、現在のネットワーク インフラストラクチャおよびトラフィック フローの詳細について理解していることが、このソリューションの導入を成功させるために不可欠です。 IP アドレスの割り当て方式、サブネットのレイアウト、およびネットワーク トラフィックのパターンに関する情報は、検証する必要のある重要な要素ですが、ネットワークのセグメンテーションおよび最新のネットワーク トラフィック フロー モデルの詳細なドキュメントが、効果的なネットワーク分離計画の開発および導入を成功させるために不可欠です。

注   ネットワーク環境の文書化の詳細については、この文書では説明しません。 このようなドキュメントを作成することは、こうした包括的なネットワーク セキュリティ イニシアチブを成功させるために不可欠です。 このため、このようなドキュメントが存在しない場合は、こうしたドキュメント イニシアチブが完成するまで、このようなプロジェクトを効果的に実装することは非常に困難であると考える必要があります。

ネットワーク アーキテクチャの文書化においては、次の情報に関する最新で詳細な情報を正確に反映させる必要があります。

  • ファイアウォールおよびロード バランサの詳細および場所

  • RAM サイズ、製造元/モデル、および MTU 設定などのネットワーク デバイス情報

  • ネットワーク トラフィックおよび使用レポート

  • NAT 使用率

  • VLAN のセグメンテーション

  • デバイス ネットワーク リンク

  • 侵入検知システム (IDS) 情報

ネットワーク トラフィック フローを把握する

IPSec ベースのネットワーク分離に影響するデバイスおよび構成に関する情報に加えて、ネットワーク内のネットワーク トラフィックのパターンを調査することは重要です。 この種類の情報を収集する場合、Windows 対応でないデバイス (Linux コンピュータなど) または Windows 2000 SP4 より前のバージョンの Windows を使用するデバイスが、他の Windows ベースのシステムと通信する方法などの要素について考えることは重要です。 その他の考慮事項は次のとおりです。

  • メインフレーム通信など、特定の種類のトラフィック専用のサブネットはありますか。

  • トラフィックは場所ごとに分離する必要がありますか。

  • HR データベースとの通信など、暗号化による高レベルのセキュリティを必要とする種類のトラフィックはありますか。

  • UDP ポート 500 をブロックするなどの、実装に影響する可能性があるセキュリティ デバイスまたはファイアウォールのルールはありますか。

  • アプリケーションの通信方法は何ですか。 たとえば、リモート プロシージャ コール (RPC) を使用しますか。使用する場合は別の考慮事項が発生する可能性があります。

  • ホストとサーバーは、どのように相互通信していますか。 ポート/プロトコル レベルの接続を使用しますか。またはさまざまなプロトコルを使用して複数のセッションを確立しますか。

Active Directory の構造を把握する

IPSec を実装することで Active Directory 構造が受ける影響を理解するには、前述のセクションで把握したネットワーク情報に加えて、Active Directory のフォレストの構造、ドメインのレイアウト、組織単位 (OU) の設計およびサイト トポロジに関する情報を収集することが重要です。 この情報には、次の項目が含まれます。

  • フォレストの数

  • ドメインの数と名前

  • 信頼関係の数と種類

  • サイトの数と名前

  • OU およびグループ ポリシーの構造

  • 既存の IPSec ポリシーに関する情報 (IPSec を使用している場合)

ホストを把握する

収集する必要がある関連するホスト情報には、次の項目があります。

  • コンピュータ名

  • IP アドレス、特に静的アドレス

  • MAC アドレス

  • オペレーティング システムのバージョン (Service Pack および修正プログラムのリビジョン レベルまで確認)

  • ドメイン メンバシップ

  • 物理的な場所

  • ハードウェアの種類と役割

IPSec の容量を把握する

IPSec を実装する計画を策定する際、特に IPSec 暗号化を使用することを検討している場合は、ホストの使用およびネットワークに関して一定量のオーバーヘッドが生じるため、容量の計画に関していくつかの事項を考慮する必要があります。 考慮事項には、次があります。

  • サーバーのメモリ使用量。 各セッションは、5 KB 程度の RAM を消費する可能性があります。

  • サーバー、 ワークステーション、およびインフラストラクチャ デバイスの CPU 使用率。 この情報は、サーバーでは特に重要です。 デバイスが既に過度に使用された状態になっていないことを確認してください。

  • ネットワークの待ち時間および使用率。 IPSec の使用時は待ち時間が増加します。 マイクロソフトで IPSec を実装したときは、ネットワーク使用率が 1% ～ 3% 増加しました。

  • NAT の使用と暗号化の種類。 AH 通信では NAT をスキャンできません。 このため、通信を暗号化するには代わりに ESP を使用する必要があります。 ESP では、ESP の Null 暗号化を使用しない限り、AH 暗号化より使用率のオーバーヘッドが高くなります。

  • グループ ポリシーの影響。 IPSec GPO は、コンピュータの起動およびログオンにかかる時間に影響を与えます。 これらの時間が実際にどのような影響を受けるかを判断するために、テスト実装の前後にベースラインを取る必要があります。

信頼レベルを検討する

もう 1 つの重要な注意事項には、このソリューションに参加するホストと容量の決定があります。 これを決定するには、信頼されるために満たす必要がある条件および存在する信頼の程度を明確に定義する必要があります。 次の情報を利用すると、信頼の明確な定義、特定レベルの信頼を満たすために必要な条件、およびこれらが計画プロセスに与える影響を検討できるため、この手順を容易に実施することができます。

信頼のレベルに関してホストに適用できる基本的な状態は 4 つあります。 これらの状態を信頼性の高い順から低い順に記載します。

  • 信頼された状態。 信頼された状態とは、ホストのセキュリティ リスクが管理されており、他の信頼されたホストは、このホストから悪意のある行為が開始されることはないと、ある適度想定できることを意味します。 この状態は、このホストが完全にセキュリティで保護されていることを必ずしも意味しませんが、自動であるか文書化されたプロセスであるかにかかわらず、このホストの状態は IT 部門の責任下にあり、何らかのメカニズムによって管理されていることを意味します。

    このホストは信頼されているため、このホストと他の信頼されたホスト間の通信は、ネットワーク インフラストラクチャによって阻害されません。 このホストでは悪意のある行為は行われないと想定できるため、ファイアウォールや類似の手段を使用してこのホストからのトラフィックをブロックまたはフィルタする必要はありません。

  • 信頼できる状態。 信頼できる状態は、コンピュータを信頼されたデバイスにすることはできるが、信頼された状態として認定するには、構成の変更、または何らかのアップグレードを必要とすることを示しています。 このようなコンピュータは、分離されたネットワークを設定するために必要な取り組みおよびコストに関する目安を提供してくれるため、設計段階でこのようなコンピュータを識別することは特に重要です。

  • 既知の Untrusted. 経理上の制約、ビジネス要件、または機能要件など、いくつかの理由によって既知のコンピュータを信頼された資産にすることができない場合があります。 たとえば、すべてのコンピュータをアップグレードするにはプロジェクトの資金が不十分である、一部のビジネス ユニットが独自のドメインの所有権を持っている、古いアプリケーションが現在サポートされているオペレーティング システムと互換性がなく、そのためにセキュリティで保護されたコンピュータ上で実行することができない、などの理由があります。

    信頼されていない理由が何であれ、既知の信頼されていないコンピュータを環境内に持つ事業主は、許容可能なリスク プロファイルを維持しつつ、コンピュータをポリシーに準拠させるためにできることはないか、およびこの状況にどのように対処するべきかを判断するために調査を実施する必要があります。

  • Unknown,信頼されていない状態。 不明で信頼されていない状態は、すべてのホストで既定とするべき状態です。 この状態のホストは管理されておらず構成が不明なため、他の信頼状態を割り当てることはできません。 これらのホストはセキュリティ侵害を受けたり、悪意のある活動のプラットフォームとして使用されたりする可能性があるため、企業に対して許容できないレベルのリスクを与える可能性があると想定されます。 このソリューションは、このようなシステムによる影響を受ける可能性を減らすために設計されています。

収集した情報を使用する

関連する情報をすべて収集したら、実装計画を策定し、IPSec ベースのネットワーク分離ソリューションが、現在のネットワーク環境に適しているかどうかを判定することができます。 このソリューションの実装に影響を与える可能性がある考慮事項は、次のとおりです。

  • ホストを信頼される状態に準拠させ、IPSec 要件に準拠させるために必要なアップグレードのコスト。

  • 現在のネットワーク デバイスが IPSec をサポートしていない場合は、インフラストラクチャのアップグレードまたは交換にかかるコスト。

  • ルーター ベースの QOS で発生する可能性がある損失とネットワーク分離から得られるセキュリティ上の利点のバランス。これは、IPSec を実装するとポート ベースの優先度設定は機能しませんが、IP アドレス ベースの QOS は継続して機能するためです。

  • IPSec の実装、特に ESP 暗号化を使用する場合、ネットワーク モニタおよび IDS デバイスに発生する可能性のあるエラー。 デバイスで IPSec パーサーを利用できる場合は、パーサーを使用するとこの問題を解決できます。

  • IPSec を実装すると、サーバーおよびネットワーク デバイスの CPU およびメモリに対するオーバーヘッドと要求が増加するため、ハードウェアをアップグレードする必要がある場合がある。

  • ネットワーク待ち時間が増加する場合があるため、予測管理が問題になる可能性がある。

  • ユーザーが信頼されていないデバイスを持っており、分離されたネットワーク上のネットワーク リソースにアクセスするビジネス上の理由があるような場合、ベンダとゲスト ユーザーの管理も過度のオーバーヘッドを発生させる可能性がある。 このような例外は、数と頻度が増加すると処理が困難になる可能性がありますが、信頼されているネットワークと信頼されていないネットワークの間の境界ゾーンを使用することで削減することができます。

これらの問題から、IPSec の実装やネットワークの分離など、ネットワーク全体に影響のある変更を行う前に、注意深く計画を立ててテストを実施する必要がある理由がわかります。 このソリューションの実装方法だけでなく、ネットワークの現状およびネットワークをポリシーに準拠させるために必要な経理上および組織上のコストを考慮して、実現可能であるかどうかを判断するために、注意深く考慮する必要があります。 また、ターゲットとするリソースだけを分離する制限的導入または段階的導入も、こうした問題に対処するための緩和的な戦略として検討してください。

繰り返しますが、IPSec ベースのネットワーク分離は、包括的なソリューションの一部でしかありません。 このガイドで紹介する各ソリューションは、ネットワークに接続できる信頼されていないデバイスからネットワークを保護するために役立ちますが、このソリューションの各部分は、個別に採用しても任意のネットワークのセキュリティ レベルを向上することができます。 このため、この時点では IPSec ドメインおよびサーバーの分離をソリューションとして利用できない場合でも、ここに記載したその他のソリューションを実装し、ネットワークが成熟してこの文書で説明した要件に準拠できるようになったときに、ネットワーク分離を実施することも有効な選択肢となる場合があります。

VPN 検疫サービスを使用して管理されていないリモート コンピュータからネットワークを保護する

Windows ベースの標準のリモート アクセス サーバー セッションでは、リモート アクセス クライアントによってセッションが開始されると、サーバーは次の処理を実行します。

  1. リモート アクセス サーバーは、構成されたリモート アクセス ポリシーに対してチェックを実行し、接続を許可します。

  2. サーバーは、ユーザーのリモート アクセスのアクセス許可を検証します。

  3. 次に、サーバーは Active Directory または他の認証サービスに対してユーザーの資格情報を認証します。

  4. サーバーはリモート クライアントに IP アドレスを割り当てます。

この時点でリモート クライアントは、ネットワークへの完全アクセス権を持っており、更新プログラムのレベル、ウイルス対策ソフトウェアの存在または更新状況、または他のセキュリティ ポリシー関連の情報を検証するチェックは実行されていません。 この機能は、更新、構成の変更、または更新プログラムがリモート ユーザーまたは頻繁に移動されるコンピュータに適用されない場合があるため、最適であるとは言えません。

しかし、VPN 検疫接続はこれとは異なります。次の図と番号順で示したプロセスを参照してください。

図 8. VPN 検疫プロセス

画像を画面全体に表示

  1. リモート クライアントは、接続の基本的な必要条件 (セキュリティ更新プログラムのレベルおよびウイルス署名ファイルの日付など) をチェックする接続マネージャの接続前スクリプトを実行し、結果を格納します。 このスクリプトの実行後、クライアントは VPN トンネルを通じてリモート アクセス セッションを確立します。

  2. リモート アクセス サーバーは、資格情報の検証に Active Directory をチェックする RADIUS を使ってユーザーの資格情報を認証します。

  3. Active Directory によってユーザーが認証されたら、リモート アクセス ポリシーを適用することによって、リモート アクセス サーバーはクライアントを検疫状態に置きます。 検疫中は、ネットワーク アクセスは検疫ポリシーによって指定された範囲に制限されます。 このようなアクセス制限は、クライアントをポリシーに準拠させるために使用できる特定のリソースにアクセスを制限する IP フィルタを通して、または一定の時間が経過した後にクライアントの回線を切断するタイムアウト期間を指定することによって実現されます。

  4. 接続後スクリプトによって、クライアントが指定された要件に準拠しているかどうかがリモート アクセス サーバーに通知されます。 タイムアウト期間内に接続の要件が満たされなかった場合は、ユーザーはエラーの詳細を通知され、接続は遮断されます。

  5. 接続後スクリプトによってクライアントが指定された要件を満たしていることが示された場合は、IP フィルタの制限を解除し、リモート アクセス ポリシーによって指定されたネットワーク リソースにアクセスする許可を与えることで、リモート アクセス サーバーはクライアントを検疫モードから解除します。

リモート アクセス クライアントは、そのネットワークが独立したサブネットか、インターネットに接続されている一連の定義済みサーバーかにかかわらず、指定された検疫ネットワーク内に位置するリソースにのみアクセスできます。 検疫ネットワークは、リモート コンピュータをセキュリティ標準に準拠させる処理をリモート クライアントが実施できるようにするリソースを提供する必要があります。 一般に、こうしたリソースには、名前解決に使用する DNS サーバーへのアクセス、更新プログラムを取得するファイル サーバーなどがあります。処理命令または Web ベースの更新プログラム用の Web サーバーも含まれることもあります。

このプロセスで検疫サブネットを使用するには、リモート クライアント コンピュータに更新プログラムをダウンロードおよびインストールする十分な時間を確保するために、セッションのタイムアウトを長く設定する必要があります。 この問題を回避するために、他のソースを使用するようにクライアント コンピュータを設定したり、VPN セッション外のインターネットに接続されている更新プログラム用サーバーを使用したりすることができます。ただし、この方法ではより複雑なスクリプトを必要とするため、他のセキュリティ問題を引き起こす可能性があります。 いずれの場合でも、検疫の動作を決定するのはスクリプトであり、検疫ネットワークではありません。

注   IPSec ポリシーは、検疫ソリューションがドメインに参加していないシステムに対応する必要がある場合は、スクリプト化することができます。 このような場合は、netsh または lpseccmd.exe を使用して証明書を用いたシンプルなポリシーを適用し、IPSec 認証をサポートすることができます。 IPSec は、階層化されたソリューションおよび VPN 検疫構成のドメインに参加しているシステムでも機能します。

VPN 検疫のクライアント コンポーネント

前のセクションで説明したように、VPN 検疫プロセスの最初の手順はクライアントで実行され、特に接続マネージャの接続前スクリプトで開始されます。 接続マネージャは、ネットワーク接続の確立および管理を集中化および自動化し、次に示す VPN 検疫構成のいくつかの主な領域をサポートする接続マネージャ管理キット (CMAK) の一部です。

  • クライアント コンピュータの構成を自動的に管理する接続前セキュリティ チェック。

  • 接続後セキュリティ チェックおよびログオンの検証。

接続マネージャを使用すると、複数のコンピュータに配布可能なプロファイルを利用して、管理者はカスタム操作を設定できます。 この機能により、リモート ユーザーが変更できる設定数を制限することで、接続プロセスを単純化できます。 変更できる設定には、次の項目が含まれます。

  • ダイヤルアップ接続で使用できる電話番号の一覧を作成する。

  • グラフィック、アイコン、メッセージおよびヘルプ テキストをカスタマイズする。

  • カスタムの接続前および接続後の処理を実行する。これには、ダイヤラ プロファイルの再設定、または Windows ファイアウォールのパケット フィルタ ルールの構成などの処理が含まれます。

もう 1 つの CMAK コンポーネントは、クライアント エージェント (RQC.exe) です。クライアント エージェントは、TCP ポート 7250 を使用して、リモート アクセス サーバー上のリモート アクセス検疫サービス (RQS.exe) と通信します。検疫接続が確立されると、RQS は RQC に秘密の共有キーを送信します。 クライアントが必要な条件を満たしている場合は、RQC は共有キーを送信し、クライアントを検疫から開放します。

接続マネージャ プロファイルとは、CMAK を使用して作成および構成できる自己解凍型のカスタマイズされた接続マネージャのクライアント ダイヤラ パッケージです。 CMAK ウィザードを使用すると、管理者はプロファイルを構成する手順を簡単に実施できます。プロファイルは、グループ ポリシーや Microsoft Systems Management Server (SMS) 2003 ソフトウェア配布などのさまざまなメカニズムを使って配布できます。 作成した実行可能ファイルをクライアント コンピュータで実行すると、プロファイルがリモート アクセス サーバーとの通信を確立するために必要な設定と共にローカル コンピュータにインストールされます。 インストールが完了したら、ユーザーは Windows XP の [接続] メニューでプロファイル名を起動するだけで接続を確立できます。

CMAK の詳細については、Microsoft TechNet Web サイトの「接続マネージャ管理キット」を参照してください。

VPN 検疫のサーバー コンポーネント

VPN リモート アクセス サーバーは、このソリューションの中心的な役割を果たす部分で、次の機能を備えています。

  • リモート アクセス検疫サービス (RQS.exe) を実行します。

  • 検疫アクセス設定のリモート アクセス ポリシーを適用します。

  • クライアント エージェントと通信をネゴシエートします。

  • クライアント エージェントからポリシー準拠情報を受信します。

  • リモート アクセス ポリシーを適用してネットワーク リソースへのアクセス許可を決定します。

リモート アクセス検疫サービスは Windows Server 2003 Service Pack 1 のオプション コンポーネントで、リモート クライアント コンピュータを検疫状態にし、クライアント エージェントがポリシー準拠を知らせる通知を送信すると、検疫モードからクライアントを開放するために必要な API をサポートしています。 このサービス (RQS.exe) は、クライアント側コンポーネント (RQC.exe) から送られるクライアント コンピュータがポリシー要件を満たしていることを告げる通知を、TCP ポート 7250 でリッスンします。 つまり、このソリューションが機能するためには、ホスト ベースのファイアウォールを含め、どのようなファイアウォールも TCP ポート 7250 のトラフィックを許可する必要があります。

VPN 検疫のネットワーク コンポーネント

次のネットワーク コンポーネントには、VPN 検疫ネットワーク ソリューションの一部として使用できる、既に説明した必須のコンポーネントおよびオプションのコンポーネントが含まれます。

  • インターネット認証サービス (IAS) RADIUS サーバー (推奨)。 IAS サーバーが必要とされるのは RADIUS を認証プロバイダとして使用する場合だけですが、IAS サーバーは、証明書およびスマート カード ベースの 2 要素の認証をサポートする拡張認証プロトコルのサポートなど、他の認証ソリューションに比べて大きな利点を持っています。 MS-Quarantine Session Timeout および MS-Quarantine-IPFilter VSA がサポートされているため、RADIUS を使用する場合は、Windows Server 2003 に付属の IAS を RADIUS プロバイダとして使用することをお勧めします。他の RADIUS サーバーではサポートされていない場合があるためです。

  • Active Directory (推奨)。 Active Directory は RADIUS のユーザー アカウント認証データベースとして機能し、IAS および他のサービスと統合できます。 IAS と共に使用すると、証明書または他の方法を使う 2 要素の認証をサポートすることができます。

  • DHCP サーバー (推奨)。 DHCP サーバーは、リモート クライアントに対して IP アドレス プロビジョニングを提供するために使用されます。

  • DNS サーバー (推奨)。 DNS サーバーは、検疫ネットワーク内のクライアントが、リモート クライアント コンピュータをポリシーに準拠させるために使用できる他のサーバー (提供されている場合) に接続できるように名前解決サービスを提供します。

  • Windows Software Update Service (WSUS) サーバー (オプション)。 WSUS サーバーは、検疫状態から解放するためにリモート コンピュータで要件を満たす必要があるセキュリティ更新プログラムおよび修正プログラムを提供することができます。 この代わりに、更新を行うためにコンピュータで外部ソースを使用する必要がある場合は、SMS 2003 または標準の Windows Update サービスなど、他の方法を使用することもできます。

  • ファイル サーバー (オプション)。 ファイル サーバーを使用すると、検疫されたコンピュータのポリシー要件を満たすために、ソフトウェア更新プログラムおよびウイルス対策署名ファイルにアクセスできる共有場所を提供できます。

  • Web サーバー (オプション)。 Web サーバーを検疫で使用すると、コンピュータを検疫状態から解除するための指示をユーザーに与えることができます。 また、ウイルス対策製品など一部の更新プログラム パッケージでも、Web コンポーネントを使用した配布が行われています。

802.1X 認証を使用して、管理されていないワイヤレス クライアントからネットワークを保護する

前のセクションでは、信頼されていないコンピュータからワイヤレス ネットワークをセキュリティで保護するために利用可能な最も効果的なオプションとして 802.1X 認証を紹介しました。 Microsoft Windows の現在のバージョンで規定でサポートされている各種 802.1X 方式について説明し、802.1X 認証が有線ネットワークで効果的でない理由について説明しました (ワイヤレス ネットワークでは非常に効果的です)。 この情報を基に、サポートされている方式間の違いについて検討し、さまざまな種類の中規模ビジネス ネットワーク環境に、より適した方式を決定することができます。

802.1X の比較

既に述べたように、Microsoft Windows の現在のバージョンでは 3 種類の 802.1X 方式がサポートされています。 サポートされている方式は、次のとおりです。

  • EAP-MD5

  • Protected EAP (PEAP)

  • EAP-TLS

これらの 3 種類の方式の中で、1 つ目 (EAP-MD5) が最もセキュリティが弱い方式であると見なされています。この方法で使用するパスフレーズはワイヤレス伝送されるので、傍受される可能性があるためです。 他の 2 つのオプション (PEAP および EAP-TLS) は、中規模ビジネス ネットワークでの展開において考慮する価値があります。

PEAP のマイクロソフト実装では、Microsoft チャレンジ ハンドシェイク認証プロトコル バージョン 2 (MS-CHAP v2) を使用します。このプロトコルは、当初はダイヤルアップ VPN 認証方式として設計されましたが、Active Directory を使用することで利用可能な強力なユーザー パスワード ポリシーをサポートできるため、PEAP に適しています。 この方法は EAP-TLS より実装がシンプルで、リソースおよび初期のコストを低く抑えることができます。実装のために必要な追加のサーバーおよびサービスがあまり多くないためです。 このソリューションでは認証サーバー用の証明書が必要ですが、実装に必要な数が少ないため、これらの証明書はサードパーティの証明書プロバイダで生成することができます。

しかし、相互認証のためにクライアントと認証サーバーの両方で証明書を必要とするため、EAP-TLS が、現在利用できる最も堅牢なセキュリティの 802.1X 認証の実装であると見なされています。 このような実装では多くの証明書が必要になるため、公開キー基盤が存在しない場合は、こうした実装をサポートするために公開キー基盤を実装することを提案します。 このため、PEAP と MS-CHAP v2 を使用する場合に比べると、EAP-TLS は実装およびサポートにかかるコストが高いように見えます。

802.1X 意思決定プロセス

任意のネットワーク環境に最も適した 802.1X 実装を決定するプロセスを簡略化するために、マイクロソフトは次の 802.1X 認証デシジョン ツリーを考案しました。

図 9. 802.1X デシジョン ツリー

このフローチャートでは「大規模なビジネス」という用語を使用しているので混乱を招くかもしれません。 この用語は、一般に最低 500 人の従業員および最低 5 人の技術者のいる IT サポート部門がある企業を意味しています。 しかし、この情報を検討することで、中規模ビジネス環境に対してもどのソリューションが適しているかが明確になります。 決定プロセスはリスクへの取組み姿勢およびコスト効率に応じて展開されています。

PEAP と EAP-TLS の主な違いは、証明書インフラストラクチャが必要かどうかにあります。このため、EAP-TLS は一般に大規模ビジネスのニーズに適したオプションであると考えられ、より厳しいセキュリティ標準を要求する規制の要件がない場合は、小規模ビジネスには PEAP で十分であると考えられています。 コストについて考慮しなければ、組織に証明書インフラストラクチャを必要とする他の理由があり、このために PKI に投資する必要がある場合があります。 結局、Web コンテンツをセキュリティで保護したり、コード署名を行ったりするために多くの証明書が必要な場合は、最もセキュリティが高い方式の 802.1X 認証を実装するために、このインフラストラクチャに投資するのが合理的であると言えます。

802.1X PEAP の要件

マイクロソフト ベースの PEAP MS-CHAP v2 実装では、Active Directory アカウント データベースに対してワイヤレス クライアントを認証するために、認証サーバーとして機能する IAS RADIUS サーバーを少なくとも 2 台必要とします。 RADIUS サーバーの数は、リモート サイトの数に基づいて、またはより多くのユーザー認証に対応するために調整する必要があります。

リモート サイトがあるからといって、必ずしも IAS RADIUS サーバーを追加する必要があるわけではありません。 ただし、リモート サイトで高帯域の接続が冗長化されていない場合、または各サイトに既に独自のドメイン コントローラおよび他のローカル リソースがある場合は、このようなサイトには認証サーバーを追加する必要があります。

802.1X EAP-TLS の要件

前に述べたように、追加の証明書要件があるために、EAP-TLS では PEAP 実装より多くのリソースを必要とします。 もちろん、サードパーティ プロバイダを使用してすべてのワイヤレス クライアントおよび認証サーバーに対して必要な証明書を発行することは可能ですが、この方法ではワイヤレス クライアントの数がごく少数のユーザーに限られていない限り、証明書インフラストラクチャを実装するよりコストが高くなります。

つまり、シンプルな EAP-TLS 実装では最低 4 台のサーバー、規模の大きい企業または地理的に分散されたネットワークでは、必要に応じてそれ以上のサーバーが必要になります。 4 台のサーバーのうち 2 台は冗長 IAS RADIUS サーバーとして機能し、残りの 2 台は証明書インフラストラクチャとして機能します。 2 台の証明書サーバーのうち 1 台 (ルート証明書サーバー) をネットワーク外に構築し、ネットワークから切断した状態にしておくことをお勧めします。言い換えると、特定の状況ではサーバーの数を 1 台減らすことができるということです。

WEP または WPA を使用する

ワイヤレス セキュリティに関して対処する必要があるもう 1 つの問題は、ワイヤレス暗号化を使用するかどうかということです。また、使用する場合は、どの標準を使用するかという問題があります。 中規模ビジネス環境では、パブリック アクセスのワイヤレス インターネット接続を提供する業務において、ワイヤレス暗号化を使用しない方法を採用することは望ましくありません。 使用する場合は、ワイヤレス ネットワークのセキュリティを保証するために、802.1X ベースの認証と共に何らかのワイヤレス暗号化を実装することが必須です。

ワイヤレス暗号化には、次の 2 つの形式と 1 つの改良型があります。 次の説明を参照してください。

  • WEP。 Wired Equivalent Privacy 標準は、64 ビットまたは 128 ビットの RC4 暗号を使用してワイヤレス通信のセキュリティを保護する最初の IEEE 802.11 標準の一部でした。 この暗号化方法は、受動的な傍受による攻撃に対するセキュリティが弱いという重大な欠陥が発見されました。 比較的短時間、時には数分の間に WEP 通信を解読できてしまう、多くのツールを容易に入手することができます。 一般にビジネス環境において WEP を使用することはお勧めできませんが、802.1X 認証など、さまざまな方法を使用することである程度のセキュリティを確保することはできます。

  • WPA。 WEP 標準に固有の弱点に対処するために、マイクロソフトおよび Wi-Fi Institute を含む主要企業のコンソーシアムによって、当時開発中だった 802.11i 標準の部分的な実装として Wi-Fi Protected Access (WPA) 標準が作成されました。 この標準では、データ暗号化に Temporal Key Integrity Protocol を使用するはるかに強力な暗号が提供され、欠陥がある WEP 標準よりはるかに優れています。 今日市場にあるほとんどのワイヤレス アクセス ポイント (WAP) で WPA 標準がサポートされています。Microsoft Windows オペレーティング システムのすべての現在のバージョンでも同様にサポートされています。

  • WPA2。Wireless Protected Access 2 (WPA2) 標準は、Wi-Fi Alliance によって 2004 年 9 月に制定されました。 これは IEEE 802.11i 仕様の完全な実装として認定されています。この標準は 2004 年 6 月に承認されました。この標準は 802.1X ベースの EAP 認証方式または PSK テクノロジ (個人モードの WPA と呼ばれることもあります) をサポートしていますが、Advanced Encryption Standard (AES) と呼ばれる Counter-Mode/CBC-MAC Protocol (CCMP) を使用する高度な暗号化メカニズムを導入しています。 このワイヤレス暗号化の実装を使用すると、非常に強力なセキュリティを実現することができます。 ほとんどのベンダは、Microsoft Windows オペレーティング システムの現在のバージョンなどにより、何らかの形で WPA2 をサポートしています。

WPA2 や WPA を採用できる場合は、これらの標準を使用してワイヤレス環境のデータをセキュリティ保護するべきです。 しかし、これらは新しい標準であるため、特にこれらの標準をサポートしていないワイヤレス環境に対して、既に大きな投資が行われている場合は、これらの標準を導入できない場合があります。 前に述べたように、802.1X 認証を構成し、頻繁にキー ペアを変更することで、WEP 標準で提供されるセキュリティ レベルを向上することは可能です。 しかし、このような場合でも、WEP は WPA または WPA 2 標準への移行中のワイヤレス ネットワークでのみ使用するべきです。

SMS を使用して管理されていないシステムを検出する

Microsoft Systems Management Server (SMS) 2003 は、Microsoft ネットワークで利用できる非常に用途が広い管理ツールです。 SMS を使用すると、ソフトウェア配布、セキュリティ更新プログラムの展開、およびシステム監査など、複数の管理機能を集中化することができます。 これらの機能の中心となるのは、これらの非常に便利なツールの展開元となる自動化および集中化されたシステム インベントリを保持する機能です。このインベントリは、管理されていないシステムを検出する場所として機能します。

SMS 2003 は、管理者がコンピュータ コレクション データベースを構築するために使用できるさまざまな検出方法を提供します。このデータベースには、ネットワーク上のすべてのコンピュータに関する情報が保持されます。 これらの検出方法は、Active Directory ベースの検出方法 (Active Directory コンピュータ アカウント リストによって提供された詳細でコレクションを更新する) から、ネットワーク検出方法 (ネットワークを能動的に調査して接続されているデバイスを確認する) に及びます。 これらの検出方法は、事前に設定した間隔で自動的に起動され、終了したらコレクション データベースを更新するように構成することができます。

管理されていないシステムがネットワークに接続されたときにそれを検出するために、ネットワーク検出がより頻繁に実行されるように構成して定期的に調査結果を確認し、新しいシステムがいつネットワークに接続されたかを判断することが可能です。 このようなシステム接続が発生した場合、新しいコンピュータ ビルドまたはネットワーク接続要求の既存の一覧と照合し、新しいシステムがネットワークを使用することを承認されていることを確認することができます。

ネットワーク検出プロセス

管理されていないシステムを検出するこの方法の欠点の 1 つは、SMS では Microsoft Windows 以外のオペレーティング システムを使用するコンピュータの詳細を検出するのが困難なことです。 また、Microsoft Windows 98 SE より前のバージョンでは、Windows Management Interface (WMI) 実装がサポートされていないため、SMS 2003 の検出方法で検出されない場合があります。 このため、新しいデバイスがネットワークに接続されると検出されるように、このソリューションのプロセスにスクリプトを追加する必要があります。 次の図は、このようなプロセスがどのように機能するかを示しています。

図 10. SMS による管理されていないコンピュータの検出プロセス

この図は、SMS コレクション データベースに異なる種類のコンピュータを追加するために使用できる検出方法を示しています。 考慮する必要があるコンピュータは、次の 3 種類です。

  • SMS アクセス可能な管理されたシステム。 これらのコンピュータは SMS で管理することができ、SMS 管理下に置かれています。 これらは既に SMS コレクション データベースに存在し、自動管理できるように構成する必要があります。 これらは、多くの場合信頼されているネットワークの一部であると見なされ、注意を払う必要はありません。

  • SMS アクセス可能な管理されていないシステム。 これらのコンピュータは SMS で管理することができますが、SMS の管理下に置かれていません。 これらは、ネットワーク上の配置によって (たとえば、ファイアウォールの背後にあるかどうかなど)、SMS で検出可能な場合と可能でない場合があり、他の手段で管理されているコンピュータが含まれることがあります。 これらのコンピュータは、管理の詳細を記載した除外一覧に記載されている必要があります。 記載されていない場合は、これらは信頼されていないと見なされ、さらに調査する必要があります。 これらのコンピュータは、検出活動を妨げるネットワーク デバイスが何もない限り、SMS により検出可能です。

  • SMS アクセス不可の管理されていないシステム。 これらのコンピュータは SMS で管理することができず、SMS の制御下にありません。 これらには、他の手段で管理されている既知のシステムが含まれる場合と含まれない場合があります。 これらのコンピュータは、管理の詳細を含む除外一覧に記載されている必要があります。 記載されていない場合は、これらは未知で信頼されていないと見なされ、さらに調査する必要があります。 これらのコンピュータは、カスタムの検出スクリプトなど、SMS 検出以外のプロセスを使用することでのみ検出することができます。

この時点で、ネットワーク上の管理されていないシステムを検出するプロセスは、ネットワーク上の認証されたコンピュータのすべての接続の詳細を文書化するプロセスの確立に影響されることが明確になったはずです。 このようなドキュメントには、コンピュータに関する詳細、自動化された方法 (SMS など) で管理されているかどうか、自動化された方法で管理されていない場合は、コンピュータを既存のセキュリティ ポリシー (存在する場合) に準拠させるためにどのようなプロセスを使用しているかが含まれている必要があります。 もちろん、認証されたコンピュータはネットワーク上に存在していても、セキュリティ標準を満たすように要求されないことがあります。しかし、このようなコンピュータは、信頼されているネットワークから分離されている信頼されていないネットワーク セグメントに強制的に配置する必要があります。

承認された方法でネットワーク上に存在することがわかっているすべてのコンピュータを文書化する「コンピュータ追加」プロセスを文書化できれば、この情報を使用して承認されているものと承認されていないものを判断することができます。 この一覧に存在しないにもかかわらずネットワーク上で検出されたコンピュータは疑わしいと見なされ、すぐに調査する必要があります。

導入と管理

「開発」セクションでは、導入計画を作成するために必要な詳細についての情報を提供しました。 このセクションでは、一般的な導入に関する問題、およびこれらのソリューションを実装するときにテクノロジの実装担当者を支援するプロセス、または特定の環境に適しているかどうかについて適切な情報に基づいた決定を下せるように、意志決定者がこれらのソリューションに伴う事項の理解を深めるプロセスについて詳しく説明します。

IPSec を使用してドメインおよびサーバーを分離する

IPSec ベースのネットワーク分離は複雑なので、運用ネットワークでは、実装担当者は段階的にこのソリューションを導入することを提案します。 段階的に導入を行うには 2 つの方法があり、グループによって導入するかポリシーによって導入するかという IPSec ポリシーの導入方法に基づいています。

どちらの方法を使用するにしても、テスト環境でこのソリューションの影響をテストするだけでなく (可能な場合)、導入の最初の段階において各グループからのパイロット サンプルを使用することは重要です。 IPSec の導入は、詳細なロールバック計画と、技術の採用に伴い影響のある業務のプロセスの責任者の同意を含めた、正式な変更制御要求プロセスに従う必要があります。

グループによる IPSec の導入

グループによって IPSec ネットワーク分離を導入する方法では、完全に定義された IPSec ポリシーを使用しますが、ポリシーを配布する GPO の ACL を使用して実装を制御します。 すべての IPSec ポリシーでは、すべての除外およびセキュリティ保護サブネットが導入前に有効にしたすべての適切なフィルタ処理を使って完全に定義されます。

構成が完了すると、管理者は各 IPSec ポリシーの GPO およびこれらの GPO を管理するコンピュータ グループを作成します。 作成が完了すると、適切な IPSec ポリシーが対応する GPO に割り当てられ、GPO は Active Directory 内の適切なオブジェクトにリンクされます。 GPO 割り当てを制御する ACL が空のため、このプロセスのこの時点ではポリシーは配布しないでください。

パイロット コンピュータを認識したら、対応するコンピュータ アカウントを適切なコンピュータ グループに配置することができます。次の GPO ポーリング間隔が過ぎたら IPSec ポリシーが適用されます。 各段階で別のコンピュータが展開一覧に追加されると、対応するアカウントをポリシー配布のために適切なグループに配置することができます。

この方法は、通信が中断されないように慎重に計画する必要があります。 たとえば、すべてのホストで使用するアプリケーションをホストするサーバーが IPSec で暗号化された通信を必要とするセキュリティで保護されたグループに配置された場合、まだグループに追加されていないコンピュータおよび IPSec 暗号化を使用できないホストはすべて中断されます。

ポリシーによる IPSec の導入

この方法では、実働状態で導入する前ではなく、導入時にゼロから IPSec にポリシーを構築することによって導入を実施します。 この方法を使用する場合、最初の IPSec ポリシーには、コンピュータにセキュリティのネゴシエートを行う規則が設定されていない例外一覧のみが含まれます。 最初のポリシーを配布したら、管理者は単一のサブネットにのみ影響するフィルタを使ってセキュリティ規則を作成することができます。 導入の進行過程では、ポリシーの導入が終了するまで、追加のサブネットをセキュリティの規則に追加することができます。

この段階的導入方法の長所は、グループごとの方法とは違い、すべてのサブネットに対してではなく全 TCP/IP トラフィックのごく一部に対してのみ IPSec のネゴシエーションが行われることです。 また、この方法では、単一のサブネットからすべてのネットワーク パスをテストできるため、問題の発生時に影響を受けるクライアントの数を減らすことができます。 しかし、この方法の問題は、グループごとの方法とは異なり、特定のコンピュータにではなく、分離ドメインまたはグループのすべてのコンピュータに適用されることです。 また、指定のサブネットとの接続を開始する際のいずれかの時点で、すべてのコンピュータはクリア テキストへのフォールバックによる 3 秒間の遅延に対処する必要があります。

この方法は、複数のサブネットを持つ複雑なネットワークではうまく機能しますが、比較的サブネットの数が少ない小規模なネットワークではあまり利点がありません。

例外の一覧

どんなにうまく設計されたネットワーク分離モデルでも、運用環境で実装すると何らの制約が発生します。 通常、DNS サーバーやドメイン コントローラのようなネットワーク環境の主要なコンポーネントによって、対処する必要のある課題が引き起こされます。 このようなシステムは、セキュリティで保護され、また、ネットワーク上のすべてのシステムから利用できなければなりません。 このため、これらのシステムは受信接続要求を受け入れるように開かれている必要があります。 計画を運用段階に移行するときに他の問題が発生する可能性がありますが、このような問題を解決するための方法があります。 例外の一覧がこれに当たります。

例外の一覧とは、IPSec でセキュリティを保護することができないコンピュータの一覧で、作成したすべての IPSec ポリシーで実装する必要があります。 IPSec は静的フィルタリングのみをサポートするため、例外の一覧に追加されたホストは、信頼されているかどうかに関係なく、ネットワークのすべての部分からの送信トラフィックと受信トラフィックの両方を許可します。 この理由から、これらのホストはサーバーの強化およびホスト ベースのステートフル ファイアウォール フィルタリングを通じて保護を強化し、管理されていないデバイスによって引き起こされるリスクを軽減するために、例外の一覧はできるだけ少なくする必要があります。 単一のサブネットまたは VLAN に例外の一覧のホストを配置して管理しやすくしたり、サーバーの機能を統合して例外の一覧のホストの数を減らしたりすることも効果的な場合があります。

例外の一覧に追加する必要があるホストには、次が含まれます。

  • ドメイン コントローラが、ドメイン メンバに対して IPSec ポリシーを提供し、ネットワーク分離の基盤となる Kerberos 認証を実施するにもかかわらず、ドメイン メンバとの IPSec 通信をサポートしていない。

  • 許容限度を超えたパフォーマンスへの影響を受ける可能性があるホスト。何千台ものクライアントを同時に管理する必要があるホスト、および DHCP サーバーなど、クリア テキストによるフォールバックで発生する 3 秒間の遅延の影響を受けるホストで発生する可能性があります。

  • 互換性のある IPSec が実装されていないホスト、または信頼されているコンピュータまたは信頼されていないコンピュータにサービスを提供するが、IPSec を使用しないホスト。

境界グループと同様に、例外の一覧に追加する必要があるホストに関して、正式の承認プロセスが必要です。

注   Microsoft Windows XP および Windows Server 2003 では、例外の一覧が不要になる「シンプルなポリシー」の修正プログラムが用意されています。 詳細については、サポート技術情報 914841 および 914842 を参照してください。

IPSec の管理上の考慮事項

実装が完了すると、IPSec ポリシーは、ネットワーク上の多くのホスト間の通信に影響を与えるようになります。 このため、導入後に変更が発生すると、多くのユーザーが多大な影響を受ける可能性があります。 この理由から、IPSec ベースの分離ネットワークで行われるすべての変更は、次に示す標準的な MOF 変更管理プロセスに準拠している必要があります。

  • 変更の要求 (RFC)

  • 変更の分類

  • 変更の承認

  • 変更の開発計画

  • 変更のリリース計画

  • 変更のレビュー

マイクロソフトでは、Windows Server 2003 を IPSec 管理プラットフォームとして使用することをお勧めします。 管理タスクを容易にするために、管理者は IP セキュリティ ポリシー MMC スナップインまたは Netsh コマンド ライン ツールのいずれかを Windows Server 2003 コンソールで使用することができます。 他の点では、IPSec ポリシーはグループ ポリシーを介して配布されるため、比較的簡単に管理することができます。 このため、既存の「コンピュータ追加」プロセスを使用する場合は、信頼されているネットワークに新しいコンピュータを追加する処理を自動化することができます。

ただし、変更を行う場合は、いくつかの点に注意する必要があります。次にその一部を紹介します。

  • IPSec SA 用に使用されていたフィルタ操作を変更すると、このポリシー設定に基づいている既存の SA が削除されます。 トラフィックの送信中の場合は、この機能によって新しいクイック モードが実施され、ネットワーク トラフィックが破棄される結果が生じる場合があります。

  • 認証方法またはメイン モードのセキュリティ メソッドを変更すると、IKE によって既存のメイン モードが削除されます。 状況によっては、この機能のためにサーバー側の IKE によるクライアントとのメイン モード ネゴシエーションが失敗することがあります。

  • GPO の IPSec ポリシーが変更されると、特定の遅延 (Active Directory での複製に関する遅延および GPO ポーリングに関する遅延など) が発生します。この遅延は、環境の規模および複雑さによって異なり、数分から数時間に及ぶ可能性があります。

もう 1 つの管理上の注意事項は、感染が発生した場合に、感染した疑いのあるコンピュータをどのように分離するかということです。 不正行為に対処する方法には、次に示すように多くの方法があります。

  • 分離ドメインを分離する。 信頼されていないデバイスが不正行為のプラットフォームとして使用されている疑いがある場合は、IPSec – Secure Request Mode フィルタを変更してセキュリティで保護されていない通信を無効にすることによって、分離されたネットワークを信頼されていないネットワークから完全に切り離すことができます。

  • 疑わしいポートをブロックする。 一方向のフィルタが 2 つ含まれるフィルタ一覧を作成することでポートごとにトラフィックをブロックすることができます。 この方法は、DNS など必要なトラフィックをブロックすることがあるため、注意して使用する必要があります。このために IPSec の変更またはロールバックがさらに困難になります。

  • 子ドメインの分離。 IPSec 認証に Kerberos プロトコルではなく事前共有キーを使用するようにドメインのポリシーを変更することで、ドメインをフォレスト内の他のドメインから分離することができます。

  • 定義済みグループの分離。 IPSec 認証に Kerberos プロトコルの代わりに事前共有キーまたは証明書を使用することで、同じ種類の分離機能を実施する異なるキーまたは証明書を使用する分離グループを作成することができます。

VPN 検疫サービスを使用して管理されていないリモート コンピュータからネットワークを保護する

基本的に、VPN 検疫制御を実際に導入するには、特定の組織に存在する他の変更管理要求プロセスおよび導入前テスト プロセスの他に、6 つの手順を実施する必要があります。 次に、その 6 つの手順を示します。

  1. 検疫リソースを作成します。

  2. クライアントの構成を検証するスクリプトを作成します。

  3. リスナ コンポーネントの Rqs.exe をリモート アクセス サーバーにインストールします。

  4. Windows Server CMAK で検疫接続マネージャ (CM) プロファイルを作成します。

  5. CM プロファイルをリモート アクセス クライアント コンピュータに配布します。

  6. 検疫のリモート アクセス ポリシーを構成します。

1. 検疫リソースを作成する

既存のセキュリティ ポリシーに準拠した状態にするために、検疫されたクライアントで内部リソースを使用する場合は、セキュリティで保護するために必要な更新プログラムおよび必要な他のソフトウェアをインストールするために使用するアクセス可能な一連のリソースが必要です。 前のセクションで詳しく述べたように、通常、これらのリソースにはネーム サーバーやファイル サーバーが含まれ、Web サーバーが含まれることもあります。 これらの検疫リソースを指定する方法には、内部ネットワークに配置されている既存のサーバーを指定する方法、および必要なリソースを個別のサブネットに配置する方法など、いくつかの方法があります。

個々のサーバーを指定する最初の方法では既存のサーバーを使用するため、更新プログラムを配布するこのようなサーバーを追加することに関連するコストを削減できます。しかし、この方法では各リソースで個別のフィルタが検疫リモート アクセス ポリシーの MS-Quarantine-IPFilter 属性に必要になるため、複雑なパケット フィルタが必要です。

すべての検疫リソースを検疫サービス専用の単一のサブネットに配置するには、より多くのサーバーをネットワーク環境に追加する必要がありますが、すべての検疫リソースに対して単一の入力および出力のパケット フィルタのみが必要となります。

2. 検証スクリプトを作成する

検疫スクリプトは、リモート アクセス コンピュータがセキュリティ ポリシーに準拠していることを確認する一連のテストを実施します。 これらのテストが完了したら、スクリプトは RQC.exe クライアント コンポーネントを起動するか (成功の場合)、あるいはポリシーに準拠させるためにクライアント コンピュータを適切なリソースにダイレクトする必要があります。 もちろん、代わりにネットワーク ポリシーによってこの方法が規定されている場合は、スクリプトによってネットワークでタイムアウトを発生させ、エラー メッセージを表示することもできます。 これらのスクリプトはコマンド ライン バッチ ファイルのようにシンプルにすることも、複雑な実行可能ファイルにすることもできます。

サンプル スクリプトの一部は、マイクロソフト ダウンロード センターの www.microsoft.com/downloads/details.aspx?FamilyID=a290f2ee-0b55-491e-bc4c-8161671b2462&displaylang=enの「[VPN Quarantine Sample Scripts](https://www.microsoft.com/download/details.aspx?familyid=a290f2ee-0b55-491e-bc4c-8161671b2462&displaylang=en)」(英語) ページで参照およびダウンロードできます。

3. RQS.exe をリモート アクセス サーバーにインストールする

Microsoft Windows Server 2003 コンピュータにリモート アクセス検疫エージェント サービス (Rqs.exe) をインストールするプロセスは、Service Pack 1 (SP1) を導入したサーバーでは異なります。 説明を簡潔にするために、すべてのシステムで最新の Service Pack およびセキュリティ更新プログラムがすべて適用されていることを前提として、このセクションでは Windows Server 2003 SP1 でのインストールについてのみ説明します。

Windows Server 2003 SP1 サーバーに Rqs.exe をインストールするには

  1. [スタート] をクリックして [コントロール パネル] をクリックします。

  2. [プログラムの追加と削除] をクリックします。

  3. [Windows コンポーネントの追加と削除] をクリックします。

  4. [コンポーネント] を選択し、[ネットワーク サービス] をクリックします。

  5. [詳細] をクリックします。

  6. [ネットワーク サービスのサブコンポーネント] を選択して、[リモート アクセス検疫サービス] をクリックし、[OK] をクリックします。

このプロセスが終わると、検疫サービスはインストールされますが起動されません。ソリューションが完全に構成されて環境を実装する用意ができた後で、管理者が手動で起動する必要があります。

インストール プロセスには、検疫スクリプトの Rqc.exe に対して構成されたバージョン文字列と一致するように、スクリプトのバージョン文字列を変更する手順も含まれます。Rqs.exe は、複数のスクリプト バージョン文字列を受け入れるように構成することができます。次に、バージョン文字列は、リモート アクセス サーバーのレジストリの HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\rqs\AllowedSet 以下に書き込まれます。この場所には、これらの設定が REG_MULTI_SZ タイプの値を用いて適用される必要があります。 通常、Allowed Set 値は RASQuarantineConfigPassed に設定されますが、追加の文字列値を加えることができます。

4. 検疫 CM プロファイルを作成する

検疫 CM プロファイルは、実際には通常のリモート アクセス CM プロファイルに次が追加されたものです。

  • ネットワーク ポリシーへの準拠および実際のスクリプトをチェックするために作成されたスクリプトを実行する接続後の操作。 これは CMAK ウィザードの [カスタム動作] ページで実行します。

  • 通知コンポーネントも、CMAK ウィザードの [追加ファイル] 画面で実施するように、プロファイルに追加する必要があります。

5. CM プロファイルを配布する

新しく作成した検疫 CM プロファイルは、すべてのリモート アクセス クライアント コンピュータに配布およびインストールする必要があります。 プロファイルは実行可能ファイル形式です。このファイルは、プロファイルをインストールして検疫ネットワーク接続を構成するために、各リモート アクセス クライアント コンピュータ上で実行する必要があります。

これらのプロファイルは、手動で配布することもできます。たとえば、添付ファイルとして指示項目を付けて共にユーザーに送信することができます。 または、SMS 2003 ソフトウェア配布などのツールを使って、自動的に配布することもできます。 配布方法は多数ありますが、各環境で最適な方法は異なります。

6. 検疫のリモート アクセス ポリシーを構成する

検疫のリモート アクセス ポリシーを構成する手順は、IAS サーバーで構成したか、または次のように別の認証プロバイダで構成したかによって異なります。

  • IAS RADIUS サーバーで構成した場合は、インターネット認証サービス スナップインを使用します。

  • Windows 認証プロバイダで構成した場合は、ルーティングとリモート アクセス スナップインを使用します。

ポリシーの作成時は、通常モードのリモート アクセス ポリシーを最初に作成する必要があります。 次にリモート アクセス ポリシー プロファイル プロパティの [詳細] タブで MS-Quarantine-Session-Timeout 属性および MS-Quarantine-IPFilter 属性を追加します。

RADIUS が使用中の場合は、検疫リモート アクセス ポリシーは、構成をコピーするか、各サーバーで手動で作成するかによって、他の RADIUS サーバーで複製する必要があります。

802.1X 認証を使用して、管理されていないワイヤレス クライアントからネットワークを保護する

前のセクションで説明したように、中規模ビジネスでワイヤレス ネットワークのセキュリティを保護するために、マイクロソフトが推奨するすべてのオプションを次に示します。

  • WPA2/AES と EAP-TLS

  • WPA2/AES と PEAP-MS-CHAP v2

  • WPA/TKIP と EAP-TLS

  • WPA/TKIP と PEAP-MS-CHAP v2

WEP を EAP-TLS または PEAP-MS-CHAP v2 のいずれかのソリューションの一部として使用すると WEP のセキュリティを強化できますが、この方法はよりセキュリティの高い WPA または WPA2 標準への移行時にのみお勧めします。

EAP-TLS および PEAP-MS-CHAP v2 を実装するプロセスには、共通点がいくつかあります。 どちらもソリューションの一部として Microsoft IAS RADIUS サーバーを使用し、どちらも何らかの形の証明書を必要としますが、EAP-TLS ではクライアント コンピュータとサーバーの両方で証明書を必要とし、PEAP-MS-CHAP v2 では認証サーバーでのみ証明書が必要です。 これが、EAP - TLS の実装時に証明書インフラストラクチャを導入することをお勧めする理由です。サードパーティ プロバイダからすべてのクライアントの証明書を購入するコストは非常に高額な場合があるためです。

EAP-TLS および PEAP-MS-CHAP v2 を使ったワイヤレス認証

EAP-TLS および PEAP-MS-CHAP v2 の実装プロセスには、この文書に記載されていない内容が多くあります。 しかし、ワイヤレス ネットワークをセキュリティで保護するためのソリューションを設計および実装するための優れたリソースが既に多数存在します。その一部を次に紹介します。

SMS を使用して管理されていないシステムを検出および修正する

「開発」セクションで述べたように、SMS 検出プロセスは、SMS で管理できる場合は新たに接続されたコンピュータをネットワーク上で検出する際に非常に役に立ちます。 また、SMS は検出プロセス時に管理できないシステムを検出できない場合があるため、この欠点を補うために別のメカニズムが必要であることも述べました。

ネットワークに接続されたコンピュータを SMS で検出できない場合、いくつかの理由があります。 次のような場合です。

  • 検出時にコンピュータは接続されているが動作しておらず、ドメインにコンピュータ アカウントがない。

  • コンピュータが、ファイアウォールまたは他のネットワーク デバイスによって SMS サーバーとサブネット間の通信が妨げられているサブネットに接続されている。

  • コンピュータはアクセス可能なネットワークに接続されているが、SMS で検出できないオペレーティング システムが使用されている。

このような事態に対処するには、SMS の実用性と SMS で管理できない項目を扱うスクリプトを組み合わせるカスタムのソリューションが必要です。 カスタム スクリプトを使用すると、スケジューラ プロセスで一定間隔を空けてネットワークをスキャンすることができます。つまり、短時間しか接続されないデバイスを検出できることを意味します。 また、このようなスクリプトは通常は分離されているサブネット上に配置されたワークステーションまたはサーバーからも実行できます。つまり、通常は、管理されていないシステムが監視されていないネットワーク セグメントに接続されると、これを検出できることを意味します。 このようなスクリプトでは WMI ベースの検出プロセスは実施されないため、管理されていないクライアントで使用されるオペレーティング システムに影響されません。

ネットワーク上のデバイスを検出するために SMS を使用する方法については、「Patch Management Using Systems Management Server 2003」のソリューション アクセラレータ (英語) を参照してください。また SMS スクリプト ソリューションのリソースなどへのリンクについては、「Microsoft Systems Management Server」のホーム ページを参照してください。

ページのトップへ

概要

この文書では、管理されていないシステムに関連する問題を管理するために、包括的なアプローチを使用できることを示しました。 IPSec ネットワーク分離は、管理されていないシステムが信頼されているネットワークのリソースにアクセスすることを防ぎ、非準拠のコンピュータへのサービスを拒否することでポリシーに準拠させるために使用できることを紹介しました。 VPN 検疫サービスを使用すると、リモート アクセス ソリューションを使用するがローカル ネットワークにあまり接続しないモバイル コンピュータをポリシーに準拠させることができます。 IEEE 802.1X および WPA/WPA2 を使用すると、ワイヤレス LAN 上の承認されていないデバイスからネットワークを保護することができます。 そして、SMS および検出スクリプトを使用すると、管理されていないシステムの検出を支援し、すべての更新プログラムおよびセキュリティ更新プログラムを使って、管理されているコンピュータを最新の状態に維持することができます。

これらの技術的ソリューションは、管理されておらず承認されていないデバイスに関連する問題の多くを解決するために役立ちますが、これらのソリューションは完全なセキュリティ ポリシーを作成し、厳格な変更管理プロセスも確立したときにのみさらに強化することができます。 これらのソリューション、ポリシー、およびプロセスをすべて組み合わせると、管理コストを削減し、セキュリティ リスクを許容可能なレベルまで下げることができる、管理が容易な中規模ビジネス インフラストラクチャを構成することができます。

ページのトップへ

付録 A : ネットワーク アクセスの保護

ネットワーク アクセス保護 (NAP) は、次世代の Windows (Microsoft Windows Server Longhorn および Windows Vista™) に組み込まれる新機能で、健康状態に関するポリシーにコンピュータを準拠させる機能を提供します。 NAP を使用すると、管理者は健康状態検証ポリシーのしきい値をアプリケーション プログラミング インターフェイス (API) を使用して設定できます。これにより、健康状態の要件を満たしていないコンピュータがネットワークに接続されたときに、ネットワーク アクセスを制限することができます。

柔軟な NAP の機能を利用すると、管理者は、各環境の要件に適したカスタム ソリューションを構成し、ネットワークに接続されたコンピュータの健康状態のログの記録のみ行ったり、ソフトウェア更新プログラムを自動的に配布したり、健康状態の要件を満たさないシステムの接続を制限するなど、さまざまな管理を実行できます。 さらに、NAP は柔軟性が高いため、サードパーティ アプリケーションやカスタムのプログラム ソリューションを組み込むことができ、コンピュータに健康状態のポリシーを包括的に強制することができます。 また、NAP を包括的に利用することもできます。実施コンポーネントにより、管理者は DHCP、VPN、および 802.1X ワイヤレス ネットワークを通じてコンピュータを健康状態のポリシーに準拠させることができます。また、NAP は IPSec にも対応しています。

NAP の詳細については、「Network Access Protection」(英語) ホーム ページを参照してください。

ページのトップへ