LDD Today

iNotes Web AccessをWebSphere Edgeリバース・プロキシー・サーバーを活用して使った構成

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: LDD Today

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:LDD Today

このシリーズの続きに乞うご期待。

あなたはついに生涯二度とないような休暇をとりました。東京の街をあちこち歩きながら、ポケベル、PDA、ラップトップ、そして携帯電話を家に置いてきたことに驚くばかりでした(実は、あなたの妻が、ラップトップをこの旅行に持って出たら離婚すると脅したのです)。あなたは妨げられることも煩わされることもなく、またとない楽しい時を過ごしていました。ところが、パーツ・ショップの前を偶然通りかかり、「旅行に出る前に、10万個のパーツを発注することを忘れてたぞ!」と出し抜けに思い出しました。そこで公衆電話を使おうとしますが、運の悪いことにテレフォン・カードを持っていませんし、電話の使い方もわかりません。それに、アメリカではこの時刻、本社は閉まっています。動揺が高まる中で、飛行機で帰国して自分で発注しようかとも考えました。しかしそのとき、突然インターネット・カフェが目に入りました。「救いの神だ!」妻には10分で戻るといって、インターネット・カフェに駆け込みました。

トークンを手にして、URLを入力しました。ブラウザーがログイン画面を表示したので、そこにユーザー名とパスワードを入力しました。外科手術のようにきわめて正確に、10万個のパーツの注文を許可するメモを手早く入力しました。注文を出し、店にいる間に重要な電子メールをチェックし、その後その店を出て妻のところに戻って昼食をとりました。こうして休暇が台無しになることなく、ビジネスでは大口の注文を逸することもありませんでした。これぞサクセス・ストーリーです。

たまたま見つけたインターネット・カフェからこれを安全に行うことができたのはどういう魔法のおかげでしょうか。運のいいことに、あなたの会社ではIBMとLotusが提供する、企業対応メッセージング・ソリューションのDominoとiNotes Web Accessを使用していました。これはWebブラウザーを利用する堅固なNotesクライアント用高機能メッセージング機能、たとえば、電子メール、カレンダー&スケジューリング、PIM、タスク管理、および個人用ジャーナリングなどを提供します。Domino Off-Line Services(DOLS)を使用して、これらの機能をオフラインで使用することもできます。

それは申し分ないこととして、セキュリティーについてはどうなのでしょうか。どうすればサーバーをWebユーザーが利用できるようにしながら、データを無許可アクセスから確実に保護できるのでしょうか。もうお察しのこととは思いますが、この記事ではまさにこの話題を論じるつもりです。この東京の例では、あなたがインターネットのローミング・ユーザーで、iNotes Web Accessを使って一般のブラウザーからセキュア・ビジネスを行っていると想定しています。これを実行するには、CAがサポートするSecure Socket Layer(SSL)を用いて電子メールにパブリック・アクセスするためのインターネットDNS名が必要です。この記事では、これを実行するために、WebSphere Edgeプロキシー・サーバーを使用して会社のイントラネットを無許可ユーザーから保護しながら、環境をセットアップする方法について説明します。

この記事は、あなたがDominoおよびEdgeサーバー環境に精通した、経験豊富なシステム管理者であると想定しています。

セキュリティーの概要

World Wide Web Consortium(英語)の一部の真に才能ある人たちのおかげで、ブラウザーがWebサーバーに接続する方法のルールを示す一連の規格文書(Request for CommentsまたはRFCと呼ばれる)のセットを手にすることができます。この記事で特に注目するRFCは以下のものです。

  • RCF1738(URL定義)
  • RFC1521(HTTP 1.1)
  • RFC2251(LDAP)

Dominoはこれらの規格を使ってサーバーへのWebアクセスを提供します。もちろん、これを安全に実行するには、サーバーにアクセスしようとしている人物を識別して認証する方法が必要であり、メール・ファイルなどの重要データが関係している場合には特にそう言えます。そこで、Dominoはいくつかのタイプのユーザー認証を備えており、それには以下のものがあります。

  • 基本(ユーザー名/パスワード)(SSLを使用または未使用)
  • セッション・ベース(SSLを使用または未使用)
  • ユーザー証明書ベース
  • LDAP認証ベース(ディレクトリー・アシスタンス機能を使用)
  • LTPA(Lightweight Third Party)ベース

(上記リストに挙げた最初の2つの認証メソッド-基本およびセッション・ベース-については、この記事の後のほうで簡単に説明します。他のタイプの認証の詳細については、Domino Administrator 6ヘルプを参照してください。)

Dominoは、これらの認証メソッドの1つを使用して、アクセスを許可する前に身元を明らかにするようリクエスターに求めます。実世界では、名前を名乗るように求めますが、コンピューターの世界でもしばしば同じことをします。名前、つまりユーザーIDを尋ねるのです。ユーザーに、IDとパスワードを提示するように求めることで、セキュリティーはさらに向上します。

基本認証

認証の最も単純な形式は、基本認証と呼ばれます。このメソッドでは、アクセスするために、ユーザーに有効な名前とパスワードの提示を求めるだけです。たとえば、ブラウザーを使用して、電子メールにアクセスするとします。その場合に、Dominoサーバーはブラウザーにステータス・コードを戻します(例-401)。このステータス・コードによって、ブラウザーはユーザー名とパスワードの入力を求めるプロンプトを生成し、このデータはサーバーに送り返されます。基本HTTP認証では、パスワードは暗号化されないプレーン・テキスト、「uuencode」テキストとして、ネットワークを経由して受け渡されます。

