データ入力するだけが役目

さて、アルバイト先で、業務範囲の話があった。
  「ファイヤーウォールのルール（NSだからポリシーと呼んでいる）設計は考えましょうチームでやるから、天災さんと秦野くん（仮名）のネットワークの日常メンテナンスしますチームはこのルールを実装するだけでいいです。」
とハッキリ言われたのが07/03の月曜日である。たしか、新たに建てたサーバにAnti Virus系アプリをインストールしたいのに、そのポートが開いていない、というので騒ぎになった後。

• セキュリティーポリシーに従ってプロテクトソフトをインストールしたい人達と、
• セキュリティーポリシーに従ってルールに乗っ取った申請がないとFWルールの変更を受け付けない人達

のせめぎ合い。

原因は、考えましょうチームのFWルール設計がAnti Virus系プロテクトソフトを考慮していなかった、というお粗末な話。
※もしかして、考えましょうチームは、

• プロテクトソフトをインストールするというセキュリティーポリシー

の存在を知らない？ ※　その日はあとで焼肉パーティーと、吉祥寺でこずえちゃんとのデートがあったけっ。

データ入力したとたん事件は起きた

14日　金曜日の午前に、考えましょうチームから秦野くん（仮名）にFWのルール設定の依頼がきた。ルールは既に考えましょうチームで考案済み。

秦野くん（仮名）、自分で全て出来ると思い込んでいるようで、天災には「これから何をするか」を報告せず、午後になるとその設定シートどおりにFWにルールを入れていった。

秦野くん（仮名）は社会人2年目だけれど、人材派遣会社と化している某自称中堅SI会社のプロパーである。某中堅SI会社の名前はこの3月いっぱいまでの常駐先でも聞いたことのある会社だ。最近、自称エンジニアというコンピュータはいじった事あるけれど仕事経験はない人達を人材派遣（特定派遣）している自称SI会社って多いね。→　FSIとか鈴木さんの会社とか増幅度とか・・・。

秦野くん、論理的に話すことはまだまだだし、的確に言い当てる事も出来ないが、本人は随分出来ると思い込んでいるようで、話す言葉は丁寧語だけれど、随分偉そうな言い方をする。

今回も、天災のアラームメールに対して返ってきたボス達のメールを読んで
  秦野：「ボスたちも天災さんと同じ意見でしたね。」
なんて言っているが、先日の考えましょうチームのFWルール設計がプロテクトソフトを考慮していなかった事件で、
  「ファイヤーウォールのルール設計は考えましょうチームでやるから、ネットワークの日常メンテナンスしますチームはこのルールを実装するだけでいいです。」
を覚えていれば、
  秦野：「ボスたちも天災さんと同じ意見でしたね。」
なんて言ないはずだ。秦野くん、まだまだだな。

すぐに天災の隣のサーバ監視の真面目青年の前にあるパトライトが点滅し始めた。真面目青年は慣れたもんで、NMSの画面からアラームログを確認、すぐにアラームを出しているサーバとどんなアラームかを察知した。

天災、自分の仕事と責任を理解しているので、そのアラーム画面を横から覗き込み、未だアラームの事に気付いていない秦野くんのところへ行き、
  天災：「今向こうでxxxサーバの死活監視アラームがでているんだけれど、そのall denyと関係あるのかな？。」
  秦野：「えっ！？そのサーバのIPアドレスはなんですか？。」
  天災：「知らないよ。サーバ監視チームに訊いたら。でもホスト名はxxxって判るよ。」
で秦野くん、そのホスト名からIPアドレスを引き出し、all denyに変更したところがビンゴ！ッてことに気付いた。

ですぐに元に戻し、変更を無かったこととするような振舞いを始めた。その対処が変と感じたので質問した。
  天災：「それ、何してるの？。」
  秦野：「all denyに変更したところが監視トラフィックを阻害しているようなので元に戻しています。」
天災はここで、

• お客様からのオーダでall anyをall denyに変更したのだから、その対処は変である。
• all denyへの変更が監視トラフィックを阻害していると確認が必要である。同時進行で別な障害がでている可能性がないとはいえない。憶測で行動するとトラブル解決にならない。
• 更に、もしall denyへの変更が監視トラフィックを阻害していると確認できたら、変更を元に戻す。
• all denyへの変更が監視トラフィックを阻害していると確認できたら、次に変更のオーダを出した考えましょうチームに、「このルールをインプリメントすると監視トラフィックを阻害します。」を報告する

それがビジネスとしてのやり方だろう？と多少怒鳴り気味に言った。もっとも、今回は十中八九、傷害の原因は新たなFWルール設定だろうから、復旧という点では原因確認前でも戻した方が良い、という人もいるだろう。

天災が考える、本来ならどうすべきかは、ルール投入前に、隣のサーバ監視の真面目青年など、関係各方面に、
  天災：「本日午後、Wルール変更あります。何らかの影響出るかも知れません。」
とか、
  天災：「今からFWルール変更するから何らかの影響出るかも知れないから。」
と事前に承知しておくのが良いんだろうけれどルール化されていないからね。

で秦野くん、サーバ監視チームのところへ行き、
  秦野：「監視サーバはどんなサービスを利用していますか？」
と要領を得ない誤解を生む質問をして、得たい回答を得られないでいた。秦野くんはポート番号を訊きたかったのだろう。特定のTCPやUDPのポートをどんなサービスが利用しているか、という会話を最近していたのだろう。しかしこのセリフでは通じない。なんかソネソネみたいな奴だな。

