Web アプリケーションの実行時のセキュリティ

更新 : 2007 年 11 月

アプリケーションを配置するには、一連のセキュリティ問題に対処する必要があります。さらに、Web アプリケーション セキュリティの最も重大な問題として、アプリケーションが配置および実行されるときのセキュリティを確立する必要があります。

Web アプリケーションの性格上、ユーザーは中核的なリソース (Web サーバー) にアクセスできます。さらにユーザーは、Web サーバーを経由することによって、データベース サーバーなどの他のリソースにもアクセスできます。適切なセキュリティの方法を理解し、実装することにより、次の目的を達成できます。

• 承認されていないアクセスに対してリソースを保護します。

• ユーザーまたはロールによってアクセス レベルを制限します。

• データの整合性と機密性を確立し、ユーザーがアプリケーションを快適に使用できる比較的安全な環境を提供します。

• 制限されているリソースに対してアプリケーションがどのようにアクセスするかを制御します。

• アプリケーションのコードが正しく動作することを保証します。

このトピックでは、以上の目的を達成する方法の概要を説明し、関連するテクノロジの詳しい情報を入手できる追加のトピックへのリンクを示します。

承認されていないアクセスからアプリケーションを保護するには、次の種類のセキュリティ機能を使用します。

• 一般的な Web サーバー機能の一部として IIS に用意されているセキュリティ機能。これらの機能には、Windows ファイル、コンピュータ、およびユーザー レベルのセキュリティが含まれています。

• アプリケーション専用アクセスを提供するために ASP.NET アプリケーションに組み込むことができるセキュリティ。

ASP.NET のセキュリティ プロセス

IIS には、Web サイト用のさまざまなセキュリティ オプションが用意されています。ただし、IIS セキュリティ機構は汎用度が高く、同じ機構がすべてのアプリケーションで使用されています。アプリケーションによっては、IIS セキュリティ オプション (Windows 統合セキュリティの使用など) が有用でない場合があります。イントラネット アプリケーションにおいては Windows 統合セキュリティを使用した方が簡単です。

ASP.NET セキュリティを使用すると、アプリケーションの特定部分にアクセスできます。ASP.NET セキュリティは IIS セキュリティと連携して動作しますが、これを拡張することにより、ユーザー資格情報の取得などの機能をカスタマイズできます。

IIS はまずクライアントから要求を受け取り、IIS 管理ツールを使用してアプリケーションに確立されているセキュリティ チェックをすべて実行します。IIS の設定でアプリケーションが匿名アクセスを許可するようになっている場合、資格情報チェックは行われません。最初の認証チェック実行後、IIS は次のレベルのチェックを実行できる ASP.NET に要求を送ります。ASP.NET では、さまざまな基準を使用してアプリケーションのアクセス制限を指定し、特定のページへのアクセスを制限したり、ユーザーを指定したりできます。

認証

次の表は、ASP.NET. でサポートされる認証方法を示しています。これらのいくつかは IIS 認証と重複します。詳細については、「ASP.NET の認証」を参照してください。

フォーム認証はユーザーの認証方法に対して十分な制御を行い、ブラウザのトークンに認証を格納できるため、パブリック インターネット上の ASP.NET アプリケーション用として最も簡単に利用できます。

IIS セキュリティの詳細については、Microsoft TechNet Web サイトの「Windows Server TechCenter for IIS」でアクセス コントロールのトピックを参照してください。ASP.NET 認証の詳細については、「ASP.NET の認証」を参照してください。

Windows Server 2003 ドメイン環境のプロトコル遷移および制限された委任によるフォーム認証の使用方法の詳細については、「Kerberos Protocol Transition and Constrained Delegation」を参照してください。

承認

Web アプリケーションを実行すると、Web サーバーのリソースや、ときにはデータベースのような他のプロセスのリソースが要求されます。ASP.NET プロセスは、アプリケーションがこのようなリソースをどのように要求するかを決定する、ユーザーのコンテキストで実行されます。ASP.NET プロセスは、Windows 2000 および Windows XP Professional Edition 上で ASPNET (既定) という名前の特殊なローカル ユーザーとして実行されるか、または Windows 2003 上で ASP.NET アプリケーションのアプリケーション プールの ID (既定では、ローカル NETWORK SERVICE アカウント) として実行されます。これらのアカウントは制限付きのアクセス許可で実行されます。ASP.NET プロセスに対しては、別のユーザー コンテキストを指定できますが、この方法はお勧めしません。たとえば、アプリケーションを管理者コンテキストで実行するローカル SYSTEM アカウントや、明示的に資格情報を付与したユーザーを指定できます。

