IPsec とグループ ポリシーを使用したサーバーおよびドメインの分離

この章では、IPsec の用語、プロセス、および概念について概要を詳しく説明します。 「IPsec とグループ ポリシーを使用したサーバーおよびドメインの分離」ガイドで説明する IPsec の理解に必要な情報を提供します。

この章は、マイクロソフトと Foundstone Strategic Security が共著したホワイト ペーパー「Using Microsoft Windows IPsec to Help Secure an Internal Corporate Network Server」(英語) の一部として公開された内容を基にしています。

このホワイト ペーパーの追加情報では、機密データを処理または格納する内部 Microsoft® Windows® サーバーへのネットワーク アクセスを IPsec を使用してセキュリティ保護する場合の最初のモデルについても説明しています。 この追加情報は「IPsec とグループ ポリシーを使用したサーバーおよびドメインの分離」ガイドの理解には必要ありませんが、背景情報として知っておくと役立ちます。

トピック

	はじめに
	IPsec ポリシー フィルタ
	IKE ネゴシエーション プロセス
	セキュリティ メソッド
	IPSec カプセル化モードおよびプロトコル ワイヤ形式
	IKE 認証
	IKE 認証方法とセキュリティ メソッドの優先順位
	セキュリティ ネゴシエーション オプション

はじめに

IPSec ポリシーを作成する場合、 (IPSec の動作を決定する) IPSec 規則と (構成した規則にかかわらず適用される) 設定を構成します。 IPSec ポリシーの構成後に、そのポリシーを適用対象となるコンピュータに割り当てる必要があります。 1 台のコンピュータに複数の IPSec ポリシーを設定できますが、一度に 1 台のコンピュータに割り当てることができるポリシーは 1 つのみです。

IPSec 規則で規定するものは、IPSec で検証する必要があるトラフィックの種類、トラフィックに対する処理 (許可、ブロック、セキュリティのネゴシエート)、IPSec ピアの認証方法などです。 IPSec 規則を構成する場合は、1 つ以上のフィルタを含むフィルタ一覧、フィルタ操作、認証方法、接続の種類、IPSec のカプセル化モード (トランスポート モードまたはトンネル モード) を構成します。 通常、IPSec 規則は特定の目的に合わせて構成します (たとえば、"インターネットから TCP ポート 135 へのすべての受信トラフィックをブロック")。

フィルタでは、ファイアウォール規則と同様に、発信元と宛先の IP アドレス、プロトコル、およびポート番号の適切なものを指定して、検査するトラフィックを定義します。 フィルタ操作では、ネットワーク トラフィックのセキュリティ要件を定義します。 フィルタ操作は、許可、ブロック、またはセキュリティのネゴシエート (IPSec のネゴシエート) に構成できます。 フィルタ操作をセキュリティのネゴシエートに構成する場合は、キー交換セキュリティ メソッド (およびそれぞれの優先順位)、セキュリティで保護されていない最初の着信トラフィックを受け入れるかどうか、IPSec をサポートしていないコンピュータとのセキュリティで保護されない通信を許可するかどうか、PFS (Perfect Forward Secrecy) を使用するかどうかも構成する必要があります。

キー交換設定およびキー交換セキュリティ メソッドは、IPSec プロトコル ワイヤ形式 (認証ヘッダー (AH) または カプセル化セキュリティ ペイロード (ESP))、暗号化アルゴリズムとハッシュ アルゴリズム、キーの有効期間、およびインターネットキー交換 (IKE) メイン モードと IPSec セキュリティ アソシエーション (SA) の両方を構成するために必要なその他の設定を決定します。 SA とは、キー マテリアルに関連付けられるセキュリティ設定上の合意です。 最初の IKE ネゴシエーション フェーズ中に作成された SA は、IKE メイン モード SA と呼ばれます (ISAKMP メイン モード SA とも呼ばれます)。 IKE メイン モード SA は、IKE ネゴシエーション自体を保護します。 2 番目の IKE ネゴシエーション フェーズ中に作成された SA は、IPSec SA と呼ばれます (IKE クイック モード SA とも呼ばれます。各 IKE クイック モード ネゴシエーションは、各方向について IPSec SA をネゴシエートするからです)。 IPSec SA は、アプリケーション トラフィックを保護します。

ここでは、次の重要な IPSec ポリシーの概念について説明します。

IPSec ポリシーの概念の詳細については、Microsoft Windows Server™ 2003 のヘルプとサポート センターを参照してください。

ページのトップへ

IPsec ポリシー フィルタ

フィルタは、IPSec ポリシーの最も重要な部分です。 クライアントまたはサーバーのポリシーで指定するフィルタが適切でない場合、またはポリシーのフィルタを更新する前に IP アドレスが変更された場合は、セキュリティによる保護が提供されない可能性があります。 IPSec フィルタは、受信 IP パケットと送信 IP パケットをすべて検証 (フィルタ) できるように、コンピュータの TCP/IP ネットワーク プロトコル スタックの IP 層に挿入します。 2 台のコンピュータ間でセキュリティ関係をネゴシエートするために必要とされるわずかな遅延を除き、IPSec はエンド ユーザー アプリケーションやオペレーティング システムのサービスから透過的になります。 フィルタは、IPSec ポリシーのセキュリティ規則によって、対応するフィルタ操作に関連付けられます。 Windows IPSec は、規則のオプションとして IPSec トンネル モードと IPSec トランスポート モードの両方をサポートしています。 IPSec トンネル モード規則の構成は、IPSec トランスポート モード規則の構成とは大きく異なります。

