仮想インシデント：Webサイトからの情報漏えいが発覚！？
「ユーザーから“御社から個人情報が漏れているらしい”との通報がメールであった。すぐに来てほしい！」
A社のIT担当Bは、マーケティング担当のC部長から緊急の呼び出しを受けた。彼らが運営しているのは製品のPRサイトで、構築・保守・運用管理に至るすべてが外部のX社に委託され、IT部門の管轄外に置かれていた。情報漏えいが本当ならば一大事、Bは現場に急行した。
Bが現場に到着したとき、C部長はすでに問い合わせをしたユーザの所在と連絡先を確認し、事情を聞き出していた。それによれば、1年ほど前に、サイトの「新商品に関するアンケートキャンペーン」に応じ、氏名やメールアドレスとともに回答を寄せたという。そのメールアドレスに対する迷惑メールやA社の競合からのセールスメールが最近になって急増、「もしや」と考えて問い合わせをかけたようだ。
実際、BがX社に調査を依頼したところ、1年前のアンケートに対する回答がそのままサイト上に残されていた。どうやら、アンケートを担当したA社の担当者が、キャンペーン終了後、アンケート用データベース（DB）から個人情報を消去するのを忘れていたらしい。しかも、その担当者はすでに会社を退職。周囲もそのミスに気づかなかった。加えて、X社によれば、A社から特に要請がなかったために、「キャンペーン期間中のサイトの正常稼働の確認」以上のことは行っていないという。つまり、稼働に直接かかわりのない脆弱性対策などは行っていなかったということだ。
Bは、その説明に憤りを感じつつもアンケート用DBを即刻停止させ、調べを進めた。結果、DBの情報全件分に相当するサイズのファイルが作成・削除された痕跡が発見された。つまり、システムの脆弱性が突かれ、アンケートで取得した情報が全件外部に持ち出された可能性があるわけだ。こうなれば、情報漏えいの可能性があることを公表するしかない。そう考えながら、Bは、IT部門で会社の全サイトのガバナンスを強化する必要性を改めて感じた。
CHECK-1 攻撃者はどこを狙うのか？
2016年上半期、インターネット上の情報を狙った公開サーバへの攻撃が日本で17件公表され、それらの合計で約172万8,000件の情報が漏えいした（公表データを基に、トレンドマイクロが集計）。2015年の1 年間で公表された公開サーバの情報漏えい事件は16件。つまり、2016年上半期だけで昨年の被害件数を上回っている。
この17件の公表事例のうち、47%に当たる8件は脆弱性に起因した被害だ（図1）。その意味でも、サイトの脆弱性を定期的に診断し、修正プログラムの適用に漏れがないようにしておくことは必須だ。
図1 公開サーバからの情報漏えい原因別割合
資料：2016 年上半期に公表・報道された公開サーバへの攻撃による情報漏えい事例の
攻撃手法割合／公表事例を元にトレンドマイクロが独自に整理
CHECK-2 収集した個人情報はどこにあるのか？
サイト上でアンケートキャンペーンなどを展開したのちに、取得した個人情報をサイト上に置いたまま、その存在を忘れてしまうケースは少なくないのではないか。個人情報の管理責任は取得した当事者（部門／組織）にあり、その当事者が消さないかぎり、個人情報はサイト上に存在し続け、漏えいの危険にさらされる。ゆえに、個人情報を収集した当事者は、収集情報を適宜サイト上から他の安全に場所に移すよう心掛けなければならない。
そもそも個人情報を取扱う組織であれば、こうした規程はあるはずだが、従業員への啓発など規程の形骸化を防ぐ働きかけが必要である。また、仮想事例のような一時的なWebサイトであれば、終了後すぐに閉鎖することをルールに盛り込むことで、情報漏えいリスクは低減する。
CHECK-3 サイトの“丸投げ”リスクは軽減されているか？
ビジネス部門がスピードを優先させ、サイトの構築・運用管理を外部のベンダーにすべて一任してしまうケースは珍しくない。ただ、そのスタイルを常態化させていると、IT部門は、自社のサイトがどんなプラットフォーム上に、どのような技術で構築され、いかなるポリシーの下で運用管理されているかが掌握し切れなくなる。したがって、サイトの外注を認めるにしても、外注時の契約条項・要件を定めてガバナンスを効かせるようにすることが大切だ。
実際、外注先と契約を結ぶ際、ビジネス部門は「外注先はプロ。何も言わなくても必要なセキュリティ対策は講じてくれるはず」と思い込み、セキュリティ対策に関する取り決めを明示的に結ばないことがある。この場合、何らかのインシデントが発生した際に、外注先の責任をどこまで追及すべきかの判断がつかなくなるおそれが強い。
また、ビジネス部門の多くは、公開サーバーの保護にどんな技術や対策が必要かを熟知しているわけではない。したがって、外注先で脆弱性対策が適切に行われるか、公開サーバーに対してIDS（侵入検知システム）／ IPS（侵入防止システム）／ WAF（Webアプリケーションファイアウォール）による防御が適用されているかを点検する、また点検を前提として契約させることも大切だ。
CHECK-4 事態把握・事後対応の仕組みとプロセスは整備されているか？
セキュリティインシデントをゼロにするのは難しいが、適切な対策を予め施すことで、発生確率や被害／影響範囲を最小限に抑えることは可能だ。例えば、公開サーバーへの攻撃は外部からの指摘によって気づくことが多い。このため、まずは自組織で早期に検知できる仕組みを導入する必要がある。ネットワークの入り口で不正検知するIDS/IPSのような製品を導入し、また万一侵入されたとしても、内部や出口のネットワーク上で不正を検知できる対策製品を導入することが有効だ。
組織的対策では、外部からの通報を受け付ける窓口を一本化し、窓口に寄せられた情報をどの部署の誰と誰に共有化させ、誰にどのようなアクションを取らせるか、また、サイトのサービス停止などの対応の判断をどのような意思決定のプロセスで下すかなどを取り決めておく必要がある。何らかの通報があった際に、システム的な事実確認の迅速化や被害の広がりを抑えるためのツールとして、EDR（Endpoint Detection and Response）のような製品も有効だ。
さらに、ビジネス部門のWebサイトは文字どおり事業に直結したサービスである。ゆえに、現場の担当者だけではサービス停止の良否は判断できず、最終的には経営層に判断を委ねることになる。その意味でも、事後対応の意思決定の体制には経営層をあらかじめ巻き込んでおくことが重要となる。
