Java Web サービス: (WS-)Security に伴う高コスト

WS-Security のオーバーヘッドを SSL と比較検討し、WS-Security のコストに見合う状況について学ぶ

Web サービス・アプリケーションをセキュアにするためにWS-Security が提供する強力な機能は、多くのアプリケーションにとって不可欠なものです。しかしこれらの機能には、パフォーマンスとメッセージのーバーヘッドという点で、かなりの犠牲が伴います。Dennis Sosnoski による連載「Java Web サービス」では、今回、WS-Security または WS-SecureConversation を使用することが Axis2 のパフォーマンスに与える影響に着目し、HTTPS によるセキュア接続という単純な (そしてパフォーマンスに優れた) 方法を選ぶほうがふさわしい場合について説明します。

Dennis Sosnoski, Consultant and Trainer, Sosnoski Software Solutions, Inc.

Author photoDennis Sosnoski は Java ベースの XML および Web サービスを専門とするコンサルタント兼トレーナーです。専門家としてのソフトウェア開発経験は 30 年以上に渡り、この 10 年間はサーバー・サイドの XML 技術や Java 技術に注力しています。オープンソースのJiBX XML Data Binding フレームワークや、それに関連した JiBX/WS Web サービス・フレームワークの開発リーダーを務め、さらに Apache Axis2 Web サービス・フレームワークのコミッターでもあります。彼は JAX-WS 2.0 および JAXB 2.0 仕様のエキスパート・グループの一員でもありました。



2009年 7月 07日

WS-Security は暗号方式と XML 暗号化および署名に関して確立された業界標準をベースに、Web サービス・アプリケーションのための包括的なセキュリティー機能を提供します。WS-Policy および WS-SecurityPolicy によって、ある特定の Web サービス・アプリケーションでこれらのセキュリティー機能を使用するように指定すると、その Web サービスのクライアントがサービスへのアクセスを自動的に自己構成できるようになります。これらの標準はさまざまなプラットフォームや Web サービス・フレームワークで幅広くサポートされているため、相互運用性には問題ありません (時間とともに向上しています)。

このような利点がある一方、WS-Security には欠点もいくつかあります。例えば、この連載の前の 2 回の記事で説明したように、WS-Security は構成するのが難しい場合があること、そして交換されるメッセージに大量の情報が追加される場合があることなどです。では、このような犠牲を払ってでも WS-Security を使用する価値があるのは、どのような場合でしょうか。この記事では、WS-Security を使用した場合のコストとこれに関連する WS-SecureConversation について、処理のオーバーヘッドとメッセージに追加される大量の情報という両方の観点で掘り下げて調べ、それぞれのアプリケーションにとって有用な方法で WS-Security を適用する方法へと話を進めたいと思います。

パフォーマンスについての検討

異なる構成でのアプリケーションのパフォーマンスを測定する方法として、この記事では単一システム上で稼働しているクライアントとサーバーを使って、リクエストの特定シーケンスの実行時間を測定します。この方法にはいくつかの欠点があります。なかでも最も顕著な欠点は、クライアントとサーバーの処理のオーバーヘッドが混ざってしまっているため、それぞれのオーバーヘッドを切り分けて評価することができないことです。しかし一方で、ネットワークを介してテストを実行する場合よりも通常は一貫した結果を得られるという利点があります。また、ユーザーそれぞれのハードウェアおよび JVM で試してみるにも簡単なので、記事に付属のコードを使ってテストしてみてください (「ダウンロード」を参照)

パフォーマンス・テスト用アプリケーション

テストに使用するアプリケーションは、地震データ検索サービスです。このアプリケーションは、1 年間に世界各地で起こった 93,000 件を超える地震のデータを保管する実際のデータベースを利用しています。サービスに対するリクエストによって、緯度、経度、日付、またはマグニチュードに関するクエリーの内容を指定すると、サービスはクエリーの条件に一致するすべての地震データを地域別および日付順で返します。リクエストを高速に処理するため、データベース全体がメモリー内に保管されて索引が付けられています。つまり、リクエストごとの処理時間はほぼすべて、実際の Web サービスの処理を行うコード (これには XML 変換を処理するデータ・バインディング・コードも含まれます) で費やされるということです。

