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

[アーティクル]
03/31/2008

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

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

適用対象:
Microsoft® ASP.NET

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

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

インターネットアプリケーションでは、大量のユーザーを抱え、多くの利用方法が可能であることから、セキュリティに関してさまざまな要求が発生します。インターネットアプリケーションは、ユーザー認証を必要としないポータルアプリケーションから、登録ユーザー向けにコンテンツを提供する Web アプリケーションや、認証、認定、クレジットカードの審査、公開ネットワークおよび社内ネットワーク上での機密データの保護などのセキュリティ対策が必要となる大規模な電子商取引アプリケーションまで、多岐にわたります。

インターネットアプリケーションを開発するときには、適切な防御メカニズムを組み込み、スケーラビリティ、パフォーマンス、およびセキュリティ保護の各要件を満たすことが課題となります。主な課題を以下に示します。

適切なユーザー資格情報ストアを選択する (カスタムデータベース、Active Directory® ディレクトリサービスなど)。
アプリケーションをファイアウォール経由で稼働させる。
セキュリティ資格情報が複数のアプリケーション層を通過できるようにする。
認定を実行する。
パブリックネットワークおよび社内ネットワークをフローするデータの整合性とプライバシーを保証する。
アプリケーションのデータベースの状態をセキュリティで保護する。
アプリケーションデータの整合性を保証する。
ユーザー数の急増に対応できるスケーラビリティに優れたソリューションを構築する。

この章では、次に挙げる 2 つの一般的なインターネットアプリケーションシナリオを使用し、認証、認定、通信セキュリティの推奨テクニックについて説明します。

ASP.NET - SQL Server
ASP.NET - リモート Enterprise Services - SQL Server

ASP.NET - SQL Server

このシナリオには 2 つの物理層があり、登録ユーザーは Web ブラウザを使用して、セキュリティで保護されたプロセスによって Web ベースのアプリケーションにログインします。ASP.NET ベースの Web アプリケーションが Microsoft® SQL Server® データベースとの間でセキュリティで保護された接続を確立し、主としてデータ取得タスクを管理します。このようなアプリケーションの例として、登録購読者にニュースコンテンツを配信するポータルアプリケーションがあります。このシナリオを図 7.1 に示します。

図 7.1 ASP.NET Web アプリケーション - SQL Server インターネットシナリオ

特徴

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

ユーザーはさまざまな種類の Web ブラウザを使用します。
匿名ユーザーがアプリケーションの制限されていないページにアクセスできます。
ユーザーが制限されたページを表示するためには、ユーザー登録またはログオン (HTML フォームを使用) が必要です。
ユーザーの資格情報は SQL Server データベースとの照合によって検証します。
データベースクエリで使用するユーザー入力 (資格情報など) を検証することによって、SQL コード注入攻撃の脅威を緩和します。
境界ネットワーク (別名 DMZ、"非武装地帯"、または "スクリーンドサブネット") 内にフロントエンド Web アプリケーションを配置し、ファイアウォールによってインターネットと社内ネットワークおよび SQL Server データベースから切り離します。
アプリケーションには、強力なセキュリティ、高度のスケーラビリティ、および詳細な監査が必要です。
データベースは、ユーザーを適切に認証することについてアプリケーションを信頼しています (つまり、アプリケーションがユーザーに代わってデータベースの呼び出しを実行します)。
Web アプリケーションは ASP.NET プロセスアカウントを使用してデータベースに接続します。
SQL Server の内部では、データベース認定に単一のユーザー定義データベースロールを使用します。

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

このシナリオでは、Web アプリケーションがログオンページを表示し、資格情報を受け取ります。認証されたユーザーは先へ進むことができますが、認証に失敗したユーザーはアクセスを拒否されます。データベースは、最低限の特権を持つアカウントである既定の ASP.NET プロセス ID を認証します (つまり、データベースは ASP.NET アプリケーションを信頼しています)。

表 7.1 セキュリティ対策

