デニーズアプリ移行で第三者が認証情報を不正作成 移行用APIとログの点検

引っ越しのために開けた窓口から、第三者がアカウントに入れるようになっていました。デニーズジャパンの11月3日の第一報によると、旧デニーズアプリから新アプリへの移行に関するシステム処理で、第三者が認証情報を不正に作成し、一部の利用者のアカウントにアクセスできる状態でした。判明したのは10月30日です。

難しいのはその先でした。個人情報を取得する処理の履歴は見つかったものの、第三者の操作と利用者本人の操作を区別できておらず、第三者による取得の有無も対象人数も調査中です。

アプリや会員サイトを作り替えた会社なら、同じことを今日、自社で確認できます。移行処理はまだ外から届くのか。そのログで、本人と第三者を分けられるのか。

項目は移行の手順と重なるが、原因は発表されていない

第一報が漏えいの可能性を挙げた項目は、アプリ会員コード、メールアドレス、生年月日、性別、都道府県、お気に入り店舗、キッズバースデーです。キッズバースデーは、子どもの誕生日の登録を指します。対象は「旧デニーズアプリをご利用されていたお客様の一部」で、氏名、住所、電話番号、パスワード、クレジットカード情報はもともと「保持しておりません」といいます。

この項目を、アプリのサイトにある移行方法のPDFと並べると、語の重なりに気づきます。手順の最後にある「登録データの確認」は、「7iDからデニーズアプリに引き継ぐデータが入力された状態で表示」する画面で、続くかっこ書きは「基本情報・お気に入り店舗・キッズバースデー」です。

もっとも、この画面が不正に使われたとは、第一報のどこにも書かれていません。7iDという語も出てきません。原因の究明は今後の対応に挙げられ、手口、不正に作成できた条件、移行の受付を止めたかどうかは、第一報からは読めません。

語の重なりから言えるのは、移行処理の役目までです。公式の手順では、認証コードを受け付け、旧データを画面に出し、確認が済めば移行完了となります。

編集部は、認証情報を作る役目と個人情報を返す役目が一続きになりがちな点で、移行処理は一般に、ログインや会員情報の画面より権限が強くなりやすいとみています。移行処理全般についての見立てで、デニーズの処理の権限を述べたものではありません。

移行の窓口は、公開のあとも閉じにくい

移行の窓口は、公開の日だけの仕事では終わりません。デニーズジャパンは6月15日のリリースで、7月16日にアプリをリニューアルし、既存の会員には移行手続きが必要になると案内しました。新規入会と移行を対象にしたキャンペーンは8月31日まで。第一報が調査結果として挙げる10月7日のアクセス記録は、その37日後のものです。不正な認証情報の新規作成を防ぐ改修が入った10月30日は、リニューアルから106日後にあたります（どちらも編集部で数えました）。

閉じにくい事情は想像がつきます。アプリの会員は2025年8月に300万人を超えていました（今回の対象人数ではありません）。久しぶりにアプリを開く人は何か月たっても現れますし、移行の途中でつまずく人も出るでしょう。移行方法のPDFの2ページ目には「初期画面に戻ってしまうお客様の復旧方法」があり、移行済みの人と未移行の人で入力するメールアドレスを分けています。11月6日の時点でも、アプリのサイトには移行方法の案内が載っていました。受付が今も動いているかまでは、案内からは分かりません。

開けておく理由はあるのに、見る人は減っていく。編集部は、作り替えを経た会社に共通しやすい落とし穴とみています。公開の前後は開発チームも監視も移行に集中しますが、数か月たてば関心は新機能に移りがちです。

デニーズの監視の体制は発表からは分かりません。ただ自社に置き換えると、移行用APIの持ち主と閉じる日を聞かれて、すぐ答えられる担当者は多くないかもしれません。

公的な注意喚起や業界の資料も、同じ所を指します。NICTの10月13日の注意喚起は、確認する範囲に「旧バージョンのAPI」や検証環境を含めるよう求め、ログでは「認証トークンの不審な発行」を見るよう挙げました。国家サイバー統括室の11月5日の文書も、認証・認可やAPIの重要な変更のときに診断と点検をするよう促します。OWASPのAPI Security Top 10は、APIの版ごとの廃止の計画がないことや台帳の不備を、見落としの原因に数えます。どれも一般の注意で、デニーズの件をこれらの手口と結びつける発表はありません。

