セキュリティ保護された ASP.NET アプリケーションの構築 : 認証、認定、および通信のセキュリティ保護 第 4 章 セキュリティで保護された通信

  • [アーティクル]

patterns and practices home

J.D. Meier, Alex Mackman, Michael Dunner, and Srinath Vasireddy
Microsoft Corporation

November 2002
日本語版最終更新日 2003 年 3 月 17 日

適用対象:
    Microsoft® ASP.NET

全体の概要については、「セキュリティ保護された ASP.NET アプリケーションの構築」の開始ページを参照してください。

要約 : この章では、インターネットおよび企業イントラネット上のクライアントとサーバーがやり取りするデータにおいて、メッセージの機密性と整合性を確保することを目的とした 2 つのコア テクノロジについて説明します。2 つのコア テクノロジとは、SSL と IPSec です。ここでは、リモートのサービス コンポーネントとの通信においてセキュリティを確保するために使用する RPC 暗号化についても説明します。

目次

セキュリティによる保護とは
SSL/TLS
IPSec
RPC 暗号化
ポイント ツー ポイント セキュリティ
IPSec と SSL の選択
ファームの作成と負荷分散
まとめ

多くのアプリケーションが、ネットワークを介し、機密性のあるデータをエンド ユーザーとやり取りしたり、中間アプリケーション ノードとの間で送受信したりします。機密データには、認証に使用される資格情報、クレジット カード番号、銀行の取引明細などがあります。転送データの漏えいや不正な改変を防止するためには、送信元と送信先を結ぶチャネルのセキュリティが確保されている必要があります。

セキュリティ保護された通信とは、次の 2 つの特性が保証されるものをいいます。

  • プライバシー データの秘密性が保証され、ネットワーク監視ソフトウェアなどを利用したデータ傍受が不可能であることを意味します。プライバシーを確保する手段として、通常、暗号化を使用します。
  • 整合性 セキュリティ保護された通信チャネルには、送信中のデータを過失または故意 (悪意) による改変から保護する機能も必要です。整合性を確保する手段として、通常、MAC (メッセージ認証コード) を使用します。

この章では、以下の通信セキュリティ テクノロジについて説明します。

  • SSL/TLS (Secure Sockets Layer / Transport Layer Security) このテクノロジが最も多く使用されるのは、ブラウザと Web サーバー間のチャネルのセキュリティを確保する場合です。ただし、Web サービス メッセージや Microsoft® SQL Server® 2000 を搭載したデータベース サーバーとの通信に対するセキュリティ確保の手段としても使用できます。
  • インターネット プロトコル セキュリティ (IPSec) トランスポート レベルの通信セキュリティ ソリューションを提供するテクノロジであり、アプリケーション サーバーやデータベース サーバーなど、2 台のコンピュータ間で送信されるデータのセキュリティを確保するために利用できます。
  • RPC (リモート プロシージャ コール) 暗号化 DCOM (分散 COM) で使用される RPC プロトコルは、クライアントとサーバーの間で送信されるデータ パケットを暗号化する認証レベル (パケット プライバシー) を提供します。

セキュリティによる保護とは

Web 要求が複数のアプリケーションの物理的な層を通過していくとき、いくつかの通信チャネルを経由します。一般的な Web アプリケーションの展開モデルを図 4.1 に示します。

図 4.1 一般的な Web 展開モデル

この展開モデルでは、要求が 3 つの異なるチャネルを通過します。クライアントと Web サーバーのリンクは、インターネットまたは企業イントラネットを経由するもので、通常 HTTP を使用します。残り 2 つのリンクは、企業ドメイン内の内部サーバーどうしを結ぶものです。種類は異なっていても、3 つのリンクすべてに潜在的なセキュリティ上の問題があります。HR や機密性の高い従業員データを扱う給与アプリケーションなど、純粋なイントラネット ベースのアプリケーションの多くは、層の間で機密データを転送します。

図 4.2 は、SSL、IPSec、RPC 暗号化を組み合わせてチャネルのセキュリティを確保する方法を示したものです。

図 4.2 通信セキュリティが確保された一般的な Web 展開モデル

どのテクノロジを使用するのかは、転送プロトコル、エンド ポイント テクノロジ、環境的な条件 (ハードウェア、オペレーティング システムのバージョン、ファイアウォール) などの、さまざまな点を考慮に入れて決定します。

SSL/TLS

