ドメインの分離によるセキュリティ強化
Microsoft IT での IP セキュリティ (IPsec) の実装
トピック
 | 要約 |
| はじめに |
| ビジネス上の利点 |
| Microsoft でのドメインの分離 |
| 計画 |
| 展開 |
| 既知の問題と問題の該当箇所 |
| ベスト プラクティス |
| まとめ |
| 詳細情報 |
要約
Microsoft Information Technology グループ (以下 Microsoft IT) は、Microsoft の Embody Trustworthy Computing (『信頼できるコンピューティング』の具体化) の取り組みの一環として、Microsoft のグローバル エンタープライズ ネットワークにドメイン分離を導入しています。ドメインを分離する目的は、信頼されている資産への (社内外からの) 不正なアクセスを防ぐことです。分離を実現するためのテクノロジには、インターネット プロトコル セキュリティ (IPSec) を採用しました。この取り組みの結果、セキュリティで保護された信頼されたコンピュータからなるネットワークを分離できます。このネットワークを Microsoft では "SecureNet" と呼んでいます。
このホワイト ペーパーでは、Microsoft IT により実施された SecureNet (Microsoft 自体のセキュリティで保護されたネットワーク) を構築するための計画と IPsec の展開について説明します。このホワイト ペーパーでは、次のトピックについて記載します。
| • | IPsec の技術概要 : 信頼されるネットワーク セグメントを構築するために採用したテクノロジの背景情報。また、このプロジェクトでの採用が検討されたその他のテクノロジと、IPsec を選択した理由について詳しく説明します。 |
| • | Microsoft のセキュリティ環境 : 展開方法に影響を与える、社内ネットワークの課題と考慮事項。 |
| • | 計画 : ネットワーク全体に IPsec を展開するための計画策定時の手順。 |
| • | グループポリシーを使用した IPsec の配布 : IPsec の展開に使用したグループ ポリシー オブジェクトの具体的なアーキテクチャ。 |
| • | Microsoft IT の IPsec ポリシー設定とフィルタデザイン : SecureNet 内のホストに展開するフィルタ、フィルタ リスト、ルール、およびポリシーの説明。Microsoft IT では、IPsec を使用できないコンピュータや現在管理されていないコンピュータにどのように対処したかも説明します。 |
| • | 既知の問題とベストプラクティス : IPsec を社内全体に計画および展開中に発生した問題点と、その過程で得た教訓。 |
このホワイト ペーパーは、社内ドメインの分離に IPsec を導入するプロセスと実装方法についてより深い理解を望む、企業の技術的意思決定者、IT インプリメンタ、およびアーキテクトを対象としています。修正プログラム管理、セキュリティ状態の管理、ネットワーク境界における防御など、他の取り組みについての詳細は取り上げていません。このような取り組みについては、www.microsoft.com/japan/technet/itsolutions/msit/ で公開されているその他のホワイト ペーパーを参照してください。
このホワイト ペーパーに記載されているテクノロジは、Microsoft® Windows Server™ 2003 を対象としています。ただし、これらのテクノロジの大半は、Microsoft Windows® 2000 Server を基盤としたインフラストラクチャが利用されていた頃に開発されたものであり、Windows 2000 Server SP 3 および Windows XP にも実装可能です。すべてのテクノロジと展開は、進化するセキュリティ要件、将来の戦略計画、および製品テストと検証の要件に対応するため、現在も発展を続けています。
このホワイト ペーパーは、早期の導入を図った Microsoft IT の経験および提案に基づいて記述されており、手順ガイドとして書かれたものではありません。エンタープライズ環境には、それぞれ固有の状況があります。したがって、このホワイト ペーパーで説明している計画や実例は、各企業の要件に合わせて調整する必要があります。
注 : セキュリティ上の理由から、このホワイトペーパーに記載されているフォレスト、ドメイン、内部リソース、および組織、および社内で開発されたセキュリティファイルの名前は、Microsoft で実際に使用されている名前ではなく、あくまで説明のためのサンプルです。
はじめに
Microsoft IT は、Microsoft の Embody Trustworthy Computing (『信頼できるコンピューティング』の具体化) の取り組みの一環として、Microsoft の社内ネットワークにドメインの分離を導入しています。ドメインを分離する目的は、社内ネットワーク上の信頼されている資産への信頼されていないデバイスからのアクセスを防ぐことです。
これまで、Microsoft は、きわめてオープンな社内ネットワークを運用してきました。このことは、会社のファイアウォール内のコンピュータは安全であると考えられていたために、問題視されていませんでした。Microsoft IT では、Systems Management Server (SMS)、グループ ポリシー、他のドメイン管理ツールを使用して、自社のネットワーク内のデスクトップ コンピュータの約 50% を管理していましたが、依然として管理ドメインに参加していないコンピュータがファイアウォール内の資産に接続し、そのリソースにアクセスできる状態でした。このような管理されていない (管理ドメインに参加していない) コンピュータは、セキュリティ状態のかなりの部分が不明なので、基本的に信頼できません。
社内ネットワークやインターネットが成熟するにつれ、このような信頼できないコンピュータが自社に与えるリスクについて、Microsoft IT の認識が高まってきました。管理ドメインに参加していないコンピュータが社内ネットワークに接続できると、社内ネットワークに対する攻撃の足がかりを攻撃者に比較的容易に与えてしまうことになります。そこで Microsoft IT では、IPsec を使用して、会社のファイアウォール内にある Microsoft IT が管理している信頼されたコンピュータを分離し、セキュリティを向上することで、社内ネットワークのセキュリティを強化することにしました。
信頼されている資産のレベル
Microsoft では、信頼されている資産に対してレベルを設けており、レベルごとに異なるセキュリティ ポリシーを必要とします。基本レベルでは、Microsoft IT が管理するコンピュータは、ドメイン、オペレーティング システム、グループ、IPsec の各ポリシーの条件を満たしています。これらの条件を満たすコンピュータでドメインに参加しているものは、"信頼されている" コンピュータであると見なされます。ドメインに参加していないコンピュータや、ドメインに参加していても有効なセキュリティ構成が設定されていないコンピュータなど、上記の要件を満たさないコンピュータは、"信頼されていない" コンピュータであるとされます。
図 1 は、IPsec を使用して論理的に分離された後の社内ネットワーク全体のアーキテクチャを示しています。
図 1. Microsoft の社内ネットワーク内のドメインの分離
IT 資産によっては、さらに厳格なセキュリティ ポリシーが必要なものがあります。たとえば、Microsoft の中核的な知的財産である同社ソフトウェアのソース コードを保管する中央のリポジトリは、厳重に保護される必要があります。また、機密性の高い人事データや会計システム データも、特別な保護が必要です。
分離に用いたテクノロジ : IP セキュリティ (IPsec)
IP セキュリティは、安全な通信を実現するための IP プロトコルのセットです。Microsoft の社内ネットワーク内でのピアツーピアのコンピュータ通信には、IPsec カプセル化セキュリティ ペイロード (ESP) プロトコルとインターネット鍵交換 (IKE) プロトコルを組み合わせて使用し、認証された通信を実現しています。IPsec ポリシーとフィルタの配布には、グループ ポリシーを使用しています。また、ドメイン コントローラや機密リソースに対する [ネットワーク経由でコンピュータへアクセス] を使ったユーザーのアクセス許可の設定により、認証されたユーザーやコンピュータの承認を可能にします。Microsoft で展開されているサーバーのうち、IPsec の暗号化機能を使用しているものはごく一部です。基本的に認証には、IPsec を使用しています。このような非暗号化構成における ESP の使用は、ESP-Null と呼ばれます。
IPsec は通常、ゲートウェイ間での暗号化されたアクセスを提供し、仮想プライベート ネットワーク (VPN) を実現するトンネリング プロトコルの一種と考えられています。Microsoft IT は、トランスポート モードで IPsec を使用することにしました。このモードでは、トンネル経由でトラフィックをルーティングするのではなく、ホストどうしを直接接続します。Microsoft では、主に IPsec を使用してホストどうしの認証を行っているので、トンネルを確立する必要がありません。
IPsec により分離された社内ネットワーク内のデバイスのサブセットとしての SecureNet
IPsec を使用することで、信頼されたホストと信頼されていないホストを論理的に分離した状態で、同じ物理ネットワークとアドレス空間上でのこれらのホストの接続を可能にします。信頼されているホストは、IPsec の展開以前にこのホストからアクセス可能であったリソースすべてにアクセスできます。社内ネットワーク内の信頼されているホストすべてからなるグループが、SecureNet です。
Microsoft IT の管理ドメインに適切に参加していないホストは信頼されず、明示的に許可されているものを除きどのリソースにもアクセスできません。信頼されていないホストは、信頼されているホストにアクセスできませんが、"境界" コンピュータとして特別に設けられたコンピュータにはアクセスできます。Microsoft IT は、信頼されていないコンピュータからの限られたアクセスを許可するポリシーを設定した特殊な境界ホストを配置しています。
ビジネス上の利点
社内ドメインを分離することで Microsoft IT が得られる主な利点は以下のとおりです。
ネットワーク リスクの削減
そもそもドメインを分離する第 1 の目的は、Microsoft IT が管理しているコンピュータと管理していないコンピュータをネットワーク レベルで分離することで、リスクを緩和することでした。
Microsoft 社内の多くのコンピュータが、Microsoft IT により管理されていません。これには、Apple Macintosh、Unix、Xbox、Pocket PC など、Windows 以外のコンピュータも含まれます。テスト コンピュータおよびゲストやベンダが所有するコンピュータも、Microsoft IT の管理対象外です。上記のプラットフォームや Windows コンピュータ間でも IPsec は使用できますが、これらのコンピュータについては Microsoft IT が管理していないため、これらを大多数のドメインを使って管理されているコンピュータから分離することで、ネットワーク全体に影響する一般的なネットワーク脅威のリスクを軽減しています。
このような脅威には、バッファ オーバーフロー攻撃、脆弱性や構成ミスの悪用、データの不整合、コンピュータへの不正なアクセスなどがあります。これらは、ハッカー、ワーム、ウィルスのほか、スパイウェアなどの悪意のあるソフトウェアによりもたらされます。どのようなネットワーク コンピュータでも、大切なデータが保管されていたり、データへのアクセス経路として使用されたりする可能性があります。
管理されていないコンピュータが信頼されている資産に接続できないようにすることで、これらの信頼されているコンピュータのセキュリティを強化しています。
より優れた資産管理情報
ドメイン分離の 2 つ目の利点は、どのコンピュータがドメインにより管理されていて、どのコンピュータが管理されていないかを把握できることです。管理されていないコンピュータについては、これらのコンピュータを管理しないことに対するビジネス ニーズを深く分析することができました。この分析を基に、ビジネス ニーズに合わせて、セキュリティ ポリシーを見直すことができます。
たとえば、Office for Mac 製品開発グループは、製品開発に Apple Macintosh コンピュータを使用する必要があります。これらの Apple コンピュータはファイル サーバーにアクセスする必要がありますが、IPsec を展開すると、このアクセスは阻止されてしまいます。Microsoft IT は、特定のファイル サーバー用に特別な例外ポリシーを作成することで、このサーバーへのファイル共有アクセスを可能にしました。このサーバーは Microsoft IT の管理下にありますが、管理対象外のコンピュータがこのサーバーを使用するという知識を踏まえ、更新した IPsec ポリシーを使用して必要に応じて SecureNet 外部のデバイスからのアクセスを遮断することができます。
また IPsec を社内ネットワーク全体に展開することで、管理対象外のコンピュータが存在するすべての状況と、これらが社内ネットワーク内で使用されている理由について適切な理解が得られました。安全な展開、小規模なサブネット、およびテスト ドメインをテストすることで、IPsec ポリシーの例外が必要になるほとんどの状況を洗い出し、分類できました。IPsec の展開は内部的に行われ、問題があるユーザーはヘルプ デスクに連絡するように指示しました。ヘルプ デスクのスタッフは、IPsec 関連の問題の解決にあたり、その過程で予測できなかった IPsec と既存のシステムが競合する場面をさらに特定することができました。これらの問題を収集して IPsec の展開チームに渡し、展開チームが解決策や対処方法を考案しました。
プロジェクトの最初に社内ネットワークをスキャンし、ネットワーク上に約 300,000 の認証されていない IP アドレスがあることがわかりました。本資料の執筆時点では、約 208,000 の IP アドレスは、管理ドメインに参加している Windows コンピュータが使用しています。このうちの約 2.5% は、信頼されていないコンピュータからのアクセスを許可するため、IPsec ポリシーの例外となる "境界" コンピュータに当たります。
境界コンピュータは SecureNet デバイスと信頼されていないホストの両方と通信できるため、攻撃対象となるリスクが高いコンピュータです。しかし、Microsoft IT では、これらのコンピュータの場所を把握しているため、必要に応じて SecureNet 外部のデバイスからのアクセスをすばやく切断できます。これらの境界コンピュータについては、「非 IPsec 通信のサポート」で詳しく説明します。IPsec 展開プロセスの将来の段階では、これらの境界コンピュータのセキュリティ強化を行う予定です。
残りの 95,000 台のコンピュータは、製品開発やテスト、顧客サポートなどさまざまな理由から管理対象外とされています。Microsoft IT では、現在、このようなコンピュータのドメインによる管理を妨げている問題を解決したり、必要に応じて境界コンピュータのセキュリティを強化するなどして、信頼されていないコンピュータ数の削減に務めています。
|
知的財産の保護
一部の IT 資産には、さらに厳格なセキュリティ ポリシーが必要です。たとえば、Microsoft の中核的な知的財産である同社ソフトウェアのソース コードを保管する中央のリポジトリは、厳重に保護される必要があります。また、機密性の高い人事データや会計システム データも、特別な保護が必要です。このようなデータを保持しているサーバーには、確実に Microsoft 社内の適切なグループ メンバしかアクセスできないようにする必要があります。グループ ポリシーを使用してアクセスを制限することもできますが、このような制限をドメインに参加していないコンピュータに適用することは困難です。IPsec を展開する前は、認証済みユーザーが管理されていないコンピュータからこれらの制限付きのサーバーにログインすることができました。IPsec 導入後は、ユーザー アカウントに加えてコンピュータ アカウントも検証されるようになり、管理されていないコンピュータからのアクセスを完全に阻止できるようになりました。
IPsec を使用すると、ドメイン ポリシーを適用できます。IPsec を用いた SecureNet の取り組みにより、Microsoft の重要な知的財産の保護を強化し、特定のユーザーおよびネットワーク ホストにしかアクセスを許可しないような制御が可能になりました。
ポリシー準拠率の向上
Microsoft の社内ネットワークへの IPsec の展開によりもたらされた思わぬ利点として、管理ドメインに参加しているコンピュータの割合が大幅に増加しました。ドメインに参加していないコンピュータはドメイン リソースにアクセスできないので、社員は使用しているコンピュータをドメインに以前よりも積極的に参加させるようになりました。IPsec を展開してドメインの分離を実施するようになってから、ドメインに参加しているコンピュータ数は 30% も増加しました。
このような後から追加されたコンピュータに、ポリシーを適用したり、SMS やグループ ポリシーをはじめとするドメイン管理ツールを使用して管理できるようになったので、環境のセキュリティと管理性が向上しました。
マルウェア検出能力の向上
スパイウェア アプリケーションの多くは、コア ネットワーク "スタック" コンポーネント (LSP: Layered Service Provider) を置き換えて、コンピュータを脆弱にします。IPsec は完全な "ネットワーク スタック" がなければ機能しないため、悪意のあるソフトウェアによる影響をより容易に発見できます。IPsec を展開することで、このようなアプリケーションを検出できます。
IPsec を社内ネットワーク全体に展開することで、このような不要なアプリケーションを削除しやすくなりました。
Microsoft でのドメインの分離
IPsec を使用すると、ネットワーク内部にセキュリティで保護された論理サブネットワークを作成できます。Microsoft IT では、グループ ポリシーを用いて、管理ドメイン全体に IPsec ポリシーとフィルタを展開しました。IPsec により、ネットワーク上の個々のホスト間のトラフィックが認証されます (IPsec を使ってトラフィックを暗号化することもできますが、Microsoft の IPsec 展開では、数台のサーバーにしか暗号化を使用していません)。同ネットワーク内の SecureNet は、Microsoft の社内ドメインにあり、同じ IPsec ポリシーを使用するすべてのホストで構成されています。
グループ ポリシーは、IPsec を管理ドメイン上のすべてのホストへの展開を容易にするためのフレームワークを提供します。管理者はグループ ポリシーを使用して、Active Directory® ディレクトリ サービスの任意のサイト、ドメイン、および組織単位 (OU) 全体に適用されるポリシーを設定できます。グループ ポリシーは、Microsoft Windows 2000 Server、Microsoft Windows 2000 Professional、Microsoft Windows® XP Professional、および Windows Server 2003 を実行するコンピュータで使用できます。
この Active Directory インフラストラクチャとグループ ポリシーさえあれば、全社規模で IPsec を展開および管理できます。Microsoft では、Active Directory とグループ ポリシーが既に全社に展開されていたので、IPsec の展開に際してソフトウェアを追加で配布する必要はありませんでした。ポリシー ベースの管理を使用すると、次の操作が可能です。
| • | 全社規模でのユーザーとコンピュータの一対多の管理。 |
| • | IT ポリシー適用の自動化。 |
| • | システムの更新やアプリケーションのインストールなどの管理タスクの簡素化。 |
| • | 全社で一貫性の保たれたセキュリティ設定の実装。 |
| • | 複数のユーザーを対象とした標準のコンピューティング環境の効率的な実装。 |
グループ ポリシーを使用して、セキュリティやネットワークなどのポリシー以外に、コンピュータ レベルで適用されるユーザー関連ポリシーを定義することもできます。また、ユーザーのデスクトップ コンピュータだけでなく、ドメイン コントローラやメンバ サーバーの管理にも、ドメイン ポリシーを使用できます。
注 : グループ ポリシーの詳細については、「Windows Server 2003 のグループ ポリシーの紹介」(www.microsoft.com/japan/windowsserver2003/techinfo/overview/gpintro.mspx) を参照してください。
ドメイン分離テクノロジの選択
ネットワークをセグメント化してセキュリティで保護するには、いくつか方法があります。Microsoft IT では、次の 2 つの主要なテクノロジを検討しました。
| • | IPsec |
| • | 802.1x |
この 2 つのテクノロジの利点はきわめて異なり、それぞれが適用する条件も異なります。
IPsec
IPsec を使用すると、同一ネットワーク上のホスト間のエンドツーエンドの認証および (必要に応じて) 暗号化を実現できます。最大の利点の 1 つは、管理のすべてが個々のホストではなく、ネットワークの境界で行われることです。ホストとネットワーク自体をつなぐ機器は、本質的に意識されなくなります。以前は、古いネットワーク アドレス変換 (NAT) 機器で IPsec を使用する場合は問題が発生していましたが、これらの問題は Windows 2000 SP3、Windows XP SP2、Windows Server 2003 以降で IPsec に追加された Network Address Translation-Traversal (NAT-T) サポートにより解決されています。
IPsec は Corporate Security が規定した次のドメイン分離要件を満たしていました。
| • | エンドツーエンド認証 : ホスト間のルーター、ハブ、およびネットワークの種類にかかわりなく、エンドツーエンドでトラフィックが認証されます。 |
| • | パケットの整合性 : すべてのパケットが、送信中に変更されていないことが確認されます。 |
| • | 必要に応じて暗号化可能 : 機密データを含むホスト間の通信では、暗号化を有効にし、データの機密性を確保できます。 |
| • | 全社規模のスケーラブルなセグメント化 : グループ ポリシーを使用して IPsec ポリシーを個々のホストに展開するので、IPsec を全社に容易に拡張できます。 |
| • | Windows インフラストラクチャの使用 : IPsec サポートは Windows 2000 以降に組み込まれており、グループ ポリシー、Active Directory およびドメイン管理ツールを使用して容易に展開および管理できます。IPsec は認証に Kerberos (必要に応じて証明書) を使用するため、Microsoft IT が既に導入していたドメイン管理インフラストラクチャを使用できます。 |
| • | ハードウェアのアップグレードが不要 : IPsec は "特別な構成なしに" 使用できます。Microsoft の環境に IPsec を展開した際に、追加のハードウェアやネットワーク投資は必要ありませんでした。 |
トラフィックを暗号化すると、プロセッサのオーバーヘッドがかなり発生するため、アクセス頻度の高いサーバーでは、暗号化アクセラレータ ハードウェアを追加する必要がある場合があります。
Microsoft ではプロキシ サーバーへの同時接続数が多いので、これらのサーバーに IPsec オフロード カードを実装しました。その結果、ある程度のパフォーマンスの改善が見られています。
802.1x
ネットワークをセグメント化するもう 1 つの方法としては、802.1x、証明書および公開キー基盤 (PKI) を使用してネットワーク上のデバイスとユーザーを管理する方法があります。IPsec とは対照的に、802.1x はホストではなくネットワーク指向の構成が必要になります。各ネットワーク ホスト、スイッチ、ルーター、またはデバイスが 802.1x をサポートしている必要があり、デバイスごとに個別の認証を行うことでネットワーク ポリシーを適用します。
Microsoft IT では、ワイヤレス アクセス ポイントの保護とその他のある特定の目的に 802.1x を使用しています。以下の理由から、社内ネットワーク全体のセグメント化には、802.1x は採用しませんでした。
| • | ハードウェア投資が必要 : すべてのネットワーク機器が 802.1x をサポートする必要があるので、一部の古いハブやスイッチは交換またはアップグレードが必要です。 |
| • | 必要なレベルでの制御が不可能 : Microsoft では、複数のコンピュータをネットワークに接続するため、従業員の多くがネットワーク ポートにハブをつなげています。802.1x ではこのような場合の管理を柔軟に行えません。あるハブに接続しているコンピュータすべてを信頼するか、信頼しないかというレベルでしか制御できません。 |
| • | サブセグメントサポートが不十分 : 本資料の執筆時点では、802.1x のような証明書ベースのインフラストラクチャでは、ドメイン内でさらに細かくグループを分離する標準的な方法が確立されていません。証明書が有効かどうかの判断は、指定された証明機関 (CA) が署名しているかどうか、証明書失効リスト (CRL) に登録されていないかどうかだけで行われます。Kerberos 認証と Active Directory を使用する場合は、ドメイン内のコンピュータの一部をまとめて、セキュリティ グループとして設定でき、独自に管理できます。 |
| • | データ整合性がサポートされない : 802.1x は、直接接続されているデバイス間の接続しか認証しません。データの整合性は保証されません。 |
| • | 暗号化がサポートされない : IPsec を含め、いくつかの暗号化テクノロジは認証に 802.1x を使用していますが、802.1x (自体) にはデータ暗号化機能がありません。 |
多くの場合、802.1x によるハードウェアとユーザーの認証は有効です。ただし、802.1x により提供される機能は認証のみです。IPsec を採用した理由は、これが完全なソリューションであるためです。
IPsec の概要
Internet Engineering Task Force (IETF) によりインターネット プロトコル (IP) のセキュリティ アーキテクチャとしてデザインされた IPsec は、IP パケットの形式および関連するインフラストラクチャを規定するもので、ネットワーク トラフィックのエンドツーエンドの強力な認証、整合性、再送攻撃に対する耐性 (anti-replay)、および必要に応じて機密性機能を提供します。IPsec の一部であるインターネット鍵交換 (IKE) では、要求時のセキュリティ ネゴシエーションと自動鍵管理サービスを規定しています。Windows Server 2003 オペレーティング システムは、堅牢な IP セキュリティ (IPsec) 実装である Windows 2003 IP セキュリティにより、ネットワーク セキュリティの展開と管理を簡素化しています。
セキュリティ プロトコルと暗号化サービスの標準ベースのフレームワーク
IPsec は、インターネット プロトコル (IP) パケット用のセキュリティ プロトコルと暗号化サービスのフレームワークです。IPsec は、ルールを使用して基本のパケット フィルタを定義します。ルールは、フィルタ リストとアクションを関連付けるものです。各フィルタでは、接続の両端のエンド ポイントを指定し、一致する IP、ポート、プロトコルまたはサブネットを特定します。アクションには次のようなものがあります。
| • | 許可 : IPsec による認証または暗号化を行わずに、フィルタ リストに指定されているホスト、ポート、プロトコル、サブネット間のトラフィックを許可します。 |
| • | ブロック : フィルタの記述に一致するパケットをすべて破棄します。 |
| • | セキュリティのネゴシエート : Kerberos またはデジタル証明書による認証、データ整合性、および必要に応じて暗号化を組み合わせて、ホスト間のセキュリティをネゴシエートします。 |
安全な環境自体ではなく、安全な環境の基盤としての IPsec
IPsec を使用してドメインを分離することで、攻撃者が保護されたコンピュータにアクセスするリスクを大幅に削減できます。また、IPsec を使用することで、ネットワークやシステム環境の理解が深まり、将来の展開に向けて基礎を築くことができます。
IPsec は、ローカル ポリシーまたはドメイン ベースのグループ ポリシーとして展開できます。ローカル ポリシーは、Microsoft 管理コンソール (MMC) スナップイン、または netsh.exe (Windows Server 2003)、ipseccmd.exe (Windows XP)、ipsecpol.exe (Windows 2000) などのコマンド ライン ツールを使用して展開できます。Microsoft IT によるグローバル展開では、ほぼドメイン ベースのグループ ポリシーのみを使用しています。
IPsec の 4 つのネゴシエート セキュリティ モデルのうち、Microsoft IT は 2 つを使用
Windows IPsec は、次のような 4 種類のネゴシエート セキュリティをサポートしています。
| • | 既定の応答 : ホストは IPsec 要求に応答しますが、IPsec を開始することはありません。 |
| • | 要求モード : ホストは、IPsec 要求と認証されていない (非 IPsec) 要求に応答します。IPsec による通信を開始し、これが失敗した場合、認証されていない通信を許可します。Microsoft では IPsec 展開プロセスの第 1 段階で要求モードを使用しました。 |
| • | セキュア要求モード : ホストは IPsec により保護された要求に応答します。認証されていない要求は無視します。IPsec による通信を開始し、これが失敗した場合、認証されていない通信を開始します。Microsoft では、SecureNet のほとんどのコンピュータでセキュア要求モードを使用しています。 |
| • | 完全要求モード : ホストは、受信要求と送信要求の両方に IPsec で保護された通信を要求します。 |
最も一般的に使用される動作は、要求モードとセキュア要求モードです。Microsoft IT も、IPsec 展開時にこの 2 つの動作を採用しました。
Microsoft のセキュリティ環境
Microsoft IT の業務は多岐に渡ります。主な役割は、エンド ユーザーのサポートや通信管理から、サーバーやネットワークの運用に至るまで、幅広い IT サービスを提供することです。Microsoft IT では、世界各地に分散する 400 以上の拠点で、約 55,000 人の従業員、5,000 社の請負業者、および 17,000 社のベンダが、毎日 24 時間いつでも Microsoft の社内ネットワークにアクセスできるようにしています。
環境
Microsoft の業務は、非常にアクティブで問題の多いセキュリティ環境で展開されていて、問題には次のものがあります。
| • | Microsoft への不正侵入の試みは、毎月およそ 100,000 件になります。 |
| • | Microsoft では、毎月検出および処理されるウイルスに感染した電子メールの数は、1,000,000 件を超えます。 |
| • | Microsoft には製品開発、テスト、およびサポートのための独自の IT 環境があり、これらの環境には特別なセキュリティが必要です。 |
このように複合的な要素を抱え、常に変化し、大規模で動的な IT 環境全体にさまざまな脆弱性が潜んでいるような環境であるため、問題は非常に複雑です。
課題
Microsoft の作業環境は、多くの面で大規模エンタープライズの典型とは言えません。Microsoft でのデスクトップ環境独自の特徴として、次のものがあります。
| • | 1 人に複数台のコンピュータ : Microsoft の従業員の多くは、オフィスで 2 台以上のデスクトップ コンピュータを使用しています。多くの場合、そのうちの 1 台は Office 製品の開発などの与えられた業務を行うための専用の構成となっており、もう 1 台は標準のネットワーク アクセスおよび電子メール アクセス用です。アプリケーションの互換性をテストするために、Windows や Office のバージョンが複数稼動するシステムを意図的に使用しているケースもあります。また、Microsoft の従業員は、Microsoft Virtual PC を使用して 1 台のコンピュータで複数のオペレーティング システムをエミュレートしています。 |
| • | 多様なデスクトップ環境 : Microsoft の従業員は技術力が高く、約 97% がローカル管理者としてコンピュータを使用しています。また、製品の品質を上げるために、使用できるツールの限界を日常的に試しています。したがって、デスクトップ コンピュータの多くで、固有の機能とソフトウェアが構成されています。 |
| • | コンピュータの頻繁な再構築 : ソフトウェアの機能をテストするため、多くの従業員は自分のシステムを、時には毎日、完全に再構築しています。ワシントン州レドモンドの本社にあるデータ センターだけでも、毎月およそ 5,000 台のコンピュータが再構築されています。 |
| • | さまざまな承認済みソフトウェアバージョンの混在 : あるアプリケーションの新バージョンがリリースされても、社内全体にわたる部署 (製品開発、製品サポート、営業など) は、すぐに新しいバージョンを一斉にインストールするわけではありません。多くの企業同様、Microsoft の部署およびビジネス ユニットにも、各自のワーク モデルに最適なソフトウェア バージョンを選択する自由が与えられています。たとえば、いくつかの部署ではバージョンの相互作用および旧バージョンとの互換性をテストするために、古いバージョンのソフトウェアを使用します。開発グループでは、あるオペレーティング システムまたはアプリケーションを製造部門にリリースするまでに、複数 (時には最高 6 つ) のビルドをデスクトップ環境に展開しています。 |
プロジェクト展開チーム モデルと構造
Microsoft の中心的な事業は、ソフトウェアの開発とマーケティングです。このため、社内でグローバル IT サービスを提供するだけでなく、Microsoft のエンタープライズ製品がユーザーにリリースされる前に、実際の運用環境でテストを実施するのも Microsoft IT の職務の 1 つです。Microsoft 社内では "ドッグフード" と呼ばれるこのテクノロジの早期導入プロセスは、Microsoft 社内のネットワーク環境にさらに多くの課題をもたらしますが、製品が他の大規模企業のビジネス上の課題に合わせて拡張できることを確かにするうえで役立ちます。
Microsoft のネットワークに IPsec を展開するためには、Microsoft IT のさまざまなグループやスタッフ間での共同作業が必要でした。このとき主要な役割を果たしたチームは、次のとおりです。
| • | Corporate Security : 仕様を策定し、社内ネットワークのセグメント化に必要な要件を洗い出しました。 |
| • | Windows Infrastructure Engineering/Infrastructure Architecture : ソリューション全体のデザインを行いました。 |
| • | Windows Infrastructure Engineering : IPsec フィルタ、フィルタ リスト、ポリシーを作成し、これらをグループ ポリシーを使用して展開しました。 |
| • | Global Client Technology Team : IPsec の展開により問題が発生したユーザーにサポートを提供しました。 |
計画
ドメイン分離プロジェクトの計画段階は、大別して次の手順で構成されています。
1. | セグメント化の要件の特定しました。Microsoft IT では、まず、既に実装されているセキュリティ対策を確認し、管理されていないコンピュータから実行される可能性のある攻撃にはどのようなものがあるかを見極めました。このプロジェクトの目標は、社内ネットワーク上の Microsoft IT が管理する各ホストを、管理されていないホストから実行される攻撃から保護するメカニズムを展開することでした。 | ||||||||||||||||
2. | テクノロジを選択しました。IPsec、802.1x、仮想 LAN、および VPN の導入を検討しました。IPsec は追加のハードウェアやソフトウェア投資が必要なく、社内ネットワーク内での IP アドレスの変更も必要ない、拡張性の高いソリューションでした。また、IPsec では、ホストを分離してセキュリティ グループにまとめたり、必要に応じてトラフィックを暗号化することもできました。 | ||||||||||||||||
3. | Microsoft IT はまず、IPsec ポリシーを適用し、管理するためのセキュリティグループとグループポリシーオブジェクト (GPO) を作成しました。Microsoft IT では、グループ ポリシーと IPsec ポリシーの 2 つのポリシーを使用しています。1 つは既定の "セキュア要求" 動作用で、もう 1 つは "要求セキュリティ" 動作を使用する境界サーバー例外用です。続いて、ネットワーク エンジニアリング チームと協力して、社内ネットワークに割り当てられているすべての IPv4 サブネットを特定しました。このサブネットの一覧を使用して、Secure Subnets ルールと呼ばれる IPsec 用の既定のルールとフィルタ セットを作成しました。また、ネットワーク エンジニアリング チームと協力して、サブネット保護フィルタ リストの例外を特定し、必要に応じて各例外を合わせたルールを作成しました。 各 IPsec ルールにはそれぞれ対応するフィルタ リストがあり、フィルタ リストには 1 つ以上のフィルタ、フィルタ アクション、認証方式、接続の種類、および IPsec カプセル化モード (トランスポート モードまたはトンネル モード) が指定されています。Microsoft IT では、IT フィルタ アクションのデザイン時に、基本のフィルタ アクション (許可、要求セキュリティ、セキュア要求) を定義しました。基本のポリシーおよびフィルタが定義できた時点で、IPv4 環境、一元化されたポリシー構成、および共通セキュリティ アクションが定義され、展開に使用する準備ができました。詳細については、「Microsoft IT の IPsec フィルタ デザイン」を参照してください。 | ||||||||||||||||
4. | ポリシー、IPsec の機能と動作をテストしました。フィルタのデザインが済み、GPO が定義できたところで、まず限られたサブネットのみを指定したフィルタを使用するポリシーを有効にし、少数のコンピュータのみが IPsec を使用するようにしました。これにより、IPsec を限られた数のコンピュータに展開し、厳しい制御のもとで最初のテストを実施できました。このテストにより、境界コンピュータのニーズを確認でき、フィルタおよびフィルタ ルールを見直すことができました。 | ||||||||||||||||
5. | ロールアウトスケジュールを作成しました。限られた数のコンピュータでのテストが完了したら、ネットワークの構成を確認し、全社へのロールアウト スケジュールを作成しました。IPsec の大規模な展開はまったく未知の作業だったので、予期しない問題が発生した場合も、大半の従業員への影響をできる限り防ぎ、解決できるような形で IPsec を展開する計画を立てました。展開は、個々のサブネット単位で始め、次に建物の単位、最終的には全ネットワーク規模で実施する予定になりました。 計画では、展開は次の 2 段階で実施します。
| ||||||||||||||||
6. | プロセスと戦略をテストしました。Microsoft IT では、ロールアウト中に展開されたサブネットでのトラフィックと、ヘルプデスクへの問い合わせ数などからエンド ユーザーへの影響を細かく監視し、ロールアウトのプロセスと戦略を必要に応じて再度検討する計画を立てました。展開は、ユーザーへの影響を最小限にとどめ、業務が妨げられないようにすることに主眼が置かれました。 Microsoft IT では、グローバル要求モードの展開に、サブネット単位の段階的な展開方法を採用したことで、大きな成功を収めることができました。Secure Subnets フィルタ リストは、ロールアウトの進行に合わせて徐々に拡張され、最終的には社内ネットワークのサブネットすべてがこのリストに含まれ、ほぼすべてのネットワーク トラフィックが IPsec によりカプセル化されるようになりました。要求モードのロールアウトが完了したところで、社内のすべてのドメインに参加しているコンピュータには、同じ Secure Subnets フィルタ リストが配布されている状態になりました。 セキュア要求をロールアウトできるようにするため、(さらに規模の小さいサブネットに割り当てられる) より詳細なルールとフィルタ リストを作成し、セキュア要求フィルタ アクションをこれに関連付けました。 サブネット単位で展開することで、IPsec の展開をより細かく制御し、各 IT 組織が展開により受ける影響を図ることができましたが、より厳格なフィルタ アクションを使用する場合に、いくつかの課題が生じました。特に、セキュア要求または要求モードでは、ユーザーが展開済みのサブネット上でドメインに参加していないコンピュータを使用している場合、ポリシーが適用されている他のコンピュータに対してこのユーザーが開始したセッションはブロックされてしまいます。これは IPsec 展開の最終段階でしたが、ユーザーの多くはドメインに参加していないコンピュータには何の変更もないと考えているため、この影響はエンド ユーザーにとって混乱の種となり得ます。 Microsoft IT では、最初、セキュア要求の展開はサブネット単位でフィルタ リストを拡張する方式で行いましたが、ユーザーにとってはこの変更があまりに紛らわしく、許容されると思える影響の範囲を超えてしまいました。このため、サブネットではなくドメイン単位で展開を行うようロールアウト プロセスを変更し、最も規模の小さいドメインから展開を行いました。Microsoft IT が管理するコンピュータの大半が含まれるメインの企業ドメインの展開は、最後に行われます。 | ||||||||||||||||
7. | ユーザーに通知しました。Microsoft の従業員のほとんどにとっては IPsec の展開をまったく意識せず、ユーザーの介入をまったく必要とせずに、実施されました。展開のピーク時に、IPsec 関連でヘルプデスクに寄せられた 1 月あたりの問い合わせ件数は 250 件未満でした。この問い合わせ件数は、他のシステムと比較してきわめて少ないと言えます。たとえば、Exchange 関連の問い合わせは 1 月あたり約 7,000 件、PBX 関連の問い合わせもほぼ同数に上ります。 ヘルプデスクのスタッフは、IPsec の展開時に発見されたネットワーク上の問題についてユーザーをサポートできるようトレーニングを受けていました。IPsec の展開に伴い発生した問題を解決できるよう、ヘルプデスクのスタッフには、トラブルシューティング用のフローチャート、プロセス関連資料、WMI、IPsec、Kerberos 認証および DNS を使用したトレーニングが提供されました。それまで Microsoft IT により管理されていなかったコンピュータを使用していたユーザーは、多くの場合必要なリソースにアクセスできなくなり、管理されていないコンピュータの管理ドメインへの参加が促進されました。 開発者や、知的財産である機密データや人事リソース、会計データが置かれているサーバーのユーザーも、IPsec により適用されるセキュリティ ポリシーの変更に注意が必要でした。以前は、このようなユーザーは社内ネットワークに接続されていればどのコンピュータからでも、ユーザーの資格情報をサーバー アプリケーションに渡すことで、機密データのあるサーバーにアクセスできました。IPsec が展開されたことで、このようなサーバーには、適切なドメイン セキュリティ グループ内にあるコンピュータを使用して、承認されているユーザーによってしかアクセスできなくなりました。これらのドメイン セキュリティ グループへのアクセスは、[ネットワーク経由でコンピュータへアクセス] を使ってアクセス権を設定することで制限できました。また、承認されていないコンピュータからの接続は、IPsec によりブロックされます。機密データへのアクセスを承認されたコンピュータにしか許可しないというビジネス上の決定は、このようなデータを含むサーバーのユーザーに伝達する必要がありました。 IPsec 展開の進捗状況については、次のようなさまざまな方法で、全社に通知されました。
従業員の大半は、トレーニングを必要としませんでした。SecureNet サーバーへの接続に IPsec が必要になる前に、あらかじめコンピュータが次の 2 つの要件を満たしている必要があることを知らせる電子メールが全従業員に送付されました。
この電子メールでは、上記の要件を満たさないコンピュータは、指定された日以降、Microsoft IT が管理するサーバーおよび社内 Web サイトにはアクセスできなくなることも警告しました。また、詳細情報を参照できる社内 Web ページへのリンクも記載しました。 |
展開
ここでは、Microsoft 社内ネットワーク全体への IPsec の展開に関連する問題について説明します。
IPsec 用グループ ポリシーの配布
グループ ポリシーは、社内ネットワーク内に IPsec を展開するフレームワークとなります。Microsoft IT では、グループ ポリシーを使用して IPsec 設定を展開しました。"既定の" グループ ポリシーは、Domain Computers グループに適用されます。セキュリティ グループを使用して、一部のコンピュータからの、既定のポリシーへのアクセスは拒否されます。これらのコンピュータには、同じセキュリティ グループにより許可される別のポリシーが適用されます。
Microsoft IT は IPsec の展開に先立ち、次の手順を実行しました。
| • | IPsec 専用のグループ ポリシー オブジェクト (GPO) の作成。 |
| • | IPsec ポリシーからホストを除外するためのユニバーサル セキュリティ グループの作成。 |
| • | GPO の適用を制御するためのユニバーサル セキュリティ グループの作成。 |
| • | GPO と IPsec ポリシーを管理するためのユニバーサル セキュリティ グループの作成。 |
| • | IPsec 用グループ ポリシーの管理。 |
IPsec 専用のグループ ポリシー オブジェクト (GPO) の作成
Microsoft IT はドメインごとに 3 つの IPsec 用の GPO を作成しました。そのうちの 2 つは、次のプライマリ IPsec ポリシーで、各ドメインのコンピュータの 99% 以上に適用されます。
| • | Request Mode (要求モード) GPO |
| • | Secure Request Mode (セキュア要求モード) GPO 注 : Microsoft IT では、暗号化テストには別の GPO を使用しています。 |
クライアント コンピュータは、継承された特定の順序で GPO を適用します。最初に指定されている GPO が、残りの GPO よりも優先的に適用されます。このように順序を指定することで、エラーが発生した場合に、最も制約の少ない IPsec ポリシーが適用されるようにできます。図 2 は、Microsoft 社内のドメイン用に作成した GPO の順序を示しています。
図 2. 社内ドメインごとに適用される GPO の順序
残りの GPO、IPsec Require Encryption は、機密性の高いリソースをさらに保護する場合に使用します。
セキュリティ グループの作成
多数のコンピュータに特別な IPsec ポリシーが必要なため、Microsoft IT ではこれらのコンピュータを分けられるよう、一連のセキュリティ グループを作成しました。セキュリティ グループごとに GPO の適用を許可または拒否できます。多くのインフラストラクチャ サーバー (ドメイン コントローラ、DNS サーバーなど) のような一部のコンピュータは、セキュア要求ポリシーを使って IPsec が有効にされると、クライアントにサービスを提供できません。このようなサーバーは、"No IPsec" セキュリティ グループに分類しています。
コンピュータのセキュリティ グループと、ドメインに関連付けられている GPO を使って、コンピュータに適用される IPsec ポリシーが決められます。
GPO の適用を制御するためのユニバーサル セキュリティ グループの作成
ドメインの管理を簡素化するため、Microsoft IT ではフォレスト レベルで適用および管理できるユニバーサル セキュリティ グループを作成しました。
グループ ポリシーと IPsec ポリシーの管理用ユニバーサル セキュリティ グループの作成
指定されたユーザー アカウントから構成されるセキュリティ グループを定義することで、フォレスト全体の IPsec の管理者を特定できます。
グループ ポリシーの管理
Microsoft IT では、Windows Server 2003 を使用して IPsec 用グループ ポリシーを管理しています。Windows 2000 にも IPsec のサポートが実装されていますが、Windows Server 2003 ではパフォーマンスが向上しており、具体的な IPsec ルールのサポートも強化されています。依然として社内ネットワーク上で Windows 2000 コンピュータが広く使われているため、Microsoft IT ではルールおよびフィルタを Windows 2000 以降に対応するよう定義しました。
Microsoft IT では、管理者がローカルの IPsec ポリシーを作成し、これを .IPSEC ファイルにエクスポートしています。この .IPSEC ファイルは、テスト環境にインポートされ、展開に先立ち評価および検証されます。作成した IPsec ポリシーに問題がなければ、標準の展開として各ドメインにインポートされます。
.IPSEC ファイルは、IPsec ポリシー設定の障害時復旧用バックアップとして使用できます。
Microsoft IT の IPsec ポリシー設定とフィルタ デザイン
社内ネットワーク上のコンピュータの大半で、既定のポリシーと標準のフィルタ ルールが使用されています。
IPsec ポリシーは、一連のルールで構成されます。各ルールは、フィルタ リストとアクションで構成され、認証方式、トンネル、接続ポイントを指定できます。フィルタ リストは、一連のフィルタで構成されます。各フィルタでは、発信元アドレスまたはネットワーク、宛先アドレスまたはネットワークのほか、必要に応じてポートやプロトコルを指定します。フィルタ アクションは、許可、ブロック、またはカスタマイズ可能なセキュリティのネゴシエート アクションのいずれかになります。
図 3 は、これらの IPsec ポリシーの構成要素間の関係を示しています。
図 3. IPsec ポリシーの構造
各ホストに割り当てられるアクティブな IPsec ポリシーは 1 つのみです。Microsoft IT は、展開プロセスの各段階で、各 GPO によってコンピュータに適用される複数の IPsec ポリシーを定義しました。IPsec が既に他の目的で使用されている場合があります。企業によっては、IPsec ブロック フィルタおよび許可フィルタを使用して、個々のサーバーを保護している場合があります。このような既存の IPsec 展開は、Microsoft IT が使用したような展開と直接競合する可能性があります。1 台のコンピュータに、SecureNet のような環境に加わるために専用のポリシーを割り当て、その上ローカルにサーバーを保護するための別の IPsec ポリシーを使用することはできません。このような問題に対処するには、特定の "サーバー保護" 用ポリシーを、これよりも広範なレベルで適用されるドメイン ポリシーのコンテキスト内で、より厳しい設定 (暗号化を要求するなど)、またはより緩やかな設定 (監視用のすべての SMTP トラフィックを許可するなど) を使って実装する方法が考えられます。これらのサーバーごとのポリシーは、特定の GPO を OU に関連付けるか、セキュリティ グループ フィルタを使用して "サーバー保護" 設定をサーバーのサブセットに適用することで実装できます。
ポリシー設定
ドメインにインポートされる IPsec ポリシーを作成するために、Microsoft IT では MMC スナップインを使用して Windows Server 2003 コンピュータ上でローカル IPsec ポリシーを定義しました。各ルールは、この IPsec ポリシーのプロパティ シートを使って管理します。フィルタ リストとフィルタ アクションは、MMC スナップインから直接定義することも、各ルールの定義内で指定することもできます。ポリシー設定は、ポリシー自体、各ルール、フィルタ、フィルタ アクションからなる特定の要素に関連付けられます。
表 1 は、Microsoft IT が管理するほとんどのコンピュータに展開されている標準の IPsec ポリシーの説明です。
表 1. Microsoft の IPsec 展開で採用されている IPsec ポリシー設定
| ポリシー設定 | 値 | コメント | ||||||
既定のフィルタ アクション | Secure Request | Microsoft では、ドメインに参加しているコンピュータのほとんどの IPsec ポリシーに、既定のフィルタ アクションである Secure Request が指定されています。このポリシーが割り当てられた各コンピュータは、別のフィルタにより除外されているものを除き、すべてのサブネットへの送信 IP 要求に対して IPsec を使用します。IPsec のネゴシエートが 3 秒以内に成功しなかった場合は、目的のホストへの接続に非認証のトラフィックを使用し、緩やかなセキュリティ アソシエーション (SA) が確立されます。このポリシーが割り当てられたホストに対する非認証の受信要求は、すべて拒否されます。IPsec ネゴシエートに成功した着信要求のみが許可されます。このフィルタ アクションは、既定では提供されていませんが、[セキュリティで保護されていない通信を受け付けるが、常に IPSec を使って応答] チェック ボックスをオフにし、[IPSec に対応していないコンピュータとセキュリティで保護されていない通信を許可] チェック ボックスをオンにすることで、新しいフィルタ アクションとして作成できます。ただし、このポリシーは Windows 2000 SP3 以降、Windows XP SP1 以降、および Windows 2003 でしかサポートされません。これ以前のバージョンの Windows 2000 や Windows XP のバージョンでは、このポリシーは Request Security と同様の動作になります。 | ||||||
既定のフィルタ リスト | Any <-> Secure Subnets | 社内サブネットに IPsec を制限する一連のフィルタです。モバイル コンピュータが社内ネットワーク以外のネットワークに接続する場合、発信または着信通信に IPsec を使用しません。 Microsoft IT が管理するコンピュータが、このフィルタ リストに指定されている RFC 1918 IP 範囲を使用してプライベート ネットワークに接続した場合、この IP アドレス範囲に該当するコンピュータには接続できません。たとえば、Microsoft 社内ネットワークでは 10.0.0.0/8 ネットワーク空間全体が、IPsec を使用するよう定義されています。Microsoft のコンピュータが、同じくこの範囲のアドレスを使用している別の企業のネットワークに接続したときに、互換性がない IPsec ポリシーが使用されていた場合、他のホストとの通信を正常に確立することはできず、着信通信要求がすべてブロックされる可能性があります。 Microsoft では、従業員が自宅のネットワークに接続できるように、狭い範囲のプライベート IP アドレスを 2 範囲明示的に除外しています。 | ||||||
既定の認証方式 | Kerberos | Microsoft Windows IPsec は、次の 3 種類の認証方式のいずれかを使用できます。
IPsec の認証に Kerberos を使用することで、Active Directory を使用してセキュリティ グループを定義したり、ネットワークをさらに細かくセグメント化することができます。 Microsoft では、Kerberos が IPsec の既定の認証方式です。Active Directory ドメインのメンバではないコンピュータをサポートするためのルールでは、証明書がサポートされています。たとえば、Active Directory による管理を行わずに、VPN クライアントに接続を許可する場合などです。 事前共有キーは、容易に改ざんされる可能性がありますが、簡単には失効できないため、ほとんどの場合推奨されません。 | ||||||
既定のセキュリティのネゴシエート メソッド | NULL 暗号化を使用する ESP | IPsec には、認証ヘッダー (AH) とカプセル化セキュリティ ペイロード (ESP) の 2 種類のセキュリティ メソッドがあります。通常、認証およびデータの整合性の検証には AH が使われます。ESP は一般には暗号化が望ましい場合に使用されます。Microsoft IT では社内ネットワークのトラフィックのほとんどに暗号化は使用していませんが、次のような理由からすべての IPsec トラフィックに ESP を採用しています。
| ||||||
ポリシーの更新間隔 | 60 分 | 各ホストは、IPsec ポリシーを 60 分ごとにローカルにキャッシュするように設定されています。60 分経過すると、ホストは Active Directory から新しいポリシーを取得して更新します。これにより、IPsec ポリシーへの変更が社内ネットワーク全体に (少なくとも) 1 時間以内で展開されるため、社内ネットワークに対する侵害にすばやく対応できます。 | ||||||
メイン モードの有効時間 | 2 時間 | Windows のメイン モードの既定の有効時間は 8 時間です。これは、2 台のコンピュータ間のセキュリティ アソシエーション (SA) が有効である時間 (SA がメモリから消去されて再びネゴシエーションが行われるまでの時間) を指定するものです。Microsoft IT では、アクセス頻度の高いサーバーのメモリ使用率を抑えるため、メイン モードの有効時間に既定よりも短い時間を設定しています。 | ||||||
クイック モードの有効時間 | 1 時間 (Windows IPsec の既定の設定) | キーが有効である時間 (再生成されるまでの時間) です。クイック モード SA には、アイドル タイムアウトとして 5 分間がハードコーディングにより設定されています。つまり、5 分間トラフィックが発生しないと、この SA は削除されます。 | ||||||
NoDefaultExempt | 1 に設定 | 既定では、ある種のトラフィックは IPsec の対象外とされています。これには Kerberos やリソース予約プロトコル (RSVP) も含まれていますが、Microsoft IT では、グループ ポリシー管理テンプレートを使用して、対象外とならないようにしています。Microsoft ではドメイン コントローラに対する IP トラフィックをすべて許可しているため、この 2 種類のトラフィックに対する IPsec の非適用措置は必要ありません。 ブロードキャストおよびマルチキャスト、IKE (UDP/500) トラフィックに対する非適用措置は、現時点では IPsec を使用して保護できないため、既定のままにしてあります。 詳細については、次のマイクロソフト サポート技術情報 (KB) の資料を参照してください。
| ||||||
IPsec インターネット鍵交換 (IKE) の既定のセキュリティ メソッド | 3DES、SHA1、DH2 | Microsoft IT では、Triple Data Encryption Standard (3DES) によりキー交換を暗号化し、Secure Hash Algorithm 1 (SHA1) によりキーの整合性を検証し、Diffie-Hellman シーケンスのレベル中 (2) を使用してキー交換を行うセキュリティ メソッドを採用しています。 | ||||||
セキュリティのネゴシエート メソッドの優先順位 | Custom | トラフィックの許可に IPsec のネゴシエーションを必要とするフィルタ アクションに対しては、カスタムのセキュリティ メソッドを作成して、暗号化なしの ESP を指定します。すべてのキーは、1 時間後に失効するよう設定されています。図 4 は、カスタムのセキュリティのネゴシエート メソッドの設定を示しています。 すべてのトラフィックに対する既定のセキュリティ メソッドは暗号化なし ESP ですが、指定されたセキュリティ メソッドがすべて組み合わされると、このフィルタ アクションを使用する IPsec ポリシーが割り当てられているコンピュータは、他のホストによる要求に応じて、暗号化や他の IPsec 機能を使用できるようになります。 |
図 4. ほとんどのホストへの IPsec 通信を許可するカスタムのセキュリティメソッドの設定
Microsoft IT の IPsec フィルタ デザイン
Microsoft IT は、社内ネットワークのほとんどのコンピュータの既定のポリシーとして、表 2 のような基本のフィルタ ルールを使用しています。
表 2. Request および Require ポリシー用に Microsoft IT が推奨する IPsec フィルタリスト
| フィルタ | フィルタ アクション |
Any <-> SecureNet, /18 subnet | Secure |
Any <-> Exempted Subnets /23 subnet | Permit |
Any <-> Virtual IP addresses (Clusters, NLB) | Permit |
Any <-> Domain Controllers | Permit |
Any <-> DNS Servers | Permit |
Any <-> DHCP Servers | Permit |
Any <-> WINS Servers | Permit |
Me <-> Any, ICMP | Permit |
デザインの背景
各 IPsec ルールにより、フィルタ リストとアクションが関連付けられます。個々のフィルタは、発信元アドレス、宛先アドレス、およびフィルタが照合するプロトコルを定義します。ネットワーク接続を記述する最も具体的なフィルタは、ルールにより適用されるフィルタです。
Microsoft の IPsec 展開では、トラフィックを許可するすべてのルールは、特定のフィルタに適用されています。セキュリティをネゴシエートするルールは、一般の SecureNet IP アドレス範囲に使用しています。
IPsec は、最も具体的なフィルタを常に適用します。このため、トラフィックを許可する例外ルールは、常にセキュリティをネゴシエートする既定のルールよりも具体的にする必要があります。
フィルタ デザインの課題
展開されるフィルタは IP アドレス範囲を定義していますが、IPsec はグループ ポリシーおよび Active Directory のセキュリティ グループ メンバシップを使って管理および展開されます。SecureNet 内のサブネットが追加、削除、または変更された場合、IPsec ルールで使用されている個々のフィルタを更新しました。展開プロセスの第 1 段階が完了した時点で、社内ネットワークのすべてのコンピュータは、IPsec により保護された通信に対応できるようになりました。第 2 段階では、最初サブネット単位での展開を試みましたが、この資料の「計画」で説明したように、大きな問題が発生しました。このような問題のために、第 2 段階では、サブネットではなくドメイン単位のロールアウトを実施しました。
保護されていないトラフィックを許可するルールの使用については、ポリシーのデザインとセキュリティの両方の観点から、十分に検討する必要があります。どの宛先アドレスが許可されるかについては、十分注意する必要があります。これは、ホストが IPsec を使用せずにこれらのアドレスと通信できてしまうためです。
もう 1 つのフィルタ デザインの課題は、複数の IP アドレスを持つマルチホーム コンピュータの管理でした。たとえば、エクストラネット上のコンピュータの中には、社内ネットワーク用に 1 枚とインターネット接続用に 1 枚の、2 枚のネットワーク インターフェイス カード (NIC) を使用しているものがあります。IPsec フィルタは、IP アドレスやネットワークを定義しますが、物理的な NIC についての概念はありません。したがって、コンピュータに適用される IPsec ポリシーでは、個々の NIC ではなく発信元アドレスと宛先アドレスを考慮します。
Microsoft では、マルチホーム コンピュータ用の IPsec ポリシーには、公衆インターネット アドレスに対するフィルタを含めていません。これにより、このようなコンピュータでインターネット接続に使われている NIC にアクティブな IPsec ポリシーが割り当てられないようにしています。
詳細については、「IPsec デザインのベスト プラクティス」を参照してください。
非 IPsec プラットフォームのサポート
ドメイン分離により得られる大きな利点の 1 つは、ネットワーク上で実行されているプラットフォームやサービスを分析し、例外を特定することで得られる知識です。例外の状態を細かく把握することで、環境全体のセキュリティを強化する次のセキュリティ対策を講じるために必要な知識を得ることができます。
非 IPsec 対応プラットフォーム
Microsoft の社内ネットワークでは、Microsoft IT によって展開された IPsec を使用できないコンピュータやデバイスが多数あります。このうち主なものは、次のとおりです。
| • | Windows 以外のコンピュータとデバイス : Apple Macintosh コンピュータ、Unix コンピュータ、Xbox、Pocket PC には、Windows IPsec がインストールされていないか、容易に展開できません。 |
| • | 古い Windows オペレーティングシステム : Microsoft の一部のグループは、Windows NT4 や Windows 9x コンピュータ上でのテストを実行しています。このようなコンピュータでは、グループ ポリシー ベースの IPsec は使用できません。 |
| • | 管理ドメインに参加していない Windows コンピュータ : 一部の開発グループは、テストにプライベート ドメインを運用しています。また、多くのユーザーが、管理ドメインに接続していないテスト コンピュータや開発用コンピュータを使用しています。 |
| • | Microsoft のものではない RAS および VPN クライアント : パートナーやベンダ企業は、特定の Microsoft リソースに接続する必要があります。従業員の多くは、自宅のコンピュータを使用して社内ネットワークに接続しています。このようなコンピュータには、管理ドメイン内にコンピュータ アカウントがない場合があります。 |
従来、このようなコンピュータはすべて、ドメイン リソースにアクセスできました。IPsec が展開されたために、これらのコンピュータは SecureNet 内のコンピュータにはアクセスできなくなりました。Windows IPsec は、このような他のプラットフォームが提供する IPsec 実装と互換性がありますが、SecureNet に必要なセキュリティ標準を満たせないため、Microsoft IT ではこれらのコンピュータを除外するように IPsec ポリシーをデザインしました。
業務上ドメイン リソースにアクセスする必要がある特定の非 Windows デバイスを接続するための有効な方法を開発することは、Microsoft IT にとって優先度の高い課題です。現在、これらのデバイスは、特別な IPsec ルールが割り当てられたリソースにアクセスしなければなりません。Microsoft IT では、このような例外サーバーを "境界コンピュータ" と呼んでいます。これらの境界コンピュータについては、次で説明します。
レガシおよびテスト環境の SecureNet への追加は、優先度が高くありません。これらのコンピュータは、社内ネットワークに接続するための最小セキュリティ標準を満たしていません。業務上テスト コンピュータを使用して社内リソースにアクセスする必要が高い場合、リソースを境界コンピュータにするよう申請できます。
非 IPsec 通信のサポート
Microsoft では、業務上ドメインに参加していないコンピュータが SecureNet に収容されるべきビジネス リソースにアクセスする必要があります。前述の種類のクライアント コンピュータ以外に、IPsec により保護できない特定の種類のインフラストラクチャのサービスがあります。
そもそも IPsec を確立するには、コンピュータがネットワークに接続でき、ドメイン コントローラから IPsec ポリシーを取得できる必要があります。つまり、ドメイン コントローラが認証されていないホストと通信し、DHCP リレー エージェントが DHCP サーバーからの応答を転送して、クライアント コンピュータがネットワークにアクセスできる必要があります。また、クライアントがドメイン コントローラを検出し、SecureNet にアクセスする必要がないゲスト コンピュータやテスト コンピュータから境界コンピュータおよびインターネットへのアクセスを可能にするには、WINS および DNS が必要です。
リモート インストール サーバー (RIS) および Advanced Deployment Services (ADS) からイメージをダウンロードする必要があるネットワーク シン クライアントや他のブートストラップ クライアントなど、他のサービスも IPsec をサポートしません。
境界コンピュータ
IPsec による一般の SecureNet 展開の例外を管理するため、Microsoft IT は異なる境界コンピュータを定義しました。境界コンピュータは、非 IPsec 受信接続を受け入れる IPsec 対応コンピュータで、SecureNet と信頼されていない社内ネットワークの境界に配置されます。境界コンピュータは、SecureNet と信頼されていない社内ネットワーク間の通信の "プロキシ" となるわけではありません。境界コンピュータは、単純に、信頼されていない社内ネットワークからのアクセスを受け付ける SecureNet コンピュータです。
| • | 境界コンピュータは、セキュア要求モードではなく、要求セキュリティを使用します。 |
| • | 境界コンピュータを配置することで、IP アドレスではなくセキュリティ グループを使用して既定の IPsec ポリシーの例外を非常に柔軟に定義することが可能になっています。 |
境界コンピュータの管理
境界コンピュータは、信頼されていないコンピュータから SecureNet リソースへのアクセスを許可する手段なので、追加の管理とセキュリティが必要です。Microsoft IT では、境界コンピュータの配置を認めるだけの具体的な理由を把握しています。セキュリティ グループを定義し、信頼されていないアクセスを許可する理由が同じコンピュータどうしをまとめています。この方法であれば、特定のサービスに対する脅威をすばやく阻止でき、ファイアウォール ルールなどの追加のグループ ポリシーを特定のセキュリティ グループに展開することができます。
たとえば、すべての RIS サーバーは、専用のセキュリティ グループにまとめられています。RIS サーバーは境界コンピュータとして、どのようなコンピュータからの非 IPsec 着信も受け入れます。これにより、RIS サーバーは Windows の読み込み前や IPsec 機能を取得する前にオペレーティング システム イメージをダウンロードするコンピュータをサポートします。RIS サーバー セキュリティ グループの一部とすることで、グループ ポリシーが既定の IPsec ポリシーへのアクセスを拒否し、RIS サーバー セキュリティ グループが要求モード ポリシーの適用を実現します。
もう 1 つの境界コンピュータの共通タイプとしては、ある特定のグループや建物内の Apple Macintoshe コンピュータが使用するファイル サーバーやプリント サーバーがあります。ファイル サーバーは、状況に応じて境界サーバーとなることが許可されます。いくつかの Mac 関連部門では、担当するソフトウェアを開発するために、特定のドメイン リソースにアクセスする必要があります。このような部門からの要求は、通常受け入れられますが、Mac リソースを特定のコンピュータに統合する取り組みは現在進められています。
境界コンピュータの展開
すべての従業員は、任意のコンピュータを境界コンピュータにするよう要請できます。この場合、境界コンピュータにするための理由と、その十分な根拠を提示する必要があります。Microsoft IT は、その必要性を検証して、要求を受け入れるか拒否するかを決定します。
IPsec を展開したことで、Microsoft IT はセキュリティ リスクがネットワークのどの場所に存在しているかを特定し、社内ネットワーク内のコンピュータの状態をより細かく把握することができました。Microsoft IT では、安全でないネットワーク トラフィックを既定では拒否し、状況に応じて許可できるようになりました。これは、IPsec の展開に付随して得られた知識と、必要に応じて安全でないトラフィックを迅速かつ厳しく制限する機能が得られたことによります。
セキュア要求モードを社内ネットワーク全体に展開した後は、境界コンピュータがドメインに参加しているコンピュータ全体に占める割合は 2% 未満になりました。IPsec の展開は完了しているので、今後も境界コンピュータを分離、統合し、境界コンピュータによるリスクを緩和するためのセキュリティ対策を加えて講じていくことができます。
現在の Microsoft IT
Microsoft 社内では、IPsec ポリシーをまず規模の小さいサブネットに適用し、そこで問題を発見、解決してからさらに大規模な展開を行いました。Microsoft における IPsec 展開の第 1 段階、2003 年 3 月に完了し、160,000 台以上のコンピュータが IPsec に対応するようになりました。技術的な問題が特定され、修正されました。この段階で接続性が失われたことはなく、Microsoft 社内のネットワーク トラフィックの 70% 以上が ESP でカプセル化されました。
IPsec 展開の第 2 段階では、全社へのセキュア要求モードの展開が行われました。展開の第 2 段階は、予定より早く 2004 年 4 月に完了しました。本資料の執筆時点では、6 フォレスト、18 ドメインに配置されている約 208,000 台のコンピュータが、正常にセキュア要求モードを使用しています。Microsoft の社内ネットワークは、現在 IPsec を使用して論理的にセグメント化されています。"信頼されている" コンピュータは、"信頼されていない" コンピュータから保護されています。
既知の問題と問題の該当箇所
主に非 IPsec 対応プラットフォームや RAS クライアント、VPN クライアントなど、IPsec の展開にまつわる問題の多くは既にこのホワイト ペーパー内で取り上げています。他に、ドメイン分離ソリューションの開発と展開時に、次のような問題が発生しました。
パフォーマンス ? LAN
ESP はネットワークを通過するすべてのパケットに短いヘッダーとトレーラを追加します。展開時に、この追加のパケット情報のために、アプリケーションにより割合は異なりますが 3 〜 9% の帯域幅使用オーバーヘッドが発生しました。Microsoft のエンタープライズ環境内のアプリケーション全体では、平均して約 3% の増加が見られました。
増加の割合は、展開されているアプリケーションの構成に応じて、エンタープライズ環境ごとに異なる可能性があります。帯域幅の増加は、LAN や高速イーサネット接続よりも、トラフィックが既に制限いっぱい近い WAN の場合により深刻な影響が出るようです。
Microsoft では、エンタープライズ環境でこの影響を認識しました。この場合は、潜在的なセキュリティの価値と比較して、実際の帯域幅の増加コストは問題にならないと判断しました。ただし、他の企業では、これが問題になることが考えられます。
パフォーマンス ? CPU
すべてのパケットに ESP を追加することによるオーバーヘッドは、ほとんどのクライアント コンピュータでは無視できます。同時ネットワーク接続数の多いサーバーの場合は、通常、CPU 処理時間がわずかに多く必要なメイン モード ネゴシエーション中に発生する Diffie-Hellman 交換数が増加するため、このオーバーヘッドが問題になります。Microsoft IT は、現在、IPsec および SSL または暗号化オフロード カードの分析も含め、コア IT サービスおよびサーバー シナリオのより詳細なパフォーマンス分析を進めています。
完全な ESP 暗号化を行うと、さらに CPU 処理時間がかかります。完全な暗号化接続を必要とするきわめて機密性の高いデータを保持しているサーバーについては、特殊な 10/100 Mbps ネットワーク カードを使用できます。これは、CPU に代わりこの暗号化処理をオフロードします。ギガビット イーサネット向けにはこのようなカードはまだ提供されていません。
Microsoft では、最初の IPsec 展開では ESP 暗号化を使用していませんが、将来的にサーバーの保護やエクストラネット セキュリティ シナリオに使用できるかどうかを調査しています。
IPsec と Windows VPN サーバー
Kerberos を使用する IPsec 展開では、VPN サーバーに特別な IPsec ポリシーを設定して、リモート クライアントへのトラフィックを許可し、トンネル自体に認証されていないトラフィックをサポートする必要があります。Microsoft の展開で使用されている IPsec ポリシーは、既定のレイヤ 2 トンネリング プロトコル (L2TP) フィルタとは互換性がありません。
全社で 1 つの信頼されたルートの証明書を使用する展開では、VPN サーバー専用の IPsec ポリシーは必要ないかもしれません。Microsoft IT では、SecureNet の大部分に Kerberos を使用することにしました。証明書は、ドメインに参加していない VPN コンピュータでのみ使用しています。
RFC 1918 プライベート IP 範囲
Request For Comment (RFC) 1918 では、だれもがプライベート ネットワーク上のコンピュータに使用できるプライベート IP の範囲を既定しています。この範囲は、Microsoft だけでなく、VPN 経由で社内ネットワークに接続する従業員やベンダも使用しています。
Microsoft では、このプライベート ネットワーク アドレス空間のほとんどをセキュア サブネットに使用しているので、セキュア サブネット内の IP アドレスを使用するホストが SecureNet に接続するためには、ドメインに参加し、Kerberos および IPsec により認証される必要があります。この条件は、プライベート アドレスを使用して SecureNet に接続するホーム ネットワーク ユーザーおよびベンダにとって問題になりました。
特に複数のネットワークを使用するモバイル ユーザーが、この問題を経験しています。たとえば、ドメインに参加しているラップトップを使用しているユーザーが、出張先のホテルのネットワークを使おうとする場合などです。ホテルが使用しているネットワーク空間が、IPsec ポリシーで定義している保護サブネットの 1 つと同じであった場合に、IPsec ポリシーがそのサブネットで使用されている場合は問題が発生する可能性があります。これは、このユーザーのラップトップに IPsec ポリシーがキャッシュされていて、ホテルのネットワークの IP アドレスに対して IPsec をネゴシエートしようとしますが、適切なフィルタがないことが原因です。IPsec ポリシーによっては、ラップトップが IPsec 通信の開始を試みてから 3 秒間の遅延を経て認証されていない通信が使われるか、相手のコンピュータが互換性のない IPsec ポリシーを使用していた場合は完全に接続が失敗します。現在までのところ、Microsoft IT にはモバイル ユーザーから実際に通信上の問題についての報告は寄せられておらず、理論上の問題にとどまっています。
Microsoft では、次の 2 つのプライベート サブネットを、セキュア サブネットの一覧から除外しています。
| • | 192.168.0.0/24 |
| • | 192.168.1.0/24 |
従業員またはベンダが独自のネットワーク上のコンピュータを使用して、SecureNet リソースに VPN 経由で接続する場合は、この承認されているプライベート アドレス サブネットを使用すると、前述の問題を回避できます。
この問題を解決するには、セキュア サブネットで使用するプライベート サブネットの数を制限し、このリストから他のプライベート サブネットを除外します。理想的には、社内ネットワークにはプライベート IP アドレス空間を使用しないようにします。
ネットワーク デバイスの問題
IPsec は、TCP/IP パケット内の宛先ポートとプロトコルのオフセットを変更します。この変更により、ルーターなどのネットワーク デバイス上で動作している多くのアプリケーション、特にネットワーク トラフィックを監視し、管理するアプリケーションが無効になります。
いずれ、このようなネットワーク アプリケーションは IPsec をサポートするように更新される見込みですが、多くのアプリケーションは IPsec にまだ対応していません。
| • | ルーターの ACL は、ESP により保護されたパケットのプロトコルおよびポート フィールドを検証できません。IP アドレスのみを使用する ACL は、問題ありません。 |
| • | ルーター上の Cisco NetFlow は、プロトコルまたはポートに基づいた IPsec メンバ間で送信されるパケットの分析を実行できません。IP アドレスのみを使用する分析は、問題ありません。 |
| • | ルーターベースのサービスの品質 (QoS) は、ポートを使用したパケットの分類を実行できません。Windows がサポートするホストベースのパケットの分類は、問題ありません。また、IP アドレスのみを使用するルーターベースの QoS も問題ありません。 |
| • | 均等化キューイング (WFQ) や他のフローベースのルーター トラフィック優先付け方法は、意図したようにパケットをキューに格納できず、ネットワークが最適に使用されない可能性があります。 |
| • | ネットワーク モニタが ESP パケットを解析できない可能性があります。 |
一般に、IPsec はネットワークベースの優先付けおよびポートベースやプロトコルベースのトラフィック管理を無効にします。暗号化パケットについては、回避策はありません。ホスト自体がトラフィック管理機能を処理する必要があります。認証のみが行われた非暗号化パケットの場合は、デバイスやプリケーションが、IPsec によるパケットの変更を認識し、正しいホストへこれらをルーティングすること以外の処理を行える必要があります。
Microsoft ネットワーク モニタには、バージョン 2.1 の時点で ESP パーサーが追加されました。これは、非暗号化 IPsec パケットのトラブルシューティングに使用できます。ネットワーク モニタは、Windows Server 2003 では簡易版が、SMS では完全なバージョンが提供されています。SMS のネットワーク モニタでは、データのフォーマット、高度な診断機能、およびその他のキャプチャ管理機能を使用できます。
上記の問題を解決するには、可能であれば、該当するツールを IPsec に対応した最新版にアップグレードします。
IPsec によるシステム リソース使用量の増加
Windows 2000 の場合は、Service Pack 3 を適用すると、多数のセキュリティ アソシエーション (SA) のあるコンピュータのメモリ使用量を軽減できます。Windows 2000 はコンピュータの各静的 IP の "Me" フィルタを拡張するため、フィルタ リストが肥大化し、CPU やメモリの使用率が増加する可能性があります。Microsoft IT では、"Me" フィルタではなく (拡張されない) "Any" フィルタを使用して、この問題を回避しています。
IPsec を使用するコンピュータは、認証された接続ごとに SA を確立します。ほとんどのコンピュータは、通常の使用では、メモリ使用率が顕著に高くなるほどの数のアクティブな接続が発生することはありません。数千単位でアクティブな接続が発生するサーバーの場合、これらの SA は合計すると数 MB にも及ぶことがあります (Microsoft IT では、アクティブな SA 1 つあたり、5 KB のメモリを使用すると見積もっています)。Windows Server 2003 の場合、CPU 処理時間の増加は、100 Mbps インターフェイス経由で送信されるトラフィックに影響するほど大きくありません。ギガビット イーサネット接続では、アクセス頻度が極めて高いサーバーのスループットが、トラフィック認証に伴い発生するオーバーヘッドのために、わずかに低下します。
暗号化が有効な場合、アクセス頻度の高いサーバーのパフォーマンスは大幅に低下します。このような問題を解決するには、IPsec オフロード カードを取り付けます。
フィルタ処理の問題
アクセス頻度の高いサーバーでは、フィルタ数ができる限り少なくなるようにすることが重要です。IPsec ドライバは、各接続に対応するフィルタをキャッシュします。どの接続にも対応しないフィルタを定義した場合、このフィルタはキャッシュされず、セキュリティ アソシエーションの検証が必要になるたびに読み込む必要があります。
可能な限り、複数のケースに当てはめることができる IPsec フィルタとルールを作成し、特定のポートを指定するフィルタを使用しないようにしてください。
IPsec と NLB クラスタ
IPsec のネットワーク負荷分散 (NLB) クラスタへの実装については、いくつかの課題があります。IPsec は個々のホストどうしが相互に認証するので、クラスタ内のサーバーの 1 つが停止した場合、そのサーバーに接続しているクライアントは接続を再ネゴシエートする必要があります。Windows Server 2003 ベースの NLB は、仮想 IP アドレスを共有するクラスタ内での使用時に、Windows 2000 に存在していた特定の IPsec の問題を解決します。
NLB は、複数のサーバーをまとめてクラスタ化し、あるサーバーで障害が発生した場合にクラスタ内の他のノードに自動的にフェールオーバーすることで、サービスの高可用性を実現します。IPsec は、別のコンピュータが同じクライアント接続を処理しないようにするため、この点で NLB と直接競合します。IPsec は、データの転送前に個々のホスト間でネゴシエートされるので、クラスタ内の同じノードが確立されている IPsec 接続に応答しない限り、トラフィックは破棄されます。
クラスタ内のあるノードで障害が発生した場合、そのサーバーとの既存の IPsec 接続はフェールオーバーを検知できず、事前に設定されているタイムアウト時間が経過するまで、セキュリティ アソシエーションを再構築できません。Windows 2000 および Windows XP では、アイドル状態が 5 分間継続しないと、クライアントが IPsec の再認証を実行することはできません。このため、このクライアントに対するサービスは 2 〜 6 分間中断されます。
NAT-T の更新が含まれている Windows XP SP1、Windows XP SP2、および Windows Server 2003 では、このアイドル タイムが 1 分間に短縮されています。クライアントが障害のあるクラスタ ノードに接続した場合は、常に遅延が発生します。
Windows XP 以前では、完全なサブネットを使用するクラスタでしか、NLB と IPsec を併用することはできませんでした。この場合、DNS を使用して負荷をクラス C サブネットの複数の IP アドレスに分散します。Windows Server 2003 では、クラスタ全体に 1 つの仮想 IP アドレスを使用することで IPsec と NLB の併用をサポートしています。クラスタ内の各ノードは、それぞれが処理する発信元 IP 範囲の一覧をネゴシエートし、クラスタ内のトラフィックとフェールオーバーの状態に応じて、動的にこの一覧を調整します。
Network Address Translation Traversal (NAT-T)
ネットワーク アドレス変換 (NAT) は、これまで IPsec の問題を引き起こしてきました。NAT デバイスがパケットのポートまたは発信元アドレスを変更した場合、チェックサムによりこのパケットが検証できなくなり、パケットは拒否されます。Microsoft のテスト ラボやテスト環境は、社内ネットワーク内で NAT を使用することがあります。
IETF はこの問題に対処する NAT-T 仕様を策定しており、Windows 2000 SP3 と SP4、および Windows XP SP1 以降には、これに対応する修正が提供されています。NAT-T は、Windows XP SP2 および Windows Server 2003 に組み込まれています。
トラブルシューティングの問題
IPsec は通常の IP トラフィックを ESP を使ってカプセル化するので、ネットワーク関連の問題のトラブルシューティングが困難です。通常、IPsec 自体には問題がありませんが、その基盤となるすべてのテクノロジが適切に構成されている必要があります。基盤テクノロジのいずれかに構成の誤りがあった場合、問題の原因を突き止めるのが難しくなる可能性があります。
IPsec のトラブルシューティングでは、複数の層での接続性を確認します。基本的な手順は、次のとおりです。
1. | ping、ipconfig、route などのユーティリティを使用して、基本的なネットワーク接続を確認します。 |
2. | 詳細なログ記録を有効にします。Net View を使用してセキュリティ アソシエーションの作成状態をキャプチャし、IKE 問題を診断します。 |
3. | 標準のクライアント ログを参照して、主要なネットワーク状態を確認します。また、netdiag.exe を使用して DNS の問題を確認します。 |
4. | gpresult、ipseccmd、ipsecpol、netdiag を使用して、グループ ポリシーと IPsec ポリシーのバージョンを確認します。 |
5. | logman.exe を使用してセキュリティ イベントを確認します。 |
6. | 必要なサービス機能を確認し、netsh、srvinfo、tlist を使用して問題のあるサービスやアプリケーションがないか確認します。 |
これらの問題を診断するために、Microsoft IT ではドメインベースのグループ ポリシーを使用して監査を有効にしました。上記の基本的なトラブルシューティングにより問題が解決できた場合は、ヘルプ デスクにより関連するデータがすべて収集され、Tier 2、3、および 4 サポートにこのデータがエスカレートされます。
前述の Microsoft ツールのほとんどは、オペレーティング システムに含まれており、オペレーティング システムのサポート ツールとして、またはリソース キットにより提供されています。
より詳細な診断を行う場合は、Oakley ログを有効にする必要がある可能性があります。Oakley ログは、セキュリティ アソシエーションの作成に使われたネゴシエーションについての詳細を記録します。詳細については、マイクロソフト サポート技術情報の資料 257225、「Windows 2000 での IPSec の基本的なトラブルシューティング」(http://support.microsoft.com/default.aspx?scid=kb;en-us;257225) (英語)を参照してください。
ベスト プラクティス
IPsec を使用した企業ドメインの分離を成功させるには、さまざまな決定を下す必要があります。IPsec ソリューションを展開する企業は、グループ ポリシーのデザイン、IPsec フィルタのデザイン、各展開ステップ、セグメントごとの措置、ドメインに参加していないコンピュータの処理方法、高可用性 (NLB) クラスタについて検討する必要があります。ここでは、企業が独自の IPsec ドメイン分離ソリューションをデザインするうえで参考にできる、Microsoft IT による推奨方法を説明します。
グループ ポリシーのデザイン
社内ネットワークにおいて IPsec を使用したドメイン分離を実現するためのグループ ポリシーをデザインする場合、Microsoft IT は以下の操作の実行をお勧めします。
| • | IT やビジネスユニットの IPsec テストに対応できるよう、すべての動作のグループポリシーを作成します。大規模なネットワークでは、例外ポリシーの管理に要する時間も無視できません。可能な限り、例外を結合して管理を単純化してください。セキュリティ グループと対応するポリシーは、ビジネスと IT のニーズを満たすための必要最低限の数にします。 |
| • | ポリシーごとに "グループポリシーの適用" アクセス制御エントリ (ACE) をフィルタするのは、限られたセキュリティユーザーグループのみにします。IPsec ポリシーの変更権限を持つ管理者は、IPsec の展開に対して全社に大きな影響を及ぼす可能性があるため、グループ ポリシーと IPsec ポリシーの管理を少数の管理者に制限することが重要です。 |
| • | 名前を付ける場合は、管理とトラブルシューティングが簡単になるように、ポリシーとグループの役割が分かる名前にします。さまざまなポリシーとセキュリティ グループがある状況では、どのポリシーがどのセキュリティ グループ用に作成されたかが簡単には分からなくなります。たとえば、"Secure Request" セキュリティ グループ用には、"Secure Request" グループ ポリシーを作成するようにします。 |
IPsec のデザイン
IPsec ポリシー、フィルタ、ルールを作成し、展開することで、Microsoft IT は IPsec のデザインについて多くの知識を得ました。
フィルタのレベル設定は、フィルタのデザインにおいて最も重要な部分です。複数のフィルタを重ね合わせて適用することはできないので、この点を考慮してサブネットを計画します。セキュア サブネットの一覧には、可能な限り大きなサブネットを使用するようにし、許可対象のサブネットには、可能な限り小さいサブネットを使用して、全体的にフィルタの数が少なくて済むようにします。理想的には、2 つのフィルタ リスト間でサブネットに開きがあるようにします。たとえば、最も小さいセキュア サブネット フィルタを /18 ネットワーク (サブネット マスク : 255.255.192.0) とし、最も大きい許可サブネット フィルタを /23 ネットワーク (サブネット マスク : 255.255.254.0) とします。続いて、試験的に要求モードを展開し、その後、特定のサブネットでセキュア要求モードを試験展開します。これは、サブネットが /19 〜 /22 (サブネット マスク : 255.255.224.0 〜 255.255.252.0) を使用するセキュア要求サブネット試験 (Secure Request Subnets Pilot) フィルタを追加することで実行できます。この方法であれば、すべてのフィルタを同時に使用でき、フィルタどうしが競合することはありません。フィルタ デザインの詳細については、「フィルタ デザインの課題」を参照してください。
その他の具体的なベスト プラクティスは、次のとおりです。
| • | 基本的なフィルタデザインには、"Me" ではなく "Any" を使用します。"Any" フィルタは、適用除外 IP アドレスが指定されていても、どのコンピュータでも動作が同じになります。"Me" フィルタは、ローカル コンピュータの IP アドレスが変更された場合、エラーになります。"Me" フィルタは、Windows XP および Windows Server 2003 用に最適化されていますが、Windows 2000 ではパフォーマンス上の問題を引き起こす可能性があります。 |
| • | セキュアサブネットには "Me <-> Any" ではなく "Any <-> Corporate subnet" ルールを作成します。これらのルールは、仮想 IP が構成されているプラットフォームも含め、すべての Windows プラットフォームに差異なく適用できます。また、"Me <-> Any" ルールが割り当てられたモバイル コンピュータは、互換性がない IPsec ポリシーが使用されている他のネットワークに接続する場合、IPsec を適切にネゴシエートできない可能性があります。 |
| • | 許可サブネットを管理します。除外サブネットは、IPsec ポリシーのセキュリティ ホールとなる可能性があります。IPsec ポリシーから除外する必要があるサブネットについては、他のテクノロジを使用してトラフィックを保護します。たとえば、Microsoft IT ではエクストラネット サブネットに対して承認されていない受信および送信トラフィックを許可しています。これらのサブネットは、ベンダやパートナーが特定のリソースにアクセスできるようにするため、特別に作成されたものです。このようなサブネットと社内ネットワーク間のトラフィックを保護するために、Microsoft IT はルーター ACL を使用しています。 |
| • | クラスタが使用する仮想 IP アドレスには "Any" ルールを使用します。"Me <-> Virtual IP address" を指定したルールを使用すると、クラスタ サーバーのポリシーに適合しなくなります。"Any <-> Virtual IP address" を使うことで、仮想 IP アドレスで IPsec を使用しなくても、IPsec を専用の IP アドレス上で使用できます。 |
| • | インフラストラクチャサーバーへの保護されていないトラフィックを許可します。クライアントはドメイン コントローラに接続して Kerberos チケットを取得する必要があるため、認証が完了するまで IPsec を使用できません。ドメイン コントローラおよび DHCP サーバーは、保護されていないトラフィックを許可する必要があります。また、Microsoft IT では、WINS サーバーおよび DNS サーバーとインターネットに接続するプロキシ サーバーへの保護されていないトラフィックも許可し、信頼されていないコンピュータが、境界コンピュータおよびインターネット リソースに接続できるようにしています。グローバル設定で IP アドレスおよびサブネットを使ってインフラストラクチャを除外するほうが、必要なプロトコルを 1 つずつ除外するよりも、管理オーバーヘッドが少なくてすみます。 |
| • | 既定の認証メカニズムには Kerberos を使用します。Kerberos は証明書に比べて構成の管理が少なくてすみます。Kerberos は、フォレストまたはドメイン間に双方向の信頼関係があり、信頼リンクの名前が NetBIOS 名ではなく完全修飾 DNS ドメイン名である場合、フォレスト間で使用できます。ネットワークがドメインに参加していないコンピュータや非 Windows コンピュータをサポートする必要がある場合は、証明書を使用する必要があります。 |
| • | グループポリシー ADM テンプレートを使用して NoDefaultExempt = 1 を設定します。この設定により、Kerberos および RSVP の除外が解除されます。この 2 つのプロトコルは、通常除外する必要はありません。この設定では、ブロードキャストおよびマルチキャスト トラフィックは除外されたままになり、IKE も許可されます。 |
| • | ICMP プロトコルを許可します。IPsec は簡単にトラブルシューティングできない可能性があります。ICMP トラフィックを許可することで、より具体的な IPsec の問題のトラブルシューティングに先立ち、基本的なネットワーク接続の検証が容易になります。また、ICMP は、ホスト間で実行されるパケット サイズの低レベルのネゴシエーションである PMTU 検知にも必要です。 |
| • | ポートまたはプロトコルによる保護を最小限にします。できるだけ "All IP" フィルタを使用します。複数のポートを指定するフィルタを定義すると、明確な通信が失敗することがあります。これは、IPsec の仕様によるものです。すべての IP トラフィック通信を保護するポリシーが適用されているコンピュータが、特定の 1 ポートしか保護しない別のコンピュータと通信する場合に、この別のコンピュータのポリシーが定義されていない他のポートに接続するとこの接続は失敗します。ポートの指定をせずに特定のアドレスへのすべての IP トラフィックを保護することで、大幅にポリシーを簡素化できるほか、セキュリティも強化できます。 |
| • | "Any <-> Any"フィルタは使用しないようにします。この種のフィルタは、Windows 2000 では使用できません。 |
| • | カスタムポリシーには IPsec Default Response ルールを使用しないようにします。Default Response ルールでは、ICMP も含め、特定のポートやプロトコルを指定できません。 |
展開オプション
IPsec を展開して社内ネットワークのセグメント化するにはさまざまな方法があります。各種の方法を評価し、社内ネットワーク環境に最適な方法を選択することをお勧めします。社内ネットワークへの展開プロセスの段階に応じて、それぞれ適した展開オプションがあります。
| • | サブネット単位での展開 : Microsoft IT では、まず IPsec ポリシーを個々のサブネットに対して展開しました。セキュア要求モードに切り替えると、これらのポリシーは適切に機能しませんでした。これは、サブネット上のワークグループ コンピュータや他の非 IPsec クライアントが必要なリソースに接続できなくなってしまったためです。これは予想された状態でしたが、問題はロールアウト中にこのレベルの影響がエンド ユーザーに及ぶことでした。サブネット単位での IPsec ポリシーの展開を成功させるには、社内ネットワーク内のデータ フローを完全に把握しておく必要があります。 |
| • | セキュリティグループ単位での展開 : セキュア要求ポリシーの試験展開の段階では、Microsoft IT は、セキュリティ グループとサブネット固有の展開の両方を使用して、IPsec を社内ネットワークに展開しました。セキュリティ グループを使用すると、コンピュータ アカウントの管理の面ではオーバーヘッドが発生しますが、比較的簡単にコンピュータの種類ごとに専用の IPsec ポリシーを作成できます。境界コンピュータは、1 つのセキュリティ グループとして管理できます。機密性の高いビジネス リソースは、より厳格な IPsec ポリシーを使って保護できます。保護レベルの異なるセグメントにリソースを分ける場合は、セキュリティ グループによる展開を検討することをお勧めします。 |
| • | ドメイン単位での展開 : IPsec をネットワークに展開し管理する方法としては、IPsec グループ ポリシーをドメインに追加する方法が最も簡単です。ドメイン内のすべてのコンピュータに適用できる 1 つのポリシーを作成でき、このポリシーだけでインフラストラクチャ サーバーへのアクセスを確保し、他のアクセスを保護できる場合は、ドメイン単位での展開が最適です。ただし、Microsoft IT では、展開時に発見したさまざまな既知の問題を考慮し、まず別の展開オプションを使用して問題を発見および解決すると同時に、サポート チームが十分な時間をかけて IPsec 関連の問題を処理する効率的な方法を開発できるようにすることをお勧めします。ドメインの IPsec ポリシーが 1 つですむ場合の最大のメリットは、必要に応じて、非常に簡単に新しいポリシーをドメイン全体に展開できることです。これは、新種のウィルスや攻撃が発生した場合に、きわめて短時間で感染を阻止できるため便利です。 |
推奨展開手順
IPsec を企業ネットワークに展開する場合は、以下の手順での実施をお勧めします。
| • | 要求モード IPsec を試験展開します。例外のみで、保護ルールをまったく指定していない IPsec ポリシーをすべてのドメイン コンピュータに展開します。これにより、これまで使われていた、互換性のないと考えられるローカルの IPsec ポリシーが確実に削除されます。続いて、企業ネットワーク内の 1 つのサブネットに保護ルールを追加します。たとえば、"Any <-> Subnet #1、All IP、Request Security" などのルールを作成します。 |
| • | 要求モード IPsec を展開します。要求モードの試験展開で発見された問題を解決したら、社内ネットワークで使用するサブネットをさらにポリシーに追加して、展開を完了させます。 |
| • | セキュア要求 IPsec ポリシーを試験展開します。試験転換に使用するセキュリティ グループを作成して、いくつかのコンピュータをこのグループにまとめます。セキュア要求 IPsec ポリシーをこのセキュリティ グループの GPO に適用します。セキュリティ グループにこの GPO の読み取りと適用のアクセス許可を付与して、テストを行います。サブネットの場合はトラブルシューティングが難しいため、この手順ではセキュリティ グループを使用することをお勧めします。 |
| • | セキュア要求 IPsec ポリシーを展開します。他のコンピュータをセキュア要求ポリシーの適用を許可するセキュリティ グループ GPO に追加して、セキュア要求 IPsec ポリシーを他のコンピュータにも適用します。展開上の既存の問題のほとんどが解決されたら、ポリシーをドメインのすべてのコンピュータに適用できます。 |
Microsoft IT は、社内ネットワークへの展開は段階的に行うことをお勧めします。まず、少数のサブネットまたはセキュリティ グループに展開し、技術上の問題を特定します。ネットワーク全体に展開する前に、十分に時間をかけて問題を解決または分析することをお勧めします。ほとんどの問題が解決されるまで、ドメイン全体への展開は行わないようにします。
ドメインに参加していないクライアント
可能であれば、IPsec 展開には Kerberos のみを使用するようにします。Kerberos を使用すると、社内ドメインの分離に伴う管理作業を簡素化できます。既にネットワークを Active Directory、Kerberos、およびグループ ポリシーを使用して管理している場合は、公開キー基盤を追加してドメインに参加していないコンピュータを管理すると、管理オーバーヘッドが発生します。
前述のとおり、Microsoft ではドメインに参加していないクライアントのグループをいくつかサポートしています。Microsoft IT は前述したさまざまなケースに合わせて、専用のセキュリティ グループを作成し、これを境界コンピュータとすることで、必要なリソースへのアクセスを提供しています。グローバルな IPsec ポリシーの例外を作成する必要があるかどうかについては、十分に検討することをお勧めします。ほとんどの社内ネットワークには、ドメインに参加できないデバイスがあります。このようなコンピュータには、特別に境界コンピュータを作成することが、信頼されていないコンピュータからのリソースへのアクセスを管理する最適な方法である可能性があります。
Microsoft では、基本の IPsec 認証プロセスに Kerberos を使用しています。これにより、ネットワーク全体を Active Directory やグループ ポリシーなどのドメイン管理ツールを使用して管理でき、個々のドメイン内でさらに細かくセキュリティ グループを定義してより厳格なセキュリティを適用することができます。
それでも、Microsoft では、企業ドメインに参加していない Windows コンピュータからの VPN 接続をサポートし、SecureNet へのアクセスを提供するようにしました。これらのドメインに参加していないコンピュータは、Microsoft の資産ではない、主に従業員やパートナー、ベンダが企業ネットワークへのアクセスに使用しているコンピュータです。これらのコンピュータをサポートするため、Microsoft の IPsec 展開では、Kerberos 以外に証明書ベースの認証もサポートしています。
IPsec と NLB
クラスタを IPsec で保護するよりも、高可用性を確保するほうが重要である場合は、クラスタの仮想 IP アドレスを IPsec ポリシーから除外し、IPsec を使用しなくてもクラスタにクライアントが接続できるようにすることを検討してください。
前述のとおり、Windows Server 2003 の IPsec は NLB にも使用できますが、これは常に新しい接続が任意のクラスタとの間に確立される場合に限ります。既存の接続は、クラスタ内のサーバーの 1 つが停止した場合、破棄される可能性があります。
Microsoft では、高い可用性が求められる業務上重要なサービスについては、IPsec 展開から除外しています。
まとめ
Microsoft では、ビジネス要件を基に、IPsec ポリシーをまず適切なソリューションとして適用しました。社内ネットワークのセキュリティ強化策としてドメイン分離を検討した際に、これらのソリューションの使用が検討され、規模の小さいサブネットを使って最初の展開が行われました。これにより、さらに規模の大きい展開を行う前に、問題を発見および解決できました。Microsoft での IPsec 展開の第 1 段階は、2003 年 3 月に完了し、160,000 台以上のコンピュータが IPsec に対応するようになりました。技術的な問題が特定され、修正または分析されました。この段階で接続性が失われたことはなく、Microsoft 社内のネットワーク トラフィックの 70% 以上が ESP でカプセル化されました。
IPsec 展開の第 2 段階では、全社へのセキュア要求モードの展開が行われました。サブネットではなくドメインを使用して IPsec を展開することで、第 2 段階は予定よりも早く 2004 年 4 月に完了できました。ヘルプデスクへの影響は最小限ですみ、IPsec 関連の問い合わせは当初の予想をはるかに下回って 1 週間あたり 90 件未満でした。現在は展開が完了しているので、問い合わせ件数は急速に少なくなるものと思われます。
Microsoft の社内ネットワークでは、約 208,000 台のコンピュータがセキュア要求モードで実行されるようになりました。これらのコンピュータには、信頼されていないコンピュータからアクセスできなくなり、ワームや攻撃を受けるリスクが大幅に縮小されました。
今後は、境界コンピュータの種類をさらに細かく見直し、さらに緩和措置が必要かどうかを見極める予定です。また、特定の "サーバー保護" シナリオにおいては暗号化を使用することを検討しています。その他、Microsoft IT では、エクストラネット環境での IPsec の使用についても調査を進めています。このような計画を除けば、プロジェクトは完了し、保守段階に移行していると言えます。
詳細情報
ドメインおよびサーバー分離のシナリオ別のガイダンスについては、「IPsec とグループ ポリシーを使用したサーバーおよびドメインの分離」(http://go.microsoft.com/fwlink/?linkid=33945) を参照してください。
Microsoft 製品またはサービスの詳細については、Microsoft Sales Information Center、(800) 426-9400 (アメリカ国内)、Microsoft Canada Information Centre、(800) 563-9048 (カナダ国内) にお問い合わせください。米国 50 州とカナダ以外のお客様は、最寄りの Microsoft オフィスまでご連絡ください。World Wide Web 上の情報については、次のアドレスにアクセスしてください。
www.microsoft.com/japan/technet/itsolutions/msit/(英語)
このドキュメントに関する質問、コメント、ご提案、またはマイクロソフト IT ショウケースについてのお問い合わせがある場合には、下記のアドレスに電子メールをご送信ください。