セキュリティ保護された Web サービスを構築する
公開日: 2004年9月7日 | 最終更新日: 2004年9月7日
トピック
.gif)
モジュールの内容
目的
適用対象
モジュールの使用方法
概要
脅威とその対策
設計に関する考慮事項
入力検証
認証
承認
機密性の高いデータ
パラメータ改ざん
例外管理
監査とログ記録
プロキシに関する考慮事項
コード アクセス セキュリティに関する考慮事項
展開に関する考慮事項
要約
その他のリソース
モジュールの内容
Web サービスを作成および展開する組織や組織は増加の一途をたどっています。通常、このような Web サービスの作成や展開を行う場合は、セキュリティに与える影響を十分に理解する必要があります。このモジュールでは、Web サービスを安全に設計、設定および展開する方法について説明します。外部からの要求を受け取るアプリケーションにとって入力検証は非常に重要であるため、適切に作成された要求だけを受け取るための方法もいくつか示します。このモジュールでは、Web サービスへのアクセスを認証されたユーザーに限定し、アクセスしたユーザーの動作をログに記録したり監査するためのさまざまな認証方法についても詳しく説明します。
また、WS-Security (Web Services Security) と関連の最新標準ファミリをサポートする Microsoft の Web Services Enhancements 1.0 for Microsoft® .NET (WSE) についても説明します。
目的
このモジュールの目的は次のとおりです。
-
セキュリティ保護された Web サービスを設計および展開する。
-
Web サービス入力を、強く型付けされたパラメータおよび XSD スキーマを使用して検証する。
-
Web サービス クライアントを認証する。
-
Web サービスへのアクセスを承認する。
-
Web サービス メッセージの機密性および整合性を保護する。
-
展開シナリオ (イントラネット、エクストラネット、インターネット) に合わせて実装するセキュリティ オプションを選択する。
-
Web Services Enhancements 1.0 for Microsoft .NET (WSE) について学習する。
-
.NET Framework のコンシューマ コードを保護するためのコード アクセス セキュリティの使用方法を学習する。
-
不正なアクセス、パラメータ改ざん、ネットワーク盗聴、構成データの漏えい、メッセージ リプレイなどの一般的な Web サービスの脅威に対処するための対策について理解する。
適用対象
このモジュールは、次の製品およびテクノロジに適用されます。
モジュールの使用方法
このモジュールから最大限の成果を得るには、以下を参照してください。
-
モジュール 19「ASP.NET アプリケーションと Web サービスをセキュリティ保護する」を参照してください。このモジュールでは、管理者向けに、十分にセキュリティ保護されていないアプリケーションをセキュリティ保護された状態にするための ASP.NET Web アプリケーションまたは Web サービスの設定方法について説明しています。
-
モジュール 17「アプリケーション サーバーをセキュリティ保護する」を参照してください。このモジュールでは、リモート アプリケーション サーバーの考慮事項を確認できます。
-
このガイドの「チェックリスト: Web サービスをセキュリティ保護する」を参照してください。このチェックリストには、セキュリティ保護された Web サービスを構築および設定するために必要なセキュリティの方法がまとめられています。
-
このモジュールでは、メッセージ レベルの脅威と、それらの脅威の対策について理解できます。
-
アプリケーション カテゴリを、一般的な問題の解決方法として使用してください。ここでは、関連情報を 3 つのカテゴリに分類しています。
概要
製品やサービスを、インターネットや組織のエクストラネットを介して顧客やビジネス パートナーに公開する企業の増加に伴い、Web サービスを利用する企業も増えてきています。これらのサービス プロバイダにとって、セキュリティ要件は非常に重要です。両方のエンドポイントをある程度制御している、主にイントラネットまたはエクストラネット シナリオの場合は、オペレーティング システムや Internet Information Services (IIS) によって提供されるプラットフォームベースのセキュリティ サービスを使用してポイントツーポイントのセキュリティ ソリューションを提供できます。しかし、利用数が拡大している Web サービスのメッセージ ベースのアーキテクチャや信頼境界にまたがる異種環境は新たな課題に直面しています。これらのシナリオでは、クロスプラットフォームの相互運用性や複数の中間ノードを介したルーティングをサポートするために、メッセージ レベルでのセキュリティについて考慮する必要があります。
Web Services Security (WS-Security) は、これらの問題を解決するために設計された最新のセキュリティ標準です。Microsoft は、WS-Security と関連の最新標準ファミリをサポートする、Web Services Enhancements 1.0 for Microsoft .NET (WSE) をリリースしています。WSE を使用すると、認証、暗号化、デジタル署名など、メッセージ レベルのセキュリティ ソリューションを実装できます。
注: WSE がサポートする仕様と標準は今後も強化されていくため、現在の WSE と将来のバージョンとの互換性は保証されません。このガイドの作成時点では、IBM や VeriSign などのベンダーによって Microsoft 以外のツールキットを利用した相互運用テストが実施されています。
脅威とその対策
セキュリティ保護された Web サービスを構築するには、関連する脅威について理解する必要があります。Web サービスを標的とした主な脅威には、次のものがあります。
-
不正なアクセス
-
パラメータ改ざん
-
ネットワーク盗聴
-
構成データの漏えい
-
メッセージ リプレイ
図 12.1 に、Web サービスを標的とした主な脅威と攻撃を示します。
.jpg)
図 12.1
主な Web サービスの脅威
不正なアクセス
機密情報や制限された情報を提供する Web サービスは、呼び出し側のユーザーを認証して承認する必要があります。不十分な認証や承認は、機密情報や操作への不正なアクセスに悪用される可能性があります。
脆弱性
Web サービスを介して行われる不正なアクセスの原因となる脆弱性には、次のものがあります。
対策
不正なアクセスを防止するには、次の対策を実行できます。
-
SOAP ヘッダーにパスワード ダイジェストを使用して認証します。
-
SOAP ヘッダーに Kerberos チケットを使用して認証します。
-
SOAP ヘッダーに X.509 証明書を使用して認証します。
-
Windows 認証を使用します。
-
ロール ベースの認証を使用して Web サービスへのアクセスを制限します。この対策を実行するには、URL 承認を使用して Web サービス ファイル (.asmx) へのアクセスを制御するか、主要なアクセス許可要求を使用して Web メソッド レベルでアクセスを制御します。
パラメータ改ざん
パラメータ改ざんとは、Web サービスの利用者と Web サービスの間でやりとりされるデータを不正に改ざんすることです。たとえば、攻撃者は、ルート内の中間ノードを介してその宛先にたどりつき、Web サービス メッセージを傍受する可能性があります。また、傍受したメッセージを宛先のエンドポイントに送信する前に改ざんする可能性もあります。
脆弱性
パラメータ改ざんの原因となる脆弱性には、次のものがあります。
対策
パラメータ改ざんを防止するには、次の対策を実行できます。
ネットワーク盗聴
ネットワーク盗聴により、攻撃者はネットワーク上でやりとりされる Web サービス メッセージを参照する可能性があります。たとえば、攻撃者は、ネットワーク監視ソフトウェアを使用して、SOAP メッセージに含まれている機密データを取得することがあります。このデータには、機密性の高いアプリケーション レベルのデータや機密情報が含まれる可能性があります。
脆弱性
ネットワーク盗聴の原因となる脆弱性には、次のものがあります。
対策
ネットワーク上でやりとりする機密性の高い SOAP メッセージを保護するために、次の対策を実行できます。
構成データの漏えい
Web サービスでは、2 つの状況で構成データが漏えいする可能性があります。1 つは、Web サービスが Web Services Description Language (WSDL) の動的な生成をサポートしている場合、または Web サーバーで使用可能なダウンロード ファイルに WSDL 情報が記載されている場合です。これは、場合によっては望ましくない状況です。
注: WSDL は、Web サービスの特性 (そのメソッド署名やサポートされているプロトコルなど) を記述します。
もう 1 つは、例外処理が不適切に行われることによって、攻撃者にとって有用な機密性の高い内部実装の詳細が Web サービスで開示されてしまう場合です。
脆弱性
構成データの漏えいにつながる脆弱性には、次のものがあります。
対策
構成データの漏えいを防止するには、次の対策を実行できます。
-
NTFS 権限を使用して WSDL ファイルへのアクセスを承認します。
-
Web サーバーから WSDL ファイルを削除します。
-
WSDL の動的な生成を防止するために、ドキュメントのプロトコルを無効にします。
-
例外をキャプチャし、SoapException または SoadHeaderException をスローして、最小限の害のない情報だけをクライアントに返します。
メッセージ リプレイ
Web サービス メッセージは、複数の中間サーバーを経由する可能性があります。メッセージ リプレイ攻撃では、攻撃者は、メッセージをキャプチャしてコピーし、クライアントになりすましてそのメッセージを Web サービスにリプレイします。メッセージは改ざんされる場合と改ざんされない場合があります。
脆弱性
メッセージ リプﾚイの原因となる脆弱性には、次のものがあります。
攻撃
メッセージ リプレイ攻撃の最も一般的なタイプとしては、次のものがあります。
-
基本リプレイ攻撃: 攻撃者は、メッセージをキャプチャしてコピーしてから、同じメッセージをリプレイし、クライアントになりすまします。悪意のあるユーザーは、メッセージの内容を知らなくても、このリプレイ攻撃を行うことができます。
-
Man-in-the-Middle 攻撃: 攻撃者はメッセージをキャプチャしてから、その内容の一部 (出荷先の住所など) を変更して、メッセージを Web サービスにリプレイします。
対策
メッセージ リプレイの脅威に対処するには、次の対策を実行できます。
-
暗号化された通信チャネル (SSL など) を使用する。
-
メッセージのプライバシーを保護し、不正を防止するためにメッセージ ペイロードを暗号化する。この対策では、基本リプレイ攻撃は防げませんが、メッセージの内容がリプレイ前に改ざんされる Man-in-the-Middle 攻撃は防げます。
-
各要求に固有のメッセージ ID または nonce を使用して複製されたメッセージを検出し、メッセージにデジタル署名して不正を防止する。
注: nonce とは、要求に対して使用される暗号上の固有の値です。
サーバーは、クライアントに応答するときに固有の ID を送信し、その ID を含むメッセージに署名します。クライアントは、別の要求を行うときに、その ID をメッセージに含めます。サーバーは、前のメッセージでクライアントに送信した ID が、クライアントから届いた新しい要求に含まれていることを確認します。この ID が前の ID と異なる場合、サーバーは要求を拒否して、リプレイ攻撃が行われたものと推測します。
メッセージには署名が行われているため、攻撃者はメッセージ ID を偽装できません。この対策では、メッセージ要求を使用してクライアントから開始されたリプレイ攻撃からサーバーを保護することはできますが、リプレイされた応答についてクライアント側は保護できません。
設計に関する考慮事項
Web サービスの開発を開始する前に、設計時に考慮すべき事項が多数あります。セキュリティ関連の主要な考慮事項は、次のとおりです。
-
認証要件
-
プライバシーと整合性の要件
-
リソース アクセス ID
-
コード アクセス セキュリティ
認証要件
Web サービスで機密性の高い情報や制限された情報を提供する場合は、呼び出し側のユーザーを認証して承認をサポートする必要があります。Windows 環境では、Windows 認証を使用できます。ただし、両方のエンドポイントを制御していない場合は、WSE が提供する、最新の WS-Security 標準に準拠する認証ソリューションを使用します。WSE は、SOAP ヘッダーを使用して、ユーザー名やパスワード、Kerberos チケット、X.509 証明書、またはカスタム トークンの形式で認証の詳細を渡すための標準フレームワークを提供します。詳細については、このモジュールで後述する「認証」を参照してください。
プライバシーと整合性の要件
Web サービス要求メッセージまたは応答メッセージで機密性の高いアプリケーション データを渡す場合は、送信中にそれらのプライバシーを保護し、改ざんされないようにするための方法を検討する必要があります。WSE は、デジタル署名による整合性チェックを行い、メッセージ ペイロード全体の機密要素を暗号化する XML 暗号化もサポートします。このアプローチの長所は、最新の WS-Security 標準に基づいている点と、複数の中間ノードを介して渡されるメッセージのためのソリューションが提供されるという点です。
その他に、SSL や IPSec チャネルによるトランスポート レベルの暗号化も使用できます。これらのソリューションは、両方のエンドポイントを制御している場合に限り適用できます。
リソース アクセス ID
既定では、ASP.NET Web サービスで偽装は行われず、ローカルまたはリモートのリソース アクセスには、最小権限を持つ ASPNET プロセス アカウントが使用されます。この ASPNET プロセス アカウントを使用して、ミラー化されたローカル アカウントをデータベース サーバーに作成し、Windows 認証を必要とする SQL Server などのリモート ネットワーク リソースにアクセスできます。
注: Windows Server 2003 では、Web サービスの実行にネットワーク サービス アカウントが標準で使用されます。
リモート データベース アクセスでの ASP.NET プロセス アカウントの使用方法の詳細については、モジュール 19「ASP.NET アプリケーションと Web サービスをセキュリティ保護する」を参照してください。
偽装を使用する場合、Web アプリケーションに適用される問題や考慮事項は Web サービスにもあてはまります。詳細については、モジュール 10「セキュリティ保護された ASP.NET ページとコントロールを構築する」と、モジュール 19「ASP.NET アプリケーションと Web サービスをセキュリティ保護する」を参照してください。
コード アクセス セキュリティ
対象の展開環境のセキュリティ ポリシーで定義される信頼レベルを検討します。<trust> 要素設定で定義される Web サービスの信頼レベルは、アクセス可能なリソースのタイプ、および実行可能なその他の権限付き操作に影響します。
また、ASP.NET Web アプリケーションから Web サービスを呼び出す場合は、Web アプリケーションの信頼レベルによって、呼び出すことができる Web サービスの範囲が決まります。たとえば、中程度の信頼レベルに設定された Web アプリケーションでは、ローカル コンピュータの Web サービスだけを呼び出すことができます。
中程度の信頼レベルおよびその他の部分的に信頼された Web アプリケーションから Web サービスを呼び出す方法については、モジュール 9「ASP.NET でコード アクセス セキュリティを使用する」を参照してください。
入力検証
ビジネス ルールを強制的に適用し、発生する可能性があるセキュリティ上の問題を防止するには、入力データを受け入れるアプリケーションと同様に、Web サービスでも渡されたデータを検証する必要があります。WebMethod 属性が有効になっている Web メソッドは、Web サービスのエントリ ポイントです。Web メソッドは、強く型付けされた入力パラメータ、または多くの場合文字列データとして渡される、緩やかに型付けされたパラメータを受け入れることができます。これは、通常 Web サービスの設計対象となるコンシューマの範囲とタイプによって決まります。
強く型付けされたパラメータ
.NET Framework 型システムで記述されている強く型付けされたパラメータ (integer、double、date など)、または Address や Employee などのその他のカスタム オブジェクト型を使用すると、自動生成された XML スキーマ定義 (XSD) スキーマに、データの型記述が含まれます。コンシューマはこの型記述を使用して、Web メソッドに送信される SOAP 要求内に適切にフォーマットされた XML を構築できます。次に、ASP.NET は System.Xml.Serialization.XmlSerializer クラスを使用して、着信した SOAP メッセージを共通言語ランタイム (CLR) オブジェクトに逆シリアル復元します。次の例に、組み込みのデータ型で構成される強く型付けされた入力を受け取る Web メソッドを示します。
[WebMethod]
public void CreateEmployee(string name, int age, decimal salary) {...}
前の例では、.NET Framework の型システムが、型チェックを自動で行っています。name フィールドを介して指定される文字の範囲を検証するには、正規表現を使用します。たとえば、次のコードは、System.Text.RegularExpressions.Regex クラスを使用して、入力文字の可能な範囲を制約し、またパラメータの長さを検証する方法を示しています。
if (!Regex.IsMatch(name, @"^[a-zA-Z'.`-´\s]{1,40}$"))
{
// 無効な名前です。
}
正規表現の詳細については、モジュール 10「セキュリティ保護された ASP.NET ページとコントロールを構築する」の「入力検証」を参照してください。次の例に、カスタムの Employee データ型を受け取る Web メソッドを示します。
using Employees;// カスタムの名前空間です。
[WebMethod]
public void CreateEmployee(Employee emp) { ... }
コンシューマは、Web サービスを呼び出すことができる XSD スキーマを知っていることが必要です。コンシューマが .NET Framework クライアント アプリケーションである場合、コンシューマは Employee オブジェクトを次のように渡すだけです。
using Employees;
Employee emp = new Employee();
// Employee フィールドを設定します。
// Employee を Web サービスに送信します。
wsProxy.CreateEmployee(emp);
.NET Framework に基づいていないコンシューマ アプリケーションは、Web サービスを運用している組織が提供するスキーマ定義に基づいて、XML 入力を手動で構築する必要があります。
この強く型付けされたパラメータ アプローチの長所は、.NET Framework が自動で入力データを解析し、型定義に基づいてそのデータを検証してくれるという点です。ただし、Web メソッド内部では、入力データを制限する必要があります。たとえば、型システムによって有効な Employee オブジェクトが確認された場合でも、Employee フィールドに対してさらに検証を行う必要があります。従業員の誕生日が 18 年前よりも前であることを検証する必要があるとします。この場合は、name フィールドなどで使用可能な文字の範囲を制限するために正規表現を使用する必要があります。
入力制限の詳細については、モジュール 10「セキュリティ保護された ASP.NET ページとコントロールを構築する」の「入力検証」を参照してください。
緩やかに型付けされたパラメータ
文字列パラメータまたはバイト配列を使用して、任意のデータを渡す場合は、.NET Framework 型システムの多くの長所を利用できません。自動生成された WSDL は、型 xsd:string の文字列入力として単にパラメータを記述するだけなので、入力パラメータを手動で解析して検証する必要があります。次の例に示すように、型、長さ、形式、および範囲を、プログラムによってチェックする必要があります。
[WebMethod]
public void SomeEmployeeFunction(string dateofBirth, string SSN)
{
. . .
// 例 1: 日付の型チェック
try
{
DateTime dt = DateTime.Parse(dateofBirth).Date;
}
// 型変換に失敗すると、FormatException がスローされます。
catch( FormatException ex )
{
// 無効な日付です。
}
// 例 2:社会保障番号の長さ、形式、および範囲のチェック
if( !Regex.IsMatch(empSSN,@"^\d{3}-\d{2}-\d{4}$",RegexOptions.None))
{
// 無効な社会保障番号です。
}
} XML データ
標準的な B2B シナリオでは、コンシューマは、注文書や請求書などのビジネス文書を表す XML データを渡すのが一般的です。入力データを処理してダウンストリーム コンポーネントに渡す前に、Web メソッドで入力データをプログラムにより検証する必要があります。
クライアントとサーバーは XML を記述するスキーマを確立して、それに同意する必要があります。以下のコードで、Web メソッドで System.Xml.XmlValidatingReader クラスを使用して、入力データ (この例では、単純な書籍の注文に関する記述) を検証する方法を示します。XML データは単純な文字列パラメータを介して渡されます。
using System.Xml;
using System.Xml.Schema;
[WebMethod]
public void OrderBooks(string xmlBookData)
{
try
{
// 検証リーダーを作成し、ロードします。
XmlValidatingReader reader = new XmlValidatingReader(xmlBookData,
XmlNodeType.Element,
null);
// XSD スキーマをリーダーに接続します。
reader.Schemas.Add("urn:bookstore-schema",
@"http://localhost/WSBooks/bookschema.xsd");
// XSD スキーマの検証タイプを設定します。
// XDR スキーマと DTD もサポートされます。
reader.ValidationType = ValidationType.Schema;
// 検証エラーを処理するイベント ハンドラを作成および登録します。
reader.ValidationEventHandler += new ValidationEventHandler(
ValidationErrors );
// 入力データを処理します。
while (reader.Read())
{
. . .
}
// 検証は正常に実行されました。
}
catch
{
. . .
}
}
// 検証エラー イベント ハンドラ
private static void ValidationErrors(object sender, ValidationEventArgs args)
{
// args.Message でエラーの詳細を取得できます。
. . .
}
次の例に、コンシューマが前述の Web メソッドを呼び出す方法を示します。
string xmlBookData = "<book xmlns='urn:bookstore-schema'
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'>" +
"<title>Building Secure ASP.NET Applications</title>" +
"<isbn>0735618909</isbn>" +
"<orderQuantity>1</orderQuantity>" +
"</book>";
BookStore.BookService bookService = new BookStore.BookService();
bookService.OrderBooks(xmlBookData));
前の例では、次の簡単な XSD スキーマを使用して入力データを検証します。
<?xml version="1.0" encoding="utf-8" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="urn:bookstore-schema"
elementFormDefault="qualified"
targetNamespace="urn:bookstore-schema">
<xsd:element name="book" type="bookData"/>
<xsd:complexType name="bookData">
<xsd:sequence>
<xsd:element name="title" type="xsd:string" />
<xsd:element name="isbn" type="xsd:integer" />
<xsd:element name="orderQuantity" type="xsd:integer"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
次の表に、追加の複雑な要素定義を示します。これらの定義は、XSD スキーマで個々の XML 要素をさらに制限する場合に使用できます。
表 12.1: XSD スキーマ要素の例
| 説明 | 例 |
| 正規表現を使用して XML 要素を制限する | <xsd:element name="zip">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:pattern value="\d{5}(-\d{4})?" />
</xsd:restriction>
</xsd:simpleType>
</xsd:element> |
| 小数点の後の 10 進値を 2 桁に制限する | <xsd:element name="Salary">
<xsd:simpleType>
<xsd:restriction base="xsd:decimal">
<xsd:fractionDigits value="2" />
</xsd:restriction>
</xsd:simpleType>
</xsd:element> |
| 入力文字列の長さを制限する |
<xsd:element name="FirstName">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:maxLength value="50" />
<xsd:minLength value="2" />
</xsd:restriction>
</xsd:simpleType>
</xsd:element> |
| 入力を、列挙型によって定義された値に制限する | <xsd:element name="Gender">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="Male" />
<xsd:enumeration value="Female" />
</xsd:restriction>
</xsd:simpleType>
</xsd:element> |
詳細については、次のサポート技術情報の文書を参照してください。
SQL インジェクション
SQL インジェクションによって、攻撃者は、Web サービスのデータベース ログインを使用してデータベースで任意のコマンドを実行する可能性があります。SQL インジェクションとは、入力データを使用して SQL クエリを構築する Web サービスで発生する可能性がある問題です。Web メソッドがデータベースにアクセスする場合は、SQL パラメータ、理想的にはパラメータ化されたストアド プロシージャを使用してアクセスする必要があります。SQL パラメータは、入力の型や長さを検証して、入力が実行可能コードではなく文字列として処理されていることを確認します。この対策およびその他の SQL インジェクション対策の詳細については、モジュール 14「セキュリティ保護されたデータ アクセスを構築する」の「入力検証」を参照してください。
クロスサイト スクリプティング
攻撃者は、クロスサイト スクリプティング (XSS) を使用してアプリケーションを悪用し、悪意のあるスクリプトをクライアント側で実行します。Web アプリケーションから Web サービスを呼び出し、Web サービスからの出力を HTML データ ストリームでクライアントに戻す場合に、XSS が発生する可能性があります。この場合は、Web アプリケーション内の Web サービスから受信した出力をエンコードしてから、クライアントに戻す必要があります。これは、独自の Web サービスを所有せず、Web サービスが Web アプリケーションの信頼境界外にある場合、特に重要です。XSS 対策の詳細については、モジュール 10「セキュリティ保護された ASP.NET ページとコントロールを構築する」の「入力検証」を参照してください。
認証
Web サービスで、機密性の高い、制限されたデータを出力する場合や、制限されたサービスを提供する場合は、呼び出し側の認証が必要です。多くの認証スキームが利用できますが、これらのスキームは大きく次の 3 つのカテゴリに分類されます。
-
プラットフォーム レベルの認証
-
メッセージ レベルの認証
-
アプリケーション レベルの認証
プラットフォーム レベルの認証
両方のエンドポイントを制御し、両方のエンドポイントが同じドメインまたは信頼するドメイン内にある場合は、Windows 認証を使用して呼び出し側を認証できます。
基本認証
IIS を使用して Web サービスの仮想ディレクトリを基本認証用に設定できます。このアプローチでは、コンシューマはプロキシを設定し、資格情報をユーザー名とパスワードとして提供する必要があります。プロキシは、それらの資格情報をそのプロキシを介して各 Web サービス要求と共に送信します。資格情報はプレーンテキストで送られるため、基本認証は SSL と組み合わた場合にだけ使用できます。
次のコードに、Web アプリケーションでエンド ユーザーから提供された認証資格情報を抽出し、それらの資格情報を使用して、IIS で基本認証用に設定されたダウンストリームの Web サービスを呼び出す方法を示します。
// 基本認証で利用可能なクライアントの資格情報を取得します。
string pwd = Request.ServerVariables["AUTH_PASSWORD"];
string uid = Request.ServerVariables["AUTH_USER"];
// 資格情報を設定します。
CredentialCache cache = new CredentialCache();
cache.Add( new Uri(proxy.Url),// Web サービスの URL
"Basic",
new NetworkCredential(uid, pwd, domain) );
proxy.Credentials = cache;
統合 Windows 認証
IIS を使用して Web サービスの仮想ディレクトリを統合 Windows 認証用に設定し、クライアントおよびサーバー環境に応じて Kerberos または NTLM 認証を実行できます。このアプローチではネットワーク上で資格情報が送信されないため、基本認証に比べ、ネットワーク盗聴の脅威がないという長所があります。
統合 Windows 認証用に設定された Web サービスを呼び出すには、コンシューマがプロキシに Credentials プロパティを明示的に設定する必要があります。
クライアントの Windows セキュリティ コンテキストのセキュリティ コンテキストを、(偽装したスレッド トークンまたはプロセス トークンのどちらかから) Web サービスにフローするには、次に示すように、Web サービス プロキシの Credentials プロパティを CredentialCache.DefaultCredentials に設定します。
proxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
また次のように、1 組みの資格情報を明示的に使用することもできます。
CredentialCache cache = new CredentialCache();
cache.Add( new Uri(proxy.Url),// Web サービスの URL
"Negotiate",// Kerberos または NTLM
new NetworkCredential(userName, password, domain));
proxy.Credentials = cache;
明示的な資格情報を指定する必要がある場合は、それらの資格情報をハード コードしたり、プレーンテキストで保存しないでください。アカウントの資格情報は、DPAPI を使用して暗号化し、暗号化したデータは、Web.config の <appSettings> 要素内または制限されたレジストリ キーの下に保存します。
プラットフォーム レベルの認証の詳細については、 Microsoft patterns & practices「セキュリティ保護された ASP.NET アプリケーションの構築」(http://www.microsoft.com/japan/msdn/net/security/secnetlpMSDN.aspx) を参照してください。
メッセージ レベルの認証
WSE を使用して、最新の WS-Security 標準に準拠するメッセージ レベルの認証ソリューションを実装できます。このアプローチでは、SOAP ヘッダーによる通常の方法で認証トークンを渡すことができます。
注: メッセージを送受信する両方の当事者が WS-Security を使用することに同意した場合は、認証トークンの正確なフォーマットについても同意する必要があります。
WSE では、次のタイプの認証トークンを使用できます。
-
ユーザー名とパスワード
-
Kerberos チケット
-
X.509 証明書
ユーザー名とパスワード
ユーザー名とパスワードの資格情報は SOAP ヘッダーで送信できます。ただし、これらの資格情報はプレーンテキストで送信され、ネットワーク盗聴の脅威を受ける可能性があるため、このアプローチは必ず SSL と組み合わせて使用してください。資格情報は、次のように SOAP ヘッダーで <Security> 要素の一部として送信されます。
<wsse:Security
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext">
<wsse:UsernameToken>
<wsse:Username>Yamaguchi</wsse:Username>
<wsse:Password>YourStr0ngPassWord</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
ユーザー名とパスワード ダイジェスト
プレーンテキストのパスワードを送信する代わりに、パスワード ダイジェストを送ることができます。ダイジェストは、UTF8 のエンコードされた SHA1 ハッシュ値である Base64 でエンコードされたパスワードです。ただし、このアプローチをセキュリティで保護されたチャネルで使用しない場合、攻撃者が、ネットワーク監視ソフトウェアを使用してデータを傍受し、そのデータを再利用して Web サービスへの認証アクセスを取得する可能性があります。このリプレイ攻撃の脅威に対処するには、nonce と作成タイムスタンプをダイジェストに結合します。
nonce とタイムスタンプを取り入れたユーザー名とパスワード ダイジェスト
このアプローチでは次のように、ダイジェストが nonce 値、作成タイムスタンプ、およびパスワードの SHA1 ハッシュになります。
digest = SHA1(nonce + creation timestamp + password)
このアプローチを使用する場合は、Web サービスで nonce 値のテーブルを維持して、重複している nonce 値を含むすべてのメッセージを拒否する必要があります。このアプローチによりパスワードを保護し、リプレイ攻撃を防止するための基盤を提供できますが、有効期限を計算するときにコンシューマとプロバイダ間でクロック同期の問題が発生します。また、攻撃者によるメッセージのキャプチャ、nonce 値の改ざん、および Web サービスへのメッセージのリプﾚイは防止することができません。この脅威に対処するには、メッセージにデジタル署名を行う必要があります。WSE では、カスタム トークンまたは X.509 証明書を使用してメッセージに署名できます。この方法により、公開キーと秘密キーのペアに基づいて、不正防止と認証を行うことができます。
Kerberos チケット
次のように、Kerberos チケットを含むセキュリティ トークンを送信できます。
<wsse:Security
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext">
<wsse:BinarySecurityToken
ValueType="wsse:Kerberosv5ST"
EncodingType="wsse:Base64Binary">
U87GGH91TT ...
</wsse:BinarySecurityToken>
</wsse:Security>
X.509 証明書
また、X.509 証明書を認証トークンとして送信して、認証を行うこともできます。
<wsse:Security
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext">
<wsse:BinarySecurityToken
ValueType="wsse:X509v3"
EncodingType="wsse:Base64Binary">
Hg6GHjis1 ...
</wsse:BinarySecurityToken>
</wsse:Security>
これらのアプローチの詳細については、WSE に付属のサンプルを参照してください。
アプリケーション レベルの認証
アプリケーションでカスタムの SOAP ヘッダーを使用して独自のカスタム認証を設計して構築できます。これを実行する前に、プラットフォームと WSE の機能を確認して、それらすべての機能が使用可能かどうかを確認してください。カスタムの認証メカニズムを使用する必要があり、さらに暗号化も必要な場合は、"System.Security.Cryptography" 名前空間で公開された標準の暗号化アルゴリズムを使用します。
承認
認証後、呼び出し側を、その ID またはロール メンバシップに基づいて、Web サービスで公開される機能のサブセットに制限できます。サービス エンドポイント (.asmx ファイル レベル)、個々の Web メソッド、またはWeb メソッド内の特定の機能へのアクセスを制限できます。
Web サービス エンドポイントの承認
Web サービスを統合 Windows 認証用に設定している場合は、Web サービス (.asmx) ファイルに NTFS アクセス許可を設定し、元の呼び出し側のセキュリティ コンテキストに基づいてアクセスを制御できます。この承認は、ASP.NET の FileAuthorizationModule で実行され、偽装の必要はありません。
認証タイプに関係なく、ASP.NET の UrlAuthorizationModule を使用して Web サービス (.asmx) ファイルへのアクセスを制御できます。これを設定するには、Machine.config または Web.config の <authorization> 要素に <allow> および <deny> 要素を追加します。
この 2 つの承認フォームの詳細については、モジュール 19「ASP.NET アプリケーションと Web サービスをセキュリティ保護する」の「承認」を参照してください。
Web メソッドの承認
宣言型の主要なアクセス許可要求を使用して、呼び出し側の ID またはロール メンバシップに基づいて個々の Web メソッドへのアクセスを制御できます。呼び出し側の ID およびロール メンバシップは、HttpContext.User を介してアクセスされる、現在の Web 要求に関連付けられたプリンシパル オブジェクトで維持されます。
[PrincipalPermission(SecurityAction.Demand, Role=@"Manager")]
[WebMethod]
public string QueryEmployeeDetails(string empID)
{
}
主要なアクセス許可要求の詳細については、モジュール 10「セキュリティ保護された ASP.NET ページとコントロールを構築する」の「承認」を参照してください。
プログラムによる承認
次に示すように、Web メソッド内で、細分化された承認ロジックの IPrincipal.IsInRole を呼び出して、命令型のアクセス許可チェックまたは明示的なロール チェックを使用できます。
// この例は Windows 認証以外の認証であること前提にしています。Windows 認証を使用する場合は、
// User オブジェクトを WindowsPrincipal にキャストし、Windows グループをロール名として
// 使用します。
GenericPrincipal user = User as GenericPrincipal;
if (null != user)
{
if ( user.IsInRole(@"Manager") )
{
// ユーザーは承認され、管理者機能を実行できるようになります。
}
} 機密性の高いデータ
Web サービス要求メッセージまたは応答メッセージで重要なアプリケーション データ (クレジット カード番号、従業員の個人情報など) を送る場合は、中間アプリケーション ノードでのネットワーク盗聴や情報漏えいの脅威に対処する必要があります。
両方のエンドポイントを制御している閉鎖的な環境では、SSL または IPSec を使用してトランスポート層暗号化を実行できます。その他の環境、およびメッセージが中間アプリケーション ﾉードを介してルーティングされる場合は、メッセージ レベルのソリューションが必要です。WS-Security 標準は、World Wide Web Consortium (W3C) の XML 暗号化標準に基づいて機密サービスを定義しており、SOAP メッセージの一部またはすべてを暗号化してからそのメッセージを送信できます。
XML 暗号化
SOAP メッセージのすべてまたは一部を暗号化するには、次の 3 つの方法があります。
-
X.509 証明書による非対称暗号化
-
共有キーによる対称暗号化
-
カスタムのバイナリ トークンによる対称暗号化
X.509 証明書による非対称暗号化
このアプローチでは、コンシューマは X.509 証明書の公開キーの部分を使用して SOAP メッセージを暗号化します。この暗号は、対応する秘密キーを所有するサービスだけが解読できます。
Web サービスが関連の秘密キーにアクセスできることが前提になります。既定では、WSE はローカルのコンピュータ ストアで X.509 証明書を検索します。次のように Web.config の <x509> 設定要素を使用して、保存場所を現在のユーザー ストアに設定できます。
<configuration>
<microsoft.web.services>
<security>
<x509 storeLocation="CurrentUser" />
</security>
</microsoft.web.services>
</configuration>
ユーザー ストアを使用する場合は、Web サービスのプロセス アカウントのユーザー プロファイルをロードする必要があります。既定の ASPNET 最小権限ローカル アカウントを使用して Web サービスを実行している場合は、.NET Framework バージョン 1.1 によってこのアカウントのユーザー プロファイルがロードされ、ユーザー キー ストアにアクセスできます。
.NET Framework バージョン 1.0 を使用して構築された Web サービスの場合は、ASPNET ユーザー プロファイルはロードされません。この場合は、次の 2 つのオプションを実行できます。
-
以前ユーザー プロファイルを作成するために Web サーバーに対話的にログオンしたときに使用した、カスタムの最小権限アカウントで Web サービスを実行する。
-
ローカルのコンピュータ ストアにキーを保存し、Web サービス プロセス アカウントに権限を付与する。Windows 2000 では、既定で ASPNET アカウントが使用されます。Windows Server 2003 では、既定でネットワーク サービス アカウントが使用されます。
権限を付与するには、Windows エクスプローラを使用して ACL を次のフォルダに設定し、Web サービス プロセス アカウントにフル コントロールを付与します。
\Documents and Settings\All Users\Application Data\
Microsoft\Crypto\RSA\MachineKeys
詳細については、WSE ドキュメントの「Managing X.509 Certificates」(英語)、「Encrypting a SOAP Message Using an X.509 Certificate」(英語)、および「Decrypting a SOAP Message Using an X.509 Certificate」(英語) を参照してください。
共有キーによる対称暗号化
対称暗号化では、Web サービスとそのコンシューマが秘密キーを共有して SOAP メッセージの暗号化と解読を行います。この暗号化は、非対称暗号化よりも迅速に実行できますが、コンシューマとサービス プロバイダは、キーを共有するために帯域外メカニズムを使用する必要があります。
詳細については、WSE ドキュメントの「Encrypting a SOAP Message Using a Shared Key」(英語) と「Decrypting a SOAP Message Using a Shared Key」(英語) を参照してください。
カスタムのバイナリ トークンによる対称暗号化
WSE を使用してカスタムのバイナリ トークンを定義し、メッセージの暗号化と解読に使用するカスタムのセキュリティ資格情報をカプセル化できます。コードには 2 つのクラスが必要です。送信側のクラスは BinarySecurityToken クラスから派生して、カスタムのセキュリティ資格情報をカプセル化し、メッセージを暗号化する必要があります。受信側のクラスは、DecryptionkeyProvider クラスから派生して、キーを取得し、メッセージを解読する必要があります。
詳細については、WSE ドキュメントの「Encrypting a SOAP Message Using a Custom Binary Security Token」(英語) と「Decrypting a SOAP Message Using a Custom Binary Security Token」(英語) を参照してください。
メッセージの一部を暗号化する
既定では、WSE は SOAP 本文全体を暗号化し、SOAP ヘッダー情報は暗号化しません。ただし、WSE を使用してメッセージの一部をプログラムにより暗号化または解読することもできます。
詳細については、WSE ドキュメントの「Specifying the Parts of a SOAP Message that are Signed or Encrypted」(英語) を参照してください。
パラメータ改ざん
Web サービスにおけるパラメータ改ざんとは、コンシューマとサービス間でメッセージ要求またはメッセージ応答を送信している間に攻撃者によりなんらかの方法でメッセージ ペイロードが改ざんされる脅威のことです。
この脅威に対処するには、SOAP メッセージにデジタル署名し、メッセージの受信者が、署名してからメッセージが変更されていないことを暗号として確認できるようにします。詳細については、WSE ドキュメントの「Digitally Signing a SOAP Message」(英語) を参照してください。
例外管理
コンシューマに返される例外の詳細には、最小レベルの情報だけを含み、内部の実装詳細を公開しないようにする必要があります。たとえば、コンシューマに適用された次のシステム例外について考えてみます。
System.Exception:User not in managers role
at EmployeeService.employee.GiveBonus(Int32 empID, Int32 percentage) in
c:\inetpub\wwwroot\employeesystem\employee.asmx.cs:line 207
この例外により、サービス コンシューマはディレクトリ構造などの詳細を確認できます。この情報を悪意のあるユーザーが使用して、仮想ディレクトリ パスのフットプリントやその他の攻撃が行われる可能性があります。
Web サービスは、3 つのタイプの例外をスローできます。
-
SoapException オブジェクト:
CLR または Web メソッド実装コードにより生成されます。
-
SoapHeaderException オブジェクト:
コンシューマが SOAP 要求を送信すると自動的に生成され、サービスの処理でエラーが発生したことを示します。
-
Exception オブジェクト:
Web サービスは、System.Exception から派生したカスタムの例外タイプをスローできます。該当する例外タイプは、エラーの状況によって異なります。たとえば、DivideByZeroException や ArgumentOutOfRangeException などの標準の .NET Framework 例外タイプがあります。
例外タイプに関係なく、例外の詳細は、標準の SOAP の <Fault> 要素を使用してクライアントに適用されます。クライアントと ASP.NET を使用して構築された Web サービスは <Fault> 要素を直接解析しないで、SoapException オブジェクトを使用して整合性を維持して処理します。これによって、クライアントは SoapException オブジェクトをキャッチする try ブロックを設定できます。
注: カスタムの HTTP モジュールから SoapException をスローした場合は、SOAP の <Fault> として自動的にはシリアル化されません。この場合は、SOAP の <Fault> を手動で作成する必要があります。
SoapException を使用する
以下のコードに、単純な WebMethod を示します。ここでは、アプリケーション ロジックの検証でエラーが発生し、その結果、例外が生成されます。クライアントに送信されるエラー情報は最小限の情報です。この例では、サポートが必要な場合に使用できるヘルプ デスクへの問い合わせ情報がクライアントに提供されています。Web サーバーでは、ヘルプ デスクへの問い合わせに関する詳細なエラー説明がログに記録され、問題の診断に使用できます。
using System.Xml;
using System.Security.Principal;
[WebMethod]
public void GiveBonus(int empID, int percentage)
{
// 管理者のみがボーナスを支給できます。
// この例では Windows 認証を使用します。
WindowsPrincipal wp = (HttpContext.Current.User as WindowsPrincipal);
if( wp.IsInRole(@"Domain\Managers"))
{
// ユーザーがボーナスを支給することを承認されます。
. . .
}
else
{
// サーバーにエラーの詳細が記録されます。例:
// "DOMAIN\山口氏は Employee Id 345667 にボーナスを支給しようとしました。
// DOMAIN\山口氏が管理者ではないため、アクセスが拒否されました。"
// 注: ユーザー名は、wp.Identity.Name から取得できます。
// SoapException を使用してクライアントに最小限のエラー情報を返します。
XmlDocument doc = new XmlDocument();
XmlNode detail = doc.CreateNode(XmlNodeType.Element,
SoapException.DetailElementName.Name,
SoapException.DetailElementName.Namespace);
// 例外の詳細部分は次のとおりです。
detail.InnerText = "User not authorized to perform requested operation";
throw new SoapException("Message string from your Web service",
SoapException.ServerFaultCode,
Context.Request.Url.AbsoluteUri, detail, null );
}
}
SoapException を処理するコンシューマ コードは次のようになります。
try
{
EmployeeService service = new EmployeeService();
Service.GiveBonus(empID,percentage);
}
catch (System.Web.Services.Protocols.SoapException se)
{
// se.Detail.InnerText からカスタム メッセージを抽出します。
Console.WriteLine("Server threw a soap exception" + se.Detail.InnerText );
} Global.asax でのアプリケーション レベルのエラー処理
ASP.NET Web アプリケーションでは通常、Global.asax 内の Application_Error イベント ハンドラのメソッド境界を超えて適用できるアプリケーション レベルの例外を処理します。Web サービスの HttpHandler は、例外をキャプチャしてから他のハンドラに到達するため、Web サービスではこの機能を利用できません。
アプリケーション レベルの例外処理が必要な場合は、カスタムの SOAP 拡張を作成して、その例外を処理します。詳細については、MSDN 文書「.NET Framework SDK Version 1.1」で、「アプリケーションの構築」の SOAP エクステンションを使用して SOAPメッセージを変更する方法 (http://www.microsoft.com/downloads/details.aspx?FamilyID=9b3a2ca6-3647-4070-9f41-a333c6b9181d&displaylang=ja) を参照してください。
監査とログ記録
Web サービスでは、プラットフォームレベルの機能を使用するか、Web メソッド実装にカスタム コードを使用して、アクティビティの詳細やトランザクションを監査し、ログに記録できます。
System.Diagnostics.EventLog クラスを使用するコードを作成して、動作を Windows イベント ログに記録します。Web サービスからこのクラスを使用するためのアクセス許可要件と方法は、Web アプリケーションの場合と同じです。詳細については、モジュール 10「セキュリティ保護された ASP.NET ページとコントロールを構築する」の「監査とログ記録」を参照してください。
プロキシに関する考慮事項
WSDL を使用して Web サービスと通信を行うプロキシ クラスを自動的に生成する場合は、生成されたコードとサービス エンドポイントを検証して、偽装されたサービスではなく、目的の Web サービスと通信していることを確認する必要があります。リモート サーバーの WSDL ファイルが適切に保護されていない場合は、悪意のあるユーザーによってファイルが改ざんされたり、エンドポイントのアドレスが変更されて、生成したプロキシ コードに悪影響を与える可能性があります。
具体的には、.wsdl ファイルで <soap:address> 要素を調べて、正しい場所をポイントしていることを確認します。Visual Studio .NET で [Web 参照の追加] ダイログ ボックスを使用して Web 参照を追加している場合は、このダイログ ボックスをスクロールしてサービス エンドポイントを確認します。
最後に、Visual Studio .NET を使用して Web 参照を追加する場合でも、Wsdl.exe を使用してプロキシ コードを手動で生成する場合でも、プロキシ コードを十分に調べて、疑わしいコードがないことを確認してください。
注: Web サービス プロキシの [URL の動作] プロパティを [ダイナミック] に設定すると、Web.config のエンドポイント アドレスを指定できます。
コード アクセス セキュリティに関する考慮事項
コード アクセス セキュリティでは、アクセス可能なリソースと、Web サービス コードで実行できる操作を制限できます。ASP.NET Web サービスは、Web サービスの <trust> 要素で設定された、ASP.NET コード アクセス セキュリティ ポリシーに従います。
コード アクセス セキュリティ ポリシーによって、Web サービスを呼び出す .NET Framework コンシューマ コードに WebPermission を付与する必要があります。WebPermission の正確な状態は、呼び出すことができる Web サービスの範囲によって異なります。たとえば、指定したサーバーのローカルの Web サービスだけを呼び出すことができるようにコードを制限できます。
完全に信頼されたコンシューマ コードには、すべての Web サービスでも呼び出すことができる無制限の WebPermission が付与されます。部分的に信頼されたコンシューマ コードには、次の制限があります。
-
中程度の信頼がある Web アプリケーションから Web サービスを呼び出す場合、既定ではローカルの Web サービスにのみアクセスできます。
-
WSE クラスを使用するコンシューマ コードには完全信頼を付与する必要があります。たとえば、Web サービス プロキシ クラスが、WSE が提供する Microsoft.Web.Services.WebServicesClientProtocol から派生している場合は、完全信頼が必要です。部分的に信頼された Web アプリケーションから WSE を使用する場合は、サンドボックスを使用して Web サービスを呼び出してください。
部分的に信頼された Web アプリケーションから Web サービスを呼び出す方法については、モジュール 9「ASP.NET でコード アクセス セキュリティを使用する」を参照してください。WebPermission の詳細については、モジュール 8「コード アクセス セキュリティの実践」の「Web サービス」を参照してください。
展開に関する考慮事項
使用可能なセキュリティ オプションの範囲は、Web サービスで適用する特定の展開シナリオに応じて大きく異なります。イントラネット内で Web サービスを利用するアプリケーションを構築する場合は、最も多くのセキュリティ オプションとテクノロジを自由に利用できます。一方、Web サービスにインターネットを介して誰でもアクセスできる場合は、使用できるセキュリティ オプションの範囲が制限されます。ここでは、このモジュールで前述した Web サービスのセキュリティ保護のためのアプローチを適用した場合の、各種展開シナリオへの影響について説明します。
イントラネットの展開
イントラネットでは通常、コンシューマ アプリケーション、サービス、およびプラットフォームを制御できるため、Web サービスのセキュリティ保護オプションを自由に利用できます。
イントラネットの場合は、通常、すべての認証と通信のセキュリティ保護オプションの中から任意のオプションを選択できます。たとえば、コンシューマとサービスが同じまたは信頼性の高いドメイン内にいる場合は、Windows 認証を使用できます。クライアント アプリケーションの開発者が、クライアント プロキシに資格情報プロパティを設定してユーザーの Windows 資格情報を Web サービスにフローするように指定できます。
イントラネット通信の多くはプライベート ネットワーク上で行われるため、ある程度のセキュリティが確保されます。このセキュリティが不十分な場合は、SSL を使用してトラフィックを暗号化できます。また、メッセージ レベルのセキュリティを使用して、クライアントとサーバーの両方に WSE をインストールし、両端でアプリケーションに対して透過的にセキュリティを処理することもできます。WSE は、認証、デジタル署名、および暗号化をサポートします。
エクストラネットの展開
エクストラネットでは、制限された数のパートナーに対して Web サービスをインターネットで公開しなければならない場合があります。ユーザー コミュニティは既知で予測可能であり、また場合によっては管理対象のクライアント アプリケーションを使用しますが、それらはそれぞれ個別の独立した環境からアクセスしてきます。この場合は、双方の当事者にとって適切で、ドメインの信頼性に依存しない認証メカニズムが必要です。
アカウント情報を両方の当事者が利用できるようにする場合は、基本認証を使用します。基本認証を使用する場合は、必ず SSL を使用して資格情報をセキュリティで保護します。
注: SSL はネットワーク上で搬送される資格情報だけを保護し、悪意のあるユーザーがクライアント コンピュータにローカルのプロキシ ツール (sslproxy など) をインストールして、SSL で Web サービスに転送する前に呼び出しを傍受するような場合、資格情報は保護されません。
エクストラネットで使用できるもう一つの方法として、明示的な資格情報を渡すのではなく、IIS クライアント証明書認証を使用する方法があります。この場合は、呼び出し側のアプリケーションが、呼び出しに有効な証明書を提示する必要があります。Web サービスはその証明書を使用して呼び出し側を認証し、操作を承認します。詳細については、MSDN 文書「セキュリティ保護された ASP.NET アプリケーションの構築: 認証、認定、および通信のセキュリティ保護」の「第 6 章 エクストラネット セキュリティ」(http://www.microsoft.com/japan/msdn/net/security/SecNetch06.aspx) を参照してください。
インターネットの展開
Web サービスを多くのインターネット コンシューマに公開した場合で、認証が必要な場合は、使用できるオプションが大幅に制限されます。プラットフォーム レベルの認証については、コンシューマが、それぞれの資格情報をマップする適切なドメイン アカウントを持っていないため、どれも適切ではありません。IIS クライアント証明書による認証およびトランスポート (SSL) レベルの使用も、多くのクライアント証明書がターゲットの IIS Web サーバー (またはその前にある ISA サーバー) で認識されなければならなため、問題があります。つまり、このシナリオには、メッセージ レベルの認証とアプリケーションレベルの認証が最も適しているといえます。サービスのコンシューマによってユーザー名、パスワード、証明書、Kerberos チケットまたはカスタム トークンの形で渡される資格情報は、Web サービス インフラストラクチャ (WSE) で透過的に検証するか、ターゲット サービス内でプログラムにより検証できます。クライアント証明書では、規模の管理が困難です。キーの管理 (発行と無効化) が問題になります。また、証明書ベースの認証はリソース集中型であるため、クライアントの数が多い場合はスケーラビリティの問題が発生します。
SSL は通常、ネットワーク トラフィック (サーバー側の証明書のみ) の暗号化を行いますが、メッセージレベルの暗号化も行うことができます。
クライアント証明書の使用は、セキュリティの観点からは長所となりますが、ユーザーの数が多い場合は問題になる可能性が高くなります。証明書を慎重に管理し、証明書のクライアントへの配布、更新、無効化などの方法についても十分に考慮する必要があります。インターネットにおけるもう一つの問題として、処理のオーバーヘッド、相当の作業負荷を伴う大規模な Web サービスでの暗号化や解読および証明書の検証による、ソリューションの全体的なスケーラビリティがあります。
要約
WS-Security は、Web サービス セキュリティの最新の標準です。WS-Security の仕様では、セキュリティ トークンを SOAP ヘッダーによる通常の方法で渡す認証方法のオプションを定義します。トークンには、ユーザー名とパスワードの資格情報、Kerberos チケット、X.509 証明書、またはカスタム トークンを含むことができます。また WS-Security は、メッセージのプライバシーや整合性に関する問題にも対処できます。メッセージ全体またはメッセージの一部を暗号化してプライバシーを保護し、それらのメッセージにデジタル署名することで整合性を確保します。
両方のエンドポイントを制御できるイントラネットのシナリオでは、プラットフォーム レベルのセキュリティ オプション (Windows 認証など) を使用できます。両方のエンドポイントを制御できない場合や、中間のアプリケーション ノードを経由してメッセージがルーティングされるなど、複雑なシナリオの場合は、メッセージ レベルのソリューションが必要です。次の「その他のリソース」では、最新の WS-Security 標準、およびこの標準とその他最新の Web サービス標準に準拠するソリューションを構築するための、関連する WSE ツール キットについての Web サイトの一覧を示します。
その他のリソース
詳細については、以下のリソースを参照してください。