リスト 1 に、サービスに対するサンプル・リクエストと、それに続くレスポンスを記載します (ページ幅に合わせてフォーマットを変更してあります)。

リスト 1. サンプル・リクエストとレスポンス
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <ns1:matchQuakes xmlns:ns1="http://ws.sosnoski.com/seismic/types">
      <ns1:min-date>2001-08-08T16:31:05.752+00:00</ns1:min-date>
      <ns1:max-date>2001-08-14T23:51:31.499+00:00</ns1:max-date>
      <ns1:min-long>160.4685</ns1:min-long>
      <ns1:max-long>178.19693</ns1:max-long>
      <ns1:min-lat>-42.423557</ns1:min-lat>
      <ns1:max-lat>-30.44976</ns1:max-lat>
    </ns1:matchQuakes>
  </soapenv:Body>
</soapenv:Envelope>

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <ns1:results xmlns:ns1="http://ws.sosnoski.com/seismic/types" count="9">
      <ns1:result-set>
        <ns1:area-name>New Zealand Region</ns1:area-name>
        <ns1:regions count="0">
          <ns1:region ident="rgn159" index="159">NORTH ISLAND,
              NEW ZEALAND</ns1:region>
          <ns1:region ident="rgn160" index="160">OFF E. COAST OF N. ISLAND,
              N.Z.</ns1:region>
        </ns1:regions>
        <ns1:quakes count="9">
          <ns1:quake time="2001-08-11T09:52:54.000+00:00" millis="1000"
              latitude="-37.6499" longitude="177.74" depth="83.0" magnitude="4.4"
              method="ML" region="rgn160"/>
          <ns1:quake time="2001-08-11T09:52:55.000+00:00" millis="0"
              latitude="-37.71" longitude="177.77" depth="70.0" magnitude="4.5"
              method="ML" region="rgn160"/>
          <ns1:quake time="2001-08-11T15:02:47.000+00:00" millis="5600"
              latitude="-38.0429" longitude="175.632" depth="299.8" magnitude="4.6"
              method="ML" region="rgn159"/>
          <ns1:quake time="2001-08-12T07:42:41.000+00:00" millis="7000"
              latitude="-37.97" longitude="175.97" depth="289.0" magnitude="4.3"
              method="MB" region="rgn159"/>
          <ns1:quake time="2001-08-12T22:37:58.000+00:00" millis="5600"
              latitude="-38.3839" longitude="176.121" depth="163.2" magnitude="4.0"
              method="ML" region="rgn159"/>
          <ns1:quake time="2001-08-12T23:25:09.000+00:00" millis="6700"
              latitude="-39.9559" longitude="176.115" depth="76.0" magnitude="4.0"
              method="ML" region="rgn159"/>
          <ns1:quake time="2001-08-13T05:10:07.000+00:00" millis="4300"
              latitude="-37.5859" longitude="176.651" depth="189.0" magnitude="4.3"
              method="ML" region="rgn159"/>
          <ns1:quake time="2001-08-14T02:43:18.000+00:00" millis="2900"
              latitude="-38.3699" longitude="175.902" depth="193.4" magnitude="4.5"
              method="ML" region="rgn159"/>
          <ns1:quake time="2001-08-14T18:02:35.000+00:00" millis="5400"
              latitude="-37.8159" longitude="176.375" depth="193.3" magnitude="4.5"
              method="ML" region="rgn159"/>
        </ns1:quakes>
      </ns1:result-set>
    </ns1:results>
  </soapenv:Body>
</soapenv:Envelope>