IPSec ポリシーに関連付けられるフィルタ規則は、ファイアウォール規則に似ています。 [IP セキュリティ ポリシーの管理] Microsoft 管理コンソール (MMC) スナップインのグラフィカル ユーザー インターフェイス (GUI) を使用すると、特定の種類のトラフィックを許可またはブロックするように IPSec を構成できます。この許可またはブロックは、発信元アドレスと宛先アドレスの組み合わせおよび特定のプロトコルとポートに基づいて設定できます。

注 : Windows IPsec は、完全な機能を備えたホストベースのファイアウォールではありません。したがって、TCP ハンドシェイク中に確立されたビットの追跡による通信フロー方向の制御のような動的またはステートフル フィルタリングはサポートしていません。

IPsec フィルタについて理解する

フィルタ一覧には、既知のサブネットとインフラストラクチャ IP アドレスのみが表示されます。 重要なことは、各規則に含まれる各フィルタの組み合わせで必要な受信および送信アクセス制御を提供する方法を理解することです。 ここでは、IPsec フィルタがパケット処理にどのように影響するかを理解するための最も重要な情報について説明します。

Windows Server 2003 では、[IP セキュリティ モニタ] MMC スナップインに IPsec フィルタの順序を詳細に表示できます。 IPsec サービスで一連の IPsec ポリシー規則が処理されるとき、フィルタは IKE ネゴシエーションの 2 つのフェーズを制御する 2 種類のフィルタにコピーされます。

IKE クイック モード専用のフィルタは、IPsec ドライバが適用するフィルタの一覧です。 IPsec ドライバは、最高の重みで指定された順序で受信および送信 IP トラフィックをこれらのフィルタと照合します。 IKE ネゴシエーション プロセスに関する以降のセクションでは、どのように IKE がこれらのポリシー制御を使用して IPsec セキュリティ アソシエーションをネゴシエートおよび管理するかを説明します。

IPsec ポリシーで定義されているフィルタは、"汎用" フィルタと見なされます。これらのフィルタは、ポリシーの適用時に IPsec サービスによる変換が必要な場合があるからです。 IPsec サービスは、IPsec ポリシー (または変更) がコンピュータに適用されるときに、すべての汎用フィルタを特定のフィルタに変換します。 特定のフィルタには、重み (順位) を計算する組み込みアルゴリズムがあります。また、トラフィックの選択時にフィルタがどの程度特定であるかも示します。 重みの値が高くなるほど、より限定的なフィルタになります。 特定のフィルタはすべて、それぞれの重みに従ってソートされます。 フィルタの重みが評価される順序は、フィルタ内に定義されている IP アドレス、プロトコル、ポートの順です。 この方法では、ポリシー内の規則の順位と各フィルタ一覧内のフィルタの順序は、パケット処理中に IPsec ドライバが適用するフィルタ動作に影響しません。 フィルタ セット全体に対する各パケットの処理時間を最短に抑えるために、パケットはまず最も限定的なフィルタと照合されます。 パケットに一致する最も限定的なフィルタに対応するフィルタ操作は、そのパケットに対して行われる操作のみです。 定義可能な最も汎用のフィルタは、任意の IP アドレス、すべてのプロトコル、およびポートに一致するフィルタです。 たとえば、次の 4 つのフィルタ定義があるとします。

Any <-> Any (任意 <-> 任意) フィルタが、定義可能な最も汎用的なフィルタです。 これは、Windows Server 2003 と Windows XP Service Pack 2 (SP2) のみでサポートされます。 通常、このフィルタはブロック操作と共に使用されて "すべて拒否" の既定の動作を実現します。このフィルタがすべてのトラフィックをブロックするために使用されている場合は、より限定的なその他のフィルタは最初のフィルタの例外と見なされます。 Windows 2000 でサポートされている最も汎用的なフィルタは、"Any <-> subnet, any protocol (任意 <-> サブネット、任意のプロトコル)" です。または、サブネットが使用されていない場合は "Any <-> My IP address (任意 <-> このコンピュータの IP アドレス)" です。

4 つのフィルタはすべて、任意の IP アドレスから 192.168.1.10 への TCP ポート 25 を使用する受信トラフィックおよびポート 25 からの対応する送信応答に一致します。 4 番目が最も限定的なフィルタです。宛先の IP アドレス、プロトコル、およびポート番号が指定されているからです。 4 つすべてが IPsec ドライバによって適用される場合は、TCP ポート 25 宛ての受信パケットのみが 4 番目の最も限定的なフィルタに一致します。 リモート システムから 25 以外のポートへの TCP トラフィックを 192.168.1.10 に送信した場合は、3 番目のフィルタが一致します。 192.168.1.10 を除く 192.168.1.0 サブネットの任意の IP アドレスにトラフィックを送信する場合は、そのトラフィックには 2 番目のフィルタが最も限定的です。

