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

  • [アーティクル]

第 4 章 : 分離グループを設計および計画する

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

この章では、「第 2 章 : サーバーおよびドメインの分離を理解する」で説明したビジネス セキュリティ要件を満たす分離グループを定義する方法について詳しく説明します。このソリューションでは、Active Directory® ディレクトリ サービス ドメインのコンピュータ識別情報、この識別情報を認証する IPsec ポリシー、および Microsoft® Windows® セキュリティ ポリシーを組み合わせて、分離グループを定義および適用します。 情報技術 (IT) 管理者は、分離グループの概念を使用して、アプリケーションに対して透過的である安全な方法で内部ネットワークのネットワーク トラフィックを管理できます。 これによって、ネットワークからのウイルス感染や攻撃による損害の脅威を大幅に軽減することができます。

このガイドでは、Woodgrove Bank のシナリオを通して、組織のセキュリティ要件を展開された分離グループに転化する方法について詳しく説明します。 また、IPsec を他のセキュリティ設定と組み合わせて、管理性と拡張性のある詳細なサーバーおよびドメインの分離ソリューションを構築する方法についても説明します。

どのビジネスのソリューションにもそれぞれ独自の要件があるため、このガイドのモデルをそのまま適用できない場合もあります。 組織でこのガイドを使用する場合は、それぞれの環境において何が必要で何を達成できるかを見極め、それぞれのビジネス要件に適合するように分離グループ モデルの設計を適切に変更する必要があります。

トピック

章の前提条件
サーバーおよびドメインの分離を設計する
グループの実装方法
Woodgrove Bank のグループ実装
要約

章の前提条件

ここでは、組織でサーバーおよびドメインの分離ソリューションへのアプローチを決定するのに役立つ情報について説明します。 組織のソリューションの成功は、ここで説明する前提条件に左右されます。

知識の前提条件

IPsec の概念と用語を理解している必要があります。 また、Microsoft Windows Server™ 2003 の次の領域について理解している必要もあります。

  • IPsec ポリシー、IPsec フィルタ、フィルタ操作、およびフィルタ一覧

  • Active Directory の概念 (Active Directory の構造とツール、ユーザーやグループなどの Active Directory オブジェクトの操作、名前解決サービス、グループ ポリシーの使用など)

  • 認証の概念 (Windows ログオン プロセス、Kerberos Version 5 プロトコルなど)

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

この章を読み進める前に、前の章にも目を通しておいてください。

組織の前提条件

このソリューションの実装に参加する必要がある、組織の他のメンバとよく話し合ってください。たとえば次のような人が考えられます。

  • エグゼクティブ スポンサー

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

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

  • ドメイン ネーム システム (DNS)、Web サーバー、ネットワーク エンジニアリングの管理および運営の担当者

    注 : IT 組織の構造によっては、これらの役割を何人かで分担している場合もあれば、少人数で複数の役割を兼任している場合もあります。 いずれも場合も、プロジェクトのさまざまな段階を通じて、組織をまたがるチームの作業の調整に役立つ単一の窓口を特定することが重要です。

この章では、「第 2 章 : サーバーおよびドメインの分離を理解する」と「第 3 章 IT インフラストラクチャの現在の状態を把握する」に記載されている要件を満たしていることも前提としています。これらの要件には、ホスト、ネットワーク、および Active Directory からの情報収集も含まれます。 また、ビジネス要件の収集および企業のスポンサーの獲得についても説明します。

最後に、このソリューションの新しい概念、用語、およびテクノロジについての、各ヘルプ デスクおよびサポート スタッフのトレーニング計画を準備する必要があります。 このソリューションは組織のさまざまな領域に影響するため、展開時に発生する問題に対処できるようにサポート スタッフをトレーニングする必要があります。

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

この章では、次のような IT インフラストラクチャがあることを前提としています。

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

    注 : Windows Server 2003 に加えられた改良には、IPsec ポリシーに影響するものがいくつかあります。 Windows 2000 でのこのソリューションの動作に影響するものは特にありません。 ただし、このソリューションのテストは Windows Server 2003 Active Directory でのみ行われています。 Windows Server 2003 で IPsec に加えられた拡張機能の詳細については、マイクロソフト Web サイトの「IPsec の新機能」ページを参照してください。

ページのトップへ

サーバーおよびドメインの分離を設計する

ソリューションの設計は、ビジネス要件とこれまでの章で収集した情報に大きく依存します。 「第 2 章 : サーバーおよびドメインの分離を理解する」と「付録 D IT の脅威の分類」には、ソリューションのコンポーネントの説明が記載されており、対処できる脅威と対処できない脅威が示されています。 「第 3 章 : IT インフラストラクチャの現在の状態を把握する」には、現在のネットワーク アーキテクチャやネットワーク内のホスト資産などの計画データを収集する方法が記載されています。 この章では、Woodgrove Bank について収集した情報と要件を使用します。これは、Tools and Templates フォルダにある Business_Requirements.xls に詳細に記録されています。 このファイルを参照しながらこの章で説明する設計プロセスを実行すると、ソリューションの設計の背景にある理由について理解が深まります。 ソリューションの設計プロセスには、主に次のタスクがあります。

  • 基本グループのモデルを作成する

  • コンピュータ グループとネットワーク アクセス グループ (NAG) を計画する

  • 追加の分離グループを作成する

  • ネットワーク トラフィック要件のモデルを作成する

  • コンピュータ グループと NAG のメンバシップを割り当てる

以降のセクションでは、それぞれのタスクについて説明します。

基本グループのモデルを作成する

通常の実装では、最初の分離グループとして共通の開始点を設定することをお勧めします。 次の図は、考慮する必要のある最初の 2 つの分離グループを示しています。

図 4.1: 基本となる分離グループ

基本グループは、分離グループの設計の開始点として最適な論理コンテナを提供します。

信頼されていないシステム

概念的には、最適な開始点は、組織の IT 部門が所有していないコンピュータ、管理していないコンピュータ、または存在すら把握していないコンピュータです。 これらのコンピュータは一般に信頼されていないホストまたは非管理ホストと呼ばれ、設計で最初に特定するシステムです。 これらのコンピュータではドメイン割り当ての IPsec ポリシーを使用できないので、ソリューションには組み込まれません。

このグループに分類されるコンピュータには、次のものがあります。

  • Windows ベース以外のコンピュータとデバイス : Macintosh および UNIX のワークステーションやパーソナル デジタル アシスタント (PDA) では、IPsec 機能を簡単に使用できない場合があります。

  • 古いバージョンの Windows オペレーティング システム： Microsoft Windows NT® 4.0 および Windows 9x を実行しているコンピュータでは、グループ ポリシー ベースの IPsec を使用できません。

  • 信頼されたドメインに参加していない Windows ベースのコンピュータ : スタンドアロン コンピュータでは、インターネット キー交換 (IKE) で Kerberos ドメイン間信頼を使用して認証を行うことができません。 IKE 認証の信頼境界として使用されているフォレストによって信頼されていないドメインに参加しているコンピュータは、ドメインまたはサーバーの分離ソリューションに参加できません。

  • マイクロソフト以外のその他のリモート アクセスまたは VPN クライアント : マイクロソフト以外の IPsec 仮想プライベート ネットワーク (VPN) クライアントが組織のリモート アクセス ソリューションに使用されていると、そのインストールによって Windows 固有の IPsec サービスが無効になる場合があります。 Windows 固有の IPsec サービスを使用できない場合、ホストはこのソリューションに参加できません。

    Windows 固有の IPsec サービスが実行されている場合でも、VPN クライアントは VPN トンネル接続を介したエンドツーエンドの IKE および IPsec 通信を許可する必要があります。 VPN 接続を介したエンドツーエンド IPsec が機能しない場合は、リモート アクセスに使用されるすべての IP サブネットの適用除外を作成できます。 このリモート クライアントが内部ネットワークに再接続された場合は、分離ソリューションに再度参加することができます。

