次の方法で共有


LightSwitch のセキュリティ

LightSwitch アプリケーションへのアクセスを保護する

Valerie Andersen

Matt Evans
Sheel Shah
Michael Simons

アプリケーションのセキュリティ確保が簡単ではないことは認めざるを得ません。さいわいなことに、Visual Studio LightSwitch を使えば、基幹業務 (LOB) アプリケーションにおけるアクセス許可ベースのアクセス制御の管理が容易になります。その結果、独自のビジネス ニーズを満たすアクセス制御ロジックを備えたアプリケーションをビルドできるようになります。

LightSwitch アプリケーションは、論理的には、プレゼンテーション、ロジック、データ ストレージの 3 つの層から構成されます。そのため、各層に含まれる資産へのアクセスについて考慮し、各層で適切なアクセス レベルを確保する必要があります。LightSwitch を使えば、適切なレベルでアクセス制御ロジックをアプリケーションに組み込むことが可能です。さらに、LightSwitch は、その基になるテクノロジに含まれるアクセス制御基盤を利用しているため、IIS や ASP.NET を通じた共通のアクセス制御構成も可能です。

今回は、LightSwitch アプリケーションのアクセス制御のしくみについて調べます。まず、3 層アーキテクチャでのアクセス制御を対象に LightSwitch が提供する機能を説明します。アプリケーションの配置もアクセス制御に関連するため、配置についても簡単に触れます。次に、LightSwitch をサポートするテクノロジを使用してアクセスをより細かく制御する方法をいくつか紹介します。最後に、Windows Azure 環境に配置する際のアクセス制御について解説します。

アクセス制御の基礎

LightSwitch アプリケーションのアクセス制御には 2 つの側面があります。1 つは "認証" です。これは、ユーザーが主張する身元をアプリケーションが確認するプロセスです。もう 1 つは "承認" です。これは、ユーザーがアプリケーション内で実行または表示できることを定義します。

認証

認証プロセスは、ユーザーが主張する身元を特定します。LightSwitch のアクセス制御の第一段階では、ユーザーがアプリケーションに自分自身の身元の特定を求める必要があります。サポートする認証モードは、"Windows 認証" と "フォーム認証" です。これらのオプションは、アプリケーションのプロパティの [アクセス制御] タブで構成できます (図 1 参照)。

Defining Permissions in the Application Designer
図 1 アプリケーション デザイナーでのアクセス許可の定義

すべてのユーザーが Windows ドメインに所属し、コンピューターにログインするユーザーとアプリケーションを使用するユーザーが同一人物であると信頼できるときは、Windows 認証をお勧めします。この認証では、ログイン プロンプトを新たに表示することも、Windows 外部でパスワードを保存または管理することも必要ではありません。Windows 認証は安全性の高いオプションですが、通常、ドメインを設定している企業イントラネット環境でアプリケーションが実行されている場合しか実用的ではありません。

2 つ目のフォーム認証では、ユーザーがアプリケーションを起動するときに、ユーザー名とパスワードの入力を求めます。LightSwitch の既定では、ユーザー名とパスワードをデータベースに照らしてチェックします。フォーム認証は、インターネット経由で実行されるクライアントや、Windows ドメインに所属していないクライアントに適しています。

フォーム認証では、アプリケーションにアクセスする必要があるユーザーをすべて、最初からシステムに追加しておかなければなりません。Windows 認証もこの方法で機能できますが、設計時にオプションを設定して、ドメインにログインできるすべての Windows ユーザーが既定でアプリケーションにアクセスできるようにします。設計時に明示的に追加していない Windows ユーザーは、特定のアクセス許可を必要とするアプリケーション機能にはアクセスできなくなります。

認証により、アプリケーションを使用できるかどうかを特定できます。アプリケーションの種類によっては、アクセス制御に関するニーズを満たすために必要なことはこのような認証だけかもしれません。ユーザーを認証したら、そのユーザーを完全に信頼してデータへのアクセスを許可します。このような場合は、これでアクセス制御の実装が完了したことになり、追加のアクセス許可やコードは必要ありません。あとは、ホスティング サーバー上のアプリケーションのセキュリティを確保するために、「アクセス制御のための配置に関する考慮事項」で取り上げる IIS オプションについて考慮するだけです。

ただし、多くのアプリケーションでは、ユーザーを認証後も、そのユーザーの動作をさらに細かく制御する必要があります。このシナリオに必要なのが承認です。