そこでこんどは天災が、サーバ監視チームのところへ行き、
  天災：「いまFWのルール変更をしていて、全ポートを遮断しているんですけれど、どうやら監視トラフィックを阻害しているようです。FWルールは午前と同じ状態に戻しました。今は監視トラフィック流れていますか？」
と訊いた。サーバ監視チームの年長者、FWのポートを変更していいか？、という質問と勘違いしたらしく、
  監視：「僕にはそれをしてよいかどうかの権限はありません。」
とか言っている。そこで、
  天災：「FWルールは午前と同じ状態に戻しました。監視トラフィックが30秒に一回とか5分に一回とか自動で定期的なのか、マニュアルで流せるのか知らないけれど、監視トラフィックが流れてアラームが下がるかどうかを確認して欲しい。監視トラフィックがトリガとなってアラームが下がると思うから。」
と言った。やっとサーバ監視チームの年長者、理解したようで、pingを実施、（死活監視はpingの定期実行だったのね。）
  監視：「今は大丈夫です。元に戻りました。」
となった。

その後、考えましょうチームから秦野くんに、今回考慮洩れをした監視トラフィックを反映したルールの提示があり、FWの設定はすんだ。

入力データのチェックはしたほうが良いのだけれど・・・

ネットワークの日常メンテナンスしますチームの年長者である天災のところへ、お客様の日常メンテナンスしますチーム統括のサブリーダがやってきて、
  統括：「ネットワークのメンテナンスしますチームでは、FWルールに洩れがあるかどうかチェックしないの？」
と質問してきた。質問の形は取っているけれど、
  統括：「人間はミスするものだから、二重三重のチェックはすべきだろう。」
と暗に言っている。困るよねぇ。僕もチェックはすべきと思うが、この人の場合、正論一見カッコいい正しそうな論なんだけれど、実は部分最適な穴だらけの意見。他所の至らないところを指摘する事で「できる奴」というふり・もしくは上司からそのように思われてきた、という事が判る。まぁ、クラスで上から数えて5番目程度の、周りの人よりチョット頭の回転が速くて、声がでかい、というタイプ。実は能無し。なぜなら、
  天災：「おっしゃるとおりですね。次回からそのように対処します。」
って言えない事情っていうのがあるのに、判っていない。そっから先の会話。
  天災：「僕ら、ネットワークのメンテナンスしますチームの役目は、FWルールを機器に実装するだけです。FWルールの設計はしません。」
  統括：「いや、設計じゃないよ！チェックだよ！」
  天災：「そうですね。それではチェックと言い換えましょう。僕らは渡されたルールをインプリメントするだけでチェックはしません。現時点ではチェックも出来ません。それはご存知かもしれませんが、大きな声で言えない理由からです。（ここでそれを説明させるなよ！お願いだ。←　心の声）もどかしいかもしれませんが、これが僕らの役目です。出来ればそちらから問題としてあげていただければ有難いくらいです。」

天災と同じSI会社から、お客様の考えましょうチームへ常駐者がいた時には、その常駐者が「漏れがないか」のチェックをしていたということだが、07/03日をもって考えましょうチームから常駐者は撤退、お客様のリソースだけで設計が行われる事となった。でFWルールの設計はそこの考えましょうチームでやる事となっており、ネットワークのメンテナンスしますチームでは関与しない。

しかも、ネットワークのメンテナンスしますチームでは、監視トラフィックがどんなものか知らされていない

• syslogがあるのか、SNMP監視もしているのか、他の監視トラフィックはあるのか
• 監視トラフィックがあったとして、それらの監視サーバのいるネットワークは何処なのか、
• 監視対象は何処なのか
• 監視トラフィックだけでなく、他にも何らかのサーバ間トラフィックはあるのかないのか

なんて情報は全く知らされていない。知らされる様子もない。トラフィックのソースとディストネーションが判らずに、必要なポートをあけている設計かどうかなんてチェックは出来ない。

• 漏れのないチェックが出来るということは、設計できるのと同程度の情報を知っているということ
• 漏れのある設計をすると言う事は、必要な情報を知らないということ
  （もちろん、ついうっかりという可能性はある）

明かりのない暗闇の中で、「これは何色だい？」って訊かれても答えられないぜ！

にも関わらず、チェックを要求されてもねぇ。必要な情報無しに
  天災：「おっしゃるとおりですね。次回からそのように対処します。」
って役目だけ引き受けて、穴だらけのチェックをして、またまた何らかのトラフィックを阻害して、
  お客様：「お前ら仕事してんのか！！」
って怒られるだけだろう。
※　「怒られるだけ」で終わらず、もっと悪い事がになったりして・・・。

なんかあった時に、お客様でも「自分が責任とりたくない。」と誰もが思ったりすると、設計した自社の人よりも他社の人ならば文句言い易いって事で、責任をとるスケープゴードを作れば良いってことなのかな？。その犠牲者が仕事を失う事になっても心痛くないしねぇ。

どうして、
  統括：「チェックに必要な情報は、これ、この通り、ここにあるからさ、チェックしてくんないかな？」
って、いえないものかね？
  統括：「チェックに必要な情報？うんなもん、そっちで調べてよ！」
っていうつもりなのかな？

松井君！エンジニアのくせに非論理的だね！