世間を騒がすようなインシデントが発生した後、システム開発の現場でしばしば起きがちな問題が、規定やガイドライン、政府統一基準などへの準拠対応だ。一筋縄ではいかないこの問題における開発現場の自衛策を紹介しよう。
この記事は会員限定です。会員登録すると全てご覧いただけます。
前回は、セキュリティインシデントによって停止したシステムの再開基準について説明した。今回はインシデントを経て企業や経営層、現場にどのような変化が訪れるのかを説明しよう。あらかじめ断っておくと、本稿は筆者の主観が含まれているため注意してほしい。
世を騒がすようなセキュリティインシデントが発生した後には、セキュリティ担当者には大きな変化が待っている。今まで後回しにされて提案時にはその必要性をとことん追求されていたセキュリティに対する無関心ぶりがウソのように逆転するのだ。
多くの企業の経営層や上層部は、世間を騒がすようなインシデントが自社で発生したり、こうした報道を見聞きしたりすると、過剰なまでにセキュリティに対して敏感になる。「自社のシステムは大丈夫かどうか」「これから開発するシステムは大丈夫かどうか」を小まめに確認するようになる。
中央省庁などでも監督企業に向けて、同様の事象を起こさないように入念にチェックが入る。だが省庁や自社の品質部門など監督する立場においても、セキュリティインシデントへの完璧な対応の判断が付かなかったり、完璧な対応の実現が現実的に難しかったりするというのが実情だ。そのため過去の規定や必要に応じて新たに追加した規定などを基に最低限クリアするべきラインを決定する。これが現場の苦悩を生む。
システム開発や運用に従事していると突然、「自組織の開発規定」「入札要件」「RFP」(提案依頼書)などに、これまではなかった規定や基準が含まれており、「え、何それ……」と首をかしげた経験があるのは筆者だけではないだろう。
Copyright © ITmedia, Inc. All Rights Reserved.