Webサービス・セキュリティの ベスト・プラクティス XMLコンソーシアム セキュリティ部会 松永 豊 matsu@kabuki.tel.co.jp (東京エレクトロン株式会社) Session ID JBSJ211-04
このセッションの目的 Webサービス構築の際に考慮しなければ いけないセキュリティ要件を確認し、 先進企業で実施されているセキュリティ対策 を紹介する。
今日の内容 Webサービスにおける脅威と 新たなセキュリティ要件 Webサービス・セキュリティのベストプラクティス セキュリティ対策と導入事例 標準規格と動向、対応ツールの状況 Webサービス・セキュリティの基盤 アーキテクチャ、処理負荷、認証
Webサービスにおける脅威と 新たなセキュリティ要件
Webサービスにおける新たな脅威 サーバ間の自動処理 (人間のチェックが入りにくい) プログラム処理の起動が可能 (SOAP) バックエンドのシステムにアクセス可能 (SOAP/http) サービスの内容を公開する (WSDL、UDDI) 1.異常なメッセージ バッファ・オーバーフロー 脆弱性攻撃 (XDoS) 2.XMLの悪用 改ざん、盗聴 3.アクセス権の侵害 不正侵入、不正利用 XML http, https SOAP Web/Appサーバ バックエンド (業務App、データベース)
SOAPの危険性 “Crypto-Gram Newsletter” by Bruce Schneier http://www.schneier.com/crypto-gram-0006.html 「うるさいファイアウォールがアプリケーション間でのコマンドのやり取りを禁止してしまう。 だからSOAPがコマンドをHTTPの中に隠してファイアウォールに見つからないようにさせてくれる、というわけだ。」 “Web Services Security” by Bilal Siddiqui http://webservices.xml.com/pub/a/ws/2003/03/04/security.html 「SOAPはWebサービスの機密性を判断できないしユーザ認証、権限認可、アクセス制御を行えない」 「問題の解決には2つの方法がある: 1. 機密性によって異なるSOAPサーバを立てる (中略) 2. 2つ目の方法はファイアウォールをXMLとSOAPに 対応させることだ。(以下略)」
Webサービスに必要なセキュリティ 誤解 http, システムの保護 https データの保護 ファイアウォールの内側にはセキュリティは要らない WS-*の仕様が全部決まるまで待つ必要がある 性能 認証 ログ 通信路の保護 SSL暗号化など フィルタリング SOAPヘッダ XML内容 仮想化 URLやIPアドレス隠蔽 XMLデータ変換 http, https SOAP <?xml … システムの保護 データの保護 通信内容正当性 の確認 電子署名 / 署名検証 スキーマ検証 記録、監査 トランザクションを記録 タイムスタンプ データ内容の 漏洩防止 文書内暗号化処理
Webサービス・セキュリティの ベスト・プラクティス システムの保護 / データの保護 対策技術と事例
ファイアウォールは SOAP/XMLの 内容はチェックしない ベスト・プラクティス – システムの保護 XMLのデータ検査をネットワークの入り口で行う ② XMLファイアウォール データ内容、頻度、サイズ ③ システム仮想化 NAT, プロクシ、URL変換 ④ メッセージ検証 整形式、スキーマ検証 ① ソフトウェア強化 パッチ、データ検証 侵入者 DoS攻撃 $1200 ファイアウォールは SOAP/XMLの 内容はチェックしない 引っかかったXMLメッセージを廃棄/記録 正しい 注文書 $1200 ウィルスを 含む注文書 保護対象の サーバ
XDoS (XMLサービス拒否攻撃) SecurityFocusに報告されている例 Multiple Vendor XML Parser Denial Of Service Vulnerability bugtraq id 6398 object class Input Validation Error cve CVE-MAP-NOMATCH remote Yes local No published Dec 16, 2002 updated Dec 16, 2002 vulnerable Apache Software Foundation Axis 1.0 Apache Software Foundation Axis 1.1 beta Apache Software Foundation Xerces C++ 2.1 .0 Apache Software Foundation Xerces Perl 1.7 .0-1 (以下、影響を受けるソフトウェアのリストが続く。Sun One、 WebSphere等。以下省略) SecurityFocusに報告されている例 (説明) XMLパーサーにサービス拒否の脆弱性が存在し、複数のベンダーで利用されているCrimsonまたはXercesで確認されている。 攻撃者は、ある方法で作成したメッセージをSOAPインターフェースに送りつけることによりこの脆弱性を利用できる。 XMLパーサーがこれを受け取るとCPU資源を食いつぶし、 システムが他のリクエストに応答できなくなり、 サービス拒否の状況となる。 (以下略) 出典: http://www.securityfocus.com/bid/6398/info/
XMLの脆弱性 [ GLSA 200507-15 ] PHP: Script injection through XML-RPC 2005-07-14 18:00:00 URL: http://www.securityfocus.com/archive/1/405265 [ GLSA 200507-10 ] Ruby: Arbitrary command execution through XML-RPC 2005-07-10 18:00:00 URL: http://www.securityfocus.com/archive/1/404984 SUSE Security Announcement: php/pear XML RPC remote code execution 2005-07-07 18:00:00 URL: http://www.securityfocus.com/archive/1/404624 [ GLSA 200507-06 ] TikiWiki: Arbitrary command execution through XML-RPC 2005-07-05 18:00:00 URL: http://www.securityfocus.com/archive/1/404479 Adobe Reader 7: XML External Entity (XXE) Attack 2005-06-15 18:00:00 URL: http://www.securityfocus.com/archive/1/402468 New Python2.2 packages fix unauthorised XML-RPC internals access 2005-02-03 17:00:00 URL: http://www.securityfocus.com/archive/1/389511 IBM DB2 XML functions overflows (#NISR05012005H) 2005-01-04 17:00:00 URL: http://www.securityfocus.com/archive/1/386096 IBM DB2 XML functions file creation vulnerabilities (#NISR05012005I) 2005-01-04 17:00:00 URL: http://www.securityfocus.com/archive/1/386097 Microsoft IIS 5.x/6.0 WebDAV (XML parser) attribute blowup DoS 2004-10-11 18:00:00 URL: http://www.securityfocus.com/archive/1/378179 Multiple vendor SOAP server (XML parser) denial of service (DTD parameter entities)
事例 - XMLフィルタリング マサチューセッツ州政府 税金システム XML+SOAPを使ったオンライン収受システム - 20億ドルの赤字を解消するためにオンライン化 既存汎用機をインターネットに接続、Webサービス化 ネットワーク管理者がXML/SOAPの内容を検査する要求 DMZ XML ファイア ウォール ファイア ウォール ファイア ウォール 汎用機 企業ユーザ 既存の app サーバ Internet SOAP ベースの appサーバ Web サーバ 不正データをストップしappサーバを保護
ベスト・プラクティス – データの保護 予期しない相手に情報が渡ることを前提に対策 受注処理 出荷処理 トランスポート層の保護 (SSL/VPN) メッセージ・フィールドの暗号化 全てのメッセージへの署名 全てのメッセージへのタイムスタンプ データの仮想化 受注処理 出荷処理 Webサービスで注文書を 発行 SSLを終端 (通信路を復号) 転送先によって必要な項目だけを選択的に復号し、転送 SSLで通信路を保護 機密項目を異なる鍵で暗号化
事例 - XML電子署名 米国クレジット会社RouteOne DaimlerChrysler Services Ford Motor Credit GMAC Toyota Financial Services 取引の身元確認、否認回避を XML電子署名で担保 データ/署名形式を統一 各参加社のシステム種別不問 データの必要な部分に署名 RouteOne 1. ローン申請と結果確認 (SOAP/インターネット経由) 2. ゲートウェイ SSL復号 XML処理 (parse) XMLファイアウォール スキーマ検証 署名確認 XMLセキュリティ ・ゲートウェイ 5. 転送 転送先タグにより、適切なサイトに メッセージ配信 契約店 3. SOAPルーティング (例)申請者地域 などでサーバ 振り分け 4. Appサーバが処理 申請内容により、適切な引き受け金融機関を決定 金融機関 2万店以上
事例 - データ仮想化 国内化学会社 XMLはタグを付けてデータを説明するため,漏えいするとデータの中身が分かってしまう。 そこで、タグ名を「売上」と明記するのではなく 、「 01 」というように数字の並びに置き換えて明記するようにした。 日経システム構築 2004.9 「SOAで変化に強いシステムを作る」より グループ会社 本社 <?XML… <売上> 123400 </売上> <?XML… <01> 123400 </01> <?XML… <売上> 123400 </売上> 変換 変換
Webサービス・セキュリティの 標準規格
WS- SecureConversation セキュリティ関連の標準規格 セキュリティ関連の標準規格と動向 ③ WS- SecureConversation Basic Security Profile WS-Federation WS-Authorization OASIS WS-SX (05/10/26発足) (WS-SecurityPolicy) WS-Policy WS-Trust WS-Privacy ② WS-Security (OASIS 04/04/06) XKMS 2.0 (W3C 05/07/28) SAML 2.0 (OASIS 05/03/15) XACML 2.0 (OASIS 05/02/01) SPML (OASIS 03/11/03) ① XML Encryption (W3C) XML Digital Signature (W3C) SOAP Foundation (W3C)
WS-Security – 最も重要な標準規格 2004/04 OASIS標準 XML-Enc (暗号化) XML-DSIG (電子署名) SOAP 認証基盤 トークン Username X.509 SAML REL ゴール:SOAPを使った安全なアプリケーション間通信の方法 日本語版は、XMLコンソーシアムWebサイト http://www.xmlconsortium.org 主な内容: メッセージ保護メカニズム、ID参照、セキュリティ・ヘッダ、 電子署名と暗号化、タイムスタンプ → 主にデータの保護をカバー セキュリティ・トークンと参照の方法 注意点 (エラー処理、相互接続性、その他) WS-I Basic Security Profile: 実装上のガイドライン
WS-Security のデータ例 Timestamp及びBodyに署名 ↓ 暗号化 タイムスタンプ セキュリティ・ トークン (X509証明書) Timestamp及びBodyに署名 ↓ 暗号化 SOAPヘッダ WS-Securityヘッダ 暗号化された 鍵情報 電子署名 OASIS Web Services Security: SOAP Message Security 1.0 OASIS Standard 200401, March 2004 11章 「拡張例」より SOAP ボディ 本文(Body) 暗号化済み
Java™との関連 JSR 105: XML Digital Signature APIs 2005/06 Final Release 完了 JSR 106: XML Digital Encryption APIs 2005/04 Committee Draft 作業中 JSR 155: Web Services Security Assertions 2001/10 Expert Group 形成 作業中 JSR 183: Web Services Message Security APIs 2002/04 Expert Group 形成 作業中 JSR 224: Java API for XML-Based Web Services (JAX-WS) 2.0 2005/10 Proposed Final Draft 完成真近 (セキュリティに関する annotation を規定)
WS-Security対応ツールの状況 WS-Security (WSS)の実装はツールに任せるべき 形態により4種類 アプリケーションサーバ ライブラリ ゲートウェイ / ESB テストツール
1. アプリケーションサーバにおける対応 製品提供形態 実装方法 特徴 Webサービスの実行環境となるアプリケーションサーバにおいてWSSに対応 実装方法 Webサービスを配置するときにWSS対応を指定する (設定での指定が多い) 特徴 Webサービスの実行環境のみでWSSに対応する コーディングを伴わず設定のみでWSSに対応できる製品が多い
2. ライブラリにおける対応 製品提供形態 実装方法 特徴 Webサービスの実行環境をWSSに対応させるために拡張するライブラリのみを提供 WSS対応のAPIを提供 (プログラムに組み込み) 特徴 コーディングを伴うことが多いが,細かな拡張,チューニングができる
3. Gateway/ESBにおける対応 構成例(その他、ServerとClientが逆の場合など) ファイアウォール 製品提供形態 SOAPメッセージを仲介しその過程でWSSに対応する 実装方法: 設定画面 特徴: 負荷分散やセキュリティを集中管理でき、 サービス実行環境に非依存、他の管理機能も提供 構成例(その他、ServerとClientが逆の場合など) LAN ファイアウォール DMZ Server Gateway Client Server Server
4. テストツール WSS対応サービスのテストツール 対応製品 WSS対応SOAPメッセージの自動生成 WSS対応サービスの負荷テスト など 対応製品 Eclipseのプラグインなど、無償ツール 各種開発テストツール等も対応
Webサービス・セキュリティの 基盤 アーキテクチャ 処理負荷 認証
Webサービス・セキュリティ の基盤 SOAを現実のビジネスで活用するには、 ネットワークもよりインテリジェントになる必要がある システム課題 データ・セキュリティ 処理負荷 サービス認証 SOAを現実のビジネスで活用するには、 ネットワークもよりインテリジェントになる必要がある パートナー サービス指向エンタープライズ サービス セキュリティ・ ゲートウェイ データ交換基盤 サービス データ変換 セキュリティ・ ゲートウェイ フィルタリング (侵入防御、漏洩防止) メッセージング サービス ルーティング データ保護 (暗号化・電子署名) パートナー サービス 認証・ アクセス制御 サービス セキュリティ・ ゲートウェイ 運用管理・監視 サービス・ ディレクトリ 認証基盤
処理負荷:セキュリティ強度との兼ね合い 処理ステップ パフォーマンスがセキュリティのキーとなる 暗号化され署名された SOAP/XML トランザクション 復号、検証された SOAP/XML トランザクション 処理ステップ 構文解析 Parsing スキーマ検証 Validation XPath フィルタ XML 復号 署名検証 構文解析 Parsing スキーマ検証 Validation XML データ変換 XML 署名 XML 暗号化 1 3 5 8 8 1 3 10 6 8 パフォーマンスがセキュリティのキーとなる 処理能力とセキュリティ機能を天秤にかけられるか? データやユーザ数の拡大に追随できるスケーラビリティ
認証: セキュリティの中核 SOAP 認証 サイト間 SSO ユーザ アイデンティティ 連携 不正侵入防止、暗号、署名、監査…全ての基礎となる Webサービスによる認証のチャレンジ 標準化: SAML、Liberty Alliance インターネット越しの認証保持 SOAPメッセージの認証 Web SSO サーバ Web SOAP 認証 SOAP サイト間 SSO ユーザ アイデンティティ 連携 SAML サーバ Web SSO サーバ SOAP Web SSO: シングル・サインオン LDAP
事例 - XML認証(SAML) 米国保険会社での顧客認証 顧客サービスのためのエクストラネット 顧客のユーザ・ディレクトリは一箇所で管理 送信中の情報は暗号化・署名して保護 保険会社 大手顧客 ユーザ・ ディレクトリ SAML WS-Security SOAP ID連携 モジュール SAMLゲートウェイ シングル・ サインオン 属性情報問い合わせ (SAML) App シングル・サインオン ソフトウェア App App 数万人の従業員 App App App
まとめ Webサービスのセキュリティは新たな課題 指針 インターネットの時と同様に、新たなセキュリティが必要 End-to-endでの設計、検討、検証が必要 サーバ、LAN、DMZ、ファイアウォール、インターネット… WS-Securityはデータ・セキュリティをカバー → そのほかにシステム保護、認証に留意 指針 「便利になると危険が増える」ことを理解し 必要な対策を把握する 標準規格は動向をウォッチして「重要な規格」を見極める
参考情報 イベント リンク XML2005 11月14日~17日 米Atlanta CSI Computer Security Conference 11月14日~16日 米Washington DC XMLコンソーシアムDay 12月15日(木)~16日(金) 東京・箱崎 http://www.xmlconsortium.org RSA Conference 2006年2月13日~17日 米San Jose リンク XMLコンソーシアム http://www.xmlconsortium.org XML/Webサービスの技術解説、WS-Security仕様の日本語版 セキュリティ部会に参加するのが情報収集の近道 @IT http://www.atmarkit.co.jp/ 仕様解説など
Webサービス・セキュリティの ベスト・プラクティス XMLコンソーシアム セキュリティ部会 松永 豊 matsu@kabuki.tel.co.jp (東京エレクトロン株式会社) Session ID JBSJ211-04