フィルタ設定の潜在的な問題

フィルタを定義する際は、特定の組み合わせの発信元アドレスと宛先アドレスを使用しないでください。 前述のとおり、任意の IP から任意の IP アドレスへのトラフィックを指定するフィルタは、Windows 2000 を実行しているホストでは避ける必要があります。

一般に、ポリシーのフィルタが多いほど、パケット処理へのパフォーマンスの影響が高まります。 このパフォーマンスの影響は、スループットの低下、非ページ プール カーネル メモリの使用量の増加、および CPU 使用率の上昇として現れます。 パフォーマンスへの影響は、全体的なトラフィックの量、IPsec でセキュリティ保護されたトラフィックの処理量、およびコンピュータの CPU 負荷によるものなので、正確に予測するのは非常に困難です。 このため、IPsec ポリシー設計のパフォーマンス テストを計画に入れる必要があります。 数百のフィルタの影響は、スループットの非常に高いコンピュータ以外ではほとんど気付かない程度です。

Windows 2000 には、大量のフィルタの処理を最適化する機能がありません。 IPsec ドライバは、フィルタ一覧全体を順にスキャンして一致を見つける必要があります。

Windows XP と Windows Server 2003 では、フィルタ処理を高速化するための最適化が多数行われたので、IPsec ポリシーに大量のフィルタを使用できます。 プロトコルまたはポートに関係ない "<IP アドレス> から <IP アドレス>" 形式のフィルタは、Generic Packet Classifier (GPC) ドライバを使用して非常に高速の検索を行うように最適化されました。 GPC では、スループット パフォーマンスを低下させることなく、これらのフィルタをほぼ無制限に処理できます。 したがって、フィルタ一覧全体を保持するのに十分な非ページ カーネル メモリがある場合は、"このコンピュータの IP アドレスから <特定の適用除外 IP アドレス>" を使用する長い適用除外リストを簡単にサポートできます。 フィルタに発信元と宛先両方の特定 IP アドレスがない場合は、GPC で最適化できないので、Any <-> specific IP または subnet (任意 <-> 特定の IP またはサブネット) フィルタで順次検索が必要になります。 ただし、Windows 2000 以降では実装が改善されています。

このコンピュータの IP アドレスの使用は多くの場合は適切ですが、複数の仮想 Web サイトをホストしている Web サーバーのように多数の IP アドレスを持つホストでは問題が発生することもあります。 また、このコンピュータの IP アドレスを使用するフィルタが大量にある場合は、IPsec ドライバ パケット フィルタの使用に遅延が発生することもあります。 IPsec サービスでは、サービスの起動時とアドレス変更イベントの発生時にフィルタを処理します。 この遅延によって、脆弱性の窓 (無防備な時間帯) ができたり、IPsec を使用した安全な接続に遅延が発生したりします。 ここでも、パフォーマンス テストを行って、特定の IPsec ポリシー設計で許容できる影響を確認する必要があります。

このコンピュータの IP アドレスを最適に使用できるのは、特定のポートまたはプロトコルへのトラフィックを許可または拒否している場合です。 たとえば、Woodgrove Bank の IPsec ポリシー設計では、すべてのコンピュータ間でクリア テキストで送受信される Internet Control Message Protocol (ICMP) トラフィックを許可するより限定的なフィルタを作成するために "このコンピュータの IP アドレス" フィルタが使用されています。

組織で My IP Address <-> Any IP Address (このコンピュータの IP アドレス <-> 任意の IP アドレス) 規則が割り当てられているモバイル クライアントを外部ネットワークに配置すると、そのクライアントが環境内で通信できなくなる可能性があります。 クリアテキストにフォールバックすることがクライアントに許可されている場合は、すべての宛先への接続に 3 秒以上の遅延が発生します。 宛先から IKE 応答が返された場合は、IKE ではドメイン間信頼 (Kerberos) を使用した認証を行うことができないので、IKE ネゴシエーションが失敗します。 明らかに、RFC 1918 プライベート アドレスが内部ネットワーク サブネットとして使用されている場合は、モバイル クライアントからホテルや自宅のネットワークあるいはその他の内部ネットワークに接続するときに影響します。 モバイル クライアントで接続の問題が発生した場合は、他のネットワークへの接続時にローカル管理者権限で IPsec サービスを停止する必要があります。 その結果、内部ネットワークへの接続時に IPsec サービスが実行されているかどうかを確認するために、ドメイン ログオン スクリプトの使用が必要になることがあります。

