コミュニティSaaSの不正アクセスから学ぶ、招待リンクと管理者権限の守り方

こんにちは、株式会社TIMEWELLの濱本です。

2026年10月9日、国内のコミュニティ運営SaaSが、不正アクセスで約30.7万人(推計)の会員情報が漏えいしたと公表しました。そのSaaSを導入していた企業や自治体が、次々と自社の会員への影響を発表しています。会員向けのコミュニティやファンサイトを、外部のSaaSで運営している会社にとっては、他人事ではない出来事だったはずです。

この記事では、公表された事実と、まだ分かっていないことを分けます。そのうえで、SaaSを運営する側と、導入して使う側の両方が見直すべき項目を、OWASPとRFC 8725に基づいて整理します。特定の会社の落ち度を探す記事ではありません。事実を出してくださった会社、自社の会員にすぐ案内を出した導入企業の動きも、学べる点がたくさんありました。

公表されている事実と、まだ分かっていないこと

発表と報道から確認できる範囲です。¹²

日時	起きたこと
10月5日 18時ごろ	不正アクセスの開始
10月6日	運営会社が検知し、通信の遮断と防御措置を実施。21時ごろ、全コミュニティをメンテナンスモードに切り替え
10月7日 13時17分〜14時36分	2回目の漏えい。メンテナンス中に残っていた通信経路を悪用した、不正な会員登録と閲覧
10月7日 14時58分	その通信経路を遮断
10月8日	外部からの不正アクセスへの防御措置を講じたうえで、順次再開
10月9日	公表。漏えいした会員は約30.7万人(推計)

公表された手口は、2つです。非公開コミュニティの招待リンクを不正に取得して一般会員として登録したこと。そのうえで、管理者になりすまして、会員情報の閲覧と取得、データの上書きを行ったことです。運営会社は、原因を「システムの不備を突かれた」と説明しています。¹

漏えいした会員のうち、メールアドレスを含む情報は約12.6万人(従業員とテスト用アカウント約4.2万人分を含む)、メールアドレスを含まない情報は約18.1万人です。項目は、表示名、自己紹介、非公開グループの所属などで、コミュニティや会員によって異なります。144人のパスワードが、本人の操作によらず仮パスワードに変更されましたが、パスワード自体の漏えいは確認されていないとされています。¹²

運営会社が挙げた対応には、攻撃に使われた不備の修正、ログイン用の署名鍵の更新、不正な通信経路の遮断と不正なIPアドレスからのアクセス拒否、攻撃者が作ったアカウントの退会処理が含まれています。報道によると、データは10月6日18時時点の状態に巻き戻されました。巻き戻しの結果、ダイレクトメッセージや新規登録などは、復元の対象外となる見込みとされています。²

導入側の動きも、公表されています。ある導入企業は、運営会社から「委託先のサイトの管理者アカウントが不正に利用された」という説明を受けたと発表し、運営会社が10月6日にサービスを停止、7日に報告を受けたこと、8日に個人情報保護委員会へ報告したことを書いています。³

一方で、公表されていないことがあります。

• 最初の侵入が、どの不備を通じて起きたのか。確認できた発表や報道には、初回の侵入経路の詳細が書かれていません。¹
• 招待リンクを、どのようにして入手されたのか。
• 管理者へのなりすましが、どの仕組みで成立したのか。署名鍵の更新が対応に含まれていますが、鍵がどう関わったかは、公式の発表からは読み取れません。
• 各社が公表した人数を足した合計と、約30.7万人の関係。報道も、各組織の数字を単純に合計できないと注意しています。²

私が気になるのは、2回目の漏えいです。1回目の対応として、全コミュニティをメンテナンスモードにしたにもかかわらず、メンテナンス中に残っていた通信経路が悪用されました。止めたつもりの入口が、実際には開いていた。この教訓は、あとの章で扱います。

運営側が見直す5つの項目