分類	詳細
認証	IIS を匿名アクセスが有効になるように構成します。ASP.NET Web アプリケーションは、フォーム認証によってユーザーを認証し、資格情報を取得します。検証は SQL Server データベースとの照合によって行います。ユーザーのパスワードはデータベースには格納されません。パスワードではなく salt 値を適用したパスワードハッシュが格納されます。salt 値を加えることによって、ディクショナリ攻撃の脅威が軽減します。 ASP.NET Web アプリケーションを実行するための最低限の特権を持つ Windows アカウントを使用して、Windows® 認証によってデータベースに接続します。
認定	ASP.NET プロセスアカウントを認定し、Web サーバー上のシステムリソースへのアクセスを許可します。リソースは Windows ACL によって保護します。データベースアクセスの認定には、ASP.NET アプリケーション ID を使用します。
セキュリティで保護された通信	SSL を使用して、ユーザーと Web アプリケーションの間で送信される機密データをセキュリティで保護します。 IPSec を使用して、Web サーバーとデータベースサーバーの間で送信される機密データをセキュリティで保護します。

結果

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

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

セキュリティ構成の設定

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

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

Web サーバーの構成

IIS の構成
手順	詳細情報
Web アプリケーションの仮想ルートディレクトリで匿名アクセスを有効にします。	IIS 認証を使用するには、IIS MMC スナップインを使用します。アプリケーションの仮想ディレクトリを右クリックして [プロパティ] を選択します。 [ディレクトリセキュリティ] タブをクリックし、[匿名アクセスおよび認証コントロール] の [編集] をクリックします。
ASP.NET の構成
手順	詳細情報
ASPNET アカウント (ASP.NET を実行するために使用するアカウント) のパスワードを既知の方法による強力なパスワードに変更します。	これにより、同じユーザー名とパスワードを持つ複製されたローカルアカウントをデータベースサーバーに作成できます。この作業が必要なのは、ASPNET アカウントが Windows 認証を使用して接続するときに、データベースサーバーからのネットワーク認証チャレンジに応答できるようにするためです。もう 1 つの方法として、最低限の特権を持つドメインアカウントを使用することもできます (ファイアウォールを通過する Windows 認証が可能な場合)。詳細については、「第 8 章 ASP.NET セキュリティ」の「ASP.NET のプロセス ID」を参照してください。 %windir%\Microsoft.NET\Framework\v1.0.3705\CONFIG にある Machine.config を開きます。 `<!-- userName="machine" password="AutoGenerate" -->` 変更後 `<!-- userName="machine" password="YourStrongPassword" -->`
ASP.NET Web アプリケーションをフォーム認証として構成します (SSL を使用)。	アプリケーションの仮想ディレクトリルートにある Web.config を開きます。 `<authentication mode="Forms" > <forms name="MyAppFormsAuth" loginUrl="login.aspx" protection="All" timeout="20" path="/" > </forms> </authentication>` SQL Server に対するフォーム認証の詳細については、このガイドの「パート IV : 参照」の「SQL Server 2000 でフォーム認証を使用する方法」を参照してください。

SQL Server の構成

手順	詳細情報
SQL Server コンピュータ上に、ASP.NET プロセスアカウントと一致する Windows アカウントを作成します。	ユーザー名とパスワードは、カスタム ASP.NET アプリケーションアカウントと一致しているか、規定のアカウントを使用する場合は ASPNET であることが必要です。
SQL Server を Windows 認証として構成します。
カスタム ASP.NET アプリケーションアカウントの SQL Server ログインを作成します。	これにより、SQL Server へのアクセス権を付与します。
新しいデータベースユーザーを作成し、そのユーザーにログイン名をマップします。	これにより、指定したデータベースへのアクセス権を付与します。
データベース内に新しいユーザー定義のデータベースロールを作成し、そのロールにデータベースユーザーを割り当てます。
このデータベースロールのデータベースアクセス許可を設定します。	最低限のアクセス許可を割り当てます。詳細については、「第 12 章データアクセスセキュリティ」を参照してください。

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

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

分析