クライアントはテストの際に、地震データ全体の一部がクエリーの結果として抽出されるように調整されたリクエストを、疑似ランダムに生成します。同じ入力パラメーターを使用してクライアントが実行されるたびに、同じシーケンスのリクエストが生成されるので、異なる構成の Web サービス構成をテストすることができます。クライアントに対する入力パラメーターを変更すれば、リクエストに含まれるクエリーの内容が変更されるので、簡単に結果として返されるメッセージのサイズを変えてテストすることができます。

WS-Security のパフォーマンス

この記事に記載するテスト結果は、2 つのリクエスト・シーケンスを基準とします。最初のシーケンスで使用する 1,000 のリクエストでは、各クエリーが地震データベース全体のほんの一部にのみ一致するようにクエリー・パラメーターが調整されています (1,000 のリクエストに対して、一致結果として 816 件の地震データだけが返されます)。2 番目のシーケンスでは、それよりも多くのデータと一致するように調整された 100 のリクエストを使用します (100 のリクエストに対して、一致結果として 176,745 件の地震データが返されます)。それぞれのリクエスト・シーケンスを異なるセキュリティー構成で何度か実行し、構成ごとの最短処理時間だけを結果に残しました。

このテストは、Athlon X2 5400+ プロセッサーと 4GB の RAM を搭載したマシンに Mandriva 2009.1 64-bit Linux® システムをインストールした環境で、Sun Java 1.6.0_13 32-bit JVM を使用して実行しました。サーバー・コードを実行した Tomcat 6.0.20 は 1,024MB のヒープを使用するように構成されています。一方、クライアント・コードが使用するヒープは 512MB です。Axis2 についてはバージョン1.5 を使用し、最新ビルドの Rampart コードを適用しました (テストを実行した時点では、Axis2 バージョン 1.5 コードに対応する Rampart の実際のリリースはありませんでした)。驚いたことに、テスト一式を実行するには Tomcat に 1,024MB のヒープが必要でした (テストでは、セキュリティー構成ごとに別の Web サービス・アプリケーションを使用します)。最初に 256MB のヒープでテストしたときには、意味をなさない奇妙なエラー (DTD (Document Type Declaration) がないにも関わらず、「SOAP メッセージには DTD を含められません」といったエラー) または java.lang.OutOfMemoryError のいずれかによって WS-Security テストに失敗することがありました。

テストは、以下のセキュリティー構成のそれぞれを使用して実行しました。

  • plain : セキュリティーなし
  • ssl : サーバーとの接続に HTTPS を使用
  • username : リクエストで WS-Security による平文の UsernameToken を使用
  • sign : 本体とヘッダーに WS-Security による署名を付与し、タイムスタンプを使用
  • encr : 本体に WS-Security による暗号化を使用
  • signencr : 本体とヘッダーに WS-Security による署名を付与してタイムスタンプを使用し、本体を暗号化

実際のテスト時間は、plain 構成の 4 秒から signencr 構成の 55 秒にまで及びました。図 1 に、相対テスト時間を示します。比較しやすいように、テスト時間は plain 構成での所要時間を 1 として正規化してあります。

図 1. テスト時間の比較
テスト時間の比較

図 1 からわかるように、SSL (Secure Sockets Layer) による暗号化 (厳密には SSL は現在、TLS (Transport Layer Security) ですが、この記事では知名度の高い以前の略語を使用します) は非セキュアなケースに近いパフォーマンスを実現しています (ただし、メッセージ数が少ないときよりも多いときのほうが、パフォーマンスに優れています。メッセージ数が少ないときはテスト時間が約 80 パーセント増加しているのに対し、メッセージ数が多いときは約 20 パーセントの増加にとどまっています)。一方、WS-Security を使用する場合にはパフォーマンスが大幅に低下します。リクエスト・メッセージに単純な UsernameToken ヘッダーを追加しただけでも、そのパフォーマンスは、メッセージ数が少ない場合は SSL と同程度に低下し、メッセージ数が多い場合は SSL の数倍もテスト時間がかかっています。署名と暗号化を組み合わせた場合には、非セキュアなケースの 2,100 パーセントを上回るほどテスト時間が長くなっています。

