ピックゴーへの不正アクセス 出前館は連携を止め、7NOWは16万件超

自社の分は漏れたのか。ピックゴーで配送を頼んでいる会社は、CBcloudが公開した発表を読んでも、その答えを出せません。11月3日の第2報は流出した可能性がある項目を並べたものの、「個社ごとに範囲が異なります」とし、件数も導入法人名も出していないからです。

数字を出したのは影響を公表した委託元の2社です。セブン‐イレブン・ジャパンは同じ日に、デリバリーサービス「7NOW」で注文した人の名前（カナ）16万4,180件などが第三者に取得されたと公表しました。出前館も、注文者の名前799件などが取られたと明かしました。

どちらも配達業務の一部をピックゴーに任せていた会社で、発表の形もよく似ています。それでも、件数の数え方、本人に知らせる手段、ピックゴーとの連携を止めたと書いたかどうかが違いました。

CBcloudは「可能性」、委託元は「確認」と書いた

CBcloudが第三者による不正アクセスを確認したのは11月1日（日）で、対象はピックゴーの法人向けサービスでした。不正アクセス元との通信を断ち、不正に利用されたアカウントを止め、悪用された不具合を修正したと、翌2日の第1報で知らせています。日本国外からのアクセスは、3日の第2報の時点でも一部を制限したままです。マルウェアなどの感染や混入がないことも確認したといいます。

第2報が挙げた項目は、荷主の会社についてのものと発注情報に分かれます。荷主の側は法人名、登録した担当者の氏名、登録した住所、電話番号、メールアドレス。発注情報には案件ID、案件金額、集荷先と届け先の名称や住所、担当者の氏名、電話番号が並びます。案件を運んだパートナードライバーについても、氏名、電話番号、メールアドレス、車両番号、配送中の位置情報が入りました。

銀行口座やクレジットカード番号などの決済情報は取得されておらず、ログインパスワードも流出の対象外だと、CBcloudは明記しました。

ただ、言葉の強さは違います。CBcloudの2つの発表は、どちらも「流出した可能性」どまり。一方の7NOWと出前館は、CBcloudの調査により「第三者に取得されたことが確認されています」と伝えました。つまり委託元には、公開の発表より一歩進んだ答えが個別に届いているとみてよいでしょう。

アカウントの説明にも、ずれがあります。CBcloudと7NOWは「不正に利用されたアカウントの停止」、出前館は「不正に作成されたアカウントの無効化」です。攻撃者が既存の荷主アカウントを乗っ取ったのなら、各社がアカウントをどう管理していたかが問われます。でも、攻撃者が新しく作ったアカウントで他社の案件まで見えたのなら、問題はサービス側で権限をどう分けていたかで、委託元の設定では防げません。

どちらなのか、両方なのかは、侵入経路や不具合の中身、法人向けのどのサービスが対象かと合わせて、まだ発表がありません。

同じ形の発表で、数え方と止め方が違う

2社の発表では、「当社のシステムへの影響」「二次被害の防止について」と節の見出しまで同じです。「CBcloudの調査では、当社の認証情報や連携設定の流出・書き換えは確認されていません」の一文は、一字一句そろっていました。CBcloudが調べて伝えた答えを、2社がそのまま載せたのでしょう。

プレステージ・コアソリューションの件では、同じ日に出た委託元4社の発表が、言葉も項目もそろいませんでした。形がそろっている今回は、そのぶん違いが目に付きます。

まず件数です。7NOWは項目の組み合わせで区分を分け、出前館は項目ごとに数えました。7NOWの3つの区分を編集部で足すと16万9,151件ですが、7NOWは合計を示しておらず、区分が重なるかどうかにもふれていません。出前館の799件と794件はほとんどが同じ人とみるのが自然で、足せば実際より多く見えてしまいます。

住所まで取られた人の割合は2社でまるで違います。区分が重ならないとすれば、7NOWで住所を含む2つの区分を足した4,971件は、全体の3%ほど。出前館は名前799件、住所794件です。

