FaveConnect不正アクセス：11万7,392件の対象確認と管理画面の不正ログイン対策

日テレWandsは2026年10月14日、同社のファンコミュニケーションサービス「FaveConnect」の管理画面に第三者が不正ログインし、高嶺のなでしこオフィシャルファンクラブとHEROINES OFFICIAL WEBSITEの会員など11万7,392件の個人情報が閲覧された可能性があると公表しました。クレジットカード番号は含まれていません。本記事では公式発表の文言をもとに、届いた連絡が本物か、自分が対象に入るか、パスワード変更が必要かを先に答えます。後半では、会員情報を扱う管理画面を運営する側に向けて、MFAの必須化、送信元IPの制限、会員情報の閲覧を記録して大量閲覧を見つける設定とSQLを示します。

まとめ：FaveConnect不正アクセスで公表された事実と会員がいま確かめること

確定しているのは、10月13日に運営管理者向け画面への不審なアクセスを検知し、調べた結果、第三者が管理者アカウントに不正ログインして10月11日から13日まで会員情報を閲覧した形跡が見つかったことです。日テレWandsは不正ログインに使われた管理者アカウントを削除し、接続元を遮断しました。認証情報がどう盗まれたかは書かれていません。

会員がやることは多くありません。日テレWands、TWIN PLANET、ファンクラブを名乗る連絡がパスワードやカード番号を聞いてきたら、偽物と判断してください。3社とも、メール、SMS、電話でそれらを聞くことはないと明記しています。高嶺のなでしこのメンバーがSNSのダイレクトメッセージで個別に連絡することもない、とTWIN PLANETは書いています。

届いた連絡は本物か・自分は対象かを確かめる｜高嶺のなでしこFC・HEROINES会員の手順

日テレWandsとTWIN PLANETが聞かないと明言した情報と偽の連絡の見分け方

日テレWandsの公表文は、同社や共同サービス提供者を装う不審なメール、電話、SMSに注意するよう求めています。そのうえで、メール、SMS、電話でパスワードやクレジットカード情報を聞くことはないと明記しています。

TWIN PLANETのお知らせは、注意の対象をもう一段広げています。同社、日テレWands、ファンクラブ、高嶺のなでしこ、そのメンバーを名乗る連絡で、SNSのダイレクトメッセージも含めた書き方です。メンバーが個別にDMを送ることはないとも書かれています。

判断の線は単純です。パスワード、カード番号、ログイン用のコードの入力を求められたら、運営名義でも偽物として扱います。リンクは開かず、ブラウザから公式サイトへ自分で入って内容を照合してください。

対象は2サービスの会員と退会後6か月以内の元会員｜ほかのFaveConnect利用者

閲覧された可能性があるのは「該当ファンクラブサイトの会員様および退会後6ヶ月以内の元会員様」です。日テレWandsは、退会者の個人情報を原則として6か月保管してから廃棄していると説明しています。退会から半年以上たっている人は、この運用どおりなら対象に入りません。

FaveConnectで運用されているほかのサービスについては、同じ手口の不正アクセスがないかを調べ、本件以外に同様の被害はないと確認したと書かれています。高嶺のなでしことHEROINES以外のファンクラブだけに入っている人は、公表上は対象外です。

退会済みの人のうち対象となった人には、別途メールで知らせたとされています。確認したい場合は、公表文が案内する退会者専用の問い合わせメールアドレスへ、件名に「不正アクセスに関する問い合わせ」と入れて送る形です。

パスワード変更とカード停止が必要かを公表内容から判断する基準

公表文に、会員へパスワードの変更を求める記述はありません。閲覧された可能性のある項目にパスワードは入っておらず、カード番号などの決済情報も含まれないと書かれています。この記載に従えば、カードの停止や再発行は不要です。

ただし、ファンクラブと同じパスワードをほかのサービスで使い回している人は、この機会に分けておく価値があります。本件とは別の漏えいで同じ組み合わせが出回っていれば、被害はそちらから起きます。

公表内容を時系列で読む｜10月11日の閲覧開始から13日の検知と管理者アカウント削除まで

閲覧が3日間続いてから検知に至った流れと公表文が示す対応の順序

公表文の時系列は短いものです。10月11日から13日まで管理画面を通じた閲覧があり、13日に不審なアクセスを検知して調査を始めました。覚知後すぐに、使われた管理者アカウントを削除して接続元を遮断し、同じ手口ではログインできない状態にしたと書かれています。