承認

LightSwitch は、ビジネス ルールを考案するためのアクセス許可ベースの承認システムを提供します (図 2 参照)。

Implementing Authorization in LightSwitch
図 2 LightSwitch での承認の実装

アプリケーション デザイナーでアクセス許可を定義します (図 1 参照)。次に、現在のユーザーが必要なアクセス許可を持っているかどうかをチェックするコードを記述します。アクセス制御のメソッドを、エンティティ、クエリ、および画面に実装できるため、現在のユーザーが、特定のデータを操作または表示したり、特定の画面を開いたりできるかどうかを決定するロジックを簡単に記述できます。

LightSwitch には、"セキュリティ管理" という組み込みのアクセス許可があり、このアクセス許可を付与されたユーザーはセキュリティ管理者になります。"セキュリティ管理" のアクセス許可を持つユーザーがログオンすると、実行中の LightSwitch クライアント アプリケーションのセキュリティ管理画面にアクセスできます。セキュリティ管理画面は、この特権が与えられたユーザーに自動的に表示されます。セキュリティ管理者は、アプリケーションに必要なロールを作成し、各ロールに必要なアクセス許可を割り当てます (図 3 参照)。次に、ユーザーを作成して、適切なロールに割り当てます (図 4 参照)。

Creating Roles at Run Time
図 3 実行時のロールの作成

Assigning Users to Roles at Run Time
図 4 実行時のロールへのユーザーの割り当て

アプリケーションを最初に配置するときに、セキュリティ管理者を "セキュリティ管理" ロールに追加して、アプリケーションに最初にアクセスできるようにする必要があります。配置プロセスは、この既定のユーザーを適切に構成するのを支援します。配置したアプリケーションの実行中にセキュリティ管理者が存在しなくなる状態を避けるため、セキュリティ管理者のアクセス許可を持つユーザーが 1 人しかいない場合は、そのユーザーを削除できないようにシステムが管理します。

アクセス許可の動作が適切かどうかを検証するためにアプリケーションを配置する必要はありません。LightSwitch アプリケーションをデバッグ モードで実行すると、認証とロールのシステムが特別なモードで実行されます。このモードでは、開発環境によって特別なテスト ユーザーの自動認証が試みられます。このテスト ユーザーにアクセス許可を付与または拒否するには、LightSwitch デザイナーの [デバッグ用に許可] チェック ボックスを使用します。その後、選択したアクセス許可を使ってデバッグ モードでアプリケーションが実行されるため、記述したアクセス許可ロジックをテストできます。つまり、テスト ユーザーとロールを複数構成する必要なく、アクセス許可のチェックが正確かどうかをすばやく検証できます。

アプリケーションの資産へのアクセスをどこで制御するか

今度は、セキュリティを確保する対象と場所について考えます。多くのアプリケーションには、なんらかの機密データが存在します。たとえば、表示してはいけないデータ、操作だけを許可しないデータ、アクセスを禁止する必要がまったくないデータなどがあります。データのセキュリティを確保する場合、まずロジック層から考えます。開発者がロジック層でデータを適切に制御すれば、多くの場合、プレゼンテーション層も適切かつ自動的に対応します。たとえば、社員データを削除するアクセス許可を持たないユーザーには、社員データを表示しているグリッドの削除ボタンを無効にするようにします。これこそが、アプリケーションのビルドを容易にする LightSwitch の能力です。

データのレベルにもアクセス制御を実装すると、アプリケーションのセキュリティがさらに強化され、開発者は組み込みのインテリジェンスを活用することができるようになります。プレゼンテーション層のみでデータのセキュリティを確保しても、データはロジック層に公開されるため、認証済みのユーザーに悪意があれば、プレゼンテーション層を迂回して、データの読み取りや操作を行うためにサービスに直接アクセスできる可能性があります。この問題は、LightSwitch アプリケーションの 3 層アーキテクチャに関連しています。ただし、実際には、3 層アプリケーションすべてに共通する問題です。プレゼンテーション層にはデータを適切に表示する役割があります。ですが、適切なアクセス制御がロジック層に実装されていなければ、認証済みのユーザーがデータにアクセスする方法はいくつもあります。

ロジック層でデータのセキュリティを確保する

ロジック層でアクセス許可をチェックする主要コンポーネントのグループは、エンティティとクエリです。

