次の方法で共有

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

第 5 章 : 分離グループの IPsec ポリシーを作成する

最終更新日: 2005年5月30日

この章では、サーバー/ドメイン分離設計を実装する手順について説明します。 ここまでの章で設計のプロセスと原理について説明しており、この章の内容は、それらの説明を前提としています。 この章以前の章を未読の場合は、まずそちらから読むことを強くお勧めします。

この章では、「第 4 章 : 分離グループを設計および計画する」で設計したドメイン分離グループおよびサーバー分離グループのセキュリティ要件を実装する手順について詳しく説明します。要件の実装は、次の事項の組み合わせにより行います。

  • 分離ドメインと分離グループの受信/送信アクセス要件 :

    • 受信/送信接続に IPsec インターネット キー交換 (IKE) ネゴシエーションを必要とする分離グループ用に特別に設計されたインターネット プロトコル セキュリティ (IPsec) ポリシー

    • IPsec で保護されたトラフィックを使用する場合にネットワーク アクセスを許可または拒否するネットワーク アクセス グループという意味での、ドメインベースのセキュリティ グループ

  • 分離ドメインと分離グループのネットワーク トラフィック保護要件 :

    • セキュリティ保護するトラフィックを正しく特定するように設計された IPsec ポリシー フィルタ

    • フィルタが特定するトラフィックに必要とされるレベルの認証と暗号化をネゴシエーションする IPsec フィルタ操作

    • 信頼されたホストの発信接続開始時にプレーンテキスト通信の許可の可否を制御する IPsec フィルタ操作の設定

このガイダンスでは、Microsoft® Windows Server™ 2003 の Active Directory® ディレクトリ サービスでグループ ポリシーと IPsec ポリシーを使用してソリューションを準備し、Windows Server 2003 と Microsoft Windows® XP を使用してドメイン メンバを構成する方法について説明します。 さらに、設計の代替案と公開オプションについても説明します。 設計がビジネスとセキュリティのすべての要件を満たしていることを確認するための、最終チェック リストも用意しています。

トピック

章の前提条件
Active Directory で IPsec ポリシーを作成する
分離グループへの受信アクセスを許可する
IPsec に関するその他の考慮事項
要約

章の前提条件

ここでは、組織内で IPsec ソリューションを実装する準備が整っているかどうかを判断する方法について説明します (ここで言う "準備" とは、ビジネス上の準備ではなくロジスティックス上の準備を意味します。このソリューションを実装するビジネス上の理由については、このガイドの「第 1 章 : サーバー分離とドメイン分離の紹介」に記載されています)。

知識の前提条件

IPsec の一般的な概念およびマイクロソフトの IPsec の実装について、特に詳しく知っている必要があります。 また、Windows Server 2003 に関する知識も、次の事項に関連して必要となります。

  • Active Directory の概念 (Active Directory の構造とツール、ユーザーやグループなどの Active Directory オブジェクトの操作方法、グループ ポリシーの使用方法など)

  • Windows システムのセキュリティ (ユーザー、グループ、監査、アクセス制御リスト (ACL) などのセキュリティの概念、セキュリティ テンプレートの使用方法、グループ ポリシーまたはコマンドライン ツールを使用したセキュリティ テンプレートの適用方法など)

  • 中核となるネットワークおよび IPsec の原理

この章を読む前に、ここ以前の章に記載されている計画ガイダンスも読んで、ソリューションのアーキテクチャと設計を十分に理解しておくことをお勧めします。 また、ソリューションの要件の基盤として、ソリューションのビジネス要件を定義して文書化しておく必要もあります。

組織の前提条件

組織内の次に挙げる人間は、場合によってはこのソリューションの実装に関与する必要があるため、打ち合わせを行ってください。

  • ビジネス スポンサー

  • セキュリティおよび監査担当者

  • Active Directory のエンジニアリング、管理、運用担当者

  • DNS (Domain Name System)、Web サーバー、およびネットワーク エンジニアリングの管理、運用担当者

    注 : IT 部門の構成によっては、これらの役割を多数の人間が担当している場合や、少数の担当者がいくつもの役割を兼務している場合があります。

前提となる IT インフラストラクチャ

この章では、次の IT インフラストラクチャの存在も仮定されています。

  • 混在またはネイティブ モードで実行している Microsoft Windows Server 2003 Active Directory ドメイン。 このソリューションは、グループ ポリシー オブジェクト (GPO) の適用にユニバーサル グループを使用します。 混在またはネイティブ モードで実行されていない場合でも、標準グローバル構成およびローカル グループ構成を使用すると GPO を適用できます。 ただし、このオプションは管理が複雑なため、このソリューションでは使用しません。

    注 : Windows Server 2003 には、IPsec ポリシーに影響を与えるいくつかの改善が施されています。 このソリューションには、Windows 2000 で実行できないようなことは何も含まれていませんが、 ソリューションのテストは Windows Server 2003 Active Directory でしか実施されていません。
    Windows Server 2003 の IPsec に追加された拡張機能の詳細については、マイクロソフト Web サイトの「IPSec の新機能」を参照してください。

  • Windows 2000 Server、Windows Server 2003 Standard Edition、および Windows Server 2003 Enterprise Edition のライセンス、インストール メディア、およびプロダクト キー。

またこの章では、環境内の目的のホストに正しいポリシーが確実に展開されるように、既存の IT インフラストラクチャについて完全に理解していることが必要です。 必要な情報とその入手方法については、「第 3 章 : IT インフラストラクチャの現在の状態を確認する」を参照してください。 この章で説明している手順を実行する場合は、最低でも次の情報を入手してからにしてください。

  • 設計用の分離グループの定義。 必要とされる分離グループではそれぞれ、セキュリティ要件の内容を伝え、その要件が適用される資産 (つまり、分離グループ メンバシップ) を特定する情報が明確に定義されている必要があります。

  • 分離グループの実装に IPsec ポリシーを使用する方法の詳細な記述 (必要となる IPsec ポリシーの一覧とその割り当て方法など)。

  • IPsec を適用して分離グループを実装した場合に発生する影響についての詳細な要約。 この要約には、問題や対処方法の一覧が添付されることがあります。

  • IPsec ポリシーの今後の変更方法に関する詳細な記述と、IPsec ポリシーの変更が必要な手順の一覧。 たとえば、セキュリティ インシデント対応、ネットワーク コンポーネントの追加、分離グループのクライアントまたはサーバーの追加などがあります。

  • 組織のネットワーク トポロジおよび IP アドレス指定方式。

ページのトップへ

Active Directory で IPsec ポリシーを作成する

必要とされる分離グループのサポートに必要なポリシーを作成するプロセスは、主に次のタスクから構成されています。

  • フィルタ一覧の作成

  • フィルタ操作の作成

  • 分離グループを実装する IPsec ポリシーの作成

これらのコンポーネントの作成を開始する前に、「第 4 章 : 分離グループを設計および計画する」にあるトラフィック モデルの図と表、およびホストとネットワークの対応表を用意する必要があります。 これらの表があれば、ポリシーによって必要な機能が提供され、かつポリシーが正しい分離グループに割り当てられるように、必要な情報を参照できます。

次の図は、Woodgrove Bank のシナリオのシミュレーションに使用されたネットワーク構成を表したものです。

拡大表示する

図 5.1: Woodgrove Bank のネットワーク構成

Woodgrove Bank のテスト ラボ構成が示すソリューションの主な機能として、次のものがあります。

  • ドメインの分離 (ネットワーク アクセス グループを使用して、IPsec の使用時にリスクは高いが信頼されている特定のホストをブロックする)

  • サーバーの分離 (ネットワーク アクセス グループを使用して、IPsec の使用時に接続を承認される信頼されたホスト クライアントを制限する)

加えてこのラボ環境は、次に挙げる Windows IPsec の必要とされる機能および現実の環境で使用される他のセキュリティ テクノロジとのテスト互換性も示しています。

  • Windows 2000 Service Pack (SP) 4 (ネットワーク アドレス変換トラバーサル (NAT-T) アップデートを含む)、Windows XP SP2、および Windows Server 2003 を実行しているコンピュータのドメイン メンバとしての互換性。

  • Microsoft Windows セキュリティ ガイドに記載されている推奨事項および強化対策を使用してセキュリティ保護を実行した場合の、そのプラットフォームの互換性。 分離の保護要件は異なるため、IPsec フィルタを使用してトラフィックを許可およびブロックするためのトラフィック マップは、このソリューションには統合されていません。 トラフィック マップを統合しないその他の理由として、サーバー分離 IPsec ポリシーの複雑さが軽減されることと、多くの場合 Windows ファイアウォールの方が許可/ブロックのフィルタリングに適している (IPsec が独立しているため、パケットごとのエンドツーエンドのセキュリティを実現できる) ことが挙げられます。

  • Web (HTTP)、SQL Server、分散ファイル システム (DFS)、ファイルおよびプリンタの共有、Microsoft Operations Manager (MOM)、ならびに Microsoft Systems Management Server (SMS) サーバーおよびトラフィックをセキュリティ保護する IPsec アプリケーションの機能。

  • 次の両方の状況で User Datagram Protocol (UDP)-ESP カプセル化を使用する IPsec カプセル化セキュリティ ペイロード (ESP) NAT-T の互換性。

    • IKE Kerberos 認証を使用した、NAT の背後にあるドメイン メンバからの送信アクセス

    • IKE Kerberos 認証を使用した、NAT の背後にあるドメイン メンバへの受信アクセス

図 5.1 のラボ シナリオは、ソリューションのすべての分離グループで正しい機能が実現していることをテストするために使用されたものです。 ここでは、合計 4 つの IPsec ポリシーを作成して、図の太い破線で囲まれている分離グループ (分離ドメイン、暗号化分離グループ、フォールバックのない分離グループ、境界分離グループ) に割り当てました。以降のセクションでは、これらのポリシーの作成方法について説明します。

IPsec ポリシーのコンポーネントの概要

IPsec ポリシーは、組織の IPsec セキュリティ要件の適用に使用されるさまざまなコンポーネントで構成されています。 次の図は、IPsec ポリシーの各種コンポーネントと、それらが互いにどのように関連しているかを示したものです。

拡大表示する

図 5.2: IPsec ポリシーのコンポーネント

IPsec ポリシーは、許可されるネットワーク通信トラフィックおよびそれが許可される方法を決定する一組の規則のコンテナとして機能します。 各規則は、フィルタ一覧と関連する操作で構成されています。 フィルタ一覧には、グループ分けされたフィルタが含まれています。 トラフィックが特定のフィルタに一致すると、関連付けられているフィルタ操作が始動します。 この規則はまた、ホスト間で使用される認証方法も定義します。

この図では、ポリシー コンポーネントは上から順に表示されていますが、 ポリシーを最も効率的に作成するには、まずフィルタとフィルタ一覧を作成します。フィルタとフィルタ一覧が、どのトラフィックをセキュリティ保護するかを制御する構成ブロックの基礎にあたるためです。

IPsec フィルタ一覧

IPsec フィルタ一覧は、1 つまたは複数のフィルタを集めたものです。このフィルタを使用して、各フィルタの条件に基づいたネットワーク トラフィックの照合が行われます。 フィルタ一覧内の各フィルタでは、次の項目が定義されています。

  • 発信元および宛先ネットワーク/アドレス

  • プロトコル

  • 発信元および宛先 TCP (Transmission Control Protocol) ポートまたは UDP ポート

フィルタ一覧とフィルタ操作は、IPsec ポリシー間で共有されるように設計されています。 そのため、特定の種類の除外用に 1 つのフィルタ一覧を作成し、各分離グループの個々の IPsec ポリシーでそれを使用することができます。 ただし、フィルタ一覧を構成するフィルタは、別のフィルタ一覧とは共有できません。 2 つのフィルタ一覧に同じフィルタを含める場合は、各フィルタ一覧用にフィルタを 2 回作成する必要があります。

フィルタには個別に操作を指定できるため、IPsec 管理者は、IPsec ポリシー内に重複するフィルタが存在しないように注意する必要があります。 IPsec サービスによって重複するフィルタのパケット処理の順番が変更され、矛盾する結果になる恐れがあります。 フィルタの操作 (許可またはブロックなど) がまったく同じでパフォーマンスに影響を与えない場合は、必要に応じて重複するフィルタを使用することもできます。

以前に収集したネットワーク情報を使用すると、管理者がセキュリティ保護しているさまざまなトラフィック パターンを特定することができます。 また、この情報は、IPsec 制限から除外する必要のあるトラフィックの特定にも使用します。

次の表に、一般的な組織に存在する基本的なフィルタ一覧の一部を示します。 組織のビジネス要件とネットワーク設計によっては、別のフィルタ一覧が必要になる場合があります。

表 5.1: ソリューションが提供するフィルタ一覧

