Share via

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

  • [アーティクル]

patterns and practices home

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

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

適用対象:
    Microsoft® ASP.NET

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

要約 : この章では、セキュリティ上の観点から捉えた .NET Web アプリケーションの一般的な特徴について説明し、.NET Web アプリケーションのセキュリティ モデルを紹介します。また、セキュリティで保護された .NET Web アプリケーションを作成するために使用する主要な実装テクノロジも紹介します。

目次

.NET Web アプリケーション
実装テクノロジ
セキュリティ アーキテクチャ
ID およびプリンシパル
まとめ

この章では、.NET Web アプリケーションのセキュリティを紹介します。一般的な .NET Web アプリケーションの各層に及ぶセキュリティ機能およびサービスの概要を説明します。

この章の目的は、以下のとおりです。

  • 一般的な .NET Web アプリケーションの基礎的な参考情報を提供します。
  • 認証、認定、およびセキュリティで保護された通信などのセキュリティ機能について理解します。これらの機能は、.NET Web アプリケーションの作成に使用するさまざまな実装テクノロジにより提供されます。
  • 信頼の境界を形成するためにアプリケーション内に設けるゲートキーパーおよびゲートについて理解します。

.NET Web アプリケーション

ここでは、.NET Web アプリケーションについて簡単に説明し、論理的観点と物理的観点の両方からその特徴を解説します。また、.NET Web アプリケーションの作成に使用するさまざまな実装テクノロジの概要についても説明します。

論理層

アプリケーション アーキテクチャを論理的な観点から見ると、すべてのシステムは、連携動作を行うサービスの集合体であると考えられます。それらのサービスは次の 3 つの層に分類することができます。

  • ユーザー サービス層
  • ビジネス サービス層
  • データ サービス層

論理的な観点からアーキテクチャを見ることにより、システムに不変的に存在するサービスの種類を認識することができ、正しい区分けと、各層間のインターフェイスの定義が可能になります。正しい区分けを行うことにより、各層の実装時において、より適切なアーキテクチャと設計を選択することが可能になり、保守の容易なアプリケーションを作成することができます。

各層の説明は以下のとおりです。

  • ユーザー サービス層は、クライアントとシステム間の対話を担当し、ビジネス サービス層内のコンポーネントによりカプセル化される主要なビジネス ロジックに対しての共通ブリッジを提供します。以前から、ユーザー サービス層は、対話ユーザーと結び付けられる傾向がありました。しかし、ユーザー サービス層には、他のシステムからのプログラム的な要求を最初に処理するという役割もあります。この場合、目に見える形のユーザー インターフェイスは存在しません。認証と認定は、クライアントの種類に応じてその本質が変化するため、通常はこのユーザー サービス層で処理されます。
  • ビジネス サービス層は、システムの主要な機能を提供し、ビジネス ロジックをカプセル化します。この層は、配信チャネル、バックエンド システム、データ ソースから独立して機能します。これにより、新しい別のチャネルやバックエンド システムに対応していくのに不可欠な、安定性と柔軟性がシステムに提供されます。通常、特定のビジネス要求が処理される場合は、ビジネス サービス層内で連携動作する複数のコンポーネントが使用されます。
  • データ サービス層は、システムの境界内に存在するデータへのアクセスと、汎用のインターフェイスを通じた他の (バックエンド) システムへのアクセスを担当します。これらのインターフェイスは、ビジネス サービス層内のコンポーネントから容易に使用できます。データ サービス層は、バックエンド システムおよびデータ ソースを抽象化し、特定のアクセス ルールとデータ形式をカプセル化します。

システム内のサービスの種類の論理的な区分けは、そのサービスを実装するコンポーネントの物理的な配置と相関関係を持つ場合もありますが、どちらかと言うと物理的な配置からは独立しています。

もう 1 つ重要なことは、論理層の特定には、対象物の規模は関係ないということです。つまり、論理層は、周囲の環境と外部連携を含めたシステム全体で、あるいはサブシステムの中で特定できるということです。たとえば、Web サービスをホストするリモート ノードそれぞれが、ユーザー サービス層 (受信した要求およびメッセージの処理)、ビジネス サービス層、およびデータ サービス層で構成されています。

物理的展開モデル

これまでに 3 つの論理的サービス層を説明しましたが、それは物理層の数を示すものではありません。3 つの論理的サービス層は、物理的に同じコンピュータ上に配置されることもあれば、複数のコンピュータ上に配置される可能性もあります。

アプリケーション サーバーとしての Web サーバー

