次の方法で共有

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

  • [アーティクル]

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 アプリケーションの構築」の開始ページを参照してください。

要約 : この章では、特定のアプリケーション シナリオに対し適切な認定戦略を決定するのに役立つ情報を記述します。これらは、最適な認証および認定の技術を選択し、それらをアプリケーション内の適切な場所に適用するのに有益な情報です。

目次

認証および認定戦略の設計
認定アプローチ
ID のフロー
ロール ベース認定
認証メカニズムの選択
まとめ

分散 Web アプリケーションにおいて、認証および認定戦略を設計することは、困難な作業です。ただし、アプリケーション開発の初期の段階で認証および認定の設計を適切に行うことで、セキュリティ上の重大なリスクの多くを回避することができます。

この章の内容は、アプリケーションの認定戦略を適切に設計する際に役立ちます。また、以下の主要な質問に対する回答も得ることができます。

  • 認定はどこで行えばよいか。また、どのような認定メカニズムを使用すればよいか。
  • どのような認証メカニズムを使用すればよいか。
  • 認証に Active Directory® のディレクトリ サービスを使用する必要があるか。または、カスタム データ ストアに対して資格情報の検証を行う必要があるか。
  • 異種および同種プラットフォームにおいて、予測される事態と設計上の考慮事項は何か。
  • Microsoft® Windows® オペレーティング システムを使用しないユーザーをアプリケーション内で表現するにはどうすればよいか。
  • アプリケーションの各層全体を通じてユーザー ID をフローさせるにはどうすればよいか。また、オペレーティング システム レベルの偽装および委任は、いつ行えばよいか。

認定を検討する場合は、認証も同時に検討する必要があります。この 2 つの処理は、以下の 2 つの理由から相互に深く関連しています。

  • 第 1 に、なんらかの主要な認定ポリシーでは、認証済みのユーザーの存在が前提とされます。
  • 第 2 に、ユーザーを認証する方法、特に、認証済みのユーザー ID をアプリケーション内で表現する方法に基づいて、使用可能となるゲートキーパーが決定されます。 ASP.NET ファイル認定、Enterprise Services (COM+) ロール、および Windows ACL などの一部のゲートキーパーでは、認証済みの Windows ID が必要です。この ID は、WindowsIdentity オブジェクトの形式で、呼び出し元のセキュリティ コンテキストを定義する Windows アクセス トークンをカプセル化しています。ASP.NET URL 認定や .NET ロールなどのゲートキーバーでは、認証済みの Windows ID は必要ありません。認証済みの ID は必要ですが、それは必ずしも Windows アクセス トークンで表現されている必要はありません。

認証および認定戦略の設計

アプリケーションの認証および認定戦略を決定する際に役立つ手順を以下に示します。

  1. リソースを識別します。
  2. 認定戦略を選択します。
  3. リソース アクセスに使用する ID を選択します。
  4. ID のフローを検討します。
  5. 認証方法を選択します。
  6. ID をフローさせる方法を決定します。

リソースの識別

アプリケーションでクライアントに公開する必要のあるリソースを識別します。通常、以下のようなリソースがあります。

  • Web サーバー リソース たとえば、Web ページ、Web サービス、静的リソース (HTML ページおよびイメージ) などです。
  • データベース リソース たとえば、ユーザーごとのデータまたはアプリケーション全体で使用するデータなどです。
  • ネットワーク リソース リモート ファイル システムのリソースや、ディレクトリ ストア (Active Directory など) からのデータです。

アプリケーションによりアクセスされるシステム リソースを識別する必要もあります。これは、クライアントに公開するリソースとは対照的なリソースになります。システム リソースには、レジストリ、イベント ログ、構成ファイルなどが含まれます。

認定戦略の選択

基本的な認定戦略には、以下の 2 つがあります。

  • ロール ベース 呼び出し元のロール メンバシップに基づいて、操作 (通常はメソッド) へのアクセスがセキュリティで保護されます。ロールを使用すると、アプリケーションのユーザー ベースを、アプリケーション内で同じセキュリティ特権を共有するユーザーのセット (上級管理者、管理者、従業員など) に区分することができます。ユーザーはロールにマップされ、ユーザーの要求する操作の実行が認定されると、アプリケーションは固定 ID を使用してリソースにアクセスします。これらの ID は、各リソース マネージャ (データベース、ファイル システムなど) により信頼されます。
  • リソース ベース Windows ACL に基づいて、個々のリソースがセキュリティで保護されます。リソースへのアクセス前にアプリケーションが呼び出し元を偽装するため、オペレーティング システムでは標準のアクセス チェックを実行できます。リソース アクセスは、すべて最初の呼び出し元のセキュリティ コンテキストを使用して行われます。この偽装によるアプローチを採用すると、アプリケーションの中間層内で接続プーリングを効果的に使用できないため、アプリケーションのスケーラビリティに深刻な影響を与えます。

スケーラビリティが重要視される .NET Web アプリケーションの大部分においては、ロール ベースの認定アプローチが最適です。比較的小規模な一部のイントラネット アプリケーションでは、個々のユーザーを対象とする Windows ACL のリソース (ファイルなど) 保護機能を利用することで、ユーザーごとのコンテンツ提供が可能なため、リソース ベースのアプローチが適切である場合があります。ロール ベース認定で推奨される一般的なパターンは以下のとおりです。

  • フロントエンド Web アプリケーション内でユーザーを認証します。
  • ユーザーをロールにマップします。
  • ロール メンバシップに基づいて、(リソースへの直接的なアクセスではなく) 操作へのアクセスを認定します。
  • 固定サービス ID を使用して、要求された認定済みの操作をサポートするために必要なバックエンド リソースにアクセスします。バックエンド リソース マネージャ (データベースなど) は、アプリケーションによる呼び出し元の認定を信頼し、信頼された 1 つ以上のサービス ID に対してアクセス許可を付与します。
    たとえば、データベース管理者は、個別のユーザーに対してではなく、特定の人事管理 (HR) アプリケーションにのみアクセス許可を付与することができます。

詳細情報

  • 2 種類の認定アプローチの比較対照については、後の「認定アプローチ」を参照してください。
  • ロール ベース認定と使用できるロールの種類の詳細については、後の「ロール ベース認定」を参照してください。

