次の方法で共有

サービスのセキュリティ保護

  • [アーティクル]

Windows Communication Foundation (WCF) サービスのセキュリティは、転送セキュリティと承認という 2 つの主要な要件で構成されています (3 番目の要件であるセキュリティ イベントの監査については、「監査」を参照してください)。簡単に説明すると、転送セキュリティは、認証 (サーバーとクライアント両方の ID の検証)、機密性 (メッセージの暗号化)、および整合性 (改ざんを検出するためのデジタル署名) で構成されます。 承認は、たとえば、特権のあるユーザーだけがファイルを読み取ることができるなど、リソースへのアクセスを制御することです。 WCF の機能を使用すれば、この 2 つの主要要件を簡単に実装できます。

BasicHttpBinding クラス (または構成内の <basicHttpBinding> 要素) を除き、すべての定義済みバインディングでは既定で転送セキュリティが有効になっています。 このセクションのトピックでは、2 つの基本的なシナリオ、インターネット インフォメーション サービス (IIS) でホストされるイントラネット サービス上で転送セキュリティと承認を実装するシナリオと、IIS でホストされるサービス上で転送セキュリティと承認を実装するシナリオについて説明します。

セキュリティの基礎

セキュリティは、 資格情報に依存します。 資格情報は、エンティティが本物であることを証明します ("エンティティ" には、個人、ソフトウェア プロセス、会社、および承認できるものすべてが当てはまります)。たとえば、サービスのクライアントが "ID" の "クレーム" を作成し、資格情報によってそのクレームを何らかの方法で証明します。 通常のシナリオでは、資格情報の交換が行われます。 最初に、サービスがその ID のクレームを作成し、資格情報を使用してクライアントにそのクレームを証明します。 次に、クライアントが ID のクレームを作成し、サービスに資格情報を提示します。 両方がお互いの資格情報を信頼した場合、 セキュリティで保護されたコンテキスト を確立できます。このコンテキストでは、すべてのメッセージは機密性が保護された状態で交換され、すべてのメッセージはその整合性を保護するために署名されます。 サービスはクライアントの ID を確立した後で、クライアントの資格情報のクレームをグループの ロール または メンバーシップ に適合できます。 いずれの場合も、クライアントが属するロールまたはグループを使用して、サービスは、そのクライアントがロール特権またはグループ特権に基づいて限られた操作を実行することを 承認 します。

Windows セキュリティ機構

クライアントとサービスのコンピューターが、両方がネットワークにログオンする必要がある Windows ドメインに存在する場合、資格情報は Windows インフラストラクチャによって提供されます。 この場合、コンピューターのユーザーがネットワークにログオンすると資格情報が確立されます。 ネットワーク上の各ユーザーおよび各コンピューターは、信頼されたユーザーおよびコンピューターの集合に属することを検証される必要があります。 Windows システムでは、このようなユーザーとコンピューターは、 セキュリティ プリンシパルとも呼ばれます。

Kerberos コントローラーによるサポートがある Windows ドメインでは、Kerberos コントローラーは、チケットを各セキュリティ プリンシパルに付与することをベースにしたスキームを使用します。 コントローラーによって付与されたチケットは、システムの他のチケット付与システムによって信頼されます。 エンティティが何らかの操作を実行しようとしたり、コンピューター上のファイルやディレクトリなどの リソース にアクセスしようとしたりすると、その都度チケットの有効性が検査され、検査に合格した場合、プリンシパルに操作用の別のチケットが付与されます。 このチケットの付与方法は、操作ごとにプリンシパルを検証する方法よりも効率的です。

Windows ドメインで従来より使用されている安全性が低い機構に、NT LAN Manager (NTLM) があります。 Kerberos を使用できない場合 (通常、ワークグループなどの Windows ドメインの外部)、代わりに NTLM を使用できます。 NTLM は、IIS のセキュリティ オプションとしても使用できます。

Windows システムでは、各コンピューターとユーザーにロールとグループのセットを割り当てることによって承認が機能します。 たとえば、各 Windows コンピューターは、 管理者のロールに属するユーザー (またはユーザー グループ) がセットアップし、管理する必要があります。 もう 1 つのロールは、 ユーザーのロールです。このロールのアクセス許可は、管理者ロールより制限されます。 ロール以外に、ユーザーはグループにも割り当てられます。 グループによって、複数のユーザーが同じロールで動作できます。 このため、実際 Windows コンピューターは、ユーザーをグループに割り当てることによって管理されます。 たとえば、複数のユーザーをコンピューターのユーザー グループに割り当て、限られた人数のユーザーを管理者グループに割り当てることができます。 ローカル コンピューターでは、管理者は新しいグループを作成して、他のユーザー (または他のグループ) をそのグループに割り当てることもできます。

