最近,SOAP (Simple Object Access Protocol)というテクノロジが注目を集めている。簡単にいうと,XMLとの組み合わせで「分散アプリケーション」を実現するプロトコルである。
分散アプリケーションという言葉から,CORBA (Common Object Request Broker Architecture),DCOM (Distributed Component Object Model)および RMI (Remote Method Invocation)という3つのテクノロジを思い起こされる読者の方も少なくはないだろう。SOAPは,従来の分散アプリーケション技術の複雑さを柔軟にカバーし,開発効率の向上とタスクに対する高い信頼性を提供してくれる点が注目である。将来性を見込んで,大手を含めたベンダー各社は積極的に対応を進めている。また,規格的にはCORBA等を使用した時に想定されるセキュリティ上のリスクを軽減することもできると考えられている。
XMLを使うシンプルなプロトコル「SOAP」
そもそも,SOAPは異なるアプリケーションをサポートするための高度なモジュールとして,Microsoft,IBM,DevelopMentorおよびUserLandによって開発され,現行のバージョン1.1が標準仕様案としてWorld Wide Webコンソーシアム(W3C)に提出され,認定が求められているところである。
現在,SOAPの中で最も知られている部分は,XML(eXtensible Markup Language)とHTTP (Hyper Text Transfer Protocol)でRPC (Remote Procedure Call)を可能にする機能である。しかしこの機能以外にも様々な機能へのアプローチが可能である。リクエストとレスポンスに関して,SOAPはシンプルなソリューションであることが明らかになっている。
SOAPでは,リクエストやレスポンスの表記にXML形式の文書を使用する。その転送手段には,CORBAのIIOP (Internet Inter-ORB Protocol)のように独自のプロトコルを使用するのではなく,既存のHTTPやSMTPなどを使用するので,ほとんどのファイアウオールを越えられることが保証されている。
また,リクエストやレスポンスがXMLなので,SOAPをJSP (Java Server Pages),ASP (Active Server Pages),CGI (Common Gateway Interface)スクリプトなどに実装するのは難しくない。
大手ベンダーもSOAP対応へ
SOAP 仕様のサポート進展状況としては,ローグウェーブソフトウェアのような小規模で目端の利く企業は早々にSOAP仕様のサポートに取り掛かっている。また,その他の大規模な企業も後れを取っているわけではない。
Microsoftが来年出荷を予定している「Visual Studio 7」の開発ツール・パッケージはSOAPを中心に構築されるため,SOAP仕様を主流へと押し上げるうえで最大の影響力を持つことになりそうである。現時点では,同社のWeb サイトから,Visual Studio 6に対応するSOAPのテクノロジ・プレビューをダウンロードすることができる。
IBMもまた,4月下旬にSOAP 1.1を使ってあらゆるJavaクラスを呼び出せるSOAP/Javaブリッジ技術「SOAP for Java」を公開し,SOAPを強力にサポートしている。SOAP for Java はその後アップデートされ,SOAPプロシージャをJScript などのスクリプト言語で記述できるようになっている。
現在,SOAPの他にもSun Microsystemsの「EB-XML」や「XML-RPCXML」のようなメッセージング・プロトコルが存在している。こういった状況の中で,Microsoftは「WebサイトやWebアプリケーションのプログラミング簡易化」を主たる目標とした,NGWS(Next Generation Windows Services)を発表している。このサービスを確立するためにも,同社は今後もSOAPの伝道に力を注ぐことになるだろう。
SOAPのセキュリティ・リスクは未知数
SOAPは,インターネットの新たな共通語であるXMLを使い,異種のプラットフォーム間で,ファイアウオール越しのメッセージ送信を可能にするものである。この場合,問題となるのがセキュリティであるが,現在は不確定な部分が多く,潜在的なセキュリティ・リスクをはらんでいることが否めない。
SOAPを含む分散アプリケーションを使用する際には少なくとも以下のセキュリティ・リスクを考慮しなければならない。まず,第一に「オブジェクト間(正確にはクライアント・ターゲット・オブジェクト間)の通信メッセージを盗聴/改ざんされてしまう」というリスク。第二に「SOAPは,URI (Uniform Resource Identifiers)が正当であること以外に,アドレス形式に対して制限を加えていないため,リモートからローカルへRPCでアプリケーション機能がユーザの介在なしに呼び出せてしまう」というリスクである。
第一のリスクに対して,SOAPの規格にはデータの完全性に関する記述がまだないため,ユーザー・サイドで暗号化等の手段を講じる必要がある。また,第二のリスクに対してSOAPの設計では,RPCコールの交換時に,XMLの拡張性と柔軟性を使用してカプセル化し,リスク軽減の手がかりを提供している。
しかし,すでに存在している類似の実装と比較した場合,規格上はセキュアであっても具体的な実装がそうであるとは限らないのが事実である。従って,SOAPがセキュリティ上のリスクを高めないとも限らない。文末に紹介するURLのWebページで,SOAPの実装については紹介されているが,セキュリティへの具体的な配慮についてはまだ公表されておらず,将来の規格で説明される予定となっているのが不安を残す材料である。
将来,SOAPが分散アプリケーション分野で開発者がプログラマブルなWebコンポーネントのようなメガ・サービスを作成/実行できるようにするための要素技術となり得るかどうかは,今後の製品群とそれらに切磋琢磨(せっさたくま)を加える利用者の動きにかかっているといえる。
参考までにSOAP1.1の規格と主な対応製品を以下に紹介する。
■SOAP (Simple Object Access Protocol) 1.1
原文(http://web3.w3.org/TR/2000/NOTE-SOAP-20000508/)
和訳(http://www.trl.ibm.co.jp/projects/xml/SOAP1.1-j-ibm-revision2.html)
■XML Corba Link 1.1(ローグウェーブソフトウェア)
■BizTalk Framework 2.0(Microsoft)
■iPortal Suite(IONA Technologies)
■SOAP for Java(IBM Alpha Works)
田中 健介(Tanaka Kensuke)
株式会社ラック 不正アクセス対策事業本部
kensuke@lac.co.jp
IT Proセキュリティ・サイトが提供する「今週のSecurity Check [一般編]」は,その週に起きたUNIX関連およびセキュリティ全般のニュースや動向をまとめた週刊コラムです。セキュリティ・ベンダーである「株式会社ラック」のスタッフの方を執筆陣に迎え,専門家の立場から解説していただきます。