リソース アクセスに使用する ID の選択

まず、リソースにアクセスするのはだれであるかということを特定します。

アプリケーションの各層を通じてリソースにアクセスする際に必要な 1 つ以上の ID を選択します。このリソースには、Web ベースのアプリケーションからアクセスされるリソースのほか、場合によっては Web サービス、Enterprise Services、および .NET リモート処理コンポーネントからアクセスされるリソースも含まれます。どの場合においても、リソース アクセスには以下のような ID が使用されます。

  • 最初の呼び出し元の ID この場合、取得された最初の呼び出し元の ID がシステムの各層を通じてフローするという、偽装および委任モデルが前提となります。委任は、認証メカニズムの決定の際の主要な規準の 1 つとなる要素です。

  • プロセス ID 既定では、この ID が使用されます (特定の偽装がない場合)。ローカル リソース アクセスや下位呼び出しの際には、現在のプロセス ID が使用されます。プロセス ID はターゲット システムによって認識される必要があるため、このアプローチを使用できるかどうかは、境界の交差状況により決定されます。

    呼び出しの方法は次のいずれかになります。

    • 同一の Windows セキュリティ ドメイン内
    • 複数の Windows セキュリティ ドメイン間 (信頼とドメイン アカウントを使用、または信頼関係が存在しない場合、複製されたユーザー名およびパスワードを使用)

サービス アカウント このアプローチでは、(固定) サービス アカウントが使用されます。以下に例を示します。

  • データベース アクセスの場合、データベースに接続するコンポーネントによって提示される固定 SQL ユーザー名およびパスワードがこのアカウントになります。
  • 固定 Windows ID が必要とされる場合は、Enterprise Services サーバー アプリケーションを使用します。

カスタム ID Windows アカウントを利用しないときは、IPrincipal および IIdentity 実装を使用して、特定のセキュリティ コンテキストに関連する詳細情報を含む独自の ID を作成することができます。たとえば、ロールの一覧、一意の識別子、またはその他のカスタム情報を ID に含めることができます。
IPrincipal と IIdentity を使用してカスタム ID を実装し、HttpContext.User を使用して現在の Web コンテキストに配置すれば、.NET ロールや PrincipalPermission 要求などの組み込みのゲートキーパーが即座に利用可能になります。

ID フローの検討

ユーザー単位の認定、監査、およびユーザー単位のデータ取得をサポートするには、状況によりさまざまなアプリケーション層と複数のコンピュータ境界を通じて最初の呼び出し元の ID をフローさせる必要があります。たとえば、バックエンド リソース マネージャで呼び出し元ごとに認定を行う場合、呼び出し元の ID は、そのリソース マネージャまで渡される必要があります。

リソース マネージャの認定要件とシステムの監査要件に基づいて、アプリケーションを通じて渡す必要のある ID を識別してください。

認証アプローチの選択

認証アプローチの選択に影響を与える主な要素は 2 つあり、最も重要な第 1 の要素は、アプリケーションのユーザー ベースの性質です (使用しているブラウザの種類や、Windows アカウントの有無など)。第 2 の要素は、アプリケーションの偽装および委任と監査要件です。

詳細情報

アプリケーションの認証メカニズムを選択する際に役立つ検討事項については、後の「認証メカニズムの選択」を参照してください。

ID をフローさせる方法の決定

セキュリティ コンテキストを提供する ID をアプリケーション レベルでフローさせるか、ID とセキュリティ コンテキストをオペレーティング システム レベルでフローさせるかを選択します。

アプリケーション レベルで ID をフローさせる場合は、メソッドとストアド プロシージャのパラメータを使用します。アプリケーション ID フローでは、次の処理がサポートされます。

  • 信頼されたクエリ パラメータを使用したユーザー単位のデータ取得
    SELECT x,y FROM SomeTable WHERE username="bob"
  • 任意のアプリケーション層内でのカスタム監査

オペレーティング システム ID フローでは、次の処理がサポートされます。

  • プラットフォーム レベルの監査 (たとえば、Windows 監査や SQL Server 監査)
  • Windows ID に基づくユーザー単位の認定

オペレーティング システム レベルで ID をフローさせる場合は、偽装および委任モデルを使用します。Kerberos 委任を使用する場合と、Kerberos がサポートされない環境などでは、基本認証などの別のアプローチを使用する場合があります。基本認証では、サーバー アプリケーションにより利用されるユーザーの資格情報が、下位のネットワーク リソースへのアクセスに使用されます。

詳細情報

ID のフローと、ネットワーク資格情報を含む偽装トークンの取得方法 (委任のサポート) の詳細については、後の「ID のフロー」を参照してください。

認定アプローチ

認定には、以下の 2 つの基本的アプローチがあります。

  • ロール ベース ユーザーは、アプリケーション定義による、論理的なロールに分類されます。特定のロールに所属するユーザーは、アプリケーション内で同じ特権を共有します。呼び出し元のロール メンバシップに基づいて、操作 (通常はメソッド呼び出し) へのアクセスが認定されます。リソースへのアクセスには、固定 ID (Web アプリケーションまたは Web サービスのプロセス ID) が使用されます。リソース マネージャは、アプリケーションによるユーザーの認定を信頼し、信頼された ID を認定します。
  • リソース ベース Windows ACL に基づいて、個々のリソースがセキュリティで保護されます。ACL に基づいて、リソースへのアクセスを許可するユーザーと、各ユーザーによる実行を許可する操作の種類 (読み取り、書き込み、削除など) が決定されます。
    リソースへのアクセスには、偽装による最初の呼び出し元の ID が使用されます。

ロール ベース

ロール (または操作) ベースのセキュリティ アプローチでは、(バックエンド リソースへのアクセスではなく) 操作へのアクセスは、呼び出し元のロール メンバシップに基づいて認定されます。ロールは、アプリケーションの設計時に分析および定義されるもので、アプリケーション内で同じセキュリティ特権 (または機能) を共有するユーザーをグループ化するための論理的コンテナとして使用されます。各ユーザーはアプリケーション内のロールにマップされ、アプリケーションにより公開される特定の操作 (メソッド) へのアクセス制御には、ロール メンバシップが使用されます。