読み取れるのは、正規の管理者アカウントでログインされた場合、最初の閲覧から検知までに最大3日間の幅があったという事実です。不正ログインの検知方法や、強化したセキュリティ対策の中身は公表されていません。本記事でも特定の手口には結び付けません。

11万7,392件はアカウント数で全件の閲覧が確認された数字ではない理由

117,392件は「閲覧された可能性のあるアカウント件数」です。2サービスの合計で、内訳は示されていません。管理画面でその範囲の会員情報に手が届く状態だった、という意味で読むのが正確です。

一方で日テレWandsは、第三者が管理画面で行った操作はすべて特定したと書いています。それでも件数を「可能性」で出しているのは、画面上で表示された情報と表示されていない情報を、会員単位で切り分けて公表していないためと考えられます。対象かどうかは、件数ではなく前の章の条件で判断してください。

データベースへの侵入なし・改ざんなしが会員にとって意味する範囲

公表文は、データベースサーバー等への直接的な侵入は確認されていないと書いています。情報の改ざんなどシステムへの不正な変更も、閲覧された情報の公開や不正利用も、現時点では確認されていません。

会員にとっての意味は、登録内容が書き換えられた心配は小さいという点にとどまります。管理画面は正規の入口なので、DBに侵入されていなくても、画面に出る項目は見られた前提で考えるべきです。氏名、住所、電話番号、生年月日、アンケート回答がそれにあたります。

閲覧された項目の悪用パターン｜ファンクラブ運営やメンバーを装う連絡と相談先

氏名・住所・生年月日・アンケート回答がそろう名簿がなりすましに使われる流れ

閲覧された可能性のある項目は、氏名、メールアドレス、住所、電話番号、職業、生年月日、性別、ニックネーム、その他会員情報、サイトでの任意のコメントです。コメントにはアンケート回答も含まれます。

ファンクラブの名簿は、誰が何のファンかが確定している点で一般の名簿と違います。想定しやすいのは、チケットの当選や特典の案内、グッズの配送確認を装い、外部のフォームでカード番号や口座を入力させる連絡です。ニックネームやアンケート回答に触れていても、本物とは限りません。同じ月に公表されたハイホーの不正ログインでも、会員情報を使った勧誘への対処が論点になっています。

不審な連絡の記録の残し方と会員・退会者で異なる問い合わせ窓口

不審な連絡が届いたら、削除する前に記録を残します。メールなら送信元アドレスと受信日時、SMSなら送信元番号と本文の画面、DMなら送信元のアカウント名です。実害が出たときに、警察や消費生活センターへ相談する材料になります。

問い合わせ先は立場で分かれます。会員はそれぞれのファンクラブサイトにある会員用の問い合わせ窓口、退会した人は公表文に載っている退会者専用のメールアドレスです。カード番号や口座を入力してしまった場合は、運営より先にカード会社や金融機関へ連絡して止めてください。

管理画面の不正ログインを止める実装｜MFA必須化・送信元IP制限・閲覧の監査ログ

管理者アカウント1つで全会員を閲覧できる設計が被害を11万件規模に広げる理由

ここからは、会員サイトやファンクラブの管理画面を作る側、運営する側の話です。本件で認証情報がどう盗まれたかは公表されていないため、以下は同種の画面で一般に押さえる設計として読んでください。

管理画面の不正ログインが重いのは、正規の入口から全会員の情報に届くためです。OWASPの多要素認証チートシートは、パスワードはいずれ漏れる前提で設計すべきだとし、管理者など高い権限を持つ利用者にはMFAを必須にするよう書いています。パスワードだけで守られた管理者アカウントは、流出した1組の認証情報だけで11万件に届く入口となるため危険です。方式の選び方は多要素認証（MFA）の実装方式で比べています。

もう一つの軸は権限の幅です。問い合わせ対応の担当者に、全会員の住所と電話番号を一覧で見る権限は要りません。役割ごとに見える項目と件数を絞る設計は、Django管理画面の権限の実装が具体例になります。

nginxで管理画面を社内IPに限定する設定と多要素認証MFAを併用する理由

管理画面のURLに届く送信元を、社内や委託先の固定IPに絞ると、盗まれたパスワードを外から試されること自体を止められます。nginxのアクセス制御モジュールでは、allowとdenyを先頭から順に照合し、最初に一致した規則が使われます。次の設定は、管理画面のパスだけを2つの送信元に限り、それ以外を403で返す例です。

