要約: この記事では、主に ASP.NET WEB アプリケーションのセキュリティ モデルの種類を紹介し、それぞれの長所と短所を比較し、選択メカニズムを提案します。
キーワード: セキュリティ モデル 信頼できるサブモデル シミュレーション/委任サブモデル ASP.NET WEB アプリケーション
1.はじめに
通常、ASP.NET WEB アプリケーションは多層アーキテクチャに属し、論理構造はプレゼンテーション層、ビジネス ロジック層、データ アクセス層に分割できます。アプリケーション リソースにアクセスするには、クライアントの ID 認証と承認が複数の層にまたがる必要があります。レベル。この記事では、主に SP.NET アプリケーションのリソース アクセス セキュリティ モデルについて説明します。
2. リソース アクセスの識別
WEB アプリケーションによって外部からクライアントに提供される一般的なリソースには
、Web ページ、Web サービス、静的リソース (HTML ページおよび画像) などの Web サーバー リソースが含まれます。
ユーザーごとのデータやアプリケーション レベルのデータなどのデータベース リソース。
リモート ファイル システム リソースなどのネットワーク リソース。
レジストリ、イベント ログ、構成ファイルなどのシステム リソース。
クライアントは、各層を流れる ID を使用して、アプリケーション層全体でこれらのリソースにアクセスします。リソース アクセスに使用されるこの ID は次のもので構成されます。
元の呼び出し元の ID 元の呼び出し元の ID が取得され、その後システムの各層を通過します。
プロセス ID ローカル リソースへのアクセスとダウンストリーム呼び出しは、現在のプロセス ID を使用して行われます。プロセス ID はターゲット システムによって認識される必要があるため、このアプローチの実現可能性は、越える境界に依存します。これは、次の 2 つの方法のいずれかで呼び出す必要があります。
同じ Windows セキュリティ ドメイン内の複数の Windows セキュリティ ドメイン - 信頼関係とドメイン アカウントを使用するか、信頼関係が存在しない場合は重複したユーザー名とパスワードを使用します。
サービス アカウント このアプローチでは、(固定) サービス アカウントを使用します。たとえば、データベース アクセスの場合、サービス アカウントは、データベースに接続されているコンポーネントによって固定の SQL ユーザー名とパスワードで表される場合があります。
固定の Windows ID が必要な場合は、Enterprise Services サーバー アプリケーションを使用する必要があります。
カスタム ID 使用可能な Windows アカウントがない場合は、Iprincipal と Iidentity を使用して独自の ID を構築できます。これには、セキュリティ コンテキストに関する詳細を含めることができます。
3. リソースアクセスモデル
3.1 信頼できるサブシステム モデル
図 1 に示すように、このモデルでは、元の呼び出し元のセキュリティ コンテキストはオペレーティング システム レベルでサービスを介して流れませんが、ダウンストリーム サービスとリソースにアクセスするために中間サービス層で固定 ID が使用されます。信頼されたサブシステム モデルの名前は、下流サービス (おそらくデータベース) が上流サービスを信頼して呼び出し元を承認するという事実に由来しています。図 1 の例では、データベースは中間層による呼び出し元の許可を信頼し、許可された呼び出し元のみが信頼された ID を使用してデータベースにアクセスすることを許可します。
3.1.1 リソースアクセスモード
信頼できるサブシステム モデルでは、リソース アクセス モデルは次のとおりです。
ユーザーを認証する ユーザーをロールにマップする ロール メンバーシップに基づいて承認する 固定の信頼できる ID を使用してダウンストリーム リソースにアクセスする
3.1.2 固定識別
ダウンストリーム システムおよびリソース マネージャーにアクセスするために使用される固定 ID。これは、プロセス ID または事前設定された Windows アカウント サービス アカウントを使用して提供できます。 SQL Server エクスプローラーの場合、これは SQL Server に対する Windows 認証を意味します。
プロセス ID を使用する場合、通常は ASP.NET プロセス ID (デフォルトは ASPNET アカウント) を使用します。実際のアプリケーションでは、多くの場合、ASPNET アカウントをより安全なパスワードに変更し、ASP.NET プロセス アカウントと一致する Windows アカウントを SQL Server コンピューター上に作成することが必要になります。具体的な方法は以下の通りです。
%windr%Microsoft.NETFrameworkv1.1.4322CONFIG ディレクトリにある Machine.config ファイルを編集し、<processModel> 要素のパスワード属性をデフォルト値 <!-UserName="machine" password = に再構成します。 "AutoGenerate" --><!-UserName="machine" password="NewPassword" --> に変更するか、ASPNET_setreg.exe ツールを使用してユーザー名とパスワードをレジストリに保存し、構成を次のように変更します。 !-enable="true" ユーザー名="レジストリ:HKLMSOFTWAREYourAPPprocesssModelASPNET_SETREG,userName" パスワード="レジストリ:HKLMSOFTWAREYourAPPprocesssModelASPNET_SETREG,password " -->
他のアプリケーションは、指定された SQL アカウント (接続文字列のユーザー名とパスワードで指定) を使用して SQL Server にアクセスします。この場合、データベースは SQL 認証用に構成されている必要があります。構成ファイルに保存された接続文字列は暗号化によって保護する必要があります。
3.2 シミュレーション/委任モデル
図 2 に示すように、偽装/削除モデルを使用する場合、サービスまたはコンポーネント (通常は論理ビジネス サービス層に位置します) は、オペレーティング システムの偽装機能を使用して、次のダウンストリーム サービスにアクセスする前にクライアント ID を偽装します。サービスが同じマシン上にある場合は、偽装を使用するだけで十分です。ダウンストリーム サービスがリモート マシン上にある場合は、委任も使用する必要があります。ダウンストリーム リソース アクセスのセキュリティ コンテキストはクライアントのコンテキストです。
3.3 リソースアクセスモデルの選択
2 つのリソース アクセス モデルの比較を表 1 に示します。
信頼されたサブシステム モデル シミュレーション/委任されたモデル監査機能のバックエンドは、上位層のサービスを信頼します。中間層が侵害された場合、バックエンド リソースは攻撃に対して脆弱になります。 バックエンド サービスは、優れたセキュリティで各呼び出し元を認証および認可できます。
スケーラビリティは接続プーリングをサポートしており、優れたスケーラビリティを備えています。 接続プーリングをサポートしていないため、スケーラビリティが不十分です。
バックエンド ACL 管理 ACL は単一のエンティティに対して構成されているため、必要な管理作業が少なくなります。 バックエンドリソースやユーザーの数が増えると、各ユーザーに対応するアクセスレベルを付与する必要があり、管理作業が煩雑になります。
技術的な問題を委任する必要はありません。 委任が必要です。ほとんどのセキュリティ サービス プロバイダーは委任をサポートしていません。
トラステッド サブシステム モデルは、大規模なイントラネット アプリケーションだけでなく、ほとんどのインターネット アプリケーションでも使用されます。これは主に、このモデルがスケーラビリティを適切にサポートできるためです。シミュレーション/デリゲート モデルは、小規模なシステムで使用される傾向があります。これらのアプリケーションでは、スケーラビリティは主な考慮事項ではなく、監査が主な考慮事項です。