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

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

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

適用対象:
    Microsoft® ASP.NET

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

要約 : この章では、セキュリティで保護された .NET リモート処理のソリューションを実装する方法を説明します。

目次

.NET リモート処理のアーキテクチャ
.NET リモート処理のゲートキーパー
認証
認定
認証および認定のしくみ
システム リソースへのアクセス
ネットワーク リソースへのアクセス
認証用の資格情報をリモート オブジェクトに渡す
最初の呼び出し元をフローする
信頼されたサブシステム
通信のセキュリティ保護
ホスト プロセスを選択する
リモート処理と Web サービス
まとめ

.NET Framework はリモート処理インフラストラクチャとして、クライアントがリモートのアプリケーション ドメインおよびプロセスでホストされるオブジェクトや、リモート コンピュータのオブジェクトと通信することを可能にします。この章では、セキュリティで保護された .NET リモート処理のソリューションを実装する方法を説明します。

.NET リモート処理のアーキテクチャ

図 11.1 は、リモート オブジェクトが ASP.NET 内でホストされるときの基本的な .NET リモート処理のアーキテクチャを示しています。通信用の HTTP チャネルを組み合わせた ASP.NET ホストの使用は、セキュリティが重要な考慮事項である場合に推奨される方法です。これは、ASP.NET ホストを使用すると、リモート オブジェクトは ASP.NET と IIS に用意されている基本的なセキュリティ サービスを利用できるようになるためです。

使用可能なホストおよびチャネル タイプの範囲の詳細、および比較情報については、後の「ホスト プロセスを選択する」を参照してください。

図 11.1 .NET リモート処理のアーキテクチャ

クライアントは、イン プロセスのプロキシ オブジェクトと通信します。認証のための資格情報 (ユーザー名、パスワード、証明書など) は、リモート オブジェクトのプロキシを通じて設定されます。メソッドの呼び出しは、シンク チェインを通過して進み、ネットワークを通じてデータを送信する役割を持つトランスポート シンクに達します (シンク チェインには、データの暗号化などを実行するために、独自のカスタム シンクを実装することができます)。サーバー側では、呼び出しは同じパイプラインを通過してから、オブジェクトにディスパッチされます。

メモ この章の全体で使用されている "プロキシ" という用語は、クライアント側のプロセス内のプロキシ オブジェクトを指しており、これを通じてクライアントはリモート オブジェクトと通信します。"プロキシ" サーバーという用語と混同しないでください。

リモート処理のシンク

.NET リモート処理では、クライアントがリモート オブジェクトのメソッド呼び出しを実行すると、トランスポート チャネル シンク、カスタム チャネル シンク、およびフォーマッタ チャネル シンクが使用されます。

トランスポート チャネル シンク

トランスポート チャネル シンクは、クライアントとサーバー間でネットワークを通じてメソッド呼び出しを渡します。.NET には HttpChannel クラスと TcpChannel クラスが用意されていますが、このアーキテクチャは拡張性が高いので、独自のカスタム実装を組み込むことができます。

• HttpChannel このチャネルは、ASP.NET 内でリモート オブジェクトをホストするときに使用するように設計されています。このチャネルは HTTP プロトコルを使用して、クライアントとサーバー間でメッセージを送信します。
• TcpChannel このチャネルは、Microsoft® Windows® オペレーティング システムのサービスまたはその他の実行可能ファイル内でリモート オブジェクトをホストするときに使用するように設計されています。このチャネルは TCP ソケットを使用して、クライアントとサーバー間でメッセージを送信します。
• カスタム チャネル カスタム トランスポート チャネルは、任意の基本トランスポート プロトコルを使用して、クライアントとサーバー間でメッセージを送信することができます。たとえば、カスタム チャネルは名前付きパイプやメール スロットを使用できます。

トランスポート チャネル シンクの比較

次の表は、2 つの主要なトランスポート チャネル シンクを比較したものです。

表 11.1 TcpChannel と HttpChannel の比較

カスタム シンク

カスタム チャネル シンクは、クライアントとサーバー間で送信されるメッセージを修正するために、チャネル シンクのパイプライン内のさまざまな場所で使用することができます。暗号化および解読を行うチャネル シンクは、カスタム チャネル シンクの一例です。

フォーマッタ シンク

フォーマッタ シンクは、メソッド呼び出しを取得およびシリアル化して、ネットワークを通じて送信することが可能なストリームにします。.NET には、2 つのフォーマッタ シンクがあります。

• バイナリ フォーマッタ BinaryFormatter クラスを使用し、メソッド呼び出しをパッケージ化して、シリアル化されたバイナリ ストリームにします。バイナリ ストリームは、データをサーバーに送信するために、後で HTTP POST を使用してポストされます。バイナリ フォーマッタは、HTTP 要求の Content-Type を "application/octet-stream" に設定します。

  バイナリ フォーマッタのパフォーマンスは、SOAP フォーマッタよりも優れています。

• SOAP フォーマッタ SoapFormatter クラスを使用し、メソッド呼び出しをパッケージ化して SOAP メッセージにします。HTTP 要求では、コンテンツ タイプが "text/xml" に設定され、HTTP POST を使用してサーバーにポストされます。

ASP.NET 内でホストするときの要求の分析

リモート オブジェクトのエンドポイントは、http://someserver/vDir/remoteobject.soap のように、.rem または .soap というファイル拡張子で終わる URL でアドレス指定されます。リモート オブジェクト (拡張子 .rem または .soap ) への要求は、IIS によって受信されると IIS 内部で ASP.NET ISAPI 拡張機能 (Aspnet_isapi.dll) にマップされます。ISAPI 拡張機能は、要求を ASP.NET ワーカー プロセス (Aspnet_wp.exe) 内のアプリケーション ドメインに転送します。この一連のイベントを 図 11.2 に示します。

図 11.2 サーバー側の処理

図 11.2 は、以下の一連のイベントを示しています。

1. .soap または .rem の要求は、HTTP 上で受信され、Web サーバーの特定の仮想ディレクトリにマップされます。

2. IIS は、.soap または .rem のマッピングをチェックし、ファイル拡張子を ASP.NET ISAPI 拡張機能 (Aspnet_isapi.dll) にマップします。

