第1回 情報セキュリティポリシー入門
第2回 策定期間短縮のススメ
第3回 サンプルを用いたポリシー策定方法
第4回 セキュリティポリシー運用のサイクル
第5回 ポリシー運用サイクルに適した形態とは
第6回 ポリシー運用の実際とコツ
これまで、情報セキュリティポリシーとは何かという説明から策定の仕方などについて解説してきたが、ここからは今回の連載のかなめである情報セキュリティポリシーの運用に焦点を絞って解説していきたいと思う。今回と次回の2回に分けて、情報セキュリティポリシー運用の実際と注意点、ポイントなどを解説していくが、今回は情報セキュリティポリシー運用の基本的な流れについて説明する。
情報セキュリティポリシーの運用に必要な基本的な作業は以下のようなサイクル図で表すことができる。
情報セキュリティポリシーを対象ユーザーに配布し、配布されたものをユーザーが閲覧する。閲覧した内容について同意することをユーザーに要求し、それに対して同意できないというユーザーがいる場合はその意見や理由を現場の声として収集する。それらの情報や同時に収集したセキュリティ情報などと、現時運用されている情報セキュリティポリシーの内容を照らし合わせて、妥当であるかどうか判断し、変更する必要がある場合は変更を加える。そしてその変更内容を再び対象ユーザーに配布し、同意を得る。
以下これらの作業を繰り返しながら、情報セキュリティポリシーの内容を徐々にブラッシュアップしていく。これらの作業を、順を追って詳しく見ていこう。
まず、ユーザーに情報セキュリティポリシーを配布するわけだが、その前段階として配布する対象者を絞る作業が必要になる。
基本的に情報セキュリティポリシーは全社に公開するものであるが、その内容によっては対象者を限定した方がよい。
例えば、「Webサーバの管理に関する規定」といったものは、Webサーバの管理にかかわる者にのみ閲覧させればいいものであって、全社に配布する必要はない。人事部にこのような内容を参照させても何の効力も発揮しないし、むしろ逆効果である。
もし、自分が人事部で採用にかかわる業務を行っているとして、自分のところにセキュリティに関する規定だということで50ページにわたる文書が回ってきたとしたら、皆さんはそのすべてを熟読されるだろうか? しかも、目次を見ると「Webサーバの管理に関する規定」などという、自分にはまったく関係のなさそうなものまで含まれている。こんな状態では、読む気にならないのではないだろうか。せいぜい、目次と最初の2、3ページを読んでみて、隣の人に渡してしまうのが関の山だろう。
このような事態を避けるために、各自にかかわりのある内容だけを絞って見せ、ユーザーの情報セキュリティポリシーの参照率が上がるよう工夫する必要がある。参照率が上がれば、情報セキュリティの重要性、自分の責任などに対する理解が深まり、全社的な情報セキュリティレベルの向上につながる。対象者を絞るだけですべてがこううまくいくわけではないが、このような細かい努力なくして情報セキュリティポリシーの運用を成功させることはできない。
また、参照率の向上というプラスの働きとは逆に、Webサーバの管理者以外にこの内容を参照させてしまうことによって、所属は人事部であるが少しセキュリティに詳しい人間がこの情報を悪用して顧客データを盗む、というような内部犯行を助長するようなマイナスの働きをしてしまう可能性もある。
このように、情報セキュリティポリシーを参照させる内容を増やすことはマイナスの方向にしか働かないということができるだろう。各ユーザーに対して自分が行わなければならないセキュリティ対策が何であるかということをはっきりと分からせるためにも、対象者を絞る作業は必須であるといっても過言ではない。
情報セキュリティポリシーの策定の段階でこれが行われていると、スムーズに運用に入ることができるだろう。
情報セキュリティポリシーを策定する際に、ある程度、配布対象者(読者)のセキュリティレベルを意識して項目立てをしておくとよい。
例えば、同じパスワードの設定に関する規定でも以下のようなセキュリティレベルの違う内容を「パスワードの設定に関する基準」として1つの基準内に併記するよりも、視点を変えて2つの基準に分けてまとめる方が対象者の切り分けがしやすい。
さて、対象者を絞る作業も終わり、対象者全員に適切な内容の情報セキュリティポリシーが行き渡ったら、次にすべきことはユーザーが内容を読んでいるかどうかを確認する作業である。ここでは、配布した情報セキュリティポリシーの内容に対してユーザーの同意を得るという手段を用いる。
この作業を行うことによって、すべてのユーザーに情報セキュリティポリシーがきちんと行き渡っているか確認することができるし、管理者から積極的に「読みなさい」という指示を出すだけでなく、ユーザーが読まなければならないような状況をつくり出せるので有効である。何かに同意をするためには、基本的にはその内容を読まなければ始まらないだろう。ユーザーは内容を読んだうえで、自分に求められていることを理解し、同意できるかどうかを判断する。
もちろん、内容をよく読みもせずに同意してしまうユーザーも少なくないだろう。もともと、情報セキュリティポリシーに同意をさせるという考え方自体は、契約社会である北米を中心として起こったもので、サイン(同意)させて、破った者は即刻クビという発想に基づいて情報セキュリティポリシーの運用を行うことも不可能でないため、ユーザーが内容を読んでいようが、読んでなかろうが、とにかくサインさせることを運用サイクルの1段階として組み込んでいるようだが、日本ではそうもいかない。
日本社会においては、規則を破ったときに、その規則に同意をしているからといって、即刻処罰するといった処置が行えないのが通常だろう。このような現状の中で、同意させるという行為がどれほどの意味を持つのかという議論もあるが、同意させることの意味はこれだけではない。
同意をさせることは、情報セキュリティに関して「自分に責任がある」ということを意識させるきっかけになる。同意をしたからといって絶対ではないという認識が強い日本人でも、同意をする以上は自分にも少なからず責任があることを認識せざるを得ない。
実は、情報セキュリティポリシーの運用にはこれが非常に重要で、ユーザーの情報セキュリティに対する意識レベルを高めるための第1歩として強い意味を持つ。
このステップをもって情報セキュリティ教育の足掛かりとすることも不可能ではないだろう。
情報セキュリティポリシーの内容に対して同意を得るという作業は思うほど簡単ではない。十分にリスク分析を行って情報セキュリティポリシーを策定したつもりでも、現状にそぐわない規定が1つや2つ必ずあるものだ。また、セキュリティホールが発見された電子メールソフトウェアの使用を禁止するなど、セキュリティを考慮すると利便性を低下させてしまうということはよくある。このような規定に対しては、同意させようとした瞬間にユーザーからの強い反発を受ける。ユーザーにとってはいままで慣れ親しんできたものを突然禁止されたり、業務形態を変える必要が出てきたりして、不便を強いられるのだから無理もない反応だろう。
しかし、すべての現場の状況やこれまでの経緯を考慮に入れていては決められるものも決まらないし、ユーザーの不満をすべて聞き入れていては適切なセキュリティ対策は行えないだろう。初めが完璧ならそれでいいというわけではないし、初めから全員が同意する情報セキュリティポリシーの方が少ないので、完璧な情報セキュリティポリシーを策定することを目指す必要はない。
それよりも大切なのは、リスクとの兼ね合いを見ながら次のサイクルに反映させられるものは反映し、どうしても変更できない内容についてはユーザーの理解を得られるように、その規定を守らなければならない理由をより分かりやすく記述し直すなどの柔軟な対応を行うことである。
ただ押し付けるだけの規定では、同意はするが規定を守らないというユーザーを増やしてしまうことにもなりかねない。
また、ユーザーからの意見だけでなく、日々その形態を変え常に存在している情報セキュリティの脅威に対応するためには、情報セキュリティポリシーの内容を適宜見直し、変更する作業が必須となる。このステップは情報セキュリティポリシーを、より企業の実情と世の中のセキュリティ事情に近づけていく重要なステップである。
ユーザーから出た意見や、収集したセキュリティ情報を基に情報セキュリティポリシーの内容を変更したり、新しく規定を追加した場合は、その都度、追加・変更内容をユーザーに配布しなくてはならない。そしてその内容について再度ユーザーの同意を得なければならない。
情報セキュリティポリシーの運用中にも、社内の組織変更があったり、新手のセキュリティの脅威が発生したりと、状況はどんどん変化していく。その変化に伴って情報セキュリティポリシーの内容には必ず追加・変更作業が発生するので、最初に説明した情報セキュリティポリシー運用の一連の作業は、サイクルで果てしなく続くのである。
これから情報セキュリティポリシーを策定して、運用を行っていこうとお考えの読者の皆さんにとっては、始める前から気が重いことかもしれないが、情報セキュリティポリシーの運用は、その策定よりもはるかに障壁の高いものであることは間違いない。しかし、そのことを認識しておけば実際の取り組み方としてどこに比重を置けばよいのかなどの目安になるだろう。
次回は、サイクルを意識して運用を行うのに適した運用形態と、運用時に発生する問題点と、その対策などについて例を挙げながら解説する。
Copyright © ITmedia, Inc. All Rights Reserved.