この記事の内容は、2つに分けられています。「第1回」は、WS-Securityの機能、ビジネス参加者の間の関係、そしてWS-Securityの能力を実装するうえでの仕組みを説明します。「第2回」では、WS-SecurityのIBM® WebSphere® Application Serverによるサポート、顧客のビジネス要件とそのWS-Security使用法、そして作動可能なソリューションとしての別のセキュリティー技術を説明します。

序説

セキュリティーを使用するうえでの潜在的重要性

セキュリティー要件を定める設計の選択そして実装がソリューションのパフォーマンスに有害な影響を及ぼすのは、よくあることです。ただ、ソリューションに使用される全てのセキュリティー技術がパフォーマンスの低下につながることを意味しているわけではありません。それよりも、ビジネス参加者の認証、メッセージ内容のデジタル署名、そしてXMLデータの暗号化を必要とするWebサービスのソリューションが（ソリューションにて公開されたビジネスの機能とデータを保護するために使われた技術とメソッドにより）かなり異なるパフォーマンス特性を持つことになる可能性に気付かなくてはなりません。

この記事で取り扱われるセキュリティーの三本柱は、(a)認証、(b)データの統合性、そして(c)データの機密性から成ります。もしもこれらのセキュリティー要件を定めるための仕組みの専門家でなければ、実装の方法の詳細に入る前にその能力の全体像を簡単に説明します。

セキュリティーの三本柱

ビジネス・トランザクション内の関係者(parties)たちの身分を確認するのに、認証が実行されます。つまり、身分証明が必要なのです。この証明は様々な方法で要求されます。簡単な一例として、秘密のパスワードとともにユーザーIDを示す方法があります。もっと複雑な例としまして、信頼される（Verisignのような）認証局から発行されるX.509証明書を使用します。証明書は身分証明書(identity credentials)そして（それに関与する）一対の秘密鍵と公開鍵を含みます。関係者により示される身分証明は、証明書そのもの、そして証明書の秘密鍵でデジタル署名された別の情報を包括します。（関係者の証明書と関連する公開鍵を使って）署名された情報を検証することにより、受信者は送信者が証明書のオーナーであることを認証し、その身分を検証できます。両方の関係者が互いを認証すれば、それは相互認証と呼ばれ、Webサービス消費者とWebサービス・プロバイダーの間で頻繁に実行されます。

（インターネットを介する伝送にてメッセージ内容が変更または破壊されないことを確証しつつも）トランザクションにて交換されるビジネス情報の統合性を検証するために、セキュリティー・キーを使ってデジタル署名をデータに施す事ができます。これはセキュリティー三本柱の第二の要件です。送信者のX.509証明書の秘密鍵を使用しWebサービス要求のSOAP本体にデジタル署名を施すのは、よくある慣例です。同様に、実際のビジネス・コンテキストの守備範囲から外れるトランザクション（例：メッセージID、セキュリティー・トークン）にて交換される情報の統合性を保証するために、要求内のSOAPヘッダー・ブロックは署名されます。同じく、データ統合性の確証のためにWebサービス応答をデジタル署名できます。

セキュリティー三本柱の第三の要件は機密性です。暗号化技術を活用すれば、Webサービス要求と応答にて交換される情報を解読不可能にできます。通過中、メモリー内、または持続し続けた後のデータにアクセスするには、実際に情報にアクセスする前に適切なアルゴリズムとセキュリティー・キーを使用してデータを暗号化解除しなくてはならないことを保証するのがその目的です。

今日では様々な仕組みを駆使してそれらのセキュリティーの処置全てを実装できます。特定の要件そしてビジネス環境を基に、トランスポートに依存するかSOAPメッセージングに特化した仕組みのどちらかを選択できます。

この記事は「Webサービスのベスト・プラクティス」シリーズの一部ですので、ソリューションでWS-Securityを推進する様々な方法そして予期すべきパフォーマンスのインパクトに、主にこの記事は焦点を合わせます。

上に戻る

