ホーム > WEBコラム

第12回WEBコラム「セキュリティポリシーの作られ方」

PCネットワークの管理・活用を考える会(大阪) WEBコラム

<著者略歴>
そのご苦労とノウハウ、笑い、叫び?を執筆された、「システム管理者の眠れない夜」連載をWindowsNTWorld誌(現在WindowsServerWorld)において1996年より開始。
現在も好評連載中であり、その人気から製本化・出版されております。
(株)クボタをご退社され、現在、大阪市立大学大学院 創造都市研究科 都市情報学専攻 博士(後期)課程にて日々研究に明け暮れる毎日。

はじめに

PCネットワークの管理活用を考える会/クライアント管理分科会、大阪座長の柳原です。

最近は日本版SOX法や新会社法への対応や、その一環としての情報セキュリティが議論されることが多いのですが、そうした議論の中でよく出てくるのが「セキュリティポリシーはつくったけれど、実際に守られてるのかどうか怪しい」という話題です。

今回は、セキュリティ対策の基本中の基本であるセキュリティポリシーについて、実効のあるものにするにはどうすれば良いかを考えてみたいと思います。

セキュリティポリシーの作られ方

ほとんどの企業では、1990年代後半からセキュリティポリシーを策定していると思います。情報システムそのものと、そこに流通・蓄積されている情報資産抜きでは、すでに業務が成り立たなくなっているのですから、この資産を守り、運用管理していくことは重要な経営課題の一つです。その課題に対する考え方が「セキュリティポリシー」です。

セキュリティポリシーは全社的な経営方針のもとで、セキュリティの目的、適用範囲、対象、教育、遵守すべき法律、罰則などが記述されているものですが、あくまでも基本的かつ簡潔明瞭に記述されます。とはいえ、どうしても抽象的な表現も多くなります。このため、社員がセキュリティポリシーを読んでも「要するに、何をすればいいのか?」という気持ちを持つでしょう。

もちろんポリシーだけでは、その解釈にもぶれが出ます。このため、現実のセキュリティポリシーは、三階層に作られるのが普通です。つまり、ポリシーの下にガイドラインを設け、ここでセキュリティを確保していくための具体的な手段を検討するためのレールを引くわけです。社内では、このレールに従って、具体的な行動マニュアルを作っていくことになります。実際に社員が頭にたたき込む必要があるのは、具体的な行動マニュアルです。

一般的に「ポリシー」は、セキュリティに対する取り組み姿勢や考え方を社外に対して表明するために、Webなどで公開されることの多い文書です(もちろん非公開の場合もあります)。これに対して、ガイドラインやマニュアルは、下手に公開してしまうと、これがセキュリティホールになりかねないので、通常は非公開です。

こうしたセキュリティポリシーは、日本の企業には横並び意識が強いために、所属している業界団体から要請があったり、同業他社がセキュリティポリシー(のポリシー部)を公開した時点で、慌ててトップダウンで作られることが多いようです。

公開されるポリシーは対外的な意図が含まれていますので、これがトップサイドで作られることはいいと思います。ガイドラインも、トップに近く、かつ社内の実情に明るい技術系スタッフが作成するのが普通ですから、これも内容が現実的であれば、それでいいでしょう。

問題は、一人一人の社員が実行しなければならないマニュアルをどうやって作り、社員に浸透させるかです。全社員に共通するような行動マニュアルは比較的容易に作成できるでしょうが、それだけでは必ず漏れが出てきます。現場ごとに仕事内容も、その環境も違います。マニュアルは具体的な内容であるべきで、現場を熟知している社員がガイドラインに沿って作成するのが一番です。しかしこれがなかなか進みません。

多くの情報システム管理者は、ここで悩んでいるようですので、私なりに考えている手順や注意点をお話しましょう。

三階層のセキュリティポリシー

セキュリティポリシーを傍観する人々の存在

まず最初に、書いている私も、読んでいる皆さんも頭を抱えるような話しから始めたいと思います。それは、ごく普通の社員は次のように考えている(場合が多い)、ということです。

  • 会社のトップが決めたことや、規則が実行不可能なことであっても「しかたがない」と諦めている。
  • 自分一人ぐらいは多少のルール違反をしても大丈夫と思っている。

おわかりでしょうか。起業したての小規模の会社でない限り、ほとんどの社員は「会社」という組織に対して、その大きさ(関わる人の多さ)や、その歴史(今までの経緯)を目のあたりにすると、どうしても「自分ひとりではどうにも変えられない」と思っているものなのです。それが「普通の社員」だと思います。

たとえば会社全体に行き渡っている規則などの場合、それが如何に「無理・無駄」に見えたとしても、変更しようとすれば多大な労力が必要になります。規則の修正プロジェクトを起案し、各部署から代表者を集め、議論した上で意見を集約し、共通項を探索しなければなりません。もちろん全部署の意見が一致するなどということは希ですから、各部署にはなんらかの妥協を求める必要があります。この作業は、部署数が増えれば増えるほど、気の遠くなるような作業になります。

