アクティビティ予約大手のアソビューが、事業者向け予約管理システム「satsuki」へのサイバー攻撃を公表しました。一部の事業者アカウントが不正ログインされ、予約者の個人情報2万7,163件などが外部に流出した可能性があります。注目すべきは、攻撃者が盗んだ認証情報を悪用し、侵入したアカウント以外の事業者の情報にまで手を広げた点です。自社が直接狙われていなくても、利用しているSaaS経由で自社や顧客の情報が漏れる——情シスが直視すべき構図がここにあります。
この記事でわかること
- アソビュー「satsuki」で何が起き、何件・どんな情報が流出したのか
- 「認証情報の悪用による横展開」という手口の意味
- 自社が使うSaaS／予約システムについて情シスが確認すべきこと
何が起きたのか
アソビュー株式会社は2026年5月28日、同社が体験・レジャー事業者向けに提供する予約管理システム「satsuki」がサイバー攻撃を受け、利用事業者(パートナー)と予約者の情報が外部に流出したと公表しました。同社によると、2026年5月20日に「satsuki」への外部からの不審なアクセスを検知し、ただちにアクセス元のブロックなどの対策を講じて調査を開始したとしています。翌5月21日付で個人情報保護委員会へ報告し、警察当局へも相談して被害届の提出を準備しているとのことです。
流出した可能性がある情報の規模は、次のとおりです。
| 対象 | 件数 |
|---|---|
| 「satsuki」経由の予約者(ゲスト)の情報 | 27,163件 |
| 不正ログインが確認された事業者の情報 | 111件 |
| その他の事業者の情報 | 14,400件 |
攻撃の手口：盗んだ認証情報で「横展開」した
今回の事案で情シスが押さえておきたいのは、被害が一つのアカウントの侵害にとどまらなかった点です。アソビューの説明によれば、攻撃の流れは大きく三段階でした。
- 一部の事業者(パートナー)アカウントへの不正ログイン
- そのアカウントから、当該事業者の予約者情報(ゲスト情報)へのアクセス
- さらに認証情報の悪用により、当該事業者以外の事業者の情報にもアクセス
つまり、最初に乗っ取った1アカウントを足がかりに、システム内部で別のテナント(他の事業者)の情報へと侵害範囲が広がっています。これは攻撃用語でいう「横展開(ラテラルムーブメント)」にあたります。複数の事業者が同じシステムを共同利用するマルチテナント型のSaaSでは、1か所の侵害が他の利用者へ波及しうることを示す典型例といえます。アカウント乗っ取りが踏み台になって被害が拡散する構図は、アカウント乗っ取りでスパムの踏み台にされた事例とも通じます。
流出した情報・しなかった情報
アソビューは、流出した可能性のある情報の項目も公表しています。線引きを正しく把握しておくことが、利用者対応や社内説明の出発点になります。
- 流出した可能性がある項目(予約者)：氏名、性別、生年月日、電話番号、住所、予約情報
- 流出の対象に含まれない項目：メールアドレス、パスワード、クレジットカード情報
パスワードやクレジットカード情報が対象外であることは不幸中の幸いですが、氏名・生年月日・住所・電話番号がそろえば、それ自体がフィッシングや本人確認のなりすましに悪用されうる「使える」情報です。事業者(取引先)側については、社名・住所・代表者氏名・請求先や口座情報といった取引関連情報も対象になったと報じられており、影響は予約者だけにとどまりません。同社は予約者向けの専用窓口(0120-30-3521)を設けて問い合わせに対応しています。
なぜ情シスにとって他人事ではないのか
「自社のサーバーは無事でも、使っているSaaS経由で自社や顧客の情報が漏れる」——これがサードパーティ(委託先・サプライチェーン)リスクの本質です。多くの企業が、予約・問い合わせ・顧客管理などの業務を外部のSaaSやASPに委ねています。そのどれか一つが侵害されれば、自社が一切攻撃を受けていなくても、自社が預けた個人情報が流出する可能性があります。
個人情報保護法は、個人データの取り扱いを外部に委託する場合、委託元に「委託先に対する必要かつ適切な監督」を求めています(法第25条)。つまり、SaaSに業務を預けたら終わりではなく、預けた先の安全管理体制を確認する責任は委託元にも残ります。委託・再委託の管理が抜け落ちると思わぬ漏えいにつながる点は、QRコード誤掲載で個人情報が流出した委託管理の事例でも繰り返し問われてきたテーマです。
情シスはどうすべきか
自社が使うSaaSの認証は「ID・パスワードだけ」になっていないか？
今回の入口は、結局のところ事業者アカウントへの不正ログインでした。ID・パスワードだけの認証は、フィッシングやパスワードの使い回しで突破されやすく、横展開の起点になります。利用中のSaaSで多要素認証(MFA)が使えるなら有効化し、管理者アカウントは必須にするのが現実的な第一歩です。あわせて、認証情報の悪用による内部侵害を早期に捉えるには、不審なログインや異常な操作を検知する仕組みも欠かせません。考え方の土台としてはゼロトラストの基本や、ログを相関分析するSIEMの仕組みもあわせて押さえておくとよいでしょう。
まず何から手をつければよいか？
自社の対策チェックリストを一から作り込む前に、公的機関の指針を起点にするのが近道です。中小規模の組織であれば、IPAの中小企業の情報セキュリティ対策ガイドラインが、委託先管理やアカウント管理を含めて体系的に整理されています。利用者・従業員への啓発には対策のしおりが使えます。委託先の安全管理措置の確認観点は、個人情報保護委員会のガイドライン(通則編)も参照してください。要は、新しいツールを導入することより、「どのSaaSに、誰のどんな情報を、どんな認証で預けているか」を棚卸しすることが出発点になります。
現場目線の所感
正直なところ、現場でSaaSの利用状況を完全に把握しきるのは簡単ではありません。各部署が業務効率のために契約したツールが情シスの知らないところで動いており、いざ漏えいが起きてから「そのサービス、うちも使っていたのか」と気づくことも珍しくないはずです。今回のように外部のシステムが侵害されると、情シスは自社のログを追っても原因が見えず、委託先の発表を待つしかない——その受け身のもどかしさは、多くの担当者が身に覚えのある感覚ではないでしょうか。だからこそ、平時に「使っているSaaSの一覧」と「それぞれの認証方式・連絡窓口」を薄くてもよいので持っておくことが、有事の初動を大きく左右します。派手な投資より、この地味な棚卸しの差が効いてきます。
まとめ
- アソビューの予約システム「satsuki」が不正ログインを受け、予約者2万7,163件などの個人情報が流出。メール・パスワード・クレカは対象外と公表されている。
- 攻撃者は盗んだ認証情報を悪用し、侵入元以外の事業者の情報へ横展開した。マルチテナントSaaSの典型的なリスクが顕在化した形。
- 自社が攻撃されなくてもSaaS経由で漏えいは起きる。利用SaaSの棚卸し・MFA・委託先監督(法第25条)を起点に、公的指針を活用して足元を固めたい。
出典
- アソビュー株式会社「弊社システムへのサイバー攻撃による情報流出に関するお詫びとお知らせ」 https://www.asoview.co.jp/news/articles/wMidTEDr
- Security NEXT「予約管理システムが侵害、個人情報が流出 – アソビュー」 https://www.security-next.com/185170
- 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」 https://www.ppc.go.jp/personalinfo/legal/
- IPA「中小企業の情報セキュリティ対策ガイドライン」 https://www.ipa.go.jp/security/guide/sme/index.html
