test

Sun Java System Communications Services 6 2005Q4 配備計画ガイド

第 4 章 ネットワークインフラストラクチャーに対するニーズの決定

ネットワークインフラストラクチャーはシステムの根本的な基盤です。ネットワークインフラストラクチャーが形成する各サービスによってネットワークの動作構造が作り出されます。Communications Services の配備で、プロジェクトの目標を基準にネットワークインフラストラクチャーを決定することで、拡大縮小や拡張が可能なアーキテクチャーを確保できます。

この章には、次の節があります。

既存ネットワークの理解

既存のネットワークインフラストラクチャーを理解して、それが配備の目標をどの程度満たすものであるかを判断する必要があります。既存のインフラストラクチャーを調査することで、既存のネットワークコンポーネントをアップグレードしたり、新規のコンポーネントを購入したりする必要があるかどうかがわかります。次の領域を調査して、既存のネットワークの完全な全体像を構築する必要があります。

  1. ケーブルの長さ、グレードなどの物理的な通信リンク

  2. アナログ、ISDN、VPN、T3 のような通信リンクと、サイト間で利用可能な帯域幅と待ち時間

  3. 次のサーバーの基本情報

    • ホスト名

    • IP アドレス

    • ドメインメンバー用のドメインネームシステム (DNS) サーバー

  4. 次に挙げるデバイスのネットワーク上の場所

    • ハブ

    • スイッチ

    • モデム

    • ルーターとブリッジ

    • プロキシサーバー

  5. モバイルユーザーを含むそれぞれのサイトのユーザー数

この調査結果一覧を完成させた後で、プロジェクトの目標に照らしてその情報を再検討し、配備を成功させるにはどのような変更が必要であるかを判断します。

ネットワークインフラストラクチャーの理解

次の代表的なネットワークインフラストラクチャーコンポーネントは、配備の成否に直接影響します。

ルーターとスイッチ

ルーターはインフラストラクチャーのネットワークを接続して、システム間の通信を可能にします。配備後のルーターの能力には余力を持たせて、プロジェクトの拡大とそれに伴う処理の増加に備える必要があります。

スイッチは、血管のようにネットワーク内のシステムを接続します。

フル稼働状態のルーターやスイッチはボトルネックとなる可能性があり、クライアントが別のネットワーク上にあるサーバーにメッセージを送信するのにかなり長い時間がかかる結果となります。そのような場合には、先見性の欠如や、ルーターやスイッチをアップグレードする資金の欠乏から、そのコスト以上に個人の生産性が低下してしまうこともあります。

ファイアウォール

ファイアウォールは、ルーターとアプリケーションサーバーの間に位置し、アクセス制御を行います。ファイアウォールは本来、信頼されていないネットワーク (インターネット) から信頼済み (内部) ネットワークを保護するものです。現在ではより一般的に、外部ネットワークやインターネットなどの信頼されていないネットワークから、信頼済みまたは隔離された自己のネットワーク上のアプリケーションサーバーを保護する目的で使われています。

ルーターの設定を行うことで、ファイアウォールを通過するデータのスクリーニングを行い、ファイアウォール全体の機能が強化されます。ルーターの設定により、NFS や NIS のような好ましくないサービスをブロックし、パケットレベルのフィルタリングを使用して信頼されていないホストやネットワークからの通信をブロックできます。

さらに、インターネットまたは信頼されていないネットワークに開放されている環境に Sun サーバーをインストールするときに、アプリケーションをホストするのに必要な最小限の数まで、Solaris ソフトウェアのインストールパッケージを減らすことができます。サービス、ライブラリ、およびアプリケーションの数を最小化することにより、保守が必要なサブシステムの数が減少し、セキュリティーの向上につながります。SolarisTM Security Toolkit は、Solaris システムを最小化し、強化し、セキュリティー保護されたシステムにするための、柔軟性と拡張性に富んだメカニズムを提供します。

サイトのセキュリティーポリシーで、このような問題に対する対策を考慮する必要があります。

ロードバランサ

ロードバランサを使用して、Web サーバーまたはアプリケーションサーバー全体の負荷を分散するか、実行するタスクの種類に基づいて要求を分散します。さまざまな専用アプリケーションを異なるアプリケーションサーバーで使用しているような場合は、ユーザーが要求するアプリケーションの種類に応じてロードバランサを使用します。

データセンターが複数ある場合は、ロードバランサの地理的な分散も考慮する必要があります。地理的な負荷分散により、要求やサイトの能力、ユーザーとの距離に基づいて負荷の分散が行われます。1 つのセンターがダウンした場合は、地理的なロードバランサによりフェイルオーバー機能が提供されます。

