計画手順 4: アプリケーション セキュリティを計画する

作成者: Keith Newman および Robert McMurray

Web サイトを構築するこのフェーズでは、ASP.NET アプリケーションのセキュリティのニーズを検討します。 以下のセクションでは、IIS 8 で利用できるアプリケーションのセキュリティの設定について説明します。

4.1. Web アプリケーションの分離

Web アプリケーションのセキュリティを向上させるために最も効果的な方法の 1 つは、Web サーバー上の他のアプリケーションから分離することです。 アプリケーション プールには、要求を処理してアプリケーション コードを実行する独自のワーカー プロセスがあります。 ワーカー プロセスにはセキュリティ ID (SID) が含まれます。 また、各アプリケーション プールには、一意のアプリケーション プール ID が含まれます。 既定では、Web アプリケーションを作成すると、アプリケーションと同じ名前の新しいアプリケーション プールも作成されます。 Web アプリケーションを異なるアプリケーション プールで維持すれば、アプリケーションを互いに分離できます。

Web アプリケーションの分離には、次のことが含まれます。

• サイトの分離: 異なるアプリケーションを、異なるアプリケーション プールを使用する異なるサイトに分離します。
• 最小限の特権: ワーカー プロセスを、サイトごとに固有の低特権の ID (仮想アプリケーション プール ID) として実行します。
• 一時的な分離: サイトごとに個別の ASP.NET 一時フォルダーを設定し、アクセスを適切なプロセス ID のみに許可します。
• コンテンツの分離: 各サイト ルートで ACL (アクセス制御リスト) を設定し、アクセスを適切なプロセス ID のみに許可します。

4.2. .NET 信頼レベル

アプリケーションの "信頼レベル" により、ASP.NET コード アクセス セキュリティ (CAS) ポリシーが与えるアクセス許可が決まります。 CAS は、完全な信頼と部分信頼という 2 つの信頼カテゴリを定義します。 完全な信頼アクセス許可を持つアプリケーションは、サーバー上のすべてのリソースの種類にアクセスし、特権操作を実行できます。 完全な信頼を持つアプリケーションは、オペレーティング システムのセキュリティの設定の影響のみを受けます。

部分信頼 Web アプリケーションは、完全な信頼を持たず、コード アクセス許可のセットが制限されているアプリケーションです。 その結果、部分信頼のアプリケーションは、セキュリティで保護されたリソースにアクセスしたり、その他の特権操作を実行したりする能力が制限されています。 部分信頼アプリケーションでは特定のアクセス許可が拒否されるため、それらのアクセス許可を必要とするリソースに直接アクセスすることはできません。 他のアクセス許可は制限された方法で許可されるので、それらのアクセス許可を必要とするリソースにはアクセスできる場合がありますが、方法は限られます。 たとえば、制限されたファイル IO アクセス許可では、アプリケーションはファイル システムにアクセスできますが、できるのはアプリケーションの仮想ディレクトリ ルートの下にあるディレクトリだけです。

Web アプリケーションまたは Web サービスを部分信頼として構成することにより、重要なシステム リソースまたは他の Web アプリケーションに属するリソースにアクセスするアプリケーションの機能を制限できます。 アプリケーションが必要とするアクセス許可のみを付与することで、最小限の特権を持つ Web アプリケーションを構築し、Web アプリケーションがコード インジェクション攻撃を受けた場合の潜在的な損害を抑えることができます。

次の一覧は、各信頼レベルに関連付けられている制限を示しています。

• 完全な信頼のアプリケーションは、すべてのリソースの種類に無制限にアクセスし、特権操作を実行することができます。
• 高、中、低、または最低限の信頼のアプリケーションは、アンマネージド コードまたはサービス コンポーネントの呼び出し、イベント ログへの書き込み、メッセージ キューのキューへのアクセス、または OLE DB データ ソースへのアクセスを行うことができません。
• 高信頼のアプリケーションは、ファイル システムに無制限にアクセスできます。
• 中信頼のアプリケーションは、ファイル システムへのアクセスが制限されており、自分のアプリケーション ディレクトリ階層内のファイルにのみアクセスできます。
• 低または最低限の信頼のアプリケーションは、SQL Server データベースにアクセスできません。
• 最低限の信頼のアプリケーションは、いずれのリソースにもアクセスできません。

4.3. .NET 認証

認証を使うと、サイトおよびアプリケーションへのアクセスを要求するクライアントの ID を確認できます。 認証が有効な場合、IIS 8 はユーザーによって指定されたアカウント資格情報を使って、ユーザーに付与されているアクセス許可とユーザーがアクセスできるリソースを決定します。

