Microsoft Windows 2000 テクニカル リファレンス セキュリティ ガイド

第 11 章 ‐ ネットワークのセキュリティ

「Microsoft Windows 2000 テクニカルリファレンス セキュリティガイド」 (発行 : 日経 BP 社) より抜粋

 11.1 IP 通信の保護

 11.2 DHCP セキュリティの問題

 11.3 動的 DNS の保護

 11.4 DFS セキュリティ

 11.5 リモートアクセスのセキュリティ

 11.6 まとめ

本書でこれまで説明してきたとおり、Windows 2000 では、オペレーティングシステムのセキュリティモデルが大幅に改善されている。ただし、ネットワークを通じてデータを伝送するときにデータがどのように保護されるのかについては、まだ説明していない。Windows 2000 コンピュータのファイルシステムは、アクセス許可を適用したうえで暗号化すれば保護できるが、承認ユーザーが別のシステムからファイルにアクセスすると、そのファイルは未保護の状態でネットワーク上を伝送されるので、未承認のユーザーが容易に傍受できてしまう。

この章では、ネットワークを通じてデータを伝送する際の安全を確保し、ネットワーク経由の不正アクセスからシステムやサービスを保護するために、Windows 2000 に組み込まれているテクノロジを説明する。該当するテクノロジは次のとおりである。

• IPSec - インターネットプロトコルセキュリティ (IPSec) は、開放型システム間相互接続 (Open Systems Interconnect : OSI) モデルのネットワーク層におけるエンドツーエンド暗号の使い方を定めた公開標準であり、関与するシステムのすべてのネットワーク通信を保護する。

• 動的 DNS - 認証されたシステムのみがリソースレコードにアクセスして、それを動的に更新できるようにすることで、Windows 2000 DNS サーバーの安全を確保する。

• DHCP セキュリティ - DHCP サーバーを承認することで、未認証サーバーが不正確な TCP/IP 構成データや誤った DHCP 応答メッセージを発行するのを防ぐ。

• リモー トアクセス - 離れた場所からネットワークにアクセスできる能力は便利ではあるが、本質的にリスクを伴う。Windows 2000 は、リモートユーザーが正しく認証され、データが保護されるように保証するメカニズムをいくつか備えている。

ネットワークオペレーティングシステムが使用する従来型のセキュリティメカニズムの多くは、ユーザー名とパスワードに基づいている。Windows 2000 には、暗号化ファイルシステムやスマートカード認証など、いくつかの新機能が追加されているが、これらのテクノロジはワークステーションのセキュリティを高めるためのものであって、ネットワークを通じて伝送されるときにデータを保護するものではない。たとえば、ネットワーク管理者は、厳密なアクセス許可を慎重に適用すれば機密データを保護できるが、承認ユーザーがリモートシステムからこれらのファイルの 1 つにアクセスしたとき、そのデータがネットワーク上を移動している間はまったく保護されない。ファイルを暗号化したとしても、クライアントに送信する前に、サーバーシステムがファイルを復号化してしまう。

ネットワークを物理的に保護することも対策の 1 つである。ケーブル自体に触れないようにすれば、侵入者がネットワークにアクセスするのを防げる。しかし、そのためには金属製の管内にケーブルを格納したり、ウォールプレートや配線ボックスへの接触を慎重に制限するなど、大げさな対応が必要になる。政府機関など、きわめて高度なセキュリティが必要なネットワークでは 1 つの候補ではあるが、普通はあまり現実的でない。

したがって、保護すべきデータが伝送中に盗まれ、さまざまな意味でネットワークや業務に悪影響を及ぼすおそれはどうしても残る。現在のネットワークは以前よりはるかに大規模になり、ネットワークのセキュリティに対する脅威が必ずしもファイアウォールの外側から来るとは限らなくなっている。ここではまず、内部からネットワークに悪影響を与える一般的なテクニックをいくつか説明する。

ネットワークアナライザ、つまり「スニッファ」は、ネットワークに接続して、システム間で送受信されるデータを捕捉するデバイスである。スニッファは、ネットワークインターフェイスをプロミスキャスモードと呼ばれるものにすることで、宛先の特定コンピュータだけでなく、ネットワーク上の全パケットを読み取る。アナライザは、携帯型の装置やコンピュータ上で実行されたソフトウェアプログラムの場合もある。SMS (Microsoft Systems Management Server) にはネットワークモニタと呼ばれるネットワークアナライザが付属しており、そのほかにも同様の製品がたくさん販売されている。これらのツールでは、機密ファイルの一部など、内部のデータを含めて、各パケットの中身を読み取ることができる。平文でネットワーク上を伝送される情報は、この種の攻撃に弱い。

侵入者が、捕捉したパケット内のデータにアクセスできる場合は、データを修正してから、そのパケットを本来の受信者に送信できる。パケットの受信者には、データが改ざんされていることがわからない。

TCP/IP ネットワークのパケットには、それぞれに送信元と送信先のシステムの IP アドレスが入っている。侵入者は、別のシステムの IP アドレスを使用してそのシステムを偽装することで、アクセスが認められていない情報にアクセスできる。これをスプーフィングという。クライアントとサーバー間の一般的な通信セッションでは、この 2 つのシステムは、伝送制御プロトコル (TCP) によって接続を確立してから、連番が入ったパケットを交換する。接続の当事者であるどちらかのシステムを偽装するため、侵入者はパケットの一部を捕捉し、そのシステムの IP アドレスを使用して、同じ連番の範囲を使用して自分のパケットを送信する。同時に、偽装先のシステムにサービス拒否 (DoS) 攻撃を開始して、システムが自らのパケットを送信するのを妨害することもある。この偽装者が犠牲者の役割を装うのに成功したら、本来はそのシステム用だったデータを受信して、自分のメッセージを送信することさえ可能になる。この種の攻撃では、ネットワークを通じて送信されたデータが漏洩するだけでなく、侵入者がアクセス先のドライブに保存されたファイルにアクセスして、さらに大きな被害をもたらすおそれもある。

厳格なパスワードポリシーを実施しているネットワーク管理者は少ない。そのため侵入者にとっては、パスワードを取得するのは一般的にかなり容易である。驚くべきことに、誰かを装い、ユーザーに電話をかけてパスワードをたずねるという単純な方法で、実に多くのパスワードが漏れている。ただし、専用のソフトウェアによってパスワードを解読したり、スニッファを使用してパスワードを入手する場合もある。オペレーティングシステムやアプリケーションは、通常、送信前にパスワードを暗号化するが、FTP のように暗号化しないものもある。ネットワークのサポート担当者が、FTP ファイル転送などの日常的なタスクに管理用アカウントを使用しないように奨励するのはこのためだ。十分な権利を持つパスワードを手に入れれば、保護されたファイルにアクセスできるだけでなく、ネットワークやシステムの設定を変更したり、侵入が発覚した後で使うために偽のアカウントを作成するなど、さらなる破壊行為を実行することもできる。

コンピュータやネットワークに無用なトラフィックを大量に流して通常の運用を妨害することで、ユーザーによるネットワークリソースへのアクセスを妨げたり、システムやアプリケーションを過負荷にしてシャットダウンさせたり、特定のシステムに対するそのほかの攻撃から管理者の目をそらせたりすることがある。DoS 攻撃は数種類あり、そのほとんどが TCP/IP の通常の機能や手続きを利用したものである。たとえば、TCP 接続の開始を要求するメッセージをシステムに繰り返し送信する。すると、ターゲットシステムのキューが未達成要求でいっぱいになり、ほかのシステムがネットワーク上で接続を開こうとする正当な行為が失敗する。

パスワード漏洩の場合と同様、暗号化などのデータ保護に使用するキーを手に入れることができれば、保護されたリソースにアクセスし、安全と信じられている通信を傍受して、別のユーザーを装うことができる。

多くの場合、ネットワークシステムで動作するアプリケーションのセキュリティは完全ではないので、オペレーティングシステム、アプリケーション、データファイルを改ざんしたり、ウイルスやトロイの木馬などの不正ソフトウェアを紛れ込ませたり、アプリケーションやオペレーティングシステムのアクセス制御メカニズムをかく乱したりして、システムに損害を与えることができる。この種の攻撃は、インターネットクライアントにサービスを提供するように設計された Web サーバーなどのアプリケーションが標的になることが多い。

IPSec を使用すると、これまでに述べたような、Windows 2000 システムに対するあらゆるタイプの攻撃を防ぐことができる。IPSec は、送信前に個々のインターネットプロトコル (IP) パケットを暗号化することで、ネットワーク伝送を保護するように設計されたプロトコルである。IP は、OSI 参照モデルのネットワーク層で機能するコネクションレスプロトコルである。ほかのすべての TCP/IP プロトコルは実質的に、ネットワーク上のほかのシステムにメッセージを送信する際の「封筒」として IP を使用する。この封筒に入れて運ばれるデータを暗号化すれば、侵入者がそのパケットを横取りできたとしても、中身を読むことはできない。

図 11.1 に示すとおり、OSI 参照モデルでは、コンピュータのネットワーク処理プロセスが 7 つの層に分かれている。ネットワーク層は 3 番目の層であり、コンピュータの所属先の LAN (イーサネットやトークンリングなど) が使用するプロトコルを定義したデータリンク層と物理層のすぐ上位にある。IP のようなネットワーク層プロトコルは、ネットワーク間通信にとって主要なエンドツーエンド配信システムである。つまり、パケットを生成したシステムとそのパケットの最終的な受信側のみが、内部的にやりとりされるデータに関与する。LAN 間接続に使用するルーターなどの中間システムは、ネットワーク層にあるパケットのみを処理して、次の目的地に転送する。

図 11.1: OSI 参照モデル