ハッカーはIP探知プログラムおよびスキャナーを使用して、セッション中にクライアントとサーバーとの間を行き来したすべてのパケットのコピーをキャプチャーすることができます。したがってこの情報は、暗号化されていないプレーン・テキスト・フォーマットで入手することができます。誰でもネットワーク上のパケットのトラフィックを監視する人には、uuencode形式でエンコードされたパスワードが平文で(暗号化されていない状態で)見えますが、パスワードは適切なネットワーク・パケットを捕捉する人によって簡単にデコードできます(uuencode処理は暗号化ではないので、誰でもプログラムをダウンロードして、パケットをデコードして他者のパスワードを入手できます)。事実、ユーザー名とパスワードが関係している認証オプションの大半は、証明書情報をプレーン・テキストとして渡します。言い換えれば、悪い連中はあなたのパスワードだけでなくユーザー名さえも傍受できるのです。

セッション・ベース(SSL)認証

それでは、ユーザー名、パスワード、そして他のデータを安全に保つにはどうしたらよいのでしょうか。答えはSSL(Secure Socket Layer)にあります。冒頭のニューヨークの物語を思い出してください。SSLを使用すれば、インターネット・カフェからのトランザクションも暗号化でき、自分のユーザー名とパスワード(および他のすべてのデータ)も安全であるとわかります。

SSLの最も基本的な機能の1つは、メッセージ・プライバシーです。SSLはクライアントとサーバーとの間のセッションを暗号化できるので、アプリケーションは、ユーザー名とパスワードを盗聴者にさらすことなく交換して認証することができます。SSLを使用すれば、初期ハンドシェークに続くすべての伝送は暗号化され、電送内容は捕捉できなくなります。クライアントとサーバーは、証明書を交換することによってそのIDを証明します。それに続くSSLサーバーとSSLクライアントとの間のすべてのトラフィックは、セッション初期設定時のSSLハンドシェークの間にネゴシエートされた鍵および暗号化アルゴリズムを使用して暗号化されます。次いで、SSLプロトコルは、送信側と受信側との間のメッセージが、伝送時に改ざんされなかったことを確認します。これによってクライアントとサーバーとの間の安全な通信路が保証されます。

SSLは、ハッシュ関数として知られる数学関数の組み合わせを使用します。このプロセスにはサーバー認証が組み込まれています。これは、証明書の交換によってサーバーIDを判別するプロセスです。サーバーのIDは、SSLハンドシェーク中に交換される公開鍵証明書内に組み込まれています。

SSLは、そのセキュリティーとサービスをエンド・ユーザーに対して透過的にするように設計されました。通常、ユーザーはURL(RFC1738(英語)を参照)に従って、SSL対応サーバーに接続するページに進みます。デフォルトでは、SSL対応サーバーは、ポート443上での接続要求を受け入れます(SSL以外のアクセスのデフォルト・ポートは80です)。ハンドシェーク・プロセスでポート443に接続する場合、これはSSLセッションを確立します。サーバーとクライアントとの間のすべてのトラフィックはこれで暗号化されます。つまり、ユーザー名とパスワードは安全だということです。

許可およびトラステッド・ネットワーク

許可とは、ユーザーがオブジェクトに対する適切なレベルのアクセスを与えられるプロセスです。メール・ファイルの場合は、標準のDomino機能によって許可する内容を制御できます。必要なのは、ユーザー名(またはグループ)を、メール・ファイルのACLに追加することだけです。ネイティブのDomino登録プロセスがその管理を行います。

ただし、コンピューター・インフラストラクチャーの一部をインターネットに公開しようと決めた場合、使用するネットワークのどの領域がトラステッドおよび非トラステッドであるかを定義する必要があります。たいていの状況では、インターネットは非トラステッド・ネットワークとみなされます。経験則として、データが一度インターネットに公開されると、誰しもが見るところとなります。

トラステッド・ネットワークは、内部業務を行うために使用するネットワークです。トラステッド・ネットワークは一般に、バックエンド・システム、内部専用Webページ、データ処理、メッセージング、および場合によっては内部インスタント・メッセージングをサポートします。多くの企業では、トラステッド・ネットワーク上で、暗号化せずに直接システム間で対話ができます。さらに、トラステッド・ネットワーク内には、どのタイプのフィルターも、ウィルス・スキャンさえもなしに、さまざまなプロトコルを存在させることができます。
結果として、トラステッド・ネットワークは必ずしも安全なネットワークではありません。事実、トラステッド・ネットワークはしばしば信頼(トラスト)できないのです。たとえば、内部ネットワークは数多くの異なるネットワークで構成することができます。これには新規の企業買収、ジョイント・ベンチャー、国際アクセス・ポイント、およびインターネットの世界の外部への複数の接続が含まれます。

非武装地帯(DMZ)

ご使用のトラステッド・ネットワークを本当に信頼できるものとするために、DMZ(非武装地帯)を経由して外界への単一アクセス・ポイントを作成することができます。DMZは、会社のトラステッド・ネットワークと非トラステッド・ネットワークとの間の緩衝地帯として配置される、隔離されたネットワークです。DMZによって、外部ユーザーはトラステッド・ネットワークに直接アクセスすることができなくなります。

