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

SOAPの弱点を克服するシステム設計のポイント

海外ではWebサービスを取り入れた実用システムが次々と立ち上がっている。これを可能にしているのはWebサービス・セキュリティ技術の成熟だ。本稿は前後2回にわたって、実用Webサービス・システムに必要となるセキュリティ構築の実践的な内容を解説する。（編集局）

本記事は、『Security&Trustフォーラム』との連動企画です。

東京エレクトロン
松永 豊
2004/3/26

■ビジネスWebサービスとセキュリティの現状

主な内容 ビジネスWebサービスとセキュリティの現状 Webサービスの普及とセキュリティの重要性 Webサービス・セキュリティを取り入れた 　 システム構築 実運用システムでの課題

　本格的なWebサービス実用化の時代を迎え、今日のWebシステム構築の現場ではXML、Webサービスのさまざまな適用事例が続々と生まれています。Eコマースにおいても、独自ソフトウェアによるシステムから、標準化されたWebサービス・ベースに移行しようとしています。これにより、ビジネスの継続性やビジネス環境の変化に迅速に対応する柔軟性を獲得した、次世代のインターネット・コマースをいち早く実現できるようになります。

　しかし実際にビジネスにおいてWebサービス技術を使うには、開発スキル・信頼性・セキュリティ・処理性能など懸念される課題も多くあります。特に受発注など金銭のやりとりを伴う業務がインターネット経由のWebサービスで実現されるためには、確実なセキュリティが必須となります。＠ITの記事でも、Webサービスのセキュリティ技術が取り上げられてきましたが、いよいよそうした技術を実際のシステムとして組み上げていく時代になってきたといえます。

　そこで本稿では、標準規格などで定義されているWebサービス・セキュリティの技術を実際のネットワーク・システムとして構築する際に必要な考慮点や関連技術、利用可能なツールや遭遇すると思われる課題を検討し、ベスト・プラクティスとしての最新システム構築例を紹介します。

■Webサービスの普及とセキュリティの重要性

新たなセキュリティ要求

　従来のWebアプリケーションでもセキュリティは必要だったわけですが、Webサービスではより高い柔軟性が提供される分、セキュリティ要求も厳しくなります。従来のWebアプリケーションで想定されてきた脅威としては、

• 通信路におけるHTTPトラフィックの盗聴やデータ改ざん
• 脆弱性を利用した破壊工作や不正アクセス（バッファ・オーバーフロー攻撃など）
• なりすまし

などが指摘されており、保護すべき対象としてHTTPリクエスト／レスポンスやWebサーバが考えられていました。

　Webサービスではこれらに加えて、標準形式として使われるXMLで記述されたデータの保護と、Webサービス・プロトコルであるSOAPに起因する危険の回避がセキュリティ上重要になります。特にビジネス用途として考えると、あるXMLデータに関与する人々の身元や内容を証明し、SOAP上で伝達することが大事になるでしょう。

Webサービスで懸念される脅威

　Webサービスならではの脅威としては、情報漏えい、情報操作、不正アクセスや破壊などが考えられます（図1）。

図1　Webサービスで新たに懸念される脅威

　情報漏えい：Webサービスでは機密性の高い情報も含めてテキスト形式のXMLで記述・転送・保存され、しかもそのXMLデータが複数の企業やサイト（ビジネス・パートナーなど）に転送されていくことが、新たな危険性につながっています。

　情報操作：これは対象のサービス内容を知っている者によって悪用されることですが、Webサービスをビジネス・アプリケーションの通信手段と考えた場合、そこでやりとりされる情報の種類そのものが新たな危険をはらんでいます。つまり、オンライン・ショッピングなどに比べて企業間取引の情報など、より機密性の高い情報が行き来することが予想され、悪用することで得られる不当利益やサービス提供者への被害規模がより大きくなるということです。

　不正アクセスと破壊：Webサービスで使われるプロトコル、SOAPの性質によって、より深刻な被害が想定されます。詳細については次項で説明しますが、バックエンドのサーバに対する破壊行動やデータベースの不正操作などが考えられます。

SOAPやXMLに内在する危険性

　まず、SOAPは下位プロトコルとしてHTTPが使われることが多く、ファイアウォールをHTTP（またはHTTPS）で通り抜けアプリケーション・サーバまでSOAPを到達させることになります（図2）。このとき、LANのより深くまでSOAPを届かせると、ほかのHTTPを利用した不正トラフィックの侵入も許してしまうことになります。

図2　SOAPプロトコルの危険性

