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

  • [アーティクル]

第 1 章 : サーバーおよびドメインの分離の紹介

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

コンピュータとネットワークを物理的に分離することにより、データや通信を損害から保護する方法は、何年も前から行われてきました。 物理的分離の問題点は、多くの企業組織では、ハードウェア的 (物理的) な境界の背後で情報技術 (IT) インフラストラクチャを保護するのが容易ではないことです。 モバイル クライアントの普及や分散ネットワーク環境の特性を考慮すると、このような物理的制限は柔軟性に欠けるため、実装および運用ができません。

サーバーおよびドメインを分離すると、セキュリティ層を作成して、コンピュータ間またはネットワーク間のネットワーク トラフィックを論理的に分離することができます。 攻撃者が企業の内部ネットワークへの物理的なアクセスに成功し、貴重なデータ資産が格納されたサーバーにアクセスしようとして有効なユーザー アカウントとパスワードを使用しても、サーバーおよびドメインが分離されていれば阻止できます。単純に、攻撃者が使用するコンピュータは企業の信頼されたデバイスではないからです。

サーバーおよびドメインの分離による論理的分離アプローチは、柔軟性、拡張性、管理性を備えた分離ソリューションの開発を可能にします。このソリューションでは、分離によるセキュリティが実現し、物理的境界を設置する場合のコストや不便さはありません。

トピック

概要
対象読者
ビジネス上の課題
プロジェクト チームを編成する
ガイドの概要
シナリオの概略
要約

概要

マイクロソフトでは、大規模組織が、ネットワーク境界のセキュリティ保護における課題の増大に直面していることを認識してます。 組織の規模が大きくなり、ビジネス関係が変化するにつれ、ネットワークへの物理的なアクセスを制御することは不可能になる可能性があります。 毎日、顧客、ベンダ、コンサルタントといった人々が、正当なビジネス上の理由で、モバイル デバイスを使用して組織のネットワークに接続します。 GPRS (General Packet Radio Service) や Bluetooth など、ワイヤレス ネットワークおよびワイヤレス接続テクノロジの登場により、ネットワーク アクセスは以前よりも容易になりました。 このように接続性が向上すると、境界セキュリティを破られること以外に、内部ネットワークのドメイン メンバが内部ネットワーク上の他のコンピュータからの重大なリスクにさらされる可能性が増大します。 インターネットに接続する場合は個人またはホストベースのファイアウォールがクライアントのセキュリティ保護に役立ちますが、これらはまだ内部サーバーおよび内部クライアントの保護に適しているとは言えません。

サーバーおよびドメインの分離には、ビジネス上多くの利点があります。 最も重要な点は、ネットワーク セキュリティ層が導入されることです。これにより、信頼されていないホストが組織の内部ネットワーク上の信頼されたドメイン メンバにアクセスする脅威を大幅に減少させることができます。 サーバーおよびドメインの分離は、ウイルスの感染拡大、内部ハッカー、社員による技術資産の悪用、情報盗難に対する有効な防御策となる可能性があります。 さらに、この手法では、クライアントかサーバーかにかかわらず、信頼されたリソースへのアクセスを試みるすべてのクライアントのドメイン メンバシップを要求できるため、IT 専門スタッフがクライアントをより高度に管理できます。 サーバーおよびドメインの分離は、ネットワーク トラフィック内のデータのプライバシーまたはその他の保護要件を満たすための主要な戦略、または追加的な戦略としても使用できます。既存の Microsoft® Windows® アプリケーションを変更したり、仮想プライベート ネットワーク (VPN) トンネリング ハードウェアをネットワーク上に展開する必要はありません。

サーバーおよびドメインの分離手法では、IT 管理者が信頼されたコンピュータであるドメイン メンバの TCP/IP 通信を制限できます。 このような信頼されたコンピュータは、他の信頼されたコンピュータ、または信頼されたコンピュータの特定のグループからの着信接続のみを許可するように設定できます。 アクセス制御は、ネットワーク ログオン権利を制御する Active Directory® グループ ポリシーを使用して集中管理されます。 ほとんどの TCP/IP ネットワーク接続は、アプリケーションを変更せずにセキュリティ保護できます。これは、インターネット プロトコル セキュリティ (IPsec) がアプリケーション層の下のネットワーク層で動作し、認証を行ったり、パケットごとの最新のセキュリティをコンピュータ間でエンドツーエンドに実現するからです。 ネットワーク トラフィックは、カスタマイズ可能なさまざまなシナリオで認証したり、認証して暗号化することができます。 グループ ポリシーと IPsec の構成は、Active Directory で集中管理されます。