SaaSを運営する側、つまり、他社の会員情報を預かる側が見直せる項目を5つに分けます。ここから先は、今回の事案の原因の推測ではなく、一般論です。

1. 招待リンクを、本人確認の代わりにしない。

招待リンクは、知っている人なら誰でも使える「秘密のURL」です。メールで転送されたり、画面共有で映ったり、チャットに貼られたりして、意図しない人の手に渡ることがあります。リンクが漏れても被害を小さくするには、有効期限を付ける、使用できる回数や人数を絞る、参加を管理者の承認制にする、いつでも失効できるようにする、といった設計が要ります。特に、非公開のコミュニティでは、リンクを知っているだけで会員になれる設計かどうかを、見直す価値があります。

2. 管理者の権限を、一般機能から分ける。

OWASPのAPIセキュリティTop 10は、API5として「機能単位の認可の不備」を挙げています。管理用の機能と一般向けの機能の区別があいまいで、本来使えない機能に届いてしまう問題です。⁴ 管理者になりすませると、会員情報の閲覧や取得、データの上書きが一度にできてしまいます。管理者の操作には、追加の認証(多要素認証や再認証)を求める、管理者の権限を付与できる経路を限定する、管理者の操作を監査ログに必ず残す、といった備えが要ります。

3. ログインの署名と鍵を、用途とテナントごとに分ける。

ログイン状態を示すトークンに、電子署名を使うサービスは多くあります。トークンの標準であるJWTのベストプラクティス(RFC 8725)は、発行者(iss)と主体(sub)を検証すること、対象者(aud)を含めて検証すること、種類の違うトークンには別の鍵を使う方法があることを挙げています。⁵ 複数の利用者向けに同じ発行者がトークンを出す場合は、audを必ず検証するよう求めています。

SaaSで、複数のコミュニティ(テナント)が同じ署名鍵を共有していると、一つの鍵が破られたときの影響が全体に広がります。今回の事案で鍵がどう関わったかは分かっていません。ただ、署名鍵をテナントごと、用途ごとに分けておくことは、被害を局所化する一般的な考え方です。鍵を更新するときの手順も、平時から決めておきます。

4. テナントの境界を、サーバー側で守る。

OWASPがAPI1として挙げる「オブジェクト単位の認可の不備」は、利用者が指定したIDを受け取る処理で、認可の確認が足りず、他人のデータに届いてしまう問題です。⁴ マルチテナントのSaaSでは、一つのコミュニティの管理者が、別のコミュニティのデータに届かないことが、最も重要な境界になります。「管理者」という肩書きではなく、「どのコミュニティの管理者か」まで確かめます。

5. 「止めた」の意味を、手順書で定義する。

今回、運営会社は、10月6日に全コミュニティをメンテナンスモードに切り替えました。それでも7日に、メンテナンス中に残っていた通信経路が悪用されました。¹ 事故のときに「止める」という作業は、画面の表示を止めることではなく、すべての入口を閉じることです。API、管理画面、バッチ、外部連携、古いバージョンのエンドポイント。入口の一覧を平時から作り、封じ込めの手順書に「一覧のすべてが閉じたことを確認する」という項目を入れます。OWASPがAPI9で挙げる、APIの棚卸しの不足は、このときにも効いてきます。⁴

導入して使う側が備える項目

SaaSを導入して、自社の会員向けのコミュニティを運営している会社は、4つのことを備えられます。

預ける情報を、必要な項目だけに絞る。 会員のニックネーム、自己紹介、所属グループ。コミュニティに預けている項目は、運営の目的に本当に必要でしょうか。預ける項目が少ないほど、委託先で事故が起きたときの影響が小さくなります。メールアドレスなど、連絡に必要な項目と、それ以外を分けて考えます。

