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

  • [アーティクル]

第 3 章 : IT インフラストラクチャの現在の状態を把握する

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

この章では、サーバーおよびドメインの分離ソリューションの計画と展開に必要な情報を入手する方法について説明します。 展開を成功させるためには、情報技術 (IT) インフラストラクチャの最新の状態を正確に知る必要があります。 この章を読むと、サーバーおよびドメインの分離ソリューションの設計に必要な情報について十分に理解できます。

この章の最後の部分では、特定されたコンピュータのうちどれが、このソリューションで "信頼された" コンピュータとして機能できるかについて理解し、記録するプロセスについて説明します。 この情報は、設計チームがこのソリューションの計画を作成するときに必要です。

トピック

章の前提条件
対象読者
現在の状態を把握する
容量に関する考慮事項
展開前の注意事項
信頼の決定
現在のホストのアップグレード コストを計算する
要約

章の前提条件

この章の情報を利用する前に、組織で以下の前提条件が満たされていることを確認してください。 この章では、以下の前提条件にほぼ当てはまる組織のニーズに特に合わせて説明しています。 以下の条件をまったく満たさなくてもプロジェクトにマイナスの影響があるとは限りませんが、以下の条件に当てはまる場合はこのガイダンスを最大限に活用できます。

知識の前提条件

IPsec の概念に精通し、次の項目についても確実に理解している必要があります。

  • Microsoft® Windows® 認証 (特に Kerberos Version 5 認証プロトコル)

  • Active Directory® ディレクトリ サービスの概念 (Active Directory の構造とツール。ユーザー、グループその他の Active Directory オブジェクトの操作。グループ ポリシーの使用法。)

  • Windows システムのセキュリティ (ユーザー、グループ、監査、アクセス制御リスト (ACL) などのセキュリティ概念)

  • 組織のシステムの名前付け規則

  • 組織の物理的な場所と論理的な場所

  • 組織で使用されているリスク管理方法

  • コア ネットワーキングの概念 (ファイアウォールを使用したポート フィルタリング)  

この章を読み進める前に、このガイドの前の章も読み、このソリューションの構造と設計の概念を十分に理解してください。

組織の前提条件

組織内で分離グループを計画する場合、通常は多くのさまざまな立場の人がこのタスクに関係します。 組織の要件を正確に判断するために必要な情報は、多くの場合、組織全体のさまざまな部門から得られます。 分離グループの計画に参加する必要がある、組織の他のメンバとよく話し合ってください。たとえば次のような人が考えられます。

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

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

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

  • DNS (ドメイン ネーム システム)、Web サーバー、およびアプリケーションの所有者

  • ネットワークの管理および運用の担当者

  • 社内の研修およびヘルプ デスクの担当者  

    注 : IT 組織の構造によっては、これらの役割を何人かで分担している場合もあれば、少人数で複数の役割を兼任している場合もあります。

上記のチームから情報を収集するほかに、環境への IPsec の導入に伴い、現在の運用方法を更新する必要があることを理解することが重要です。 また、ネットワーク デバイスの BIOS やファームウェアのアップデートなど、ソフトウェアおよびハードウェアのアップデートが必要になる可能性もあります。 最後に、IPsec 環境のサポートおよびトラブルシューティング用にネットワーク ツールの追加が必要になる場合もあります。

前提となる 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 の新機能」ページを参照してください。

  • ネットワークを監視し、監視データを分析し、そのデータに基づいて容量計画を決定するための技術と専門知識。

    注 : 多くの組織では、ネットワーク監視ツールの使用が制限されています。このため、このツールを使用するときは正しい運用手順に従うように注意する必要があります。

  • ネットワーク上のホストについてのネットワーク構成データを取り込むツールが配置されていること。 たとえば、既存の資産管理システムを使用してこの情報を収集できます。 詳細については、この章の「ホストの検出」を参照してください。

ページのトップへ

対象読者

この章は、ソリューションの設計者が使用する IT インフラストラクチャのインベントリの作成を担当する IT 専門家を対象としています。 このような IT 専門家は多くの場合、組織のサポート スタッフまたは運用スタッフです。 この章を最大限に活用するためには、情報収集プロセスで使用するツールとテクノロジ、および組織の現在のインフラストラクチャの両方について、技術的な面を十分に理解している必要があります。

ページのトップへ

現在の状態を把握する

組織のコンピュータ、ソフトウェア、およびネットワーク デバイスについての信頼できる記録を取得し、管理するプロセスは、IT における長年の課題です。 プロジェクトが成功するかどうかは、このようなプロセスによって取得した情報にかかっています。 サーバーおよびドメインの分離プロジェクトの計画プロセスを始める前に、組織に既に展開されているコンピュータ、ネットワーク、およびディレクトリ サービスについての最新の情報を集めて分析する必要があります。 この情報により、既存のインフラストラクチャで考えられるすべての要素を考慮した設計ができます。 収集した情報が正確でない場合、計画段階で考慮されていなかったデバイスやコンピュータが実装の段階で現れると、問題が発生する可能性があります。 以降のセクションでは、各領域で必要な情報の概略を説明し、Woodgrove Bank のサーバーおよびドメインの分離ソリューションで収集された情報の例を示します。

ネットワークの検出

サーバーおよびドメインの分離を計画する際に最も重要な点はおそらく、ネットワーク アーキテクチャです。これは、IPsec がインターネット プロトコル自体の上に多層化されているからです。 ネットワークについての理解が不十分であったり不正確である場合は、分離ソリューションは成功しません。 サブネットのレイアウト、IP アドレスの割り当て方式、トラフィック パターンについての理解もこれに含まれますが、このプロジェクトの計画段階を完了するには次の 2 つの作業が非常に重要です。

  • ネットワークのセグメンテーションの文書化

  • 現在のネットワーク トラフィック モデルの文書化

目標は、資産が位置する物理的な場所に加えてネットワーク上の論理的な場所を特定するための十分な情報を得ることです。

まず、よく考えられて構成され、アドレス範囲の特定が容易で、重複や不連続の範囲が最小限に抑えられているネットワーク アーキテクチャから始めることをお勧めします。 企業合併および買収など固有のビジネス要件または状況があるために、"合理化された" ネットワークにはならないかもしれませんが、現在の状態を文書化し、理解しておくと、ネットワークとそこで管理されている資産の特定作業が簡単になります。 複雑で適切に文書化されていないネットワークを設計の開始点にすると、多くの領域が特定されないまま残る可能性があるため、実装の段階で問題が発生する場合があります。

このガイドは、サーバーおよびドメインの分離を計画する際に最も関連する情報を取得するのに役立ちますが、TCP/IP のアドレス割り当てと可変長サブネット マスク、仮想ローカル エリア ネットワーク (VLAN) のセグメンテーションなどのネットワーク最適化の方法および技術といった、その他の問題については説明していません。 取得した情報は、サーバーおよびドメインの分離ソリューションの実装および運用のコンポーネントを開発するために使用されます。

ネットワークのセグメンテーションの文書化

組織の現在のネットワーク アーキテクチャが文書化され、参照できるようになっていない場合は、このソリューションの先へ進む前にこのような文書を至急作成する必要があります。 文書化された情報が最新ではないか、最近検証されていない場合、基本的に次の 2 つの選択肢があります。

  • この情報が原因でプロジェクトに過度のリスクがもたらされる可能性を受け入れる

  • 手作業またはネットワーク分析ツールで検出プロジェクトを開始し、現在のネットワーク トポロジの文書化に必要な情報を得る

必要な情報はさまざまな方法で表現できますが、現在のネットワーク構成を表し理解するには、多くの場合、一連の概略図を使用するのが最も有効です。 ネットワークの概略図を作成する場合、あまり多くの情報を入れすぎないようにしてください。 必要に応じて、別の層の詳細を示す図を複数使用します。

たとえば Woodgrove Bank のシナリオでは、次の図を作成して、既存のワイド エリア ネットワーク (WAN) およびサイト環境の概要を表しました。

図 3.1: Woodgrove Bank の WAN およびサイトのネットワーク概略図 拡大表示する

この図の作成後、サイトごとに詳細図を作成し、最終的に各サイト内のサブネットの図を作成しました。

ネットワークの文書化の過程で、一部のネットワーク アプリケーションやネットワーク サービスに IPsec との互換性がないことがわかる場合があります。 現在わかっている互換性の問題には、次のものがあります。

  • ルーター上の Cisco NetFlow で、IPsec メンバ間のパケットをプロトコルまたはポートに基づいて分析できません。

  • ルーターベースの QoS (Quality of Service) で、ポートまたはプロトコルを使用してトラフィックに優先順位を付けることができません。 ただし、特定の IP アドレスを使用してトラフィックに優先順位を付ける方法は影響を受けません。 たとえば、"ポート 80 を使用する任意の発信元から任意の発信先への通信を優先する" という規則は機能しませんが、"任意の発信元から 10.0.1.10 への通信を優先する" という規則は影響を受けません。

  • IP プロトコル 50 (カプセル化セキュリティ ペイロード (ESP) が使用するポート) をサポートまたは許可しないデバイス。

  • WFQ (Weighted Fair Queuing) およびその他のフローベースのルーター トラフィックの優先順位付けは失敗する場合があります。

  • ネットワーク モニタで、暗号化されていない (ESP-Null) ESP パケットを解析できない場合があります。

    注 : Microsoft Network Monitor version 2.1 では ESP パーサーが追加され、暗号化されていない IPsec パケットのトラブルシューティングができるようになっています。 Network Monitor は Microsoft Systems Management Server (SMS) のコンポーネントです。 詳細については、「Microsoft Systems Management Server」ページを参照してください。

  • デバイスで ESP を解析できない場合、ポートまたはプロトコルの規則を指定する ACL が ESP パケットで処理されません。

  • デバイスに ESP パーサーがあり、暗号化を使用している場合、ポートまたはプロトコルの規則を指定する ACL が ESP パケットで処理されません。