アプリケーション内でロールのマップが行われる場所は、設計上の主要な基準点になります。以下に例を示します。

  • 極端な例としては、データベースなどのバックエンド リソース マネージャ内でロールがマップされる場合があります。この場合、最初の呼び出し元のセキュリティ コンテキストが、アプリケーションの各層を通じてバックエンド データベースまでフローする必要があります。
  • 次に極端な例としては、フロントエンド Web アプリケーション内でロールがマップされる場合があります。このアプローチの場合、各リソース マネージャが認定し、信頼することになる固定 ID を使用して、下位のリソース マネージャへのアクセスが行われます。
  • 第 3 の例としては、中間層の Enterprise Services アプリケーション内など、フロントエンド層とバックエンド層の間にある任意の場所でロールがマップされる場合があります。

複数層に分かれた Web アプリケーションでは、信頼された ID をバックエンド リソース マネージャへのアクセスに使用することにより、接続プーリングの機能を活用できるため、アプリケーションのスケーラビリティにおける選択の幅が広がります。また、信頼された ID を使用することで、最初の呼び出し元のセキュリティ コンテキストをオペレーティング システム レベルでフローさせる必要性を軽減することができます。オペレーティング システム レベルでのフローは、特定の環境では不可能ではありませんが、実現には困難が伴う場合があります。

リソース ベース

リソース ベースの認定アプローチは、Windows ACL と、オペレーティング システムの基本的なアクセス制御メカニズムに依存します。アプリケーションは、呼び出し元を偽装し、アクセス チェックの実行をオペレーティング システムと特定のリソース マネージャ (ファイル システム、データベースなど) に任せます。

このアプローチは、Windows ACL により個別に保護することが可能なリソース (ファイルなど) へのアクセスを提供するアプリケーションに最適です。これらのアプリケーションの例としては、FTP アプリケーションや単純なデータ駆動型の Web アプリケーションが挙げられます。このアプローチを実現するには、複数の異なるソースから取得および集約されるデータにより構成される要求対象のリソースがどこにあるのかを分析することから開始します。これらのソースには、複数のデータベース、データベース テーブル、外部アプリケーション、Web サービスなどがあります。

また、リソース ベースのアプローチは、アプリケーションを通じてバックエンド リソース マネージャまでフローする最初の呼び出し元のセキュリティ コンテキストに依存します。このため、複雑な構成が必要となるほか、複数層に分かれたアプリケーションによる大規模ユーザーへの対応能力も大幅に制限される場合があります。アプリケーションの中間層内でのプーリング (データベース接続プーリングなど) を効果的に使用できないのがその理由です。

リソース アクセス モデル

.NET Web アプリケーション (および一般的な複数層の分散アプリケーション) で一般的に使用されるリソース アクセス用の 2 つのセキュリティ モデルでは、次の 2 つの対照的な認定アプローチが使用されます。

  • 信頼されたサブシステム モデル
  • 偽装および委任モデル

セキュリティとスケーラビリティの両方の観点から捉えた場合、どちらのモデルにもそれぞれ利点と欠点があります。次からの節では、これらのモデルについて説明します。

信頼されたサブシステム モデル

このモデルでは、下位のサービスおよびリソースにアクセスする際に、中間層のサービスで固定 ID が使用されます。オペレーティング システム レベルでは、最初の呼び出し元のセキュリティ コンテキストはサービスを通じてフローされませんが、アプリケーションにより、アプリケーション レベルで最初の呼び出し元の ID をフローさせることが決定される場合があります。この必要があるのは、バックエンドの監査要件をサポートする場合や、ユーザー単位でのデータ アクセスおよび認定をサポートする場合です。

呼び出し元を認定するために、下位サービス (データベースなど) が上位サービスを信頼するため、このようなモデル名で呼ばれます。図 3.1 に、このモデルを示します。信頼の境界に特に注目してください。この例では、中間層による呼び出し元の認定をデータベースが信頼することで、認定された呼び出し元のみが信頼された ID を使用してデータベースにアクセスできます。

図 3.1 信頼されたサブシステム モデル

信頼されたサブシステム モデルにおけるリソース アクセスのパターンは、以下のとおりです。

  • ユーザーを認証します。
  • ユーザーをロールにマップします。
  • ロール メンバシップに基づいて認定を行います。
  • 信頼された固定 ID を使用して、下位のリソース マネージャにアクセスします。

固定 ID

下位のシステムやリソース マネージャにアクセスする際に使用される固定 ID は、通常、サービス アカウントと呼ばれる事前構成済みの Windows アカウントにより提供されます。Microsoft SQL Server® リソース マネージャでは、これは SQL Server に対する Windows 認証を意味します。

または、一部のアプリケーションでは、接続文字列のユーザー名とパスワードにより指定される SQL アカウントが、SQL Server へのアクセスに使用されます。この場合、データベースが SQL 認証用に構成されている必要があります。

SQL Server との通信における Windows 認証と SQL 認証の比較対照については、「第 12 章 データ アクセス セキュリティ」を参照してください。

信頼された複数の ID の使用

一部のリソース マネージャでは、呼び出し元のロール メンバシップに基づいてやや細分化された認定が必要な場合があります。たとえば、ユーザーが、読み取り/書き込み操作の実行を認定するグループと、読み取り専用操作の実行を認定するグループに分かれている場合があります。

SQL Server の場合、以下のアプローチを検討します。

  • 読み取り専用操作用と、読み取り/書き込み操作用の 2 つの Windows アカウントを作成します。より一般的には、アプリケーション固有のロールを反映する個別のアカウントを用意します。たとえば、アカウントの 1 つはインターネット ユーザー用とし、もう 1 つは内部オペレータまたは管理者、あるいはその両者用とします。
  • 各アカウントを SQL Server ユーザー定義データベース ロールにマップし、各ロールに対して必要なデータベース アクセス権限を確立します。
  • ユーザーをアプリケーション内のロールにマップし、ロール メンバシップを使用して、データベースに接続する前に偽装するアカウントを決定します。

図 3.2 に、このアプローチを示します。

図 3.2 データベースへのアクセスにおいて、より細分化された認定をサポートするために複数の ID を使用する場合のモデル

偽装および委任モデル

