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

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

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

適用対象:
    Microsoft® ASP.NET
    Microsoft SQL Server™

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

要約 : この章では、一般的なイントラネット アプリケーション シナリオをセキュリティで保護する方法について説明します。シナリオごとに、それぞれの特徴を示したうえで、セキュリティ対策として必要な設定について説明していきます。また、各シナリオの「分析」には、追加情報を挙げてあります。

目次

ASP.NET - SQL Server
ASP.NET - Enterprise Services - SQL Server
ASP.NET - Web サービス - SQL Server
ASP.NET - リモート処理 - SQL Server
最初の呼び出し元をデータベースにフローする
まとめ

イントラネット アプリケーションにアクセスするのは、限られた数の許可されたユーザー (あるドメインに属する従業員など) だけです。イントラネット環境では、アプリケーションに対する外部からのアクセスは限られているとはいえ、認証、認定、および通信セキュリティの戦略を作成するときには、やはりいくつかの問題に直面することがあります。たとえば、信頼関係のないドメインがある場合、呼び出し元のセキュリティ コンテキストと ID をシステム内のバックエンド リソースまでフローすることが困難になります。イントラネットが数種類のブラウザの混在する異種環境に存在することもあります。このような場合には、共通の認証メカニズムを使用することが難しくなります。

イントラネットが Microsoft® Windows® 2000 以降を実行するコンピュータだけで構成される同種環境であり、委任に関してユーザーを信頼しているドメインがある場合は、最初の呼び出し元のセキュリティ コンテキストをバックエンドに委任するという方法が可能です。

通信のセキュリティについても検討する必要があります。アプリケーションがイントラネット環境で稼働していても、ネットワーク上で転送されるデータのセキュリティによる保護を軽視することはできません。場合によっては、アプリケーション サーバーとデータベースの間で転送されるデータだけでなく、ブラウザと Web サーバーの間でやり取りされるデータをセキュリティで保護する必要もあります。

この章では、以下の一般的なイントラネット シナリオを使用し、認証、認定、通信セキュリティを実装する主要なテクニックについて説明します。

ASP.NET - SQL Server

ASP.NET - Enterprise Services - SQL Server

ASP.NET - Web サービス - SQL Server

ASP.NET - リモート処理 - SQL Server

さらに、Windows 2000 委任のシナリオについても説明します (「最初の呼び出し元をデータベースにフローする」)。このシナリオでは、最初の呼び出し元のセキュリティ コンテキストと ID がオペレーティング システム レベルでブラウザから Web サーバーおよびアプリケーション サーバーを経由してデータベースまでフローされます。

メモ この章で扱ういくつかのシナリオでは、ASP.NET アプリケーションの実行に使用する既定の ASPNET アカウントを別のアカウントに置き換えるか、そのパスワードを変更して、リモート コンピュータ上に複製アカウントを作成できるようにします。これらのシナリオでは、Machine.config の <processModel> 要素を更新します。その結果、資格情報はクリア テキストで machine.config に保存されます。詳細については、「第 8 章 ASP.NET セキュリティ」の「ネットワーク リソースへのアクセス」を参照してください。

ASP.NET - SQL Server

このシナリオでは、同種環境のイントラネットにおいて、セキュリティで保護されたユーザー個人情報を HR データベースから取得できます。アプリケーションは信頼されたサブシステム モデルを使用して、最初の呼び出し元に代わって呼び出しを実行します。アプリケーションは Windows 統合認証によって呼び出し元を認証し、ASP.NET プロセス ID を使用してデータベースへの呼び出しを実行します。ここで扱うデータには機密性が求められるため、Web サーバーとクライアントの通信には SSL を使用します。

このアプリケーション シナリオの基本モデルを図 5.1 に示します。

図 5.1 ASP.NET - SQL Server

特徴

このシナリオには次のような特徴があります。

クライアントは Internet Explorer を使用します。

ユーザー アカウントは Microsoft Active Directory® ディレクトリ サービスに登録されています。

アプリケーションは機密性のあるユーザー個人情報を扱います。

アプリケーションへのアクセスを、認証されたクライアントだけに制限する必要があります。