本人か第三者かを分けられないと、人数を絞りにくい

同じ秋の事故と並べると、第一報の書き方の違いが見えてきます。手口も数え方も違うので、早さや数字で優劣は決められません。

下の3社の発表には、ふだんの利用と見分ける手がかりになりそうな跡が出てきます。連続したアクセスや、特定のAPIを特定の時刻から使った跡です。ただ、アエナとソースネクストの数字は最大の見積もりで、本人の操作を分けて数えたとまでは読めません。

一方、本人も同じ移行処理を使っていた時期に、第三者が作った認証情報で同じ処理を呼んだとすれば、ログの1行は本人の操作とよく似てくるでしょう。あくまで推測で、デニーズのログの中身は発表からは分かりません。

不正な認証情報そのものは、見つけて無効化しています（10月31日と11月2日）。それでも第一報の時点で、取得の処理を本人か第三者かに分けられていません。人数が確定しない理由として第一報が挙げるのは、確認できているのが10月7日のアクセス記録についての調査結果で、ほかの期間を調査中であることです。

発行の記録と取得の記録をつなぐ印が足りないのか、単に調査の途中なのかは、発表からは分かりません。どちらにせよ、自社のログを点検するなら、ここがいちばんの急所です。

まず見るのは、1行目と3行目に同じ「認証情報の識別子」があるかどうかです。これがあれば、無効にした認証情報の一覧から、何が返ったかをたどれます。

OWASPのLogging Cheat Sheetも「いつ、どこで、だれが、何を」を記録するよう求め、トークンの追加や削除、データの入出力をリスクの高い機能に挙げています。アクセストークンやパスワードはログに直接書かないよう同じ資料が勧めているので、残すのは識別子かハッシュ値です。デニーズの調査が10月7日以外の期間へ広がっているように、調べる範囲はあとから広がります。移行の開始から窓口を閉じたあとまで通して残しておけば、途中で切らずに済みます。

影響するのは旧アプリの会員と、作り替えた会社

旧デニーズアプリを使っていた人の一部が、対象の可能性があります。対象者には、特定でき次第、デニーズジャパンから個別に連絡が届く予定です。

私用のスマートフォンで使っている社員もいるでしょう。情シスから伝えるなら、身に覚えのないメールのURLを開かず、個人情報を入れないようにと短く添えれば足ります。第一報はパスワードを保持していないと書いているので、「パスワードが漏れたから変更を」という連絡は発表と合いません。起動すると初期画面が出て再ログインを求められる人がいるのは、今回の対策に伴うものだと第一報にあります。

点検が要るのは、この数年でアプリや会員サイト、ID基盤を作り替えたり統合したりした会社です。開発を委託しているなら、移行処理がまだ動いているかは社内から見えにくく、委託先に聞く項目になります。

逆に、会員向けのアプリやサイトを持たず、旧システムからの移行もしていない会社は、急いで動く話ではありません。

移行用の窓口を閉じるまでの手順

1. 直近3年の作り替えを書き出します。案件ごとに、移行のために作った画面、API、旧環境を、設計書と委託先への聞き取りで一覧にします。
2. 一覧の各行に3つの印を付けます。認証情報を作るか、個人情報を返すか、今も外から届くか。3つとも当てはまる行から先に見て、持ち主と閉じる日も同じ表に入れます。
3. 本人確認が何を確かめているかを、設計書で読みます。認証コードが示すのは、その宛先のメールを受け取れることだけです。旧アカウントの本人との結びつきをどこで確認しているかを、委託先に文書で答えてもらいます。
4. 検証環境か自社のテスト用会員で移行を1回通し、ログを引きます。他人の会員IDや推測したURLを本番で試してはいけません。発行の記録と個人情報を返した記録を同じ識別子でつなげられなければ、上の表の項目を足す依頼を出します。
5. 閉じる条件を決めます。未移行の会員が何件を切ったら閉じるか、閉じたあとの移行は問い合わせ窓口で受けるか、移行しなかった会員の旧データをいつ消すか。閉じるまでは、次の脆弱性診断の範囲に移行用APIを入れます。

旧データを消す日は、後回しにされやすい項目です。MUJIアプリの件では、退会した人の情報も対象に含まれると報じられました。委託先への質問を広げるなら、次のシートがそのまま使えます。

新しいアプリの公開日は、関わった人みんなが覚えています。移行の窓口を閉じる日は、決まっているでしょうか。