セキュリティ保護された 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 セキュリティ対策

分類	詳細
認証	IIS で Windows 統合認証を使用し、Web サーバーで最初の呼び出し元に対する強力な認証を実行します。 ASP.NET 内で Windows 認証を使用します (偽装なし)。 認証方法を Windows 認証に設定した SQL Server データベースとの接続をセキュリティで保護します。 このデータベースは ASP.NET ワーカー プロセスを信頼して呼び出しを実行させます。ASP.NET プロセス ID はデータベース側で認証します。
認定	最初の呼び出し元に関連付けられた ACL を使用して Web サーバーのリソースを構成します。管理を容易にするために、ユーザーを Windows グループに追加し、ACL ではグループを使用します。 Web アプリケーションは、最初の呼び出し元に対して .NET ロール チェックを実行し、ページへのアクセスを制限します。
セキュリティで保護された通信	Web サーバーとデータベースの間で送信される機密データをセキュリティで保護します。 最初の呼び出し元と Web アプリケーションの間で送信される機密データをセキュリティで保護します。

結果

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

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

セキュリティ構成の設定

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

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

IIS の構成

手順	詳細情報
Web アプリケーションの仮想ルート ディレクトリで匿名アクセスを無効にします。	IIS 認証を使用するには、IIS MMC スナップインを使用します。アプリケーションの仮想ディレクトリを右クリックして [プロパティ] を選択します。Windows 統合認証を有効にします。[ディレクトリ セキュリティ] タブをクリックし、[匿名アクセスおよび認証コントロール] の [編集] をクリックします。

ASP.NET の構成

手順	詳細情報
ASPNET パスワードを既知の方法による強力なパスワード値に変更します。	ASPNET は最低限の特権を持つローカル アカウントであり、ASP.NET Web アプリケーションの実行に使用される既定のアカウントです。 [ローカル ユーザーとグループ] を使用して、ASPNET アカウントのパスワードを既知の値に設定します。 %windir%\Microsoft.NET\Framework\v1.0.3705\CONFIG にある Machine.config を開きます。 <!-- userName="machine" password="AutoGenerate" --> 変更後 <!-- userName="machine" password="YourNewStrongPassword" -->
ASP.NET Web アプリケーションを Windows 認証として構成します。	アプリケーションの仮想ディレクトリ ルートにある Web.config を開きます。
偽装がオフになっていることを確認します。	偽装は既定でオフに設定されていますが、念のため Web.config を開き、次のように設定されていることを確認してください。 ``` ``` 要素を削除することによって、偽装をオフにすることもできます。

SQL Server の構成

手順	詳細情報
SQL Server コンピュータ上に、ASP.NET プロセス アカウント (ASPNET) と一致する Windows アカウントを作成します。	ユーザー名とパスワードは ASPNET アカウントと同じであることが必要です。 このアカウントには以下の特権を与えます。 - このコンピュータにネットワークからアクセスする。 - ログオンをローカルで拒否する。 - バッチ ジョブとしてログオンする。
SQL Server を Windows 認証として構成します。
ローカル ASPNET アカウントの SQL Server ログインを作成します。	これにより、SQL Server へのアクセス権を付与します。
新しいデータベース ユーザーを作成し、そのユーザーにログイン名をマップします。	これにより、指定したデータベースへのアクセス権を付与します。
新しいユーザー定義のデータベース ロールを作成し、そのロールにデータベース ユーザーを追加します。
このデータベース ロールのデータベース アクセス許可を設定します。	最低限のアクセス許可を割り当てます。 詳細については、「第 12 章 データ アクセス セキュリティ」を参照してください。

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

手順	詳細情報
Web サイトを SSL に対応するように構成します。	このガイドの「パート IV : 参照」の「Web サーバー上で SSL を設定する方法」を参照してください。
Web サーバーとデータベース サーバーの間に IPSec を構成します。	このガイドの「パート IV : 参照」の「2 つのサーバー間の通信を IPSec で保護する方法」を参照してください。

分析

• このシナリオでは、すべてのユーザーが 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 セキュリティ対策

分類	詳細
認証	Windows 統合認証を使用して、Web サーバーで強力な認証を実行します。 Enterprise Services (COM+) ロール チェックをサポートするために、最初の呼び出し元のセキュリティ コンテキストをサービス コンポーネントにフローします。 Windows 認証を使用してデータベース接続をセキュリティで保護します。 データベースは、データベース呼び出しを実行することについてサービス コンポーネントの ID を信頼します。データベースは Enterprise Services アプリケーション プロセス ID を認証します。
認定	Enterprise Services (COM+) ロールを使用して、ビジネス ロジックへのアクセスを認定します。
セキュリティで保護された通信	SSL を使用して、ユーザーと Web アプリケーションの間で送信される機密データをセキュリティで保護します。 IPSec を使用して、Web サーバーとデータベースの間で送信される機密データをセキュリティで保護します。

