著者の中村　祐一氏

　第4回の「Webサービス」において、企業間の連携に関する技術的な問題と、そこでのWebサービスの役割についての話がありました。企業間連携はe-ビジネス･オンデマンドの重要な側面です。これまでの統合技術は、あらかじめ決められた参加企業をどのようにして連携させるかに主眼があったわけですが、e-ビジネス･オンデマンドでは、必要に応じて参加企業を加えていくことも視野に入れていく必要があります。そのためには、それを支える技術も十分な拡張性と柔軟性が必要となります。

　本稿では、Webサービスのセキュリティについて紹介しますが、セキュリティ一般に関しても要件は全く同じです。すなわち、新たな参加者との連携を安全に行おうとする場合、こちら側のセキュリティ機構と相手側のセキュリティ機構は違っているのが普通で、それらをどのように連携させるかを扱う必要があるのです。Webサービスセキュリティは、このようなオープンな世界において安全性を提供することを目的に提案されたもので、本稿ではその概要を見ていきます。

連携のためのセキュリティ上の要件

　通常、セキュリティ管理は、定められた範囲内の資源を守ることに主眼が置かれています。ここでの「範囲」は「セキュリティドメイン」と呼ばれ、企業内の特定の範囲であったり、企業をまたがる場合もあります。

　例えば、「VeriSign」は証明書の発行・管理サービスを提供していますが、証明書は企業ごとに発行されるので、そのセキュリティドメインは企業をまたがったものとなります。また、企業内での出張清算システムなどを考えると、従業員のID情報を管理対象としたセキュリティドメインが存在することになるわけです。

　既存のセキュリティ技術は、セキュリティドメイン内の管理に主眼が置かれてきたわけですが、オープンな世界ではセキュリティドメインの連携が重要になってきます。ところが、上記のような例をちょっと見ただけでも、セキュリティドメインが対象とする範囲や目的によって、様々な種類のものが数多く存在することが予想できると思います。

　さらに、セキュリティドメインを管理している技術も単一ではありません。先のVeriSignでは「X.509」という形式で証明書を表現していますが、別のセキュリティドメインではIDとパスワードで表現しているかもしれません。要するに異なるセキュリティ機構の統合も大きな問題となってくるわけです。

　このような問題点を解決するには、様々なセキュリティドメインやセキュリティ機構を統一するような汎用の「セキュリティモデル」を作る必要があります。ここで、汎用のセキュリティ機構ではなく、セキュリティモデルと言っている点に注意してください。世の中で使われているセキュリティ機構を全て置き換えることは不可能ですし、使えるものはそのまま使いたいというのが実際のとこでしょう。したがって、ここで必要とされるセキュリティモデルは極めて抽象的であり、既存のセキュリティ機構をつなぐための接着剤のような役割を果たすことが期待されます。

Webサービスセキュリティのモデル

　2002年4月に、IBMはマイクロソフトとVeriSignとともに「Security in a Web Services World: A Proposed Architecture and Roadmap」を発表しました。この中では、前節での要件を反映したようなWebサービスセキュリティのモデルが提案されています。そのセキュリティモデルでは、サービスの利用者（リクエスタ）がWebサービスの提供者（プロバイダ）にメッセージを送る場合に、セキュリティに関する様々な宣言（Claim）をセキュリティトークン（Security Token）として一緒に付与するようになっています。トークンの中味のフォーマットなどは各セキュリティ機構に応じて自由に決めることができ、それにより抽象化を実現しているわけです。

　さらに、トークンの発行や管理を行う主体としてセキュリティトークンサービス（Security Token Service）という特別なWebサービスを規定し、セキュリティ機構において通常必要とされるセキュリティサーバーを抽象化したものとして位置づけています。このような考え方により、セキュリティ機構の抽象化が可能になり、結果的にそれらの統合も可能にしているわけです。

　前記のRoadmapの文書では、Webサービスセキュリティモデルに基づいて、これから策定していく規格のロードマップも以下のような形で与えています。

　これらのうち、いくつかを紹介しましょう。

　「WS-Security」は、メッセージにセキュリティトークンを付与するための方法、ならびにメッセージそのものを盗聴や改ざんから守るための方法を定義しています。

　「WS-Trust」は、セキュリティトークンサービスとのやり取りを規定しており、セキュリティトークンの発行依頼や検証依頼のための方法が定義されています。

　「WS-Federation」は、複数のセキュリティトークンサービスを連携させるための方法を規定しています。セキュリティトークンサービスは通常一つのセキュリティドメインを管理しているので、この規格により複数のセキュリティドメインの連携が可能になるわけです。

現状と今後の展開

　Webサービスセキュリティの規格のロードマップですが、すべての規格が出そろったわけではありません。また、公開されたものもドラフトであり、正式に標準化されているわけではありません。現在、標準化団体「OASIS」の中でそれらのドラフトを標準化するための作業が進められています。

　この中での最初の規格、WS-Securityは既に実装が公開されており、「IBM Websphere」やマイクロソフト「 .Net」などの製品に実装が含まれています。また、OASISにおける相互運用テストで複数の会社の実装間での接続が確認されており、現実に使われる段階に差し掛かってきたと言えます。

　残りの規格に関しては、いくつかのものはドラフトが公開されていますが、ようやく最初の実装が出始めたばかりです。また、「WS-Privacy」と「WS-Authorization」はまだドラフトも公開されていません。 それでは、異なるセキュリティドメインを連携させる、という最初に掲げた目標はいつごろ可能になるのでしょうか？　前節のセキュリティモデルにより連携の可能性は示したのですが、やはり規格が標準化され、実装間での相互運用テストまで行かないと、実用的な技術という感じがしません。

　Webサービスセキュリティは、従来技術が対象としていなかったセキュリティドメインの統合という技術的なチャレンジを含んでいるので、多少時間がかかることは仕方ないところです。現在ロードマップの下の層から順次作業が進められており、限定された中での連携は可能です。

　ロードマップのすべての規格が早期にそろって、連携が完全なものになることを期待したいと思います。

■勉強に成りました。技術的なことは人間の持てる智慧で何とか展開できると思います。問題になるのは「運営主体」で無いかと思います。いずれにしても「ISO」や「IEEE」等の様な国際的な運営機構でなされてゆく事と思います。そうしたある種の「合意（＝文化）」を認める集合体であってこそ、始めて「安全性」が成立するからです。その時本件は、単純なる「規格＝共通語」作りといった事でなく日々の人間活動に直結してくるので、公開された「立法：司法：行政」的な活動で保証する必要があると思われます。オリンピック委員会のような無様な姿にならないような「仕掛け」の予めの内臓も必要になるのでないでしょうか？
（武蔵：５２：元情報システム管理責任者）