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

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

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

ローカル エリア ネットワーク (LAN) が普及して以来、情報技術 (IT) 専門家の課題は、十分なセキュリティを維持しながら障害許容力のある可用性の高いサービスを提供することです。 ネットワーク層とトランスポート層にセキュリティを実装するという問題に対処するため、TCP/IP と連携するさまざまなテクノロジが導入されてきました。 たとえば IPv6、802.1X、ネットワーク スイッチ、仮想 LAN (VLAN) のセグメンテーション、インターネット プロトコル セキュリティ (IPsec) をはじめ、他にも多数あります。

これらのテクノロジ導入から予期しない結果として現れたのが、多層アプローチによるネットワーク セキュリティの実現です。 これらの複数の層を使用すると、1 つまたは複数のホストやネットワークを他のホストやネットワークから隔離、分割、または分離することができます。 この章の目的は、IPsec で提供されるセキュリティ層を他の層と比較して整理することと、ソリューションでこのセキュリティ層をグループ ポリシーと共に使用して、管理性と拡張性を備えた方法で企業規模の環境に分離を実現する方法を説明することです。

トピック

章の前提条件
対象読者
ビジネス要件
信頼されたコンピュータを特定する
組織の全体的なネットワーク セキュリティ戦略にサーバーおよびドメインの分離を組み込む方法
用語の再確認
サーバーおよびドメインの分離を実現する方法
サーバーおよびドメインの分離で防御される脅威
サーバーおよびドメインの分離を展開する方法
要約

章の前提条件

この章に記載されている情報を活用するには、以下の概念とテクノロジを十分に理解している必要があります。 以下の前提条件を満たしていなくてもこのガイダンスを利用できますが、すべての前提条件を満たしていれば実装が成功する確率ははるかに高くなります。

知識の前提条件

Microsoft® Windows Server™ 2003 の次の領域について理解している必要があります。

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

• Kerberos Version 5 プロトコルおよび公開キー基盤 (PKI) の使用を含む認証の概念

• Microsoft Windows® システムのセキュリティ。ユーザー、グループ、監査、およびアクセス制御リスト (ACL) などのセキュリティ概念。セキュリティ テンプレートの使用。相互認証の概念。ドメイン ネーム システム (DNS) や Windows Internet Naming Service (WINS) などの標準的な名前解決方式と概念。標準的な Windows の診断ツールとトラブルシューティングの概念。グループ ポリシーまたはコマンドライン ツールを使用してセキュリティ テンプレートを適用する方法。

• TCP/IP の概念の知識 (サブネットのレイアウト、ネットワーク マスク、ルーティングなど)。 また、インターネット制御メッセージ プロトコル (ICMP)、アドレス解決プロトコル (ARP)、最大転送単位 (MTU) などの低レベルの機能、プロトコル、用語についての知識。

• セキュリティ リスク管理の原則についての知識。

  注 : 「Windows Server 2003 Deployment Kit」の「Chapter 6 Deploying IPsec」(英語) では、IPSec トランスポート モードを使用するシナリオについて説明していますが、これらの中にその時点では推奨ではないものがありました。 しかし、マイクロソフト社内で独自に IPsec を展開した経験に加え、利用できるガイダンスが追加されたことから、現在は状況が変わっています。 マルチキャスト トラフィックとブロードキャスト トラフィックではまだ IPsec を使用できませんが、すべての種類のユニキャスト IP トラフィックは IPsec でセキュリティ保護できるようになっています。 ドメインまたはサーバーの分離シナリオで IPsec を展開する利点と、コスト、影響その他のトレードオフを比較し、評価する必要があります。 現在マイクロソフトでは、このガイダンスに従ってお客様のネットワークへの IPsec の普及を推奨し、サポートを行っています。

組織の前提条件

組織のセキュリティの計画を 1 人で担当することはまずありません。 組織の要件を正確に判断するために必要な情報は、多くの場合、組織内のさまざまな部門から得られます。 分離の計画に参加する必要がある、組織の他のメンバとよく話し合ってください。たとえば次のような役割を持つ人が考えられます。

• 企業のスポンサー

• ユーザー グループの代表者

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

• リスク管理グループ

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

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

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

サーバーおよびドメインの分離プロジェクトの対象範囲では、包括的なチームが、ビジネス要件、技術的な問題、ユーザーへの影響、およびプロジェクトの全体的なプロセスを理解している必要があります。 多くの場合、上級職の人をこのプロジェクトの窓口とすると、サポート スタッフや展開時に影響を受けるユーザーなど、幅広く社内の意見が必要になる場合に便利です。 複雑なプロジェクトが失敗する主な 2 つの原因は、計画不足と連絡不足です。 プロジェクト チームはこれらの潜在的なリスクを理解し、リスクを最小限にするための措置をとる必要があります。

ページのトップへ

対象読者

この章は、組織に合わせてカスタマイズされた、サーバーおよびドメインの分離ソリューションの設計を担当する技術面での意思決定者と技術設計者を対象としています。 この章の内容を最大限に活用するには、関連するテクノロジと組織の現在のインフラストラクチャの両方について、技術的な面を理解していることが必要です。

ページのトップへ

ビジネス要件

ソリューションの導入は、組織のビジネス要件に基づく必要があることを理解することが重要です。 分離とは、1 つまたは複数のコンピュータを、それ以外のコンピュータとのネットワーク通信から論理的または物理的に隔離することです。 セキュリティ上の制限事項は常に、組織の社員の日常業務に影響します。 このソリューションの導入に伴う変更により、ドメイン内のコンピュータどうしの通信方法や、ドメイン内のコンピュータと信頼されていないコンピュータとの通信方法も変化します。 このソリューションでは、プロジェクト チームが実現性について計画および調査する時間と、IT サポート スタッフのトレーニングが必要です。また少なくとも、最小限の社員を対象とする意識向上プログラムを用意する必要があります。 ネットワーク トラフィックにセキュリティ サービスが追加されることによって、サーバー メモリやハードウェア アクセラレーション ネットワーク カードの追加が必要になる場合もあります。 また、他のソリューションでも同じか同様の目的を実現できる場合もあります。 したがって、このソリューションによってビジネスにもたらされる金銭的価値を評価することが重要です。

法規制に確実に準拠する

コンピュータに保存される個人情報の増加に従って、データのプライバシーに対する注目も高まっています。 顧客や社員の情報へのアクセスを制御することは、単に適切なビジネス慣習というだけではなくなっています。 各国の法律によっては、機密情報の保護を怠った組織は重大な経済的および法的責任を負いかねません。 たとえば米国で活動する組織は、次の 1 つ以上の規制が定める要件を満たす必要があります。

• 連邦情報セキュリティ管理法 (FISMA : Federal Information Security Management Act)

• 米国企業会計改革法ならびに投資者保護法 (Sarbanes-Oxley Public Company Accounting Reform and Investor Protection Act)

• 金融サービス近代化法 (GLBA : Gramm-Leach-Bliley Financial Services Modernization Act)

• 医療保険の携行性と責任に関する法律 (HIPAA : The Health Insurance Portability and Accountability Act)

HIPAA のセキュリティに関する規則には、医療関連の組織による電子的な個人の健康情報 (ePHI) の取り扱い方法について、厳しいガイドラインが定められています。 HIPAA では特定のテクノロジの義務付けや推奨はしていませんが、HIPAA への準拠に必要な機能と ePHI へのリスクを軽減させる手段が規定されています。 IPsec の保護機能によるドメインまたはサーバーの分離を、次の HIPAA 条項が定める要件を満たすための技術的な措置として採用することを検討してください。

• アクセス制御に関する条項 164.312(a)(1) 信頼されたコンピュータへの受信ネットワーク アクセスを、グループ ポリシーによる承認を使用して保護する。暗号化を使用して、ネットワーク トラフィックでの EPHI の漏えいするを防ぐ。

• 監査制御に関する条項 164.312(b) どのコンピュータが相互に通信しているかを監査する。

• 整合性に関する条項 164.312(c)(1) ePHI が保存されているコンピュータへの受信ネットワーク アクセスを、承認および信頼されたコンピュータおよびユーザーの特定のグループのみに制限する。 また、アプリケーション接続でのすべてのネットワーク パケットの整合性と信頼性を確保することにより、ネットワーク転送中の ePHI の改ざんを防ぐ。

• 個人またはエンティティの認証に関する条項 164.312(d) 信頼されたコンピュータから他の信頼されたコンピュータへの受信ネットワーク アクセスで、認証と承認を要求する。

• 転送セキュリティに関する条項 164.312(e)(1) 信頼性、整合性、暗号化を提供する。

多くの場合、これらの要件は Secure Sockets Layer (SSL) と Transport Layer Security (TLS) によって満たすことができます。 たとえば、アプリケーションで Microsoft .NET テクノロジと SSL/TLS を使用すると、HIPAA のセキュリティに関する規制に準拠できます。 詳細については、ホワイト ペーパー「Healthcare Without Boundaries: Integration Technology for the New Healthcare Economy」(英語) を参照してください。

ただし、アプリケーション通信で SSL/TLS の使用とアルゴリズムの制御を正しく統合する必要があります。 IPsec 分離ソリューションの主な利点は、ホスト コンピュータのオペレーティング システムだけでなくすべてのアプリケーションが保護されることと、既存のアプリケーションのネットワーク トラフィックを、アプリケーションに変更を加えずにセキュリティ保護できることです。 詳細については、この章で後述する「SSL/TLS と IPsec の比較」を参照してください。

このソリューションの米国政府規制への準拠

2003 年 12 月 16 日、 米国行政管理予算局 (OMB) は、覚書「E-Authentication Guidance for Federal Agencies」(英語) を公開しました。 この覚書には、認証の侵害リスクのレベルは、電子認証 (e 認証) の必要性のレベルに対応すると明記されています。

NIST の Special Publication 800-63「Electronic Authentication Guideline: Recommendations of the National Institute of Standards and Technology」には、認証レベル 1 ～ 4 の技術要件が定められています。 多くの場合、強固なレベル (3 と 4) のユーザー認証には、アプリケーションの書き換えや交換が必要です。 全体的なセキュリティ リスクを軽減できれば、高度な機密情報へのアクセスに対し、コストの低いユーザー認証を使用できます。 Windows プラットフォームにサーバーおよびドメインの分離ソリューションを導入すると、信頼されたコンピュータの認証、アクセス制御、ネットワーク トラフィック認証、および暗号化が行われる最初の層が追加され、この後にアプリケーション層でユーザー認証が行われます。 したがって、サーバーおよびドメインの分離ソリューションを使用すると、アプリケーション変更の要件を少なくしたり先送りできる場合があり、リスク管理に関する規定への準拠にも役立ちます。

情報保証製品に対する政府の規制に準拠するため、マイクロソフトではいくつかの認定手続きを行っています。 Windows 2000 は情報技術セキュリティ評価共通基準 (ISO 標準 15408) の評価保証レベル 4 (EAL4) + 欠陥修正 (ALC_FLR.3 Systematic Flaw Remediation) の認定を受けました。 この認定は、オペレーティング システムと機密データ保護の両方のカテゴリに適用されます。

