レベル: 初級 Judith Myerson, Systems Engineer and Architect
2008年 10月 23日 専用のセキュリティー監視ホストとしての Web サービスと、分散型のセキュリティー監視ホストとして協調動作する Web サービスの、どちらが適しているのでしょう。この記事では、Judith Myerson がそれぞれのホスト・タイプの長所と短所を検証し、それぞれのホスト・タイプを使ってセキュリティーの問題を解決するための方法を提案します。
計画することから始める
どちらのタイプの Web サービスを使ってセキュリティーを監視するのかを決定する際には、組織の中でセキュリティー監視用の Web サービスを提供するために、どのようなサポートやオペレーション、管理を行うのかを計画することから始める必要があります。提供するセキュリティーが、予測されるリスクと対応策のコストとのバランスがとれたものであることを確認します。たとえその企業がリスクの評価や、対策の費用対効果 (ROI: return on investment) の測定、セキュリティー・ポリシーの見直しなどを定期的に行うことによってバランスの取れたセキュリティーを実現している場合であっても、サービス・レベル・アグリーメント (SLA) で保証されるアップタイムを Web サービスが実現していることを確認する必要があります。
計画の中には、次のような項目を含める必要があります。
- 管理の委譲: 専用型の場合と分散型の場合それぞれについて、地理的な場所の指定、管理権限の委譲レベル、セキュリティー監視のための管理ロールを含める必要があります。これを地区レベル、地域レベル、そして全世界レベルで行う必要があります。
- セキュリティーのインフラ: 企業全体のセキュリティーを 1 つの中心的なグループが専任で管理するのか、あるいは各部門がそれぞれ独自のインフラを独立に管理した上でデータの共有や転送に関して協力するのかを判断する必要があります。また企業内にあり得るすべての管理ロールを考え、1 つの企業に対してロールをいくつ割り当てるのかを判断する必要があります。
- Web サービスの対話: 企業の Web サービスが、グリッド接続あるいはポイント・ツー・ポイント接続を介して他の企業の Web サービスと対話する必要があるかどうかを考慮する必要があります。グリッドが使用される場合には、そのグリッドが地区レベルなのか地域レベルなのか、全世界レベルなのか、それともその 3 つのすべてなのかについて、また未使用のリソースを各グリッド・レベルにある複数のワークステーションでどのように融通し合うのかについて考慮する必要があります。
- リスク、トレーニング、そして文化: コンピューターとネットワーク・インフラを格納する設備のリスクを評価し、物理的なセキュリティーを施す必要があります。そしてセキュリティー監視用の Web サービスを構築する上での開発者のスキルを高めるために、トレーニング・クラスを提供する必要があります。また企業内や、(そして他の企業についてもわかっている場合には) 他の企業の文化や組織上の側面を考慮する必要があります。
セキュリティー監視専用の Web サービス
ホストとしてセキュリティー監視専用の Web サービスを採用することに決定した場合には、このサービスが集中管理型セキュリティー監視用の Web サービスと同じではないことに注意する必要があります。この Web サービスは集中管理型の手法とは異なり、監視専用の Web サービスを企業内で複数まとめて 1 台の仮想ホストとすることができ、それぞれの Web サービスが SOA (Service-Oriented Architecture) の中に完結したセキュリティー用のツールやポリシー、標準を持つことができます。集中管理型の場合には、1 つの企業がセキュリティー監視用の Web サービスを複数持つことはできません。
ある企業のセキュリティー監視専用の Web サービスは他の企業のセキュリティー監視専用の Web サービスと通信することができ、その通信は地区レベル、地域レベル、全世界レベルという 3 つのレベルのいずれかで行われます。セキュリティー監視専用の Web サービスの方が分散型のセキュリティー監視 Web サービスよりも多くのメリットを低コストで提供できるということを実証する必要があります。
専用型モデルのメリットの 1 つは、監視対象の Web サービスが、グリッドをスキップして企業内のイントラネットや閉じたネットワーク上で機密データを転送できることです。1 つのイントラネットから別のイントラネットへ、イントラネットから閉じたネットワークへ、または 1 つの閉じたネットワークから別の閉じたネットワークへデータの転送やアクセスを行う場合には、セキュアな通信が必要です。
分散型セキュリティー監視 Web サービス
分散型セキュリティー監視 Web サービスのモデルは、グリッド上のさまざまな企業にまたがってセキュリティー監視用の Web サービスがどのように分散されるかを記述します。まず、このモデルの最上位には全世界レベルの監視ホストがあり、このホストが 2 番目の地域レベルのホストにグループ分けされ、そして地域レベルのホストが 3 番目の地区レベルのホストにグループ分けされます。
ホストとして分散型の監視 Web サービスに移行する理由、あるいは分散型の監視 Web サービスを構築する理由をいくつか調べてみましょう。
セキュリティーとファイアーウォール、そしてリスク
異なる企業間にまたがってセキュリティーを監視する Web サービスには、分散型のセキュリティー・モデルが必要です。セキュリティーに関する責任は企業間で分担して負担します。各企業はそれぞれが担当するセキュリティー・インフラを独立して管理します。
グリッド内で行われる Web サービスの対話は、企業のファイアーウォールを越えてさまざまな企業にアクセスできる必要があります。例外としては、企業や政府のイントラネットがファイアーウォールの背後にある場合や、イントラネットやインターネットと接続されない閉じたネットワークの場合があります。
ある企業内で一定の期間内にリスクが高まったことを専用の監視ホストが検出した場合、その監視ホストによる Web サービスが、集中的にセキュリティーを制御して許容できるレベルにまでリスクを軽減することは非常に困難な場合があります。
複数のグリッド
一部の企業では、グリッド内にある Web サービスによって他のグリッドとの対話を行う戦略を採るかもしれません。1 つの企業が、異なるサービスを提供する複数のグリッドと対話することはあり得ます。そうしたサービスには、購買関係のサービスから給与処理のサービスに至るまで広範な種類があります。企業はこれらのサービス・グリッドを使用することによって、他のパートナーのシステムや、サービス・プロバイダーである顧客のシステム、供給元のシステムなどとの対話を行います。サービス・グリッドによって、そのグリッドに参加している企業は、それぞれが独自にコンピューターやネットワーク、セキュリティーのインフラやポリシーを内部に持つ、緩い結合による連携動作を行うことができます。
異種混成の技術とセマンティクス
さまざまな企業から成る Web サービスは異種混成の技術スタックを使って構成される可能性があります。各企業はコンピューティング・インフラを独自に決定します。このため、さまざまな企業やグリッドでのセキュリティー監視 Web サービスを含めて、さまざまな Web サービスで異なるセマンティクスが使われる可能性があります。企業間で交換されるデータの解釈は各企業で異なります。企業間にまたがる標準として使用できる汎用のデータ・モデルはまだありません。
リソースの問題
Web サービスの問題点は、Web サービスが通常は疎結合であり、リソースが不十分かどうかにかかわらず実行されてしまうことです。分散型セキュリティー監視 Web サービス用のリソースがグリッド内にある場合、それらのリソースの浪費を確実に防ぐための方法が必要です。
非グリッド環境では、バックグラウンドのリソースの量は増えたり減ったりします。Web サービスがメッセージの送受信を待つ間、リソースが不足する場合と不足しない場合があります。何千台ものワークステーションがある場合にスケールの変化に応じた適切な制御をしないと、その変化によってグリッド内の 1 つのシステム・イメージが影響を受け、結果としてリソースの過負荷や、場合によっては DoS (サービス拒否攻撃) に陥る可能性があります。
リソースの問題に対するソリューション
1 つのソリューションは、各ワークステーションで未使用のリソースが他のワークステーションとの間でどのように融通され、共有されているかを監視するためのグリッド・モニターを作成する方法です。あるワークステーションに未使用リソースがあり、そのリソースが他のワークステーションとの間で適切に活用されていないことを監視システムが検出した場合には、分散型サービス監視 Web サービスはグリッド管理者やシステム管理者にアラートを送信し、管理者がログの詳細を調べて問題を解決できるようにします。
私が書いた記事「SOA における密結合の Web サービス」(developerWorks、2008年1月) では別のソリューションとして、ワークステーション・レベルで結合を切り替える機能を備えた Web サービスについて説明しています。ある Web サービスが、その Web サービスに対応するリソースが一定のレベルに達したというアラートを受信した場合には、この切り替えスイッチによってその Web サービスを疎結合から密結合に切り替えます。Web サービスを切り替える際には、いくつかの標準も切り替える必要があります (例えば疎結合用の WS-Context から密結合用の WS-Addressing に切り替える、など)。
分散型セキュリティー監視 Web サービスには、結合の切り替え用のスイッチ機構に加えて WS-Resource Framework または WS-Resource Transfer を含める必要があります。グリッド・レベルにあるこの Web サービスは、グリッド・レベルのリソースが一定のレベルに達した場合に一部の Web サービスを疎結合から密結合に切り替えるために WS-Notification 仕様と WS-Security 仕様を利用して、指定されたワークステーションにアラートを送信することができます。
この逆の場合には、指定されたワークステーション内で密結合に切り替えられた Web サービスのリソースが一定のレベルに達した場合に、そのワークステーション上には、グリッド内の分散型セキュリティー監視 Web サービスにアラートを送信できる Web サービスが必要になります。
企業間の連携
1 つの企業内にある分散型の監視 Web サービス・ホストが他のさまざまな企業にある類似のホストにアクセスする場合には、企業間の連携が必要になります。その理由は、以下に示すとおりです。
- 分散型セキュリティー監視 Web サービスのホストによって提供されるポリシーや標準、ツールに関して、相互運用性と互換性を確保する必要があります。
- さまざまな企業によるグリッドを動作させ、保護するためには、何を標準化するのか、また何に互換性と相互運用性を持たせるのかを決定する必要があります。
- 協調型作業に参加する企業は、セキュリティーのためにどのようなポリシーや標準、ツールを各社に適用するかについて合意する必要があります。
まとめ
セキュリティー監視サービス用のホストとして専用型にするのか分散型にするのかを選択する際には、開発者とテスター、そしてシステム管理者とグリッド管理者から成るチームが必要です。また、いずれかのタイプのホストを企業内と企業間で開発、マイグレーション、テスト、デプロイするための計画を事前に立案する必要があります。この記事で説明したような問題を解決することによって、Web サービスのセキュリティーを監視するための作業がずっと容易になります。IBM® Rational® ClearQuest® や IBM Rational Tester for SOA Quality、IBM Rational Functional Tester を利用すると、テストや欠陥追跡の時間を削減できるため、生産性を高めることができます。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について  | | | Judith M. Myerson はシステム・アーキテクト兼システム・エンジニアです。ミドルウェア・テクノロジー、企業単位のシステム、データベース・テクノロジー、アプリケーション開発、ネットワーク管理、セキュリティー、RFID テクノロジー、そしてプロジェクト管理を含む数多くの分野を得意としています。 |
記事の評価
| 
