ホーム ライブラリ ラーニング ダウンロード サポート コミュニティ
サインイン | United States - English | |
このトピックはまだ評価されていません - このトピックを評価する

ASP.NET における認証 : .NET セキュリティ ガイド

.NET による分散アプリケーションの構築

Jeff Kercher
Edward Jezierski
Microsoft Corporation

August 2001
日本語版最終更新日 2001 年 12 月 5 日

要約 : この記事では、サーバー アプリケーションを設計する際のセキュリティ上の重要事項について説明します。Internet Information Services と ASP.NET は、どちらもアプリケーション内でユーザーを適切に認証し、正しいセキュリティ コンテキストを取得するためのセキュリティ モデルを提供しています。

目次

はじめに
セキュリティ上の注意事項
IIS と ASP.NET の間の関係
認証方式
Web サービスのセキュリティ
コード アクセス セキュリティ
チャネル セキュリティ
関連情報
付録 A


はじめに

セキュリティはアプリケーション アーキテクトと開発者の両方にとっての重要な問題です。機密情報を格納するアプリケーションは、悪意のある攻撃や、情報または知的所有物を盗もうとする競争相手から守られなくてはなりません。アプリケーションのセキュリティ モデルを設計する際には、ビジネスの観点からのセキュリティ要件と、選択したセキュリティ モデルがパフォーマンス、スケーラビリティ、および導入に与える影響を意識する必要があります。


セキュリティ上の注意事項

サーバー アプリケーションを設計する際には、設計仕様にセキュリティ上の問題を扱うセクションを盛り込む必要があります。アプリケーションの機能仕様では、以下の項目を考慮に入れ、対処しなくてはなりません。

  • セキュリティの目標。セキュリティの対象を理解し、明確に説明できるようにしておきます。
  • セキュリティ リスク。アプリケーションの脆弱性を理解します。また、ビジネスにとっての潜在的な脅威の大きさも理解する必要があります。
  • 認証。認証とは、ユーザーからクレデンシャルを受け取り、これらのクレデンシャルを指定された認証局と照らし合わせて確認するプロセスです。ユーザー(またはアプリケーションあるいはコンピュータ)のアイデンティティはセキュリティ プリンシパルと呼ばれます。クライアントは、サーバーがプリンシパルのアイデンティティを検証できるように、クレデンシャルを提供しなくてはなりません。アイデンティティが判明したら、アプリケーションはプリンシパルに対して、システム上のリソースへのアクセスを承認することができます。このドキュメントの次のセクションでは、適切な認証メカニズムを選択するための各種の基準を示しています。
  • 承認。これは、証明済みのアイデンティティに対して、特定のリソースへのアクセスを許可するかどうかを決定するプロセスです。
  • データ伝送のセキュリティ。ネットワーク上を移動するデータを暗号化することで、転送中の盗み見や改ざんを防ぐことができます。転送中のデータのセキュリティをどのレベルまで確保するのかを検討する必要があります。
  • 偽装 (インパーソネーション)。このメカニズムにより、サーバーはクライアントのセキュリティ クレデンシャルを使って動作することができます。サーバーがクライアントを偽装しているとき、サーバーが実行するすべての操作は、クライアントのクレデンシャルを使って実行されます。偽装では、サーバーはクライアントに代わってリモート リソースにアクセスすることはできません。このためには委譲を使用する必要があります。
  • 委譲。偽装と同様に、委譲によってサーバー プロセスはクライアントのセキュリティ クレデンシャルを使って動作することができます。ただし、委譲は偽装よりも強力で、サーバー プロセスはクライアントの振りをして他のコンピュータに対して呼び出しを行うことができます。
  • オペレーティング システム セキュリティ。セキュリティの対象となっているリソースに侵入者がアクセスするのを防ぐために、適切なアクセス制御リスト (ACL) とネットワーク セキュリティを確立することを指します。適切なリソースに適切な ACL を設定して、該当するプリンシパルのみがアクセスできるようにする必要があります。
  • 物理的アクセスのセキュリティ。サーバー コンピュータを安全な部屋に置くことを指します。この基本的な問題を軽視してはなりません。
  • コード アクセス セキュリティ。コードの出所や、コードのアイデンティティのその他の側面に基づいて、コードにさまざまなレベルの信頼を与えます。独自のアクセス権限を作成する方法を知っておく必要があります。

IIS と ASP.NET の間の関係

アプリケーションを設計する際には、Internet Information Services (IIS) 認証と Microsoft® ASP.NET セキュリティ アーキテクチャの間の関係を理解しておく必要があります。これにより、ユーザーを適切に認証し、アプリケーション内で正しいセキュリティ コンテキストを取得することができます。ASP.NET アプリケーションのセキュリティ構成と IIS のセキュリティ構成は完全に独立しており、互いに独立して、または組み合わせて使用することができます。

IIS はセキュリティ関連の構成設定を IIS メタベースに保持しています。一方、ASP.NET はセキュリティ関連の (およびその他の) 構成設定を XML 構成ファイルに保持します。このため、一般論として、セキュリティ上の観点からはアプリケーションの導入が単純化されますが、アプリケーションで採用したセキュリティ モデルによっては、IIS メタベースと ASP.NET アプリケーションの両方を、その構成ファイル (Web.config) を通して設定しなくてはならなくなります。

図 1 は IIS と ASP.NET の間の関係を示しています。

図 1. IIS と ASP.NET の間のセキュリティ上の関係
図 1. IIS と ASP.NET の間のセキュリティ上の関係


ASP.NET 認証プロバイダと IIS セキュリティ

ASP.NET は、認証プロバイダを使った認証を実装しています。認証プロバイダとは、クレデンシャルを検証し、cookie の生成といったその他のセキュリティ機能を実装しているコード モジュールです。ASP.NET は次の 3 つの認証プロバイダをサポートしています。

  • フォーム認証。このプロバイダを使用すると、認証されなかった要求は、クライアント サイド リダイレクションを使って特定の HTML フォームにリダイレクトされます。その後、ユーザーはログオン クレデンシャルを入力し、フォームをサーバーに返送することができます。アプリケーションが (アプリケーション固有のロジックを使って) 要求を認証すると、ASP.NET はクレデンシャルか、クライアント アイデンティティを再取得するためのキーを含んだ cookie を発行します。それ以降の要求は、要求ヘッダーに cookie を入れて発行されるので、それ以上の認証は不要となります。
  • Passport 認証。参加サイトに対してシングル ログオン機能とメンバシップ サービスを提供する、Microsoft が運用している集中化された認証サービスです。ASP.NET は、Microsoft® Passport ソフトウェア開発キット (SDK) との組み合わせによって、Passport ユーザーに対しフォーム認証と似た機能を提供しています。
  • Windows 認証。このプロバイダは IIS の認証機能を利用します。IIS が認証を終了すると、ASP.NET は認証済みのアイデンティティのトークンを使ってアクセスを承認します。

ASP.NET アプリケーションで特定の認証プロバイダを使用可能にするためには、アプリケーションの構成ファイルに次のようなエントリを作成する必要があります。

コピー 

                  
// web.configファイル
<authentication mode = "[Windows/Cookie/Passport/None]">
</authentication>

認証に加えて、ASP.NET はアプリケーション スレッドのセキュリティ トークンを確立するための偽装 メカニズムを提供しています。正しいトークンを取得するためには、IIS 認証、ASP.NET の認証プロバイダ、および ASP.NET の偽装設定を適切に構成する必要があります。図 2 に、IIS 認証と ASP.NET プロバイダのよく使われる組み合わせを示します。

図 2. ASP.NET と IIS のセキュリティ設定のマトリックス
図 2. ASP.NET と IIS のセキュリティ設定のマトリックス


Windows アカウントを使用した認証

Microsoft Windows NT®ドメイン コントローラによって、または Microsoft Windows® 2000 Active Directory? の中で保持されているアカウントを使ってユーザーを認証する場合には、図 2 のように、IIS 認証と Windows Provider for ASP.NET を組み合わせて使用します。このアプローチにより、特別に認証コードを書く必要がなくなります。この方法で認証が行われると、ASP.NET は認証されたユーザーをもとに Windows プリンシパル オブジェクトを作成し、アプリケーション コンテキストに追加します。その結果、ASP.NET スレッドは認証されたユーザーとして動作することができ、ユーザーのグループ メンバシップを獲得することができます。