一般的なWS-Securityモデル

WS-Security仕様はOASIS標準の委員会での承認処理の最終段階に入っており、アプリケーションのエンド・ポイント間のセキュリティー三本柱として輪郭が定められた3つの要件の全てを定める仕組みを提供します。WS-Securityにより、セキュリティー三本柱の要件を（ソリューションにて1つか全てが定められるように）それぞれ選択的に実装できます。

別のアプリケーションのサービスを必要とするアプリケーションは、この記事ではコンシューミング・アプリケーション（Consuming Application）とみなされます。サービスを提供するアプリケーションを、サービス・プロバイダー（Service Provider）と呼びます。下記の図はこの関係を図解し、この記事で考察される大半の論点の基礎となります。

以降の章にて考察され図解される筋書では、Service ProviderのX.509証明書の公開鍵はクライアントと交換されService Providerのサービスを呼び出す前にクライアントのランタイムにて構成されなくてはなりません。Consuming Application とService Providerの両方にしてみれば、関係者の証明書を発行した（Verisignのような）Certificate Authorityのルート証明書はローカルの鍵ストアにインポートされる必要があります。Consuming Applicationの鍵ストアはService Providerの証明書のルート証明書を所有することになります。同様に、Service Providerの鍵ストアはConsuming Applicationの証明書のルート証明書を必要とします。これは必須であり、SOAPメッセージにてバイナリー・セキュリティー・トークンとして受け渡される個別の証明書のデジタル署名の検証を可能にします。

3つのセキュリティー要件の完全実装は、以下の項目を含みます

• Webサービス要求/応答の送信者
  • X.509証明書の秘密鍵でメッセージを署名
  • 関係者のみがメッセージ内容にアクセス可能なことを確証するために、受信者のX.509証明書の公開鍵でメッセージを暗号化
• Webサービス要求/応答の受信者
  • 送信者を認証しメッセージの統合性を検証するために、送信者の公開鍵を使用してメッセージのシグニチャーを検証
  • X.509証明書の秘密鍵でメッセージを暗号化解除

上に戻る

WS-SecurityのXML暗号化に関する詳細

WS-Security仕様とXML Encryption仕様を基にし参照するデータの暗号化は、以下の項目を伴います。

• 対称アルゴリズムと非対称アルゴリズムの両方を使用する2段階のプロセス
• Triple DESのように対称アルゴリズムを使用してメッセージ・データを暗号化/暗号化解除を実行するために使われる共有鍵。対称アルゴリズムは非常に効率的で、暗号化と暗号化解除の計算でも1つの鍵と共に機能します。WS-Security実装はランダムに生成された鍵を使用します。一度メッセージのデータが暗号化されれば、鍵そのものがメッセージに挿入されます。（下記にて説明される通り、鍵も暗号化されることに注意してください。）
• RSA-V1.5のような非対称アルゴリズムを使い鍵を暗号化/暗号化解除した状態でSOAPメッセージにて共有鍵を受け渡す。秘密鍵と公開鍵を活用するアルゴリズム付きのメッセージ・データとは違う形で共有鍵の暗号化が実行されます。（証明書の所有者が私有する）第一の鍵、そして（ビジネスを運営する関係者同士で共有する）第二の鍵の2つを、X.509証明書は持ちます。対称アルゴリズムは非対称アルゴリズムよりも効率的です。しかしながら、それらは関係者同士の共有鍵の管理を必要とし、「ビジネス・パートナーではなく組織に属しない部外者に露出されてしまう」と言うセキュリティー上の内在するリスクを抱えます。このように、ランダム・キーに非対称アルゴリズムのみを使用することにより、WS-Securityは比較的効率の良いソリューションと簡単な管理を提供します。この記事の「第2回」では、なぜここで『比較的』と言ったかを説明します。

XML Encryptionの詳細を学びたい場合は、参考文献の章にあるリンクを使ってみてください。

上に戻る

実世界でのWS-Securityの筋書