このモデルでは、一般に論理ビジネス サービス層のどこかに位置するサービスまたはコンポーネントが、オペレーティング システム レベルの偽装を使用してクライアントの ID を偽装し、次の下位サービスにアクセスします。次のサービスが同じコンピュータ上にある場合は、偽装のみで十分です。下位サービスがリモート コンピュータ上に位置する場合は、委任が必要になります。

委任の結果、下位のリソース アクセスに使用されるセキュリティ コンテキストは、クライアントのセキュリティ コンテキストと同じものになります。通常、このモデルは次の 2 つの理由により使用されます。

  • このモデルの使用により、下位サービスは、最初の呼び出し元の ID を使用して呼び出し元ごとに認定を行うことができます。
  • このモデルの使用により、下位サービスは、オペレーティング システム レベルの監査機能を使用することができます。

この技術の具体的な例としては、中間層の Enterprise Services コンポーネントが、データベースへのアクセス前に呼び出し元を偽装する場合が挙げられます。データベースへのアクセスには、最初の呼び出し元のセキュリティ コンテキストに基づくデータベース接続が使用されます。このモデルの場合、データベースは、すべての呼び出し元を 1 つずつ認証し、個々の呼び出し元の ID (または呼び出し元の Windows グループ メンバシップ) に割り当てられたアクセス許可に基づいて認定の決定を行います。図 3.3 に、偽装および委任モデルを示します。

図 3.3 偽装および委任モデル

リソース アクセス モデルの選択

信頼されたサブシステム モデルは、主にスケーラビリティへの対応上の理由から、インターネット アプリケーションの大部分と、大規模なイントラネット アプリケーションで使用されます。偽装モデルは、スケーラビリティが主要な問題とならない小規模なアプリケーションや、否認防止の理由から監査が重要な検討事項となるアプリケーションで使用される傾向にあります。

偽装および委任モデルの利点

偽装および委任モデルの主な利点は、データ中心の監査機能を使用できることです。監査により、管理者は、特定のリソースへのアクセスを試みたユーザーを追跡することができます。一般的に監査の信頼性が最も高くなるのは、リソース アクセスが発生した時点に、リソース アクセスの同一ルーチンを基準に監査が生成される場合と考えられます。

偽装および委任モデルでは、下位のリソース アクセスのためにユーザーのセキュリティ コンテキストが保持されるため、この要件がサポートされます。これにより、バックエンド システムでは、ユーザーと要求されたアクセスを信頼性の高い状態で記録することができます。

偽装および委任モデルの欠点

偽装および委任モデルには、以下の欠点があります。

  • 技術的な困難 ほとんどのセキュリティ サービスでは、委任がサポートされません。Kerberos はその中でも目立った例外と言えます。
    偽装を行うプロセスには、特に [オペレーティング システムの一部として機能] 特権などの高い特権が必要です (この制限は、Windows 2000 にのみ適用されるもので、Windows Server 2003 には適用されません)。
  • スケーラビリティ 偽装および委任モデルでは、データベース接続プーリングの機能を有効に利用することができません。データベース アクセスには、最初の呼び出し元の個別のセキュリティ コンテキストに基づいた接続が使用されるためです。これにより、アプリケーションによる大規模ユーザーへの対応能力が大幅に制限されます。
  • 管理作業の増大 バックエンド リソースの ACL は、各ユーザーに適切なレベルのアクセス許可を付与するように保守する必要があります。バックエンド リソースの数が増加し、ユーザーの数も増大すると、ACL の管理作業にかなりの時間を取られることになります。

信頼されたサブシステム モデルの利点

信頼されたサブシステム モデルには、以下の利点があります。

  • スケーラビリティ 信頼されたサブシステム モデルでは、アプリケーションのスケーラビリティにおける主要な要件である接続プーリング機能がサポートされます。接続プーリングを使用すると、プールされた使用可能な接続を複数のクライアントで再利用できます。このモデルでは、すべてのバックエンド リソース アクセスに、呼び出し元の ID とは無関係なサービス アカウントのセキュリティ コンテキストが使用されるため、接続プーリングを使用することが可能になります。
  • バックエンドの ACL 管理作業の最小化 データベースなどのバックエンド リソースにアクセスするのは、サービス アカウントのみです。したがって、ACL は、この 1 つの ID に対してのみ構成すればよいことになります。
  • ユーザーによるデータへの直接アクセスの禁止 信頼されたサブシステム モデルでは、中間層のサービス アカウントのみがバックエンド リソースへのアクセスを許可されます。そのため、ユーザーは、アプリケーションの認定を受けることなくアプリケーションを通過し、バックエンドのデータに直接アクセスすることはできません。

信頼されたサブシステム モデルの欠点

信頼されたサブシステム モデルには、以下の 2 つの欠点があります。

  • 監査 バックエンドで監査を行うには、アプリケーション レベルで明示的に最初の呼び出し元の ID をバックエンドに渡し、そこで監査の処理を行います。このとき、中間層を信頼しなければならず、潜在的な否認のリスクが発生します。別の方法としては、中間層で監査証跡を生成し、それをバックエンドの監査証跡に関連付けます (この場合、サーバー同士の時刻を同期しておく必要があります)。
  • サーバーの不正利用リスクの増大 信頼されたサブシステム モデルでは、中間層のサービスにバックエンド リソースへの幅広いアクセスが許可されます。そのため、中間層のサービスが不正に利用されると、攻撃者によるバックエンド リソースへの幅広いアクセスを容易に認めてしまう可能性があります。

ID のフロー

分散アプリケーションは、セキュリティで保護された複数のサブシステムに分割されます。たとえば、フロントエンド Web アプリケーション、中間層 Web サービス、リモート コンポーネント、およびデータベースは、4 つの異なるセキュリティ サブシステムです。それぞれのサブシステムで、認証と認定が行われます。

最初の呼び出し元に対する認定をサポートするためには、次の下位サブシステムに対して呼び出し元の ID (および関連するセキュリティ コンテキスト) をフローさせるべきサブシステムを識別する必要があります。

アプリケーション ID フローとオペレーティング システム ID フローの比較