フィルタ一覧 説明
Secure Subnets List IPsec でセキュリティ保護する、組織内すべてのサブネットが含まれています。
DNS Exemption List IPsec を使用しなくても通信が許可される DNS サーバーの IP アドレスが含まれています。
Domain Controllers Exemption List IPsec を使用しなくても通信が許可されるドメイン コントローラの IP アドレスが含まれています。
WINS Exemption List IPsec を使用しなくても通信が許可される Windows インターネット ネーム サービス (WINS) サーバーの IP アドレスが含まれています。
DHCP, Negotiation Traffic UDP 68 上での DHCP (Dynamic Host Configuration Protocol) ネゴシエーション トラフィックの発生を許可するフィルタが含まれています。
ICMP, All Traffic トラブルシューティングを実行する目的で ICMP (Internet Control Message Protocol) が組織内で機能することを許可するフィルタが含まれています。
Secure Subnets List には、組織の内部ネットワーク内のすべてのサブネットが含まれています。 このフィルタ一覧は、特定の分離グループに必要な操作を実装するフィルタ操作に関連付けられています。 この操作は、そのサブネットのすべてのネットワーク トラフィック (IPsec のネゴシエートなど) に対して最も広範なセキュリティを実現する操作です。というのも、他のフィルタ (ICMP 用のフィルタなど) では異なる操作 (許可など) の要求に特化されるためです。 この方法を使用する場合、信頼されていないホストまたは IPsec に対応していないホストがそのサブネット上に存在してはいけないことに注意してください。 フィルタは、受信セキュリティ要件と送信セキュリティ要件の両方を実装する必要があります。 フィルタを定義する場合、この 2 つをミラーとして構成する必要があります。 ミラーリングを使用すると、発信元と宛先で正反対のアドレスが使用された場合、必ずトラフィックが一致します。 フィルタを記述する際、フィルタがミラーリングされていることを示すには "<->" 記号を使用します。 フィルタ操作により IPsec カプセル化のセキュリティ メソッドがネゴシエートされる際には、必ずミラーリングされたフィルタが使用される必要があります。 ##### 発信元アドレスと宛先アドレス 各フィルタには、発信元アドレスと宛先アドレスの設定があります。 Windows XP および Windows Server 2003 には、Windows 2000 よりも多くのアドレス オプションが備わっています。 このプラットフォームがドメインのメンバである場合は、Windows 2000 の設定のみ使用してください。 ここでは、Windows 2000 の設定について説明します。 - **このコンピュータの IP アドレス** : このオプションを指定すると、コンピュータのアドレスが静的 IP アドレスか DHCP によって割り当てられたアドレスかにかかわらず、Active Directory 内の通常の IPsec ポリシーを複数またはすべてのコンピュータに適用できます。 ドメインから集中的に行われるポリシー割り当てをサポートできるように、IPsec では物理ネットワーク インターフェイスのフィルタ構成はサポートされていません。LAN または WAN などのインターフェイス (ダイヤルアップまたは仮想プライベート ネットワーク (VPN) インターフェイスなど) のみがサポートされています。 **\[このコンピュータの IP アドレス\]** を使用すると、IPsec サービスがポリシー適用の準備を行う際に、コンピュータで使用される各 IP アドレスが含まれた特定のフィルタに汎用 IPsec ポリシー フィルタがコピーされます。 また、正しい数のフィルタを維持できるように、IPsec サービスによってアドレス変更および新しいネットワーク インターフェイスの検出が行われます。 コンピュータに 2 つの IP アドレスが設定された 1 枚のネットワーク カードが取り付けられている場合、2 つの異なる IP アドレスを使用した 2 つの異なる IPsec 固有フィルタが作成されます。 - **任意の IP アドレス** : このオプションを指定すると、IPsec フィルタは任意の IP アドレスとの照合を行います。 - **特定の DNS 名** : このオプションを指定すると、指定した DNS 名の IP アドレスが IPsec によって評価され、その IP アドレスを使用したフィルタが作成されます。 管理者がフィルタに IP アドレスを入力した場合と同じになります。 初期フィルタの作成時に DNS 名から還元されて、対応する IP アドレスがフィルタに配置されます。 DNS サーバーのリソース レコードがフィルタに指定する DNS 名として不適切なものである場合、正しくない IP アドレスがフィルタに追加されます。 **注 :** DNS 名は、ポリシーでフィルタが初めて作成されるときのみ評価され、それ以降は評価されません。 DNS 名には、ドメイン内の各ドメイン コントローラの IP アドレスなど数多くの対応する IP アドレスが含まれているため、DNS 名を利用するオプションは、多数のフィルタを作成する必要がある場合に便利です。 特定の DNS 名の IP アドレスの一覧が常に反映されるフィルタを自動的に作成する方法はありません。 - **特定のアドレス** : このオプションを指定すると、トラフィックはフィルタに指定されている IP アドレスと照合されます。 - **特定のサブネット** : このオプションを指定すると、管理者は特定のサブネットを設定することができます。 指定されたサブネット内の IP アドレスはすべて、フィルタに一致します。 このオプションでは、特にサブネットの適用除外リストを作成する場合、そのサブネットの IP アドレスになりすましている悪意のあるユーザーも除外対象となるため、注意が必要です。 **注 :** Windows XP および Windows Server 2003 では、機能が拡張されているため、その他の数多くのオプションと同様にアドレス オプションも追加されています。 同じ IPsec ポリシーを複数のプラットフォームに適用する場合は、ポリシー設計に Windows 2000 のオプションだけが使用されていることを確認する必要があります。 ##### プロトコル 発信元アドレスと宛先アドレスの設定以外にも、特定のプロトコルまたはポートとの照合を行うように各フィルタを構成できます。 既定では、フィルタはすべてのプロトコルおよびすべてのポート上のトラフィックを照合します。 ポートをサポートする特定のプロトコルをフィルタ条件の一部として選択した場合は、発信元ポートと宛先ポートを設定するオプションも利用できるようになります。 ##### 発信元ポートと宛先ポート TCP または UDP ポートとの照合を行うようにフィルタを構成することもできますが、このソリューションでは、ポート固有のフィルタを作成することはお勧めしていません。 ポートのフィルタを実行すると、管理オーバーヘッドがかなり大きくなるとともに IPsec フィルタの構成の複雑さが増し、IKE が正常にセキュリティをネゴシエートするには、クライアント ポリシーとサーバー ポリシーの間で複雑な調整が必要になることがあります。 このソリューションでは、信頼されたコンピュータ間の通信は実際に信頼できるものと想定しているため、フィルタは、ICMP を除くすべてのトラフィックが IPsec でセキュリティ保護されることを許可します。 信頼されたホストでポート フィルタリングを必要とする場合は、**Business\_Requirements.xls** を参照して、IPsec と IPsec 層の上位にあるホストベースのファイアウォール (Windows ファイアウォールなど) を組み合わせると実現できるセキュリティ要件を確認してください。 \[このコンピュータの IP アドレス\] を使用したフィルタの動作に関するいくつかの問題 (付録 A を参照) に対処できるように、このソリューションでは Woodgrove Bank シナリオに Any <-> subnet フィルタを使用します。 複数の Any IP Address <-> A Specific Subnet フィルタで構成されたフィルタ一覧が作成されています。ここには、組織のすべてのサブネットが明示的に一覧化されています。 この方法により、管理者はセキュリティ保護する特定のサブネットを定義できます。 指定したサブネットの外部のトラフィックは、どの IPsec フィルタにも一致せず、プレーンテキストで宛先ホストに送信されます。 フィルタ設計に関するその他のベスト プラクティスについては、Microsoft TechNet Web サイトの IT ショウケース ホワイト ペーパー「[Improving Security with Domain Isolation: Microsoft IT implements IP Security (IPsec)](https://technet.microsoft.com/ja-jp/library/bb735174.aspx)」の「Best Practices」セクション (英語) を参照してください。 ##### 適用除外リストに関する考慮事項 サポート上、技術上、またはビジネス上の理由により、一部のトラフィックは IPsec で保護できません。 また、Windows 以外のオペレーティング システムを実行しているコンピュータでは、IPsec がサポートされていないか、IPsec を容易に展開できないことがあります。 Microsoft Windows NT® 4.0、Windows 95、Windows 98 などの旧バージョンの Windows を実行しているコンピュータでは、グループ ポリシー ベースの IPsec を処理できません。 最後に、Windows 2000 以降を実行している管理対象外のコンピュータは、ポリシーを個々のコンピュータに手動でロール アウトし、Kerberos バージョン 5 プロトコル以外の認証方法 (事前共有キーや証明書など) を使用した場合に限り、IPsec ネゴシエーションに参加できます。 また、Windows 2000 以降を実行しているコンピュータが IPsec を確立するには、ネットワーク接続を確立して、ドメインから IPsec ポリシーを取得できる必要があります。 現時点では、ネットワークへの接続、ドメイン コントローラの検索、およびポリシーの取得を行うには、サポートしているインフラストラクチャ サービスを IPsec セキュリティから除外する必要があります。 このようなサービスには、DNS、WINS などのネーム サービスやドメイン コントローラ自体があります。 このようなインフラストラクチャ サービス以外にも、IPsec をサポートしていない他のサービスが組織内に存在する可能性があります。 たとえば、Advanced Deployment Services (ADS) や Remote Installation Services (RIS) からイメージをダウンロードする必要のあるシン クライアントまたはその他のブートストラップ クライアントは、IPsec をサポートしていません。 このようなサービスを提供するサーバーがネットワーク上に存在する場合は、これを適用除外リストに含めることができるかどうかを確認するか、これを境界分離グループのメンバにして IPsec を使用できないホストからのネットワーク通信を受け付けることができるようにします。 **注 :** ADS、RIS、またはそのようなサービスを提供するサーバーを適用除外リストに含めるか、または境界分離グループのメンバにするかは、リスク要因と管理要因に基づいて決定します。 いずれの場合も、選択した方法を徹底的にテストする必要があります。 IPsec インフラストラクチャに参加できないクライアントがビジネス上の理由により IPsec を使用しているサーバーにアクセスする必要がある場合は、何らかの方法を実装して通信パスを確立できるようにする必要があります。 このガイドで説明しているソリューションでは、除外フィルタ一覧を使用して、許可を通じてこのようなトラフィック要件を制御します。 IPsec ネゴシエーションを使用できない場合でも必要なすべてのホスト通信が行われるように、IPsec インフラストラクチャには適用除外リストが組み込まれています。 適用除外リストを使用すると、適用除外リストのフィルタに一致するトラフィックを許可するという方法で、選択的にトラフィックを除外して IPsec インフラストラクチャに参加させないようにすることができます。 このリストは、IPsec によって実装されるセキュリティ メカニズムをバイパスするため、注意深く設計する必要があります。 たとえば、通常は暗号化によってセキュリティ保護されるサーバー (機密情報の保護が目的) を除外フィルタに含めると、ゲスト コンピュータは IPsec を使用せずに直接サーバーと通信できるようになります。 適用除外リストはフィルタ一覧として実装されるため、一覧のサイズが最小限に抑えられてユーザー インターフェイス (UI) 構成が簡単になります。 たとえば、すべてのドメイン コントローラまたは各ドメインのドメイン コントローラ用のフィルタを含むフィルタ一覧を作成する必要があります。 いくつかのフィルタ一覧を作成するもう 1 つの利点として、各フィルタ一覧の許可の規則を IPsec ポリシーで簡単に有効/無効にできることが挙げられます。 IPsec ポリシーに除外を実装する規則を設計する際には、IPsec で保護しないトラフィックの量を最小限に抑えることが必要なこともありますが、 非常に特殊なフィルタを使用して得られるセキュリティを優先すると、その代償として IPsec ポリシーの複雑さやサイズが増大します。 あるドメインまたはフォレスト内のクライアントが別の信頼されたドメインまたはフォレスト内のサーバーの Kerberos チケットを取得できるようになるには、信頼されたすべてのフォレスト内の*すべての*ドメイン コントローラの IP アドレスを除外する必要があります。 Windows Kerberos クライアントは、それが属しているドメインのドメイン コントローラおよび他のドメインのドメイン コントローラの両方に送信された ICMP、Lightweight Directory Access Protocol (LDAP) UDP 389、Kerberos UDP 88、および TCP 88 トラフィックを必要とします。 ドメイン メンバは、各自のドメインのドメイン コントローラで、Server Message Block (SMB) TCP 445、Remote Procedure Call (RPC)、LDAP TCP 389 などのその他の種類のトラフィックも必要とします。 セキュリティ要件が極端に厳しくない場合は、簡略化とフィルタ数の削減のため、ドメイン コントローラの IP アドレスを持つ "すべてのトラフィック" の除外を実装します。 TCP ポート 23 を使用して UNIX システムにアクセスする送信 Telnet などのように、特定のアプリケーション トラフィックを宛先アドレスではなくポートで除外して、アドレス一覧の保守を行わずに済ませたい場合があります。 たとえば、除外する送信先が次のようなものであるとします。     My IP Address to Any IP address, TCP, src port Any, dst port 23, mirrored この場合、対応する受信フィルタは次のようになります。     Any IP Address to My IP address, TCP, src port 23, dst port Any この受信フィルタを使用した場合、Telnet 接続要求からの応答を受信できますが、攻撃者が IPsec 認証要件をバイパスしてホスト上の開いているポートにアクセスできるようにもなります。 このフィルタ設計を使用する場合、組織はそのような潜在的な攻撃のセキュリティ リスクを注意深く評価する必要があります。 宛先 IP アドレスを指定すれば、リスクを最小限に抑えることができます。 Kerberos 認証プロトコルの既定の除外を無効にした場合も、これと同じ状況になります。 既定の除外が設計およびセキュリティに与える影響の詳細については、マイクロソフト サポート技術情報 [811832](https://support.microsoft.com/?kbid=811832) および [810207](https://support.microsoft.com/?kbid=810207) を参照してください。 既定の除外が有効になっていないという仮定に基づいて IPsec ポリシーを設計することをお勧めします。 適用除外リストにシステムのアドレスを含めると、適用除外リストを実装するすべての IPsec ポリシーの IPsec ホストとしてそのシステムが参加するのを効果的に除外できます。 組織内のほとんどのクライアント (ゲスト クライアントを含む) は、通常、DHCP、DNS、または WINS などのインフラストラクチャ サービスにアクセスする必要があるため、このようなサービスを提供するサーバーは通常この方法で実装されます。 ##### Woodgrove Bank のフィルタ一覧 Woodgrove Bank の管理者は、第 4 章で得られたトラフィック要件を分析した後、次の表のようなフィルタ一覧を策定しました。 **表 5.2: Woodgrove Bank のフィルタ一覧の例**