ケースによっては、IIS 認証をバイパスし、カスタム ソリューションを実装したいことがあります。これも ASP.NET で実現できます。たとえば、ユーザーのクレデンシャルを Active Directory と照合してチェックするカスタム ISAPI フィルタを作成し、Windows プリンシパル オブジェクトの作成は手動で行います。これ以外にも有効な方法はありますが、いずれも .NET プロバイダを直接使用する場合よりも多くのコードを書かなくてはなりません。


非 Windows アカウントを使用した認証

ユーザーをアプリケーション レベルで認証する予定で、ユーザーが Windows アカウントを持っていない場合、一般には匿名認証を使用するように IIS を構成することになります。この構成では、以下の .NET 認証モジュールを使用することができます。

  • None : ユーザーの認証をまったく行わない場合、またはカスタム認証コードを作成する場合に使用します。
  • Forms : ユーザーに対してログオン ページを表示したい場合に使用します。
  • Passport : Passport サービスを使用する場合に使用します。

偽装と委譲

偽装では、ASP.NET アプリケーションはオプションとして、偽装の対象となっているクライアントのアイデンティティを使って動作することができます。通常、偽装はリソース アクセス制御のために使用されます。偽装はサーバー リソースを消費するので、本当に必要かどうかを慎重に検討するようにしてください。委譲は偽装をさらに強力にしたもので、サーバー プロセスはクライアントとして動作しながらリモート リソースにアクセスすることができます。

偽装が有効になっていると、ASP.NET は IIS から偽装のためのトークンを受け取ります。ASP.NET では、従来の Active Server Pages (ASP) と比べると、Web アプリケーションの中で偽装をより細かく制御することができます。制御はアプリケーションの Web.config ファイルで値を指定することによって行います。

偽装設定の指定には、次の 3 つのオプションがあります。

  • 偽装を有効にする。この場合、ASP.NET は IIS から渡されたトークンの偽装を行います。これは認証済みのユーザーか、匿名のインターネット ユーザー アカウントのどちらかです。
    コピー 
    

<identity impersonate="true"/>
  • 特定の偽装 アイデンティティを指定して、偽装を有効にする。この場合、ASP.NET は、構成されたアイデンティティを使って生成されたトークンの偽装を行います。この場合、クライアント トークンは、渡されていても使用されません。
    コピー 
    

<identity impersonate="true" name="domain\user" password="pwd"/>
  • 偽装を無効にする。ASP との後方互換性を保つために、デフォルト設定となっています。このときには、IIS と ASP.NET の認証をどのように組み合わせて使用した場合でも、ASP.NET スレッドはアプリケーション ワーカー プロセスのプロセス トークン (デフォルトでは IIS システム アカウント) を使って動作します。
    コピー 
    

<identity impersonate="false"/>

アプリケーションが UNC 共有ディレクトリ上に存在する場合、ASP.NET は、構成済みのアカウントが使用されていれば、つねに IIS UNC トークンの偽装を行ってその共有ディレクトリにアクセスします。明示的に構成されたアカウントが存在する場合、ASP.NET は IIS UNC トークンよりもそのアカウントを優先して使用します。

表 1 は、Web.config の 3 つの構成設定に応じて、ASP.NET が要求の実行のために使用するスレッド トークンを示しています。IUSR_SERVER アカウントは、現在の URL に対する匿名アクセスのために構成されたアカウントを示していることに注意してください (つまり、IUSR_アカウントである必要はない)。プロセス アカウントは、アプリケーション ワーカー プロセスが実行に使用しているアカウントで、特に構成されていない限り、デフォルトでは System アカウントとなります。

表 1. ASP と IIS の構成に応じた ASP スレッド トークン

ASP.NET の偽装IIS が匿名アクセスを使用しているIIS が匿名アクセスを使用していない アプリケーションが UNC 共有ディレクトリに置かれている
無効プロセス アカウントプロセス アカウントIIS UNC トークン
有効 IUSR_SERVER 認証済みユーザーIIS UNC トークン
有効。ユーザー "Jeff" を指定"Jeff""Jeff""Jeff"


アプリケーション アイデンティティ

ASP.NET アプリケーション ワーカー プロセス (aspnet_wp.exe) は、規定の System アカウントよりも弱い権限を持つ、特別に構成されたアカウントを使って実行することをお勧めします。第1に、セキュリティが破られた場合でも、侵入者は管理権限を使ってアクセスすることができません。第2に、アプリケーション サービス プロバイダ (ASP) は弱い権限のアカウントを使ってアプリケーションを実行することができるため、ホスティングされたアプリケーションがサーバー コンピュータの整合性に違反したり、管理権限を必要とするアクションを実行することはできなくなります。

特定のアカウントを使って ASP ワーカー プロセスを実行するには、\WINNT\Microsoft.NET\Framework\Version\Config フォルダに置かれているルート構成ファイル (machine.config) に、次のように <processModel> 要素を追加します。

コピー 

                  
<system.web>
  <processModel enable="true" username="domain\user" password="pwd"/>
</system.web>

特定のユーザー アカウントを指定するだけでなく、username 属性を、特別に認識される 2 つの値、"SYSTEM" と "MACHINE" のどちらかに設定することができます。どちらの場合でも、特定のクレデンシャルは不要なので、password 属性は "AutoGenerate" に設定しなくてはなりません。規定の "SYSTEM" 設定は、ワーカー プロセスを System アカウントを使って実行するのに対し、"MACHINE" 設定では、ワーカー プロセスは ASPNET というプレフィックスの付いた特殊なアカウントを使って実行されます。このアカウントは、通常の ASP アプリケーションをホスティングするときに、IIS が dllhost.exe のインスタンスを実行するために使用する IWAM_MACHINENAME アカウントに似ています。ASPNET アカウントは .NET のインストール時に作成されます。

カスタム アカウントを使用する場合、そのアカウントは以下のディレクトリに対するアクセス権利を持っていなくてはなりません。

  • %installroot%\ASP.NET Temporary Files ディレクトリに対する読み書きアクセスが必要です。このルートの下のサブディレクトリは、動的にコンパイルされる出力のために使用されます。
  • %temp% ディレクトリに対する読み書きアクセスが必要です。これはコンパイラが動的コンパイルの際に使用します。
  • アプリケーション ディレクトリへの読み取りアクセスが必要です。
  • システム アセンブリにアクセスするために、%installroot%階層への読み取りアクセスが必要です。

関連する ACE は、ASPNET アカウントのインストール プロセスの際に定義されることに注意してください。

特別に構成されたプロセス アカウントを使用する場合には、偽装の使用に関する制約を意識する必要があります。クライアントのアイデンティティの偽装は依然として可能ですが、アプリケーションの Web.config ファイルの中で特定の偽装 アカウントを定義する拡張形式の偽装は使用できません。これは、このオプションでは、ワーカー プロセスが、権限の弱いプロセス アイデンティティが通常は持っていない SE_TCB_NAME 権限 (「オペレーティング システムの一部として動作する」) を必要とするためです。要求ごとの偽装は使用できます。これは、IIS がログオン セッションを作成し、偽装 トークンをワーカー プロセスに直接渡すためです。この制約は Windows 2000 と Windows NT 4 のみに適用されます。Microsoft Windows XP では、この権限なしでも特定のログオン セッションを生成できるように、機能強化が図られています。

詳細については、『.NET Framework Developers Guide』 の以下の章を参照してください。

  • "How ASP.NET Security Works"
  • "ASP.NET Authentication"
  • "ASP.NET Configuration Concepts"
  • "Using IIS Authentication With ASP.NET Impersonation"

IIS 5.0 における認証の詳細については、記事 『Internet Information Services 5.0 Authentication Methods』 を参照してください。


認証方式

.NET Web アプリケーション内での認証には、さまざまなオプションがあります。たとえば、サポートされている IIS 認証メカニズムの 1 つを利用することもできますし、アプリケーション コードの中で認証を行うこともできます。認証方式を選択するときには、以下に示す要因のいくつかまたはすべてを考慮に入れる必要があります。

  • サーバーとクライアントのオペレーティング システム
  • クライアント ブラウザのタイプ
  • ユーザーの数と、ユーザー名とパスワードのデータベースの位置とタイプ
  • アプリケーションがインターネットとイントラネットのどちらをベースにしているのか、ファイヤウォールの背後に置かれるのかといった導入関連の要因
  • アプリケーションのタイプ。たとえば、対話型の Web サイトなのか、非対話型のWebサービスなのか
  • 保護しようとしているデータの機密レベル
  • パフォーマンスとスケーラビリティの要因
  • アプリケーション承認の要件。たとえば、アプリケーションをすべてのユーザーに提供するのか、一部の領域を登録済みユーザーに制限し、他の領域を「管理者のみ」に制限する必要があるのか。