Windows 2000 は当初、マルチキャスト アドレスとブロードキャスト アドレスを使用するパケットのフィルタリングができる設計になっていませんでした。これらのトラフィックは IKE ネゴシエーションを使用してセキュリティ保護することができないからです。 このため、マルチキャストおよびブロードキャストのパケットが、IPsec フィルタをバイパスする元の既定の適用除外に含まれていました。 既定の適用除外がセキュリティに与える影響と、それらの一部を既定で削除するための Service Pack 3 での変更の実装については、マイクロソフト サポート技術情報 (KB) 811832「一部の状況で、IPSec のデフォルトの適用除外項目を使用して IPsec による保護を迂回することが可能になる」を参照してください。 Windows XP と Windows Server 2003 では、IPsec との TCP/IP 統合が強化されて、すべての種類の IP パケットをフィルタリングできます。 ただし、IKE ではマルチキャストとブロードキャストのセキュリティをネゴシエートできないので、フィルタ機能の一部のみがサポートされています。 既定の適用除外の削除と、マルチキャスト トラフィックとブロードキャスト トラフィックに対してサポートされるフィルタ機能については、KB 810207「既定の IPSec 免税は、Windows Server 2003 に削除されています。」を参照してください。 Windows XP SP2 では、Windows Server 2003 と同じ Any <-> Any フィルタ機能をサポートします。

ページのトップへ

IKE ネゴシエーション プロセス

IKE プロトコルは、各コンピュータ間の信頼関係の安全な確立、セキュリティ オプションのネゴシエート、共有の秘密暗号化キー マテリアルの動的な生成ができるように設計されています。 セキュリティ保護された正常な通信を可能にするために、IKE はフェーズ 1 (メイン モード) ネゴシエーションとフェーズ 2 (クイック モード) ネゴシエーションという 2 つのフェーズで操作を実行します。 セキュリティ ネゴシエーション中に 2 台のコンピュータ間で合意された暗号化アルゴリズムと認証アルゴリズムを使用することにより、各フェーズでの機密性の確保と認証の実行が可能になります。

メイン モード ネゴシエーション

メイン モード ネゴシエーションでは、2 台のコンピュータが、セキュリティ保護された認証済みチャネルを確立します。 初めに、いくつかの IPSec ポリシー パラメータがネゴシエートされます。ここでネゴシエートされる IPSec パラメータは、暗号化アルゴリズム (DES または 3DES)、整合性アルゴリズム (MD5 または SHA1)、基本キー マテリアルに使用する Diffie-Hellman グループ (グループ 1、グループ 2、または Windows Server 2003 ではグループ 2048)、および認証方法 (Kerberos Version 5、公開キー証明書、または事前共有キー) です。 IPSec ポリシー パラメータのネゴシエート後に、公開値の Diffie-Hellman 交換が完了します。 Diffie-Hellman アルゴリズムは、コンピュータ間で共有キー、対称キー、共通キーを生成するために使用します。 Diffie-Hellman 交換が完了すると、各コンピュータの IKE サービスは認証の保護に使用されるマスタ キーを生成します。 マスタ キーは、ID を認証するために、ネゴシエーション アルゴリズムおよびネゴシエーション方法と共に使用されます。 次に、通信の開始側が応答側に SA の案を提示します。 応答側は、この案の受諾応答を送信するか、または代替案を返信します。 IKE メイン モード ネゴシエーションに成功すると、メイン モード SA が生成されます。

クイック モード ネゴシエーション

クイック モード ネゴシエーション中に、アプリケーション トラフィックを保護するために IPSec SA のペアが確立されます。このトラフィックには、TCP、User Datagram Protocol (UDP)、およびその他のプロトコルを通じて送信されるパケットを含むことができます。 初めに、いくつかのポリシー パラメータがネゴシエートされます。ここでネゴシエートされるパラメータは、IPSec プロトコル ワイヤ形式 (AH または ESP)、整合性および認証のためのハッシュ アルゴリズム (MD5 または SHA1)、および暗号化が必要な場合には暗号化アルゴリズム (DES または 3DES) です。 この間に、確立された IPSec SA ペアで搬送する IP パケットの種類に関して共通の合意が成立します。 IPSec ポリシー パラメータのネゴシエート後に、セッション キー マテリアル (各アルゴリズムの暗号化キーと、秒および キロビット単位のキーの有効期間) が更新または交換されます。

各 IPSec SA はセキュリティ パラメータ インデックス (SPI) によって特定されます。SPI は、送信される各パケットの IPSec ヘッダーに挿入されます。 1 つの SPI で受信 IPSec SA を特定し、もう一方の SPI で送信 IPSec SA を特定します。

IKE メイン モード SA および IPSec SA

トラフィックをセキュリティ保護するために IPSec を使用するたびに、1 つの IKE メイン モード SA と 2 つの IPSec SA が確立されます。 シナリオ例では、CORPCLI と CORPSRV の間に IPSec でセキュリティ保護された通信を確立するために、次の SA が確立されます。

CORPCLI [IP1] <-------- IKE メイン モード SA [IP1、IP2] -----> [IP2] CORPSRV

CORPCLI [IP1] ---------- IPsec SA [SPI=x] ------------------> [IP2] CORPSRV

CORPCLI [IP1] <-------- IPsec SA [SPI=y] --------------- [IP2] CORPSRV