注 : このガイドの執筆時点では、Windows XP および Windows Server 2003 の両プラットフォームについても認定中です。

また、Windows 2000、Windows XP、Windows Server 2003 の IPsec 暗号化コンポーネントは、FIPS 140-1 暗号化要件への準拠が認定されました。 したがって、サーバーおよびドメインの分離ソリューションは、軍事機関、政府機関、およびそれに関連する IT 環境で使用できます。 詳細については、次のリンクを参照してください。

• 「NSTISSP No. 11 Fact Sheet: National Information Assurance Acquisition Policy」 https://niap.nist.gov/cc-scheme/nstissp\_11\_revised\_factsheet.pdf (英語)

• 「Validated Products List (by Technology Type)」https://www.niap-ccevs.org/cc-scheme/vpl/ (英語)

• 「Overview: Windows 2000 Common Criteria Certification」https://www.microsoft.com/technet/security/prodtech/Windows2000/w2kccwp.mspx (英語)

• 「FIPS 140 Evaluation」 https://www.microsoft.com/technet/archive/security/topics/issues/fipseval.mspx (英語)

このセクションの情報は、米国で活動する組織にのみ該当します。 ただし、関連規制は世界各国で作成されています。たとえば 1998 年に欧州連合で可決されたデータ保護条例 (Data Protection Directive of 1998) およびカナダの個人情報保護及び電子文書法 (PIPEDA : Personal Information Protection and Electronic Documents Act) には、個人情報の管理とデータのプライバシーについて厳格なガイドラインが既定されています。

IT インフラストラクチャのビジネス リスク評価

ビジネス リスク評価を行うと、ビジネスが IT インフラストラクチャにどのように依存しているかが明らかになります。 IT セキュリティのリスク評価を行うと、情報の整合性とサービスの安定性に対するリスクが特定され、優先順位が明確になります。 セキュリティのリスク評価によって、こういったリスクに対処しなければならない理由がはっきりし、リスクに対処しない場合の見積もりコストも割り出されます。 コストの見積もりは、問題別にさまざまな技術ソリューションを評価するために極めて重要です。 1 つのソリューションでリスクに 100 % 対処できるわけではないので、さまざまなソリューションを関連コストを含めて相互に比較します。

意思決定者は、ネットワークを介してウイルスやワームの感染が拡大し、そのためにサービスが低下したり停止するリスクを、分離ソリューションでどのように軽減できるかという点を考慮して、このソリューションのコストを評価することができます。 組織によっては、価値の高いデータへのハッカーによる攻撃が成功した場合のビジネスへの影響とコストの方が問題となる場合もあります。

注 : 一部の国や地域では、セキュリティ侵害があった場合、影響する可能性がある顧客に必ず報告することが法によって義務付けられています。 組織に関係する具体的な法的問題については、該当国の関係官庁または顧問弁護士に問い合わせてください。

次の分類を参考に、セキュリティ インシデントの総コストを見積もります。

• サービス停止によって発生するコスト : ネットワーク サーバー上でのサービス停止によって発生する総コストを算出するには、次のそれぞれの個別コストを合計します。

  • サポート担当者に必要なインシデントへの対応時間

  • アプリケーション サービス中断によって失われる収益

  • 社内の生産性低下

• 情報の盗難によって発生するコスト : 内部のネットワーク サーバーの情報の盗難によって発生する総コストを算出するには、次のそれぞれの個別コストを合計します。

  • 情報の開発に必要な知的財産の損失

  • 盗難が公になった場合、顧客の信頼を失うことによって全製品にわたって失われる将来の収益

  • 盗難が公になった場合、投資家の信頼を失うことよって減少する市場価値

  • マーケティングおよび開発に必要な内部的な対応時間

  • 社内の対応努力に伴う収益機会の損失

  • ビジネス、社員、または顧客に対する、外部者による情報の悪用を防ぐための対応に必要な時間

• サーバーの管理者資格の侵害によって発生するコスト : 内部のネットワーク サーバーの管理者資格の侵害によって発生する総コストを算出するには、次のそれぞれの個別コストを合計します。

  • 攻撃への対応とサーバーの交換に要する社内の労力

  • サーバーの管理者資格の侵害によって可能になる他のコンピュータへの攻撃を防ぐための社内の対応

• 結果として生じる訴訟または規制措置によって発生するコスト : 結果として必要になる訴訟によって発生する総コストを算出するには、次のそれぞれの個別コストを合計します。

  • 攻撃者が特定されても組織が敗訴した場合の訴訟費用

  • 攻撃者が特定され、組織が勝訴しても、裁判所が認めた損害賠償額を被告が支払えない場合の訴訟費用

  • 取り締まりの罰金、監査、制限、および現在のビジネス環境を再構築するためのその他の誠意ある努力にかかるコスト

情報セキュリティの長期的方向性への投資

Microsoft ネットワーク アクセス保護 (NAP) のイニシアチブは、ネットワークに接続するデバイスおよび相互接続するデバイスのポリシー準拠を厳密に制御するための長期的方向性を確立しています。 リモート アクセス検疫と、サーバーおよびドメインの分離の 2 つがこの方向性の構成要素で、現在の Windows 2000 以降のプラットフォームで実装できるようになりました。 境界と内部の両方の分離機能を組み合わせることにより、信頼されていないコンピュータやユーザー資格情報の侵害によって発生するウイルス感染およびその他の攻撃から、組織を効果的に防御できます。

NAP のイニシアチブの詳細については、「ネットワーク アクセス保護」Web サイトを参照してください。

仮想プライベート ネットワーク (VPN) と検疫アクセス制御の詳細については、「Windows Server 2003 の仮想プライベート ネットワーク」Web サイトを参照してください。

マイクロソフトでは、Windows の将来のリリースに、より管理しやすく包括的なネットワーク アクセス保護の搭載を計画しています。

ページのトップへ

信頼されたコンピュータを特定する

信頼とは何か、またそれがコンピュータとどのように関連しているかは、サーバーおよびドメインの分離のトピックの重要な部分です。 分離とは根本的に、特定の信頼されたホストが、そのホストへのネットワーク レベルのアクセス権を持つユーザーを判断する機能です。 したがってリモート コンピュータは、リモート エンドでの接続方法 (たとえばワイヤレス、LAN、インターネット) にかかわらず、IPsec を使用して信頼のネゴシエートを行い、接続先コンピュータとのエンドツーエンドの TCP/IP トラフィックをセキュリティ保護する必要があります。 このエンドツーエンドのセキュリティ モデルにより、他のリンクベースのネットワーク アクセス制御およびセキュリティ テクノロジ (VPN、802.1x、802.11 WEP など) では不可能なレベルのネットワーク通信の保護が実現します。 最初にリモート コンピュータを信頼することは、ユーザー資格情報の盗難、侵害、悪用などを防御するのに非常に有効です。

このソリューションのコンテキストにおける信頼とは、ある特定のコンピュータが既知の状態にあり、組織で合意した最低限のセキュリティ要件を満たしていることを組織が確信できることです。 この要件には、技術的なもの、セキュリティに重点を置いたもの、ビジネス関連のもの、またはこれらを任意に組み合わせたものがあります。 このような要件には、コンピュータが他のコンピュータとの通信を確立する前にどのような状態になっていなければならないかも規定されます。 マイクロソフトでは、信頼されたコンピュータの仕様として、必要なセキュリティ更新プログラムとサービス パックの自動更新リストを加えることをお勧めします。 Windows Update サービスや Microsoft Systems Management Server (SMS) などの更新プログラム管理システムを利用して、このような更新プログラムを管理および実行するのが理想的です。 こういった更新プログラムを適用する頻度は、組織で各更新プログラムのテストおよび展開にかかる時間によって異なります。 ただし、最適なセキュリティのためには、環境に可能な限り迅速に更新プログラムを適用してください。

信頼されていないコンピュータとは、このようなセキュリティ要件を満たしていることが保証されないコンピュータです。 一般に、管理されていないかセキュリティ保護されていないコンピュータは信頼されていないコンピュータとみなします。

サーバーおよびドメインの分離ソリューションの目的は、組織の資産を保護するツール、テクノロジ、およびプロセスを実装することによって、信頼されたリソースにもたらされるリスクを軽減することです。 このソリューションでは次のことを実現します。

• 信頼された状態とみなされるコンピュータ (特定のセキュリティ要件を満たすコンピュータ) のみが、信頼されたリソースにアクセスできる

• 信頼されていないコンピュータは、特定のビジネス上の理由によってリスクが正当化される場合を除き、信頼されたリソースへのアクセスを拒否される

既定では、信頼されたリソースには、他の信頼されたリソースからのネットワークレベルのアクセスのみ許可します。 さらに、信頼された環境内の特定のユーザーとコンピュータに対して許可または拒否の権限と ACL を使用して、ネットワーク層でアクセスを制御します。

このような信頼された環境を作成し、この環境の内部と外部で許可される通信を制限することにより、ビジネスにおけるデータ資産への全体的なリスクを低減できます。 他にも次のようなビジネス上の利点があります。

• ネットワークの特定領域でのデータ フローに対する高度な理解

• "信頼された" 状態を実現するためのより強力なセキュリティ プログラムの採用

• ホストおよびネットワーク デバイスの最新のインベントリ作成

たとえば Woodgrove Bank のシナリオでは、信頼されたコンピュータとは Windows 2000 Service Pack (SP) 4、Windows XP SP2 以降、または Windows Server 2003 以降を実行し、Woodgrove が所有し管理するいずれかのドメインに属するすべてのコンピュータです。 また、信頼された資産とは Windows 2000 以降を実行し、グループ ポリシーを使用してセキュリティ設定を適用するすべてのコンピュータです。信頼された資産は、IT スタッフによって定期的に検証され、最低限の要件が引き続き満たされていることが確認されます。 IT スタッフは、信頼された資産の検証において、セキュリティ専用のソフトウェア (ウイルス対策ソフトウェアなど) のインストールと構成が、Woodgrove 独自のセキュリティ要件に従って集中管理されていることも確認します。 このソリューションのコンテキストで信頼されたコンピュータとみなされるコンピュータの詳細については、このガイドの「第 3 章 : IT インフラストラクチャの現在の状態を把握する」の「信頼の決定」を参照してください。

管理されていないコンピュータ

管理されていないコンピュータとは、IT 部門がセキュリティ設定を集中管理していないコンピュータです。 また、必要なセキュリティ管理機能を備えていないコンピュータも管理されていないコンピュータに該当します。 管理されていないコンピュータは、信頼されていないコンピュータとみなされます。これらのコンピュータが接続先の信頼されたコンピュータのセキュリティ要件を満たすことを組織が確信できないからです。

保護されていないコンピュータ

信頼されていないコンピュータには、必要なセキュリティ レベルに構成されていないか構成できないオペレーティング システムを実行しているコンピュータも含まれます。 保護されていないコンピュータは、次の 4 つのグループに分けられます。