server {
    listen 443 ssl;
    server_name fc.example.jp;

    # 管理画面は社内と委託先VPNの出口だけに開く
    location /admin/ {
        allow 203.0.113.0/24;   # 本社の固定IP（例）
        allow 198.51.100.10;     # 委託先VPNの出口（例）
        deny  all;

        access_log /var/log/nginx/admin_access.log;
        proxy_pass http://app_backend;
    }

    # 会員向けの画面は従来どおり公開
    location / {
        proxy_pass http://app_backend;
    }
}

ロードバランサやCDNの背後に置いている場合、nginxが見る送信元は中継装置の住所になるため、この設定だけでは絞れません。中継側で送信元を絞るか、実際の送信元を受け取る設定を足してください。

注意したいのは、IP制限はMFAの代わりにならない点です。OWASPのチートシートも、パスワードと信頼済みIPの組み合わせは多要素認証にあたらないと明記しています。社内の端末が乗っ取られれば、許可済みの送信元からの侵入が可能です。IP制限は入口を狭める策、MFAは盗まれたパスワードを無効にする策と分けて、両方を入れます。

会員情報の閲覧とエクスポートを監査ログに残し大量閲覧を検知するSQL

本件で閲覧が始まってから検知までに最大3日間あった点は、運営側の課題として読めます。OWASPのロギングチートシートは、記録すべき事象としてデータのエクスポートを含む監査証跡と、機微なデータへのアクセスを挙げています。ログイン成功だけでなく、管理者が会員詳細を開いた事実とCSVを出した事実を、アプリケーション側で1件ずつ残すのが出発点です。

-- 管理画面での閲覧・エクスポートを1操作1行で残す
CREATE TABLE admin_access_log (
    id          bigserial   PRIMARY KEY,
    admin_id    text        NOT NULL,
    action      text        NOT NULL,  -- view_member または export_csv
    member_id   bigint,
    row_count   integer     NOT NULL DEFAULT 1,
    source_ip   inet        NOT NULL,
    occurred_at timestamptz NOT NULL DEFAULT now()
);

-- 直近1時間に会員詳細を100件以上開いた、またはCSVを出した管理者を抽出
SELECT admin_id,
       source_ip,
       count(*)       FILTER (WHERE action = 'view_member') AS viewed,
       sum(row_count) FILTER (WHERE action = 'export_csv')  AS exported
FROM admin_access_log
WHERE occurred_at >= now() - interval '1 hour'
GROUP BY admin_id, source_ip
HAVING count(*) FILTER (WHERE action = 'view_member') >= 100
    OR sum(row_count) FILTER (WHERE action = 'export_csv') > 0;

集計にはPostgreSQLの集約式のFILTER句を使い、閲覧とエクスポートを1回の走査で数えています。このクエリを数分おきに実行し、結果が1行でもあれば担当者へ通知します。しきい値の100件は例で、普段の業務で1人が1時間に開く件数を1週間ほど計ってから決めてください。

ログ自体の保管先は、管理画面と同じ権限では消せない場所に分けます。転送と改ざん防止の設定はFluentdで作る監査ログ基盤、事故後にログから痕跡を追う手順は不正アクセスの調べ方にまとめています。

ファンクラブSaaSを使う事業者が委託先に確かめる管理画面の4項目

本件のように、アーティスト事務所などがSaaSを使って共同でサービスを提供する形では、管理画面の作りは委託先の領分です。それでも会員から見れば提供者は事務所でもあり、TWIN PLANETも提供者として謝罪しています。契約や更新のときに、少なくとも次の4点を書面で確かめておくと、事故の確率と広がり方の両方を見積もれます。

1. 管理者アカウントにMFAが必須になっているか、任意設定にとどまっているか
2. 管理画面に届く送信元を絞っているか、インターネット全体に開いているか
3. 会員情報の閲覧とエクスポートが操作単位で記録され、大量閲覧を通知する仕組みがあるか
4. 退会者の情報を何か月保管し、いつ削除しているか

4番目は見落とされがちです。本件では退会後6か月以内の元会員も対象に入りました。保管期間を短くすれば、同じ事故でも届く範囲は小さくなります。

管理画面対策の採用判断｜MFAとIP制限を同時に入れる条件と後回しにしない線

会員数1万件超か管理者に社外委託を含む場合はMFAとIP制限を同時に入れる判断

