レベル: 中級 Judith M. Myerson, Systems Architect and Engineer, IBM
2009年 04月 15日 概要: Web サービスを監視する場合、専用のセキュリティー監視ホストとしての Web サービスを用意するのと、分散型のセキュリティー監視ホストとして協調動作する、いくつかの Web サービスを用意するのとどちらがよいのでしょうか。この記事では、それぞれのタイプのホストの長所と短所を調べ、それぞれを使用してセキュリティーの問題を解決する方法を提言します。
はじめに
私は以前書いた記事「SOA での Web サービスのホストとしてセキュリティーを監視する場合、専用型と分散型のどちらを選ぶか」の中で、セキュリティー監視 Web サービスとして専用型と分散型のどちらを選ぶかを決定する際、監視の計画を立てる必要があることを説明しました。そしてそれぞれの方式の長所と短所を検証し、それぞれの方式を使用してセキュリティーの問題を解決する方法を示しました。また専用型の監視ホストではセキュアな通信が必要なことにも触れました。このセキュアな通信はデータ転送やデータ・アクセスを、イントラネットから別のイントラネットに対して行う場合や、イントラネットからクローズド・ネットワークに対して行う場合、あるいはクローズド・ネットワークから別のクローズド・ネットワークへ行う場合にも必要です。
この記事では、監視ホスト用の Web サービスと監視対象の Web サービスとの間の通信をセキュアに行うための方法について説明します。セキュアな通信方法について、IP 層のネットワーク・プロトコルとして IPv4 (Internet Protocol version 4) を使用する場合と IPv6 (Internet Protocol version 6) を使用する場合を比較します。またリモート・データ・センターのシナリオを例に、IPv6 ベースのワークステーションで、さらにはグローバルなグリッドで、監視 Web サービスと監視対象の Web サービスとの間にセキュアな通信を確立する利点について説明します。さらに、Web サービス間の通信に遅延がある場合に、それがセキュリティー侵害や、脆弱性をついた攻撃、リソースの浪費、さらにはシステム・クラッシュといった事態につながるのを避けるために、何をする必要があるのかも見ていきます。そして最後に、そうした問題を克服するための例をいくつか示します。
Web サービスを監視する
Web サービスを監視するために、複数のホスト上で複数の監視用 Web サービスを動作させることができます。中心となる監視ホストとしての Web サービスは、監視のための階層構造の最上位レベルで監視を行い、別の監視ホスト・サービスとの間で、さらには階層の下位レベルにある監視対象 Web サービスとの間で、セキュアな通信を行います。災害復旧計画では、フェールオーバー用の監視ホスト Web サービスと監視対象 Web サービスを指定しておく必要があります。必ず定期的にアプリケーションとデータをバックアップすることで、災害発生時の復旧が必要以上に遅れることを回避し、ビジネスの信用ひいては顧客を失う事態を避ける必要があります。
最上位レベルでは、中心となる監視 Web サービス・ホストをグリッドの中で分散実行されるように構成する必要があります。下位レベルの監視ホストは、そのホストが企業内にあるのか、あるいはグリッド内にあるのかに応じて、専用型にすることも分散型にすることもできます。専用ホストが企業内にある場合には、そのホストをグリッド内の他の監視サービスにセキュアに接続することができます。
監視 Web サービスは、ローカル・レベル、地域レベル、全世界レベルという 3 つのレベルで構成することができます。一部の監視 Web サービスはローカル・レベルでのみ実行され、親がありません。それ以外のローカル監視 Web サービスには地域レベルの親があり、そして全世界レベルの親があります。場合によると、全世界レベルに親としての監視 Web サービスがあり、地域レベルには何もない場合もあります。
要件を規定する
監視 Web サービスと監視対象の Web サービスとの間でセキュアな通信を行うための標準が有効に機能するためには、セキュアな通信を実現するための要件を規定する必要があります。そうした要件には以下の内容を含める必要があります。
表 1. 最低要件
| 項目 | 説明 |
|---|
| ID | そのエンティティーが監視 Web サービスや監視対象の Web サービスなのか、個人なのか、あるいは設備なのかを特定する必要があります。 |
|---|
| 認証 | 表明されたID のクレデンシャルを確認する必要があります。 |
|---|
| 承認 | 監視 Web サービスと監視対象の Web サービス、そしてユーザーに適切な許可が与えられており、それによって彼らに割り当てられたタスクを実行することができ、割り当てられていないタスクは実行できないようになっている必要があります。 |
|---|
| 機密性 | 想定外のものに、あるいは許可されていないものに情報が公開されないようにする必要があります。 |
|---|
| 完全性 | 想定外の情報変更や、悪意による情報変更がされないようにする必要があります。 |
|---|
| 否認防止 | 監視 Web サービスと監視対象の Web サービスが特定のメッセージの送受信を否定できないようにする必要があります。 |
|---|
クレデンシャルの交換
監視 Web サービスと監視対象の Web サービスとの間にセキュアな通信を実現するためのステップは 2 つあります。第 1 に、双方 (監視 Web サービスと監視対象の Web サービス) は相手が表明したセキュリティー・クレデンシャルが信用するに足るものかどうかを判断する必要があります。そのためには、そのクレデンシャルがライブラリーの中にあるのかどうかをチェックするか、あるいは外部でクレデンシャルを受け入れます。それが終わると両者はクレデンシャルを交換することができます。
Web サービスを使って通信するアプリケーションは、セキュリティー・クレデンシャルの取得、交換を WS-Trust を使って行うことができます。これはアプリケーションが直接行うことも、あるいは信頼できるサードパーティーを通して行うこともできます。また WS-SecureConversation を使うことで、監視 Web サービスと監視対象の Web サービスとがセキュアな形でメッセージを大量に交換できるセキュアなセッションを確立、維持することができます。
WS-Trust によって信頼関係を確立、検出、仲介することができます。WS-SecureConversation は WS- Security の制約を克服し、監視対象の Web サービスと監視 Web サービスとの間で 1 つのセキュアなメッセージを交換する形式にします。WS-Trust と WS-SecureConversation の両方を使うことによって、メッセージの交換に関する全体としてのパフォーマンスとセキュリティーを向上させることができます。
IPv4 と IPv6 のどちらがセキュアか
ここで、監視 Web サービスと監視対象の Web サービスとを接続するために必要なセキュアな通信について、IPv4 を使う場合と IPv6 を使う場合を比較してみましょう。第 1 に、グリッド内で IPv4 ベースのセキュアな通信を行おうとすると、監視 Web サービスと監視対象の Web サービスとをサイト・ツー・サイトで接続することしかできません。NAT (Network Address Translation) の問題とクライアント/サーバー型のビジネス・モデルのため、セキュアな通信が可能なのは片方向のみです。LAN セグメントのセキュリティーは低く、さまざまなベンダーの間でアプリケーションの相互運用を実現することは困難です。
第 2 に、IPv6 を利用すれば、サイト・ツー・サイトで接続する場合だけではなく、エンド・ツー・エンドで接続する場合もグリッド内でセキュアな通信を行うことができます。IPv6 ではネットワーク・セキュリティーに関する改善がいくつか行われており、広いアドレス空間、近隣探索、アドレス自動構成などが実現されています。IPv6 では IPSec が必須ですが、IPv4 ではオプションとして IPSec をサポートしているにすぎません。
IPv4 ではセキュアな通信といっても片方向ですが、対照的に IPv6 ではネットワーク側の機器とモバイル機器との間で双方向のセキュアな通信を実現しています。これによってクライアント/サーバー型のビジネス・モデルを実現できるばかりではなく、ピア・ツー・ピア・モデルやモバイル・モデルも実現することができます。IPv6 を利用すれば、新しい通信を容易にセットアップすることができます。
ただし IPv6 でセキュリティーが改善されているからといって、IPv6 が IPv4 よりもセキュアだということにはなりません。IPv4 の場合と同様、IPv6 も脆弱性をついた攻撃の対象となり得ます。ローカルなレベルでは IPv4 から IPv6 への完全移行は可能ですが、地域レベルや全世界のレベルで完全に IPv6 に移行するためには時間がかかります。グリッド内の監視 Web サービスを IPv4 から IPv6 に切り換えるかどうかは、そのグリッドに参加しているワークステーションの中で使われていないリソースをどう活用するかに依存します。
パフォーマンスの遅延を回避する
監視 Web サービスと監視対象の Web サービスとの間でのセキュアな通信に遅延が生じるのを避けるには、セキュアな通信のための標準を確立するだけではなく、システム・パフォーマンスの基準も設定する必要があります。システムのパフォーマンスが基準を下回ると、セキュアな通信に関して、脆弱性をついた攻撃を受けるリスクや、IPv6 への移行に関するセキュリティー上の問題が発生する可能性、そしてリソースが浪費される可能性などが高まり、それが SLA に影響し、最終的にはシステム・クラッシュを引き起こしかねません。
そうした事態が発生すると、監視 Web サービスはシステム管理者やセキュリティー担当者が即座に問題解決アクションを実行できるようにアラートを送信し、フェールオーバー用の監視 Web サービスに一時的に移行します。一方、ある時点でパフォーマンス基準を満たすことができなくなった監視対象の Web サービスも、監視 Web サービスのアラート機構をトリガーすると、フェールオーバー用の Web サービスに一時的に移行します。
シナリオ: データ・センターに対するリモート制御
ここでオペレーション・センターの例を考えてみましょう。このセンターでは、このセンターの監視 Web サービスと複数のデータ・センターにある監視対象の Web サービスとを、セキュアな通信を使用してリモート接続しています。オペレーション・センターからはリモート操作によって、カメラのピントを合わせたり、カメラの向きを変えたり、カメラから画像を取得したり、あるいは温度計をリセットしたり、温度計からデータを読み取ったり、外部の温度が大幅に変化した場合には温度計からアラートを受信してファンのスピードを調整したりすることができます。
監視 Web サービスは、複数のデータ・センターのリモート制御に関して IPv6 がどの程度適切に機能しているか、また各データ・センターがどのようなパフォーマンスになっているかを追跡する必要があります。また、オペレーション・センターと複数のデータ・センターの両方でシステム・パフォーマンスの基準を設定する必要があります。基準を設定する際には、脆弱性をついた攻撃を受けるリスクや、IPv6 へ移行する際に問題が発生する可能性、そしてリソースが浪費される可能性などを最も低く抑えられると思われる最適なレベルに設定する必要があります。
中心となる監視ホストは監視対象の Web サービスのパフォーマンスを比較します。その結果、センサーやパフォーマンスが異常な変化を示した場合にはシステム管理者にアラートを送信するように、監視 Web サービスを構成します。そうした変化は、たとえパフォーマンス基準を上回っている場合であっても、アップタイムに関する SLA 保証に影響する可能性があります。
まとめ
Web サービス同士の間にセキュアな通信を確立するためには、開発者、テスター、システム管理者から成るチームが必要です。どの Web サービスが監視を実行するホストなのか、どの Web サービスが監視対象なのかを事前に計画し、要件は何か、クレデンシャルをどのように交換するかを規定する必要があります。また、この記事のシナリオで示したように、IPv6 のセキュリティーをどのように改善するかも決定する必要があります。そうした問題を解決することによって、セキュアな通信を行う Web サービスの監視がとても容易になります。また IBM Rational® ClearQuest、IBM Rational Tester for SOA Quality、IBM Rational Functional Tester、WebSphere® MQ Low Latency Messaging を利用するとグリッド・レベルでのテストや欠陥追跡の時間を削減できるため、生産性を高めることができます。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について  | | | Judith M. Myerson はシステム・アーキテクト兼システム・エンジニアです。ミドルウェア・テクノロジー、企業単位のシステム、データベース・テクノロジー、アプリケーション開発、ネットワーク管理、セキュリティー、RFID テクノロジー、そしてプロジェクト管理を含む数多くの分野を得意としています。 |
記事の評価
| 
