ベネッセ 2014年委託先の社員による顧客情報の持ち出し

システムの開発と運用を担うグループ会社の業務委託先の社員が、顧客のデータベースから個人情報を抽出して業務用の端末に保存し、USB ケーブルで自分のスマートフォンへ書き出して名簿業者へ売った。書出し制御も通信量の警告も置いてあったが、どちらもこの経路には効いていなかった。

2014年9月25日にベネッセホールディングスが公表した、個人情報漏えい事故調査委員会の調査報告の公表版に沿って書いています。公表版は詳細な報告書の概要で、機密と捜査に関わる事項は除かれています。持ち出しが始まった時期、使われた端末とスマートフォンの機種、書出し制御の製品名は公表版に無い。再発防止策は2014年9月3日時点の対応状況として報告されたものです。

要点

漏れた個人情報は、延べ約2億1,639万件、重複を除いて約3,504万件、人の数で約4,858万人と認定された。
通った道は、データベースからの抽出、業務用の端末への保存、USB ケーブルでのスマートフォンへの転送、名簿業者3社への売却。
書出し制御は版の更新のあと、特定の新機種のスマートフォンを含む一部の外部媒体で効かなくなっていた。通信量の警告は、このデータベースとの通信を対象に入れていなかった。
付けた権限の見直しが定期に行われず、委託先の担当者がどの委託先の誰かを把握しないまま、広い権限を付けることがあった。
根本の直しは、委託先の担当者に個人情報を触らせず、分析用のデータベースに個人情報を持たせないこと。書出し制御、警告、監視はその上の網。

何が起きたか

図1 公表された経緯。持ち出しが始まった時期は公表版に書かれていない

日付	公表の内容
2014年6月27日	顧客からの問い合わせで、顧客の情報が社外に漏れている可能性を認識し、緊急対策本部を置いて社内調査を始めた[1]
7月7日	ベネッセコーポレーションからの漏えい情報と確認。危機管理本部を置き、外部の情報セキュリティの専門家を招いて、データベースの緊急対策と拡散の防止を始めた[1]
7月9日	記者会見。問い合わせの窓口を開いた[1]
7月15日	警視庁へ刑事告訴。外部の弁護士を委員長とする調査委員会の設置を決めた[1]
7月17日	警視庁が、システムの開発と運用を担うグループ会社シンフォームの業務委託先の元社員を、不正競争防止法違反の容疑で逮捕した[1]
7月22日から9月12日	調査委員会の調査。延べ63名の事情聴取、資料の分析、現場の検証[1]
9月17日	最終報告書を経済産業大臣へ提出[3]
9月25日	調査報告の公表版と再発防止策を公表[1]
9月26日	経済産業省が個人情報保護法に基づく勧告を出し、経済産業分野の個人情報保護ガイドラインの改正案を公表した[2]。IPA は同じ日に組織における内部不正防止ガイドラインの改訂版を公表した[3]
12月12日	改正したガイドラインを告示[3]

件数は、警察から鑑定のために渡された、名簿業者3社へ売られたとされるデータを分析したもの。延べ約2億1,639万件、全く同じ内容を除くと約6,984万件、氏名や生年月日で同一人物をまとめると約3,504万件、人の数で約4,858万人[1]。
延べ件数は売却で漏れた全部とは断定できないが、これを大きくは超えない可能性が高いとされた[1]。
勧告の事実と日付は、総務省と経済産業省の資料の記載による[2][3]。

通った道筋

図2 データベースから名簿業者までの道筋と、効いていなかった2つの仕組み

公表版の言葉では、元社員はデータベース内の顧客等の個人情報を抽出して、業務で使っていた端末に保存し、USB ケーブルで私物のスマートフォンへ転送して、その内蔵メモリに保存する等の態様で不正に領得した[1]。データベースは堅牢なデータセンターにあり、専用回線で執務室と結ばれていた。執務室は入館許可証で入退室を管理し、端末はワイヤーロックで持ち出せず、ファイル共有ソフトの導入と外部のオンラインストレージへの接続は止めてあった[1]。外から入る道と、物を持ち出す道は閉じていた。開いていたのは、正規の権限で読み、正規の端末に置き、端末の口から書き出す道である。

