セキュリティ保護された ASP.NET アプリケーションの構築 : 認証、認定、および通信のセキュリティ保護 第 6 章 エクストラネット セキュリティ

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

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

適用対象:
    Microsoft® ASP.NET

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

要約 : この章では、一般的なエクストラネット アプリケーション シナリオをセキュリティで保護する方法について説明します。シナリオごとに、それぞれの特徴を示したうえで、セキュリティ対策として必要な設定について説明していきます。また、各シナリオの「分析」には、追加情報を挙げてあります。

目次

Web サービスの公開
Web アプリケーションの公開
まとめ

エクストラネット アプリケーションとは、2 つの企業または部門にまたがってリソースやアプリケーションを共有するアプリケーションをいいます。こうしたアプリケーションやリソースはインターネットに対して公開されます。エクストラネット アプリケーションに関する主要な課題の 1 つは、両方の当事者が納得できる認証方法を作成することです。こうした環境で使用可能な認証方法は限られてきます。場合によっては、既存の認証メカニズムと連携できることが条件となるからです。

エクストラネット アプリケーションの一般的な特徴は以下のとおりです。

• ユーザー アカウントに対してインターネット シナリオの場合より厳しい管理が必要となります。
• ユーザー アカウントに対する信頼レベルは、インターネットから利用されるアプリケーションの場合より高くなります。

この章では、以下のシナリオを使用し、認証、認定、通信のセキュリティ保護の推奨テクニックについて説明します。

• Web サービスの公開
• Web アプリケーションの公開

Web サービスの公開

ある企業とそのパートナー企業のデータ交換シナリオについて検討します。この場合、発行元企業がインターネット上でサービスを発行、販売します。この企業は、限定したパートナー企業に対し、Web サービスを使用して情報を公開します。各パートナー企業のユーザーは、社内のイントラネット ベースの Web アプリケーションを使用して Web サービスにアクセスします。このシナリオを図 6.1 に示します。

図 6.1 エクストラネットによる Web サービス企業とパートナー企業のデータ交換

特徴

このシナリオには次のような特徴があります。

• 発行元企業は、インターネット上で Web サービスを公開します。
• 発行元は、(個人ユーザーではなく) パートナー企業の資格情報 (X.509 クライアント証明書) を確認し、リソースへのアクセスを許可します。発行元は、パートナー企業における個々のユーザーのログインについて関知する必要はありません。
• クライアント証明書は、発行元企業側で Active Directory? ディレクトリ サービスのアカウントにマップされます。
• エクストラネットには、企業内の Active Directory とは別の Active Directory があります。エクストラネットの Active Directory は固有のフォレスト内にあり、独自の信頼関係エリアを形成します。
• Web サービス認定は、マップされた Active Directory アカウントに基づいて行います。各企業に固有の Active Directory アカウントで表されるパートナー企業 ID に基づく認定プロセスを使用することもできます。
• データベース アクセスには、ASP.NET Web サービス プロセス ID に対応する単一の信頼関係接続を使用します。
• Web サービスから取得されるデータは機密データであるため、転送中 (発行元企業の内部およびインターネット上) はセキュリティで保護する必要があります。

このシナリオのセキュリティ対策

このシナリオでは、各パートナー企業の内部 Web アプリケーションが Web サービスを使用して発行元企業からデータを取得し、ユーザーに提供します。発行元には、パートナー企業を認証するセキュリティ メカニズムが必要ですが、パートナー企業の各ユーザー ID の使用は、そのセキュリティ メカニズムでは適切ではありません。

2 つの企業がインターネットを介して交換するデータは機密性が高いため、転送時には SSL を使用して保護する必要があります。

エクストラネット パートナー企業の IP アドレスからの着信接続のみを許可するファイアウォールを使用して、それ以外の不正なインターネット ユーザーが Web サービス サーバーに接続するのを防止します。

表 6.1 セキュリティ対策