下記の筋書はWS-Securityにより実現可能な多くある可能性のうちのひとつです。この記事の「第2回」にて概略を述べる予定である顧客のソリューションで普及しているプラクティスのとおり、X.509保証書を使用します。

Consuming ApplicationにてWebサービス要求を処理

一般的には、（Service ProviderのWSDLにより、WebSphere Studio Application DeveloperのようなIntegrated Development Environmentから生成された）Service ProxyかJAX-RPCのスタブ・コンポーネントをConsuming Applicationは持ちます。Webサービス呼び出しが実行された場合、要求を送信する前にクライアント・システムのSOAPランタイムまたはプロキシーはWS-Securityの機能を実行します。

最初に、SOAPメッセージはデジタル署名されます。セキュリティー・キーと証明書を必要なだけ回収するために、SOAPランタイムは鍵ストアへアクセスします。環境が提供するWS-Securityのサポートによっては、SOAP本体のみを署名できるかも知れませんし、本体内の個別のエレメントを署名できるのかも知れません。それに加えて、SOAPヘッダー・ブロックも署名されるかも知れません。Consuming ApplicationのX.509証明書の秘密鍵を使用することにより、この署名を実行します。一度メッセージが署名されれば、バイナリー・セキュリティー・トークンとしてX.509証明書そのものがSOAPヘッダーに包括されます。メッセージは対称アルゴリズムを使用し共有鍵で暗号化されます。データ暗号化に使われた鍵そのものは、非対称アルゴリズムを使用し（Service ProviderのX.509証明書と関連する）公開鍵で暗号化されます。一度メッセージと共有鍵が暗号化されたら、要求の送信先であるService Provider のX.509証明書への参照はSOAPヘッダーに含まれます。Service Providerが複数の証明書を使うからこそ、これは可能なのです。

Service ProviderにてWebサービス要求を処理

Service ProviderがWebサービス要求を受信するとき、要求のURL（サービスの公開されたアクセス・ポイント）を基に要求はSOAP処理エンジン（SOAPランタイム）に向けられます。要求にて受け渡された共有鍵そしてメッセージ・データは既に暗号化されていますので、SOAPヘッダーに参照されたX.509証明書を識別し鍵ストアから秘密鍵を回収するのが第一段階です。秘密鍵を入手すれば、非対称アルゴリズムを使用して共有鍵を暗号化解除できます。共有鍵が公開されていれば、対称アルゴリズムを使用してメッセージ・データを暗号化解除できます。メッセージ全体が公開された時点で、SOAPヘッダーに受け渡されたX.509証明書はその公開鍵を回収するためにアクセス可能となります。メッセージのデジタル署名はConsuming Applicationの公開鍵で実行されます。署名の検証の成功により、Service ProviderのSOAPランタイムがメッセージの統合性を検証するだけではなくConsuming Applicationが実際にメッセージを署名したことを保証します。証明書を所有する送信者のみがメッセージの署名に使われた秘密鍵へアクセス可能なので、そのプロセスはメッセージの発信源/送信者の認証もします。一度メッセージを暗号化解除し署名を検証すれば、SOAPランタイムはWebサービス実装を呼び出します。

Service ProviderにてWebサービス応答を処理

サービス実装のビジネス・ロジックが実行され応答があれば、Webサービスの応答メッセージにて同じWS-Securityが作動されます。しかしながら、Webサービス『要求』を処理する場合と比較し、Webサービス『応答』を同じアプリケーション（例：CAならCA、SPならSP）にて処理する場合、デジタル署名と暗号化においてはX.509の鍵の組み合わせ（秘密鍵と公開鍵）の役割は逆転します。Service ProviderのSOAPランタイムはそれ自身のX.509証明書の秘密鍵を使ってメッセージにデジタル署名を施します。証明書はSOAPメッセージに包括され、共有鍵を使うことによりメッセージは暗号化されます。データ暗号化に使われた鍵は、元の要求にて受け渡された鍵と同じかまたはランダムに生成された別の鍵かも知れません（後者の方がより典型的なケースです）。要求にて受け渡された証明書の公開鍵を使うことにより共有鍵の暗号化を実行します。証明書の秘密鍵へのアクセスが可能な要求送信者のみがメッセージの暗号化解除を実行できます。一度メッセージを署名そして暗号化すれば、Service ProviderのSOAPランタイムがConsuming Applicationへ応答を送信します。