認証方式の決定

付録 A のフロー チャートを使って、個々のアプリケーションの要件に応じた最適な認証方式を決定することができます。このチャートを使用するには、ユーザー ベースと導入モデルの性質に関する質問に答えていきます。チャートの終わりには、そのアプリケーションに適した認証方式が記されています。

フロー チャートを確認したら、以下のサブセクションに目を通してください。これらのサブセクションでは、各種の認証方式に関する詳しい情報と、意思決定プロセスの微調整に役立つ細かいガイダンスを示しています。このセクションを読み終えれば、適切な認証方式を選択できるようになっているはずです。


フロー チャートの意思決定ポイントの説明

  1. ユーザーはログインを行わなくてはならないか。 サイトまたはサービスへのアクセスに、ユーザー名とパスワードは必要か
  2. パーソナライゼーションは必要か 。 サイトは、ユーザーのログオンなしに、パーソナライズされたコンテンツを提供するのか。
  3. ユーザー アカウントの格納場所は。 ユーザー アカウントは Windows NT ドメイン アカウントに格納されるのか、Active Directory に格納されるのか、それともリレーショナル データベース、代替 LDAP (Lightweight Directory Access Protocol) ディレクトリ サービス、または XML ファイルといった他のデータ ストアに格納されるのか。
  4. シングル サインオンやシームレスなログオンは必要か。 ユーザーにログオン ページからログオンさせるのか、それとも認証が自動的に行われるようにするのか。 たとえば、自動化された B2B トランザクションでは、自動的に認証を行う必要があります。
  5. セキュアなログオンは必要か。 ハッカーがネットワーク経由でユーザー名とパスワードを盗むのを、きわめて困難にする必要はあるか。 この決定は、通常はサイト上のデータの機密レベルに基づいて行われます。
  6. アプリケーションはインターネット上で動作するのか。 アプリケーションはユーザーがドメインに対して認証されないファイヤウォールの背後に置かれるのか、それともエンド ユーザーがすでにドメインに対して認証されているイントラネット ベースのアプリケーションとなるのか。
  7. セキュリティ コンテキストを委譲する必要はあるか。 ビジネス コンポーネントは呼び出し元のアイデンティティで動作する必要はあるか。 そうであるならば、偽装が必要となります。さらに、リモート システム上のメッセージ キュー、データベース、またはファイル システムなどのシステム リソースにアクセスする必要がある場合には、委譲レベルの偽装が必要となります。
  8. サーバーとクライアントは Windows 2000 のみを実行しているか? Windows 2000 を実行するコンピュータの同質的な環境なのか、それとも Windows 9x や Windows NT 4.0 などの他のオペレーティング システムを実行しているクライアントが存在するのか。

匿名認証

匿名認証では、サーバーはクライアントに対し、ユーザー クレデンシャルを送信するように要求しません。この方式は、サイトまたはサービスがパブリックに提供され、呼び出し元のアイデンティティを知る必要がない場合に適しています。さらに、通常は、サポートされている認証メカニズムの非互換性が原因で生じるブラウザの制約もありません。サイトが匿名認証で構成されていれば、すべてのユーザーにアクセスが許可されます。IIS を匿名認証に構成したとしても、ASP.NET 層で認証を行っていれば、真の匿名認証にはならないことに注意してください。このセクションでは、IIS とアプリケーションの両方がログインを要求しないという前提に立ちます。


典型的な使用シナリオ

匿名認証は、以下のような場合に検討します。

  • ログインにもビジネス ロジック コンポーネントにも、呼び出し元の名前および(または)パスワードを知る必要がない。
  • 保護の対象の情報は「パブリック」なものと見なされる。

匿名認証は、以下のような場合には検討の対象から外します。

  • ユーザーに対しログイン名とパスワードの入力を求めなくてはならない。

その他の注意事項

匿名認証を選ぶときには、以下の事柄にも注意する必要があります。

パーソナライズされたコンテンツのみを含んでいるサイト

パーソナライズされたコンテンツのみを提供するサイトを設計しているときには、匿名認証は適していない可能性があります。例としては、ユーザーの郵便番号に応じたローカル情報を提供するが、ユーザーの明示的なログオンは要求しないニュース サイトが考えられます。パーソナライゼーション機能は、認証とは別に cookie を使って実現することができます。cookie の詳細については、このドキュメントの後の方の「 Cookies 」のセクションを参照してください。

偽装

匿名認証を使用する場合、アプリケーション スレッドは以下のいずれかとして実行されます。

  • 組み込みの匿名インターネット アカウント、IUSR_MACHINENAME。
  • IIS で匿名ユーザー用に構成されたアカウント。
  • IIS システム アカウント。

アプリケーションが COM+ コンポーネント、データベース、メッセージ キュー、または UNC ファイル共有ディレクトリなどの他のリソースを使用する場合には、匿名ユーザーに対して適切な権限を与えなくてはなりません。この場合には、以下のオプションを検討してください。

  • すべての Web サーバーとアプリケーション サーバーを含んだドメイン コントローラをセットアップします。匿名ユーザーは、リソースにアクセスできる適切な権限を持つドメイン ユーザーとして実行されるように構成します。この方式では、アカウント管理が集中化されるので、管理がしやすくなります。
  • サーバーをドメイン内で実行していない場合は、個々の Web サーバーとアプリケーション サーバーについて、それと同じ名前とパスワードを持つユーザーを作成します。アカウント管理が重複して複雑化するため、この方式は勧められません。

パフォーマンス

匿名 Web サイトを使用し、ASP.NET の偽装を使用しない方式では、最高のパフォーマンスが実現できる一方で、アプリケーションのセキュリティは最も弱くなります。


実装

匿名認証を実装するには、IIS を匿名認証に構成し、適切な匿名ユーザー アカウントを構成します。ASP.NET は、Web.config ファイルで、認証を使用しないように構成します。

コピー 

                  
// web.configファイル
<system.web>
   <authentication mode="None" />
</system.web>

基本認証

基本認証に構成された IIS は、ブラウザに対し、ユーザーのクレデンシャルを HTTP 経由で送信するよう指示します。パスワードとユーザー名は Base64 エンコーディングを使ってエンコードされます。パスワードはエンコードされますが、復号は比較的簡単なので、安全とは見なされません。ブラウザはユーザーに対してダイアログ ボックスを表示し、ユーザー名やパスワードなどのクレデンシャルとともに、オリジナルの匿名要求を再発行します。ポップアップのログオン ダイアログ ボックスが適しているかどうかは、ユーザー インターフェイス デザインの要件によります。大部分のインターネット ブラウザは基本認証をサポートしています。


典型的な使用シナリオ

基本認証は、以下のような場合に検討します。

  • ユーザーは Windows NT ドメインまたは Active Directory アカウントを持っている。
  • Netscape Navigator とすべてのバージョンの Internet Explorer (Pocket PC および Windows CE プラットフォームを含む) を含む、複数のブラウザ タイプをサポートする必要がある。
  • インターネット経由での認証をサポートする必要がある。
  • アプリケーション コード内でクリア テキスト パスワードにアクセスする必要がある。
  • 委譲をサポートする必要がある。

基本認証は、以下のような場合には検討の対象から外します。

  • セキュアなログインが必要だが、Secure Sockets Layer (SSL) のようなセキュアなチャネルを使用していない。
  • ユーザーはカスタム データベースに格納されており、Windows アカウントを持っていない。
  • ユーザーに対し、カスタマイズされたフォームをログイン ページとして表示する必要がある。

その他の注意事項

基本認証を選ぶときには、以下の事柄にも注意する必要があります。

基本認証を使った委譲

基本認証を使うと、1 台のコンピュータから別のコンピュータに対して委譲を行うことができます (ただし、さらに別のコンピュータに委譲することはできません)。委譲が可能なのは、IIS サーバーが Win32 API LogonUser の呼び出しを通して、ユーザーをローカルにログオンさせるためです。IIS はユーザーのパスワードのクリア テキストを持っているので、リモート コンピュータからのチャレンジに応答することができ、Web サーバーはクライアントの代わりとして動作することが可能となります。セキュリティ コンテキストを (2 ホップ以上の) 他のコンピュータに委譲する必要がある場合には、呼び出しチェーンの中のコンピュータにローカルにログオンしなくてはなりません。基本認証では、ユーザー名とクリア テキストのパスワードにアクセスすることができるため、これを ISAPI や CGI をベースにした他のアプリケーションに渡すことで、ローカル ログオンが可能となります。