ここで

この要約が示しているように、CORPCLI と CORPSRV 間の IKE メイン モード SA は双方向です。 いずれのコンピュータも、IKE メイン モード SA によって提供される保護を使用してクリック モード ネゴシエーションを開始できます。 IPSec SA は、上位層プロトコルの状態に依存しません。 たとえば、TCP 接続は IPSec SA の継続中に確立および終了できます。また、TCP 接続の終了前に、IPSec SA を終了できます。 IKE は、既存の IPSec SA ペアの有効期限が終了する前にクイック モード ネゴシエーションを使用して新しい IPSec SA ペアを 2 つ確立することにより、再ネゴシエートを試みて接続が中断しないようにします。 通常、このプロセスは IPSec SA のキー更新と呼ばれていますが、実際には新しい IPSec SA を 2 つ確立するプロセスです。 IKE メイン モード SA の有効期間は、試行された IPSec SA の時間と回数のみで表します。IKE プロトコルで転送されたデータのバイト数ではありません。 IKE メイン モード SA は、IPSec SA ペアとは無関係に終了します。 新しい IPSec SA ペアが必要な場合は、(メイン モード SA の有効期限が終了したときに) IKE メイン モード SA が必要に応じて自動的に再ネゴシエートされます。 インターネット技術標準化委員会 (IETF) 設計によると、IKE にはメイン モード SA のキーを更新し、いずれかの方向で IKE クイック モードをネゴシエートする機能が必要です。 したがって、両方のコンピュータの IPSec ポリシーで IKE メイン モード SA 向けに構成される認証方法では、IKE メイン モード ネゴシエーションが開始された方向の認証が成功するようにしておく必要があります。 同様に、クイック モードのフィルタ操作の IPSec ポリシー設定では、双方向のクイック モード ネゴシエーションができるようにする必要があります。

ページのトップへ

セキュリティ メソッド

セキュリティ メソッドは、IKE メイン モード ネゴシエーションで使用され、暗号化アルゴリズムとハッシュ アルゴリズムおよび Diffie-Hellman グループを定義します。Diffie-Hellman グループは、メイン モード SA を作成し、IKE ネゴシエーション チャネルをセキュリティ保護するために使用されます。 セキュリティ メソッドは、クイック モード ネゴシエーションでも使用され、カプセル化モード (トランスポートまたはトンネル)、IPSec プロトコル ワイヤ形式 (AH または ESP)、暗号化およびハッシュ アルゴリズム、およびクイック モードの受信 SA と送信 SA を作成するために使用するキーの有効期間を定義します。

ページのトップへ

IPSec カプセル化モードおよびプロトコル ワイヤ形式

IPSec は、IP ペイロードの暗号化保護を提供して、IP パケット内のデータを保護します。 提供される保護は、IPSec を使用するモードとプロトコル ワイヤ形式によって決まります。 IPSec は、トランスポート モードまたはトンネル モードで使用できます。

IPSec カプセル化モード

IPSec トンネル モードは、ネットワーク間でサイト間 (ゲートウェイ間またはルーター間とも呼ばれる) トラフィックの保護に最も一般的に使用されています。たとえば、インターネット経由のサイト間ネットワークがあります。 IPSec トンネル モードを使用する場合、送信ゲートウェイは、新しい IP パケットを作成して元の IP パケット全体をカプセル化し、これをいずれかの IPSec プロトコル ワイヤ形式 (AH または ESP) で保護します。 トンネル モードの IPSec の詳細については、「Windows Server 2003 Deployment Kit」の中にある「Deploying Network Services」の「Deploying IPSec」の章 (英語) を参照してください。

IPSec トランスポート モードは、ホスト間通信を保護するために使用され、Windows IPSec の既定のモードです。 IPSec トランスポート モードを使用する場合、IPSec は IP ペイロードのみを暗号化し、IP ヘッダーは暗号化しません。 Windows IPSec は主にトランスポート モードで使用して、エンドツーエンド通信 (クライアントとサーバー間の通信など) を保護します。

IPsec プロトコル ワイヤ形式

IPSec は、AH または ESP の 2 つのプロトコル ワイヤ形式をサポートしています。 IPSec トランスポート モードでは、元の IP ペイロードを IPSec ヘッダー (AH または ESP) でカプセル化します。

AH

AH は、パケット全体 (パケットで搬送される IP ヘッダーとデータ ペイロードの両方) に対して、データの出所の認証、データの整合性、およびリプレイ防御を提供します。ただし、転送中に変更できる IP ヘッダーのフィールドは除きます。 データは暗号化されないので、データの機密性は保持されません。 データの読み取りは可能ですが、変更となりすましからは保護されます。 次の図に示すように、IP ヘッダーと TCP データの間に AH ヘッダーを配置することで整合性と認証を実現しています。

図 A.1: パケット内の認証ヘッダー
拡大表示する

AH を使用するには、適切な規則のプロパティで、[カスタム セキュリティ メソッドの設定] ダイアログ ボックスの [暗号化をしないデータとアドレスの整合性 (AH)] チェック ボックスをオンにし、使用する整合性アルゴリズムを指定します。