Web ファーム上のロードバランサでは、サーバーの前とルータの後ろにロードバランサを配置して、トラフィックを適切なサーバーにルーティングします。ソフトウェア負荷分散ソリューションは、Web サーバーにインストールします。ソフトウェアによるソリューションでは、サーバーの 1 つが通常はトラフィックスケジューラとして機能します。

負荷分散ソリューションでは、受信したパケットのヘッダと内容を読み取ることができます。これにより、ユーザーや要求の種類を含むパケット内の情報の種類別に負荷分散を行うことができます。パケットヘッダを読み取る負荷分散ソリューションにより、権限のあるユーザーを識別し、特定のタスクを処理するサーバーに要求を送ることができます。

サービスを提供しているすべてのサーバーとの間で、ロードバランサが動的な通信をどの程度行なっているかを調査する必要があります。スケジューラはそれぞれのサーバーに ping を実行するか「ライブ」なエージェントをサーバー上で作成してロードデータを確認していますか。ロードバランサが TCP パケットをどのように解析しているかも調査する必要があります。そして、ロードバランサがパケットを処理するスピードにも注目します。ロードバランサの中には、他のロードバランサより効率性の高いものもあります。ロードバランサの効率性は、通常スループットで測定されます。

ストレージエリアネットワーク (SAN)

配備を成功に導くためには、ストレージシステムのデータ要件を理解することが必要です。SAN のシステムでは、ストレージをそれが使用されているサーバーから独立した形で配備することが多くなってきています。SAN のシステムを配備することで、ストレージデバイスを再配置することなくマシンを交換することができるため、機能しなくなったサーバーの回復に要する時間を短縮することができます。

次の質問を参考にして、SAN の導入により配備するストレージの要件が適切に達成されているかどうかを評価します。

DNS (Domain Name System、ドメインネームシステム)

DNS クエリの使用頻度が高いサーバーにはローカルキャッシング DNS サーバーを用意して、ルックアップによる待ち時間を短縮し、ネットワークトラフィックを減らします。

要件を決定する際には、メールストア、メールリレーイン、メールリレーアウトなどの機能別にホスト名を割り当てるようにします。すべてのホスト名が現在 1 台のマシン上でホストされている場合でも、このポリシーを考慮する必要があります。サービスをそのように構成しておくと、そのサービスを別のハードウェアに移すときに、変更に伴う影響をかなり小さくすることができます。

ネットワークインフラストラクチャーレイアウトの計画

インフラストラクチャーのトポロジを考えるときに、次の視点から検討を行う必要があります。

非武装地帯 (DMZ)

今日、ほとんどの企業ネットワークで DMZ が取り入れられています。DMZ により、企業ネットワークがインターネットから分離されます。DMZ は厳重に保護された領域で、Web サーバーのようなインターネットサービスと機能を提供するサーバーが配置されます。これらのマシンは、直面する攻撃に耐えられるように強化されています。そのような攻撃によりセキュリティーが破られた場合のエクスポージャーを制限するために、通常これらのサーバーには内部ネットワークに関する情報が含まれていません。たとえば、ネームサーバー機能には、インターネットに接続されたサーバーとルーターしか含まれていません。

さらに進んだ DMZ では、ファイアウォールのセキュリティーと機能がより強固になったことから、DMZ がファイアウォールの後ろのセグメントに移動されています。しかし、DMZ は依然として内部ネットワークからは分離されています。Web サーバー、FTP サーバー、メールサーバー、および外部 DNS をホストするすべてのマシンは、必ず DMZ セグメントに配置する必要があります。

単純なネットワーク設計では、インターネットサービス、VPN アクセス、およびリモートアクセスのための個別の DMZ セグメントだけを定義します。ただし、VPN アクセスとリモートアクセスのトラフィックにはセキュリティー上の問題が存在します。したがって、これらのタイプのトラフィックについては、それ以外のネットワークから分離された適切な接続が必要となります。

DMZ セグメントを提供するファイアウォールは、対応するサービスポートと DMZ 内でそのサービスを提供しているホストに宛てられたインバウンドパケットだけを許可するものでなければなりません。また、DNS やメールのようなサービスを提供するマシンは、そのサービスのためにインターネットにアクセスする必要がありますが、これらのマシンに対するインターネットへのアウトバウンドトラフィックを制限します。要求された接続のタイプにより、DMZ をインバウンド専用とアウトバウンド専用に分けることも 1 つの方法です。しかし、サービス拒否攻撃により DNS や電子メールサービスが妨害される可能性を考えると、インバウンドとアウトバウンド専用のサーバーに分けてこれらのサービスを提供することには検討の余地があります。電子メールベースのトロイの馬やワームにより、アウトバウンドメールサーバーが制御不能に陥り、オーバーランが発生した場合でも、インバウンドメールは受け取ることができます。DNS サーバーと同じアプローチを適用します。

