1999年11月に「Webがクラッキングされているのを発見したら」という記事を,ITproの前身であるBizITサイトに掲載した。


 深夜に,自社のWebサイトにアクセスしてみたら,クラッキングなどによって,サイトがひどい状況になっているのを発見した。さて「あなたはどうしますか?」

 あれから7年余り経ち,Web2.0が叫ばれるようになった。Webの使われ方が大きく変化している今,同じテーマをあらためて考えてみたい。

 Webサイトに,変な画像が張ってあったり,ふざけた文章に書き換えられているのを深夜発見したとしよう。Webサイトの用途や書き換えの程度によるが,それくらいならば,ひょっとしたら“恥ずかしい”で済ませられるかもしれない。翌朝,システム部門などに連絡すればいい。しかし,内容によっては恥で済ませられない場合もある。たとえば,製品やサービスを紹介するページで仕様が変更されていたり,ショッピング・サイトで価格を書き換えられていたりという場合だ。こうなると直接的なダメージを被る。さらに,ユーザーに個人情報を登録してもらうサイトで,登録された個人情報が外部から見える状況になっていたら・・・。

 社員が直接発見しなくても,取引先や知人などから「あなたのところのWebサイトがとんでもないことになっている」という連絡が来ることもあり得る。掲示板に自社サイトで発生している問題が書き込まれているかもしれない。自分自身が“社内での”第一発見者になる可能性もある。

セキュリティ上の防御策を強化しても・・・

 セキュリティ対策といえば,まずクラッキングなどの攻撃を防ぐための対策に重点が置かれる。セキュリティ・ホールなどの情報を収集,対処したり,セキュリティ強化ツールを導入したりする。しかし,いくら対策を立てても,すべての攻撃を完全に防げるわけではない。

 問題が発生しても,昼間ならシステム部門に連絡すればなんとかなるだろう。しかし,深夜の場合はそうはいかない。システム担当者に電話すべきなのか。その問題の“深刻さ”程度によっては判断に困る。そもそも,だれに連絡したらいいのかさえわからないという可能性もある。

 セキュリティ・ポリシーを定めている企業は着実に増えてきているものの,まだ半数以下である。NRIセキュアテクノロジーズが2006年5月に実施した「企業における情報セキュリティ実態アンケート調査」によると,セキュリティ・ポリシーを策定している企業は43.7%にとどまる。さらに,そのうち,「セキュリティ事故発生時に対応に関する規定」がある企業は46.5%,「事業継続計画」がある企業は17%にすぎない。クラッキングを見つけたとしても,対応をセキュリティ・ポリシーにきちんと規定してある企業は少ない。

原因はクラッキングとは限らない

 Webサイト上で発生するトラブルは,クラッキングが原因とは限らない。コンテンツの作成ミス,あるいはプログラムのミスによっても問題が起こる。むしろ,外部からのクラッキングよりも,こういったミスによって発生する問題のほうが多いだろう。いまではWebの活用が進み,コンテンツの更新や新機能の追加が多く複雑になっている。ミスが発生する可能性は,以前より高くなっているとも言えるだろう。

 こうなると,「クラッキング→セキュリティ・ポリシーに沿って行動」ではなくなり,トラブル対策という通常の業務の範ちゅうに近くなる。つまり,社内のほかの部署が担当している業務での問題を発見したのと,ほぼ同じ状況である。

 それにWeb2.0といわれるように,サイト/サービス間の連携やユーザー参加型などが事態を複雑にする。たとえば,地図を提供するサイトとレストラン情報を提供するサイトが連携して,レストラン・マップ・サービスを実現しているとする。このような場合にWeb上のサービスで問題が発生すると,どうのように解決すべきか社内だけでは判断や対処できない可能性が出てくる。

 ユーザー参加型では,ユーザー自身がコンテンツを投稿したりするため,サイト運営側ではコントロールしきれない面も出てくる。また,ユーザー参加型の多くは,登録制を採っており,個人情報を記録している。一般のサイトでも,メール・マガジンを届けたりするため,登録制を採用するところが増えている。つまり,ひとたび何かの問題が発生すれば,個人情報が漏れるという可能性が高くなっている。

Webサイトを停止させていいのか

 Webサイト上で問題を発見したら,だれに連絡したらいいのか。セキュリティ関連の問題なのか,あるいはコンテンツやサービス上の問題なのかによって連絡先が異なるのか。連絡を受けた管理者は,具体的に,どのように行動したらいいのか。

 とりあえず,Web上のサービスを停止させるべきか,それともサービスは続けたまま,該当ページを削除,あるいは修正すればいいのか。そのサイトが提供しているサービスと発生した問題の内容によって,判断は異なってくる。よかれと思ってサービスを停止させたとしても,あとで社内の関係部署からクレームが来たのでは立つ瀬がない。さらに,ほかのサイトと連携してサービスを提供している場合は,社外との関係も考えなければならない。

 こうなると,たとえシステム部門など特定の部署と連絡が取れたとしても,その部署や担当者だけでは判断できない。社内の関係部署,連携するサービスの責任者などをリストアップしておき,すみやかに連絡,相談できる体制を構築する必要がある。対応方法を迷っているうちに,被害は大きくなっていく。被害を最小限に抑えるためにも,事後の対応を整理し,それをエンドユーザーにも周知徹底しておきたい。

 このようにいろいろと考えてみると,自分自身の周りを見てもまだ甘いところがある。セキュリティ・ポリシーの策定など,7年前に比べれば格段に改善されているのは確かだが。

 運営する側にしてみれば「24時間365日営業」の難しさを主張したいが,利用する側に立てば「いつでも利用できるのが当たり前」のWebサイト。困ったものである。