ESP

ESP は、IP ペイロードについてのみ、データの出所の認証、データ整合性、リプレイ防御、および機密性のオプションを提供します。 トランスポート モードの ESP は、暗号化チェックサムでパケット全体を保護しません。 また、IP ヘッダーは保護されません。 次の図に示すように、ESP ヘッダーは TCP データの前に配置され、ESP トレーラおよび ESP 認証トレーラは、TCP データの後ろに配置されます。

図 A.2: パケット内の ESP データ
拡大表示する

ESP を使用するには、適切な規則のプロパティで、[カスタム セキュリティ メソッドの設定] ダイアログ ボックスの [データの整合性と暗号化 (ESP)] チェック ボックスをオンにし、使用する整合性アルゴリズムと暗号化アルゴリズムを指定します。

ページのトップへ

IKE 認証

IKE は、コンピュータ間の相互認証を使用して、信頼された通信を確立し、Kerberos Version 5 プロトコル、コンピュータの X.509 Version 3 公開キー基盤 (PKI) 証明書、または事前共有キーのいずれかの認証方法の使用を要求します。 2 つの通信エンドポイントには共通の認証方法が少なくとも 1 つ定義されている必要があります。定義されていない場合、通信は失敗します。

IKE 認証プロセス

IKE ネゴシエーション中に、IKE 開始側は、IKE 応答側に認証方法の一覧を提示します。 応答側は開始側の発信元 IP アドレスを使用して、IKE ネゴシエーションを制御するフィルタを特定します。 応答側の IPSec ポリシーにあるフィルタに対応する認証方法の一覧を使用して、開始側が提示した一覧からいずれかの認証方法が選択されます。 次に、応答側は、合意する認証方法を開始側に通知するために応答します。 選択された認証方法が失敗した場合、IKE には異なる認証方法を試行する手段が用意されていません。 認証が成功し、メイン モード ネゴシエーションが正常に完了した場合、そのメイン モード SA は 8 時間維持されます。 8 時間後にデータがまだ送信されている場合は、自動的にメイン モード SA の再ネゴシエートが実行されます。

IKE 認証方法

使用している IPSec ポリシーに適切な認証方法を選択することが重要です。 IPSec ポリシー規則は、フィルタ内の各 IP アドレスを認証方法の一覧と関連付け、IKE が各 IP アドレスで使用する認証方法の一覧を判断できるようにします。

Kerberos Version 5 プロトコル認証

Kerberos Version 5 プロトコルは、Windows 2000 および Windows Server 2003 の Active Directory ドメインで既定の認証規格です。 このドメインまたは信頼されたドメインにあるすべてのコンピュータは、この認証方法を使用できます。

Kerberos 認証を使用すると、メイン モードのネゴシエーション時に、各 IPSec ピアが自分のコンピュータ ID を、暗号化されていない形式で相手のピアに送信します。 メイン モード ネゴシエーションの認証フェーズで ID ペイロード全体が暗号化されるまで、コンピュータ ID は暗号化されません。 攻撃者は、IKE パケットを送信し、それに応答する IPSec ピアからそのコンピュータ ID とドメインのメンバシップを入手できます。 この理由から、インターネットに接続しているコンピュータをセキュリティ保護するには、証明書による認証をお勧めします。

Windows 2000 ～ Service Pack 3 および Windows XP の既定では、Kerberos トラフィックは IPSec フィルタの適用から除外されています。 Kerberos トラフィックに対する適用除外を削除するには、レジストリを変更してから、適切な IPSec フィルタを追加してこのトラフィックをセキュリティ保護する必要があります。 Windows 2000 および Windows Server 2003 での既定の適用除外の詳細については、マイクロソフト Web サイトの「IPsec の特段の注意事項」 - 「IPSec ポリシーの作成、変更、および割り当て」を参照してください。

公開キー証明書による認証

Windows 2000 Server では、証明書サービスを使用すると、証明書の有効期間内において IPSec のコンピュータ証明書を自動的に管理できます。 証明書サービスは Active Directory およびグループ ポリシーと統合されています。このサービスは、証明書の自動登録と更新を有効にし、IPSec と互換性のある既定の証明書テンプレートを複数提供することにより、証明書の展開を容易にします。 IKE 認証に証明書を使用するには、使用する特定の証明書を定義するのではなく、使用する受け入れ可能なルート証明機関 (CA) の順序付き一覧を定義します。 両方のコンピュータの IPSec ポリシー構成で共通のルート CA が定義されている必要があります。また、クライアントにはコンピュータ証明書が関連付けられている必要があります。

証明書の選択処理中に、IKE はコンピュータ証明書に対する特定の要件が満たされていることを確認するための一連の検査を実行します。 たとえば、コンピュータ証明書は 512 ビットよりも大きい公開キー長を持ち、デジタル署名キーを使用する必要があります。