3. ISAPI 拡張機能は、要求を ASP.NET ワーカー プロセス (Aspnet_wp.exe) 内のアプリケーション ドメインに転送します。これが、このアプリケーションに向けられた最初の要求である場合は、新しいアプリケーション ドメインが作成されます。

4. HttpRemotingHandlerFactory ハンドラが呼び出され、リモート処理インフラストラクチャは、サーバー側オブジェクト構成 (シングル コールまたはシングルトンのパラメータなど) を指定する Web.config の <system.runtime.remoting> セクションおよび <authorization> 要素の認定パラメータを読み取ります。

5. リモート処理インフラストラクチャは、リモート オブジェクトが含まれるアセンブリを配置し、インスタンス化します。

6. リモート処理インフラストラクチャは、HTTP ヘッダーとデータ ストリームを読み取り、リモート オブジェクトのメソッドを呼び出します。

   メモ このプロセスの間、ASP.NET は通常の順序でイベント ハンドラを呼び出します。必要に応じて、この 1 つまたは複数のイベント ハンドラを Global.asax 内に実装することができます。たとえば、BeginRequest、AuthenticationRequest、AuthorizeRequest などです。要求がリモート オブジェクトのメソッドに達すると、認証されたユーザーを表す IPrincipal オブジェクトは HttpContext.User および Thread.CurrentPrincipal に格納され、認定に使用することができます。たとえば、プリンシパル アクセス許可要求やプログラムによるロール チェックで使用します。

ASP.NET および HTTP チャネル

リモート処理自体には、セキュリティ モデルはありません。クライアント (プロキシ) とサーバー (リモート オブジェクト) 間の認証および認定は、チャネルおよびホスト プロセスによって実行されます。以下のホストとチャネルの組み合わせを使用することができます。

• カスタム実行可能ファイルと TCP チャネル この組み合わせには、セキュリティ機能は組み込まれていません。
• ASP.NET と HTTP チャネル この組み合わせでは、ASP.NET と IIS の基本的なセキュリティ機能を介した認証と認定を使用できます。

ASP.NET 内でホストされるオブジェクトは、ASP.NET と IIS の基本的なセキュリティ機能によって保護されています。これには、次のようなものがあります。

• 認証機能 Windows 認証は、Web.config 内で次のように構成されます。

  <authentication mode="Windows" />
  

  IIS での設定では、使用される HTTP 認証の種類が指定されます。

  共通の HTTP ヘッダーは、要求の認証に使用されます。リモート オブジェクトのプロキシを構成してクライアントの資格情報を渡したり、既定の資格情報を使用したりすることができます。

  フォーム認証と Passport 認証は、使用することができません。これは、これらの認証メカニズムの要件である Cookie にクライアントがアクセスできるようにする方法が、チャネルにないためです。また、フォーム認証と Passport 認証には、クライアントの対話処理が必要なログオン ページへのリダイレクトが必要です。リモートのサーバー側オブジェクトは、対話型処理の使用に対応するように設計されていません。

• 認定機能 クライアントは、標準の ASP.NET の認定機能を使用して認定されます。

  構成可能な認定オプションには、以下のようなものがあります。

  • URL 認定
  • ファイル認定 (後の「ファイル認定を使用する」で説明する特定の構成が必要です)

プログラムによる認定オプションには、以下のようなものがあります。

• プリンシパル アクセス許可要求 (宣言型および強制型)
• IPrincipal.IsInRole を使用した明示的なロール チェック

通信のセキュリティ保護機能 SSL と IPSec を単独、または併用して、クライアントとサーバー間のデータの転送をセキュリティで保護するために使用する必要があります。

詳細情報

• ASP.NET および IIS によって提供される認証機能および認定機能の詳細については、「第 8 章 ASP.NET セキュリティ」を参照してください。

• ASP.NET または IIS 内でオブジェクトをホストする方法の詳細については、Microsoft サポート技術情報の Knowledge Base の文書 312107「HOW TO: Host a Remote Object in Microsoft Internet Information Services」(英語情報) を参照してください。

.NET リモート処理のゲートキーパー

ASP.NET によってホストされるリモート オブジェクトが使用可能な、認証を行うポイント (ゲートキーパー) は以下のとおりです。

• IIS 匿名認証がオフになっていると、IIS はそのドメインまたは信頼されたドメインで認証することが可能なユーザーからの要求しか許可しません。また、IIS は IP アドレスおよび DNS のフィルタ処理を行います。
• ASP.NET

  • UrlAuthorizationModule アプリケーションの Web.config ファイル内の <authorization> 要素を構成して、アプリケーションにアクセスするユーザーおよびユーザー グループを指定することができます。認定は、HttpContext.User に格納されている IPrincipal オブジェクトに基づいています。

  • FileAuthorizationModule FileAuthorizationModule はリモート コンポーネントが使用できますが、後の「ファイル認定を使用する」に説明する特定の構成が必要です。

    メモ 偽装は、ファイル認定の動作には必要ありません。

    FileAuthorizationModule クラスは、要求されたファイルまたは URI (.rem や .soap など) に対してのみ、アクセス チェックを実行します。リモート オブジェクト内のコードによってアクセスされるファイルにはアクセス チェックを実行しません。

プリンシパル アクセス許可要求および明示的なロール チェック IIS と ASP.NET の構成可能なゲートキーパーに加えて、きめ細かなアクセス制御メカニズムとして、宣言型または強制型のプリンシパル アクセス許可要求を使用することができます。プリンシパル アクセス許可のチェックを行うと、現在のスレッドにアタッチされている IPrincipal オブジェクトによる定義に従って、個々のユーザー ID およびグループ メンバシップに基づき、クラス、メソッド、または個々のコード ブロックへのアクセスを制御することができます。

メモ ロール メンバシップの要求に使用されるプリンシパル アクセス許可のチェックは、ロール メンバシップをテストするための IPrincipal.IsInRole の呼び出しとは異なります。前者では、呼び出し元が、指定されたロールのメンバでない場合は例外が発生しますが、後者ではロール メンバシップを確認するためのブール値が返されるだけです。

Windows 認証では、ASP.NET は認証されたユーザーを表す WindowsPrincipal オブジェクトが HttpContext.User を使用して、現在の Web 要求に自動的にアタッチされます。

認証

ASP.NET Web アプリケーション クライアントと連動するリモート処理を使用するときは、Web アプリケーション内およびリモート オブジェクトのホストで認証が発生します。リモート オブジェクトのホストに使用可能な認証オプションは、ホストの種類によって異なります。

