セキュリティ ベストプラクティス
ローカル通信システムの IP セキュリティ
最終更新日: 2004年1月23日
Joanie Rhine
マイクロソフト ソリューション フレームワーク
メモ このホワイトペーパーは、ベスト プラクティス シリーズの一部です。企業セキュリティのベストプラクティスには、このシリーズを構成するホワイトペーパー一覧が掲載されています。セキュリティ構成要素アーキテクチャも参照してください。
トピック
このドキュメントの目的
セキュリティのリスク
カスタマ プロファイル
企業の IP セキュリティの事例
IPSec の概要
Windows 2000 での IPSec ポリシーの実装
まとめ
参考資料
このドキュメントの目的
MSF のホワイトペーパー「エンドシステムにおけるデータセキュリティとデータ可用性」では、IP ネットワークに対するさまざまなセキュリティの脅威について概説します。セキュリティ違反には、スニッフィングなどの受動的な攻撃から、なりすましやサービス拒否 (DoS) など、より悪意のある故意による攻撃までさまざまなものがあります。1999 年に Computer Security Institute (CSI) と連邦捜査局 (FBI) が実施した「コンピュータ犯罪/セキュリティ調査」によると、機密情報への許可されていないアクセスや機密情報の盗難による被害額は年平均で $4,486,000 にもなります。また、同調査によると、許可されていないアクセスの 7 割が企業内部のものであると見られています。内部に潜む敵を見過ごさないことが重要です。これらの攻撃は、必ずしもハッカーの行為や企業に恨みを持つ従業員によるものではありませんが、情報の喪失の原因が事故または過失である可能性があることは確実です。それでもなお、内部から情報を保護することや複数のセキュリティメカニズムを使用することは、多層防御の基本です。
セキュリティのリスク
顧客の環境を保護する場合、物理的なセキュリティ、ファイアウォール、強力なパスワードなどを考慮することが重要です。ただし、この手法では、企業の「内部」からの攻撃に対する保護としては不十分です。データはデータベースやディスクに保存されているときは保護されているとしても、多くのアプリケーションではデータやパスワードはテキスト形式で転送されます。つまり、周辺のセキュリティがいかに強力でも、正規の内部ユーザーがネットワーク上で転送されるデータやパスワードを入手することは阻止できません。そのため、問題は「情報の否認防止、完全性、信頼性、および機密性という形で、いかにしてセキュリティを確保するか」ということです。
さらに、現在多くの顧客はインターネットの機能を接続に利用しています。トンネリングプロトコルを使用すると、リモートユーザーまたは独立したネットワークがローカルの ISP に接続でき、インターネット接続を使用して別のネットワークへアクセスできます。この手法では、既存の IP ネットワークをリモートアクセスの媒体として使用します。これにより、企業はコストのかかるポイントツーポイント接続や専用の WAN テクノロジの使用を回避できます。従来のダイヤルアップ回線を使用したリモートアクセスでは、確立される接続が通常の電話回線を使用したポイントツーポイント接続だったため、それほど大きな問題にはなりませんでした。ユーザー (またはルーター) は、リモートアクセスデバイスに直接接続されているアクセスポイントの番号にダイヤルしていました。悪意のある攻撃を行うには、電話回線上で転送されるデータ自体にアクセスする何らかのメカニズムが必要でした。これらのリモートアクセスによる接続は、企業の電話回線ネットワークを介して行われることが前提だったため、データを覗き見ることは現在よりもはるかに困難でした。興味深いことに、ポイントツーポイントのダイヤルアップ接続の場合、インターネットと同様に固有のセキュリティはありませんが、一般のユーザーがダイヤルアップ接続を介した対話を盗聴する手段を見つける可能性はあまり高くありませんでした。これは、機器の局所性や関連するコンポーネントのユーザー補助の欠如など、主にその設計が原因でした。ロサンゼルスのクライアントとシアトルのサーバーの間でのダイヤルアップ接続を例にとってみましょう。この場合、悪意のあるユーザーがフロリダにいる場合は、配線やスイッチへアクセスするメカニズムがありません。ただし、インターネットの場合、コンポーネントの知識がより一般的で、これらのコンポーネントへは距離に関係なくアクセスできるため、データの傍受ははるかに容易に達成できます。そのため、インターネットを通じたトンネリング技術の対費用効果や利便性を顧客が享受するには、これらのリスクからデータを保護する技術が利用可能で実装されていなければなりません。
カスタマ プロファイル
これから紹介する顧客は、約 5,000 人のユーザーを有する大手金融機関で、以後「バンク」と呼びます。ユーザーの多く (約 3,500 人) はサンフランシスコの本部にいます。その他 1,500 人のユーザーは、全米各地の支店に点在します。バンクでは、最近 Microsoft Windows 2000 へのドメインの移行を完了し、単一ドメインフォレストの Active Directory ディレクトリサービスアーキテクチャを実装しました。すべてのクライアントコンピュータは Windows NT 4.0 から移行され、2 ヵ月で完了する予定です。
各支店は Active Directory サイトとして定義され、最低 2 個のドメインコントローラがあり、そのうちの 1 つはグローバルカタログサーバーの役割を果たします。サンフランシスコの本部が数個のファイルサーバー、プリントサーバー、およびさまざまな専用アプリケーションの拠点となります。大部分の支店では、1 日中本部のデータへ頻繁にアクセスします。リーノーとオーランド以外の支店は、256 Kbps 以上の専用 WAN を使用して本部に接続します。Windows 2000 へのアップグレード以前、リーノー支店とオーランド支店は、ポイントツーポイントトンネリングプロトコル (PPTP) を使用したルーターツールーターの仮想プライベートネットワーク (VPN) により本部へ接続していました。現在両支店では、レベル 2 トンネリングプロトコル (L2TP) とインターネットプロトコルセキュリティ (IPSec) の利点と欠点への関心を示しています。
バンクには、データセキュリティとデータの可用性に関する 2 つの主な目標があります。
機密財務データを SQL データベースで維持管理し、ネットワーク上で許可されたユーザーにより頻繁に更新する。機密財務データには、いくつかの得意先の財務に関する機密情報や合併吸収などの情報も含まれます。
L2TP/IPSec を使用してリーノー支店およびオーランド支店と本部を接続する。
このホワイトペーパーの目的は、データが企業ネットワークまたはインターネット上で転送される際に、そのデータが本物で改ざんされておらず、機密データであることをバンクが確認できるための枠組みを提供することです。
企業の IP セキュリティの事例
IP セキュリティ (IPSec) は、ネットワーク転送時のデータを保護するためのモデルを提供します。IPSec は、Requests for Comments (RFCs) 2401-2411 により定義された Internet Engineering Task Force (IETF) 標準です。IP プロトコルまたはネットワーク層がセキュリティを提供するよう修正されるのは初めてのことです。IPSec では、認証、完全性、および必要に応じて機密性が提供されます。送信側のコンピュータでは、データセキュリティで保護してから転送し、受信側のコンピュータでは、データを受信後にデコードします。暗号化キーに応じて、IPSec をコンピュータ、サイト、ドメイン、アプリケーション通信、ダイヤルアップユーザー、およびエクストラネット通信の保護に使用できます。厳しい管理と周辺のセキュリティを使用した総合的なセキュリティ計画の一部として、IPSec は転送後のデータを確実に保護します。ただし、ディスクへ保存されたデータは保護されません。次の項では、IPSec のしくみ、プロトコルおよび標準のサポートを含む IPSec の詳細について個別に検証するとともに、バンクがセキュリティのモデルとして IPSec を実装した経緯についても見ていきます。
ネットワークセキュリティという用語は、広範な意味を持ち、しばしばあいまいです。許可または拒否するトラフィックに関する物理的な制限を意味するのでしょうか。手紙に記載される署名のように、送信されるデータの信憑性を確認することでしょうか。あるいは、受信したデータが改ざんされておらず、傍受されていないことを信頼する機能のことでしょうか。実際、これらすべてがネットワークセキュリティの一面です。IPSec は、ネットワーク上でのデータ転送に関する次の 3 つの主な問題に対応します。
信憑性および否認防止
完全性
機密性
IP を介して転送されるデータには、固有のセキュリティがありません。前述したとおり、IP トラフィックの傍受、IP アドレスの偽造などの悪意のある行為は比較的容易に達成できます。受信するパケットが正式な送信者からのものかどうか、またはデータが転送中に改ざんされていないかどうかは保証できません。
今日の企業環境では、企業ネットワークとインターネットの両方でデータを送信できる安全な方法が必要です。IPSec では、L2TP などのテクノロジと同様、この機能を実現できます。このように言うと、「なぜすべてをセキュリティで保護しないのか」と疑問を抱く人もいるでしょう。残念ながら、問題はそれほど単純ではありません。IPSec 計画の意思決定を確実なものにするには、相互運用性、パフォーマンス、影響、簡単さなど、すべての問題を検証する必要があります。これらの疑問をうまく検証し、IPSec がビジネスにもたらす利点を知るには、まずこのテクノロジに関する予備知識を得ることが必要です。
IPSec の概要
名前のとおり、IPSec は IP データグラムのセキュリティを提供するものです。大部分のネットワークがセキュリティで保護されておらず、ネットワーク上でデータが転送される際にそのデータを保護するための追加コンポーネントが必要であるという前提に基づき、IPSec では送信元の認証、完全性チェック、および内容の機密性などの機能を提供します。
データのセキュリティ保護は何ら新しいものではなく、セキュリティの提供方法もさまざまです。一部のアプリケーションでは、アプリケーション層で Secure Sockets Layer (SSL) や Transport Layer Security (TLS) などのセキュリティサービスを提供します。これらのプロトコルの場合、アプリケーションがその基本となるセキュリティプロバイダに対して呼び出しを行うことで、これらのサービスを提供します。Windows 2000 の場合、アプリケーションからその基本となるセキュリティコンポーネントへのアクセスには、セキュリティサポートプロバイダインターフェイス (SSPI) から共通のインターフェイスが提供されているなど、実装の詳細をほとんど抽象化できますが、アプリケーションは少なくとも「セキュリティに依存」する必要があります。IPSec の場合、セキュリティをネットワーク層に下げることで、その必要性がなくなります。これにより、アプリケーションは基本となるセキュリティインフラストラクチャから独立した状態を保つことが可能になります。IP データグラムは、最初にトラフィックを生成したアプリケーションに関係なくセキュリティで保護されます。言い換えれば、アプリケーションは IPSec に依存しないということです。セキュリティ規則は、実行中のアプリケーションに関係なく管理者が定義できます。つまり、IPSec はアプリケーションに対して透過的であるということです。その影響には極めて大きなものがあります。IPSec には、インターネットを含む IP ネットワーク上で転送されるデータを認証し、状況に応じて安全に暗号化する機能があります。IPSec では、コンピュータとネットワークの間でエンドツーエンドのセキュリティを提供します。
IPSec のしくみ
IPSec は、IP データグラムのセキュリティを提供するものです。IPSec はエンドツーエンドのセキュリティです。これは、送信者と受信者のみがセキュリティに関する詳細を認識できる必要があるということです。両者の間にあるデバイスは、データの転送時に暗号やシークレットキーなどを認識する必要がありません。これは、次の 2 つの理由から、バンクのような顧客にとって重要なことです。まず、データが転送されるネットワークがセキュリティで保護されていないという理由です。これは、多くの場合、基本となるネットワークインフラストラクチャを変更する必要がないということです。次に、実装が比較的単純であるという理由です。通信を行うホストのみが IPSec を認識する必要があります。ルーターなどの中間デバイスは IPSec の存在を認識する必要がありません。顧客にとっては、莫大なコストの投資や大幅なネットワークインフラストラクチャの変更を行わずに、ハイレベルのセキュリティを実装できるということです。ただし、ファイアウォールや特定の種類のトラフィックをブロックするその他のデバイスの場合、特別な注意事項がありますが、これについては後述します。
Windows 2000 の場合、IETF の IPSec 作業グループで定義された業界標準に基づいて IPSec を実装します。IPSec は、セキュリティで保護する必要のあるトラフィックを識別し、その後定義されたレベルでセキュリティを適用することにより機能します。そのため、たとえばバンクは、ソース IP アドレスやホスト名など一定の基準を満たすトラフィックを識別し、その後適切なレベルのセキュリティを識別した情報に基づき選択することができます。
IPSec を使用すると、特定のホスト、ネットワークルーター、またはファイアウォール間、またはホストとルーターまたはファイアウォール間で転送されるデータをセキュリティで保護できます。業界標準の認証アルゴリズムや暗号化アルゴリズムを使用することで、IPSec は既存のテクノロジを活用し、ネットワークトラフィックを保護するための総合的な手法を提供します。IP データグラムの保護は、認証ヘッダー (AH) とカプセル化セキュリティペイロード (ESP) の 2 つのプロトコルにより行われます。AH はデータの完全性を保証するためのもので、リプレイ防止サービスによる保護を行い、ホストを確実に認証します。ESP は機能的には AH と同様のものですが、状況に応じてデータの機密性も実現します。AH と ESP の両方で上記の機能を実装するための特定の暗号化アルゴリズムは提供されていませんが、その代わりに既存の暗号化アルゴリズムや認証アルゴリズムを利用します。
Windows 2000 の IPSec コンポーネントは、主に次の 4 つです。
IPSec プロトコル
セキュリティアソシエーション
セキュリティポリシー
IPSec ドライバ
IPSec プロトコル
AH と ESP の 2 つのプロトコルが機能すると、データの認証、完全性、および機密性を実現できます。これらのプロトコルは、IP ペイロード全体または IP ペイロードの上級層のプロトコルのみを保護するよう構成できます。これらのプロトコルを個別または組み合わせて使用すると、バンクは簡単な認証および完全性チェックを実現できるだけでなく、ネットワーク転送時にデータを暗号化することもできます。
認証ヘッダー
RFC 2402 で定義されている AH は、鍵付ハッシュにより転送時のデータの完全性を実現します。現在サポートされているハッシュアルゴリズムは、HMAC MD5 および HMAC SHA です。HMAC (Hashed Message Authentication Code) は、受信者が確認できるデータのデジタル署名を作成するためのシークレットキーアルゴリズムの 1 つです。MD5 では 128 ビットの値が生成され、SHA では 160 ビットの値が生成されます。一般的には SHA の方がセキュリティの強度が高く、MD5 の方が高速です。AH では IP ヘッダーと IP ペイロードがハッシュされますが、ホップ数など変更されることが前提となっている部分のデータグラムは含まれません。ヘッダーとペイロードの両方がハッシュされるため、AH ではアドレス指定情報を検証でき、その結果 IP データが改ざんされていないことが保証されます。
リプレイ防止サービスも AH の機能の 1 つです。シーケンス番号の連続的な追加と受信ウィンドウのスライドにより、AH と ESP の両方でリプレイ防止サービスを確実に実行できます。
AH ではデータ暗号化という形での機密性は実現できません。これは ESP の機能です。
カプセル化セキュリティ ペイロード
ESP は RFC 2406 で定義されているインターネットプロトコルです。単独または AH と組み合わせて使用することで、ESP はデータの完全性と暗号化を実現します。ESP でサポートされている暗号化アルゴリズムは、DES-CBC、56 ビット DES、および 3DES です。また、ESP はHMAC MD5 および HMAC SHA を使用して完全性チェックを行います。リプレイ防止サービスは AH の場合と同じ方法で行われます。
認証、完全性、および暗号化のアルゴリズムは、IPSec 通信エンドポイント間でセキュリティネゴシエーションの一部として決定されます。このプロセスをセキュリティアソシエーションといいます。これについては次の項で説明します。
どちらのプロトコルも転送モードとトンネルモードという 2 つのモードで使用できます。AH と ESP の基本操作は、完全性のためにデータが署名されること以外は、どちらの操作モードでも同じです。転送モードは、通信エンドポイントと暗号化エンドポイントが同じ場合にパケットを保護するために使用します。トンネルモードでは、暗号化エンドポイントが他のネットワークの代わりにセキュリティを提供するゲートウェイの役割を果たします。この場合、IPSec パケットが認証、検証、および復号化されてから通信エンドポイントへ転送されます。シナリオでは、ルーターモードを使用してルーターツールーター VPN を作成することができます。VPN およびルーティングの詳細については、『Windows 2000 Server リソースキット 1 ネットワークガイド』の第 9 章「仮想プライベートネットワーキング」を参照してください。転送モードでは、ヘッダーがデータグラムの IP 部分と上級層のヘッダーとの間に置かれます。トンネルモードでは、IP パケット全体が別の IP データグラムでカプセル化され、IPSec ヘッダーが 2 つの IP ヘッダー間に置かれます。
トンネルモードの IPSec を単独で使用してもリモートアクセスはサポートできますが、完全な IPSec の VPN を構築するにはまだ課題が残ります。現在最も重要な課題は、異なるベンダーの実装との相互運用性と、マルチキャストとブロードキャストトラフィックをトンネリングする機能がないことです。特に後者の課題は、IPSec のトンネルモードを使用したルーターツールーターの VPN 接続の作成機能に影響します。現時点での解決策は、リモートアクセス接続のトンネリングに L2TP/IPSec を使用することです。L2TP と IPSec の実装については後述します。
IPSec の Windows 2000 への実装方法により、バンクは異なるレベルの IPSec を特定の要件を持つ分野に適用することが可能です。これにより、低レベル、中レベル、または高レベルのセキュリティが必要な分野を定義し、それに応じて IPSec を柔軟に適用できます。たとえば、すべての分野で認証と完全性が必要で、特定の高レベルセキュリティの分野のみに機密性が必要であるというように、バンクが意思決定を行うことも可能です。この場合、アプリケーションは次のようになります。
機密性を必要とする分野では、ESP と AH の両方が必要になります。データの暗号化には、コンピュータのコストがかさむので注意が必要です。ESP の暗号化機能を使用する計画の場合、すべてこの点に注意する必要があります。
機密性を必要としない分野では、AH だけで十分に認証と完全性を実現できます。
セキュリティ アソシエーション
IPSec を使用して 2 つのホストが通信できるようにするには、認証方法や暗号化アルゴリズムなど、まずそのセッションのガイドラインを確立する必要があります。セキュリティアソシエーション (SA) は、採用する特定のセキュリティ設定に関する両ホストの合意事項とみなされます。たとえば、ホスト A がホスト B と通信を行う場合、両者で特定のセキュリティ設定について合意する必要があります。完全性に関しては AH または ESP を使用するのか、認証には Kerberos または証明書を使用するのか、などです。
セキュリティアソシエーションは一方的なものです。つまり、送受信トラフィックのセキュリティパラメータを定義するには、個々の SA を確立する必要があります。さらに、ホストが 1 つまたは複数の IPSec ホストと同時に通信する場合、複数のアソシエーションが存在します。セキュリティアソシエーションは、各 IPSec コンピュータのデータベースに格納されます。データベース内では、各 SA がすべての AH ヘッダーまたは ESP ヘッダーに含まれる SPI (Security Parameter Index) により識別されます。受信側はこの SPI を使用して受信パケットの処理に使用する SA を決定します。
IETF では、関連するキー交換に対するセキュリティアソシエーション確立の枠組みが定義されています。インターネットキー交換 (IKE) では、セキュリティアソシエーションの作成を管理し、情報のセキュリティ保護に使用するキーを生成します。IKE では、Diffie-Hellman アルゴリズムを使用してキーを生成、管理します。Diffie-Hellman の手法を使用すると、両者でデータの暗号化と復号化に使用する対称キーを生成できます。対称暗号化方式では、キーを交換するためのセキュリティで保護されたチャネルが必要ですが、IKE ではこのチャネルが提供されています。
注 : セキュリティアソシエーションが確立されると、通信をブロックするか、または SA のネゴシエーションを必要とすることなくデータを送信するよう、IPSec ポリシーを構成できます。
.gif)
セキュリティ ポリシー
IP セキュリティの基本は、特定の種類のトラフィックを識別し、そのトラフィックがセキュリティで保護されているかどうかを確認することです。ここで紹介されているバンクでは、各支店と VPN 接続を介した企業ネットワークの間にあるトラフィックをセキュリティで保護する必要があると考えています。IPSec の場合、認証されていること、改ざんされていないこと、および場合によっては暗号化されていることが「セキュリティで保護されている」ことを意味します。セキュリティで保護するトラフィックと実装するセキュリティのレベルに関する決定事項は、セキュリティポリシーで定義します。Windows 2000 では、IPSec ポリシーをコンピュータ、サイト、ドメイン、または組織単位に関連付けるポリシーベースの管理機能が提供されています。ポリシーは組織が必要とする、あるいは組織が希望するセキュリティに基づき定義する必要があります。
IPSec ポリシーの実装は、「規則」の使用により制御されます。この規則により、IPSec ポリシーの呼び出し方法とタイミングが IP トラフィックの送信元、送信先、および種類に応じて制御されます。これらの規則には、特定の種類のトラフィックを識別し、識別情報と一致する場合にセキュリティの処理を適用するためのフィルタが含まれます。IPSec ポリシーの作成および適用方法の詳細については、このホワイトペーパーで後述する「Windows 2000 での IPSec ポリシーの実装」を参照してください。
規則のプロパティは次のとおりです。
.gif)
[IP フィルタ一覧] では、この規則を使用してセキュリティで保護するトラフィックが定義されます。
[フィルタ操作] では、IP フィルタ一覧の一致情報に基づき行われるセキュリティ処理のリストが表示されます。
[認証方法] では、Kerberos、証明書、または共有シークレットを使用して各コンピュータを認証するかどうかを指定します。
[トンネルの設定] では、規則がトンネルに適用されるかどうかを指定します。
[接続の種類] では、管理者はこの規則の適用先となる接続を指定できます。選択できる接続は、[すべてのネットワーク接続]、[ローカルエリアネットワーク (LAN)]、または [リモートアクセス] の 3 つです。
[すべてのネットワーク接続] の場合、ポリシーの適用先となるホストで、すべての受信トラフィックと送信トラフィックを検証する必要があります。たとえば、財務データベースを維持管理する SQL サーバーでこのポリシーを設定すると、このサーバーとのすべての接続を検証し、実行するセキュリティ処理を決定する必要があります。
[ローカルエリアネットワーク (LAN)] の場合、このホストに接続されるすべての LAN トラフィックを検証する必要があります。
最後に、[リモートアクセス] の場合は、リモートアクセス接続を介するサーバーとのすべての通信を検証します。
Windows 2000 の場合、自動的に「既定の応答規則」が含まれます。これにより、セキュリティ通信を要求するコンピュータに対して規則が定義されていない場合でも、そのコンピュータがセキュリティで保護された通信の要求に応答できます。たとえば、ホスト B がホスト A 殻セキュリティで保護された通信を要求しているが、ホスト A がホスト B に対して定義した受信フィルタを持たない場合、既定の応答規則が呼び出され、ホスト A とホスト B の間でセキュリティのネゴシエーションが行われます。規則は定義されているすべてのポリシーに対して指定されますが、有効に設定されている必要はありません。
IPSec ドライバ
IP ポリシーが定義されている場合、IPSec ドライバは起動時にロードされます。IPSec ドライバの役割は、すべての IP トラフィックを監視し、IPSec ポリシーの要件に基づきパケットを保護することです。IPSec ドライバの具体的な役割は次のとおりです。
送受信される IP パケットを、特定の IP ポリシーフィルタと一致するかどうか確認する。
新しい接続のセキュリティアソシエーションを要求する。
Kerberos や証明書などの認証方法を指定するポリシーを実装する。
セキュリティアソシエーションを更新または削除する。
.gif)
プロセスの概要
IP セキュリティのプロセスは次のとおりです。
IP パケットと IP セキュリティポリシーの一部である IP フィルタを照合する。たとえば、送信フィルタは、ポート番号 23 (Telnet) に送信されるすべての TCP トラフィックをセキュリティで保護するよう指定します。
IKE がデータベースに格納されているセキュリティアソシエーションとネゴシエートする。
IPSec ドライバが送信パケットを受信すると、定義されたセキュリティメソッドが適用されます。
注 : IPSec のコンポーネントの詳細については、『Windows 2000 Server リソースキット 6 TCP/IP ガイド』の第 8 章「IPSec (インターネットセキュリティポリシー)」を参照してください。
.gif)
ビジネス要件
IPSec の基本については理解できましたので、バンクに対するソリューションとして IPSec を評価できます。IPSec を評価するには、顧客の現在の環境をはじめ、相互運用性、パフォーマンス、既存のインフラストラクチャへのテクノロジの統合などの特別な問題について検証する必要があります。そうすることにより、IPSec を使用して理想的なセキュリティソリューションを実現する方法を決定できます。
さらに、IPSec の利点を確立後、セキュリティで保護する必要のある分野や必要なセキュリティのレベルなどのビジネス要件を検討する必要があります。
前述したとおり、バンクにはいくつかのセキュリティ要件があります。バンクの最初の要件は、特定のサーバーでアクセスされネットワーク上で更新される機密情報が本物であるかどうか、否認が防止されているかどうか、および機密情報であるかどうかを保証することです。これには、情報の送信元および送信先のホストを認証する機能、転送時のデータの完全性を保証する機能、および暗号化サービスを提供する機能が含まれます。
第 2 に、本部とインターネットを通じて接続しているリーノーとオーランドに支店があることです。これにより、バンクは各支店と本部の間にポイントツーポイント接続を使用しなくても、各支店間で広範な接続を実現できます。両者のエンドポイントに必要なのは、インターネットとローカルネットワークへの接続のみです。ただし、インターネットは固有のセキュリティがほとんどないパブリックネットワークです。バンクがインターネット使用の利便性を生かして遠隔地と本部を接続し、なおかつ最高レベルのセキュリティを確保するには、どうすればよいでしょうか。
IPSec と Windows 2000 のテクノロジを使用すれば、これらの要件をすべて満たすことができます。次の項では、バンクが IPSec と Windows 2000 を使用してこれらの目標を達成する方法について検証していきます。
Windows 2000 での IPSec ポリシーの実装
一般的に、IPSec ポリシーを実装すると、コンピュータ、ドメイン、または組織単位のセキュリティ要件が満たされます。バンクのセキュリティ要件を決定すると、IPSec ポリシーを適用するレベルについて知ることができます。バンクに対して指定されたシナリオでは、本部の財務データを格納するセキュリティで保護されたサーバーと通信するすべてのホストの認証が望まれます。このデータは、静的 IP アドレスを割り当てられた物理的に安全なサーバーに格納されています。公開キー基盤 (PKI) はすでにイントラネット通信に対して内部的に実装されているため、バンクは x.509 証明書を使った IPSec ホストの認証を希望しています。また、このデータは IPSec により提供されている暗号化サービスを使って保護する必要があります。バンクの通信はすべて米国内にあるため、3DES 暗号化を使用すると最強のアルゴリズムを確保できます。また、リーノーとオーランドに支店があることにも注意が必要です。これらの支店では、現在 PPTP によるルーターツールーターの VPN 接続を使用しています。この接続のバックボーンとしてインターネットのようなパブリックネットワークを使用する場合の固有のセキュリティに関するリスク、および PPTP ではホストを認証できないことを考え、バンクでは IPSec による認証、完全性、および機密性を確保するためにレイヤ 2 トンネリングプロトコル (L2TP) を実装することにしました。L2TP の詳細および利点については後述します。
この時点で、バンクのニーズを識別し、実装の準備が整いました。Windows 2000 では、IPSec の実装をローカルまたは Active Directory のグループポリシー実装の一部として作成および管理するためのインターフェイスが提供されています。
定義済みポリシー
既定では、Windows 2000 には 3 つの定義済みポリシーが含まれています。それらは、クライアント、セキュリティで保護されたサーバー、およびサーバーです。バンクが最初に行う作業は、既定のポリシーを適用するかどうか、またはニーズを満たすためにカスタムポリシーを作成する必要があるかどうかを決定することです。既定では、事前に構成されたポリシーはアクティブになっています。ポリシーは次のとおりです。
クライアント (応答のみ) : このオプションを使用すると、クライアントが既定の応答規則の設定に応じてセキュリティを要求するコンピュータに応答できます。このポリシーを有効にすると、クライアントがセキュリティを要求することはなくなりますが、接続先のホストに応じて IPSec とネゴシエートします。これにより、バンクはセキュリティで保護された通信の要求に応じ、なおかつ自ら要求を開始しないようクライアントコンピュータを構成できます。
セキュリティで保護されたサーバー (セキュリティが必要) : このポリシーを使用すると、サーバーは接続を許可する前に IPSec とのネゴシエーションを要求することができます。このポリシーにより、セキュリティで保護されていない受信トラフィックを許可することになりますが、送信トラフィックは常に保護されます。データを常に保護する必要のあるバンクのシナリオの場合、このポリシーを実装できます。
サーバー (セキュリティが必要) : このポリシーを使用すると、サーバーは IPSec とのネゴシエーションを要求できますが、相手側のコンピュータが IPSec 対応でない場合は、セキュリティで保護されていない通信を許可することになります。バンクはこのポリシーを使用して、IPSec非対応のコンピュータとの相互運用性を犠牲にすることなく、IPSec 対応のコンピュータ間でセキュリティを実装できます。
ローカル IPSec ポリシーを表示するには、次の手順に従ってください。
Microsoft 管理コンソールを開き、[IP セキュリティポリシーの管理] スナップインを追加します。
[スタート]、[ファイル名を指定して実行] の順にクリックし、「MMC」と入力してから [OK] をクリックします。
[MMC] で [コンソール]、[スナップインの追加と削除]、[追加] の順にクリックします。
[IP セキュリティポリシーの管理]、[追加] の順にクリックします。
.gif)
.gif){kind=link}
多くの場合、規定のポリシーにより必要なセキュリティが提供されています。ただし、ポリシーをカスタマイズするか、または新しいポリシーを作成して、さらにセキュリティ要件を満たすこともできます。
IPSec ポリシーをバンクで使用する
この時点で明らかなことは、バンクには IPSec とその関連テクノロジを使用すればサポートできる特定のセキュリティが必要であるということです。ただし、IPSec の実装戦略を開発するには、テクノロジ以上のものが必要です。IPSec を導入する前に、設計者は、顧客のためのテクノロジ開発を成功させるために必要な時間、労力、およびコストだけでなく、求められる諸機能についても検討する必要があります。さらに検討すべき問題は、次のとおりです。
パフォーマンスへの影響。IPSec の実装により、プロセッサの使用率、IP トラフィック、および IP パケットのサイズが増大します。
既存のネットワークにもたらされる影響。バンクの場合、実際に IPSec を使用する少数のコンピュータにおける追加処理能力とネットワークへの負荷よりも、セキュリティの問題が重要です。ただし、このことがすべての環境に当てはまるわけではありません。実装を完了するには、すべての事実を慎重に検討することが必要です。パフォーマンスが問題にならなければ、専用のネットワークカードが適切な解決策になる場合もあります。 1
ドメインのポリシーを作成する
ここまでで、次のことが完了しました。バンクのビジネスニーズを評価して関連するテクノロジを識別することにより、実装の準備が整いました。バンクでは、機密情報をホストするセキュリティで保護されたサーバーと、その機密データにアクセスするホストとの間にあるすべてのトラフィックが本物であり、改ざんされていなくて、暗号化されていることを保証する必要があります。認証には、x.509 証明書を使った既存の PKI を使用します。HMAC MD5 を使って完全性チェックを行い、3DES を使ってデータの暗号化を実装します。そのためには、Windows 2000 のグループポリシーを使って IPSec 規則を配布します。IPSec ポリシーは、ローカルコンピュータ、ドメイン、または組織単位の各レベルで実装できます。バンクで実装するポリシーは一部のサーバーのみに適用されるため、これらのサーバーを組織単位内に配置するのが賢明です。次に、ポリシーを組織単位に適用すると、サーバーは特定の組織単位にあるため、そのポリシーを適用できます。これにより、その他すべてのクライアントコンピュータ上での処理が不要になります。
その他に考慮すべき点は、クライアントコンピュータのみです。既定では、Windows 2000 環境のホストには IPSec が適用されません。ただし、クライアントがセキュリティで保護されたサーバーからセキュリティの要求があった場合に正しく応答できるようにするには、そのような命令を出すポリシーを適用する必要があります。ホストコンピュータは、証明書を使った認証の要求に応答し、目的の暗号化についてネゴシエートする必要があります。そのためには、証明書をサポートするよう既定のドメインポリシーを変更し、クライアントポリシーをドメインレベルで割り当てます。
既定のクライアントポリシーを割り当ておよび変更して証明書ベースの認証を可能にする
バンクでは、すべてのクライアント証明書を発行および維持管理する内部の証明機関 (CA) を実装しました。証明機関を指定するよう既定の応答規則を編集することにより、ポリシーを変更できます。
[クライアント (応答のみ) のプロパティ] にある [規則] タブの [フィルタ操作] 列で [既定の応答] を選択して [編集] をクリックします。
.gif)
[規則の編集のプロパティ] にある [認証方法] タブで、[追加] をクリックします。
.gif)
[新しい認証方法のプロパティ] で、[次の証明機関 (CA) からの証明書を使う] を選択して [参照] をクリックします。
任意の証明機関を選択して [OK] をクリックします。
注 : 証明機関を追加したら、不要な検証を行わなくても済むように、Kerberos 認証の前にその証明機関が追加されていることを確認します。
.gif)
[詳細] ペインで [クライアント (応答のみ)] ポリシーを右クリックして [割り当て] をクリックします。
.gif)
.gif){kind=link}
.gif){kind=link}
このポリシーを処理するホストコンピュータは、セキュリティで保護された通信の要求に応答し、セキュリティアソシエーションについてネゴシエートしますが、クライアントからこの要求がない場合は、セキュリティで保護された通信はこのホストで行われません。
IPSec を要求するようセキュリティで保護されたサーバーを構成する
次の手順では、証明書ベースの認証、完全性、および暗号化を必要とするサーバーのポリシーを構成します。さらに、このポリシーでは IPSec 非対応の通信は許可されません。これにより、ポリシーで指定されている信頼されたホストのみがアクセスを許可されます。
次の 3 つの手順に従って構成します。
第 1 に、認証に正規の証明書を要求するよう、セキュリティで保護されたサーバーの IPSec ポリシーを変更します。
第 2 に、任意のソースからサーバーに送信されるトラフィックを指定するフィルタを定義する必要があります。この手順は、[フィルタの追加] ウィザードを使用すれば簡単に行えます。これにより、任意の IP アドレスからこのコンピュータの IP アドレスへのトラフィックがこのポリシーの影響を受けるよう指定できます。セキュリティで保護されたサーバーの組織単位にあるコンピュータのみにこのポリシーを適用することにより、これらのコンピュータとの間で送受信されるすべてのトラフィックが本物であり、改ざんされておらず、暗号化されていることが保証されます。
第 3 に、バンクはさらに既定の暗号化アルゴリズムとして 3DES を実装することにしました。この変更もこのポリシーを使って行うことができます。
注 : 既定では、すべてのフィルタがミラーリングされています。これにより、送信元のアドレスと送信先のアドレスが逆になっているパケットもフィルタに一致するよう指定できます。IPSec ポリシーの構成の詳細については、『Windows 2000 Server リソースキット 6 TCP/IP ガイド』の第 8 章「IPSec (インターネットセキュリティポリシー)」を参照してください。
IPSec を VPN ソリューションとして実装する
バンクに対する第 2 の要件は、支店と本部の間でやり取りされるデータを保護するための VPN 戦略全般の一環として IPSec を実装することです。前述のとおり、IPSec を L2TP とともに使用すると、ルーターやゲートウェイの間だけでなくホストの間にあるトラフィックも保護できます。バンクによる VPN 上の IPSec の実装について見ていく前に、VPN の概念について簡単に説明します。
仮想プライベートネットワーク (VPN) を使用すると、インターネットなどの共有ネットワークまたはパブリックネットワーク上で 2 台のコンピュータ間の通信が可能になります。クライアント上では、この接続はポイントツーポイント接続として表示されます。VPN 上で転送されるデータは、パブリックネットワーク上でのルーティングを可能にするヘッダーによりカプセル化されます。VPN サーバーがパケットを受信すると、ヘッダーが削除されてパケットがプライベートネットワーク内の送信先へ転送されます。パブリックネットワークでは、このデータを送信するためのインフラストラクチャが提供されます。VPN は、ポイントツーポイントトンネリングプロトコル (PPTP) やレイヤ 2 トンネリングプロトコル (L2TP) など、さまざまなトンネリングプロトコルにより確立されます。L2TP/IPSec と PPTP の比較および推奨される使用方法については、次の表を参照してください。
| サポートされる機能 | PPTP | L2TP/IPSec |
|---|---|---|
| パスワードまたは RADIUS (リモート認証ダイヤルインユーザーサービス) によるユーザー認証 | サポート対象 | サポート対象 |
| スマートカードまたはトークンによるユーザー認証 | サポート対象、EAP の場合2 | サポート対象、EAP の場合 |
| ホストの認証 | サポート対象外、ユーザー認証のみ | サポート対象、x.509 証明書を使用する PKI の場合 |
| ネットワークアドレス変換 (NAT) 機能 | サポート対象 | 現時点ではサポート対象外 |
| IP プロトコル以外のプロトコル | サポート対象 | サポート対象 |
| トンネルクライアントの内部 IP アドレス | サポート対象 | サポート対象 |
| IP ブロードキャスト、マルチキャスト | サポート対象 | サポート対象 |
| 暗号化方式 | 40 ビットまたは 128 ビットの暗号化を行う Microsoft Point-to-Point 暗号化 (MPPE) | 40 ビット DES、56 ビット DES、および 128 ビットの暗号化を行う 3DES |
| 機能 | PPTP か L2TP/IPSec のどちらを使用するか |
|---|---|
| NAT サービスを必要とする場合 | PPTP |
| 最強のセキュリティが必要な場合 | L2TP/IPSec |
| Windows 9x および Windows NT との互換性が必要な場合 | PPTP |
| 暗号化技術のハードウェア高速化が必要な場合 | IPSec |
| ポリシーベースの実装を行う場合 | IPSec |