IPSec を使用してデータを保護する際、送信側のシステムは個々のパケットを暗号化し、通常どおりに送信する。パケットが最終目的地に到着するまで、復号化は行われない。このようにすると、ネットワーク内の移動中にパケットを横取りしても、無意味な暗号パケットしか手に入れることはできない。つまり、パケットを転送する中間システムが IPSec をサポートしている必要がないので、LAN 接続、WAN 接続、ダイヤルアップを使用したリモートアクセス接続や仮想プライベートネットワーク接続 (VPN) に IPSec を採用できる。データリンク層で機能する暗号化では、中間リンク上のデータしか保護されない。そのうえ、パケットを処理する全ルーターが、受信時にそのパケットを復号化し、転送時に再び暗号化する必要がある。これでは、ルーターの処理負荷が増加するだけでなく、IPSec に対応したルーターしか使えなくなってしまう。

ネットワーク層での暗号化は、そのトラフィックを生成したアプリケーションやプロセスが何であれ、全ワークステーションの送出トラフィックに保護が適用されるということでもある。これは、OSI モデルの上位層で機能する暗号化プロトコルとは対照的だ。たとえば、Web クライアント/サーバー通信の保護に使用するセキュアソケットレイヤ (SSL) プロトコルは、モデルの最上位層であるアプリケーション層で機能するので、正常に機能するためには、クライアントアプリケーションとサーバーアプリケーションの両方がこのプロトコルをサポートしていなければならない。IPSec は、ネットワーク層より上位で稼働する全プロセスに完全に透過的である。つまり、TCP、UDP、ICMP (インターネット制御メッセージプロトコル) など、IP データグラムに入れて運ばれるすべてのプロトコルは自動的に保護される。また、IPSec ではデータは送信側システムのアプリケーション層を離れた後に暗号化され、受信側システムのアプリケーション層に届く前に復号化されるので、SSL とは違って、通信の当事者であるアプリケーションを修正する必要はない。

IPSec は、個々のパケットの暗号化に加えて、次のような多くのセキュリティサービスを提供する。

• 非否認 - IPSec は、デジタル署名と公開キーテクノロジを使用して、メッセージが偽装者からではなく、実際の送信者から発信されたことを検証する。送信側がそのメッセージを生成したことを拒否することも、送信側に代わって第三者がメッセージを生成することもできない。

• 認証 - IPSec は、通信前にシステムが相手の身元を検証できるように、事前の共有キーによる認証、Kerberos 認証、公開キー証明書に基づいたデジタル署名など、多種多様な認証手段をサポートしている。

• 暗号化 - パケットデータを暗号化するため、Windows 2000 に実装されている IPSec は、DES (Data Encryption Standard) アルゴリズムまたは 3DES (Triple Data Encryption Standard) アルゴリズムを使用する。DES と 3DES は対称型暗号化アルゴリズムである。つまり、データの暗号化と復号化に使用するキーを双方のシステムが持っている。これらのアルゴリズムは、データを 64 ビットのブロックごとに暗号化する。3DES では、各ブロックを3回処理するによってセキュリティを向上している。

• 再生攻撃への耐性 - パケットの中身を読むことはできなくても、場合によっては、横取りしたパケットをそのまま使うことができる。たとえば、クライアントとサーバー間の最初のメッセージ交換には認証情報が入っていると推測できる。後でそのパケットを再送信すれば、サーバーにアクセスできる可能性がある。IPSec は、CBC (Cipher Block Chaining) というテクニックを採用している。これを DES または 3DES、および一意の IV (Initialization Vector) と併用すると、まったく同一のデータが入った 2 つのパケットがある場合でも、暗号化後のパケットはそれぞれ異なって見える。そのため、暗号の見当がつかない侵入者がトラフィック分析テクニックを使用してパケットの中身を推測しようとしても、それは不可能である。

• 完全性 - IPSec では、HMAC (Hash Message Authentication Code : ハッシュメッセージ認証コード) を作成して、送信前に各パケットにデジタルに署名できる。暗号チェックサムまたは MIC (Message Integrity Code : メッセージ完全性コード) とも呼ばれるこの署名は、通信に関与する双方が 1 つのキーを共有する点が、公開キーテクノロジを使用するそのほかのデジタル署名と異なっている。HMAC は、パケットの中身を要約していることから、メッセージダイジェストとも呼ばれる。また、メッセージからダイジェストを作成することはできるが、ダイジェストからはメッセージを作成できないことから、不可逆変換とも呼ばれる。送信側のシステムは、パケットデータを MD5 (Message Digest 5) や SHA-1 (Secure Hash Algorithm 1) などのハッシュ化アルゴリズムに通してHMACを計算し、それをパケットに添付する。受信側のシステムも、パケットを処理するときにこれと同一の計算を行う。伝送中にこのデータが改ざんされていた場合は、HMAC の結果がそのパケットの署名と食い違う。

IPSec が備えている保護機能では、前述のどの攻撃も防止できる。パケット内のデータを暗号化している場合、第三者がパケットの中身を読み取ることはできない。IPSec では、パケットの捕捉を防ぐことはできないが、侵入者がデータを使用するのを防ぐことができる。この暗号を、システム間に信頼関係を確立する双方向認証と併用すれば、パスワードやキーの横取り、身元の偽装、アプリケーションの改ざんを防止できる。IPSec の暗号チェックサムでは、個々のパケットの暗号化に加えて、パケットデータが受信側に届く前に改ざんされるのも防ぐことができる。IPSec はまた、IP アドレス、プロトコル、ポートに基づいて、管理者が通信を調整できるパケットフィルタリング機能も備えている。このフィルタリングでは、未承認のソースから届いたパケットをシステムが破棄することによって、さまざまな DoS 攻撃を防ぐことができる。

IPSec は、現行の IPv4 プロトコルや将来のIPv6プロトコルを使用するシステムに各種のセキュリティサービスを提供するように設計され、IETF (Internet Engineering Task Force) による承認の過程にある一連の標準文書に基づいている。「IP Security Document Roadmap」というタイトルの RFC 2411 には、各文書に定められているプロトコルどうしの関係が説明されている。本書の執筆時点では、IPSec の各種の要素を定義した RFC (Requests for Comments) の大半は、提案 (proposed standard) の段階である。つまり、文書は完成しているが、インターネット標準としてはまだ承認されていない。Windows 2000 に実装されている IPSec はこれらの文書に基づいているが、文書が承認される前に仕様が変わる可能性がある。つまり、Windows 2000 の IPSec サポートを、最終的にこの標準に合わせて修正しなければならなくなるおそれがある。IPSec に関連する RFC は次のとおりである。

• RFC 2411 IP Security Document Roadmap

• RFC 2401 Security Architecture for the Internet Protocol

• RFC 2402 IP Authentication Header

• RFC 2403 The Use of HMAC-MD5-96 within ESP and AH

• RFC 2404 The Use of HMAC-SHA-1-96 within ESP and AH

• RFC 2405 The ESP DES-CBC Cipher Algorithm With Explicit IV

• RFC 2406 IP Encapsulating Security Payload (ESP)

• RFC 2407 The Internet IP Security Domain of Interpretation for ISAKMP

• RFC 2408 Internet Security Association and Key Management Protocol (ISAKMP)

• RFC 2409 The Internet Key Exchange (IKE)

• RFC 2410 The NULL Encryption Algorithm and Its Use With IPSec

• RFC 2412 The OAKLEY Key Determination Protocol

注意 :
ほかの多くのネットワーク標準とは異なり、IETF が公開する RFC はパブリックドメインであり、自由にダウンロードできる。番号やキーワードによって特定の RFC を選択したいときは、http://www.rfc-editor.org/rfcsearch.html (英語) を参照してほしい。

IPSec は、多様なセキュリティをシステムに提供する 2 種類のプロトコルを採用している。IP 認証ヘッダー (AH) と IP カプセル化セキュリティペイロード (ESP) である。ここからは、この 2 つのプロトコルについて説明する。

IP 認証ヘッダー
RFC 2402 で規定されている IP 認証ヘッダー (AH) プロトコルは、控えめなセキュリティを提供するので、オーバーヘッドもそれなりに小さい。AH は、パケット全体 (つまり、IP ヘッダーとそれに続くデータ) に認証サービス、耐再生サービス、完全性サービスを提供するが、データの暗号化は行わない。AH を単独で使用すると、通信システムのオペレータは、データが未改ざんで、相手ユーザーから本当に発信されたものであると確信できるが、メッセージが盗聴されていないという保証はない。

注意 :
後で説明するが、AH は単独で使用することも、ESP プロトコルと組み合わせて使用することもできる。

AH では、標準 IP データグラムに別のヘッダーを追加する。このヘッダーが置かれる場所は、本来の IP ヘッダーの後で、かつ次のヘッダー (TCP や UDP などのトランスポート層プロトコルや ICMP 用のヘッダー) と、そのパケットを作成したアプリケーションが生成するデータの前である (図 11.2 を参照)。

図 11.2: AH ヘッダー付き IP データグラム

パケットにほかの IPSec プロトコル (ESP など) がある場合、そのヘッダーは AH ヘッダーの直後にくる。IP ヘッダーのプロトコルフィールドは、そのパケットにある次のヘッダーを表していなければならない。通常、これは TCP ヘッダーまたは UDP ヘッダーであり、プロトコルフィールドの値はそれぞれ 6 と 17 である。ただし、AH ヘッダーのあるパケットでは、プロトコルフィールドの値は 51 であり、AH ヘッダーの「次ヘッダー」フィールドの値はトランスポート層プロトコルヘッダーを表す。図 11.3 に AH ヘッダーの形式を示す。

図 11.3: AH ヘッダーの形式

これらのフィールドの機能は次のとおりである。

• 次ヘッダー (8 ビット ) - RFC で定められた標準値を使用して、AH ヘッダーの直後にあるヘッダーを表す。システムが AH に加えて ESP プロトコルも使用している場合、値は 50 である。使用していない場合、このフィールドの値は、TCP パケットの場合が 6、UDP パケットの場合が 17 になる。