エンティティ: エンティティは、アプリケーション データへのアクセスや操作を行うための汎用メカニズムです。エンティティで実行できる 4 つの主要動作は、読み取り、挿入、更新、および削除です。LightSwitch は、この各動作が実行されるときに、ユーザーのアクセス許可の検証を行うためのフックポイントを開発者に提供します。また、現在のユーザーにアプリケーションで定義されている特定のアクセス許可があるかどうかをチェックするための簡単な API も提供します。次のコードは、アクセス許可のチェックの例を示しています。また、開発者がアクセス許可をチェックできるように、API が提供する各動作に対応するさまざまなメソッドも示しています。

partial void Employee_CanUpdate(ref bool result)
{
  result = Application.Current.User.HasPermission(Permissions.EmployeeUpdate);
}
 
partial void Employee_CanInsert...
 
partial void Employee_CanRead...
 
partial void Employee_CanDelete...
 
partial void SaveChanges_CanExecute...

注意すべき点が 2 つあります。まず、これらのメソッドは、SaveChanges_CanExecute を除き、特定のエンティティのインスタンスではなくエンティティ セット全体に実装されます。そのため、特定のエンティティのインスタンスのデータ値に関連するチェックを行うことはできません。SaveChanges_CanExecute メソッドは、データ ソース全体における変更へのアクセスを制御するため、エンティティ固有のロジックやエンティティ セット固有のロジックを含めることができません。もう 1 つの注意すべき点は、Employee_CanRead メソッドが false を返すと、Employee_CanUpdate および Employee_CanDelete メソッドはどちらも暗黙のうちに false になるため呼び出されないことです。ユーザーは、読み取りを許可されていなければ、エンティティの更新や削除も許可されません。

"Can" から始まるメソッドは、セキュリティの確保を大まかに行う基本的な手段です。これらは基本的なデータ アクセス制御ポリシーをサポートしますが、制限もあります。データの読み取りを細かく制御する場合は、クエリにアクセス制御ロジックを実装します。また、データの書き込みを細かく制御する場合は、保存パイプラインでアクセスを制御します。

クエリ: クエリも、ロジック層でセキュリティを確保します。各クエリには、アクセスを制御できるメソッドがあります。LightSwitch は、存在する各エンティティに、エンティティのすべてのインスタンスを返す All クエリと、キーごとに 1 つのエンティティ インスタンスを返す Single クエリおよび SingleOrDefault クエリを自動生成します。これらの組み込みのクエリにはそれぞれ CanExecute メソッドがあるので、このメソッドを使ってアクセス制御を実装します。

partial void Employees_All_CanExecute(ref bool result)
{
  result = Application.Current.User.HasPermission(Permissions.QueryEmployees);
}
 
partial void Employees_Single_CanExecute...
partial void Employees_SingleOrDefault_CanExecute...

重要なのは、LightSwitch クエリが構成可能であることです。つまり、既存のクエリを基盤に新しいクエリを構成できます。アクセス制御ロジックをクエリに適用する際、最初のクエリでのアクセス許可の要件が、その最初のクエリを基に構成しているクエリへの入力として機能します。Single クエリおよび SingleOrDefault クエリは、All クエリを基盤に構成されているため、特定のアクセス許可を派生クエリに指定しなければ、All クエリのセキュリティを確保すると、両方のクエリのセキュリティも確保されます。ただし、必要に応じて、構成元のクエリよりも制限が少ないアクセス許可を、派生クエリに指定することも可能です。また、エンティティ セットの CanRead メソッドは、その型のすべてのクエリで、CanExecute よりも前に適用されます。

図 5 はクエリ構成の例です。Employee エンティティを基に NorthAmericaEmployees クエリを作成する場合、このクエリは、組み込みの Employee_All クエリを基に構成されます。そのため、Employee_All_CanExecute によって適用されるすべてのアクセス制御ロジックは、NorthAmericaEmployees クエリにも適用されます。これは、派生クエリに特定のコードを記述している場合を除き、NorthAmericaEmployees クエリが Employee_All クエリを基盤にするためです。特定のユーザーしか NorthAmericanEmployees エンティティのデータにアクセスできないようにするには、NorthAmericaEmployees_CanExecute メソッドを使って、そのクエリのアクセス許可を具体的に制限または許可します。

Query Composition on the Employee Entity
図 5 Employee エンティティに基づくクエリ構成

リレーションシップのアクセスを制御する