このガイドで説明する論理的分離の概念には、2 つのソリューションが提示されています。1 つは、信頼されていない接続からドメイン メンバを分離するドメイン分離です。もう 1 つは、信頼されたドメイン メンバまたはドメイン メンバの特定のグループからのネットワーク接続のみをサーバーが受け入れるようにするサーバー分離です。 この 2 つのソリューションは、単独または 1 つの全体的な論理的分離ソリューションの一部として一緒に使用することができます。

このガイドで紹介するテスト済みのソリューションに必要なプラットフォームの最小構成は次のとおりです。

  • Windows 2000 Service Pack 4 以降

  • Microsoft Windows Server™ 2003

  • Windows XP Service Pack 2 以降

この構成要件を満たすと、IPsec コンポーネントが必要なリビジョン レベルになります。 Windows 以外のプラットフォームまたは信頼されていないシステムとの通信は、適用除外リストを持つか、クリア テキスト (非 IPsec) 通信へのフォールバックが許可されている IPsec 構成によって制御されます。 新しいネットワーク アドレス変換 (NAT) トラバーサル機能を備えたローカル エリア ネットワーク (LAN) では、ネットワーク アドレス変換器は IPsec を使用する場合の障害ではなくなっています。

このガイドでは、Woodgrove National Bank のシナリオを使用して、典型的なラボ環境にサーバーとドメイン両方の分離を実装する方法を説明します。 また、この 2 つのソリューションをマイクロソフト社内やお客様の環境で実装した経験についても説明します。 このガイドは、この問題の専門家で構成されるマイクロソフト チームによって開発され、マイクロソフトの IT 専門スタッフと、ベータ プログラムに参加していただいた多数のお客様の両方によってレビューが行われました。

サーバー分離とドメイン分離のいずれのシナリオも、マイクロソフトのグローバルな内部ネットワークに存在しているため、マイクロソフトの業務はこれらのソリューションのセキュリティに依存しています。 さらに、マイクロソフトではこのソリューションをお客様に推奨するにあたり、信頼できるコンピューティングのための高い安全性と管理性を備えたインフラストラクチャを目指した長期的方向性をサポートしています。

ページのトップへ

対象読者

このガイドは、初期評価および承認の段階から、展開、テスト、実装完了後の管理に至るまで、IT ライフサイクルのあらゆる段階でサーバー/ドメイン分離ソリューションをサポートできるように作成されています。 したがって、このガイドの各章は、さまざまな読者のニーズを満たす内容となっています。

この章は、サーバー/ドメイン分離プロジェクトの実施が組織にメリットをもたらすか否かの判断を行うビジネス上の意思決定者を主な対象とした内容になっています。 この章の内容を理解するのに特定の技術的知識は不要であり、組織のビジネスおよびセキュリティのニーズを理解していれば十分です。

このガイドの計画に関する章 (第 2 章から第 4 章) は、組織向けにカスタマイズしたソリューションの設計を担当する技術設計者および IT 専門家が参考に利用できる内容になっています。 これらの章の内容を十分に活用するには、関連する技術と組織の現在のインフラストラクチャの両方を技術的に十分理解している必要があります。

第 5 章と付録は、組織のソリューションの展開計画作成担当者を対象とした内容になっています。 ここでは、ソリューションを正しく展開するための推奨事項を多数紹介しており、またテスト ラボ環境を構築するための実践的な実装手順についても説明しています。

このガイドの第 6 章は、ソリューションの実装が完了して完全に機能するようになった後の、日常の運用管理の担当者を対象とした内容で、リファレンスとして利用できるようになっています。 この章で説明するさまざまな運用プロセスと手順を、組織の運用フレームワークに組み込むことをお勧めします。

第 7 章には、IPsec の展開に関するトラブルシューティング情報が記載されています。 IPsec は基本的にネットワーク通信に影響するため、トラブルシューティングの情報と方法は、IPsec を実装する組織にとって非常に役立つ場合があります。

ページのトップへ

ビジネス上の課題