• ペイロード長 (8 ビット ) - 32 ビットワードから 2 を引いて、AH ヘッダーの長さを指定している。

• 予約済み (16 ビット ) - 将来の使用に備えて予約されている。フィールドには値 0 が入る。

• SPI (32 ビット ) - 宛先 IP アドレスとセキュリティプロトコル (この場合は AH) を組み合わせて、そのデータグラムのセキュリティアソシエーションを表す任意の値が入る。セキュリティアソシエーション (SA) は、伝送する情報の保護に使用するセキュリティ手段に関する、2 台のコンピュータ間の合意である。値 1～255 は将来の使用に備えて予約されている。

• 連番 (32 ビット ) - 1 から始まる値が入っており、特定の SA を使用するパケットごとに増加する。このフィールドはプロトコルの耐再生サービスを提供する。受信側システムは、同一の連番と SA 値を持つパケットを受信したかどうかをチェックし、受信していた場合はそのパケットを破棄する。

• 認証データ ( 可変 ) - 送信側システムが、送信中は値が不変または予測可能な全 IP ヘッダーフィールドについて計算した ICV (Integrity Check Value : 完全性検査値)、認証データフィールド (この目的では値 0 に設定されている) を含む AH ヘッダー全体、および AH フィールドに続く上位レベルのプロトコルヘッダーとデータが入る。受信側システムは、同一の計算を実行した結果を ICV の値と比較し、パケットの完全性を検証する。値の長さは 32 ビットの倍数でなければならない。このフィールドには、32 ビットの長さに調整するためにパディング (すきまを埋めるための詰め物) が含まれることがある。

IP カプセル化セキュ リティペイロード
IP カプセル化セキュリティペイロードプロトコル (ESP) は、IP パケットで運ばれるデータの暗号化に加えて、認証サービス、整合性サービス、耐再生サービスを提供する。IP パケットにヘッダーを追加する AH とは異なり、ESP は実際に自分のプロトコル構造内のデータを暗号化する (図 11.4 を参照)。

図 11.4: ESP ヘッダー付きの IP データグラム

ESP ヘッダーの後から ESP トレーラまで (トレーラ自体を含む) の間にあるすべてのデータは、本来のトランスポート層 (または ICMP) ヘッダーとアプリケーションデータを含めて、不正使用から保護するために暗号化される。完全性署名の計算に使用する情報は、ESP ヘッダーの先頭から ESP トレーラの末尾までである。AH プロトコルとは異なり、ESP では、パケットの本来の IP ヘッダーは署名に含めない。したがって、受信側に気付かれずに第三者がこのヘッダーを改ざんするおそれがある。これを避けるには、AH プロトコルと ESP プロトコルを併用して、最大限の保護を実現する必要がある。

AH プロトコルの場合と同様、IP ヘッダーのプロトコルフィールドはトランスポート層ヘッダーを表しているのではなく、値 50 がある ESP ヘッダーを表している。ESP トレーラの次のヘッダーフィールドは、トランスポート層ヘッダーの適切な値を指定している。図 11.5 に ESP パケットの形式を示す。これには、トランスポート層ヘッダーとアプリケーションデータが含まれる。

図 11.5: ESP パケットの形式

各フィールドの機能は次のとおりである。

• SPI (32 ビット ) - 宛先 IP アドレスとセキュリティプロトコル (この場合は AH) とを組み合わせて、このデータグラムの SA を表す任意の値が入る。値 0～255 は将来の使用に備えて予約されている。

• 連番 (32 ビット ) - 1 から始まる値が入り、特定の SA を使用するパケットごとに増加する。このフィールドはプロトコルの耐再生サービスを提供する。受信側のシステムは、同一の連番と SA 値を持つパケットを受信したかどうかをチェックし、受信していた場合はそのパケットを破棄する。

• ペイロードデータ ( 可変 ) - ESP が適用される前のパケットの本来のトランスポート層 (または ICMP) ヘッダーに加えて、アプリケーションデータが入る。

• パディング (0 ～ 255 バイト ) - 一定の長さのデータブロックしか処理できない一部の暗号化アルゴリズムの要件を満たし、パディング長フィールドとそれに続く次のヘッダーフィールドを 32 ビットのワード内で右詰めにするためのパディング。このパディングによって、認証データフィールドを 32 ビットの先頭から始めることができる。

• パディング長 ( 8 ビット ) - このフィールドの直前にあるパディングのバイト数。

• 次ヘッダー (8 ビット ) - RFC で定められた標準値を使用して、ESP ヘッダーの直後にあるヘッダーを表す。フィールドの値は、TCP パケットの場合が 6、UDP パケットの場合が 17 である。

• 認証データ ( 可変 ) - ESP ヘッダーの先頭から ESP トレーラの末尾まで (本来の IP ヘッダーと ESP 認証データフィールド自体を除く) の全フィールドを対象にして、送信側システムが計算した ICV が入っているオプションフィールドである。受信側システムは、同一の計算を実行した結果を ICV の値と比較し、パケットの整合性を検証する。このフィールドは 32 ビット境界から始まっていなければならない。

トランスポートモードとトンネルモード
AH と ESP の節で説明したパケットの形式はどちらも、トランスポートモードで実行されたプロトコルを定義している。トランスポートモードは、同一 LAN 上にあるかプライベート WAN リンクで接続されたシステム間で、クライアント対クライアントのセキュリティに使用する。トランスポートモードでは、エンドシステムの両方が IPSec をサポートしていなければならないが、中間システムはパケットを通常どおり転送するだけなので、IPSec をサポートしている必要はない。

トンネルモードは、最大限のセキュリティが必要なインターネット経由の仮想プライベートネットワークに使用するリンクなど、ゲートウェイ間のリンクを目的としている。トンネルモードでは、送信側システムは、まったく新しい IP ヘッダーを作成して、IP データグラム全体をカプセル化する。ESP プロトコルは、本来の IP ヘッダーを含めてデータグラム全体を暗号化し、AH プロトコルは、本来の IP ヘッダーと新しい IP ヘッダーの両方を含めて、パケット全体を対象にして署名を作成する。結果的に、このカプセル化と暗号化のプロセスでは、インターネットのように本質的に安全とはいえないネットワークの中に、安全なトンネルが形成される。図 11.6 に、トンネルモードでの ESP と AH のパケットの形式を示す。

図 11.6: トンネルモードでの ESP と AH のパケット形式

トンネルモードでは、IPSec をサポートしていなければならないのは、セキュリティサービスを提供する双方のゲートウェイのみである。トンネルがインターネットを通じて 2 つのネットワークを結んでいる場合、パケットの最終的な発信元システムと宛先システムは、IPSec をサポートしている必要はない。実際には、TCP/IP が実行されている必要さえない。メッセージを発信する側のシステムは、ローカルネットワーク上のゲートウェイにパケットを送信し、このゲートウェイが IPSec セキュリティによってパケットを IP データグラムにカプセル化してから、インターネットを通じて別のネットワークにあるゲートウェイに送信する (図 11.7 を参照)。リモートゲートウェイは、そのパケットを受信して、データを復号化し、必要に応じて整合性チェックをしてから、通常の IP データグラムまたはそのほかのネットワーク層プロトコルを使用して、そのデータを宛先システムに送信する。

図 11.7: 仮想プライベートネットワーク接続には IPSec トンネル機能を使用できる

L2TP トンネル機能
図 11.7 に示すようなトンネルを作成するには、IPSec 自体をトンネルプロトコルとして使用するか、あるいは L2TP (Layer 2 Tunneling Protocol) でトンネルを作成し、IPSec でデータを暗号化することでを実現する。L2TP は、IETF が RFC 2661 で規定したプロトコルで、PPTP (Point-To-Point Tunneling Protocol) と Cisco Systems の L2F (Layer 2 Forwarding) を組み合わせたものである。L2TP は、ダイヤルアップネットワークや WAN 接続で使用するフレームなど、PPP (Point-To-Point Protocol) フレームを UDP データグラムにカプセル化するように設計されている (図 11.8 を参照)。UDP は、コネクションレスサービスを提供する TCP/IP トランスポート層プロトコルである。トンネルを通じて送信されるオリジナルデータは、トランスポート層で TCP とUDPのどちらを使用していてもかまわない。各データグラムは、もう 1 つ別の UDP データグラムにパッケージ化されてから送信される。

図 11.8: L2TP パケットの形式

L2TP は、それ自体には暗号化サービスがないので、IPSec の ESP プロトコルを使用して UDP データグラム全体の暗号化と認証を行い、第三者がデータグラムを損傷するのを防ぐ。暗号化なしの L2TP トンネルも作成できるが、データが保護されないので、技術的には VPN 接続ではない。

L2TP を使用するには、IP インターネットワークで接続された L2TP サーバーと L2TP クライアントが必要である。この接続は、トンネルを作成するときに既に存在していてもかまわないが、そうでない場合は、クライアントがネットアークアクセスサーバー (NAS) へのダイヤルアップを開始しなければならない。通信プロセスは、通常どおりに PPP フレームの作成で始まる。PPP フレームには、IP、IPX、NetBEUI のフレームデータを入れることができる。この PPP フレームは次に L2TP ドライバに渡され、このドライバが、パケットの送信先トンネルを表す値が入った L2TP ヘッダーを追加する。その後、L2TP ドライバはこのフレームを TCP/IP プロトコルドライバに渡し、このドライバがL2TPフレームを UDP データグラムにカプセル化し、その後で正しい IPSec ポリシーが適用される。IPSec はこの UDP データグラムを暗号化し、認証署名を計算して、適切な ESP ヘッダーフィールドとトレーラフィールドを追加する。最後に、PPP フレーム、L2TP フレーム、UDP データグラム、ESP フレーム、IP フレームの順で内側から入れ子になったパケット構造全体が、PPP フレーム内に再びカプセル化され、WAN ミニポートドライバに渡されて転送される。