分離ドメイン

分離ドメインは、信頼されたホストの最初の論理コンテナを提供します。 このグループ内のホストは、IPsec ポリシーを使用して、ホストに許可された通信を制御します。 ここでのドメインは、Windows ドメインではなく信頼境界を指します。 このソリューションでは、この 2 つの構造が非常によく似ています。信頼されたホストからの受信接続を受け入れるには Windows ドメイン認証 (Kerberos) が必要だからです。 ただし、多数の Windows ドメイン (フォレスト) が信頼関係でリンクされて単一の論理的分離ドメインを提供する場合があります。 そのため、これらを同一とは見なしません。

分離ドメインの通信特性は、"通常" または標準の規則を組織の大部分のコンピュータに提供することを目的としています。 これにより、通常の実装では、分離ドメインには最大数のコンピュータが含まれます。 分離ドメインとは異なる通信要件の分離グループがある場合は、ソリューションに他の分離グループを作成できます。 概念上は、分離ドメインは分離グループの一種にすぎません。

境界グループ

ほとんどの組織には、IPsec を使用して通信できないワークステーションやサーバーがいくつかあります。 たとえば、Mac や UNIX などのワークステーションでは IPsec を使用して通信できない場合がほとんどです。 これらのコンピュータのビジネス要件が分離ドメイン内の信頼されたホストとの通信ということはよくあります。 内部ネットワーク上のすべてのホストが同じレベルで信頼されて IPsec を使用でき、設計が単純であることが理想です。 しかし実際には、オペレーティング システムによって IPsec への対応度が異なります。

この状況に対処するには、分離グループ (このガイドでは境界グループ) を作成し、そこに信頼されていないシステムとの通信を許可するホストを含めることをお勧めします。 これらのホストは信頼されていないコンピュータからの着信通信を直接受信できるので、高レベルのリスクにさらされます。

境界グループ内のコンピュータは信頼されたホストであり、他の信頼されたホストおよび信頼されていないホストの両方と通信できます。 境界ホストは、IPsec を使用して通信を試行します。まず、IKE ネゴシエーションを発信元のコンピュータに対して開始します。 3 秒以内に IKE の応答がない場合は、ホストはクリアテキストにフォールバックして、IPsec を使用せずにプレーンテキストでの通信の確立を試行します。 境界グループ内のホストは動的 IP アドレスを持っている場合があります。分離ドメイン内で他の信頼されたホストと同じように IPsec ポリシーを使用するからです。 このような境界グループのホストは、IPsec でセキュリティ保護されたネットワーク通信を使用する信頼されたホストとの通信と、クリアテキストへのフォールバックを使用する信頼されていないホストとの通信が許可されるため、他の方法で高度にセキュリティ保護する必要があります。 この追加のリスクを理解し、軽減することは、コンピュータを境界グループに配置するかどうかを決定する上で重要です。 たとえば、コンピュータをこのグループに置くことに同意する前に、各コンピュータの正式なビジネス正当化プロセスを設定すると、追加のリスクが必要な理由をすべての関係者が理解できるようになります。 次の図は、このような決定をする際に役立つプロセス例を示しています。

図 4.2: 境界グループ メンバシップの決定プロセス例のフロー チャート

このプロセスの目標は、ホストを境界グループに追加することのリスクを、組織で許容できるレベルにまで軽減できるかどうかを判断することです。 最終的には、リスクを軽減できない場合はメンバシップを拒否することを前提とします。

適用除外リストを作成する

サーバーおよびドメインの分離のセキュリティ モデルはすべて、実際の環境に実装するときはいくつかの制約を受けます。 主要なインフラストラクチャ サーバー (ドメイン コントローラ、DNS サーバー、動的ホスト構成プロトコル (DHCP) サーバーなど) は、通常は内部ネットワーク上のすべてのシステムから使用できます。 明らかに、これらのサーバーをネットワーク攻撃から可能な限り保護する必要があります。 しかし、これらのサーバーはドメイン メンバだけでなくネットワーク上のすべてのシステムから使用できるので、これらのサーバー サービスでは受信アクセスに IPsec を要求できません。また、すべてのトラフィックで IPsec トランスポート モードによる保護を利用することができません。 これらのサービス (特に DNS) にアクセスするために行われるクリアテキストへのフォールバックには 3 秒かかり、内部ネットワーク アクセス全体のパフォーマンスに深刻な影響を与えるので、これらのサーバーを境界グループに入れることはできません。 また、コンピュータの起動時や、ネットワーク ケーブルまたはネットワーク カードがモバイル コンピュータに接続されたときに、 信頼されたホストは DHCP サーバーにアクセスしてインターネット プロトコル (IP) アドレスを取得する必要があります。 信頼されたホストは、ドメインにログオンして Kerberos 資格情報を取得するために、DNS でドメイン コントローラを検索する必要もあります。 したがって、IPsec を正しく機能させ、共通の内部ネットワーク インフラストラクチャの共有をすべての内部ホストに許可するには、IPsec 使用の対象外となるサーバーおよびサービス (プロトコル) のリストが必要です。 IPsec でセキュリティ保護されないコンピュータのリストは適用除外リストと呼ばれ、設計される各 IPsec ポリシーに実装されます。 信頼されたホストから IPsec を使用してアクセスできないサーバーが他にもネットワーク上にある場合は、これらも適用除外リストに追加できます。 ホストが適用除外リストに追加されるのは、一般に次のような場合です。

  • 信頼されたホストからアクセスする必要があるが、互換性のある IPsec が実装されていないホスト コンピュータの場合。

  • 信頼されていないホストと信頼されたホストにサービスを提供するホストが、境界分離グループのメンバシップの基準を満たしていない場合。

  • クリアテキストへのフォールバックで発生する 3 秒間の遅延またはアプリケーション トラフィックの IPsec カプセル化によって悪影響を受けるアプリケーションにホストが使用されている場合。

  • ホストが何千ものクライアントに同時に対応しており、パフォーマンスに影響するので IPsec を使用できない場合。

  • ホストが、信頼関係のない複数の分離ドメインに属する信頼されたホストに対応している場合。

  • ホストがドメイン コントローラである場合。ドメイン コントローラとドメイン メンバの間の IPsec は現在サポートされていないためです。 ただし、ドメイン コントローラは、このリストの他の基準を満たし、ドメイン メンバおよび分離概念のベースとなる Kerberos 認証に IPsec ポリシーを提供します。

  • ホストが信頼されたホストと信頼されていないホストに対応しているが、信頼されたホストとの通信のセキュリティ保護に IPsec を使用しない場合。

Windows での IPsec 実装は、静的フィルタリングのみに対応しており、動的 (ステートフル) フィルタリングには対応していません。 このため、送信トラフィックの静的な適用除外は、受信トラフィックの静的な適用除外にもなります。 適用除外されたホストは、各ホスト (信頼されたホストまたは信頼されていないホスト) に対して認証されていない受信アクセスを行います。 したがって、適用除外されたホストの数を最小限に抑え、これらのホストを攻撃とウイルス感染に対して可能な限り厳密に管理して強化する必要があります。 適用除外リストにあるホストからの受信攻撃のリスクを軽減するには、ホストベースのステートフル フィルタリング ファイアウォール (Windows ファイアウォールなど) を使用します。 Windows XP Service Pack (SP) 2 では、ファイアウォールの構成にドメインベースのグループ ポリシー制御が使用されます。 Windows ファイアウォールには、ポリシー設定の [Windows Firewall: Allow authenticated IPsec bypass] を使用することによって、ファイアウォールを経由する IPsec で保護された特定のコンピュータのみを承認する機能もあります。Woodgrove Bank では Windows ファイアウォール機能を実装しないことを選択しましたが、 他の環境では、分離ドメインまたは分離グループ内に高レベルのセキュリティが必要な場合もあります。 詳細については、Microsoft ダウンロード センターのホワイト ペーパー「Microsoft® Windows® XP Service Pack 2 向け Windows ファイアウォール設定の導入」を参照してください。

