最終的には人の判断が大切

　多機能、高性能のセキュリティ機器は便利ではあるが、ユーザーがそれを購入して安心している状態が実は一番危うい。ポリシーがない状態で万一何か新しいセキュリティ侵害が発生しても、その機器だけでは何もできないだろう。情報漏えいが発覚した企業の責任者は、メーカーかシステムインテグレーターを呼び付けて責任転嫁をするかもしれない。しかし、事はさらに重大である。

　一度セキュリティの侵害を受けると、多くの企業はセキュリティを強化する方向に向かう。ただし、それは逆に利便性を犠牲にすることになる。インターネットからの情報収集が制限されると、営業業績に何らかの影響が出ないとは限らない。またそうであれば、ユーザーは情報収集のために別の手段を取る可能性もあり、それがバックドアになりかねない。

　また、セキュリティ機器に振り回されないことも重要である。高機能になればなるほど雄弁、つまり頻繁に警告を発するようになるからだ。それらの警告にいちいち反応していたのでは、ほかの業務に支障を来すかもしれない。かといって、警告を寓話のオオカミ少年のようにないがしろにすれば、本当の危機に対応できないだろう。最後は人が判断をした方が賢明である。そのためにも、事前にセキュリティポリシーを作成しておくことがなおさら必要になる。

セキュリティポリシー、理解していますか？

　『セキュリティポリシーのつくり方』なる指南書が仮にあったとしても、そのようなものに惑わされることはない。セキュリティポリシーは、それぞれの企業に合ったものを作成していけばよい。

　まずは第一の目的を「書き上げること」としよう。そして、文書として保存することが必要である。労力ばかりが掛かって誰も顧みない文書になるのではないかと懸念を抱く人もいるかもしれない。しかし、まずは始めてみること、書き切ることが重要なのである。その答えは、以下を読めば見えてくるだろう。

　次の文を読んでみていただきたい。

　実は、上記はすべて間違いである。なぜ間違いなのか次に考えてみよう。

セキュリティポリシーをつくる目的

　まず1について。セキュリティポリシー作成の目的は、事業活動に支障を来さないこと、つまり安全に事業を行えるようにすることである。ファイアウォール、IPS（侵入防止システム）、アンチウイルス、バックアップ、冗長化など、ネットワークを安全に保つこれらのシステムは、セキュリティポリシーから導かれる手法にすぎない。セキュリティポリシーは、事業を安全に行うために必要なセキュリティ機器を、どこに、どのように、そして誰の管理の下に配置するかを記述しなければならない。

ポリシーは簡潔に！

　2は、まったく逆である。セキュリティポリシーは、細かく長々と書かれれば書かれるほど複雑なものになり、結果として脆弱なものになる。一般に「複雑さとセキュリティは反比例する」といわれるように、複雑なシステムは簡潔なシステムより脆弱になる傾向がある。つまり、複雑なポリシーはそれを守ることが面倒になりがちなため、果てはまったく無視されるという事態を招く。

　簡潔なセキュリティポリシーを作成するには、質疑応答形式で記述するとよい。なぜなら、特定の問題に簡潔に答えを出せるからだ。用途や役割に応じて質疑応答形式の記述をまとめることで、矛盾なく簡潔に構成することができる。社員に「読む」努力、「理解する」努力、「覚える」努力を強いてはならない。決して学術論文を作成してはならないのである。誰もが読めて、理解できるものが必要だ。

完ぺきなセキュリティポリシーはない

　3の100％完全なセキュリティポリシーを作成するために努力することは、多くの場合無駄である。それよりは、今できることを基に、たとえそれが不完全なものであっても、セキュリティポリシーを書き上げることを優先すべきだろう。

　しかし、このことは多分、想像以上に難しいだろう。特に日本の「根回し」の慣習、つまり、できるだけ完全なものを作り上げ、関係者に根回しをして事を進める慣習において、時間と労力をかけて決めたことを途中で変えるのはそう簡単にはいかない。

　一方、米国では一般に、ポリシーの大体の方向性を決めてからつくり始める、途中で問題が発生した場合は適宜方向修正をする、という進め方に慣れている。すべてのプロジェクトについて米国式の進め方に有利性があるとは思わないが、ことセキュリティポリシー作成については米国の方式に分があるようだ。なぜなら、インターネットの進化は終わったわけではなく、常に新た試練に対処する必要に迫られるからである。

　企業慣習ひいては社会慣習を変えることは並大抵のことではない。しかし、セキュリティポリシー作成に限っては、その努力をしてみる価値は大いにある。

ポリシー変更をためらってはならない

　4のセキュリティポリシーの変更は脆弱性をつくる、という考えは誤りである。確かに、セキュリティポリシーを運用していくと、利便性が損なわれ、一部のユーザーから元の甘い管理に戻してほしいという要望が出る。それに応えて元に戻すと、脆弱なシステムになってしまう。かといって、かたくなに変更に応じないでいると、彼らは相談さえしなくなり、迂回（うかい）路を設けるなど、自分たちだけのポリシーをつくってしまう。

　運用に支障が出た場合には、変更することにちゅうちょすべきではない。ただしそれは、新しいセキュリティポリシーの“創造”であるべきだ。セキュリティと利便性の間のどこかに妥協点を見つけて、ユーザーに納得してもらう努力をしなければならない。また、新たな脅威の発生によってセキュリティポリシーを変更しなければならない事態は、今後も継続して起こるだろう。その場合も同様に、ユーザー側の要件とすり合わせ、その着地点を模索する努力が求められる。

　さて次回は、こうしたポイントを踏まえながら、実際にポリシーを一から作成してみよう。