弱点その(1)―反発

 売りばかりなら文句はないが,現実にはそうではないことも多い。セキュリティ・ポリシーを宣伝しなければならない立場としては,宣伝する相手からの反論にも立ち向かわなければならない。相手はこちらの弱点を突いてくる。

 では,セキュリティ・ポリシーの弱点は何だろうか。ポリシー導入以前の状況をネガティブではなく,ポジティブにとらえてみる。例えば,ポリシー導入以前はWebブラウジングでショッピングしたり,自分の趣味の情報を漁ったり,掲示板の閲覧やチャットをし放題。メールも私信が飛び交い,メッセンジャ・ソフトも使い放題。もちろん,仕事の能率について厳しくチェックされるため,そんなことばかりしてもいられない。遊んでばかりだと仕事の評価も下がってしまう。それより集められる情報を積極的に利用した方がよほど自分のためになるし,これだけ情報を気にせず自由にやり取りできると,今までにできなかったような仕事の応用や展開ができる。インターネット万歳!…。

 このような自由を謳歌していた素晴らしい世界に,暗黒のルール「セキュリティ・ポリシー」が持ち込まれたらこうなるだろう。「何だか分からないが,Webの閲覧をコンテンツ・フィルタとか言うばかげたソフトで制限しやがった。おかげで全くまっとうな情報源にすらアクセスできないことがある。その度にいちいち申請しなければならず,理由や目的まででっち上げないとならない。情報収集のためという理由じゃ弱い,と文句を付けられるし。メールも情報漏洩フィルタとかで制限され,ちょっと添付ファイルを付けて出すと警告される。顧客の情報に絡んだところは,メールでやり取りするのにもどうかすると許可がいる。メッセンジャ・ソフトなんて,電話でもなくメールでもない微妙な連絡や相手がいるかどうかの確認に便利に使っていたのに,これは全面的に禁止。ちょっとした書類を作って配るときも,いちいち管理基準に照らしてびくびくしながら配布しなきゃならないし。ああ,それにしても何でこんなに面倒な世の中になってしまったのだ…」。

 いささか誇張し過ぎかもしれないが,当たってないわけではないだろう。自由,特に責任の所在があいまいな中での自由に対して制限を加えることは,頭で理解していたとしても感情的に納得できないことがある。そうした,いわば反感を持って新たなルール体系に対峙するとき,どうしてもアラを探す目になりがちだ。理屈では「理由」や「目的」を書き込んだ「申請」が必要だと分かっている。そもそも,そういう管理がされていないことがおかしなことだとも理解している。しかし,「ただでさえ忙しいのに,このうえ何でそんな手間を増やすのだ」と言いがかりをつけたくなるのだ。この感情的反発,これがセキュリティ・ポリシーの一つの弱点だと言えるだろう。

弱点その(2)―利己主義

 もう一つは,よくある利己主義的な思想である。例の「自分だけは大丈夫」という根拠のない自信だ。

 いったいどんな論理からそうなるのか全く分からないが,なぜか「自分だけは大丈夫」と思ってしまう人は多い。その人に言わせると,「自分だけは多少ルールをはみ出しても大丈夫」ということになり,せっかくリスクを避けるような手順を考えているのにもかかわらず,その手順をサボタージュしたり,その手順と異なる自分のやり方を押し通してしまったりする。いわゆるエライ人に多いタイプだ(もちろんエライ人だけではない)。

 「ごみはきちんと捨ましょう」とか「会議室でタバコ吸うのはやめましょう」という類の,それほど実害はない会社の規則のようにセキュリティ・ポリシーをとらえてしまうことが原因なのだろうか。多少はみ出ても問題ないとばかりに,こういうエライ人は平気でルールを無視する。こういう態度も,セキュリティ・ポリシーに限らず,一般的な規則が内包する弱点だと言えるのではないだろうか。

弱点その(3)―技術力

 「リスクを拾いきれるかどうかは,使う人や作る人の技術力次第」という問題もある。「BS7799やISMS認証を受けました。PDCAサイクルを回してセキュリティ・レベルも維持しています。でも,Webサイトのアプリケーションにクロスサイト・スクリプティングのバグを作り込んでしまいました」とか,「セキュリティ・ポリシーも作って,ガイドラインに基づいてサイト構築しましたが,ファイアウォールのポリシーに弱点を作ってしまい,リバースtelnetで攻撃を仕掛けられてしまいました」などの問題のことだ。ガイドラインや手順,ルールを作るときに,技術的な目配りを効かせていないとこうなる。

 あるいは,「アウトソース契約を結ぶときのガイドラインを作り,それに沿って契約を結んだのに,情報漏洩されても責任を問えなかった」とか,「年賀状のために住所録を作ったが,見事にそれを漏洩されてしまった。しかしポリシー上,住所録は規定の範囲を外れていたために,やはりこれも責任を追及できなかった。それどころか住所録に載っていた1人がストーカ被害に遭い,会社が被害者から民事で訴えられてしまった」とかいう事態も起こり得る。

 こうした事例は,作成したルールや手順を法律に照らして,問題や抜けがないかを確認しておけば,防ぐことができたものだ。問題が起こったときでも訴えられないようになっているのか,訴えられたときでも法的に有効な証拠が揃えられるような手順・ルールになっているのか,といった法律面での技術的目配りである「法的準拠」の視点が欠けているために,生じた抜け穴だと言えるだろう。結果として「ルールは作ったけど,効き目がない」などと言われてしまうことになる。

 この辺りが,いわゆる弱点になるだろうか。

園田 道夫 Michio Sonoda

筆者は情報処理推進機構(IPA)の脆弱性分析ラボ研究員,および日本ネットワークセキュリティ協会(JNSA)の研究員を務める。JNSAではハニーポットワーキンググループ,セキュリティスタジアム企画運営ワーキンググループのリーダーとして活動している。MicrosoftのSecurity MVP。現在セキュリティ夜話(http://www.asahi-net.or.jp/~vp5m-snd/sec/),極楽せきゅあ日記(http://d.hatena.ne.jp/sonodam/)にて連続的に読み物掲載中。