データベースは、ユーザーを適切に認証することについてアプリケーションを信頼しています (つまり、アプリケーションがユーザーに代わってデータベースの呼び出しを実行します)。

Microsoft SQL Server® は、認定プロセスで単一のデータベース ユーザー ロールを使用します。

このシナリオのセキュリティ対策

このシナリオでは、Web サーバーが呼び出し元を認証し、呼び出し元の ID を使用してローカル リソースへのアクセスを制限します。最初の呼び出し元に対してリソースへのアクセスを制限するために、Web アプリケーション内で偽装を行う必要はありません。データベースは、最低限の特権を持つアカウントである、既定の ASP.NET プロセス ID を認証します (つまり、データベースは ASP.NET アプリケーションを信頼しています)。

表 5.1 セキュリティ対策

結果

このシナリオの推奨セキュリティ構成を図 5.2 に示します。

図 5.2 ASP.NET - SQL Server イントラネット シナリオの推奨セキュリティ構成

セキュリティ構成の設定

作業を始める前に、以下のドキュメントを参照してください。

• カスタム ASP.NET アカウントの作成 (このガイドの「パート IV : 参照」の「ASP.NET の実行に使用するカスタム アカウントの作成方法」を参照)
• 最低限の特権を持つデータベース アカウントの作成 (「第 12 章 データ アクセス セキュリティ」を参照)
• Web サーバーにおける SSL の構成 (このガイドの「パート IV : 参照」の「Web サーバー上で SSL を設定する方法」を参照)
• IPSec の構成 (このガイドの「パート IV : 参照」の「2 つのサーバー間の通信を IPSec で保護する方法」を参照)

IIS の構成

ASP.NET の構成

<!-- userName="machine" password="AutoGenerate" -->

<!-- userName="machine" password="YourNewStrongPassword" -->

SQL Server の構成

セキュリティで保護された通信の構成

分析

• このシナリオでは、すべてのユーザーが Windows アカウントを持ち、Microsoft Internet Explorer を使用しているため、IIS での Windows 統合認証が最適です。Windows 統合認証の利点は、ユーザーのパスワードがネットワーク上で送信されないことです。また、Windows は対話ユーザーの現在のログオン セッションを使用するため、ログオンはユーザーにとって透過的です。

• ASP.NET は最低限の特権を持つアカウントとして稼働するため、不正アクセスによる潜在的な損害は緩和されます。

• .NET ロール チェックを実行したり、Windows ACL 内で最初の呼び出し元に対してリソースをセキュリティで保護するために、ASP.NET で偽装を行う必要はありません。最初の呼び出し元に対して .NET ロール チェックを実行するには、次のように、最初の呼び出し元を表す WindowsPrincipal オブジェクトを HTTP コンテキストから取得します。

WindowsPrincipal wp = (HttpContext.Current.User as WindowsPrincipal);
if ( wp.IsInRole("Manager") )
{
  // User is authorized to perform manager-specific functionality
}

ASP.NET FileAuthorizationModule は、IIS 内で aspnet\_isapi.dll にマップされた ASP.NET ファイルについて、最初の呼び出し元に対する ACL チェックを実行します。IIS は、.jpg、.gif、.htm などの静的ファイルに対するゲートキーパーの役割を果たし、最初の呼び出し元の ID を使用して、ファイルに関連付けられた NTFS アクセス権に基づきアクセス チェックを実行します。

• SQL Server への接続に Windows 認証を使用すると、資格情報はファイルに保存されず、ネットワークを介してデータベース サーバーに送信されることはありません。

• データベース サーバー上の複製された Windows アカウント (ASPNET ローカル アカウントと一致するアカウント) を使用すると、管理の負担が増加します。一方のコンピュータでパスワードが変更されると、もう一方のコンピュータでアカウントの同期と更新を行う必要があります。シナリオによっては、最低限の特権を持つドメイン アカウントを使用して管理を容易にすることができます。

• ローカル アカウントを複製するというアプローチは、Windows 認証に必要なポートがオープンしていない可能性があるファイアウォールが存在する環境でも有効です。Windows 認証とドメイン アカウントの組み合わせは、このシナリオでは機能しないことがあります。