ASP.NET アプリケーションでは、いくつかのリソースに対する承認されたアクセス権を複数のユーザーに与えるように指定できます。アプリケーションが Windows 認証を使用する場合は、Windows アクセス許可を使って、サーバー上の特定のファイルやフォルダへのアクセスを承認できます。

また、URL ベースの承認を使用し、次のような基準に基づいて承認を与えたり拒否したりできます。

• ユーザーが入力する資格情報に基づく特定のユーザーまたは ID

• ロール (共通の役割または機能に基づいて複数のユーザーが特権を共有できるように定義されたエンティティ)

• 動詞 (アプリケーションの一部にアクセスするための GET や POST などの HTTP プロセス)

たとえば、すべてのユーザーが GET 動詞を実行してアプリケーションからページを取得でき、特定のユーザーだけがアプリケーションにページをポストできるように指定できます。同様に、すべてのユーザーがページを取得でき、特定のロールがポストする権利は拒否されるように指定できます。

アプリケーション全体の URL 承認を許可したり、または各ディレクトリについて個別に許可したりできます。一般的な方法としては、すべてのユーザーがパブリック ディレクトリ内のページを参照できるようにし、特定のユーザーまたはロールだけが別のディレクトリに保持された制限付きページの権限を持つようにします。

メモ :
既定では、イメージやスタイル シートなどの静的ファイルは、IIS 経由で提供される際に、ASP.NET 承認を受けません。一部のユーザーのみが静的ファイルにアクセスできるようにする場合、IIS セキュリティ機能を使用してそのファイルへのアクセスを制限できます。ASP.NET 開発サーバーを使用して ASP.NET アプリケーションをテストする場合、アプリケーションは異なる動作を示します。これは、静的ファイルが ASP.NET 承認を受け、匿名アクセスが無効になっている場合には匿名ユーザーにこれらの静的ファイルが提供されないためです。代わりに、IIS の静的ファイル名の拡張子を ASP.NET ISAPI 拡張子に割り当てると、ASP.NET の承認規則が適用されます。

詳細については、「ASP.NET の承認」および「Web アプリケーションのセキュリティに関する基本的な対策」を参照してください。

ASP.NET 構成ファイル

Web.config ファイルの設定を使用して ASP.NET セキュリティの選択を確立します。構成ファイルによって、承認および認証のセクションなど、さまざまなセキュリティ オプションの定義済み要素を含めることができます。Web.config ファイルの関連セクションは次のようになります。

<configuration>
  <system.web>
    <authentication mode="Forms">
      <forms loginUrl="login.aspx" />
    </authentication>
    <authorization>
      <deny user="?" />
    </authorization>
  </system.web>
</configuration>

アプリケーションには複数の構成ファイルを含むことができます。既定では、構成ファイルはアプリケーションのルートにあり、アプリケーション全体のセキュリティを指定します。したがって、サブフォルダはセキュリティ設定を継承します。また、各フォルダの構成ファイルを個別に作成し、そのフォルダのセキュリティ設定を作成することもできます。

詳細については、「ASP.NET のアーキテクチャ」を参照してください。

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

.asmx ファイルを使用する XML Web サービスは ASP.NET を使用する Web アプリケーションとして実行されるため、すべての ASP.NET アプリケーションと同じセキュリティ モデルとして動作します。たとえば、XML Web サービスは基本認証または Windows 統合セキュリティを使用するように設定できます。

デザイン時に XML Web サービスへの参照の追加 (XML Web サービスの探索ドキュメントの要求) を行うと、XML Web サービスは設定内容に応じて標準 Web アプリケーション認証を実行します。たとえば、XML Web サービスが基本認証を使うように設定されている場合は、要求元のクライアントにユーザー名およびパスワードを要求します。たとえば、XML Web サービスが基本認証を使用している場合は、[Web 参照の追加] ダイアログ ボックスで資格情報の入力を求めます。

XML Web サービスへの呼び出しを含むアプリケーションを構築する場合は、適切な資格情報を持っていることを確認してから呼び出しを実行しないと呼び出しは失敗します。実行時に XML Web サービスに資格情報を渡すには、XML Web サービスを表すクライアント側のオブジェクトの Credentials プロパティを設定してからメソッドを呼び出します。