WS-Security によるこのパフォーマンス・ヒットは、一部には Rampart ハンドラー実装の不備が原因となっています。その不備とは、メッセージに対するセキュリティー処理が行われないとしても、Rampart が関係するたびに、各リクエストとレスポンス・メッセージが DOM (Document Object Model) の形に変換されるというものです。この特定の問題は、Rampart 1.5 リリースが Axis2 バージョン 1.5 と歩調を合わせるようになる頃には修正されるはずです。修正がどのように実装されるかによっては、UsernameToken を使用した場合のテスト時間が大幅に改善される可能性もあります。しかし、この問題が修正されたとしても、他の WS-Security のテスト時間には影響しないと思います。

上記以外の WS-Security パフォーマンス・ヒットの原因は、XML Signature と XML Encryption の機能の組み合わせ、そして WS-Security やこの 2 つの XML 標準の実装に使用されているライブラリーです。「Axis2 WS-Security による署名および暗号化」で、XML メッセージに署名を付けるにはカノニカライズと呼ばれるステップが必要だと説明したことを覚えているでしょうか。このステップでは、署名の値が計算される前に、XML を特定のカノニカル形式に変換します。WS-Security 標準でこのステップが要件となっている理由は、XML がパーサーによって分析されて再生成された後でも、署名を維持するという決定がなされたためです。これが XML Signatureの便利な特性であることは確かですが、処理には大量のオーバーヘッドが追加されます。カノニカライズは DOM モデルを使用して実装するのが最も簡単であるという理由もあって、XML セキュリティー・ライブラリーはすべて、XML の DOM 表現で処理されるように作成されています (Rampart ハンドラーがサービスまたはクライアントを扱っている場合でも、これが理由で、いずれは DOM が必要になるという前提の下、Rampart ハンドラーによって DOM が生成されています)。UsernameToken を使用した場合のテスト時間から明らかなように、データを DOM 表現に変換するステップだけでも、WS-Security による大きなオーバーヘッドが生じます。レスポンス・メッセージの数が多い場合、このオーバーヘッドによる処理時間は実際の署名付与または暗号化の処理時間と肩を並べるようになってきます (図 1 において、DOM の作成だけが主なオーバーヘッドとなる username 構成の赤いバーと、DOM が作成された後に実際の暗号化処理が行われる sign および encr 構成の赤いバーを比較するとわかります)。

DOM の問題以上に WS-Security によるオーバーヘッドの大部分を占めているのは、ダイジェストを生成してデータを暗号化する際の計算が集中する処理です。この部分の処理は、使用されている実装方法によらず必要となるため、WS-Security 処理時間に対して行える改善には限りがあります。この連載の今後の記事では、他の WS-Security 実装でも Axis2/Rampart とパフォーマンスを比較する予定ですが、これらの実装のほとんどが同じライブラリーを使用しているので、大きな違いが出ることを期待しないでください。

WS-SecureConversation

WS-SecureConversation は、WS-Security および WS-Trust 標準をベースにした標準で、その目的は複数のメッセージをセキュアに交換できるようにすることです。WS-SecureConversation では、進行中のメッセージ交換を対象としたコンテキストを使用するので、WS-Security を上回る効率性を秘めています。この WS-SecureConversation に必要なセキュリティー・トークンの発行を可能にするモジュールとして、Rampart ディストリビューションには rahas という別個のモジュールが組み込まれています。さらに、このディストリビューションには WS-SecureConversation を使用したポリシー構成の例 (samples/policy/sample04) も用意されています。このパフォーマンス・テスト・アプリケーションでは、この例をベースとしたポリシーを使用しました。