ID をフローさせる戦略には、オペレーティング システムの委任機能を使用する方法と、アプリケーション レベルでチケットまたは資格情報、あるいはその両方を渡す方法があります。以下に例を示します。

  • アプリケーション レベルで ID をフローさせるには、一般的にメソッドの引数またはストアド プロシージャのパラメータを使用して、資格情報 (またはチケット) を渡します。

    メモ 認証済みの呼び出し元の ID を渡す GenericPrincipal オブジェクトは、プロセス間を自動的にフローしません。フローさせるにはカスタム コードが必要です。

    ユーザー固有のデータを取得および処理するためのストアド プロシージャに、次のようにしてパラメータを渡すことが可能です。

SELECT CreditLimit From Table Where UserName="Bob"

このアプローチは、"信頼されたクエリ パラメータ" アプローチと呼ばれることがあります。

  • オペレーティング システム レベルでの ID フローには、偽装の拡張形式である委任が必要になります。

偽装および委任

一般的な環境の場合、サーバー アプリケーション内のスレッドは、サーバー プロセスのセキュリティ コンテキストを使用して実行されます。プロセスのセキュリティ コンテキストを構成する属性は、プロセスのログオン セッションによって保持されており、プロセス レベルの Windows アクセス トークンにより公開されます。すべてのローカルおよびリモートのリソース アクセスは、プロセス レベルのセキュリティ コンテキストを使用して実行されます。このセキュリティ コンテキストは、サーバー プロセスの実行に使用される Windows アカウントにより決定されます。

偽装

サーバー アプリケーションを偽装用に構成すると、要求の処理に使用されるスレッドに偽装トークンが関連付けられます。偽装トークンは、認証済みの呼び出し元 (または匿名ユーザー) のセキュリティ コンテキストを示します。すべてのローカル リソース アクセスは、呼び出し元のセキュリティ コンテキストを提示するスレッド偽装トークンを使用して行われます。

委任

サーバー アプリケーション スレッドがリモート リソースへのアクセスを試みる場合、委任が必要です。特に、偽装された呼び出し元のトークンには、ネットワーク資格情報が含まれている必要があります。含まれていない場合、すべてのリモート リソース アクセスは、匿名ユーザー (AUTHORITY\ANONYMOUS LOGON) として行われます。

セキュリティ コンテキストを委任できるかどうかは、複数の要因により決定されます。表 3.1 に、IIS のさまざまな認証の種類と、その種類ごとに認証済みの呼び出し元のセキュリティ コンテキストを委任できるかどうかを示します。

表 3.1 IIS 認証の種類

認証の種類 委任できるか メモ
匿名 状況による。 IIS で匿名アカウント (既定では IUSR_MACHINE) がローカル アカウントとして構成されている場合、ローカル (Web サーバー) およびリモートのコンピュータに、同じユーザー名とパスワードを持つ同一のローカル アカウントがなければ委任できません。
匿名アカウントがドメイン アカウントの場合は委任可能です。
基本 できる。 基本認証がローカル アカウントで使用される場合、ローカルおよびリモートのコンピュータに同一のローカル アカウントがあれば委任できます。ドメイン アカウントの場合も委任可能です。
ダイジェスト できない。 　
統合 Windows 状況による。 統合 Windows 認証は、クライアントおよびサーバー コンピュータのオペレーティング システムのバージョンに応じて、NTLM または Kerberos のいずれかです。
NTLM の場合、委任はサポートされません。
Kerberos の場合、適切に構成された環境においてサポートされます。
詳細については、このガイドの「パート IV : 参照」の「Windows 2000 での Kerberos 委任の構成方法」を参照してください。
クライアント証明書 状況による。 IIS 証明書のマップを使用している場合、委任可能です。このとき証明書は、リモート コンピュータ上で複製されるローカル アカウントにマップされるか、ドメイン アカウントにマップされている必要があります。
マップされたアカウントの資格情報が、ローカル サーバーに格納され、ネットワーク資格情報を含む対話型のログオン セッションの作成に使用されるため、委任が有効になります。
Active Directory 証明書のマップでは、委任はサポートされません。

重要 Windows 2000 での Kerberos 委任には制限がありません。つまり、複数のリモート コンピュータを対象に複数のネットワーク ホップを作成することができます。この潜在的なセキュリティ リスクを回避するには、ドメイン アカウントによる到達範囲を制限するために Domain Users グループからアカウントを削除し、特定のコンピュータにログオンする場合にのみそのアカウントが使用されるように設定してください。

ロール ベース認定

.NET Web アプリケーションの大部分では、ロール ベースの認定アプローチが使用されます。この場合、さまざまなロールの種類を検討し、アプリケーション シナリオに最適なロールを選択する必要があります。ロールの種類は次のとおりです。

  • .NET ロール
  • Enterprise Services (COM+) ロール
  • SQL Server ユーザー定義データベース ロール
  • SQL Server アプリケーション ロール

.NET ロール

.NET ロールは、柔軟性の高いロールであり、認証済みの ID が所属するロールの一覧を含む IPrincipal オブジェクトを中心に構成されています。.NET ロールは、Web アプリケーション、Web サービス、または ASP.NET 内でホストされ、HttpChannel を使用してアクセスできるリモート コンポーネント内で使用することができます。

.NET ロールを使用する認定は、宣言的な PrincipalPermission 要求で実行するか、強制的な PrincipalPermission 要求または、IPrincipal.IsInRole メソッドをコード内で使用して、プログラム的に実行します。

Windows 認証での .NET ロール

アプリケーションで Windows 認証を使用する場合、ASP.NET では、HttpContext.User により現在の Web 要求のコンテキストに関連付けられた WindowsPrincipal が自動的に作成されます。認証プロセスが完了した後、現在の要求に関連付けられたオブジェクトは、後続のすべての .NET ロール ベース認定に使用されます。

認証済みの呼び出し元の Windows グループ メンバシップは、ロール セットの決定に使用されます。Windows 認証の場合、.NET ロールは Windows グループと同じものになります。

Windows 以外の認証での .NET ロール

アプリケーションで、フォーム認証や Passport 認証などの Windows 以外の認証メカニズムを使用する場合、GenericPrincipal オブジェクト (またはカスタムの IPrincipal オブジェクト) を作成するコードを記述し、SQL Server データベースなどのカスタムの認証データ ストアから取得したロール セットをそのオブジェクトに追加する必要があります。

