ネットワークを考えるときに考えること(6)

前回に続いて非機能要件としてどういう話を考えるか。

非機能要件を考える

拡張性

増減するもの:

  • 機器単体
    • シャーシ型の場合はいろいろ増えますが…まあ筐体内に収まる範囲内でしょう。筐体に外付けでくっつけるようなものがある場合とかは要注意なんですが、ネットワーク機器の場合はあまりないかも。スタッキングによる拡張を想定している場合は、スタック拡張用のスペースはあらかじめ見込んでおいてください。機材にも寄りますが、例えばC3750系とかだとスタックケーブルは数メートルの範囲内だったはずです。
    • モジュール型機器の場合はモジュールの追加とか交換とかができるような配線になってること。
    • いずれも増やすものに合わせたスペースと電源の確保が必要。シャーシ型機器の場合、内部に入れるモジュールによって電源モジュールを容量の大きいものに変える必要があったり、電源モジュールの追加が必要だったり。
  • システム全体
    • システムの規模が大きくなれば、サーバなどの増設などにあわせてネットワーク機器も増設されます。
    • システムが拡張される(縮小される)ときに何が増減して、それに合わせてネットワーク側は何をすべきかというのを見ておきます。
    • 当然、物理的な増減もありますし、データ量やトラフィックの変化なども合わせて考えていきます。
    • システムワイドという話であれば、データセンタ内のラック増設、増床、データセンタそのものの追加や移転、といった物理面(ファシリティ面)の変化もあり得ます。

拡張単位・拡張条件:

  • 物理リソースの使用量やキャパシティに応じて、どういった条件でどの単位で拡張を行うかを考えておきます。
    • 物理・論理リソースの割り当て、作業時のオペレーション、必要に応じて発注や作業のリードタイムを含むスケジューリング…なども。足りなくなってからだとだいたい間に合いません。こうした条件を満たす状況が発生した場合には何らかのリソース拡張を検討する、といったトリガ設定をしておいた方が良いです。(そして、そのためのモニタリングをちゃんとやりましょう。)
    • 拡張上限がどこなのかを見ておいてください。リソースとして増やせるもの・範囲・上限はどこか、上限に対してシステムがどこまで拡張できるか。(プライベートIPアドレス枯渇問題、VLAN ID枯渇問題…)
柔軟性

(ネットワークの)柔軟性ってなんだってところですが…。いったん作ったら基本的には構成や設定を変えない静的なシステムなのか、環境の構成変更が頻繁に行われる動的なシステムなのか、くらいの話ですここでは。基幹系とかミッションクリティカル云々という話の出るところでは、最初にがっちがちに作って後はひたすら定常運用(変更作業は原則行わない)…なんてところもあります。逆にプライベートクラウドとか、サーバ仮想化基盤が全面的に使われてているようなところでは日常的に論理環境の追加・変更・削除が行われるようなシステムがあります。変更の内容や頻度、単位などに応じてそれらにあった構成や技術が必要ですし、求められる変更作業要求(作業時間・サービスレスポンスなどの時間)をどうクリアするか、という検討が必要です。

  • 通常のシステム運用で変化させるもの
    • どこが「柔軟」であるべきか?
      • 計算機リソース(仮想マシン)等の追加・削除・位置の変更
      • システムやセグメントなど論理リソースの追加・削除
    • それらの変更作業の頻度(の想定)、オペレーションに許容される時間はどの程度か?
  • 構成の変動・リソースの変動
    • 環境構成を変えるようなもの、単純にリソースの追加、など構成の範囲や単位を考えます。
    • リソースについては当然、物理・論理という話がくっついてきます。
セキュリティ

ネットワーク設計は関係性の設計、みたいな話を最初に書いたりしたわけですが、これは「すべてのノードがすべてのノードと自由に接続できるのが理想」みたいな話を書いているわけではありません。Public internet な話であればそうかもしれませんが、少なくとも企業のネットワーク設計においてはそうではありません。「関係性」には「関係してはいけない」という条件が含まれます。一部の人にだけ限定して見せなければいけないとか、特定の何かからだけアクセス可能でなければいけないとか、そういうコントロールも必要になります。システムとして実現すべきアクセス制御は何か、ネットワークで担保すべきアクセス制御は何かを考えてください。

セキュリティの話も多岐にわたるので一概に言えないですが…。「ネットワーク」に求められるセキュリティサービスという観点で、こういった話は考えておきましょう。