効いていなかった2つの仕組み

仕組み	設計	この件での状態
通信量の警告	端末とサーバーの間の通信量が閾値を超えると、データベースを管理する部門の部長へメールで警告する[1]	対象の範囲が明確に決められておらず、端末とこのデータベースとの通信が対象に設定されていなかった[1]
書出し制御	規程で外部媒体への書き出しを原則禁止し、仕組みでも止める。版の更新のたびに設定を見直していた[1]	版の更新の際に、特定の新機種のスマートフォンを含む一部の外部媒体で効かなくなり、元社員はそれを知って書き出した[1]

どちらも、作った時点の対象の一覧に頼る仕組みである。一覧に無いものは素通りし、一覧から漏れたことは誰にも知らされない。

悪い例。架空の監視の設定。対象を列挙し、新しいデータベースは手で足す

# alert-targets.yml  架空の例。名前と閾値は本物ではない
volume_alert:
  threshold_mb_per_hour: 500
  notify: dbadmin@example.com
  targets:
    - crm-db.example.com
    - billing-db.example.com
  # analytics-db.example.com は載っていない。載っていないことに誰も気付かない

直した例。個人情報を持つ印の付いた資源は、既定で対象に入る

# 対象を名前でなく属性で決め、外すときだけ理由と承認を残す
volume_alert:
  threshold_rows_per_session: 10000
  notify: soc@example.com
  targets: { tag: holds-personal-data }
  exclusions_require: [reason, approver, expiry]
  report_untagged_databases: daily

書出し制御も同じで、許す機器を列挙して他を全部止める形にし、版を上げたら新しい種類の機器で止まるかを試してから配る。端末に何も保存させない形にすれば、書出し制御に頼る範囲そのものが小さくなる。

どこで止められたか

図3 持ち出しが進む5段と、それぞれで止める仕組み

段	公表版で認定されたこと	止める仕組み
1 触れる	付けた権限の定期の見直しが行われていない状況が多く見受けられた。委託先の担当者が二次、三次のどの委託先の者かを把握せずに、広い権限を付けることがあった[1]	委託先の担当者には個人情報への権限を付けない。付けるなら業務ごとに短い期限で付け、定期に棚卸しする[1][4]
2 抽出する	データベース内の個人情報を区分して異なる権限を付けておらず、マーケティング分析の目的に照らした抽象化もしていなかった[1]	分析用のデータベースに個人情報を持たせない。持つなら区分ごとに権限を分け、1つの権限で読める範囲を絞る[1]
3 置く	抽出した個人情報を業務用の端末に保存できた[1]	シンクライアントにして、端末へデータを落とせなくする[1]
4 書き出す	書出し制御の版の更新で、一部の外部媒体への書き出しが止まらなくなっていた[1]	物理的な接続とテザリング等の無線の両方で、外部媒体を認識させない。更新のたびに新しい機器で試す[1]
5 続く	通信量の警告の対象から漏れていた。ログは取っていたが、不正を想定した定期の監視はしていなかった[1]	個人情報を持つ全部のサーバーと端末の通信を警告の対象にし、ログを定期に見る。通常の業務で使わない SQL の組み合わせも警告の条件にする[1]

1と2 触れる、抽出する。根本の段

3から5は、正規の権限で読んだデータが外へ出る口を1つずつ塞ぐ策である。口は、USB、テザリング、画面の撮影、印刷と、機器が増えるたびに増える。触れる人を減らし、触れても個人を特定できる形で読めなければ、どの口から出ても被害は小さい。公表版は、本番環境の個人情報を扱う保守と運用をグループ外へ委託せず、委託先の担当者からは個人情報への権限を外し、分析用のデータベースには個人情報を持たせない方針を示した[1]。