• Windows グループは、セキュリティ上の要求に合ったレベルまで細分化する必要があります。.NET ロール ベースのセキュリティは Windows グループのメンバシップを基礎とするため、このソリューションでは、Windows グループがアプリケーションにアクセスするユーザーの分類に対応するレベルまで細分化されていることが必要となります。ここでロールを管理するために使用する Windows グループは、そのコンピュータのローカル グループとドメイン グループのどちらでもかまいません。

• SQL Server アプリケーション ロールを使用すると、パスワード管理や接続プールの問題が生じます。そうした問題を回避するために、SQL Server データベース ユーザー ロールの使用をお勧めします。

  アプリケーションでは、SQL Serverアプリケーション ロールをアクティブ化するために、組み込みストアド プロシージャをロール名およびパスワードと共に呼び出します。したがって、パスワードを保存するときにセキュリティで保護する必要があります。SQL Server アプリケーション ロールを使用する場合には、データベース接続プールはアプリケーションのスケーラビリティを著しく低下させるため、これも無効にすることが必要です。

  SQL Server データベース ユーザー ロールと SQL Server アプリケーション ロールの詳細については、「第 12 章 データ アクセス セキュリティ」を参照してください。

• データベース ユーザーはデータベース ユーザー ロールに追加し、ロールにはアクセス許可が割り当てられるため、データベース アカウントを変更した場合に、すべてのデータベース オブジェクトについてアクセス許可を変更する必要はありません。

Q&A

• Web アプリケーションでは、なぜ偽装を有効にできないのでしょうか。偽装を有効にすると、最初の呼び出し元に対する ACL チェックによって Web アプリケーションがアクセスするリソースをセキュリティで保護できます。

  偽装を有効にすると、偽装したセキュリティ コンテキストにネットワーク資格情報が含まれなくなります (委任が有効になっておらず、Windows 統合認証を使用している場合)。したがって、SQL Server に対するリモート呼び出しで NULL セッションが使用され、結果的に呼び出しが失敗となります。偽装を無効にすると、リモート要求には ASP.NET プロセス ID が使用されます。

  前のシナリオでは、ASP.NET FileAuthorizationModule を使用しました。これによって、最初の呼び出し元の ID に対して Windows ACL を使用した認定プロセスが実行されるため、偽装は不要となります。

  Windows 統合認証 (NTLM) ではなく基本認証を使用している場合に偽装を有効にすると、データベース呼び出しには最初の呼び出し元のセキュリティ コンテキストが使用されます。ユーザー アカウント (またはユーザーが属する Windows グループ) には、それぞれに SQL Server ログインが必要となります。Windows グループ (または最初の呼び出し元) に対し、データベース オブジェクトへのアクセス許可をセキュリティで保護することが必要です。

• データベース側は最初の呼び出し元が誰であるのかを認識しません。監査の軌跡は、どのように作成するのですか。

  Web アプリケーション側でエンド ユーザーの操作を監査するか、ユーザーの ID をデータ アクセス呼び出しのパラメータとして明示的に渡します。

関連シナリオ

Internet Explorer 以外のブラウザ

IIS での Windows 統合認証には Internet Explorer が必要です。数種類のブラウザが混在する環境では、以下のセキュリティ対策が一般的です。

• 基本認証と SSL 基本認証は、ほとんどのブラウザによってサポートされています。ユーザーの資格情報がネットワーク上で転送されるため、SSL を使用してセキュリティを確保する必要があります。

• クライアント証明書 各クライアント証明書をそれぞれ固有の Windows アカウントにマップすることもできれば、1 つの Windows アカウントですべてのクライアントを表すことも可能です。クライアント証明書を使用する場合も SSL が必要となります。