以下の図は、DMZの基本的なセットアップを示しています。非トラステッド・ネットワーク(この場合はインターネット)は、DMZの最上部に示しています。トラステッド・ネットワークは、図の最下部に示しています。トラステッド・ネットワークにアクセスするには、DMZを通過する必要があります。

たいていのDMZは、一連のルールに従って構成されています。これらのルールは複数のポリシーによって制御され、組織の一連の手順としてインプリメントされます。最も一般的なルールの1つは、DMZをバイパスするプロトコルは1つとしてないというものです。別の一般的なルールは、TCP/IPトランザクションを、トラステッド・ネットワーク内に直接実行することはできないというものです。言い換えれば、すべてのTCP/IPトランザクションはDMZで停止し、再確立してからトラステッド・ネットワークに入って実行を続行する必要があるということです。つまり、DMZが実行することは、信頼できないトラフィックがトラステッド・ネットワークに入らないようにすることです。DMZの役割とは、フィルター操作、認証、およびある場合は必要に応じて完全にトラフィックをブロッキングすることによって、トラステッド・ネットワークへのアクセスを制御および制限することです。
それでは、DMZはインバウンド・トラフィックにどう役立つのでしょうか。以下に示すのはそのリストの一部です。

  • サービス妨害(DoS)またはTCP/IPSyncフラッディングなどの、さまざまなアタックに対するフィルター操作および管理
  • ウィルス、コンテンツ、およびサイズについての電子メール・メッセージのスキャン
  • 受動盗聴/パケット探知のブロック
  • アプリケーション層アタックのブロック
  • ポート・スキャンのブロック
  • 各プロトコル毎のトラステッド・ネットワークへのアクセスの制限
  • IPアドレス・スプーフィングのブロック

たとえば、ある会社ではトラステッド・ネットワークでデータの部分コピーを作成し、それをDMZ内のサーバーに移動(または複製)します。業務データはDMZ内に置かないとする厳格なポリシーがない限り、これは良いアイデアになるでしょう。この場合、要求を代行受信し、ユーザーを認証し、その要求をトラステッド・ネットワークのサーバーに転送するアプリケーションが必要になる場合があります。それでおわかりのように、何にでも対応できる、といったものはありません。

また、Dominoのケースを考えてみましょう。たとえば、インターネットを経由してアクセス可能にしたいメール・ファイルが10本あるとします。小規模なサーバーを簡単に構築して、それをDMZ内に置き、10本の実稼動しているメール・ファイルを複製します。これらすべてはうまくいき、多くの顧客もこれを実行しています。しかし、おそらくあなたは2,000本、あるいは20,000本ものメール・ファイルをお持ちのことでしょう。それで多くのサーバー(そしておそらく複数のNotes/Dominoドメイン)を構築し、大規模な複製スケジュールを管理することが必要になります。これはあっという間にとんでもないほど膨大な雑務となる可能性があります。

これまで、DMZを使用してインバウンド・トラフィックを制御することを説明してきました。ただし、DMZはアウトバウンド・トラフィックを制御するためにも使用されます。加えて、それによってトラステッド・ネットワークの設計と構成を隠す(マスクする)こともできます。DMZは、プロキシー・サーバー(この論題については後で取り上げます)およびフィルター・サーバーを経由したインターネットへのアクセスを制限するように設計することができます。これらのサーバー(ポリシー文書で設定されている制限によって調整される)は、以下を実行することができます。

  • 宛先、サイズ、およびコンテンツに基づいて電子メール・メッセージを制御する
  • DMZから出るウィルスをスキャンする
  • 許可されていないサイトへのアクセスを制限する
  • 許可されていないサイトへのアクセスをモニターする

プライベート・ネットワーク

今日の会社では、内部IPアドレス体系を外部のインターネットから隠すことによって、プライベート・ネットワークをセットアップすることが一般的な1つの慣例となっています。DMZでのルーターの使用はこれを実現するために役立ちます。この技法は、ネットワーク・アドレス変換(NAT)として知られています(詳細については、RFC1631を参照してください)。以下の図は、単一アドレスが192.9.0.0ネットワークにマップされる例を示しています。

これはセットアップが非常に簡単で単純です。実際、ホーム・ルーターを100ドル以下で購入して、ご使用のケーブル・モデムやDSL接続について同じことを実行できます。プライベート・アドレス・ネットワークの詳細については、RFC1591(英語)を参照してください。プライベート・ネットワークの使用には、以下のような多くの利点があります。

  • すべてのトラフィックに対して、非常に少ないセットのIPアドレスで済む。
  • プライベート・アドレス方式によって、ハッカーによるネットワーク攻撃が難しくなる。
  • 同じネットワーク上のすべてのインバウンド・トラフィックをブロックできる。たとえば、192.9.200.0を使用しているなら、そのネットワークからパケットを送信している人は誰もがハッカーです。ルーターに指示してそれらのパケットを破棄することができます。
  • 内部ルーティングを意のままに管理および制御できます。ルーターに加えられる変更は、インターネット上のルーティングには影響を与えません。

プロキシー・サーバー

トラステッド・ネットワークの内外でのアクセスを制御する別の方法では、プロキシー・サーバーを使用します。プロキシー・サーバー(アプリケーション・ゲートウェイとしても知られます)は、トラステッド・ネットワークと非トラステッド・ネットワークとの間のトラフィックを仲介するアプリケーションです。これによってトラフィックをIPレベルで管理するファイアウォールの必要性がなくなるわけではありませんが、アプリケーション・レベルのファイアウォールが備えられます。多くのプロキシー・サーバーには、ユーザー認証用の特別のロギングまたはサポートが入っています。次の図は、アウトバウンド・プロキシー・サーバーの簡単な例を示しています。