ASP.NET 内でホストする

ASP.NET 内でオブジェクトがホストされるときは、クライアント側のプロキシとサーバーとの間でメソッド呼び出しを渡すのに HTTP チャネルが使用されます。HTTP チャネルは、HTTP プロトコルを使用して、サーバーに対してリモート オブジェクト プロキシを認証します。

ASP.NET の内部でホストするときに使用可能な認証オプションの範囲は次のとおりです。

• IIS の認証オプション 匿名認証、基本認証、ダイジェスト認証、Windows 統合認証、および証明書認証

• ASP.NET の認証オプション Windows 認証、または、なし (カスタム認証を実装する場合)

  メモ .NET リモート処理では、フォーム認証と Passport 認証を直接使用することはできません。リモート オブジェクトへの呼び出しは、対話型処理用には設計されていません。リモート オブジェクトのクライアントが .NET アプリケーションである場合、Web アプリケーションはフォーム認証および Passport 認証を使用し、資格情報を明示的にリモート オブジェクトに渡すことができます。このようなケースは、後の「最初の呼び出し元をフローする」で詳しく説明しています。

Windows サービスでホストする

Windows サービス内でオブジェクトがホストされるときは、クライアントとサーバーとの間でメソッド呼び出しを渡すのに TCP チャネルが使用されます。この場合、RAW ソケット ベースの通信が使用されます。ソケットには認証が用意されていないため、サーバーがクライアントを認証する方法はありません。

この場合、リモート オブジェクトはカスタム認証を使用する必要があります。

カスタム認証

簡単なカスタム認証では、リモート オブジェクトはユーザー名とパスワードを受け付ける Login メソッドを公開できます。資格情報がストアと照らし合わせて検証され、ロールの一覧が取り出されて、その後の要求で使用するためにトークンがクライアントに送信されます。トークンは、サーバーで取り出されると、Thread.CurrentPrincipal に格納されている IPrincipal オブジェクトをロールを使用して作成するために使用されます。この場合、IPrincipal オブジェクトは認定の目的で使用されます。

これ以外のカスタム認証の例には、名前付きパイプなどの認証を行うプロセス間通信チャネルを使用するカスタム トランスポート チャネル シンクの作成や、Windows Security Service Provider Interface (SSPI) を使用して認証を実行するチャネル シンクの作成などがあります。

詳細情報

• Windows サービス内でオブジェクトをホストする方法の詳細については、このガイドの「パート IV : 参照」の「Windows サービスでリモート オブジェクトをホストする方法」を参照してください。

• シンクまたはシンク チェインの詳細については、MSDN ライブラリの .NET Framework のセクションで、"シンクとシンク チェイン" を検索して参照してください。

• SSPI を使用するカスタム認証ソリューションを作成する方法の詳細については、MSDN ライブラリの「.NET Remoting Security Solution, Part 1: Microsoft.Samples.Security.SSPI Assembly」(英語情報) を参照してください。

  メモ このドキュメントでの実装はサンプルであり、Microsoft でテストしたものではなく、またサポートもされていません。

認定

オブジェクトが ASP.NET によってホストされ、通信に HTTP チャネルが使用されているときは、認証および認定することが可能なクライアントは以下のメカニズムで管理することができます。

• URL 認定
• ファイル認定
• プリンシパル アクセス許可要求 (宣言型および強制型)
• コード内での IPrincipal.IsInRole のチェック

オブジェクトが Windows サービス内でホストされるときは、TCP チャネルでは認証を行いません。このため、カスタム認証を実行し、IPrincipal オブジェクトを作成して Thread.CurrentPrincipal に格納することによって認証を実行する必要があります。

このとき、以下に示すような宣言型のプリンシパル アクセス許可要求のチェックを使用して、リモート オブジェクトのメソッドに注釈を付けることができます。

[PrincipalPermission(SecurityAction.Demand, 
Role="Manager")]
void SomeMethod()
{
}

オブジェクトのメソッド コードでは、強制型のプリンシパル アクセス許可要求と、IPrincipal.IsInRole を使用する明示的なロール チェックを使用することもできます。

ファイル認定を使用する

Windows の組み込みのアクセス制御を使用し、セキュリティで保護することが可能な Windows リソースとしてリモート オブジェクトをセキュリティで保護する必要がある場合があります。ファイル認定 (Windows ACL を利用) を使用しない場合は、URL 認定しか使用できません。

FileAuthorizationModule を使用して、リモート オブジェクトのエンドポイント (.rem または .soap で終わる URL で識別) へのアクセスを認定するには、拡張子が .rem または .soap の物理ファイルをアプリケーションの仮想ディレクトリ内に作成する必要があります。

メモ 拡張子 .rem および .soap は、オブジェクトのエンドポイントへの要求を ASP.NET ISAPI 拡張機能 (aspnet_isapi.dll) にマップするために IIS によって使用されます。通常は、これらの拡張子の物理ファイルは存在しません。

.NET リモート処理のファイル認定を構成するには、以下の手順に従います。

1. objectUri と同じ名前 (RemoteMath.rem など) のファイルを、アプリケーションの仮想ディレクトリのルートに作成します。

2. 以下の行をファイルの先頭に追加し、ファイルを保存します。

   <%@ webservice class="YourNamespace.YourClass" ... %>
   

3. Windows エクスプローラを使用して、適切に構成された ACL をファイルに追加します。

   メモ objectUri は、サーバーのリモート オブジェクトの構成に使用される Web.config ファイルから取得することができます。<wellknown> 要素を探してください。以下に例を示します。

   <wellknown mode="SingleCall" objectUri="RemoteMath.rem" type="RemotingObjects.RemoteMath,
   RemotingObjects, Version=1.0.000.000 Culture=neutral, PublicKeyToken=4b5ae668c251b606"/>
   
   

詳細情報

• これらの認証のしくみの詳細については、「第 8 章 ASP.NET セキュリティ」を参照してください。
• プリンシパル アクセス許可要求の詳細については、このガイドの「パート I : セキュリティ モデル」にある第 2 章の「プリンシパル アクセス許可要求」を参照してください。

認証および認定のしくみ