• オペレーティング システムのセキュリティ評価が低い : このグループには、必要なセキュリティ インフラストラクチャ評価を満たしていないオペレーティング システムを実行しているコンピュータが入ります。 これに該当するオペレーティング システムは、Windows 9x、Microsoft Windows NT®、Windows CE です。 一般に、セキュリティ インフラストラクチャに必要な機能は、Windows XP および Windows Server 2003 などの最新のオペレーティング システムに搭載されています。 このような機能には、アクセス制御 (ファイルのアクセス許可など)、パケット暗号化や強固な認証および承認などのネットワーク セキュリティ機能、異なるレベルの権限 (ユーザーと管理者)、セキュリティ設定の集中管理のサポート、データの機密性と整合性の保証のサポート、他のセキュリティ テクノロジ (Kerberos 認証プロトコルおよび証明書サービスなど) のサポートなどがあります。

• 構成が適切でない : 最も安全なオペレーティング システムであっても、構成が適切でなければ攻撃に対して無防備なままになります。 このようなコンピュータも保護されていないデバイスとみなす必要があります。

• 必要なレベルの更新プログラムがインストールされていない : IT セキュリティは常に進化している領域であるため、ほとんどのソフトウェア ベンダは、ソフトウェア更新プログラムをリリースして最新の脆弱性に適切に対処できるようにしています。 信頼された状態とみなされるためにホストに必要な最低レベルの更新プログラムを組織で特定することもできます。 この場合、この最低限の更新プログラムをインストールしていないコンピュータは、保護されていないコンピュータとみなされます。

• 信頼されたコンピュータが侵害された可能性がある : 信頼されたコンピュータが侵害される可能性もあります。多くの場合は信頼された攻撃者によるものです。 信頼されたコンピュータが侵害された場合は、修正作業を行って信頼された状態に戻すまでは信頼されたコンピュータとみなすことはできなくなります。 あるコンピュータのユーザーを信頼できない場合は、そのコンピュータも信頼できないことに注意してください。

この 4 つのグループのいずれかに入るデバイスは、信頼されていない状態と分類されます。このようなデバイスは何らかの方法で侵害されていないと確信できないからです。 したがって、このようなデバイスはその接続先となる信頼されたコンピュータにとって重大なリスクとなります。

サーバーおよびドメインの分離によって直接実現可能な目標

サーバーおよびドメインの分離の全体的な目標は、信頼されていないコンピュータから信頼されたコンピュータへの未承認のアクセスによってもたらされる脅威を軽減することです。 現在のプラットフォームでは、受信ネットワーク アクセスの制限によってリモート コンピュータを分離する機能は、IPsec のインターネット キー交換 (IKE) セキュリティ ネゴシエーション プロトコルを使用して、ドメイン メンバ コンピュータを正しく認証する機能に基づいています。 ユーザー認証はコンピュータ認証に成功した後にのみ行われ、IPsec セキュリティ アソシエーションによってすべての上位層プロトコルと 2 台のコンピュータ間のアプリケーション接続が保護されます。 したがって、サーバーおよびドメインの分離を使用すると、次の目標を実現できます。

• 信頼されたドメイン メンバ コンピュータを、信頼されていないデバイスからネットワーク レベルで分離する。

• 内部ネットワーク上の信頼されたドメイン メンバへの受信ネットワーク アクセスには、別の信頼されたドメイン メンバを使用する必要があるようにする。

• 信頼されたドメイン メンバが、特定のグループに属するドメイン メンバ コンピュータへの受信ネットワーク アクセスを制限できるようにする。

• ネットワーク攻撃のリスクを少数のホストに集中させる。これにより、信頼されたドメインの境界ができ、境界では最大限のリスク軽減方法 (ログへの記録、監視、侵入検知など) をより効果的に適用できる。

  • 攻撃が発生する前の予防的な監視と準拠に重点を置き、優先する。

• 攻撃の発生前、発生時、発生後の対応および回復作業に重点を置き、加速化する。

• パケットごとの強固な相互認証、整合性、リプレイ防御および暗号化を追加することにより、アプリケーションおよび上位層プロトコル (サーバー メッセージ ブロック (SMB) または NetBT など) を変更せずにセキュリティを向上させる。

サーバーおよびドメインの分離は、信頼されたホストのすべてのネットワーク サービスを、信頼されていないネットワーク アクセスや攻撃から保護することを目的としています。 サーバーおよびドメインの分離によって、他のネットワークベースのセキュリティに存在する弱点や問題点、またユーザー資格情報の保護における弱点に対するホストの脆弱性が改善されます。 最後に、サーバーおよびドメインの分離ソリューションは、他のネットワークベースのセキュリティ テクノロジと同様のネットワークの脅威に対処しますが、それとは異なるレベルのネットワーク アクセス制御とトラフィック保護を提供します。 たとえばサーバーおよびドメインの分離ソリューションでは、特定の信頼されたホスト コンピュータへの受信アクセスを、ホストおよびユーザーのドメイン ID に基づいて承認できるため、この承認された通信がエンドツーエンドで保護されます。 一方、ほとんどのネットワークベースのセキュリティ テクノロジでは、ユーザー ID のみがサポートされています。

サーバーおよびドメインの分離によって対処できるリスク

サーバーおよびドメインの分離によって対処できる最大のリスクは、信頼されていないコンピュータから信頼されたコンピュータへの未承認のアクセスによってもたらされるリスクです。 一部のセキュリティ リスクは、このソリューション単独では十分に軽減することができません。 こういったセキュリティ リスクに対し、別のセキュリティ プロセスやテクノロジを追加しても防御できない場合、最終的にこの分離ソリューションのセキュリティ上の利点が無効になる可能性があります。 このソリューションで直接軽減できない重大なセキュリティ リスクには次のようなものがあります。

• 信頼されたユーザーが機密性の高いデータを盗むまたは漏えいするリスク : 分離ソリューションでは内部ネットワーク内でコンピュータが通信する場所を制御できますが、管理者ユーザーはこの制御を覆すことができます。 このソリューションでは、信頼されたユーザーが機密性の高いデータを不正にコピーしたり広めたりするリスクを排除できません。

• 信頼されたユーザーの資格情報が侵害されるリスク : 管理者は、ネットワーク ログオン情報を保護するために、ほとんどの IPsec トラフィックの暗号化を選択できますが、ドメイン コントローラへのユーザー ログオン トラフィックの IPsec による保護はサポートされていません。 サーバーおよびドメインの分離では、攻撃者が信頼されたホストを使用して他の信頼されたホストを攻撃できる可能性があります。 また攻撃者が、信頼されたホストでの IPsec 使用の対象外となっているホスト (たとえばドメイン コントローラや DNS サーバー) や、信頼されていないコンピュータからの受信接続を受け入れるホストの資格情報を侵害し、それを使用して信頼されたホストを攻撃する可能性もあります。 管理者は、信頼されたホストから信頼されていないホストへの送信接続を行うかどうかを制御できますが、このソリューションでは、攻撃者が信頼されたユーザーをだましてパスワードを公開するように仕向け、資格情報を侵害するリスクを軽減できません。

• 悪意のあるユーザー : 正当なユーザーがアクセス権を悪用する場合もこれに分類されます。 たとえばこのソリューションでは、不満を持つ社員が、職務上持っている信頼されたホストへのアクセス権を利用して情報を盗もうとした場合のリスクを軽減できません。 信頼されたホスト コンピュータへの物理的アクセスが可能であれば、攻撃者はそのホストへの未承認の管理アクセス権を手に入れることができます。 管理者はサーバーおよびドメインの分離による保護を無効にできるため、既定のアクセス範囲と管理者の数 (エンタープライズ管理者、ドメイン管理者、ワークステーションまたはメンバ サーバーのローカル管理者など) を制限することが不可欠です。

• 信頼されていないコンピュータが他の信頼されていないコンピュータにアクセスするリスク : このソリューションでは、攻撃者が信頼されていないコンピュータを使用して、他の信頼されていないコンピュータを攻撃するリスクを軽減できません。

• 信頼されていないコンピュータが特定の信頼されたコンピュータを攻撃するリスク : サーバーおよびドメインの分離ソリューションは、信頼されたホストを保護するように設計されています。 しかし、展開時の実際問題としてこのソリューションでは、さまざまな理由から他の信頼されたコンピュータへの信頼されたアクセスのネゴシエートに IPsec を使用しない、信頼されたドメイン メンバを特定します。 このような、信頼されているが IPsec を使用しないコンピュータは、適用除外リストのメンバになります (たとえばドメイン コントローラ)。 またこのソリューションでは、特定の信頼されたホストを、信頼されていないコンピュータからアクセス可能なホストにすることで、分離ドメインに境界サービスを提供します。 攻撃者が IPsec 適用除外ホストまたは境界ホストの制御を手に入れると、分離ドメイン内にある他のすべての信頼されたホストを攻撃できるようになります。

• 信頼されたホストのセキュリティへの準拠の保証 : このソリューションでは、信頼されたホストの定義方法を提案しており、特にこれらのホストが Windows 2000 または Windows Server 2003 のドメイン メンバであることが必要です。 このソリューションでは、信頼が確立され、その結果 IPsec で保護された接続が確立されるかどうかは、IPsec IKE のドメインベースの (Kerberos) 認証が成功するかどうかにのみかかっています。 時間の経過とともに、信頼されたホストが、信頼されたホストとしての条件の一部をさまざまな理由から満たさなくなり、それでもドメイン メンバとして正常に認証される場合があります。 ドメイン メンバを信頼されたホストの定義に確実に準拠させるのは、組織の IT 管理システムとプロセスの責任です。

これらの問題に対処するため、推奨のセキュリティ強化構成とテンプレートが、Woodgrove のラボ環境のすべてのシステムに適用されました。 Windows プラットフォームのセキュリティ テクノロジおよび管理手順の詳細については、「TechNet : セキュリティ センター」Web サイトを参照してください。

ページのトップへ

組織の全体的なネットワーク セキュリティ戦略にサーバーおよびドメインの分離を組み込む方法

サーバーおよびドメインの分離は、ネットワークおよびコンピュータなどのネットワーク接続デバイスを保護するため、他の予防的なメカニズムや対応型のメカニズムに加えて使用されます。 セキュリティは複数の層を必要とする多面的な問題なので、多層防御の概念とその背景にある高度な考え方を確認しておくと役に立ちます。 包括的なネットワーク セキュリティ戦略では、適切なテクノロジを適用して、障害が発生した 1 か所に大きく依存せずに優先順位が最も高いリスクを軽減します。 たとえば、構成ミスまたは悪意のある社員が原因で境界のセキュリティに障害が発生した場合、他のどの防御層で、内部の信頼されたホストに対するネットワーク攻撃やウイルス感染を食い止められるでしょうか。 攻撃者が米国オフィスの会議室のイーサネット ポートに接続した場合、ヨーロッパまたはアジアのすべての信頼されたホストへの攻撃を防ぐのは何 でしょうか。

多層防御

