中規模ネットワークの構築 - 運用管理設計

40,50人〜数千人が利用する中規模ネットワークを構築する時の運用管理設計について説明します。

運用管理VLAN

ネットワークの管理のために、運用管理VLANを検討します。運用管理VLANに接続された機器しかネットワーク機器にSSHなどで接続できないようにして、セキュリティを確保するためです。

集中ルーティング型ではファイアウォール、コアスイッチ、エッジスイッチともに運用管理VLANのIPアドレスを設定し、コアスイッチでフィルタリングして他のVLANからは通信できないようにします。

集中ルーティング型での運用管理VLANのアクセス

この時、可能であればファイアウォールでは運用管理VLANとのルーティングを停止し、運用管理VLANからファイアウォールへは通信できるものの、他VLANから運用管理VLANへはルーティングできないようにして、万一にでもインターネットからは通信できないようにすると望ましいと思います。

物理的な接続と対比させると、以下になります。

集中ルーティング型での運用管理VLANと物理接続の対比

分散ルーティング型ではネットワーク機器すべてに運用管理VLANを設定できないため、設定されているIPアドレスに対してファイアウォール、各LANスイッチで運用管理VLANからだけ通信可能なようにフィルタリングします。

分散ルーティング型での運用管理VLANへのアクセス

物理的な接続と対比させると、以下になります。

分散ルーティング型での運用管理VLANと物理接続の対比

運用管理VLANという特殊なVLANがある訳ではなく、通常のVLANと同様の設定で作成します。

なお、実際の運用では管理端末だけアクセスできて、管理者自身のパソコンからアクセスできないと不便です。このような場合、管理端末ではなく運用管理サーバーを構築し、運用管理サーバー経由で運用管理VLANにアクセスできるようにします。

集中ルーティング型での運用管理サーバー役割 分散ルーティング型での運用管理サーバー役割

運用管理サーバーは運用管理VLANだけでなく、通常のパソコンから接続できるように他のVLAN(上の図ではVLAN30)にも接続されている必要があります。

運用管理VLANはサーバーの運用管理VLANとも共有できるため、ネットワーク、サーバー両方の管理者向けのVLANとして構築すると便利です。

なお、管理者が少ない場合や管理する機器が少ない場合は、運用管理VLANを設けずに管理者のパソコンからだけアクセスできるようにフィルタリングする方法もあります。

また、運用管理VLANに対して、通常の業務データが流れるVLANを業務VLANと呼ぶこともあります。

ログの扱い

ネットワーク機器ではログを保存できる量が少ないため、すぐに上書きされてしまいます。

トラブル発生時にログを見ようとしても消えていることもあり、複数機器がある場合、それぞれの機器から採取してくるのも面倒です。

このため、Syslogサーバーにログを保存することを検討します。

Syslogサーバーを運用管理VLANに接続し、LANスイッチやファイアウォールなどのネットワーク機器からSyslogサーバー宛てにログを送信するようにします。

SyslogサーバーとSyslogの送信

また、ログがわかりやすいようにファシリティで分類します。例えば、ファイアウォールのようにログが大量にある機器は1台で1つのファシリティ、LANスイッチのようにあまりログが多くなく機器の数が多いものは複数のファシリティにわけるとわかりにくいため、全体で1つのファシリティにするとわかりやすいと思われます。

なお、LANスイッチではパソコンが接続されたインターフェースのup、downまでログを送信すると大量になります。このため、トラブル発生時に解析ができるように基本は装置のトラブルを示すWarningやCritical相当を採取します。Warningは装置がダウンするまではいかないものの何かしらの影響がある場合のログ、Criticalは装置がすぐにダウンするような場合に出力されることが多いためです。また、勝手に設定変更されてないか確認するため、設定変更したログやログインした証跡のログを採取するようにします。

ファイアウォールについては、すべての通信のログを残すことが基本です。例えば、Webサイトを改ざんされたなどのセキュリティ被害にあった場合、ログからどの通信が原因だったか確認することができます。また、踏み台にされて意図せずに他サイトを攻撃した場合などは警察からログの提出を求められることがあります。この場合は、ログによって少なくとも悪意がなかったことが証明できます。

このようなことから、LANスイッチはトラブル発生時に使うことが主目的のためログ保存期間は短くてよいと思いますが、ファイアウォールのログは被害に合った時の対応や予期しない加害者の疑いを晴らす意味で保存期間は長くする必要があります。ファイアウォールのログはすべてのフレームについてログを採取できれば望ましいですが、ログが大量になるのとファイアウォールの負荷にも影響が出る可能性があります。このため、1アクセス単位(1パケット単位ではなく)で採取してどのような通信があったか記録することが重要です。

ログ保存期間の補足

ログの保存期間について、日本では最大90日間の保全を求められています。これは、日本も加盟している国際的な条約であるサイバー犯罪条約に従っています。保存義務ではなく保全なので、保存していたらそのまま消去しないよう求めることです。したがって、保存しなければいけないということではありません。

また、国際カードブランドの基準であるPCI DSS(Payment Card Industry Data Security Standard)では最低1年間、オンラインなどすぐ閲覧できる状態では3か月保存することが求められています。国際的なカードブランド社が運営しているだけでなく、IT企業など多くの企業が会員です。このため、カード会社でなくても参考になる数字です。