WS-SecureConversation ポリシー (ここには記載しませんが、「ダウンロード」セクションのファイルの中に secureconversation-policy-client.xml ファイルとして含まれています) には、<sp:SecureConversationToken> 要素が組み込まれています。この要素が、メッセージ交換に使用するセキュリティー・トークンのタイプを詳しく記述し、トークン交換メッセージに適用するセキュリティー・オプションを指定します。これらのトークン交換メッセージは、rahas モジュールが実装する操作を使用し、クライアントとサービスとの間での通常のメッセージ交換を利用してやり取りされます。そのため、WS-SecureConversation が使用されている場合には、クライアントとサーバーとの間を行き来するリクエストとレスポンスのメッセージ・ペアを度々目にするはずです (リスト 2 を参照)。追加されたこれらのトークン交換メッセージは、ポリシーによって構成された別のセキュリティー・オプションを使用し、かつ WS-SecureConversation によって定義された特殊な http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT リクエストおよび http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/SCT レスポンスといったアクション・コードを使用しているという点で、アプリケーション・メッセージと区別することができます。

リスト 2. リクエストとレスポンスのサンプル
<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
  <soapenv:Header xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
    <wsse:Security xmlns:wsse="http://...-wss-wssecurity-secext-1.0.xsd"
        soapenv:mustUnderstand="1">
      ...
    </wsse:Security>
    <wsa:To
    >http://localhost:8800/axis2/services/seismic-secureconversation</wsa:To>
    <wsa:ReplyTo>
      <wsa:Address
      >http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
    </wsa:ReplyTo>
    <wsa:MessageID>urn:uuid:5EA8E8F04EBA73255B1246409570148</wsa:MessageID>
    <wsa:Action>http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT</wsa:Action>
  </soapenv:Header>
  <soapenv:Body xmlns:wsu="http://...-wss-wssecurity-utility-1.0.xsd"
      wsu:Id="Id-30222347">
    <xenc:EncryptedData ...>
      ...
    </xenc:EncryptedData>
  </soapenv:Body>
</soapenv:Envelope>

<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
    <wsse:Security xmlns:wsse="http://...-wss-wssecurity-secext-1.0.xsd"
        soapenv:mustUnderstand="1">
      ...
    </wsse:Security>
    <wsa:To
    >http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To>
    <wsa:MessageID>urn:uuid:1BCDE6BE423F5FDE791246409571325</wsa:MessageID>
    <wsa:Action
    >http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/SCT</wsa:Action>
    <wsa:RelatesTo>urn:uuid:5EA8E8F04EBA73255B1246409570148</wsa:RelatesTo>
  </soapenv:Header>
  <soapenv:Body xmlns:wsu="http://...-wss-wssecurity-utility-1.0.xsd"
      wsu:Id="Id-5148380">
    <xenc:EncryptedData ...>
      ...
    </xenc:EncryptedData>
  </soapenv:Body>
</soapenv:Envelope>

証明書を使用した通常の WS-Security とパフォーマンスを比較するため、メッセージ本体の暗号化にのみセッション・トークンを使用するように WS-SecureConversation の構成をセットアップしました。図 2 に、テスト時間の結果を plain および encr テスト構成でのテスト時間と並べて示します。ここでも比較しやすいように、テスト時間は plain 構成での所要時間を 1 として正規化されています。

図 2. WS-SecureConversation によるテスト時間の比較
WS-SecureConversation によるテスト時間の比較

図 2 を見るとわかるように、WS-SecureConversation による暗号化によって、WS-Security を大幅に上回るパフォーマンスの改善がもたらされます。これは特に、メッセージ数が少ない場合に顕著で、WS-SecureConversation による構成での速度は証明書を使用した WS-Security による暗号化のほぼ 2 倍です。メッセージ数が多くなるとパフォーマンス上の優位はそれほど顕著にはなりませんが、それでも WS-SecureConversation のほうが 18 パーセントも速くなっています。

メッセージ・サイズの比較

連載の以前の記事で説明したように、WS-Security は SOAP メッセージ・ヘッダーに大量の情報を追加します。今回の記事で実行したパフォーマンス・テストではクライアントとサーバーが同じシステム上で稼働していますが、クライアントとサーバーとの間でのデータ送信がネットワークを介して行われる場合には、追加された大量の情報がパフォーマンスに大きな影響を与える可能性があります。この追加された情報がパフォーマンスに与える影響の程度は、クライアントとサーバーとの間でのネットワーク接続の品質によって決まります。ただし、メッセージのサイズが大きければ大きいほど、メッセージの交換速度が低下することは明らかです。