Windows 2000 に実装された IPSec は、管理コンポーネントとランタイムコンポーネントという2つの要素で構成されている。管理コンポーネントは次のとおりである。

• IPSec ポリシー - このポリシーには、IPSec が提供するさまざまなセキュリティサービスの構成データが格納される。管理者は、許可すべき通信の種類とその通信を保護する方法をポリシーとして定義し、このポリシーをユーザー、グループ、またはそのほかの Active Directory ディレクトリサービス構造オブジェクトに関連付けることで、IPSec セキュリティを実現できる。

• IP セキュリティポリシーの管理 - これは MMC 用のスナップインで、IPSec ポリシーの作成と管理に使用する。

  ランタイムコンポーネント (つまり、IPSec システム上で、セキュリティで保護された通信に関与する要素) は、次のとおりである。

• IPSec Policy Agent サービス - このサービスは、IPSec をサポートする各システムで動作して、Active Directory またはローカルシステムレジストリに格納された IPSec ポリシーにアクセスし、その情報を IPSec ドライバに転送する。

• IKE (Internet Key Exchange) - IKE は、SA を作成し、2 つのシステム間でキーを交換するためのプロトコルである。RFC 2409 は、IKE の 2 段階のプロセスを定義している。最初の段階では、フェーズ 1 SA (Security Association) を確立する。フェーズ 1 SA は、双方のシステム間の安全な認証済み通信チャネルである。フェーズ 1 SA の確立では、暗号化アルゴリズム、ハッシュ化アルゴリズム、システムが使用する認証手段のネゴシエーションに続いて、認証プロセス自体が行われる。第 2 段階では、IPSec サービス用の 2 つのフェーズ 2 SA (着信用と発信用が 1 つずつ) の確立と、IPSec プロトコル (AH や ESP)、ハッシュアルゴリズム (MD5 または SHA1)、暗号化アルゴリズム (DES または 3DES)、認証用/暗号化キー用の材料の交換または更新のネゴシエーションを行う。

• IPSec ドライバ - このドライバは、その時点でアクティブで、ネットワーク上の通信を監視している IPSec ポリシーから IP フィルタ一覧を受け取る。フィルタ一覧内のエントリと一致する発信パケットを検出すると、このドライバは、宛先システムとのキー交換プロセスを開始するように IKE に指示する。相手システムとの SA が確立されると、ドライバは適切な値を IPSec プロトコルヘッダーフィールドに挿入して、必要な暗号化作業を行う。着信パケットの場合、ドライバは、送信側システムが実行した計算を繰り返し、必要に応じてパケットデータを復号化することで、署名を検査する。

したがって、IPSec ポリシーが施行された場合、典型的な通信の交換は次のように進行する。

1. ワークステーション A のユーザーが、あるアプリケーションで作業している。このアプリケーションが、ワークステーション B の特定ユーザーに送信するメッセージを生成する。

2. ワークステーション A の IPSec ドライバが、メッセージの宛先 IP アドレスまたはプロトコルを、その時点でアクティブな IPSec ポリシーの IP フィルタ一覧と比較する。

3. システム間の通信を保護するよう IPSec ポリシーで指定されている場合、IPSec ドライバは IKE に対して、ワークステーション B とネゴシエートするように指示する。

4. ワークステーション B の IKE が、保護されたネゴシエーションを要求しているワークステーション A の IKE からメッセージを受信する。

5. 双方のシステムが、1 つのフェーズ 1 SA と 2 つのフェーズ 2 SA (発信用と着信用が 1 つずつ) をネゴシエートする。

6. 発信フェーズ 2 SA 用に合意されたパラメータを使用して、ワークステーション A の IPSec ドライバが発信データ用の整合性署名を計算し、データを暗号化してから、IP データグラムに適切なヘッダーフィールドを追加して、IPSec パケットを構築する。

7. ワークステーション A は完成したパケットをワークステーション B に送信し、ワークステーション B はそのパケットを自分の IPSec ドライバに渡す。

8. 着信 SA のパラメータを使用して、ワークステーション B の IPSec ドライバがデータを復号化し、署名を再計算して、結果をパケット内の結果と比較することで、パケットの整合性を検証する。

9. ワークステーション B の IPSec ドライバが、復号化後のデータを TCP/IP スタックに渡し、このスタックがそのデータをメッセージの本来の宛先であるアプリケーションに渡す。

ネットワークに IPSec を配備する際の最初の手順は、保護すべき通信を判断することである。IPSec によって通信を保護すると、当然ながらネットワークの負荷がある程度増加する。暗号化の処理と完全性の計算によって、送信側と受信側の双方のシステムでプロセッサ負荷が増加する。さらに、各パケットに IKE ネゴシエーションと IPSec プロトコルヘッダーが追加されるため、ネットワークトラフィックも増加する。IPSec がもたらすあらゆるセキュリティをネットワーク通信に最大限に活用することもできるが、そうすると、システムやネットワークに加わる負荷のため、はっきりとわかるほどパフォーマンスが低下するおそれがある。

最善の対策は、ほとんどの場合、保護したいコンピュータまたはネットワークを選択することである。IPSec セキュリティポリシーは、IP アドレスを使用したフィルタに基づいて、どのパケットを保護すべきか判断する。たとえば、極秘情報を格納するデータベースサーバーがある場合は、IP アドレスをすべて指定したフィルタを作成して、あらゆるクライアント通信に IPSec セキュリティが適用されるよう構成できる。同様に、システムが特定のシステムやネットワークと通信する場合にのみ、IPSec セキュリティの使用を要求するフィルタを作成することもできる。また、IPSec セキュリティを任意と必須のどちらにするかをポリシーで指定することもできる。なお、IPSec をサポートする Windows バージョンは、現時点では Windows 2000 のみである。ネットワークに Windows 95/98、または NT のシステムがある場合、または UNIX や Macintosh などのそのほかのコンピューティングプラットフォームを使用している場合、IPSec 通信は不可能である。さらに、どれだけのセキュリティを提供したいかも判断しなければならない。ネットワーク通信の整合性だけを確保できればよい場合もあれば、暗号化も必要な場合もある。

考慮すべき最も重要な要因は、DHCP、DNS、WINS などの重要なネットワークサービスを運用しているシステムで使用するセキュリティポリシーである。IPSec をサポートしていないワークステーションがネットワークにある場合は、これらのワークステーションがこのサービスにアクセスすることができないので、あらゆる通信を保護する [セキュリティで保護されたサーバー] などのポリシーを使用することはできない。

[IP セキュリティポリシーの管理 ] の実行
Windows 2000 システムに IPSec を配備するときは、Microsoft 管理コンソール (MMC) の [IP セキュリティポリシー] スナップインを使用して、ポリシーを作成する。Windows 2000 のデフォルトでは、[ローカルセキュリティ設定] コンソールに [ローカルコンピュータの IP セキュリティポリシー] がある。[ローカルセキュリティ設定] コンソールは、[スタート] メニューの [管理ツール] プログラムグループから [ローカルセキュリティポリシー] を選択すると呼び出せる。また、mmc.exe を実行して、[IP セキュリティポリシーの管理] スナップインを追加すると、コンソールを手動で開くことができる。スコープペインで [ローカルコンピュータの IP セキュリティポリシー] (図 11.9 の左側) を選択すると、デフォルトでは、システム上に作成された 3 つのポリシーが表示される。

図 11.9: IP セキュリティポリシーコンソール

この 3 つのデフォルトポリシーは次のとおりである。

• [ クライアント ( 応答のみ )] - このポリシーでは、別のシステムから要求された場合に限って IPSec セキュリティを使用する。このシステムがセキュリティを必要とすることはなく、別のシステムの要求に応える場合に限ってネゴシエーションを開始する。このポリシーは、機密情報があるサーバーに接続するときなど、別のシステムが必要としているときに限ってセキュリティを強化したいクライアントシステムを対象にしている。

• [ セキュリティで保護されたサーバー ( セキュリティが必要 )] - このポリシーでは、あらゆる通信に IPSec セキュリティを必要とする。IPSec をサポートしていないシステムとの接続はすべて拒否する。このポリシーは、高度な機密情報が入ったサーバーや、VPN 接続の確立に使用するゲートウェイシステムを対象としている。

• [ サーバー ( セキュリティが必要 )] - このポリシーでは、ほかのすべてのシステムに IPSec セキュリティの使用を要求する (ただし、必須ではない)。このポリシーの典型的な用途は、可能な場合は必ず IPSec を使用したいが、Windows 2000 が動作していない (つまり、IPSec 機能を備えていない) クライアントにもサービスを提供しなければならないサーバーである。

結果ペイン (図 11.9 の右側) に表示されるポリシーは、デフォルトではどれも割り当てられていない (非アクティブになっている)。ポリシーを強調表示してからツールバーの [割り当て] ボタンをクリックするか、[操作] メニューから [割り当て] を選択すると、アクティブにできる。

IPSec を使用するようにシステムを構成するときは、デフォルトのポリシーをそのままアクティブにすることも、プロパティを修正することも、独自のポリシーを新規作成することもできる。[操作] メニューから [IP セキュリティポリシーの作成] を選択するとウィザードが起動し、ポリシーを一から構成できる。ポリシーの要素の多くは、ポリシーのプロパティの修正を支援するウィザードにリンクされている。

IPSec ポリシーは、規則、IP フィルタ一覧、フィルタ操作という 3 つの基本要素で構成されている。規則は、IP フィルタ一覧と、セキュリティを使用する時期と方法を定めたフィルタ操作を組み合わせたものである。フィルタ一覧は、規則の適用先のシステムを識別する IP アドレス、プロトコル、ポートの集まりである。フィルタ操作では、規則を適用するときに課すセキュリティの種類を定めている。たとえば、[サーバー (セキュリティが必要)] ポリシーには、図 11.10 のような規則が収められている。