IPsec を使用すると、ポートおよびプロトコルを使用したネットワークベースの優先順位付けやポート/プロトコルベースのトラフィック管理が正しく機能しません。 残念ながら、暗号化されたパケットを処理する代わりの方法はありません。 トラフィック管理または優先順位付けをポートまたはプロトコルに基づいて行う必要がある場合は、ホスト自体にトラフィック管理または優先順位付けを行う機能がなければなりません。

次に、ネットワークのさまざまなデバイスについてどのような情報が必要かを正確に記録する必要があります。

ネットワーク インフラストラクチャのデバイス

ネットワーク インフラストラクチャを構成するデバイス (ルーター、スイッチ、ロード バランサ、ファイアウォール) は、このソリューションの実装後、IPsec を使用して通信することになります。 このため、これらのネットワーク デバイスについて次に挙げる項目を調べて、この設計の技術的および物理的要件に対応できることを確認することが重要です。

  • 製造元/モデル : この情報から、そのデバイスでサポートされる機能を確認できます。 また、そのデバイスで実行されている BIOS またはソフトウェアを調べ、IPsec がサポートされているかどうかも確認します。

  • RAM 容量 : この情報は、容量や、そのデバイスに IPsec が与える影響を判断する場合に役立ちます。

  • トラフィック分析 : この情報 (ピーク時使用率およびデバイスの日常の使用を示す日別/週別の傾向) があると常に役に立ちます。 IPsec に関して、この情報がデバイスのスナップショットとなり、デバイスがある一定期間どのように使用されるかがわかります。 IPsec の実装後に問題が発生した場合は、その根本原因がデバイスの使用率の高さに関係しているかどうかを判断するのに役立ちます。

  • IPsec に直接影響する ACL : ACL は、特定のプロトコルの機能に直接影響します。 たとえば、Kerberos プロトコル (UDP (User Datagram Protocol) および TCP ポート 88) または IP プロトコル (ポートではなくプロトコル) 50 または 51 が許可されないと、IPsec は機能しません。 また、NAT トラバーサル (NAT-T) を使用する場合、インターネット キー交換 (IKE) トラフィック (UDP 500 および 4500) を許可するようにデバイスを設定する必要があります。

  • デバイス インターフェイスに接続されているネットワーク/サブネット : この情報から、内部ネットワークの構成を可能な限り正確に分析することができます。 アドレス範囲に基づいてネットワークの境界を定義する方法は非常にわかりやすく、他のアドレスが管理されていないのか、内部ネットワーク以外のもの (インターネット アドレスなど) なのかを特定できます。 この情報は、このガイドの以降の章で IPsec ポリシーを決定する際に必要です。

  • デバイスでネットワーク アドレス変換 (NAT) を実行しているかどうか : ネットワーク アドレス変換 (NAT) は、接続されているネットワークまたはインターネットに対して、アドレス範囲全体を単一の IP として表す場合に一般的に使用されています。 ソリューションの計画担当者は、このプロセスがネットワークのどこで行われているかを知る必要があります。

    注 : マイクロソフト サポート技術情報 (KB) 818043「Windows XP および Windows 2000 用 L2TP/IPSec NAT-T 更新プログラム」では、Windows XP Service Pack (SP) 1 および Windows 2000 SP4 用の NAT-T 更新プログラムをダウンロードできます。 ただし、Windows XP SP2 または Windows Server 2003 SP1 がインストールされていないと、IPsec 応答側は正しく機能しません。

  • VLAN のセグメンテーション : VLAN が現在ネットワークにどのように実装されているかを確認すると、現在のトラフィック パターンやセキュリティ要件を理解できます。また、IPsec によってセキュリティ要件が増加したり競合する可能性も確認できます。

  • デバイスが接続されているリンク : この情報は、デバイスがどのネットワーク間の接続を管理しているかを表すのに役立ちます。 また、特定のインターフェイスでさまざまな場所への論理ネットワークおよび接続を特定する場合にも役立ちます。

  • デバイス インターフェイスの最大転送単位 (MTU) サイズ : MTU は、特定のインターフェイスで、転送用に分割 (断片化とも呼ばれるプロセス) せずに転送できる最大データグラムを表します。 IPsec 通信では、MTU は断片化が発生する領域を把握するのに必要です。 パケットの断片化は、ISAKMP (Internet Security Association and Key Management Protocol) 用にルーターで追跡する必要があります。 IPsec では、セッションの MTU サイズが、使用される通信パスの最小検出 MTU に設定され、do not fragment ビット (DF ビット) が 1 に設定されます。

    注 : パスの MTU (PMTU) の検出が有効で正しく機能している場合は、デバイス インターフェイスの MTU サイズを調べる必要はありません。 「Windows Server 2003 Hardening Guide」などの資料では、PMTU の検出を無効にすることを推奨しています。 ただし、IPsec が正しく機能するためには PMTU の検出を有効にする必要があります。

また、IPsec は侵入検知システム (IDS) にも影響する可能性があります。これは、パケット内のデータの変換に特定のパーサーが必要になるからです。 IDS にパーサーがない場合は、このようなパケット内のデータを IDS で検証できず、特定のセッションが脅威となる可能性があるかどうかを判断できません。 この場合、IPsec を使用するということは、組織において IPsec の必要性が IDS の必要性を上回ることを意味します。

このセクションで確認した情報は、プロジェクトの成功にとって非常に重要です。これらの情報によって、デバイスを IPsec 対応に構成する (またはデバイスが既に IPsec トラフィック用に構成されている場合は、さらに負荷を増大させる) 前に、ネットワーク インフラストラクチャの現在の構成と "健康状態" を把握できるからです。 ピーク使用率の情報を確認することにより、デバイスが現在の状態のまま IPsec に対応できるかや、予想される負荷に耐えるためにはメモリやファームウェアのアップグレードが必要かを判断できます。 製造元やモデルの情報は、デバイスのアップグレードが必要な場合、ハードウェアの購入時に役立ちます。 その他の構成パラメータや機能の情報は、製造元やモデルに固有のものの場合もありますが、やはり役に立つ場合があります。 デバイスに構成された ACL の数は、デバイスを IPsec 対応に構成するのに必要な作業を見積もる目安になります。 ネットワークに、IPsec トラフィック用に構成されているデバイスが 1 つもなく、ネットワークに多数のルーターが存在する場合、デバイス構成はかなりの労力を要します。

これらの情報を集めると、このプロジェクトの要件を満たすためにデバイスのアップグレードが必要か、ACL の変更が必要か、またはデバイスが予想される負荷に耐えられるように別の措置を取る必要があるかどうかを迅速に判断できます。

現在のネットワーク トラフィック モデルの分析

アドレス割り当てとネットワーク インフラストラクチャの情報を集めたら、次は通信フローを慎重に検証する手順に進みます。 たとえば、人事 (HR) などの部門が複数の建物に分かれており、この部門の情報を IPsec で暗号化する場合、これらの建物がどのように接続されているかを調べて、その接続に設定する "信頼" のレベルを決定する必要があります。 高度に安全な建物が、保護されていない別の建物に、銅ケーブルで接続されている場合は、盗聴または情報のリプレイ攻撃によって危害を受ける可能性があります。 このような攻撃が脅威となる場合は、信頼されたホストに対する IPsec が提供の強固な相互認証とトラフィック暗号化が有効です。 ただしこのソリューションでは、信頼されたホストに対する物理的なセキュリティがない場合は脅威に対処できないという点は考慮されていません。

トラフィック フローを検証する際は、Windows 2000 SP4 より前のバージョンの Windows や、Linux、UNIX、Mac など Windows ベース以外のデバイスも含め、すべての管理されたデバイスと管理されていないデバイスが相互にどのように接続されているかに特に注意します。。 次のことを確認してください。特定の通信がポート/プロトコル レベルで行われているか、または同一ホスト間に多くのセッションがさまざまなプロトコルを使用して確立されているか。 サーバーとクライアント相互の通信はどのように行われているか。 現在実装または計画されているセキュリティ デバイスまたはプロジェクトで、分離プロジェクトに影響しそうなものはあるか。 たとえば、Windows XP SP2 および Windows ファイアウォールを使用して UDP 500 などの特定のポートを "ロック ダウン" している場合、IKE ネゴシエーションが失敗する原因になります。