基本認証のセキュリティ

パスワードは比較的簡単に解読できるため、基本認証を単独で使用するのは、セキュリティの必要のないアプリケーション、または弱いセキュリティでも十分なアプリケーションに限定するようにしてください。

基本認証のセキュリティを確保するには、SSL と組み合わせます。これにより、パスワードの解読を防ぐことができます。この基本認証と SSL の組み合わせは、今日稼働しているインターネット アプリケーションの多くで使用されています。


実装

基本認証を実装するには、IIS 内で基本認証を構成し、ユーザーにWebサーバーに対する "log on locally" 権限を持たせます。ASP.NET アプリケーションが基本認証によって認証されたユーザーとして動作する必要がある場合には、Web.config ファイルで次に示す構成を使用します。

コピー 

                  
// web.config ファイル
<system.web>
   <authentication mode="Windows" />
</system.web>

ダイジェスト認証

ダイジェスト認証は Windows 2000 と IIS 5.0 の新機能です。この形式の認証は、ユーザーのパスワード情報を暗号化し、いくつかの一般的なサーバー攻撃 (リプレイ攻撃など) を防ぐためのメカニズムを備えています。ダイジェスト認証は、基本認証とは異なり、ネットワーク上でクレデンシャルをクリア テキストとして送信することはしません。その代わりに、RSA が採用している MD5 というハッシング メカニズムを使用します (詳細については、http://www.ietf.org/rfc/rfc1321.txt の "The MD5 Message-Digest Algorithm" を参照してください)。これはインターネット シナリオでは有効な認証オプションですが、クライアントとサーバーの要件が原因で広くは普及していません。基本認証とは異なり、ダイジェスト認証では (NTLM や Kerberos と同様に) IIS がユーザーを Web サーバーにローカルにログオンさせないため、委譲を行うことはできません。


典型的な使用シナリオ

ダイジェスト認証は、以下のような場合に検討します。

  • Web サーバーは Windows 2000 を実行しており、ユーザーは Active Directory に格納された Windows アカウントを持っている。
  • すべてのクライアントが .NET プラットフォームか Internet Explorer 5.xを使用している。
  • 基本認証よりも強力なレベルでパスワードを暗号化する必要がある。
  • インターネット経由での認証をサポートする必要がある。

ダイジェスト認証は、以下のような場合には検討の対象から外します。

  • .NET または Internet Explorer 5.0 以降以外のプラットフォームを使用しているクライアントが存在する。
  • ユーザーは Active Directory に格納された Windows アカウントを持っていない。
  • 委譲を使用する必要がある。

その他の注意事項

ダイジェスト認証を選ぶときには、以下の事柄にも注意する必要があります。

ダイジェスト認証のセキュリティ

ダイジェスト認証の目的は、基本認証よりも安全なログオン手段を提供することです。しかし、これは基本認証に SSL、NTLM、Kerberos、または証明書認証を組み合わせたものほどは安全ではありません。

SSL 上でダイジェスト認証を使用すれば、セキュアなソリューションを実現することができます。しかし、その導入関連の要件が原因で、現時点では広くは普及していません。

ダイジェスト認証のための具体的なプラットフォーム要件

ダイジェスト認証では、クライアントは .NET または Internet Explorer 5.xを使用している必要があります。ユーザー アカウントは、ダイジェスト認証が構成された Active Directory に格納されていなくてはなりません。


実装

IIS でダイジェスト認証を構成する必要があります。詳細については、Microsoft Knowledge Base の記事 Q222028 『Setting Up Digest Authentication for Use with Internet Information Services 5.0』 を参照してください。

ASP.NET アプリケーションが IIS ダイジェスト認証によって認証されたユーザーとして実行されなくてはならない場合は、次に示す Web.config 構成を使用します。

コピー 

                  
// web.configファイル
<system.web>
<authentication mode="Windows" />
</system.web>

Windows 2000 でダイジェスト認証を使用するためには、サーバーはダイジェスト認証がセットアップされた Active Directory サーバーにアクセスできなくてはなりません。

ダイジェスト認証の詳細については、http://www.ietf.org/rfc/rfc2069.txt の RFC 2069 の仕様を参照してください。


統合 Windows 認証

統合 Windows 認証 (NTLM チャレンジ／レスポンス方式または Kerberos を使用) では、Windows NT ドメインまたは Active Directory アカウントを持つユーザーの認証が行われます。基本認証やダイジェスト認証とは異なり、暗号化されたパスワードがネットワーク上で送られることはないので、この方式のセキュリティはきわめて強力です。サーバー上に Active Directory Services がインストールされており、ブラウザに Kerberos V5 認証プロトコルとの互換性があれば、Kerberos V5 プロトコルとチャレンジ／レスポンス方式のプロトコルの両方が使用されます。それ以外の場合は、チャレンジ／レスポンス方式のプロトコルのみが使用されます。この方式は、ユーザー コンピュータと Web サーバー コンピュータが同じドメイン内にあり、すべてのコンピュータが Microsoft Internet Explorer version 3.01 以降を実行するように管理者が制御できるイントラネット環境に最も適しています。


典型的な使用シナリオ

統合 Windows 認証は、以下のような場合に検討します。

  • ユーザーは Windows NT ドメインまたは Active Directory アカウントを持っている。
  • アプリケーションはイントラネット上 (ファイヤウォールの背後) で実行される。
  • すべてのクライアントが Internet Explorer version 3.01 以降を実行している。
  • 委譲を行う必要がある (このためには Kerberos が必要)。
  • ドメイン ユーザーのためにシームレスなログオン手順が必要(たとえば、ポップアップのログオン ダイアログ ボックスを表示しない、など)。

統合 Windows 認証は、以下のような場合には検討の対象から外します。

  • ユーザー アカウントは、Windows NT ドメイン データベースや Active Directory ではなく、外部のデータベースに格納されている。
  • インターネット経由での認証をサポートする必要がある。
  • クライアントは Netscape Navigator やその他の Microsoft 以外のブラウザを使用している。
  • クライアントのクリア テキスト パスワードを入手する必要がある。

その他の注意事項

統合 Windows 認証を選ぶときには、以下の事柄にも注意する必要があります。

NTLM と Kerberos のセキュリティ レベル

どちらのプロトコルも、きわめて高度なセキュリティを持つと見なされています。NTLM と Kerberos では、パスワードはネットワーク上で送信されません。NTLM はチャレンジ／レスポンス方式のメカニズムを使用します。Kerberos は相互認証をサポートしているため、さらに安全であると考えられています (クライアントは通信先のサーバーを確認することができます)。

委譲の問題

NTLM プロトコルは委譲をサポートしていません。IIS サーバーに渡されたクライアントのクレデンシャルを、さらに認証のためにバックエンド サーバーに渡すことはできません。ただし、Kerberos は委譲をサポートしており、クライアントのクレデンシャルを複数の下流コンピュータ上のプロセスに委譲することができます。たとえば、Kerberos を使うと、Web ユーザーのクレデンシャルを COM+ の中間層に提示し、Windows 統合セキュリティが構成された Microsoft SQL Server? データベースに渡すことが可能です。Kerberos 認証は、規定の Active Directory 構成では有効になっていません。委譲のためのソリューションとして採用する前に、使用している環境が Kerberos をサポートしていることを確認するようにしてください。

インターネット上での使用

NTLM プロトコルと Kerberos プロトコルは、どちらも一般にインターネット上では使用されません。インターネット上での Kerberos の主な問題点は、セキュリティの認証局が集中化され、すべてのユーザーから利用可能になっていなくてはならないということです。これを実現するためのインフラストラクチャが必要となります。インターネットでの導入のもう1つの問題点は、これらのプロトコルが Microsoft 以外のブラウザではサポートされておらず、クライアント ベースのタイプによっては制約となるということです。

パフォーマンスとスケーラビリティ

Kerberos は NTLM よりも高速です。しかし、どちらのプロトコルも基本認証や一部のカスタム認証方式ほどは高速ではありません。多数のユーザーが同時にログオンする可能性がある場合には、Active Directory の構成を慎重に設計する必要があります。数百万人のユーザーがアクセスする可能性がある場合には、SQL Server などの高性能のデータベースを使ってユーザー名とパスワードを格納することを検討してください。多層アプリケーションの中でセキュリティ コンテキストを委譲する場合には、スケーラビリティの問題に遭遇する可能性があります。特に、データベース接続プーリングのような中間層のソリューションは利用することができません。


実装

Kerberos または NTLM を実装するためには、統合 Windows 認証を使用するように IIS を構成する必要があります。Internet Explorer 以外のブラウザを実行するクライアントをサポートする必要がある場合には、NTLM または Kerberos とともに、基本認証を有効にするといいでしょう。

Kerberos を構成する際には、以下の事柄を考慮に入れる必要があります。

  • クライアントおよびサーバー コンピュータは、いずれも Windows 2000 ドメインの中で Windows 2000 を実行していなくてはなりません。
  • クライアントのユーザー アカウントでは委譲が有効になっている必要があります。
  • サービスのアカウントでは委譲が有効になっている必要があります。

ASP.NET アプリケーションが、統合 Windows 認証を使って IIS によって認証されたユーザーとして動作しなければならない場合は、次に示す Web.config 構成を使用します。

コピー 

                  
// web.config ファイル

<system.web>
   <authentication mode="Windows" />
</system.web>

証明書認証

証明書は、コンピュータ上にインストールされたデジタルな「キー」です。コンピュータがサーバーへのアクセスを試みると、キーが自動的にユーザーを認証するために提示されます。クライアント証明書は、ドメインまたは Active Directory 内の Windowsアカウントにマッピングすることができます。ASP.NET で Windows 認証プロバイダを使用する場合、アプリケーション スレッドは、証明書のマッピング先のユーザーとして実行されます。また、証明書に含まれている電子メール アドレス (またはその他の一意のフィールド) を使って、ASP.NET でカスタム認証を実装することもできます。クライアントの側から見ると、クライアントはログオン ページを使ってログインする必要がないため、セキュリティはシームレスに実現されます。このため、証明書は自動化されたビジネス プロセスにきわめて適しています。


典型的な使用シナリオ

証明書認証は、以下のような場合に検討します。

  • 保護しようとしているデータはきわめて機密レベルが高く、きわめて安全なソリューションが必要である。
  • 相互認証が必要である。
  • サードパーティがサーバーと証明書所有者の間の関係を管理できるようにしたい。
  • クライアントの対話をシームレスにしたい。たとえば、自動化された B2B エクスチェンジなど。

証明書認証は、以下のような場合には検討の対象から外します。

  • クライアント証明書を発行し、管理するためのコストが、セキュリティの強化分の価値を上回る。

その他の注意事項

証明書認証を選ぶときには、以下の事柄にも注意する必要があります。

導入

クライアント証明書をクライアント ワークステーションに物理的に導入する必要があります。このための方法としては、Web導入をはじめとして、CD-ROM からの証明書のインストールなどのさまざまなものがあります。証明書が他の認証モードと SSL の組み合わせほど頻繁に使用されていないのは、一般に導入の問題のせいです。

Windows アカウントへのマッピング

証明書をドメインまたは Active Directory アカウントにマッピングすることが可能です。個々のユーザーを認証する必要がある場合は、証明書が個々のアカウントにマッピングされる 1 対 1 マッピングと呼ばれるテクニックを使用することができます。Active Directory マッピングを使用する場合には、1 対 1 マッピングに制限はありません。

特定のグループまたは組織のすべてのユーザーを認証する必要がある場合は、共通の会社名を含んでいるすべての証明書が 1 つのアカウントにマッピングされるといった多対 1 のマッピングを使用することができます。

例として、次のような B2B シナリオを考えてみましょう。

  1. A 社は、パートナー会社の B 社に対し、社内 Web サイトの一部を表示する許可を与えている。
  2. B 社のコンピュータには証明書がインストールされている。
  3. 多対 1 のマッピングにより、ASP.NET アプリケーションは汎用の "CompanyB" Windows アカウントとして実行される。

証明書の詳細については、Michael Howard 著 『Designing Secure Web-Based Applications for Microsoft Windows 2000』 を参照してください。

実装

IIS で証明書認証を構成する必要があります。パブリック キー証明書を Windows 2000 ユーザー アカウントにマッピングする方法については、ステップ バイ ステップ ガイド ユーザー アカウントへの証明書のマッピングを参照してください。


Passport 認証

Passport 認証は、Microsoft が提供している集中化された認証サービスです。Passport を使用すると、独自の認証コード、ログオン ページ、およびユーザー テーブルを実装する必要がなくなります。Passport は cookie メカニズムのように動作します。クライアントは、以前に Passport に対して認証されていれば、サイトへのアクセスが許可されます。認証されていなければ、認証のために Passport サイトに自動的にリダイレクトされます。

Passport は、やはり Passport をサポートしている複数のドメイン間でシングル サインオン機能が必要とされる場合に適しています。また Passport は、認証サービスとしての役割以外にも、プロファイル管理や購入サービスなどのサービスも提供しています。

Windows 2000 プラットフォームでは、Passport はオペレーティング システムに組み込まれている認証および承認メカニズムと直接には統合されていません。.NET Framework は Passport cookie をチェックしますが、独自のユーザー データベースを使用している場合には、Passport ユーザーをデータベース内のユーザーにマッピングするコードを実装し、さらに独自の承認メカニズムを実装する必要があります。


典型的な使用シナリオ

Passport 認証は、以下のような場合に検討します。

  • サイトは他の passport 対応サイトと組み合わせて使用され、これらのサイトにアクセスするユーザーに対してシングル サインオン機能を提供したい。
  • ユーザー名とパスワードのデータベースを独自に維持したくない。

passport 認証は、以下のような場合には検討の対象から外します。

  • 独自のデータベースまたは Active Directory にすでに格納されているユーザー名とパスワードを利用したい(ただし、コードを追加すれば、passport ID をユーザー アカウントにマッピングすることも可能)。
  • クライアントは、サイトにプログラム的にアクセスする他のコンピュータである。

その他の注意事項

passport 認証を選ぶときには、以下の事柄にも注意する必要があります。

passport の有効化

passport 認証を使用するためには、サイトを passport サービスに登録し、サーバー上に passport SDK をインストールする必要があります。

委譲

Windows 2000 では、ユーザーの passport セキュリティ クレデンシャルをサーバー間で委譲することはできません。

ユーザー アカウントへのマッピング

passport ユーザー ID (PUID) はアイデンティティに過ぎません。ユーザー アカウントが Active Directory または何らかのカスタム データベースの中で定義されており、PUID をユーザーにマッピングする必要がある場合には、独自のカスタム コードを実装する必要があります。将来のバージョンの Windows では、PUID から Windows アカウントへのマッピングがネイティブでサポートされる可能性があります。

passport のセキュリティ

cookie の暗号化のおかげで、passport をスタンドアロンの認証方式として使用してもセキュリティが確保されます。ただし、リプレイ攻撃を防ぎ、最高レベルのセキュリティを確保するためには、passport を SSL と組み合わせて使用する必要があります。


実装

passport を実装するためには、passport SDK をサーバー上にインストールする必要があります。また、サービスを使用するために、passport に登録しなくてはなりません。web.config ファイルは次のように構成します。

コピー 

                  
// web.configファイル
<system.web>
   <authentication mode="passport " />
</system.web>

passport サービスの詳細については、以下を参照してください。


フォーム認証

フォーム認証とは、ユーザー クレデンシャル (ユーザー名とパスワードなど) を受け付けるカスタム ユーザー インターフェイス コンポーネントのことを指します。今日使用されているインターネット アプリケーションの多くは、ユーザーにログオンさせるためにこの種のフォームを表示します。フォームそのものは、認証を行うわけではなく、ユーザー クレデンシャルを取得するための手段でしかないことに注意してください。認証は、カスタム コードを使ってユーザー名とパスワードのデータベースにアクセスすることによって行われます。

ユーザーが認証されると、サーバーは一般に、それ以降の要求ですでに認証が済んでいることを知らせるための手段をクライアントに与えます。必要ならば要求のたびにクライアントに認証を行わせることもできますが、その場合にはパフォーマンスとスケーラビリティに影響が及びます。以前にログオンしたクライアントの識別には、2 つの基本的なアプローチがあります。

  • cookie。cookie は、サーバーが最初にクライアントに提示する小さなデータです。これは後に、HTTP 要求のたびにクライアントからサーバーに提示されます。これを、クライアントがすでに認証されていることの通知として使用することができます。ASP.NET は、CookieAuthenticationProvider モジュールに、フォーム認証のために cookie を使用するためのメカニズムを用意しています。cookie は、Internet Explorer と Netscape Navigator を含む大部分の Web ブラウザでサポートされています。
  • カスタム。クライアントをサーバーに対して識別する独自のカスタム メカニズムを実装することができます。クライアントが cookie を無効にしている場合には、個々の URL クエリ文字列に一意の識別子を格納することが可能です。また、トップレベル フレームや非表示フレームに格納される、非表示の永続的なフォーム フィールドを使用することもできます。どちらのケースでも、ハッカーがアプリケーションに対する認証をプログラム的にシミュレートできないようにする必要があります。

cookie は、フォーム認証を使用する Web サイトで広く使用されています。.NET の最初のリリースでは、cookie を使用したフォーム認証のみがサポートされます。


典型的な使用シナリオ

フォーム認証は、以下のような場合に検討します。

  • ユーザー名とパスワードは、Windows アカウント以外のどこかに格納されている。Windows アカウントでフォーム認証を使用することも可能。
  • アプリケーションをインターネット経由で導入する。
  • すべてのブラウザとクライアント オペレーティング システムをサポートする必要がある。
  • ログオン ページとして独自のユーザー インターフェイス フォームを提供したい。

フォーム認証は、以下のような場合には検討の対象から外します。

  • アプリケーションを企業イントラネットに導入しようとしており、統合 Windows 認証を利用することができる。
  • プログラム的なアクセスによってユーザー名とパスワードを検証することができない。

その他の注意事項

フォーム認証を選ぶときには、以下の事柄にも注意する必要があります。

フォーム認証のセキュリティ

ユーザーがログオン ページを介してパスワードを入力する場合には、SSL を使ってチャネルのセキュリティを確保し、パスワードが盗まれるのを防ぐことができます。要求間でユーザーのアイデンティティを保持するために cookie を使用する場合には、ハッカーがネットワーク監視プログラムを使ってユーザーの cookie を「盗む」というセキュリティ リスクを考慮に入れる必要があります。cookie を使用するサイトを完全にセキュアにするためには、サイトとのすべての通信に SSL を使用するしかありません。大部分のコマース サイトでは、パフォーマンスのオーバーヘッドが大きくなりすぎるため、この方法は非現実的です。ASP.NET では、サーバーに定期的な間隔で cookie を再生成させることができます。この cookie の有効期限ポリシーは、盗んだ cookie を使って他のユーザーがサイトにアクセスするのを防ぐことを目的としています。

パフォーマンスとスケーラビリティ

トラフィックの大きい Web サイトを設計するときには、ユーザー認証がパフォーマンスに与える影響を考慮に入れなくてはなりません。多数のユーザーが同時にログオンすると予想される場合には、クレデンシャルの検証を可能な限り高速に実行する必要があります。

SSL を使用する場合には、暗号化のステップが必要となるため、パフォーマンスが顕著に低下します。パフォーマンス要件を満たすためには、Web ファーム内で、セキュア ログオンを実行するサーバーとコンテンツ サーバーを分離しなくてはならないことがあります。

cookie の存在のチェック

.NET を使用する場合、cookie が存在するかどうかのチェックは自動的に行われます。.NETを使用しない場合には、基本的に2つのアプローチがあります。

  • クライアントの要求に、クライアントが認証されていることを証明する cookie が存在するかどうかを確認する ISAPI フィルタを実装することができます。cookie が存在する場合には、要求の処理を続けます。cookie が存在しない場合は、クライアントをログオン ページにリダイレクトします。このような ISAPI フィルタは、Microsoft® Commerce Server 2000 によって実装されています。
  • 個々の Web ページの先頭に、cookie の存在や、Web ページから渡されたその他のカスタムの値の存在をチェックするコードを置くことができます。そのトークンが存在しなければ、コードはユーザーをログオン ページにリダイレクトします。これは単純な実装ですが、ASP ページ以外のリソースは保護できない場合があります。たとえば、画像ファイルへのアクセスは依然として可能かもしれません。

ASP.NET を使用する場合には、フォーム認証が提供する組み込みの機能を利用することができます。

Windows アカウントでのフォーム認証の使用

インターネット アプリケーションを導入しようとしており、ユーザーがサーバー上に Windows アカウントを持っている場合には、基本認証またはダイジェスト認証の代わりとして、フォーム認証、または SSL 上でのフォーム認証を使用することができます。

このソリューションは、イントラネット ベースのアプリケーションで、統合 Windows 認証を利用できる場合には適していないかもしれません。また、企業のセキュリティ ポリシーが、ユーザーがパスワードを HTML フォームに入力することを禁じている場合もあります。


実装

フォーム認証を実装するためには、独自のログオン ページを作成し、未認証のクライアントを特定のURLにリダイレクトしなくてはなりません。また、アカウント ルックアップの独自の方式を作成する必要があります。ASP.NET を使用する場合には、次に示す Web.config 構成を使用することができます。

コピー 

                  
// web.config ファイル
<system.web>
   <authentication mode="Forms" />
</system.web>

独自の認証を実装することになるので、通常は IIS を匿名認証に構成します。

SSL の実装の詳細については、以下の記事を参照してください。


cookie は、Web サーバーによってハード ディスク ドライブに格納される小さなテキスト ファイルです。その主な目的は、サーバーが、以前にアクセスしたことのあるクライアントを識別できるようにすることです。cookie は認証メカニズムと組み合わせて使用することも、単独で使用することもできます。以下の使用シナリオが考えられます。

  • フォーム認証と組み合わせて使用する。サーバーは認証時にクライアントに対して cookie を発行し、それ以降の要求はサーバーに提示された cookie に基づいて確認されます。
  • ユーザーに対してカスタマイズされたコンテンツを提供するパーソナライゼーションのみに使用する。

ASP.NET は cookie を作成するメカニズムを持っており、クライアント要求に cookie が含まれているかどうかを自動的にチェックします。ASP.NET によって作成された cookie は、オプションとして、.NET Framework がサポートするトリプル DES スキームを使って暗号化することができます。また、cookie プロバイダの独自の実装を実装し、これをフォーム認証と組み合わせて使用することもできます。

cookie の詳細については、『Information About cookies』 を参照してください。


その他の注意事項

ブラウザ タイプによっては、cookie のサイズに制限があることがあります。RFC 2019 は上限を 4 KBと定めています。Internet Explorer 5 はサイズに上限を課していません。cookie が正常に動作するためには、ブラウザのセキュリティ設定で cookie を受け付けるように構成しておく必要があります。


Web サービスのセキュリティ

Web サービスとは、インターネット経由でプログラム的に呼び出すことができる、ASP.NET インフラストラクチャをベースにしたアプリケーションです。セキュリティの点では、対話的な Web サイトを開発するときと似たような問題が生じます。また、Webサービスのセキュリティの確保には、他の ASP.NET リソースと同じメカニズムを使用することになります (IIS と ASP.NET の認証プロバイダなど)。ただし、設計にあたっては、以下の要因を新たに考慮する必要があります。

  • クライアントとの対話。Web サービスには、セキュリティ クレデンシャルを対話的に入力するユーザーがおらず、その代わりにアプリケーションが「ユーザー」となることがあります。
  • メソッド レベル セキュリティ。ユーザーをメソッド レベルで承認し、特定のメソッドのみに使用を制約しなくてはならないことがあります。これは、COM+ コンポーネントのメソッド レベル セキュリティと似た方法で実現します。
  • 委譲。Web サービスは、他のサービスを呼び出し、オリジナルの呼び出し元のセキュリティ コンテキストを保持しなくてはならないことがあります。

Web サービスの認証

Web サービスは何らかの方法でユーザー クレデンシャルを受け付けなくてはなりません。サービスが非対話型である場合には、呼び出し元のセキュリティ トークンを入手するか、クレデンシャルを提示するための適切な手法を公開する必要があります。以下に示す認証方式は、簡単に使用することができ、ユーザーがクレデンシャルを入力する必要がないため、プログラミング可能な Web サービスに適しています。

  • 基本、ダイジェスト、および統合 Windows 認証
  • 証明書マッピング認証
  • アプリケーション固有の認証、またはカスタム認証

また、以下のものも使用することができます。

  • インターネット プロトコル セキュリティ
  • passport

Windows アカウントと IIS 認証の使用

このドキュメントの「認証方式」のセクションに述べたのと同じ問題を考慮に入れる必要があります。この実装では、必要なカスタム コーディングの量が最小限に抑えられ、Windows ACL を使って他のリソースへのアクセスを承認することができます。


証明書と証明書マッピングの使用

証明書認証を使用する場合、クライアントとサーバーの間の対話はシームレスに行えます。つまり、クライアントはプログラム的にユーザー名とパスワードを提供する必要がありません。さらに、これは高度なセキュリティを持つメカニズムです。購入オーダーのサブミットなどの B2B トランザクションは、証明書を使用するシナリオとして理想的です。証明書マッピングを使って Windows ユーザー アカウントを取得する場合には、Windows ACL を使ってリソースへのアクセスを承認することもできます。


カスタム認証

カスタム認証ソリューションを実装することができます。これらのソリューションには、統合 Windows 認証のアプローチと比べると、アプリケーションがユーザーごとに個別の Windows アカウントを保持する必要がないという利点があります。また、IIS 認証を完全にバイパスし、Web サービスのコードの中で独自のカスタム メソッドを使用し、アプリケーション固有のニーズに合わせて最適化することも可能です。

Web サービスのためのカスタム認証ソリューションとしては、以下のようなものが考えられます。

  • ユーザー名とパスワードを、メソッド呼び出しのパラメータとして受け付ける。
  • 他のメソッドの呼び出しの前に必ず呼び出さなくてはならないログオン メソッドを用意する。Microsoft .NET Framework の cookie 機能を使って、ログオン メソッドが呼び出されていることを検証することができます。
  • SOAP ヘッダーまたは SOAP 本体を使ってクレデンシャルを格納する。
  • カスタム HTTP ヘッダーまたは本体を作成して、そこにクレデンシャルを格納する。

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

クライアントが中間層の Web サービスにカプセル化されたビジネス ロジックを呼び出すWebサーバーである場合など、クライアント コンピュータの IP アドレスがわかっている場合には、インターネット プロトコル セキュリティ (IPSec) が選択肢として有効なことがあります。この方式では、Web サービスに接続するコンピュータを、その IP アドレスに基づいて制約することができます。

このアプローチは、クライアントの IP アドレスが事前にはわからないインターネット シナリオには使用できません。

IPSec の詳細については、『Windows 2000 Server の IP セキュリティ』 を参照してください。


Web サービスでの passport の使用

ケースによっては、Web サービスは passport 認証を認証のために使用することができます。ただし、認証されていないクライアントを passport サイトにリダイレクトしなくてはならないという要件のために、用途は限定されます。非対話型クライアントは、passport サーバーにリダイレクトされるケースに対応できるようにプログラミングされていない限り、リダイレクションによって問題が生じる可能性があります。


承認

ユーザーの認証を行った後に、Web サービスへのアクセスを承認しなくてはならない場合があります。以下に、承認を行うためのいくつかの選択肢を示します。

  • Windows ACL を使用する
  • URL 承認を使用する
  • .NET プリンシパル オブジェクトを使用する

Windows ACLの使用

Windows ACL を使用すると、特定のアプリケーション ファイルに対するファイル システム権限を作成することができます。このソリューションは、Web サービスがユーザーを Windows アカウントに認証し、偽装を使用している場合に適しています。


URL 承認の使用

URLAuthorizationModule は、ユーザーとロールを、URI 名前空間の中の要素にマッピングします。このモジュールはポジティブとネガティブの両方の承認アサーションを実装しています。つまり、このモジュールは、ユーザーのロール メンバシップなどに基づいて、URI 名前空間の任意の要素へのアクセスを選択的に許可または拒否することができます。次の例は、数人のドメイン ユーザーにアクセスを許可し、その他のユーザーに対してはアクセスを拒否しています。

コピー 

                  
<configuration>
   <system.web>
         <authentication mode="Windows" />
          <authorization>
              <allow users="domain1\user, domain2\user2, domain1\user3 />
              <deny users="*" />
          </authorization>
    </system.web>
</configuration>

Windows プリンシパル オブジェクト

.NET Framework クラス ライブラリ (BCL) の System.Security.Principal 名前空間は、コードの実行に使用されているセキュリティ コンテキストを表す WindowsPrincipal オブジェクトを含んでいます。このオブジェクトは、IIS で Windows認証を使用したときに自動的に作成されます。これにより、Windows ユーザーの Windows グループ メンバシップをチェックし、それに応じてアクセスを制約することができます。

汎用的なプリンシパル オブジェクト

独自のカスタム ロールに基づいて、汎用的なプリンシパル オブジェクトを作成することができます。これは、独自のユーザー／ロール データベースを持っている場合に使用します。プリンシパル オブジェクトは OnAuthenticate イベントに格納されます。このイベントを Windows アカウントにマッピングするカスタム テーブルを作成しておくことができます。いずれにせよ、特定のユーザーのためのカスタム プリンシパル オブジェクトを作成することが可能です。

以前に認証が行われたユーザーについては、cookie を使用して、再訪したユーザーのためのプリンシパル オブジェクトを再作成することができます。


ロールとメソッド レベル セキュリティ

特定のメソッドの呼び出しを特定のクライアント プリンシパルに制約するために、メソッド レベル セキュリティを使わなくてはならないことがあります。これにはいくつかのアプローチがあります。

Windows アカウントを使用する場合は、Windows グループの形で、ユーザーのためのロールを作成します。ASP スレッドはクライアントの偽装を行い、Windowsプリンシパル オブジェクトが利用可能になっているので、以下のアプローチを使用することができます。

  • ASP.NET スレッドからアクセスされる保護対象のリソースに対して、ACL を作成します。
  • 個々のメソッドから、WindowsPrincipal オブジェクトの IsInRole メソッドを呼び出し、呼び出し元が適切な権限を持っていることを検証します。また、コード内に、クライアントのグループ メンバシップに基づいて特定のサブルーチンを呼び出すロジック ステートメントを実装することもできます。

カスタム データベースに含まれているユーザーとロールから作成された汎用的なプリンシパル オブジェクトを使用する場合:

  • 上に述べたWindows プリンシパル オブジェクトの場合と同じように、プリンシパル オブジェクトの IsInRole メソッドを呼び出すことで、ロール メンバシップをプログラム的にチェックすることができます。

プリンシパル オブジェクトを使用しない場合には、これ以外の選択肢があります。

  • ユーザー クレデンシャルをメソッド呼び出しのパラメータとして受け取り、ルックアップを実行する。
  • メソッド呼び出しの最初の操作として、cookie の存在を検証する。
  • カスタムのキー値を返すログオン メソッドを作成する。それ以降のメソッドはキー値をパラメータとして受け付ける。これはブラウザがサポートする cookie の使用方法に似ています。ただし、クライアントが cookie をサポートしていない場合でも使用できます。

委譲

Web サービスでは、ASP.NET の Web サイトと同じ、委譲に関連する問題が存在します。セキュリティ コンテキストを Web サービスに委譲するためには、Kerberos 認証を使用するか、他のコンピュータ上で動作している Web サービスが、Windowsサーバーである場合には LogonUserを、Windows サーバーでない場合にはそれと等価な認証 API を呼び出せるように、クレデンシャルを渡す必要があります。


クライアント アクセス

Web サービスにプログラム的に接続するときには、クライアント接続に .NET クラスを使用することができます。.NET クライアントでサポートされる認証プロトコルは以下のとおりです。

  • 基本
  • ダイジェスト
  • Windows 統合 (NTLM と Kerberos)
  • 証明書
  • カスタム

コード アクセス セキュリティ

コンピュータ システムを悪意のあるコードから守り、モバイル コードを安全に実行するための手段を提供するために、.NET Framework はコード アクセス セキュリティ (CAS) と呼ばれるセキュリティ メカニズムを用意しています。CAS は .NET のセキュリティ機能ですが、ASP.NET Web アプリケーションなどのすべての .NET マネージ コードに適用されます。ただし、CAS がすべてのマネージ コードに適用されるとはいっても、以下の場合にはコーディングの際に特別な配慮が必要です。

  • ブラウザにホスティングされるコントロールを設計している場合
  • サードパーティ アプリケーションをホスティングする場合
  • 共有サーバー上で複数のベンダのアセンブリをホスティングする場合
  • ファイル書き込みAPIなどの特定のネイティブ機能の使用を、特定のアセンブリに対して禁止したい場合

CASでは、コードの出所や、ストロング アセンブリ名などのコードのアイデンティティのその他の側面に基づき、セキュリティ ポリシーによってコードにさまざまなレベルの信頼度を割り当てることができます。CASは、コードが他の悪意のあるコードによって悪用される可能性を軽減します。コードが実行できる操作のセットと、コードが決して実行を許されない操作のセットを具体的に設定することができます。具体的に言えば、CASは、コードが特定の権限を明示的に要求し、決して必要としないことがわかっている権限を明示的に拒否することができる権限サポート メカニズムをサポートしています。


コード アクセス権限

コード アクセス セキュリティは、コード アクセス権限という概念をベースにしています。個々の権限は、コードがファイル、ディレクトリ、レジストリ項目といった保護されたリソースにアクセスする権利、またはアンマネージ コードの呼び出しといった保護された操作を実行する権利を表しています。コードは権限を要求することができ、ランタイム セキュリティ ポリシーはどの権限を許可するかを決定します。権限の一覧については、『コード アクセス許可』 を参照してください。

.NET では、管理者はアプリケーションに対して事前に定義された権限のセットを割り当てることができます。これらの権限は、アプリケーションに与えられた信頼のレベルに基づいて異なります。デフォルトでは、アプリケーションは、コードのデジタル署名、出所、およびアプリケーションの位置に関して提示されたエビデンスに基づく信頼レベルを与えられます。

たとえば、UNC 共有ディレクトリ上で (つまりイントラネット セキュリティ ゾーン内で)実行されているアプリケーションは、LocalIntranet 権限セットを受け取ります。ローカル マシン上で(つまりマイ コンピュータ セキュリティ ゾーン内で)実行されているアプリケーションは、FullTrust 権限セットを受け取ります。

ASP.NET Web アプリケーションは、信頼レベルを割り当てることで、さらに細かく制御することができます。信頼レベルは、構成ファイルの中で <trust> 要素を使って構成されます。

コピー 

                  
<trust level="Full | High | Low | None" originUrl="url" />

個々のレベルは、アプリケーションの権限を決定し、その詳細は XML セキュリティ ポリシー ファイルによって指定されます。個々のレベルは特定のファイルにマッピングされます。ASP.NET のデフォルト マッピングは次のとおりです。

  • High - web_hightrust.config にマッピングされます。
    このレベルは、アプリケーション ディレクトリへの読み書きアクセスを許可する権限をアプリケーションに与え (オペレーティング システムの権限による制約はあります)、アプリケーションは認証プリンシパル オブジェクトを置き換えることができます。また、アプリケーションはアンマネージ コードの呼び出しは行えません。
  • Low - web_lowtrust.config にマッピングされます。
    このレベルでは、アプリケーションはアプリケーション ディレクトリの読み込みを行うことができ、制限付きのネットワーク接続が行えます。アプリケーションは、<trust> 要素の originUrl 属性が適切に構成されていれば、ホスト サイトに接続することができます。
  • None - web_notrust.config にマッピングされます。
    このレベルは、基本的な実行権限を提供し、アプリケーションでの隔離ストレージの使用がサポートされます (コードに保存済みデータを安全に関連付けるメカニズム)。

Full 信頼では、アプリケーションはすべてのリソースを使用することができ(オペレーティング システムの権限による制約はあります)、コード アクセス セキュリティなしで動作するのと同じになるので (ただしマネージ コードに対して CAS をオフにすることはできません)、構成ファイルは関連付けられていません。これらのマッピングは、構成ファイルの <securityPolicy> 要素の中でオーバーライドすることができ、個々のレベルのカスタマイズと拡張が可能です。また、任意の権限セットを定義する独自のレベルを作成することもできます。次に規定の <securityPolicy> マッピング セットを示します。

コピー 

                  
<securityPolicy>
   <trustLevel name="Full" policyFile="internal" />
   <trustLevel name="High" policyFile="web_hightrust.config" />
   <trustLevel name="Low"  policyFile="web_lowtrust.config" />
   <trustLevel name="None" policyFile="web_notrust.config" />
</securityPolicy>

構成設定のロック

ASP.NET 構成は階層的な性質を持っており、オプションとしてマシン、アプリケーション、およびサブアプリケーションのレベルで構成ファイルが存在します。サブレベルの構成ファイルは、上位のレベルでの設定をオーバーライドしたり、構成情報を追加するために使用することができます。このように高度な柔軟性が実現されていますが、管理者は特定の構成設定を強制し、個々のアプリケーションによるオーバーライドを禁止したい場合があります。たとえば、ホスティングされた Web サイトの管理者は、コード アクセス セキュリティのレベルを指定し、個々のアプリケーションによる変更を禁止したいと考えるかもしれません。これは、<location> 要素と allowOverride 属性の組み合わせによって実現することができます。

たとえば、ホスティングされた Web サイトの管理者が、どのアプリケーションもアンマネージ コードを呼び出せないようにしたいと考えたとします。次の構成ファイルの一部は、管理者がサイト全体のコード アクセス構成設定をロックし、(アンマネージ コードへの呼び出しが禁止される) High の信頼レベルのアプリケーションのみに制約する方法を示しています。

コピー 

                  
<location path="somesitepath" allowOverride="false">
  <trust level="high" originUrl="http://somesite.com" />
</location>

path 属性は、サイトまたは仮想ディレクトリを参照することができ、指定されたディレクトリとそのすべてのサブディレクトリに適用されます。上の例では、allowOverride を "false" に設定すると、<location> 要素内で指定された構成設定を、サイト内のアプリケーションがオーバーライドするのを禁止することができます。構成設定をロックする機能は、信頼レベルなどのセキュリティ設定だけでなく、すべての設定に適用されることに注意してください。

詳細については、以下を参照してください。


チャネル セキュリティ

チャネルは、AppDomains、プロセス、およびコンピュータなどのリモーティング境界を越えてメッセージを転送します。.NET Framework は、HTTP と TCP という 2 つのリモーティング チャネルを提供しています。

これらのプロトコルで機密情報や重要な情報を転送するときには、セキュア チャネルを使って情報を保護することを検討してください。情報が暗号化によって保護されていないと、ネットワーク監視ソフトウェアを使って簡単にインターセプトし、盗み見ることができます。

以下に、チャネル セキュリティのいくつかのキー ポイントを示します。

  • IIS と ASP.NET の組み合わせによってホスティングされた HTTP チャネルは、SSL を使ったセキュアなデータの送信と受信をサポートします。SSL はセキュアな通信チャネルをセットアップするための最も一般的なメカニズムであり、IIS 内で構成することができます。
  • HTTP/ポート80 や TCP などのセキュアでないチャネルを使用したい場合でも、暗号APIを使ってデータを手動で暗号化することができます。
  • トランスポート層の下でチャネル セキュリティ メカニズムを実装することができます。Windows 2000 を使用している場合には、インターネット プロトコル セキュリティ (IPSec) を使って、アプリケーションに対しては透過的にデータ転送のセキュリティを確保することができます。
  • ASP.NET を COM または DCOM コンポーネントと組み合わせて使用しており、リモーティング メカニズムとして DCOM を使用している場合には、DCOM Packet Privacy 認証レベルを使って DCOM 通信を暗号化することを検討してください。

詳細については、以下を参照してください。


関連情報

このドキュメントで扱ったセキュリティ関連のトピックの関連情報については、以下のリファレンスを参照してください。

  • Microsoft Pressから発行されている『Microsoft® Windows® 2000 Server Resource Kit』の「Understanding Digital Certificates」
  • Microsoft Knowledge Baseの記事Q158229 「INFO: Security Ramifications for IIS Applications 」

Web サービスのセキュリティの詳細については、以下のリファレンスを参照してください。

セキュリティ一般に関する情報については、次のサイトを参照してください。


付録 A

図 3. 最適な認証方式を決定するためのフロー チャート
図 3. 最適な認証方式を決定するためのフロー チャート(画像をクリックすると拡大図が表示されます)


協力者

以下の協力者とレビューアーに深く感謝いたします。

Rob Howard、Erik Olson、Venkat Chilakala、Michael Monteiro (Sapient)、Suresh Kandula (Sapient)、Chris Brooks、Edward Jezierski、Alex Mackman、Mike Jenne、David Mowers、Amitabh Srivastava、Steve Busby、Kenny Jones。


この情報は役に立ちましたか。
(残り 1500 文字)