WCF RIA Services のセキュリティ
ここでは、ドメイン サービスを安全に使用できるようにするためのガイダンスを示します。EnableClientAccessAttribute 属性を適用してドメイン サービスを公開すると、そのサービスが公開されているネットワーク上のすべてのユーザーがドメイン サービスを利用できるようになります。クライアント アプリケーションがドメイン サービスにアクセスする唯一のアプリケーションとは限りません。この考慮事項は、パブリック ネットワークで特に重要です。ただし、機密データが公開されている場合は、企業ネットワークなどの制限付きネットワークでも重要になります。
[新しいドメイン サービス クラスの追加] ダイアログ ボックスでは、ドメイン サービスの操作を開始するためのコードが生成されます。生成されたコードは、すぐに配置できるとは限りません。コードを確認し、アプリケーションのセキュリティ要件を満たすように変更する必要があります。特に、ネットワーク上のすべてのユーザーが利用できるようにする操作について検討する必要があります。次のチェック リストは、ドメイン サービスを安全に使用できるようにするための開始点となります。
セキュリティ チェック リスト
ドメイン サービスを安全に使用できるようにするには、次のガイダンスを考慮してください。
ドメイン サービスによって公開されるデータと操作を最小限に抑えます。これは、情報の漏えいやサービス拒否に対する防衛の最前線となります。
クライアントで必要なエンティティのみを公開します。この方法では、公開するエンティティの数を減らすことが可能な場合は、サーバーのロジックおよび検証とクライアントのロジックおよび検証を区別することが必要になることがあります。たとえば、クライアントの Employee エンティティが不要な経費報告アプリケーションでは、ドメイン サービスを介してそのエンティティを公開する必要はありません。
機密データを公開しないようにエンティティを構成します。ExcludeAttribute 属性または プレゼンテーション モデル を使用して、クライアントで利用できるデータを減らすことができます。たとえば、アプリケーションで誕生日とクレジット カード番号が不要な場合は、クライアントに表示される構造からそれらを除外します。
LINQ のデータのフィルター処理機能を使用するのではなく、アプリケーションで必要なパラメーターを受け取るクエリ メソッドが必要です。たとえば、特定の従業員の経費明細書を表示する場合は、クエリ メソッドのパラメーターとして従業員 ID は必要ですが、すべての経費明細書を取得するメソッドを指定する必要はありません。この方法では、すべての従業員に関するデータ収集は最小限に抑えられます。
アプリケーションで特定のシナリオに必要なデータのみを提供するクエリ メソッドを作成します。この方法では、すべてのデータを返す 1 つのクエリ メソッドではなく、データの一部を返す複数のクエリ メソッドを指定します。たとえば、製品をカテゴリ別または仕入先別に表示する場合は、すべての製品を返す 1 つのメソッドではなく、カテゴリまたは仕入先の情報を受け取る 2 つのメソッドを指定できます。
アプリケーションで通常必要となるデータのみが提供されるようにデータをフィルター処理します。たとえば、過去 1 年以内に完了した注文のみを返すクエリ メソッドがあります。
クエリから返される結果の数を制限して、サーバーの偶然または意図的に生じるオーバーロードを最小限に抑えます。QueryAttribute で ResultLimit プロパティを使用して、返される結果の数を調整します。たとえば、多数の製品が返される場合は、結果を 20 個に絞ることによりクライアントでページングを適用します。また、出力キャッシュに OutputCacheAttribute 属性を使用して、中間層およびデータベースの負荷を軽減することを検討してください。
公開される各エンティティで操作の数を最小限に抑えます。たとえば、注文アプリケーションで注文の追加または変更のみを行う必要がある場合は、Orders エンティティに対するクエリ、挿入、および更新の各操作を公開する必要がありますが、削除操作を公開する必要はありません。また、Products エンティティについてはクエリ操作のみを公開する必要がありますが、データ変更操作を公開する必要はありません。
可能な限り、更新できるメンバーを制限する名前付き更新メソッドを使用してください。
認証済みユーザーおよび特定のロールに属しているユーザーのデータと操作へのアクセスを制限します。
RequiresAuthenticationAttribute 属性を使用して、できる限り匿名アクセスを回避します。匿名アクセスを許可する必要がある場合は、匿名アクセスを最小限のドメイン サービスとそのドメイン サービス内の最小限の操作のサブセットに制限します。
できる限り、操作固有の RequiresRoleAttribute 属性を追加します。ドメイン サービス内の各操作を個別に検討してください。たとえば、すべてのユーザーが Products エンティティを照会する必要があっても、管理者ロールのユーザーのみがそのエンティティを更新する必要がある場合があります。
AuthorizationContext プロパティを使用して、カスタマイズされた認証モデルを提供することを検討します。
クライアントが送信したデータは疑わしいデータとして扱います。悪意のあるクライアント (認証および承認されているクライアントの場合もあります) は、変更セット内の現在の値と元の値に対して改ざんされた値を提供する可能性があります。アプリケーション ロジックでこれらの値を信頼できるものと見なさないようにする必要があります。代わりに、改ざんされた元の値による潜在的な脅威を考慮してください。
フォーム認証に https プロトコルを使用します。クリア テキストによるパスワードの送信には重大な脆弱性がありますが、https を使用すると脆弱性を軽減できます。
公開するエンドポイントの数を最小限に抑えます。既定では、RIA サービス によってドメイン サービス用にバイナリ エンドポイントが作成されます。別のエンドポイントを追加するのは、そのエンドポイントを明示的に必要とするクライアントを所有している場合だけです。使用していないすべてのエンドポイントを無効にします。