図 11.10: [サーバー (セキュリティが必要) のプロパティ] ダイアログボックス

最初のフィルタ一覧では、すべての IP トラフィックにこの規則を課すように指定し、この規則のフィルタ操作では、システムに IPSec セキュリティの使用を要求する (ただし、必須ではない)。フィルタ一覧を修正すると、特定の IP アドレスのみに規則を適用できる。また、フィルタ操作を修正すると、セキュリティを要求するのではなく、強制することもできる。さらに、ほかのパラメータを構成すると、規則によって呼び出すセキュリティ手段を修正できる。ここからは、これらのさまざまな要素の作成方法と修正方法を取り上げる。

ポリシーの作成
ポリシーを新規作成することにした場合は、IP セキュリティポリシーウィザードが、ポリシーの名前と説明を入力するように指示し、デフォルトの応答規則をアクティブにしたいかどうかをたずねる。このデフォルト規則では、セキュリティを要求するコンピュータにシステムが応答する。その後、ポリシーに使用させたい認証手段を指定する (図 11.11 を参照)。

図 11.11: [既定の応答規則の認証方法] ダイアログボックス

デフォルトでは、Windows 2000 IPSec ポリシーは認証に Kerberos V5 を使用するが、証明機関から取得した証明書を使用することも、セキュリティネゴシエーションに関与する双方のシステムが事前に共有するキーとしての英数字文字列を使用することもできる。事前に共有するキーを使用するには、通信の対象となるすべてのコンピュータに同じキーを使用しなければならない。この方法は、Windows 2000 が動作していないシステム、つまり Kerberos プロトコルをサポートしていないシステムとネゴシエートする際に使う。認証手段を選択したら、コンソールによって新しいポリシーが作成され、規則、フィルタ一覧、フィルタ操作での構成に進めるようになる。

規則の 作成
ポリシーの [プロパティ] ダイアログボックスの [規則] タブにある [追加] ボタンをクリックすると、デフォルトではセキュリティの規則ウィザードが起動する ([追加ウィザードを使用] チェックボックスのチェックマークを外してウィザードを迂回し、規則を直接作成することもできる)。ウィザードではまず、[トンネルエンドポイント] ダイアログボックス (図 11.12 を参照) が表示される。このダイアログボックスでは、トンネルのエンドポイントとして機能するシステムにこの規則を適用するかどうかを指定できる。適用する場合は、トンネルへの接続として機能するネットワークインターフェイスの IP アドレスを指定しなければならない。

次に、システムの全ネットワーク接続、LAN 接続のみ、リモートアクセス接続のみのどれにこの規則を適用するかを指定する。また、図 11.11 に示したダイアログボックスで、この規則の認証手段も選択しなければならない。規則作成プロセスの最後の 2 つの手順は、IP フィルタ一覧の選択または作成と、フィルタ操作の選択である。どちらの場合も、用意されたデフォルトオプションの1つを使用することも、会社の仕様に合わせてオプションを修正することも、独自の一覧と操作を作成することもできる。

図 11.12: [トンネルエンドポイント] ダイアログボックス

フィルタ一覧とフィルタ操作の作成は、規則作成プロセスの一部にすることも、規則を作成した後で各手順を別々に実行することもできる。以降の節では、これらの手順を詳細に説明する。

ポリシーには必要に応じていくつでも規則を作成できる。また、ポリシーの規則一覧にあるチェックボックスを使用すれば、必要に応じてアクティブまたは非アクティブにできる。複数の規則を同時にアクティブにできるので、各種の通信に合わせてさまざまなセキュリティシナリオを定義できる。

フィルタ一覧の作成
ポリシー内の各規則には、図 11.13 に示すような専用の規則の編集プロパティダイアログボックスがある。このダイアログボックスを使用すると、規則を適用する際のパラメータを構成できる。フィルタ一覧では、この規則によって保護する通信を定義する。ダイアログボックスの [IP フィルタ一覧] タブには、[すべての IP トラフィック] と [すべての ICMP トラフィック] という 2 つのデフォルトフィルタがある。システムのすべてのIPトラフィックまたは ICMP トラフィックにこの規則を適用したいのでない限り、新しいフィルタ一覧を作成 (または既存のフィルタ一覧を修正) した方がよい。

注意 :
フィルタ一覧は、使用する規則とは別に保持する。規則のフィルタ一覧を新規作成するか、既存のフィルタ一覧を修正すると、その一覧はシステム上のほかの全規則で利用可能になる。そのため、既存のフィルタ一覧を変更すると、そのフィルタ一覧を使用する全規則に影響する。フィルタ一覧のデフォルトパラメータを修正するときは、この点に注意すること。

図 11.13: [新しい規則のプロパティ] ダイアログボックス

[追加] ボタンをクリックするか、既存のフィルタ一覧を編集すると、[IP フィルタ一覧] ダイアログボックスが表示される (図 11.14 を参照)。このダイアログボックスには、フィルタ一覧の全プロパティがまとめられている。保護したい通信の種類を選択するときは、[追加ウィザードを使用] チェックボックスにチェックマークを付けたかどうかに応じて、[新しい IP フィルタウィザード] ダイアログボックスまたは [フィルタのプロパティ] ダイアログボックスを使用して、[フィルタ] ボックスにエントリを追加する。

図 11.14: [IP フィルタ一覧] ダイアログボックス

新しい IP フィルタウィザードでは、ミラー化フィルタが自動的に作成される。ミラー化フィルタとは、どちら向きのトラフィックにも適用されるフィルタである。各方向のトラフィックごとに別々の規則を作成したい場合は、ウィザードを使用してフィルタを作成してからミラー化機能を削除することも、ミラー化機能なしでフィルタを手動で作成することもできる。保護したいシステムの IP アドレスと、保護したいトラフィックを生成するプロトコルを指定するように、ウィザードから指示される。ウィザードを使うと簡単にエントリを作成できるが、柔軟に設定をすることはできない。

ウィザードなしでフィルタを作成するときは、図 11.15 のような [フィルタのプロパティ] ダイアログボックスが表示される。

図 11.15: [フィルタのプロパティ] ダイアログボックス

[アドレスの指定] タブにある [ミラー化] チェックボックスでは、フィルタを対称的に機能させるかどうかを指定できる。送信側と受信側のシステム用に次のパラメータのいずれかを指定して、保護したい通信に関与するシステムを識別する。

• [ このコンピュータの IP アドレス ] - システムの現在の IP アドレスを表す。このシステムに対するあらゆるトラフィックを保護できる。

• [ 任意の IP アドレス ] - 有効な任意の IP アドレスを表す。任意のアドレスに対するトラフィックを保護できる。

• [ 特定の DNS 名 ] - DNS サーバーの名前を指定できる。このサーバーに対するあらゆるトラフィックを保護できる。

• [ 特定の IP アドレス ] - 特定の IP アドレスを指定できる。このアドレスに対するあらゆるトラフィックを保護できる。

• [ 特定の IP サブネット ] - 特定のネットワークアドレスを指定できる。このネットワークに対するあらゆるトラフィックを保護できる。

[フィルタのプロパティ] ダイアログボックスの [プロトコル] タブでは、保護したいトラフィックの種類を指定する。デフォルトでは、このフィルタによってあらゆるトラフィックが保護されるが、特定のプロトコルを選択すると、セキュリティを特定アプリケーションに制限できる。[TCP] プロトコルまたは [UDP] プロトコルを選択すると、保護するポート番号も指定できる。たとえば、インターネットメールを保護したい場合は、TCP プロトコルとポート番号 25 を選択する。これは、インターネット電子メールクライアントで使用する SMTP (Simple Mail Transport Protocol) として一般的なポート番号である。[説明] タブでは、このフィルタの説明を指定できる。

フィルタを作成すると、指定したプロパティの要約が [IP フィルタ一覧] ダイアログボックスに表示される。1 つの一覧に複数のフィルタを作成できる。規則でフィルタ一覧を使用すると、そのフィルタ一覧の各フィルタが適用される。

ヒント :
TCP/IP システムには必ず、一般的なポートとそれらがサポートするプロトコルの一覧が、Services というテキストファイルに保管されている。Windows 2000 システムでは、C:\WINNT\system32\drivers\etc ディレクトリがこのファイルのデフォルトの場所である。

フィルタ操作の作成
フィルタ一覧を作成したら、フィルタ操作を作成する必要がある。フィルタ操作は、一覧に一致するトラフィックへ適用するセキュリティの種類を指定する。フィルタ操作の場合も、ウィザードを使用して作成することも、手動で作成することもできる。規則の編集プロパティダイアログボックスの [フィルタ操作] タブには、デフォルトでは、作成済みの 3 つのフィルタ操作が示される。

• [ 許可 ] - 何のセキュリティも要求せずに、フィルタ一覧で指定されたトラフィックを流すことができる。

• [ セキュリティを要求 ( 省略可能 )] - フィルタ一覧で指定されたトラフィックにセキュリティを要求するが、クライアントが IPSec をサポートしていない場合でもトラフィックを流すことができる。

• [ セキュリティが 必要 ] - フィルタ一覧で指定されたトラフィックについてはセキュリティが必須になるので、信頼関係のないクライアントとの通信は拒否される。

フィルタ操作ウィザードの使い方
フィルタ操作は手動で作成することもできるが、IP セキュリティのフィルタ操作ウィザードでは、作成プロセスを容易にするために追加のガイドと説明が表示される。このウィザードではまず、新しいフィルタ操作の名前と説明を入力するように指示される。次に、次の3つのオプションの中からフィルタ操作の全般的な動作を選択する。

• [ 許 可 ] - IP フィルタ一覧で指定されたシステム間の通信を、どのような IPSec セキュリティやネゴシエーションもなしに行うことができる。

