SOAの導入を成功させるための10のステップ――SOA導入プロジェクトの経験者から聞き出した秘訣を一挙公開 4ページ

[IDG-2007/08/09]
シェア

STEP 7
セキュリティ計画を策定する

　SOAの最初の目標は、自社内のアーキテクチャ統合であるが、パートナー企業とのB2Bサービスの統合も当然視野に入るだろう。いや、むしろB2Bサービスの統合の方が、大きなメリットをもたらす可能性が高いはずである。ただし、ファイアウォールの外との通信を行う際には、セキュリティ対策を徹底しなければならない。

　米国のIT市場調査会社Forrester Researchのバイスプレジデント、ランディ・ヘフナー氏は、ファイアウォールを越えて通信を行う際には、どのようなセキュリティ技術を使うのかを決める前に、自社がハブなのか、それともハブにぶら下がる取り引き先であるのかをハッキリさせる必要がある」と語る。

　「例えば、ハブであるウォルマートは、アーキテクチャの仕様を決定する立場にある。一方、取り引き先企業は、ウォルマートが採用したセキュリティ・アーキテクチャに対応しなければならない」（ヘフナー氏）

　Webサービスが用いるXMLメッセージのセキュリティを確保するためには、業界標準となっているWS-Securityに加え、まだ標準化が済んでいない、いくつかのセキュリティ仕様を用いることになる（図3）。例えば、その中の1つであるWS-Trustは、セキュリティ・トークンを発行する前にサービスの要求元を適切に認証するものである。そのほか、個人認証によって得られた認証情報を関連するメッセージに適用するWS-SecureConversationや、ユーザーの介在なしにサービス同士がセキュリティ・ポリシーを交換し、認証および権限付与のネゴシエーションを可能にするWS-SecurityPolicy（図2のWS-Policyとは異なる）などの仕様が考案されている。WS-TrustやWS-SecureConversation、WS-SecurityPolicyは、ドメインをまたがってXMLメッセージをやり取りする際には必要不可欠なものであるが、普及するには時間がかかりそうだ。

　「セキュリティを容易に確保できる革新的な標準仕様が出てくるまで、何とか自分たちで対処するしかない」と語るのは、2006年1月に米国の電話会社Verizon Communicationsによる買収が完了した米国の長距離通信事業者MCIのチーフ・アーキテクト、ボブ・レアード氏である。同氏は、現在、インフラのセキュリティ管理者にトラフィック・フローやトランザクションの監視を徹底するように指示したり、2005年8月にIntelが買収した米国のXML関連製品ベンダーであるサーベガのXMLファイアウォールといったSOA専用のセキュリティ・ハードウェアを導入したりといった対策を講じている。

　さらに同氏は、「このままでは、SOA対応のセキュリティ製品が本格普及する前に、SOAに対して悪意ある攻撃が行われ、必ず何らかの被害が発生するはずだ」と警鐘を鳴らす。

SOA_fig3_thumb.jpg
図3：Webサービスの主な標準仕様（承認されていないものも含む）

STEP 8
メッセージング・インフラを選択する

　サービスやアプリケーション間のメッセージ交換に、どのようなインフラを用いるかは、慎重に検討する必要がある。小規模なSOA環境では、直接的なXMLの同期通信でも問題ない。しかし、大規模な環境においては、高信頼性を備えた非同期メッセージングの仕組みが必要になるのだ。

　米国TIBCO Softwareや米国webMethodsなどの大手専業ベンダーが提供するESB（Enterprise Service Bus）／EAI（Enterprise Application Integration）ミドルウェア、あるいはBEA SystemsやIBM、Oracleが提供するアプリケーション・サーバは、いずれも非同期の高信頼性メッセージング機能を備えている。これらはすべて、SOAPやJMS、MQ（Message Queuing）などのさまざまなメッセージング・プロトコルをサポートし、レガシー・システム用のアプリケーション・アダプタを提供する。ただし、現在のところ、各ソリューションはそれぞれ独自の方法でメッセージの受信確認を行っている。この状況は、高信頼性メッセージングの標準仕様であるWS-ReliableMessagingが普及したとしても、すぐには変わりそうにない。

　なお、余談ではあるが、ESBの定義はベンダーによって大きく異なっている。ハートフォードのモアランド氏は、「アーキテクトを10人雇えば、ESBの定義が、自分のものを含めて11通りになるだろう。なぜなら、ESBはアーキテクチャだと言う人もいるかと思えば、製品スイートだと言う人もいる」と指摘する。

　MCIのレアード氏が、「最終的にわれわれは、IBMのWebSphereを選択した。なぜなら、すでにWebSphere MQを導入済みで、同じベンダーの製品を利用することが最も合理的だと判断したからだ」と語るように、大抵の企業は、使い慣れたベンダーの製品を好んで選択するものだ。

　ロッキード・マーティンのヴィバート氏も、レアード氏と同じ意見である。同氏は、ソニックソフトウェア製のJMSベースのESB「Sonic ESB」のメッセージング機能を気に入っているが、顧客が同じような機能を提供している他のベンダーの製品を使っている場合には、そのベンダーから乗り換えるように勧めたりはしないという。

　その一方で、特に小規模な企業に多いのだが、単一ベンダーの製品で統一することを嫌う人もいる。「われわれにとって、何よりも重要なのは柔軟性である」と主張するのは、米国連邦準備制度理事会で13年間にわたり開発業務に従事したあと、現在はニューヨークにある小規模な開発企業のCIO（最高情報責任者）を務めているポール・リンド氏である。同氏は、「プロプライエタリなテクノロジーを無理やりSOAに対応させるWebSphere MQよりも、Webサービス標準に最初から準拠している製品の方が望ましい」と語る。

　リンド氏の意見に対してMCIのレアード氏は、IBM製品に依存することによって、長期的には製品の選択肢が狭まる可能性については認めているが、このリスクは、比較的安価かつ今すぐにSOAを導入し、IBM製品の進化とともにSOA環境を発展させることとのトレードオフであると考えている。しかし、だからと言って他のベンダーのSOA製品に目を向けていないわけではない。IBM以外のSOA製品でも評判の高いものは試したり、試験的に特定のプロジェクトに組み込んだりして、できるだけ選択肢を多く確保しながら、相互運用性の問題が生じるのを避けているのだという。

　一方、前出の大手金融コングロマリットのテクノロジー担当役員は自社で、ある有名なEAI製品を非同期メッセージング・ソフトウェアとして使用していると話す。この製品の特徴の1つが、データ量の多いトランザクションにおいて必要となるバイナリ通信をサポートしている点だ。同氏は、ESBの導入についての質問に、「すでに重量級のメッセージング製品を使っているのだから、JMSのような軽量級の製品を導入する必要はないだろう」と答えた。