Windows を実行しているコンピューターでは、ディレクトリの各フォルダーを保護できます。 つまり、フォルダーを選択して、そのフォルダーのファイルにアクセスできるユーザー、およびそのユーザーがファイルのコピー、ファイルの変更 (最大限の特権が与えられている場合)、ファイルの削除、またはフォルダーへのファイルの追加を実行できるかどうかを制御できます。 これは、アクセス制御と呼ばれ、その機構はアクセス制御リスト (ACL) と呼ばれます。 ACL を作成するとき、アクセス権を 1 つまたは複数のグループおよびドメインの個別のメンバーに割り当てることができます。

WCF インフラストラクチャは、この Windows セキュリティ機構を使用するように設計されています。 したがって、イントラネットに展開するサービスを作成していて、そのクライアントを Windows ドメインのメンバーに限定する場合、セキュリティを簡単に実装できます。 有効なユーザーだけがドメインにログオンできます。 ログオン後、Kerberos コントローラーによって、各ユーザーは他のコンピューターまたはアプリケーションとの間にセキュリティで保護されたコンテキストを確立できます。 ローカル コンピューターでは、グループを簡単に作成でき、特定のフォルダーを保護する場合、そのグループを使用してローカル コンピューター上でアクセス権を割り当てることができます。

イントラネット サービスでの Windows セキュリティの実装

Windows ドメインでのみ実行するアプリケーションをセキュリティで保護するには、 WSHttpBinding または NetTcpBinding バインディングの既定のセキュリティ設定を使用できます。 既定では、同じ Windows ドメインに存在するすべてのユーザーが WCF サービスにアクセスできます。 ドメイン内にいるユーザーは、ネットワークにログオン済みなので信頼できます。 サービスとクライアントの間で交換されるメッセージは、機密性を保護するために暗号化され、整合性を保護するために署名されます。 Windows セキュリティを使用するサービスの作成方法の詳細については、「方法: Windows 資格情報でサービスをセキュリティで保護する」を参照してください。

PrincipalPermissionAttribute クラスを使用した承認

コンピューター上のリソースへのアクセスを制限する必要がある場合、最も簡単な方法は PrincipalPermissionAttribute クラスを使用することです。 この属性を使用すると、ユーザーが指定の Windows グループまたはロールに属しているか、特定のユーザーであることを要求して、サービス操作の呼び出しを制限できます。 詳細については、「方法: PrincipalPermissionAttribute クラスでアクセスを制限する」を参照してください。

権限借用

偽装は、リソース アクセスの制御に使用できるもう 1 つの機構です。 既定では、IIS でホストされるサービスは、ASPNET アカウントの ID で実行されます。 ASPNET アカウントは、アクセス許可のあるリソースにだけアクセスできます。 ただし、ASPNET サービス アカウントを除外し、他の特定の ID によるフォルダーへのアクセスを許可するように ACL を設定できます。 ここで問題となるのが、ASPNET アカウントがフォルダーにアクセスできない場合に、他のユーザーがフォルダーにアクセスできるようにする方法です。 これは、偽装を使用することで解決できます。偽装によって、サービスは特定のリソースにアクセスするためにクライアントの資格情報を使用できます。 もう 1 つの例は、特定のユーザーだけがアクセス許可を持つ SQL Server データベースにアクセスする場合です。 偽装の使用方法の詳細については、「方法: サービスでクライアントに偽装する」および委任と偽装に関するページを参照してください。

インターネット上のセキュリティ

インターネット上のセキュリティは、イントラネット上のセキュリティと同じ要件で構成されます。 サービスは、信頼性を証明するために資格情報を提示する必要があり、クライアントは、サービスに対して ID を証明する必要があります。 クライアントの ID が証明されると、サービスは、クライアントによるリソースへのアクセスを制御できます。 ただし、インターネットではさまざまな種類が混在しているので、提示される資格情報は、Windows ドメインで使用される資格情報とは異なります。 Kerberos コントローラーが資格情報のチケットを使用して、ドメインでユーザーの認証を処理するのに対し、インターネットでは、サービスとクライアントは、資格情報を提示するための複数の異なる方法のいずれかに依存します。 なお、このトピックの目的は、インターネット上でアクセスできる WCF サービスを作成するための一般的な方法を示すことです。