Consuming ApplicationにてWebサービス応答を処理

Webサービス応答のConsuming ApplicationでのWS-Security処理は、サービス・プロバイダーがWebサービス要求の処理を実行した場合と類似します。

元のHTTPセッションを基にしたSOAP処理エンジン（SOAPランタイム）へと向けられた応答を伴うWebサービス応答をConsuming Applicationは受信します。その応答に受け渡された共有鍵とメッセージ・データは暗号化されています。このため、非対称アルゴリズムを使って共有鍵を暗号化解除するために対応する要求と関与する証明書の秘密鍵を回収するのが最初のステップです。共有鍵が公開された状態では、対称アルゴリズムを使用してメッセージ・データを暗号化解除できます。全てのメッセージが公開されれば、SOAPヘッダーにて受け渡されたX.509証明書へのアクセスを通して公開鍵を回収できます。応答メッセージのデジタル署名はService Providerの公開鍵で実行されます。署名の検証が成功すれば、Consumer ApplicationのSOAPランタイムはメッセージの統合性を検証するだけではなく、Service Providerが実際にメッセージを署名したことを保証します。証明書を所有する送信者のみがメッセージの署名に使われた秘密鍵へアクセス可能なので、そのプロセスはメッセージの発信源/送信者の認証をもします。一度メッセージが暗号化解除され署名が認証されたら、SOAPランタイムはConsuming Applicationへ応答を転送します。

上に戻る

まとめ

WS-Securityの内部は非常に複雑であり、様々な筋書にて活用できます。説明された上記の例では、今日の顧客が実装し続けた様々な側面を持ちます。現存のセキュリティー・ポリシー、セキュリティー・インフラストラクチャー、またはビジネス要件によっては、WebSphere Application Serverのプラットフォームの顧客が筋書の一部または全てを実装してきました。これについては、この記事の「第2回」にて考察します。

WS-Securityに対するWebSphere Application Serverのサポートが宣言モデルを介して行なわれるのは良い傾向です。かくして、Webサービス実装が開発そして試験されれば、WS-Security機能の使用可能化は配置の段階にて簡単に達成できます。結果として発生するXML EncryptionとXML Digital Signatureの複雑性などは、本物のIT設計者やIT専門家にしてみれば取るに足らない問題であるはずです。

参考文献

• このシリーズの以前の記事全てにも目を通してください。
  
  
• WebSphere Studio Application Developerの実験的な練習は、Secure Web Services with WS-Securityでどうぞ。
  
  
• 「Secure Web Service: Interoperability」（developerWorks、2004年02月）は、Webサービスのインターオペラビリティーの確保に関するチュートリアルです。
  
  
• Basic Security Profile Scenariosは、WS-I（Web Services Interoperability）の最初のWorking Group Draft（Working Groupの草案）です。
  
  
• Web Services Security （Webサービスのセキュリティー）関連の情報は、WS-Securityで。
  
  
• XML Encryption Syntax and Processing（XML 暗号化の構文そして処理）関連の情報は、W3C Specificationでどうぞ。
  
  
• XML-Signature Syntax and Processing（XML署名の構文そして処理）関連の情報は、W3C Specificationにて入手できます。
  
  
• Webサービス・セキュリティーに対するWebSphere Application Serverのサポートに関するより多くの情報でしたら、WebSphere InfoCenterでどうぞ。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• 序説
• 一般的なWS-Securityモデル
• WS-SecurityのXML暗号化に関する詳細
• 実世界でのWS-Securityの筋書
• まとめ
• 参考文献
• 著者について
• コメント