このシナリオでは、ユーザーが Windows アカウントを持っていないため、フォーム認証が最適です。ユーザーの資格情報はフォームログインページで取得します。アプリケーションコードで資格情報の検証を実行する必要があります。データストアは、どのような種類のものでも使用できます。最も一般的なソリューションでは SQL Server データベースを使用しますが、Active Directory を資格情報ストアとして使用することも可能です。
フォーム認証では、最初のログオンで入力される資格情報を SSL で保護する必要があります。フォーム認証チケットも保護する必要があります。このチケットは最初のログオン以降に認証済みクライアントが発行する Web 要求で Cookie として渡されます。フォーム認証チケットを保護するには、すべてのページで SSL を使用する方法があります。また、<forms> 要素の protection 属性を All または Encrypt に設定し、FormsAuthentication クラスの Encrypt メソッドを使用して、フォーム認証チケットを暗号化することもできます。

protection 属性を "All" に設定すると、アプリケーションが FormsAuthentication.Encrypt を呼び出したときに、チケットが整合性チェックを受け、暗号化されます。このメソッドは、認証チケットを作成するときに呼び出します。一般には、このメソッドをアプリケーションのログインボタンイベントハンドラに挿入します。
```
string encryptedTicket = FormsAuthentication.Encrypt(authTicket);
```
フォーム認証とチケットの暗号化の詳細については、「第 8 章 ASP.NET セキュリティ」を参照してください。
ASP.NET は最低限の特権を持つローカル ASPNET アカウントとして稼働するため、不正アクセスによる潜在的な損害は緩和されます。
Web サーバーで URL 認定を使用した場合、認証されていないユーザーは、制限のない Web ページは表示できますが、制限されたページを表示しようとすると、認証を要求されます。
偽装が有効になっていないので、Web ベースのアプリケーションが実行するローカルまたはリモートのリソースアクセスでは、ASPNET アカウントセキュリティコンテキストが使用されます。これに合わせてセキュリティで保護されたリソースの Windows ACL を設定する必要があります。
ユーザーの資格情報はカスタム SQL Server データベースとの照合によって検証されます。データベースには salt 値を適用したパスワードハッシュが保存されます。詳細については、「第 12 章データアクセスセキュリティ」の「データベースとの照合によるユーザー認証」を参照してください。
SQL Server への接続に Windows 認証を使用することによって、資格情報は Web サーバー上のファイルに保存されず、ネットワーク上で転送されることもありません。
現在、アプリケーションで SQL 認証を使用している場合には、接続文字列にユーザー名とパスワードが含まれているため、データベース接続文字列を保存するときにセキュリティで保護する必要があります。DPAPI の使用を検討してください。詳細については、「第 12 章データアクセスセキュリティ」の「データベース接続文字列をセキュリティで保護して保存する」を参照してください。
データベースサーバー上の複製された Windows アカウント (ASPNET プロセスアカウントと一致するアカウント) を使用すると、管理の負担が増加します。1 つのコンピュータでパスワードが変更されると、すべてのコンピュータでアカウントの同期と更新を行う必要があります。シナリオによっては、最低限の特権を持つドメインアカウントを使用して管理を容易にすることができます。
Web サーバーとデータベースサーバーの間に IPSec を使用すると、データベースとの間で転送されるデータのプライバシーが保証されます。
ブラウザと Web サーバーの間に SSL を使用すると、資格情報に加え、クレジットカード番号などの機密データも保護されます。
Web ファームを使用する場合は、フォーム認証チケットの暗号化などで使用する暗号化キー (Machine.config の <machineKey> 要素で指定) がファーム内のすべてのサーバーにおいて一貫性が保たれるようにする必要があります。Web ファームで ASP.NET を使用する方法の詳細については、「第 8 章 ASP.NET セキュリティ」を参照してください。

注意点

このシナリオのアプリケーションでは、監査上の必要から、最初の呼び出し元の ID をデータベースまでフローする必要があります。呼び出し元の ID は、ストアドプロシージャのパラメータを使用して渡すことができます。

ASP.NET - リモート Enterprise Services - SQL Server

このシナリオでは、ASP.NET ページを実行する Web サーバーが、リモートアプリケーションサーバーで稼働するサービスコンポーネントとの間にセキュリティで保護された接続を確立し、またリモートアプリケーションサーバーは SQL Server データベースに接続します。多くのインターネットアプリケーションインフラストラクチャがそうであるように、このシナリオの Web サーバー (境界ネットワーク内に配置) とアプリケーションサーバーもファイアウォールで分離されています。サービスコンポーネントは、SQL Server との間にセキュリティで保護された接続を確立します。

