Webサービス・セキュリティ構築の実践（後編）

事例から読み解くWSセキュリティ最新動向 Page 2

東京エレクトロン
松永 豊
2004/5/7

■WSセキュリティ構築事例

主な内容 WSセキュリティのシステム構築トレンド WSセキュリティ構築事例 まとめ 付録：Webサービス・セキュリティの 　 ツール状況

　Webサービスの構築現場でも、セキュリティ機能を取り入れた構築事例が増えてきました。電子署名やXMLファイアウォールを利用したシステムの実例を紹介します。

XML電子署名（開発ツールの利用）：政府機関でのパスポート情報管理

　カナダのパスポート・オフィスでは、ID情報の盗用を防止するためのパスポート登録情報一元管理に、ebXMLを利用したWebサービスのシステムを導入しました。カナダの29カ所あるパスポート申請窓口をインターネットで結び、それまで手作業だった身元確認作業を自動化しています。申請情報を出生証明と照らし合わせて身元を確認するために、Webサービスのメッセージを出生統計局に送付して自動照合を行うわけですが、この際、XML Digital Signatureの規格で電子署名を添付し、内容証明としています。

　このシステムでは、メッセージングの部分にはパッケージソフトウェアの機能を利用しています。メッセージングの信頼性とセキュリティを実現するためにebXMLを採用し、実装を簡単にするためにebXML機能を提供するサイベース社のWeb Services Integrator Suiteというパッケージを利用しています。既存のアプリケーション基盤と一貫性を保てることと、モジュールが独立しておりゲートウェイとして利用できることが主な選定要因です。システム全体を見るとマルチベンダで構成され、身元確認を行う関連官庁ではebXMLの実装にwebMethods社のモジュールを使用しています（この事例は、2003年12月に米国で開催されたXML 2003 Conferenceで、システム・インテグレータのPentelar社、Rustum Tharani氏が報告した内容です）。

XMLファイアウォール（ゲートウェイの利用）：政府機関での税金収受システム

　マサチューセッツ州の税務部門では、2003年に企業からの申告をインターネット経由のWebサービス・システムに変更しました。システム設計で問題になったのが、SOAPのトランスポートとして使われるHTTPをバックエンドシステムまで到達させることです。Webサービスのフロントエンドには.NETの環境が使われていますが、そこから既存のメインフレーム上のアプリケーションにアクセスするようになっており、不正侵入の遮断が必須でした。

　しかもセキュリティ管理を担当するネットワーク･セキュリティのチームで一元的にセキュリティ運用を行えることが条件となりましたが、ネットワーク技術が中心のこのチームにJavaやXML、あるいはWebサービスなどの教育を行うことに多大な工数と困難が予想されました。

　解決策としては、DMZと.Netサーバの間にゲートウェイを設置し、XMLベースのフィルタリング処理をアプリケーションから分離する方法を選択しました。SOAPのフィルタリングやスキーマ検証といった負荷のかかる処理をゲートウェイ上で行い、さらに一般的なファイアウォールと同様のGUIを用意することにより、ネットワーク技術者でもIPアドレスやドメインだけでなく、SOAPヘッダやXMLのデータ内容（スキーマや、あるノードの値）によってトラフィックを制限できるようにしたわけです。ネットワーク･セキュリティのチームはWebサービスのセキュリティの一元管理と監視が可能になりました。

• XMLを使ったオンライン税金収受システム
• 稼働中：週間10億円のトランザクション
• 追加メリット：一元管理、高性能
• 必要なセキュリティ機能を低コストで構築

図4　マサチューセッツ州政府の税金収受システム

XML電子署名（ゲートウェイの利用）：クレジット会社とパートナー企業のオンライン取引

　米国のクレジット会社「RouteOne」は、各自動車メーカーが個別に運営していた自動車クレジットのビジネスを一元化し、よりオープンで効率のよい自動車ローンの運営を目的に設立された会社です。全米2万店以上の自動車ディーラと自動車メーカー系金融機関との間で取引を仲介する役を担っています。RouteOneでは取引トランザクションの整合性を保証し否認回避を実現するために、XML Digital Signatureの電子署名を利用しています。