今日の高度に接続された組織やモバイル ネットワーク デバイスの特性は、組織の IT インフラストラクチャに多くのリスクをもたらす恐れがあります。 このようなリスクの発生元はさまざまですが、モバイル環境の社員、ベンダ、および顧客のコンピュータ、さらに小規模な支社や社員の自宅にあるリモート コンピュータなどが挙げられます。 多くの場合、こういったリスクはウイルスやワームなど悪意のあるソフトウェア (マルウェアとも言います) が発生元です。これらは、悪意のないユーザーのコンピュータに気付かないうちにダウンロードまたはインストールされています。

論理的分離は単独では対ウイルス防御と見なされませんが、より広範なウイルス対策ソリューションの一部になることができます。論理的分離では、セキュリティ層が追加されるため、攻撃の可能性を低下させることができ、攻撃を受けてもその範囲を最小限にできるからです。 たとえば顧客の訪問があり、その顧客がスプレッドシートを渡すために自分のモバイル コンピュータを組織のネットワークに接続すると、それによって組織の IT インフラストラクチャにリスクがもたらされます。 組織の物理ネットワークに直接接続することにより、この顧客は、ネットワークベースの攻撃に対して配置されている境界防御をバイパスしてしまっているからです。

しかし、顧客が接続した内部ネットワークで、組織のサーバーへの直接アクセスが許可されなかったら、このリスクは軽減されます。 問題は、このような組織のリソースへのアクセスをどのようにして、それを必要とするコンピュータだけに制限するかです。 その答えがサーバーおよびドメインの分離であり、この手法では、コンピュータそのものを特定して認証し、そのコンピュータがアクセスを許可されているのはどのリソースかを判断します。 この認証はユーザーがログオンする前に行われ、コンピュータが接続されている間は有効です。 このアプローチでは、重要なビジネス データが、組織のネットワークに接続する身元不明で管理されていないコンピュータからアクセスされる潜在的なリスクを低下させることができます。

注 : マルウェアについての詳細と、組織が自衛する具体的な方法については、Microsoft TechNet Web サイトの「対ウイルス多層防御ガイド」を参照してください。

ビジネス上の利点

論理的分離の防御層を導入する利点として、次のようなことが挙げられます。

  • セキュリティの強化。 論理的分離の防御層によって、ネットワーク上のすべての管理対象コンピュータのセキュリティを強化できます。

  • 特定の情報にアクセスできるユーザーの管理の強化。 このソリューションを使用すると、コンピュータはネットワークに接続しても、それだけではすべてのネットワーク リソースに自動的にはアクセスできなくなります。

  • コストの削減。 このソリューションは通常、物理的分離ソリューションよりもかなり低いコストで実装できます。

  • 管理対象のコンピュータ数の増加。 管理対象コンピュータでしか組織の情報を使用できない場合、ユーザーがアクセスできるようにするには、すべてのデバイスを管理対象システムにする必要があります。

  • マルウェア攻撃に対する保護レベルの向上。 分離ソリューションによって、信頼されていないコンピュータが信頼されたリソースにアクセスする能力が大幅に制限されます。 したがって、攻撃者が有効なユーザー名とパスワードを入手した場合でも、信頼されていないコンピュータから行ったマルウェア攻撃は接続が許可されないため失敗します。

  • ネットワーク データを暗号化するメカニズム。 論理的分離により、選択したコンピュータ間のすべてのネットワーク トラフィックの暗号化を要求できます。

  • 迅速な緊急時分離。 このソリューションでは、攻撃が行われた場合、ネットワーク内部の特定のリソースを迅速かつ効果的に分離する仕組みが用意されています。

  • 一般に公開されているネットワーク接続の保護。 ロビーにあるような特定のネットワーク接続ポイントからは、ネットワークのすべてのリソースには直接アクセスできません。

  • 監査能力の向上。 このソリューションでは、管理対象リソースが行うネットワーク アクセスをログに記録して、監査することができます。

技術的課題

今日の IT インフラストラクチャを攻撃者から防御する一方で、社員が最も迅速かつ生産的な方法で作業できるようにすることは容易ではありません。 環境のセキュリティ保護に役立ちそうなさまざまなテクノロジ群を単に理解するだけでも、多くの人にとっては困難です。 このソリューションが一般的な IT インフラストラクチャのどこに組み込まれるかや、既存のネットワーク防御を補うためにどのように設計されているかを正確に知ることが役立つ場合があります。

次の図は、いくつかのネットワーク防御層で構成される一般的なネットワーク インフラストラクチャを表し、一般的な環境のどこに論理的分離を組み込むかを示しています。