.NET リモート処理を使用する多くのアプリケーションでは、アプリケーションの中間層でのビジネス機能を実現するためにリモート オブジェクトが使用されており、この機能は ASP.NET Web アプリケーションによって呼び出されます。このしくみを図 11.3 に示します。

図 11.3 ASP.NET Web アプリケーションによって呼び出されるリモート オブジェクト

この場合、Web アプリケーションが使用可能な IIS と ASP.NET ゲートキーパーは、クライアント側のプロキシへのアクセスをセキュリティで保護するために使用することができます。また、リモート アプリケーション サーバーの ASP.NET ホストが使用可能な IIS および ASP.NET ゲートキーパーは、リモート オブジェクトへのアクセスをセキュリティで保護するために使用できます。

.NET Web アプリケーションによってアクセスされるリモート オブジェクトの認証および認定のしくみは、実質的には 2 つ存在します。

• 呼び出し元を Web サーバーで認証および認定し、偽装を使用して呼び出し元のセキュリティ コンテキストをリモート オブジェクトにフローすることができます。これが偽装および委任のモデルです。

  この方法では、IIS の認証メカニズムを使用します。これは、Kerberos 認証、基本認証、フォーム認証 (後の 2 つの認証では、Web アプリケーションは呼び出し元の資格情報にアクセス可能) などであり、呼び出し元のセキュリティ コンテキストを委任したり、リモート オブジェクトのプロキシを使用して資格情報をリモート オブジェクトに明示的にフローしたりすることができます。

  構成可能なプログラムによる ASP.NET のゲートキーパー (URL 認定、ファイル認定、プリンシパル アクセス許可要求、.NET ロールなど) は、リモート オブジェクト内で呼び出し元を個別に認定するために使用できます。

• Web サーバーで呼び出し元を認証および認定し、信頼された ID を使用してリモート オブジェクトと通信することができます。これが信頼されたサブシステム モデルです。

  このモデルは、認証を Web アプリケーションに依存して、リモート オブジェクトを呼び出す前に呼び出し元を正しく認定します。Web アプリケーションから送出された要求が、信頼された ID からリモート オブジェクトに受信されると、先に進むことを許可されます。

詳細情報

• 偽装および委任、信頼されたサブシステム モデルの詳細については、「第 3 章 認証と認定」の「認証メカニズムの選択」を参照してください。
• リモート処理で最初の呼び出し元を使用する方法の詳細については、後の「最初の呼び出し元をフローする」を参照してください。
• リモート処理で、信頼されたサブシステム モデルを使用する方法の詳細については、後の「信頼されたサブシステム」を参照してください。

システム リソースへのアクセス

ASP.NET によってホストされるリモート オブジェクトから、システム リソース (イベント ログやレジストリなど) にアクセスする方法の詳細については、「第 8 章 ASP.NET セキュリティ」の「システム リソースへのアクセス」を参照してください。第 8 章で説明している手法と制限事項は、ASP.NET によってホストされるリモート オブジェクトにも当てはまります。

ネットワーク リソースへのアクセス

ネットワーク リソースに リモート オブジェクトからアクセスするときは、リモート コンピュータからのネットワーク認証要求に応答するために使用される ID について検討する必要があります。この場合には、3 つの選択肢があります。

• プロセス ID (既定値) ASP.NET 内でホストする場合、ASP.NET のワーカー プロセスを実行するのに使用され、Machine.config の <processModel> 要素で定義されている ID によって、リソースへのアクセスに使用されるセキュリティ コンテキストが決まります。

  Windows サービス内でホストする場合は、サービスのプロセス (サービス MMC スナップインで構成) を実行するのに使用される ID によって、リソースへのアクセスに使用されるセキュリティ コンテキストが決まります。

• 固定サービス ID たとえば、LogonUser を呼び出すことによって作成される ID です。

  メモ このサービス ID と、Windows サービスの実行に使用される ID を混同しないでください。固定サービス ID とは、特にアプリケーションからリソースにアクセスする目的で作成される Windows ユーザー アカウントを指しています。

• 最初の呼び出し元の ID 偽装に対応するように構成された ASP.NET、または Windows サービス内で使用されるプログラムによる偽装で使用します。

以上のそれぞれの方法に関する相対的な利点の詳細、および構成の詳細については、「第 8 章 ASP.NET セキュリティ」の「ネットワーク リソースへのアクセス」を参照してください。

認証用の資格情報をリモート オブジェクトに渡す

クライアントのプロセスがリモート オブジェクトを呼び出すときは、プロキシを使用して呼び出しが行われます。これは、対象のオブジェクトと同じメソッドを公開するローカルのオブジェクトです。

クライアントの資格情報の指定

リモート オブジェクトが ASP.NET 内でホストされており、Windows 認証に対応するように構成されている場合は、チャネルの資格情報のプロパティを使用して、認証に使用される資格情報を指定する必要があります。資格情報を明示的に設定しないと、資格情報を使用せずにリモート オブジェクトが呼び出されます。Windows 認証が必要な場合は、この結果、アクセスが拒否されたという応答の HTTP ステータス 401 が発生します。

DefaultCredentials を使用する

リモート オブジェクトのプロキシをホストするプロセスの資格情報 (または、プロキシを呼び出すスレッドが偽装を行っている場合は現在のスレッド トークン) を使用する場合、チャネルの資格情報のプロパティを、プロセスの資格情報キャッシュによって保持される DefaultCredentials に設定にする必要があります。

構成ファイルで DefaultCredentials の使用を指定するか、プログラムで資格情報を設定します。

明示的な構成

クライアント アプリケーションの構成ファイル (クライアント アプリケーションが ASP.NET Web アプリケーションである場合は Web.config) 内で、プロキシがリモート オブジェクトと通信するときに DefaultCredentials を使用することを指定するため、<channel> 要素の useDefaultCredentials 属性を true に設定します。

<channel ref="http" useDefaultCredentials="true" />

プログラムによる構成

プログラムによる構成では、プログラムで以下のコードを使用して DefaultCredentials の使用を指定します。

IDictionary channelProperties;
channelProperties = ChannelServices.GetChannelSinkProperties(proxy);
channelProperties ["credentials"] = CredentialCache.DefaultCredentials;

特定の資格情報を使用する

リモート オブジェクトを呼び出すときに、特定の資格情報を認証に使用するには、以下の設定を使用して、構成ファイル内で既定の資格情報の使用を無効にします。