.NET Web アプリケーションの一般的な展開パターンは、ビジネス コンポーネントとデータ アクセス コンポーネントを Web サーバー上に配置することです。これにより、ネットワーク ホップが少なくなり、パフォーマンスが向上します。図 2.1 に、このモデルを示します。

図 2.1 アプリケーション サーバーとしての Web サーバー

リモート アプリケーション層

リモート アプリケーション層の配置が一般的なパターンになるのは、境界ネットワーク (別名 DMZ、"非武装地帯" または "スクリーンド サブネット") 内に Web 層が独立して存在し、エンド ユーザーと、パケット フィルタリングを行うファイアウォールを持つリモート アプリケーション層と切り離されている場合です。図 2.2 に、リモート アプリケーション層を示します。

図 2.2 リモート アプリケーション層の概要

実装テクノロジ

.NET Web アプリケーションでは、一般的に以下のテクノロジを使用して 1 つ以上の論理サービスを実装します。

  • ASP.NET
  • Enterprise Services
  • Web サービス
  • .NET リモート処理
  • ADO.NET および Microsoft® SQL Server® 2000
  • インターネット プロトコル セキュリティ (IPSec)
  • SSL (Secure Sockets Layer)

ASP.NET

ASP.NET は、通常、ユーザー サービスを実装するために使用します。ASP.NET により、Web ページの作成時に利用できる、組み込み可能なアーキテクチャが提供されます。ASP.NET の詳細については、次の資料を参照してください。

Enterprise Services

Enterprise Services は、各アプリケーションにインフラストラクチャ レベルのサービスを提供するものです。これらのサービスには、分散トランザクションや、.NET コンポーネントでのオブジェクト プーリングなどのリソース管理サービスが含まれます。Enterprise Services の詳細については、次の資料を参照してください。

Web サービス

Web サービスにより、SOAP ベースのメッセージ交換を使用した、データ交換およびアプリケーション ロジックのリモート呼び出しが可能となり、ファイアウォールを介して、または異種システム間でデータを移動させることができます。Web サービスの詳細については、次の資料を参照してください。

.NET リモート処理

.NET リモート処理により、プロセスやマシンの境界を越えて分散オブジェクトにアクセスするためのフレームワークが提供されます。.NET リモート処理の詳細については、次の資料を参照してください。

ADO.NET および SQL Server 2000

ADO.NET により、データ アクセス サービスが実現します。ADO.NET は基本的に、分散 Web アプリケーションを意図した設計になっているため、Web アプリケーションに本来備わる、非接続型のシナリオに対してのサポートは万全です。ADO.NET の詳細については、次の資料を参照してください。

SQL Server により、オペレーティング システムの認証メカニズム (Kerberos または NTLM) を使用した統合セキュリティが実現します。認定は、ログオンおよび、個々のデータベース オブジェクトに適用できる細かいアクセス許可を利用して行われます。SQL Server 2000 の詳細については、次の資料を参照してください。

インターネット プロトコル セキュリティ (IPSec)

IPSec により、ポイント ツー ポイント型のトランスポート レベルの暗号化と、認証サービスが提供されます。IPSec の詳細については、次の資料を参照してください。

SSL (Secure Sockets Layer)

SSL により、セキュリティで保護されたポイント ツー ポイント型の通信チャネルが実現します。このチャネルで送信されるデータは暗号化されます。SSL の詳細については、次の資料を参照してください。

セキュリティ アーキテクチャ

図 2.3 は、リモート アプリケーション層モデルを、これまでに説明した各種テクノロジにより提供されるセキュリティ サービスと共に示したものです。認証と認定は、各層全体に広がる多くのポイントで行われます。これらのサービスは、主にインターネット インフォメーション サービス (IIS)、ASP.NET、Enterprise Services、および SQL Server により提供されます。また、セキュリティで保護された通信チャネルも各層全体に適用されており、クライアントのブラウザまたはデバイスからデータベースまで網羅しています。チャネルをセキュリティ保護するため、SSL (Secure Sockets Layer) と IPSec を組み合わせて使用しています。

図 2.3 セキュリティ アーキテクチャ

各層のセキュリティ

表 2.1 に、これまでに説明した技術で提供される認証、認定、およびセキュリティで保護された通信の各機能をまとめます。

表 2.1 セキュリティ機能