検査(ネットワーク面):

  • IDS/IPS, DDoS対策などの侵入検知・プロテクション系
    • Web系であればWAFなどの高レイヤ検査が検討されることがあります。
  • ネットワークとしてどこでそういった検査ポイントをもうけるべきか、どういった検査を行うべきかを考えます。とくにWAFなどアプリケーション依存の高いものはアプリケーション担当側と話をする必要があるでしょう(少なくともネットワーク担当者に丸投げ、みたいな話をされないように。)
    • アプリケーション検査系は、利用したいアプリケーションや検出したい事項について正しくカスタマイズされないと大して効果ありません。システム要件上、そうした機能が必要だからと行って導入したものの、ほとんどデフォルトの設定のままポン付けされているという話もあります。が、高い金払っておいておくだけで何の効果があるのか。安全祈願のお札と大差ありません。
  • 検査用の機器の導入方法(物理・論理構成)は注意してください。検査対象フローの流れる箇所にインラインで入れる必要があるのか、ミラーあるいはタップして検査だけ行わせるのか。いずれの場合もトポロジや系切替などで対象フローが移動した場合にどうなるのかを考慮して入れておく必要があります。
    • 物理的なTAP装置を入れる場合はTAP自体の物理障害時の動作などを確認しておきましょう。
    • そもそも物理的に入れられるかどうかも当然検討に含める必要があります。インテリジェントタップなんて製品もあったりしますが、セキュリティポリシ上L1タップ(プリズムによる光る分岐など信号処理を伴わないもの)のみ可とする…なんてセキュリティポリシになってるシステムの話も聞いたことがあります。
    • ミラーリングを想定している場合、ミラー取得ポイントとその機器で設定できるミラーセッションに注意してください。(通常、ミラーリングセッションには上限があります。Ciscoだと2セッションまで、とか。)*1
    • 場合によってはリモートミラー(RSPAN)を使う必要があるかもしれません。この場合RSPAN用のVLANを用意したり、SPAN中継機器で専用に物理リンクを確保したり、といったネットワーク構成が必要になります。

検査(システム内の機能として):

  • ウィルス対策、パターンアップデートの方法とパス、パターン配布方式。
    • IDS/IPSなどのシグネチャ更新やWindows Update等なんかも含まれます。
    • 最近出てきているセキュリティアプライアンスでは、発見された怪しげな検体をインターネット上のサービスに転送して、そこで実際に実行・検査する…なんて物もあります。その機械はどこを通して何を送付しますか?
  • ログや監査システム
    • システム内のログ集約、検査、監査、監視
    • レポーティングの方法

権限分離・構成分離:

  • L4以上での分離: 接続可能だが接続できるものを制限する: パケットフィルタや認証を加えたアプリケーションレベルの話での権限分離
  • L3以下での分離: 経路制御上での分離やセグメント単位での分離。システムのネットワーク構造としての分離。
  • システム内というだけでなく、システム間で正しく分割管理されているかどうか、といった観点もあります。仮想化して物理リソースを複数システムで共有している場合は特に。
運用

対象システムを維持・管理する上で、誰が何をするか、というのを考えます。

操作:

  • 運用業務(定常的なオペレーション)として、誰が、どこから、どこに対して、何を行うのか。
  • アクセス経路は?
  • 非常時の対応は?
    • 社外(システム外)からのアクセスパス: リモート接続法と経路(回線)の確保: 障害発生時に外部からアクセスさせる必要があるかどうか。ある場合はどういうパスで、どこまでアクセスさせるか。アクセス時の認証方式や暗号化方式をどうするか。
    • トラブル発生時に中の人がどこにもつなげない、という状況になるとお手上げです。サポートとの連絡、ベンダからのパッチ受領、ソフトウェアアップデートの取得、必要なツールの取得、類似現象やベンダ内ナレッジの検索…など。

分離:

  • サービス(表)と運用(裏)の分離という話も書きましたが、運用系の(バックエンドの)システム屋そのトラフィックをどう分離するかというのは考えておいてください。
  • 表-裏間のトラフィックは絶対に発生するので(監視とか)、環境として完全に分離すると言うことはできません。表/裏のセキュリティポリシに応じてどのようにコントロールするかを検討します。
  • シリアルコンソールサーバやiDRAC/iLOなどのハードウェア管理モジュール、リモートKVMなどの独立したパスでハードウェアを直接操作できる機能を有効活用しましょう。障害対応の強い味方(場合によっては最後の手段)です。

監視・モニタリング:

  • 表裏と経路
    • 監視システムを裏(バックエンド)に億場合、"表"をどういう経路で監視しますか? "表"のサービスとして、何のサービスを、どういった観点で監視しますか?
  • チェックするもの
    • 死活: デバイスの生死、ポートの生死、(デバイス上で動かしている)サービスの生死
    • 品質・性能: RTT(遅延), レスポンスタイムなどの監視
    • リソースとキャパシティ: 機器の CPU/メモリの利用率, データ流量など
      • 機器で動かしているサービスに応じて何を監視するかを考える必要があります。BGP Gatewayなら経路数、ある程度規模の多いNAT処理をしているならNATテーブル…など。
  • 監視方法: SNMP polling, SNMP Trap, ping等の応答, サービスに応じたパケットの応答, syslog
  • モニタリング: 時間的傾向の記録・可視化…通常時に対してどの程度増えた(減った)が異常・正常を判断するひとつの指標になります。

次回

とまあいろいろぐだぐだ書いてきたわけですが、繰り返し同じような話が出てきていると思うので、検討するときに共通する考え方とか観点についてちょっと書いてみようと思います。

*1:最近の機材はわからないですが、C6500/FWSMとかだとFWSMが自動的にミラーセッション使うようになっていてC65側で利用可能なミラーセッションが自動的に1個だけになってたと思います。使う機器によってミラーセッションをデフォルトで食われるなんて事があるかもしれません。