リレーションシップにまたがってクエリを操作するときは、関連するエンティティを走査するリレーションシップに従って、エンティティのアクセス許可がチェックされることを理解しておくことが重要です。これは、エンティティに正しいアクセス許可を定義することが重要な理由の 1 つです。リレーションシップを通じて行われる読み取りアクセスからデータを保護するためには、エンティティの CanRead メソッドに適切なレベルのアクセス許可が必要です。例として、Employee テーブルと関連する Compensation (給与) データについて考えてみます。図 6 のモデルを参照してください。

HR Application Model
図 6 HR アプリケーション モデル

クエリを使用して Employee と Compensation 間のリレーションシップを走査しているときは、リレーションシップを走査するときに、Compensation_All_CanExecute のアクセス許可ではなく、エンティティの読み取り操作のアクセス許可が評価されます。エンティティが走査されるときに適切なレベルのアクセス許可が実現されるように、Compensation エンティティの CanRead メソッドのアクセス許可を正しく設定する必要があります。エンティティのセキュリティが確保されていないと、クエリを使用してデータを推測できることに注意が必要です。たとえば、図 7 に示すように、最も給与の高い社員を返すクエリを用意する場合は、アクセスを許可されているユーザーのみがそのクエリを使用して Employee のデータにアクセスできるように、Employee のデータにアクセスする Compensation エンティティのセキュリティを適切に確保しなければなりません。

Defining a Query to Return the Top-Paid Employees
図 7: 最も給与の高い社員を返すクエリの定義

プレゼンテーションのエクスペリエンスをカスタマイズする

ロジック層でデータのセキュリティを確保したら、今度はプレゼンテーション層でのユーザー エクスペリエンスを設計します。ユーザーが特定の画面に完全にアクセスできないようにするのであれば、アプリケーションで <ScreenName>_CanRun を使用してその画面を非表示にします。ユーザーが特定の画面にアクセス許可を持たないときは、その画面がユーザーのナビゲーション メニューに表示されません。また、<CommandName>_CanExecute メソッドを使用して、画面上で実行できるコマンドを制限することも可能です。

ほかにも、<EntityProperty>_IsReadOnly、<ScreenControl>.IsEnabled、<Screen-Control>.IsReadOnly、<ScreenControl>.IsVisible など、画面上の特定のコントロールの編集可能状態を非表示、表示、および制御するために、画面およびエンティティで使用可能なメソッドがいくつかあります。これらのメソッドはアクセス制御をその主目的にしているわけではありませんが、目的とするユーザー エクスペリエンスを提供するのに非常に便利です。ユーザーが操作できないデータを非表示にするのが最適なケースもあれば、読み取り専用のコントロールを表示すべきケースや、ユーザーがデータを正しく入力するように誘導して、誤った場合は意味のあるエラーを表示する必要があるケースもあるでしょう。LightSwitch のプレゼンテーション層は、このようなさまざまなケースに柔軟に対応します。

ただし、「データの編集可能状態を非表示、表示、制御するために画面にロジックを提供するだけでは、ユーザー アクセスからデータを保護することにはならない」という事実を明確に理解する必要があります。これは、データの表示方法を制御しているだけです。認証済みのユーザーに悪意があり、ロジック層を適切に保護していなければ、直接ロジック層のサービスを攻撃して、データを表示または操作することが可能です。これこそが、各アプリケーション層に適切にアクセス制御を実装することが不可欠な理由です。

ストレージ層でデータのセキュリティを確保する

ストレージ層では、データをデータベースに保存します。データベースでの必要最低限の特権をデータベース ログインに与えることで、ストレージ層のデータへのアクセスを制御できます。アプリケーションはこのログインを使用してデータベースに接続し、必要な操作を実行します。データへの接続はすべて中間層を経由して実行されます。また、エンド ユーザーは、3 層配置ではデータまたは接続文字列に直接アクセスすることは絶対にできません。LightSwitch アプリケーションを配置するときに、アプリケーションがデータへのアクセスに使用する接続文字列を指定する必要があります (図 8 参照)。アプリケーションに一意のデータベース ログインがない場合は、LightSwitch がアプリケーション管理者の作成をサポートします。識別対象のデータベース ユーザーをアプリケーション固有にすること、およびアプリケーションが使用してもかまわないデータのみへのアクセス権をそのデータベース ユーザーに付与することを強くお勧めします。