図 3 に、それぞれのテスト・ケースでの代表的なメッセージの実サイズを示します。ここでも同じく、比較しやすいように、サイズは plain 構成での結果を 1 として正規化されています。

図 3. メッセージ・サイズの比較
メッセージ・サイズの比較

ご想像の通り、username 構成ではリクエスト・メッセージのサイズしか増えていません。これは、UsernameToken はリクエスト・メッセージでしか使用されないためです。その他のセキュリティー構成ではいずれも、リクエスト・メッセージとレスポンス・メッセージ両方のサイズが増えています。WS-Security によって追加される情報は、リクエストおよびレスポンス・メッセージの数が少なくなるほど多くなります。これも、ご想像の通りでしょう。WS-Security ヘッダーのサイズは各構成で基本的に一定なので、元のメッセージ・サイズが小さければ、この一定のヘッダー・サイズが増加することによって一層大きな影響が出ることになります。暗号化を使用した場合には、暗号化データに使用される base64 エンコーディングによるパディングの影響も加わります。


WS-Security を使用するのがふさわしい場合

これまで WS-Security が処理時間とメッセージ・サイズの両方に与える影響を説明してきましたが、読者の皆さんは、どのような場合に、これだけの犠牲を払う価値があるのか疑問に思っていることでしょう。手短に答えれば、それは、より単純な手段である SSL を使っても上手くいかない場合です。このセクションでは、SSL でニーズに対応できるのか、それとも WS-Security の威力をフルに利用したソリューションが必要なのかどうかを判断する際に役立つガイドライン、そして WS-Security の使用に伴うオーバーヘッドを最小限に抑えるための指針を紹介します。

機密情報の安全を確保する場合

機密性の保持は、セキュリティーの最も重要な側面の 1 つです。WS-Security では XML Encryption を使用して、メッセージ・コンテンツをその対象受信者以外には秘密にします。その方法の基礎となるのは通常、デジタル証明書のなかにラップされた公開鍵です。暗号化はメッセージ全体に適用することも、選択した部分のみに適用することもできます。さらには暗号化を何層かに重ねることによって、複数のシステムを使用するメッセージ交換の参加者ごとにアクセス可能な情報を制御することもできます。

WS-Security の使用例として挙げられるのは、オンライン購入システムです。このようなシステムではクライアントが販売システムにアクセスして注文を行いますが、注文が処理される前に、支払 (例えば、クレジット・カードによる支払) が行われていることがバンキング・システムによって確認されていなければなりません。このとき販売システムが、暗号化されていない形式でクレジット・カード情報にアクセスするとしたら、ブラウザー・ベースのショッピング・サイトに以前からあるようなセキュリティー・リスクが生じてしまいます。つまり、ハッカーに狙われやすいセキュリティーの甘いデータベースにクレジット・カード番号が保管されるという結果です。WS-Security を使用すれば、支払いの確認を行うバンキング・システムでしか復号できない暗号化形式でクレジット・カード情報を送信することができます。

しかし多くのアプリケーションにとっては、機密性を保持するためだけであれば、WS-Security による XML Encryption を使用する必要はありません。(他のサーバーを介した間接的アクセスではなく) クライアントがサービスに直接アクセスし、必要なすべての処理をサービスが直接行う場合には、アクセスに SSL (HTTPS) 接続を使用するだけでも優れた機密性を保証することができます。しかも、そのパフォーマンス・コストは WS-Security より大幅に低くすみます。ただし、この方法が有効なのはクライアントが直接サービスに接続する場合だけです。サービスが情報を他のサービスに渡さなければならないとしたら、攻撃されやすいオンライン・ショッピングの Web サイトと同じ状況に陥ってしまいます。つまり、セキュア接続を使用してショッピング・サイトにクレジット・カード情報を渡しても、そのサイトのサーバーが情報の安全性を保つという保証はありません。