多層防御とは、最もわかりやすく言うと、1 つのメカニズムに頼るのではなく階層的な手法によってコンピュータを保護することです。 階層的な防御を成功させるには、感染源と組織への攻撃のチャンスを狙っている敵対者について理解し、敵対者のターゲットになる可能性のあるものを理解することが必要です。 たとえば、競合他社が敵対者で、企業スパイを雇い、開発中の新製品やサービスに関する情報を盗もうとする場合があります。 攻撃者とその予想ターゲットを理解できたら、次に、侵害される可能性のあるコンピュータにインシデント対応手順を適用する必要があります。 この手順には、認証、承認、機密性、否認防止などがあります。 業界のベスト プラクティスである防御**-検知 - 対応 (protect-detect-react) に従う組織は、攻撃の発生は避けられないこと、攻撃をすぐに検知し、サービスの中断やデータの損失を最小限にすることが最も重要であることを理解しています。 防御 - 検知 - 対応 (protect-detect-react) を実践することにより、攻撃が発生する可能性は高いので、攻撃の発生を抑えることよりもデータや資産の保護に労力を費やすべきであることを認識できるようになります。 一般的に言えば、攻撃が発生した後にその状態を元通りに回復するよりも、攻撃を防御する方が費用対効果が高くなります。

すべての情報保証メカニズムは、人、プロセス、テクノロジに着目しています。 分離ソリューションには、この 3 つの領域すべてが組み込まれています。つまりこのソリューションは、リスク、要件、および保護が必要な資産について十分に理解し、人とプロセスの両要素にわたって理解することによって実現します。 さらに分離ソリューションでは、ネットワークとそのデバイスの現在の状態についての知識、コンピュータ相互のやり取りを規定する通信要件、およびこれらの通信要件を制限できるセキュリティ要件が必要で、これらによってセキュリティと通信の適切なバランスが達成されます。

詳細については、米国国家安全保障局 (NSA) のホワイト ペーパー「Defense in Depth」(英語) で参照できます。

このプロセスの詳細と実際の設計例は、TechNet のガイダンス「Windows Server System Reference Architecture」の「Enterprise Design」(英語) を参照してください。

次の図は、論理的分離ソリューションを、Windows Server System Reference Architecture で使用されている多層防御アプローチにどのように組み込むかを示したものです。

図 2.1: 論理的分離が組み込まれた多層防御

この図からわかる重要な点は、論理的分離によるセキュリティ層が、ネットワーク通信の制御を通じてホスト コンピュータを保護することを直接の目的としていることです。 この役割は、ホストベースのファイアウォールの役割に最も似ています。 ただし、ホストのファイアウォールがポートに許可サービスおよびブロック サービスを提供するのに対し、IPsec は許可サービスとブロック サービスを提供し、信頼されたネットワーク アクセス サービスをネゴシエートします。 アクセスが許可されると、IPsec で 2 台のコンピュータ間のすべてのパケットを保護できます。 このソリューションのコンテキストで定義されているように、サーバーおよびドメインの分離のような "論理的分離" ソリューションでは次のことは行われません。

• ルーターなどのネットワーク デバイスは保護されません。

• リモート アクセス VPN 接続の確立を許可されるコンピュータを指定するなどの、物理的ネットワーク アクセス制御を行いません。また、ネットワークベースのファイアウォールによる保護はありません。

• アクセス制御用の 802.1x、ワイヤレス リンク用の 802.11 WEP 暗号化などのネットワーク リンクを保護しません。 ただし IPsec では、発信元と宛先のインターネット プロトコル (IP) アドレス間のパスにあるすべてのネットワーク リンクで、エンドツーエンドの保護が実現されます。

• ネットワーク上のすべてのホストが保護されるのではなく、分離ソリューションに組み込まれるホストのみが保護されます。

• アプリケーション レベルのパスを保護しません。これには、電子メールおよび .NET メッセージ フローが経由するエンドツーエンドのパス、およびクライアントと Web サーバーの宛先の間で複数回プロキシ処理できる Hypertext Transmission Protocol (HTTP) 要求などが含まれます。

各層におけるセキュリティを、IT セキュリティ リスク軽減の分析の一部として考えてください。 たとえば特定のコンピュータが、論理的分離層でサーバーへのアクセスを許可されていない場合は、どのユーザーがそのコンピュータにログオンしているかは関係ありません。 どのユーザーも (管理者であっても)、そのサーバーへのアクセスは拒否されます。

SSL/TLS と IPsec の比較

IPsec は、SSL/TLS などのアプリケーション レベルのセキュリティに代わるものではありません。 IPsec を使用する利点の 1 つは、既存のアプリケーションを変更せずに、そのネットワーク トラフィックをセキュリティ保護できることです。 アプリケーションで SSL/TLS を使用している環境に IPsec を導入すると、次のような利点があります。

• 信頼されていないコンピュータやその他のデバイスからのネットワーク攻撃に対して、すべてのアプリケーションおよびオペレーティング システムを保護できる。

• SSL/TLS の使用が適切でないか規定に準拠していない場合 (たとえば、すべての eHPI データが暗号化および認証されていない場合) への備えとして、多層防御アプローチが確立される。

• ユーザー資格情報が信頼されていないコンピュータに入力されるのを防ぐ (ユーザーは、IPsec でクライアント/サーバー間の相互信頼が確立されるまでは内部の SSL/TLS Web サイトへのログオンを求められないため)。

• Windows のレジストリ設定で規制に準拠する SSL/TLS アルゴリズムを選択できない場合に、セキュリティを提供する。 Windows 2000、Windows XP、および Windows Server 2003 では、SSL/TLS アルゴリズムをレジストリ キーで制御できます。これについては、マイクロソフト サポート技術情報 245030「特定の暗号化アルゴリズムと Schannel.dll の暗号化のプロトコルの使用を制限する方法」を参照してください。

• 証明書を利用できない場合のセキュリティを提供する。

IPsec では、発信元と宛先の IP アドレスの間のトラフィックが保護されます。 SSL/TLS では、アプリケーション パス全体を通してトラフィックが保護されます (たとえば、Web ブラウザから Web プロキシを経由して Web サーバーまで)。

米国立標準技術研究所 (NIST) は、TLS の使用についてのガイダンスを作成中です。 Special Publication 800-52「Guidelines on the Selection and Use of Transport Layer Security」は、米連邦政府で TLS を実装するためのガイドラインです。 このガイダンスの詳細については、NIST Computer Security Division の Web サイト (英語) を参照してください。 IPsec の使用については、これと同様のガイドラインがありません。 ただし 米国家安全保障局 (NSA) は、Windows 2000 IPsec の使用に関しての指針を公開しています。 この指針は、NSA の Web サイト (英語) で参照できます。 NSA のガイドラインに準拠する必要がある組織は、NSA の指針に加えてこのソリューションの設計を検討する必要があります。

IPsec を証明書認証と共に使用すると、SSL/TLS と同様の保護が実現しますが、一部異なる点もあります。 TLS でサポートされ、NIST 800-52 で推奨されている暗号化アルゴリズムのうち、Windows IPsec でサポートされるのはそのごく一部です (3DES、SHA-1、1024 ビット Ephemeral Diffie-Hellman など)。 このガイドで紹介しているソリューションでは、ドメイン メンバ間の IKE 認証に、証明書ベースの署名ではなく Kerberos プロトコルの署名を使用しています。 Windows IPsec の IKE ネゴシエーションでは、Kerberos プロトコルおよび証明書ベースの認証を使用するコンピュータ間に相互信頼が確立されます。 IKE はアプリケーションに統合されないため、宛先のコンピュータ名が、アプリケーションに期待される接続先コンピュータ名と一致しているかどうかは検証できません。このため、他の信頼されたホストから高度な Man-in-the-Middle (仲介者) 攻撃を受ける可能性があります。 しかし、アプリケーションには SSL/TLS が統合されるため、宛先の名前が認証 (信頼) されるだけでなく、名前が期待された名前であるかどうかを検証できます。

ページのトップへ

用語の再確認

この章を読み進める前に、このソリューションのコンテキストでよく使用されるいくつかの用語の意味を確認することをお勧めします。 これらの用語を十分に理解している場合は、このセクションをスキップできます。 ただし、これらの用語の理解が十分でない場合は、このガイドの説明でわかりにくい部分が出てくるかもしれません。

分離に関する用語

次の用語は論理的分離の概念に固有の用語です。 この章を読み進める前に、これらの用語を十分に理解してください。

• 分離 : 1 つまたは複数のコンピュータを他のコンピュータから論理的に隔離すること。

• ドメイン分離 : この用語は、信頼されたコンピュータを信頼されていないコンピュータから隔離する分離の種類を表します。 コンピュータの分離に必要なのは、有効な資格情報を提示して IKE で正常に認証されることだけです。 このドメインとは、相互の通信のセキュリティ保護を試行する 2 台のホスト間の双方向の信頼を介してアクセスできる、信頼パス内の任意のドメインです。

• サーバー分離 : この用語は、サーバーが IPsec と [ネットワーク経由でコンピュータへアクセス] 権利を使用して、受信アクセスを信頼されたコンピュータの特定のグループに制限する方法を表します。

• 論理的分離 : 分離テクノロジを幅広く意味する用語。この用語には、ドメイン分離、サーバー分離、ネットワーク層でコンピュータを分離するネットワーク アクセス保護 (NAP) が含まれます。

• 分離グループ : 同一の通信セキュリティ ポリシーと、基本的に同一の受信/送信ネットワーク トラフィック要件を共有する、信頼されたホスト コンピュータの論理的なグループ。 分離グループの受信/送信アクセス制御を実装するには、許可/ブロック操作を行う IPsec ポリシーを単独で使用するか、または IPsec のセキュリティ ネゴシエーションをグループ ポリシーのネットワーク ログオン権利と組み合わせる (さらに他のネットワーク構成または接続設定を加える場合もある) 方法があります。 個々のアプリケーション、ネットワーク サービス、およびプロトコルは、それぞれの層でのトラフィック要件を満たす特定の構成にする必要があります。 たとえば Exchange サーバーのグループの場合、受信の TCP/IP 接続を行うクライアントまたはサーバー コンピュータは、信頼されたドメイン メンバである必要があります。 このグループからドメイン メンバ以外への送信の TCP/IP 接続は許可されないため (特定の例外があります)、このグループは Exchange Server 分離グループということになります。

• 分離ドメイン : 分離グループのメンバシップが、Windows ドメインのメンバシップと同じである場合、この分離グループを分離ドメインと言います。 ドメインに、双方向に信頼されたドメインがある場合、それらのドメインのメンバはこの分離ドメインの一部になります。 分離グループの受信/送信の要件は単純で、他の信頼されたホスト ドメイン メンバからの受信接続のみが許可されます。 サーバー分離グループに属するサーバーには、分離ドメインの一部であるクライアントがある場合があります。