SSL/TLS を使用する目的は、クライアントとサーバー間に暗号化された通信チャネルを確立することです。セキュリティ保護されたチャネルを確立するためのハンドシェイク メカニズムの詳細については、以下の Microsoft サポート技術情報の Knowledge Base の文書を参照してください。

  • 257591「[IIS]SSL (Secure Sockets Layer) ハンドシェイクの概要」
  • 257587「[IIS] SSL ハンドシェイクでのサーバー認証プロセスに関する説明」
  • 257586「[IIS]SSL ハンドシェイクを使用したクライアント認証プロセスに関する説明」

SSL の使用

SSL を使用するときには、以下の点に注意してください。

  • SSL を適用した場合、クライアントは HTTPS プロトコルを使用し (https:// で始まる URL を指定)、サーバーは TCP ポート 443 でリッスンします。
  • SSL を有効にした場合は、アプリケーションのパフォーマンスを監視する必要があります。 SSL はデータの暗号化と解読に複雑な暗号化関数を使用するため、アプリケーションのパフォーマンスが低下します。最大のパフォーマンス低下は、公開キーと秘密キーを使用した非対称型の暗号化を実行する最初のハンドシェイク中に発生します。それ以降 (セキュリティ保護されたセッション キーが生成され、交換された後)、非対称型より高速の対称型暗号化によってアプリケーション データが暗号化されます。
  • SSL を使用するページは、テキストの量を減らし、単純なグラフィックスを使用することによって、最適化する必要があります。
  • SSL の使用に伴うパフォーマンスの低下は、セッションを確立するときに最大となるため、接続がタイムアウトを起こさないようにする必要があります。そのためには、ServerCacheTime レジストリ エントリの値を大きくします。詳細については、Microsoft サポート技術情報の Knowledge Base の文書 247658「[IIS]SSL サーバーとクライアントのキャッシュ要素の設定方法」を参照してください。
  • SSL では、Web サーバー (SQL Server 2000 との通信に SSL を使用する場合はデータベース サーバー) にサーバー認証用の証明書をインストールする必要があります。サーバー認証用の証明書のインストールについては、このガイドの「パート IV : 参照」の「Web サーバー上で SSL を設定する方法」を参照してください。

IPSec

IPSec は、アプリケーション サーバーとデータベース サーバーなどの 2 台のコンピュータ間で送信するデータのセキュリティを確保するために使用します。暗号化、整合性、認証のサービスはトランスポート レベルで実装するため、IPSec はアプリケーションに対して完全に透過的です。アプリケーション間相互の通信は、TCP ポートおよび UDP ポートを使って、通常どおり行われます。

IPSec を使用すると、以下のことが可能となります。

  • 2 台のコンピュータ間で送信するデータの暗号化によって、メッセージの機密性を保証します。

  • 2 台のコンピュータ間でメッセージの整合性を保証します (データの暗号化なし)。

  • 2 台のコンピュータ (ユーザーではなく) の相互認証を行います。たとえば、特定のクライアント コンピュータ (アプリケーション サーバー、Web サーバーなど) からの要求だけを受け付けるポリシーを設定することによって、データベース サーバーのセキュリティを確保することができます。

  • 相互に通信できるコンピュータを制限できます。また、通信を特定の IP プロトコルと TCP/UDP ポートだけに制限することもできます。

    メモ IPSec は、本来、アプリケーション レベルのセキュリティを担うものではありません。現在は、縦深防御メカニズムとして使用したり、安全性の低いアプリケーションのセキュリティをコードの変更なしに強化するために用いたりするほか、TLS 以外のプロトコルをネットワーク回線攻撃から保護する目的にも使用されています。

IPSec の使用

IPSec を使用するときには、以下の点に注意してください。

  • IPSec は、認証と暗号化のどちらの目的にも使用できます。
  • コード上で設定を変更するための IPSec API はありません。IPSec の設定は、Microsoft 管理コンソール (MMC) のローカル セキュリティ ポリシーで IPSec スナップインを使用して行います。
  • Microsoft Windows? 2000 に付属の IPSec では、すべての種類の IP トラフィックについてセキュリティを確保することはできません。ブロードキャスト、マルチキャスト、インターネット キー交換、Kerberos などのトラフィックのセキュリティ対策には使用できません (Kerberos は元来、セキュリティで保護されたプロトコルです)。
    詳細については、Microsoft サポート技術情報の Knowledge Base の文書 253169「[NT]IPSec により保護されるトラフィックと保護されないトラフィック」を参照してください。
  • どのような場合に IPSec を適用するのかを指定するには、IPSec フィルタを使用します。 IPSec ポリシーのテストには IPSec モニタを使用します。IPSec モニタ (Ipsecmon.exe) では、どの IPSec ポリシーが有効であるかと、コンピュータ間にセキュリティで保護されたチャネルが確立されているかどうかを確認できます。
    詳細については、以下の Microsoft サポート技術情報の Knowledge Base の文書を参照してください。
    • 313195「[HOW TO] IPSec モニタの使用方法」
    • 231587「IP セキュリティ モニタ ツールを使用した IPSec 通信の表示」

2 つのサーバー間に信頼関係を確立するには、IPSec と相互認証を使用します。この場合、証明書を使用して両方のコンピュータを認証します。
詳細については、以下の Microsoft サポート技術情報の Knowledge Base の文書を参照してください。

ファイアウォールによって分離された 2 台のコンピュータ間で行う通信のセキュリティ対策として IPSec を使用する必要がある場合は、ファイアウォールでネットワーク アドレス変換 (NAT) が使用されていないことを確認してください。IPSec を NAT ベースのデバイスと組み合わせて使用することはできません。
詳しい説明と設定手順については、Microsoft サポート技術情報の Knowledge Base の文書 233256「HOW TO Enable IPSec Traffic through a Firewall」と、このガイドの「パート IV : 参照」の「2 つのサーバー間の通信を IPSec で保護する方法」を参照してください。

RPC 暗号化

RPC は、DCOM で使用する基本的なトランスポート メカニズムです。RPC では、認証なし (データ保護なし) からパラメータ状態の完全な暗号化まで、さまざまなレベルの認証を設定できます。

セキュリティ レベルが最も高い認証 (RPC Packet Privacy) では、各リモート プロシージャ コールのパラメータ状態 (および DCOM メソッド呼び出し) を暗号化します。RPC 暗号化のレベルには 40 ビットと 128 ビットがあり、クライアント コンピュータとサーバー コンピュータに搭載された Windows のバージョンによって異なります。

RPC 暗号化の使用

RPC 暗号化を使用する必要性が最も高いのは、Web ベースのアプリケーションとリモート コンピュータ上のサービス コンポーネント (Enterprise Services サーバー アプリケーション内) 間で通信を確立する場合です。

このような場合に RPC Packet Privacy 認証 (および暗号化) を使用するには、クライアントとサーバーの両方の構成が必要になります。クライアントとサーバーの間で最高レベルのネゴシエーションが実行され、この結果、クライアント側とサーバー側の設定のうちレベルの高い方が使用されることになります。

サーバー側の設定は、サービス コンポーネント アセンブリ内で .NET 属性を使用するか、展開時にコンポーネント サービス管理ツールを使用して、アプリケーション レベル (Enterprise Services アプリケーション) で定義できます。

クライアントが ASP.NET Web アプリケーションまたは Web サービスである場合、クライアントが使用する認証レベルは、machine.config 内で 要素の comAuthenticationLevel 属性を使用して設定します。この設定は、Web サーバー上で動作するすべての ASP.NET アプリケーションにおいて既定の認証レベルとなります。

詳細情報

RPC 認証レベルのネゴシエーションとサービス コンポーネント設定の詳細については、「第 9 章 Enterprise Services セキュリティ」を参照してください。

ポイント ツー ポイント セキュリティ

ポイント ツー ポイント通信のシナリオは、以下の 3 種類に大別できます。

  • ブラウザと Web サーバー
  • Web サーバーとリモート アプリケーション サーバー
  • アプリケーション サーバーとデータベース サーバー

ブラウザと Web サーバー

ブラウザと Web サーバーの間で送信される機密データのセキュリティを確保するには、SSL を使用します。SSL の使用が必要となるのは、次のような状況です。

  • フォーム認証を使用しており、ログオン フォームから Web サーバーに送信されるクリア テキストの資格情報に対するセキュリティが必要な場合。
    このシナリオでは、SSL を使用して、ログオン ページだけでなくすべてのページへのアクセスにセキュリティを施し、最初の認証プロセスで生成される認証 Cookie をクライアントとアプリケーションのブラウザ セッションが終了するまで安全に保つ必要があります。

  • 基本認証を使用しており、Base64 でエンコードされたクリア テキストの資格情報に対するセキュリティが必要な場合。
    SSL を使用して、最初のログオン ページだけでなくすべてのページへのアクセスにセキュリティを施す必要があります。基本認証では、アプリケーションに対するすべての要求 (最初の要求だけではない) と共に、クリア テキストの資格情報が Web サーバーに送信されるからです。

    メモ Base64 は、バイナリ データを表示可能な ASCII テキストとしてエンコードします。暗号化とは異なり、Base64 はメッセージの整合性やプライバシーを保証しません。

  • アプリケーションがブラウザと Web サーバーの間でクレジット カード番号や銀行口座の取引明細などの機密データをやり取りする場合。

Web サーバーとリモート アプリケーション サーバー

Web サーバーとリモート アプリケーション サーバー間のトランスポート チャネルには、IPSec、SSL、RPC 暗号化のいずれかを使用したセキュリティ対策が必要です。使用するテクノロジは、プロトコルや環境条件 (オペレーティング システムのバージョン、ファイアウォールなど) に基づいて選択します。

  • Enterprise Services リモート サーバーがいくつかのサービス コンポーネントを (Enterprise Services サーバー アプリケーション内) をホストしており、それらのコンポーネントと直接通信する (したがって DCOM を使用する) 場合は、RPC Packet Privacy 暗号化を使用してください。
    Web アプリケーションとリモートのサービス コンポーネントとの間で RPC 暗号化を使用する方法については、「第 9 章 Enterprise Services セキュリティ」を参照してください。

  • Web サービス リモート サーバーが Web サービスをホストしている場合は、IPSec、SSL のいずれかを選択できます。
    Web サービスが、既に HTTP トランスポートを使用しているので、SSL を使用するのが一般的です。SSL では、2 台のコンピュータ間のトラフィックをすべて暗号化するのではなく、Web サービスとの間でやり取りするデータだけを暗号化することもできます。IPSec を使用すると、2 台のコンピュータ間のトラフィックがすべて暗号化されます。

    メモ メッセージ レベルのセキュリティ (データ暗号化を含む) は、GXA (Global XML Web Services Architecture) イニシアチブによって推進されており、詳細は WS-Security 仕様に記載されています。Microsoft では、メッセージ レベルのセキュリティ ソリューションを開発するためのツールとして Web Services Development Toolkit を提供しています。

  • .NET コンポーネント (.NET リモート処理を使用) リモート サーバーがいくつかの .NET コンポーネントをホストしており、それらのコンポーネントに TCP チャネル経由で接続する場合は、IPSec を使用することによって、通信リンクのセキュリティを確保できます。.NET コンポーネントを ASP.NET 内でホストする場合は、SSL を使用します (SSL は IIS を使用して構成します)。

アプリケーション サーバーとデータベース サーバー

アプリケーション サーバーとデータベース サーバーの間で送信されるデータのセキュリティを確保するには、IPSec を使用します。データベース サーバーが SQL Server 2000 を搭載していて、アプリケーション サーバーに SQL Server 2000 ネットワーク ライブラリをインストールしている場合は、SSL を使用できます。後者の方法では、データベース サーバーのコンピュータ ストアにサーバー認証証明書をインストールする必要があります。

以下の状況では、データベース サーバーとのリンクにセキュリティ対策を施す必要があります。

  • Windows 認証を使用せずに、データベース サーバーに接続する場合。たとえば、SQL Server へのアクセスに SQL 認証を使用したり、非 SQL Server データベースに接続したりする場合などです。こうしたケースでは、資格情報がクリア テキストで転送されるため、セキュリティ上の大きな問題となります。

    メモ SQL Server へのアクセスに Windows 認証を使用することには、いくつかの重要な利点があります。その 1 つは、資格情報がネットワークを介して転送されないことです。Windows 認証と SQL 認証の詳細については、「第 12 章 データ アクセス セキュリティ」を参照してください。

  • アプリケーションが機密データ (給与データなど) をデータベースに送信したり、データベースから取得したりする場合。

SQL Server に対する SSL の使用

データベースへのチャネルに対するセキュリティ対策として SSL を使用する場合は、以下の点に留意してください。

  • SSL が動作するためには、データベース サーバー コンピュータのコンピュータ ストアにサーバー認証証明書をインストールする必要があります。クライアント コンピュータには、サーバー証明書を発行した (信頼できる) 機関から発行されたルート証明機関証明書も必要です。
  • クライアントには、SQL Server 2000 接続ライブラリがインストールされている必要があります。古いバージョンや汎用ライブラリは動作しません。
  • SSL は、TCP/IP (SQL Server の推奨通信プロトコル) と名前付きパイプでのみ動作します。
  • サーバーを構成して、クライアントからの接続をすべて強制的に暗号化させることができます。
  • クライアント側では、以下のことが可能です。
    • すべての送信データを強制的に暗号化させます。
    • 接続文字列を使用して、接続ごとに暗号化を適用するかどうかをクライアント アプリケーションに選択させます。

IPSec の場合とは異なり、クライアントまたはサーバーの IP アドレスが変わったときに構成を変更する必要はありません。

詳細情報

SQL Server における SSL の使用の詳細については、以下の資料を参照してください。

IPSec と SSL の選択

IPSec、SSL のどちらを使用するのかを決定するときには、以下の点を検討してください。

  • IPSec ではコンピュータ間のすべての IP トラフィックについてセキュリティを確保できるのに対し、SSL は個々のアプリケーションのセキュリティに対応します。
  • IPSec は、コンピュータ全体に対する設定であり、個々のネットワーク接続の選択的な暗号化はサポートしません。ただし、サイトを分割し、部分ごとに SSL を使用するかどうかを指定できます。また、SSL を使用して SQL Server に接続する場合は、接続ごとに SSL を使用するかどうかをクライアント アプリケーションから指定できます。
  • IPSec はアプリケーションに対して透過的であるため、HTTP、FTP、SMTP など、IP 上で動作するセキュリティで保護されたプロトコルで使用できます。ただし、SSL/TLS はアプリケーションと緊密に結合されます。
  • IPSec は、暗号化だけでなくコンピュータの認証にも使用できます。このことが特に重要な意味を持つのは、信頼されるサブシステムを使用する場合です。このようなシナリオでは、データベースは、特定のコンピュータで動作する特定のアプリケーションからの固定 ID に対して許可を与えます。IPSec を使用し、特定のアプリケーション サーバーだけがデータベースへの接続を許されるようにすると、他のコンピュータからの攻撃を防ぐことができます。
  • IPSec では、両方のコンピュータが Windows 2000 またはそれ以降の Windows を搭載している必要があります。
  • SSL は NAT ベースのファイアウォールを介した通信に使用できますが、IPSec はそのような通信には使用できません。

ファームの作成と負荷分散

複数の仮想 Web サイトで SSL を使用する場合は、一意の IP アドレスまたは一意のポート番号を使用する必要があります。複数のサイトで同じ IP アドレスまたはポート番号を使用することはできません。IP アドレスを負荷分散機能のサーバー アフィニティ設定と組み合わせる場合は、複数のサイトの IP アドレスが同じであってもかまいません。

詳細情報

詳細については、Microsoft サポート技術情報の Knowledge Base の文書187504 「SSL を使用すると HTTP 1.1 ホスト ヘッダーがサポートされない」を参照してください。

まとめ

この章では、SSL、IPSec、RPC 暗号化を組み合わせて、分散アプリケーションのエンド ツー エンド通信セキュリティ ソリューションを構築する方法について説明しました。要点は以下のとおりです。

  • インターネット上および企業イントラネット内で転送されるデータを保護するためには、チャネルのセキュリティが重要になります。
  • Web ブラウザと Web サーバー、Web サーバーとアプリケーション サーバー、アプリケーション サーバーとデータベース サーバーのそれぞれのリンクごとに、セキュリティ要件について検討します。
  • セキュリティで保護された通信は、プライバシーと整合性を保証します。否認不能性に対する防御にはなりません (この目的にはクライアント証明書を使用します)。
  • チャネル セキュリティのテクノロジには、SSL、IPSec、RPC 暗号化があります。RPC 暗号化は、アプリケーションが DCOM を使用してリモートのサービス コンポーネントと通信する場合に使用します。
  • SQL Server との通信に SSL を使用する場合は、アプリケーション側で接続ごとに暗号化を実行するかどうかを選択できます。
  • IPSec は、2 台のコンピュータ間をフローするすべての IP トラフィックを暗号化します。
  • どのセキュリティ メカニズムを使用するのかは、転送プロトコル、オペレーティング システムのバージョン、ファイアウォールを含むネットワーク要素などの条件に基づいて決定します。
  • セキュリティで保護された通信とパフォーマンスは相いれない要素です。アプリケーションの要件に適したセキュリティ レベルを選択することが必要です。