Specifying the Database Connection Credentials for the Running Application During Deployment
図 8 配置中に行う、実行中のアプリケーションへのデータベース接続資格情報の指定

セキュリティを確保した LightSwitch アプリケーションを 2 層で配置することも可能です。2 層配置では、プレゼンテーション層とロジック層をユーザーのデスクトップで実行します。この構成では、データベースの接続文字列が格納されている web.config ファイルにクライアントのユーザーがアクセスできるようになるため、セキュリティが確保されるアプリケーション構成に必須であるプレゼンテーション層とロジック層の分離が行われません。接続文字列を入手できれば、ユーザーは中間層のアクセス制御ロジックを迂回して、データベースに直接アクセスできます。このような場合は、中間層とデータベースの間で Windows 認証を使用するのが最適です。Windows 認証を使用しないでアプリケーションを適切に保護するには、3 層配置を行う必要があります。

アクセス制御のための配置に関する考慮事項

LightSwitch アプリケーションを最初に配置するときに、LightSwitch の管理者権限を持つユーザーを作成する必要があります。最初は、このユーザーしか管理者権限を持ちません。その後、このユーザーは、先ほど説明したように、クライアント アプリケーション内でロールとユーザーを構成するのに使用されることになります。このユーザーは LightSwitch アプリケーションの管理者になりますが、Windows の管理者でなくてもかまいません。また、配置プロセス外で管理者権限を持つユーザーを新しく作成するコマンドライン ユーティリティもあります。この Microsoft.LightSwitch.SecurityAdmin.exe ユーティリティは、LightSwitch のインストール ディレクトリにあります。

IIS のアクセス制御機能を活用する

ここまでは LightSwitch 固有のアクセス制御機能について説明してきました。ここからは、アプリケーション管理者がサポート対象のテクノロジを使って LightSwitch アプリケーションのセキュリティを手動で確保する方法をいくつか簡単に紹介します。

LightSwitch と SSL: Web ブラウザーと Web サーバーの通信と同様、LightSwitch クライアントとサーバーは、HTTP プロトコルを使って通信します。HTTP は、データをクリア テキストで送信することを仕様で規定しているため、ネットワークを盗聴すれば、クライアントとサーバーが交換するデータをモニタリングできます。ネットワークの盗聴から通信を保護するには、HTTPS プロトコルを使用します。HTTPS プロトコルは、HTTP の通常データを暗号化トンネルで隠ぺいします。

クライアントが HTTPS 経由でサーバーと通信するように、LightSwitch アプリケーションを配置できます。その結果、クライアントとサーバー間で交換される重要なビジネス データを保護できるだけでなく、フォーム認証を使用する際にユーザー名とパスワードを保護することも可能です。フォーム認証を IIS または Windows Azure と共に使用する際のベスト プラクティスは、HTTPS サイトに配置することです。HTTPS サイトに配置しなければ、攻撃者が認証トークンを盗み、ログイン ユーザーを偽装することが可能になります。Windows 認証を使用しているときは、HTTPS の代わりに HTTP を使用しても、攻撃者はユーザーのパスワードを入手したりユーザーを偽装したりすることはできません。ただし、認証モードが何であっても、HTTPS を使用しない限り、クライアントとサーバー間で転送されるビジネス データが盗聴される可能性は残ります。

SSL と証明書: HTTP 経由で通信する Web サーバーは、インストールされるサーバー証明書を信頼します。証明書には 2 つの目的があります。1 つ目に、クライアントが接続しているサーバーが、実際に正しいサーバーで、置き換えられたり侵害されたりしていないことを、証明書が確認します。2 つ目に、サーバー証明書には、クライアントに送信されるデータを暗号化するための秘密キー情報が含まれています。

Web ブラウザーが、初めてアクセスするサーバーの ID を信頼できるようにするためには、サーバーの証明書が信頼された証明機関 (CA) によって暗号で署名されている必要があります。証明書は、verisign.co.jpentrust.net (英語)、instantssl.com (英語)、geocerts.com (英語) などの多くのプロバイダーから購入できます。ほとんどのプロバイダーは、サーバー証明書の生成やサーバー証明書への署名に課金するため、開発環境では、自己生成型の未署名の (つまり、信頼されていない) 証明書を使うのが一般的です。

サーバーが信頼されていない証明書を使用している状態で、HTTPS を経由して LightSwitch Web アプリケーションに接続した場合、動作は Web ブラウザーによって異なります。最低でも、ブラウザーに証明書についての問題が表示され、続行するかどうかたずねられます。LightSwitch Web アプリケーションでは、これが正しく機能します。