テクノロジ 認証 認定 セキュリティで保護された通信
IIS 匿名
基本
ダイジェスト
Windows 統合 (Kerberos/NTLM)
デジタル証明書		 IP/DNS アドレス制限
Web アクセス権
NTFS アクセス権、要求対象ファイルの Windows アクセス制御リスト (ACL)		 SSL
ASP.NET なし (カスタム)
Windows
フォーム
Passport		 ファイル認定
URL 認定
プリンシパル アクセス許可
.NET ロール
Web サービス Windows
なし (カスタム)
メッセージ レベル認証		 ファイル認定
URL 認定
プリンシパル アクセス許可
.NET ロール		 SSL およびメッセージ レベル暗号化
リモート処理 Windows ファイル認定
URL 認定
プリンシパル アクセス許可
.NET ロール		 SSL およびメッセージ レベル暗号化
Enterprise Services Windows Enterprise Services (COM+) ロール
NTFS アクセス権		 リモート プロシージャ コール (RPC) 暗号化
SQL Server 2000 Windows (Kerberos/NTLM)
SQL 認証		 サーバー ログイン
データベース ログイン
固定データベース ロール
ユーザー定義ロール
アプリケーション ロール
オブジェクト権限		 SSL
Windows 2000 Kerberos
NTLM		 Windows ACL IPSec

認証

Windows 2000 の .NET Framework では、次の認証オプションがあります。

  • ASP.NET 認証モード
  • Enterprise Services 認証
  • SQL Server 認証

ASP.NET 認証モード