IIS と ASP.NET の使用

インターネット セキュリティの要件、およびその問題を解決するための機構は、新しいものではありません。 IIS は、Microsoft のインターネット用 Web サーバーであり、それらの問題に対処するセキュリティ機能を多数備えています。また、ASP.NET には、WCF サービスで使用できるセキュリティ機能が含まれています。 これらのセキュリティ機能を利用するには、IIS 上で WCF サービスをホストします。

ASP.NET メンバーシップとロール プロバイダーの使用

ASP.NET には、メンバーシップとロール プロバイダーが用意されています。 プロバイダーは、呼び出し元を認証するためのユーザー名とパスワードの組み合わせのデータベースであり、これによって、各呼び出し元のアクセス特権を指定することもできます。 WCF では、構成を通して既存のメンバーシップとロール プロバイダーを容易に使用することができます。 この機能を示すサンプル アプリケーションについては、「 Membership and Role Provider 」のサンプルを参照してください。

IIS で使用する資格情報

Kerberos コントローラーによるサポートがある Windows ドメインとは異なり、インターネットには、随時ログオンしている多数のユーザーを管理するための共通のコントローラーがありません。 代わりに、インターネットの資格情報は、ほとんどの場合、X.509 証明書 (SSL (Secure Sockets Layer) 証明書とも呼ばれる) の形で提示されます。 この証明書は、通常、 証明機関によって発行されます。この証明機関は、証明書の信頼性を保証するサードパーティの企業および証明書が発行された個人です。 インターネット上にサービスを公開するには、このような信頼された証明書を提供して、サービスを認証する必要があります。

それでは、どのように信頼された証明書を取得するのでしょうか。 その方法の 1 つは、サービスを展開する準備とそのサービスの証明書を購入する準備ができたら、Authenticode、VeriSign などのサードパーティ証明機関に連絡する方法です。 ただし、WCF を使用した開発フェーズにおいて証明書を購入する準備ができていなくても、運用環境への展開のシミュレーションに使用できる X.509 証明書を作成するためのツールと方法が用意されています。 詳細については、「証明書の使用」を参照してください。

セキュリティ モード

WCF のセキュリティをプログラムする場合は、いくつか重要な決定を行う必要があります。 最も基本的な決定の 1 つは、 セキュリティ モードを選択することです。 2 つの主要なセキュリティ モードとして、 トランスポート モード と メッセージ モードがあります。

3 番目のモードは、2 つの主要モードのセマンティクスを組み合わせたもので、 メッセージ資格情報付きトランスポート モードです。

セキュリティ モードによって、メッセージをセキュリティで保護する方法が決まります。それぞれのモードには、次に示す利点と欠点があります。 セキュリティ モードの設定の詳細については、「方法: セキュリティ モードを設定する」を参照してください。

トランスポート モード

ネットワークとアプリケーションの間には複数の層があります。 これらの 1 つが "トランスポート" 層で、エンドポイント間のメッセージ転送を管理します。 当面は、WCF で複数のトランスポート プロトコルが使用され、各プロトコルによってメッセージの転送をセキュリティで保護できるということを理解しておくだけで十分です (トランスポートの詳細については、トランスポートに関するページを参照してください)。

一般的に使用されるプロトコルは HTTP ですが、その他にも TCP があります。 この各プロトコルは、プロトコルに固有の機構によってメッセージ転送をセキュリティで保護できます。 たとえば、HTTP プロトコルは SSL over HTTP (一般的に "HTTPS" と省略される) を使用してセキュリティで保護されます。そのため、セキュリティのトランスポート モードを選択するときは、同時に、プロトコルによって指定された機構の使用を選択することになります。 たとえば、 WSHttpBinding クラスを選択し、そのセキュリティ モードをトランスポートに設定した場合、セキュリティ機構として SSL over HTTP (HTTPS) を選択することになります。 トランスポート モードの利点は、セキュリティが比較的低いレベルで統合されるので、メッセージ モードよりも効率的であるという点です。 トランスポート モードを使用するとき、トランスポートの仕様に基づいてセキュリティ機構を実装する必要があります。これによって、トランスポートを経由した Point-to-Point からのみメッセージを安全にフローできます。

メッセージ モード

