- - PR -
WANを統合するときの課題
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2006-06-13 11:05
皆様，アドバイスありがとうございます．
>一番いいのは、作業期間中はWAN回線を2重に持つことです。 なるほど，リグレッション環境でちゃんとテストしてから 切り替えることは大事ですね． >機材次第じゃないんですか？ >自動化して正しく書き換えられたら良いですが、人の手作業でやらないと、 >問題が発生したときに対応できませんよ？ 確かに，自動化できれば便利ですけど，ちょっと不安が残りますね． だとしたら，スキルのある人が手作業でやったほうがいいですね！ 皆様のおかげで，WANを統合するときの課題については理解できました． 一点だけ，関連して気になっている点がございますので， 質問をさせて下さい． WANを統合すると，外部からのセキュリティの脅威が増えたり， 脅威の進入経路が変わったりするので， あらためて，ドメインやセグメントの分割を 見直す必要がでてくるかと思っております． ■そこで，知りたい事は，ネットワークのセグメントをどのような観点／プロセス で分割するかということです． 自分なりに調べた範囲では， ネットワーク内のトラフィック量やセキュリティポリシーを考慮して、 セグメントを分割することがわかりました． ネットワーク設計のセグメント分割のプロセスなど ありましたら語教授ください． | ||||
|
投稿日時: 2006-06-13 14:19
こんにちは。
意気込んでいるところスイマセン。
WANの統合によって、脅威が増えるのですか？ 脅威って何でしょうね？ セキュリティ対策を考えるのであれば、脅威分析をまず行ってみてはいかがでしょうか？ 何が脅威となりますか？ 何処から？、誰が？（何が？）、どんな手段で？ （どんな事を考えるかはノウハウだったりするので具体的な記載は控えます） どうやって、それぞれの脅威から守りますか？（場合によっては守らないという選択もあり。） そういうところを考えてから、セキュリティポリシーとか決められるんじゃないかと思います。 つまり、そういう物もなしにセキュリティポリシー云々を語ったところで「どんなセキュリティポリシーなの？」って部分でつまづくんじゃないでしょうか？ 曖昧なまま作業をすすめるから、どういう基準でネットワークセグメントを構成するかも決まらないのでしょう。 セキュリティポリシーを明確に定めれば、あとは決め打ちだと思います。 | ||||
|
投稿日時: 2006-06-13 15:23
こんにちは。
最近のネットワークはスイッチ類を多用するケースがほとんどなので、以前に比べ トラフィック対策に主眼を置いた複雑なセグメント分割が減っています。 （とは言ってもブロードキャストはコリジョンドメイン全体に流れます） そこで、大雑把ですが、 1.WANを隔てた拠点は独立セグメントにする。 2.同一拠点でも、構成機器100〜200台程度を上限に別セグメントにする。 程度の設計で良いと思っています。 → Ethernetの原点のCSMA/CDに準じた設計ですね。 なお、セキュリティ面に関しては、セグメント分割により確保できるセキュリティ レベルには過度の期待はせず、認証VLAN方式の採用等による環境整備を推奨します。 → 昔はLAN内のローカルルータにACLを入れたり、専用ファイアウォールをたてる 等の対応もしましたが、出張先からアクセスしたい等の要望に対応するのが 困難なのでこの方式に変更した経緯があります。 多少なりとも参考になれば幸いです。 | ||||
|
投稿日時: 2006-06-14 10:20
こんにちは。
皆様がいろいろなアドバイスを提示されているので、補完というかポイントだけ。 ・アプリケーションサービスにおける品質基準（必要帯域、QoS等）の考慮は？ ・伝送路上の遅延の考慮は？（上の品質基準に絡むかも） ・引き込み回線の物理配線の考慮は？ 光の場合、宅内工事が必ず発生しますが、設置場所、工事内容確認、（テナントの場合）施 設管理者の承認等々は大丈夫ですか？ ・回線納期、回線サービス範囲の考慮は？ 光回線の場合、現地調査→宅内工事→終端装置設置工事→開通というステップになるので、 納期は結構かかります。また、光ブロードバンド回線を利用する場合、サービス範囲が限 られていますが、考慮されていますか？ ・利用回線サービスの仕様制限の考慮は？ L3サービスではIP以外疎通不可です。SNAとありませんか？ IPXとかも大丈夫でしょ うか？ また光ブロードバンド回線利用時は、原則QoSはかかりませんが大丈夫ですか？ ・法令対応の考慮は？ 今後くるであろうJ-SOX法に対応できますか？ Network設計の参考図書としては他スレでも書いたような覚えがありますが、『マスタリングTCP/IP ネットワークデザイン編』という著書がありますので、一読される事をお勧めいたします。 以上、ご参考まで | ||||
|
投稿日時: 2006-06-22 10:20
皆様アドバイスを頂きありがとうございます．
ちょっとわからない点がありましたので，質問をさせてください． >2.同一拠点でも、構成機器100〜200台程度を上限に別セグメントにする。 >程度の設計で良いと思っています。 >→ Ethernetの原点のCSMA/CDに準じた設計ですね。 「構成機器100〜200台程度を上限に」とありますが， この100〜200台という基準は，CSMA/CDに準じた設計では，よく言われる 一般的な事なのでしょうか． 構成機器の上限の決め方の方針などありましたらご教授ください． | ||||
|
投稿日時: 2006-06-22 12:24
こんにちは。
一般的かと言われるとコメントに窮しますが「経験上問題が発生していない」 レベルであるとご判断願います。 多少荒っぽいコメントで恐縮ですが、セグメント分割数は多すぎても少なすぎて も管理上手がかかりますので、（適切な表現でありませんが）損益分岐点に相当 する分割単位を模索した経緯があります。 プライベートアドレスのサブネットマスク長はご存知ですよね。 クラスCの24bit長によるセグメント分割では、セグメント内の最大アドレスが 254個になりますが、この部分に着眼して当初はMAX200以内で設計してました。 → 残り50数個は予備のつもりでした。 その後、企業内の部署の特長により研究・企画部門等の通信量の多い部署は分割 しています。 今回の相談内容ですが、主体がWAN部分なので前のコメント内容を参考にして頂く 程度で十分だと思います。 → 「構成機器100〜200台程度を上限に」とは後（WAN構築後）から拠点内を 再度セグメント分割可能なアドレス設計をしておいたほうが良い程度に 解釈いただければ幸いです。 [ メッセージ編集済み 編集者: BackDoor 編集日時 2006-06-22 15:14 ] | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。