ただし、IIS によってホストされている LightSwitch デスクトップ アプリケーションを使用している場合、および LightSwitch デスクトップ アプリケーションに HTTPS 経由でアクセスしている場合、IIS サーバーは信頼された証明書を使用しなければなりません。Silverlight は、信頼されていないサーバー証明書を使用するサーバーからのデスクトップ アプリケーションを許可しません。証明書が信頼されていなければ、アプリケーションのインストールは正常に完了したようにみえても、アプリケーションの起動直後にエラーになります。この問題を解決するには、サーバーの証明書をクライアントの証明書ストアに事前にインストールして Web ブラウザーがその証明書を信頼するようにするか、サーバーの証明書を信頼された CA によって署名されたものに置き換えます。クライアントからアプリケーションに最初にアクセスする前に、これらの解決措置のいずれかを実行してください。さもなければ、クライアントには、証明書が変更または改ざんされているように見えます。

IIS: SSL を使って LightSwitch アプリケーションをホストするために、IIS サーバーで LightSwitch 固有の構成を行う必要はありません。サーバー管理者は、Web サーバーを構成して HTTPS を有効にし、標準の方法で証明書を選択します。

HTTP と HTTPS の両方を使用して同じ LightSwitch アプリケーションをホストすることは実際には可能で、そのようにしたいケースもあるでしょう。ですが、既に示したように、HTTP 経由で接続するクライアントは、ユーザーのパスワード情報や重要なビジネス データを保護しません。

最新バージョンの IIS では、Default Web Site が既定で HTTP と HTTPS 接続の両方をリッスンするように設定されています。サーバー管理者は、HTTPS を要求して HTTP 受信接続を HTTPS エンドポイントにリダイレクトするため、HTTP と HTTPS 接続の両方をリッスンするサーバーに LightSwitch アプリケーションを強制的に配置できます。この設定は、LightSwitch アプリケーションの web.config で行います。

アプリケーション プールの構成: IIS に発行する際、アプリケーションを固有のアプリケーション プールで実行することを検討してください。アプリケーション プールは、ワーカー プロセスどうしを分離する (このため、ある Web アプリケーションがクラッシュしても、サーバー上の別のアプリケーションに影響しません) ときにも使用しますが、アプリケーションを異なる ID で実行する場合にも使用します。このため、Web アプリケーション、または特定の Windows ID で実行される一連のサービスをホストするアプリケーション プールを作成して、アプリケーション実行のために ID が必要とするリソースのみへのアクセスを許可できます。LightSwitch アプリケーションの場合、その追加のリソースはデータベースになります。既定では、配置ウィザードは、コンピューター アカウント ID で実行される ASP.NET 4 アプリケーション プール下でアプリケーションを発行します。ただし、この ID はアプリケーション データベースにアクセスできないため、アプリケーションを実行すると "ユーザー 'IIS APPPOOL\ASP.NET v4.0' はログインできませんでした" のようなエラー メッセージが表示されます。

この問題を解決するオプションがいくつかあります。接続文字列で SQL Server のユーザー名またはパスワードを使用している場合、(ユーザーがデータベースに対して適切なアクセス権を持っていれば) アプリケーションはほぼ実行可能です。ただし、データベースへの接続に Windows 認証を選択しているときは、最低限の特権しか持たない Windows ユーザー アカウントでアプリケーションを実行できるよう構成するために、別個のアプリケーション プールが必要です。また、このアカウントには、アプリケーション データベースへの適切なアクセス権を許可することも必要です。

Windows 認証を IIS 7 で使用している場合、注意すべき構成設定がもう 1 つあります。アプリケーション プールの ID としてカスタム ユーザー ID を使用するときは、(Kerberos ではなく) Windows NT LAN Manager (NTLM) プロバイダーを使用するか、Kerberos 認証のサポートを有効にする必要があります。または、アプリケーション プールの ID としてネットワーク サービスの ID を使用して、そのアカウントのアクセスを代わりにデータベースに追加します。

LightSwitch Azure アプリケーションのセキュリティを確保する

Windows Azure でホストされている LightSwitch アプリケーションは、すべて外部からアクセスできます。したがって、このようなアプリケーションのアクセス制御の要件は独特です。