フィルタ一覧 フィルタの定義 プロトコルまたはポート
Secure Subnets Any <-> 192.168.1.0/24 Any <-> 172.10.1.0/24 すべて
DNS Exemption List Any <-> 192.168.1.21 Any <-> 192.168.1.22 すべて
Domain Controllers Exemption List Any <-> 192.168.1.21 Any <-> 192.168.1.22 すべて
LOB Application Servers Exemption List Any <-> 192.168.1.10 すべて
WINS Exemption List Any <-> 192.168.1.22 すべて
DHCP, Negotiation Traffic My IP Address <-> Any UDP 発信元 68、宛先 67
ICMP, All Traffic My IP Address <-> Any ICMP のみ
Woodgrove Bank の設計者は、この章の説明に従ってこれらのフィルタ一覧を作成しました。 最初の一覧である Secure Subnets List は、次の 2 つのフィルタで構成されています。 - Any <-> 192.168.1.0/24 - Any <-> 172.10.1.0/24 これらのサブネット フィルタは、受信トラフィックおよび送信トラフィックの両方を照合するようにミラーリングされており、あらゆるプロトコルで始動するように構成されています。 このフィルタ一覧は、適切なフィルタ操作と組み合わされた場合に分離グループを実装します。 Woodgrove Bank の設計者は次に、ICMP ネットワーク トラフィックの適用除外リストを実装することにしました。 このフィルタ一覧は、ICMP ネットワーク トラフィックのためだけに設定された単一のミラーリングされたフィルタ (My IP Address <-> Any) で構成されています。 これにより、IPsec セキュリティ アソシエーション (SA) のネゴシエートが行われているかどうかに関係なく、管理者は Ping ユーティリティを環境内のトラブルシューティング ツールとして使用することができます。 また、このソリューションを正しく動作させるにはパスの最大転送単位 (MTU) を検出する必要があるという理由からも、このアプローチは必要でした。 DHCP トラフィックに関しては、Woodgrove Bank の設計者は UDP ポート 68 用の新しいフィルタを作成して、DHCP クライアントが DHCP サーバーからのトラフィックを受信できるようにしました。 また Woodgrove Bank には、IPsec インフラストラクチャに参加できないサーバー上で実行されている業務 (LOB) アプリケーションが一部存在しました。 これらのサービスに対応するため、LOB Application Servers Exemption List という新しい除外フィルタ一覧を作成し、LOB アプリケーションをホストしているシステム用に Any <-> 192.168.1.10 フィルタを追加しました。 そして Woodgrove Bank の設計チームは、インフラストラクチャ サービスを特定して対応する除外フィルタ一覧を作成し、分離グループの IPsec 設定に関係なくすべてのクライアントがこれらのサービスを提供するサーバーに直接通信できるようにしました。 適用除外リストは、具体的には次のサービス用に作成されました。 - **DNS** : このリストにより DNS サーバーが除外され、ネットワーク内のすべてのクライアントがドメイン名の参照を実行できるようになります。 - **ドメイン コントローラ** : このリストにより、ドメイン参加システムはドメイン コントローラで認証されるようになります。 - **WINS** : このリストにより、ホストのデバイスは WINS サーバー上の NetBIOS 名を具体的に参照できるようになります。 これらのフィルタ一覧は、Any <-> Specific IP Address を定義するミラーリングされたフィルタで構成されており、そのフィルタはあらゆるプロトコルで始動するように構成されています。 適用除外リストに含めるコンピュータの数は最小限に抑える必要があります。これは、リストに含めたコンピュータに送信されるトラフィックはすべて除外対象となるため、適用除外リストのどのコンピュータからでも分離ドメイン内のすべての信頼されたホストに TCP/IP 経由でフルアクセスできるようになるためです。 したがって、この方法を採用した場合、他の場合よりも攻撃対象となる領域が増大します。 除外した IP アドレスからの受信トラフィックのリスクを軽減する要件の詳細については、**Business\_Requirements.xls** スプレッドシート (Tools and Templates フォルダ内) を参照してください。 Woodgrove Bank は、IP アドレスが同じにもかかわらず、DNS サーバー用とドメイン コントローラ用の 2 つの一覧を個別に使用することにしました。 この方法を採用したのは、両方のフィルタ一覧にまったく同じ操作である "許可" が含まれると考えられるためです。 また、Woodgrove の運用ネットワークでは、一部の領域でドメイン コントローラではない DNS サーバーが使用されています。 DHCP 用のフィルタは、特定の宛先 IP アドレスが指定されるのではなく、すべての DHCP クライアントの送信トラフィックを照合するように設計されました。 このフィルタをミラーリングすると、DHCP サーバーからの応答が許可されます。 既に説明したように、発信元ポート 67 を使用する IP アドレスから送られる受信攻撃も許可されます。 ただし、受信攻撃はクライアントの宛先ポート 68 に限定され、これは DHCP クライアントによって使用されています。 Woodgrove Bank がこの設計を採用したのは、すべての DHCP サーバーに対してフィルタを設定することを避けるためであり、リスク評価の結果によれば、DHCP クライアント ポートに対する受信攻撃のリスクまたは不正な DHCP サーバーのリスクがそれほど高いものではなかったためでもあります。 ここでは、各フィルタの詳細については説明しません。 ただし、IPsec の監視ツールやコマンドライン ツールを使用した場合、フィルタ一覧内の情報ではなく各フィルタの説明が表示されるため、フィルタの説明フィールドを使用して各フィルタを注意深く定義しておくことをお勧めします。 #### IPsec フィルタ操作 フィルタ操作は、IP パケットがフィルタ一覧内のフィルタに一致した後の処理方法を定義します。 フィルタ操作は、さまざまな分離グループを実装する際の基礎となります。 Windows オペレーティング システムには 3 種類の既定のフィルタ操作が用意されていますが、これらを削除して新しいフィルタ操作を作成することをお勧めします。そうしておくと、設計の一部として作成した操作のみを使用できるようになります。 各フィルタ操作は、名前、説明、およびセキュリティ メソッドで構成されています。 ##### 名前 フィルタ操作によって行われる動作を表す名前を指定します。 ##### 説明 説明フィールドに、フィルタ操作の動作に関する詳細な説明を入力します。 ##### セキュリティ メソッド フィルタ操作内に実装されるセキュリティ メソッドは、フィルタ一覧内の関連付けられているフィルタに一致するパケットを処理するための要件によって決定します。 次の 3 つのオプションがあります。 - **ブロック** : 関連付けられているフィルタに一致する IP パケットをブロックします。 つまり、パケットは破棄または無視されます。 - **許可** : 関連付けられているフィルタに一致する IP パケットが IPsec 層を通過することを許可します。これ以外に IPsec による処理は行われません。 - **ネゴシエート** : 送信パケットがフィルタ条件に一致する場合、IPsec によるネゴシエートが行われ、フィルタ操作内にあるセキュリティ メソッドが順番に試行されます。 セキュリティ メソッドは、一覧内で優先順位が高い順に上から並んでいます。 各セキュリティ メソッドでは、整合性の使用、暗号化の有効化、機能させる暗号化アルゴリズムの種類を定義できます。 フィルタに一致する受信パケットがネゴシエート操作でどのように処理されるかは、**\[セキュリティで保護されていない通信を受け付けるが、常に IPSec を使って応答\]** の設定によります。 次の表は、各セキュリティ メソッドで利用可能な暗号化オプションを示したものです。 **表 5.3: セキュリティと暗号化オプション**

セキュリティ メソッド 暗号化オプション 説明
認証ヘッダー (AH) MD5 SHA-1 IP ペイロード (データ) と IP ヘッダー (アドレス) の両方の整合性と認証が、暗号化なしで提供されます。 AH は、NAT を実行しているデバイスを走査できません。
ESP - 整合性 <なし> MD5 SHA-1 IP ペイロード (データ) に対してのみ、データ整合性と認証が提供されます。 暗号化とともに使用することも、暗号化なしで使用することもできます。 認証なしで ESP を使用することはお勧めしません。
ESP - 暗号化 <なし> 3DES DES DES または 3DES の場合、IP ペイロード (データ) の暗号化が提供されます。 暗号化が不要な場合は、Null 暗号化アルゴリズムとともに使用できます。
Windows 2000 SP4、Windows XP SP2、および Windows Server 2003 の IPsec 実装では現在、L2TP/IPsec VPN クライアント トンネルの NAT-T のサポートに加え、IPsec トランスポート モード ESP の NAT-T テクニックがサポートされています。 Windows 2000 SP4 では、NAT-T を更新する必要があります。 Windows 2000 および Windows XP の IPsec トランスポート モード NAT-T のサポートは、Windows 2000 および Windows XP の SP2 以前のバージョンでは制限があります。これは、IPsec で保護された TCP トラフィックの TCP パス MTU (PMTU) 検出がサポートされていないためです。 Windows Server 2003 では、これがサポートされています。 NAT-T テクニックでは、ESP のカプセル化に IP ヘッダーの後ろの UDP ヘッダーが使用されます。 NAT がパスに存在していると IKE によって自動的に検出され、セキュリティ メソッド リストで ESP が許可されている場合は UDP-ESP が使用されます。 また、現在の Windows IPsec 実装では、米国政府の Advanced Encryption Standard (AES) はサポートされていません。 これは、将来のバージョンの Windows で変更される予定です。 AH および ESP では、次の暗号化オプションを利用できます。 - **MD5** : このハッシュ アルゴリズムは、128 ビットの暗号化キーを使用してパケット コンテンツのダイジェストを生成します。 MD5 は、米国政府のセキュリティ規定の承認されたアルゴリズムではありません。 - **SHA-1** : このハッシュ アルゴリズムは、160 ビットというより長い暗号化キーを使用してパケット コンテンツのダイジェストを生成します。 SHA-1 のキーの長さが長いほどセキュリティは強力になりますが、処理にかかるオーバーヘッドも大きくなります。 SHA-1 は、米国政府のセキュリティ規定の承認されたアルゴリズムです。 ESP は、どの暗号化アルゴリズムも使用しないように構成できます。その場合、データ整合性と認証のみが適用されます。 この構成は一般的に ESP-Null と呼ばれ、通信接続が確立され ESP パケットに含まれて転送される IP パケットのデータ部分の整合性チェックが実行される前に、ホストを認証することができます。 ESP はまた、IP パケットのデータ セクションを暗号化することもできます。 使用できる暗号化オプションには次の 2 つがあります。 - **DES** : このオプションでは単一の 56 ビット キーが使用され、各ブロックの処理が 1 回ずつ行われます。 DES は、Request for Comment (RFC) に準拠するために提供されます。 DES 暗号化は攻撃者によって侵害されやすくなっているため、DES の使用はお勧めできません。 - **3DES** : このオプションでは固有の 56 ビット キーが 3 つ使用され、各ブロックの処理が 3 回ずつ行われます。 DES もサポートされていますが、3DES の方が安全性が高いためこれを使用することをお勧めします。 ただし、3DES は DES よりも処理にかかるオーバーヘッドが大きく、時間も長くかかります。 非常に高いセキュリティ要件に対応する必要がある場合は、AH プロトコルと ESP プロトコルを互いに組み合わせることができます。 たとえば、データ暗号化だけでなく IP ヘッダーの整合性も明確な要件となっている場合は、AH - SHA-1 整合性および ESP - 3DES 暗号化を使用するセキュリティ メソッドを設定できます。 データ整合性のみを必要とする場合は、ESP-null - SHA-1 を使用します。 セキュリティ オプションはさまざまに組み合わせて選択できますが、AH はデータ整合性とアドレス ヘッダー整合性の両方を提供することに注意してください。 AH と ESP を併用しても、パケット データの整合性保護能力は向上せず、パケットの処理に伴う作業負荷が増えるだけです。 また、AH に ESP を組み合わせても、AH の NAT バリヤの問題を解決することはできません。 したがって、AH と ESP の併用は、最高のセキュリティを必要とする環境にのみ適切な方法です。 フィルタ操作のセキュリティ メソッドを設計する際には、入念に計画する必要があります。 2 台のコンピュータ間でのネゴシエートを正常に行うには、それぞれのフィルタ操作に共通のセキュリティ メソッドが少なくとも 1 つ含まれている必要があります。 各フィルタ操作には、さまざまな種類のネゴシエーションに対応できるように複数のネゴシエーション方法が含まれていることができます。 たとえば、あるシステムで通常 ESP-Null のネゴシエートのみが行われる場合でも、フィルタ操作には ESP-3DES 用のネゴシエーション方法も含まれていることがあります。 このようにしておくことで、システムは必要に応じて 3DES 暗号化接続をネゴシエートすることができます。 セキュリティ メソッドを選択できるだけでなく、必要に応じて各セキュリティ メソッドのセッション キーの設定を行うこともできます。 既定の設定では、100 メガバイト (MB) のデータが通過したときに、または 1 時間経過後に IPsec SA の有効期間が切れるように構成されています。 これらの設定では、IPsec セキュリティ アソシエーションの新しいペアが IKE クイック モードによって再ネゴシエートされる時期が制御されています。 IKE クイック モード処理は、"キーの再作成" とも呼ばれていますが、実際には既存の IPsec SA ペアのキーを更新するだけです。 有効期間が切れた場合、IPsec はパケットを破棄する必要があります。したがって、バイト単位または秒単位のいずれかの有効期間が切れるかなり前に再ネゴシエートが試行されます。 有効期間の値の設定が低すぎると、パケットが失われる可能性があります。 同様に、多数のクライアントと IPsec SA を維持しているサーバーでは、CPU 使用率が増加する場合があります。 IPsec SA を更新すると、仮に攻撃者がセッション キーの 1 つを判別できた場合でも通信全体を解読することはできなくなります。 有効期間を増やすと、攻撃者はセッション キーに関する情報をさらに多く入手できるようになります。 したがって、運用上必要でない限り、有効期間は変更しないようにしてください。また、高度な暗号化攻撃に対する適切な保護レベルを定義する特定のセキュリティ要件については、記録しておくことができます。 ##### セキュリティ ネゴシエーション オプション IPsec ポリシーでは、次のセキュリティ ネゴシエーション オプションを設定できます。 - 受信パススルー - クリアテキストにフォールバック - セッション キーの PFS (Perfect Forward Secrecy) を使う ###### 受信パススルー 受信パススルー オプションは、内部サーバー ポリシーで使用するために作成されたもので、これを使用すると、侵入不可能な "既定の応答" 規則をクライアント ポリシーが使用できるようになります。 このオプションを有効にした場合、受信フィルタに一致するプレーンテキスト接続要求が受理されます。 サーバーの接続応答が送信フィルタに一致すると、クライアントへの IKE メイン モード ネゴシエーション要求が始動します。 このオプションを有効にすると受信攻撃が IPsec 層を通過できるようになるため、インターネットに直接接続されているコンピュータでは、このオプションを有効にしないでください。 また、このオプションを有効にすると、任意の受信パケットの発信元 IP に対してサーバーが IPsec SA ネゴシエーションを試行します。 そのため、攻撃者は発信元 IP アドレスを偽装し、IKE に莫大な数の無効な IP アドレスとのネゴシエーションを試行させることで、サーバーにサービス拒否を発生させることができます。 受信パススルーを有効にするには、**\[フィルタ操作の管理\]** ダイアログ ボックスの **\[セキュリティで保護されていない通信を受け付けるが、常に IPSec を使って応答\]** チェック ボックスをオンにします。 **注 :** クライアントに割り当てたポリシーが既定の応答規則を有効にしない場合は、IPsec 通信の応答は発生しないため、このオプションを無効にしてください。 また、これはサービス拒否攻撃の攻撃経路として利用されることもあります。 ###### クリアテキストにフォールバック このオプションでは、最初の IKE メイン モード ネゴシエーションが宛先コンピュータから応答を受信しなかった場合に、発信元コンピュータが IPsec による保護なしでトラフィックを送信できるようにするかどうかを制御します。 IPsec をサポートしていないホストは、IKE ネゴシエーション要求に対して IKE を使用して応答することができません。 このようなホストのことを "IPsec に対応していない" コンピュータといいます。 ただし、IKE メイン モード応答が受信されない場合でも、コンピュータが IPsec に未対応であるとは限りません。 IPsec 対応コンピュータにアクティブな IPsec ポリシーが適用されていないこともあります。 また、アクティブな IPsec ポリシーに許可とブロックの操作しか定義されていない場合もあれば、 アクティブな IPsec ポリシーが発信元コンピュータの IP アドレスとネゴシエートするように設計されていない場合もあります。 IPsec 用語では、IPsec を使用しないネットワーク トラフィックのことを、"*プレーンテキスト*" と呼びます。 対象コンピュータからの応答が 3 秒以内に返されない場合は、ソフト セキュリティ アソシエーション (ソフト SA) が作成され、プレーンテキストで通信が開始されます。 初めて展開を行う際には、IPsec が有効になっていないホストにクライアントが通信できるように、このオプションを有効にすることをお勧めします。 また、トラブルシューティングのために IPsec サービスを停止する場合、このオプションを使用するとプレーンテキスト接続を一時的に再確立することができます。 対象コンピュータから IKE 応答が送信されず、何らかの理由で IKE ネゴシエーション中に障害が発生した場合は、発信元コンピュータの IPsec によって送信パケットが破棄され、事実上通信はブロックされます。 このオプションを有効にするには、**\[フィルタ操作の管理\]** ダイアログ ボックスの **\[IPSec に対応していないコンピュータとセキュリティで保護されていない通信を許可\]** チェック ボックスをオンにします。 **注 :** このオプションの動作は、Windows 2000 SP3 以降、Windows XP SP1、または Windows Server 2003 を実行しているコンピュータでは変更されています。 このオプションのみを有効にした場合、有効にしたシステムではセキュリティ保護されない状態で通信を開始できますが、IPsec に対応していないシステムからの通信要求は受理されません。 IPsec に対応していないシステムからの要求に応答して、そのシステムとの通信を開始する必要がある場合は、**\[セキュリティで保護されていない通信を受け付けるが、常に IPSec を使って応答\]** オプションと **\[IPSec に対応していないコンピュータとセキュリティで保護されていない通信を許可\]** オプションを両方ともオンにする必要があります。 Windows 2000 または Windows XP を実行しているシステムに適切な Service Pack が適用されていない場合は、**\[セキュリティで保護されていない通信を受け付けるが、常に IPSec を使って応答\]** オプションがオンになっていなくても、**\[IPSec に対応していないコンピュータとセキュリティで保護されていない通信を許可\]** オプションがオンになっていると、クライアントはセキュリティ保護されていない通信要求を受理します。 このような動作になるのは、**\[IPSec に対応していないコンピュータとセキュリティで保護されていない通信を許可\]** オプションをオンにした場合、関連付けられている受信フィルタが受信パススルー フィルタとして処理されるためです (これは、**\[セキュリティで保護されていない通信を受け付けるが、常に IPSec を使って応答\]** オプションをオンにした場合と同じ動作です)。 ###### セッション キーの PFS (Perfect Forward Secrecy) を使う このオプションでは、すべてのセッション キーの生成にマスタ キー マテリアルを使用できるようにするか、最初のセッション キーを生成するときだけにするかを決定します。 このオプションを有効にすると、マスタ キーは 1 回しか使用できなくなるため、新たにセッション キーの再ネゴシエーションを行うたびに新しいキー交換を実行する必要があります。これによって新しいマスタ キーを生成してから、セッション キーを生成します。 このような要件があるため、マスタ キーが侵害された場合でも、攻撃者は追加のセッション キーを生成してトラフィック ストリームを解読することはできません。 ただし、各セッション キーの更新間隔でキー交換を実行するとオーバーヘッド コストが増加するため、このオプションを有効にすることはお勧めできません。 受信パススルー、クリアテキストにフォールバック、セッション キーおよびマスタ キーの PFS (Perfect Forward Secrecy) の各オプションの詳細については、Microsoft ダウンロード センター Web サイトの「[Using Microsoft Windows IPSec to Help Secure an Internal Corporate Network Server](https://www.microsoft.com/download/details.aspx?familyid=a774012a-ac25-4a1d-8851-b7a09e3f1dc9&displaylang=en)」の「Security Negotiation Options」セクション (英語) を参照してください。 ##### Woodgrove Bank の IPsec フィルタ操作 次の表に、Woodgrove Bank シナリオのさまざまな分離グループを実装するのに使用されたフィルタ操作の名称と説明を示します。 **表 5.4: IPsec フィルタ操作と説明**