このセクションでは、ASP.NET アプリケーションに固有の認証モードについて説明します。

1. ASP.NET フォーム認証
2. ASP.NET 偽装認証

ASP.NET フォーム認証

フォーム認証では、クライアント側リダイレクトを使用して、認証されていないユーザーを、資格情報 (通常は、ユーザー名とパスワード) を入力できる HTML フォームに転送します。 資格情報が有効であることが確認されると、ユーザーは最初に要求したページにリダイレクトされます。 フォーム認証では、多くの場合、サーバーとクライアント ブラウザーの間でユーザーの資格情報を渡すために Cookie が使われます。

次のセクションでは、サイトにフォーム認証を追加する計画を立てるために知っておく必要のあることについて説明します。

1. フォーム認証の基本
2. 認証 Cookie

フォーム認証の基本

ASP.NET フォームベースの認証は、多くの要求を受信するパブリック Web サーバー上のサイトまたはアプリケーションに適しています。 この認証モードを使うと、オペレーティング システムが提供する認証メカニズムに依存するのではなく、アプリケーション レベルでクライアントの登録と認証を管理できます。

フォーム認証では、ユーザーは ASP.NET メンバーシップ データベースの ID を使ってログオンできます。 この認証方法では、HTML ログオン ページへのリダイレクトを使ってユーザーの ID を確認します。 フォーム認証は、サイト レベルまたはアプリケーション レベルで構成できます。

フォーム認証は、次の理由で便利です。

• SQL サーバー データベースなどのカスタム データ ストアまたは Active Directory のいずれかを認証に使用できます。
• Web ユーザー インターフェイスと簡単に統合できます。
• クライアントは任意のブラウザーを使用できます。

認可にメンバーシップのロールを使う場合は、フォーム認証または同様のカスタム認証方法を使います。

既定では、フォーム認証のログイン URL は Login.aspx です。 サイトまたはアプリケーションにアクセスするクライアント用に独自のログイン ページを作成できます。 たとえば、訪問者から特定の情報を収集したり、サイト上の選んだページまたは選んだアプリケーションにメンバーシップを提供したりできます。

フォーム認証の既定のタイムアウト値は 30 分です。 セッションの有効期間を短くして Cookie 再生攻撃を受けにくくするために、タイムアウト値をより短い期間に変更することを検討してください。

認証 Cookie

認証 Cookie は、クライアントがアプリケーションの一部またはすべてのページにアクセスできることを確認するためのトークンとして使われます。 これに対し、個人用設定 Cookie には、特定のサイトまたはアプリケーションでのユーザー エクスペリエンスを決定するユーザー固有の設定が含まれています。

重要: 認証 Cookie はクライアントとサーバーの間ですべての要求と共に渡されるため、Secure Sockets Layer (SSL) を使って常に認証 Cookie をセキュリティで保護してください。 SSL の詳細については、4.5.TLS/SSL 通信を参照してください。

Cookie はリダイレクトの必要がないため、サイトへの訪問者を追跡する方法としては、クエリ文字列よりも効率的です。 ただし、これらはブラウザーに依存しており、一部のブラウザーではその使用がサポートされていません。 さらに、一部のユーザーはブラウザーで Cookie のサポートを無効にしているので、Cookie ベースの認証を使用するのは必ずしも効果的とは限りません。

既定では、ASP.NET アプリケーションの Cookie 名は .ASPXAUTH です。 ただし、代わりに、アプリケーションごとに一意の Cookie 名とパスを使うこともできます。 これを行うことで、1 つのアプリケーションに対して認証されたユーザーが、Web サーバー上の他のアプリケーションに対して認証されないようにすることができます。

サイトまたはアプリケーションに対して、次のいずれかの Cookie モードを選択できます。

Cookie 保護モードは、フォーム認証 Cookie が特定のアプリケーションに対して実行する機能を定義します。 次の表は、定義できる Cookie 保護モードを示しています。

クライアントが頻繁に要求するオブジェクトがアプリケーションに含まれる場合は、これらのオブジェクトをキャッシュすることによってアプリケーション パフォーマンスを向上させます。 認証 Cookie がタイムアウトになる前に、キャッシュされたオブジェクトにユーザーがアクセスした場合、IIS 8 では、キャッシュされたオブジェクトをキャッシュ内に保持できるようになり、タイマーがリセットされます。 ただし、その間ユーザーがキャッシュされたオブジェクトにアクセスしない場合、IIS 8 はキャッシュされたオブジェクトをキャッシュから削除します。