カスタムの IPrincipal オブジェクト

.NET ロール ベースのセキュリティ メカニズムは、拡張可能です。IPrincipal および IIdentity を実装する独自のクラスを開発することで、拡張された独自のロール ベース認定機能を実現できます。

カスタム データ ストアから取得されるロールを含んだカスタムの IPrincipal オブジェクトを、HttpContext.User を使用して現在の要求コンテキストに関連付けていれば、基本的なロール チェック機能は確保されます。

IPrincipal インターフェイスを実装することで、宣言的および強制的の両形式の PrincipalPermission 要求をカスタム ID と連動させることができます。また、拡張されたロール セマンティクスを実装することも可能です。たとえば、"IsInMultipleRoles( string [] roles )" などの追加のメソッドを使用して、複数ロールのメンバシップに対するテストとアサーションが可能です。

詳細情報

Enterprise Services (COM+) ロール

Enterprise Services (COM+) ロールを使用すると、アクセス チェックが中間層に移行するため、バックエンド データベースに接続するときにデータベース接続プーリングを使用することができます。ただし、Enterprise Services (COM+) のロール ベース認定が機能するには、Windows アクセス トークンの使用によりフロントエンド Web アプリケーションが最初の呼び出し元の ID を偽装し、ID が Enterprise Services アプリケーションにフローする必要があります。この場合、Web アプリケーションの Web.config ファイルに次のエントリを記述します。

<authentication mode="Windows" />
<identity impersonate="true" />

ユーザーの呼び出し可能なメソッドの種類を決定するような、メソッド レベルでの宣言的なチェックで十分な場合は、アプリケーションの導入後に [コンポーネント サービス] 管理ツールを使用して、ロール メンバシップを更新することができます。

メソッド コードでのプログラムによるチェックが必要な場合は、ロールのロジックがハードコーディングされるため、Enterprise Services (COM+) ロールの管理上および展開上の利点の一部が失われます。

SQL Server ユーザー定義データベース ロール

このアプローチでは、データベースにロールを作成し、ロールに応じてアクセス許可を割り当てた後で、Windows のグループ アカウントおよびユーザー アカウントをロールにマップします。このアプローチでは、SQL Server 認証より Windows 認証を優先的に使用している場合、呼び出し元の ID をバックエンドにフローさせる必要があります。

SQL Server アプリケーション ロール

このアプローチでは、データベース内のロールにアクセス許可が付与されますが、SQL Server アプリケーション ロールには、ユーザーまたはグループのアカウントが含まれません。そのため、最初の呼び出し元の細分化の性質は失われます。

アプリケーション ロールでは、ユーザーのセットではなく特定のアプリケーションに対してアクセスを認定します。アプリケーションでは、ロール名とパスワードを受け入れる組み込みのストアド プロシージャの使用により、ロールがアクティブ化されます。このアプローチの主な欠点の 1 つは、アプリケーション側でセキュリティ上安全に資格情報 (ロール名および関連付けされたパスワード) を管理する必要があることです。

詳細情報

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

.NET ロールと Enterprise Services (COM+) ロールの比較

以下の表に、.NET ロールと Enterprise Services (COM+) ロールの各機能の比較を示します。

表 3.2 Enterprise Services ロールと .NET ロールの比較

機能 Enterprise Services ロール .NET ロール
管理 [コンポーネント サービス] 管理ツール カスタム
データ ストア COM+ カタログ カスタム データ ストア (SQL Server、Active Directory など)
宣言的 可能
[SecurityRole("Manager")]		 可能
[PrincipalPermission(SecurityAction.Demand, Role="Manager")]
強制的 可能
ContextUtil.IsCallerInRole()		 可能
IPrincipal.IsInRole
クラス、インターフェイス、およびメソッド レベルの細分化 可能 可能
拡張性 なし あり
(カスタムの IPrincipal 偽装を使用)
すべての .NET コンポーネントでの使用 ServicedComponent ベース クラスに基づくコンポーネントのみ 可能
ロール メンバシップ Windows のグループ アカウントまたはユーザー アカウントを含むロール WindowsPrincipal を使用する場合、ロールは Windows グループ (特別なレベルの抽象化なし)
明示的なインターフェイス実装の必要性 あり
メソッド レベルの認定を取得するには、インターフェイスの明示的な定義および実装が必要		 なし
ロール メンバシップ Windows のグループ アカウントまたはユーザー アカウントを含むロール WindowsPrincipal を使用する場合、ロールは Windows グループ (特別なレベルの抽象化なし)
明示的なインターフェイス実装の必要性 あり
メソッド レベルの認定を取得するには、インターフェイスの明示的な定義および実装が必要		 なし

.NET ロールの使用

.NET ロールでは、以下の項目をセキュリティで保護することができます。

  • ファイル
  • フォルダ
  • Web ページ (.aspx ファイル)
  • Web サービス (.asmx ファイル)
  • オブジェクト
  • メソッドとプロパティ
  • メソッド内のコード ブロック

.NET ロールを使用することで、メソッドやプロパティによる操作と特定のコード ブロックを保護できるということは、アプリケーションによるローカルおよびリモートのリソースへのアクセスを保護できるということです。

メモ 前の一覧にある最初の 4 つの項目 (ファイル、フォルダ、Web ページ、および Web サービス) は、UrlAuthorizationModule の使用により保護されます。UrlAuthorizationModule では、認定の決定に呼び出し元 (および呼び出し元の ID) のロール メンバシップを使用することができます。

Windows 認証を使用すると、.NET ロールの使用に必要な多くの作業を省略できます。ASP.NET では、WindowsPrincipal オブジェクトが作成され、ユーザーの Windows グループ メンバシップにより関連するロール セットが決定されます。

Windows 以外の認証メカニズムで .NET ロールを使用するには、以下のコードを記述する必要があります。

  • ユーザーの資格情報を取得するコード
  • SQL Server データベースなどのカスタム データ ストアに対してユーザーの資格情報を検証するコード
  • ロールの一覧を取得し、GenericPrincipal オブジェクトを作成した後で、それを現在の Web 要求に関連付けるコード
    GenericPrincipal オブジェクトは、認証済みのユーザーを示し、宣言的な PrincipalPermission 要求やプログラム的な IPrincipal.IsInRole チェックなどの後続の .NET ロール チェックに使用されます。