分類	詳細
認証	パートナー アプリケーションでは、Web サービスへの各要求にクライアント証明書を使用します。 パートナー企業からのクライアント証明書は、個々の Active Directory アカウントにマップされます。 データベースでは Windows® 認証を使用します。接続には ASP.NET Web サービス プロセス ID を使用します。データベースは Web サービスを信頼します。
認定	Web サービスはロール ベースの .NET 認証を使用して、Active Directory アカウントが Partner グループのメンバであるかどうかチェックします。
セキュリティで保護された通信	パートナー企業の Web アプリケーションと発行元の Web サービスとの通信は、SSL を使用して保護します。 Web サービスとデータベースとの通信は、IPSec を使用して保護します。

結果

このシナリオの推奨セキュリティ構成を図 6.2 に示します。

図 6.2 エクストラネットによる Web サービス企業とパートナー企業のデータ交換シナリオの推奨セキュリティ構成

セキュリティ構成の設定

作業を始める前に、以下のドキュメントを参照してください。

• カスタム ASP.NET アカウントの作成 (このガイドの「パート IV : 参照」の「 ASP.NET の実行に使用するカスタム アカウントの作成方法」を参照)
• 最低限の特権を持つデータベース アカウントの作成 (「第 12 章 データ アクセス セキュリティ」を参照)
• Web サーバーにおける SSL の構成 (このガイドの「パート IV : 参照」の「Web サーバー上で SSL を設定する方法」を参照)
• IPSec の構成 (このガイドの「パート IV : 参照」の「2 つのサーバー間の通信を IPSec で保護する方法」を参照)
• ファイアウォールを使用した環境での IPSec の設定 (Microsoft サポート技術情報の Knowledge Base の文書 233256「How to Enable IPSec Traffic Through a Firewall」を参照)
• SSL を使用した Web サービスの呼び出し (このガイドの「パート IV : 参照」の「SSL を使用して Web サービスを呼び出す方法」を参照)。このソリューション テクニックはパートナー企業において必要です。

パートナー アプリケーションの構成

この章では、パートナー アプリケーションとそのセキュリティ構成については詳しく扱いません。ただし、パートナー アプリケーションと Web サービスとの通信を円滑にするには、以下の点について考慮する必要があります。

• パートナー企業の Web アプリケーションでは、内部ユーザーの認証および認定を可能にする認証メカニズムを選択できます。内部ユーザーは、それ以上の認証を受けるために Web サービスまで送られることはありません。
• パートナー企業の Web アプリケーションがユーザーに代わって Web サービスを呼び出します。ユーザーが直接 Web サービスを呼び出すことはできません。
• パートナー企業の Web アプリケーションは、クライアント証明書を使用して、Web サービスに対してクライアントの身元を証明します。
• パートナー アプリケーションが ASP.NET Web アプリケーションである場合、そのアプリケーションは中間アウト プロセス コンポーネント (Enterprise Services アプリケーションまたは Windows サービス) を使用して、証明書を読み込み、Web サービスに渡す必要があります。
  この処理が必要となる理由と実行方法の詳細については、このガイドの「パート IV : 参照」の「ASP.NET からのクライアント証明書を使用して Web サービスを呼び出す方法」を参照してください。

エクストラネット Web サーバーの構成