一方、メッセージ モードでは、セキュリティ データを各メッセージの一部として追加することによってセキュリティを提供します。 XML および SOAP のセキュリティ ヘッダーを使用して、メッセージの整合性と機密性を確保するために必要な資格情報とその他のデータを各メッセージに追加します。 各メッセージにはセキュリティ データが追加され、各メッセージを個別に処理する必要があるので、パフォーマンスが犠牲になります (トランスポート モードでは、トランスポート層がセキュリティで保護されると、すべてのメッセージが自由にフローされます)。ただし、メッセージ セキュリティには、トランスポート セキュリティに勝る利点が 1 つあります。それは、柔軟性に優れていることです。 つまり、セキュリティ要件はトランスポートによって決定されません。 メッセージをセキュリティで保護するために、任意の種類のクライアント資格情報を使用できます (トランスポート モードでは、トランスポート プロトコルによって、使用できるクライアント資格情報の種類が決まります)。

メッセージ資格情報付きトランスポート

3 番目のモードは、トランスポート セキュリティとメッセージ セキュリティの利点を組み合わせています。 このモードでは、トランスポート セキュリティを使用して、各メッセージの機密性と整合性を効率的に確保できます。 同時に、各メッセージには、その資格情報データが追加されるので、メッセージを認証できます。 認証と共に、承認も実装できます。 送信者を認証することによって、送信者の ID に応じてリソースへのアクセスが許可または拒否されます。

クライアント資格情報の種類と資格情報の値の指定

セキュリティ モードを選択した後で、必要に応じて、クライアント資格情報の種類を指定することもできます。 クライアント資格情報の種類では、サービスでの認証時にクライアントが使用する必要がある種類を指定します。

ただし、すべてのシナリオにクライアント資格情報の種類が必要とは限りません。 SSL over HTTP (HTTPS) を使用して、サービスはクライアントに対して認証を行います。 この認証の一部として、 ネゴシエーションと呼ばれるプロセスで、サービスの証明書がクライアントに送信されます。 SSL によってセキュリティで保護されたトランスポートによって、すべてのメッセージの機密性が確保されます。

クライアントの認証が必要なサービスを作成している場合、クライアント資格情報の種類の選択肢は、選択したトランスポートとモードによって異なります。 たとえば、HTTP トランスポートを使用して、トランスポート モードを選択する場合、基本、ダイジェストなどのいくつかの選択肢があります (これらの資格情報の種類の詳細については、「HTTP 認証の理解」をご覧ください)。

Windows ドメインで、そのネットワークの他のユーザーだけが利用できるサービスを作成している場合、最も使いやすいのは、Windows クライアント資格情報の種類です。 ただし、場合によっては、サービスにも証明書を提供する必要があります。 詳細については、「 How to: Specify Client Credential Values」を参照してください。

資格情報の値

資格情報の値 とは、サービスが使用する実際の資格情報です。 資格情報の種類を指定したら、サービスを実際の資格情報で構成する必要があります。 Windows を選択し、サービスを Windows ドメインで実行する場合は、実際の資格情報の値を指定しません。

ID

WCF では、ID という用語はサーバーとクライアントでその意味が異なります。 つまり、サービスを実行しているとき、ID は認証後にセキュリティ コンテキストに割り当てられます。 実際の ID を表示するには、 WindowsIdentity クラスの PrimaryIdentity プロパティと ServiceSecurityContext プロパティを確認します。 詳細については、「方法: セキュリティ コンテキストを調べる」を参照してください。

反対に、クライアントでは、ID はサービスを検証するために使用されます。 デザイン時に、クライアント開発者は <identity> 要素をサービスから取得した値に設定できます。 実行時に、クライアントは、要素の値をサービスの実際の ID と照合してチェックします。 チェックが失敗した場合、クライアントは通信を終了します。 特定のユーザー ID でサービスを実行している場合の値はユーザー プリンシパル名 (UPN) で、コンピューター アカウントでサービスを実行している場合の値はサービス プリンシパル名 (SPN) です。 詳細については、「サービス ID と認証」を参照してください。 資格情報には、証明書、つまり証明書を識別する証明書内のフィールドも使用できます。

保護レベル

ProtectionLevel プロパティは、 ServiceContractAttribute クラス、 OperationContractAttribute クラスなどのいくつかの属性クラスで使用します。 保護レベルは、サービスをサポートするメッセージ (またはメッセージ部分) が署名されるのか、署名および暗号化されるのか、または署名と暗号化なしで送信されるのかを指定する値です。 このプロパティの詳細については、「保護レベルの理解」を参照してください。プログラミング例については、「方法: ProtectionLevel プロパティを設定する」を参照してください。 コンテキスト内で ProtectionLevel を使用してサービス コントラクトを設計する方法については、「サービス コントラクトの設計」を参照してください。

関連項目