詳細情報

フォーム認証における GenericPrincipal オブジェクト作成の詳細については、「第 8 章 ASP.NET セキュリティ」を参照してください。

ロール メンバシップのチェック

.NET ロールでは、以下の種類のチェックが可能です。

重要 .NET ロール チェックは、現在の要求に関連付けられている、認証済みのユーザーを示す IPrincipal オブジェクトに依存します。ASP.NET Web アプリケーションでは、IPrincipal オブジェクトが HttpContext.User に関連付けられている必要があります。Windows フォーム アプリケーションでは、IPrincipal オブジェクトが Thread.CurrentPrincipal に関連付けられている必要があります。

  • 手動によるロール チェック 細分化された認定を行う場合、IPrincipal.IsInRole メソッドを呼び出して、呼び出し元のロール メンバシップに応じて特定のコード ブロックへのアクセスを認定します。ロール メンバシップのチェックには、AND と OR の両方のロジックを使用できます。
  • 宣言的なロール チェック (メソッドへのゲート) ロール メンバシップを宣言的に要求するために、PrincipalPermissionAttribute クラス (PrincipalPermission に短縮可能) でメソッドに注釈を付けることができます。この場合、OR ロジックのみがサポートされます。たとえば、少なくとも 1 つの特定のロール (たとえば、出納係または管理者のいずれか) に呼び出し元が所属していることを要求できます。ただし、宣言的なチェックでは、呼び出し元が管理者で、さらに出納係であることを指定することはできません。
  • 強制的なロール チェック (メソッド内でのチェック) コード内で PrincipalPermission.Demand を呼び出して、細分化された認定ロジックを実行することができます。AND とOR 両方の論理演算がサポートされます。

ロール チェックの例

以下のコードに、プログラム的、宣言的、および強制的な方法でロール チェックを行う例を示します。

Bob による操作を認定する方法

  • 直接的なユーザー名チェック
    GenericIdentity userIdentity = new GenericIdentity("Bob");
    if (userIdentity.Name=="Bob")
    {
    }
  • 宣言的なチェック
    [PrincipalPermissionAttribute(SecurityAction.Demand, User="Bob")]
    public void DoPrivilegedMethod()
    {
    }
  • 強制的なチェック
    PrincipalPermission permCheckUser = new PrincipalPermission(
                                                   "Bob", null);
    permCheckUser.Demand();

出納係 (Teller) による操作を認定する例

  • 直接的なロール名チェック
    GenericIdentity userIdentity = new GenericIdentity("Bob");
    // Role names would be retrieved from a custom data store
    string[] roles = new String[]{"Manager", "Teller"};
    GenericPrincipal userPrincipal = new GenericPrincipal(userIdentity, 
                                                          roles);
    if (userPrincipal.IsInRole("Teller"))
    {
    }
  • 宣言的なチェック
    [PrincipalPermissionAttribute(SecurityAction.Demand, Role="Teller")]
    void SomeTellerOnlyMethod()
    {
    }
  • 強制的なチェック
    public SomeMethod()
    {
      PrincipalPermission permCheck = new PrincipalPermission(
                                                   null,"Teller");
      permCheck.Demand();
      // Only Tellers can execute the following code
      // Non members of the Teller role result in a security exception
      . . .
    }

管理者 (Manager) または出納係 (Teller) による操作を認定する例

  • 直接的なロール名チェック
    if (Thread.CurrentPrincipal.IsInRole("Teller") ||
        Thread.CurrentPrincipal.IsInRole("Manager"))
    {
      // Perform privileged operations
    }
  • 宣言的なチェック
    [PrincipalPermissionAttribute(SecurityAction.Demand, Role="Teller"),
     PrincipalPermissionAttribute(SecurityAction.Demand, Role="Manager")]
    public void DoPrivilegedMethod()
    {
    …
    }
  • 強制的なチェック
    PrincipalPermission permCheckTellers = new PrincipalPermission( 
                                                       null,"Teller");
    PrincipalPermission permCheckManagers = new PrincipalPermission(
                                                       null,"Manager");
   (permCheckTellers.Union(permCheckManagers)).Demand();

管理者 (Manager) であり、出納係 (Teller) でもあるユーザーによる操作を認定する例

  • 直接的なロール名チェック
    if (Thread.CurrentPrincipal.IsInRole("Teller") &amp;&amp;
        Thread.CurrentPrincipal.IsInRole("Manager"))
    {
      // Perform privileged operation
    }

  • 宣言的なチェック

    .NET ロールでは、宣言的に AND チェックを実行することができません。PrincipalPermission 要求を繰り返すと、論理和 (OR) になります。

  • 強制的なチェック

    PrincipalPermission permCheckTellers = new PrincipalPermission(
                                                     null,"Teller");
    permCheckTellers.Demand();  
    PrincipalPermission permCheckManagers = new PrincipalPermission(
                                                     null, "Manager");
    permCheckManagers.Demand();

認証メカニズムの選択

ここでは、一般的なアプリケーション シナリオにおいて適切な認証メカニズムを選択する際に役立つ内容を紹介します。以下の問題を検討することから始めます。

  • ID Windows 認証メカニズムは、アプリケーションのユーザーが、アプリケーションの Web サーバーからアクセス可能な信頼された機関により認証される Windows アカウントを持っている場合にのみ適切です。
  • 資格情報の管理 Windows 認証の主要な利点の 1 つは、オペレーティング システムに資格情報の管理を任せることができるところにあります。フォーム認証などの Windows 以外の認証アプローチでは、ユーザーの資格情報を格納する場所と方法を慎重に検討する必要があります。一般的には、次の 2 つのアプローチが使用されます。

    • SQL Server データベース

    • Active Directory 内のユーザー オブジェクト

      資格情報ストアとして SQL Server を使用する場合のセキュリティ上の検討事項については、「第 12 章 データ アクセス セキュリティ」を参照してください。

      Active Directory を含むカスタム データ ストアに対してフォーム認証を使用する場合の詳細については、「第 8 章 ASP.NET セキュリティ」を参照してください。

