楽天ドライブへの管理用アカウント認証情報の悪用による不正アクセス（15,382アカウント分の保存ファイル閲覧・取得）
公表日
ファイルを保存できるクラウドサービス「楽天ドライブ」で、運営側の管理用アカウントが悪用され、15,382アカウント分の保存ファイル（写真や文書など）が閲覧・取得されました。不正なアクセスは約8か月続いていました。
対象者は？
楽天ドライブの利用者のうち、15,382アカウントの保存ファイル（写真・文書など）が閲覧・取得されました。別に、687アカウントのアカウント名・表示名・プロフィール画像のURLが取得され、そのうち313アカウントでは、元に戻しにくく加工されたパスワードも取得されています。3つの範囲がどれだけ重なっているかは公表されていません。
対象の方には、メールで個別に連絡が行われています。臨時のサポート窓口（0800-600-6600、年中無休9〜17時）とお問い合わせフォームがあります。
いますぐできること
- 楽天ドライブに保存していたファイルに、身分証の画像や契約書など大事な書類がなかったか思い出し、あれば関係する手続き（カードの停止など）を検討する
- 楽天ドライブと同じパスワードを他のサービスでも使っていれば、そちらのパスワードを変更する
- 身に覚えのない請求や、保存していたファイルを材料にした脅しの連絡が来ても応じず、公式の窓口か警察に相談する
何が起きたのか
2026年1月29日から9月17日までの約8か月間、楽天ドライブの利用者が保存したファイルが、第三者に閲覧・取得されていました。8月27日には、アカウント名やパスワードに関する情報も取得されました。運営側は10月6日に公表し、アプリのダウンロードと新しいアカウントの作成を制限しました。なお、7月30日には、通知を配信する外部の委託先のシステムが不正アクセス使う権限のない人が、他人のIDやパスワード、システムの弱点を使って、サービスやサーバーに入り込むことです。日本では「不正アクセス禁止法」で禁止されている犯罪です。を受け、利用者に偽の通知が届く別の件もありました。
なぜ起きたのか・なぜ広がったのか
第三者が、楽天ドライブで使っている一部のシステムの管理用アカウントの情報を不正に手に入れ、システムに入り込みました。利用者のパスワードではなく、運営側のアカウントが入り口でした。その情報がどのように手に入れられたのか、いつ気づいたのかは、まだ公表されていません。正規の管理用アカウントでのアクセスだったため、長い期間にわたって続いた可能性があります。8月13日の時点では「保存データへの不正アクセス使う権限のない人が、他人のIDやパスワード、システムの弱点を使って、サービスやサーバーに入り込むことです。日本では「不正アクセス禁止法」で禁止されている犯罪です。は確認されていない」と案内されていましたが、実際にはその時もアクセスが続いていました。
いまの状況2026-10-08 時点続報待ち
不正なアクセスの経路は遮断され、監視が強化されています。アプリのダウンロードと新しいアカウントの作成は制限されたままで、再開の時期は発表されていません。公表の時点で、二次被害は確認されていないとしています。関係当局には報告済みです。入り口となった管理用アカウントの詳しい内容や補償の有無は、まだ発表されていません。
企業として考えたいこと
自社のサービスで、管理者用のアカウントからお客様のデータをどこまで見られるでしょうか。そのアカウントが乗っ取られて、少しずつ普段どおりに使われたら、気づける仕組みはあるでしょうか。
技術的な要約
2026年10月6日、楽天ドライブの運営側（公式ページに法人名の記載はなく、報道では楽天シンフォニー、一部報道は楽天グループと表記）は、サポートサイトで、第三者が同サービスで使用する一部システムの管理用アカウントの認証情報を不正に取得し、システムにアクセスしたと公表した。2026年1月29日から9月17日までの約8カ月間に15,382アカウント分の保存データ（写真・文書など）が閲覧・取得され、8月27日には687アカウントのアカウント名・ディスプレイネーム・プロフィール画像URL、313アカウントではこれに加え『暗号化』されたパスワードと暗号化時に付加した文字列（ソルトとみられる）が閲覧・取得された。認証情報の入手経路、MFAの有無、検知日は公表されていない。同サービスでは7月30日に外部委託先のプッシュ通知配信システムへの不正アクセスがあり、8月13日に更新した楽天モバイルのお知らせでも『保存データへの第三者による不正アクセスは現時点で確認されていない』と案内していたが、実際には当時も保存データへのアクセスが続いていたことになる。経路遮断・監視強化のうえ、アプリのダウンロードと新規アカウント発行を制限し、対象者へのメールでの個別通知と関係当局への報告を行った（二次被害は未確認）。公式ページは10月8日1時7分に更新されている。
攻撃の分類
- 侵入口
- 認証情報窃取・流用公表で確認公式表現：『第三者が、楽天ドライブで使用する一部システムの管理用アカウントの認証情報を不正に取得し、システムにアクセスした』。利用者のパスワードを狙ったものではなく運営側の管理用アカウントが起点。どのシステム（自社管理画面、クラウド基盤のコンソール、SaaS、開発基盤等）の管理用アカウントか、認証情報の入手経路（フィッシング、インフォスティーラー、委託先・従業員端末からの流出、使い回し等）、MFAの有無はいずれも非公表。7月30日の外部委託先プッシュ通知配信システムへの不正アクセスとの関連も公表されていない。
- 脆弱性
- 判明している脆弱性はありません
- 攻撃者
- 特定・主張なし
- ATT&CK
影響
- 業務停止
- なし 既存利用者向けのサービス停止は公表されていない。本件の対応としてアプリのダウンロードと新規アカウント発行を制限（公式。開始日は非公式の個人ブログが9月21日と記述、公式では未記載）。なお7月30日の別件では、7月31日12:00にWebサイトを一時停止し8月4日15:00に再開した（楽天モバイルのお知らせ、8月13日更新で確認）。期間：新規ダウンロード・新規アカウント発行の制限は2026-10-06時点で継続、再開時期は未発表
- データ
- 確定上限 15,382確定 15,382アカウント会員IDハッシュ化PWその他（保存ファイル：写真・文書等）その他（ディスプレイネーム、プロフィール画像URL）公式は『漏えいが確認された情報』として事象①〜③を記載（おそれではない）。事象1：2026-08-27、687アカウントのアカウント名・ディスプレイネーム・プロフィール画像URL。事象2：2026-08-27、313アカウントで事象1の項目に加え『暗号化されたパスワード』と『パスワード暗号化時に加えた文字列』（公式は『復元を困難にするため加工・暗号化』と説明。加えた文字列はソルトとみられる。平文パスワードの取得は記載なし。ケータイWatchは『特殊な文字列に変換されたパスワード』と表記。ハッシュか可逆暗号かは公式表現からは断定できないため、data_typesは便宜上ハッシュ化PWとした）。事象3：2026-01-29〜09-17、15,382アカウントの保存データ（写真・文書など）。3事象間の重複有無は非公表で合算不可（313が687の内数かについても報道で書き方が割れる）。records_maxは最大の事象3の値。保存ファイルの中身次第で本人確認書類等の高機微データが含まれ得るが、内訳は公表されていない。
- 波及先
- —
- 金銭影響
- —
- サプライチェーン
- 本件で悪用された管理用アカウントが委託先のものか、委託先経由で窃取されたかは非公表。別件として、2026年7月30日に楽天ドライブが利用する外部委託先のプッシュ通知配信システムが不正アクセスを受け（12:55頃から不審なプッシュ通知が表示。16:27頃遮断は報道ベース）、メールアドレスとシステム固有IDの閲覧可能性と偽通知の送信が発生しているが、本件との関連は公表されていない。
時系列
技術解説
攻撃の構造：運営側の管理用アカウントから利用者の保存ファイルへ 事実
公表によれば、攻撃者は利用者のパスワードではなく、楽天ドライブで使用する『一部システム』の管理用アカウントの認証情報を取得してシステムにアクセスした。その結果、15,382アカウントの保存ファイル（写真・文書）そのものと、1,000件弱のアカウント属性・パスワード派生値が閲覧・取得されている。管理用アカウントの権限で利用者のファイル本体に到達できたことから、少なくともその管理用アカウントにはストレージ上の利用者データを読む権限（または読める経路）があったことになる。どのシステムの管理用アカウントか、認証情報の入手経路、MFAの有無、アクセス元IPや操作の種類（管理画面からの閲覧か、API・ストレージへの直接アクセスか）はいずれも非公表で、技術的な侵入口はこれ以上特定できない。
時系列の食い違い：8月13日の『未確認』説明と実際のアクセス期間 事実
楽天ドライブでは7月30日12:55頃に外部委託先のプッシュ通知配信システムが不正アクセスを受け、偽の支払い失敗・アカウント停止通知がフィッシングページへ誘導した。7月31日には一時サイトを停止し一部楽天IDのパスワードを強制リセット、8月13日に更新した楽天モバイルのお知らせで運営側は保存データへの第三者の不正アクセスは確認されていないと説明し、8月28日の利用者向け通知でも保存データやパスワードは漏えいしていないとしていた。しかし10月6日の公表では、保存データへのアクセスは1月29日から9月17日まで続き、8月27日にはパスワード派生値まで取得されていた。つまり『確認されていない』と説明していた時点でも攻撃は進行中であり、2週間後にはさらに深い情報が取られている。7月の件と本件の関連は公表されておらず、同一攻撃者か、7月の件を受けた調査で本件が見つかったのかは不明である。
なぜ約8カ月気づけなかったのか（推測） 解釈
1月29日から9月17日まで約232日間、正規の管理用アカウントによるアクセスとして扱われていた可能性が高い。正規認証情報による操作は認証ログ上は成功ログインにしか見えず、アクセス元・時間帯・閲覧件数の異常を見る仕組みがなければ検知は難しい。特に管理者が日常的に利用者ファイルを閲覧する業務（サポート対応、違法コンテンツ審査等）がある場合、少数ずつの閲覧は業務ノイズに埋もれる。8月27日に属性データとパスワード派生値という『別種のデータ』が取られた点は、攻撃者が権限の範囲を探り始めた兆候とも読め、ここで検知できなかったことが結果的に約3週間の継続を許した。7月の委託先侵害を受けて監視を強めた結果9月に発見に至った可能性もあるが、検知日・検知契機は非公表であり、いずれも推測である。
件数とデータの読み方：小さく見えて重い 解釈
件数は最大15,382アカウントで①の100万件には遠いが、取得されたのは氏名やメールではなく利用者がクラウドに置いたファイル本体である。写真・文書には身分証の画像、契約書、医療関係の書類などが含まれ得るため、実際の機微度は利用者ごとに異なり、事業者側でも中身の分類はできていない可能性が高い。公表が『身に覚えのない請求、脅迫的な連絡』への注意を呼び掛けている点は、ファイル内容を材料にした恐喝・なりすましを想定していると読める。また313アカウント分は『暗号化されたパスワード』とソルトが同時に取られており、ハッシュ方式（アルゴリズム・ストレッチ回数）が弱ければオフライン解析で平文が復元される。3事象の重複関係が非公表のため、実人数の合計は算出できない。
対応
- 封じ込め
- 検知後に調査を開始し、不正アクセス経路を遮断、監視体制を強化（日付非公表）。アプリのダウンロードと新規アカウント発行を制限。7月の別件では偽通知の停止・アクセス遮断、7/31 12:00〜8/4 15:00のWebサイト一時停止、一部楽天IDのパスワード強制リセットを実施。
- 公表の仕方
- 2026-10-06（10:10時点）に「【重要】『楽天ドライブ』における不正アクセスの発生について」をサポートサイトで公表し、3事象ごとの日付・件数・項目を開示（10-08 01:07にページ更新）。対象者へメールで個別通知、お問い合わせフォームと臨時サポート窓口（0800-600-6600、年中無休9〜17時、日本語のみ）を案内。身に覚えのない請求・脅迫的な連絡・なりすましには対応せず窓口か警察に相談するよう呼び掛け。認証情報の入手経路・MFA・検知日・対象システム名・運営法人名は記載なし。7月の別件では8月13日時点で保存データへの不正アクセスは確認されていないと説明していた。
- 当局対応
- 関係当局へ報告（公式。当局名は非公表。個人情報保護委員会が想定される）
教訓と対策
| 教訓 | 具体的な対策 |
|---|---|
| 管理用アカウントの認証情報だけで利用者データに到達できた | 管理系はIdP経由のSSOに統一し、FIDO2/パスキー等のフィッシング耐性MFAを必須化。共有・サービスアカウントのパスワード認証を廃止し、短命トークン（OIDC/Workload Identity）とデバイス証明（管理端末からのみ）を条件付きアクセスで要求する |
| 管理者権限で利用者のファイル本体を読めた | サポート用途の閲覧はJust-In-Time承認（チケット番号・対象アカウント・有効時間を指定）でのみ付与し、通常の管理ロールからストレージ読み取り権限を外す。保存ファイルは利用者単位の鍵（KMS＋エンベロープ暗号化）で暗号化し、復号操作を全件監査ログに残す |
| 約8カ月間の正規アカウントによる不審アクセスを検知できなかった | 管理アカウントの操作ログ（閲覧対象ユーザー数、ダウンロード量、アクセス元ASN/国、時間帯）をUEBA/SIEMでベースライン化し、1日あたりの閲覧アカウント数や初出IPでアラート。ストレージのデータアクセスログ（S3 Data Events等）を有効化し、管理者主体の読み取りを日次レポートする |
| パスワード派生値とソルトが一緒に取得された | パスワードはArgon2id/bcrypt等の低速ハッシュで保存し、ソルトに加えてHSM/KMS管理のペッパーを適用してDB単独の流出ではオフライン解析できないようにする。可逆暗号で保存している場合は即時にハッシュ方式へ移行する |
| 別件の調査中に『保存データへの不正アクセスは確認されていない』と説明したが、実際には進行中だった | 初期公表では『確認されていない』と『調査範囲（どのシステム・期間・ログを確認したか）』を併記し、未調査範囲を明示する。周辺インシデント発生時は同一資格情報・同一管理系の全システムについて認証情報ローテーションとログ遡及調査を同時に実施する |
自組織などでの確認項目
- あなたのサービスで、運営側の管理アカウント1つが盗まれた場合、利用者のファイルやメッセージ本文まで読めるか。読めるとしたら、その権限は本当に日常業務に必要か。
- 管理者アカウントによる『正規ログイン・正規操作』が数カ月続いた場合、現在のログと監視で何日目に気づけるか。具体的にどのアラートが発火するか。
- 委託先のシステムで侵害が起きたとき、自社側の管理系認証情報のローテーションや遡及調査をどこまで、何日以内に行う手順になっているか。
- 調査途中で利用者に『現時点で被害は確認されていない』と伝える際、後で覆った場合の信頼低下をどう抑える書き方ができるか。
未解明点
- 悪用された管理用アカウントがどのシステム（自社管理画面、クラウドコンソール、SaaS、開発基盤等）のものか、認証情報の入手経路とMFAの有無
- 検知日・検知契機、経路遮断日（9月17日との関係）
- 7月30日の委託先プッシュ通知配信システム侵害、および10月4日の『楽天会員1億100万件』販売投稿と本件との関連
- パスワードの保存方式（ハッシュアルゴリズムか可逆暗号か）と、313アカウントのパスワードリセット有無
- 3事象間の重複と対象者の実人数、保存ファイルに含まれる情報の種類（本人確認書類等の有無）
- 報告先の関係当局名、アプリ配布・新規登録の再開時期と補償の有無
出典
- 1楽天ドライブ（公式ページに法人名の記載なし）2026-10-06公式本文確認済
- 2ケータイ Watch2026-10-06報道本文確認済
- 3INTERNET Watch2026-10-06報道本文確認済
- 4セキュリティ対策Lab（Rocket Boys）2026-10報道本文確認済
- 5Jetstream2026-10報道本文確認済
- 6Jetstream2026-08報道本文確認済
- 7innovaTopia2026-10報道本文確認済
- 8ITトレンド2026-10-07報道本文確認済
- 9pondaichi-act2.tech（個人ブログ）2026-10研究者本文確認済
- 10coki2026-10報道本文確認済
- 11楽天モバイル2026-08-13公式本文確認済