例として、ユーザーに機密データ (個人の会計明細など) を提供するインターネットバンキングアプリケーションについて考えてみます。顧客からデータベースに送信される取引データをセキュリティで保護する必要があり、データの整合性を維持することが非常に重要となります。ユーザーとの間で発生するトラフィックだけでなく、データベースにアクセスするトラフィックも、セキュリティで保護する必要があります。このシナリオを図 7.3 に示します。

図 7.3 ASP.NET - リモート Enterprise Services - SQL Server インターネットシナリオ

特徴

ユーザーはさまざまな種類の Web ブラウザを使用します。
匿名ユーザーがアプリケーションの制限されていないページにアクセスできます。
ユーザーが制限されたページを表示するためには、ユーザー登録またはログオン (HTML フォームを使用) が必要です。
Web ベースのフロントエンドアプリケーションは境界ネットワーク内に配置され、ファイアウォールによってインターネットと社内ネットワーク (およびアプリケーションサーバー) と分離されます。
アプリケーションには、強力なセキュリティ、高度のスケーラビリティ、および詳細な監査が必要です。
Web ベースのアプリケーションは、SOAP を使用して Web サービス層に接続します。この層は、アプリケーションサーバーの Enterprise Services アプリケーション内で動作するサービスコンポーネントとのインターフェイスとして機能します。DCOM より SOAP の方が望ましいのは、ファイアウォールの制限があるためです。
SQL Server は、認定プロセスで単一のユーザー定義データベースロールを使用します。
データは機密性が高く、ネットワーク上および永続的なデータストア内では、データの整合性とプライバシーをセキュリティで保護する必要があります。
Enterprise Services (COM+) トランザクションを使用して、データの整合性を確保します。

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

このシナリオでは、Web サービスがフォームログインページから資格情報を受け取り、SQL Server データベースとの照合によって呼び出し元を認証します。ログインページでは、SSL を使用して、インターネット上で送信されるユーザーの資格情報を保護します。

Web ベースのアプリケーションは、サービスコンポーネントに実装されたビジネスサービスとのインターフェイスとなる Web サービスに接続します。Web サービスは、境界ネットワーク内に配置される Web ベースのアプリケーションを信頼し、ASP.NET プロセス ID を認証します。ユーザーの ID は、メソッドとストアドプロシージャのパラメータを使用して、すべての層を経由してアプリケーションレベルで転送します。この情報は、層を越えて実行されるユーザーの操作を監査するために使用します。

表 7.2 セキュリティ対策

分類	詳細
認証	Web サーバーで強力な認証を実行します。 Enterprise Services アプリケーション ID はデータベース側で認証します。 IIS で匿名アクセスが有効になるように構成し、Web ベースのアプリケーションでは (SQL Server データベースとの照合により) フォーム認証によってユーザーを認証します。 Web サービスの仮想ディレクトリでは、統合 Windows 認証として構成します。Web サービスは Web ベースのアプリケーションのプロセス ID を認証します。データベースへの接続には Windows 認証を使用します。データベースは、Enterprise Services アプリケーションの実行に使用される、最低限の特権を持つアカウントを認証します。
認定	信頼されたサブシステムモデルを使用し、ユーザー単位の認証は Web アプリケーション内でのみ実行します。 Web サーバー上のページへのユーザーアクセスは、URL 認証によって制御します。 ASP.NET プロセスアカウントを認定し、Web サーバー上のシステムリソースへのアクセスを許可します。リソースは ACL によって保護します。データベース内のアクセス許可は、ユーザー定義のロールによって制御します。Enterprise Services アプリケーション ID は、このロールのメンバです。 Enterprise Services プロセスアカウントを認定し、アプリケーションサーバー上のシステムリソースへのアクセスを許可します。リソースは ACL によって保護します。
セキュリティで保護された通信	ユーザーと Web ベースのアプリケーションとの間で送信される機密データは、SSL によって保護します。 Web サーバーと Web サービスとの間で送信される機密データは、SSL によって保護します。サービスコンポーネントとデータベースとの間で送信される機密データは、IPSec によって保護します。