統計的には、セキュリティ事故発見から過去1年以内にほとんどの要因があるとされています。このため、ファイアウォールのログは最低3か月、できれば1年以上保存することをお奨めします。

ファイアウォールのログは、すべて採取するとアクセス数によっては大量になりますが、例えば1アクセスについて1Kバイトのログが発生し、1時間当たり10,000アクセスあった場合、1日では240Mバイトになり、1年間では約90Gバイトになります。

すでに、テラ(=1,024G)を越えるディスクも多いため、よほどアクセスが多くない限り一般の企業や研究所で1年間ログを保存することはそう難しくないと思います。

時刻同期の検討

ログをSyslogサーバーで集中管理しても、時刻がズレているとトラブル発生時に調査するのが困難です。例えば15:00にトラブルが発生し、15:00ころのログを調べていても時刻がズレていたため15:10として記録されていると、該当のログが探しにくくなります。このため、NTPサーバーを運用管理VLANに接続し、各LANスイッチを時刻同期させます。

NTPサーバーと各LANスイッチの時刻同期

NTPサーバーやファイアウォールは、インターネットで公開されている上位のNTPサーバーに時刻同期させるようにします。

インターネット上のNTPサーバーへの時刻同期

上記のようにすると、以下の階層構造となり、すべての機器で時刻同期されます。

NTPの階層構造

上位のNTPサーバーは、通常は複数設定できます。このため、NTPサーバーが複数台ある場合はすべてのNTPサーバーに同期するように設定することで冗長化が可能です。

SNMPおよびSNMPTRAPの検討

ネットワークの管理・監視のために、運用管理VLANにSNMPマネージャを接続することを検討します。

導入するSNMPマネージャによって機能は違いますが、一般的にはMIBを収集することで通信量がどの位あるかグラフで表示して把握することも可能です。

通信量をグラフにした例

運用管理に特化したOSSとして、Zabbixがあります。Zabbixでは、TRAPによる監視や、MIBを収集してグラフ化することもできます。また、TRAPを受信すると管理者にメールを送信することも可能です。

Zabbixでの運用管理例

Zabbixは、GNU General Public License (GPL) version 2というライセンスを採用していて、自由にダウンロードして無料で利用できます(Zabbix自体を商用環境で利用する場合は、いずれかのレベルのサポートの利用がお願いされています)。

DMZについて

DMZのLANスイッチを管理する方法は、2とおりの考え方があります。1つは、すでに説明した運用管理VLANにそのまま接続する方法です。

DMZのLANスイッチはファイアウォールのDMZのインターフェースに接続されていますが、運用管理VLANのIPアドレスを設定すれば論理的にはDMZに接続されていないことになり、例えファイアウォールのフィルタリングがなくてもインターネットからDMZのLANスイッチへは通信できません。これは、DMZのLANスイッチがDMZのネットワークに属していないためです。

DMZのLANスイッチはDMZのネットワークに論理的には接続されていない

LANスイッチだけ考えた場合はこれで問題ありませんが、DMZにあるサーバーまで含めて考えた場合は少し検討が必要です。

サーバーは、通常のインターフェースとは別に管理用のインターフェースを接続するための運用管理VLANが必要になることがあります。

この運用管理VLANは、サーバーから通信を発信できる場合はイントラネット内の運用管理VLANと同じであってはいけません。DMZのサーバーはインターネットに公開されているため、万一乗っ取られるとイントラネットすべてのサーバーやLANスイッチが危険になるためです。

DMZのサーバーが運用管理VLANに接続された状態

このため、可能であれば小さなファイアウォールを導入して必要な通信だけ透過するようにします。

DMZのサーバーは乗っ取られてもイントラネットには入られないようにする

DMZの運用管理VLAN用のLANスイッチを用意してDMZのLANスイッチやサーバーを接続し、小型ファイアウォールに接続することで実現可能です。

このようにすることでセキュリティを確保しつつ、DMZとイントラネットの運用管理VLANの間でSSH、Syslog、SNMPなど必要な通信が可能になります。

小さなファイアウォールを用意できない場合は、DMZの運用管理VLANをインターネットに接続するファイアォールに接続してイントラネットの運用管理VLANと通信できるようにしても大丈夫ですが、設定が複雑になるため充分留意が必要です。

なお、DMZのLANスイッチやサーバーに関しては公開NTPサーバーに同期させますが、DMZにNTPサーバーがある場合はこのサーバーに同期しても良いと思います。

LLDPの検討

LLDPをサポートしている機器がほとんどの場合は、有効化することを検討します。LLDPを利用することで近隣の装置の把握だけでなく、どのインターフェースに接続されているかの確認も容易にできるようになります。

このため、間違ったインターフェースのケーブルを抜いたり、間違ったインターフェースの設定変更をしたりするミスを防ぎやすくなります。

なお、Catalystの場合、LLDPと同等の機能であるCDPがデフォルトで動作しています。LANスイッチをCatalystで統一している場合はそのまま有効でよいと思いますが、Catalystが少ない場合はCDPを停止することも考慮します。

中規模ネットワークの構築関連ページ