図 1.1: インフラストラクチャの各領域とネットワーク防御層

拡大表示する

図 1.1 は、一般的なネットワーク インフラストラクチャに多層防御セキュリティ設計を導入するために使用できるさまざまなテクノロジを簡単に示したものです。 このようなインフラストラクチャは、通常次のような要素で構成されます。

  • リモート ワーカーとリモート ネットワーク : これらのリモート エンティティは通常、VPN を使用して、組織の内部ネットワークに接続し、組織の IT インフラストラクチャにアクセスします。

  • インターネット : 組織の内部ネットワークは、多くの場合、1 つまたは複数の境界ファイアウォール デバイスを介してインターネットに接続されます。 この境界ファイアウォール デバイスは多くの場合、境界ネットワークに配置され、インターネット接続に伴う外部からの脅威に対して高度な保護を提供します。

  • 境界ネットワーク : このネットワークは特に、インターネットとの間で直接アクセスを行う必要があり、したがって攻撃を受ける可能性がより高いサーバーやデバイスのために配置されます。

  • 内部ネットワーク : 通常このネットワークは、組織の IT インフラストラクチャの一部として所有され、管理されているサイトに物理的に配置されている、組織のネットワーク群を表します。

  • 検疫ネットワーク : このネットワークは比較的新しいコンポーネントで、組織が規定する必要最小限のセキュリティ基準を満たしていないコンピュータに対し、限定的な接続を許可します。 コンピュータとユーザーは、必要なテストにパスした後、内部ネットワークへの完全な接続を許可されます。 テストに失敗した場合は、検疫ネットワークにより、テストにパスするために必要な要素をダウンロードしてインストールできる限定的な接続が許可されます。 マイクロソフトでは、ネットワーク アクセス保護 (NAP) を使用してリモート アクセス コンピュータを検疫する新しい機能を提供しています。 詳細については、「ネットワーク アクセス保護」ページを参照してください。

  • パートナー ネットワーク : このネットワークは組織によって所有または管理されていないため、通常は、特定のビジネス アプリケーションまたはビジネス プロセスが、エクストラネット通信を提供する VPN トンネルまたは境界ルーターを経由して動作できるように、高度に制御されたアクセス レベルが与えられます。

図 1.1 には、論理的分離の直接の対象が、内部ネットワーク ホストの通信であることが示されています。 VPN はリモート アクセス サービス (RAS) によって管理され、リモート ワーカーまたはリモート ネットワークからのトラフィックがリモートから安全に接続されるようにする役目を果たします。 ネットワークの境界に配置されたファイアウォールにより、インターネットと内部ネットワーク間の通信が保護されます。 RAS を NAP と組み合わせると、検疫ネットワークを使用してリモート ワーカーの接続を管理する機能が得られます。

現在、これらのさまざまなネットワーク防御は通常、多層防御ネットワーク設計の個別のコンポーネントとしてインストールされ、管理されています。 しかしこれらは今後数年で、1 つの共通ネットワーク防御ソリューションにまとめられ、単一のエンドツーエンド ソリューションとして実装および管理できるようになるでしょう。

現在の多くのネットワーク設計に欠けているものは、内部ネットワーク上のコンピュータを同じネットワークの他のコンピュータから保護する機能です。 大規模な内部ネットワークでは多数の組織をサポートすることがあり、場合によっては複数の IT 部門でコンピュータや物理的なアクセス ポイントを管理する必要があります。 その結果、物理的に接続されているすべてのコンピュータが信頼されて互いに対する完全なネットワーク アクセスを持つ、1 つの単純なネットワークとして内部ネットワークを見ることができなくなっています。

論理的分離の目的は、内部ネットワークをセグメント化して切り離し、ハードウェア的 (物理的) な境界を設置せずにセキュリティ レベルを高めることです。 論理的分離の実際の技術的課題は、組織にとって管理しやすく拡張可能な方法で実装することです。 あまりに複雑で制限の多い設計では、ユーザーが必要なビジネス タスクを実行する機能が損なわれ、分離ソリューションをまったく導入しないよりも悪い状況になりかねません。 ソリューションの展開前および展開時に、適切な計画とテストを行うことが不可欠です。 このガイドに従うと、拡張性と管理性の両方を備え、展開段階の各ポイントでテストができる制御された方法で展開可能なソリューションを設計できます。