　次にXMLデータがアプリケーションに直接扱われることを利用した不正操作があります。例えばSQLインジェクションをXMLデータ内で行うことが考えられます。Webアプリケーションであれば、フォームやURLなど、想定される部分に対策を施すことになりますが、Webサービスのメッセージの場合は、SOAPメッセージを受け取り、ボディも含めてパースした後でないとデータ内容のチェックは行えません。このように従来から存在する攻撃手法に対しても、より防御が難しくなります。

　またOSやWebサーバなどと同じようにXMLパーサやSOAPサーバでも脆弱性が報告されており、これらを利用したバッファ・オーバーフローやDoS攻撃があります。これらは特にXMLの性質に起因するものではありませんが、従来のOSなどへのパッチ適用に加えて関連ソフトウェアのメンテナンスが必要になります。

XML／SOAP関連脆弱性の例 以下の3つの例は、SecurityFocusにレポートされたもの。 Multiple Vendor XML Parser Denial Of Service Vulnerability Multiple Vendor XML DTD Parameter Entity SOAP Server Denial Of Service Vulnerability Multiple Vendor XML Parser SOAP Server Denial Of Service Vulnerability

　そして、従来のWebアプリケーションとの差を決定づけるのは、SOAPの大きな特徴であるSOAP-RPCです。この機能によってSOAPメッセージは、Webサービス・プロバイダ側のメソッドを呼び出し、処理を実行させることができます（参考：＠IT記事「SOAPヘッダの役割とSOAP-RPCの実現」）。このためWebサービスでは強力な分散アプリケーションを実現できるわけですが、裏を返すと悪意のあるユーザーにサーバ上のプログラム起動を許す可能性があります。サーバ上の情報取得やシステムへの侵入、破壊行為につながる恐れがあるので注意が必要です。

SOAP脆弱性についての警鐘 　SOAPについては、『暗号の秘密とウソ』（翔泳社、ISBN：4881359967）の著者である暗号学者のブルース・シュナイアー氏がニュースレター「Crypto-Gram」の中で次のような危険性を指摘しています。 ◇ 「SOAPは複数の企業によって開発されてきたが、（そのうちの1社の）マイクロソフト自身がセキュリティとSOAPの関係について述べており、参考になる。 ……中略…… 『SOAPはHTTPを通信機構として採用しており、ファイアウォールはHTTPを通過させるように設定されることが多いので、ファイアウォールのどちらの側からも自由に利用できる。ただしシステム管理者がSOAP独特のHTTPヘッダを使ってSOAPそのものをブロックしてしまうことも可能なので、注意が必要である。』 なるほど。厄介なファイアウォールがアプリケーション同士のコマンド通信を妨害してしまうので、SOAPというものを作ってHTTPの中にコマンドを隠し、ファイアウォールに気付かれないようにしたというわけだ。」（訳＝筆者）

■Webサービス・セキュリティを取り入れたシステム構築

セキュリティ機能の実装とアプリケーション

　Webサービスのセキュリティを実現するには、XMLデータやSOAPプロトコル（通信）、XML処理系（システム）、情報そのもの（注文内容、機密情報など）を保護する必要があります。Webサービスはいわばネットワーク通信とアプリケーションが融合したような技術なので、セキュリティ機能もネットワークとアプリケーションを総体としてとらえて実装する必要があります。

通信の保護

　通信路の暗号化はSSLとして普及している技術であり、サーバ上での実装やSSLアクセラレータまたはアクセラレータを組み込んだ製品（ロードバランサなど）の使用といった選択肢があります。

　さらに侵入保護のためには、アプリケーションに渡る前にデータ内容の検証を行い、フィルタリングを行う必要があります。ここにはいわゆるXMLファイアウォールの機能が必要になり、

• 書式
• スキーマ
• 署名を利用している場合には署名

の検証を行い、不正なトラフィックをブロックすると同時に監査のためにログを記録します。情報漏えい防止のためには、同様の作業を外向けのトラフィックに対しても実施します。

システムの保護

　パッチなどサーバ・ソフトウェアのメンテナンスは当然サーバごとに行う必要があります。内部システムに対する侵入自体を防御するためには、前項のフィルタリングに加えて、サービスを仮想化する方法があります。プロキシによってシステム情報（URLなど）を変換したり、スキーマ変換によって内部データ構造が露出しない工夫を施したりするわけです。スキーマ変換まで行う場合は、プロキシ上にXMLデータを変換できるサーバを構築します。

情報の保護