• [ ブロック ] - IP フィルタ一覧で指定されたシステム間で行われるすべてのセキュリティネゴシエーションとすべての通信が禁止される。

• [ セキュリティのネゴシエート ] - IP フィルタ一覧で指定されたシステムがセキュリティパラメータの一般的なセットを折衝できる。

ウィザードは次に、この規則によって、IPSec をサポートしているシステムとの通信のみを許可するか、IPSec のないシステムとの非保護通信も許可するかをたずねる。Windows 2000 が実行されていないシステムがネットワーク上にあり、保護されたリソースにそのシステムからアクセスしなければならない場合は、後者のオプションを選択する。次に、セキュリティメソッドを選択するように指示される。ESP プロトコルを使用する [高] セキュリティと、AH を使用する [中] セキュリティがある。また、[カスタム] を選択すると、一方または両方のプロトコルを選択し、パケット整合性署名の計算とデータの暗号化に使用するアルゴリズムを指定できる。

手動でのフィルタ操作の作成
ウィザードを使用せずにフィルタ操作を作成するときは、規則の編集プロパティダイアログボックスの [フィルタ操作] タブにある [追加ウィザードを使用] チェックボックスのチェックマークを外して、[追加] ボタンをクリックし、[新しいフィルタ操作のプロパティ] ダイアログボックスを表示する (図 11.16 を参照)。[セキュリティメソッド] タブでは、フィルタ操作の全般動作のときに示したものと同じ 3 つのオプション ([許可]、[ブロック]、[セキュリティのネゴシエート]) の 1 つを選択できる。

図 11.16: [新しいフィルタ操作のプロパティ] ダイアログボックス

[セキュリティのネゴシエート] を選択すると、このフィルタ操作のセキュリティメソッドを複数作成できる。これらのセキュリティメソッドは、システムが IKE ネゴシエーションプロセス中に相手のコンピュータに提案するプロトコルとアルゴリズムを組み合わせたものである。双方のシステムがいずれかのメソッドに合意するまで、ここに表示されているとおりの優先順位で提案がなされる。作成可能なセキュリティメソッドの数は、ネットワーク上で使用している各種の IPSec 実装と、データに必要と考えるセキュリティの程度によって異なる。

セキュリティメソッドを作成するときは、ウィザードで AH プロトコルまたは ESP プロトコルを選択することも、[カスタムセキュリティメソッドの設定] ダイアログボックス (図 11.17 を参照) を使用して独自のカスタム手段を選択することもできる。このダイアログボックスでは、一方または両方のプロトコルを選択できる。また、システムに使用させる整合性アルゴリズム (MD5 または SHA1) と暗号化アルゴリズム (DES または 3DES) も指定する。さらに、送信されたキロバイト数または経過時間に基づいて、通信システムが新しいキーを作成する頻度も指定できる。

図 11.17: [カスタムセキュリティメソッドの設定] ダイアログボックス

[新しいフィルタ操作のプロパティ] ダイアログボックスの [セキュリティメソッド] タブの下部にある2つのチェックボックスでは、送信/応答にだけ IPSec を適用したり、保護されない通信を許可したりできる。3 つ目のチェックボックスである [セッションキーの PFS (Perfect Forward Secrecy)] では、有効期限の経過後にシステムがシークレットキーを再利用するのを禁止する。この方法でフィルタ操作を作成すると、ウィザードではできないようなさまざまなアルゴリズムを持つ複数のセキュリティメソッドを作成できる。

システムの規則、フィルタ一覧、フィルタ操作の作成と構成が終わったら、いよいよアクティブにする。ポリシーの [プロパティ] ダイアログボックスの規則一覧にあるチェックボックスを操作して、使用予定の各規則に適切なフィルタ一覧を関連付け、各ポリシーに使用したい規則をアクティブにする。最後に、MMCツールバーの [割り当て] ボタンまたは [操作] メニューの [割り当て] を使用して割り当てることで、ポリシーをアクティブにする。

 

DHCP (動的ホスト構成プロトコル) は、ネットワーク上のワークステーションに自動的に TCP/IP 構成設定を提供する重要なサービスである。DHCP がなければ、管理者は、ネットワーク上の各コンピュータに IP アドレスを手動で割り当てるために、実際に各コンピュータまで出向いて TCP/IP クライアントを構成しなければならない。ワークステーションは、起動すると、ローカルネットワーク上の DHCP サーバーを検索するために、ブロードキャストメッセージを送信する。サーバーは、IP アドレス群とその他の構成データを (DHCP オプションの形で) ワークステーションに提供することで、そのブロードキャストメッセージに応答する。ワークステーションは、提供されたアドレスの 1 つを選択して残りを拒否し、自らを構成した後、事前に決定されたリース期間が経過するか、更新されるまでの間、DHCP サーバーが割り当てたパラメータを使用する。

DHCP は、IETF が承認したインターネットの標準であり、どのような種類の TCP/IP ネットワークにも使用できる。Windows 2000 Server 製品は、Windows のみでなく、多種多様なコンピューティングプラットフォームで実行された TCP/IP クライアントもサポートできる DHCP サーバーアプリケーションを備えている。同様に、そのほかの DHCP サーバー製品も、各種のクライアントプラットフォームをサポートできる。ただし、Windows 2000 の DHCP サーバーは、企業ネットワークでの使用に最適なセキュリティ機能を備えている。

Windows 2000 は IPSec セキュリティプロトコルをサポートしているので、Windows 2000 の DHCP サーバーを使用すると、あらゆる通信の保護が必要なクライアントシステムにサービスを提供できる。ただし、前述のとおり、DHCP サーバープログラムが実行されたシステムで IPSec ポリシーを構成するときは、ネットワーク上のワークステーションの種類に注意する必要がある。すべてのワークステーションで Windows 2000 が動作している場合は、あらゆる通信が保護されるようにサーバーを構成してもかまわない。一方、IPSec をサポートしていないほかのバージョンの Windows やほかのオペレーティングシステムが動作するクライアントに対して、DHCP サーバーがサービスを提供しなければならない場合は、可能な場合のみ IPSec を使用するようにサーバーを構成できるが、未保護通信に対してもシステムをオープンにせざるを得ない。そうしないと、IPSec に対応していないワークステーションがサーバーから TCP/IP 構成パラメータを受け取ることができない。

DHCP は主として、大規模な TCP/IP ネットワークをサポートするように設計されている。このようなネットワークは、TCP/IP クライアントを手動で構成するのに非常に苦労する環境だからである。フォールトトレランスと負荷分散を実現するために、企業ネットワークには複数の DHCP サーバーがある場合が多い。DHCP に関係するもう 1 つのセキュリティ関連の問題は、不正な DHCP サーバーがネットワークに紛れ込むおそれがあることである。不正な DHCP サーバーとは、DHCP サーバーソフトウェアが実行された未承認のシステムのことで、不正な IP アドレスでクライアントを構成したり、ネットワーク上の承認サーバーによるリースの更新を妨げたりするおそれがある。クライアントが不正な IP アドレスで構成されていると、ネットワークへのログオンに必要なドメインコントローラを見つけられない場合がある。また、リースの更新を拒否されたクライアントが、新しいアドレスを適切なタイミングで取得できない場合もある。不正サーバーの存在は悪意による場合もあれば、誰かが機能を理解しないままこのソフトウェアをインストールしただけの場合もある。

Windows 2000 では、不正 DHCP サーバーがネットワークに悪影響を与えないようにする機能がActive Directoryに用意されている。この機能は、DHCP Server という Active Directory オブジェクトである。ネットワーク上で DHCP サービスの実行を承認されたシステムを表す IP アドレスの一覧を、属性の 1 つとして保持する。この承認によって、不正サーバーが DHCP サービスを提供できないようにする。

注意 :
DHCP サーバーの承認プロセスでは Active Directory が機能している必要があるため、ネットワーク上の最初の DHCP サーバーは、ワークグループサーバーではなく、ドメインコントローラまたはメンバサーバーとして導入しなければならない。この最初のサーバーを導入すると、DHCP Server オブジェクトが作成され、ほかのサーバーを承認できるようになる。このように Active Directory に依存しているということは、DHCP サーバーの承認が Windows 2000 の DHCP サーバーにしか適用されないということでもある。DHCP サーバーが Windows NT などのプラットフォームで実行されている場合は、承認も検出もできない。

DHCP サーバーの承認
承認プロセスは、Windows 2000 サーバーに DHCP サービスが読み込まれようとしたときに始まる。このサービスは、DHCP Inform という種類のメッセージを使用してパケットを生成し、ブロードキャストとしてローカルネットワークに送信する。このメッセージは、ネットワーク上のほかの DHCP サーバーを見つけるためのものであり、ベンダ固有の特殊な DHCP オプションが入っている。DHCP Inform メッセージは、これらのオプションによって、ディレクトリサービスのエンタープライズルートに関する情報のクエリとして機能する。ほかの DHCP サーバーは、この DHCP Inform メッセージを受信すると、ディレクトリサービスのエンタープライズルートに関して要求された情報が入った DHCP Ack メッセージで応答する。

ほかの DHCP サーバーが応答しなかった場合は、この新しいサーバーが初期化を許されて、DHCP サービスの提供を開始する。ただし、このサーバーは、ネットワーク上にほかの DHCP サーバーがないかどうかを判断するために、5分おきに DHCP Inform メッセージの送信を続ける。ほかのサーバーが応答した場合、この新しいサーバーは、承認サーバーの一覧に自分の IP アドレスが含まれているかどうかを判断するために、応答から得られた情報を使用してディレクトリサービスに照会する。承認されている場合、サーバーは初期化プロセスを完了して、DHCP サービスの提供を開始する。サーバーが承認されていない場合、DHCP サービスは終了する。