結果

このシナリオの推奨セキュリティ構成を図 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 の構成

手順	詳細情報
Web アプリケーションの仮想ルート ディレクトリで匿名アクセスを無効にします。
Windows 統合認証を有効にします。

ASP.NET の構成

手順	詳細情報
ASP.NET Web アプリケーションを Windows 認証として構成します。	アプリケーションの仮想ディレクトリ ルートにある Web.config を開きます。
ASP.NET Web アプリケーションを偽装に対応するように構成します。	Web アプリケーションの仮想ディレクトリにある Web.config を開きます。
Enterprise Services に対する呼び出しが呼び出し元の偽装をサポートするように、ASP.NET DCOM のセキュリティを構成します。	Machine.config を開き、 要素を見つけます。comImpersonationLevel 属性が Impersonate に設定されていることを確認します (既定の設定)。 ```

Enterprise Services の構成

手順	詳細情報
Enterprise Services を実行するためのカスタム アカウントを作成します。	メモ ローカル アカウントを使用する場合は、SQL Server コンピュータに複製アカウントも作成する必要があります。
Enterprise Services アプリケーションをサーバー アプリケーションとして構成します。	この構成には、コンポーネント サービス ツールを使用するか、サービス コンポーネント アセンブリに含まれる次の .NET 属性を使用します。 ``` [assembly: ApplicationActivation(ActivationOption.Server)] ```
Enterprise Services (COM+) ロールを構成します。	コンポーネント サービス ツールまたはスクリプトを使用して、Windows ユーザーとグループのいずれか、または両方をロールに追加します。 ロールを定義するには、サービス コンポーネント アセンブリ内で .NET 属性を使用します。
Enterprise Services をカスタム アカウントとして実行できるように構成します。	この構成には、必ずコンポーネント サービス ツールまたはスクリプトを使用します。サービス コンポーネント アセンブリ内の .NET 属性を使用することはできません。

SQL Server の構成

手順	詳細情報
SQL Server コンピュータ上に、Enterprise Services プロセス アカウントと一致する Windows アカウントを作成します。	ユーザー名とパスワードはカスタム Enterprise Services アカウントと同じであることが必要です。 このアカウントには以下の特権を与えます。 - このコンピュータにネットワークからアクセスする。 - ログオンをローカルで拒否する。 - バッチ ジョブとしてログオンする。
SQL Server を Windows 認証として構成します。
Enterprise Services アカウントの SQL Server ログインを作成します。	これにより、SQL Server へのアクセス権を付与します。
新しいデータベース ユーザーを作成し、そのユーザーにログイン名をマップします。	これにより、指定したデータベースへのアクセス権を付与します。
新しいデータベース ユーザー ロールを作成し、そのロールにデータベース ユーザーを追加します。
このデータベース ユーザー ロールのデータベース アクセス許可を設定します。	最低限のアクセス許可を割り当てます。 詳細については、「第 12 章 データ アクセス セキュリティ」を参照してください。

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

手順	詳細情報
Web サイトを SSL に対応するように構成します。	このガイドの「パート IV : 参照」の「Web サーバー上で SSL を設定する方法」を参照してください。
Web サーバーとデータベース サーバーの間に IPSec を構成します。	このガイドの「パート IV : 参照」の「2 つのサーバー間の通信を IPSec で保護する方法」を参照してください。

分析

• 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 セキュリティ対策

分類	詳細
認証	Web アプリケーションは IIS からの Windows 統合認証を使用してユーザーを認証します。 Web サービスは IIS からの Windows 統合認証を使用します。Web サービスは Web アプリケーションから委任された最初の呼び出し元のセキュリティ コンテキストを認証します。 Kerberos 認証プロトコルを使用して、最初の呼び出し元のセキュリティ コンテキストを委任によって Web アプリケーションから Web サービスまでフローします。 Windows 認証を使用して、ASP.NET プロセス アカウントでデータベースに接続します。
認定	Web アプリケーションは、最初の呼び出し元に対してロール チェックを実行し、ページへのアクセスを制限します。 Web サービス メソッドへのアクセスは、.NET ロールを使用し、最初の呼び出し元の Windows グループ メンバシップに基づいて制御します。
セキュリティで保護された通信	SSL を使用して、最初の呼び出し元と Web アプリケーションおよび Web サービスの間で転送される機密データをセキュリティで保護します。 IPSec を使用して、Web サービスとデータベースの間で転送される機密データをセキュリティで保護します。

結果

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

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

セキュリティ構成の設定

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

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

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

IIS の構成
手順	詳細情報
Web アプリケーションの仮想ルート ディレクトリで匿名アクセスを無効にします。 Web アプリケーションの仮想ルートで Windows 統合認証を有効にします。
ASP.NET の構成
手順	詳細情報
ASP.NET Web アプリケーションを Windows 認証として構成します。	Web アプリケーションの仮想ディレクトリにある Web.config を開きます。 アプリケーション サーバーの構成 (Web サービスをホストするサーバー) IIS の構成 手順 詳細情報 Web サービスの仮想ルート ディレクトリで匿名アクセスを無効にします。 Web サービスの仮想ルート ディレクトリで Windows 統合認証を有効にします。 　 ASP.NET の構成 手順 詳細情報 ASPNET パスワードを既知の値に変更します。 ASPNET は最低限の特権を持つローカル アカウントであり、ASP.NET Web アプリケーションの実行に使用される既定のアカウントです。 [ローカル ユーザーとグループ] を使用して、ASPNET アカウントのパスワードを既知の値に設定します。 %windir%\Microsoft.NET\Framework\v1.0.3705\CONFIG にある Machine.config を開き、 SQL Server の構成 手順 詳細情報 SQL Server コンピュータ上に、Web サービスを実行するために使用する ASP.NET プロセス アカウントと一致する Windows アカウントを作成します。 ユーザー名とパスワードはカスタム ASP.NET アカウントと同じであることが必要です。 このアカウントには以下の特権を与えます。 - このコンピュータにネットワークからアクセスする。 - ログオンをローカルで拒否する。 - バッチ ジョブとしてログオンする。 SQL Server を Windows 認証として構成します。 　 カスタム ASP.NET アカウントの SQL Server ログインを作成します。 これにより、SQL Server へのアクセス権を付与します。 新しいデータベース ユーザーを作成し、そのユーザーにログイン名をマップします。 これにより、指定したデータベースへのアクセス権を付与します。 新しいデータベース ユーザー ロールを作成し、そのロールにデータベース ユーザーを追加します。 　 このデータベース ユーザー ロールのデータベース アクセス許可を設定します。 最低限のアクセス許可を割り当てます。 セキュリティで保護された通信の構成 手順 詳細情報 Web サーバー上の Web サイトを SSL に対応するように構成します。 このガイドの「パート IV : 参照」の「Web サーバー上で SSL を設定する方法」を参照してください。 Web サーバーとデータベース サーバーの間に IPSec を構成します。 このガイドの「パート IV : 参照」の「2 つのサーバー間の通信を IPSec で保護する方法」を参照してください。 分析 このシナリオでは、IIS での Windows 統合認証が理想的です。すべてのユーザーが Windows 2000 以上および Internet Explorer 5.x 以上を使用し、Active Directory にアカウントが登録されているため、委任をサポートする Kerberos 認証プロトコルを使用できるからです。これによって、コンピュータの境界を越えてユーザーのセキュリティ コンテキストをフローすることが可能となります。 Active Directory において、エンド ユーザー アカウントが "アカウントは重要なので委任できない" とマークされていないことが必要です。Web サーバー コンピュータのアカウントは Active Directory で "コンピュータを委任に対して信頼する" とマークされていることが必要です。詳細については、このガイドの「パート IV : 参照」の「Windows 2000 での Kerberos 委任の構成方法」を参照してください。 Web サーバーおよびアプリケーション サーバー上の ASP.NET は最低限の特権を持つローカル アカウント (ローカル ASPNET アカウント) で実行されるため、不正アクセスによる潜在的な損害は緩和されます。 Web サービスと Web アプリケーションは、どちらも認証方法を Windows 認証として構成します。両コンピュータの IIS は、Windows 統合認証として構成します。 Web アプリケーションから Web サービスを呼び出したとき、既定では資格情報は渡されません。資格情報は、下位 Web サーバーの IIS が発行したネットワーク認証チャレンジに応答するために必要です。Web アプリケーションから Web サービスを呼び出したときに資格情報が送信されるようにするには、Web サービス プロキシの "資格情報" プロパティを次のように設定します。 wsproxy.Credentials = CredentialCache.DefaultCredentials; 資格情報付きで Web サービスを呼び出す方法の詳細については、「[第 10 章 Web サービス セキュリティ](cc465521\(v=msdn.10\).md)」を参照してください。 Web アプリケーションでは偽装を有効にします。その結果、Web アプリケーションから Web サービスが呼び出されると、最初の呼び出し元のセキュリティ コンテキストがフローされ、Web サービスで最初の呼び出しの認証 (および認定) が可能となります。 Web サービスでは、.NET ロールが使用され、ユーザーが属する Windows グループ (HRDept、PayrollDept、および Employees) に基づいてユーザーが認定されます。HRDept グループと PayrollDept グループのメンバは、すべての従業員の個人情報を取得できますが、Employees グループのメンバは、各自の固有の情報しか取得できません。 次のサンプル コードに示すようにWeb メソッドに PrincipalPermissionAttribute クラスで注釈を付け、特定のロール メンバシップを要求することができます。PrincipalPermissionAttribute の代わりに PrincipalPermission を使用することもできます。これは、すべての .NET 属性の種類に共通の機能です。 [WebMethod] [PrincipalPermission(SecurityAction.Demand, Role=@"DomainName?HRDept)] public DataSet RetrieveEmployeeDetails() { } このサンプル コードにある属性は、DomainName\HRDept Windows グループのメンバだけが RetrieveEmployeeDetails メソッドを呼び出せることを意味します。このグループに属していないユーザーがこのメソッドを呼び出そうとすると、セキュリティ例外がスローされます。 ASP.NET ファイル認定 (Web アプリケーションおよび Web サービス内) は、ファイルの種類を Aspnet_isapi.dll にマップする IIS メタベース内にマップが存在するファイルの種類について、呼び出し元に対する ACL チェックを実行します。ISAPI マッピングが存在しない静的ファイル (.jpg、.gif、.htm など) は、IIS によってチェックされます (この場合もファイルに添付された ACL を使用します)。 Web アプリケーションでは偽装を有効に設定しているので、そのアプリケーション自体がアクセスするリソースには、最初の呼び出し元に最低でも読み取りアクセス権を付与する ACL を設定する必要があります。 Web サービスは、偽装も委任もオフに設定されているので、ローカル システム リソースやデータベースにアクセスするときには ASP.NET プロセス ID を使用します。このため、すべての呼び出しが 1 つのプロセス アカウントを使用して実行されます。これによって、データベース接続プールが使用可能となります。委任をサポートしないデータベース (SQL Server 7.0 以前など) の場合は、この方法が適しています。 SQL Server の認証方法を Windows 認証に設定することによって、資格情報は Web サーバーに保存されず、ネットワークを介して SQL Server に送信されることもありません。 最初の呼び出し元と Web サーバーの間に SSL を導入することによって、Web アプリケーションとの間でやり取りするデータが保護されます。 下位の Web サーバーとデータベースの間に IPSec を導入することによって、データベースとの間でやり取りするデータが保護されます。 注意点 データベース サーバー上の複製された Windows アカウント (ASPNET プロセス アカウントと一致するアカウント) を使用すると、管理の負担が増加します。パスワードの更新および同期を手動で定期的に行う必要があります。 別の方法として、最低限の特権を持ったドメイン アカウントを使用することもできます。ASP.NET プロセス ID の選択の詳細については、「第 8 章 ASP.NET セキュリティ」を参照してください。 .NET ロール ベースのセキュリティは Windows グループのメンバシップを基礎とするため、このソリューションでは、Windows グループがアプリケーションにアクセスするユーザーの分類に対応するレベルまで細分化されていることが必要となります。 Kerberos 委任には制限がないので、Web サーバーでどのアプリケーション ID を実行するのかを慎重に指定する必要があります。セキュリティ レベルを上げるには、ドメイン アカウントの適用範囲を狭くします。そのためには、ドメイン アカウントを Domain Users グループから削除し、適切なコンピュータからのアクセスだけを許可します。詳細については、ホワイト ペーパー「既定のアクセス制御設定」を参照してください。 Q&A 関連シナリオ SQL Server 以外のデータベースに接続する必要がある場合、または現在 SQL Server 認証を使用している場合には、接続文字列を使用して、データベース アカウントの資格情報を明示的に渡す必要があります。その場合には、接続文字列を保存するときにセキュリティで保護する必要があります。 詳細については、「第 12 章 データ アクセス セキュリティ」の「接続文字列をセキュリティで保護して保存する」を参照してください。 ASP.NET - リモート処理 - SQL Server このシナリオでは、ASP.NET ページを実行する Web サーバーは、リモート アプリケーション サーバー上のリモート コンポーネントとセキュリティで保護された接続を確立します。このコンポーネントと Web サーバーの通信には、HTTP チャネルを介する .NET リモート処理を使用します。リモート コンポーネントは ASP.NET でホストします。このシナリオを図 5.7 に示します。 図 5.7 ASP.NET - .NET リモート処理 - SQL Server 特徴 ユーザーはさまざまな種類の Web ブラウザを使用します。 リモート コンポーネントは ASP.NET でホストします。 Web アプリケーションは HTTP チャネルを使用してリモート コンポーネントと通信します。 ASP.NET アプリケーションは .NET リモート コンポーネントを呼び出し、認証のために最初の呼び出し元の資格情報を渡します。資格情報は基本認証によって取得できます。 このデータは機密性が高いため、プロセスとコンピュータ間においてセキュリティで保護する必要があります。 このシナリオのセキュリティ対策 このシナリオでは、ASP.NET Web アプリケーションをホストする Web サーバーが最初の呼び出し元を認証します。Web アプリケーションは、呼び出し元の認証資格情報 (ユーザー名とパスワード) を HTTP サーバー変数から取得できます。次に、Web アプリケーションは、リモート コンポーネント プロキシを構成することによって、取得した資格情報を使用し、リモート コンポーネントをホストするアプリケーション サーバーに接続します。データベースは、Windows 認証を使用して ASP.NET プロセス ID を認証します (つまり、データベースはリモート コンポーネントを信頼します)。次に、リモート コンポーネントはデータベースを呼び出し、ストアド プロシージャのパラメータを使用して最初の呼び出し元の ID をアプリケーション レベルで渡します。 表 5.4 セキュリティ対策 分類 詳細 認証 SSL に加えて基本認証を使用し、IIS からユーザーを認証します。 リモート コンポーネント (ASP.NET および IIS) から Windows 認証を使用します。 Windows 認証を使用して、最低限の特権を持つ ASP.NET アカウントでデータベースに接続します。 認定 Web サーバーで最初の呼び出し元に対して ACL チェックを実行します。 リモート コンポーネント内で、最初の呼び出し元に対してロール チェックを実行します。 ASP.NET (リモート コンポーネント) ID に対してデータベース アクセス許可を与えます。 セキュリティで保護された通信 SSL を使用して、ユーザーと Web アプリケーションおよびユーザーと IIS でホストされるリモート オブジェクトの間で送信される機密データをセキュリティで保護します。 IPSec を使用して、Web サーバーとデータベースの間で送信される機密データをセキュリティで保護します。 結果 このシナリオの推奨セキュリティ構成を図 5.8 に示します。 図 5.8 ASP.NET - リモート Web サービス - SQL Server イントラネット シナリオの推奨セキュリティ構成 セキュリティ構成の設定 作業を始める前に、以下のドキュメントを参照してください。 最低限の特権を持つデータベース アカウントの作成 (「第 12 章 データ アクセス セキュリティ」を参照) Web サーバーにおける SSL の構成 (このガイドの「パート IV : 参照」の「Web サーバー上で SSL を設定する方法」を参照) IPSec の構成 (このガイドの「パート IV : 参照」の「2 つのサーバー間の通信を IPSec で保護する方法」を参照) Web サーバーの構成 IIS の構成 手順 詳細情報 Web アプリケーションの仮想ルート ディレクトリで匿名アクセスを無効にします。 　 基本認証を有効にします。 SSL を使用して、基本認証に使用する資格情報を保護します。 ASP.NET の構成 手順 詳細情報 ASP.NET Web アプリケーションを Windows 認証として構成します。 アプリケーションの仮想ディレクトリ ルートにある Web.config を開きます。 アプリケーション サーバーの構成 IIS の構成 手順 詳細情報 Web アプリケーションの仮想ルート ディレクトリで匿名アクセスを無効にします。 Windows 統合認証を有効にします。 　 ASP.NET の構成 手順 詳細情報 リモート コンポーネント (ASP.NET 内) を Windows 認証として構成します。 リモート コンポーネントの仮想ディレクトリ ルートにある Web.config を開きます。 SQL Server の構成 手順 詳細情報 SQL Server コンピュータ上に、Web サービスを実行するために使用する ASP.NET プロセス アカウントと一致する Windows アカウントを作成します。 ユーザー名とパスワードはカスタム ASP.NET アカウントと同じであることが必要です。 このアカウントには以下の特権を与えます。 - このコンピュータにネットワークからアクセスする。 - ログオンをローカルで拒否する。 - バッチ ジョブとしてログオンする。 SQL Server を Windows 認証として構成します。 　 カスタム ASP.NET アカウントの SQL Server ログインを作成します。 これにより、SQL Server へのアクセス権を付与します。 新しいデータベース ユーザーを作成し、そのユーザーにログイン名をマップします。 これにより、指定したデータベースへのアクセス権を付与します。 新しいデータベース ユーザー ロールを作成し、そのロールにデータベース ユーザーを追加します。 　 このデータベース ユーザー ロールのデータベース アクセス許可を設定します。 最低限のアクセス許可を割り当てます。 セキュリティで保護された通信の構成 手順 詳細情報 Web サーバー上の Web サイトを SSL に対応するように構成します。 このガイドの「パート IV : 参照」の「Web サーバー上で SSL を設定する方法」を参照してください。 アプリケーション サーバー上の Web サイトを SSL に対応するように構成します。 このガイドの「パート IV : 参照」の「Web サーバー上で SSL を設定する方法」を参照してください。 アプリケーション サーバーとデータベース サーバーの間に IPSec を構成します。 このガイドの「パート IV : 参照」の「2 つのサーバー間の通信を IPSec で保護する方法」を参照してください。 分析 Web サーバーおよびアプリケーション サーバー上の ASP.NET は最低限の特権を持つローカル アカウントとして実行されるので、不正アクセスによる潜在的な損害は緩和されます。どちらの場合も既定の ASPNET アカウントを使用します。 ASPNET ローカル アカウント (SQL Server コンピュータに複製されたアカウント) を使用すると、潜在的なセキュリティ リスクはさらに減少します。データベース サーバーに複製された Windows アカウントがあることによって、リモート コンポーネントをアプリケーション サーバー上で最低限の特権を持つ ASP.NET アカウントとして実行できます。 Web サーバーでの基本認証によって、Web アプリケーションはユーザーの資格情報を使用して、アプリケーション サーバーからの Windows 認証チャレンジに応答できます。 呼び出し元の資格情報を使用してリモート コンポーネントを呼び出すために、Web アプリケーションでは次に示すコードによってリモート コンポーネント プロキシを構成します。 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; セキュリティ資格情報のリモート コンポーネントへのフローについては、「第 11 章 .NET リモート処理のセキュリティ」を参照してください。 リモート処理プロキシは、基本認証によって取得されるユーザーの資格情報を使用して個別に構成されるため、ASP.NET Web アプリケーションでは偽装を有効にしません。Web アプリケーションがアクセスする他のリソースは、ASP.NET プロセス アカウントから得られるセキュリティ コンテキストを使用します。 ユーザーと Web サーバー間において SSL は、Web サーバーとの間でやり取りするデータを保護すると共に、認証プロセス中にクリア テキストで渡される基本資格情報も保護します。 アプリケーション サーバーで実行される Windows 統合認証では、最初の呼び出し元に対する .NET ロール チェックを実行します。.NET ロールは、Windows グループに対応しています。 ロール ベースのチェックは、偽装がオフである場合でも実行可能です。 ASP.NET ファイル認定は、ファイルの種類を aspnet_isapi.dll にマップする IIS メタベース内にマップが存在するファイルの種類について、呼び出し元に対する ACL チェックを実行します。IIS は静的ファイル (IIS 内で ISAPI 拡張機能にマップされていないファイル) に対してアクセス チェックを実行します。 アプリケーション サーバーでは偽装が有効になっていないので、リモート コンポーネントが実行するローカルまたはリモート リソース アクセスでは、ASPNET セキュリティ コンテキストを使用します。それに応じて ACL を設定する必要があります。 SQL Server の認証方法を Windows 認証に設定することによって、資格情報はアプリケーション サーバーに保存されず、ネットワークを介して SQL Server に送信されることもありません。 注意点 データベース サーバー上の複製された Windows アカウント (ASPNET プロセス アカウントと一致するアカウント) を使用すると、管理の負担が増加します。パスワードの更新および同期を手動で定期的に行う必要があります。 .NET ロール ベースのセキュリティは Windows グループのメンバシップを基礎とするため、このソリューションでは、Windows グループがアプリケーションにアクセスするユーザーの分類に対応するレベルまで細分化されていることが必要となります。 関連シナリオ Web サーバーは Kerberos を使用して呼び出し元を認証します。Kerberos の委任を使用して、最初の呼び出し元のセキュリティ コンテキストをアプリケーション サーバー上のリモート コンポーネントまでフローします。 このアプローチでは、すべてのユーザー アカウントで委任を有効になるよう構成することが必要です。Web アプリケーションにおいて偽装を有効に設定し、DefaultCredentials を使用してリモート コンポーネント プロキシを構成することもできます。このテクニックについては、「第 11 章 .NET リモート処理のセキュリティ」の「最初の呼び出し元のフロー」で詳しく説明します。 最初の呼び出し元をデータベースにフローする これまでのシナリオでは、信頼されたサブシステム モデルを使用しており、どのような状況でも、データベースはアプリケーション サーバーまたは Web サーバーがユーザーを正しく認証および認定することについて信頼していました。信頼されたサブシステム モデルには多くの利点がありますが、シナリオによっては (監査上の理由などから) 偽装および委任モデルを使用し、最初の呼び出し元のセキュリティ コンテキストをコンピュータ境界を越えてデータベースまでフローする必要があります。 最初の呼び出し元をデータベースまでフローしなければならない一般的な理由としては、次の 2 つがあります。 データベースのアクセス権を細分化し、アクセス許可をオブジェクトごとに制御する必要がある。個々のオブジェクトについて、読み取りが可能なユーザーやグループもいれば、書き込みができるユーザーやグループもいます。 この点は、ロールのメンバシップによって各オブジェクトの読み取り権と書き込み権が決まる、細分性の低いタスク ベースの認定とは対照的です。 ID をフローし、アプリケーション レベルで監査を実行するのではなく、プラットフォームの監査機能を使用した方がよい場合がある。 社内のセキュリティ ポリシーに規定されているため選択する必要があるなどの理由から、偽装および委任モデルを選択して、最初の呼び出し元のセキュリティ コンテキストをいくつかのアプリケーションを経由してバックエンドまでフローする場合は、委任とネットワーク アクセスを念頭に置いて設計する必要があります (複数のコンピュータにまたがる場合、この作業は容易ではありません)。共有リソースのプール (データベース接続など) も重要な問題であり、アプリケーションのスケーラビリティを著しく低下させることがあります。 ここでは、次に上げる 2 つの最も一般的なアプリケーション シナリオにおいて偽装および委任モデルを実装する方法について説明します。 ASP.NET - SQL Server ASP.NET - Enterprise Services - SQL Server 信頼されたサブシステムと偽装および委任モデルの詳細およびそれらの相対的な利点については、「第 3 章 認証と認定」を参照してください。 ASP.NET - SQL Server このシナリオでは、最初の呼び出し元のセキュリティ コンテキストを使用してデータベースを呼び出します。ここで説明した認証方法には、基本認証と Windows 統合認証があります。Kerberos 委任シナリオについては、「ASP.NET - Enterprise Services - SQL Server」を参照してください。 Web サーバーで基本認証を使用する 次に示す基本認証の構成設定では、最初の呼び出し元をデータベースまでフローすることが可能となります。 表 5.5 セキュリティ対策 手順 詳細情報 認証 IIS から基本認証を使用してユーザーを認証します。 ASP.NET 内で Windows 認証を使用します。 ASP.NET では偽装を有効にします。 SQL Server との通信には Windows 認証を使用します。 認定 Web サーバーで最初の呼び出し元に対して ACL チェックを実行します。 最初の呼び出し元が Windows グループ (Managers、Tellers などのアプリケーション要件に基づくグループ) にマップされている場合は、最初の呼び出し元に対して .NET ロール チェックを実行してメソッドへのアクセスを制限できます。 セキュリティで保護された通信 SSL を使用して、Web サーバーとデータベースの間で送信されるクリア テキストの資格情報をセキュリティで保護します。 Web サーバーとデータベースの間で送信されるすべての機密データをセキュリティで保護するには、IPSec を使用します。 このアプローチでは、以下の点に留意する必要があります。 基本認証では、ポップアップ ダイアログ ボックスが表示され、ユーザーは資格情報 (ユーザー名とパスワード) を入力できます。 データベースは最初の呼び出し元を認識する必要があります。Web サーバーとデータベースが異なるドメインにある場合には、最初の呼び出し元を認証できるように、信頼関係を有効にする必要があります。 Web サーバーで Windows 統合認証を使用する Windows 統合認証を使用すると、NTLM 認証または Kerberos 認証が実行されることになります。Windows 統合認証は、クライアント コンピュータとサーバー コンピュータの構成によって異なります。 NTLM 認証は委任をサポートしません。そのため、最初の呼び出し元のセキュリティ コンテキストを Web サーバーから物理的に離れた場所にあるリモート データベースにフローすることはできません。ブラウザと Web サーバーの間では、NTLM 認証が可能な単一ネットワーク ホップが使用されます。NTLM 認証を使用するためには、Web サーバーに SQL Server をインストールする必要があります。この構成が適しているのは、きわめて小規模のイントラネット アプリケーションだけです。 ASP.NET - Enterprise Services - SQL Server このシナリオでは、ASP.NET ページがリモート Enterprise Services アプリケーションでホストされているビジネス コンポーネントを呼び出し、さらにその Enterprise Services アプリケーションがデータベースに接続します。最初の呼び出し元のセキュリティ コンテキストは、ブラウザからデータベースまでフローします。このシナリオを図 5.9 に示します。 図 5.9 ASP.NET が Enterprise Services 内のコンポーネントを呼び出し、Enterprise Services がデータベースを呼び出す 特徴 ユーザーは Internet Explorer 5.x 以上を使用します。 すべてのコンピュータが Windows 2000 以降を実行しています。 ユーザー アカウントは Active Directory の 1 つのフォレストに格納されています。 アプリケーションは、最初の呼び出し元のセキュリティ コンテキストをオペレーティング システム レベルでデータベースまでフローします。 すべての層で Windows 認証が使用されます。 ドメイン ユーザー アカウントは委任が有効になるよう構成し、Enterprise Services アプリケーションを実行するアカウントは Active Directory で "コンピュータを委任に対して信頼する" とマークされていることが必要です。 このシナリオのセキュリティ対策 このシナリオでは、Web サーバーで呼び出し元を認証します。最初の呼び出し元のセキュリティ コンテキストをリモート Enterprise Services アプリケーションまでフローするために、ASP.NET では偽装を有効になるよう構成する必要があります。Enterprise Services アプリケーションでは、呼び出し元のセキュリティ コンテキストがデータベースまで確実にフローするように、コンポーネント コードにおいて呼び出し元の偽装を明示的に指定することが必要です (CoImpersonateClient を使用)。 表 5.6 セキュリティ対策 手順 詳細情報 認証 すべての層 (Web サーバー、アプリケーション サーバー、データベース サーバー) が Kerberos 認証をサポートします。 認定 中間層において、認定チェックとして、最初の呼び出し元の ID に対する Enterprise Services (COM+) ロール チェックを実行します。 セキュリティで保護された通信 ブラウザと Web サーバー間で SSL を使用し、機密データをセキュリティで保護します。 ASP.NET とリモート Enterprise Services アプリケーション内のサービス コンポーネントの間で RPC パケット プライバシー (暗号化機能を提供) を使用します。 サービス コンポーネントとデータベースの間には IPSec を使用します。 結果 このシナリオの推奨セキュリティ構成を図 5.10 に示します。 図 5.10 ASP.NET が Enterprise Services 内のコンポーネントを呼び出し、Enterprise Services がデータベースを呼び出す。最初の呼び出し元のセキュリティ コンテキストがデータベースにフローする。 セキュリティ構成の設定 作業を始める前に、構成に関して以下の点に留意してください。 Enterprise Services プロセス アカウントは Active Directory で "コンピュータを委任に対して信頼する" とマークされていること、またエンド ユーザー アカウントは "アカウントは重要なので委任できない" とマークされていないことが必要です。詳細については、このガイドの「パート IV : 参照」の「Windows 2000 での Kerberos 委任の構成方法」を参照してください。 すべてのコンピュータが Windows 2000 以降を実行していることが必要です。これはクライアント (ブラウザ) コンピュータとすべてのサーバーについても同じです。 すべてのコンピュータが Active Directory に登録されており、同じフォレストに属している必要があります。 Enterprise Services をホストするアプリケーション サーバーには Windows 2000 SP3 がインストールされている必要があります。 Windows 2000 で Explorer 6.0 を使用している場合、既定では、必須の Kerberos 認証ではなく NTLM 認証となっています。Kerberos 委任を有効にする方法については、Microsoft サポート技術情報の Knowledge Base の文書 299838「[IE6] アップグレード後に統合 Windows 認証ができない」を参照してください。 Web サーバー (IIS) の構成 手順 詳細情報 Web アプリケーションの仮想ルート ディレクトリで匿名アクセスを無効にします。 Windows 統合認証を有効にします。 　 Web サーバー (ASP.NET) の構成 手順 詳細情報 ASP.NET Web アプリケーションを Windows 認証として構成します。 Web アプリケーションの仮想ディレクトリ ルートにある Web.config を開きます。 リモート リソースを呼び出す前に以下の外部関数を呼び出します。 COMSec.CoImpersonateClient(); COMSec.CoRevertToSelf(); 詳細については、「<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 属性を使用します。 [assembly: ApplicationActivation(ActivationOption.Server)] </td></tr> <tr> <td class="data" valign="top">Enterprise Services アプリケーションをパケット プライバシー認証として構成します (暗号化と共にセキュリティで保護された通信を提供するため)。</td> <td class="data" valign="top">サービス コンポーネント アセンブリに次の .NET 属性を追加します。 [assembly: ApplicationAccessControl( Authentication = AuthenticationOption.Privacy)] </td></tr> <tr> <td class="data" valign="top">Enterprise Services アプリケーションでコンポーネント レベルのロール ベース セキュリティを有効にします。</td> <td class="data" valign="top">プロセス レベルおよびコントロール レベル (インターフェイスとクラスを含む) でロール チェックを構成するには、次の属性を使用します。 [assembly: ApplicationAccessControl(AccessChecksLevel= AccessChecksLevelOption. ApplicationComponent)] クラスを以下の属性で修飾します。 [ComponentAccessControl(true)] インターフェイス レベルおよびメソッド レベルのロール チェックの構成については、「第 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 アプリケーション内で認定チェックを実行する必要がある場合は、次のコードを使用します。 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 を使用してアクセス チェックを実行します。 - SQL Server への接続に Windows 認証を使用すると、資格情報はアプリケーション サーバー上のファイルに保存されず、ネットワーク上で転送されることもありません。たとえば、次のように、接続文字列に Trusted\_Connection 属性を含めます。 ConStr="server=YourServer; database=yourdatabase; Trusted_Connection=Yes;" - 最初の呼び出し元のコンテキストはすべての層を経由してフローされるため、監査がきわめて容易になります。プラットフォーム レベルの監査を実行できます (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)