<channel ref="http" useDefaultCredentials="false" />

メモ プログラムによる設定は、常に構成ファイルの設定よりも優先されます。

次に、以下のコードを使用して、特定の資格情報を使用するようにプロキシを構成します。

IDictionary channelProperties =  
ChannelServices.GetChannelSinkProperties(proxy);
NetworkCredential credentials;
credentials = new NetworkCredential("username", "password", "domain");
ObjRef objectReference = RemotingServices.Marshal(proxy);
Uri objectUri = new Uri(objectReference.URI);
CredentialCache credCache = new CredentialCache();
// Substitute "authenticationType" with "Negotiate", "Basic", "Digest", 
// "Kerberos" or "NTLM"
credCache.Add(objectUri, "authenticationType", credentials);
channelProperties["credentials"] = credCache;
channelProperties["preauthenticate"] = true;

常に特定のタイプの認証を要求する

上記のように、CredentialCache.Add を使用して、常に特定のタイプの認証を要求する必要があります。以下のコードに示すように、NetworkCredential クラスは、直接使用しないでください。

IDictionary providerData = ChannelServices.GetChannelSinkProperties(yourProxy);
providerData["credentials"] = new NetworkCredential(uid, pwd);

これは、実際に運用するコードでは使用するべきではありません。これは、リモート オブジェクトのホストによって使用される認証機構を管理することは不可能であり、その結果、資格情報が使用される方法を管理することも不可能であるためです。

たとえば、Kerberos や NTLM 認証のチャレンジがサーバーから送られてくることを想定している場合でも、基本認証のチャレンジを受信することがあります。この場合、渡されたユーザー名とパスワードは、クリア テキスト形式でサーバーに送信されます。

preauthenticate プロパティを設定する

プロキシの preauthenticate プロパティは、true または false に設定することができます。これをtrue に設定 (上記のコード例) すると、特定の認証資格情報が渡されるため、HTTP ヘッダー WWW-Authenticate が最初の要求と共に渡されます。これによって、最初の要求に関してアクセスを拒否し、その後の要求で認証を実行する Web サーバーの処理を停止します。

connectiongroupname プロパティを使用する

ASP.NET によってホストされるリモート コンポーネントに接続し、最初の呼び出し元のセキュリティ コンテキストを、(前に説明したように、DefaultCredentials と偽装を使用するか、明示的に資格情報を設定して) フローする ASP.NET Web アプリケーションがある場合は、チャネルの connectiongroupname プロパティを Web アプリケーション内で設定する必要があります。この目的は、前のクライアントの認証資格情報に関連付けられているリモート コンポーネントへの認証済みの古い接続を、新しい未認証のクライアントが再使用できないようにすることです。接続の再使用は、HTTP KeepAlives と、パフォーマンスの理由により IIS で有効にされる認証の永続化の結果として発生します。

connectiongroupname プロパティを、呼び出し元ごとに区別される識別子 (呼び出し元のユーザー名など) に設定します。

channelProperties["connectiongroupname"] = userName;

メモ 最初の呼び出し元のセキュリティ コンテキストが Web アプリケーションを通じて リモート コンポーネントにフローしないが、固定ID (Web アプリケーションの ASP.NET プロセス ID など) を使用してリモート コンポーネントに接続する場合、connectiongroupname を設定する必要はありません。この場合は、接続のセキュリティ コンテキストが呼び出し元ごとに変わることはありません。

次のバージョンの .NET Framework では、プロキシ オブジェクトを呼び出すスレッドの SID に基づいた接続プールがサポートされる予定です。このため、Web アプリケーションが呼び出し元を偽装している場合でも、上記の問題に対処することができます。このプールは、.NET リモート処理のクライアントでサポートされ、Web サービスのクライアントではサポートされない予定です。

最初の呼び出し元をフローする

ここでは、ASP.NET Web アプリケーションを通じて、最初の呼び出し元のセキュリティ コンテキストを、リモートのアプリケーション サーバーで ASP.NET によってホストされるリモート コンポーネントにフローする方法を説明します。この必要があるのは、リモート オブジェクトまたは後続の下位のサブシステム (データベースなど) 内でユーザー単位の認証をサポートする場合です。

図 11.4 では、最初の呼び出し元 (Bob) のセキュリティ コンテキストは、ASP.NET Web アプリケーションをホストするフロントエンドの Web サーバーを通じて、リモートのアプリケーション サーバーの ASP.NET によってホストされるリモート オブジェクトにフローされ、最終的にバックエンドのデータベース サーバーに達します。

図 11.4 最初の呼び出し元のセキュリティ コンテキストをフローする

資格情報をリモート オブジェクトにフローするため、リモート オブジェクトのクライアント (この場合、ASP.NET Web アプリケーション) では、オブジェクトのプロキシを構成し、プロキシの credentials プロパティを明示的に設定する必要があります。これについては、前の「認証用の資格情報を Web サービスに渡す」で説明しています。

メモ IPrincipal オブジェクトは、.NET リモート処理の境界を越えてフローされません。

呼び出し元のコンテキストをフローするには、次の 2 つの方法があります。

• 既定の資格情報を渡し、Kerberos 認証 (および委任) を使用します。この方法では、ASP.NET Web アプリケーション内で偽装を行い、偽装された呼び出し元のセキュリティ コンテキストから取得した DefaultCredentials でリモート オブジェクトのプロキシを構成する必要があります。
• 明示的な資格情報を渡し、基本認証またはフォーム認証を使用します。この方法では、ASP.NET Web アプリケーション内で偽装を行う必要はありません。その代わりに、Web アプリケーションが使用することが可能な、サーバー変数 (基本認証の場合) またはHTML フォーム フィールド (フォーム認証の場合) から取得した明示的な資格情報を使用して、プログラムでリモート オブジェクトのプロキシを構成します。基本認証またはフォーム認証では、サーバーでクリア テキストのユーザー名とパスワードを使用できます。

既定の資格情報に Kerberos の委任を使用する

Kerberos の委任を使用するには、すべてのコンピュータ (サーバーとクライアント) で Windows 2000 以降が実行されている必要があります。さらに、委任されるクライアントのアカウントは、Active Directory® ディレクトリ サービスに格納され、"アカウントは重要なので委任できない" として設定されていないことが必要です。