トラステッド・ネットワークを出る前に、すべてのトラフィックはスキャンされます。さらに、すべてのリターン・トラフィックは、ユーザーに戻される前にスキャンされます。たいていのプロキシー・サーバーは、キャッシング機能を提供することもできます。ページが複数回アクセスされた場合、プロキシー・サーバーにキャッシュされ、さらに高速なアクセスができます。

関連した概念は、リバース・プロキシーです。これは、インターネットとご使用のWebブラウザーの間、通常はDMZに置かれるサーバーです。リバース・プロキシー・サーバーは、インターネットから着信するユーザー要求を代行受信し、それらを適切なWebブラウザーに転送します(Sametimeなどの他のアプリケーションも、リバース・プロキシーに対応することができます)。以下の図は、リバース・プロキシーの例を示しています。

おわかりのとおり、上図はリバース・プロキシー・プロセスにおける4つの基本ステップ(A~D)を示しています。

  1. ブラウザーのユーザーは、Webページを開くようにとの要求を出します。このURLは、DNSエントリーを経て、DMZに送信されます。
  2. B要求はリバース・プロキシー・サーバーに入り、トラステッド・ネットワーク内の宛先に送信されます。これは、一連のルールまたは構成文書によって制御されます。例:URLが/mailの場合、トラフィックはhttp://192.9.200.55/mailに送信されます。
  3. 要求はDMZを出て、ターゲット・サーバーに送信されます。
  4. 要求はターゲット・サーバーに入り、処理されます。

リバース・プロキシーを使用すると、トラステッド・ネットワーク上の単一のサーバーにアクセスを制限することができます。リバース・プロキシーは、ルール・セットで許可されているものを除いて、すべてのトラフィックをブロックします。これは、リバース・プロキシーは、トラステッド・ネットワーク上の他のサーバーとそのリソースへのアクセスの試行を停止するという意味です。「でもハッカーの連中はリバース・プロキシー・サーバーに侵入してサーバーにアクセスできるじゃないか!」と主張する人もいることでしょう。ご心配なく。たいていのリバース・プロキシー・サーバーでは認証を提供しています。リバース・プロキシー・サーバーでユーザー名とパスワードの入力を求めることによって、DMZへのアクセスを制限することができます。

リバース・プロキシー環境のインストール

ここまでで以下の点を論じてきました。

  • iNotes Web Access: LotusとIBMが提供する堅固なWebベース電子メール・システム。
  • SSL: インターネット上を転送されるユーザー名、パスワード、およびデータを保護するために使用される、ネットワーク層セキュリティー暗号。
  • DMZ: トラステッド・ネットワークをインターネットから分離する地帯。
  • プロキシー・サーバー: トラステッド・ネットワークとのアクセスやデータのやり取りを制限するシステム。
  • リバース・プロキシー: トラステッド・ネットワーク内のサーバーへのアクセスを制御するシステム。

この記事の残りの部分では、これらすべてをまとめて単一のソリューションに組み込む方法を説明します。目標は、トラステッド・ネットワーク内のDominoサーバー上にあるメール・ファイルへのセキュアなアクセスを提供することです。さらに、トラステッド・ネットワークへのアクセスを、Dominoサーバーだけに制限したいとも考えています。この例では、IBM WebSphere Edgeサーバーをリバース・プロキシーとして使用します。
理論上は、どのリバース・プロキシーでもこのソリューションに使用できます。実際、以下のサーバー/装置が、企業のプロダクション・サイトで使用されてきました。

リバース・プロキシー:

  • WebSphere Edgeリバース・プロキシー・サーバー
  • Tivoli Policy Director
  • NetegrityのSecure Reverse Proxy Server
  • SunのiPlanet
  • Neoteris Reverse Proxy Webアプライアンス
  • Whale E-Gap

SSLアプライアンス:

  • Redline SSLアクセラレーター

WebSphere Edgeサーバー

IBM WebSphere Edgeサーバーは、企業のサーバー・マシンに保管されている文書にアクセスするユーザーと、インターネットにアクセスする内部ユーザーにサービスを提供します。Edgeサーバーは、Webコンテンツにアクセスしたり、能率的かつ経済的なインターネット・アクセスを提供したりすることができます。Edgeサーバーという名前が示唆しているように、通常このソフトウェアは、企業のイントラネットとインターネットとの境界に(ネットワーク構成の観点から)近いマシン上で稼動します。Edgeサーバーは、以下のようなさまざまな役割で動作します。

  • フォワード・プロキシー
  • リバース・プロキシー
  • キャッシュ・プロキシー
  • IPディスパッチャー(複数サーバー構成でロード・バランシング用に使用される)

この記事では、Edgeサーバーを、インバウンド認証と共に、リバース・プロキシー構成でインストールします。これによってユーザーに2回のプロンプトを出すことができます。1回はDMZへのアクセス用、もう1回はDominoサーバーへのアクセス用です。この例では使用しませんが、シングル・サインオン(SSO)を利用できることに注意してください。