ほかの ASP.NET セキュリティ オプションはあまり柔軟でない場合があるため、XML Web サービスは、SOAP ヘッダーで資格情報を渡すカスタム認証ソリューションを実装することがあります。このソリューションでは、資格情報はクライアントとサーバー間で交換されるメッセージのオプション部分で渡されます。開発者は、ヘッダーの情報を待機して認証コードを呼び出すカスタム HTTP モジュール (IHttpModule インターフェイスの実装) を書き込むことができます。

ASP.NET アプリケーションの場合と同じように、XML Web サービスは固有のロール ベースの承認を実装し、アプリケーションの特定の部分へのアクセスを制限できます。

詳細については、「XML Web サービス インフラストラクチャ」および「ASP.NET を使用して作成した XML Web サービスのセキュリティ」を参照してください。

データの整合性と機密性の確立

認証および承認によって、ユーザーの確認およびアクセス可能なリソースの指定を行うことができます。これらのセキュリティ機能の主要な目的は、承認されていない方法で Web アプリケーションが使用されないように保護することです。

ただし、セキュリティには、ユーザーの情報を保護し、機密性の高い情報をユーザーが安心してやり取りできるようにするという目的もあります。たとえば、アプリケーションがユーザーに対して、クレジット カードの番号やその他のアカウント番号、個人情報、またはユーザーにとって機密性のあるデータを要求する場合には、これらの情報を安心して入力できる方法をユーザーに提供する必要があります。

IIS の SSL (Secure Sockets Layer) を使用すると、暗号化された情報を HTTPS プロトコルを使用してやり取りできます。SSL は、ユーザーに転送される情報の暗号化、およびユーザーがアプリケーションにポストする情報の暗号化という両方向の暗号化を提供します。

SSL および暗号化の確立

SSL および暗号化を使用するには、企業または ID に対するサーバーの証明書を取得する必要があります。この証明書は、偽装できないような方法でサイトを識別するデジタル署名です。インターネットのパブリックなアプリケーションでは、既に認められているサードパーティの証明機関からサーバー証明書を取得します。プライベートなイントラネット アプリケーションでは、サーバー証明書を各自で発行できます。人事関係のサイトなどの内部アプリケーションを保護するために、サーバー証明書を発行する場合があります。

また、サーバー証明書によって、ブラウザ ユーザーとの SSL で暗号化された接続を構成できます。SSL では、公開キー暗号化方式という暗号化方式を使用します。この暗号化方式では 2 つのキーを使用します。データの暗号化に使われる公開キーと、その公開キーによって暗号化された情報の復号化に使われる非公開の秘密キーです。取得するサーバー証明書には公開キーが含まれています。ユーザーが SSL を使用する場合は、証明書と公開キーがアプリケーションからブラウザに送信されます。ブラウザとサーバーは公開キーを使用し、情報の交換を暗号化する方法を確立します。

メモ :
SSL を使用するには、ブラウザが少なくとも 40 ビットの暗号キーをサポートしている必要があります。ほとんどのブラウザはこのレベルの機能を備えています。ただし、このキー長では安全性が確保されないと考えられています。オプションで、128 ビット キーの SSL 接続のみを許可するように IIS のアプリケーションを設定できます。

いったんサーバー証明書を取得した開発者は、ユーザーに SSL の使用を指示できます。ユーザーには、プリフィックスの https:// を用いて Web ページの取得やポストを行うように指示します。Web サイトも、HTTPS 接続のみを受け入れるように IIS に設定できます。IIS およびブラウザは、自動的に、暗号化されたチャネルを使って情報を交換するようになります。

SSL の使用方法の詳細については、Microsoft Knowledge Base の文書番号 Q307267「How to: Secure XML Web Services with Secure Sockets Layer in Windows 2000」を参照してください。暗号化については、「暗号化の概要」を参照してください。証明書および SSL の設定については、Microsoft TechNet Web サイトの「Windows Server TechCenter for IIS」を参照してください。

.NET コード セキュリティの使用

セキュリティの目的の 1 つとして、アプリケーションのコードが不適切なコンテキストで誤って実行された場合や、悪意を持った方法で使用された場合に、コードの誤用を確実に回避できる対策を実行する必要があります。ASP.NET は .NET Framework の一部であるため、コード アクセス セキュリティを利用して、コードの実行許可を確立することもできます。詳細については、「コード アクセス セキュリティ」を参照してください。

参照

概念

Web アプリケーションのセキュリティに関する基本的な対策