• フォーム認証 フォーム認証は、データベースなどのカスタム データ ストアまたは Active Directory との照合によって資格情報の有効性を検証するものです。

  この認証に Active Directory を使用する場合は、必ずアプリケーションに関連のある必要なグループだけを取得してください。"SELECT *" 句を使用したクエリをデータベースに発行すべきではないのと同じように、Active Directory から無制限にすべてのグループを取得するような方法は避けてください。

  認証にデータベースを使用する場合は、SQL コマンドの入力を慎重に解析し、SQL コード注入攻撃に備える必要があります。また、パスワードをクリア テキストのままデータベースに保存するのではなく、salt を加えたパスワード ハッシュ (暗号化したパスワード) として保存することも必要です。

  資格情報の保存先としての SQL Server とデータベースへのパスワード保存の詳細については、「第 12 章 データ アクセス セキュリティ」を参照してください。

Windows 統合認証を使用しない場合は、資格情報がプラットフォームによって管理されないため、必ず SSL を使用することになります。ただし、この利点はあくまでも認証プロセスだけにかかわるものです。ネットワーク上で機密データを送信する場合にも、IPSec か SSL のいずれかを使用する必要があります。

データベースを使用した SQL 認証

シナリオによっては、Windows 認証ではなく SQL 認証を使用せざるを得ないことがあります。たとえば、Web アプリケーションとデータベースの間にファイアウォールがある場合や、セキュリティ上の理由から Web サーバーがドメインのメンバでない場合です。この場合にも Windows 認証は使用できません。このような場合、データベースと Web サーバーの間に SQL 認証を実装することもできます。このシナリオをセキュリティで保護するためには、以下のことが必要です。

• データ保護 API (DPAPI) を使用して、ユーザー名とパスワードを含むデータベース接続文字列をセキュリティで保護します。詳細については、次の資料を参照してください。
• 「第 12 章 データ アクセス セキュリティ」の「データベース接続文字列をセキュリティで保護して保存する」
• このガイドの「パート IV : 参照」の「ASP.NET から DPAPI (コンピュータ ストア) を使用する方法」
• このガイドの「パート IV : 参照」の「ASP.NET と Enterprise Services から DPAPI (ユーザー ストア) を使用する方法」
• このガイドの「パート IV : 参照」の「DPAPI ライブラリを作成する方法」
• Web サーバーとデータベース サーバーの間に IPSec または SSL を実装し、ネットワーク上で転送されるクリア テキストの資格情報を保護します。

最初の呼び出し元をデータベースにフローする

このシナリオでは、Web アプリケーションからデータベースへの呼び出しを実行するために、最初の呼び出し元のセキュリティ コンテキストを使用します。このアプローチでは、以下の点に留意する必要があります。

• このアプローチを選択した場合は、Kerberos 認証 (アカウントの委任を有効に設定)、基本認証のいずれかを使用する必要があります。

  委任シナリオについては、後の「最初の呼び出し元をデータベースにフローする」で説明します。

• ASP.NET で偽装を有効に設定することも必要です。この場合、ローカル システム リソース アクセスは最初の呼び出し元のセキュリティ コンテキストを使用して実行されます。したがって、それに応じてレジストリやイベント ログなどのローカル リソースの ACL を構成する必要があります。

• 最初の呼び出し元が接続を共有できないので、データベース接続プールが制限されます。個々の接続が呼び出し元のセキュリティ コンテキストに対応付けられます。

• ユーザーのセキュリティ コンテキストをフローする代わりに、最初の呼び出し元の ID をアプリケーション レベルでフローすることもできます (その場合、メソッドとストアド プロシージャのパラメータを使用する方法などがあります)。

ASP.NET - Enterprise Services - SQL Server

このシナリオでは、ASP.NET ページが Enterprise Services アプリケーションでホストされているビジネス コンポーネントを呼び出し、さらにその Enterprise Services アプリケーションがデータベースに接続します。このシナリオの例として、企業内の発注システムがあります。こうしたシステムでは、イントラネット上でトランザクションを転送することによって、各部門が注文を行います。このシナリオを図 5.3 に示します。

図 5.3 ASP.NET が Enterprise Services 内のコンポーネントを呼び出し、Enterprise Services がデータベースを呼び出す

特徴

このシナリオには次のような特徴があります。

ユーザーは Internet Explorer を使用します。

コンポーネントは Web サーバーに配置します。

アプリケーションは、転送時にセキュリティで保護する必要がある機密データを扱います。

ビジネス コンポーネントは Windows 認証を使用して SQL Server に接続します。