注 :[秘密キーの保護を強力にする] の詳細オプション セットを指定して証明書サービスから取得した証明書は、IKE 認証では動作しません。これは、IKE ネゴシエーション時に、コンピュータ証明書の秘密キーにアクセスする上で必要な暗証番号 (PIN) を入力できないためです。

事前共有キー

Kerberos 認証を使用せず、CA にアクセスできない場合は、事前共有キーを使用できます。 たとえば、ネットワーク上のスタンドアロン コンピュータでは、事前共有キーの使用が必要な場合があります。これは、コンピュータのドメイン アカウントを通じた Kerberos 認証を使用しても、CA からの証明書を使用しても、正常な IKE 認証を実現できないシナリオがあるからです。

重要 : 事前共有キーは簡単に実装できますが、正しく使用しないと侵害される可能性があります。 キー値が安全に保存されず、機密を保持することが難しいので、Active Directory での事前共有キーによる認証はお勧めしません。 IPSec ポリシーでは、事前共有キー値はプレーンテキストに保存されます。 ローカルの Administrators グループのすべてのメンバは、ローカル IPSec ポリシーを表示できます。また、ローカル IPSec ポリシーは、Local System ユーザー権利を有するシステム サービスからであれば読み取ることができます。 事前共有キーが Active Directory ベースの IPSec ポリシーに保存されている場合、既定では、ドメインで認証されたすべてのユーザーがその事前共有キーを表示できます。 また、IKE ネゴシエーション パケットを入手できた攻撃者は、公開されている数々の手法を使用すれば事前共有キー値を発見できることがあります。
詳細については、「Authentication Vulnerabilities in IKE and Xauth with Weak Pre-Shared Secrets」(英語) を参照してください。

事前共有キーによる認証は、相互運用性と RFC 規格との互換性を確保する目的で用意されています。 事前共有キー認証を使用する必要がある場合は、25 文字以上のランダムなキー値と、IP アドレス ペアごとに異なる事前共有キーを使用します。 このような方法によって、宛先ごとに異なるセキュリティ規則が作成されるので、侵害された事前共有キーがあっても、危害を受けるのはそのキーを共有しているコンピュータのみになります。

IPSec CRL のチェック

証明書ベースの認証を使用する場合は、IPSec 証明書失効リスト (CRL) のチェックを有効にすることもできます。 Windows2000 の既定では、IKE の証明書の認証中に IPSec CRL が自動的にチェックされることはありません。

IPSec CRL のチェックを有効にするには

注意 : レジストリの編集を誤ると、システムが重大な損傷を受けることがあります。 レジストリに変更を加える前に、コンピュータ上の重要なデータをバックアップすることをお勧めします。

ページのトップへ

IKE 認証方法とセキュリティ メソッドの優先順位

1 つの認証方法またはセキュリティ メソッドのみを指定するように、IPSec 規則を構成できます。 または、複数の認証方法とセキュリティ メソッドに優先順位を付けた一覧を指定することもできます。 優先順位は認証方法とセキュリティ メソッドに適用されます。優先順位の高い順に、それぞれの方法およびメソッドを指定できます。 たとえば、次の図に示すように、Kerberos Version 5 プロトコルと公開キー証明書による認証の両方が認証方法として示されるように指定して、Kerberos プロトコルに高い優先順位を与えることができます。

図 A.3: 認証方法の優先順位

CORPSRV に接続しようとするクライアントが、認証方法として公開キー証明書のみを受け入れる場合、CORPSRV はこの認証方法を使用して通信の確立を継続します。 選択された認証方法を使用して IKE が成功しない限り、通信はブロックされます。 IKE は、ネゴシエーションに失敗した場合でも、別の認証方法を試そうとはしません。 セキュリティ メソッドにも同じ原則が適用されます。たとえば、ESP が AH よりも優先されることがあります。

ページのトップへ

セキュリティ ネゴシエーション オプション

フィルタ操作のプロパティの [セキュリティ メソッド] タブで、クリアテキストへのフォールバック (セキュリティ保護されない通信へのフォールバック)、受信パススルー、およびセッション キーの PFS を IPSec ポリシーで許可するかどうかを構成できます。 規則の全般プロパティの [キー交換の設定] ダイアログ ボックスでは、マスタ キーの PFS を構成できます。

クリアテキストにフォールバック

クリアテキストにフォールバックすることが許可されている場合、トラフィックのセキュリティは可能な限り IPSec によって保護されます (接続の他端にあるコンピュータが、そのポリシーで補足的なフィルタ操作およびフィルタと共に IPSec をサポートしている場合)。ただし、ピアにセキュリティ ネゴシエーションの要求に応答する IPSec ポリシーがない場合、トラフィックはセキュリティで保護されずに送信されます。 ピアが 3 秒以内にセキュリティ ネゴシエーションの要求に応答しない場合は、プレーンテキスト トラフィック用の SA (ソフト SA) が作成されます。 ソフト SA は、IPSec カプセル化を行わない通常の TCP/IP 通信を許可します。 IPSec はこのようなトラフィックをセキュリティ保護しないことがありますが、トラフィックをセキュリティ保護する上で別のアプリケーションが役立つことがあリます。たとえば、LDAP (Lightweight Directory Access Protocol) 暗号化や RPC 認証メカニズムで、トラフィックをセキュリティ保護できることがあります。 ピアが 3 秒以内に応答したものの、セキュリティ ネゴシエーションに失敗した場合、対応するフィルタと一致する通信はブロックされます。