「第 2 章 : サーバーおよびドメインの分離を理解する」で行った脅威モデルの作成プロセスを使用して、さまざまな種類のネットワーク トラフィックを検証すると、信頼されていないまたは管理されていないデバイスからセキュリティ保護する必要があるトラフィックを生成するプロトコルおよびアプリケーションが簡単にわかります。 一般的なアプリケーションとプロトコルには次のものがあります。

  • NetBIOS over TCP/IP (NetBT) およびサーバー メッセージ ブロック (SMB) : LAN では、ポート 137、138、139 を NetBT 用に、ポート 445 を SMB 用に有効にするのが一般的です。 これらのポートは、NetBIOS 名前解決サービスおよびその他の機能を提供します。 残念ながら、これらのポートでは Null セッションとして知られるセッションも確立されます。 Null セッションとは、既知のユーザーまたはエンティティのセキュリティ コンテキストを使用しないホストで確立されるセッションです。 このようなセッションは多くの場合匿名セッションです。

  • リモート プロシージャ コール (RPC) : 通常 RPC は、リスン ポート (エンドポイント マッパーとも言う。TCP ポート 135) を備えたアプリケーションを提示することによって動作し、このアプリケーションが、一時的な範囲の別のポートで通信を開始するように "呼び出し元" (多くの場合別のアプリケーション) に指示します。 ファイアウォールでセグメント化されたネットワークでは、この RPC 通信が構成上の問題になります。つまり、RPC 通信によって RPC リスン ポートと 1024 より上のすべてのポートが開くことになるからです。 このように多くのポートが開くと、ネットワーク全体で攻撃対象となる範囲が広がり、ファイアウォールの効果は減少します。 ただし RPC の利点は、RPC を使用するアプリケーションで、OSI (Open Systems Interconnection) モデルの第 1 層から第 4 層の機能を抽象化できることです。このため開発者は、分散アプリケーション用に低レベルの呼び出しをネットワークに行わなくてすみます。 多くのアプリケーションが基本機能を RPC に依存しているため、IPsec ポリシーでは RPC を考慮する必要があります。 IPsec ポリシー作成の詳細については、「第 5 章 : 分離グループの IPsec ポリシーを作成する」を参照してください。

  • その他のトラフィック : IPsec では、パケット内のデータの暗号化に加え、パケットの認証機能によって、ホスト間のデータ送信をセキュリティ保護できます。 重要なのは、何を保護する必要があるか、またどのような脅威に対処する必要があるかを特定することです。 必要に応じて、セキュリティ保護する必要があるその他のトラフィックまたはトラフィックの種類を検証し、モデルを作成します。 たとえば、ごくわずかなクライアントのみがアクセスを許可されている特殊用途のデータベース、または HR (人事) マネージャだけが使用する HR チーム用の特殊なアプリケーションなどが考えられます。

物理および論理ネットワークの文書化がすんだら、次の手順として現在のトラフィック パターンを検証し、次の質問に回答します。

  • 現在、特定の種類のトラフィック専用のサブネットはあるか (たとえば、Mac ワークステーションおよび UNIX ワークステーション、またはメインフレームと端末の接続など)。

  • さまざまな種類別にトラフィックを分けたり、サイト間のトラフィックを分ける必要があるか。

Active Directory

情報収集の際、ネットワークの次に重要なのが Active Directory です。 ドメインのレイアウト、組織単位 (OU) の構造、サイト トポロジなどのフォレストの構造を理解する必要があります。 この情報から、現在コンピュータが配置されている場所、コンピュータの構成、IPsec の実装に伴う Active Directory への変更が与える影響を知ることができます。 この部分の検出作業を終えるために必要な情報を次に挙げます。

  • フォレストの数 : フォレストは Active Directory の実装におけるセキュリティ境界なので、分離する必要があるホストや分離を実現する方法を決定するには、現在の Active Directory のアーキテクチャを理解する必要があります。

  • ドメインの名前と数 : IPsec 認証は、IKE ネゴシエーション プロセスの結果として行われます。 このソリューションの認証方式は Kerberos プロトコルです。 このプロトコルは、コンピュータがドメインに参加していることと、オペレーティング システムのバージョンの必要条件 (Windows 2000、Windows XP、または Windows Server 2003) を満たしていることを前提にしています。

  • 信頼の数と種類 : 信頼の数と種類を確認することが重要なのは、信頼が分離の論理的境界に影響し、またこのソリューションで IKE 認証をどのように行えるか (または行う必要があるか) も定義するからです。

  • サイトの名前と数 : サイトの構造は、通常ネットワーク トポロジと一致しています。 Active Directory でサイトがどのように定義されているかがわかると、複製やその他の詳細を理解する手がかりとなります。 このソリューションでは、サイトの構造から、現在の Active Directory の実装の状態をより深く理解できます。

  • OU 構造 : OU 構造を作成するときのちょっとした計画で、運用効率を大幅に向上させることができます。 OU は論理的な構成概念であるため、多様な要件や目的に合わせて変形させることができます。 OU 構造は、グループ ポリシーが現在どのように使用されているかや、OU がどのように配置されているかを検証するのに最適です。 このソリューションの第 4 章と第 5 章では、OU の構造と、OU を使用して IPsec ポリシーを適用する方法について詳しく説明しています。

  • IPsec ポリシーのこれまでの使用方法 : このプロジェクトの最終目標は IPsec ポリシーの実装なので、ネットワークで現在 IPsec を使用している場合は、その使用方法を理解することが非常に重要です。 単純な IPsec フィルタ (強化ガイドに規定されているようなフィルタ) を使用しているか完全なポリシーを実装しているかにかかわらず、現在の使用方法と要件を理解することで、このソリューションをよりスムーズに統合できます。

Woodgrove Bank のシナリオでは単一のフォレスト (corp.woodgrovebank.com) を使用しています。このフォレストには 5 つのサイトにまたがる 4 つのドメインがあります。 各サイトには、次の表に示すようにドメイン コントローラ (DC)、プライマリ ドメイン コントローラ (PDC)、またはグローバル カタログ (GC) サーバーがあります。

表 3.1: Woodgrove Bank の Active Directory の情報