会員情報が1万件を超える、または管理者に社外の委託先や業務委託の個人が含まれる管理画面は、MFAの必須化と送信元IPの制限を同時に入れるべきです。どちらか一方を先に入れて様子を見る段階ではありません。認証情報の管理を自社だけで完結できない以上、パスワードが漏れる前提で入口を二重に絞るのが筋です。

監査ログと大量閲覧の通知は、その次に入れます。ログは被害を止める策ではなく、止められなかったときに早く気づき、範囲を確定させる策だからです。漏えいが起きた場合の個人情報保護委員会への報告の流れは、個人情報保護委員会の案内と報告義務の実務の解説で確認できます。

IP制限を見送る場面と監査ログだけで済ませて被害を止められない失敗パターン

IP制限を見送ってよいのは、管理者が自宅や外出先から日常的に入り、固定の送信元を決められない場合です。このときは、フィッシングに強いパスキーや認証アプリによるMFAを必須にし、新しい端末からのログインを管理者全員へ通知する形で補います。IP制限のために全員をVPNへ移す費用が見合わない小規模な運営では、これで十分です。

避けたいのは、監査ログだけ整えて満足する失敗です。ログと通知があっても、パスワードだけで入れる管理画面は、検知までの時間ぶん閲覧を許します。本件の3日間は、その幅が実際にどれほどになるかを示しています。自社の管理画面がどこまで守れているか分からない場合は、脆弱性診断・セキュリティ診断で認証と権限の作りを外から確かめるのが早道です。

FaveConnect不正アクセスと日テレWandsの公表についてよくある質問

会員と運営事業者から出やすい質問を、10月23日時点の公表内容に沿ってまとめます。

FaveConnectとはどのようなサービスですか？

日テレWandsが運営するファンコミュニケーションサービスです。TWIN PLANETのお知らせによれば、高嶺のなでしこオフィシャルファンクラブは、このFaveConnectを使ってTWIN PLANETと日テレWandsが共同で提供しています。HEROINES OFFICIAL WEBSITEは、imaginateが共同サービス提供社として公表文に記載されています。本件で不正ログインされたのは、ファンクラブサイトの運営管理者向けの画面です。

高嶺のなでしこのファンクラブ会員は全員が対象ですか？

公表文では、該当ファンクラブサイトの会員と退会後6か月以内の元会員が「閲覧された可能性のあるお客様」とされています。117,392件はHEROINES OFFICIAL WEBSITEとの合計で、全件の閲覧が確認された数字ではありません。現会員は対象に入る前提で、不審な連絡に注意してください。退会から半年以上たった人は、保管期間の運用どおりなら対象外です。

ファンクラブのパスワードは変えたほうがよいですか？

公表文にパスワード変更を求める記述はなく、閲覧された可能性のある項目にもパスワードは含まれていません。本件だけを理由に変える必要はないと読めます。ただし、同じパスワードを他のサービスで使っている場合は、別の漏えいから被害が出ないよう、サービスごとに分けておくのが安全です。

不正ログインの原因や手口は公表されていますか？

公表されているのは、第三者が管理者アカウントに不正にログインしたという事実までです。パスワードがどの経路で盗まれたか、MFAが設定されていたかは書かれていません。日テレWandsは、同じ手口では不正にログインできない状態にしたと説明し、新たな事実が判明した場合は速やかに公表するとしています。

自社の会員サイトで同じ事故を防ぐには何から始めればよいですか？

まず管理者アカウントの一覧を作り、退職者や終了した委託先のアカウントが残っていないかを確かめます。次に、管理者全員にMFAを必須にし、可能なら管理画面の送信元を絞ります。会員情報の閲覧とエクスポートの記録は、その後で構いません。API経由の不正アクセスも含めた対策の全体像は、API不正アクセス対策の実装手順で扱っています。

関連記事

• 多要素認証（MFA）とは？3要素と実装方式・耐フィッシングMFAをコード付きで解説：管理者に必須化するMFAの方式を選ぶときに
• API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効：管理画面以外の入口の守り方
• 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：漏えいの可能性が出たときの報告の期限
• 不正アクセスの調べ方｜ログの確認方法と痕跡を見つけるコマンド例：不正ログインの範囲をログで確定する手順
• ハイホー不正ログイン：3万8,509件の対象確認と電話勧誘への対処：同じ月に公表された会員情報の不正ログイン事例