個人情報保護法25条は、個人データの取り扱いを委託するとき、委託先に必要かつ適切な監督を行うよう求める[5]。委託先が誰に再委託し、実際に誰がどの権限で触れているかを知らなければ、監督はできない。

4 書き出す。制御の更新

書出し制御は、版を上げたときに新しい種類の機器で効かなくなった。元社員はその事実を知って使った[1]。止める仕組みの更新は、それ自体が穴を開ける変更である。更新の後に、手元の新しいスマートフォンとテザリングで実際に書き出しを試し、止まることを確かめてから広げる。

公表版に無いこと

報道や解説では、スマートフォンの特定の接続の方式が書出し制御をすり抜けた、と説明されることが多い。2014年9月25日の公表版にあるのは、特定の新機種のスマートフォンを含む一部の外部媒体で書出し制御が機能しない状態が生じた、という記述までで、方式の名前は書かれていない。

5 続く。警告と監視

アクセスログと通信ログは自動で記録されていた。事故の後に検証はできたが、意図的な不正を想定した定期の監視はしていなかった[1]。気付いたのは顧客からの問い合わせだった。記録があっても、読む人と警告の規則が無ければ、知るのは外からの連絡になる。記録から警告と対応までの置き方は A09 セキュリティログとアラートの不備にある。

組織と意識

公表版は、システムだけでなく組織の問題も原因に挙げた。グループ全体の情報セキュリティの統括責任者と統括部署が無かった。組織再編で業務と責任が引き継がれないことがあった。システム会社が事業部門の意向に従わざるを得ず、事業効率と速さを優先した。役職員の多くが、社内の人間が悪意を持って大量の個人情報を持ち出すことはあり得ないと考えていた可能性が高い[1]。警告の対象から漏れたことも、書出し制御の穴も、誰の責任で確かめるかが決まっていなかったことと結び付いている。

守り方

根本の直し

委託先の担当者に、本番の個人情報への権限を付けない。付けるなら、業務ごとに期限の短い権限にし、期限で切れるようにする[1]。
分析や開発に使うデータベースには、個人を特定できる情報を持たせない。目的に要る属性だけにし、識別子は置き換える[1]。
個人情報は区分ごとに権限を分け、1つの権限で読める範囲と件数を絞る。対象単位で認可を掛ける考え方は A01 アクセス制御の不備と同じである。

緩和の策

端末にデータを置かせない。シンクライアントにし、端末に業務データが残っていないかを自動で探す[1]。
外部媒体は許す機器だけを通し、物理の接続と無線の両方で止める。制御の版を上げたら、新しい機器で止まることを試してから配る[1]。
警告と監視の対象を名前の列挙でなく属性で決め、個人情報を持つ資源は既定で入れる。対象から外れた資源を定期に一覧にする。A09 セキュリティログとアラートの不備
委託先と再委託先を契約で把握し、触れる担当者を事前に確かめ、年1回以上監査する[1][5]。
内部の者による持ち出しを、起こり得る具体的なリスクとして扱い、IPA の組織における内部不正防止ガイドラインで点検する[4]。

参照

個人情報漏えい事故調査委員会による調査結果のお知らせ、別紙調査報告の公表版ベネッセホールディングス、ベネッセコーポレーション、2014年9月25日
行政機関及び独立行政法人等が保有する個人情報の管理状況の点検調査結果概要総務省行政管理局、2014年10月。経済産業省の勧告とガイドライン改正案の公表の記載
個人情報の保護に関する法律についての経済産業分野を対象とするガイドラインの改正経済産業省商務情報政策局情報経済課、2015年1月、総務省のサイトに掲載
組織における内部不正防止ガイドライン IPA
個人情報の保護に関する法律第25条委託先の監督 e-Gov法令検索

ベネッセ 2014年 委託先の社員による顧客情報の持ち出し

要点