次の状況では、この設定を有効にすることを検討してください。

• キャッシュに使用可能なメモリ量が限られている場合。
• キャッシュする必要があるオブジェクトが多数ある場合。この設定では、頻繁に要求されたオブジェクトのみがキャッシュに残されます。

ASP.NET 偽装認証

ASP.NET アプリケーションの既定のセキュリティ コンテキストとは異なるセキュリティ コンテキストで ASP.NET アプリケーションを実行する場合は、ASP.NET 偽装を使います。

ASP.NET アプリケーションの偽装を有効にすると、そのアプリケーションは 2 つの異なるコンテキスト (IIS 8 によって認証されたユーザーとして、または設定した任意のアカウントとして) のいずれかで実行できます。 たとえば、匿名認証を使い、認証されたユーザーとして ASP.NET アプリケーションを実行することを選んだ場合、アプリケーションは匿名ユーザー用に設定されたアカウント (通常は IUSR) で実行されます。 同様に、アプリケーションを任意のアカウントで実行するように選択している場合は、そのアカウント用にセットアップされたセキュリティ コンテキストでアプリケーションが実行されます。

既定では、ASP.NET 偽装は無効です。 偽装を有効にすると、ASP.NET アプリケーションは、IIS 8 によって認証されたユーザーのセキュリティ コンテキストで実行されます。

4.4. マシン キーの設定

マシン キーでは、フォーム認証 Cookie データとページ レベルのビュー状態データを保護できます。 また、アウトプロセス セッション状態の ID も検証します。 ASP.NET は次の種類のマシン キーを使います。

• "検証キー" は、メッセージ認証コード (MAC) を計算してデータの整合性を確認します。 このキーは、フォーム認証 Cookie または特定のページのビュー状態に追加されます。
• "暗号化解除キー" は、フォーム認証チケットとビュー状態の暗号化と暗号化解除に使われます。

IIS 8 では、検証と暗号化の設定を構成し、ビュー状態、フォーム認証、メンバーシップ、ロール、匿名 ID などの ASP.NET アプリケーション サービスで使うマシン キーを生成することができます。

アプリケーションのマシン キーを生成する前に、次の設計上の決定を行います。

• 使用する検証方法を決定します: AES、MD5、SHA1 (既定値)、TripleDES、HMACSHA256、HMACSHA384、または HMACSHA512。
• 使用する暗号化方法を決定します: 自動 (既定値)、AES、TripleDES、または DES。
• 実行時に検証キーを自動的に生成するかどうかを決定します。
• アプリケーションごとに一意の検証キーを生成するかどうかを決定します。
• 実行時に、暗号化解除キーを自動的に生成するかどうかを決定します。
• アプリケーションごとに一意の暗号化解除キーを生成するかどうかを決定します。

4.5. TLS/SSL 通信

トランスポート層セキュリティ (TLS) とその前身である Secure Sockets Layer (SSL) は、Web サイトに通信セキュリティを提供するプロトコルです。 TLS/SSL を使用すると、サーバーとクライアントを認証することができ、その後は認証済みの関係者間で送受信されるメッセージを暗号化することもできます。

認証プロセスでは、TLS/SSL クライアントから TLS/SSL サーバーにメッセージが送信され、サーバーはサーバー自体の認証に必要な情報を使用してそれに応答します。 クライアントとサーバーは、さらにセッション キーの交換を実行し、認証のやり取りが終了します。 認証が完了すると、認証プロセス中に確立された対称暗号化キーを使って、サーバーとクライアントの間で SSL で保護された通信を開始できます。

Web サイトの TSL/SSL を構成するには、次の手順に従います。

1. 証明機関 (CA) からサーバー証明書を取得します。 「サーバー証明書」を参照してください。
2. サイトに SSL バインドを追加します。 「SSL バインド」を参照してください。
3. サイトで SSL を必須にするように IIS を設定します。 「サイトで SSL を必須にする」を参照してください。
4. サイトにクライアント証明書を使うことを検討してください。 「クライアント証明書」を参照してください。

サーバー証明書

サーバー証明書は、証明機関 (CA) から取得できます。 証明機関からのサーバー証明書の取得は、Secure Sockets Layer (SSL) またはトランスポート層セキュリティ (TLS) の構成における 1 つの手順です。 サーバー証明書はサード パーティの CA から取得できます。 サード パーティの CA は、証明書を発行する前に身元証明を提供するよう要求する場合があります。 また、Microsoft 証明書サービスなどのオンライン CA を使って、独自のサーバー証明書を発行することもできます。