データ完全性を維持する場合

データ完全性は、機密性と同様の問題です。WS-Security は XML Signatureを使用して、送信中のデータが改ざんされていないことを確実にします。少しでも改ざんされていると、署名が無効になるからです。XML Encryption と同じく、著名はメッセージ全体または選択した部分のみへの適用が可能で、署名を何層にも重ねることで、複数のシステムが関わるメッセージ交換の参加者によって処理されるデータの完全性を保証することもできます。

仮想的な例として挙げたオンライン購入システムは、データ完全性の好例でもあります。WS-Security を使用すれば、クライアントがバンキング・システムに送信する支払指示書に署名を付与し、意図した支払い額が販売システムの仲介によって変更されることがないようにすることが可能です。支払い額はクライアントによって署名が付与されるため、暗号化する必要はありません。そのため、販売システムは支払い額が正確であることを確認してから、バンキング・システムに送信することができます。

データ完全性に関しても同じく、クライアントが直接サービスにアクセスし、必要なすべての処理をそのサービスが内部で行う場合には、WS-Security による XML Signature を使用するまでのことはありません。SSL 接続はデータの機密性を維持するだけでなく、送信中のデータが変更されることを防ぐからです。ただし、これが該当するのは単一のクライアントとサーバーとの間で送信が行われる場合に限られます。サーバーが他のシステムにデータを渡すとしたら、これらのシステムは、データがサーバーによって変更されていないという保証を得られません。

信頼性を保証する場合

信頼性は、クライアントとサーバーが直接接続する場合でも SSL では対応できない機能を、WS-Security が提供する領域です。WS-Security による XML Signature を使用してメッセージに署名を付与することで、文書を受信および処理する時点でそれが信頼できるものとして検証できるだけでなく、信頼性を一切損なうことなく、監査のために保管することもできます。

この領域で SSL に可能なのは、せいぜいクライアントとサーバーとの接続を確立する際にクライアント証明書を身元の証明として要求することくらいです。これでは、メッセージにデジタル署名を付与して信頼性を保証する場合と比べ、はるかに確実さに劣ります。SSL 接続の一環として、クライアントとサーバーとの間で交換されるデータ・ストリーム全体を簡単に保管することはできないため、接続の確立時にクライアント証明書を検証したとしても、後でこのステップが正しく処理されたことを証明する手段がないからです。

オンライン購入システムの例に話を戻すと、支払指示書にクライアントが署名を付与することによって、この支払指示書をバンキング・システムが保持し、後でトランザクションに関する議論が持ち上がったときに、支払指示書を提供することが可能になります。したがって、バンキング・システムは支払がクライアントによって承認されたことを証明できるため、一切の法的責任とは無関係でいられるというわけです。

基本領域の枠を超えたセキュリティー

機密性、完全性、信頼性という基本領域の枠を超え、WS-Security は特殊なセキュリティー要件に対応するための数多くの機能を提供します。例えば UsernameToken は、サービスに対する基本ユーザー認証の通信方法を標準化する単純な機能です。その他、SAML (Security Assertion Markup Language) の承認トークンやその他の形式でセキュリティー関連の情報を SOAP メッセージ交換に追加できるようにする WS-Security 機能もあります。このタイプのセキュリティー情報を Web サービスで使用する必要がある場合は、おそらく WS-Security サポートを使用して情報を転送することになるでしょう。WS-Security が定義する標準フォーマットおよび手順は、独自に実装するよりも堅牢である可能性が高いからです。

WS-Security のコスト削減

WS-Security を使用することにした場合は、この記事のテスト結果からわかるように、パフォーマンスが問題になる可能性があります。しかし問題が発生しても、慌てる前にサービスのデータ量について検討してください。暗号化と署名の両方に WS-Security を使用すると、サービスのパフォーマンスが 22分の1 に低下するというのは恐ろしい見通しです。けれどもサービスが 1 時間に少数のメッセージしか交換しないのであれば、ハードウェアの需要という点から考えると、それほど大きなパフォーマンスの差ではありません。