論理的分離の導入後は、新しくセキュリティ層が追加されるため、承認されたクライアントの機能性を制限することなくネットワーク上のさまざまな情報資産に対するリスクを軽減できます。

ページのトップへ

プロジェクト チームを編成する

このソリューションは、組織の内部ネットワーク通信のすべての領域に影響する可能性があります。つまり、この通信を利用するすべての部門とユーザーに影響するということです。 このため、このプロジェクトの全段階において、組織のすべてのニーズや要望について話し合い、文書化し、理解し、検討することが不可欠です。

一般的な組織で、このような広がりを持つプロジェクトに必要なすべてのタスクを 1 人の担当者が実行できると考えるのは現実的ではないので、プロジェクト チームの編成をお勧めします。 プロジェクト チームは、現在の IT インフラストラクチャの主要技術部門に加え、組織内の全部門からの代表者で構成します。 プロジェクト チームが組織内でどのように活動するかについてはこのガイドでは扱っていないため、ここでは、このプロジェクトの期間中に適切なプロジェクト チームが設置され、プロジェクトのさまざまな段階で、ソリューションの要件と目標がプロジェクト関係者とソリューションのユーザーに十分に伝えられることを前提とします。 このようなプロジェクトを編成する方法の詳細については、「Microsoft Solutions Framework (MSF) プロセス」を参照してください。

ページのトップへ

ガイドの概要

ここでは、「IPsec とグループ ポリシーを使用したサーバーおよびドメインの分離」ガイドの各章の内容を簡単に紹介します。

第 1 章 : サーバーおよびドメインの分離の紹介

第 1 章 (この章) では、概要を説明し、このガイドの各章の内容を簡単に紹介します。 ここでは、組織のための論理的分離の概念とサーバーおよびドメインの分離アプローチを紹介し、ビジネスにおけるこれらの妥当性と、これらを一般的な IT インフラストラクチャに組み込む方法について説明します。 この章では、Woodgrove National Bank のシナリオについても説明します。このシナリオは、機能検証、設計、およびテストを目的として採用されました。

第 2 章 : サーバーおよびドメインの分離を理解する

第 2 章では、信頼されたホストの概念を説明し、サーバーおよびドメインの分離ソリューションの開発に信頼を使用する方法を説明します。 ここでは、サーバーおよびドメインの分離の概念、IPsec、グループ ポリシーの相互関係を考察します。 このガイドの技術的な部分では、このソリューションから予測されることについて、セキュリティ上の脅威に対する防御と、IPsec を使用してドメインおよびサーバーの分離ソリューションを開発する場合に直面する可能性のある技術上の問題の両方の観点から詳しく技術解説しています。

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

プロジェクトを開始する前に、ソリューションの設計者が現在の IT インフラストラクチャについて最新の正確な情報を把握していることが不可欠です。 この情報には、すべてのネットワーク デバイスの現在の状態、サーバーとワークステーションの構成、ドメイン間信頼などがあります。 また、NAT、IPsec ベースのリモート アクセス VPN クライアント、内部ファイアウォールおよびプロキシ、内部ポートベースのフィルタリングなど、その他のネットワーク テクノロジが与える可能性のある影響も含まれます。 この章では、計画に必要な情報と、その情報を収集する手順について説明します。

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

この章では、組織のビジネス要件をサーバーおよびドメインの分離設計と結び付け、ビジネス要件を達成する方法について説明します。 分離に関する組織のセキュリティ要件を満たす分離グループを設計する手順について、順を追って説明します。 また、展開時に組織が受ける影響を最小限に抑え、実装を成功させる可能性を最大限にするために役立つさまざまな展開アプローチも紹介します。 この章の手順やプロセスはすべて、Woodgrove Bank のシナリオの例を使用して説明しています。

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

IPsec ポリシーとは、各コンピュータがピアツーピアで通信する場合の規則を適用するためのメカニズムです。 この規則は、グループ ポリシー オブジェクトを使用して信頼されたドメインのメンバに割り当てられ、配布されます。 この章では、IPsec ポリシーの作成方法、および受信側のコンピュータに展開する方法について説明します。

第 6 章 : サーバーおよびドメインの分離環境を管理する