次の表は、Web サーバーおよびアプリケーション サーバーに必要な構成の手順を示しています。

Web サーバーの構成

<authentication mode="Windows" />

<identity impersonate="true" />

<channel ref="http" 
useDefaultCredentials="true" />

リモートのアプリケーション サーバーの構成

<authentication mode="Windows" />

<identity impersonate="true" />

詳細情報

Kerberos の委任の詳細については、このガイドの「パート IV : 参照」の「Windows 2000 での Kerberos 委任の構成方法」を参照してください。

明示的な資格情報に基本認証またはフォーム認証を使用する

Kerberos の委任を使用する代わりに、Web アプリケーションで基本認証またはフォーム認証を使用してクライアントの資格情報を取得し、リモート オブジェクトに基本認証 (または Windows 統合認証) を使用することができます。

この方法により、Web アプリケーションでクライアントのクリア テキストの資格情報を使用できます。資格情報は、リモート オブジェクトのプロキシを通じてリモート オブジェクトに渡すことが可能です。この場合、クライアントの資格情報を取り出すように Web アプリケーションのコードを追加し、リモート オブジェクトのプロキシを構成する必要があります。

基本認証

基本認証では、Web アプリケーションは最初の呼び出し元の資格情報をサーバー変数で使用できます。以下のコードは、資格情報を取得し、リモート オブジェクトのプロキシを構成する方法を示しています。

// Retrieve client's credentials (available with Basic authentication)
string pwd = Request.ServerVariables["AUTH_PASSWORD"];
string uid = Request.ServerVariables["AUTH_USER"];
// Associate the credentials with the remote object proxy
IDictionary channelProperties =  
ChannelServices.GetChannelSinkProperties(proxy);
NetworkCredential credentials;
credentials = new NetworkCredential(uid, pwd);
ObjRef objectReference = RemotingServices.Marshal(proxy);
Uri objectUri = new Uri(objectReference.URI);
CredentialCache credCache = new CredentialCache();
credCache.Add(objectUri, "Basic", credentials);
channelProperties["credentials"] = credCache;
channelProperties["preauthenticate"] = true;

メモ 上記のコードの NetworkCredential コンストラクタには、ユーザー ID とパスワードが渡されます。ドメイン名をハードコードしないようにするため、基本認証を構成するときに、既定のドメインを IIS 内の Web サーバーで構成することができます。

フォーム認証

フォーム認証では、Web アプリケーションからは、最初の呼び出し元の資格情報を (サーバー変数ではなく) フォーム フィールドで使用できます。この場合は、以下のコードを使用します。

// Retrieve client's credentials from the logon form
string pwd = txtPassword.Text;
string uid = txtUid.Text;
// Associate the credentials with the remote object proxy
IDictionary channelProperties =  
ChannelServices.GetChannelSinkProperties(proxy);
NetworkCredential credentials;
credentials = new NetworkCredential(uid, pwd);
ObjRef objectReference = RemotingServices.Marshal(proxy);
Uri objectUri = new Uri(objectReference.URI);
CredentialCache credCache = new CredentialCache();
credCache.Add(objectUri, "Basic", credentials);
channelProperties["credentials"] = credCache;
channelProperties["preauthenticate"] = true;

次の表は、Web サーバーおよびアプリケーション サーバーで必要な構成の手順を示しています。

Web サーバーの構成

<authentication mode="Windows" />

<authentication mode="Forms" />

<identity impersonate="false" />

<channel ref="http" 
useDefaultCredentials="false" />

アプリケーション サーバーの構成

<authentication mode="Windows" />

<identity impersonate="true" />

信頼されたサブシステム

信頼されたサブシステム モデルは、最初の呼び出し元のセキュリティ コンテキストをフローする別の実装がより簡単な方法として使用できます。このモデルには、リモート オブジェクトと Web アプリケーションの間に信頼の境界が存在します。要求をリモート オブジェクトに転送する前に、リモート オブジェクトは Web アプリケーションを信頼して、呼び出し元を正しく認証および認定します。最初の呼び出し元の認証は、リモート オブジェクトのホストでは発生しません。リモート オブジェクトのホストは、Web アプリケーションによって使用される、信頼された固定 ID を認証して、リモート オブジェクトと通信します。ほとんどの場合、これは ASP.NET Web アプリケーションのプロセス ID です。

図11.5 に、信頼されたサブシステム モデルを示します。また、この図は、想定される 2 つの構成を示しています。1 番目の構成では ASP.NET ホストと HTTP チャネルが使用され、2 番目の構成では Windows サービスのホストと TCP チャネルが使用されます。

図 11.5 信頼されたサブシステム モデル

呼び出し元の ID をフローする

信頼されたサブシステム モデルを使用する場合は、データベースで監査するなどの目的で、最初の呼び出し元の ID (セキュリティ コンテキストではなく、名前) をフローすることが必要になる場合があります。

ID は、メソッドおよびストアド プロシージャのパラメータを使用して、アプリケーション レベルでフローすることができます。また、次の例のように、信頼されたクエリ パラメータを使用して、ユーザー固有のデータをデータベースから取り出すことが可能です。

SELECT x,y,z FROM SomeTable WHERE UserName = "Bob"

ホストの選択

信頼されたサブシステム モデルとは、リモート オブジェクトのホストが最初の呼び出し元を認証しないことを示しています。ただし、直接のクライアント (この場合は ASP.NET Web アプリケーション) を認証および認定して、許可されていないアプリケーションがリモート オブジェクトに要求を発行するのを防ぐ必要があります。

ASP.NET 内でホストしており、HTTP チャネルを使用している場合は、Windows 統合認証を使用して ASP.NET Web アプリケーションのプロセス ID を認証することができます。

Windows サービス内でホストしている場合は、TCP チャネルを使用できます。TCP チャネルは、パフォーマンスは優れていますが、認証機能は備えていません。このシナリオでは、Web サーバーとアプリケーション サーバーとの間で IPSec を使用することが可能です。IPSec ポリシーは、Web サービスとアプリケーション サーバーとの通信を許可するものしか設定できません。

構成手順

次の表は、Web サーバーおよびアプリケーション サーバーに必要な構成の手順を示しています。

Web サーバーの構成

<authentication mode="Windows|Forms|Passport" />

<identity impersonate="false" />

<channel ref="http" 
useDefaultCredentials="true" />