ユーザーに2回のプロンプトを出すのは、セキュリティー上の理由もあり、心理的な理由もあります。インターネットを経由してトラステッド・ネットワークにアクセスすることが必要なすべてのユーザーは、ユーザー名とパスワードを使用してトラステッド・ネットワークにアクセスする必要があります。多くの会社では、これをセキュリティー要件として構成し、DMZにアクセスするために異なるユーザー名とパスワードを従業員に使用させます。2つの異なるユーザー名とパスワードを持つことによって、セキュリティーをさらに向上させることができます。どの場合でも、会社にとってどれが最適に機能するかを判別する必要があります。2つのプロンプトを示す別の理由は、Edgeサーバーの基本機能を説明するためです。

Edgeサーバーは、以下のシステムにインストールできます。

  • AIX
  • Solaris
  • Linux
  • Windows

ハードウェアおよびソフトウェア要件については、WebSphere Edge Serverの資料を参照してください。以下の手順では、Edgeサーバー・ソフトウェアと資料が利用できることを前提としています。

Edgeサーバーのインストール

  1. Edgeインストール・パッケージを実行します。インストール・プログラムはtempディレクトリーにファイルを展開します。そのディレクトリーからsetup.exeファイルを実行します。
  2. 情報画面が2つ表示され、使用許諾契約がそれに続きます。それに同意した後に、以下の[Component Selection(コンポーネントの選択)]画面が表示されます。

    この画面で、使用可能にしたいコンポーネントを選択します。[Caching Proxy(キャッシング・プロキシー)]を選択し、[Next(次へ)]をクリックします。これによって、インストールの構成の部分(この記事の次のセクションで説明します)でリバース・プロキシーをセットアップすることができます。
  3. Edgeコードがインストールされます。サーバーをリブートし、構成ウィザードを開始してリバース・プロキシー・サーバーをセットアップします。
  4. [Select Proxy Behavior(プロキシー動作の選択)]プロンプトで、[Reverse Proxy(リバース・プロキシー)]を選択して[Next(次へ)]をクリックします。
  5. [Select Proxy Port(プロキシー・ポートの選択)]プロンプトで、ポート番号を入力します(デフォルトは80)。
  6. [Target Web Server(ターゲットWebサーバー)]プロンプトで、プライマリー・インバウンドURLを入力します。

これでEdgeサーバーはインストールされ、構成できるようになりました。この時点で、ファイアウォール管理者と共に構成を検討して、必要なすべてのルール・セットが適所に配置され機能していることを確認することができます。特に、大半の構成では、インターネットからリバース・プロキシー・サーバーのDMZアドレス(この例ではProxy.forMyMailServer.Web)に入ることを許可するのは、ポート443(SSL)だけにするべきです。リバース・プロキシー・サーバーは、ポート80(非SSL)またはポート443(SSL)接続のどちらかを、内部Dominoサーバー(たとえばiNotes.forMyMailServer)に戻って開けるようにする必要があります。このタイプのファイアウォール規則では、直接接続によってインターネット・ベースの要求を内部Dominoサーバーに送信することはできなくなります。すべてのトラフィックは、プロキシー・サーバーによってフィルター操作される必要があります。

Edgeサーバーの構成

ソフトウェアそのものの構成は2カ所で実行されます。プロキシー・サーバーの管理業務の大半は、Webブラウザーの管理インターフェースから実行されます。これによって、毎日のサーバー運用に必要な構成パラメーターの95%に直接アクセスすることができます。ただし、管理インターフェースからは利用できず、ibmproxy.confファイルを編集して変更する必要があるいくつかの項目があります。

Edge管理インターフェース

管理インターフェースを開くための最初のURLは、http://Proxy.forMyMailServer.Web/admin-bin/webexec/frameset.htmlです。SSLをシステムに対して構成すると、これはhttpsに変更されます。URLをクリックして、[Administration(管理)]画面を開きます。ユーザー名とパスワードを入力するように求められます。

