1|2|3トラブルばかりで管理しきれないとにかく中村君の会社のネットワークはトラブルが多い。トラブルも、部分的にサーバが止まるとか、ネットワークが突如重たくなるなどの大きなものから、IPアドレスのバッティングや、Webサイトが見られない、メールがなかなか届かないなど細かいものまで、毎日毎日これでもか、というくらいトラブルが出てくるのだ。メールが届かなくなってしまった)もともと全く構成管理されていないネットワークなのだから、トラブルが出ない方が奇跡だ。念頭に置いたうえで、どのように次につなげるかというのが重要になる。要員が増えた(増やしてもらえた)ときもスムーズに管理できるよう、複数のメンバーでこれまでの対応履歴を共有できるようにしておく仕組みもこのときに考えておくべきだろう。この際に履歴の更新手順も考えておく必要がある。日々の対応をしたらしっぱなし。日々の対応を紙にメモする。日々の対応をExcelのワークシートなどで管理する。日々の対応をWikiやBTS(バグ追跡システム)などで管理。「ウチで今度売り出すソフトウェアを試したい、って営業から強くいわれたんだよね。そのソフトウェアってメールサーバと連携するみたいなんだけど、いわれたとおりの設定をしただけなんだけどなあ。設定したところでおれ倒れちゃったんだよね。メールが届かなくなってしまった)このようなソフトウェアの検証のために社内インフラを構成するサーバを使ってはならない。検証用のサーバを別に用意すべきであり、また、検証は通常のインフラとは隔離された専用の検証用ネットワーク内でのみ実施すべきだ。間違っても問題なく動いている通常のインフラには、緊急の問題対策以外で手を入れないようにしておくべきである。万が一、そういう要請を突っぱねることができなかったとしたら、どうなっても責任は取れない、ということを上司や要請を出してきた相手に納得させるべきだろう。そのサーバの管理責任を要請元が取ること、および、インフラへの影響などをかんがみて一方的に切断する場合もあること、また、接続期限が明記されているといった内容の確認書を取っておくとよいだろう。そのうえで、できる限り素早く復旧する準備をしておき、そこで初めて実験をやらせるべきだ。「やらせない」で済むのであれば、それが一番良いわけだが。実験的な用途に社内インフラを構成するサーバを使用。実験的な用途に社内ネットワークに検証用サーバを接続し、検証。実験的な用途に実験ネットワークに検証用サーバを接続し、検証。構成はきちんとメンテナンスしておこう常に最新の実物の構成と、それに対応したドキュメントを用意しておくべきだ。その場合、メンテナンスするに当たっての手順もちゃんと定義しておき、担当部門のほかの担当者が知らないうちに構成が変わっていた、ということがないようにしておかないと、同様の事故の再発は防止できない。本記事はフィクションであり、実在の人物・組織などとは一切関係ありません。情報セキュリティ運用の基礎知識Security&Trustウォッチ全記事一覧から各連載にアクセスできます。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。