アプリケーション サーバーの構成

以下の手順は、ASP.NET ホストを使用している場合に該当します。

<authentication mode="Windows" />

<identity impersonate="false" />

Windows サービスのホストを使用する

Windows サービスのホスト プロセスを使用している場合は、Windows アカウントを作成してサービスを実行する必要があります。このアカウントによって提供されるセキュリティ コンテキストは、ローカルおよびリモートのすべてのリソースにアクセスするときに、リモート オブジェクトによって使用されます。

リモートの Microsoft SQL Server® データベースに Windows 認証を使用してアクセスするには、最低限の特権のドメイン アカウントを使用するか、最低限の特権のローカル アカウントを使用し、同じユーザー名とパスワードを持つ重複したアカウントをデータベース サーバーに作成します。

通信のセキュリティ保護

通信のセキュリティ保護は、メッセージの整合性と機密性の保証と関係があります。これは、メッセージがネットワークを通じてフローされるためです。プラットフォーム ベースの手法を使用して通信をセキュリティで保護し、SSL または IPSec を使用することができます。また、メッセージ レベルの手法を使用し、カスタムの暗号化シンクを開発してメッセージ全体を暗号化したり、メッセージの一部を選択して暗号化することも可能です。

プラットフォーム レベルのオプション

クライアントとリモート コンピュータとの間で渡されるデータをセキュリティで保護するために考慮すべきプラットフォーム レベルのオプションには、以下の 2 つがあります。

• SSL
• IPSec

ASP.NET 内でリモート オブジェクトをホストすると、SSL を使用してクライアントとサーバー間の通信チャネルをセキュリティで保護することができます。これには、リモート オブジェクトをホストするコンピュータにサーバー認証証明書が必要です。

Windows サービス内でリモート オブジェクトをホストする場合には、クライアントとホスト サーバー コンピュータとの間で IPSec を使用したり、カスタムの暗号化シンクを開発することが可能です。

メッセージ レベルのオプション

.NET リモート処理のアーキテクチャは拡張可能な特性を持っているため、カスタム シンクを開発し、処理を行うパイプラインに組み込むことができます。通信をセキュリティで保護するため、リモート オブジェクトとの間で送受信されるメッセージ データを暗号化および解読するカスタム シンクを開発することができます。

この方法の利点は、メッセージを部分的に選択して暗号化できることです。これは、クライアントとサーバー間で送信されるデータがすべて暗号化されるプラットフォーム レベルの方法とは、大きく異なります。

詳細情報

SSL と IPSec の詳細については、「第 4 章 セキュリティで保護された通信」参照してください。

ホスト プロセスを選択する

リモートからアクセスされるオブジェクトは、ホストの実行可能ファイルで実行されている必要があります。ホストは、着信する要求をリッスンし、呼び出しをオブジェクトにディスパッチします。選択されたホストのタイプによって、チャネルと呼ばれるメッセージ転送メカニズムが異なります。また、選択されたチャネルの種類によって、認証、認定、通信のセキュリティ保護、および使用しているソリューションのパフォーマンス特性が異なります。

HTTP チャネルには優れたセキュリティ オプションがありますが、一方、TCP チャネルはパフォーマンスに優れています。

リモート オブジェクトをホストするためのオプションは、主に以下のものがあります。

• ASP.NET 内でホストする
• Windows サービス内でホストする
• コンソール アプリケーション内でホストする

推奨事項

ASP.NET および IIS によって得られるセキュリティ インフラストラクチャを利用するには、セキュリティ面から見て、ASP.NET 内でリモート オブジェクトをホストすることをお勧めします。これには、クライアントが HTTP チャネルを介してリモート オブジェクトと通信することが必要です。ASP.NET と IIS の認証、認定、および通信のセキュリティ保護の機能は、ASP.NET 内でホストされているリモート オブジェクトから利用可能です。

セキュリティではなく、パフォーマンスを主に考慮しているのであれば、Windows サービス内でリモート オブジェクトをホストすることを検討してください。

ASP.NET 内でホストする

ASP.NET 内でリモート オブジェクトをホストした場合、オブジェクトは次のようになります。

• オブジェクトは、HTTP プロトコルを使用してアクセスされます。
• オブジェクトには、URL を使用してアクセスできるエンドポイントがあります。
• オブジェクトは、Aspnet_wp.exe のワーカー プロセス内部のアプリケーション ドメイン内に存在します。
• オブジェクトは、IIS および ASP.NET に用意されているセキュリティ機能を継承します。

メリット

IIS 内でリモート オブジェクトをホストする場合には、以下のメリットが得られます。

• IIS および ASP.NET に用意されている認証、認定、および通信のセキュリティ保護の機能をすぐに使用することができます。
• IIS の監査機能を使用できます。
• ASP.NET ワーカー プロセスが常に実行されています。
• Machine.config の <processModel> 要素を通じて、実行可能ファイルのホスト機能に対する高度な管理が可能です。スレッド管理、フォールト トレランス、メモリ管理などを調整できます。
• Web サービスのファサード層をリモート オブジェクトの前面に作成できます。

デメリット

ASP.NET を使用してリモート オブジェクトをホストする場合には、以下のデメリットがあります。

• TCP チャネルよりも低速な HTTP チャネルを使用する必要があります。
• ユーザー プロファイルは、ASP.NET によってロードされません。いくつかの暗号化方法 (DPAPI など) では、ユーザー プロファイルが必要になることがあります。
• オブジェクトが、ASP.NET Web アプリケーション内で動作しているコードからアクセスされる場合は、基本認証を使用しなければならないことがあります。

Windows サービスでホストする

Windows サービス内でリモート オブジェクトをホストすると、リモート オブジェクトはサービスのプロセス内部に含まれるアプリケーション ドメイン内に存在します。この場合は HTTP チャネルを使用できないので、TCP チャネルを使用する必要があります。TCP チャネルでは、以下のセキュリティ機能がサポートされています。