DHCP サーバーの承認方法
ドメインコントローラに DHCP をインストールした場合は、DHCP コンソールのサーバーの一覧に追加した時点で、そのシステムは自動的に承認される。この場合、そのサーバーは、承認された DHCP サーバーの一覧に表示される (図 11.18 を参照)。

図 11.18: [承認されたサーバーの管理] ダイアログボックス

ただし、ドメインコントローラ以外のシステムに DHCP をインストールした場合は、まず一覧に追加しなければならない。

承認された DHCP サーバーの一覧に DHCP を追加する方法

1. [DHCP] コンソールを開いて、スコープペインのツリーのルート表示で [DHCP] を強調表示し、[操作] メニューから [承認されたサーバーの管理] を選択する。

2. [承認されたサーバーの管理] ダイアログボックスで [承認] ボタンをクリックする。

3. [DHCP サーバーの承認] ダイアログボックスで、承認したいサーバーの名前または IP アドレスを指定する。

4. [OK] をクリックして、承認された DHCP サーバーの一覧に指定システムを追加する。

 

Windows 2000 では、ドメインネームシステム (DNS) は Windows NT のときよりもはるかに重要である。Active Directory は、名前空間の構造や、ドメインコントローラなどのネットワークシステムに関する情報の保管を DNS に依存している。本来、DNS は、情報の受領ではなく、情報の周知を容易にするように設計されていた。そのため、ネットワーク上のシステムの名前と IP アドレスが入ったリソースレコードを、管理者が手動で作成する必要があった。システム名を IP アドレスに解決する際に、Windows NT が必ず NetBIOS 名とその NetBIOS ネームサーバー (WINS) に依存する理由の 1 つは、新しいシステムの名前とアドレス情報をネームサーバーに自動的に登録できるからである。

ただし IETF は、DNS サーバーに対してリソースレコードを自動的に作成、修正、削除できる機能の必要性を認めて、RFC 2136「Dynamic Updates in the Domain Name System」で標準を開発している。Active Directory を実行する際の必要条件の 1 つが、この動的更新をサポートした DNS サーバーへアクセスできることである。ドメインコントローラは、SVR リソースレコードを作成 (または更新) することで、自らの存在をネームサーバーに登録できる。また、標準ワークステーション用の A と PTR のリソースレコードが常に最新状態になるように、DHCP クライアントとサーバーは、更新内容を DNS サーバーに送信できる。クライアントは、自分の機能に応じて、更新内容を DNS サーバーに直接送信する場合と、DHCP サーバーに送信してもらう場合がある。DHCP アドレスの割り当ては頻繁に変化する可能性があるので、動的更新を利用できなければ、管理者が正しい IP アドレスで DNS 名前空間を更新することは困難かまたは不可能である。

DNS とそのデータは Windows 2000 ネットワークにとって重要なので、動的更新を実行できることはセキュリティ上の問題になる。不正システムに DNS レコードの修正を許すと、ネームサービスの有効性が損なわれるおそれがある。そのため、Windows 2000 の DNS サーバーは、IETF インターネットドラフト文書「GSS Algorithm for TSIG (GSS-TSIG) 」で規定されているとおり、保護された動的更新もサポートしている。保護された動的更新は、DNS レコードに対する変更内容の提出が承認ユーザーにしか認められない点を除いて、動的更新とまったく同様に機能する。

注意 :
インターネットドラフトは、IETF標準承認プロセスが開始されていないテクノロジを規定した草案文書群である。IETF の標準承認プロセスは、文書が RFC として公開されたときに開始される。したがって、ドラフト文書は、インターネット標準として承認される前に変更される可能性がある。

動的 DNS 更新を保護するメカニズムを規定した標準はいくつかある。たとえば、RFC 2137「Secure Domain Name System Dynamic Update」、RFC 2535「Domain Name System Security Extensions」などである。Windows 2000 ではこのどちらも使用しない。代わりに、RFC 2078 に規定された Generic Security Service Application Programming Interface (GSS-API) に依存する。この標準では、セキュリティを実際に提供しているプロトコルとは独立したセキュリティサービスが規定されている。このサービスによって、DNS は、基盤となるセキュリティメカニズムとして Windows 2000 の標準 Kerberos V5 プロトコルを使用できる。

動的更新を保護するために、DNS クライアントとサーバーは、特定のプロトコルと交換キーの使用を折衝するトークンを交換して、セキュリティコンテキストを確立する。セキュリティコンテキストが確立すると、2 つのシステム間で交換されるメッセージには、信憑性を立証するトランザクション署名が収められる。このトークンとトランザクション署名はそれぞれ、TKEY と TSIG という 2 つの特殊なリソースレコードとしてパッケージ化されている。これらのレコードの形式は、さらに 2 つのインターネットドラフト文書「Secret Key Establishment for DNS (TKEY RR) 」と「Secret Key Transaction Signatures for DNS (TSIG) 」に記載されている。TKEY と TSIG はゾーンファイルには表示されず、DNS サーバーによってキャッシュに格納されないので、メタリソースレコードとも呼ばれており、それぞれ、リソースレコードタイプコードが 249 と 250 になっている。

保護された動的更新をサポートするのは、Active Directory に統合された DNS ゾーンのみである。標準プライマリゾーンは動的更新をサポートしているが、保護された動的更新はサポートしない。これは、DNS Zone オブジェクトと DNS Node オブジェクトの ACL によって、これらのオブジェクトに入ったリソースレコードの修正を許されたユーザーとグループが指定されているからである。[DNS] コンソールまたは [Active Directory ユーザーとグループ] コンソールを使用すると、ほかの種類のオブジェクトのアクセス許可を修正する場合と同様にして、これらのオブジェクトのアクセス許可を修正できる。

保護された動的更新を DNS クライアントが実行するプロセスは次のとおりである。

1. 動的更新は、追加、修正、削除するレコードについて権限のあるソースである DNS サーバーに対して実行しなければならない。したがって、クライアントはローカル DNS サーバーにクエリを送信して、自分の名前について権限を持つサーバーを見つけ出す。ローカルサーバーは、そのレコードを含むゾーンの名前と、そのゾーンの権限を持つサーバーの名前を返す。

2. クライアントは、動的更新要求を権限のあるサーバーに送信して、保護されていない更新を実行しようとする。更新対象の名前を含むゾーンが、保護された更新しか受け付けないように構成されている場合、そのサーバーはクライアントの要求を拒否する。

3. 保護されていない動的更新要求に対するサーバーの拒否を受け取った後、クライアントは、TKEY リソースレコードが入ったメッセージを送信することで、保護された動的更新プロセスを開始する。サーバーは、自らの TKEY メッセージによって応答し、この 2 つのシステムが共通のセキュリティメカニズムの使用を折衝できるようにする。双方のシステムで Windows 2000 が実行されている場合は、両方のシステムがセキュリティプロトコルとして Kerberos V5 の使用を提案する。この 2 つのシステムは、Kerberos を使用して、互いの身元を検証するメッセージを交換してから、キーの交換を含むセキュリティコンテキストを確立する。

4. セキュリティコンテキストが確立すると、クライアントは動的更新要求をサーバーに再送信するが、今度の要求メッセージには、セキュリティコンテキストを使用して生成されたキーが入った TSIG リソースレコードが含まれている。サーバーは、この TSIG キーと確立済みのセキュリティコンテキストを使用して、メッセージの送信側の身元を検証する。

5. サーバーは、該当リソースレコードの追加、削除、修正に必要なアクセス許可をクライアントが持っており、動的更新のすべての必要条件が満たされている場合、適切なActive Directoryオブジェクトを修正することで、クライアントから要求された動的更新を実行する。

6. サーバーはメッセージをクライアントに送信し、更新が正常に完了したことを通知する。メッセージには今回も TSIG リソースレコードが含まれている。

デフォルトでは、Active Directory 統合ゾーンはすべて、保護された動的更新しか受け付けないように構成されている。標準プライマリゾーンを作成してから、Active Directory 統合ゾーンに変換することにした場合は、保護された動的更新を受け付けるように手動でゾーンを構成しなければならない。具体的には、構成したいゾーンを [DNS] コンソールで右クリックし、コンテキストメニューから [プロパティ] を選択して、そのゾーンの [プロパティ] ダイアログボックスを開く。図 11.19 のダイアログボックスが表示される。[全般] タブの [動的更新を使用可能にしますか] フィールドを使用すると、ゾーンの動的更新機能を有効または無効にしたり、保護された動的更新しか受け付けないように構成できる。

このダイアログボックスでは、[セキュリティ] タブをクリックして、Windows 2000 の標準的なアクセス許可コントロールを表示することもできる。これらのコントロールでは、DNS Zone オブジェクトのプロパティの修正を許すユーザーやグループを指定できる。デフォルトでは、Authenticated Users グループには [すべての子オブジェクトの作成] アクセス許可が付与されているので、このグループのメンバは動的更新を使用してゾーン内に DNS Node オブジェクトを作成できる。新しいオブジェクトを作成したユーザーはそのオブジェクトの所有者にもなるので、そのオブジェクトに対するフルコントロール権を持つ。また、レコードの [プロパティ] ダイアログボックスの [セキュリティ] をクリックすると、特定のリソースレコードのアクセス許可を修正することもできる。

図 11.19: DNS ゾーンのプロパティダイアログボックス

注意 :
DNS Zone オブジェクトと DNS Nodeオブジェクトには、[DNS] コンソールまたは [Active Directory ユーザーとグループ] コンソールからアクセスできるが、後者の場合は、まず [表示] メニューから [拡張機能] を選択して、[System] コンテナの [Microsoft DNS] に移動する。

デフォルトでは、Windows 2000 システムの DNS クライアントはまず、保護されていない動的更新を実行しようとし、それに失敗すると、保護された動的更新を実行しようとする。UpdateSecurityLevel という新しい値を次のレジストリキーに追加すると、DNS クライアントシステムでこの動作を変更できる。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

UpdateSecurityLevel の有効値は次のとおりである。

