|
| |
| Sun Java System Messaging Server 6 2004Q2 配備計画ガイド | |
第 4 章
ネットワークインフラストラクチャに対するニーズの決定ネットワークインフラストラクチャは、システム構成の基盤となるもので、 ネットワークの動作を生み出すサービスを構成します。Messaging Server の配備で、プロジェクトの目標を基準にネットワークインフラストラクチャを決定することで、基準化され、拡張可能なアーキテクチャを確保できます。
この章には、以下の節があります。
既存ネットワークの理解既存のネットワークインフラストラクチャを理解して、それが配備の目標をどの程度満たすものであるかを判断する必要があります。既存のインフラストラクチャを調査することで、既存のネットワークコンポーネントをアップグレードしたり、新規のコンポーネントを購入したりする必要があるかどうかがわかります。以下の領域を調査して、既存のネットワークの完全な全体像を構築する必要があります。
この調査結果一覧を完成させた後で、プロジェクトの目標に照らしてその情報を再検討し、配備を成功させるにはどのような変更が必要であるかを判断します。
ネットワークインフラストラクチャの理解以下の共通ネットワークインフラストラクチャコンポーネントは、配備の成否に直接影響します。
ルーターとスイッチ
ルーターはインフラストラクチャのネットワークを接続して、システム間の通信を可能にします。配備後のルーターの能力には余力を持たせて、プロジェクトの拡大とそれに伴う処理の増加に備える必要があります。
スイッチは、血管のようにネットワーク内のシステムを接続します。
フル稼働状態のルーターやスイッチはボトルネックとなる可能性があり、クライアントが別のネットワーク上にあるサーバーにメッセージを送信するのにかなりの時間がかかる結果となります。そのような場合には、先見性の欠如や、ルーターやスイッチをアップグレードする資金の欠乏から、そのコスト以上に個人の生産性が低下してしまうこともあります。
ファイアウォール
ファイアウォールは、ルーターとアプリケーションサーバーの間に位置し、アクセス制御を行います。ファイアウォールは本来、信頼されていないネットワーク (インターネット) から信頼済み (内部) ネットワークを保護するものです。現在ではより一般的に、外部ネットワークやインターネットなどの信頼されていないネットワークから、信頼済みまたは隔離された自己のネットワーク上のアプリケーションサーバーを保護する目的で使われています。
ルーターの設定を行うことで、ファイアウォールを通過するデータのスクリーニングを行い、ファイアウォール全体の機能が強化されます。ルーターの設定により、NFS や NIS のような好ましくないサービスをブロックし、パケットレベルのフィルタリングを使用して信頼されていないホストやネットワークからの通信をブロックできます。
さらに、インターネットまたは信頼されていないネットワークに開放されている環境に Sun サーバーをインストールするときに、アプリケーションをホストするのに必要な最小限の数まで、Solaris のインストールパッケージを減らすことができます。サービス、ライブラリ、およびアプリケーションの数を最小化することにより、保守が必要なサブシステムの数が減少し、セキュリティの向上につながります。SolarisTM Security Toolkit は、Solaris Operating Environment を最小化し、強化し、セキュアなシステムにするための、柔軟性と拡張性に富んだメカニズムを提供します。
サイトのセキュリティポリシーで、以下の問題に対する対策を考慮する必要があります。
ロードバランサ
ロードバランサを使用して、Web サーバーまたはアプリケーションサーバー全体の負荷を分散し、実行するタスクの種類に基づいて要求を分散します。さまざまな専用アプリケーションを異なるアプリケーションサーバーで使用しているような場合は、ユーザーが要求するアプリケーションの種類に応じてロードバランサを使用します。
データセンターが複数ある場合は、ロードバランサの地理的な分散も考慮する必要があります。地理的なロードバランシングにより、要求やサイトの能力、ユーザーとの距離に基づいて負荷の分散が行われます。1 つのセンターがダウンした場合は、地理的なロードバランサによりフェイルオーバー機能が提供されます。
Web ファーム上のロードバランサでは、サーバーの前とルータの後ろにロードバランサを配置して、トラフィックを適切なサーバーにルーティングします。ソフトウェアロードバランシングソリューションは、Web サーバーにインストールします。ソフトウェアによるソリューションでは、サーバーの 1 つが通常はトラフィックスケジューラとして機能します。
ロードバランシングソリューションでは、受信したパケットのヘッダと内容を読み取ることができます。これにより、ユーザーや要求の種類を含むパケット内の情報の種類別にロードバランスを行うことができます。パケットヘッダを読み取るロードバランシングソリューションにより、権限のあるユーザーを識別し、特定のタスクを処理するサーバーに要求を送ることができます。
サービスを提供しているすべてのサーバーとの間で、ロードバランサが動的な通信をどの程度行っているかを調査する必要があります。スケジューラはそれぞれのサーバーに ping を実行するか「ライブ」なエージェントをサーバー上で作成してロードデータを確認していますか。ロードバランサが TCP パケットをどのように解析しているかも調査する必要があります。そして、ロードバランサがパケットを処理するスピードにも注目します。ロードバランサの中には、他のロードバランサより効率性の高いものもあります。ロードバランサの効率性は、通常スループットで測定されます。
ストレージエリアネットワーク (SAN)
配備を成功に導くためには、ストレージシステムのデータ要件を理解することが必要です。SAN のシステムでは、ストレージをそれが使用されているサーバーから独立した形で配備されることが多くなってきています。SAN のシステムを配備することで、ストレージデバイスを再配置することなくマシンを交換することができるため、機能しなくなったサーバーの回復に要する時間を短縮することができます。
以下の質問を参考にして、SAN の導入により配備するストレージの要件が適切に達成されているかどうかを評価します。
DNS
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 による認証が必要ですか。また、モバイルユーザーの数にほとんど変化がないか、今後増加するのかについても検討します。