今回のパターンの例は、Arnon Rotem-Gal-Oz氏が現在作成中している本(サイト･英語)からのものです。Arnon氏は、メッセージの送受信をしたり、専用のソフトウェアコンポーネントやハードウェアでそれらを検査するために、サービスファイヤーウォールをどのように利用するのかについて説明しています。
"無人地帯"を行きかうセキュアなメッセージやインフラストラクチャのパターンについて説明します。一般に、やりとりされるメッセージを保護するために、セキュアなメッセージ、若しくはセキュアなインフラストラクチャのパターンを利用します。しかし、メッセージの送り手に悪意がある場合、私たちはどうすれば良いでしょうか？攻撃者が悪意のあるメッセージ(例えば、SOAPに添付されたウィルス)を送信した場合、そのパターンでは、この悪意のあるメッセージが手をつけられず、誰にも見られていない状態で得たということを保証するということは、実際にはできないでしょう。
問題
悪意のある送信者の攻撃のタイプを説明することで、それらをもう少しじっくりと見てみることにしましょう。図１は、XMLによるDoS攻撃 (XDoS)を示しています。このタイプの攻撃は、悪意のある送信者がメッセージにたくさんのデジタル署名を添付します。このタイプの攻撃に対応できていないパーサーは、ロードでサービスの動きが低下している要因となっているこれらの署名全てを確認します。
図１：XDoS攻撃の説明。悪意のある送信者は、妥当に見せかけたXMLを用意し沢山のデジタル署名を添付します。それを知らないパーサーは、それらの署名を全て確認しようとすることで、CPUの使用率が低下しサービスが利用できない状態となります.
図１の中で示された受信メッセージを利用した攻撃は、私たちが対処しなければならない脅威の一つです。もう一つの関連する類の脅威または問題としては、送信メッセージに関連するものがあります。ここで、私たちは、個人的若しくは機密扱いの情報が、サービスの外に漏れないということを保証しなければなりません。この種のシナリオでは、私たちは、サービスの外では契約フローで許可された情報のみを保持しているということを保証するための方法を見つけたいと思います。
悪意のある受信メッセージの検知に対し、どのようにしてサービスを保護し、送信メッセージに関する情報公開をどのようにして防止しますか？
悪意のある送信者に対処するための一つの選択肢として、Secured Infrastructureパターン(SOA Patternsの4 章の初めで説明しています)を適用し、権限のあるクライアントに対し認証を要求するという方法があります。これは、認証されていないクライアントは、システムにアクセスすることができないということです。このアプローチの問題の一つとして、サービスコンシューマの数がコントロールされるので、(例えば、インターネット上に公開されているなどのように)一般に公開されていないときにだけ有効であるということです。認証アプローチのもう一つの制限として、システムへのアクセスが許可されると、内部からの攻撃に対処することができないということがあげられます。
もう一つの選択肢として、ビジネスロジックの一部として、悪意のある内容を選別するためのセキュリティロジックを組み込むという方法があります。このアプローチにもいくつか問題があり、それは、全てのサービスに共通した多くの脅威に対して重複したコードが作られるということです。もう一つの問題点として、ビジネスロジックがセキュリティロジックによって汚され、実装とその保守が非常に困難になるということです。
より良い選択肢として、もう一つのコンポーネントにセキュリティをおくことです。より詳しく、この選択肢について見ていきましょう。
解法
SOAメッセージはアプリケーションレベルのコンポーネントです。しかしながら、メッセージの概念は、新しいものでもなく、SOA特有のものでもありません。私たち(コンピュータ産業において)は、既に、OSIスタックの低レベルなメッセージにおける数多くの見識があります。それは、ネットワークレベル、特に、TCPパッカーやUDPデータグラムに関してです。TCPとUDPには、SOAメッセージとほとんど類似点がありません。興味深いのは、このパターンの目的で、彼らが直面する脅威です。その脅威がおそらく似たものであるので、私たちは、TCPのために機能すると分かったものをSOAのメッセージのために利用し、同じ解決策を用いることもできるのです。
Service Firewallパターンを実装し、送受信メッセージをインターセプトすることで、専用のソフトウェアコンポーネント若しくはハードウェアでそれらを調べてみます。
図２：Service Firewall パターン。サービスファイアウォールは、外界と実際のサービス（またはエッジ）の間に配置します。サービスファイアウォールが走査し、送受信両方のメッセージの妥当性確認と検査を行います。一旦メッセージが問題あるものとして特定されると、それはフィルターにかけるか、駆除されます。
.
Service Firewall パターンは、Edge Component パターンのアプリケーションです。図２は、サービスファイアウォールがどのように行われているかを示したものです。まず初めに、送受信メッセージそれぞれをインターセプトし、検査します。一度インターセプトされたら、サービスファイアウォールが先の例のシナリオで述べたようなウィルスやXDoS攻撃といった、悪意のある内容のメッセージであるかどうかをチェックします。加えて、サービスファイアウォールは、規約どおりになっているかの確認や、プロパティタイプやサイズの検証などをおこなうことによって、メッセージの妥当性をチェックします。問題のあるメッセージであると特定されたときは、メッセージを検査してログに残します。そして、それをフィルターにかけるか問題のある内容を駆除するかどうかを決め、それを通過させます。
サービスファイヤーウォールは、サービスを第一線で防御するためのものとして機能します。下記の図3の中で示されるように、リクエストがファイアウォールに到達すると、それを検査し、妥当であるかを確認します。認可されたリクエストは、本当のサービス（またはもう一つのエッジコンポーネント）に送られます。
図３：リクエストがサービスファイアウォール(図中のXML firewall)に到達すると、妥当性を確認しふるいにかけられます。例えば、Firewallは、XMLが事前に定義されたXSDにマッチしているかどうかをチェックします。認可されたリクエストは通過し、認可されなかったリクエストは拒否されます。
サービスファイアウォールの背景にある考えは単純です。しかしながら、その実装はそれぞれの役割(検査、妥当性確認、フィルターなど)を果たすために実装しなければならない機能が沢山あるため、少し複雑です。それに加えて、サービスファイアウォールが、全てのメッセージに対し機能できることを保証するための方法が必要となります。
技術マッピング
.第1章のパターン構造で述べたとおり、技術マッピングの部分は、現在の技術がパターンを実装するという例に言及するだけでなく、既存の技術を利用しているパターンを実装するというのがどういうことなのかを少しみてみます。
Service Firewall パターンを実装するための最も簡単な方法は、検査やバリデーションロジックを実装するところに、指定されたエッジコンポーネントを作ることです。一旦ファイヤーウォールロジックが作られると、それはDMZ上にデプロイします。通常のファイヤーウォールの背後にある本当のサービスをデプロイし、全てがセットされます。エッジコンポーネントは、きちんと処理して不要なリクエストをブロックし、通常のファイヤーウォールがその他の攻撃をブロックします。
通常のファイヤーウォールを使用しないでService Firewall パターンを実装するには、少し問題があります。攻撃者が、単純に実際のサービスに使用されているエンドポイントを呼び出して、サービスファイやウォールを完全に無視することができるからです。これらの状況下においては、インターセプトの機能に頼ることができます。例えば、図４で示すように、関係のある拡張ポイントは、インターセプトする受信メッセージに対しWindows Communications Foundationによって提供されています。
図４：WCFでは、メッセージが入ってきたとき若しくは出て行くときに、メッセージを取り扱うための方法を制御するための拡張ポイントが、数十個サポートされています。一般に、Service Firewall パターンで定義された別々の役割を実装するために、これらの（上で表される）拡張ポイントのうちの4つを使うことができます。
図４に示すように、(WCFによってサポートされている数十個の拡張ポイントの中の)４つの関係する拡張ポイントがあり、それらは、Service Firewall パターンの様々な役割を遂行するためのクラスを利用します。送受信両方のメッセージに対して、アドレスの妥当性確認、規約の妥当性確認、メッセージの検査、パラメータの検査などのクラスを利用することができます。次に示すように、メッセージがサービスの中や外を通過する際に、インターセプターとしてこれらのクラスを追加するためのコードを利用することができます。
次のコードは、WCFによって取り扱われる送受信メッセージのインターセプターを追加するためのWCFのコードです。これらのインターセプターを、Service Firewall パターンの実装や、妥当性確認、検査などに利用することができます。送受信全てのメッセージがここを通過します。
public void SetInterceptors(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
{
foreach (ChannelDispatcher ChannelDisp in serviceHostBase.ChannelDispatchers)
{
foreach (EndpointDispatcher EndPointDisp in ChannelDisp.Endpoints)
{
EndPointDisp.DispatchRuntime.MessageInspectors.Add(new MyMessageInspector());
foreach (DispatchOperation op in EndPointDisp.DispatchRuntime.Operations)
op.ParameterInspectors.Add(new MyParameterInspector());
}
}
}
Service Firewall パターンのもう一つの実装として、ハードウェアや組み込みアプライアンスの利用があります。例えば、Layer7、IBM、Vordelやその他いくつかの企業が、XMLファイヤーウォールアプライアンスを提供しています。XMLアプライアンスを利用する優位点は、DMZの他のファイヤーウォールと共にそれをデプロイすることができ、それを第一線の防御として利用することができることです。もう一つの優位点として、これらがXMLを取り扱う上で最適化されたプラットフォームであるので、そのアプライアンスのパフォーマンスへの影響は、セルフコーディングによるソリューションと比べて低いということです。ハードウェアのXMLファイヤーウォールを利用する不利な点として、セットアップのコスト(ユニットあたり数万)があげられます。もう一つの不利な点としては、追加のハードウェアを管理することと、SOA規約(サービスとアプライアンスの両方で)の倍の管理の両方によって増加するメンテナンスの複雑さがあげられます。
アプライアンスを利用するにせよ、Service Firewall パターンのコードを実装するにせよ、DoS攻撃の脅威を未然に防いだり、サービス自身にいくつかのバリデーションを保持するといったことで、実際にサービスのセキュリティを高めることができます。
品質特性
この章の始めで記したように、セキュリティパターンに対する品質特性の部分に関しては、そのパターンが防ぐ脅威について説明します。
Service Firewall パターンは、非常に用途の広いパターンで、多くの種類の脅威を取り扱うことができます。次に示す表は、脅威の分類とService Firewall パターンの実装がその分類の脅威に対して防御できる対処法を示しています。
| 脅威 | 脅威への対処 |
改ざん |
|
| 情報公開 |
|
| DoS |
|
| 権限取得 |
|
表１：脅威の分類とその対処。サービスファイヤーウォールの実装で上記対処のリストを行うことができ、脅威を低減します。
Service Firewall パターンの脅威を低減する特性に加えて、より広い範囲で品質特性を見ることもできます。(書籍の)４章にあるほとんどのパターンと同様に、Service Firewall パターンはセキュリティパターンです。興味深いことに、他の大部分のセキュリティパターンとは異なり、プロジェクトの終わり頃にそれを追加することが比較的容易です。しかしながら、完全に自由に扱えるというものではないという点に注意しなければなりません。システムのパフォーマンスへの影響を測定しなければなりません。加えて、メンテナンス契約に関する経費なども考慮しなければなりません。
この章も終わりに近づき、扱いやすさに関するパターンについて話し始めるときが来ました。次のパターンはIdentity Providerパターンです。セキュリティと管理容易性を兼ね備えている側面があり、それへの移行を支援します。
原文はこちらです：http://www.infoq.com/articles/service-firewall
（このArticleは2007年6月18日に原文が掲載されました）