サービスのセキュリティ保護
Windows Communication Foundation (WCF) サービスのセキュリティは、転送セキュリティと承認という 2 つの主要要件で構成されます(3 番目の要件であるセキュリティ イベントの監査については、「セキュリティ イベントの監査」を参照してください)。簡単に説明すると、転送セキュリティは、認証 (サーバーとクライアント両方の ID の検証)、機密性 (メッセージの暗号化)、および整合性 (改ざんを検出するためのデジタル署名) で構成されます。承認は、たとえば、特権のあるユーザーだけがファイルを読み取ることができるなど、リソースへのアクセスを制御することです。WCF の機能を使用すれば、この 2 つの主要要件を簡単に実装できます。
BasicHttpBinding クラス (または構成の <basicHttpBinding> 要素) を除き、すべての定義済みバインディングでは既定で転送セキュリティが有効になっています。このセクションのトピックでは、2 つの基本的なシナリオ、インターネット インフォメーション サービス (IIS) でホストされるイントラネット サービス上で転送セキュリティと承認を実装するシナリオと、IIS でホストされるサービス上で転送セキュリティと承認を実装するシナリオについて説明します。
.gif "ms734769.note(ja-jp,VS.90).gif") メモ : |
|---|
| Windows XP Home では、Windows 認証をサポートしていません。このため、このシステムではサービスを実行しないでください。 |
セキュリティの基礎
セキュリティは、資格情報に依存します。資格情報は、エンティティが本物であることを証明します(エンティティには、個人、ソフトウェア プロセス、会社、および承認できるものすべてが当てはまります)。たとえば、サービスのクライアントが 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 データベースにアクセスする場合です。偽装の使用詳細については、 、「方法 : サービスでクライアントに偽装する」および「WCF の委任と偽装」を参照してください。
インターネット上のセキュリティ
インターネット上のセキュリティは、イントラネット上のセキュリティと同じ要件で構成されます。サービスは、信頼性を証明するために資格情報を提示する必要があり、クライアントは、サービスに対して ID を証明する必要があります。クライアントの ID が証明されると、サービスは、クライアントによるリソースへのアクセスを制御できます。ただし、インターネットではさまざまな種類が混在しているので、提示される資格情報は、Windows ドメインで使用される資格情報とは異なります。Kerberos コントローラが資格情報のチケットを使用して、ドメインでユーザーの認証を処理するのに対し、インターネットでは、サービスとクライアントは、資格情報を提示するための複数の異なる方法のいずれかに依存します。なお、このトピックの目的は、インターネット上でアクセスできる WCF サービスを作成するための一般的な方法を示すことです。
IIS と ASP.NET の使用
インターネット セキュリティの要件、およびその問題を解決するための機構は、新しいものではありません。IIS は、マイクロソフトのインターネット用 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 は複数のトランスポート プロトコルを使用し、各プロトコルによってメッセージの転送をセキュリティで保護できるということをだけを理解しておいてください (トランスポート詳細については、 、「Windows Communication Foundation のトランスポート」を参照してください)。
一般的に使用されるプロトコルは 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 クライアント資格情報の種類です。ただし、場合によっては、サービスにも証明書を提供する必要があります。詳細については、「方法 : クライアントの資格情報の値を指定する」を参照してください。
資格情報の値
資格情報の値とは、サービスが使用する実際の資格情報です**。資格情報の種類を指定したら、サービスを実際の資格情報で構成する必要があります。Windows を選択し、サービスを Windows ドメインで実行する場合は、実際の資格情報の値を指定しません。
ID
WCF では、ID という用語はサーバーとクライアントで意味が異なります**。つまり、サービスを実行しているとき、ID は認証後にセキュリティ コンテキストに割り当てられます。実際の ID を表示するには、ServiceSecurityContext クラスの WindowsIdentity プロパティと PrimaryIdentity プロパティを確認します。詳細な情報については、次のページを参照してください。 「方法 : セキュリティ コンテキストを調べる」を参照してください。
反対に、クライアントでは、ID はサービスを検証するために使用されます。デザイン時に、クライアント開発者は <identity> 要素をサービスから取得した値に設定できます。実行時に、クライアントは、要素の値をサービスの実際の ID と照合してチェックします。チェックが失敗した場合、クライアントは通信を終了します。特定のユーザー ID でサービスを実行している場合の値はユーザー プリンシパル名 (UPN) で、コンピュータ アカウントでサービスを実行している場合の値はサービス プリンシパル名 (SPN) です。詳細な情報については、次のページを参照してください。 「サービス ID と認証」を参照してください。資格情報には、証明書、つまり証明書を識別する証明書内のフィールドも使用できます。
保護レベル
ProtectionLevel プロパティは、ServiceContractAttribute クラス、OperationContractAttribute クラスなどのいくつかの属性クラスで使用します。保護レベルは、サービスをサポートするメッセージ (またはメッセージ部分) が署名されるのか、署名および暗号化されるのか、または署名と暗号化なしで送信されるのかを指定する値です。プロパティ詳細については、 、「保護レベルの理解」を参照してください。プログラミング例については、「方法 : ProtectionLevel プロパティを設定する」を参照してください。コンテキストで ProtectionLevel を使用してサービス コントラクトを設計する方法詳細については、 、「サービス コントラクトの設計」を参照してください。
関連項目
タスク
方法 : ProtectionLevel プロパティを設定する
方法 : Windows 資格情報でサービスをセキュリティで保護する
方法 : セキュリティ モードを設定する
方法 : クライアントの資格情報の種類を指定する
方法 : PrincipalPermissionAttribute クラスでアクセスを制限する
方法 : サービスでクライアントに偽装する
方法 : セキュリティ コンテキストを調べる
リファレンス
System.ServiceModel
ServiceCredentials
ServiceContractAttribute
OperationContractAttribute
概念
サービス ID と認証
保護レベルの理解
WCF の委任と偽装
サービス コントラクトの設計
セキュリティの概要