事故のときの連絡の条件を、契約で決める。 委託先が事故を知ってから、導入企業に連絡するまでの時間、連絡の中身、調査の結果の共有、利用停止の判断を誰がするか。これらを契約か運用の取り決めで決めておくと、動きが速くなります。今回の導入企業の発表には、委託先の停止から、報告を受け、個人情報保護委員会へ報告するまでが、日付つきで書かれています。³ 取り決めがあれば、この流れをさらに縮められます。

利用停止の手順と、会員への案内の文面を用意する。 事故が起きたら、コミュニティを止める判断を急ぐことになります。止めるボタンを誰が押せるか、止めている間の案内をどこに出すか、再開の条件は何か。あらかじめ決めておきます。会員への案内には、何が起きたか、どの情報が対象か、会員に何をしてほしいか、問い合わせ先、の4点を入れます。ユニリタは、事案に便乗した詐欺メールが届くおそれがあるとして、不審なリンクや添付ファイルを開かないよう、会員に呼びかけています。³

個人情報保護委員会への報告の担当と期限を決める。 報告が必要な事態は、要配慮個人情報を含む、財産的被害のおそれがある、不正の目的によるおそれがある、1,000人を超える、の4類型です。該当するときは、速やかに、概ね3〜5日以内を目安に速報を出し、30日以内(不正の目的によるおそれがある場合は60日以内)に確報を出します。⁶ 委託先との間で、誰が報告するかを、あらかじめ決めておきます。

会員と社員に伝えておくこと

事案のあと、会員向けには、コミュニティへの再ログインや、パスワードの再設定が必要になることがあります。今回も、全会員がログアウトされ、再開後に再ログインが必要とされました。仮パスワードに変更された会員は、再設定が必要です。² 手順の案内は、公式のサイトを経由するよう、はっきり書いておきます。

社員にも、同じことを伝えます。コミュニティの運営を担当する社員の管理者アカウントには、多要素認証を有効にし、他のサービスと同じパスワードを使い回さないこと。管理者のアカウントが乗っ取られたとき、会員情報が一度に見られることを、運営の担当者に共有しておくことが、いちばんの備えになります。

まとめ

公表されたのは、非公開コミュニティの招待リンクの不正取得と、管理者へのなりすまし、そして、メンテナンス中に残っていた通信経路を通じた2回目の漏えいです。最初の侵入の入口や、なりすましの仕組みは、まだ公表されていません。

運営側が見直せるのは、招待リンクの設計、管理者の権限の分離、署名鍵の分け方、テナントの境界、そして「止めた」の定義です。導入して使う側が備えられるのは、預ける項目の絞り込み、事故のときの連絡の取り決め、利用停止と案内の準備、報告の担当と期限の決め方です。

私は、いちばん差が出るのは、導入する前の確認だと考えています。委託先を選ぶときに、事故のときの連絡と、データの持ち方を、契約の前に確かめておくこと。続報が出たときには、この記事を更新します。社内の点検や、委託先の管理について相談したい方は、WARP SECURITYの個別相談からお声がけください。会員情報を返すAPIの点検は、ソースネクストの事案から学ぶ記事も参考になります。

参考

Footnotes

1. 国内のコミュニティ運営サービスへの不正アクセス、推計約30万人の個人情報が漏えい（報道）— INTERNET Watch（インプレス）— 2026年10月 ↩ ↩² ↩³ ↩⁴ ↩⁵

2. 国内のコミュニティ運営サービスへの不正アクセス まとめ（影響を受けた組織）（報道）— セキュリティ対策Lab — 2026年10月 ↩ ↩² ↩³ ↩⁴ ↩⁵

3. 【重要なお知らせ】外部委託先への不正アクセスによる弊社コミュニティ会員情報の漏えいについて — ユニリタ — 2026年10月13日 ↩ ↩² ↩³

4. OWASP API Security Top 10 2023 — OWASP ↩ ↩² ↩³

5. RFC 8725 JSON Web Token Best Current Practices — IETF — 2020年 ↩

6. 漏えい等の対応とお役立ち資料 — 個人情報保護委員会 ↩