SSL 暗号化: LightSwitch は、アプリケーションを Windows Azure に発行する際、既定で HTTPS エンドポイントを使用します。これは、インターネット通信が行われるときに重要なビジネス情報が暗号化されるようにするためです。LightSwitch では、アプリケーションの発行中に、そのアプリケーションに対して自己署名 SSL 証明書を作成できます。これは Windows Azure でアプリケーションをテストする優れた方法ですが、外部のベンダーからライセンスが付与される証明書を使用することを強く推奨します。デスクトップ アプリケーションは、証明書が信頼されていない場合 SSL 経由では機能しないため、デバッグのために SSL 暗号化を無効にするには、Microsoft.LightSwitch.RequireEncryption の配置構成値を false に更新します。これは、アプリケーションが適切に配置された後に、Windows Azure ポータルを使用して行います。

自己署名 SSL 証明書を使用してアプリケーションをテストしたら、Windows Azure ポータル経由でアプリケーションを再発行しなくても SSL 証明書を更新できます。新しい SSL 証明書は、SSLCertificate 値を新しい証明書の拇印に変更して暗号化を有効にすることで、ホスト対象のアプリケーション用にアップロードできます。

アプリケーションの認証: Windows Azure がホストする LightSwitch アプリケーションへの不正アクセスを防止するには、フォーム認証を推奨します。この場合、アプリケーションの発行後に、追加でサーバー構成を行う必要はありません。しかし、アプリケーションが Windows 認証を必要とする場合、発行済みの LightSwitch アプリケーションをドメインに参加させる必要があります。このためには、Windows Azure Connect を使用します。Windows Azure Connect を有効にする方法の詳細については、bit.ly/qx0Z6n (英語) を参照してください。

SQL Azure データベースのセキュリティ: 通常、LightSwitch アプリケーションは、組み込みのデータベースに SQL Azure データベースを使用します。このデータベースは、LightSwitch でテーブルを作成している場合や、認証を使用している場合に重要です。SQL Azure は、ファイアウォールとユーザーの資格情報を組み合わせて、不正アクセスから保護します。

Windows Azure がホストする LightSwitch アプリケーションがデータベースに接続できるようにするには、"他の Windows Azure サービスにこのサーバーへのアクセスを許可する" ファイアウォール規則を true に設定する必要があります。また、LightSwitch では、アプリケーションを発行するコンピューターの IP アドレスにファイアウォール規則を追加する必要があります。アプリケーションを発行したら、このファイアウォール規則を解除することをお勧めします。その結果、外部のコンピューターがデータベースにアクセスするのを回避できます。

まとめ

LightSwitch によって、開発者は簡単かつ生産性の高い方法でビジネス アプリケーションをビルドできますが、これは、アクセス制御機能の実装にも同様に当てはまります。開発者は認証を使用して、アプリケーションへのアクセスをすばやく簡単に制限することができます。アクセスを細かく制御するときは承認機能を使います。これにより、アプリケーションのロジック層とデータ層でアクセス許可を定義して資産を保護し、ユーザー アクセスを効果的に制御できます。また、IIS と Windows Azure で一般的に使用される機能も、完全なアクセス制御ソリューションを構築するために活用できます。ただし、可能性は皆さんしだいです。LightSwitch についての情報は、LightSwitch チームのブログ (blogs.msdn.com/b/lightswitch、英語) を参照してください。

 

Valerie Andersen は、Visual Studio LightSwitch に携わっているマイクロソフトのプログラム マネージャーです。彼女の目標は、実世界の開発者が、セキュリティが確保された高品質のアプリケーションをすばやくビルドして、世界中の顧客のニーズを満たせるようにすることです。

Matt Evans は、LightSwitch に携わっているソフトウェア テスターです。彼は、開発者の求めるレベルで LightSwitch アプリケーションのセキュリティを確保できるようにすることを考えています。

Sheel Shah は、LightSwitch に携わっているマイクロソフトのプログラム マネージャーです。彼女はチームの中で、Windows Azure のサポート、配置、および LightSwitch のクライアント機能の設計に重点的に取り組んでいます。

Michael Simons は、LightSwitch に携わっているマイクロソフトのシニア開発者です。彼はチームの中で、データおよびセキュリティ機能の開発に重点的に取り組んでいます。

この記事のレビューに協力してくれた技術スタッフの Dan LeeaphonJohn RivardDan Seefeldt、および Matt Thalman に心より感謝いたします。