はじめに

このシリーズ第1回の記事（参考文献を参照）では、アクセスと応答時間がWebサービスを公開する前にテストされるべきWebサービスの機能であると述べました。第3回（参考文献を参照）では、SOAプレイヤーが動的に生産そして消費するリソースの実行可能時間のSLA保証をWebサービスが満たす可能性を高める方法としてのシステム障害のしきい値をどのようにして作成するかについて考察しました。この記事では、これらの記事を展開して脆弱性の課題を取り込み、それがどのように関連して重要な論点であるかを考察します。

このシリーズ第4回（参考文献を参照）では、SOAでの複数のWebサービスとそれらに関連するサービスそしてアプリケーションのACL（Access Control List: アクセス制御リスト）をよりよく制御するためにセキュリティー管理をいかにして企業が統制された位置で取り入れるかを説明しました。しかしながら、ACLでWebサービスを保護しても、Webサービス（そして非Webサービス）の脆弱性を悪意に満ちた攻撃にさらすことのリスクを緩和することにはつながりません。

この記事では、3種類の要求/応答の組み合わせの種類（トランスバーサル(transversal:通過)、脆弱性プローブ(vulnerability probe:脆弱性調査)、そして修復）を考慮して、SLAの脆弱性を悪用されるというリスクを緩和する上で知っておくべき情報について考察します。Webサービスの要求または応答が中断された時、そしてラウンドトリップ(round trip)を完了するまでの間にある大きなギャップや沢山の小さなギャップの積み重ねが、保証された実行可能時間にどれほど大きな影響を与えるかについて網羅します。WebサービスはSOAにて別のWebサービスまたは非Webサービスと（最低限の中断、または中断なしで）相互に作用するように設計されているため、時間のギャップを埋める事は大切な事です。

上に戻る

脆弱性の評価

要求される脆弱性の情報が正確なデータであることを保証するためには、3つの簡単なステップで脆弱性を評価する必要があります。第1のステップは、悪意のある攻撃に弱い重要なシステムの資産（有形、無形）を識別することです。

有形資産とは、実際に目で見ることができ感じ触れられるものです。例として、IBM® Thinkpad® R SeriesとWebsphere® Studioシステム管理者があります。無形資産とは、実際に目で見ることができず感じられず触れられないものですが、有形のものに対する追加的な価値を持ちます（例えば、WebSphere Application Serverへの追加的な価値としてのクライアントの照会への応答時間など）。

第2のステップは、ハッカーや攻撃者が悪意をもって利用できる脆弱性を識別することです。第3のステップは、脆弱性の悪用というリスクを緩和するために保護をほどこしたり修正したりすることなどの治療を提供することです。

上に戻る

情報の入手

リスクを緩和する方法のひとつとして、AVDL（参考文献を参照）や別のXMLフォーマットの記述言語を使用する方法があります。既知の脆弱性がどのようにして識別され、どのようにしてアプリケーションのコンポーネントに対する予期される脆弱性が取り扱われるかに関する情報を入手します。例として、OSの種類/バージョン、Webサーバーの種類、そしてデータベースの種類があげられます。

別の方法として、結果的に悪用される（またはされない）脆弱性につながるアプリケーションの正当な使用計画についての情報を（AVDLを介して）入手する方法があります。ディレクトリー構造、HTML構造、そしてリーガル・エントリー・ポイント(legal entry points)が例としてあげられます。

上に戻る

障害しきい値

情報に対する要求が開始される時そして要求に対する応答が送信される時の時間の差は、企業を完全なサービス妨害（DoS）や重大なシステム資産の破壊から救済できるかできないかの違いを意味する可能性があります。この時間のギャップが大きければ、障害しきい値が実行可能時間の保証への有害な影響を引き起こすほどのレベルに達するかも知れません。

脆弱性を識別して費用効果の高い保護（例えば、災害時回復計画や日次バックアップ・システム）を導入するほうが、企業全体にわたるサービス妨害（DOS）や重要なシステム資産の破壊から回復するよりもはるかに安上がりです。取引のパートナー達は、脆弱性と正当な使用に関する情報を、障害が（ほとんど）ない状態でタイミングよく受け取るべきです。