パフォーマンスが当然の懸念である場合には、セキュリティー・オプションを賢く使用することで、WS-Security によるパフォーマンス・ヒットを最小限に抑えられる可能性があります。一部の Web サービス・フレームワークでは、WS-Security を使用してメッセージに完全に署名を付与して暗号化し、SSL 接続で送信するという完璧なセキュリティー構成を作成する傾向があります。最大限の保護が必要で、パフォーマンスについては考えないのであれば問題はありませんが、大抵は、SSL (クライアントと単一のサーバーとの間で送信する情報を保護することだけが重要な場合) または WS-Security 暗号化 (中継地点での機密性を保持した上で、複数のサーバーにデータを配信する必要がある場合) のどちらか一方を使用するほうが理にかなっています。

中継地点を介す場合も含め、クライアントとサーバーとの間でメッセージの交換に長い時間を要する場合には、WS-SecureConversation を使用することもできます。パフォーマンスの向上は比較的控えめなものですが、それでも証明書を使用する WS-Security と比べるとかなりの向上になります。比較的少数のメッセージ交換では、メッセージ本体の実際の (対称) 暗号化に比べ、証明書と非対称暗号化による追加オーバーヘッドが大きくなる可能性がありますが、こうした状況には WS-SecureConversation がとりわけ有効に機能します。

WS-Security のパフォーマンス・コストを削減するもう 1 つの方法は、セキュリティー処理専用のハードウェアにセキュリティーの処理を任せることです。一部の XML ゲートウェイ・アプライアンスでは、WS-Security 暗号化および署名を高速処理できるようになっています。これらのアプライアンスによって重要な WS-Security 処理に対処する一方、アプリケーションではプレーンな SOAP を操作するという方法を使えます。当然、アプライアンスをサーバーに追加する際には、潜在的なセキュリティー・ホールを作らないようにすることが肝心です。また、アプライアンスを購入する前には、そのアプライアンスによるパフォーマンスの向上をテストする必要もあります。しかし少なくとも理論上は、このような処置によって正真正銘のパフォーマンス向上を実現できるはずです。


まとめ

WS-Security のパフォーマンス・コストは相当な量になる可能性があるため、ときには単純な SSL のポイント・ツー・ポイント暗号化のほうが優れたソリューションになることがあります。しかし多くのタイプのアプリケーションには、SSL では不十分です。そのようなアプリケーションには WS-Security (またはこの標準から派生した WS-SecureConversation) が必要となります。そうなったら、パフォーマンス・コストは単なる必要経費に過ぎません。この記事では WS-Security のコストについて説明し、WS-Security がそれぞれのアプリケーションにふさわしいかどうかを判断するためのガイドラインを紹介しました。

この連載の次回の記事では WS-Security をもう一度取り上げ、WS-SecurityPolicy を使用して、Web サービス・アプリケーション内での個々の操作に使用する WS-Security の機能をきめ細かく制御する方法を説明します。操作レベルで WS-Security を制御することもまた、WS-Securityのオーバーヘッド削減につながる手法なので (少なくとも、その可能性はあります)、連載の話題を移す前に、この記事の最適なフォローアップとして説明しておきます。


ダウンロード

内容ファイル名サイズ
Source code for this articlej-jws6.zip1.6MB

参考文献

学ぶために

製品や技術を入手するために

  • Apache Axis2: Axis2 の最新リリースをダウンロードしてください。
  • Rampart: Axis2 対応 Rampart モジュールをダウンロードしてください。
  • IBM 製品の評価版をダウンロードしてください。または、IBM SOA Sandbox のオンライン試用版で、DB2®、Lotus®、Rational®、Tivoli®、および WebSphere® のアプリケーション開発ツールとミドルウェア製品を体験することもできます。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Java technology, SOA and web services, Open source
ArticleID=418052
ArticleTitle=Java Web サービス: (WS-)Security に伴う高コスト
publish-date=07072009