ID フロー 偽装および委任モデルを実装し、各層を通じてオペレーティング システム レベルで最初の呼び出し元のセキュリティ コンテキストをフローさせる必要があるかどうかを検討します。この必要があるのは、監査をサポートする場合や、ユーザーごとに細分化された認定を行う場合などです。フローさせる場合は、前の「委任」で説明したとおり、呼び出し元を偽装してそのセキュリティ コンテキストを次の下位サブシステムに委任できる必要があります。

ブラウザの種類 管理対象のすべてのユーザーが Internet Explorer を持っているかどうか、または、さまざまな種類のブラウザのユーザー ベースをサポートする必要があるかどうかを検討します。表 3.3 に、Internet Explorer を必要とする認証メカニズムと、一般的な各種のブラウザをサポートする認証メカニズムを示します。

表 3.3 認証のためのブラウザ要件

認証の種類 Internet Explorer が必要か メモ
フォーム 不要
Passport 不要
統合Windows (Kerberos または NTLM) 必要 Kerberos の場合、クライアントおよびサーバー コンピュータで稼働する Windows 2000 以降のオペレーティング システムと、委任用に構成されたアカウントが必要です。詳細については、このガイドの「パート IV : 参照」の「Windows 2000 での Kerberos 委任の構成方法」を参照してください。
基本 不要 基本認証は、ほぼすべてのブラウザによりサポートされる HTTP 1.1 プロトコルの一部です。
ダイジェスト 必要
証明書 不要 クライアントに X.509 証明書が必要です。

インターネット シナリオ

インターネット シナリオでは、基本的に次の状況が想定されます。

  • ユーザーが、サーバーのドメインまたはサーバーによりアクセス可能な信頼されたドメインに Windows アカウントを所有していない。
  • ユーザーが、クライアント証明書を所有していない。

図 3.4 に、インターネット シナリオで認証メカニズムを選択する際の枝分かれ図を示します。

図 3.4 インターネット アプリケーションの認証メカニズムの選択

Web サービス セキュリティと、GXA (Global XML Architecture) イニシアチブの一部である WS-Security 仕様の詳細については、「第 10 章 Web サービス セキュリティ」を参照してください。

フォーム認証と Passport 認証の比較

ここでは、フォーム認証と Passport 認証を比較して、それぞれの利点をまとめます。

フォーム認証の利点

  • カスタム データ ストア (通常、SQL Server または Active Directory) に対する認証がサポートされます。
  • データ ストアから取得されるロールを使用したロール ベース認定がサポートされます。
  • Web ユーザー インターフェイスに自然な形で統合されます。
  • ASP.NET に、豊富なインフラストラクチャが用意されています。従来の ASP と比較して、必要とされるカスタム コードが少なくて済みます。

Passport 認証の利点

  • Passport は、一元化されたソリューションです。
  • Passport により、アプリケーションでは資格情報の管理に関する問題を回避できます。
  • ロール ベースの認定スキームで使用できます。
  • 暗号化テクノロジを基盤としているため、セキュリティ上非常に安全です。

詳細情報

  • Web 認証アプローチの詳細については、「第 10 章 Web サービス セキュリティ」を参照してください。
  • SQL Server でのフォーム認証の使用については、このガイドの「パート IV : 参照」の「SQL Server 2000 でフォーム認証を使用する方法」を参照してください。

イントラネットおよびエクストラネット シナリオ

図 3.5 に、イントラネットおよびエクストラネットのアプリケーション シナリオで認証メカニズムを選択する際の枝分かれ図を示します。

図 3.5 イントラネットおよびエクストラネット アプリケーションの認証メカニズムの選択

認証メカニズムの比較

以下の表に、使用可能な認証メカニズムの比較を示します。

表 3.4 使用可能な認証方法

　 基本 ダイジェスト NTLM Kerberos 証明書 フォーム Passport
サーバーのドメインにおける Windows アカウントの必要性 必要 必要 必要 必要 不要 不要 不要
委任のサポート あり なし なし あり 可能 あり あり
Windows 2000 クライアントおよびサーバーの必要性 なし あり なし あり なし なし なし
資格証明がクリア テキストとして渡される (SSL が必要) はい いいえ いいえ いいえ いいえ はい いいえ
Internet Explorer 以外のブラウザのサポート あり なし なし なし あり あり あり

詳細については、前の「ID のフロー」の「委任」を参照してください。

まとめ

分散アプリケーションで認証および認定アプローチを設計することは、困難な作業です。ただし、アプリケーション開発の初期の段階で認証および認定の設計を適切に行うことで、セキュリティ上の重大なリスクの多くを回避することができます。この章のまとめは以下のとおりです。

  • 信頼されたサブシステムのリソース アクセス モデルを使用することで、データベース接続プーリングの機能を利用することができます。
  • アプリケーションで Windows 認証を使用しない場合は、.NET ロール チェックを使用して認定を行います。カスタム データ ストアに対して資格情報を検証し、ロールの一覧を取得した後で、GenericPrincipal オブジェクトを作成します。このオブジェクトを、現在の Web 要求に関連付けます (HttpContext.User)。
  • アプリケーションで Windows 認証を使用し、Enterprise Services を使用しない場合は、.NET ロールを使用します。Windows 認証の場合、.NET ロールは Windows グループとなることに留意してください。
  • アプリケーションで Windows 認証と Enterprise Services を使用する場合は、Enterprise Services (COM+) ロールの使用を検討します。
  • Enterprise Services (COM+) ロールを使用したロール ベース認定機能を利用するには、最初の呼び出し元の ID を Enterprise Services アプリケーションにフローさせる必要があります。また、ASP.NET Web アプリケーションから Enterprise Services アプリケーションを呼び出す場合、Windows 認証を使用する Web アプリケーションが偽装用に構成されている必要があります。
  • ロール メンバシップを宣言的に要求するために、PrincipalPermission 属性でメソッドに注釈を付けます。このメソッドは、呼び出し元が指定したロールに所属しておらず、セキュリティ例外が生成される場合には呼び出されません。
  • 細分化された認定の決定を行う場合、メソッド コード内で PrincipalPermission.Demand を呼び出すか、IPrincipal.IsInRole を使用します。
  • 追加のロール チェック セマンティクスを使用する場合、カスタムの IPrincipal オブジェクトの実装を検討します。