結果

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

図 7.4 ASP.NET - リモート Enterprise Services - SQL Server インターネットシナリオの推奨セキュリティ構成

セキュリティ構成の設定

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

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

Web サーバーの構成

IIS の構成
手順	詳細情報
Web ベースのアプリケーションの仮想ルートディレクトリで匿名アクセスを有効にします。
ASP.NET の構成
手順	詳細情報
ASPNET アカウント (ASP.NET を実行するために使用するアカウント) のパスワードを既知の方法による強力なパスワードに変更します。	これにより、同じユーザー名とパスワードを持つ複製されたローカルアカウントをアプリケーションサーバーに作成できます。この作業が必要なのは、ASPNET アカウントがアプリケーションサーバーからのネットワーク認証チャレンジに応答できるようにするためです。もう 1 つの方法として、最低限の特権を持つドメインアカウントを使用することもできます (ファイアウォールを通過する Windows 認証が可能な場合)。詳細については、「第 8 章 ASP.NET セキュリティ」の「ASP.NET のプロセス ID」を参照してください。 %windir%\Microsoft.NET\Framework\v1.0.3705\CONFIG にある Machine.config を開きます。 `<!-- userName="machine" password="AutoGenerate" -->` 変更後 ``` ```
Web ベースのアプリケーションをフォーム認証として構成します (SSL を使用)。	アプリケーションの仮想ディレクトリルートにある Web.config を開きます。 `<authentication mode="Forms" > <forms name="MyAppFormsAuth" loginUrl="login.aspx" protection="All" timeout="20" path="/" > </forms> </authentication>` SQL Server に対するフォーム認証の詳細については、このガイドの「パート IV : 参照」の「SQL Server 2000 でフォーム認証を使用する方法」を参照してください。

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

IIS の構成
手順	詳細情報
匿名アクセスを無効にします。
Windows 統合認証を有効にします。	Web サーバーに配置された Web ベースのアプリケーションから渡された ASP.NET プロセス ID を IIS で認証します。
ASP.NET の構成
手順	詳細情報
Windows 認証を使用します。	Web サービスの仮想ディレクトリルートにある Web.config を開きます。 `<authentication mode="Windows" />`
Enterprise Services の構成
手順	詳細情報
Enterprise Services サーバーアプリケーションを実行するためのアカウントとして、最低限の特権を持つカスタムアカウントを作成します。	メモローカルアカウントを使用する場合は、データベースサーバーコンピュータに複製アカウントも作成する必要があります。
このカスタムアカウントを使用するように Enterprise Services アプリケーションを構成します。	「第 9 章 Enterprise Services セキュリティ」の「セキュリティの構成」を参照してください。
ロールベースのアクセスチェックを有効にします。	「第 9 章 Enterprise Services セキュリティ」の「セキュリティの構成」を参照してください。
アプリケーションに 1 つの Enterprise Services (COM+) ロール (Trusted Web Service など) を追加します。	Web ベースのアプリケーションで完全なエンドユーザー認証を実行します。Web サービス (およびサービスコンポーネント) だけが Trusted Web Service ロールのメンバへのアクセスを許可されます。
Trusted Web Service ロールにローカル ASPNET アカウントを追加します。	「第 9 章 Enterprise Services セキュリティ」の「セキュリティの構成」を参照してください。

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 サーバーとアプリケーションサーバーの間に SSL を構成します。	このガイドの「パート IV : 参照」の「SSL を使用して Web サービスを呼び出す方法」を参照してください。
アプリケーションサーバーとデータベースサーバーの間に IPSec を構成します。	このガイドの「パート IV : 参照」の「2 つのサーバー間の通信を IPSec で保護する方法」を参照してください。

分析