フィルタ操作 説明
IPsec – Block フィルタに一致するトラフィックをブロックします。
IPsec – Permit フィルタに一致するトラフィックを許可します。
IPsec – Request Mode (Accept Inbound, Allow Outbound) ホストは、IPsec またはプレーンテキストのいずれかの受信パケットを受け付けます。 送信トラフィックの場合は、IKE ネゴシエーションが開始され、応答がない場合はクリアテキストへのフォールバックが許可されます。 このフィルタ操作は、境界分離グループの構成に使用されます。
IPsec – Secure Request Mode (Ignore Inbound, Allow Outbound) ホストは、パケットが IPsec によってセキュリティ保護されている場合に限り受信 TCP/IP アクセスを許可し、IPsec 以外の受信パケットを無視します。 送信トラフィックの場合は、IKE ネゴシエーションが開始され、応答がない場合はクリアテキストへのフォールバックが許可されます。 このフィルタ操作は、信頼されていないホストへの送信が許可されている分離ドメインの実装に使用されます。
IPsec – Full Require Mode (Ignore Inbound, Disallow Outbound) ホストは、受信パケットおよび送信パケットの両方に対して IPsec でセキュリティ保護された通信を要求します。 このフィルタ操作は、すべての通信が IPsec で保護されるフォールバックのない分離グループの実装に使用されます。
IPsec – Require Encryption Mode (Ignore Inbound, Disallow Outbound) ホストは、パケットが IPsec ESP 3DES 暗号化によってセキュリティ保護されている場合に限り受信 TCP/IP アクセスを許可し、IPsec 以外の受信パケットを無視します。 送信トラフィックの場合は、IPsec ESP 3DES 暗号化を要求する IKE ネゴシエーションが開始されます。 このフィルタ操作は、暗号化分離グループの実装に使用されます。
最初の 2 つのフィルタ操作は単純なものです。 ブロック フィルタ操作は、この操作に関連付けられているフィルタ一覧内のフィルタに一致するすべてのトラフィックをドロップします。 許可フィルタ操作は、関連付けられているフィルタ一覧の中に一致するフィルタがある場合、トラフィックの発生を許可します。 表 5.4 の残りの 4 つのフィルタ操作は、Woodgrove Bank シナリオの分離グループを実装するのに使用されています。 Woodgrove Bank の管理者には、実装するセキュリティ分離グループが 4 つあります。 この構成を展開するには、許可とブロックを行うフィルタ操作以外に、カスタム セキュリティ ネゴシエーション方法が定義されたフィルタ操作を少なくとも 3 つ定義する必要があります。 Woodgrove Bank には、特定のセキュリティ分離グループ内でコンピュータを互いに分離するような追加要件はありません。 Woodgrove Bank は、環境を実装するには次の表にある 4 種類のフィルタ操作のネゴシエーションで十分であると判断しました。 **表 5.5: サポートされているセキュリティ メソッド**

フィルタ操作 サポートされているセキュリティ メソッド
IPsec – Request Mode (Accept Inbound, Allow Outbound) ESP – SHA-1, <None> ESP – SHA-1, 3DES
IPsec – Secure Request Mode (Ignore Inbound, Allow Outbound) ESP – SHA-1, <None> ESP – SHA-1, 3DES
IPsec – Full Require Mode (Ignore Inbound, Disallow Outbound) ESP – SHA-1, <None> ESP – SHA-1, 3DES
IPsec – Require Encryption Mode (Ignore Inbound, Disallow Outbound) ESP – SHA-1, 3DES
NAT を使用するネットワーク デバイスが組織内に存在するため、Woodgrove Bank は AH ではなく IPsec ESP を使用しています。 Woodgrove Bank には、組織の一部のサーバーに暗号化を実装するという要件もありました。 したがって、すべてのポリシーで暗号化を使用するオプションが必要でした。 そのような理由から、Woodgrove Bank は、IPsec ESP のみに基づいてセキュリティを実装することにしました。 ESP の整合性に関しては、Woodgrove Bank は MD5 ではなく SHA-1 を使用してセキュリティを強化することにしました。これには、承認されたアルゴリズムの使用など、財務情報の処理に関する米国政府の規制に対応する必要があるという理由もありました。 Woodgrove Bank は、PFS はどのフィルタ操作にも実装しないことにしました。PFS を使用する必要があるような特定のセキュリティ上の脅威が存在しなかったためです。 この決定には、キーの再ネゴシエーションによるコンピュータのパフォーマンスの低下を回避するという目的もありました。 ##### 分離ドメインのフィルタ操作 分離ドメインを実装するために、Woodgrove Bank の管理者は、IPSEC - Secure Request Mode (Ignore Inbound, Allow Outbound) フィルタ操作を作成しました。 Woodgrove Bank には、分離ドメイン内のホストと他の分離グループ内のホストとの通信に関して、いくつかのビジネス要件があります。 したがって、分離ドメイン内のクライアントは、このガイドの第 4 章の表 4.5 および 4.6 に記載されている設定の結果、次の操作を実行します。 - フォールバックのない分離グループ内のホストと通信を開始する - フォールバックのない分離グループ内のホストからの通信を受け付ける - 暗号化分離グループ内のホストと通信を開始する - 暗号化分離グループ内のホストからの通信を受け付ける - 境界分離グループ内のホストと通信を開始する - 境界分離グループ内のホストからの通信を受け付ける - 信頼されていないシステムへの通信を開始する 分離ドメイン内のクライアントは、信頼されていないシステムからの通信を受け付けることはできません。 IPsec ポリシーは、フィルタとフィルタ操作を使用して、受信 IP パケットと送信 IP パケットを遮断および制御します。 IKE は両方のコンピュータを認証しますが、最初の接続要求が送信された時点では、特定の IP アドレスを使用しているコンピュータのグループ メンバシップは認知されていません。 したがって、特定の識別グループまたは分離グループと特定の方法で通信を開始するように、IPsec と IKE を具体的に構成することはできません。 また、これらの分離グループのメンバであるコンピュータは、内部ネットワークの任意の場所に配置できます。 したがって、IP アドレスを使用して分離グループまたは分離グループに近いものを定義することはできません。 IPsec ポリシーのこのような要件を実装するには、すべての内部サブネットを特定するフィルタ一覧とともに動作するようにフィルタ操作を設計する必要があります。 上述の要件は、次の 2 つの基本的な動作に分類することができます。 - 送信 : 対応するフィルタ (すべての内部サブネット) にパケットが一致する場合、IPsec ESP (ESP-null が優先、ESP - SHA-1 - 3DES を含む) を使用したトラフィックのセキュリティ保護を試行する IKE ネゴシエーション要求を開始します。 宛先対象のホストが IKE に応答しない場合は、クリアテキストへのフォールバックが許可されます。 - 受信 : 対応するフィルタ (すべての内部サブネット) にパケットが一致する場合、有効な IPsec ESP パケット内で既にセキュリティ保護されていない限り、トラフィックは無視されます。 暗号化分離グループとの通信を有効にするため、セキュリティ メソッドには、暗号化分離グループ用に定義されているセキュリティ メソッド (ESP - SHA-1 - 3DES アルゴリズム) が含まれています。 暗号化セキュリティ ネゴシエーション方法の詳細については、この章で後述する「暗号化分離グループのフィルタ操作」を参照してください。 Woodgrove Bank では、分離ドメイン内のトラフィック、および境界分離グループとフォールバックのない分離グループのトラフィックに ESP-null と SHA-1 を使用しています。 フィルタ操作の **\[セキュリティで保護されていない通信を受け付けるが、常に IPSec を使って応答\]** オプションを無効にして、受信プレーンテキストが無視されるようにする必要があります。 こうしておくと、分離ドメイン内のホストは、IPsec 環境に参加していないコンピュータから送信されたトラフィックを受け付けなくなります。 IPSEC - Secure Request Security (Ignore Inbound, Allow Outbound) フィルタ操作は、分離ドメインのメンバが信頼されていないシステムとの通信を開始できるように構成されています。 この動作を実装するには、フィルタ操作の **\[IPSec に対応していないコンピュータとセキュリティで保護されていない通信を許可\]** オプションを有効にします。 分離ドメイン内の信頼されたホストが、信頼されていないホスト (IPsec に対応していない別のシステム) に送信接続を開始した場合、IPsec ソフト SA が確立されてトラフィック フローの停止後 5 分間に渡りアクティブになります。 したがってこの時間内、その信頼されていないシステムは、信頼されたホストに対して新しいプレーンテキスト接続を逆に開始することができます。 ソフト SA がタイムアウトになると、信頼されたホストは、そのシステムから送信されたプレーンテキスト トラフィックを受け付けなくなります。 IPsec フィルタリングおよびソフト SA サポートは、多くのファイアウォールと異なり、ステートフル フィルタリングなど接続固有の保護を実行するようには設計されていません。 ソフト SA は、関連付けられているフィルタに一致するすべてのトラフィックを許可します。 このプロセスの詳細については、「付録 A: IPsec ポリシーの概念の概要」の「IKE メイン モード SA および IPSec SA」を参照してください。 ##### 境界分離グループのフィルタ操作 境界分離グループを実装するために、Woodgrove Bank の管理者は、IPSEC – Request Mode (Accept Inbound, Allow Outbound) フィルタ操作を作成しました。 Woodgrove Bank には、境界分離グループ内のホストと他の分離グループ内のホストとの通信に関して、いくつかのビジネス要件があります。 したがって、境界分離グループ内のクライアントは、このガイドの第 4 章の表 4.5 および 4.6 に記載されている設定の結果、次の操作を実行できます。 - フォールバックのない分離グループ内のホストと通信を開始する - フォールバックのない分離グループ内のホストからの通信を受け付ける - 分離ドメイン内のホストと通信を開始する - 分離ドメイン内のホストからの通信を受け付ける - 暗号化分離グループ内のホストからの通信を受け付ける - 信頼されていないシステムと通信を開始する - 信頼されていないシステムからの通信を受け付ける IPsec ポリシーのこのような要件を実装するには、すべての内部サブネットを特定するフィルタ一覧とともに動作するようにフィルタ操作を設計する必要があります。 上述の要件は、次の 2 つの基本的な動作に分類することができます。 - 送信 : 対応するフィルタ (すべての内部サブネット) にパケットが一致する場合、IPsec ESP (ESP-null が優先、ESP - SHA-1 - 3DES を含む) を使用したトラフィックのセキュリティ保護を試行する IKE ネゴシエーション要求を開始します。 宛先対象のホストが IKE に応答しない場合は、クリアテキストへのフォールバックが許可されます。 - 受信 : 対応するフィルタ (すべての内部サブネット) に一致するプレーンテキスト パケットを受け付けます。 Woodgrove Bank では、分離ドメインおよびフォールバックのない分離グループとの間でトラフィックを開始し受け付けるための要件を満たすために、分離ドメインとフォールバックのない分離グループで使用するセキュリティ ネゴシエーション方法をフィルタ操作に含めました。 Woodgrove が選択した共通のセキュリティ ネゴシエーション方法は、整合性を実現する ESP - SHA-1 です。 境界分離グループ内のホストは、信頼されていないシステムと通信を行うことを許可されています。 これを可能にするため、Woodgrove Bank の管理チームは、このフィルタ操作の **\[IPSec に対応していないコンピュータとセキュリティで保護されていない通信を許可\]** オプションと **\[セキュリティで保護されていない通信を受け付けるが、常に IPSec を使って応答\]** オプションの両方を有効にしました。 両方のオプションを有効にすることで、ホストがセキュリティ保護されていない受信トラフィックを受け付け、セキュリティ保護されていない送信トラフィックに関してはクリアテキストへのフォールバックが行われるようにしました。 ##### フォールバックのない分離グループのフィルタ操作 フォールバックのない分離グループを実装するために、Woodgrove Bank の管理者は、IPSEC - Full Require Mode (Ignore Inbound, Disallow Outbound) フィルタ操作を作成しました。 Woodgrove Bank には、フォールバックのない分離グループ内のホストと他の分離グループ内のホストとの通信に関して、いくつかのビジネス要件があります。 したがって、フォールバックのない分離グループ内のクライアントは、次の操作を実行できます。 - 分離ドメイン内のホストと通信を開始する - 分離ドメイン内のホストからの通信を受け付ける - 暗号化分離グループ内のホストと通信を開始する - 暗号化分離グループ内のホストからの通信を受け付ける - 境界分離グループ内のホストと通信を開始する - 境界分離グループ内のホストからの通信を受け付ける フォールバックのない分離グループ内のクライアントは、信頼されていないシステムに通信を開始することも、信頼されていないシステムからの通信を受け付けることもできません。 IPsec ポリシーのこのような要件を実装するには、すべての内部サブネットを特定するフィルタ一覧とともに動作するようにフィルタ操作を設計する必要があります。 上述の要件は、次の 2 つの基本的な動作に分類することができます。 - 送信 : 対応するフィルタ (すべての内部サブネット) にパケットが一致する場合、IPsec ESP (ESP-null が優先、ESP - SHA-1 - 3DES を含む) を使用したトラフィックのセキュリティ保護を試行する IKE ネゴシエーション要求を開始します。 宛先対象のホストが IKE に応答しない場合も、クリアテキストへのフォールバックは許可*されません*。 - 受信 : 対応するフィルタ (すべての内部サブネット) にプレーンテキスト パケットが一致する場合、それらを無視します。 暗号化分離グループとの通信を有効にするため、セキュリティ ネゴシエーション方法には、暗号化分離グループ用に定義されている暗号化ネゴシエーション方法が含まれています。 暗号化セキュリティ ネゴシエーション方法の詳細については、この章の次のセクション「暗号化分離グループのフィルタ操作」を参照してください。 Woodgrove Bank は、境界分離グループとフォールバックのない分離グループに送信されるトラフィックに、整合性に関するセキュリティ ネゴシエーション方法として ESP - SHA-1 を使用しています。 フォールバックのない分離グループを作成するため、フィルタ操作の **\[セキュリティで保護されていない通信を受け付けるが、常に IPSec を使って応答\]** チェック ボックスはオフになっています。 こうすることで、フォールバックのない分離グループ内のホストは、すべての受信トラフィックと送信トラフィックを IPsec でセキュリティ保護することになります。 また、IPsec 環境に参加していないコンピュータから送信されたトラフィックは受け付けません。 IPSEC - Full Require Mode (Ignore Inbound, Disallow Outbound) フィルタ操作は、このフィルタ操作を使用するコンピュータが IPsec インフラストラクチャに参加していないコンピュータに対して通信を開始することを許可しません。 この要件を適用するため、**\[IPSec に対応していないコンピュータとセキュリティで保護されていない通信を許可\]** オプションは無効になっています。 ##### 暗号化分離グループのフィルタ操作 Woodgrove Bank は、ベースとなる整合性プロトコルには ESP、暗号化オプションには SHA-1 を選択しました。 また、暗号化分離グループ内のホストは、分離ドメインおよびフォールバックのない分離グループ内のホストと通信を行う必要があります。 フィルタ操作は、情報を暗号化するセキュリティ ネゴシエーション方法が含まれるように構成されています。 Woodgrove Bank には、暗号化分離グループ内のホストと他の分離グループ内のホストとの通信に関して、いくつかのビジネス要件があります。 したがって、暗号化分離グループ内のクライアントは、表 4.6 の設定の結果、次の操作を実行できます。 - 分離ドメイン内のホストと通信を開始する - 分離ドメイン内のホストからの通信を受け付ける - フォールバックのない分離グループ内のホストと通信を開始する - フォールバックのない分離グループ内のホストからの通信を受け付ける - 境界分離グループ内のホストと通信を開始する 暗号化分離グループ内のコンピュータは、境界分離グループ内のホストからの通信を受け付けることを禁止されています。 IPsec ポリシーのこのような要件を実装するには、すべての内部サブネットを特定するフィルタ一覧とともに動作するようにフィルタ操作を設計する必要があります。 上述の要件は、次の 2 つの基本的な動作に分類することができます。 - 送信 : 対応するフィルタ (すべての内部サブネット) にパケットが一致する場合、IPsec ESP - SHA-1 - 3DES を使用したトラフィックのみのセキュリティ保護を試行する IKE ネゴシエーション要求を開始します。 宛先対象のホストが IKE に応答しない場合も、クリアテキストへのフォールバックは許可*されません*。 - 受信 : 対応するフィルタ (すべての内部サブネット) にプレーンテキスト パケットが一致する場合、それらを無視します。 IPsec ESP - SHA-1 - 3DES を許可する信頼されたホストからの IKE ネゴシエーション要求だけを受け付けます。 暗号化分離グループ内のクライアントは、境界分離グループからの通信を受け付けることができず、信頼されていないシステムとは通信を開始することも受け付けることもできません。 分離ドメインとの通信を有効にするため、IPSEC - Require Encryption Mode (Ignore Inbound, Disallow Outbound) で使用されている暗号化セキュリティ ネゴシエーション方法は、IPSEC - Secure Request (Ignore Inbound, Allow Outbound) フィルタ操作と IPSEC - Full Require Mode (Ignore Inbound, Disallow Outbound) フィルタ操作にも含まれています。 Woodgrove Bank は、DES よりもセキュリティが高く、オーバーヘッド コストも大きい 3DES 暗号化方法を使用しています。 信頼されていないシステムとは通信を受け付けることも開始することもしないという要件があるため、Woodgrove Bank は、**\[セキュリティで保護されていない通信を受け付けるが、常に IPSec を使って応答\]** オプションを有効にしませんでした。 このように構成すると、暗号化分離グループ内のホストは、IPsec 環境に参加していないコンピュータから送信されたトラフィックを受け付けなくなります。 また、**\[IPsec に対応していないコンピュータとセキュリティで保護されていない通信を許可\]** オプションも無効にして、コンピュータが IPsec 環境に参加していないコンピュータとの通信の開始を試行できないようにしました。 境界分離グループのコンピュータからの IPsec 通信をブロックするには、構成を追加する必要がありました。 Woodgrove Bank の管理者は、暗号化分離グループのコンピュータ用の IPsec ポリシーを配布する GPO に、\[ネットワーク経由でコンピュータへアクセスを拒否する\] 権限を設定しました。 この権限は、境界分離グループに参加しているシステムのコンピュータ アカウントをすべて持っているグループに適用しました。 そのコンピュータのいずれかが暗号化分離グループ内のシステムと通信を開始しようとした場合、IKE 認証で承認は失敗し、通信はブロックされます。 #### IPsec ポリシー IPsec ポリシーによって、Windows ベースのコンピュータは IPsec 環境で機能するように構成されます。 IPsec ポリシーは、トラフィックの照合に使用する規則をまとめたものです。 Windows 2000 には、3 種類の IPsec ポリシーがあります。 - ローカル ポリシー - Active Directory ドメイン ポリシー - 動的ポリシー Windows XP と Windows Server 2003 では、その他に次のポリシーがサポートされています。 - **スタートアップ IPsec ポリシー** : ローカルのレジストリに格納されて管理されており、 Windows XP SP2 以降でのみサポートされています。 このポリシーは、コンピュータが IP アドレスを取得した直後に適用され、IPsec サービスが開始する前である場合もあります。 サービスが継続ポリシーを適用すると置き換えられます。 - **継続 IPsec ポリシー** : ローカル コンピュータのレジストリ内に格納され、そこで管理されます。 構成はコマンドライン ツールで行います。 IPsec サービスが開始されたときに初めて適用されます。 スタートアップ ポリシーと置き換わります。 - **ローカル IPsec ポリシー** : ローカル コンピュータ上に格納され、そこで管理されます。 構成は \[IP セキュリティ ポリシーの管理\] MMC (Microsoft Management Console) スナップインまたはコマンドライン ツールで行います。 ドメイン ポリシーが割り当てられていない場合は、継続ポリシーに追加して適用されます。 - **Active Directory ドメイン IPsec ポリシー** : Active Directory 内に格納され、 管理は \[IP セキュリティ ポリシーの管理\] MMC スナップインまたはコマンドライン ツールで行います。 適用されると、割り当てられているすべてのローカル ポリシーを無効にします。 Active Directory IPsec ポリシーは、\[グループ ポリシー エディタ\] MMC スナップインまたは **\[Windows の設定\]**、**\[セキュリティの設定\]**、**\[IPsec ポリシー\]** にあるグループ ポリシー管理コンソール (GPMC) を使用して GPO に割り当てます。 - **動的 IPsec ポリシー** : メモリにのみ格納されます。 構成はコマンドライン ツールで行います。 既存のポリシーに動的に追加する場合に使用されます。 動的ポリシーは、IPsec サービスが停止した時点で破棄されます。 このガイドでは、記載を簡略にするため Active Directory ドメイン IPsec ポリシーの使用方法についてのみ説明します。 IPsec ポリシーを定義する場合は、すべてのコンピュータの IPsec インフラストラクチャの基礎となる汎用ポリシーを設計することをお勧めします。 その後、追加のポリシーを作成して、セキュリティ構成を追加する必要があるシステムにさらに厳しい設定を適用します。 追加ポリシーは、特定のビジネス要件または技術要件を満たす必要がある可能な限り多数のコンピュータに影響を与えるように設計してください。 ポリシーの総数を最小限に抑えておくと、ポリシーのトラブルシューティングや管理が容易になります。 IPsec ポリシーは、名前、説明、一組の規則、ならびに、ポーリング間隔、キー交換設定、キー交換方法などの構成設定で構成されています。これらについては、次のセクションで詳しく説明します。 ##### 名前 フィルタ操作などのポリシーには、プロジェクトの実装時および運用時にソリューションを容易に管理およびトラブルシュートできるように、わかりやすい名前を付けてください。 ##### 説明 ポリシーの詳細な説明を入力しておくと、管理者はポリシーを実際に開いて規則を確認しなくても、ポリシーの機能を特定することができます。 ##### 規則 IPsec の規則は、単一のフィルタ一覧、関連付けられているフィルタ操作、コンピュータ間の信頼の確立に使用される認証方法、接続の種類、および規則がトンネル設定であるかないかということで構成されています。 各規則により、ホスト間の信頼の確立に使用される 1 つまたは複数の認証方法が定義されます。 選択できる方法として、Kerberos バージョン 5 プロトコル、特定の証明機関から入手する証明書、事前共有キーがあります。 接続の種類では、IPsec ポリシーを適用する接続が定義されます。 ポリシーの適用先として、すべての接続、ローカル エリア接続、リモート アクセス ベースの接続のいずれかを設定できます。 トンネルの種類では、IPsec ポリシーが IPsec トンネルを定義するかどうかが定義されます。 トンネルの種類を無効にすると、IPsec ではトランスポート モードが使用されます。 このガイドで既に特定したセキュリティ分離グループをサポートするために、Woodgrove Bank は 4 つの IPsec ポリシーを実装しました。 すべてのポリシーが、Kerberos バージョン 5 認証プロトコルを使用し、すべての接続に適用され、IPsec トンネルを定義しないというように構成されました。 次の表に、Woodgrove Bank シナリオで使用されているポリシーを示します。 **表 5.6: Woodgrove Bank の IPsec ポリシー**