　ビジネス・アプリケーションではおそらくデータレベルのセキュリティが最も重要になるでしょう。このためには暗号化や電子署名を利用して、情報そのものを保護します。ここがOASISのWS-Security規格でカバーされる部分です。システム的には、通信の間だけでなく、アプリケーションに到達した後、さらにデータベースなどに保存されている状態でも暗号化を維持できるところが特徴的です。従って、社外に向けてメッセージを送信するような利用形態のほかに、社内で暗号化して保存しておく、といった用途も考えられます。

認証基盤の整備

　情報を保護するために暗号化や電子署名を利用するには、認証情報の管理を避けて通れません。最低限でも、暗号処理に使用する暗号鍵の管理が必要です。

　いままで公開鍵暗号方式が最も身近に使われてきたのは、SSLで暗号化を行うWebサイトでしょう。PKIで使われる証明書を利用して認証と鍵情報のやりとりを行い、通信経路を暗号化しています。

　XMLを使った通信の場合には、メッセージ自体を暗号化できます。ただし、Webサービスを利用したアプリケーションが増加してくると、個々のWebサービスが証明書を要求し、1つのトランザクションに対して、証明書・暗号鍵の管理や暗号処理の要求と、その処理負荷が何回も発生することが考えられます。

　こういった暗号処理関連の管理に関して、いくつか考慮が必要です。

　データ形式：証明書やキーストアの種類。ファイル形式などのほかに、開発段階では自己署名の証明書を使っていたものを運用ではどうするか、などのポリシーが必要です。

　証明書の配布：認証情報と暗号鍵を提供する証明書は、セキュリティ機能を必要とするポイントすべてで参照できる必要があります（配布の方法については、情報処理振興事業協会のサイトに解説があります）。

　認証局：暗号化または署名されたメッセージを受け取ったサービスが証明書を検証するための認証局。サービスが証明書の発行元の認証局にアクセスできる必要があり、両者が同一サイトにない場合は、何らかのアクセス方法を与えるか、公的サービスの利用が考えられます。さらに署名の検証などの機能をアプリケーションに組み込む形態を取る場合には、外部へのアクセスなどの待ち時間を考慮した設計が必要です。

　こういった鍵情報の管理に関しては、リアルタイムに確認を行うための標準規格も存在します。

　OCSP：証明書の有効性を検証（＠IT記事「証明書の有効性」）。ただし、必ずしも効率がよくないため、Webサービスでの利用にはスケーラビリティ面の不安が残る。

　XKMS：XML鍵管理サービス。証明書検証の処理を専用のサーバに委託し、アプリケーションからは、暗号処理に使う鍵情報の有効性を直接問い合わせるだけでよくなります（＠IT記事「XML鍵管理サービス（XKMS）とXMLプロトコル（SOAP）」）。現時点では対応製品やサービスが少ないようですが、XMLセキュリティの実装には有望な技術です。

■実運用システムでの課題

　ここまで説明してきたように、Webサービスを保護するための技術はほとんど標準規格として確立していますが、システムとして構築しようとするとさまざまな課題に遭遇します。特にWebサービス・セキュリティの場合には、アプリケーションそのもの、やりとりされるメッセージ、そして通信経路（ネットワーク）をすべて考慮しなければいけないところが問題となります。ここでは主に開発負荷、相互接続性、処理負荷、運用工数の4点の課題について取り上げます。

開発負荷

　セキュリティ機能を盛り込もうとすると、大きな工数増が懸念されます。同じアプリケーション同士の通信、あるいは1対1のプログラム（クライアント／サーバの形態など）に限定されていればまだ単純ですが、相手側の実装を限定しないWebサービス提供になると、次項で紹介する相互接続性も関係して多大な工数が発生します。

　一般的に、セキュリティ機能を持たせるには、まず要件に基づいてポリシーや使用する要素技術を決定します。

要件	内容
ビジネス要件	秘匿しなければいけない情報、参加メンバーなどを特定
セキュリティ上の要求	電子署名や暗号化を適用するデータの決定
スキーマの決定	データ本体に追加する、暗号化や署名に伴うタグの扱い。タグを追加（置換）する場所や形式が決まったら、スキーマ検証の方法を検討
電子署名、暗号化の方法	アルゴリズム、XML文書やSOAPメッセージへの組み込み方法など
認証・暗号鍵管理	暗号鍵や証明書の形式、共有のための認証基盤
認識情報	メッセージを特定するためのタイムスタンプや番号の扱い
侵入防御方法	フィルタリングのポリシー、ログの方法と管理、仮想化の有無
処理フロー	フィルタリングや署名検証でエラーになった場合の扱いなど
システム構成	各技術的要求を満たすためのシステム構成
表1　システム設計上決定が必要な内容