• ネットワーク アクセス グループ : この用語は、ネットワーク ログオン権利に関するグループ ポリシーのセキュリティ設定を使用することによってコンピュータへのネットワーク アクセスを制御するために使用される Windows ドメインのセキュリティ グループを表わします。 これらは特に、分離グループの受信アクセス要件を適用するために作成されます。 分離グループごとに、ANAG (Allow ネットワーク アクセス グループ) と DNAG (Deny ネットワーク アクセス グループ) がある場合があります。

• 信頼 : この用語は、コンピュータが、認証プロセスによって検証された ID を受け入れることに同意しているという事実を表します。 ドメインの信頼とは、ドメインのすべてのメンバがドメイン コントローラを信頼して ID を確立し、その ID に対してグループ メンバシップ情報を適切に提供することを意味します。 信頼は、IPsec を使用してリモート コンピュータと通信するために必要です。 信頼はまた、ユーザーまたはコンピュータが、通信相手として受け入れ可能でリスクが低いとみなされることを意味します。

• 信頼できるホスト : この用語は、組織の最低限のセキュリティ要件を満たすように構成することが可能なコンピュータを表しますが、現在既に信頼されたホストである場合とそうでない場合があります。 どのコンピュータが信頼できる状態かを把握することは、信頼された分離グループのメンバシップを計画するときに重要です。

• 信頼されたホスト : この用語は、Windows 2000、Windows XP、または Windows Server 2003 を実行し、少なくとも Windows 2000 セキュリティ ドメインのメンバであり、IPsec ポリシーを実行する機能を備えたプラットフォーム コンピュータを意味します。 信頼されたホストは通常、特定の追加的な管理要件とセキュリティ要件を満たすために定義されます。 信頼されたホストの構成は、そのホストのセキュリティ リスクが低く、管理されているとみなされるように制御されます。 信頼されたホストがウイルスや悪意のある操作の発生源になる可能性はまずありません。 このトピックの詳細については、このガイドの「第 3 章 : IT インフラストラクチャの現在の状態を把握する」を参照してください。

• 信頼されていないホスト : 信頼されたホストではないホスト コンピュータ。 このコンピュータの構成は不明か、または管理されていません。 このホスト (またはこのホストのユーザー) がネットワークに接続した場合、ウイルスや悪意のある操作の発生源にならないという保証はほとんど、またはまったくありません。

• 境界ホスト : 信頼されたホストですが、信頼されたホストと信頼されていないホスト両方からのネットワーク トラフィックにさらされるため、他の信頼されたホストよりも綿密な監視と攻撃に対する強固な防御が必要です。 境界のホストは他の信頼されたホストにリスクをもたらす可能性が高いため、できるだけ数を少なくしてください。

• 適用除外 : IPsec を使用しないコンピュータ。ドメインに参加している場合としていない場合があります。 適用除外には 2 種類あります。 1 つは、静的 IP アドレスを使用するコンピュータで、そのアドレスが IPsec ポリシーの "適用除外リスト" に含まれているため、信頼されたホストはこのコンピュータとの通信に IPsec を使用しません。 もう 1 つは、セキュリティ保護された通信をネゴシエートするための IPsec ポリシーの使用の対象外になっているコンピュータです。 後者は、適用除外リストに含まれる場合と含まれない場合があります。 適用除外コンピュータは、信頼されたホストの要件を満たす場合もありますが、分離ドメイン内の他の信頼されたホストとの間で、IPsec で保護された通信を行いません。

セキュリティに関する用語

以下のセキュリティ関連の用語を十分に理解してください。

• 承認 : 個人、コンピュータ プロセス、またはデバイスに、特定の情報、サービス、または機能へのアクセスを許可するプロセス。 承認は、アクセスを要求する個人、コンピュータ、プロセス、またはデバイスの ID に基づいて行われます。ID は認証によって確認されます。

• 認証 : 個人、コンピュータ プロセス、またはデバイスの資格情報を検証するプロセス。 認証では、要求を行う個人、プロセス、またはデバイスが、身元を証明する資格情報を提示する必要があります。 一般的な資格情報の形式には、デジタル証明書の秘密キー、2 台のデバイスで管理用に構成される秘密 (事前共有キー)、ユーザーまたはコンピュータがドメインにログオンするための秘密のパスワード、または指紋や網膜スキャンなどの生体の一部があります。

• なりすまし : このガイドでは、なりすましとは、攻撃者が通信を妨害したりデータを傍受する目的で、正当な IP アドレスを偽装する行為を意味します。

• 非否認 : コンピュータに対してある操作を実行する個人が、操作を実行したことを否定できないようにするための技術。 非否認により、送金、購入の承認、メッセージの送信などの特定の操作についてユーザーまたはデバイスが行なったことを否定できない十分な証拠が得られます。

• 暗号文 : 暗号化されているデータ。 暗号文は暗号化プロセスの出力結果で、適切な解読キーを使用することによって、読み取り可能なプレーンテキストに戻すことができます。

• プレーンテキスト (またはクリアテキスト): 暗号化されていない状態の通信およびデータ。

• ハッシュ: 一方向の数学関数 (ハッシュ アルゴリズムとも言う) を任意の大きさの入力データに適用して得られる固定サイズの結果。 入力データに変更があった場合、ハッシュは変わります。 ハッシュ関数は、2 つの入力が同じハッシュ値を出力する可能性が極めて低くなるように選択されます。 ハッシュは認証やデジタル署名など多くの操作で使用できます。 メッセージ ダイジェストとも呼ばれます。

ネットワークに関する用語

以下の用語は、このソリューションのネットワークの要素を表します。

• 開始側 : 他のコンピュータとのネットワーク通信を開始するコンピュータ。

• 応答側 : ネットワークを介した通信の要求に応答するコンピュータ。

• 通信パス : 開始側と応答側の間を通過するネットワーク トラフィック用に確立される接続パス。

グループ ポリシーに関する用語

以下の用語は、Windows のグループ ポリシーに関連する用語です。

• GPO : 作成したグループ ポリシー設定は、グループ ポリシー オブジェクト (GPO) に格納されます。 選択した Active Directory システム コンテナ (サイト、ドメイン、および組織単位 (OU)) に GPO を関連付けることにより、その Active Directory コンテナ内のユーザーとコンピュータに GPO のポリシー設定を適用できます。 グループ ポリシー オブジェクト エディタを使用して個々の GPO を作成し、グループ ポリシー管理コンソールから、企業全体にわたって GPO を管理します。

• ドメイン ポリシー : Active Directory に一元的に格納されるポリシー。

• ローカル ポリシー : 個々のコンピュータに格納されるポリシー。

IPsec の基本用語

以下の IPsec の用語を十分に理解してください。

• IPSec ポリシー : ネットワーク トラフィックを IP 層で処理するためのセキュリティ規則のグループ。 セキュリティ規則には、許可、ブロック、またはネゴシエート アクションに関連付けられたパケット フィルタが含まれています。 ネゴシエーションが必要な場合、IPsec ポリシーには、ピア コンピュータとネゴシエートするための認証方法およびセキュリティ メソッドが含まれています。

• 継続 IPsec ポリシー : Windows XP および Windows Server 2003 で導入された IPsec ポリシー。IPsec ポリシー設定を継続的に適用することができます。 継続ポリシーは IPsec サービスの開始時に最初に適用されるため、ローカルまたはドメインの IPsec ポリシーよりも優先されます。

• IKE ネゴシエーション : ネットワーク接続の開始時に行われ、IPsec を使用するコンピュータがこの接続の開始を許可するかどうかを判断するプロセス。

• セキュリティ アソシエーション (SA) : 2 台のホスト間で、IPsec を使用した通信方法と、このネゴシエーションを定義するさまざまなパラメータついて行われる合意。

  • メイン モード SA : この SA は、開始側と応答側のコンピュータ間で IKE ネゴシエーションが行われるときに最初に確立されます。

  • クイック モード SA : この SA は、ホスト間の通信セッションごとにメイン モード SA が確立された後にネゴシエートされます。

• クリアテキストにフォールバック : このオプションでは、IKE の開始側が、応答側から IKE の応答を得られない場合に通常の TCP/IP トラフィック (IKE または IPsec ではない) を許可することができます。 これは、IPsec ポリシー管理ツールのフィルタ操作のプロパティ ページにある [IPSec に対応していないコンピュータとセキュリティで保護されていない通信を許可] オプションです。

• 受信パススルー : このオプションでは、IPsec 対応のコンピュータが、リモート コンピュータからの通常の TCP/IP (IKE または IPsec ではない) 受信パケットを受け入れます。 通常の上位層プロトコルの応答が送信パケットになり、この送信パケットによって IKE の開始がリモート コンピュータに戻されます。 これは、IPsec ポリシー管理ツールのフィルタ操作のプロパティ ページにある [セキュリティで保護されていない通信を受け付けるが、常に IPSec を使って応答] オプションです。

  注 : 受信パススルーを有効にしても、クリアテキストにフォールバックするオプションが応答側で有効になっていない場合、応答側は IPsec に対応していない開始側と正常に通信できません。

他にも、IPsec の要素を具体的に表す重要な用語があります。 このガイドの「付録 A: IPsec ポリシーの概念の概要」には、このような IPsec の用語の概要と、このソリューションで作成する分離グループに属するコンピュータで使用される IPsec プロセス全般の説明が記載されています。

ページのトップへ

サーバーおよびドメインの分離を実現する方法

コンピュータをリスクから分離するという考え方は、新しいものではありません。 ファイアウォールによってセグメンテーションを行う、ルーターにアクセス制御とフィルタリングを適用する、ネットワーク トラフィックを物理的にセグメント化するなどの技法はすべて、一定のレベルの分離を行うものです。

このガイドで紹介するソリューションは、ネットワーク インフラストラクチャに既に存在するデバイスや技法で動作するように設計されています。 重要な点は、Windows 2000 以降のプラットフォームに既に存在するホスト ソフトウェアに変更を加えることにより、分離を実装するという点です。 ネットワークのセグメンテーション、VLAN、境界領域のネットワーク アクセス制御、ネットワーク検疫、ネットワークベースの侵入検知などのテクノロジや手順は、ネットワーク デバイスの実装または構成変更によって実現されます。 サーバーおよびドメインの分離では、これらの既存の技法すべてを補完し、管理された Windows ドメイン メンバに新しい保護レベルを提供します。 Windows の IT 管理者は、既存の Windows 2000 または Windows Server 2003 のドメイン インフラストラクチャにサーバーおよびドメインの分離を実装できます。既存のネットワーク パスと接続方法、アプリケーションは、ほとんどまたはまったく変更する必要はありません。

サーバーおよびドメインの分離のコンポーネント

サーバーおよびドメインの分離ソリューションはいくつかの重要なコンポーネントで構成されており、これらのコンポーネントがまとまってこのソリューションを有効なものにしています。 以降では、これらのコンポーネントについて説明します。

信頼されたホスト