これらのコンポーネントのビジネス機能は、呼び出し元の ID に基づいて制限されます。

サービス コンポーネントはサーバー アプリケーション (アウトプロセス) として構成されます。

コンポーネントは、サーバー アプリケーションのプロセス ID を使用してデータベースに接続します。

ASP.NET 内で偽装を有効にします。これにより、Enterprise Services のロール ベース セキュリティが向上します。

このシナリオのセキュリティ対策

このシナリオでは、Web サーバーが最初の呼び出し元を認証し、その呼び出し元のセキュリティ コンテキストをサービス コンポーネントにフローします。サービス コンポーネントは、最初の呼び出し元の ID に基づいてビジネス機能へのアクセスを許可します。データベースは Enterprise Service アプリケーションのプロセス ID を認証します (つまり、データベースは Enterprise Service アプリケーション内のサービス コンポーネントを信頼します)。サービス コンポーネントがデータベースに対して呼び出しを実行するときには、信頼されたクエリ パラメータを使用して、ユーザーの ID をアプリケーション レベルで渡します。

表 5.2 セキュリティ対策

結果

このシナリオの推奨セキュリティ構成を図 5.4 に示します。

図 5.4 ASP.NET - ローカル Enterprise Services - SQL Server イントラネット シナリオの推奨セキュリティ構成

セキュリティ構成の設定

作業を始める前に、以下のドキュメントを参照してください。

• 最低限の特権を持つデータベース アカウントの作成 (「第 12 章 データ アクセス セキュリティ」を参照)
• Web サーバーにおける SSL の構成 (このガイドの「パート IV : 参照」の「Web サーバー上で SSL を設定する方法」を参照)
• IPSec の構成 (このガイドの「パート IV : 参照」の「2 つのサーバー間の通信を IPSec で保護する方法」を参照)
• Enterprise Services セキュリティの構成 (このガイドの「パート IV : 参照」の「Enterprise Servises でロールを基準としたセキュリティを使用する方法」を参照)

IIS の構成

ASP.NET の構成

Enterprise Services の構成

SQL Server の構成

セキュリティで保護された通信の構成

分析

• ASP.NET と Enterprise Services は最低限の特権を持つアカウントとして稼働するので、不正アクセスによる潜在的な損害は緩和されます。どちらかのプロセス ID が不正利用されたとしても、アカウントの特権が限定されているため、損害は狭い範囲にとどまります。また、ASP.NET の場合、悪意のあるスクリプトが送り込まれた場合でも、限定的な被害で済みます。
• 最初の呼び出し元のセキュリティ コンテキストが、Enterprise Services (COM+) のロール ベースの認定をサポートするため Enterprise Services コンポーネントにフローされるように、ASP.NET アプリケーションでは偽装が有効になるよう構成する必要があります。偽装を行わない場合、プロセス ID (つまり ASP.NET ワーカー プロセス) に対してロール チェックが実行されます。偽装は、リソースを誰に対して認定するのかという問題に影響します。
• 偽装を無効にすると、ASP.NET プロセスに対してシステム リソース チェックが実行されます。偽装を有効にすると、システム リソース チェックは最初の呼び出し元に対して実行されます。ASP.NET からシステム リソースへのアクセスの詳細については、「第 8 章 ASP.NET セキュリティ」の「システム リソースへのアクセス」を参照してください。
• Enterprise Services (COM+) ロールを使用することによって、アクセス チェックはビジネス ロジックがある中間層にプッシュされます。その場合、呼び出し元はゲートでチェックを受け、ロールにマップされます。また、ビジネス ロジックに対する呼び出しはロールに基づきます。これによって、バック エンドに対する不要な呼び出しが回避されます。Enterprise Services (COM+) ロールには、コンポーネント サービス マネージャを使用して、展開時にロールを作成し、管理できるという利点もあります。
• SQL Server の認証方法を Windows 認証に設定することによって、資格情報はファイルに保存されず、ネットワーク上でも送信されることはありません。
• Enterprise Services アプリケーションを実行するためにローカル アカウントを使用し、データベース サーバーに複製アカウントを作成するという方法は、Windows 認証に必要なポートがオープンしていない可能性があるファイアウォールが存在する環境でも有効です。Windows 認証とドメイン アカウントの組み合わせは、このシナリオでは機能しないことがあります。

