ガートナーが語る「SOAのセキュリティ」：動き出したSOAのいま（1/4 ページ）

SOAで必要なセキュリティとは何だろうか。ガートナーの考えを聞く。しかし、「100％完璧なセキュリティはない」ことを常に認識しておかなければならない。

[谷川耕一，ITmedia]

本記事の関連コンテンツは、オンライン・ムック「動き出したSOAのいま」でご覧になれます。

　SOAで必要なセキュリティとは何か――。先行して進められているWebサービスのセキュリティから考えると、SOAのセキュリティについて理解しやすいかもしれない。WebサービスもSOAも、コンポーネント化されたサービスを連携させたものであり、コンポーネントごとにセキュリティを確保してもサービス全体のセキュリティが確保できるわけではない。鍵となるのは、問題ごとに対処法を検討して対応する技術や製品を導入するのではなく、SOAで実現されるシステム全体のセキュリティ基盤を構築するという総合的な視点だ。

前提となるWebサービスのセキュリティ

　Web環境に必要なセキュリティといえば、暗号化やクロスサイトスクリプティング対策など、幾つかの方法がすぐにも思い浮かぶ。これがWebサービスになったときには、ちょっと頭をひねることになるかもしれない。

　Webサービスのセキュリティを考える場合には、前提としてWeb環境のセキュリティが施され、その上にWebサービス独自な部分の危険性、脆弱性を回避する策が必要となる。

　Webサービスで利用されているテクノロジーとして代表的なものに、サービス間のデータ交換形式であるXML、ネットワーク経由でオブジェクト間の通信を行うプロトコルのSOAP（Simple Object Access Protocol）がある。

　例えば、WebサービスにおけるXMLのセキュリティを考えてみよう。Webサイトのセキュリティ課題として少し前に話題となったクロスサイトスクリプティングについてみてみると、単一のWebサイトの場合であればそのサイト上の入力フォームなどでのみ対策を施せばいいが、XMLという形でデータがアプリケーションに直接届けられてしまうWebサービスでは、画面での入力時ではなく、XMLのデータから生成されるSQLに対して脆弱性をチェックし、アプリケーション側で対策する必要が出てくる。

　また、SOAPにはSOAP RPC（Remote Procedure Call）があり、リモートサーバ内のメソッドをあたかもローカルなメソッドのように呼び出すことができる機能がある。これを悪用させないためには、送られてきたメッソッドが正式な権限ユーザーによるものであり、内容が改ざんされていないものであることを証明する仕組みを組み込む必要があるだろう。もちろん予測していないメソッドがやってきたらきちんとそれをはじくような、メソッド側のカスタマイズも必要になるかもしれない。

　このようにWebサービスとなった場合には、サービス／システム間でデータがやり取りされるため、Webサイトに対するアタックなどとは異なる新たな脆弱性や危険性が生まれてくる。現状、Webサービスに関連するセキュリティについては、標準化団体のW3CやOASISが中心となって仕様を開発中だ（図）。すでに公開され、使われ始めているものも多数ある。数あるセキュリティの仕組みを、サイトの性格や扱うデータの重要性に合わせ適宜組み合わせて、安全性を確保すればいいわけだ。

標準化団体のW3CやOASISが中心となって仕様を策定中

　標準を決めて公開していくということは、業界全体としてのセキュリティ向上の取り組みとしては重要だが、公開することのジレンマもある。例えば、XMLをカプセル化、暗号化して経路の安全性を高めるという策がある。これに関する標準仕様が公開されれば、カプセル化したものについての、処理プロセスも明らかになる。つまり、標準化されると解析もされやすくなるわけだ。

　ガートナージャパンのリサーチディレクターを務める石橋正彦氏は、「例えばリスナーについて公開すると、デフォルトの設定ではまず脆弱性が出てくる可能性が高い」と指摘する。数あるWebサービスのセキュリティ対策を導入したとしても、アプリケーションの欠陥やセキュリティホールにより、なんらかの攻撃を受けてしまう可能性はある。「100％完璧なセキュリティはない」ことを、改めて認識しておく必要がある。