ポリシー名 説明
IPSEC – Isolation Domain IPsec Policy (1.0.041001.1600) このポリシーは分離ドメインを定義します。 この分離グループ内のホストは、IPsec に対応していないホストと通信を開始する際に、クリアテキストへのフォールバックを実行することができます。 このポリシーによって、ホストは IPsec 通信を必ず要求するように構成されます。 IPsec に対応しているクライアント間でネゴシエーションが失敗した場合、通信は失敗します。
IPSEC – Boundary Isolation Group IPsec Policy (1.0.041001.1600) このポリシーは境界分離グループを定義します。 このポリシーによって、ホストは IPsec 通信を要求するように、ただし IPsec に対応していないホストと通信する必要がある場合はクリアテキストへのフォールバックを実行できるように構成されます。
IPSEC – No Fallback Isolation Group IPsec Policy (1.0.041001.1600) このポリシーはフォールバックのない分離グループを定義します。 このポリシーによって、ホストは IPsec 通信を必ず要求するように構成されます。 ネゴシエーションが失敗するか、または IPsec を使用しないクライアントとの通信が試行された場合は、通信は失敗します。
IPSEC – Encryption Isolation Group IPsec Policy (1.0.041001.1600) このポリシーは暗号化分離グループを定義します。 このポリシーによって、ホストは IPsec 通信と暗号化を必ず要求するように構成されます。 ネゴシエーションが失敗するか、または IPsec を使用しないクライアントとの通信が試行された場合は、通信は失敗します。
各ポリシー名と一緒に表示されている番号はバージョン番号です。これについては、「ポリシーのバージョン管理」で説明します。 Woodgrove Bank の各ポリシーには同じ適用除外リストが含まれています。これは、特定の 1 つの分離グループの特定のコンピュータ群を除外する要件がないためです。 次の表に、上の表で特定した 4 つのポリシーに共通する有効な規則を示します。 **表 5.7: Woodgrove Bank の IPsec ポリシーに定義されている共通の規則**

フィルタ一覧 フィルタ操作 認証方法 トンネル エンドポイント 接続の種類
DNS Exemption List IPSEC – Permit なし なし すべて
Domain Controllers Exemption List IPSEC – Permit なし なし すべて
WINS Exemptions List IPSEC – Permit なし なし すべて
DHCP, Negotiation Traffic IPSEC – Permit なし なし すべて
ICMP, All Traffic IPSEC – Permit なし なし すべて
この表に記載されている規則の他に、各ポリシー内の既定のクライアント応答規則は無効になっています。 Woodgrove Bank が定義した 4 つのポリシーは、どの除外フィルタ一覧でも処理されないトラフィックの処理方法に関してのみ異なります。 いずれの規則でも、認証方法は Kerberos バージョン 5 プロトコル、トンネル エンドポイントは "なし"、接続の種類は "すべて" に設定されています。 次の表に、4 つの分離グループを実装するための Woodgrove Bank の規則を示します。 **表 5.8: 分離グループを実装するための Woodgrove Bank のベースとなる規則**