注意点

• データベース サーバー上の複製された Windows アカウント (Enterprise Services プロセス アカウントと一致するアカウント) を使用すると、管理の負担が増加します。パスワードの更新および同期を手動で定期的に行う必要があります。
• .NET ロール ベースのセキュリティは Windows グループのメンバシップを基礎とするため、このソリューションでは、Windows グループがアプリケーションにアクセスするユーザーの分類に対応するレベルまで細分化されていることが必要となります。

ASP.NET - Web サービス - SQL Server

このシナリオでは、ASP.NET ページを実行する Web サーバーがリモート サーバー上の Web サービスに接続します。次に、このリモート サーバーがリモート データベース サーバーに接続します。このようなシナリオの例として、ユーザー個人の機密データを扱う人材管理 Web アプリケーションがあります。このようなアプリケーションは Web サービスを利用してデータを取得します。このアプリケーション シナリオの基本モデルを図 5.5 に示します。

図 5.5 ASP.NET - リモート Web Service - SQL Server

Web サービスは、個々の従業員が各自の個人情報を取得できるメソッドを公開します。このような情報は、Web アプリケーションを使用する認証済みの個人だけに提供する必要があります。Web サービスは、あらゆる従業員の情報を取得できるメソッドも提供します。この機能の使用は、人事部門や給与支払部門の従業員に限定する必要があります。このシナリオでは、従業員を次に挙げる 3 つの Windows グループに分類しています。

• HRDept (人事部門のメンバ)

  このグループのメンバは、すべての従業員の情報を取得できます。

• PayrollDept (給与支払部門のメンバ)

  このグループのメンバは、すべての従業員の情報を取得できます。

• Employees (すべての従業員)

  このグループのメンバは、各自の情報のみを取得できます。

個人情報には機密性があるため、すべてのノード間のトラフィックをセキュリティで保護する必要があります。

特徴

• ユーザーは Internet Explorer 5.x 以上を使用します。
• すべてのコンピュータが Windows 2000 以降を実行しています。
• ユーザー アカウントは Active Directory の 1 つのフォレストに格納されています。
• アプリケーションは最初の呼び出し元のセキュリティ コンテキストをデータベースまでフローします。
• すべての層で Windows 認証を使用します。
• ドメイン ユーザー アカウントの委任を有効に設定します。
• データベースは委任をサポートしません。

このシナリオのセキュリティ対策

このシナリオでは、ASP.NET Web アプリケーションをホストする Web サーバーが最初の呼び出し元の ID を認証し、Web サービスをホストするリモート サーバーに最初の呼び出し元のセキュリティ コンテキストをフローします。これによって、Web メソッドに認定チェックを適用することが可能となり、最初の呼び出し元に対してアクセスを許可または拒否することができます。データベースは Web サービスのプロセス ID を認証します (データベースは Web サービスを信頼)。次に、Web サービスはデータベース呼び出しを実行し、ストアド プロシージャのパラメータを使用してユーザーの ID をアプリケーション レベルで渡します。

表 5.3 セキュリティ対策

結果

このシナリオの推奨セキュリティ構成を図 5.6 に示します。

図 5.6 ASP.NET - Web サービス - SQL Server イントラネット シナリオの推奨セキュリティ構成

セキュリティ構成の設定

作業を始める前に、以下のドキュメントを参照してください。

• Web サーバーにおける SSL の構成 (このガイドの「パート IV : 参照」の「Web サーバー上で SSL を設定する方法」を参照)
• IPSec の構成 (このガイドの「パート IV : 参照」の「2 つのサーバー間の通信を IPSec で保護する方法」を参照)

Web サーバーの構成 (Web アプリケーションをホストするサーバー)

wsproxy.Credentials = CredentialCache.DefaultCredentials;

資格情報付きで Web サービスを呼び出す方法の詳細については、「[第 10 章 Web サービス セキュリティ](cc465521\(v=msdn.10\).md)」を参照してください。