悪意ある割り込みからWebサービスを保護する方法のひとつは、脆弱性を査定するツール、アプリケーション・セキュリティーのゲートウェイ、報告用のツール、相関システム(correlation systems)、そして修復ツールに関する情報をWebサービスに包括する事です。AVDLでそれを達成することができます。その仕様は、ネットワーク・トポロジー、TCP関連の攻撃、それから他のネットワーク層の問題のようなネットワーク層の脆弱性の情報を網羅しません。これらの問題はSAML（Security Assertion Markup Language）とXACML（eXtensible Access Control Markup Language）にて網羅されているので、認証やアクセス・コントロールに関する情報について考察しません。（参考文献を参照）。

上に戻る

レスポンス・タイプの修正

AVDLは現時点ではそれぞれのレスポンス・タイプの障害しきい値に関する情報についての問題を扱いません。この理由から、この問題に取り組むために、トランスバーサル・コンテナー、脆弱性プローブ、そして修復の概念を、AVDL仕様にて考察されているとおりに修正しました。脆弱性のレスポンスを、以下の3種類に分類しました。

• 脆弱性のトランスバーサル・コンテナー(Vulnerability transversal containers)
• 脆弱性のプローブ・コンテナー(Vulnerability probe containers)
• 脆弱性の修復コンテナー(Vulnerability remediation containers)

Webサービスが要求を送信し応答を受信するラウンドトリップでの長引く障害は心配のタネとなります。SLA保証に影響をおよぼす重大な障害しきい値を引き起こすかも知れないのが、その理由のひとつです。

アプリケーション向けの大きな修復ファイルのダウンロードが、ネットワークの問題により何度も中断されたのを見てきました。必要とする修正（例えば、ファイアウォール・プロトコル）なしでアプリケーションを使用することは不可能でした。幸運なことに、障害が発生したところでバッチに一時的な回復点を付けるメカニズムを、ベンダーは機転を利かせてそのソフトウェアに導入しました。

そうすれば、開始時点ではなく回復点にてダウンロードを再開することができます。ダウンロードが終了した後、アプリケーションにあるファイアウォールのコンポーネントは正常に作動しました。これは障害しきい値においては重大なことです。

上に戻る

脆弱性のコンテナー

Webサービスでのアプリケーション・セキュリティーの脆弱性を記述するために使うことができるレスポンス・タイプと、それぞれが関連する3種類のコンテナーに注目しましょう。

トランスバーサル・コンテナー

脆弱性のトランスバーサル・コンテナー とは、単にHTTPを介するラウンドトリップでの要求と応答のペアについての見方です。それは、SOAにて要求と応答がどこに行ったかを示すマップです。コンテナーの中に複数のペアを入れることはできません。それはそれぞれのコンテナーに複数のマップを所有できないことを意味します。図1に示すとおり、SOA内にいる間、複数のコンテナーが1つのセッションにて一連のタスクを完了する様にできます。

ここであえてヒューマン・フェイシング・セッション(human-facing session) と呼ばれるものと関わるのも構わないのですが、脆弱性のリスクを緩和する上で使える情報を提供するタスクを完了するには、画面の裏側にある複数のセッションを必要とします。Webアプリケーションのそれぞれのページにて複数の要求と応答を所有することができます。

全てのタスクを完了するのにページが必要とするコンテナーの数は、ページのコンテントそして複雑さに依存します。脆弱性のトランスバーサル(transveral)の障害しきい値が重大かそうでもないかを判断する上でのポリシーが何であるかに関する情報を含む必要があります。トランスバーサルが中断された時刻、回復が実行された時刻、それぞれの中断が発生した回数、そして結果として発生した障害しきい値を記録するログを作成することを推奨します。

プローブ・コンテナー

脆弱性プローブ・コンテナー(vulnerability probe container) は、それぞれWebアプリケーションの単一の脆弱性を記述します。トランスバーサル・コンテナーのセッションの場合と同様に、脆弱性プローブのセッションは（それぞれがラウンドトリップを完了するのに必要な要求/応答のペアを1つだけ含む）コンテナーを複数所有するかも知れません。

プローブ・コンテナーはトランスバーサル・コンテナーよりも一歩先を行きます（図2を参照）。トランスバーサルのセッションが1つのの階層のコンテナーからなるのに対して、プローブのセッションは2つの階層のコンテナーからなります。それはプローブのセッションが（それぞれが自身の要求/応答のペアを持つ）複数のプロトコルを含むことを意味します。

