■http://anond.hatelabo.jp/20110514170542

システム管理者から言わせてもらうと、これだけの情報ではシステム停止対応をした是非は判定できないが、

おそらくは、事前通知なしのシステム緊急停止は行きすぎた対応ではないかと思う。

それに、この派遣社員は、テスターとしては合格だが、技術者としては微妙。ビジネスマンとしてはアウトだ。

このケースは、「SQLインジェクション」といって、攻撃により情報漏えいが起きる可能性であり、

システムにセキュリティ上の致命的な欠陥が潜在的に存在すると分かっただけで、事前通知なしの緊急停止という対応は普通はしない。

逆に、具体的な攻撃が観測された場合、または通常の操作で情報漏えいが発生する欠陥が見つかった場合などは、迷いなく事前通知なしの緊急停止に踏み切るべきだ。

プライベートの趣味のサイトであれば即停止でもよいだろうが、ビジネスで使っているシステムである以上、セキュリティだけでなく、事業継続性や説明責任や止めた場合の影響も考慮すべき。

緊急度や対応方法もいろいろなバリエーションがあるし、インシデント発生対応時のマニュアルを参照しつつ、状況を照らして迅速に判断することになる。

なお、判断するのは、あくまで正社員の責任者（内容によっては経営者が）であって、派遣社員ではない。

ただ会社側の体制に問題があると思う。

派遣社員の暴走？も、会社側がこういう場合の対応について考えるきっかけを与えることになっただろうから、それはそれで意義はあったのではないかと思う。

システムのことさっぱりわからない経営者やマネジメント側の人間ができることは、

(1)派遣社員には、システム運用稼働中に本番サーバを触らせないように権限を決めておく。

(2)その代わり、システム管理者として、スキルと判断力と責任感を兼ね備えた人材(正社員)を配置しておく。

(3)インシデント発生対応時のマニュアルを整備しておく。

ことだろう。

プライバシーマークやISMSを取得すれば、こういうことが体系的にできる。

私がもしこのテスター(派遣社員)から運用中のシステムの脆弱性を指摘されたらどうするか考えてみた。

（そもそもこんな品質レベルのシステムは導入する時に却下するだろうが。）

(1)テスターから第一報をうける。時刻を記録。

　ここからはインシデント対応マニュアルを参照しつつ対応する。

(2)上司に口頭で「XXシステムで、セキュリティ上の問題発生、これより対応開始します」と報告。時刻を記録。

(3)状況を確認する。

　（「SQLインジェクション」脆弱性が存在することがわかった。

　　アクセスログなどから攻撃や情報漏えいの痕跡はとりあえず見当たらない。

　　ただし、攻撃は比較的容易で、個人情報が流出する可能性があることが分かった。）

(4)対応方法を判断する。

　緊急性、停止方法、影響、修正、暫定復旧のめどを見積もる。

　（1時間以内に顧客通知を完了した上で、システムを停止して調査するとする。）

(5)上司に対応概要説明。同意を得る。

(6)顧客通知開始。時刻を記録。

(7)システム停止。時刻を記録。

(8)ここからは調査、復旧作業など、具体的な対応に入る。

トラブル対応は手がいるので助っ人を頼む。顧客への連絡などは、営業担当者でも手伝ってもらえるはずだ。

システム停止後は、攻撃や情報漏えいが起きたか起きなかったかの調査が先になるだろう。

もちろん致命的なバグを仕込んだ開発者は呼びつけて調査に加わらせる。

都度、時刻を記録するのは、後で顧客に提出する報告書を書くためだ。

また、システム停止前に利用者に事前通知するかどうかは重要なポイントで、

データの更新処理を行うデータベース連携のシステムであれば、

更新処理中にシステムを停止すると、データの内容に不整合が生じる可能性もある。

事前通知なしでシステム止めた場合、責任上これが問題となってくるし、データ不整合が発生したら、その分復旧も遅れだろう。これひとつとっても、やみくもにシステム停止すればよいわけでは決してない。

備えあれば憂いなし。

Permalink | 記事への反応(2) | 02:50

ツイートシェア