信頼されたホストとは、最低限のセキュリティ要件を満たすように IT 組織で管理できるコンピュータです。 多くの場合、信頼された状態は、そのコンピュータが安全で管理されたオペレーティング システム、ウイルス対策ソフトウェア、アプリケーションとオペレーティング システムの最新の更新プログラムを実行している場合のみ実現できます。 コンピュータが信頼された状態であると判断されたら、このソリューションの次のコンポーネントは、そのコンピュータの状態を認証によって確認することです。 状態の把握の詳細については、「第 3 章 : IT インフラストラクチャの現在の状態を把握する」を参照してください。

注 : IPsec 単独では、コンピュータが特定のホスト基準を満たしているかどうかを判断できません。 コンピュータの基本構成を把握し、その構成からの変更を報告するには、監視テクノロジが必要です。

ホストの認証

ホストの認証メカニズムでは、セッションを開始しようとしているコンピュータに、Kerberos チケットからの資格情報、証明書、または事前共有キーなど、有効な認証のための資格情報があるかどうかが確認されます。 現在このタイプの認証メカニズムを Windows ベースのコンピュータで実行するテクノロジは 2 つあります。 以降のセクションでは、この 2 つのテクノロジについて説明します。

802.1X プロトコル

802.1X は、ユーザーおよびデバイスを認証するための標準ベースのプロトコルです。この認証に成功したユーザーとデバイスは、802.11 ワイヤレス リンクまたは 802.3 イーサネット ポートなどのリンク層のネットワーク ポートを介した接続を承認されます。 このプロトコルによって、ユーザー エクスペリエンスの制御 (課金処理などに使用)、承認の制御、およびその他の機能が可能になります。 このプロトコルは、1 つまたは複数の専用サーバー (たとえばリモート認証ダイヤルイン ユーザー サービス (RADIUS)) と、このプロトコルをサポートするネットワーク インフラストラクチャを必要とします。 802.1X は、クライアントとワイヤレス アクセス ポイント間のワイヤレス トラフィックの 802.11 Wired Equivalent Privacy (WEP) 暗号化用のネットワーク アクセスおよび暗号化キーを制御できるように設計されています。 ネットワーク アクセスが許可されたデバイスは、通常は内部ネットワークの他の部分にも接続できるようになります。 ワイヤレス アクセス ポイントで暗号化が解除されたデータは、通常のプレーンテキストの TCP/IP 形式で送信先へ転送されます。この間、おそらくさまざまなアプリケーション層のメカニズムでセキュリティ保護されます。

Woodgrove のセキュリティでは、すべての信頼されたホストを、内部ネットワーク上の信頼されていないコンピュータから保護する必要があります。 802.1X では、信頼されたコンピュータだけにワイヤレスおよび一部の有線リンクを介したアクセスが許可されるようにできますが、内部のほとんどの 802.3 イーサネット ポートで使用されているスイッチは、802.1X 認証に対応していません。 1 つ 1 つの物理的な LAN アクセス用ウォール ポートをアップグレードし、それを世界各地のオフィスで行う場合、ハードウェアの購入およびインストールには膨大なコストが必要になります。 このため Woodgrove では、ワイヤレス セキュリティには 802.1X を使用するが、有線のイーサネット ポートには使用しないことに決定しました。

Woodgrove のもう 1 つのセキュリティ要件は、信頼されたクライアントと暗号化サーバーの間のトラフィックをエンドツーエンドで暗号化することでした。 802.1X の設計はワイヤレス接続の暗号化にのみ対応しており、有線接続の暗号化には対応していません。 ワイヤレス接続を暗号化した場合でも、ワイヤレス アクセス ポイントでパケットの暗号化が解除され、内部 LAN に転送された後はそのデータは保護されません。 結果として、802.1X ではエンドツーエンドの暗号化という要件が満たされません。

802.1X では Woodgrove のセキュリティ要件のすべてが満たされるわけではありませんが、ワイヤレス セキュリティには 802.1X が使用されます。 マイクロソフトでは、ワイヤレス ネットワークのセキュリティ保護と有線ネットワークのアクセス制御については、可能な場合には 802.1X を使用することをお勧めします。 802.1X の使用の詳細については、マイクロソフトの Web サイトの「Wi-Fi」ページを参照してください。

IPsec

IPsec は、インターネット プロトコル (IP) 用の IETF 標準セキュリティ プロトコルです。 IPsec では、一般的なポリシーベースの IP 層でのセキュリティ メカニズムが提供されます。このメカニズムは、ホスト別の認証に最適です。 IPsec ポリシーには、ホストの受信/送信 IP トラフィックのフローを制御するセキュリティ規則と設定が定義されます。 ポリシーは、ドメイン メンバへのポリシーの割り当てにグループ ポリシー オブジェクトを使用して、Active Directory で集中管理できます。 IPsec には、ホスト間にセキュリティ保護された通信を確立する機能があります。 IPsec では インターネット キー交換 (IKE) ネゴシエーション プロトコルを使用して、2 台のホスト間で IPsec を使用して安全に通信するためのオプションをネゴシエートします。 2 台のホスト間で、IPsec を使用した通信方法と、このネゴシエーションを定義するさまざまなパラメータについて行われる合意を、セキュリティ アソシエーション (SA) と言います。 IKE ネゴシエーションでは、1 つのメイン モード SA (ISAKMP SA とも呼ばれます) と、2 つのクイック モード SA (IPsec SA。1 つは受信トラフィック用、もう 1 つは送信トラフィック用) が確立されます。 IKE でメイン モード SA を確立するには相互認証が必要です。 Windows の IKE では次の 3 つの方法のいずれかを使用できます。

• Kerberos Version 5 認証プロトコル

• X.509 デジタル証明書、および対応する Rivest、Shamir、& Adleman (RSA) 公開キーと秘密キーのペア

• 事前共有キー (厳密にはパスワードではなくパスフレーズ)

IPsec を展開しない最も一般的な理由は、IPsec では公開キー基盤 (PKI) 証明書が必要で、多くの場合はその展開が難しいからというものですが、これは誤解です。 PKI が必要なくなるように、マイクロソフトでは Windows 2000 のドメイン認証 (Kerberos) を IKE ネゴシエーション プロトコルに統合しました。

Windows の IKE ネゴシエーションは、IKE ネゴシエーション要求に応答しないコンピュータとの通信が許可されるように構成できます。 この機能をクリアテキストへのフォールバックと言い、IPsec の公開では実質上不可欠です。 この機能が通常の運用において便利な点は、信頼されたホストが接続要求を開始した場合のみ、信頼されたホストと信頼されていないコンピュータやデバイスとの通信が許可されることです。 IPsec では、認証ヘッダー (AH) またはカプセル化セキュリティ ペイロード (ESP) のいずれかで保護できない通信を表すのに、ソフト セキュリティ アソシエーションという用語を使用します。 IPsec では、宛先 IP アドレスを含むセキュリティ ログの成功の監査にこのような通信を記録し、トラフィック フローのアクティビティを監視します。 トラフィック フローが一定のアイドル時間 (既定では 5 分) 経過後に停止した場合、新しく送信接続を行うときはセキュリティのネゴシエートが再度必要になります。

IPsec では、送信トラフィックのステートフル フィルタリングは、AH または ESP セキュリティ アソシエーション内のトラフィックについても、またはソフト SA でのプレーンテキストのトラフィックについてもサポートされません。 このため、ここで紹介するサーバーおよびドメインの分離の IPsec ポリシー設計を使用する場合、信頼されたホストは、信頼されていないコンピュータから開いている任意のポートへの受信接続をソフト SA を介して受信できます。 これは、攻撃に対する脆弱性の窓となる可能性があります。 しかしこの設計では、受信接続を受信するために開いているポートをネゴシエートする特定のプロトコルもサポートしています。 Windows ファイアウォールなどのホストベースのファイアウォール製品を使用すると、IPsec による保護に加えて、送信接続用のステートフル フィルタリングを追加できます。 暗号化を行わない IPsec AH または ESP によって保護されたネットワーク トラフィックは、プレーンテキスト形式とはみなされません。これにはなりすましと改変に対する認証と保護の機能があるからです。

IPsec では通常の IP パケットが安全な形式にカプセル化されるため、ネットワーク通過時のパケットの外観は、Transmission Control Protocol (TCP) パケットや User Datagram Protocol (UDP) パケットではなくなります。 Woodgrove Bank 社内に IPsec を展開する過程では、ほとんどのネットワーク管理ツールが、アプリケーションをその TCP または UDP のポート番号からすぐに特定できる (たとえばポート 25 は電子メール トラフィック用、ポート 80 は Web トラフィック用) ことを前提としていることがわかりました。 IPsec を使用する場合、トラフィックが不透明になるため、ルーターやネットワーク侵入検知システムでは、使用されているアプリケーションの区別やパケット内のデータの検査ができません。 このことはネットワーク管理上の問題になる可能性があります。トラフィックの監視、セキュリティ フィルタリング、WFQ (Weighted Fair Queuing)、およびサービスの品質 (QoS) の分類に現在使用しているツールの価値が低下することになるからです。

残念ながら、トラフィックを特定できるという前提は、完全に正確というわけではなく、IPsec を使用しない場合でも、急速に使用されなくなっています。 ポート番号とアプリケーションの対応関係も次第に弱くなってきています。 たとえば、Web サーバーを任意のポート番号で実行し、そのポート番号をそのサイトの URL に記録することが可能です。 また、代替のポート番号でメール サービスを実行することにより、一部のインターネット サービス プロバイダ (ISP) の電子メール フィルタリング作業をバイパスすることもできます。 多くのピアツーピア (P2P) アプリケーションはポート アジャイル (ポートに関して敏捷) です。つまり、このようなアプリケーションは、検出を回避するため無作為に選択したポート番号を使用します。 リモート プロシージャ コール (RPC) サービスに基づいたアプリケーションもポート アジャイルです。RPC サービスでは、さまざまなサービス用に一時的な範囲 (1024 より上) から無作為にポートを選択するからです。

今後 Web サービスの利用の増加によって、トラフィックの特定に関する問題はさらに大きくなることが見込まれます。Web サービス用のトラフィックは HTTP または HTTPS で、ポート 80 またはポート 443 を使用して実行されるからです。 クライアントとサーバーはこの HTTP URL を使用してトラフィックを特定します。 Web サービスのアーキテクチャに移行するアプリケーションはすべて、区別されない 1 つのデータ ストリームとしてルーターに認識されます。これは、これらの Web サービス用のトラフィックが 1 つまたはごく少数のポートで実行され、各アプリケーションまたはサービスがそれぞれ独自のポート番号で実行されるのではないからです。 HTTPS 接続と RPC 暗号化に SSL と TLS を使用すると、攻撃に対する防御としてのネットワークベースの検査の価値が低下します。 Woodgrove では、ネットワーク管理アプリケーションでパケットのアドレス解析が可能で、IPsec で保護されていないその他すべてのトラフィックを特定できたため、一部のネットワーク管理機能が失われても、このプロジェクトの計画に影響を与えるほどではないと決断しました。 さらに、一部のネットワーク管理ツールのベンダは、暗号化されていない IPsec パケットの内部を検査できるようにツールを修正することに同意しました。