もし、苦労の挙げ句に妥協点を見いだし、それを全社の規則に反映させることができたとしましょう。しかし話はこれだけでは終わりません。各部署はなんらかの妥協を強いられているのです。この妥協案をオフィシャルなものにしたとたんに、規則の修正プロジェクトは全社から怨嗟の的になります。特にプロジェクトリーダーは針のむしろに座らされた状態になるでしょう。下手をすると、全社からのブーイングによって左遷の憂き目にあうかもしれません。入社後何年かたつと、たいていの社員は社内のこのような構図が見えてきます。

ほとんどの企業の中にはこのような構図があります。このため、会社のトップから業務の変更を求められるような「セキュリティ対策」の指示が降りてきても、なかなか実行されません。酷い場合には、考えることすらされません。指示を聞いても、

「現実には、そんな細かい対策なんかできっこないじゃないか。それもしかたがない」

と諦めてしまうのです。そして、現実にはポリシーやガイドラインに反した仕事をしながら「自分ひとりぐらい大丈夫」と考えるわけです。

このような「あきらめ気分」が蔓延している会社では、トップ方針を出したとしても、実際には実行出来るマニュアル、すなわち、現場に適合したマニュアルの作成は望めないでしょう。もしマニュアルが作成され、実行されたとしても、それは表面的なものに限られるでしょう。すなわち、セキュリティポリシーが出されても、それは傍観されるだけに終わる可能性が高いのです。

自律的なセキュリティ体制のために

セキュリティポリシーが、一般社員から他人事のように傍観されている状態では、有効なマニュアルを作成することは難しいと思います。これをなんとかしなければなりません。本来ならば、セキュリティ対策の第一線である社員が、自らの手で自らの情報を守るためのマニュアルを作ることが一番なのです。

このためにはまず、マニュアルを作ることを目的とするのではなく、セキュリティの重要性を自ら学び、自ら対策を考えるグループを作ることです。このグループの大きさは、数人程度が良いでしょう。職場に別目的のグループ(例えばコストダウンなど)があれば、それをそのままセキュリティを考えるグループにしてもいいと思います。このグループのアウトプットとして、マニュアルを位置づければ良いと考えています。

この程度の小さい集団では、一人一人の意見が生きてきます。つまり各人がグループの意志決定に対して、効力感を味わうことができます。言っても無駄、という意識は少なくなってくるはずです。このような小さなグループを多数作り、各人が自分の問題としてセキュリティを考え、行動を決めていくことが大切です。すなわち、これが自律的なセキュリティ体制作りの、第一歩となるでしょう。

そして、ここで作られたマニュアルは、イントラネットなどを使って企業内に公開します。各グループは、他のグループがどのようなマニュアルを作っているのかを相互に確認できるようにするのです。これはグループ間の学習につながるでしょう。

しかし、このままでは問題があります。各グループが作り出すセキュリティのマニュアルには、セキュリティの専門家の目から見れば抜けがあったり、誤った対策もあり得るからです。

よって、各グループが作ったマニュアルを吸い上げ、チェックし、アドバイスを出す役割が必要です。これには、ガイドラインを作ったメンバーが最適です。マニュアルがガイドラインから逸脱していないかどうかをチェックしやすいからです。また、マニュアルには現場の意見が盛り込まれているはずですから、ガイドラインの見直しにも役立つでしょう。

この見直しを行った結果として、ガイドラインに適合し、同時に社員が納得できるマニュアルができあがるはずです。

こんなやり方では、社内に多数のマニュアルができてしまって、収拾がつかないのでは?と思う方もおられるでしょう。しかしこれは程度問題だと思います。どのような作り方をしても、全社で一つのマニュアルで済むわけがないのです。それでは必ず漏れが生まれ、同時に傍観してしまう社員が生まれるのです。それよりも、数は多くても生きたマニュアルの方が良いと思いませんか?

ほとんどの人は、自分で作り、周囲に宣言した決まりは守ろうとするものです。他人の作った決まりは傍観されやすいものです。このあたりの人の気持ちを生かした、自律的なセキュリティ体制を作ることが大切だと、筆者は考えています。

自己紹介

パーソナルコンピュータとの付き合いは1979年のNEC社製PC-8001から始まっています。
1985年から当時はオフコンと呼ばれていたIBM社のシステム36を使って、機械製造メーカでの社内用生産管理システムの構築に関わりました。言語はRPGでした。 1990年ごろから社内にパソコン通信やLANを導入してきました。この頃からネットワーク上でのコミュニケーションに関わっており、1993年以降はインターネットとWindows NTによる社内業務システムの開発、運用を行ってきました。
1996年からはインターネット上でのコミュニティであるNT-Committee2に参加し、全国各地で勉強会を開催しています。
http://www.hidebohz.com/Meeting/
1997年からはIDGジャパンのWindows NT World誌に「システム管理者の眠れない夜」というコラムの連載を始めました。連載は既に7年目に突入し、誌名は「Windows Server World」に変わっていますが、読者の皆さんに支えられて今でも毎月、締め切りに追われる日々が続いています。
連載から生まれたメーリングリストもあります。ご参加はこちら。お気軽にどうぞ。

「システム管理者の眠れない夜」イメージ「システム管理者の眠れない夜」イメージ

Copyright 2006 Hideki Yanagihara All Right Reserved