イントラネット

DMZ は、インターネットへのサービスを提供するホストのためのネットワークセグメントを提供します。この設計により、内部ホストは外部からの攻撃にさらされるホストとは別のセグメントに置かれるため、保護されます。内部的には、内部ユーザーに限定された同様のサービス (Web、ファイルサーバー、内部 DNS など) を提供しています。インターネットサービスをセグメント化するのと同様に、内部サービスもセグメント化します。このような方法によるサービスの分離により、ルーターのフィルタリングでより緊密な制御を行うことができます。

インターネットに向けたサービスを DMZ で分離してセキュリティーを確保したように、私設内部サービスも独自の内部 DMZ 内に配置するべきです。また、ネットワークのサービスとサイズによっては複数の DMZ が有用なように、複数のイントラネットも同様に有用です。

セグメントを提供するファイアウォールの規則は、DMZ のファイアウォールに使用されるものと同様に構成する必要があります。インバウンドトラフィックは、内部メールサーバーに渡されるインバウンドメールのような DMZ からの情報をリレーするマシンと、内部ネットワーク内にあるマシンだけから送られてくるものでなければなりません。

内部ネットワーク

残りのセグメントが内部ネットワークセグメントを構成します。これらのセグメントには、ユーザーのマシンや部署で使用するワークステーションが含まれます。これらのマシンは、イントラネット内のホストからの情報を要求します。開発、ラボ、およびテストネットワークセグメントもこれに含まれます。各内部ネットワークセグメント間のファイアウォールを使用してトラフィックのフィルタリングを行い、部門間のセキュリティーをさらに強化します。これらのセグメント上で使用される内部ネットワークトラフィックとサービスのタイプを識別して、内部ファイアウォールが有効であるかどうかを判断します。

内部ネットワーク上のマシンは、インターネット上のマシンと直接通信してはいけません。これらのマシンでは、DMZ 内のマシンとの直接通信を避けた方が賢明です。これらのマシンが要求するサービスがイントラネット上のホストにあれば理想的です。一方で、イントラネット上のホストは DMZ 内のホストと通信を行なって、電子メールのアウトバウンドや DNS などのサービスを完了することができます。このような間接的な通信であれば問題はありません。

プロキシ

DMZ 内には、インターネット上のマシンと直接通信を行うマシンだけを配置する必要があります。ユーザーがインターネットへのアクセスを要求した場合は、以前のトポロジに基づいた問題が発生します。このような場合は、プロキシが有効です。内部ネットワークセグメントに、またはさらに望ましいのはイントラネットセグメントにプロキシを配置します。インターネットにアクセスする必要のあるマシンは、要求をプロキシに渡し、プロキシがそのマシンに代わって要求を実行します。インターネットへのこのリレーにより、マシンが直面する可能性のある危険を防ぐことができます。

プロキシはインターネット上のマシンと直接通信を行うため、DMZ 内に配置する必要があります。ただしこれは、内部のマシンが直接 DMZ 内のマシンと通信を行うのを防ぐという意図と矛盾します。この通信を間接的なものにするために、二重のプロキシシステムを使用します。イントラネット内の二次プロキシは、内部マシンの接続要求を DMZ 内のプロキシに渡し、そこでインターネットへの直接接続が行われます。

ファイアウォールの設定

通常のパケットフィルタリング機能のほかに、ほとんどのファイアウォールには IP スプーフィングを防ぐ機能もあります。可能な限り IP スプーフィング保護機能を使用してください。

たとえば、インターネットから内部ネットワークへのエントリポイントが 1 つだけで、インターネットからのパケットに内部マシンの発信元アドレスがある場合、それはおそらくスプーフされたものです。ネットワークのトポロジに基づいて、内部マシンの発信元アドレスを持つパケットは、インターネットからではなく内部ネットワークから発信されたものでなければなりません。IP スプーフィングを防ぐことでこのような可能性はほとんどなくなり、IP アドレスベースの認証をすり抜けることも困難になるため、他のファイアウォールの規則を減らすことができます。内部ファイアウォールにも同様の IP スプーフィング対策を行います。

モバイルユーザー

リモートユーザーまたはモバイルユーザーに対しては、どのようにアクセス手段を提供するかを検討する必要があります。そのようなユーザーがアクセスできない手段があるでしょうか。どのようなタイプのセキュリティーポリシーを必要としていますか。SSL による認証が必要ですか。また、モバイルユーザーの数にほとんど変化がないか、今後増加するのかについても検討します。