デジタル証明書は、ユーザーまたはコンピューターの ID を検証するためにオンライン パスワードのように動作する電子ファイルです。 これらは、クライアント通信に使われる SSL 暗号化チャネルを作成するために使われます。 証明書とはデジタル ステートメントであり、証明書所有者の身元を保証し、当事者が暗号化を使ってセキュリティで保護された方法で通信できるようにする証明機関 (CA) によって発行されます。

デジタル証明書は次のことを行います。

• 所有者 (ユーザー、Web サイト、さらにはルーターなどのネットワーク リソース) が、主張しているとおりの人物またはものであることを認証します。
• オンラインでやり取りされるデータを盗難や改ざんから保護します。

デジタル証明書は、証明書サービスを使って、信頼できるサード パーティ CA または Microsoft Windows 公開キー基盤 (PKI) によって発行されます。または、自己署名することもできます。 証明書の種類ごとに長所と短所があります。 それぞれの種類のデジタル証明書は改ざん防止機能があり、偽造することはできません。

証明書はさまざまな用途に発行できます。 これらの用途には、Web ユーザー認証、Web サーバー認証、Secure/Multipurpose Internet Mail Extensions (S/MIME)、インターネット プロトコル セキュリティ (IPsec)、トランスポート層セキュリティ (TLS)、コード署名などがあります。

証明書には公開キーが含まれており、対応する秘密キーを保有するユーザー、コンピューター、またはサービスの ID にその公開キーを結合します。 公開キーと秘密キーはクライアントとサーバーで使われ、送信する前にデータを暗号化します。 Windows ベースのユーザー、コンピューター、サービスの場合、信頼されたルート証明書ストアにルート証明書のコピーがあり、その証明書に有効な証明書パスが含まれている場合、CA への信頼が確立されます。 証明書が有効であるためには、証明書が失効しておらず、証明書の期限が切れていない必要があります。

SSL バインド

異なる目的を提供する、または異なるプロトコルを使う必要があるサイト コンテンツがある場合は、サイトに複数のバインドを割り当てることができます。 たとえば、コマース サイトには、商品を購入するためにユーザーがアカウントにログオンすることを求めるアプリケーションが含まれている場合があります。 企業は HTTP 経由でサイトをホストしていますが、ユーザーは HTTPS ページで自分のアカウントにログオンする必要があります。 この例では、サイトには 2 つのバインドがあり、1 つは HTTP 部分用、もう 1 つは HTTPS 部分用です。

そのままでは、IIS マネージャーを使って HTTP と HTTPS 以外のプロトコルのバインドを追加することはできません。 Windows Communication Foundation (WCF) でサポートされているプロトコルなど、別のプロトコルのバインドを追加する場合は、その他のいずれかの管理ツールを使います。 ただし、IIS ファイル転送プロトコル (FTP) サーバーをインストールすると、IIS マネージャーを使って FTP バインドを追加できます。 また、UI を拡張する他のモジュールやサード パーティの機能をダウンロードできる場合もあります。

サイトで SSL を必須にする

Secure Sockets Layer (SSL) 暗号化は、クライアントとサーバー間で送信される機密情報や個人情報をセキュリティで保護します。 SSL が有効な場合、リモート クライアントは https:// で始まる URL を使ってサイトにアクセスします。

まずサーバー証明書を構成し、HTTPS バインドを作成して SSL 設定を有効にします。 その後、次のような状況で Secure Sockets Layer (SSL) 暗号化を必須にします。

1. サーバー上の機密コンテンツまたは個人コンテンツを暗号化されたチャネルで保護する必要がある場合。
2. ユーザーが個人情報を送信する前にサーバーの ID を確認できるようにする場合。
3. クライアント証明書を使って、サーバーにアクセスするクライアントを認証する場合。

クライアント証明書

クライアントが Web サーバー上のコンテンツにアクセスする前に ID を検証するようにする場合は、クライアント証明書を構成します。 既定では、クライアント証明書は無視されます。

Web サイトでクライアント証明書を構成する前に、サーバー証明書を構成し、HTTPS バインドを作成して Secure Sockets Layer (SSL) の設定を有効にします。

すべてのクライアントの ID を検証する場合は、クライアント証明書が必須であることを指定します。 一部のクライアントで、最初に ID を検証せずにコンテンツへのアクセスを可能にする場合は、クライアント証明書を受け入れるように指定します。