[WebMethod]
[PrincipalPermission(SecurityAction.Demand, 
                  Role=@"DomainName?HRDept)]
public DataSet RetrieveEmployeeDetails()
{
}

string pwd = Request.ServerVariables["AUTH_PASSWORD"];
string uid = Request.ServerVariables["AUTH_USER"];
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, "Negotiate", credentials);
channelProperties["credentials"] = credCache;
channelProperties["preauthenticate"] = true;

リモート リソースを呼び出す前に以下の外部関数を呼び出します。 

詳細については、「<a runat="server" href="cc465515(v=msdn.10).md">第 
            9 章 Enterprise Services セキュリティ</a>」参照してください。
            <p /></td></tr> <tr> <td class="data" valign="top">Enterprise Services アプリケーションをサーバー 
            アプリケーションとして構成します。</td> <td class="data" valign="top">この構成には、コンポーネント サービス ツールを使用するか、サービス コンポーネント 
            アセンブリに含まれる以下の .NET 属性を使用します。 

</td></tr> <tr> <td class="data" valign="top">Enterprise Services アプリケーションをパケット 
            プライバシー認証として構成します (暗号化と共にセキュリティで保護された通信を提供するため)。</td> <td class="data" valign="top">サービス コンポーネント アセンブリに次の .NET 属性を追加します。 

</td></tr> <tr> <td class="data" valign="top">Enterprise Services アプリケーションでコンポーネント 
            レベルのロール ベース セキュリティを有効にします。</td> <td class="data" valign="top">プロセス レベルおよびコントロール レベル (インターフェイスとクラスを含む) 
            でロール チェックを構成するには、次の属性を使用します。 

クラスを以下の属性で修飾します。 

インターフェイス レベルおよびメソッド レベルのロール 
            チェックの構成については、「第 9 章 Enterprise Services セキュリティ」の「<a runat="server" href="cc465515(v=msdn.10).md">セキュリティの構成</a>」を参照してください。</td></tr> <tr> <td class="data" valign="top">Enterprise Services を実行するカスタム 
            アカウントを作成し、Active Directory で "コンピュータを委任に対して信頼する" としてマークします。</td> <td class="data" valign="top">Enterprise Services アプリケーションは、Active 
            Directory で "コンピュータを委任に対して信頼する" とマークされたドメイン 
            アカウントとして動作する必要があります。詳細については、このガイドの「パート IV : 参照」の「<a runat="server" href="cc465525(v=msdn.10).md">Windows 
            2000 での Kerberos 委任の構成方法</a>」を参照してください。</td></tr> <tr> <td class="data" valign="top">Enterprise Services をカスタム 
            アカウントとして実行できるように構成します。</td> <td class="data" valign="top">この構成には、必ずコンポーネント サービス 
            ツールまたはスクリプトを使用します。サービス コンポーネント アセンブリ内の .NET 
        属性を使用することはできません。</td></tr></tbody></table>  
<table class="data" xmlns="http://www.w3.org/1999/xhtml"> <tbody> <tr> <th class="data" align="left" width="20%" colspan="2">データベース サーバー (SQL 
            Server) の構成</th></tr> <tr> <th class="data" align="left" width="20%">手順</th> <th class="data" align="left" width="80%">詳細情報</th></tr> <tr> <td class="data" valign="top">SQL Server を Windows 認証として構成します。</td> <td class="data" valign="top">　</td></tr> <tr> <td class="data" valign="top">ユーザーが属する Windows グループの SQL Server 
            ログインを作成します。</td> <td class="data" valign="top">これにより、SQL Server 
            へのアクセス権を付与します。<br />アクセス制御ポリシーでは Windows 
            グループをロールとして扱います。たとえば、Employees、HRDept、PayrollDept 
            などのグループを作成することもできます。</td></tr> <tr> <td class="data" valign="top">各 SQL Server ログインの新しいデータベース ユーザーを作成します。</td> <td class="data" valign="top">これにより、指定したデータベースへのアクセス権を付与します。</td></tr> <tr> <td class="data" valign="top">データベース ユーザーのデータベース アクセス許可を設定します。</td> <td class="data" valign="top">最低限のアクセス許可を割り当てます。<br />詳細については、「<a runat="server" href="cc465522(v=msdn.10).md">第 
            12 章 データ アクセス セキュリティ</a>」を参照してください。</td></tr></tbody></table>

### 分析

  - 最初の呼び出し元のセキュリティ コンテキストをフローするうえで重要となるのが、委任レベルのトークンを生成する Kerberos 認証です。委任レベルのトークンを受け取ったサーバー プロセス (IIS) は、その委任レベルを変更せずに、同じコンピュータの任意のアカウントで実行されている他のプロセスにそのトークンを渡すことができます。ワーカー プロセスが、ローカル アカウントとドメイン アカウントのどちらとして動作しているのかは関係ありません。問題となるのは、IIS がどのアカウントとして動作しているかです。IIS が LocalSystem 以外のアカウントとして動作している場合、そのアカウントは Active Directory で "コンピュータを委任に対して信頼する" としてマークされている必要があります。
    
    IIS が LocalSystem として動作している場合、そのコンピュータ アカウントは "Trusted for delegation" とマークされている必要があります詳細については、このガイドの「パート IV : 参照」の「[Windows 2000 での Kerberos 委任の構成方法](cc465525\(v=msdn.10\).md)」を参照してください。

  - このシナリオでは、すべてのユーザーが Windows アカウントを持ち、Internet Explorer 5.x 以上を使用しているので、IIS の Windows 統合認証 (Kerberos 認証) が最適です。Windows 統合認証の利点は、ユーザーのパスワードがネットワーク上に送信されないことです。また、Windows が対話ユーザーの現在のログオン セッションを使用するので、ログオンはユーザーにとって透過的です。

  - ASP.NET は WindowsPrincipal オブジェクトを作成し、それを現在の Web 要求コンテキスト (HttpContext.User) にアタッチします。Web アプリケーション内で認定チェックを実行する必要がある場合は、次のコードを使用します。 

    
    ASP.NET FileAuthorizationModule は、IIS 内で Aspnet\_isapi.dll にマップされた ASP.NET ファイルについて、最初の呼び出し元に対する ACL チェックを実行します。IIS は、.jpg、.gif、.htm などの静的ファイルに対するゲートキーパーの役割を果たし、最初の呼び出し元の ID を使用してアクセス チェックを実行します。

  - SQL Server への接続に Windows 認証を使用すると、資格情報はアプリケーション サーバー上のファイルに保存されず、ネットワーク上で転送されることもありません。たとえば、次のように、接続文字列に Trusted\_Connection 属性を含めます。 

  - 最初の呼び出し元のコンテキストはすべての層を経由してフローされるため、監査がきわめて容易になります。プラットフォーム レベルの監査を実行できます (Windows や SQL Server が提供する監査機能など)。

### 注意点

  - Windows 2000 で Explorer 6.0 を使用している場合、ネゴシエートされる既定の認証メカニズムは NTLM です (Kerberos ではありません)。詳細については、Microsoft サポート技術情報の Knowledge Base の文書 299838「\[IE6\] アップグレード後に統合 Windows 認証ができない」を参照してください。
  - 層を越えたユーザー委任を使用すると、信頼されたサブシステム モデルを使用した場合と比較し、パフォーマンスとアプリケーションのスケーラビリティが低下します。デデータベース接続は最初の呼び出し元のセキュリティ コンテキストと結び付いており、効率的なプールができないため、データベースへの接続プールを利用することはできません。
  - このアプローチでは、Windows グループがアプリケーションのセキュリティ要件に見合ったレベルまで細分化されていることも前提となります。つまり、アプリケーションにアクセスする同じセキュリティ特権を持つユーザーの分類に対応する細分度で Windows グループを設定する必要があります。

## まとめ

この章では、一般的なイントラネット アプリケーション シナリオをセキュリティで保護する方法について説明しました。

エクストラネット アプリケーションおよびインターネット アプリケーションのシナリオについては、「[第 6 章 エクストラネット セキュリティ](cc465511\(v=msdn.10\).md)」と「[第 7 章 インターネット セキュリティ」を参照してください。](cc465513\(v=msdn.10\).md)