大規模な組織では、1 つの IPsec ポリシーですべての適用除外をドメイン全体またはすべての信頼されたフォレストに実装する場合、適用除外リストがかなり長くなります。 リストが長くなると、ポリシーが適用される各コンピュータに多くの悪影響を及ぼします。たとえば、次のようなものがあります。

  • 分離の全体的な効果が低減する。

  • 頻繁な更新のため、管理負荷が大きくなる。

  • ポリシーのサイズが大きくなるので、メモリと CPU リソースの消費が増え、ネットワーク スループットが低下し、ポリシーのダウンロードと適用にかかる時間が長くなる。

適用除外の数をできるだけ少なくするには、次のようなオプションがあります。

  • クリアテキストへのフォールバックにかかる 3 秒間の遅延に耐えられる通信には、適用除外を使用しない。 このオプションは、ドメイン コントローラには適用されません。

  • 各分離グループ (特にサーバーのみのグループ) の通信要件を慎重に検討する。 クライアントのドメインレベル ポリシーのすべての適用除外と通信する必要はない場合があります。

  • サーバー機能を統合する。 複数の適用除外サービスを 1 つの IP アドレスでホストできる場合は、フィルタの数を減らせます。

  • 同じサブネット上の適用除外ホストを統合する。 ネットワーク トラフィックの量によっては、各 IP アドレスに対して適用除外を使用するのではなく、適用除外されているサブネットにサーバーを配置することができます。

境界グループの定義と同じように、適用除外リストに追加するホストの承認には正式なプロセスが必要です。 適用除外の要求処理のモデルとして、前の図の決定フローを参照してください。

コンピュータ グループとネットワーク アクセス グループ (NAG) を計画する

分離ドメインおよび各分離グループには、ネットワーク セキュリティ要件の明確で完全な仕様が必要です。 "Tools and Templates" フォルダにある Business_Requirements.xls スプレッドシートは、要件を文書化する際のモデルになります。 受信および送信要件を文書化したら、アクセス制御を実装するためのメカニズムを設計できます。

プロセスのこの時点で、分離グループ要件を満たすために必要な新しい Active Directory グループの記録を開始する必要があります。 分離グループごとに、専用の Active Directory グループを最高 3 つ作成する必要があります。 ここからは、各グループの役割について説明します。

コンピュータ グループ

各分離グループにコンピュータ グループを作成して、そこに分離グループのメンバを含める必要があります。 これは、分離グループのセキュリティ要件が、ドメインで割り当てられている GPO の数種類のセキュリティ設定によって満たされるからです。 たとえば、このソリューションでは、セキュリティ グループ フィルタリングを GPO に使用して、IPsec ポリシーを特定の分離グループ内のコンピュータに配布します。 GPO が処理されると、コンピュータ グループのメンバーであるコンピュータ アカウントに、関連する IPsec ポリシーが割り当てられます。 これにより、適切な GPO を適用するために組織単位 (OU) 構造を分離グループ メンバシップに基づいて変更または新規作成しなければならない事態を回避します。 OU 構造を変更して分離グループ メンバシップを反映できる場合は、これらのコンピュータ セキュリティ グループでグループ ポリシーの適用を制御する必要はありません。

表 4.1: Woodgrove Bank のコンピュータ グループ