差の理由はどちらの発表にもありません。委託元ごとにピックゴーへ渡す項目が違うのか、取られ方が違うのか。CBcloudが「個社ごとに範囲が異なります」と断ったのも、この差と関係がありそうです。

出前館の「注文メモ」も、情シスなら見過ごせない項目です。自由に書ける欄には、建物への入り方や家族の事情のように、決まった項目にない情報が入ることがあります。自社が配送の委託先に送る欄に、こうした自由記入の欄がないか。次に契約を見直すとき、確認しておきたい点です。

出前館は、修正の完了まで連携を止めた

出前館は11月2日に連絡を受け、「被害の拡大を防ぐため」同日14時過ぎにCBcloudとの連携を止めました。再開は21時ごろ。CBcloudが不具合の修正を終えたことを確認し、自社側の通信状況を見てから戻しています。止めていたのは7時間ほどです。

7NOWの発表には、連携を止めたという記載がありません。ただ、7NOWが自社の分を知らされたのは11月3日で、出前館が修正を終えたと確認した翌日です。同じ日に同じ判断が要ったとは限らず、2社の対応の良し悪しは比べられません。

出前館が書いた再開の条件は、ほかの会社でもそのまま使えます。委託先が修正を終えたことと、自社側で通信を確認したこと。この2つがそろうまで止めておく、という順番です。

再開の条件が「アカウントの停止」でなく「不具合の修正」だった点も、筋が通っています。プレステージの件では、不正に使われた認証情報を無効にしたあとも不正アクセスが続き、翌日にシステムを止めました。アカウントを止めたことだけを理由に戻していたら、同じことが起きたおそれがあります。

アララメッセージの件では、運営会社が全サービスを止めるまでの3日間に、契約企業の環境からデータが持ち出され、偽メールも送られ続けました。委託先が止める範囲を決めるのを待たずに、委託元が自分から連携を切れるか。その判断をだれが、どの条件で下すかは、事故の連絡が届く前に決めておかないと間に合いません。

人数が少なくても、委託元は報告する

個人情報保護委員会のガイドライン（通則編）では、委託先で起きた漏えいも、原則として委託元と委託先の双方が報告します。連名でも出せます。委託先が委託元に知らせた場合、委託先は報告の義務を免除されます。

不正アクセスなら、人数は関係ありません。報告の対象には、千人を超える漏えいのほかに、不正な目的で行われたおそれがある行為による漏えいも入ります。ガイドラインによると、その行為の相手には委託先も含まれます。だから、出前館の799件のように千人に届かなくても、委託先が不正アクセスを受けたなら対象です。

期限は2段です。速報は知った時点から「概ね3～5日以内」。確報はふつう30日以内で、不正の目的による漏えいなら60日以内になります。起点の「知った」時点は法人なら「いずれかの部署が当該事態を知った時点」です。物流の担当者に委託先から事故のメールが届いた日が、起点になりえます。

影響するのは、荷主と注文者とドライバー

確認が要るのは次の人と会社です。

• ピックゴーの法人向けサービスで配送を頼んでいる会社。届け先の情報のほか、登録した担当者の氏名と連絡先、案件IDと金額も含まれえます。CBcloudのサイトには、法人向けに緊急配送、定期配送、ピックゴーダイレクト、LCC宅配が並びます。どのサービスを使っていても、自社の分はCBcloudに聞くことになります。
• 7NOWと出前館の注文者。7NOWはSMSで、出前館はメールで、対象の人に順次知らせます。社員が私用で使っていれば、個人のスマートフォンに届く連絡です。
• 案件を運んだパートナードライバー。氏名や電話番号のほか、車両番号と配送中の位置情報が対象です。車両とプロフィールの画像を開けるURLも含まれますが、URLは発行から5分でアクセスできなくなると、CBcloudは注記しています。