ASP.NET 認証モードには、Windows 認証、フォーム認証、Passport 認証、および認証なしがあります。

  • Windows 認証 この認証モードの場合、ASP.NET は、IIS に依存する形でユーザー認証を行い、認証済みの ID を示す Windows アクセス トークンを作成します。IIS には、以下の認証メカニズムがあります。

    • 基本認証 基本認証では、ユーザーは、身元の証明のためユーザー名とパスワードで構成される資格情報が要求されます。これは、RFC 2617 (http://www.faqs.org/rfcs/rfc2617.html） に基づくインターネット標準案です。基本認証は、Netscape Navigator と Microsoft Internet Explorer の両方でサポートされています。ユーザーの資格情報は、暗号化されていない Base64 エンコード形式でブラウザから Web サーバーへと送信されます。Web サーバーでは、ユーザーの暗号化されていない資格情報が取得されるため、リモート コンピュータまたはリモート リソースにアクセスする場合などに、その資格情報を使用してリモート呼び出しを行います。

      メモ 基本認証は、SSL などを使用してセキュリティが確保されているチャネルでのみ使用するようにしてください。SSL を使用しない場合、ユーザー名とパスワードは、ネットワーク監視ソフトウェアによって簡単に盗聴されてしまいます。また、資格情報は後続の要求すべてに渡されるため、基本認証を使用する場合はログオン ページだけでなくすべてのページで SSL を使用してください。SSL と組み合わせた基本認証の詳細については、「第 8 章 ASP.NET セキュリティ」を参照してください。

    • ダイジェスト認証 IIS 5.0 で導入されたダイジェスト認証は、基本認証とほぼ同じですが、ブラウザから Web サーバーに暗号化されていないユーザーの資格情報が送信される代わりに、資格情報のハッシュが送信される点が異なります。この認証には、Internet Explorer 5.0 以降のクライアントと、特定のサーバー構成が必要ですが、結果としてセキュリティを強化することができます。

    • 統合 Windows 認証 統合Windows 認証 (クライアントとサーバーの構成に応じて Kerberos または NTLM) では、ユーザーの ID を確認するために、ユーザーの Web ブラウザである Internet Explorer との情報交換が暗号化されます。この認証は、Internet Explorer でのみサポートされ、Netscape Navigator ではサポートされないため、クライアント ソフトウェアの制御が可能なイントラネット環境で使用される傾向があります。この認証は、匿名アクセスが無効化されているか、Windows ファイル システム アクセス権を介した匿名アクセスが拒否されている場合に、Web サーバーでのみ使用できます。

    • デジタル証明書認証 デジタル証明書認証では、ユーザーを確実に識別するために、クライアント証明書が使用されます。クライアント証明書は、ユーザーのブラウザ (またはクライアント アプリケーション) から Web サーバーに渡されます。Web サービスの場合は、Web サービス クライアントから、HttpWebRequest オブジェクトの ClientCertificates プロパティを使用して証明書が渡されます。Web サーバーでは、証明書からユーザーの ID が抽出されます。この認証は、ユーザーのコンピュータにインストールされているクライアント証明書に依存するため、ユーザーの追加処理が明確であり、その操作の制御が可能なイントラネット環境またはエクストラネット環境で使用される傾向があります。クライアント証明書を受け取った IIS では、その証明書を Windows アカウントにマップすることができます。

    • 匿名認証 クライアントを認証する必要がないか、カスタムの認証スキームを実装する場合は、匿名認証を使用するように IIS を構成することができます。この場合、Web サーバーでは、すべての匿名ユーザーを同じ匿名 (またはゲスト) アカウントとして表す Windows アクセス トークンが作成されます。既定の匿名アカウントは、IUSR_MACHINENAME です。MACHINENAME は、インストール時に指定した、コンピュータの NetBIOS 名です。

Passport 認証 この認証モードの場合、ASP.NET は、Microsoft Passport の一元管理された認証サービスを使用します。ASP.NET には、Microsoft Passport ソフトウェア開発キット (SDK) により公開される機能に対する有用なラッパーが用意されています。この開発キットは、Web サーバーにインストールされている必要があります。

フォーム認証 この認証では、クライアント側のリダイレクトを使用して、特定の HTML フォームに認証されていないユーザーを転送し、資格情報 (通常、ユーザー名とパスワード) の入力を要求します。入力された資格情報は検証され、生成された認証チケットがクライアントに返されます。セッション中は、ユーザー ID と、オプションでユーザーの所属するロールのリストがこの認証チケットに保持されます。
また、フォーム認証は、Web サイトの個人化用に単独で使用されることがあります。この場合 ASP.NET で、大部分のプロセスを簡単な構成で自動処理できるため、カスタム コードを記述する必要はほとんどありません。個人化のシナリオでは、Cookie にはユーザー名だけが格納されます。

メモ フォーム認証では、ユーザー名とパスワードがプレーン テキスト形式で Web サーバーに送信されます。このため、フォーム認証は、SSL で保護されたチャネルと組み合わせて使用する必要があります。後続の要求時に送信される認証 Cookie を継続的に保護するためには、ログオン ページだけでなくアプリケーションのすべてのページで SSL の使用を検討してください。

なし ユーザー認証を行わない場合や、カスタムの認証プロトコルを使用する場合です。

詳細情報

ASP.NET 認証の詳細については、「第 8 章 ASP.NET セキュリティ」を参照してください。

Enterprise Services 認証

Enterprises services 認証は、基礎となるリモート プロシージャ コール (RPC) トランスポート インフラストラクチャを使用して行われます。このインフラストラクチャでは、オペレーティング システムの SSPI (Security Service Provider Interface) が使用されます。Enterprise Services アプリケーションのクライアントは、Kerberos または NTLM 認証を使用して認証されます。

サービス コンポーネントは、ライブラリ アプリケーションまたはサーバー アプリケーションでホストされます。ライブラリ アプリケーションは、クライアント プロセス内でホストされるため、クライアント ID の存在が前提とされます。サーバー アプリケーションは、独自の ID により個別のサーバー プロセスで実行されます。ID の詳細については、この章の「ID およびプリンシパル」を参照してください。

サービス コンポーネントに対する受信呼び出しは、以下の各レベルで認証されます。

  • 既定 セキュリティ パッケージの既定の認証レベルが使用されます。
  • なし 認証は行われません。
  • 接続 認証は、接続時にのみ行われます。
  • 呼び出し 認証は、各リモート プロシージャ コールの開始時に行われます。
  • パケット 呼び出しデータがすべて受信されたかどうかを認証および検証します。
  • パケット整合性 送信中にデータが変更されていないかどうかを認証および検証します。
  • パケット プライバシー データと、送信元の ID および署名を含むパケットが認証および暗号化されます。

詳細情報

Enterprise Services 認証の詳細については、「第 9 章 Enterprise Services セキュリティ」を参照してください。

SQL Server 認証

SQL Server では、Windows 認証 (NTLM または Kerberos) を使用したユーザー認証か、SQL 認証と呼ばれる独自の組み込みの認証スキームを使用できます。次の 2 つのオプションがあります。

  • SQL Server と Windows クライアントは、SQL Server 認証または Windows 認証を使用して、Microsoft SQL Server のインスタンスに接続できます。これは、混合モード認証と呼ばれることがあります。
  • Windows のみ ユーザーは、Windows 認証を使用して Microsoft SQL Server のインスタンスに接続する必要があります。

詳細情報

各アプローチの比較対照については、「第 12 章 データ アクセス セキュリティ」を参照してください。

認定

Windows 2000 の .NET Framework には、次の認定オプションがあります。

  • ASP.NET 認定オプション
  • Enterprise Services 認定
  • SQL Server 認定

ASP.NET 認定オプション

ASP.NET 認定オプションは、ASP.NET Web アプリケーション、Web サービス、およびリモート コンポーネントで使用できます。ASP.NET には、以下の認定オプションがあります。

  • URL 認定 これは、コンピュータとアプリケーション構成ファイル内の設定により構成される認定メカニズムです。URL 認定により、アプリケーションの URI (Uniform Resource Identifier) 名前空間内にある特定のファイルおよびフォルダへのアクセスを制限できます。たとえば、指定したユーザーに対し、URL で指定して特定のファイルまたはフォルダへのアクセスを個別に拒否または許可することができます。また、ユーザーのロール メンバシップや、要求の発行に使用される HTTP コマンド (GET、POST など) の種類に基づいてアクセスを制限することも可能です。
    URL 認定には、認証済みの ID が必要です。この ID は、Windows またはチケットベースの認証スキームを使用することで取得します。
  • ファイル認定 ファイル認定は、呼び出し元を認証するために IIS による Windows 認証メカニズムの 1 つを使用していると同時に、Windows 認証用に ASP.NET を構成している場合にのみ適用されます。
    この認定では、Web サーバー上の指定したファイルへのアクセスを制限することができます。アクセス許可は、ファイルに設定された Windows ACL により決定されます。
  • プリンシパル アクセス許可要求 プリンシパル アクセス許可要求は、細分化された追加のアクセス制御メカニズムとして、宣言的にまたはプログラム的に使用することができます。これにより、個々のユーザーの ID とグループ メンバシップに基づいて、クラス、メソッド、または個別のコード ブロックへのアクセスを制御できます。
  • .NET ロール .NET ロールは、アプリケーション内で同じアクセス許可を持つユーザーをグループ化する場合に使用します。このロールは、Windows グループや COM+ ロールなどの、以前のロールベースの実装と理論上ほぼ同じものです。ただし、.NET ロールは、認証済みの Windows ID を必要とせず、フォーム認証などのチケットベース認証スキームで使用できる点が以前のアプローチと異なります。
    .NET ロールは、リソースおよび操作へのアクセスを制御するために使用し、宣言的またはプログラム的に構成することが可能です。

詳細情報

ASP.NET 認定の詳細については、「第 8 章 ASP.NET セキュリティ」を参照してください。

Enterprise Services 認定

Enterprise Services 内のサービス コンポーネントに含まれる機能へのアクセスは、Enterprise Services ロール メンバシップにより制御されます。このロールは、.NET ロールとは異なり、Windows グループ アカウントまたはユーザー アカウントを含むことが可能です。ロール メンバシップは、COM+ カタログ内に定義されており、[コンポーネント サービス] ツールを使用して管理します。

詳細情報

Enterprise Services 認定の詳細については、「第 9 章 Enterprise Services セキュリティ」を参照してください。

SQL Server 認定

SQL Server では、個々のデータベース オブジェクトに適用可能な細分化されたアクセス許可を使用できます。アクセス許可を、ロール メンバシップ (SQL Server により提供される固定データベース ロール、ユーザー定義ロール、またはアプリケーション ロール) に基づいて決定したり、個々の Windows ユーザー アカウントまたはグループ アカウントに付与する形で決定することもできます。

詳細情報

SQL Server 認定の詳細については、「第 12 章 データ アクセス セキュリティ」を参照してください。

ゲートキーバーおよびゲート

これ以降、"ゲート" に関する処理を担当するテクノロジを示すために、"ゲートキーパー" という用語を使用します。ゲートとは、アプリケーション内の、リソースを保護するためのアクセス制御ポイントです。ここでのリソースとは、オブジェクトのメソッドで表される操作または、データベースやファイル システム のリソースなどを指します。

これまでに説明した主要なテクノロジのそれぞれが、アクセス認定のためのゲートキーパーとしての役割を果たします。リソースや操作にアクセスするための要求は、実際のアクセスの前に一連のゲートを通過する必要があります。要求が通過する必要のあるゲートは、以下のとおりです。

  • IIS には、ユーザーを認証するためのゲートがあります (つまり、匿名認証を無効化することができます)。IIS Web アクセス権は、Web ユーザーが特定のファイルおよびフォルダにアクセスする機能を制限するためのアクセス制御メカニズムとして使用できます。Web アクセス権は、NTFS ファイル アクセス権と異なり、個別のユーザーまたはグループではなくすべての Web ユーザーに適用されます。NTFS ファイル アクセス権は、Web ページ、イメージ ファイルなどの Web リソースに対して追加の制限を設ける場合に使用します。これらの制限は、個別のユーザーまたはグループに適用されます。
    IIS では、Web アクセス権の次に NTFS ファイル アクセス権がチェックされます。ユーザーがファイルまたはフォルダにアクセスするには、必ずこの両方のメカニズムによる認定が必要になります。Web アクセス権のチェックに失敗した場合、"HTTP 403 - アクセス禁止" の応答が返されるのに対し、NTFS アクセス権のチェックに失敗した場合、"HTTP 401 - アクセス拒否" が返されます。
  • ASP.NET には、構成可能なプログラムによる各種のゲートがあります。これには、URL 認定、ファイル認定、プリンシパル アクセス許可要求、および .NET ロールが含まれます。
  • Enterprise Services ゲートキーパーでは、ビジネス機能へのアクセスを認定するために、Enterprise Services ロールが使用されます。
  • SQL Server 2000 には、サーバー ログイン、データベース ログイン、およびデータベース オブジェクト権限などの一連のゲートがあります。
  • Windows 2000 には、セキュリティで保護されたリソースに設定された ACL を使用するゲートがあります。

つまり、ゲートへの呼び出しを行って特定のリソースにアクセスを試みるユーザーまたはサービスの ID を基準に認定を行うのが、ゲートキーパーということになります。複数のゲートを設けることで、複数の防御ラインを利用した重層的なセキュリティを実現できます。表 2.2 に、ゲートキーバーのセットと、各ゲートキーパーが対象とするゲートをまとめます。

表 2.2 ゲートキーパーおよび対象ゲート

ゲートキーパー ゲート
Windows オペレーティング システム ログオン権限 (許可および拒否、[ローカルでログオンを拒否する] など)。
その他の特権 ( [オペレーティング システムの一部として機能] など)。
レジストリおよびファイル システムなどのセキュリティで保護されたリソースに対するアクセス チェック。このアクセス チェックでは、セキュリティで保護されたリソースに設定された ACL が使用されます。ACL には、リソースへのアクセスを許可または拒否するユーザーと、許可する操作の種類が指定されます。
TCP/IP フィルタリング。
IP セキュリティ。
IIS 認証 (匿名、基本、ダイジェスト、統合、証明書)。
IP アドレス制限およびドメイン名制限。これは、追加のセキュリティ防御ラインとして使用できますが、IP アドレスのスプーフィングによる攻撃を比較的簡単に受けるため、必要以上に依存することは避けてください。
Web アクセス権。
NTFS アクセス権。
ASP.NET URL 認定。
ファイル認定。
プリンシパル アクセス許可要求。
.NET ロール。
Enterprise Services Windows (NTLM/Kerberos) 認証。
Enterprise Services (COM+) ロール。
偽装レベル。
Web サービス IIS および ASP.NET の機能によるゲートの使用。
リモート処理 ホストの機能によるゲートの使用。ASP.NET にホストされる場合、IIS および ASP.NET によるゲートが使用されます。Windows サービスにホストされる場合は、カスタム ソリューションの開発が必要です。
ADO.NET 接続文字列。明示的な資格情報か、Windows 認証が使用されます (たとえば、SQL Server に接続する場合)。
SQL Server サーバー ログイン。
データベース ログイン。
データベース オブジェクト権限。

アプリケーションの各層を通じてさまざまなゲートを用意することで、バックエンド リソースへのアクセスを許可するユーザーをフィルタすることができます。徐々に細分化されていく連続的なゲートによって、アクセス許可の範囲は、要求がアプリケーションを通過しバックエンド リソースに向かうにつれ狭くなります。

図 2.4 に、IIS を使用するインターネットベースのアプリケーションの例を示します。

図 2.4 ゲートキーパーによるユーザーのフィルタ

図 2.4 から、以下のことがわかります。

  • IIS では、匿名認証を無効化することができます。そのため、IIS により認証されるアカウントのみがアクセスを許可されます。これにより、潜在的なユーザー数は 10,000 に減少します。
  • 次に、ASP.NET の URL 認定により、ユーザーの数は 1,000 に減少します。
  • さらに、ファイル認定により 100 に絞り込まれます。
  • 最終的に、Web アプリケーションのコードにより、特定のロール メンバシップに基づいて、10 人のユーザーのみが制限されたリソースにアクセスすることを許可されます。

ID およびプリンシパル

.NET セキュリティの層は、Windows セキュリティの上部にあります。Windows セキュリティのユーザー中心型の概念は、ログオン セッションで提供されるセキュリティ コンテキストを基盤としていますが、.NET セキュリティでは、IPrincipal オブジェクトと IIdentity オブジェクトが基盤になります。

Windows プログラミングでは、実行しているコードのセキュリティ コンテキストを把握する場合、プロセス所有者または現在実行中のスレッドの ID を確認します。.NET プログラミングでは、現在のユーザーのセキュリティ コンテキストを把握する場合、Thread.CurrentPrincipal から現在の IPrincipal オブジェクトを取得します。

.NET Framework では、.NET コードの実行時のユーザーは、ID オブジェクトとプリンシパル オブジェクトで示され、それらが一緒になって、.NET のロールベース認定のバックボーンを提供します。

ID オブジェクトとプリンシパル オブジェクトは、それぞれ IIdentity インターフェイスと IPrincipal インターフェイスを実装する必要があります。これらのインターフェイスは、System.Security.Principal 名前空間内で定義されます。共通のインターフェイスを実装することで、基礎となる実装の詳細とは無関係に、多態な形態で ID オブジェクトとプリンシパル オブジェクトを処理することができます。

IPrincipal インターフェイスでは、IsInRole を通じてロール メンバシップ確認できるほか、関連付けされている IIdentity オブジェクトにアクセスできます。

public interface IPrincipal
{
  bool IsInRole( string role );
  IIdentity Identity {get;}
}

IIdentity インターフェイスでは、名前や認証の種類などの認証の詳細を取得できます。

public interface IIdentity
{
  string authenticationType {get;}
  bool IsAuthenticated {get;}
  string Name {get;}
}

.NET Framework には、図 2.5 に示すように IPrincipal と IIdentity を使用した具体的な実装がいくつか用意されています。これについて、以下の節で説明します。

図 2.5 IPrincipal および IIdentity 実装クラス

WindowsPrincipal および WindowsIdentity

Windows セキュリティ コンテキストは .NET では、以下の 2 つのクラスに分かれています。

  • WindowsPrincipal このクラスは、現在の Windows ユーザーに関連するロールを格納します。WindowsPrincipal の実装では、Windows グループがロールとして処理されます。IPrncipal.IsInRole メソッドは、ユーザーの Windows グループ メンバシップに応じて true または false を返します。

  • WindowsIdentity このクラスは、現在のユーザーのセキュリティ コンテキストにおける ID 部分を保持するもので、静的 WindowsIdentity.GetCurrent() メソッドにより取得できます。このメソッドは、Token プロパティを含む WindowsIdentity オブジェクトを返します。Token プロパティは、現在の実行スレッドに関連付けられたアクセス トークンの Windows ハンドルを示す IntPtr を返します。このトークンは、ネイティブの Win32® アプリケーション プログラミング インターフェイス (API) の GetTokenInformation、SetTokenInformation、CheckTokenMembership などの関数に渡されて、トークンに関するセキュリティ情報を取得するために使用されます。

    メモ 静的 WindowsIdentity.GetCurrent() メソッドは、偽装の有無にかかわらず現在の実行スレッドの ID を返します。この動作は、Win32 GetUserName API と同じものです。

GenericPrincipal および関連付けされる ID オブジェクト

これらのオブジェクトの実装は非常に単純であり、Windows 認証を使用しないアプリケーションによって、プリンシパルの複雑な表現を必要としない場合に使用されます。コード内で簡単に作成できるため、アプリケーションで GenericPrincipal を扱う際には、一定の信頼が存在している必要があります。

認定を確定するために GenericPrincipal の IsInRole メソッドを使用する場合は、GenericPrincipal の送信元のアプリケーションを信頼する必要があります。これに対し、WindowsPrincipal オブジェクトを使用する場合は、認証済みの ID と、有効なグループ名またはロール名を含む有効な WindowsPrincipal オブジェクトを取得するために、オペレーティング システムを信頼する必要があります。

GenericPrincipal クラスには、以下の種類の ID オブジェクトが関連付けられます。

  • FormsIdentity このクラスは、フォーム認証により認証された ID を示します。ユーザーの認証セッションについての情報を含む FormsAuthenticationTicket が含まれます。
  • PassportIdentity このクラスは、Passport 認証により認証された ID を示します。Passport プロファイル情報が含まれます。
  • GenericIdentity このクラスは、特定のオペレーティング システムに関連しない論理的なユーザーを示します。通常は、カスタムの認証および認定メカニズムに関連して使用されます。

ASP.NET と HttpContext.User

通常、Thread.CurrentPrincipal は、何らかの認定が行われる前に、.NET コードにチェックインされます。ただし、ASP.NET では、HttpContext.User プロパティを使用して認証済みのユーザーのセキュリティ コンテキストを取得することができます。

このプロパティは、IPrincipal インターフェイスを受け入れ、処理を返します。現在の要求における認証済みのユーザーが、このプロパティに含まれます。ASP.NET では、認定が行われる際に HttpContext.User が取得されます。

Windows 認証を使用する場合、Windows 認証モジュールでは、自動的に WindowsPrincipal オブジェクトが作成され、HttpContext.User に格納されます。フォームや Passport などの別の認証メカニズムを使用する場合は、GenericPrincipal オブジェクトを作成し、HttpContext.User に格納する必要があります。

ASP.NET ID

ASP.NET Web アプリケーションの実行時には、単一の要求中に複数の ID が存在する場合があります。これらの ID には以下のものが含まれます。

  • HttpContext.User は、現在の Web 要求のセキュリティ情報を含む IPrincipal オブジェクトを返します。これは、認証済みの Web クライアントです。
  • WindowsIdentity.GetCurrent() は、現在実行中の Win32 スレッドにおけるセキュリティ コンテキストの ID を返します。既定では、この ID は ASPNET です。これは、ASP.NET Web アプリケーションを実行するために使用される既定のアカウントです。ただし、Web アプリケーションが偽装用に構成されている場合、ID は認証済みのユーザー (IIS の匿名認証が有効化されている場合は、IUSR_MACHINE) を示します。
  • Thread.CurrentPrincipal は、Win32 スレッドの上部に位置する現在実行中の .NET スレッドのプリンシパルを返します。

詳細情報

  • Web アプリケーションの構成とASP.NET IDの組み合わせについて (偽装の有無別) の詳細な分析については、このガイドの「パート IV : 参照」の「.NET の ID マトリックス」を参照してください。
  • 独自の IPrincipal 実装を作成する場合の詳細については、「第 8 章 ASP.NET セキュリティ」および「パート IV : 参照」の「IPrincipal の実装方法」を参照してください。

リモート処理および Web サービス

現在のバージョンの .NET Framework では、リモート処理と Web サービスに独自のセキュリティ モデルはありません。どちらも IIS と ASP.NET のセキュリティ機能を継承しています。

リモート処理アーキテクチャに組み込まれたセキュリティはありませんが、セキュリティを考慮して設計されていることに変わりはありません。一定のレベルのセキュリティをリモート処理アプリケーションに組み込むことは、開発者または管理者、あるいはその両者に任されています。プリンシパル オブジェクトがリモート処理の境界を越えて渡されるかどうかは、以下のようにクライアントおよびリモート オブジェクトの場所を基準に決定されます。

  • 同一プロセス内でのリモート処理の場合 同じまたは別のアプリケーション ドメイン内のオブジェクト間でリモート処理が使用される場合、リモート処理インフラストラクチャにより、呼び出し元のコンテキストに関連付けられた IPrincipal オブジェクトへの参照が、受信先のコンテキストにコピーされます。
  • 複数のプロセス間でのリモート処理の場合 この場合、IPrincipal オブジェクトはプロセス間で送信されません。元の IPrincipal の作成に使用される資格情報は、場合により別のコンピュータ上に存在するリモート プロセスに送信される必要があります。この資格情報に基づいて、リモート コンピュータでは適切な IPrincipal オブジェクトが作成されます。

まとめ

この章では、さまざまな .NET 関連テクノロジにより導入される認証および認定の各オプションをすべて紹介しました。.NET Web アプリケーション全体に配置された複数のゲートキーパーを使用することで、重層的なセキュリティ戦略を実装できます。この章のまとめは以下のとおりです。

  • ASP.NET アプリケーションでは、Windows と IIS により提供される既存のセキュリティ機能を使用できます。
  • SSL と IPSec の組み合わせにより、ブラウザからデータベースに至る NET Web アプリケーションの各層を通じて、セキュリティで保護された通信を実現できます。
  • SSL を使用すると、基本認証またはフォーム認証を使用する際に、ネットワーク上で渡されるクリア テキストの資格情報を保護できます。
  • .NET では、WindowsPrincipal クラスと WindowsIdentity クラスの組み合わせを使用して、Windows 認証で識別されたユーザーを表します。
  • GenericPrincipal と、GenericIdentity または FormsIdentity の各クラスは、フォーム認証などの Windows 以外の認証で識別されたユーザーを表すために使用します。
  • IPrincipal と IIdentity を実装するクラスを作成することで、独自のプリンシパル実装および ID 実装を作成できます。
  • ASP.NET Web アプリケーション内において、認証済みのユーザーを示す IPrincipal オブジェクトは、HttpContext.User プロパティの使用により現在の HTTP Web 要求に関連付けられます。
  • ゲートは、認定済みのユーザーがリソースやサービスにアクセスする際に通過するアプリケーション内のアクセス制御ポイントです。ゲートキーパーは、ゲートへのアクセスを制御する役割を果たします。
  • 複数のゲートキーパーを使用することで、重層的なセキュリティ戦略を実現できます。

次の「第 3 章 認証と認定」では、特定のアプリケーション シナリオに最適な認証および認定の戦略を選択する際に役立つ追加情報を紹介します。