([Administration(管理)]画面が表示されない場合は、構成ウィザードで、プロキシー・ルールを[Mapping rules(ルールのマッピング)]セクションのルール・リストの最初に置いたことが原因の可能性があります。この問題は、c:\program files\ibm\edge\cp\etc\en_USディレクトリーの下にある、ibmproxy.confファイルを手動で編集することによって修正できます。(# *** ADD NEW MAPPING RULES HERE ***セクションの下の、プロキシー/*http://iNotes.forMyMailServer.Web/*ディレクティブを移動させます。) すべての手順がうまくいけば、管理インターフェースが以下の画面で示すように表示されます。このインターフェースは、プロキシー・サーバーの大半の操作機能へのポータルです。いくつかの例外を除いて、すべての構成変更はここから実行できます。

[Proxy Settings(プロキシーの設定)]セクションでは、プロキシー・サーバーがどのプロトコルをサポートするかを制御します。以下の構成では、サーバーはHTTPプロトコルだけをサポートします。他のすべてのプロトコルは使用不可にする必要があります。その他の設定は、以下のようにデフォルト値のままにしておくことができます。

[Privacy Setting(プライバシーの設定)]セクションでは、追加HTTPヘッダーを要求と共に渡すようにすることができます。ここで加えるべき変更は、[Forward client's IP address to destination server(クライアントのIPアドレスを宛先サーバーに転送)]の設定を使用可能にすることだけです。これによって、要求元のクライアントの実IPアドレスが含まれた追加HTTPヘッダー値が、以下のように追加されます。

[SSL Settings(SSLの設定)]セクションでは、プロキシー・サーバーのSSL構成を制御します。これによって、サーバー全体のレベルでSSLを物理的に使用可能にする方法を決定します。ただし、この設定が機能するには、鍵リング・データベースを作成してIBM Key Managementツールを取り込む必要があります(詳細については、Edge Serverの資料を参照してください)。

[Cache Settings(キャッシュの設定)]セクションでは、プロキシー・サーバーのキャッシングの動作を制御します。プロキシー・サーバーそのものは、パフォーマンスを向上させるためにコンテンツをローカルにキャッシングすることができます。これは大半のリバース・プロキシー構成では非常に重要です。静的コンテンツのキャッシングによって、Dominoサーバーにかかる負荷全体を減らすことができます。キャッシングされる主なエレメントは、イメージ、Javaクラス・ファイル、およびイメージ・リソースです。プロキシー・サーバーには、コンテンツのキャッシュ先にできる2つの場所があります。その1つはシステム・メモリー内で、[Cache memory(キャッシュ・メモリー)]フィールドで指定した量が最大になります。メモリーは高速化キャッシング・デバイスであり、この値はプロキシー・サーバーをホスティングするハードウェアに応じて最大化する必要があります。以下の画面で示す値16392KBはデフォルト値です。もう1つのキャッシュ場所は、ハード・ディスクの専用パーティションです。このキャッシング・パーティションの場所は、物理的ハードウェア構成によって決定されます。この例では使用可能にしていません。この機能を使用可能にするにはhtcformatユーティリティーの使用が必要で、そのステップはEdge Serverの資料に概説されています。

[Cache Filters(キャッシュ・フィルター)]セクションでは、プロキシー・サーバーに、リバース・プロキシーによって検索されたコンテンツのキャッシングを許可します。ホスティングされるそれぞれのサイトは、[Cache Query Response filtering by URL(URLによるキャッシュ照会応答のフィルター操作)]フィールド内で必ず定義します。URLの形式は*//internal.host.name/*です。これはほぼすべてのリバース・プロキシー要求から着信するワイルドカード応答を表します。プロキシー・サーバーのキャッシング機能は、HTTPヘッダー内に含まれている有効期限情報によって引き続き制約を受けます。これによって動的コンテンツは、必要ない場合はキャッシングされません。

以下の画面は、[Caching Filters(キャッシュ・フィルター)]フォームの続きです。

[Last Modified Factor(最終変更要因)]セクションでは、Edgeサーバーにローカルにキャッシングされる明示的なDomino設計エレメントの有効期限を、さらに詳細に制御することができます。最初に構成される2つの主な項目は、?OpenImageResourceおよび?OpenElement&FieldElemFormat=gif URL要求です。これらはイメージを表しますが、その性質からプロキシー・サーバーはデフォルトではそれらをイメージとしてみなしません(それらは単なる標準HTMLより長いデータとしてキャッシングする必要があります)。

[Basic Settings(基本設定)]セクションでは、サーバーのホスト名と、それがリッスンするIPアドレスを制御します。デフォルトのポート番号は、サーバーがSSLのみをサポートするようにセットアップされている場合は無効です(エクストラネット・ベースのメール・アプリケーションの場合にはこのようにセットアップされることがあります)。[Bind(バインド)]オプションは、どのIPアドレスがマシン上で使用されるのかを制御することに注意してください。たいていの場合、これはすべてのローカルIPアドレスにバインドされます。このセクションは、接続元クライアントのDNSルックアップも制御します。このオプションで、Edgeサーバーは各着信クライアントのIPアドレスをホスト名で解決するので、結果としてサーバーの処理オーバーヘッドの原因となります。これを実行するセキュリティー上またはロギング上の理由がない限り、このオプションは一般にはオフにしておく必要があります。

[Document Protection(文書保護)]セクションでは、Edgeサーバーによって処理されるコンテンツに特別アクセス制御を設定することを許可します。たとえば、デフォルトの設定では、コンテンツに対するアクセス制御セクションは/admin-bin/*サブディレクトリー下に作成されます。このセクションには重要な要素が2つあります。その1つとして、すべてのURL要求テンプレートは、Edgeのローカル・コンテンツとプロキシー経由送信されたコンテンツの両方に有効です。これによって、たとえばDominoサーバー上の/MyStuff/*フォルダーなどに、追加の制限を設定することができます。これらの制限によって、myprotstuffと呼ばれるユーザーだけが、固定DSLアドレスに対応する外部アドレスx.x.x.xからのコンテンツにアクセス可能にすることができます。Edgeサーバーは、アクセスを認可する前に名前とパスワードを要求します。証明書は、Edgeサーバー上のローカル・パスワード保管場所や、またはたとえばLDAPデータ・ソースなどから送信されます。次いでEdgeサーバーによる検証の後に、ユーザーは処理のために許可Dominoサーバーにルーティングされます。

[HTTP Methods(HTTPメソッド)]セクションでは、Edgeサーバーによってサービスされる要求タイプを定義することができます。デフォルトではいくつかがオンになっています。ただしDominoで機能することが必要なのは、GET、HEAD、およびPOSTだけです。他は不要であり、セキュリティー上のリスクを発生させる可能性があります。

[Request Routing(要求ルーティング)]セクションこそすべての魔法が起きるところです。これらのルール・セットは、プロキシー・サーバーが認識するすべての着信要求の運命を制御します。したがって、この構成はサーバーの正常な運用とパフォーマンスには不可欠です。Edgeサーバーは、各着信要求をこのルール・リストから索引順に実行し、要求テンプレートとIPアドレス(定義されている場合)の突き合わせを実行します。この突き合わせは、大文字小文字を区別します(これはUNIX以外のDominoサイトで留意すべき点です)。つまり、Edgeサーバーは要求テンプレートの/Mailと/mailとは別のものとして扱います。要求がルールと一致すると、指定されたアクションが実行されます。これらのアクションで、コンテンツをドロップしたり、直接にローカル・ファイルのEdgeサーバー・リソースに渡したり、CGIアプリケーションの場合は実行したり、別の場所にプロキシー経由送信したりすることができます。

「pass everything」リバース・プロキシー・インプリメンテーションのプロキシー・ルールは次のものと似ています。この場合、このルールは、要求が1~22のルール・セットのいずれとも一致しない場合に、その要求をhttp://iNotes.forMyMailServer.Webにプロキシー経由送信することを規定しています。

IndexActionRequest TemplateReplacement file path
23Proxy/*http://iNotes.forMyMailServer.Web/*

ただしこのセットアップは、HTTP経由でアクセス可能なDominoサーバー上のすべてのリソースへの直接アクセスを許可するので危険です。以下の表には、Edgeサーバーから公開されるDominoリソースのさらに厳密なセットを記載しています。以下のルール・セットでは、/mail*サブディレクトリー内のコンテンツだけが処理されます。このルールは、サイトに複数のメール・サブディレクトリー(たとえば/mail[1~3])がある場合に、それらが考慮されるように定義されています。アクセスをメール・データベースのサブセットだけに制限したい場合は、それらを/pubmail/*などの特別なフォルダーに移動させます。それぞれのユーザーのメール・データベースに対してルールを作成するのは、実際的ではなく賢明なことでもありません。他のルールによって、iNotes Web Accessの経験をエンド・ユーザーに提供するために必要なサポート・コンテンツにアクセスできます。

IndexActionRequest TemplateReplacement file path
1Proxy/mail*http:// xxx.xxx.xxx.xxx/mail*
2Proxy/iNotes/*http:// xxx.xxx.xxx.xxx /iNotes/*
3Proxy/inotes5/*http:// xxx.xxx.xxx.xxx /inotes5/*
4Proxy/icons/*http:// xxx.xxx.xxx.xxx /icons/*
5Proxy/domjava/*http:// xxx.xxx.xxx.xxx /domjava/*
6Proxy/names.nsfhttp:// xxx.xxx.xxx.xxx /names.nsf

考慮すべき1つの重要なルールは、認証に使用される/names.nsfルールです。これによってインターネットからDomino Directoryにアクセスできますが、デフォルト・フォルダー・リスト以外のコンテンツは利用できません。これは、DominoによるURLの作成方法の結果です。セッション認証を持つユーザーがDominoにログインすると、デフォルトのログイン画面は要求を/names.nsf?Loginに送信します。Edgeサーバーはこの要求を突き合わせ、それをDominoに渡します。たとえば、ユーザーが/names.nsf/Groups?OpenViewまたは/names.nsf/85255ed5006cafef852556d4006ca21c?OpenViewでGroupsビューを開こうとすると、DominoおよびEdgeサーバーの要求は、ルールに一致しないために失敗します。ユーザーは、アクセスが禁止されていることを伝えるエラー・メッセージ403を受け取ります。

前の方で論じたとおり、これらの要求テンプレートはIPアドレスで制御することもできます。Edgeサーバーが複数のIPアドレス(ホスト名)をサポートするようにセットアップされている場合、各IPアドレスは、[Server IP Address(サーバーIPアドレス)]または[Host Name(ホスト名)]列にデータを取り込む別個のルールを持つことができます。値がブランクの場合、ルールはIPアドレスに関係なくすべての要求に適用されます。注意を1つ:ホスト名を使用する場合、IPアドレス(たとえばhttp://xxx.xxx.xxx.xxx/URL)を使って作成された要求は、ルールに一致しないため失敗します。これは部分ホストにも一致しないので、プロキシーのホスト名はproxy.formymailserver.webとは等しくありません。 Edgeサーバー管理インターフェースの残りのセクションで、追加のシステム構成を実行できます。ただし、機能サーバーに必要とされるすべての画面はここまでのセクションで取り上げています。

ibmproxy.conf

他にもEdgeサーバーの操作に重要なオプションがあり、それらはWeb管理インターフェースからは入力できません。これらはibmproxy.confから直接設定する必要があるので、お気に入りのテキスト・エディターを立ち上げて準備してください。良いことにこれらの例は既に構成ファイルに定義済みであり、単にコメント化されているだけです。 最初はLogVirtualHostName項目です。これはEdgeシステム上で仮想サーバーを実行している場合に重要です。これは、それぞれのログ・エントリーに要求先のホストが含まれるようにログ・ファイルを変更します。この設定を組み込んでいないと、どのIPをエンド・ユーザーが要求したかを簡単に知る方法はありません。これを以下のようにbeginningに設定します(他の選択可能なオプションはマージされてなくなります)。

LogVirtualHostName beginning

SignificantUrlTerminator設定は、Edgeサーバーにこの値を基本URLの一部として扱うように指示します。言い換えれば、大半のDomino URLには「?」が含まれているので、それらは動的コンテンツを表す照会URLとして扱われ、そのためEdgeサーバー上でローカルにキャッシングするには不適です。このディレクティブは、Edgeサーバーに、URLのこのポイントの後に起動して動的コンテンツを検出するように指示します。Dominoは、標準の静的GIFファイルとみなされるものを表すために?OpenImageResourceおよび?OpenElementを使用するので、それらをEdgeサーバーではそのようなものとして扱うことができるようになります。

SignificantUrlTerminator ?OpenImageResource
SignificantUrlTerminator ?OpenElement
SignificantUrlTerminator /?OpenImageResource
SignificantUrlTerminator /?OpenElement

ReversePassディレクティブはDominoからの標準リダイレクト302応答を代行受信し、それらを新規ロケーションに再書き込みします。この新規ロケーションは、エンド・ユーザーが更新リダイレクト・ページを要求した場合に引き続き有効であるために、以下のような有効な外部URL名とする必要があります。

ReversePass http://xxx.xxx.xxx.xxx/*
http://proxy.formymailserver.web/*

SendRevProxyNameディレクティブも、リバース・プロキシー・サーバーのホスト名をDominoに渡すので非常に重要です。これによってDominoからの応答はEdgeサーバーのソースであり、エンド・クライアントのソースではないことが保証されます。これによって

SendRevProxyName yes

SSLOnlyディレクティブは、EdgeサーバーにSSLトラフィックだけを処理するように強制します。これは、以下のようにしてサイトに他の外部プロトコルを許可しない場合に必要です。

SSLOnly ON

SSLCertificateディレクティブは、仮想サーバー・サイトに必要です。ユーザーがEdgeサーバーからセキュア・コンテンツを要求した場合、EdgeサーバーからSSL証明書が戻されます。この証明書は、ユーザーが要求しているものと必ず一致している必要があります。そうでない場合、ユーザーはエラー・メッセージを受け取ります。Edgeサーバーは複数のSSL証明書を処理でき、要求されたIPアドレスに基づいてそれらの証明書を配布します。ユーザーがproxy.formymailserver.webを要求すると、Edgeサーバーは正しい証明書を送信します。proxy1.formymailserver.webを要求すると、別の証明書を受け取ります。このもう1つの重要な点は、SSLがEdgeサーバー上の仮想サーバーに対して使用されると、それぞれの仮想サーバーはその固有のIPアドレスを要求することです。サーバーがホスト名を見て、そのIPアドレスに適したアクションを決める、名前付き仮想サーバーという概念があります。このタイプのセットアップは、SSLの世界では正しく動作しませんが、以下のような非SSLの使用では完全に有効です。

SSLCertificate xxx.xxx.xxx.xxx proxy.formymailserver.web

Edgeサーバー・アプリケーションのefixまたはパッチから入手できる追加のディレクティブがあります。efix 9以降に入手可能になったさらに興味深い機能は、HTMLコンテンツをオンザフライで再書き込みする以下の機能です。

----Junction URL Rewrite Plug-in ----

ServerInit c:\PROGRA-1\IBM\edge\cp\lib\plugins\mod_rewrite\
mod_rw.dll:modrw_init

Transmogrifier
c:\PROGRA-1\IBM\edge\cp\lib\plugins\mod_rewrite\
mod_rw.dll:modrw_open:modrw_write:modrw_close:modrw_error

JunctionRewrite on

これによって、単一プロキシー・サーバーURLの背後にあるDominoサーバーを仮想化することができます。たとえば、URL http://proxy.formymailserver.web/server1は1つのDominoサーバーを指し、http://proxy.formymailserver.web/server2はもう1つのDominoサーバーを指します。この再書き込みプラグインは、プロキシー・ルールを直接処理して、情報の変更方法を決定します。ただしこれはHTMLコンテンツを更新できるだけであることに留意してください。/mail/jdoe.nsfへの参照は/server1/mail/jdoe.nsfに変更することができます。ルール・セットの例を以下の表に示します。

IndexActionRequest TemplateReplacement file path
23Proxy/server/*http://iNotes1.forMyMailServer.Web/*
24Proxy/server/*http://iNotes2.forMyMailServer.Web/*

シングル・サインオン

業界がさらにオンデマンドで情報を入手可能とする方向に進むにつれ、重要性を増してきたトピックはSSO(シングル・サインオン)です。DominoではSSOの単一サーバーおよびマルチ・サーバーの両方のインプリメンテーションはcookieによって操作されるので、SSOをサポートするためにEdgeサーバーに追加の変更を加える必要がないというのは優れた点です。1つの重要な要素として、関連ドメイン(たとえばformymailserver.web)は、内部と外部のシステム全体で同じままにしておく必要があります。

まとめ

Dominoを使用したリバース・プロキシー・ソリューションのインプリメンテーションは、興味深くもあり、(あえて言ってしまえば)おもしろい演習にもなります。注意深く計画し、この記事で提供した情報を使って作業すれば、インプリメンテーションはかなり簡単になるはずです。プロキシー・テクノロジーによって、かつて可能であったよりもさらに安全にメッセージング・リソースにアクセスでき、これは次のスタッフ会議であなたが発言することにも役立つでしょう。そこで次にニューヨーク、ダラス、またはロンドンの路上でiNotes Web Accessの電子メールにアクセスするときは、堅固で安全なリバース・プロキシー・ソリューションを持つ企業コンピューティング環境に保護されているという確信を持ってそうすることができるでしょう。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Lotus
ArticleID=341691
ArticleTitle=LDD Today: iNotes Web AccessをWebSphere Edgeリバース・プロキシー・サーバーを活用して使った構成
publish-date=03032003