　このケースでは、多数の会社間のトランザクションがRouteOneを経由して行くことになり、会社自体がWebサービス・プロキシの役割を果たしています。

　リモートの販売店はローンの申請をSOAPで送信してきます。このリクエストにはXMLデジタル署名を必須としてあり、RouteOneの入り口で署名検証とデータ検査が行われています。署名が検証され正当なメッセージである事を確認した後、ローン処理用アプリケーション･サーバに送られます。サーバが申請を処理した後、内容否認回避の目的で署名を行い、最後に署名済み文書が申請元あるいは金融機関に転送されます。すべてのメッセージと署名は記録され、後からの監査を可能にしています。こういった機能の実装によって第3者によるRouteOneシステムへの不正アクセスと不正なトランザクションを防いでいるのです。

　問題は各金融会社のプラットフォームやアプリケーションが統一されておらず、自動車ディーラのシステムも特定できないので接続性が保証できないことでした。このシステムではデータ形式をXML形式、署名をXML電子署名で統一し、細かな実装上の違いをRouteOneが仲介役として吸収して解決しています。つまりWebサービスのプロキシ形態を取ることにより、ビジネスの橋渡しだけでなくアプリケーション間の橋渡しも実現しているわけです。RouteOne社の内部では、XML電子署名の高速処理と運用一元化の目的でXMLセキュリティ･ゲートウェイ製品を導入しています。

　この結果、自動車ディーラはクレジット会社ごとのインターフェイスの違いを気にする必要がなくなり、RouteOneが契約している全金融機関（現在22社）の中から必要なクレジット商品を選択できるようになりました。

• XML電子署名の処理をゲートウェイで一元化
  • 開発・運用を一元化
  • 仕様の違いを吸収
  • 高速処理

図5　米国クレジット会社RouteOneのオンライン取引（クリックで拡大します）

■まとめ

　本稿執筆中に、標準化団体のOASISでWS-Security規格の最終投票が行われ、OASIS標準として承認されました。中心となるSOAP Message Security 1.0に「WS-Security 2004」という別名が付けられ、同時にトークン･プロファイルとしてUsernameとX.509 Certificateが標準規格となっています。

　本稿で事例として紹介したように、海外ではすでにセキュリティ機能を盛り込んだWebサービス・システムの構築も始まっていますが、正式な標準化を受けてこの流れはますます加速していくものと思われます。いままでWebサービスはアプリケーション・アーキテクチャとして語られる場面が多かったわけですが、セキュリティ機能の実装が進んでくると、ネットワーク構築も含めて全体の設計を考える必要が出てきます。

　インターネットが普及する中でファイアウォール技術が発展してきたように、今回紹介したような技術がより洗練され、システム構築に不可欠な要素となっていくでしょう。（次ページへ続く）

 

後編 Page 1

3/4

後編 Page 3

Index
Webサービス・セキュリティ構築の実践
	前編 SOAPの弱点を克服するシステム設計のポイント
	後編　 事例から読み解くWSセキュリティ最新動向 Page 1 WSセキュリティのシステム構築トレンド Page 2 WSセキュリティ構築事例 まとめ Page 3 付録：Webサービス・セキュリティのツール状況

『Security&Trustフォーラム』でも、Webサービスのセキュリティに役立つ記事を掲載しています。 【連載】Webサービスのセキュリティ 第1回 Webサービスのセキュリティ概要 第2回 XMLデジタル署名とXML暗号 第3回 XML鍵管理サービスとXMLプロトコル 第4回 強力なSSOを実現するXML認証・認可サービスSAML 第5回 PKIとPMIを融合させる次世代言語XACML 第6回（最終回） XACMLのアクセス制御ルールとその仕様

■関連記事

　・XML暗号化の基礎と実践
　・ビジネスWebサービス最新事情

 

Webサービス・セキュリティ構築の実践

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）