ほとんどのホストベースのアプリケーションは、修正しなくても、IP アドレス間のすべてのトラフィックを保護する IPsec と共に動作します。 このソリューションでは IPsec を特定のアプリケーションまたはプロトコルのみに使用することはありません。これは、他のネットワーク サービスがネットワーク攻撃を受けるリスクがあるからです。 アプリケーションが IPsec と共に正しく動作しない場合、管理者は、このトラフィックを IPsec の保護の範囲外で、サーバーに使用される IP アドレスに基づいて許可することもできます。 アプリケーションを既知のポートに基づいて許可することはお勧めしません。それによって、攻撃者に対して静的な受信の入り口を開くことになり、開いている任意のポートに受信接続ができるようになるため、分離ソリューションの効果がなくなってしまうからです。 動的に割り当てられるポートを使用するアプリケーションは、IPsec の保護の範囲外では許可されません。 マルチキャストおよびブロードキャストの IP アドレス割り当てを使用するアプリケーションは、サーバーおよびドメインの分離のための IPsec 設計では動作に問題が発生する場合があります。 Windows IPSec では、すべてのマルチキャストおよびブロードキャスト トラフィックを許可する機能がサポートされていますが、特定の種類を許可する機能はサポートされていません。 アプリケーションの互換性の問題がある場合は、これを解決できる更新プログラムまたはアップグレードがリリースされるかどうか、される場合はいつかをベンダに確認してください。 このアプリケーションのアップグレードまたは互換性のあるバージョンとの交換が不可能な場合、このアプリケーションを使用する必要があるコンピュータは、分離ドメインまたは分離グループに参加できない可能性があります。

IPsec では、認証機能以外に 2 つの便利なサービスをホスト通信で利用できます。このサービスとは、アドレスの整合性の保証とネットワーク トラフィックの暗号化です。

• アドレスの整合性の保証 : IPsec では AH を使用して、パケットごとにデータとアドレスの整合性を確保できます。 Windows の AH では、Windows IPsec ドライバ内のキー付きのハッシュ メカニズムが使用されます。 AH を使用するとリプレイ攻撃が抑止され、各受信パケットが送信時から正常に受信するまでの間に変更されていないことを保証することにより、強固な整合性が実現します。 AH は、ネットワーク アドレス変換 (NAT) を実行するデバイスを経由すると正しく機能しません。NAT では IP ヘッダー内の発信元アドレスが置き換えられるため、IPsec AH が提供するセキュリティに違反することになるからです。

• ネットワーク トラフィックの暗号化 : IPsec では、データの整合性に加え、IP プロトコル用のカプセル化セキュリティ ペイロード (ESP) オプションを使用した暗号化によって、機密性も保証されます。 ESP ではアドレスの整合性は保証されませんが (AH と共に使用する場合を除く)、UDP カプセル化を使用して NAT デバイスを正常に通過させることができます。 内部ネットワークが NAT を使用するデバイスでセグメント化されている場合は、必然的に ESP を選択します。ESP ではパケットの暗号化は強制ではないからです。 Windows IPsec では、ESP と Null 暗号化 (ESP/null) の使用を定義する RFC 2410 がサポートされます。 ESP/null では、データの信頼性、整合性、およびリプレイ防御が、暗号化なしで実現されます。 Windows Server 2003 Network Monitor には、通常の TCP/IP 上位層プロトコルを公開するために暗号化されていない ESP を解析する機能があります。 ESP 暗号化を使用すると、パケットの監視は、コンピュータが IPsec ハードウェア アクセラレーション ネットワーク カードを使用してまず着信パケットを解読する場合のみ可能になります。

  注 : 暗号化 ESP または Null 暗号化を使用する ESP は、AH と同様、認証による強固な IPsec ピアリング関係を提供します。 また、リプレイを防御し、NAT デバイスを正常に経由できます。 このような理由から、Woodgrove では AH を実装せず、企業ネットワークに ESP/null と暗号化 ESP のみを使用することに決定しました。

IPsec の動作モードには、トンネル モードとトランスポート モードの 2 つがあります。

• IPsec トランスポート モード : IPsec トランスポート モードは、ホスト間のエンドツーエンドのトラフィックをセキュリティ保護する方法としてお勧めします。 IPsec ドライバは、元の IP ヘッダーの後ろに単純に IPsec ヘッダーを追加します。 元の IP ヘッダーはそのまま維持され、パケットの残りの部分は AH または ESP 暗号化処理によってセキュリティ保護されます。 IPsec フィルタは、IPsec でどのトラフィックをブロック、許可、またはカプセル化するかを制御します。 IPsec フィルタは発信元と宛先の IP アドレス (またはサブネット)、プロトコル (ICMP または TCP など)、発信元と宛先のポートを指定します。 したがってフィルタは、ある特定のコンピュータに厳密に適用することができます。または、可能なすべての宛先アドレスおよびプロトコルに適用することができます。 トランスポート モードは、[このコンピュータの IP アドレス] で設定されたフィルタを自動更新することにより、動的 IP アドレスに対応するように設計されています。このモードはオーバーヘッドが少なく、全体的に IPsec トンネル モードよりもはるかに使い方が簡単です。 したがって、IKE ネゴシエーションを行うトランスポート モードは、IPsec で保護された受信接続を承認する効果的な方法と言えます。 IPsec トランスポート モードの使用には次のような注意点があります。

  • 初期の遅延 : IKE が開始されて、ネゴシエーションが正常に完了するには、最初に 1 ～ 2 秒の遅延が必要です。 通信が中断されずに続いている間、IKE は、トラフィックを自動的に保護する暗号化キーを更新しようとします。

  • 定義済みのフィルタの優先順位 : IPsec ポリシーのフィルタは重複可能なため、最も限定的なフィルタを優先するという事前定義の優先順位があります。 これには、通信の両端で、IKE ネゴシエーション用に互換性のある IPsec トランスポート モードのフィルタ セットが必要です。 たとえばこのソリューションでは、IPsec セキュリティをネゴシエートする一般的な "すべてのトラフィック" 用フィルタと、IPsec を使用するトラフィックを保護するのではなく、ICMP トラフィックのみを許可する具体的なフィルタを組み合わせて使用しています。

  • コンピュータへの負荷 : IPsec ESP トランスポート モードの暗号化は、コンピュータに大きい負荷がかかります。 暗号化されたファイルのコピー中の CPU 使用率は、80 ～ 100% に達する場合があります。 Windows 2000、Windows XP、Windows Server 2003 には、ハードウェアでの IPsec 暗号化処理を加速化させるネットワーク カード用のインターフェイスがあります。

• IPsec トンネル モード : IPsec トンネル モードは通常、VPN ゲートウェイの静的 IP アドレス間のゲートウェイツーゲートウェイの VPN トンネルに使用されます。 このため、トンネル モードでは IPsec ヘッダーを持つ新しい IP ヘッダーが作成されます。 元の IP ヘッダーを持つ元のパケットは、完全にカプセル化されてトンネル パケットになります。 サーバーおよびドメインの分離のシナリオでは、トンネル モードを使用して、静的 IP サーバーから IPsec 対応ルーターへのトラフィックをセキュリティ保護することができます。 この方法は、宛先のホストで IPsec がサポートされていない場合に必要になることがあります。 Woodgrove のシナリオでは、トンネル モードが必要になることはありませんでした。

IPsec のトランスポート モードとトンネル モードの技術的な詳細については、「Windows Server 2003 Deployment Kit」の「Deploying Network Services」にある「Deploying IPsec」の章の「Determining Your IPSec Needs」(英語) を参照してください。

ホストの承認

ホストで受信しようとする通信が検証可能な発信元からのものであると確認されたら、ホストではその発信元コンピュータおよびユーザーにアクセスを許可するかどうかを判断する必要があります。 この手順は重要です。あるデバイスに認証の機能があっても、それは所定のホストへのアクセスも許可されているとう保証にはならないからです。

マイクロソフトが推奨するアプローチは、標準の Windows グループを使用して、設計内のコンピュータのリソースにアクセスするユーザーおよびコンピュータの機能を制限する方法です。 この方法では、アクセスされるホストのローカル ポリシーのユーザー権利の割り当てアクセス許可を使用することにより、ネットワーク レベルとアプリケーション レベルで、コンピュータ アカウントとユーザー アカウント両方の承認を行う新しい層を作成します。 [ネットワーク経由でコンピュータへアクセス] (ALLOW) と [ネットワーク経由でコンピュータへアクセスを拒否する] (DENY) の両方のユーザー権利の割り当てを使用すると、コンピュータおよびユーザーがリソースにアクセスする機能を制限できます。これは、このコンピュータおよびユーザーが共通の IPsec ポリシー パラメータを共有し、ログオンしたユーザーがリソースへのアクセス権を持っている場合も同様です。 このような強化された制御レベルが、このソリューションで説明する分離アプローチの基礎です。

Active Directory のグループ機能では、必要な承認レベルが管理しやすく拡張可能な方法でコンピュータとユーザーに割り当てられるように整理されます。 ホスト アクセス許可を得るために特に作成されたグループを、標準的な共有アクセス許可を持つグループと区別するため、このガイドではネットワーク アクセス グループという用語を使用します。

次の図は、このソリューションでのホストとユーザーの全体的な承認プロセスに含まれる主な手順を示しています。

図 2.2: ユーザーとホストの承認プロセス

図 2.2 には 5 つの手順から成るプロセスが示されています。それぞれの手順について以下で説明しますが、分離ソリューションが実装された後はすべてのネットワーク通信でこのプロセスが行われるようになります。

1. ユーザーが部門のサーバー上の共有フォルダへのアクセスを試みる : クライアント コンピュータにログオンしたユーザーが、論理的分離ソリューション内の信頼されたホスト上の共有フォルダにアクセスを試みます。 この操作により、クライアント コンピュータから信頼されたホストへの接続が、ファイル共有プロトコル (通常は、TCP 宛先ポート 445 を使用するサーバー メッセージ ブロック (SMB) プロトコル) を使用して試行されます。 クライアントにはこのソリューションの一部として IPsec ポリシーが割り当てられています。 送信 TCP 接続要求により、サーバーに対して IKE ネゴシエーションが開始されます。 クライアントの IKE はサーバーで認証されるための Kerberos チケットを受け取ります。

2. IKE メイン モードのネゴシエーション : サーバーがクライアント コンピュータから最初の IKE 通信要求を受信したら、サーバーはその Kerberos チケットを認証します。 この認証プロセス中、IKE では、グループ ポリシーに ALLOW または DENY のユーザー権利として割り当てられている必要なホスト アクセス権がそのクライアント コンピュータにあるかどうかが確認されます。 クライアント コンピュータに必要なユーザー権利が割り当てられている場合、IKE ネゴシエーションは完了し、IPsec メイン モード SA が確立されます。

3. IPsec のセキュリティ メソッドのネゴシエーション : IKE メイン モード SA のネゴシエーションが完了したら、両方のホストで受け入れられる IPsec SA のためのセキュリティ メソッドを使用して接続をネゴシエートするために、IPsec ポリシーのセキュリティ メソッドが確認されます。

   次のフローチャートは、手順 2 と 3 のすべてのプロセスを示しています。

   

   図 2.3: コンピュータのホスト アクセス許可の確認プロセス