このシナリオでは、ユーザーが Windows アカウントを持っていないため、フォーム認証が最適です。ユーザーの資格情報はフォームログインページで取得します。アプリケーションコードで資格情報の検証を実行する必要があります。データストアは、どのような種類のものでも使用できます。最も一般的なソリューションでは SQL Server データベースを使用しますが、Active Directory を資格情報ストアとして使用することも可能です。
Web ベースのアプリケーションは最低限の特権を持つローカル ASPNET アカウントとして稼働するので、不正アクセスによる潜在的な損害は緩和されます。
Web サーバーで URL 認定を使用した場合、認証されていないユーザーは、制限のない Web ページは表示できますが、制限されたページを表示しようとすると、認証を要求されます。
偽装が有効になっていないので、Web ベースのアプリケーションが実行するローカルまたはリモートのリソースアクセスでは、ASPNET アカウントセキュリティコンテキストが使用されます。それに応じて ACL を構成する必要があります。
ユーザーの資格情報はカスタム SQL Server データベースとの照合によって検証されます。データベースには salt 値を適用したパスワードハッシュが保存されます。詳細については、「第 12 章データアクセスセキュリティ」の「データベースとの照合によるユーザー認証」を参照してください。
SQL Server への接続に Windows 認証を使用すると、資格情報はアプリケーションサーバー上のファイルに保存されず、ネットワーク上で転送されることもありません。
データベースサーバー上の複製された Windows アカウント (Enterprise Services プロセスアカウントと一致するアカウント) を使用すると、管理の負担が増加します。1 つのコンピュータでパスワードが変更されると、すべてのコンピュータでアカウントの同期と更新を行う必要があります。シナリオによっては、最低限の特権を持つドメインアカウントを使用して管理を容易にすることができます。
Web アプリケーションは Web サービスを呼び出すときに、DefaultCredentials (つまり、ASP.NET プロセスアカウントである ASPNET) を使用して Web サービスプロキシを構成する必要があります。
```
proxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
```
詳細については、「第 10 章 Web サービスセキュリティ」の「認証用の資格情報を Web サービスに渡す」を参照してください。
Web サーバーとアプリケーションサーバーに配置されたサービスコンポーネントの前に位置する Web サービス層の間に構成された SSL は、2 つのサーバー間で送信されるデータのプライバシーを保証します。
Enterprise Services アプリケーションは、アプリケーションレベルのロールベースセキュリティとして構成されます。この構成によって、Web サービスを実行するために使用されるローカル ASPNET アカウントだけがサービスコンポーネントにアクセスできます。
アプリケーションサーバーとデータベースサーバーの間に構成した IPSec は、データベースとの間で送信されるデータのプライバシーを保証します。
ブラウザと Web サーバーの間に構成した SSL は、資格情報と銀行口座の明細を保護します。

注意点

まとめ

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

イントラネットアプリケーションおよびエクストラネットアプリケーションのシナリオについては、「第 5 章イントラネットセキュリティ」と「第 6 章エクストラネットセキュリティ」を参照してください。

次の方法で共有

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

目次

ASP.NET - SQL Server

特徴

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

結果

セキュリティ構成の設定

Web サーバーの構成

SQL Server の構成

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

分析

注意点

関連シナリオ

Active Directory との照合によるフォーム認証

詳細情報

.NET ロールによる認定

詳細情報

Web サーバーでドメイン匿名アカウントを使用する

詳細情報

ASP.NET - リモート Enterprise Services - SQL Server

特徴

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

結果

セキュリティ構成の設定

Web サーバーの構成

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

SQL Server の構成

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

分析

注意点

関連シナリオ

Active Directory との照合によるフォーム認証

詳細情報

DCOM の使用

詳細情報

詳細情報

まとめ

その他のリソース

次の方法で共有

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

目次

ASP.NET - SQL Server

特徴

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

結果

セキュリティ構成の設定

Web サーバーの構成

SQL Server の構成

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

分析

注意点

関連シナリオ

Active Directory との照合によるフォーム認証

詳細情報

.NET ロールによる認定

詳細情報

Web サーバーでドメイン匿名アカウントを使用する

詳細情報

ASP.NET - リモート Enterprise Services - SQL Server

特徴

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

結果

セキュリティ構成の設定

Web サーバーの構成

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

SQL Server の構成

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

分析

注意点

関連シナリオ

Active Directory との照合によるフォーム認証

詳細情報

DCOM の使用

詳細情報

詳細情報

まとめ

その他のリソース

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

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