物理的なサイト ドメイン [Users] ドメイン コントローラの種類
ニューヨーク (ニューヨーク州) corp.woodgrovebank.com
americas.corp.woodgrovebank.com		 5,000 フォレスト ルート グローバル カタログ
PDC
アメリカ地域の GC
ヨーロッパ地域の DC
アジア地域の DC
シカゴ (イリノイ州) americas.corp.woodgrovebank.com 750 アメリカ地域の GC
アトランタ (ジョージア州) americas.corp.woodgrovebank.com 1,450 アメリカ地域の GC
ボストン (マサチューセッツ州) americas.corp.woodgrovebank.com 480 アメリカ地域の GC
サンフランシスコ (カリフォルニア州) americas.corp.woodgrovebank.com 250 アメリカ地域の GC
ピッツバーグ (ペンシルバニア州) americas.corp.woodgrovebank.com 50 アメリカ地域の GC
フェニックス (アリゾナ州) americas.corp.woodgrovebank.com 50 アメリカ地域の GC
マイアミ (フロリダ州) americas.corp.woodgrovebank.com 50 アメリカ地域の GC
ワシントン DC americas.corp.woodgrovebank.com 75 アメリカ地域の GC
ケンブリッジ (マサチューセッツ州) americas.corp.woodgrovebank.com 36 アメリカ地域の GC
トロント (カナダ) americas.corp.woodgrovebank.com 25 アメリカ地域の GC
ロンドン (英国) europe.corp.woodgrovebank.com
corp.woodgrovebank.com		 5,200 フォレスト ルート GC
PDC エミュレータ
ヨーロッパ地域の GC
アメリカ地域の DC
アジア地域の DC
ジュネーブ (スイス) europe.corp.woodgrovebank.com 350 ヨーロッパ地域の GC
アムステルダム (オランダ) europe.corp.woodgrovebank.com 295 ヨーロッパ地域の GC
ミュンヘン (ドイツ) europe.corp.woodgrovebank.com 149 ヨーロッパ地域の GC
ローマ (イタリア) europe.corp.woodgrovebank.com 80 ヨーロッパ地域の GC
ダブリン (アイルランド) europe.corp.woodgrovebank.com 79 ヨーロッパ地域の GC
エディンバラ (スコットランド) europe.corp.woodgrovebank.com 40 ヨーロッパ地域の GC
ヨハネスブルグ (南アフリカ) europe.corp.woodgrovebank.com 37 ヨーロッパ地域の GC
東京 (日本) asia.corp.woodgrovebank.com
corp.woodgrovebank.com		 500 フォレスト ルート GC
PDC エミュレータ
アジア地域の GC
ヨーロッパ地域の DC
アメリカ地域の DC
香港 (中国) asia.corp.woodgrovebank.com 100 アジア地域の GC
バンコク (タイ) asia.corp.woodgrovebank.com 150 アジア地域の GC
シンガポール asia.corp.woodgrovebank.com 210 アジア地域の GC
シドニー (オーストラリア) asia.corp.woodgrovebank.com 45 アジア地域の GC
バンガロール (インド) asia.corp.woodgrovebank.com 35 アジア地域の GC
台北 (台湾) asia.corp.woodgrovebank.com 65 アジア地域の GC
Woodgrove Bank の Active Directory 設計では、フォレストによって自動作成される双方向の信頼関係が使用されました。 クロス フォレストや外部の信頼は追加されていません。 次の図は、Woodgrove Bank で使用された OU 構造の概略図です。 この構造は、3 つの主要な地域ドメインである*アメリカ*、*ヨーロッパ*、*アジア*で共通して使用されました。 ![](images/Dd362839.SGFG0302(ja-jp,TechNet.10).gif) **図 3.2: Woodgrove Bank の OU 構造の例** [拡大表示する](https://technet.microsoft.com/ja-jp/dd362839.sgfg0302_big(ja-jp,technet.10).gif) このサーバーおよびドメインの分離プロジェクトが、Woodgrove Bank にとって初めての IPsec の実装だったため、既存のアクティブな IPsec ポリシーはありませんでした。 #### ホストの検出 資産の検出計画を行って得られる最も大きな利点は、ネットワーク上のホスト (ワークステーションとサーバー) に関する大量のデータを入手できることです。 「第 4 章 : 分離グループを設計および計画する」で行う決定では、ホストがこの設計の IPsec 通信に参加できるようにするために、すべてのホストの状態についての正確な情報が必要となります。 ##### ホストのデータ要件 ここでは、必要なホストの情報を説明し、この情報を物理的および論理的に表す方法を示します。 - **コンピュータ名 :** この名前は、ネットワークでそのコンピュータを特定する NetBIOS 名または DNS 名です。 1 台のコンピュータにメディア アクセス コントロール (MAC) アドレスや IP アドレスが複数存在する場合があるため、このコンピュータ名は、ネットワークでの一意性を判断するための 1 つの基準になります。 コンピュータ名は状況によって複製される可能性があるため、一意性は絶対と考えることはできません。 - **各ネットワーク インターフェイス カード (NIC) の IP アドレス :** IP アドレスは、サブネット マスクと一緒に使用され、ネットワーク上のホストを特定するアドレスです。 IP アドレスは変更されることが多いため、資産を特定する効果的な方法ではないことに注意してください。 - **各 NIC の MAC アドレス :** MAC アドレスは、ネットワーク インターフェイスの特定に使用する 48 ビットの一意のアドレスです。 同一デバイス上のさまざまなネットワーク インターフェイスを区別するのに使用します。 - **オペレーティング システム、サービス パック、ホットフィックス (更新プログラム) のバージョン :** オペレーティング システムのバージョンは、ホストが IPsec との通信に対応できるかどうかを判断する重要な要素です。 また、インストールされている可能性のあるサービス パックやホットフィックスの現在の状態を追跡することも重要です。最低限のセキュリティ標準を満たしているかどうかが、これによって判断される場合が多いからです。 - **ドメイン メンバシップ :** この情報で、コンピュータが IPsec ポリシーを Active Directory から取得できるかどうか、またはローカルの IPsec ポリシーを使用する必要があるかどうかを判断します。 - **物理的な場所 :** この情報は単純に、組織内でデバイスが配置されている場所です。 あるデバイスを特定の分離グループに組み込むかどうかを、そのデバイスの設置場所、またはそのデバイスが定期的に通信するデバイス群の設置場所に基づいて判断するのに使用します。 - **ハードウェアの種類/役割 :** この情報は、自動プロセスで収集することができない場合があります。 ホストの検出を実行するツールを使って、ハードウェア情報を照会し、ハードウェアの種類 (サーバー、ワークステーション、またはタブレット PC など) を特定するアプリケーションを実行すると、この情報を得ることができます。 この情報を使用して、特定のコンピュータが分離グループに組み込むのに適しているかどうかや、コンピュータをどの分離グループに入れるべきかを判断できます。 **注 :** ハードウェアの種類の情報は、データの補間によって、またはクエリを実行してこの情報を取得するソフトウェア製品によって知ることができます。 たとえば、HP Evo n800 は有名なモバイル コンピュータですが、ハードウェア レベルを照会できれば (またはそれを特定する資産タグがあれば)、このデバイスに割り当てる適切な IPsec ポリシーをより迅速に判断できます。 すべての情報を集め、データベースに統合したら、定期的に検出作業を実行し、情報を常に最新に保ちます。 組織の要件に合致する設計を作成するためには、ネットワーク上の管理されたホストを表す最新かつ完全な構成図が必要です。 ネットワーク上のホストから情報を収集するにはさまざまな方法があります。 ハイエンドな完全に自動化された方法もあれば、まったく手作業でデータを収集する方法もあります。 一般的には、スピードと正確さの点から、手動による方法よりも自動化された方法でデータを収集する方が好まれます。 いずれの方法でも、必要とされる情報は同じであり、情報の収集にかかる時間が異なるだけです。 手動による方法でよく問題になるのは、情報の重複、作業範囲を正確に定めること (すべてのネットワークをスキャンしてホスト情報を取得したのか、クライアントのサブネットだけを確認したのかなど)、プロジェクトに有効利用できるようにタイムリーに情報を取得することなどです。 IT システム全体の監査におけるすべての要素については、このプロジェクトの範囲外です。 ただし、このソリューションでの必要性以外に多くの理由から、この監査情報を組織で利用できるようにする必要があることを理解することが重要です。 最新の正確なシステム インベントリが必要となる重要なプロセスの例を 2 つだけ挙げると、資産管理とセキュリティ リスク管理があります。 ##### 自動検出 SMS などの自動監査ネットワーク管理システムを使用すると、IT インフラストラクチャの現在の状態について多くの重要な情報を得ることができます。 ただし自動システムの問題は、オフラインである、コンセントが入っていないなど何らかの理由で、情報の照会に物理的 (または論理的) に応答できないホストが最終的なデータベースに入らないことです。 最も自動化されたシステムでも、ホストをアクセス可能で正しく認識された状態にするには、手動で管理する部分が必要です。 さまざまなベンダから多くの製品やツールが発売されています。 中央でスキャンする方式のものもあれば、クライアント コンピュータにインストールしたエージェントを使用するものもあります。 購入のための製品比較や推奨はこのガイドの範囲外ですが、このソリューションでは、第 4 章および 5 章で設計に関して考慮する際に、この章で取り上げた検出データを使用する必要があります。 SMS 2003 を使用して資産管理を行う方法 (またはこのプロジェクトに必要な情報を収集する方法) の詳細については、「[SMS 2003 資産管理](https://www.microsoft.com/japan/smserver/evaluation/capabilities/asset.asp)」を参照してください。 ##### 手動による検出 手動による検出方法と自動化された方法の最も大きな違いは時間です。 このプロジェクトに必要な情報を手動で集める作業には、数十人の社員で行って何日も何週間もかかる場合があり、大規模な企業ではさらに長くかかる可能性があります。 手動による方法で組織のインフラストラクチャの現在の状態を監査することを計画している場合は、集めた情報をスプレッドシートやデータベースなどの電子的な形式で利用できるようにすることが重要です。 膨大な量のデータが生成される可能性があるため、必要な情報を返す特定のクエリを迅速かつ正確に生成できないと、フィルタリングや分析のプロセスは非常に困難になる恐れがあります。 さらに、ローカルの IT 管理者に、情報の取得や以前に収集した情報の検証を委任する方法もあります。 組織に自動監査ツールがない場合でも、Windows プラットフォームで提供されている標準的なリモート管理およびスクリプティング インターフェイスを使用することにより、自動化の要素を取り入れることができます。 このようなツールを使用するときに最も注意することは、管理ツールやスクリプトと互換性がないというだけでクライアントを見逃さないようにすることです。 Windows Scripting Host (WSH)、Microsoft Visual Basic® Scripting Edition (VBScript)、および Windows Management Instrumentation (WMI) を使用すると、システム構成情報を収集するスクリプト ファイルを作成できます。 次の表は、VBScript と WMI の使用条件をプラットフォーム別にまとめたものです。 **表 3.2: VBScript と WMI のプラットフォーム別の使用条件**

プラットフォーム VBScript WMI
Windows 95 WSH 5.6 をインストール WMI CORE 1.5 をインストール
Windows 98 ビルトイン WMI CORE 1.5 をインストール
Windows Millennium ビルトイン ビルトイン
Microsoft Windows NT® version 4.0 WSH 5.6 をインストール WMI CORE 1.5 をインストール
Windows 2000 ビルトイン ビルトイン
Windows XP ビルトイン ビルトイン
Windows Server 2003 ビルトイン ビルトイン
**注 :** Microsoft Windows Script 5.6 Update は、「[Windows Script](https://www.microsoft.com/japan/msdn/scripting/)」からダウンロードできます。[Windows Management Instrumentation (WMI) CORE 1.5](https://www.microsoft.com/download/details.aspx?displaylang=ja&familyid=afe41f46-e213-4cbf-9c5b-fbf236e0e875) のインストール ファイルは、Microsoft ダウンロード センターからダウンロードできます。 このソリューションの Tools and Templates フォルダには、**Discovery.vbs** というサンプルの VBScript が入っています。 このスクリプトでは WMI を使用して、この章の「ホストのデータ要件」に挙げた情報を、役割と物理的な場所以外すべて取得します。 この情報は、ローカル コンピュータの **C:\\Discovery\\<*システム名*>\_info.txt** のテキスト ファイル に収集されます。 このスクリプトを変更して、収集する情報を追加したり、収集した情報をリモート ファイル共有に格納することができます。 WMI または VBScript をホスト コンピュータで利用できない場合、一部の情報についてはバッチ スクリプトおよび外部のツールを使用して収集することができます。 問題なのは、バッチ言語は機能がかなり限られる点と、Windows の以前のバージョンではコマンド ラインから構成情報を簡単に取得することができない点です。 ホストの検出を実行するには、ホストに照会し、照会の結果を格納する場所を用意することが必要です。 情報の収集に自動、手動、またはその両方の組み合わせのいずれを使用する場合も、設計で問題となる可能性がある大きな注意点の 1 つは、最初のインベントリ スキャンの時点と実装を開始できるようになった時点との間に行われた変更を取り込むことです。 最初のスキャンが終了した後、このスキャン以降に行われたすべての変更と更新をインベントリに記録するようサポート スタッフに指示してください。 このインベントリは、以降の章で説明する IPsec ポリシーの計画と実装で重要になります。 [](#mainsection)[ページのトップへ](#mainsection) ### 容量に関する考慮事項 情報を収集したら、次は IPsec の影響について、容量計画も含めて考えます。 ここでは、環境への IPsec の導入を適切に計画するために不可欠ないくつかの点について説明します。 #### IPsec の影響 IPsec ではさまざまな暗号化手法を使用するため、コンピュータのオーバーヘッドはかなり大きくなります。 特に綿密な分析が必要となるシナリオは、暗号化を必要とするシナリオです。 たとえばあるシナリオでは Triple Data Encryption Standard (3DES) と Secure Hash Algorithm (SHA-1) を使用して、最も強固な暗号化とキー交換による保護が必要な状況での整合性をチェックします。 別のシナリオでは、セキュリティ アソシエーション (SA) のネゴシエーションを利用します。 メイン モード SA には、3 時間など短い有効期間を使用できますが、多くのセキュリティに関する考慮事項と同様、トレードオフを考慮する必要があります。 各メイン モード SA は約 5 KB の RAM を占有します。 サーバーが何万もの同時接続を処理することが求められる状況では、過負荷状態になる恐れがあります。 その他の要因には、ネットワーク インフラストラクチャ サーバーでの CPU 使用率の問題、IPsec を実行しているサーバーおよびワークステーションでのオーバーヘッドの増大 (特にサーバー。通常サーバーには、クライアントより多くのメイン モード SA が含まれるため)、IPsec のネゴシエーションの結果発生するネットワークの遅延の増大などがあります。 **注 :** マイクロソフトでこのソリューションを展開した経験から、IPsec を使用した直接の結果として、通常 1 ～ 3% のネットワーク使用率の増大が見込まれることがわかりました。 もう 1 つの主な注意点は、ネットワーク間が NAT デバイスで接続されている場合です。 問題は、NAT ではホスト間での認証ヘッダー (AH) のやり取りが許可されないということです。これは、ヘッダーを含む変更されていないパケットの認証を提供するという AH の大原則に NAT が違反することになるからです。 内部ネットワークに NAT デバイスがある場合は、AH の代わりに ESP を選択する必要があります。 ESP にはデータを暗号化する機能がありますが、暗号化は必須ではありません。 このことは、容量に関する考慮事項においても重要です。暗号化によるオーバーヘッドも、このプロジェクトの計画と設計の段階で考慮する必要があるからです。 ESP は Null 暗号化と共に実装することもできます。これにより、NAT との通信を遮断することなく、最も強固なピアツーピアの IPsec 通信を実現できます。 また暗号化を使用しないため、暗号化を使用する ESP よりも影響が少なくなります。 #### ポリシーの影響 IPsec ポリシーとグループ ポリシーはいずれも、コンピュータの起動時間やユーザーのログオンにかかる時間に影響します。 情報収集の段階で、このソリューションを実装する前のコンピュータの起動時間とユーザーのログオン時間を記録しておくと便利です。 この段階でこれらの時間を記録しておくと、パイロット期間中にテスト システムと比較する基準となり、ユーザーのログオンにかかる全体的な時間への影響を判断できます。 [](#mainsection)[ページのトップへ](#mainsection) ### 展開前の注意事項 ここまでは、分離作業を成功させるために、ネットワーク、Active Directory、ホストから収集する必要がある情報について説明しました。 ここでは、IPsec の展開前に慎重に検証する必要がある領域を挙げます。 #### ネットワーク インフラストラクチャ 情報を収集すると、ネットワークでの IPsec による分離を計画できます。 情報の収集後、このデータを慎重に分析すると、パイロット期間中および展開時に起こる問題の大半が明らかになります。 次に挙げる事項が問題のすべてではありませんが、テストおよび展開の前に、収集した情報の分析を始める際にこれらを考慮することが重要です。 ##### 過剰使用のデバイス 現在の使用率が 75% を超えているスイッチやルーターは、トラフィックの増加に耐えられるように、またトラフィックのバーストに備えてさらに使用率に余裕を持たせるために、アップグレードや再構成が必要になる場合があります。 IPsec の実装における適切な容量の計画は、正確な計算よりも、テストと予想されるトラフィック負荷に関連しています。 任意の 2 つの顧客で、シナリオ、トラフィック パターン、ユーザーの集中率、アプリケーションがまったく同じということはほとんどあり得ないので、ネットワーク デバイスがどのような影響を受けるかについて適切に計画し、考慮することが不可欠です。 たとえば、IPsec には完全に予測可能な面もあります。 IPsec を ESP と共に使用する各パケットは、IPsec を使用しない同一パケットよりも正確に 36 バイト大きくなります。 単一のメイン モード SA を確立するために必要なメッセージは 6 つあるため、特定のデバイスでの使用率への影響を考慮するのは簡単です。 Quallaby (英語) の PROVISO アプリケーションのようなツール、またはその他のネットワーク アナライザ ソリューションを使用して、IT 環境での IPsec の容量を計画できます。 ##### 互換性のないデバイス IPsec と互換性のないデバイスは、IPsec 通信に使用できません。 このような互換性のないデバイスが管理されたデバイスと通信する必要がある場合は、互換性のないデバイスを IPsec の適用除外リストに入れる必要があります。 代替方法の 1 つは、デバイスのハードウェアまたはソフトウェアを IPsec 対応にアップグレードする方法です。 もう 1 つの方法は、送信された通信がクリアテキストにフォールバックされる場合、このような管理されていないデバイスで境界に配置されたコンピュータとの通信を許可することです。 ##### 正しく構成されていないデバイス デバイスが正しく構成されていないと、通信の失敗やデバイスの負荷の増大の原因となり、デバイスが危害を受ける可能性もあります。 デバイスの構成、管理、およびセキュリティのベスト プラクティスに従うと、この問題を軽減できます。 ##### IP アドレスの割り当て IP アドレスは IPsec ソリューションの基本的な構成ブロックなので、アドレスの割り当てができる限り "クリーン" であることが重要です。 アドレス空間が重なっている、アドレスが重複している、サブネット マスクが正しくないなどの問題が原因で、正常なネットワークの運用が困難になる可能性があります。 このような状態のネットワークに IPsec を導入すると、トラブルシューティングが困難になり、問題の原因が IPsec ではないかと疑われることになります。 組織の成長、合併および買収、その他の要因により、ネットワークの IP アドレスの割り当てを示す構成図はすぐに情報が古くなり、正確ではなくなります。 IPsec の最大の問題を解決するため、ネットワークをサブネットに分割するときに範囲が重ならないこと、ルート テーブルが適切に要約されていること、およびアドレス集約を簡単に判別できることを確認してください。 #### Active Directory の情報 現在の Active Directory の実装が正しく機能している場合 (つまり、名前解決、動的ホスト構成プロトコル (DHCP)、グループ ポリシーのアプリケーション、信頼関係など)、IPsec に影響するものは何もありません。 Active Directory を検証した時点と、分離プロジェクトを開始した時点との間に行われた変更を詳しく調べ、互換性の問題が起こらないようにしてください。 #### ホストの情報 前のセクションでは、ネットワーク ホストに関する十分な情報を収集する方法について説明しました。 IPsec に対応できるクライアントとサーバーを特定したら、それらをどのように分離する必要があるか、および分離ソリューションが与える影響を綿密に検証する必要があるアプリケーションは何かに注意します。 ##### 組み込むクライアント/サーバーを決定する ホストに関する情報を収集したら、分離ソリューションに組み込むのに適したホストを決定するのは比較的簡単です。 たとえば、IPsec で通信できるのは、Windows 2000 ベース、Windows Server 2003ベース、および Windows XP ベースのコンピュータのみです。 ただし、組み込みが可能なクライアントをすべて組み込む必要はありません。 この設計プロセスの重要な部分は、このソリューションに組み込むコンピュータとデバイス、およびそれらが入るグループを決定することです。 ##### 分離する必要があるサービスを決定する サーバーおよびドメインの分離プロジェクトのコンテキストでは、サービスとは Microsoft Exchange Server、Microsoft SQL Server™、または Internet Information Services (IIS) のような、ネットワーク上のクライアントにサービスを提供するアプリケーションを指します。 これらのサービスを個別に評価して、サーバーおよびドメインの分離に組み込むかどうかを判断する必要があります。 これらのサービスをこのソリューションに組み込む必要性についてはいくつかの理由がありますが、たとえば組織のポリシー、政府の規制、その他のビジネス要件などが挙げられます。 たとえば、メール サーバー間の通信はすべて IPsec で保護しなければならないが、クライアントとサーバー間の通信は IPsec で保護する必要はないと組織のポリシーで規定されている場合があります。 「第 4 章 : 分離グループを設計および計画する」では、分離プロセスについて詳しく説明します。 サービスを分離するときは、複数のサービスを行うサーバーについて慎重に検討してください。たとえば、Web サービスと File Transfer Protocol (FTP) を行うファイル サーバーがメール サーバーでもあるような場合です。 ##### ネットワークの負荷分散とクラスタリング サーバーおよびドメインの分離を実施する組織では、ネットワーク負荷分散 (NLB) とクラスタリングを使用するコンピュータを対象外にすることができます。 IPsec は、"アフィニティなし" モードの NLB との互換性がありません。IPsec では、異なるコンピュータが同じクライアント接続を使用することができないからです。 この互換性の問題のため、"アフィニティなし" モードの NLB と IPsec を一緒に使用しないでください。 ##### 例外を管理する 例外の管理は、IPsec の計画の重要な部分です。 信頼されていないホストからのアクセスを許可するコンピュータを使用する場所を決定したり、管理されたコンピュータと管理されていないコンピュータの間のアクセスを制御することは、分離において非常に重要です。 ベスト プラクティスは、例外の数をできる限り少なく抑えることだと考えられています。 技術的なニーズから、ドメイン コントローラや DHCP、DNS、WINS の各サーバーなどの一部のコンピュータまたはサービスを IPsec の対象外にしなければならない場合があります。 これらのコンピュータは管理する必要があるため、管理されていないコンピュータが、管理され信頼されたコンピュータと通信するのを許可するよりも危険性が低くなります。 ##### Windows ベース以外のデバイス ほとんどの企業ネットワークは、同機種環境ではありません。 IPsec の展開を計画するときは、オペレーティング システム、ネットワーク インフラストラクチャ、ハードウェア プラットフォームなどさまざまな要素を考慮する必要があります。 組織で Windows ベース以外のコンピュータを使用している場合は、Windows の領域外での IPsec ポリシーの使用は現在不可能であることに注意してください。 この制限に対処するには、一部のプラットフォームを信頼されたものとして扱う方法がありますが、これらのプラットフォームでは IPsec ポリシーを使用できないため、サーバーおよびドメインの分離ソリューションではこれらのプラットフォームが保護されません。 次のセクションでは、信頼を決定する方法について説明します。 ##### デバイスの管理および監視 IPsec の初期の計画段階で見落とされがちな点は、ネットワーク トラフィックの管理と監視に IPsec が与える影響です。 IPsec では認証が必要であり、暗号化が可能なので、デバイスによっては IPsec 対応のコンピュータの監視や管理ができなくなります。 暗号化が必要な状況では、ネットワークを介してデータを転送するとき、そのデータを監視する運用上の必要性よりもセキュリティの方が重要だということが言われます。 別の状況では、ESP トラフィックを解析する ESP パーサーなど、IPsec の監視を有効にするために可能なアプリケーションまたはデバイスの変更を評価する必要があります。 IPsec をサポートするために監視デバイスや管理デバイスをアップグレードすることが不可能な場合は、そのことを必ず記録するようにします。 この情報は、ソリューションの設計者やアーキテクチャ チームが「第 4 章 : 分離グループを設計および計画する」で使用する必要があります。 [](#mainsection)[ページのトップへ](#mainsection) ### 信頼の決定 現在、組織の IT インフラストラクチャを構成するホスト デバイスに関する情報を取得したら、このソリューションに組み込むホストの機能に直接影響する基本的な決定を行う必要があります。 この決定とは、ホストをどの時点で信頼された状態とみなすことができるかというものです。 "*信頼された*" という語は人によって受け取り方がさまざまなので、プロジェクトのすべての関係者に、この語の定義をしっかりと伝達することが重要です。 これを怠ると、信頼された環境にセキュリティ問題が発生する原因になります。全体的なセキュリティは、信頼された状態として認定された最も安全でないクライアントによって設定されるセキュリティ レベルを超えることができないからです。 この概念を理解するために、一般的な IT インフラストラクチャのホストに当てはめることができる 4 つの基本的な状態を考えます。 4 つの状態をリスクの低い順に並べると次のようになります。 1. 信頼された状態 2. 信頼できる状態 3. 既知の信頼されていない状態 4. 不明で信頼されていない状態 このセクションの残りの部分では、これらの状態の意味と、組織のホストがどの状態であるかを判断する方法について説明します。 #### 信頼された状態 信頼されたホストとして分類することは、そのホストが完全に保護されている、または脆弱ではないということではありません。 信頼された状態とは、基本的にそのホストのセキュリティ リスクが管理されているということです。 この管理された状態の責任は、IT 管理者と、そのホストの構成を担当するユーザーにあります。 信頼されたホストが適切に管理されていないと、ソリューション全体にとって脆弱なポイントになります。 あるホストが信頼されたホストとみなされている場合、他の信頼されたホストでは、そのホストからは悪意のある操作が行われないことを前提にできることになります。 たとえば、信頼されたホストは、他の信頼されたホストからウイルスで攻撃されることはないことを前提にします。信頼されたホストはすべて、ウイルスの脅威に対処するためのメカニズム (ウイルス対策ソフトウェアなど) を使用する必要があるからです。 信頼されたホスト間の接続が、ネットワーク インフラストラクチャによって妨害されないようにする必要があります。 たとえば信頼されたホストでは、他の信頼されたホストに悪意がないことが前提となるため、他の信頼されたホストによるアクセスを制限するための IP レベル のパケットのブロックは一般的には必要ありません。 ポートまたはプロトコルによるホスト通信の制御に必要な制限は、IPsec を使用するのではなく、コンピュータ自体にホストベースのファイアウォールを設定することによって実装する必要があります。 Woodgrove Bank のシナリオでは、セキュリティ チームは次の 5 つの主要目標を定め、ホストを信頼された状態にするために必要なテクノロジについて計画を立てました。 - コンピュータの ID またはユーザーの ID が侵害されていないこと - 必要なリソースが、管理された環境のどこに格納されているかにかかわらず、安全で利用可能であること - *安全な*リソースとは、改ざん、ウイルス感染、未承認のアクセスなどがないリソースです。 - *利用可能な*リソースとは、稼働時間が想定のレベルを満たすかそれ以上であり、セキュリティの脆弱性がないリソースです。 - *管理された*環境とは、Windows 2000 SP4 以降を実行し、正しく構成され、更新プログラムがインストールされたコンピュータを備えた環境です。 - データおよび通信がプライベートであること、つまり、情報の読み取りや使用ができるのは、意図された受信者のみであること - デバイスの所有者/運用者が、環境の信頼性を維持するためのポリシーと手順を理解し、それに従うこと - リスクや脅威にタイムリーに対処すること Woodgrove Bank のサポート チームは、これらの目標から、ホストを信頼された状態とみなせるかどうかを判断するための一連の技術的要件を設定しました。 信頼された状態を定義するときは、資産の所有者が特定の資産のビジネス ニーズに合致するセキュリティ要件を自由に追加できるようにしてください。 たとえば人事部門では、特定のサーバーに生体認証によるログオン メカニズムを追加する必要がある場合があります。 この要件は、このソリューションのコンテキストにおいて信頼されるサーバーの機能には何の影響もありません。 ただし、特定の資産の要件が、信頼された状態の要件と矛盾しないように注意してください。 時間をかけて目標を定め、信頼されたホストに必要と組織が判断する最低限の構成を定めた技術的要件を定義してください。 たとえば Woodgrove Bank のシナリオでは、設計チームは次のような技術的要件のリストを使用しました。 - **オペレーティング システム :** 信頼されたホストでは Windows XP SP2 または Windows Server 2003、もしくは最低限、Windows 2000 SP4 を実行している必要があります。 - **ドメイン メンバシップ :** 信頼されたホストは管理されたドメインに属することになります。つまり、IT 部門にはセキュリティ管理権限が必要です。 - **管理クライアント :** すべての信頼されたホストで特定のネットワーク管理クライアントを実行し、セキュリティ ポリシー、構成、およびソフトウェアの集中管理と制御を可能にする必要があります。 - **ウイルス対策ソフトウェア :** すべての信頼されたクライアントでウイルス対策ソフトウェアを実行し、最新のウイルス定義ファイルを毎日チェックして自動更新されるように設定します。 - **ファイル システム :** すべての信頼されたホストを NTFS ファイル システムで構成します。 - **BIOS 設定 :** すべての信頼されたモバイル コンピュータを、IT サポート チームが管理する BIOS レベルのパスワードを使用して構成します。 - **パスワードの要件 :** 信頼されたクライアントでは強固なパスワードを使用する必要があります。   信頼された状態は常に一定ではないことに注意してください。信頼された状態は、セキュリティ標準の変更やそれらの標準への準拠に応じて変化します。 新しい脅威やそれに対処する新しい防御策が常に登場します。 このため、信頼されたホストを組織の管理システムによって常にチェックし、準拠を維持することが欠かせません。 さらにこのような管理システムには、信頼された状態の維持に必要な場合、更新や構成変更を発行する機能がなければなりません。 これらすべてのセキュリティ要件を常に満たしているホストは、信頼されたホストとみなすことができます。 しかし、この章で前述した検出プロセスで特定されたほとんどのホスト コンピュータが、現在はセキュリティ要件を満たしていないということもよくあります。 したがって、信頼されたホストにできるホストとできないホスト (つまり信頼されていないホストと考えなくてはならないホスト) を見分けることが重要です。 このプロセスにおいて、中間的な信頼できる状態を定義すると便利です。 このセクションの残りの部分では、その他の状態とその意味について説明します。 #### 信頼できる状態 現在のインフラストラクチャで、信頼された状態にすることができるホストを必要に応じてできるだけ早く特定すると便利です。 信頼できる状態とは、ソフトウェアと構成に必要な変更を行えば、現在のホストを物理的に信頼された状態にできることを示すために割り当てられます。 信頼できる状態を割り当てられた各コンピュータについて、そのホストを信頼された状態にするのに何が必要かを記載した構成メモを作成します。 この情報は特に、プロジェクト設計チームがホストをソリューションに追加するコストを見積もったり、サポート スタッフが必要な構成を適用する際に重要です。 一般的に、信頼できるホストは次の 2 つのグループのいずれかに分類されます。 - **構成が必要 :** ホストの現在のハードウェア、オペレーティング システム、ソフトウェアは、信頼できる状態となる条件を満たしています。 ただし、前提となるセキュリティ レベルを達成するには、構成変更が必要です。 たとえば、ホストを信頼された状態とみなすためには安全なファイル システムが必要と組織で規定されている場合、ハード ディスクが FAT32 でフォーマットされたホストはこの要件を満たしません。 - **アップグレードが必要 :** このグループのコンピュータを信頼された状態とみなすには、システムのアップグレードが必要です。 次に、このグループのコンピュータに必要となる場合があるアップグレードの種類の例を示します。 - オペレーティング システムのアップグレードが必要。 ホストの現在のオペレーティング システムが組織のセキュリティ ニーズを満たしていない場合、ホストを信頼された状態にするにはアップグレードが必要です。 - ソフトウェアが必要。 ウイルス対策スキャナや管理クライアントなどの必要なセキュリティ アプリケーションがインストールされていないホストは、これらのアプリケーションをインストールしてアクティブにするまでは信頼された状態とみなすことはできません。 - ハードウェアのアップグレードが必要。 場合によっては、ホストを信頼された状態にするために特定のハードウェアのアップグレードが必要になることがあります。 このようなホストでは、オペレーティング システムのアップグレードまたはソフトウェアの追加が必要となった結果、ハードウェアのアップグレードも必要となる場合がほとんどです。 たとえば、セキュリティ ソフトウェアをインストールするのに追加の記憶域が必要になり、その結果ハード ディスク容量を増やす必要がある場合などがあります。 - コンピュータの交換が必要。 この分類には、許容できる最小の構成要件をハードウェアが満たしていないために、このソリューションのセキュリティ要件に対応できないホストが入ります。 たとえば、プロセッサが古いために安全なオペレーティング システムを実行できないコンピュータ (100 MHz x86 ベースのコンピュータなど) がこれに当てはまります。 これらのグループを使用して、アップグレードが必要なコンピュータにソリューションを実装するためのコストを割り当ててください。 #### 既知の信頼されていない状態 組織のホストを分類する過程で、特定のよくある明確な理由から、一部のホストを信頼された状態にできないことが判明します。 この理由には次のようなものがあります。 - **財政的な理由 :** 財政的に、ホストのハードウェアまたはソフトウェアのアップグレードが不可能な場合。 - **政治的な理由 :** 政治的またはビジネス上の状況から、組織で既定された最小のセキュリティ要件に準拠できず、ホストを信頼されていない状態のままにしておかなければならない場合があります。 事業主やそのホストの独立ソフトウェア ベンダ (ISV) と、サーバーおよびドメインの分離の付加価値について話し合うことを強くお勧めします。 - **機能的な理由 :** ホストは、安全でないオペレーティング システムを実行したり、安全でない方法で動作してその役割を果たす必要があります。 たとえば、以前のオペレーティング システムでのみ動作する特定の業務アプリケーションを実行するには、ホストで以前のオペレーティング システムを実行する必要があります。 ホストが既知の信頼されていない状態のままになる機能的な理由はさまざまです。 次に、この状態に分類される可能性のある機能的な理由の例をいくつか挙げます。 - **Windows 9*x*** **または Windows Millennium Edition を実行しているコンピュータ :** これらのバージョンの Windows オペレーティング システムを実行しているコンピュータは、信頼できる状態に分類することはできません。これらのオペレーティング システムでは基本的なセキュリティ インフラストラクチャがサポートされないからです。 実際、これらのオペレーティング システムには設計上セキュリティ インフラストラクチャが存在しません。 さらに、これらのオペレーティング システムにあるのは、システム ポリシーとユーザー ログオン スクリプトを介してユーザー固有のコンピュータ構成を管理する基本的な集中管理機能だけです。 最後にこれらのオペレーティング システムには、必要なセキュリティ管理機能がまったく搭載されていません。 - **Windows NT を実行しているコンピュータ :** サーバーおよびドメインの分離のコンテキストでは、Windows NT を実行しているコンピュータを信頼できる状態に分類できません。このオペレーティング システムでは基本的なセキュリティ インフラストラクチャが十分にはサポートされないからです。 たとえば Windows NT では、ローカル リソースでの "拒否" の ACL がサポートされず、ネットワーク通信の機密性と整合性、強固な認証のためのスマート カード、またはコンピュータ構成の集中管理を保証する手段がありません (ただし、ユーザー構成に関する限定的な集中管理はサポートされます)。 また、データの機密性を保護し、整合性を保証する機能 (たとえば Windows 2000 暗号化ファイル システムなど) もありません。 さらに、Windows NT では必要なセキュリティ機能がすべてサポートされているわけではありません。 たとえば、グループ ポリシーまたは IPsec ポリシーはサポートされておらず、ローカルの管理者レベルのアクセス権を必要に応じて取得できるようにするメカニズムもありません。 また、セキュリティ構成が定期的に再適用されるのではないため、セキュリティ構成が常に有効であるとは限りません。 **注 :** Windows NT が信頼できない状態であるという説明は、あくまでもサーバーおよびドメインの分離の実装との関連においてであり、オペレーティング システムとして通常使用する場合には当てはまりません。 このプロジェクトで使用するサーバーについては、Windows Server 2003 プラットフォームにアップグレードすると、最も安全で管理しやすいソリューションが実現します。 - **スタンドアロン コンピュータ :** 実行している Windows のバージョンにかかわらず、スタンドアロンとして、またはワークグループのメンバとして構成されているコンピュータは、通常は信頼できる状態にすることはできません。 これらのオペレーティング システムで、必要最低限の基本セキュリティ インフラストラクチャが完全にサポートされていても、そのコンピュータが信頼されたドメインの一部でない場合、必要なセキュリティ管理機能を実現するのは困難です。 - **信頼されていないドメインのコンピュータ :** 組織の IT 部門によって信頼されていないドメインのメンバであるコンピュータは、信頼された状態に分類できません。 信頼されていないドメインとは、必要なセキュリティ機能をメンバに提供できないドメインです。 このような信頼されていないドメインのメンバであるコンピュータのオペレーティング システムで、必要最低限の基本セキュリティ インフラストラクチャが完全にサポートされていても、そのコンピュータが信頼されたドメインに属していない場合は、必要なセキュリティ管理機能が十分には保証されません。 たとえば信頼されていないドメインには、信頼されたユーザーが必要に応じてローカルの管理者レベルのアクセス権を取得できるようにするメカニズムがありません。 また、セキュリティ構成が (集中管理が可能な場合でも)、信頼されていないドメインの管理者によって簡単に上書きされます。 さらに、セキュリティ構成、ソフトウェア、ポリシー、および規格への準拠を保証できず、準拠を効率的に監視する機能もありません。 - **Windows NT ドメインのコンピュータ :** Windows NT に基づくドメインのメンバであるコンピュータは、信頼された状態に分類できません。 このようなコンピュータのオペレーティング システムで、必要最低限の基本セキュリティ インフラストラクチャが完全にサポートされていても、そのコンピュータが Windows NT ドメインに属している場合は、必要なセキュリティ管理機能が十分にはサポートされません。 ただし、このようなホストが組織にとって必要な役割を果たすために設計に組み込む必要がある場合は、このホストに既知の信頼されていない状態を割り当てます。 この状態は、リスクが特定されているがこのソリューションでは対処できないという意味です。 このような既知の脅威に対処するには、別の手法を使用する必要があります。 この分類に入るホストにはさまざまな特質があるため、このような手法について具体的なガイダンスを示すことはできません。 しかし、これらの手法の目的は、この分類のホストによってもたらされるリスクを最小限にすることです。   #### 不明で信頼されていない状態 すべてのホストの既定の状態は、不明で信頼されていない状態とみなす必要があります。 この状態のホストの構成は不明であるため、これらのホストには信頼の状態を割り当てられません。 この状態のホストに関する計画はすべて、ホストが危害を受けたか危害を受ける可能性があり、したがって組織にとって許容できないリスクであることを前提とする必要があります。 このソリューションの設計者は、この状態のコンピュータが組織に与える可能性がある影響が最小限になるように努力してください。 [](#mainsection)[ページのトップへ](#mainsection) ### 現在のホストのアップグレード コストを計算する この章の最後の手順は、コンピュータをソリューションに組み込むことができるレベルにアップグレードするためにかかる概算コストを記録するプロセスです。 プロジェクトの設計段階ではいくつかの主要な決定を行う必要があります。その際、次の質問に回答する必要があります。 - コンピュータは分離ソリューションに必要な最小のハードウェア要件を満たしているか。 - コンピュータは分離ソリューションに必要な最小のソフトウェア要件を満たしているか。 - コンピュータを分離ソリューションに組み込むにはどのような構成変更が必要か。 - コンピュータを信頼された状態にするための変更案を実行する場合の見積りコストまたは影響はどのようなものか。 これらの質問に回答することによって、特定のホストまたはホストのグループをこのプロジェクトの対象とするのに必要な作業のレベルや概算コストを迅速に把握できます。 このようなデータをすべて 1 人または同じ役割の数人で収集することはあまりありません。 ヘルプ デスクやフィールド サービス技術者が収集するデータもあれば、設計者やビジネス スポンサー レベルから収集する必要があるデータもあります。 コンピュータの状態は常に変化すること、またリストにした改善措置を実行することによって、コンピュータを信頼されていない状態から信頼された状態に変更できることを常に認識してください。 コンピュータを信頼された状態にするかどうかを決定したら、このガイドの「第 4 章 : 分離グループを設計および計画する」で説明する分離グループの計画と設計の段階に進みます。 次の表は、ホストの現在の状態把握し、そのホストを信頼された状態にするには何が必要かを判断する際に使用できるデータ シートの例です。 **表 3.3: ホストの収集データの例**

ホスト名 ハードウェア要件の達成 ソフトウェア要件の達成 必要な 構成 詳細 見積もりコスト
HOST-NYC-001 いいえ いいえ ハードウェアとソフトウェアのアップグレード 現在のオペレーティング システムは Windows NT 4.0。 古いハードウェアは Windows XP SP2 と互換性がない。 $XXX
SERVER-LON-001 はい いいえ 信頼されたドメインへの参加、および Windows NT 4.0 から Windows 2000 SP4 以降へのアップグレード ウイルス対策ソフトウェアがインストールされていない。 $XXX
表 3.3 の各列の説明は次のとおりです。 **ホスト名 :** ネットワーク上のホスト デバイスの名前。 - **ハードウェア要件の達成 :** このソリューションに組み込むための最小のハードウェア要件をコンピュータが満たしているかどうかを表します。 - **ソフトウェア要件の達成 :** このソリューションに組み込むための最小のソフトウェア要件をコンピュータが満たしているかどうかを表します。 Woodgrove Bank の場合、最小要件は Windows 2000 SP4、Windows XP SP2、または Windows Server 2003 で、各オペレーティング システムとも重要なセキュリティ更新プログラムがすべてインストールされている必要があります。 さらに、各コンピュータが信頼されたドメイン (Woodgrove Bank の IT スタッフによって集中管理されているドメイン) に属し、ドメインのコンピュータへのアクセス権が IT 管理者に特別に与えられている必要があります。 - **必要な構成 :** コンピュータを信頼された状態にするために必要な措置を示します。 - **詳細 :** コンピュータが現在信頼された状態ではない理由を示します。 - **見積もりコスト :** デバイスを信頼された状態にするために必要な見積もりコストを示します。 このコストには、ソフトウェア、ハードウェア、生産性の低下、サポートなどのコストの見積もりが含まれます。 この情報は、特定のコンピュータを信頼されたコンピュータとしてソリューションに組み込むことがビジネスの観点から見て現実的かや価値があるかを判断する場合に役立ちます。 この表のホスト HOST-NYC-001 は、現在 "既知の信頼されていない" 状態ですが、必要なアップグレードを行うことが可能であれば信頼できる状態にすることができます。 ただし、多くのコンピュータで同じアップグレードが必要となる場合は、ソリューションの全体的なコストはかなり高くなります。 ホスト SERVER-LON-001 はハードウェア要件は満たしていますが、IPsec ポリシーの使用が可能で、ドメインに参加できるオペレーティング システムへのアップグレードが必要です。 また、ウイルス対策ソフトウェアも必要です。 見積もりコストは、オペレーティング システムのアップグレード作業とウイルス対策ソフトウェアのインストール作業、それにオペレーティング システムとウイルス対策ソフトウェアそれぞれのライセンス コストを加えたものになります。 表 3.3 に示した情報を取得したら、この章で収集した他の情報と一緒に保存し、設計者またはアーキテクチャ チームがこの情報を利用できるようにします。 この情報は、分離グループの設計について説明する第 4 章で行う作業の基礎となります。 ここで特定したコストは、ホストのアップグレードにかかる見積もりコストのみであることに注意してください。 他にも、設計、サポート、テスト、トレーニングなど、プロジェクトに関連するコストは多数あります。 プロジェクトの正確なコストを特定する場合は、プロジェクト全体の計画でこれらの追加コストを考慮する必要があります。 [](#mainsection)[ページのトップへ](#mainsection) ### 要約 この章では、サーバーおよびドメインの分離プロジェクトの実行に必要な情報の概要を、影響に関する考慮事項も含めて説明しました。 この章の説明に従って、次のタスクを実行できます。 - ネットワーク上の資産を特定する - ネットワークの情報を収集する - ホストの情報を収集める - 現在のトラフィックの情報を把握する - Active Directory アーキテクチャを検証し、関連情報を取得する - IPsec の容量に関する考慮事項を検証する - IPsec の展開前の考慮事項を確認する - 信頼できるデバイスと信頼できないデバイスとは何か、また Woodgrove Bank のシナリオではこれらがどのように分類されたかを説明する これらのタスクを完了すると、次の章で分離グループの設計を開始するために必要な情報をすべて収集することができます。 #### 関連情報 ここでは、このソリューションの実装に役立つ可能性のある関連情報へのリンクを紹介します。 - Windows Server 2003 で IPsec をサポートするためのファイアウォールの構成については、Windows Server 2003 のマニュアルの「[Configuring Firewalls](https://technet2.microsoft.com/windowsserver/en/library/6e268195-6750-494a-8f19-25d07911926f1033.mspx)」ページ https://technet2.microsoft.com/windowsserver/en/library/6e268195-6750-494a-8f19-25d07911926f1033.mspx (英語) を参照してください。 - [Windows Management Instrumentation (WMI) CORE 1.5 (Windows 95/98/NT 4.0)](https://www.microsoft.com/download/details.aspx?displaylang=ja&familyid=afe41f46-e213-4cbf-9c5b-fbf236e0e875) のインストール パッケージは、Microsoft ダウンロード センター https://www.microsoft.com/download/details.aspx?displaylang=ja& FamilyID=afe41f46-e213-4cbf-9c5b-fbf236e0e875 からダウンロードできます。 - WMI の詳細については、MSDN® の「[Windows Management Instrumentation](https://msdn.microsoft.com/ja-jp/library/aa394582.aspx)」https://msdn.microsoft.com/library/en-us/wmisdk/ wmi/wmi\_start\_page.asp (英語) を参照してください。 - 「[Windows 2000 および Windows XP 用の Windows Script 5.6](https://www.microsoft.com/download/details.aspx?displaylang=ja&familyid=c717d943-7e4b-4622-86eb-95a22b832caa)」は、Microsoft ダウンロード センター https://www.microsoft.com/download/details.aspx?displaylang=ja& FamilyID=c717d943-7e4b-4622-86eb-95a22b832caa からダウンロードできます。 - 「[Windows 98、Windows Millennium Edition (Windows Me)、および Windows NT 4.0 用の Windows Script 5.6](https://www.microsoft.com/download/details.aspx?familyid=e74494d3-c4e1-4e18-9c6c-0ea28c9a5d9d&displaylang=ja)」は、Microsoft ダウンロード センター https://www.microsoft.com/download/details.aspx?familyid=e74494d3-c4e1-4e18-9c6c-0ea28c9a5d9d&displaylang=ja からダウンロードできます。 - 「[Windows Script 5.6 Documentation](https://www.microsoft.com/download/details.aspx?familyid=01592c48-207d-4be1-8a76-1c4099d7bbb9&displaylang=en)」は、Microsoft ダウンロード センター https://www.microsoft.com/download/details.aspx? FamilyId=01592C48-207D-4BE1-8A76-1C4099D7BBB9&displaylang=en (英語) からダウンロードできます。 [](#mainsection)[ページのトップへ](#mainsection)