補遺編1 ネットワーク管理のあるべき姿

根津 研介 園田 道夫 宮本 久仁男 2004/7/30

※ご注意 本記事はフィクションであり、実在の人物・組織などとは一切関係ありません。

---

バックナンバー

第1回 それはある日突然に……

第2回 社内ネットワークの恐るべき実態

第3回 突然、メールが届かなくなってしまった

第4回 反撃開始、まずは全社的ポリシーの導入から

第5回 ポリシーを作っただけでは終わりではない

最終回 ネットワークの私的利用をやめさせよう

　中村君の社内ネットワーク管理者修業は、あちらこちらとよろよろよろけながらも何とかやっていけるようにはなりつつあるようだ。ある日、いきなり管理者を任せられてしまったにしてはよくやった方だろう。

　しかし、物事の解決方法が1つということはなく、ましてや、中村君のやり方が必ずしも正解であると断言できるわけではない。ここは現実的に、ほかのやり方、ほかの対策についてもきっちり押さえておき、中村君のような、ほんのちょっぴりの幸運にも恵まれないようなシビアな現場でも何とかなるように準備万端、備えておきたいものだ。

　このような観点から、今回と次回の2回にわたって、中村君とは異なるアプローチで、あの会社のどうしようもないネットワークを救うことを考えてみよう。

ネットワーク担当者が1人きり

部長	「小野さんは先週、病院で検査を受けたら、しばらく治療に専念することが必要ということで、急きょ、先週末で休職された」
	（第1回 それはある日突然に……）

　小野さんが入院した後、実際に考え、動くのが中村君1人という状態である。

　さて、ここで考えてみよう。中村君は、あくまで情報システム部のイチ新入部員である。本来、新入部員が入ってすぐにその人がたった1人になってしまう状況自体がかなり問題だといえる。もしも中村君が入ってこなかったら、小野さんが倒れた後は誰もメンテナンスしないという状況になりかねなかったのだ。

　しかし、専任でネットワーク管理者を置くのは難しいケースもあるだろう。会社によって上下はあるが、1人の人間を専任でつけるコストは1000万円ともいわれている。1000万円もかけてネットワーク管理だけやっていなさい、というような余裕がないことも多い。

　そんな場合には「必要に応じて」対応する人を何人か割り当てておくのがよいだろう。ただし、業務で使用するインフラをボランティアで管理してもらうというのもあまり褒められたことではない。少なくとも「そういう業務もあり、正規の業務として」上司や経営層が認知し、必要があれば代理のスタッフがその仕事を実施することを認めてもらう必要がある。

×	動ける人が1人しかいない。
○	企業ネットワークの管理担当者は、全員が専任である必要はないので複数人用意しよう。
○	必要があって、専任でない管理担当者が動く場合には、業務として認めるようにしよう。

　では、上司に「そういう業務もある」と認めてもらうにはどうしたらいいだろうか。会社に分かってもらっていない場合には、まず認めてもらうところから始めなければならないが、そのためには何をどうすべきなのだろうか。

　まず1つ、この連載では中村君は後回しにしてしまっているが、管理手順書などのドキュメントをそろえることが必要だろう。手順書があれば、「これだけの仕事をしなければ、ネットワーク管理はうまく回らないんですよ」といえるはずだ。さらにいえばそこで、日常的な管理手順、運用にかかる工数が具体的に分かっていると説得力が増すだろう。

　可能ならばそこでアウトソースした場合の見積もりを取ってみるのも手かもしれない（その結果、もっと安い工数でやれるところが見つかり、「その金額の範囲内で、社内でやるように」というお達しが出て、墓穴を掘ってしまうケースも考えられなくもないが）。

　次に、数日間の休みを取るときなどに、実際に引き継いでみる、という方法もあるだろう。管理にかかる工数などを他人に実感してもらって、説得する場合の材料とするわけだ。同時に複数人で管理する体制も作っていくことができる。

　ただし、インフラの動作を問題なく継続させることの重要性について上司が分かっていなかったとしたら、引き継ぎという作業自体が難しくなってしまうかもしれない。そういうときはそもそも、インフラ管理をやらされること自体非常に報われないだろう。可能かどうかは分からないが、転職や転属などを含めて、管理業務を拒否することを覚悟した方がいいのではないだろうか。

ドキュメントが何も残されていない

	翌日、情報システム部へ引っ越しをした中村君は、とんでもないことに気付いた。社内のイントラネットのネットワーク構成図がないし、インターネットとの接続ポイントがどこなのかも分からない。サーバマシンが何台あって、どこに置かれているのかも分からない。つまり、何も引き継ぎのドキュメントがなかったのだ。
	（第1回 それはある日突然に……）

　これまた企業ネットワークにおいては論外だ。当然、ネットワークの物理構成図や論理構成図、そして各機材の設定情報は何らかのドキュメントとして残されているべき情報である。

×	ドキュメントが残されておらず、担当者しか分からない。
×	ドキュメントは残っているがメンテナンスされていない。
△	ドキュメントは残されていないが、担当者が複数人おり、それぞれが同等に構成を把握している。
○	メンテナンスされたドキュメントが残っており、担当者が複数人いる。

　とはいえ、ドキュメントを残すというのは、中村君がやったようにどうしても後回しになりがちな作業でもある。どうしても日々の管理やトラブル対応に忙殺されてしまって、作成する時間を捻出（ねんしゅつ）できない、ということもあるだろう。

　そんなときは「平山さん」を巻き込むといい。これは別に冗談ではなく、技術知識を追いかけることに興味があり、管理スクリプトを作ったりする方がドキュメント書きより何倍も楽しいという人がいるのと同様に、ドキュメントをまとめることが得意で楽しくて仕方がないという人も存在する。

　しかし、そういう人が技術用語に慣れていることは珍しい。従って、まとめさせる側には専門用語や概念などを分かりやすく説明できる能力が必要になるだろう。それができない場合には、腹をくくって自前で作るしかない。

　そうはいっても、ドキュメント作成作業を明示的に行うことすら難しい場合があるかもしれない。そういうときは上記の「ネットワーク担当者が1人きり」の場合と同じく、長い休みを取るので引き継ぐ、という大義名分を使ってでもドキュメントを作成するべきだ。

　ドキュメントを作る行為にそれほどの抵抗がない場合には、作成作業にかかる工数をしっかり見積もって作業するといいだろう。実際の作業の記録ももちろん残す。そういうデータはいろいろ使えるので非常に重要だ。

「最終回」

1/3

---

Index
ネットワーク管理のあるべき姿
	Page1 ネットワーク担当者が1人きり ドキュメントが何も残されていない
	Page2 インシデント発生時の対応が定まっていない パッチを当てる場合の作業手順が決まっていない 勝手に無線LANを導入されていた
	Page3 トラブルばかりで管理しきれない 稼働中のサーバでソフトウェアの検証をしない 構成はきちんとメンテナンスしておこう

関連記事
	実践！情報セキュリティポリシー運用
	効果的な情報セキュリティマネジメントへのアプローチ
	【実録】ISMS構築・運用ステップ・バイ・ステップ
	スローポリシーのススメ
	連載：Webサイト運営者のセキュリティ確保の心得 第3回 データベースサーバの構築、運用から発生する脆弱点とその対策
	連載：Webアプリケーションに潜むセキュリティホール第2回 顧客データがすべて盗まれる？！
	Security Tips Index

基礎解説記事

5分で絶対に分かるシリーズ

管理者のためのセキュリティ推進室

情報セキュリティ運用の基礎知識

Security&Trustウォッチ

連載：にわか管理者奮闘記

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）