IIS の構成
手順	詳細情報
Web サービスの仮想ルート ディレクトリに対する匿名アクセスを無効にします。	IIS 認証を使用するためには、IIS MMC スナップインを使用します。アプリケーションの仮想ディレクトリを右クリックして [プロパティ] をクリックします。 [ディレクトリ セキュリティ] タブをクリックし、[匿名アクセスおよび認証コントロール] 内の [編集] をクリックします。
Web アプリケーションおよび Web サービスの仮想ルートの証明書認証を有効にします。	このガイドの「パート IV : 参照」の「Web サーバー上で SSL を設定する方法」を参照してください。 このガイドの「パート IV : 参照」の「ASP.NET からのクライアント証明書を使用して Web サービスを呼び出す方法」を参照してください。
Active Directory (エクストラネット) の構成
手順	詳細情報
パートナー企業の Active Directory アカウントを設定します。	エクストラネット固有の Active Directory を使用します。この Active Directory は固有のフォレストにあり、社内の Active Directory とは完全に分離します。
証明書のマッピングを構成します。	Microsoft TechNet の「Step-by-Step Guide to Mapping Certificates to User Accounts」(英語情報) を参照してください。 また、Microsoft サポート技術情報の Knowledge Base の文書 313070「[HOWTO] IIS (Internet Information Services) 5.0 でクライアント証明書のマッピングを構成する方法」も参照してください。
ASP.NET (Web サービス) の構成
手順	詳細情報
ASP.NET Web サービスを Windows 認証として構成します。	Web サービスの仮想ルート ディレクトリにある Web.config を開きます。 SQL Server の構成 手順 詳細情報 Microsoft SQL Server® を実行するコンピュータ上に、Web サービスを実行するために使用する ASP.NET プロセス アカウント (既定のアカウントは ASPNET) と一致する Windows アカウントを作成します。 ユーザー名とパスワードは ASP.NET プロセス アカウントと同じでなければなりません。 このアカウントには以下の特権を与えます。 - このコンピュータにネットワークからアクセスする。 - ログオンをローカルで拒否する。 - バッチ ジョブとしてログオンする。 SQL Server を Windows 認証として構成します。 　 ASPNET アカウントの SQL Server ログインを作成します。 これにより、SQL Server へのアクセス権を付与します。 新しいデータベース ユーザーを作成し、そのユーザーにログイン名をマップします。 これにより、指定したデータベースへのアクセス権を付与します。 データベース内に新しいユーザー定義のデータベース ロールを作成し、そのロールにデータベース ユーザーを割り当てます。 　 このデータベース ロールのデータベース アクセス権を設定します。 最低限のアクセス許可を割り当てます。 「第 12 章 データ アクセス セキュリティ」を参照してください。 セキュリティで保護された通信の構成 手順 詳細情報 Web サーバー上の Web サイトを SSL に対応するように構成します。 このガイドの「パート IV : 参照」の「Web サーバー上で SSL を設定する方法」を参照してください。 Web サーバーとデータベース サーバーの間に IPSec を構成します。 このガイドの「パート IV : 参照」の「2 つのサーバー間の通信を IPSec で保護する方法」を参照してください。 分析 Web サーバー上の ASP.NET は最低限の特権を持つローカル アカウント (既定の ASPNET アカウント) で実行されるため、不正アクセスによる潜在的な損害は緩和されます。 パートナー企業の ASP.NET Web アプリケーションは、Windows 統合認証を使用し、Web サービスにアクセスできるユーザーを認定します。 パートナー企業の ASP.NET Web アプリケーションは、中間 Enterprise Services アプリケーションを使用して、クライアント証明書を取得し、Web サービスを呼び出します。 発行元企業は、証明書に含まれているパートナーの組織名を使用して、IIS 内で証明書のマッピングを実行します。 Web サービスは、マップされた Active Directory アカウントを使用して、PrincipalPermission 要求と .NET ロール チェックに基づいて認定を実行します。 SQL Server の認証方法を Windows 認証に設定することによって、資格情報は Web サーバーに保存されず、内部ネットワークを介して SQL Server に送信されることもありません。SQL 認証を使用する場合は、アプリケーション内とネットワークでの転送中に、ユーザー名とパスワードを含む接続文字列をセキュリティで保護することが重要です。接続文字列を保存するときには、DPAPI を使用するか、「第 12 章 データ アクセス セキュリティ」で説明するセキュリティで保護された保存戦略からいずれかの戦略を選択します。Web サービスとデータベースの間で転送される接続文字列 (および機密性のあるアプリケーション データ) を保護するには、IPSec を使用します。 パートナー企業と Web サービスの間に構成された SSL は、インターネットを介して転送されるデータを保護します。 Web サービスとデータベースの間に IPSec を構成すると、社内ネットワーク上のデータベースとの間でやりとりされるデータが保護されます。パートナー企業と発行元企業がプライベート ネットワークを使用して通信を行う場合には、IPSec を使用して、通信をセキュリティで保護するだけでなく、コンピュータ認証を実行することもできます。 注意点 データベース サーバー上の重複するローカル Windows アカウント (IIS のローカル ASPNET プロセス アカウントと一致するアカウント) を使用すると、管理の負担が増加します。パスワードの更新および同期を手動で定期的に行う必要があります。 .NET ロール ベースのセキュリティは Windows グループのメンバシップを基礎とするため、このソリューションでは、Windows グループがアプリケーションにアクセスするユーザーの分類に対応するレベルまで細分化されていることが必要となります。このシナリオでは、Active Directory アカウントは Partner グループのメンバでなければなりません。 Q&A データベース側は最初の呼び出し元が誰であるのかを認識しません。監査の軌跡は、どのように作成するのですか。 Web サービスにおけるエンド ユーザー (パートナー企業) の操作を監査します。ストアド プロシージャのパラメータを使用して、パートナー企業の ID をアプリケーション レベルでデータベースに渡します。 関連シナリオ 発行元企業は、雑誌や新聞の記事など、機密性のないデータを発行する場合もあります。その場合、発行元はパートナー企業がそうしたデータを Web サービスから取得できるように、各パートナーに一意のユーザー名とパスワードを割り当てることができます。 こうした場合には、発行元の Web サイトを基本認証でユーザーを認証するように構成します。パートナー アプリケーションは、与えられたユーザー名とパスワードを使用して、Web サービス プロキシ用の資格情報を明示的に設定します。 詳細情報 Web サービス プロキシの設定の詳細については、「第 10 章 Web サービス セキュリティ」を参照してください。 Web アプリケーションの公開 このシナリオでは、発行元企業は、そのアプリケーションをインターネットから使用する排他的なアクセス権をパートナーに与えることによって、パートナー ポータル アプリケーションを提供します。これによって、サービスの販売、最新の製品情報の提供、オンライン共同作業などが可能になります。このシナリオを図 6.3 に示します。 図 6.3 パートナー ポータル シナリオ シナリオの特徴 このシナリオには次のような特徴があります。 パートナー企業の Web アプリケーションは、フォーム ログイン ページを使用して資格情報を受け取るか、IIS の基本認証を使用してログイン ダイアログを表示します。 資格情報は、エクストラネット境界ネットワーク (別名 DMZ、"非武装地帯"、または "スクリーンド サブネット") 内の Active Directory との照合によって検証されます。エクストラネットの Active Directory は固有のフォレスト内にあり、独自の信頼関係境界を形成します。 データベース アクセスには、ASP.NET Web アプリケーション プロセス ID に対応する単一の信頼関係接続を使用します。 Web アプリケーション認証は、GenericPrincipal オブジェクト (フォーム認証プロセスにおいて作成) または WindowsPrincipal オブジェクト (基本認証を使用した場合) に基づいて実行されます。 Web アプリケーションから取得されるデータは機密性が高いため、転送中 (発行元企業の内部およびインターネット上) はセキュリティで保護する必要があります。 このシナリオのセキュリティ対策 2 つの企業がインターネットを介して交換するデータは機密性が高いため、転送時には SSL を使用して保護する必要があります。 エクストラネット パートナー企業の IP アドレスからの着信接続のみを許可するファイアウォールを使用して、それ以外の不正なインターネット ユーザーが Web サーバーに接続するのを防止します。 表 6.2 セキュリティ対策 分類 詳細 認証 パートナー企業内のユーザーは、Web アプリケーションにおいて、エクストラネット Active Directory との照合による基本認証またはフォーム認証によって認証されます。 データベースでは Windows 認証を使用します。接続には ASP.NET Web アプリケーション プロセス ID を使用します。データベースは Web アプリケーションを信頼します。 認定 Web アプリケーションは、.NET ロール ベースの認定を使用して、認証されたユーザーが Partner グループのメンバであるかどうかチェックします。なお、このユーザーは、フォーム認証の場合は GenericPrincipal オブジェクトで、基本認証の場合は WindowsPrincipal オブジェクトで表されます。 セキュリティで保護された通信 パートナー企業の Web ブラウザと発行元の Web アプリケーション間の通信は、SSL を使用して保護します。 Web アプリケーションとデータベースとの通信は、IPSec を使用して保護します。 結果 このシナリオの推奨セキュリティ構成を図 6.4 に示します。 図 6.4 パートナー ポータル シナリオの推奨セキュリティ構成 エクストラネット Web サーバーの構成 IIS の構成 手順 詳細情報 フォーム認証を使用する場合は、Web アプリケーションの仮想ルート ディレクトリで匿名アクセスを有効にします。 または 基本認証を使用する場合は、匿名アクセスを無効にし、基本認証を選択します。 　 Active Directory (エクストラネット) の構成 手順 詳細情報 パートナー ユーザーの Active Directory アカウントを作成します。 エクストラネットの Active Directory を使用します。この Active Directory は固有のフォレストにあり、社内の Active Directory とは完全に分離されています。 ASP.NET の構成 手順 詳細情報 ASP.NET Web アプリケーションを Windows 認証として構成します (IIS 基本認証の場合)。 または ASP.NET をフォーム認証を使用するように構成します。 Web サービスの仮想ルート ディレクトリにある Web.config を開きます。 要素を次のどちらかに設定します。 ``` ``` または ``` ``` ASPNET アカウント (ASP.NET を実行するために使用するアカウント) のパスワードを既知の方法による強力なパスワードに変更します。 これによって、同じユーザー名とパスワードを持つ複製されたローカル アカウントをデータベース サーバーに作成できます。この作業が必要なのは、ASPNET アカウントが Windows 認証を使用して接続するときにデータベース サーバーからのネットワーク認証チャレンジに応答できるようにするためです。 もう 1 つの方法として、最低限の特権を持つドメイン アカウントを使用することもできます (ファイアウォールを通過する Windows 認証が可能な場合)。 詳細については、「第 8 章 ASP.NET セキュリティ」の「ASP.NET のプロセス ID」を参照してください。 %windir%\Microsoft.NET\Framework\v1.0.3705\CONFIG にある Machine.config を開きます。 SQL Server の構成 手順 詳細情報 SQL Server コンピュータ上に、Web サービスを実行するために使用する ASP.NET プロセス アカウント (既定のアカウントは ASPNET) と一致する Windows アカウントを作成します。 ユーザー名とパスワードは ASP.NET プロセス アカウントと同じでなければなりません。 このアカウントには以下の特権を与えます。 - このコンピュータにネットワークからアクセスする。 - ログオンをローカルで拒否する。 - バッチ ジョブとしてログオンする。 SQL Server を Windows 認証として構成します。 　 ASPNET アカウントの SQL Server ログインを作成します。 これにより、SQL Server へのアクセス権を付与します。 新しいデータベース ユーザーを作成し、そのユーザーにログイン名をマップします。 これにより、指定したデータベースへのアクセス権を付与します。 データベース内に新しいユーザー定義のデータベース ロールを作成し、そのロールにデータベース ユーザーを割り当てます。 　 このデータベース ロールのデータベース アクセス許可を設定します。 最低限のアクセス許可を割り当てます。 「第 12 章 データ アクセス セキュリティ」を参照してください。 セキュリティで保護された通信の構成 手順 詳細情報 Web サーバー上の Web サイトを SSL に対応するように構成します。 このガイドの「パート IV : 参照」の「Web サーバー上で SSL を設定する方法」を参照してください。 Web サーバーとデータベース サーバーの間に IPSec を構成します。 このガイドの「パート IV : 参照」の「2 つのサーバー間の通信を IPSec で保護する方法」を参照してください。 分析 Web サーバー上の ASP.NET は最低限の特権を持つローカル アカウント (既定の ASPNET アカウント) で実行されるため、不正アクセスによる潜在的な損害は緩和されます。 ブラウザと Web アプリケーションの間に SSL を構成して、フォーム認証または基本認証で使用する資格情報を保護します (資格情報は、どちらの認証方法でもクリア テキストで転送されます。ただし、基本認証では Base64 エンコードが使用されます)。SSL では、Web アプリケーションから返されるアプリケーション固有のデータも保護されます。 フォーム認証では、ログオン ページだけでなく、すべてのページで SSL を使用し、最初の認証以降すべての Web 要求で渡される認証 Cookie を保護します。 最初のログオン ページだけで SSL を使用し、認証で使用される資格情報を暗号化する場合には、Cookie に含まれるフォーム認証チケットを保護する必要があります。フォーム認証チケットは、最初の認証以降に Web 要求が発行されるたびに、クライアントとサーバーの間で転送されるからです。フォーム認証チケットを暗号化するには、<forms> 要素の protection 属性を次のように構成し、FormsAuthentication クラスの Encrypt メソッドを使用してチケットを暗号化します。 <authentication mode="Forms"> <forms name="MyAppFormsAuth" loginUrl="login.aspx" protection="All" timeout="20" path="/" > </forms> </authentication> protection 属性を "All" に設定すると、アプリケーションが FormsAuthentication.Encrypt を呼び出したときに、チケットが整合性チェックを受け、暗号化されます。このメソッドは、通常、アプリケーションのログイン ボタン イベント ハンドラに挿入し、認証チケットを作成するときに呼び出します。 string encryptedTicket = FormsAuthentication.Encrypt(authTicket); フォーム認証とチケットの暗号化の詳細については、「第 8 章 ASP.NET セキュリティ」を参照してください。 基本認証を使用する場合も同様に、すべてのページで SSL を使用します。基本認証で使用する資格情報も、最初にユーザーが入力するときだけでなく、Web ページ要求が発行されるたびに転送されるからです。 基本認証の場合、ASP.NET が認証の対象となる呼び出し元を表す WindowsPrincipal オブジェクトを自動的に作成し、現在の Web 要求 (HttpContext.User) に関連付けます。Web 要求では、PrincipalPermission 要求と .NET ロールを含む .NET 認定でこのオブジェクトが使用されます。 フォーム認証の場合は、入力された資格情報を Active Directory の情報との比較によって検証するコードを作成し、認証の対象となるユーザーを表す GenericPrincipal を作成する必要があります。 SQL Server の認証方法を Windows 認証に設定することによって、資格情報は Web サーバーに保存されず、内部ネットワークを介して SQL Server に送信されることもありません。 Web サービスとデータベースの間に IPSec を構成すると、社内ネットワーク上のデータベースとの間でやりとりされるデータが保護されます。 注意点 データベース サーバー上の重複するローカル Windows アカウント (IIS のローカル ASPNET プロセス アカウントと一致するアカウント) を使用すると、管理の負担が増加します。パスワードの更新および同期を手動で定期的に行う必要があります。 基本認証を使用すると、ブラウザの画面にポップアップ ダイアログが表示されます。このようなダイアログが表示されないシームレスなログオン プロセスにするには、フォーム認証を使用します。 関連シナリオ エクストラネットと社内ネットワークが接続されないケース エクストラネット アプリケーションにおいて社内ネットワークとの接続を不要にすると、セキュリティ レベルがさらに向上します。このシナリオの特徴は以下のとおりです。 エクストラネット内に別個の SQL Server データベースがあり、内部データベースからエクストラネット データベースにデータを複製します。 ルーターを使用して、エクストラネットから社内ネットワークへの接続を拒否します。接続は特定の非特権ポートを使用する方法で確立できます。 社内ネットワークからエクストラネットへ接続するときには、必ず強力な監査およびログの機能を備えた専用サーバーが使用され、ユーザーはエクストラネットにアクセスする前に認証を受ける必要があります。 詳細情報 Microsoft TechNet の以下のドキュメントを参照してください。 Extending Your Network to Business Partners (英語情報) エクストラネットへの Microsoft SharePoint Portal Server 2001 の導入 Active Directory を使用したフォーム認証の詳細については、このガイドの「パート IV : 参照」の「Active Directory でフォーム認証を使用する方法」を参照してください。F まとめ この章では、2 つの一般的なエクストラネット アプリケーション シナリオをセキュリティで保護する方法について説明しました。 イントラネット アプリケーションおよびインターネット アプリケーションのシナリオについては、「第 5 章 イントラネット セキュリティ」と「第 7 章 インターネット セキュリティ」を参照してください。