• 認証機能

  カスタム認証ソリューションを用意する必要があります。これには、以下のオプションがあります。

  • **SSPI の基本的な認証サービスを使用する。**Windows SSPI 資格情報とコンテキスト管理の API を使用するチャネル シンクを作成して、呼び出し元を認定することができるほか、必要に応じて呼び出し元を偽装することも可能です。チャネルシンクは、TCP チャネルの上部に位置します。SSPI を TCP チャネルと組み合わせると、クライアントとサーバーは認証情報をやり取りすることができます。認証された後は、クライアントとサーバーは機密性と整合性を確保してメッセージを送信することが可能です。
  • **名前付きパイプなどの認証をサポートする基本的な転送を使用する。**名前付きパイプのチャネルは、転送メカニズムとして名前付きパイプを使用します。これによって、呼び出し元の認証が実現するほか、パイプでの Windows ACL ベースのセキュリティや呼び出し元の偽装も使用できるようになります。

認定機能

認定が可能になるのは、カスタム認証ソリューションを実装した場合だけです。

• ユーザーを、たとえば、名前付きパイプでの転送を使用して偽装することが可能であれば、WindowsPrincipal.IsInRole を使用できます。
• IPrincipal オブジェクトを作成して、認証されたクライアントを表すことが可能な場合には、.NET ロールを使用できます。この場合、プリンシパル アクセス許可要求と、IPrincipal.IsInRole を使用した明示的なロール チェックを通して行われます。

通信機能のセキュリティ保護

次の 2 とおりの方法があります。

• IPSec を使用して、クライアントとサーバー間のデータ転送をセキュリティ保護します。
• 非対称の暗号化を行う、カスタム チャネル シンクを作成します。このオプションについては、後で説明します。

メリット

Windows サービス内でリモート オブジェクトをホストする場合には、以下のメリットが得られます。

• ホスト プロセスの高度なアクティベーション管理が可能です。
• Windows サービスのアーキテクチャの利点を継承します。
• アプリケーションの中間層に IIS を導入する必要がありません。
• ユーザー プロファイルが自動的にロードされます。
• クライアントが、バイナリ エンコードされたデータを使用し、TCP チャネルを通じて通信するため、パフォーマンスに優れています。

デメリット

Windows サービスを使用してリモート オブジェクトをホストする場合には、以下のデメリットがあります。

• カスタムの認証および認定ソリューションを用意する必要があります。
• セキュリティで保護された通信ソリューションを用意する必要があります。
• 監査ソリューションを用意する必要かあります。

コンソール アプリケーション内でホストする

コンソール アプリケーション内でリモート オブジェクトをホストすると、リモート オブジェクトはコンソール アプリケーションのプロセス内部に含まれるアプリケーション ドメイン内に存在します。この場合は HTTP チャネルを使用できないので、TCP チャネルを使用する必要があります。

この方法は、実際に運用するソリューションにはお勧めしません。

メリット

この方法では、中間層に IIS が必要ではありませんが、実質的なメリットはほとんどありません。この方法は、実際の運用環境ではなく、開発環境やテスト環境にのみお勧めします。

デメリット

カスタムの実行可能ファイル内でリモート オブジェクトをホストする場合には、以下のデメリットがあります。

• ホストは、手動で起動され、インタラクティブなログオン セッション下で実行されなければなりませんが、このことは、推奨されていません。
• フォールト トレラントではありません。
• カスタムの認証および認定を用意する必要があります。
• 監査機能はありません。

リモート処理と Web サービス

.NET には、Web サービスの使用を含め、クライアントがリモート オブジェクトと通信できるようにするさまざまな方法が用意されています。

異種システム間での相互運用性を確保する必要がある場合は、SOAP、XML、HTTP などの公開された規格を使用する Web サービスによる手法をとることが正しい選択です。これに対して、サーバー間のイントラネット ベースのソリューションを作成する場合は、リモート処理で以下の機能が得られます。

• どのような .NET タイプ (Microsoft C#® 開発ツールおよび Microsoft Visual Basic® .NET 開発システムを使用して作成されたカスタム タイプなど) でも再現可能なため、オブジェクトの高度な再現性が実現されています。

  これには、クラス、クラスの階層、インターフェイス、フィールド、プロパティ、メソッドと委任、データセット、ハッシュ テーブルなどが含まれます。

• オブジェクトは、値渡しおよび参照渡しでマーシャリングが可能です。

• オブジェクトの有効期間は、リースに基づいて管理されます。

• 特に、TCP チャネルとバイナリ フォーマッタでは、高度なパフォーマンスが得られます。

• ネットワーク負荷分散を使用して、負荷分散された中間層を構築することができます。

表 11.2 モート処理と Web サービスの主な相違点

まとめ

.NET リモート処理自体には、セキュリティ モデルは用意されていません。ただし、ASP.NET 内でリモートオブジェクトをホストし、通信に HTTP チャネルを使用することによって、IIS と ASP.NET に用意されている基本的なセキュリティ サービスでリモート オブジェクトを保護することができます。これとは逆に、TCP チャネルおよびホストのカスタム実行可能ファイルはパフォーマンスには優れていますが、この組み合わせには、組み込みのセキュリティは用意されていません。

• クライアントを認証する場合は、HTTP チャネルを使用し、ASP.NET 内でホストして、IIS で匿名アクセスを無効にします。

• パフォーマンスを向上させたい場合、クライアントを認証しなくてもよければ、TCP チャネルを使用します。

• TCP チャネルを使用する場合は、IPSec を使用して、クライアントとサーバーとの間の通信チャネルをセキュリティで保護します。HTTP チャネルをセキュリティで保護するには、SSL を使用します。

• リモート リソースへの信頼された呼び出しを行う必要がある場合は、コンソール アプリケーションではなく、Windows サービス内でコンポーネントをホストします。

• IPrincipal オブジェクトを .NET リモート処理の境界を越えて渡すことはできません。ただし、シリアル化が可能な、独自の IPrincipal クラスを実装することが可能です。この場合、悪意のあるクライアントが IPrincipal オブジェクトをスプーフィングしてリモート オブジェクトに送信することが比較的容易になるので注意してください。また、リモート処理に独自の IPrincipal クラスを実装する場合は、IlogicalThreadAffinitive の扱いにも注意してください。

• リモート オブジェクトはインターネットに公開しないでください。インターネットへの公開には、Web サービスを使用します。

  .NET リモート処理は、イントラネットでのみ使用してください。オブジェクトは、Web アプリケーションから内部的にアクセスする必要があります。クライアントは .NET のクライアントでなければならないため、オブジェクトが ASP.NET 内でホストされていても、インターネットのクライアントにはオブジェクトを公開しないでください。