脆弱性のプローブの障害しきい値が重大かそうでもないかを判断する上でのポリシーが何であるかに関する情報を含む必要があります。プローブの障害しきい値のログとトランスバーサルの障害しきい値のログとを結合させることも可能です。

修復コンテナー

修復 とは、しかるべき場所にて脆弱性を閉じるのに使われる保護を含みます。XMLでは、修正に特定された保護コードを割り当てられます。それはマシン言語に修正がハード・コードされるオープン・ブロックを含みます。もしも修正がかなり長くなると予測されるのであれば、脆弱性を処置するためにどこに修正がダウンロードされるべきかに関する情報を含むという代案もあります。

修復コンテナーが持つ問題は、数多くのパッチが次々とダウンロードされる場合、複数のコンテナーにある要求/応答にともなうネットワークの問題により中断される可能性が常にあるということです。ダウンロード中に中断した場合に回復点を添付するメカニズムがあります。しかし、中断が発生した時刻、回復が実行された時刻、そしてダウンロード中の中断が発生した回数をログに記録するメカニズムがありません。

修復のダウンロードの障害しきい値が重大かそうでもないかを判断する上でのポリシーを確立する必要があります。そのようなログは、（トランスバーサル、プローブ、そして修復の）ラウンドトリップでの中断を追跡し、障害しきい値を計算するログと結合させることができます。このログがSLAの保証に関するこのシリーズの記事（参考文献を参照）で触れた別の変数を含むことを推奨します。

上に戻る

まとめ

異機種間のSOAにてWebサービスの脆弱性を悪用されるリスクを緩和する行為は、（脆弱性と修復に関する情報が伝送またはダウンロードされる間にも発生する可能性のある）要求/応答の中断の問題を解決するためにも計画の先回りをする必要があります。SLAの許容レベルでの障害しきい値を指定する課題については、開発者はセキュリティーまたは脆弱性の専門家と連絡を取るべきです。

参考文献

• 下記にリストされているこのシリーズの記事から、WebサービスのコンテキストにてSLAを使用する方法に関する情報を入手しましょう。
  • 「SLAによるWebサービスの保証」（developerWorks 、2002年04月）
  • 「SLAで第二世代Webサービス・アプリケーションを保証」（developerWorks 、2004年08月）
  • 「SLAの保証付きでWebサービスをEAIに統合」（developerWorks 、2004年10月）
  • 「SLAの保証付きで複数のWebサービスを保護」（developerWorks 、2004年11月）
  • 「SLAの保証付きでWebサービスにファイアウォールを設置」（developerWorks 、2004年12月）
  • 「SLAの保証付きでWebサービスをローカライズ」（developerWorks 、2005年01月）
  
  
  
• SAMLとXAMCLに関する支援を必要とされるのでしょうか？それでしたら、OASISのWebサイトに目をとおしてみましょう。
  
  
• XMLを使用してアプリケーション・セキュリティーの脆弱点を記述する標準の方法としてのAVDLについてより深く学びたいのであれば、OASISのWebサイトをご覧になってください。
  
  
• システム・デザインの本質的な原理と優先権に焦点を合わせe-commerceと分散統合システムの登場により推進される新たな必須条件を強調する、Judith M. Myerson著の「 The Complete Book of Middleware 」をお読みください。
  
  
• 「 Enterprise Systems Integration, Second Edition 」を読むことにより、システム統合を成功させるのに欠かせられないビジネス的洞察力と技術的なノウハウを養えます。
  
  
• Webサービスに関連する多数のタイトルをはじめ、広範な論題を網羅する技術書物が用意されておりますので、Developer Bookstoreをご覧になってください。
  
  
• 知識欲の袋に底はないのでしょうか？SOA and web services のページは、数百にもわたる情報豊かな記事と、Webサービス・アプリケーションの開発方法についての（初級、中級、そして上級の）チュートリアルを提供します。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• はじめに
• 脆弱性の評価
• 情報の入手
• 障害しきい値
• レスポンス・タイプの修正
• 脆弱性のコンテナー
• まとめ
• 参考文献
• 著者について
• コメント