|
| |
| Sun Java System Calendar Server 6 2004Q2 配備計画ガイド | |
第 3 章
ネットワークインフラストラクチャの必要性の決定ネットワークインフラストラクチャはシステムの根本的な基盤です。ネットワークインフラストラクチャが形成する各サービスによってネットワークの動作構造が作り出されます。Calendar Server の配備では、プロジェクト目標からネットワークインフラストラクチャを決定すると、確実に拡張および成長が可能なアーキテクチャを備えることができます。
この章で説明する内容は次のとおりです。
既存のネットワークについて既存のネットワークインフラストラクチャを理解して、それが配備目標のニーズに十分対応可能かを判断する必要があります。既存のインフラストラクチャを調査して、既存のネットワークコンポーネントをアップグレードしたり、新しいネットワークコンポーネントを購入したりする必要があるかどうかを確認します。次の分野をカバーすることによって既存のネットワークの完全なマップを作成する必要があります。
この一覧表を完成させた後、プロジェクト目標に関連した情報を検討し、配備を正常に実現するために必要とされる変更を判断する必要があります。
ネットワークインフラストラクチャコンポーネントについて次の一般的なネットワークインフラストラクチャコンポーネントは配備の成功に直接影響します。
ルーターとスイッチ
ルーターはインフラストラクチャのネットワーク同士を接続し、システム間の通信ができるようにします。プロジェクトで計画された拡張や用途に対応するため、配備後のルーターに予備の容量を確保する必要があります。
同様に、スイッチはネットワーク内のシステム同士を接続します。
ルーターやスイッチがフル稼働しているとボトルネックの増大をまねく傾向があり、その結果、クライアントが異なるネットワークのサーバーにメッセージを送信するのにかなり多くの時間を費やすことになります。このような場合、ルーターまたはスイッチをアップグレードする見通しや費用がないと、そのコストに比較にならないほど従業員の生産性に影響する可能性があります。
ファイアウォール
ファイアウォールは、ルーターとアプリケーションサーバー間に配置されアクセス制御を行います。元々ファイアウォールは、信頼できないネットワーク (インターネット) から信頼ネットワーク (使用しているもの) を保護するために使用されていました。最近では、信頼できないネットワーク (ネットワークおよびインターネット) から自分の (信頼される、分離した) ネットワークのアプリケーションサーバーを保護するために広く使われるようになっています。
ルーターを設定すると、ファイアウォールに入ってくるデータを選別することで全体的なファイアウォールの能力が増強されます。ルーターを設定すると、場合によっては好ましくない、NFS、NIS などのサービスをブロックし、パケットレベルのフィルタリングを使用して信頼できないホストやネットワークからのトラフィックをブロックすることができます。
さらに、インターネットや信頼できないネットワークに公開している環境で Sun サーバーをインストールする場合、Solaris のインストールは、ホストするアプリケーションをサポートするのに必要な最小限のパッケージ数まで減らしてください。サービス、ライブラリ、およびアプリケーションを最小限にすることができれば、保守を必要とするサブシステムの数を少なくできるので、セキュリティの強化に役立ちます。SolarisTM Security Toolkit は、Solaris オペレーティング環境のシステムの最小化、堅固化、および安全性の向上を図るための柔軟で拡張可能なメカニズムを提供します。
サイトのセキュリティポリシーでは、このような課題に対して指針を与える必要があります。
ロードバランサ
ロードバランサを使用して、ロード全体を Web サーバーやアプリケーションサーバーに分散させたり、実行するタスクの種類に応じて要求を分散させてください。たとえば、さまざまな専用アプリケーションがあり、そのために異なるアプリケーションサーバーを持っている場合、ユーザーが要求するアプリケーションの種類に応じてロードバランサを使用することができます。
複数のデータセンターが存在する場合は、地理的なロードバランスを考慮する必要があります。地理的なロードバランスでは、要求、サイトの容量、およびユーザーにもっとも近いの場所などに応じて、ロードを分散させます。1 つのセンターが停止した場合、地理的なロードバランサによってフェイルオーバー機能が働きます。
Web ファーム上のロードバランサの場合、ハードウェアロードバランサをサーバーの前およびルーターの後ろに配置し、ルーティングされたトラフィックが適切なサーバーに誘導されるようにします。ソフトウェアのロードバランスソリューションは Web サーバー自体に常駐します。ソフトウェアソリューションを使用すると、通常、サーバーの 1 つがトラフィックスケジューラとして機能します。
ロードバランスソリューションは、入力パケットのヘッダーと内容を読み取ることができます。これにより、ユーザーや要求のタイプなど、パケット内の情報の種類に応じてロードバランスを行うことができます。パケットヘッダーを読み取るロードバランスソリューションによって、権限のあるユーザーを識別し、所定のタスクを処理するサーバーに要求を送信することができます。
要求に応じるすべてのサーバーとロードバランサが動的にどのように通信するかを調査する必要があります。スケジューラは、ロードデータを確認するために、それぞれのサーバーを ping しますか。あるいは、サーバーに常駐する「ライブ」エージェントを作成しますか。また、ロードバランサがどのように TCP パケットをパースするのかも調べる必要があります。どのくらい短時間でロードバランサがパケットの処理をできるかに注目してください。ロードバランサによっては他より効率的なものとなります。ロードバランスの効率は、通常、スループットで計測されます。
ストレージエリアネットワーク (SAN)
ストレージシステムのデータ要件を理解することは、配備を成功させるために必要です。ストレージに関連して使用されるサーバーにストレージが依存しないように、ますます SAN が配備されています。SAN の配備によって、ストレージドライブの場所を変更することなくマシンを置き換えることができるので、機能しないサーバーからの復元時間を短くすることができます。
次の質問を使用して、配備ストレージ要件が SAN を通じて最適に処理されているかを評価してください。
DNS
DNS 照会の使用率が非常に高いサーバーでは、ローカル DNS キャッシュサーバーを装備して、検索応答時間およびネットワークトラフィックを低減させる必要があります。
要件を決定する場合、メールストア、メールリレーイン、メールリレーアウトなどの機能のホスト名の割り当てを考慮してください。すべてのホスト名が現在 1 つのマシン上でホストされている場合でも、このポリシーを考慮する必要があります。このような方法で設定されるサービスを使用すると、代替ハードウェアへのサービスの再配置による変更の影響がかなり少なくなります。
ネットワークインフラストラクチャレイアウトの計画インフラストラクチャトポロジを導き出す際、次の点について考慮しておく必要があります。
非武装地帯 (DMZ)
今日では、ほとんどの企業のネットワークに DMZ が設定されています。DMZ はインターネットから企業のネットワークを分離します。DMZ は安全性が強化された領域であり、インターネットのサービスや設備を提供する、Web サーバーなどのサーバーをそこに配置します。これらのマシンは受ける可能性のある攻撃に耐えるよう強化されます。そのような攻撃によるセキュリティの侵害の場合にも被害を抑えるため、通常、これらのサーバーには内部ネットワークについての情報が含まれていません。たとえば、ネームサーバーの設備には、サーバーとインターネットへのルーターだけが含まれています。
DMZ の実装場所は、ファイアウォールのセキュリティと設備の堅固さが増すにつれ、徐々にファイアウォールの背後のセグメントに移動しています。しかし、DMZ はまだ内部ネットワークから分離された状態にあります。引き続き、Web サーバー、FTP サーバー、メールサーバー、および外部 DNS をホストするすべてのマシンを DMZ セグメントに配置する必要があります。
簡単なネットワーク設計では、インターネットサービス、VPN アクセス、およびリモートアクセス用に、別々の DMZ セグメントを設定するだけの場合もあります。しかし、VPN アクセスおよびリモートアクセスのトラフィックにはセキュリティの問題があります。これらのタイプの該当する接続をネットワークの他の部分から分離しておく必要があります。
DMZ の分離を可能にするファイアウォールによって、DMZ 内でサービスを提供している、対応するサービスポートおよびホスト宛てのインバウンドパケットだけが許容されます。さらに、インターネットに向けて開始されるアウトバウンドトラフィックは、たとえば DNS やメールなど、提供するサービスを実行するためにインターネットへのアクセスが必要なマシンに限定してください。接続要求の特定のタイプについて、インバウンドのみの DMZ と アウトバウンドのみの DMZ に分離することを考えることもできます。ただし、DNS や電子メールを中断させるサービス拒否攻撃の可能性がある場合は、インバウンドサーバーとアウトバウンドサーバーを別々に設置してこれらのサービスを提供することを考慮してください。電子メールベースのトロイの木馬またはワームがアウトバウンドメールサーバーを制御不能にしたり、オーバーランする場合でも、インバウンドの電子メールは引き続き受信することができます。同じ手法を DNS サーバーにも適用してください。
イントラネット
DMZ はインターネットにサービスを提供するホストのネットワークセグメントになります。この設計により、内部ホストは外部からの攻撃によって危険にさらされる可能性があるホストと同じセグメントにないため保護されます。内部においても、Web、メール、ファイルサービス、内部 DNS などの同様のサービスが内部ユーザーに対してのみ提供されます。ちょうどインターネットサービスが分離されているのと同様に、内部サービスも分離されます。このようなサービスの分割によって、より緊密な制御がルーターのフィルタリングで行われます。
インターネット向けのサービスをセキュリティのために DMZ に分離するのと同様に、非公開の内部サービスも独自の 内部 DMZ に置く必要があります。
サービスやネットワークのサイズに応じて、複数の DMZ が有用であるように、複数のイントラネットも役立つことがあります。
分離を可能にするファイアウォールのルールは、DMZ のファイアウォールに使用するルールと同様に設定する必要があります。インバウンドトラフィックは、内部メールサーバーに渡されるインバウンド電子メールなどの DMZ から情報を中継するマシンおよび内部ネットワークに常駐するマシンからのみ来るはずです。
内部ネットワーク
残りのセグメントから内部ネットワークセグメントが構成されます。これらのセグメントにはユーザーのマシンや部門のワークステーションが収容されています。これらのマシンはイントラネットに常駐するホストから情報を要求します。開発、研究、およびテストの各ネットワークセグメントもこのリストに含まれます。部門間のセキュリティを追加するため、それぞれの内部ネットワークの間にファイアウォールを使用してトラフィックのフィルタリングを行ってください。これらのセグメントのそれぞれに使用されている内部ネットワークトラフィックとサービスのタイプを特定し、内部ファイアウォールが有用であるかどうかを判断してください。
これらのマシンはインターネット上のマシンと直接通信しないようにする必要があります。できれば、これらのマシンと DMZ のマシンとの直接通信を回避します。つまり、必要とされるサービスがイントラネットのホストに常駐している必要があります。次に、イントラネットのホストは DMZ のホストと通信し、アウトバウンド電子メールや DNS などのサービスを完了させることができます。このような間接的な通信が許容されます。
プロキシ
インターネットのマシンと直接通信するマシンだけが DMZ に常駐する必要があります。ただし、ユーザーがインターネットにアクセスを要求した場合、これは前のトポロジの決定からすると問題を引き起こします。このような状況では、プロキシが役立ちます。プロキシを内部ネットワークセグメント、または可能なら、イントラネットセグメントに配置してください。インターネットへのアクセスが必要なマシンは、その要求をプロキシに渡すことができ、次にプロキシはそのマシンの代わりに要求を発行します。インターネットへのこのリレーアウトは、発生する可能性のある危険からマシンを保護するのに役立ちます。
プロキシはインターネットのマシンと直接通信するため、DMZ に常駐する必要があります。ただし、このことは内部のマシンが DMZ のマシンと直接通信することを防止するという要求とは相反します。この通信の間接性を保持するため、二重のプロキシシステムを使用してください。イントラネットに常駐する 2 番目のプロキシは内部マシンの接続要求を DMZ のプロキシに渡し、次に DMZ のプロキシはインターネットとの実際の接続を確立します。
ファイアウォールの設定
通常のパケットフィルタリング機能に加えて、ほとんどのファイアウォールには IP スプーフィングを防止する機能があります。可能なあらゆる箇所で IP スプーフィングに対する保護機能を使用してください。
たとえば、インターネットからネットワークへのエントリポイントが 1 つのみで、インターネットから受信したパケットに内部マシンの 1 つのソースアドレスが付いてくる場合、なりすましの可能性があります。ネットワークトポロジからすると、内部マシンの ソース IP アドレスを含むパケットはネットワーク内部からのみ来るはずで、インターネットから来るはずがないからです。IP スプーフィングを防止することによって、この可能性が排除され、IP アドレスベースの認証や他のファイアウォールフィルタリングのルールが無視される可能性が減少します。同じ IP スプーフィング保護機能をあらゆる内部ファイアウォールに同様に使用してください。
モバイルユーザー
リモートユーザーまたはモバイルユーザーがいる場合、それらのユーザーが設備にアクセスする方法にも注意してください。それらのユーザーがアクセスできない設備があるでしょうか。どのような種類のセキュリティポリシーに注意を向ける必要があるでしょうか。認証に SSL は必要でしょうか。さらに、モバイルユーザーの人数は一定なのか、または将来増加する見込みなのかを調査してください。