クリアテキストへのフォールバックを設定すると、次に挙げるコンピュータとの相互運用性を実現できます。

クリアテキストへのフォールバックを有効または無効にするには、フィルタ操作のプロパティの [セキュリティ メソッド] タブで、[IPSec に対応していないコンピュータとセキュリティで保護されていない通信を許可] チェック ボックスをオンまたはオフにします。

クライアント ポリシーでは、このオプションを有効または無効にできます。 このオプションを有効にすると、サーバーがセキュリティをネゴシエートするためのクライアントの要求に応答しない場合は、クリアテキストにフォールバックすることをクライアントに許可できます。 このチェック ボックスをオフにすると、サーバーがセキュリティをネゴシエートするためのクライアントの要求に応答しない場合、通信はブロックされます。 場合によっては、クリアテキストへのフォールバックを許可することが役に立ちます。 ただし、IKE は応答がない場合にのみ、クリアテキストへのフォールバックを許可します。 セキュリティ上の理由から、認証に失敗したり、セキュリティ パラメータについて合意に至らない場合のように IKE ネゴシエーションに失敗したり、(応答後の) IKE ネゴシエーション中にエラーが発生した場合、Windows IPSec はセキュリティ保護されていない通信を許可しません。

最初の展開では、サーバー側で IPSec が無効になっている場合に、クライアントがクリアテキストへのフォールバックを実行して初期接続を確立できるように、このチェック ボックスをオンにすることをお勧めします。

受信パススルー

受信パススルーを許可する場合、通常の受信 TCP/IP トラフィック (TCP SYN パケットなど IPSec で保護されないトラフィック) は、フィルタ操作に関連付けられた受信フィルタと一致する場合に限り、受け入れられます。 上位層プロトコルの応答パケット (TCP SYN ACK パケットなど) は、対応する送信フィルタと一致し、セキュリティ ネゴシエーションを開始します。 次に 2 つの IPSec SA がネゴシエートされます。トラフィックは、双方向で IPSec によりセキュリティ保護されます。 受信パススルー オプションを使用すると、サーバーは既定の応答規則を使用して、クライアントに対するセキュリティ ネゴシエーションを開始できます。 クライアントの IPSec ポリシーで既定の応答規則を有効にした場合、クライアントはサーバーの IP アドレスを含むフィルタを維持する必要はありません。 クライアントの IPSec ポリシーで既定の応答規則を有効にしない場合は、サーバーの IPSec ポリシーで受信パススルー オプションを有効にする必要はありません。 また、インターネットに接続するコンピュータでは、このオプションを有効にしないでください。

受信パススルーを有効または無効にするには、フィルタ操作のプロパティの [セキュリティ メソッド] タブで、[セキュリティで保護されていない通信を受け付けるが、常に IPSec を使って応答] チェック ボックスをオンまたはオフにします。

セッション キーおよびマスタ キーの PFS

PFS は、マスタ キーの既存のキー マテリアルを使用して新しいセッション キーを派生させることができるかどうかを決定するメカニズムです。 PFS では、1 つのキーが侵害された場合、PFS で保護されたデータへのアクセスのみ許可するため、通信全体は必ずしも影響を受けません。 これを実現するために、PFS では、転送の保護に使用するキーは、追加キーの生成には使用できないようになっています。 セッション キーの PFS は再認証なしで使用でき、マスタ キー PFS に比べてリソースの消費も多くありません。 セッション キーの PFS を有効にすると、新しい Diffie-Hellman キー交換が実行され、新しいマスタ キーのキー情報が生成されます。

サーバー ポリシーで有効にしたセッション キー PFS は、クライアント ポリシーでも有効にする必要があります。 規則の全般プロパティの [キー交換の設定] ダイアログ ボックスで [セッション キーの PFS (Perfect Forward Secrecy) を使う] チェック ボックスをオンにして、セッション キーの PFS を有効にできます。 マスタ キーの PFS では再認証が必要で、リソースも大量に消費されます。 クイック モード ネゴシエーションが行われるたびに、新しいメイン モード ネゴシエーションが必要です。 [マスタ キーの PFS (Perfect Forward Secrecy)] チェック ボックスをオンにして、マスタ キーの PFS を構成できます。 サーバー ポリシーでマスタ キー PFS を有効にした場合でも、クライアント ポリシーではその PFS を有効にする必要はありません。 このオプションを有効にすると大幅なオーバーヘッドが生じるため、セッション キーの PFS またはマスタ キーの PFS は、IPSec トラフィックが IPSec によって提供される強力な暗号化保護を破ろうとする巧妙な攻撃者にさらされる可能性がある危険な環境でのみ有効にすることをお勧めします。

ページのトップへ

9 of 13