2万9,465人。ベネフィット・ワンの業務委託先のシステムから、個人情報が漏れた優待サービス「トク買」の会員の数です。
トク買はクレディセゾンの会員向けのサービスで、システムを運用していたのは委託先のフォレステックでした。ベネフィット・ワンが10月28日に明らかにし、同じ日にクレディセゾンもカード会員向けのお知らせを出しています。
情シスの目で見ておきたいのは、会員の情報とは別に、ベネフィット・ワンが決済システムとつなぐための認証関連情報の一部も、委託先から漏えいしたおそれがあることです。
報告は3回に分かれた
ベネフィット・ワンの公表の経緯。委託先からの報告は3回に分かれた出典: 株式会社ベネフィット・ワン「当社業務委託先への不正アクセスによる提携先会員の個人情報漏えいに関するお詫びとお知らせ」(引用)
10月14日の13時45分に始まった不正アクセスに、委託先が気づいたのは7日後の21日でした。ベネフィット・ワンが最初の報告を受けたのは、その日の11時40分です。同日17時にトク買を止め、23日に個人情報保護委員会へ速報を出しました。
ただ、話はそこで終わりませんでした。フォレステックは24日から25日にかけて、21日の時点で把握していなかった不正アクセスを追加で見つけ、25日に2回目の報告を出しています。
26日には、ベネフィット・ワンが被害の拡大を防ぐため、決済システムとの連携に使う認証関連情報を変えました。その認証関連情報の一部が漏えいしたおそれがあると分かったのは、翌27日19時の3回目の報告です。
鍵を替えたのが、漏えいのおそれが分かる前日だったことになります。28日には、この変更で、今はこの経路から不正な処理ができない状態だと確認したとしています。
詳しい原因は、10月29日の時点で調査中です。
漏れたのは会員の情報と、決済につなぐ鍵の一部
漏えいした項目は、次の3つに分かれます。
| 区分 |
項目 |
補足 |
| 会員の情報 |
氏名、フリガナ、生年月日、性別、郵便番号、メールアドレス、お客様番号、入退会情報 |
登録の内容によって人ごとに違う |
| 決済に使う番号 |
会費を集める決済処理に使う管理番号 |
会員の情報と決済の情報を結び付ける番号で、クレジットカード番号ではない |
| ベネフィット・ワンの情報 |
決済システムとの連携に使う認証関連情報の一部 |
漏えいしたおそれ。10月26日に変更済み |
対象には、退会した会員も一部含まれます。人数は調査を続けていて、今後変わる可能性があるとしています。
管理番号と認証関連情報を組み合わせると、会費の決済で不正な処理ができるおそれがありました。もっとも、この決済システムはトク買の会費を集めるためだけのもので、クレディセゾンは、第三者への送金や他人の口座へ資金を移すことはできない仕組みだと説明しています。14日から26日の変更までの期間に、不正な決済処理は見つかっていません。
クレジットカードの番号、有効期限、セキュリティコードは、ベネフィット・ワンも対象のシステムも持っていません。カードの情報は決済代行事業者が管理していて、そこには不正アクセスが及んでいないとしています。クレディセゾンが管理するシステムから漏えいしたものでもありません。
決済代行に入るための鍵が、福利厚生の会社のさらに先の委託先に置かれていた。今回の件でいちばん考えさせられるのは、この点です。カードの番号を持たない作りにしていても、連携の鍵が外に出れば、会費の決済という限られた範囲では悪用の余地が生まれます。
対象になる人と、確認が要る会社
- トク買に登録していた会員が対象です。退会した人も一部含まれます。ベネフィット・ワンやクレディセゾン、委託先を名乗るメール・電話・SMSに注意が要ります。ベネフィット・ワンは、会員にクレジットカード番号やパスワードを尋ねることはないとしています。
- セゾンカードを持っていても、トク買に登録していない人は対象外です。漏えいはトク買のシステムからで、クレディセゾンのシステムからではありません。
- 確認が要るのは、福利厚生や会員向けの優待のサービスを外の会社に任せている会社です。今回の発表の対象はトク買だけですが、契約の相手のさらに先に、システムを運用する委託先がいる形は珍しくありません。
ベネフィット・ワンは9月30日にも、別の件を公表していました。設定の不備で、ほかの会社の従業員の情報が見える状態になっていたもので、9月末からの情報漏えいの一覧に載せています。今回の不正アクセスとは、原因も対象のサービスも違います。
総務・人事と委託先に確認すること
- 社員向けの注意を出します。トク買を使っていた社員には、ベネフィット・ワンやセゾンを名乗るメールのURLを開かず、カード番号やパスワードを入れないよう伝えます。対象かどうかの問い合わせ先は、ベネフィット・ワンのメール窓口です。
- 福利厚生や優待のサービスの契約を、総務・人事と一緒に一覧にします。契約の相手だけでなく、システムを運用している会社がどこかまで、契約書や委託先の一覧で確認します。
- 外部のサービスに預けている、決済や連携のための認証情報（APIキー、トークン、接続用のアカウント）を洗い出します。どの委託先のどのシステムに置かれ、誰が替えられるのかを台帳に書きます。
- 委託先から事故の連絡が来たときに、漏えいが確定する前でも連携の認証情報を替える、という手順を決めておきます。今回は、ベネフィット・ワンが26日に替えていたことで、27日に漏えいのおそれが分かった時点では、その経路はすでに閉じていました。
- 委託先の事故は、第一報で範囲が決まらないものとして扱います。追加の報告を受け取る窓口と、社内に知らせ直す担当を決めておきます。
委託先の事故が、報告のたびに広がる例は、この秋に続いています。メール配信のユミルリンクの件も、第一報のあとに対象が大きく増えました。鍵を替える判断を、確定の報告まで待たない。ベネフィット・ワンの26日の動きは、委託元の側で取れるいちばん早い手でした。