4. ユーザーのホスト アクセス許可をユーザーに対して確認する : IPsec で保護された通信が確立されたら、SMB プロトコルはクライアントのユーザー アカウントを使用して認証します。 サーバー側では、信頼されたホスト用のグループ ポリシーに ALLOW または DENY のユーザー権利として割り当てられている必要なホスト アクセス許可がこのユーザー アカウントにあるかどうかを確認します。 次のフローチャートはこのプロセスを示しています。

   

   図 2.4: ユーザーのホスト アクセス許可の確認プロセス

   このユーザー アカウントに必要なユーザー権利が割り当てられている場合は、このプロセスは完了し、このユーザーのログオン トークンが作成されます。 このプロセスが完了したら、論理的分離ソリューションでのセキュリティ チェックは終了します。

5. 共有アクセス許可とファイル アクセス許可の確認 : 最後に、Windows の標準の共有アクセス許可とファイル アクセス許可がサーバーによって確認され、このユーザーが、要求したデータへのアクセスに必要な許可を持つグループのメンバであることが確認されます。

ネットワーク アクセス グループを使用することで、非常にレベルの高い制御をソリューションで実現できます。

次のシナリオは、論理的分離ソリューションの各手順がどのように機能するかを示す具体的な例です。

会議中、契約者が自分のモバイル コンピュータを会議室のネットワーク接続ポイントに接続し、社員の HR サーバーの共有フォルダにデータをコピーしようとします。 HR 部門所属の社員である Donna は、契約者に HR サーバーの共有フォルダへのパスを教えます。 契約者のコンピュータは不明なホストまたは信頼されていないホストなので、IT 部門ではこのコンピュータを管理していません。また、契約者のコンピュータに設定されているセキュリティ保護対策のレベルも不明です。 したがって、契約者からコピーされるファイルにはマルウェアが含まれている可能性があり、これが内部のコンピュータに感染する恐れがあります。 契約者のコンピュータが HR サーバーへの接続を試みると、前述のプロセスの手順 2 で失敗します。 契約者のモバイル コンピュータは信頼されたドメインに参加していないため、このコンピュータの資格情報の確認に必要な Kerberos チケットを提示できません。このため、IKE メイン モード SA をネゴシエートできません。 HR サーバーが属している分離グループの IPsec ポリシー要件では、HR サーバー と IPsec を使用しないホストとの通信は許可されないため、この信頼されていないコンピュータからの通信の試みはすべてブロックされます。 要約すると、論理的分離ソリューションは、信頼されていないコンピュータや管理されていないコンピュータが内部ネットワークに物理的にアクセスできる状況であっても、これらのコンピュータがもたらす脅威から IT インフラストラクチャを保護するのに役立ちます。

この例は、ホスト単位の分離を実現する方法を示しています。 このソリューションのもう 1 つの重要な要件は、管理コストを削減して分離を実現することです。 ユーザーをグループ分けするのと同じ方法でコンピュータをグループ分けし、それぞれのグループに対して、各コンピュータのローカル ポリシーの ALLOW または DENY のユーザー権利の割り当てを割り当てることができます。 ただしこの方法は管理が難しく、拡張も容易ではありません。適切な管理と拡張には、グループ ポリシーおよび Active Directory の集中管理機能と、必要な通信パスについての十分な理解が必要です。 さらに、この方法単独では強固な認証やデータ暗号化機能は提供されません。 このようなホスト アクセス許可が IPsec と組み合わされ、ホストが分離グループ別に分けられていると、各グループ間の関係が理解しやすくなり、(要件を明確に文書化した後) 通信パスの定義が簡単になります 。 分離グループの設計とフレームワークの詳細については、「第 4 章 : 分離グループを設計および計画する」を参照してください。

ページのトップへ

サーバーおよびドメインの分離で防御される脅威

サーバーおよびドメインの分離により、コンピュータ相互の通信方法、および通信を開始しようとするデバイスとの間の通信方法に制限が設定されます。 この制限または境界を使用して、デバイスが信頼された状態とみなされるレベルを表すことにより、通信を制限できます。 IPsec ポリシーを使用して、認証、承認、ネットワーク ロケーションなどの境界をホストの周囲に設定することは、多くの脅威を軽減する効果的な方法です。 IPsec は完璧なセキュリティ戦略ではありませんが、IPsec によって全体的なセキュリティ戦略に防御層が追加されます。

次のセクションでは、一般的な脅威のいくつかを解説し、脅威モデルの作成について簡単に説明します。 Woodgrove Bank のシナリオにおける信頼されたデバイスの詳細と、コンピュータを信頼できる状態として特定し分類するために Woodgrove で使用した設計プロセスの詳細については、「第 3 章 : IT インフラストラクチャの現在の状態を把握する」の「信頼の決定」を参照してください。

脅威モデルを作成し、分類する

近年、ネットワークベースのアプリケーションおよびサーバーへの攻撃の頻度が著しく上昇し、複雑さも増しています。 興味深いことに、攻撃の種類や形式、また攻撃への基本的な対抗措置は、いずれも比較的変化のない状態にとどまっています。 しかし、このような防御策を実装する一部の機能や方式はそうではありません。 サーバーおよびドメインの分離ソリューションで必要な計画を理解する前に、現在存在する脅威の詳細なリスク分析と、さまざまなテクノロジやプロセスを使用してこれらの脅威に対抗する方法の調査を組織内で行う必要があります。

組織にとっての脅威を特定、分類し、一覧にするプロセスは、数年にわたって文書化されてきました。 このような文書では多くの場合、組織にとって一般的なビジネス上、環境上、および技術上の脅威のモデル作成に利用できる方法論が示されています。 マイクロソフトでは、脅威モデルの作成に STRIDE の手法を使用しています。 STRIDE は、防御すべき脅威の各分類の頭文字を意味します。 この分類は次のとおりです。

S    なりすまし (spoofing)

T    改ざん (tampering)

R    否認 (repudiation)

I    情報の漏えい (information disclosure)

D    サービス拒否 (denial-of-service)

E    特権の昇格 (elevation-of-privilege)

保護が必要なすべての資産を確実に保護するために、十分な時間とリソースを費やして、可能な限り詳細な脅威モデルを定義することが不可欠です。 サーバーおよびドメインの分離で軽減される特定の脅威や攻撃の詳細については、このガイドの「付録 D: IT の脅威の分類」を参照してください。 脅威モデルの詳細については、「マイクロソフトの Securing Windows 2000 Server ソリューション」の「第 2 章 セキュリティの概要を定義する」を参照してください。このソリューションは、 https://www.microsoft.com/japan/technet/security/prodtech/windows2000/secwin2k/default.mspx からダウンロードできます。

ページのトップへ

サーバーおよびドメインの分離を展開する方法

組織にとっての脅威と、その脅威をソリューションで軽減する方法を理解したら、次は、このソリューションを展開する方法を検証します。 ここでは、この展開プロセスの実行方法を説明します。

情報収集

設計プロセスの開始に先立つ一番最初の手順は、ワークステーションおよびサーバーの構成や通信パスも含め、組織のネットワークの現在の状態を表わす最新の正確な構成図があるかどうかを確認することです。 このソリューションによって何を防御するのかを明確に把握していなければ、効果的な論理的分離ソリューションを開発することはできません。

「第 3 章 : IT インフラストラクチャの現在の状態を把握する」では、組織のネットワークおよびネットワーク上のデバイスの現在の状態について行う情報収集の詳細と根拠を説明します。 このプロセスでは、このソリューションの以降の章で必要な情報をすべて収集します。また、組織内で行われる他のプロジェクトの評価も行います。 最も重要なのは、このプロセスによって、組織の情報システムに必要な通信パスを詳細に分析して吟味できることと、リスク、通信要件、ビジネス要件の間に存在する可能性のある妥協点について情報に基づいた選択ができることです。

IPsec 展開プロセスの概要

設計を決定し作成したら、次は、その設計を管理しやすくユーザーへの影響を最小限に抑えられる方法で組織に実装するためのプロセスを確立します。 「第 4 章 : 分離グループを設計および計画する」では、このためのいくつかの異なるアプローチについて詳しく説明します。 ただし基本的なプロセスは、次のように要約できます。

1. 設計と IPsec ポリシーを機能検証のためのラボでテストする : 提案された IPsec ポリシーを、分離されたテスト用の環境でテストしてください。このテストによって、設計が予測どおりに機能することを確認し、ポリシー設定または展開メカニズムで発生する可能性のあるすべての問題をテストします。

2. テストされ、承認された設計をパイロット運用する : 設計がラボ環境で予測どおりに機能することが確信できたら、次は、このソリューションを運用環境に展開するためのパイロット展開に組み込む限定数のコンピュータを特定します。 特定されたコンピュータおよびユーザーには予防的なサポートを実施し、テスト中に発生する問題がユーザーの職務の遂行に与える影響が最小限になるようにします。

3. ソリューションの段階的な公開を実装する : このプロセスの最後の手順は、この設計を組織の残りの部分に展開するための計画を作成することです。 これは簡単ではありません。 この計画作成の手順には非常に注意が必要です。 IPsec ポリシーのたった 1 つの設定変更で、多くのコンピュータがネットワーク リソースにアクセスできなくなるような設計になる可能性があります。 展開計画をテストして整理することにより、構成または設計のミスが何らかの理由でテスト段階で検出されなかった場合に前の正常な状態にすぐ戻せるような方法で、このソリューションで導入される変更を実装できるようにします。

「第 4 章 : 分離グループを設計および計画する」では分離ドメインの設計プロセスについて詳しく説明し、このソリューションの段階的な公開のアプローチのオプションを紹介します。  

ページのトップへ

要約

この章では、このガイドで説明しているソリューションの背景にある目標とプロセスについて説明しました。 IT の専門家は何年も前から IPsec の利点をよく理解していましたが、このテクノロジの特質の複雑さから、多くの人が実装を敬遠してきました。 IPsec の実装では、ソリューションに堅固な設計、よく計画された展開、信頼できるテスト方法がない場合、重大な結果を招く可能性があります。

この章では、論理的分離とはサーバーおよびドメインの分離の手法を Windows プラットフォームの機能、IPsec、グループ ポリシー、Active Directory と共に使用する追加のセキュリティ層であり、これによって、データ資産にもたらされるリスクを最小限にする、管理しやすく拡張可能なエンタープライズ ソリューションを実現できることを説明しました。

以降の章では、このソリューションの計画と実装に必要な各段階に焦点を当てて説明します。 「第 6 章 : サーバーおよびドメインの分離環境を管理する」では、サーバーおよびドメインの分離を使用する運用環境の毎日の実行に実装できる手順について説明しています。 「第 7 章 : IPsec のトラブルシューティング」には、サポート情報とトラブルシューティングに関する情報が記載されています。

ページのトップへ