連載 ビジネスWebサービス最新事情(3)
OASIS WS-SecurityとXKMSの構造を知る
Webサービスをビジネスで利用するために、高度なセキュリティやトランザクション処理、複数のWebサービスの連携などを実現するさまざまな仕様が策定されようとしている。本連載では、これらの仕様を理解するための解説を行っていく。(編集局) |
日本アイオナテクノロジーズ(株)
服部 和彦
2003/10/2
■OASIS WS-SecurityはSOAPのセキュリティを規定する
Webサービスでメッセージレベルのセキュリティを実現するには、前回(連載2回「Webサービスのセキュリティ技術を詳解する」)で説明したXML署名および暗号化が施された文書を、SOAPメッセージ内にどのように格納するかを決める必要があります。このための標準がOASIS WS-Securityです。この仕様はまだ策定中(最新版は委員会標準候補)ですが、サポートを表明しているベンダやテスト実装を行っているベンダも多く、この分野でのデファクトになると思われます。
- OASIS WS-Security(OASIS Working Draft 17, 20030827)
WS-Security仕様が定義する機能は大まかに以下のようになります。
- セキュリティ・トークン
- 署名
- 暗号化
- ユーティリティ(タイムスタンプ)
- エラー通知
図1 WS-Security仕様が定義する機能 |
セキュリティ・トークン
WS-Securityでは、受信側が受け取ったメッセージに基づく認証や認可を行えるように、送信側で認証・認可情報をSOAPメッセージヘッダ内に「トークン」として格納する方法を規定しています。コア仕様ではトークンの具体的な形式(プロファイル)や受信側での処理に関する方法は規定されていないので、どういった認証・認可方法をどう使うかに関してはユーザーが自由に選択できます。またいくつかの一般的なプロファイルは仕様として提出されており、これを用いることで異なる実装と相互に運用することが可能です。現在策定中のプロファイル仕様には以下のものがあります。
- Username Token Profile
ユーザー名とパスワードをトークンとして使用するためのプロファイル - X.509 Certificate Token Profile
X.509証明書をトークンとして使用するためのプロファイル - Kerberos Token Profile
MIT Kerberosチケットをトークンとして使用するためのプロファイル - SAML Token Profile
SAML(Security Assertion Markup Language)文書をトークンとして使用するためのプロファイル - XrML Token Profile
XrML(eXtensible rights Markup Language)文書をトークンとして使用するためのプロファイル - XCBF Token Profile
XCBF(XML Common Biometric Format)文書をトークンとして使用するためのプロファイル
署名
WS-Security仕様では、具体的な署名方法についてはW3CのXML署名仕様をそのまま用いており、署名情報に関する部分(XML署名のSignature要素)をSOAPメッセージヘッダ内に格納するための方法を規定しています。署名対象はSOAPボディ内だけでなく、セキュリティ・トークンに対する署名(これはX.509トークンなどに対して必要です)など、メッセージ内の任意の要素に対して行えます。
暗号化
署名と同様に、WS-Security仕様では、具体的な暗号化方法についてはW3CのXML暗号化仕様をそのまま用いており、暗号化情報に関する部分(XML暗号化のEncryptedData要素以外の要素)をSOAPメッセージヘッダ内に格納するための方法を規定しています。暗号化対象はSOAPボディ内だけでなく、アタッチメントを含むメッセージ内の任意の要素に対して行えます。
タイムスタンプ
リプレイ攻撃や中継攻撃、DoS(Denial-of-Service)攻撃などの第三者からの攻撃を防ぐために、メッセージがいつ生成され、またいつまで有効なのかを示す必要がある場合があります。これを行うために、WS-Securityではメッセージに対して作成日時と期限切れ日時を持つタイムスタンプを使用することが可能です。
エラー通知
メッセージ受信側でセキュリティ情報に関する処理が失敗したとき、エラーに関する具体的な情報をメッセージ送信側に通知できるようにするため、SOAP Faultを使用したエラー伝達の方法が定められています。
Minimalist Profile(MProf)
署名や暗号化などは一般にコストの大きい複雑な処理です。さらにXML署名・暗号化仕様に従ってXMLに対してそれらを行う場合、正規化などのXML変換処理を伴うため、さらに処理コストが大きくなります。このことは、PDAなどのリソースの限られたデバイス上でWS-Securityを実装する場合に大きな障害となります。これを解決するため、WS-Securityの処理オプションのうち最も処理コストが低いものだけをまとめたMinimalist Profile(MProf)と呼ばれるサブセット仕様が策定中です(“Profile”という名前が付いていますが、セキュリティ・トークンの形式を定めたプロファイルとは異なります)。MProfを用いることで、PDAなどのリソースの限られたデバイス上でもWS-Securityを使ったセキュアなWebサービスが可能になります。
■PKIをWebサービスで利用するためのXKMS
これまで見てきたように、署名や暗号化など多くの場面で公開鍵暗号方式が広く使われており、それに必要な公開鍵の取得・検証や登録などを行う公開鍵基盤(PKI)の使用は、Webサービスでのセキュリティを実現するために必要不可欠になります。しかしながらPKIを使用するための具体的な方法はPKIを実装した製品ごとに異なっており、さまざまなアプリケーションから標準的に利用できる方法が存在しないのが現状です。
- XML Key Management Specification(XKMS)2.0(W3C Working Draft 20030418)
http://www.w3.org/TR/xkms2/
http://www.w3.org/TR/xkms2-bindings/
http://www.w3.org/TR/xkms2-xbulk/
この問題を解決するための仕様がXKMSであり、PKIの機能をWebサービスとして利用するための方法が規定されています。XKMSは内部的にさらに2つの仕様に分かれています。
- XKISS(XML Key Information Service Specification)
鍵情報を取得・検証するためのサービス - XKRSS(XML Key Registration Service Specification)
鍵情報の登録等を行うためのサービス
図2 XKMS仕様の構成 |
XKISS
鍵情報の取得・検証を行うためのサービスです。鍵情報の取得だけを要求するLocateサービスと、鍵情報の取得時に鍵の有効性検証まで要求するValidateサービスを持っています(従ってValidateサービスはLocateサービスの拡張になっています)。
XKRSS
鍵情報の登録(Register)・再発行(Reissue)・失効(Revoke)・リカバリ(Recover)を行うためのサービスです。登録サービスではクライアントが生成した公開鍵のみを登録できますし、秘密鍵・公開鍵の生成もサービスに依頼できます。リカバリサービスは鍵のリカバリに秘密鍵に関する情報が必要となるため、登録時に鍵の生成をサービスに依頼した場合にのみ利用可能です。
XBULK
スマートカードでの利用など、大量の鍵情報を一度に登録するための仕様です。この仕様はXKMSのコア仕様とは別に、オプションサービス仕様として策定が進められています。
バインディング
XKMSでは、サービスを利用するために最低限必要な要求と応答メッセージの形式は規定されていますが、メッセージをどうやって伝達するかに関しては、さまざまな方法が使えるようにあえて規定していません。従って実際にXKMSを使う場合には、XKMSメッセージを伝達する下位トランスポートのプロトコルを決める必要があります。XKMSバインディング仕様ではSOAP 1.1/1.2へのバインディングが規定されており、SOAP上でXKMSメッセージをやりとりできるようになっています。また、メッセージレベルやトランスポートレベルでのセキュリティを併用する際の方法も定められています(トランスポートレベルではSSL/TLSとの併用に関して)。
◆
今回は、Webサービスのセキュリティ関連仕様のうち、XML署名とXML暗号をSOAPメッセージ内で使用するための仕様であるOASIS
WS-Securityと、公開鍵基盤(PKI)を使用した公開鍵情報の取得や登録などをWebサービスとして使用可能にするための仕様であるW3C
XKMS(XML Key Management Specification)の仕組みを解説しました。次回はOASIS
SAMLとXACMLについて解説します。(次回に続く)
■関連記事
・XML暗号化の基礎と実践 前編 XML暗号化と正規化と電子署名
・XML暗号化の基礎と実践 後編 XML暗号化と電子署名の実践
・SOAPのセキュリティはどうなっている?
・【連載】Webサービスのセキュリティ
■バックナンバー
1 .複雑化するWebサービスの仕様群を整理する
2. Webサービスのキュリティ技術を詳解する
3. OASIS WS-SecurityとXKMSの構造を知る
4. OASIS SAMLとXACMLの構造を知る
5. Webサービスを連携させるコレオグラフィ
6.
混迷するWebサービス・トランザクション制御
7.
BtoB基盤となるWebサービス・トランザクション(最終回)
ビジネスWebサービス最新事情 |
- QAフレームワーク:仕様ガイドラインが勧告に昇格 (2005/10/21)
データベースの急速なXML対応に後押しされてか、9月に入って「XQuery」や「XPath」に関係したドラフトが一気に11本も更新された - XML勧告を記述するXMLspecとは何か (2005/10/12)
「XML 1.0勧告」はXMLspec DTDで記述され、XSLTによって生成されている。これはXMLが本当に役立っている具体的な証である - 文字符号化方式にまつわるジレンマ (2005/9/13)
文字符号化方式(UTF-8、シフトJISなど)を自動検出するには、ニワトリと卵の関係にあるジレンマを解消する仕組みが必要となる - XMLキー管理仕様(XKMS 2.0)が勧告に昇格 (2005/8/16)
セキュリティ関連のXML仕様に進展あり。また、日本発の新しいXMLソフトウェアアーキテクチャ「xfy technology」の詳細も紹介する
|
|