ソリューションを導入して運用できる状態にした後、日常業務としてソリューションを適切に管理およびサポートするためには、理解して文書化しておく必要がある数多くのプロセスがあります。 この章では、サポート性のモデルを提示し、Microsoft Operations Framework (MOF) のようなより大きな運用フレームワークの一部として使用する必要があるさまざまな管理プロセスと手順について説明します。 MOF の詳細については、「Microsoft Operations Framework」を参照してください。

第 7 章 : IPsec のトラブルシューティング

ソリューションを展開して使用を開始すると、問題の発生はまず避けられません。 この章では、IPsec のさまざまなトラブルシューティングの手順、タスク、ツール、ヒントなどについて詳しく説明します。これらを使用して、IPsec が問題の原因であるかどうかを特定し、そうであった場合は問題のトラブルシューティングを行うことができます。

付録

このガイドには、上記の各章のほかにさまざまな参照資料、業務支援ツール、スクリプトが付属しています。これらはこのガイドの開発時に、マイクロソフトのテスト ラボ環境の計画、テスト、展開に使用されたものです。 これらの付録に記載された情報を、組織のサーバーおよびドメインの分離ソリューションの実装に役立てることができます。 ここに記載された資料は、初期の計画段階から、展開後のソリューションの日常の運用に至るまで、このプロジェクトのすべての段階で参考となるように構成されています。

ページのトップへ

シナリオの概略

マイクロソフトの内部ネットワーク内には、サーバー分離とドメイン分離の両方のソリューションが展開されています。 しかし、代表的な物理的ラボ環境への実装のテストは、このソリューションに具体的で一般的なモデルを用意するために、Woodgrove Bank という顧客のシナリオに基づいて行われました。 マイクロソフトのビジネス要件と技術要件に加えて、この架空の会社のビジネス要件と技術要件がソリューションの開発に使用されました。 このガイドには、マイクロソフト社内の IT 管理者が通常使用しているサポート技術と管理技術が多数取り入れられています。 ただし、Woodgrove Bank の要件や人員配置がマイクロソフト独自の考えと異なる場合がある箇所については、そのことを付記しています。

Woodgrove Bank とは

Woodgrove National Bank は、機能検証に使用される架空の会社で、一般的な展開を説明する際に具体的な顧客例を挙げるために使用されています。 Woodgrove Bank の要件は、マイクロソフトが企業のお客様とのビジネスで得た多くの経験から導き出されたものです。 Woodgrove は銀行なので、組織の金融資産と顧客の個人データの両方の安全性を確保する必要から、セキュリティに大きく依存しています。 Woodgrove Bank はまた、行政機関や業界団体が定めるさまざまな規制を遵守する必要があります。 このソリューションの対象が特定の 1 つの国または地域に限定されるのを避けるため、ここでは具体的な法律や規制については言及しません。

Woodgrove Bank はグローバルな主要投資銀行で、金融仲介機関としての役割から、公共機関、企業、行政機関、および個人を顧客としています。 Woodgrove Bank の業務は、証券引受、証券販売および取引、投資相談、投資リサーチ、ベンチャー キャピタル、および金融機関向けの仲介業務です。

Woodgrove Bank は、英国ロンドンに本社を置く大手グローバル金融サービス企業、WG Holding Company の完全所有会社です。 WG は、Woodgrove National Bank、Northwind Trading、Contoso, Ltd.、Litware Financials、Humongous Insurance の 5 社を所有しています。 WG 所有の企業はすべて、それぞれが社員 5,000 人以上を有する大規模組織です。

地理的プロファイル

Woodgrove Bank では、15,000 人以上の社員が世界各地の 60 以上のオフィスで働いています。 この会社には、多数の社員を抱える企業本部 (拠点オフィス) が、ニューヨーク (社員 5,000 人)、ロンドン (社員 5,200 人)、東京 (社員 500 人) にあります。 各拠点オフィスは、いくつかの小規模なセカンダリ サイトを抱えています (たとえば、ニューヨークの拠点オフィスにはボストンとアトランタにセカンダリ サイトがあります)。これらの拠点オフィスのほかに、2 つの主要オフィスがシドニーとヨハネスブルグにあり、それぞれに専用のファイル サーバー、プリント サーバー、アプリケーション サーバーがあります。

サイト間の接続