ポリシー名 フィルタ一覧 フィルタ操作
IPSEC – Isolation Domain IPsec Policy (1.0.041001.1600) Woodgrove Bank のセキュリティ保護されたサブネット IPsec – Secure Request Mode (Ignore Inbound, Allow Outbound)
IPSEC – Boundary Isolation Group IPsec Policy (1.0.041001.1600) Woodgrove Bank のセキュリティ保護されたサブネット IPsec – Request Mode (Accept Inbound, Allow Outbound)
IPSEC – No Fallback Isolation Group IPsec Policy (1.0.041001.1600) Woodgrove Bank のセキュリティ保護されたサブネット IPsec – Full Require Mode (Ignore Inbound, Disallow Outbound)
IPSEC – Encryption Isolation Group IPsec Policy (1.0.041001.1600) Woodgrove Bank のセキュリティ保護されたサブネット IPsec – Require Encryption Mode (Ignore Inbound, Disallow Outbound)
Woodgrove Bank は、認証プロトコルとして Kerberos バージョン 5 プロトコルのみを使用することにしました。 ローカル管理者がレジストリから、認証済みのユーザーとコンピュータがドメインから認証キーの値を読み取ることができるため、事前共有キーは使用しませんでした。 Woodgrove では PKI (公開キー基盤) が展開されていないため、証明書を選択することもしませんでした。 Kerberos バージョン 5 プロトコルを使用することで、すべてのドメイン参加コンピュータはポリシーを認証および取得でき、そのため IPsec インフラストラクチャに参加することができます。 ドメインに参加していないコンピュータは、認証メカニズムとポリシー配布システムがないため、IPsec 環境に簡単に参加することができません。 このようなコンピュータが信頼されたホストの条件を満たしている場合は、証明機関を使用して IPsec ローカル ポリシーを構成し、そのコンピュータと他の信頼されたホストとの通信を有効にすることができます。 現時点では、Woodgrove Bank は非ドメイン コンピュータを信頼されていないコンピュータとして扱っています。 **注 :** Kerberos バージョン 5 プロトコルを IKE 認証に使用しても、非ドメイン ベースのコンピュータが IPsec 環境に参加できなくなることはありません。 たとえば、UNIX システムが Active Directory を Kerberos 領域として使用するように適切に構成されていて、IKE 実装が Kerberos 認証をサポートしている場合、そのシステムは分離ドメインに参加できます。 ただし、マイクロソフトではそのような構成に関してテストを行っておらず、このガイドでも取り上げません。 ##### ポーリング間隔 ポーリング間隔に関して考慮が必要な事項として、グループ ポリシーのポーリング間隔、および IPsec サービスのポーリング間隔の 2 つがあります。 IPsec サービス ポリシー変更のポーリング間隔は、既定では 180 分に設定されており、Active Directory ベースの IPsec ポリシーの変更を対象に連続してポーリングが行われます。 これらのポーリングでは、IPsec ポリシーの変更の確認のみが行われます。ドメインまたは組織単位 (OU) メンバシップの変更、あるいは GPO の IPsec ポリシーの割り当てまたは削除は検出されません。 コンピュータの OU メンバシップの変更および GPO の割り当ては、グループ ポリシー サービスのポーリングによって検出されます。既定ではこれは 90 分間隔で実行されます。 Woodgrove Bank は、両方のポーリング間隔を 60 分に設定し、万一セキュリティ応答が必要になった場合でも、1 時間以内にポリシーの更新と展開を実行してリスクを軽減できるようにしました。 このようにポーリングの頻度を増やした場合、IPsec ポリシー上のタイムスタンプを確認するため、クライアントから送信される LDAP クエリ形式のポーリング トラフィックが増加します。 Woodgrove Bank シナリオでは、オーバーヘッドが大幅に増えることはありませんでしたが、大量のクライアントが存在する展開環境では大幅に増える可能性があります。 ##### キー交換設定 以下のキー交換設定は、新しいキーの生成方法およびその更新の頻度を定義します。 "マスタ キー" とは、IKE メイン モードで生成された Diffie-Hellman 共有秘密キー マテリアルのことを指します。 "セッション キー" とは、IPsec の整合性および暗号化アルゴリズムで使用される IKE クイック モードで生成されたキーのことを指します。 セッション キーは、マスタ キーから作成されます。 - **PFS (Perfect forward secrecy) :** IKE には 2 種類の PFS があります。つまり、マスタ キーの PFS (メイン モード PFS) とセッション キーの PFS (クイック モード PFS) です。 サポートされている他のキー交換設定と機能が重複するため、メイン モード PFS を使用することはお勧めしません。 メイン モード PFS では、クイック モードを実行してセッション キーを更新するたびに、IKE によって新しいマスタ キーの再認証とネゴシエーションが行われる必要があります。 この要件があるため、暗号化キーを更新する必要があるたびに必ず、2 台のコンピュータで新しい IKE メイン モードとクイック モードのネゴシエーションが最初から開始されます。 これで保護能力は高まりますが、オーバーヘッド コストも増加します。 セッション キー PFS では、クイック モード中に (メイン モード認証なしで) 新しいマスタ キーが生成され、新しいマスタ キーから新しいセッション キーが作成されます。 この機能により、通信内のデータのほとんどまたはすべてが 1 つのマスタ キー値だけで保護されることがなくなるため、攻撃者がマスタ キーを発見できた場合でも漏洩する暗号化データは少量になります。 セッション キー PFS は、フィルタ操作のセキュリティ メソッドのチェック ボックスとしてサポートされています。 セッション キー PFS は、IPsec で保護されたトラフィックに、Diffie-Hellman マスタ キーに対する高度な暗号化攻撃の危険性がある場合だけ使用してください。 - **新しいキーを認証して生成する間隔: <*数値>*** **分** : この値で、IKE メイン モード SA の有効期間が設定されます。既定では 480 分です。 これによってマスタ キーと信頼関係の有効期間を制御できます。有効期間経過後は再ネゴシエートする必要があります。 固有のクライアントからホストに対して最初の TCP/IP 接続が行われると、新しい IKE メイン モード SA が作成されます。 ソフト SA とは異なり、メイン モード SA は非アクティブ状態が 5 分続いてもホストから削除されません。 メイン モード SA は、それぞれ約 5 キロバイトのメモリを消費します。 この値を調整して、IKE が必要とする CPU 負荷とメモリ使用率を最適化することができます。 有効期間を短くした場合、サーバー上のアクティブなメイン モード SA の数が少なくなります。 こうすると維持する SA の数が少なくなるため、メモリ使用率が小さくなり、IKE 処理時間が短くなります。 ただし、通信の回数が多いクライアントでは、メイン モード SA の再ネゴシエーションに必要な CPU 負荷が増加することがあります。 - **新しいキーを認証して生成する間隔: <*数値>*** **セッション** :この設定では、1 つのメイン モード SA の有効期間中に許可される IKE クイック モードの最大数を制御することができます。したがって、同じマスタ キーから生成できるセッション キーの数を制限できます。 この制限値に達すると、新しい IKE メイン モード SA がネゴシエートされて、新しいマスタ キーが生成されます。 既定では値は 0 に設定されています。つまり、無制限ということです。 したがって、クイック モード PFS を使用しない限り、マスタ キーは IKE メイン モード SA の有効期間が切れた場合にのみ更新されます。 マスタ キー PFS の設定と同じ動作にするには、このオプションを 1 に設定します。 Woodgrove Bank では、マスタ キー PFS を必要とする特別なセキュリティ要件がないため、マスタ キー PFS を使用しないことにしました。 同様に、フィルタ操作で IKE クイック モード PFS を使用しませんでした。 IKE メイン モード SA の有効期間を 480 分から 180 分に変更し、境界分離グループ以外のビジー状態にあるサーバー上のメイン モード SA がより迅速に削除されるようにしました。 境界分離グループに関しては、IKE メイン モード SA の有効期間を 20 分に減らし、暗号化分離グループとネゴシエーションを行う常駐メイン モード SA が提供する攻撃対象領域を削減しました。 境界分離グループ内のホストは、暗号化分離グループ内のホストと新たな IKE ネゴシエーションを開始することはできませんが、その逆は可能です。 メイン モード SA が確立された場合、境界ホストはその後この SA を使用してクイック モード SA をネゴシエートし、メイン モード SA が削除されるまで暗号化分離グループ内の対応するシステム宛ての受信トラフィックを保護することができます。 このリスクを軽減するには、境界サーバー上のメイン モード SA が削除される回数を増やします。 マスタ キーがセッション キーの生成に使用できるセッションの数は、既定値である 0 のままにしました。 ##### キー交換方法 キー交換方法では、メイン モード IKE ネゴシエーション中に使用されるセキュリティ メソッドを制御します。 構成オプションには、整合性 (SHA-1 および MD5)、機密性または暗号化 (3DES および DES)、およびキー交換処理中に使用されるベース素数の長さがあります。 **注 :** Windows 2000 を実行しているコンピュータで 3DES を使用するには、コンピュータに高度暗号化パックまたは SP2 以降がインストールされている必要があります。 IKE ネゴシエーション自体の整合性と暗号化、および IPsec データ保護の整合性と暗号化に使用されるキーの暗号強度は、素数のベースとなっている Diffie-Hellman グループの強度によって決まります。 Diffie-Hellman グループには、次の 3 つのオプションがあります。 - **High (3)** - 2048 ビット キー強度。 このオプションは、Diffie-Hellman グループ 14 の IETF RFC 3526 仕様に対応します。 3DES に最高の暗号強度を持たせる場合は、このキー強度が必要です。 詳細については、IETF RFC 3526 を参照してください。 - **Medium (2)** - 1024 ビット キー強度。 - **Low (1)** - 768 ビット キー強度。 High は、Windows XP SP2 および Windows Server 2003 ベースのシステムでのみ使用できます。 Medium は、Windows 2000 および Windows XP SP1 との相互運用性を実現します。 Low は、下位互換性を実現します。脆弱であるため使用しないでください。 次の表に、Woodgrove Bank が実装することにしたキー交換セキュリティ メソッドを、優先度の高い順に上から示します。 **表 5.9: 既定のキー交換セキュリティ メソッド**

暗号化 整合性 Diffie-Hellman グループ
3DES SHA-1 High (3) 2048 ビット
3DES SHA-1 Medium (2) 1024 ビット
3DES MD5 Medium (2) 1024 ビット
**注 :** IPsec ポリシーで 2048 ビット グループを使用するには、\[IP セキュリティ ポリシーの管理\] MMC スナップインや Netsh IPsec コマンドライン ユーティリティなどの Windows Server 2003 管理ツールを使用して、IPsec ポリシーを構成する必要があります。 このポリシーは、ドメインで 2048 ビット オプションを無視する Windows 2000 プラットフォームに割り当てることができます。 ##### ポリシーのバージョン管理 IPsec ポリシーの設計は、初期設計、ラボ テスト、パイロット展開、実運用時に何回も変更される可能性があります。 スクリプト、スプレッドシート、またはその他のドキュメントを使用して IPsec ポリシーを作成する場合は、これらのファイルを Microsoft Visual SourceSafe® などのバージョン管理システムで管理してください。 Active Directory 内でポリシーの属性を参照して IPsec ポリシーのバージョンを特定することは困難です。 トラブルシューティング時には、コンピュータ上でどのバージョンの IPsec ポリシーがアクティブになっているかを判断できなければなりません。 したがって、ポリシーの名前とポリシー規則の両方に、何らかの形式のバージョン管理情報を格納することをお勧めします。 次の形式に従ってバージョン ID を作成すると、簡単にバージョンを管理できます。 ```

次に、フィルタ一覧、フィルタ、フィルタ操作、および IPsec ポリシーを Netsh コマンド シェルを使用して手動で入力します。 GUI ツールの場合と同様、Netsh でも IPsec ポリシー ファイルのエクスポートとインポートがサポートされているため、バックアップと復元の作業を実行できます。

Netsh をバッチ モードで実行するには、Netsh コマンドのスクリプト ファイルを作成する必要があります。 このスクリプト ファイルには、フィルタ一覧、フィルタ、フィルタ操作、および IPsec ポリシーのすべての構成コマンドだけでなく、ドメイン上にフォーカスを設定するコマンドも含める必要があります。

これで、Netsh を起動してスクリプト ファイルを実行し、Active Directory で IPsec ポリシー情報を作成することができます。 Netsh を起動してスクリプト ファイルを実行するコマンドライン構文を次に示します。

netsh –f <scriptfile>

Netsh の使用方法の詳細については、Windows Server 2003 のヘルプとサポート センターの「Administration and Scripting Tools」セクションの「Netsh」を参照してください。

注 : Netsh による IPsec ポリシーの操作は、Windows Server 2003 を実行しているコンピュータ上でしか実行できません。 Windows 2000 または Windows XP を実行しているコンピュータで IPsec ポリシーのコマンドライン操作を実行するには、それぞれ Ipsecpol.exe または Ipseccmd.exe が必要です。 また Netsh では、ツールの IPsec 関連の説明の中に dump コマンドが記載されています。 この機能は、ヘルプ テキストには記載されていますが、実装されていません。 また、GUI ツールとは異なり、Netsh ではリモート接続はサポートされていません。

IPsec ポリシー配布用のグループ ポリシー オブジェクトを作成する

GPO は、Active Directory 内に格納されているオブジェクトであり、コンピュータに適用する一連の設定を定義します。 IPsec ポリシーは、GPO 内に直接格納されるのではなく、 GPO が IPsec ポリシーと LDAP DN リンクでつながり、これが維持されます。 IPsec ポリシーは、Active Directory 内の cn=IP Security, cn=System, dc=<domain> に格納されます。

GPO は、Active Directory 内のサイト、ドメイン、または OU に割り当てられます。 これらの場所やコンテナ内にあるコンピュータは、ブロックされていない限り GPO が定義したポリシーを受け取ります。 IPsec 設計チームは、既存の GPO を使用して IPsec ポリシーを配布できるかどうかを Active Directory チームと協議してください。 使用できない場合、または管理方法を大幅に変更する必要がある場合は、展開する IPsec ポリシーのセットごとに新しい GPO を定義します。 このガイドで説明しているソリューションでは、IPsec ポリシーの展開に新しい GPO を使用します。

GPO は、[Active Directory ユーザーとコンピュータ] または [Active Directory サイトとサービス] ツールでも作成できますが、新しい GPO を作成する場合はグループ ポリシー管理コンソール (GPMC) を使用することをお勧めします。 Active Directory ツールを使用してポリシーを作成すると、GPO は参照したオブジェクトに自動的にリンクされます。 GPMC を使用して GPO を作成すると、GPO は Active Directly 内で作成されますが、各 GPO をサイト、ドメイン、または OU に明示的にリンクするまではコンピュータに適用されないようにすることができます。

GPMC は、Windows XP Service Pack 1 以降または Windows Server 2003 を実行しているコンピュータのアドオン ユーティリティです。 GPMC を利用すると、ドラッグ アンド ドロップ操作が可能な操作性の高いユーザー インターフェイスを使って、1 つまたは複数のフォレスト内の複数のドメインとサイトのグループ ポリシーを管理することができます。 主な機能に、GPO のバックアップ、復元、インポート、コピー、報告機能があります。 これらの操作は完全にスクリプト化可能で、スクリプト化すれば管理をカスタマイズしたり自動化することができます。 このような GPO 管理テクニックは、IPsec ポリシー オブジェクト自体を管理する場合にも使用できます。 IPsec ポリシーの管理方針は、IPsec ポリシーの割り当てを行う GPO の作成と連携して策定することをお勧めします。

GPMC の使用方法の詳細については、マイクロソフト Web サイトのホワイト ペーパー「GPMC でのグループ ポリシーの管理」を参照してください。

グループ ポリシー管理コンソール (GPMC) Service Pack 1 は、www.microsoft.com/downloads/details.aspx?
FamilyID=0a6d4c24-8cbd-4b35-9272-dd3cbfc81887&DisplayLang=ja からダウンロードできます。

GPMC を使用して各 IPsec ポリシーの GPO を作成するには、次の手順に従います。

新しい GPO を作成するには

  1. ドメイン ツリーを展開し、[グループ ポリシー オブジェクト] コンテナを右クリックして [新規作成] を選択します。

  2. 新しい GPO 名を入力して、[OK] をクリックします。

Active Directory オブジェクトのバージョン情報は簡単に取得できないため、IPsec のフィルタ操作やポリシーと同様に GPO の名前についても、名前の中にポリシーのバージョン番号が含めるなどの命名規則を決めておく必要があります。 ポリシー名にバージョン番号を含めると、現在有効なポリシーを迅速に特定することができます。 マイクロソフトでは、この章で既に説明したフィルタ操作と IPsec ポリシーの場合と同じ命名規則を使用することをお勧めします。 たとえば、"Isolation Domain IPsec GPO ver 1.0.040601.1600" という名前の GPOは、2004 年 6 月 1 日の午後 4 時に作成されたバージョン 1.0 であることを示します。

GPO を作成したら、適切な IPsec ポリシーを使用するためにその構成を行う必要があります。

IPsec ポリシーを GPO に割り当てるには

  1. GPO 名を右クリックして [編集] を選択し、グループ ポリシー エディタを起動します。

  2. 割り当て可能な IPsec ポリシーは、Active Directory の Computer Configuration\Windows Settings\Security Settings\IP Security Policies 内にあります。

  3. IPsec ポリシーを割り当てるには、右ペインでポリシー名を右クリックして、[割り当て] を選択します。

    • 1 つの GPO に対して 1 つの IPsec ポリシーを割り当てることができます。

  4. GPO の変更を保存するには、グループ ポリシー エディタ ツールを閉じます。

IPsec ポリシーは、GPO に設定されたコンピュータ構成によりホスト コンピュータに適用されます。 GPO を IPsec ポリシーの適用にのみ使用する場合は、ユーザー構成設定が無効になるように GPO を構成することをお勧めします。 この設定を無効にしておくと、ユーザー構成オプションの評価がバイパスされるため GPO の処理時間を短縮できます。