　実装の段階では、決定した内容に従って必要な作業を組み込みますが、外部への問い合わせや時間のかかる暗号処理が必要になる部分もあり、待ち時間などを考慮する必要があります。

　例としてデータの暗号化を行う場合に追加となる作業を紹介します。

作業	内容
SOAPエンベロープの作成	SOAPヘッダに暗号化方法などの情報を入れる
暗号鍵（証明書）情報の取得	キーストア、認証局などから必要なデータを取得
暗号鍵情報の追加	WS-Securityなどの仕様に合わせてタグと証明書データなどを追加（SOAPヘッダ内のSecurityタグ）
暗号化処理	データを暗号化し、XML内で元のデータと置き換え
暗号化用タグの追加	W3Cの仕様に合わせてタグを追加（SOAPボディ）
DataReference	暗号化データの位置をヘッダに追加
スキーマ検証	発信する前のデータ形式をチェック
表2　データ暗号化で必要なクライアント側（consumer）作業

作業	内容
メッセージの認証	SSLクライアント認証など
SOAPメッセージの受信	XMLをパースし、SOAPヘッダを解釈、メッセージの種類を特定。不正であれば拒絶処理
スキーマ検証	正しい形式の文書か？
暗号化内容の特定	SOAPヘッダの情報から、暗号化個所、方法などを取得
鍵情報の取得・検証	必要な暗号鍵を取得。場合によっては認証局などにアクセス
復号化処理	取得した情報から、暗号データを復号
スキーマ検証	復号した内容を含めて文書形式の検証
エラー処理	不正なデータや仕様が合わなかった場合のハンドリング
ログ記録	メッセージの検証内容などを記録。否認回避など外部への証明が必要ならログに署名を追加
データ加工	ビジネス･ロジックが要求する形式へデータ変換。特に認証情報などを伝達する要求が多い。仮想化を行う場合にはそのための変換
表3　データ暗号化で必要なサーバ側（provider）作業

　このほかに同様な形で電子署名やタイムスタンプに関しての機能追加が必要になってきます（XMLの暗号化と電子署名に関しては、＠IT記事「XML暗号化の基礎と実践」に実例付きで紹介されています）。

相互接続性

　Webサービスそのものも相互接続性に関しては大きなテーマとなりますが、セキュリティ機能においても検討が必要です。

• 使用するセキュリティ機能（暗号化、電子署名など）
• 各セキュリティ機能の設定（仕様）
• XML文書／SOAPメッセージへのバインディング（WS-Security仕様など）
• 認証機能（証明書の扱いなど）

　こういった各項目についてメッセージの両端で整合性がないと通信が失敗します。それぞれ標準規格を採用するのが相互接続性を保つ最善策といえますが、規格自体が日々進化しており、規格の中にもさまざまな選択肢があるので、設計段階での仕様決定が重要になります。システム設計のガイドラインとしては、標準化団体のWS-IがBasic Security Profileを策定中です。すでにWS-I Security Scenarios（PDF）という文書のドラフトが公開されており、1方向、同期メッセージの往復、マルチホップ経由のメッセージに対するコールバック、といったシナリオに対して実装のガイドラインが提供されると紹介されています。

処理負荷

　XMLの処理はただでさえ重い、といわれていますが、セキュリティ機能を利用する場合にはここに暗号処理の負荷が加わります。

図3　Webサービス・セキュリティの処理負荷

　電子署名と暗号化を行っただけで、処理負荷が10倍になったという実験結果もあります。処理性能が足りなくなった場合、対処方法によって3種類の新たな問題の浮上が考えられます。

• 性能チューニングを行う→開発工数の増加
• サーバ設備を増強する→設備投資と管理コストの増加
• セキュリティ機能を軽減化する→セキュリティ強度の弱体化

運用工数

　Webサービス・セキュリティ運用の最大の難しさは、アプリケーション、ネットワーク、セキュリティと、通常担当者が異なる3つの分野を統合して管理するところにあります。また、管理項目が多岐にわたるうえに、サービス（アプリケーション）の種類が多くなると、それらを横断して管理しなければいけない項目も出てくるので余計複雑になります。

◇

　前編の本稿では、Webサービスならではのセキュリティ課題を中心に、問題点の切り分けと対処方法の概要を解説しました。後編では、システム構築の実例を元に、現時点で取りうるベストプラクティスを紹介していきます。（後編に続く）

1/4

後編

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メールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）