東京とロンドンは、ニューヨークの企業本部にプライベート インターネットで接続され、帯域幅はそれぞれ 6 メガビット/秒 (Mbps) と 10 Mbps です。 すべての地域の拠点オフィスが、企業本部に 2 メガバイト (MB) から 10 MB で接続されています。 主要支社の接続は 2 MB です。 ごく小規模な支社の場合は、一般的に 1 MB のワイド エリア ネットワーク (WAN) 接続です。 これらの接続の詳細は、このガイドの「第 3 章 : IT インフラストラクチャの現在の状態を把握する」の図 3.1 に示されています。

エンタープライズ IT の課題

Woodgrove Bank は、ほとんどの企業に共通する課題に直面しています。つまり、収益を増やし、コストを下げる一方で、固定資産のコストを削減するという課題です。 こういった課題は IT に継続的な影響を与えます。 Woodgrove Bank にはさらに次のような企業イニシアチブもあり、これらも IT に影響します。

  • M&A (合併買収) による新規市場への展開

  • 顧客の期待以上のサービス提供

  • 社員の生産性向上

  • プロセスと業務の改善

  • 安全な環境の提供

これらのイニシアチブが IT に影響するだけでなく、IT 担当の意思決定者にはさらに次のような IT 固有の課題もあります。

  • IT 全体のコストの削減

    • 運用コストの削減、管理性の向上と管理コストの削減、環境内のサーバー数の削減、異種アプリケーションおよびサービスの単一サーバーへの統合

    • 既存の IT 投資の活用

    • 機動的な IT インフラストラクチャの構築

  • 投資収益の増大

    • 稼働率の向上

    • 可用性と信頼性の向上

    • 新しいハードウェア プラットフォームの活用

  • 社員、パートナー、顧客が最も安全な環境でビジネスを行うための環境確保

  • 社内的にも社外的にも、サービス品質保証制度を適用できる能力の保有

  • どこからでも情報にリアルタイム アクセスできることによる、ビジネス アジリティ (俊敏性) の向上

IT 組織のプロファイル

Woodgrove Bank の環境は、Windows と UNIX を使用する混合サーバー環境ですが、インフラストラクチャは Windows Server のバックボーンで稼動しています。 Windows ベースのサーバーは合計 1,712 台あり、この大半で Windows 2000 以降が実行されています。

  • ファイル サーバーとプリント サーバー                   785

  • Web サーバー                               123

  • インフラストラクチャ サーバー                  476

  • Microsoft Exchange サーバー          98

  • Microsoft SQL Server™ サーバー    73

  • 開発サーバー                  73

  • 監視サーバー                      33

  • その他 (Lotus Notes、Oracle)         51

これらのサーバーの大半は、3 つの企業本部 (ニューヨーク、ロンドン、東京) にあります。

PC 環境

Woodgrove Bank のほとんどの社員が、少なくとも 1 台のパーソナル コンピュータ システムを持っています。 ほとんどの社員がデスクトップ PC を所有し、営業担当者はモバイル コンピュータを使用しています。 Woodgrove Bank には合計で 17,000 台を超えるエンドユーザー PC があります。 これらの PC の約 85% がデスクトップ コンピュータで、残りの 15% がモバイル コンピュータです。 エンドユーザー PC の 95% 以上が、Windows のいずれかのバージョンを実行している Intel ベースの PC です。 ほかに、特定の部門では業務 (LOB) アプリケーション用に数台の Mac ワークステーションと少数の UNIX ワークステーションを使用しています。

システムおよび管理アーキテクチャの概要

Woodgrove Bank のネットワークは複数の IT ゾーンで構成されています。企業データ センターが 1 つ、拠点オフィスが 2 つ、サテライト オフィスが 2 つ、リモート ユーザーをサポートする境界ネットワークが 1 つです。 次の図に示すように、Woodgrove Bank ではサーバーとデスクトップをニューヨークで一元管理するための集中管理モデルを実装しています。

図 1.2: Woodgrove Bank の IT 集中管理モデル

拡大表示する

ディレクトリ サービス

Woodgrove Bank では Active Directory 設計にサービス プロバイダのフォレスト モデルを採用しました。 理由は、このモデルには 1 つのフォレストを境界用に、別の共有フォレストを内部リソース用に使用できる柔軟性があるからです。 これにより、境界ネットワークに配置するサーバーの分離要件を満たすことができます。 Woodgrove では単一フォレスト モデルは選択しませんでした。このモデルでは、境界サーバーを重要な企業データから分離できないからです。 次の図は、Woodgrove Bank で使用している Active Directory の論理構造を示しています。

図 1.3: Woodgrove Bank のディレクトリ サービスの設計