GPO のユーザー構成を無効にするには

  1. GPMC ツールを開きます。

  2. GPMC で GPO 名を右クリックします。

  3. [GPO Status] を選択して、[User Configuration Settings Disabled] を選択します。

後で GPO でユーザー構成の設定を行う場合は、ユーザー構成設定の処理を再度有効にして適用する必要があります。

ドメイン セキュリティ グループ

ドメイン セキュリティ グループには 2 つの役割があります。 1 つ目は、分離グループのメンバであるドメイン コンピュータのアカウントを特定することです。2 つ目は、ネットワーク アクセス グループのメンバであるドメイン コンピュータのアカウントを特定することです。

分離グループのメンバはすべて、同じ IPsec ポリシーを受け取る必要があります。 したがって、OU コンテナを使用してポリシーの割り当てを制御する代わりに、ドメイン セキュリティ グループを作成して IPsec ポリシーの適用と管理を行うことができます。 ユニバーサル グループは、フォレスト全体に適用できて管理が必要なグループの数を削減できるため、ポリシーの割り当てを制御するのに最適です。 ユニバーサル グループが使用できない場合は、代わりにドメイン グローバル グループを使用できます。 ドメイン ローカル グループは、ネットワーク アクセス グループに使用します。これについては後述します。

次の表に、Woodgrove Bank シナリオ用に作成された、IPsec 環境を管理してポリシーの適用を制御するためのグループを示します。

表 5.10: IPsec グループ名

グループ名 説明
No IPsec IPsec 環境に参加していないコンピュータ アカウントのユニバーサル グループです。 通常、インフラストラクチャ コンピュータのアカウントで構成されています。
CG_IsolationDomain_computers 分離ドメインに参加しているコンピュータ アカウントのユニバーサル グループです。
CG_BoundaryIG_computers 境界分離グループのメンバであり、したがって信頼されていないシステムとの通信を許可されているコンピュータ アカウントのユニバーサル グループです。
CG_NoFallbackIG_computers フォールバックのない分離グループに参加している、認証されていない通信は送信できないコンピュータ アカウントのユニバーサル グループです。
CG_EncryptionIG_computers 暗号化分離グループのメンバであり、したがって必ず通信が暗号化されるコンピュータ アカウントのユニバーサル グループです。
上に挙げたグループ以外にも、グループを追加で作成して初期公開時のポリシー適用の制限に使用する場合があります。 IPsec を展開する際には、GPO と IPsec ポリシーを作成して、それをそのままドメイン内のすべてのコンピュータに同時に割り当てるのはお勧めできません。 ドメイン セキュリティ グループを使用すると、どのコンピュータが GPO を読み取れるか、つまり対応する IPsec ポリシーを受信できるかを正確に制御できるようになります。 IPsec ポリシーを配布する GPO は、どれもドメイン全体に割り当てることができます。 公開プロセスでは、IPsec をネゴシエートする可能性があるすべてのノードで IPsec ポリシーが正しく設計、割り当て、取得されているかどうか、注意深く検討する必要があります。 境界グループ ポリシーの設計は、通常、IPsec ポリシーをまだ受け取っていないコンピュータと行う送受信で非 IPsec 通信を利用できるようにするために使用されます。 ##### Active Directory を使用して IPsec ポリシーを配布する Active Directory のコンピュータにどの GPO を適用するかは、次の 3 つの方法で制御できます。 - リンクしている GPO を介して OU を使用する。 - GPO に適用される ACL で参照されているセキュリティ グループにコンピュータ アカウントを配置する。 - GPO で Windows Management Instrumentation (WMI) フィルタを使用する。 リンクしている GPU を使って OU 経由で GPO の適用を制御する方法は、Active Directory で最も一般的なポリシー適用方法です。 この方法では、Active Directory 内に OU を作成し、GPO をサイト、ドメイン、または OU にリンクします。 コンピュータは、Active Directory 内の場所に基づいてポリシーを受け取ります。 コンピュータを特定の OU から別の OU に移動すると、移動先の OU にリンクされているポリシーは、グループ ポリシーによるポーリングで変更が検出された時点で有効になります。 2 番目の方法では、GPO 自体のセキュリティ設定を使用します。 Active Directory 内にある GPO の ACL にグループを追加します。 その場合このグループには、"グループ ポリシーの読み取りと適用の許可" の権限が割り当てられます。ポリシーのこの権限は、グループ内のコンピュータで有効になります。 また、グループ内のコンピュータに適用されないポリシーの権限は明確に拒否されます。 次にポリシーは、ドメイン レベルでリンクされます。 3 番目の方法では、ポリシーの WMI フィルタを使用してポリシーの適用範囲を動的に制御します。 WMI SQL フィルタを作成して、ポリシーにリンクします。 クエリされた状態が True の場合はポリシーが適用され、そうでない場合は無視されます。 Windows 2000 を実行しているコンピュータは、WMI フィルタリングを無視してポリシーを適用します。 WMI クエリは、GPO の処理速度を低下させる可能性があるため、必要な場合のみ使用してください。 Woodgrove Bank では、OU に直接リンクするのではなく、セキュリティ グループを使用してポリシーの適用を制御する方法を採用しました。 Woodgrove がこの方法を採用した理由は、複数の場所にポリシーを適用したり、正しいポリシーを受け取れるようにコンピュータを OU 間で移動する必要がなく、IPsec ポリシーの環境への導入が簡単なためでした。 この方法でも最初に挙げた方法でも ACL の評価は必要なため、GPO の ACL が非常に大きい場合を除いて、この方法に関連するオーバーヘッドが最初の方法より大きくなることはありません。 Woodgrove では、環境内に Windows 2000 システムが含まれているため、WMI フィルタリングは採用しませんでした。 次の表に、最終的なグループ ポリシー ACL 構成を示します。 IPsec ポリシー オブジェクト自体の ACL は使用していません。また、使用することはお勧めしません。 **表 5.11: Woodgrove Bank のポリシー GPO の権限**