• 0 - 保護されていない動的更新をまず実行してから、それが失敗した場合は保護された動的更新を実行しようとする。これはデフォルト値である。

• 16 - 保護されていない動的更新しか使用しない。

• 256 - 保護された動的更新しか使用しない。

ただし、このレジストリ値のデフォルトの動作を変更すべきなのは、DNS の更新プロセスを完全に保護したい場合のみである。保護されていない動的更新のみを使用するように構成した場合、システムは、保護されたゾーンにあるレコードを更新できなくなる。

Windows 2000 の DHCP クライアントは、DHCP サーバーから完全修飾ドメイン名 (FQDN) を受信できる DHCP オプションをサポートしているので、DNS 内のリソースレコードを動的に更新できる。旧バージョンの Windows やほかのオペレーティングシステムの DHCP クライアントはこのオプションをサポートしていないので、自分のレコードを更新することはできない。ただし、代わりに Windows 2000 の DHCP サーバーがリソースレコードを更新できる。この機能は、DHCP サーバーの [プロパティ] ダイアログボックスにある [DNS] タブで制御する (図 11.20 を参照)。

図 11.20: DHCP サーバーのプロパティダイアログボックス

ただし、DHCP サーバーによってダウンレベルのクライアントリソースレコードを動的に更新する場合の問題点は、このサーバーが新たに作成されたオブジェクトの所有者になることである。後で別の DHCP サーバーがそのオブジェクトを更新しなければならくなった場合、そのサーバーはこのオブジェクトを所有していないので、プロセスは失敗する。この問題を回避するときは、この DHCP サーバーを、Active Directory 内の DNS UpdateProxy という特殊なセキュリティグループに追加する。このグループのメンバが作成したオブジェクトはセキュリティを持たないので、承認されたユーザーなら誰でもこのオブジェクトの所有権を得ることができる。DNS UpdateProxy グループは、デフォルトでは Active Directory 内に作成され、[Users] コンテナに配置される。グループのメンバ一覧を呼び出して、Active Directory ツリー表示からオブジェクトを選択することで、DHCP サービスが実行されているシステムを表すコンピュータオブジェクトを通常どおりに追加する。

 

Windows 2000 の分散ファイルシステム (Distributed File System : DFS) は、別のシステムの共有ファイルやディレクトリを組み合わせて、連続した単一の名前空間にできるサーバーツールである。ユーザーは、ネットワーク上のあちこちに存在する共有内のリソースにアクセスする代わりに、DFSが実行されたサーバー上の単一の共有にアクセスできる。DFS サービスは、別のコンピュータにある共有のディレクトリ構造を収めた仮想ルートディレクトリを作成する。この DFS ディレクトリ構造を構成するリソースは、ネットワークへのアクセスが可能であれば、どの Windows コンピュータの NTFS ドライブや FAT ドライブにあってもかまわない。また、NetWare サーバーにあってもかまわない。DFS 構造は、ユーザーには単一の共有に見えるが、実際には複数のシステムにある各共有にアクセスすることになる。

同一の共有リソースが、オリジナルの共有ドライブと DFS 共有の 2 つの場所に表示されることになるので、このようなことをするとセキュリティ上の問題が生じると思う人がいるかもしれない。ところが、Windows 2000 では、基本的には何もせずにこの問題がうまく解決されている。DFS は、別のアクセス制御メカニズムを追加するのではなく、DFS 共有を構成しているオリジナルの共有の ACL に全面的に依存している。そのため、ユーザーが個々の共有内のリソースに対するアクセス許可を持っていれば、DFS 共有を通じてアクセスするためのアクセス許可も持つことになる。

このようになっているのにはいくつか理由がある。個々の共有をさまざまな種類のドライブに配置できることから、さまざまなアクセス制御メカニズムを使用することも理由の 1 つだが、DFS は、利便性を向上させる手段をユーザーに提供することを唯一の目的として設計されているので、DFS 共有に追加された後でも、オリジナルの個々の共有にもこれまでどおりにアクセスできる。DFS が独自のアクセス制御メカニズムを備えていたとしたら、管理者は、共有データへのアクセスを制御するために、別々のアクセス許可セットを 2 か所に用意しなければならなくなったはずである。

 

ここまで、Windows 2000 システムが IPSec を使用して、LAN 上のシステム間で行われる通信と、リモートサイトのシステムとの間で行われる通信の両方のネットワーク通信を保護するしくみを説明してきた。リモートアクセスクライアントは、サーバーにダイヤルインして、LAN に物理的に接続されている場合と同様にネットワークリソースで作業し、電話回線を通じて送られるデータを暗号化して、未承認ユーザーに漏洩しないようにできる。ただし、このリモートアクセス暗号化メカニズムで保護されるのは、リモートアクセスクライアントとリモートアクセスサーバー間の実際のリンクのみである。エンドツーエンド暗号の場合は、IPSec を使用しなければならない。PPP トラフィックを暗号化しカプセル化すれば、インターネットなどの公衆IPネットワークで接続された 2 つのシステム間にトンネルを作成して、安全な通信経路を実現できる。ただし、この経路を確立する前に、通信を意図する 2 つのエンドシステムが相互に認証できなければならない。

パスワード認証プロトコル (PAP) を使用してユーザー名とパスワードを送信すれば、クライアントはリモートアクセスサーバーに対して自らを認証できるが、これでは最低限のセキュリティしか実現しない。リモートアクセスリンクを通じて送信されるデータを侵入者が横取りすれば、ユーザーのパスワードを手に入れることができるので、送信中のデータが危険にさらされるだけでなく、そのパスワードでアクセス可能なネットワーク上のほかのデータにまで危害が及ぶ。Windows 2000 のリモートアクセスサービス (RAS) は、クリアテキストパスワードに代わる多数の代替手段を備えており、はるかに安全な認証方法を提供する。たとえば、セキュリティで保護されたユーザー認証手段 (リモートアクセスを許可する前にサーバーがクライアントを認証しなければならない) や、相互認証手段 (接続を正常に確立するには、双方のシステムが相手を認証しなければならない) である。これらのメカニズムでは、暗号化を使用して認証データを安全に送信したり、スマートカードを使用してユーザーの身元を検証したりできる。

Windows NT に搭載されていた旧バージョンの RAS は、暗号化を使用したリモートアクセスクライアントの認証を、チャレンジハンドシェイク認証プロトコル (CHAP) や Shiva パスワード認証プロトコル (SPAP) などのプロトコルに依存していた。SPAPでは、ユーザーのパスワードを暗号化して送信する。一方、CHAP では、サーバーから送信されたチャレンジ文字列の一方向ハッシュを、クライアントのパスワードを使用して作成する。サーバーは同一の計算を行って、クライアントがユーザー認証用に送信したものと比較する。MS-CHAP v2 は、CHAP の原理を応用して、同様のハッシュプロセスを使用して双方向認証を行える機能を追加したものである。

拡張認証プロトコル (EAP) は、RFC 2284 で規定された PPP 認証プロトコルであり、複数の認証メカニズムをサポートしている。PPP 接続の確立中、関与する 2 つのシステムは (任意に) 特定の認証プロトコルの使用を折衝する。このネゴシエーションが行われるのは接続のリンク確立段階であり、PAP や CHAP などの従来の認証プロトコルが選択されるのはこのときである。EAP はこのプロセスの代替手段を備えている。システムはリンク確立フェーズ中に EAP の使用に同意するが、実際の認証手段の選択は、接続プロセスの認証段階が実際に開始されるまで延期される。認証段階が始まると、この 2 つのシステムは特定の種類の EAP の使用を折衝する。EAP がこのような方法を採用したのは、EAP で新しい認証手段をサポートするときに、追加の種類を定義するだけで済むからである。Windows 2000 は、EAP-MD5 と EAP-TLS という 2 種類の EAP をサポートしている。この章の残りでは、これらについて説明する。

EAP-MD5 は CHAP と同じ認証メカニズムを使用しているが、接続の認証段階が始まるまで選択は延期される。この時点で、サーバーは、EAP-Request メッセージによってクライアントのユーザー ID を要求し、クライアントは、名前が入った EAP-Response によって応答する。次にサーバーは MD5 チャレンジ文字列をクライアントに送信し、クライアントはハッシュ操作を実行して、その結果をサーバーに返す。サーバーがこの情報を検証すると、接続確立プロセスが続行する。

EAP-TLS は、(RFC 2246 で規定された) TLS プロトコルのEAP実装である。EAP による TLS の使用は、RFC 2716 で規定されている。TLS は、SSL プロトコルに基づいて、双方向認証や暗号化アルゴリズムネゴシエーションなどの追加セキュリティサービスを提供する。EAP-TLS が実行する認証手順は、公開キー証明書の交換と検証に基づいている。双方向認証中、クライアントシステムはユーザー証明書を提出する。これは、クライアントシステムとスマートカードのどちらに格納されていてもかまわない。サーバーはコンピュータ証明書を送信する。このようにして、サーバーは、ネットワークへのアクセスをクライアントに許可すべきであることを検証し、クライアントは期待どおりのサーバーに到達できたことを確信する。

 

以上ここまでで述べてきたとおり、Windows 2000 は、セキュリティ面で Windows NT コンポーネントよりもはるかに優れたネットワーク通信を実現できるコンポーネントを備えている。IPSec では、OSI モデルのネットワーク層でデータ伝送を暗号化し、途中で機密データが盗聴されるのを防ぐことができる。Microsoft DHCP サーバーには、偶発的または意図的にクライアントに不正な TCP/IP 設定を提供する未承認サーバー/システムがまぎれ込むのを防止する機能がある。Microsoft DNS サーバーは、ドメインコントローラが行うリソースレコードの動的更新を保護できる。このようなテクノロジの実現によって、ネットワークのセキュリティがはるかに向上し、保護すべきデータを侵入者の手から守ることができる。