拡大表示する

境界フォレストでは、単一フォレストのドメイン モデルを使用しています。境界サーバーの管理にはこのモデルで十分です。 境界では複製の要求はごく少ないので、複製の境界を設置したり、複数の地域ドメイン モデルを使用してフォレストをセグメント化する必要はありません。 Woodgrove ではこの設計を境界サーバーのみの管理に採用したことに注意してください。 ユーザー アカウントが境界に配置され、境界が複数の場所に位置する場合は、異なるドメイン設計が必要となります。

内部フォレストは複数の地域ドメイン モデルに基づいています。 Woodgrove はアメリカ、ヨーロッパ、アジアの 3 つの地域ドメインを作成しました。 さらに、フォレスト レベルの機能を管理するために専用のフォレスト ルートを実装しました。 このモデルには、ドメイン レベルの自律性の管理を各地域に委任する機能のほかに、複製トポロジを管理する機能があります。

Woodgrove Bank のサイト トポロジは、アメリカ、ヨーロッパ、アジア (アジア太平洋) の 3 つの地域に分割されています。 ニューヨーク、ロンドン、東京はトポロジ全体に対する中心拠点です。

Woodgrove Bank の設計者グループは、基本的にオブジェクトベースの組織単位 (OU) 設計を採用しました。 OU 構造が各地域ドメインにそっくりそのまま複製され、OU 構造の一部がフォレスト ルートに作成されます。 このガイドの第 3 章の図 3.2 には、Woodgrove Bank で使用されている OU 構造の詳細が示されています。

Woodgrove におけるサーバーおよびドメインの分離戦略の公開

組織の要件を最も満たす設計について共通の理解を得るため、Woodgrove Bank では機能検証のためのラボ プロジェクトを作成しました。 このプロジェクトでは、小規模なラボ環境に実装することによって、Woodgrove で提案された設計をテストしました。この設計を次の図に示します。

図 1.4: Woodgrove Bank のパイロット設計

拡大表示する

この図には、このガイドで説明するシナリオをテストするために Woodgrove Bank のシナリオで使用されたコンピュータの一部が示されています。 この機能検証プロジェクトの目的は、運用サーバーや社内ユーザーに影響を与えることなく、ラボ設計に十分な多様性を持たせて、ソリューションが予想どおりに機能することを確認することでした。

このガイド全体で使われている例は、図 1.4 に示されたパイロット設計のインフラストラクチャから得られた結果に基づいています。

注 : 分離によってコンピュータ ネットワーキングの多くの面が変更されるため、マイクロソフトでは、それぞれの分離シナリオをまずラボ環境でテストし、運用環境に影響がないようにすることを強くお勧めしています。 IT 管理者は、第 6 章と第 7 章で、サポート性の問題、運用手順、トラブルシューティングについて確認してください。

ラボへの実装プロジェクトが成功した後、基本的なサーバー分離シナリオを実装するサーバーのグループが決定されました。 これらのサーバーは、接続に影響があった場合でもビジネスへの影響が少ないサーバーです。 IT 管理者とサポート スタッフは、トラブルシューティング技術についてトレーニングを受けました。 これらのサーバーについて、パフォーマンスとサポート コールの影響が慎重に監視されました。 組織内での管理の役割、プロセス、およびサポート方法がテストされました。 次に、Woodgrove の小規模ドメインの 1 つが、ドメイン分離のパイロット用に選ばれました。 このドメイン分離プロジェクトの影響は、ほとんどのドメイン メンバが位置するネットワーク サブネットに対してのみ IPsec を使用することによって最小化されました。 また、これらのドメイン メンバがこのパイロットに参加していない他のコンピュータと通信するときは、IPsec 以外の通信を可能にし、さらに影響を軽減しました。 これらのパイロットが完了した時点で、プロジェクト チームは、組織全体に展開する最終的な設計の作成と実装に必要なすべての情報を得ました。

ページのトップへ

要約

この章では、論理的分離について紹介し、サーバーおよびドメインを分離することによって、IPsec とグループ ポリシーを使用したエンタープライズ レベルのソリューションを作成する方法について説明しました。 また、このガイドの各章の概要を説明し、内容を簡単に紹介しました。 この章の内容から、このソリューションが組織に何をもたし、一般的な IT インフラストラクチャのどこに組み込まれるかや、このソリューションを成功させるために必要なスキルを理解できます。

ページのトップへ