GPO 名 セキュリティ グループ名 割り当てられている権限
IPSEC – Isolation Domain Policy No IPsec グループ ポリシーの適用を拒否
IPSEC – Isolation Domain Policy CG_IsolationDomain_computers グループ ポリシーの読み取りと適用を許可
IPSEC – Boundary Group Policy No IPsec グループ ポリシーの適用を拒否
IPSEC – Boundary Group Policy CG_BoundaryIG_computers グループ ポリシーの読み取りと適用を許可
IPSEC – No Fallback Isolation Group Policy No IPsec グループ ポリシーの適用を拒否
IPSEC – No Fallback Isolation Group Policy CG_NoFallbackIG_computers グループ ポリシーの読み取りと適用を許可
IPSEC – Encryption Isolation Group Policy No IPsec グループ ポリシーの適用を拒否
IPSEC – Encryption Isolation Group Policy CG_EncryptionIG_computers グループ ポリシーの読み取りと適用を許可
###### 分離ドメイン Woodgrove Bank では、分離ドメイン ポリシーを組織内の各ドメインのドメイン レベルにリンクすることにしました。 ポリシーは ACL を使用します。これにより、CG\_IsolationDomain\_computers グループのメンバ以外はポリシーを適用できなくなります。 Authenticated Users グループの "グループポリシーの適用" 権限は、ポリシー ACL から削除されました。 分離ドメイン ポリシーは、組織内のすべてのコンピュータが既定の IPsec セキュリティ ポリシーとして使用するポリシーです。 したがって、ドメイン コンピュータ グループには、ポリシーへの読み取りアクセス権限を与えました。 Authenticated Users グループの "グループポリシーの適用" 権限は、ポリシー ACL から削除されました。 初期公開時には、ACL からドメイン コンピュータ グループを削除し、別の一時的なセキュリティ グループを使用してこのポリシーの受け取り先を制御しました。 この方法を採用することで、このポリシーを段階的に展開できました。 ###### 境界分離グループ Woodgrove Bank では、境界分離グループ ポリシーを組織内の各ドメインのドメイン レベルにリンクすることにしました。 ポリシーは ACL を使用します。これにより、CG\_BoundaryIG\_computers グループのメンバ以外はポリシーを適用できなくなります。 Authenticated Users グループの "グループポリシーの適用" 権限は、ポリシー ACL から削除されました。 ビジネス上の理由で信頼されていないシステムからの通信を受け付ける必要がある場合は、システムのコンピュータ アカウントを CG\_BoundaryIG\_computers セキュリティ グループに追加します。 ###### フォールバックのない分離グループ Woodgrove Bank では、フォールバックのない分離グループ ポリシーを組織内の各ドメインのドメイン レベルにリンクすることにしました。 ポリシーは ACL を使用します。これにより、CG\_NoFallbackIG\_computers グループのメンバ以外はポリシーを適用できなくなります。 Authenticated Users グループの "グループポリシーの適用" 権限は、ポリシー ACL から削除されました。 ビジネス上の理由で信頼されていないシステムとの通信を開始できないようにする必要がある場合は、システムのコンピュータ アカウントを CG\_NoFallbackIG\_computers セキュリティ グループに追加します。 ###### 暗号化分離グループ Woodgrove Bank では、暗号化分離グループ ポリシーを組織内の各ドメインのドメイン レベルにリンクすることにしました。 このポリシーは ACL を使用します。これにより、CG\_EncryptionIG\_computers グループのメンバ以外はポリシーを適用できなくなります。 Authenticated Users グループの "グループポリシーの適用" 権限は、ポリシー ACL から削除されました。 ビジネス上の理由で暗号化されたトラフィックでのみ通信を行う必要がある場合は、システムのコンピュータ アカウントを CG\_EncryptionIG\_computers セキュリティ グループに追加します。 [](#mainsection)[ページのトップへ](#mainsection) ### 分離グループへの受信アクセスを許可する Woodgrove Bank では、信頼されているホストの一部のみに、暗号化分離グループ内のサーバーへの受信ネットワーク アクセスを許可できるようにする必要がありました。 この要件を実装するため、第 4 章の表 4.8 で次のネットワーク アクセス グループ (NAG) を定義しました。 - ANAG\_EncryptedResourceAccess\_Users - ANAG\_EncryptedResourceAccess\_Computers - DNAG\_EncryptedResourceAccess\_Computers クライアントが暗号化サーバーへの IKE を開始すると、IKE は Kerberos サービス チケットを取得する必要があります。このチケットには、クライアント コンピュータが ANAG および DNAG (またはそのいずれか) のメンバであるかどうかを示すドメイン セキュリティ グループ ID が含まれています。 暗号化分離グループ内のすべてのコンピュータが同じドメインのメンバである場合、これらの NAG はドメイン ローカル セキュリティ グループとして作成できます。 暗号化分離グループ内のコンピュータが個別の信頼されているドメインのメンバである場合、ドメイン グローバル グループのセットのいずれかを NAG に使用するか、または各ドメインでドメイン ローカル グループを作成できます。 Woodgrove Bank シナリオではドメインは 1 つだけです。そのため、これらの NAG にはドメイン ローカル グループを使用します。 次の追加の GPO は、受信許可を実装する "**ネットワーク経由でコンピュータへアクセス**" 権限を定義するために作成されたものです。 - EncryptionIG Inbound Network Authorization GPO CG\_EncryptionIG\_Computers グループには、この GPO に対する "読み取りと適用" 権限が与えられています。 Authenticated Users グループは "読み取り" 権限から削除されたため、この GPO は暗号化分離グループのメンバであるコンピュータにのみ適用されます。 第 4 章の表 4.8 に記載されているように、許可されているクライアント ドメイン コンピュータ アカウント IPS-ST-XP-05 は、ANAG\_EncryptedResourceAccess\_Computers ネットワーク アクセス グループに追加されます。 暗号化サーバー アカウントである IPS-SQL-DFS-01 および IPS-SQL-DFS-02 もここに追加されます。 ただし、CG\_EncryptionIG\_computers グループを使用してより大きなリストを管理すれば、同じ結果をより簡単に得ることができます。 アカウントは、何らかの方法で (ANAG メンバシップを通じて、CG\_EncryptionIG\_computers グループを直接追加して、または権限にコンピュータ アカウントを明示的に含めることで) "**ネットワーク経由でコンピュータへアクセス**" 権限を持つことを許可される必要があります。 許可されない場合、アカウントは、アプリケーションが要求する IPsec で保護された相互接続を実行できなくなります。 大規模なドメイン環境をシミュレートできるように、ANAG グループが Woodgrove Bank シナリオの受信アクセスを許可する唯一のグループとなっています。 Authenticated Users グループにはすべてのドメイン コンピュータが含まれているため、このグループは "**ネットワーク経由でコンピュータへアクセス**" 権限から削除する必要があります。 許可されているドメイン ユーザーは明示的に許可される必要があります。そのためには、Domain Users にビルトイン グループを使用します。 ただし、Woodgrove Bank では、ユーザーとコンピュータの受信ネットワーク アクセスの制限を定義する機能を利用することにしました。 したがって、ANAG\_EncryptedResourceAccess\_Users というドメイン ローカル セキュリティ グループを作成して、許可されているアプリケーション ユーザー アカウント (User7 など)、ローカル管理者グループ、ドメイン管理者グループを指定しました。 このようなユーザーレベルのネットワーク アクセスの制限は、IPsec ESP 3DES 接続が正常に確立された後の、上位層のプロトコル (RPC、SMB、SQL など) 認証要求で発生します。 次のドメイン セキュリティ グループは、暗号化サーバーのネットワーク ログイン権限用に作成されたものです。 これらのグループは、\[コンピュータの構成\]、\[Windows の設定\]、\[セキュリティの設定\]、\[ローカル ポリシー\]、\[ユーザー権利の割り当て\] の下の GPO の **\[ネットワーク経由でコンピュータへアクセス\]** 権限下にあります。 - ANAG\_EncryptedResourceAccess\_Computers - ANAG\_EncryptedResourceAccess\_Users 次のグループは、同じ GPO を **\[ネットワーク経由でコンピュータへアクセスを拒否する\]** に設定したものです。 - DNAG\_EncryptedResourceAccess\_Computers User7 は、暗号化サーバーに直接ログオンできないと想定されるため、IPS-ST-XP-05 クライアント コンピュータを使用して IPS-SQL-DFS-01 または IPS-SQL-DFS-02 サーバーにアクセスする必要があります。 IPS-ST-XP-05 コンピュータには、有効なドメイン コンピュータ アカウントが設定され、暗号化サーバーの IP アドレスに IKE ネゴシエーションを開始するアクティブな IPsec ポリシーが適用されている必要があります。 ドメイン内の他のすべてのユーザーとコンピュータは、**\[ネットワーク経由でコンピュータへアクセス\]** 権限から故意に除外されているため、事実上アクセスを拒否されます。 境界コンピュータのみ、DNAG の使用により明示的にアクセスを拒否されます。これは、ANAG に境界コンピュータのアカウントを含めるなど、将来のグループ メンバシップの変更に対する多層防御手段として機能します。 明示的な拒否パラメータは、あらゆる形式の許可を無効にします。 [](#mainsection)[ページのトップへ](#mainsection) ### IPsec に関するその他の考慮事項 IPsec を正しく実装するには、IPsec ポリシーの定義以外にもいくつか考慮が必要な事項があります。 Tools and Templates フォルダにある **Business\_Requirements.xls** スプレッドシートに、IPsec を使用する際の制約の詳細が示されています。 #### 既定の適用除外 Windows 2000 および Windows XP では、次の種類のトラフィックは既定でフィルタの照合から除外されます。 - ブロードキャスト - マルチキャスト - Kerberos 認証プロトコル - IKE - Resource Reservation Protocol (RSVP) Windows Server 2003 オペレーティング システム ファミリでは、ブロードキャスト、マルチキャスト、RSVP、および Kerberos 認証プロトコルからのトラフィックは、既定ではフィルタの照合から除外されません (IKE トラフィックのみ除外されます)。 ブロードキャスト パケットおよびマルチキャスト パケットは、セキュリティをネゴシエートするフィルタ操作が含まれているフィルタに一致した場合、ドロップされます。 Windows Server 2003 ファミリでは、ブロードキャスト トラフィックとマルチキャスト トラフィックのフィルタリングは既定で限定的なものになっています。 発信元アドレスを \[任意の IP アドレス\] にしているフィルタは、マルチキャストおよびブロードキャスト アドレスに一致します。 発信元アドレスと宛先アドレスの両方を \[任意の IP アドレス\] にしているフィルタは、受信および送信マルチキャスト アドレスに一致します。 このようなフィルタを使用して、すべてのトラフィックをブロックできます。 ただし、特定のマルチキャストまたはブロードキャスト トラフィックのブロックに使用する一方向のフィルタはサポートされていません。 Windows Server 2003 ファミリの IPsec 実装では適用除外の既定の動作が変更されているため、Windows 2000 または Windows XP 用に作成された IPsec ポリシーについては動作を確認し、特定の種類のトラフィックを許可する明示的な許可フィルタを構成するかどうかを判断してください。 IPsec ポリシーの動作を Windows 2000 および Windows XP の既定の動作に戻すには、Netsh コマンドを使用するか、レジストリを変更します。 **Netsh を使用して、IPsec ドライバを Windows 2000 および Windows XP の既定のフィルタリング動作に戻すには** 1. **Netsh** プロンプトで次のコマンドを入力して **ENTER** キーを押します。 `netsh ipsec dynamic set config ipsecexempt 0` 2. コンピュータを再起動します。 **レジストリを変更して、すべてのブロードキャスト、マルチキャスト、および IKE のトラフィックを IPsec フィルタリングの適用から除外するには** 1. **HKEY\_LOCAL\_MACHINE\\System\\CurrentControlSet\\** **Services\\IPSEC\\NoDefaultExempt DWORD** レジストリ設定の値を **1** に設定します。 **NoDefaultExempt** キーは、既定では存在しないため作成する必要があります。 2. コンピュータを再起動します。 #### NAT-T (ネットワーク アドレス変換トラバーサル) ネットワーク アドレス変換器の動作方法により、IPsec NAT-T を使用するネットワーク アドレス変換器の背後にある Windows 2000 Server または Windows Server 2003 を実行しているサーバーと通信したときに、クライアントで予期しない結果が発生することがあります。 Windows XP SP2 では、そのようなサーバーへの IPsec NAT-T セキュリティ アソシエーションは既定でサポートされなくなっています。 この変更は、以下の一連のイベントが発生する状況で予期されるセキュリティ リスクを排除するために行われました。 1. IKE および IPsec NAT-T トラフィックを NAT 構成ネットワーク上のサーバー (サーバー 1) にマップするように、ネットワーク アドレス変換器が構成されます。 2. NAT 構成ネットワークの外部にあるクライアント (クライアント 1) が、IPsec NAT-T を使用してサーバー 1 との双方向セキュリティ アソシエーションを確立します。 3. NAT 構成ネットワーク上にあるクライアント (クライアント 2) が、IPsec NAT-T を使用してクライアント 1 との双方向セキュリティ アソシエーションを確立します。 4. ネットワーク アドレス変換器の静的マッピングにより IKE および IPsec NAT-T トラフィックがサーバー 1 にマップされるため、クライアント 1 がクライアント 2 とのセキュリティ アソシエーションを再確立する状況が発生します。 この状況では、クライアント 1 からクライアント 2 に送信された IPsec セキュリティ アソシエーションのネゴシエーション トラフィックが、サーバー 1 に間違ってルーティングされる可能性があります。 このような状況が実際に発生することはほとんどありませんが、Windows XP SP2 ベースのコンピュータの既定の動作では、ネットワーク アドレス変換器の背後にあるサーバーに対して IPsec NAT-T ベースのセキュリティ アソシエーションが確立されることはないようにしており、このような状況が絶対発生しないようにしています。 NAT で IPsec 通信を行う必要がある場合、インターネットから直接接続可能なすべてのサーバーにパブリック IP アドレスを使用することをお勧めします。 そのように構成できない場合は、Windows XP SP2 の既定の動作を変更して、ネットワーク アドレス変換器の背後にあるサーバーに対する IPsec NAT-T セキュリティ アソシエーションを有効にすることができます。 **AssumeUDPEncapsulationContextOnSendRule レジストリ値を作成して設定するには** 1. **\[スタート\]** メニューで **\[ファイル名を指定して実行\]** をクリックし、「**regedit**」と入力して **\[OK\]** をクリックします。 2. 次のレジストリ サブキーを見つけてクリックします。 ``` HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\IPSec ``` 3. **\[編集\]** メニューの **\[新規\]** をポイントして、**\[DWORD 値\]** をクリックします。 4. **\[新しい値 \#1\]** ボックスに次のように入力して、ENTER キーを押します。**AssumeUDPEncapsulationContextOnSendRule** **注 :** この値の名前は、大文字と小文字が区別されます。 5. **\[AssumeUDPEncapsulationContextOnSendRule\]** を右クリックして、**\[修正\]** を選択します。 6. **\[値のデータ\]** ボックスに、次のいずれかの値を入力します。 - **0** (既定) : 0 (ゼロ) に設定すると、Windows はネットワーク アドレス変換器の背後にあるサーバーとセキュリティ アソシエーションを確立できなくなります。 - **1** : 1 に設定すると、Windows はネットワーク アドレス変換器の背後にあるサーバーとセキュリティ アソシエーションを確立できるようになります。 - **2** : 2 に設定すると、サーバーと Windows XP SP2 ベースのクライアント コンピュータの両方がネットワーク アドレス変換器の背後にある場合に、Windows はセキュリティ アソシエーションを確立できるようになります。 **注 :** Windows XP の最初のリリースおよび Windows XP Service Pack 1 (SP1) では、値は 2 に設定されていました。 7. **\[OK\]** をクリックして、レジストリ エディタを閉じます。 8. コンピュータを再起動します。 **AssumeUDPEncapsulationContextOnSendRule** の値を 1 または 2 に設定すると、Windows XP SP2 はネットワーク アドレス変換器の背後にあるサーバーに接続できるようになります。 Windows Server 2003 ベースのサーバーについても、NAT デバイスの背後に配置されている場合、IPsec で正しく動作させるには更新を行う必要があります。[Windows Server 2003 Service Pack 1](https://www.microsoft.com/japan/windowsserver2003/downloads/servicepacks/sp1/default.mspx) の入手方法については、次の URL を参照してください。 https://www.microsoft.com/japan/windowsserver2003/downloads/servicepacks/sp1/default.mspx **注 :** 詳細については、マイクロソフト サポート技術情報 885348「[IPSec NAT-T is not recommended for Windows Server 2003 computers that are behind network address translators](https://support.microsoft.com/default.aspx?scid=kb;en-us;885348)」(英語) を参照してください。 この記事では、このシナリオを使用した場合のセキュリティ リスクについて説明しています。 このシナリオで IPsec を使用する利点とそれに伴うセキュリティ リスクは、ユーザーが各自で評価してください。 マイクロソフトでは、関連するセキュリティ リスクがあるためこのシナリオをお勧めしていませんが、このソリューションで説明している構成でこのシナリオをサポートします。 受信 NAT 接続を正しく動作させるには、PMTU 検出機能が有効に機能している必要があります。 「*Windows XP Hardening Guide*」(英語) や「*Windows Server 2003 Hardening Guide*」(英語) などの一部のガイドでは、PMTU 検出機能を無効にすることを推奨しており、場合によっては PMTU 検出機能を無効にするポリシー テンプレートが用意されています。 **PMTU 検出機能を無効にするには** 1. **\[スタート\]** メニューで **\[ファイル名を指定して実行\]** をクリックし、「**regedit**」と入力して **\[OK\]** をクリックします。 2. 次のレジストリ サブキーを見つけてクリックします。 ``` HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\tcpip\parameters ``` 3. **\[編集\]** メニューの **\[新規\]** をポイントして、**\[DWORD 値\]** をクリックします。 4. **\[新しい値 \#1\]** ボックスに「**EnablePMTUDiscovery**」と入力して ENTER キーを押します。 5. **\[EnablePMTUDiscovery\]** を右クリックして、**\[修正\]** を選択します。 6. **\[値のデータ\]** ボックスに、「1」と入力します。 7. **\[OK\]** をクリックして、レジストリ エディタを閉じます。 8. コンピュータを再起動します。 また、Windows 2000 を実行しているホストが NAT-T シナリオに参加している場合は、マイクロソフト サポート技術情報 818043「[Windows XP および Windows 2000 用 L2TP/IPSec NAT-T 更新プログラム](https://support.microsoft.com/kb/818043)」で紹介されている更新プログラムを適用して正しく機能させる必要があります。 詳細については、以下のマイクロソフト サポート技術情報を参照してください。 - 885407「[IPsec NAT トラバース (NAT-T) の既定の動作は、Windows XPService Pack 2 に変更されています。](https://support.microsoft.com/kb/885407)」https://support.microsoft.com/kb/885407 - 818043「[Windows XP および Windows 2000 用 L2TP/IPSec NAT-T 更新プログラム](https://support.microsoft.com/kb/818043)」https://support.microsoft.com/kb/818043 #### IPsec と Windows ファイアウォール Windows XP SP2 を実行しているコンピュータで Windows ファイアウォールを有効にすると、不要な受信トラフィックがブロックされるため攻撃に対する保護能力が向上します。 Windows XP SP2 の IPsec は、Windows ファイアウォールを認識します。 アクティブな IPsec ポリシーが存在する場合、Windows XP SP2 の IPsec コンポーネントの指示により、Windows ファイアウォールは UDP ポート 500 および 4500 を開いて IKE トラフィックを許可します。 IPsec サポートの追加の機能として、IPsec で保護されているすべてのトラフィックが Windows ファイアウォール処理をバイパスするように、グループ ポリシーによって指定することができます。 詳細については、ホワイト ペーパー「[Microsoft® Windows® XP Service Pack 2 向け Windows ファイアウォール設定の導入](https://download.microsoft.com/download/a/5/0/a502c5cb-ad7d-4fc4-ad58-be8eaf32478e/wf_xpsp2.doc)」の付録 A を参照してください。 #### IPsec とインターネット接続ファイアウォール (ICF) SP2 を実行していない Windows XP ベースのコンピュータの場合、インターネット接続ファイアウォール (ICF) を使用した方がトラフィックのフィルタのセキュリティ要件に適切に対応できます。 ICF にはフィルタリング機能が備わっており、Windows XP SP1 で受信マルチキャスト トラフィックおよび受信ブロードキャスト トラフィックをブロックできます。 ただし、ICF は、トランスポートまたはトンネル モードの IPsec AH または ESP によって保護されているトラフィックを認識しません。 IPsec は ICF よりも下位のネットワーク層で動作し、IKE は ICF よりも上位の層で動作するため、受信トラフィック用に IKE (UDP ポート 500) の静的な許可を設定してください。 IPsec がトラフィックをブロックした場合、ICF のドロップされたパケットのログには、IPsec が破棄したパケットは含まれません。 [](#mainsection)[ページのトップへ](#mainsection) ### 要約 この章では、第 4 章で作成した分離グループ設計に基づく IPsec ポリシーを作成し、これを展開する方法について説明しました。 説明内容は、次の 7 つの基本タスクに分類することができます。 - フィルタ一覧を特定して作成する - フィルタ操作を特定して作成する - 規則を特定して作成する - IPsec ポリシーを特定して作成する - IPsec ポリシーの配布メカニズムを定義する - IPsec ポリシーの公開方法を定義する - グループ ポリシーのネットワーク ログオン権限の構成を使用して、受信アクセスを制御する承認を定義する 上記のタスクを実行することで、サーバー/ドメイン分離ソリューションの設計と計画の段階は完了します。 次の段階では、設計を検証できるようにテストまたはパイロット環境を展開します。 マイクロソフトでは、この検証作業をテスト ラボで実施し、Woodgrove Bank シナリオをパイロットとして使用しました。 この環境を再作成する方法、または展開の各段階の詳細については、このガイドの付録 C を参照してください。ここには、シナリオの設計を検証するためにマイクロソフトがテスト ラボで使用した展開プロセスの詳しい手順が記載されています。 #### 関連情報 ここでは、この章で説明したテクノロジに関する詳細情報へのリンクを示します。 ##### IPsec に関する一般的な背景情報 - マイクロソフトの [IPsec ホームページ](https://www.microsoft.com/ipsec) (英語): www.microsoft.com/ipsec - マイクロソフト Web サイトの「[IPsec for Windows 2000](https://www.microsoft.com/download/details.aspx?familyid=501a48d5-a3ee-4094-aeb4-16bbff098810&displaylang=en)」ページ (英語) - IPsec に関する Windows 2000 固有のさまざまな情報が掲載されています : www.microsoft.com/downloads/details.aspx?familyid=501a48d5-a3ee-4094-aeb4-16bbff098810&displaylang=en - Microsoft Windows Server 2003 Web サイトの「[IPsec](https://www.microsoft.com/windowsserver2003/technologies/networking/ipsec/default.mspx)」ページ (英語) - IPsec に関する Windows Server 2003 固有のさまざまな情報が掲載されています : www.microsoft.com/windowsserver2003/technologies/ networking/ipsec/ default.mspx - 「*Windows Server 2003 Deployment* *Kit*」の「[Deploying IPsec](https://technet2.microsoft.com/windowsserver/en/library/0bd06cf7-2ed6-46f1-bb55-2bf870273e151033.mspx)」の章 (英語) :https://technet2.microsoft.com/windowsserver/en/library/0bd06cf7-2ed6-46f1-bb55-2bf870273e151033.mspx?mfr=true ##### その他の情報 - Microsoft Windows Server 2003 Web サイトの「[グループ ポリシー](https://www.microsoft.com/japan/windowsserver2003/technologies/management/grouppolicy/default.mspx)」ページ - Active Directory のグループ ポリシーで Windows システムを管理することに関するさまざまな情報が掲載されています : https://www.microsoft.com/japan/windowsserver2003/ technologies/management/grouppolicy/ default.mspx. - 2004 年 10 月の *Cable Guy* の記事「[ネットワーク アドレス変換 (NAT) の使用に関する問題](https://www.microsoft.com/japan/technet/community/columns/cableguy/cg1004.mspx)」には、NAT と IPsec の特定の問題に関して詳細な情報が記載されています。 この記事は、次のマイクロソフト Web サイトから入手できます。 https://www.microsoft.com/japan/technet/community/columns/ cableguy/cg1004.mspx [](#mainsection)[ページのトップへ](#mainsection)