コンピュータ グループ名 説明
CG_IsolationDomain_Computers このユニバーサル グループには、分離ドメインを構成するすべてのコンピュータが含まれます。
CG_BoundaryIG_Computers このグループには、信頼されていないシステムからの通信を受け入れることができるすべてのコンピュータが含まれます。
##### ネットワーク アクセス グループ IPsec および Kerberos を使用するだけで、信頼されたシステムと信頼されていないシステムの認証境界ができます。 他のグループと区別するために、このガイドではこのグループを*ネットワーク アクセス グループ (NAG)* と呼びます。 作成できる NAG には、ALLOW グループと DENY グループの 2 種類があります。 他の信頼されたシステムがアクセスを明示的に許可または拒否する機能を制御するのが、これらのグループです。 この制御には、グループ ポリシーの \[ネットワーク経由でコンピュータへアクセスを拒否する\] (DENY) または \[ネットワーク経由でコンピュータへアクセス\] (ALLOW) ユーザー権利を使用します。 技術的にこのユーザー権利アクセス制御は、ログオン資格情報を取得して、ネットワークにログオンするアカウントを認証するネットワーク サービスのみに適用されます。 "アカウント" は、コンピュータ、ユーザー、またはサービス アカウントの場合があります。 IPsec ポリシーがすべてのトラフィックを保護するように構成されている場合、IKE はリモート コンピュータのネットワーク ログオン権利を承認します。 これにより、IPsec で保護された接続をリモート コンピュータから確立する機能が、ネットワーク ログオン権利によって制御されます。 この IP レベルのアクセス制御がチェックされた後は、一般に通常の上位層プロトコル (ファイル共有など) がユーザーを認証し、ユーザー識別情報のネットワーク ログオン権利を再度評価します。 最後に、サーバー固有のアクセス許可 (ファイル共有アクセス制御リストなど) が、ユーザー識別情報を使用して評価されます。 詳細については、「第 2 章 : サーバーおよびドメインの分離を理解する」のネットワーク アクセス制御層の図を参照してください。 既定では、ALLOW ユーザー権利には、すべての認証されたユーザー*および*コンピュータにコンピュータへのアクセスを許可する *Everyone* グループが含まれます**。 このソリューションの実装時に、Everyone グループは組織の要件に応じて、グループ ポリシー ユーザー権利の割り当てを介して、特定のコンピュータまたはユーザーおよびグループを含む NAG に置き換えられます。 同様に、DENY ユーザー権利には IPsec で保護された受信アクセスが想定されていないコンピュータが含まれます。 単一のグループにユーザー アカウントとコンピュータ アカウントを含めることもできますが、ユーザーとコンピュータを別々のグループにすることをお勧めします。 この方法では、ポリシーとグループを継続的に管理およびサポートする機能が向上します。 ALLOW および DENY ユーザー権利割り当ての構成は、以前の Windows プラットフォームのセキュリティ ガイドに記載されているガイダンスを補足するものです。これらのガイドでは、IPsec に必要なコンピュータ認証が詳細に説明されていません。 NAG が実装する要件には、次のようなものがあります。 - 境界ホストまたはパブリック領域にある信頼されたホストから機密性の高いサーバーへのネットワーク アクセスをブロックする。 - 上級管理職専用サーバーへのアクセスを、上級管理職が使用するクライアント コンピュータのみに制限する。 - 研究開発プロジェクトの信頼されたホストを、ドメイン内の他の信頼されたホストから分離する。 Woodgrove Bank のシナリオでは、1 つのビジネス要件によって、年間に購入できるコンピュータ ハードウェアの数が制限されていました。 プリント サーバーは信頼されたホストと信頼されていないホストの両方に印刷を許可する必要がありました。 Woodgrove Bank は、信頼されていないコンピュータのみが印刷に使用するサーバーの新規購入を希望していましたが、1 台のサーバーで両方のホストの要求を満たすことができると判断しました。 そこで、境界サーバーをプリント サーバーとして作成しました。 プリント サーバーは信頼されていないコンピュータからのウイルス感染や攻撃のリスクが高いので、残りの信頼されたホストではプリント サーバーからの受信アクセスをブロックする必要がありました。 信頼されたホストでは、引き続き必要に応じてプリント サーバーへの送信接続が可能になります。 したがって Woodgrove Bank では DENY NAG でこの要件を実装する必要があると判断しました。 設計プロセスのこの段階では、NAG メンバシップを割り当てる必要はありません。 必要なのは、設計に必要な NAG を特定して文書化することだけです。 Woodgrove Bank の設計者は、次の NAG が必要と判断しました。 **表 4.2: Woodgrove Bank のネットワーク アクセス グループ**
NAG 名 説明
DNAG_IsolationDomain_Computers このグループには、分離ドメイン内のすべての信頼されたホストへの IPsec で保護された受信接続を拒否されたドメイン コンピュータ アカウントが含まれます。
#### 追加の分離グループを作成する 設計プロセスのこの時点では、2 つの分離グループがあります。分離ドメインと境界グループです。 組織のビジネス要件がこの設計で満たされる場合は、この章の次のセクションに進み、これら 2 つの分離グループのトラフィック モデルを定義します。 しかし、組織の複数の信頼されたホストで別の受信または送信ネットワーク アクセス制御またはトラフィック保護が必要な場合は、要件セットごとに分離グループが必要になります。 ここでは、追加のグループが必要な場合について説明します。 まず、分離ドメインの設定によって満たされない固有の分離またはトラフィック保護要件を持つコンピュータを特定します。 目標はこれらのホストの数を最小限に抑えることです。新しいグループが増えるたびに設計全体が複雑になり、サポートと管理が難しくなるからです。 新しいグループの作成につながる要件には、一般に次のようなものがあります。 - 暗号要件 - ネットワーク レベルで必要なホストまたはユーザー アクセスの制限 - 分離ドメインとは異なる発信/着信ネットワーク トラフィック フローまたは保護の要件 多くの場合、価値の高いデータを含むサーバーの受信アクセス要件は、ドメインにある信頼されたホストのサブセットのみに接続を許可することです。 信頼されたホストから信頼されていないコンピュータへの送信接続が許可されない場合もあります。情報漏えいのリスクを減らすためや、ネットワーク トラフィックの保護規制に準拠するためです。 たとえば、Woodgrove Bank のシナリオでは、設計者は次の 2 つの分離グループを追加作成することでのみ満たされる要件を特定しました。 - *暗号化*グループ。最高レベルの保護を必要とする価値の高いデータを含むアプリケーション サーバーの小グループが含まれます。 信頼されたクライアントの特定のサブセットのみがこれらのサーバーへの受信接続を許可されます。 これらのサーバーとのすべてのネットワーク トラフィックには、財務データのプライバシーに関する米国連邦規制に準拠した 128 ビット レベルの暗号化が必要です。 最後に、これらのサーバーでは信頼されていないホストへの送信接続または境界ホストからの受信接続が許可されていません。 - *フォールバックを行わない*グループ。これは、信頼されていないシステムへのネットワーク通信を制限しなければならない分離ドメイン内のいくつかの信頼されたホストに必要です。 2 番目のグループにはフォールバックを行わないという要件がありますが、アプリケーション サーバーにある完全な要件セットはありません。 したがって、このの 2 つの異なる要件セットは、2 つの分離グループを追加する必要があることを示しています。 これらの追加グループによって、Woodgrove Bank のグループの合計数は 4 になりました。 次の図は、Woodgrove Bank の分離グループの最終設計におけるこれらのグループの位置を示しています。 ![](images/Dd362840.SGFG403(ja-jp,TechNet.10).gif) **図 4.3: Woodgrove Bank のグループの最終設計** 設計の要件を満たすには、次の 4 つのグループにポリシーが必要です。 - **分離ドメイン** : これは、すべての信頼されたコンピュータの既定のグループです。 - **境界分離グループ** : このグループは、信頼されていないホストがアクセスできるコンピュータに割り当てられます。 - **暗号化分離グループ** : このグループは、信頼された暗号化通信パスを使用した通信のみを許可します。 - **フォールバックを行わない分離グループ** : このグループには、セキュリティ要件が高く、信頼されていないホストへの通信を直接開始することを許可されないコンピュータが含まれます。 Woodgrove Bank は、IPsec ポリシーを必要とする 2 つの追加グループを特定したので、これらの新しく特定したポリシーの適用を制御する追加のコンピュータグループを定義しました。 **表 4.3: Woodgrove Bank の追加のコンピュータ グループ**
コンピュータ グループ名 説明
CG_NoFallbackIG_Computers このグループには、クリアテキストへのフォールバックを許可されていないすべてのコンピュータが含まれます。
CG_EncryptionIG_Computers このグループには、暗号化を使用する必要があるすべてのコンピュータが含まれます。
その結果、Woodgrove Bank は信頼されたホストのサブセットに対する受信アクセスを承認する NAG が必要であると判断しました。 Woodgrove Bank の設計者は、次の NAG を作成しました。 **表 4.4: Woodgrove Bank のネットワーク アクセス グループ**
NAG 名 説明
ANAG_EncryptedResourceAccess_Users このグループには、暗号化分離グループ サーバーへのアクセスを承認されたすべてのユーザーが含まれます。
ANAG_EncryptedResourceAccess_Computers このグループには、暗号化分離グループ サーバーへの受信ネットワーク アクセスを承認されたすべてのコンピュータが含まれています。
DNAG_EncryptionIG_Computers このグループには、暗号化分離グループ内のホストへのアクセスを拒否されるコンピュータ アカウントのグループが含まれます。
#### ネットワーク トラフィック要件を収集する 設計プロセスのこの時点で、グループ間で渡される通信トラフィック要件を通信の形式と共に文書化する必要があります。 グループのトラフィック要件を記録する方法は多数あります。 しかし、マイクロソフトの IT サポート チームは独自の経験から、正確な要件を伝達するには図を作成することが最適な方法であると考えました。 次の図は、基本グループ、信頼されていないホスト、および適用除外リストの間で一般に許可される通信パスを示しています。 モデルを簡略化するために、適用除外リストは 1 つのグループとして表示されています。 これは、ドメイン コントローラや DNS サーバーなどのインフラストラクチャ サービスの一般的な例です。 ただし、分離グループは、そのグループ内の特定のコンピュータのみを適用除外するビジネス要件を持つ場合があります。 この場合、分離グループには、共通の適用除外に加えて除外されるコンピュータの追加の適用除外リストが含まれます。 適用除外リストのエントリは最小限に抑えることをお勧めします。エントリによってシステムが IPsec インフラストラクチャへの参加から明示的に除外されるためです。 次の図では、黒い実線の矢印は IPsec を使用する通信を示します。点線の矢印は IPsec を使用しない通信を示しす。 太字の破線で囲まれているグループでは、そのグループ内のコンピュータに IPsec ポリシーが割り当てられています。 ![](images/Dd362840.SGFG404(ja-jp,TechNet.10).gif) [拡大表示する](https://technet.microsoft.com/ja-jp/dd362840.sgfg404_big(ja-jp,technet.10).gif) **図 4.4: 基本分離グループに許可される一般的な通信パス** 次の表は、基本グループ、セキュリティ保護されていないシステム、および適用除外リストの間のトラフィックに許可される通信パスを示しています。 **表 4.5: 基本分離グループに許可される通信オプション**
パス 始点 終点 双方向 IKE/IPsec の試行 フォールバック 暗号化
1 ID EX はい いいえ いいえ いいえ
2 ID BO はい はい いいえ いいえ
3 ID UN いいえ はい はい いいえ
4 BO EX はい いいえ いいえ いいえ
5 BO UN いいえ はい はい いいえ
6 UN BO いいえ いいえ いいえ いいえ
7 UN EX はい いいえ いいえ いいえ
この表は、最初の分離グループ設計における許可された各通信パスの通信要件を示します。 以下では、各列について説明します。 - **パス** : グループ図に示された通信パスに割り当てられた番号です。 - **始点** : トラフィックの開始側を含むグループです。 - **終点** : 許可された通信パスを介してアクセスされる応答側を含むグループです。 - **双方向** : パスで開始側と応答側の役割を逆に許可して、**始点**または**終点**のいずれかのグループからトラフィックを開始できるかどうかを示します。 - **IKE/IPsec の試行** : このパスで IPsec を使用して通信のセキュリティ保護を試行するかどうかを示します。 - **フォールバック** : IKE ネゴシエーションにしっばいした場合に、IPsec を使用しない通信に戻れるかどうかを示します。 - **暗号化** : IPsec ポリシーに設定された暗号化アルゴリズムを使用して、このパスで通信を暗号化する必要があるかどうかを示します。 表をできるだけ簡潔にするために、グループ名には省略形を使用しました。 この文書化の形式を使用することにより、ソリューションの通信を非常に簡潔に表すことができます。 すべてのネットワーク トラフィックがこの表で特定されていない限り許可されないことを前提にすることによって、ソリューションの一部として保護されるトラフィックを特定するプロセスがより明確になります。 上の図の例では、次の許可された各パスについて説明しています。 - トラフィック パス 1、4、および 7 は、IPsec ポリシーの適用除外リストに記載されているすべてのホスト用に特に許可されたネットワーク通信を示しています。 適用除外は分離グループによって異なる場合があります。 - トラフィック パス 2 は、分離ドメインと境界グループの間の通信を示しています。 このパスでは、IPsec を使用したトラフィックの保護を試行します。 セキュリティ要件によっては、トラフィックを暗号化する必要があります。 IKE ネゴシエーションが失敗した場合は、クリアテキストにフォールバックするオプションが設定されていないため、通信は失敗します。 - パス 3 は、分離ドメイン内のホストが信頼されていないホストとの通信を開始できることを示しています。 これが可能なのは、このグループのポリシーでは、最初の IKE ネゴシエーション要求に応答がない場合に、分離ドメインのホストがクリアテキストにフォールバックすることを許可されるからです。 信頼されたホストとの非 IPsec 通信の開始を試行する信頼されていないシステムは、IPsec 受信フィルタによってブロックされます。 - トラフィック パス 5 と 6 は、境界グループと信頼されていないシステムの間に許可された通信を示しています。 パス 4 は、信頼されていないホストへのクリア テキストでの送信通信が境界グループに許可されることを示しています。 IKE ネゴシエーションに応答がない場合は、ホストはクリアテキスト通信へのフォールバックを実行します。 パス 5 は、信頼されていないホストから開始された境界グループへのトラフィックを示しています。 この矢印はパス 4 と似ていますが、表の説明によると、信頼されていないホストは境界グループとの IKE ネゴシエーションを試行せず、 クリア テキスト TCP/IP 接続を行います。 基本通信を文書化したら、追加グループを全体的な計画に追加し、それらの通信要件を同様に記録できます。 たとえば、Woodgrove Bank のシナリオでは、2 つの追加グループが必要でした。これらのグループによって、通信図は次のように複雑になります。 ![](images/Dd362840.SGFG405(ja-jp,TechNet.10).gif) [拡大表示する](https://technet.microsoft.com/ja-jp/dd362840.sgfg405_big(ja-jp,technet.10).gif) **図 4.5: Woodgrove Bank の分離グループに許可される通信パス** 次の表は、Woodgrove Bank のシナリオで追加されたグループのトラフィックに許可される通信パスを示しています。 **表 4.6: 追加の分離グループに許可される通信オプション**
パス 始点 終点 双方向 IKE/IPsec の試行 フォールバック 暗号化
8 EN EX はい いいえ いいえ いいえ
9 EN ID はい はい いいえ はい
10 EN NF はい はい いいえ はい
11 EN BO いいえ はい いいえ はい
12 NF ID はい はい いいえ いいえ
13 NF EX はい いいえ いいえ いいえ
14 NF BO はい はい いいえ いいえ
上の図と表に示されている例では、次の許可された各追加パスについて説明しています。 - パス 8 と 13 は、適用除外されたすべてのトラフィックのクリア テキスト通信です。 - パス 9 と 10 は、暗号化グループ、フォールバックを行わないグループ、および分離ドメイングループの間で必要な IPsec カプセル化セキュリティ ペイロード (ESP) によって暗号化された通信を示しています。 IKE ネゴシエーションに失敗して暗号化を使用した通信のセキュリティ保護ができない場合は、試行した通信が失敗します。 - パス 11 のトラフィックは、若干異なり、暗号化グループから開始される境界グループへの通信のみを許可し、その逆は許可しません。 Woodgrove Bank では、価値の高いデータを暗号化グループに配置しており、信頼されていないリソースから直接アクセスされるコンピュータにそのデータを公開することを希望していないからです。 - 12 と 14 のトラフィック パスは、IPsec AH トランスポート モード、または暗号化なし (ESP-Null) で認証される IPsec ESP トランスポート モードによって実装されます。 この例のように、追加グループによってソリューションが急激に複雑になることがあります。 このため、最も多くの変更が行われる展開の初期段階では特に、グループの数を最小限に抑えることをお勧めします。 #### コンピュータ グループとネットワーク アクセス グループのメンバシップを割り当てる 設計でトラフィック要件を詳細に文書化したら、次はどのホストをどのコンピュータ グループまたは NAG のメンバにするかを特定します。 前述のとおり、このソリューションでは、コンピュータ グループを使用して、関連する IPsec ポリシーを含む GPO を適用します。 特定の分離グループに属する必要があるコンピュータを決定したら、分離グループのコンピュータ グループにそのコンピュータのアカウントを追加します。 分離ドメインについてはこの手順は必要ありません。すべてのドメイン コンピュータは暗黙的に分離ドメイン コンピュータ グループに属するからです。 NAG のメンバシップは、NAG が実装する受信承認に基づきます。 たとえば、特定のサーバーから既知のクライアント セットへの通信を制限する NAG が存在する場合は、クライアント コンピュータ アカウントを適切な NAG に配置する必要があります。 NAG は必要な場合のみ作成されるので、既定の構成はありません。 ##### コンピュータ グループのメンバシップ 重要なのは、1 つのホストを複数のコンピュータ グループに配置できないことです。これは、コンピュータ グループを使用して GPO の適用を制御するからです。 理論上はポリシーを変更して 1 つのホストを複数のコンピュータ グループに配置することは可能ですが、この方法は複雑なので、ソリューションのサポートが急激に難しくなります。 一般に、コンピュータ グループのメンバシップを決定するこのタスクは複雑ではありませんが、時間がかかります。 「第 3 章 : IT インフラストラクチャの現在の状態を把握する」で実行したような監査から生成した情報を使用して、ホストの分離グループ メンバシップに基づいて各ホストを 1 つのコンピュータ グループに配置します。 この配置を決定するには、次の表のように、最終設計にグループ列を追加して、コンピュータ グループ メンバシップを記録します。 **表 4.7: ホスト収集データの例**
ホスト名 ハードウェア要件の達成 ソフトウェア要件の達成 必要な構成 詳細 見積もりコスト グループ
HOST-NYC-001 いいえ いいえ ハードウェアとソフトウェアの両方のアップグレード 現在のオペレーティング システムは Windows NT 4.0。 古いハードウェアは Windows XP と互換性がない。 $XXX ID
SERVER-LON-001 はい いいえ 信頼されたドメインへの参加、NT 4 から Windows 2000 以降へのアップグレード ウイルス対策ソフトウェアがインストールされていない。 $XXX EN
##### ネットワーク アクセス グループのメンバシップ この設計プロセスの最後の手順は、この章で特定した NAG のメンバシップを割り当てることです。 コンピュータ グループの場合は 1 つの信頼されたホストを 1 つのコンピュータ グループに所属させる必要がありますが、NAG の場合は 1 つの信頼されたホストを複数の NAG のメンバにすることができます。 できるだけ少数の NAG を使用して、ソリューションが複雑にならないようにしてください。 メンバシップをユーザー アカウントの NAG に割り当てるときは、アクセスの制御をどの程度厳しくするかを決定します。 既に標準の共有アクセス許可とファイルのアクセス許可を使用して適性レベルの制御を行っているリソースの場合、最も簡単にメンバシップを割り当てるには、リソースにアクセスする必要がある、フォレスト内の信頼された各ドメインに属する Domain Users にユーザーの NAG メンバシップを割り当てます。 この方法では、Authenticated Users の元の既定値の動作がほぼ復元されますが、ローカル ユーザー アカウントは含まれません。 ローカル ユーザーまたはサービスのアカウントが必要な場合は、ドメインベースの GPO で ALLOW および DENY ネットワーク ログオン権利を構成する方法は最適ではありません。 ALLOW および DENY ユーザー権利の割り当てでは、複数の GPO の設定を組み合わせることはありません。 したがって、このコンピュータでは、ドメインベースの GPO を ALLOW および DENY に割り当てないようにし、カスタマイズしたローカル GPO を使用する必要があります。 IPsec ポリシーの割り当てを配布するドメインベースの GPO が、ネットワーク ログオン権利を配布する GPO とは異なる場合は、IPsec ポリシーを割り当てるドメインベースの GPO を引き続き使用できます。 さらに、ALLOW NAG と DENY NAG のどちらかまたは両方を使用する受信アクセス要件の実装方法も決定します。 作成する NAG の種類は、目的の動作と、管理作業を最小限に抑えることのみを基に決定します。 ユーザー用の既存の空の DENY NAG と、GPO で \[ネットワーク経由でコンピュータへアクセスを拒否する\] 権利が割り当てられているコンピュータ用の DENY NAG があると便利です。 セキュリティの高いシナリオでは、ユーザー NAG のメンバシップを特定のユーザーまたはグループに割り当てることができます。 この方法を使用すると、このグループのメンバでないユーザーは、ローカル管理者グループのメンバですべての共有アクセス許可およびファイルのアクセス許可に対するフル コントロール権限を持っていても、ネットワークを介したコンピュータへのアクセスをブロックされます。 Woodgrove Bank のシナリオでは、NAG\_EncryptedResourceAccess\_Users メンバシップが Domain Users に割り当てられ、次の表のように記録されました。 **表 4.8: Woodgrove Bank のネットワーク アクセス グループとメンバシップの割り当て**
NAG 名 メンバシップ 説明
ANAG_EncryptedResourceAccess_Users User7 このグループは、暗号化分離グループのコンピュータへの IPsec で保護された受信接続の確立を承認されたすべてのユーザー用です。
ANAG_EncryptedResourceAccess_Computers IPS-SQL-DFS-01
IPS-SQL-DFS-02 IPS-ST-XP-05		 このグループには、暗号化分離グループのコンピュータへの IPsec で保護された受信接続の確立を承認されたすべてのコンピュータが含まれます。
DNAG_EncryptionIG_Computers CG_BoundaryIG_Computers このグループには、暗号化分離グループのコンピュータへの IPsec で保護された受信接続の確立を承認されていないすべてのコンピュータが含まれます。
**注 :** NAG のメンバシップは、IPsec トラフィック保護のレベルを制御しません。 IPsec ポリシー設定が、トラフィック保護に使用するセキュリティ メソッドを制御します。IPsec ポリシー設定は、IKE によって認証される識別情報とは無関係です。 IKE ネゴシエーションでは、認証プロセスで Kerberos コンピュータ識別情報が渡されたか失敗したかを認識するだけです。 "user3 が接続した場合に暗号化 " または "信頼されたホスト IPS-SQL-DFS-01 または IPS-SQL-DFS-02 の場合に暗号化 " というポリシーを実装することはできません。 管理者は、"あらゆる信頼されたホストからの受信接続の暗号化" および "あらゆる信頼されたホストへの送信接続の暗号化" が必要な暗号化分離グループ内のサーバーの IPsec ポリシーを使用して、目的の動作を達成する必要があります。 ここまで、この設計プロセスでは IPsec ポリシー設計の詳細を見直していません。 Woodgrove Bank の IPsec ポリシー設計の詳細については第 5 章で説明します。 設計プロセスのこの時点では、要件をドラフト設計に変換するタスクが完了しています。 ここでは、IPsec ポリシーの作成に必要な設計と文書の両方の開発について説明しました。 ##### 設計に影響する可能性がある制限 次の問題は設計に影響する可能性があるので、設計を完了したと見なす前に検討する必要があります。 - **一意のホストからサーバーへの IPsec を使用した同時接続の最大数**。 同時接続の最大数は、使用頻度の高いサーバーへの IPsec 実装が順調に進むのか、IKE または IPsec の処理で CPU が過負荷になるのかを左右する要因です。 正常な各 IKE ネゴシエーションで確立される SA は、約 5 KB のユーザーモード メモリを占有します。 すべての同時接続ピアの現在の IKE SA 状態を維持するために CPU リソースが必要です。 拡張の詳細については、ホワイト ペーパー「[Improving Security with Domain Isolation: Microsoft IT implements IP Security (IPsec)](https://technet.microsoft.com/ja-jp/library/bb735174.aspx)」 を参照してください。 - **IPsec を使用するホストの Kerberos トークンの最大サイズ制限**。 実質的な制限は 1 ユーザーにつき約 1,000 グループです。この値を超えると、GPO の適用に失敗します。 詳細については、マイクロソフト サポート技術情報 (KB) 327825「[New Resolution for Problems That Occur When Users Belong to Many Groups](https://support.microsoft.com/?kbid=327825)」 (英語) および 306259「[Members of an Extremely Large Number of Groups Cannot Log On to the Domain](https://support.microsoft.com/?kbid=306259)」(英語) を参照してください。 これらの文書では特にユーザーについて記述されていますが、コンピュータ アカウントについても同じ問題があります。Kerberos MaxTokenSize がコンピュータ アカウントにも適用されるからです。 たいていの実装ではこの制限に到達することはまずありませんが、1 台のコンピュータ (おそらくクライアント) を多数の NAG に配置する場合は、この問題に注意する必要があります。 これらの問題が設計に影響する場合は、設計プロセスを再検討して問題に対処する必要があります。 たとえば、同時接続の最大数の問題に対処するには、非常に大きな負荷がかかっているサーバーを適用除外リストに移動します。 Kerberos トークンの最大サイズ制限に対処するには、設計で使用する NAG の数を減らします。 これらの制限が設計に影響しない場合は、次のタスクとして、設計を組織に展開する方法を検討します。 [](#mainsection)[ページのトップへ](#mainsection) ### グループの実装方法 初期設計を作成したら、IPsec を実装するプロセスについて慎重に検討する必要があります。 ポリシーをすべてのコンピュータに簡単に展開し、IPsec を円滑に動作させ、ユーザーへの影響を許容範囲内の小さなものにとどめることができるのは、最小の環境においてのみです。 大規模な組織では、複雑さとリスクから段階的に展開を進める必要があります。 この方法により、組織は環境に対するこのような基本的な変更に関連するリスクを軽減することができます。 慎重に計画しないと、ヘルプ デスクへの問い合わせや生産性低下によって、展開のコストが急激に増加します。 組織内で IPsec を展開するにはさまざまな方法があります。 展開方法を決定する要因には次のようなものがあります。 - 環境の開始状態と終了状態 - グループ構成の複雑さ - ドメイン構造の複雑さ - 組織のリスク許容度 - セキュリティ要件 ここで説明する展開方法は、包括的ではありませんが、実行可能な方法の例です。 これらの方法を組み合わせて使用することもできます。 一般に、組織は通信を制限またはブロックする IPsec ポリシーを最初から展開するべきではありません。問題をトラブルシューティングするための十分な時間を確保し、複雑な環境の管理調整を減らすためです。 どの方法で IPsec を展開する場合でも、展開シナリオを、公開手順やポリシー変更の特定の手順およびタイミングなどを含め、ラボ環境で徹底的にテストすることを強くお勧めします。 さらに、IPsec 機能を要求しても、クリアテキストへのフォールバックを実行することによってプレーンテキスト通信を受け入れるフィルタ操作を使用します。 この方法は、初期の公開の影響を最小限に抑えます。 公開が完了したら、トラフィックの IPsec 保護を要求する、より安全な運用モードに移行します。 運用環境での展開には、公開の主要段階ごとに初期パイロットを使用することを強くお勧めします。 IPsec ポリシーの変更による影響を分析することは特に重要です。Kerberos チケットの有効期間、グループ ポリシーのポーリング間隔、IPsec ポリシーのポーリング間隔などから運用環境に影響するためです。 ロールバック戦略およびロールバック基準を備えた正式な変更制御プロセスを実装して、影響を受けるすべての IT 組織に変更とその影響を認識させ、意思決定者へのフィードバックを整理する方法を知らせる必要があります。 #### グループごとの展開 グループごとの展開方法では、完全に定義された IPsec ポリシーを使用しますが、ポリシーを配布する GPO のグループおよび ACL を使用してポリシーの適用を制御します。 グループごとの展開方法では、IPsec ポリシーは最終構成で Active Directory に作成されます。 各 IPsec ポリシーにはすべての適用除外と、適切なフィルタ操作を有効にして定義された安全なサブネットが含まれます。 次に、IPsec ポリシー管理者によって 各 IPsec ポリシーの GPO が作成されます。 さらに、ドメインでコンピュータ グループが作成されて、新規作成されたこれらの GPO が管理および適用されます。 GPO の ACL が変更されて、Authenticated Users メンバの "適用" 権利がなくなります。 ポリシーの管理と適用を行う適切な管理者ユーザーグループには GPO に対する権利も付与されます。 次に、適切な IPsec ポリシーが、対応する GPO に割り当てられます。 さらに、GPO が Active Directory 内の適切なオブジェクトにリンクされます。 この時点では、GPO の割り当て (GPO 読み取り機能) を制御する ACL が空なので、環境内のコンピュータがポリシーを受け取ることはありません。 最後に、ポリシーを受け取るコンピュータが特定され、GPO に対する読み取りアクセス権限を持つ適切なコンピュータ グループにそのコンピュータ アカウントが配置されます。 コンピュータの Kerberos チケットがグループ メンバシップ情報で更新されると、GPO および対応する IPsec ポリシーが次のグループ ポリシー ポーリング間隔で適用されます。 **注 :** Active Directory の IPsec ポリシー オブジェクトまたは IPsec ポリシー コンテナの読み取りをドメイン コンピュータに制限する ACL はお勧め*できません*。 組織に IPsec 標準および IPsec 暗号化という 2 つの IPsec ポリシーが定義されているとします。 IPsec 標準ポリシーは既定のポリシーで、着信トラフィックには IPsec の使用を要求しますが、システムが非 IPsec ベース コンピュータへの接続を開始する場合は、クリアテキストへのフォールバックの実行を許可します。 IPsec 暗号化ポリシーでは、暗号化された IPsec のネゴシエーションが常に必要です。 この例では、組織の管理者が 2 つの GPO を Active Directory に作成します。標準 IPsec GPO と暗号化 IPsec GPO です。 これらが特定するグループを次の表に示します。 **表 4.9: IPsec 管理グループ**
グループ名 グループの種類 説明
IPsecSTD ユニバーサル IPsec 標準ポリシーの適用を制御
IPsecENC ユニバーサル IPsec 暗号化ポリシーの適用を制御
新規作成された 2 つの GPO の ACL が更新されて、ACL が Authenticated Users グループに自動的に適用されないようになり、適切な適用グループおよび管理グループに適切な権利が付与されます。 管理者は 2 つの GPO の ACL を次の表の情報に従って変更しました。 **表 4.10: GPO のグループ権利**
グループ 標準 IPsec GPO 暗号化 IPsec GPO
Authenticated Users 読み取り 読み取り
IPsecENC なし 読み取り グループ ポリシーの適用
IPsecSTD 読み取り グループ ポリシーの適用 なし
**注 :** この表は追加または変更されたアクセス許可のみを示しています。 他にもアクセス許可を持つグループが存在します。 管理者は Active Directory で 2 つの GPO をドメインにリンクしました。 この方法では、ポリシーは確実にドメイン内のコンピュータに適用されます。このとき、配置が変わることはありません (ポリシーをブロックする OU にコンピュータが配置されている場合を除く)。 コンピュータが特定されると、そのコンピュータ アカウントが IPsecSTD グループまたは IPsecEnc グループに追加されます。 しばらくして、対応する IPsec ポリシーが適用されて有効になります。 この方法では、通信が中断されないように慎重に計画する必要があります。 たとえば、サーバーを IPsecEnc グループに配置しても、そのサーバーに依存する複数のクライアントが IPsec をネゴシエートできない場合、クライアントとサーバーの間の通信が中断されます。 #### ポリシーの構築ごとの展開 この展開方法では、展開時に IPsec ポリシーを新たに構築できます。 この方法の長所は、グループごとの展開方法のようにすべての内部サブネットに対してではなく、TCP/IP トラフィック全体のうちわずかなトラフィックに対してのみ IPsec のネゴシエーションが行われることです。 また、内部ネットワークでこの対象サブネットへのネットワーク パスをすべてテストして、ネットワークが渡す IKE ネゴシエーションと IPsec で保護されるトラフィックに問題がないことを確認できます。 さらに、IPsec のポーリング間隔によって、IPsec ポリシーの更新 (ロールバックを含む) をより早く配布できるという長所もあります。Kerberos チケット許可チケット (TGT) またはサービス チケットでのグループ メンバシップの変更に依存する必要がありません。 この方法の短所は、グループごとの展開方法のように特定のコンピュータではなく、分離ドメインまたはグループ内のすべてのコンピュータに適用されることです。 また、指定のサブネットと通信する際のある時点で、クリアテキストへのフォールバックによる 3 秒間の遅延がすべてのコンピュータで発生します。 この展開方法では、最初、IPsec ポリシーには例外のみが含まれます。コンピュータがセキュリティをネゴシエートするための規則は IPsec ポリシーに存在しません。 この方法ではまず、使用中の可能性がある既存のローカル IPsec ポリシーをテストし削除します。 管理チームは、先にローカルで定義された IPsec ポリシーを使用しているホストを特定して、特別なプロセスでこれらのシステムを管理できる必要があります。 ローカル IPsec ポリシーよりもドメイン ポリシーが優先される場合は、通信が中断され、影響を受けるコンピュータのセキュリティが失われます。 ドメイン ポリシーの適用によって上書きされるローカル ポリシーとは異なり、Windows Server 2003 の継続ポリシーはドメイン ポリシーの適用結果と結合されます。 継続ポリシーを含むシステムが機能しているように見えても、継続ポリシーの構成によって、動作が変更されたり、ドメイン ポリシーが提供するセキュリティが実際に低減したり、セキュリティ保護サブネット規則がポリシーに追加された後で通信が中断されたりしていることがあります。 次に、組織のネットワーク上の単一サブネットのみに影響するフィルタを持つセキュリティ規則を作成できます。たとえば、 "任意の IP からサブネット A へのすべてのトラフィック、ネゴシエート " という規則を作成します。この規則には、受信プレーンテキストを受け入れ、クリアテキストへのフォールバックが許可されているサブネットへの送信トラフィックのネゴシエーションをトリガするフィルタ操作が含まれています。 すべてのドメインでこの IPsec ポリシーの公開が有効になると、そのサブネットでのみ信頼されたホストの通信がソフト SA から通常の IPsec セキュリティ アソシエーションに次第に移行します。 失敗した IKE ネゴシエーションは、調査および解決されます。 適用に非互換性がある場合は、特定されて修正されます。 IPsec は、サブネット内の信頼されたホスト間の通信をセキュリティ保護します。 サブネット外の信頼されたホストとの通信は、3 秒の遅延後にクリアテキストにフォールバックされます。 ポリシーが構築されて最終状態なるまで、追加のサブネットがセキュリティ保護規則に追加されます。 組織に IPsec 標準ポリシーという単一の IPsec ポリシーが定義されているとします。このポリシーは、IPsec ネゴシエーションを要求しますが、失敗した場合はクリア テキスト通信にフォールバックします。 ポリシーは Active Directory に作成され、適用除外の規則のみが含まれます。 標準 IPsec GPO が作成され、環境内のすべてのコンピュータに適用されるようにリンクされます。 さらに、IPsec 標準ポリシーがこの新しい GPO に割り当てられます。 最終的にすべてのコンピュータに IPsec ポリシーが割り当てられます。 このドメイン ポリシーが既存のローカル ポリシーよりも優先されるので、ローカル IPsec ポリシーの問題があれば発見されます。 すべてのサブネットが安全なサブネットフィルタ一覧に表示されるまで、問題が継続的に解決されます。 [](#mainsection)[ページのトップへ](#mainsection) ### Woodgrove Bank のグループ実装 Woodgrove Bank では、運用展開を実装するのに、まず構築ごとの方法ですべてのコンピュータを境界グループに移動することを選択しました。 この方法では、管理者は、すべてのシステム間の通信に大きな影響を与えることなく、徐々に実装を進めて未解決の問題を解決することができました。 まずセキュリティ保護サブネットなしでポリシーを展開することにより、管理チームはローカル IPsec ポリシーが割り当てられているシステムを特定し、追加検討する情報を得ることができました。 サブネットがポリシーに追加されると、それまでに発見された追加の競合が解決されました。 コンピュータが境界グループ ポリシーで運用されるようになった後、チームは分離ドメイン グループ、フォールバックを行わないグループ、および暗号化グループを実装しました。 これらのグループの展開には、グループごとの展開方法を使用しました。 一連のコンピュータがパイロット用に選択され、新しいポリシーを制御する適切なグループに追加されました。 問題は発見されるたびに解決され、グループがいっぱいになるまで追加のコンピュータがグループに追加されました。 次の表は、ソリューションが完全に展開された後のコンピュータ グループおよび NAG とそれらのメンバシップを示しています。 **表 4.11: コンピュータ グループとネットワーク アクセス グループのメンバシップ**
コンピュータ グループまたはネットワーク アクセス グループ メンバ
CG_IsolationDomain_Computers ドメイン コンピュータ
CG_BoundaryIG_Computers IPS-PRINTS-01
CG_NoFallbackIG_Computers IPS-LT-XP-01
CG_EncryptionIG_Computers IPS-SQL-DFS-01 IPS-SQL-DFS-02
ANAG_EncryptedResourceAccess_Users User7
ANAG_EncryptedResourceAccess_Computers IPS-SQL-DFS-01
IPS-SQL-DFS-02 IPS-ST-XP-05
DNAG_EncryptionIG_Computers CG_BoundaryIG_Computers
ANAG\_EncryptedResourceAccess\_Computers グループには、暗号化分離グループ内のサーバーが含まれることに注意してください。 これは、これらのサーバーが必要に応じてサーバー自体またはサーバーどうしで通信できるようにするためです。 これらのサーバーにこの通信が必要ない場合は、これらのサーバーをこのグループに追加する必要はありません。 [](#mainsection)[ページのトップへ](#mainsection) ### 要約 この章では、サーバーおよびドメインの分離ソリューションの設計プロセスについて説明しました。 ここでは、コンピュータ グループおよび NAG の必要性の特定、基本分離グループの理解、追加分離グループの追加、トラフィック モデルの完成、グループへのメンバシップの割り当て、および展開の公開方法の計画を行いました。 また、Woodgrove Bank という架空の組織での IPsec 実装例を使用して実際の設計プロセスを説明し、マイクロソフトのテスト ラボで設計を立証しました。 グループの設計は、ビジネス要件と、前の 2 つの章で取得し **Business\_Requirements.xls** スプレッドシート (Tools and Templates フォルダ内) に記載されている検出情報に基づいて行いました。 ネットワークへの IPsec の影響を認識することも、重要な検討事項でした。 この章を読むと、分離グループの計画、これらのグループ間の通信要件の文書化、および高レベルの IPsec ポリシーの計画を開始するための十分な情報が得られます。 これらのタスクを終えると、「第 5 章 : 分離グループの IPsec ポリシーを作成する」に進むことができます。 #### 関連情報 ここでは、このソリューションの実装に役立つ可能性のある関連情報へのリンクを紹介します。 ##### IPsec 次のリンクは、Windows 固有の IPsec についてさまざまな情報を提供しています。 - ホワイト ペーパー「[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)」では、機密情報を処理または格納する内部サーバーへのネットワーク アクセスを IPsec を使用してセキュリティ保護する場合の最初のモデルについて説明しています。 このホワイト ペーパーは、www.microsoft.com/downloads/ details.aspx?FamilyID=a774012a-ac25-4a1d-8851-b7a09e3f1dc9&displaylang=en (英語) からダウンロードできます。 - すべてのドメイン メンバを保護する IPsec の Microsoft での展開例については、ケース スタディ「[Improving Security with Domain Isolation: Microsoft IT implements IP Security (IPSec)](https://technet.microsoft.com/ja-jp/library/bb735174.aspx)」www.microsoft.com/technet/itsolutions/msit/ security/ipsecdomisolwp.mspx (英語) を参照してください。 - 「[IPsec for Windows 2000](https://www.microsoft.com/download/details.aspx?familyid=501a48d5-a3ee-4094-aeb4-16bbff098810&displaylang=en)」www.microsoft.com/downloads/details.aspx?familyid=501a48d5-a3ee-4094-aeb4-16bbff098810&displaylang=en (英語) - Microsoft Windows Server 2003 の「[IPsec](https://www.microsoft.com/windowsserver2003/technologies/networking/ipsec/default.mspx)」www.microsoft.com/windowsserver2003/technologies/networking/ipsec/ (英語) ##### セキュリティ - マイクロソフトにおける IT セキュリティ リスクの評価方法については、ホワイト ペーパー「[IT Security at Microsoft Overview](https://technet.microsoft.com/ja-jp/library/bb687780.aspx)」www.microsoft.com/technet/itsolutions/msit/security/mssecbp.mspx を参照してください。 ##### Windows Server 2003 Active Directory Active Directory の詳細については、次を参照してください。 - 「[Active Directory](https://www.microsoft.com/japan/windowsserver2003/technologies/directory/activedirectory/default.mspx)」www.microsoft.com/japan/windowsserver2003/technologies/directory/activedirectory/default.mspx [](#mainsection)[ページのトップへ](#mainsection)