ピックゴーと取引のない会社に、荷主としての影響はありません。ただ、CBcloudは導入法人の名前を出していないので、7NOWと出前館のほかにも、注文者の情報を取られた会社がこれから公表するかもしれません。どの発表もパスワードと決済情報を対象外としているので、7NOWや出前館のパスワードを社員に一斉に変えさせる場面でもありません。

本物の連絡と偽の連絡が、同じ道を通る

本物のお知らせと偽の連絡は、同じ道を通って届きます。CBcloudも出前館も、自社を装った不審な電話、メール、SMSに注意するよう呼びかけました。ところが、7NOWが本人に知らせる手段もSMSです。

7NOWで電話番号まで取られたのは209件でした。16万件を超える対象のほとんどは、電話番号までは漏れていない計算です。それでも「7NOWからSMSが来る」と知れ渡れば、無差別に送られた偽のSMSも本物らしく見えます。受け取った社員には、SMSのリンクは開かず、7NOWの公式サイトでお知らせを自分で探すよう伝えるのが確実です。

荷主の会社は、別の連絡に気をつけたいところです。第2報には、案件ID、案件金額、登録した担当者の氏名とメールアドレスが並んでいました。この組み合わせがあれば、実在する案件の請求を装ったメールが作れます。

たとえば「配送料の振込先が変わりました」というメールに、本物の案件IDと金額が書いてあったらどうでしょう。経理の担当者がその場で疑うのは難しいはずです。

配送の委託先とつながる会社が、今週確認すること

1. ピックゴーを使っている部署がないかを探します。請求書や経費精算の取引先の名前で「CBcloud」を引くと早く見つかります。使っていれば、自社の分が含まれるか、どの項目が何件か、登録した担当者の情報も入っているかを、CBcloudの営業担当者か、お客様相談窓口（customer.support@cb-cloud.com）に聞きます。

2. 配送の委託先に預けた認証情報を一覧にします。APIキー、Webhookの送り先と署名鍵、SFTPアカウントなどです。2社が載せた「連携設定の流出・書き換え」がないという答えも、委託先の調査によるものでした。11月1日の前後に、そのキーを使った呼び出しがふだんと違う時間や接続元から来ていないかを、自社側のログで見ます。疑いがあれば、キーを再発行します。

3. 連携を止める条件と、戻す条件を書き出します。出前館にならうなら、委託先から事故の連絡を受けたら止め、委託先が修正を終え、自社側でも通信を確認できたら戻します。止めると決める人と、止めている間に受注をどう回すかも、物流の担当と一緒に決めます。

4. 委託先から事故の連絡が届いたら、その日のうちに個人情報の担当者へ回るようにします。速報の「概ね3～5日以内」は、どこかの部署が知った時点から数えるからです。委託先に送る依頼の文面は、出前館がCBcloudに求めた3つが骨組みになります。原因の全容を究明すること、ほかの脆弱性がないかも含めて全体を点検すること、恒久的な再発防止策を実施して報告することです。

5. 社員に短い注意を流します。

   7NOWと出前館が、配達の委託先への不正アクセスで、注文者の名前や住所が取得されたと公表しました。対象の人には、7NOWはSMS、出前館はメールで連絡するとしています。
   届いた連絡のURLから、個人情報やカードの番号を入力しないでください。確認したいときは、7NOWと出前館の公式サイトのお知らせを、ブラウザーから直接開いてください。
   配送料の請求や支払い先の変更を求めるメールや電話が届いたら、その場で応じず、担当の部署に確認してください。
   

配送の委託先に、何を渡しているか。届け先の名前、住所、電話番号に、自由に書けるメモ。案件の金額と、発注した担当者の名前。CBcloudが第2報に並べた項目は、そのまま自社の点検表になります。個人情報保護委員会のガイドラインも、委託する業務に要らない個人データを渡さないことを「当然のこと」としています。出前館の7時間の次に効くのは、渡す欄を1つ減らすことかもしれません。