--- title: "楽天ドライブの不正アクセスと保存データ1.5万件の流出｜管理用アカウントを守る認証と検知" url: "https://www.issoh.co.jp/tech/details/18187/" published: 2026-10-08 updated: 2026-10-08 categories: ["セキュリティ"] publisher: "株式会社一創" --- # 楽天ドライブの不正アクセスと保存データ1.5万件の流出｜管理用アカウントを守る認証と検知 楽天ドライブは2026年10月6日、第三者がシステムの管理用アカウントの認証情報を不正に取得し、利用者のアカウント情報と保存データを取得・閲覧したと公表しました。対象は3つの事象に分かれ、保存データ（写真・文書等）が取得されたアカウントは15,382件、期間は1月29日から9月17日までです。本記事では公式発表を整理し、313件で取得された「暗号化されたパスワード」の意味、利用者が今やるパスワード変更と保存ファイルの棚卸しをまとめました。後半では、利用者のデータを預かるサービスの開発者向けに、管理用アカウントのMFA必須化、パスワードの保管方式、大量読み出しの検知をIAMポリシーとPythonのコードで示します。 ## まとめ：楽天ドライブの不正アクセスで公表された3つの事象と利用者・開発者の対応 公表済みの事実は、管理用アカウントの認証情報が不正に取得されたこと、それによって3つの事象で情報が取得・閲覧されたこと、不正アクセス経路の遮断とアプリのダウンロード・新規アカウント発行の制限を行ったことです。認証情報が取られた経緯と、不正アクセスに気付いた日は発表に書かれていません。二次被害は現時点で確認されていないとされています。 利用者が最優先でやるのは、対象者向けの個別メールの確認と、楽天ドライブと同じパスワードを使っている他サービスの変更です。保存していたファイルに本人確認書類や取引先の資料があれば、その中身を前提に次の連絡を疑ってください。開発者側の教訓は、管理用アカウント1つの認証情報で利用者の保存データまで読めてしまう構成を見直すことにあります。 | 事象 | 取得・閲覧された情報 | 時期 | 件数 | | --- | ---------------- | ----------- | ------- | | 事象① | アカウント名・表示名・画像URL | 2026年8月27日 | 687件 | | 事象② | ①に加え暗号化パスワード等 | 2026年8月27日 | 313件 | | 事象③ | 保存データ（写真・文書等） | 1月29日〜9月17日 | 15,382件 | ## 公表内容を時系列で確認する｜7月の不審な通知から10月6日の発表まで ### 10月6日の発表で示された管理用アカウントの認証情報の不正取得という原因 [楽天ドライブの発表（2026年10月6日10時10分時点）](https://support.rakuten-drive.com/hc/ja/articles/62934949147929)は、原因を「第三者が楽天ドライブにて使用する一部システムの管理用アカウントの認証情報を不正に取得し、システムにアクセスした」と説明しています。脆弱性を突かれたのではなく、正規の管理用アカウントとしてログインされた構図です。 対応として挙げられているのは、不正アクセス経路の遮断と監視体制の強化、アプリのダウンロードと新規アカウント発行の制限、サイトでの告知と対象者へのメール通知、関係当局への報告の4つです。問い合わせ先には、お問い合わせフォームと臨時サポート窓口（0800-600-6600、年中無休9時〜17時、日本語のみ）が案内されています。 ### 7月30日の不審なプッシュ通知と当時「保存データへの不正アクセスは未確認」とした案内 楽天ドライブでは、7月30日12時55分ごろにアプリから送られたように見える不審なプッシュ通知が表示される事象も起きています。[当時の案内（更新版）](https://support.rakuten-drive.com/hc/ja/articles/61104873739545)によると、「YOUR RAKUTEN DRIVE HACKED」などの英語の件名で、偽のGoogleログインページやビットコインの請求画面へ誘導する内容でした。Webサイトは7月31日12時に一時停止し、8月4日15時に再開しています。 同じ案内には「楽天ドライブに保存されたデータへの第三者による不正アクセスは現在確認されておりません」との一文があります。一方、10月6日の発表は事象③の期間を1月29日からとしており、7月の時点ですでに保存データの取得が続いていたことになります。7月の不審通知と今回の管理用アカウントの件が同じ攻撃者によるものかどうかについて、公式の説明はありません。 ### 同時期のGyazo・タイムズカーの事案と比べた保存データ流出の共通点 2026年秋には、利用者がアップロードしたファイルを預かるサービスの事故が続いています。画像共有の[Gyazoの不正アクセスとアップロード基盤の見直し](https://www.issoh.co.jp/tech/details/17839/)、免許証画像を保管していた[タイムズカーの不正アクセスと保管設計](https://www.issoh.co.jp/tech/details/17925/)でも、問われたのは保存されたファイルそのものでした。 楽天ドライブの事案が違うのは、入口が管理用アカウントだった点です。利用者一人ひとりのパスワードを破られたのではなく、運営側の権限で多数の利用者のデータに届いています。対策を考える場所が、利用者の認証ではなく運営側の権限設計に移ります。 ## 3つの事象を仕分ける｜アカウント情報・パスワード・保存データの重さの違い ### 事象①と事象②で取得された項目の違いと687件・313件それぞれの悪用のされ方 事象①と②はどちらも2026年8月27日の1日に起きています。違いはパスワードに関わる情報の有無です。発表の項目を並べると次のとおりです。 | 項目 | 事象①（687件） | 事象②（313件） | | ------------- | --------- | --------- | | アカウント名 | 含む | 含む | | ディスプレイネーム | 含む | 含む | | プロフィール画像URL | 含む | 含む | | 暗号化されたパスワード | 含まない | 含む | | 復元を困難にする付加文字列 | 含まない | 含む | ディスプレイネームは、ファイル共有の際に相手に表示されるニックネームです。事象①だけの利用者は、共有相手を装った連絡や、アカウント名あての標的型のメールに注意が要ります。事象②の利用者は、それに加えてパスワードが解読される可能性を考えておく必要があります。 ### 暗号化されたパスワードと復元を困難にする文字列が意味するハッシュとソルト 発表で事象②の項目として記載されているのは「特殊な文字列に変換し復元を困難にした暗号化されたパスワード」と「パスワードの暗号化に際し復元を困難にするために加えた文字列」です。表現から読む限り、前者はパスワードのハッシュ値、後者はハッシュ化の際に利用者ごとに加えるソルトを指すと考えられます。用語の違いは[ハッシュ化と暗号化の違いとパスワード保管の仕組み](https://www.issoh.co.jp/column/details/13487/)で解説しています。 ソルトは秘密の値ではありません。ハッシュとソルトが一緒に取られても、攻撃者は候補のパスワードを1つずつ試して照合する作業をすることになり、その速さはハッシュの方式で大きく変わります。楽天ドライブがどの方式を使っていたかは公表されていません。短いパスワードや辞書にある単語は、どの方式でも先に当てられる側に入ります。 ### 1月29日から9月17日まで約8か月続いた事象③の保存データ取得の重さ 事象③は、15,382件のアカウントで楽天ドライブ上に保存されたデータ（写真・文書等を含む）が取得・閲覧されたというものです。期間は2026年1月29日から9月17日で、約8か月にわたります。事象①②が1日の出来事だったのに対し、事象③は長期間続いていました。 クラウドストレージに置かれるのは、スマートフォンの写真の自動バックアップ、契約書や請求書、本人確認書類の画像など、利用者にとって漏れてほしくないものが中心です。パスワードは変えれば無効にできますが、取られたファイルの中身は取り返せません。3つの事象のうち、利用者への影響が最も長く残るのは件数が最も多い事象③です。 ## 利用者が今やる対応｜通知メールの確認・パスワード変更・保存ファイルの棚卸し ### 対象者への個別メールと楽天ドライブを名乗る連絡を見分けるための確認先 対象者には、楽天ドライブから個別にメールなどで通知とお願いが送られます。ただし、メールが届いたこと自体を手掛かりにして本物と判断するのは危険です。7月には楽天ドライブを装った通知が実際に出回り、偽のログインページへの誘導が確認されています。 届いたメールのリンクは開かず、自分でブラウザに入力した楽天ドライブの公式サイトか、10月6日の発表に書かれたお問い合わせフォームと臨時サポート窓口（0800-600-6600）で確認してください。発表は、身に覚えのないログイン、心当たりのない請求、脅迫的な連絡に気付いたときは開封・対応せず、窓口か警察に相談するよう求めています。 ### 事象②の対象者と同じパスワードを他で使っている人が変更する順番 事象②の対象者は、楽天ドライブのパスワードを変更してください。対象かどうか分からない段階でも、楽天ドライブで使っていたパスワードを他のサービスでも使っている場合は、そちらの変更を急ぐほうが安全です。ハッシュが解読されると、同じメールアドレスとパスワードの組み合わせで他のサービスへのログインが試されます。 変更する順番は、メールアカウント、決済やネット銀行、楽天IDに結びつくサービス、その他の順にします。メールアカウントを先にするのは、他のサービスのパスワード再設定の連絡がそこに届くからです。どこで同じパスワードを使っているか思い出せない人は、パスワード管理ツールの導入を検討する機会にしてください。企業で社員のパスワードの決まりを作る立場の人は、[パスワード管理のベストプラクティスとNISTの指針](https://www.issoh.co.jp/column/details/13508/)も参考になります。 ### 保存していた写真・文書の中身から二次被害の範囲を見積もる手順 事象③の対象かどうかは個別の通知で分かります。対象だった場合は、保存していたファイルの中身から、次に起きうることを見積もります。 1. 楽天ドライブのフォルダを開き、1月29日以降に保存されていたファイルの種類を書き出す 2. 運転免許証・マイナンバーカード・パスポートの画像があれば、なりすましの申し込みに使われうるものとして扱う 3. 取引先の契約書・見積書・名簿があれば、勤務先と取引先へ報告する 4. 家族や知人の顔写真があれば、本人に事情を伝える 5. 共有リンクを発行していたファイルは、共有を止めて相手を確認する 仕事のファイルを個人のクラウドストレージに置いていた場合、漏えいは個人の問題で終わりません。勤務先の情報システム部門への報告を後回しにしないでください。 ## 管理用アカウントの認証を固める｜MFA必須化と利用者データへの到達経路の制限 ### 侵入経路が非公表の段階で利用者データを預かる開発者が自社で点検できる範囲 楽天ドライブの管理用アカウントの認証情報がどのように取られたかは公表されていません。ここから先は今回の原因を推測するものではなく、利用者のファイルや個人情報を預かるサービス全般で、開発者が自社を点検するための項目です。 点検の出発点は「管理用アカウントのパスワードやアクセスキーが1つ漏れたとき、何ができてしまうか」です。答えが「全利用者の保存データを読める」であれば、今回と同じ構図になりえます。保存先の仕組みは[クラウドストレージの仕組みと種類](https://www.issoh.co.jp/tech/details/15270/)で整理しています。止める手段は、ログインにMFAを必須にすること、利用者データに届く経路を絞ること、届いた操作を検知することの3段です。 ### AWSのIAMポリシーでMFAを伴わない管理操作と保存データの読み出しを拒否する設定例 利用者のファイルをAmazon S3に置く構成を例にします。[AWSのグローバル条件キーの説明](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference%5Fpolicies%5Fcondition-keys.html)によると、`aws:MultiFactorAuthPresent`は長期のアクセスキーで呼び出したときにはリクエストに含まれないため、拒否の条件には`BoolIfExists`を使うよう案内されています。`Bool`で書くと、アクセスキーによる呼び出しを拒否できません。 ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyUserFilesWithoutMFA", "Effect": "Deny", "Action": ["s3:GetObject", "s3:ListBucket"], "Resource": [ "arn:aws:s3:::example-user-files", "arn:aws:s3:::example-user-files/*" ], "Condition": { "BoolIfExists": {"aws:MultiFactorAuthPresent": "false"} } }, { "Sid": "DenyUserFilesWithStaleMFA", "Effect": "Deny", "Action": ["s3:GetObject", "s3:ListBucket"], "Resource": [ "arn:aws:s3:::example-user-files", "arn:aws:s3:::example-user-files/*" ], "Condition": { "NumericGreaterThanIfExists": {"aws:MultiFactorAuthAge": "3600"} } } ] } ``` 1つ目の文は、MFAを経ていない一時認証情報と長期のアクセスキーの両方で、利用者ファイルのバケットへの読み出しを拒否します。2つ目の文は、MFAから1時間（3600秒）を過ぎたセッションも拒否します。管理用アカウントのパスワードだけが漏れても、MFAの2つ目の要素がなければ保存データには届きません。MFAの方式ごとの強さは[多要素認証の実装方式と耐フィッシングMFA](https://www.issoh.co.jp/tech/details/13314/)で比べています。 ### 管理用アカウントから利用者の保存データを直接読めない構成にする条件と見送る場面 MFAを必須にしても、MFAごと乗っ取られれば保存データに届きます。もう一段の対策は、運用担当の管理用アカウントには利用者ファイルの読み出し権限を最初から与えず、問い合わせ対応などで中身を見る必要があるときだけ、承認を経て期限付きの権限を渡す運用です。 この分離を必須にすべきなのは、利用者が本人確認書類や業務文書を置くサービス、法人の利用者を抱えるサービス、運用担当者が10人を超えるサービスです。利用者数が数百人規模の社内システムで、管理者が2〜3人に限られている場合は、承認フローを作る工数に見合いません。その場合はMFAの必須化と、後述する読み出しの検知までで止めます。 ## パスワードの保管と大量閲覧の検知｜事象②と事象③を自社で防ぐ実装 ### ソルトとペッパーを分けて保管するPythonのscryptによるハッシュ化コード [OWASPのPassword Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password%5FStorage%5FCheat%5FSheet.html)は、Argon2idを第一候補とし、使えない場合のscryptの最低設定をN=2^17、r=8、p=1としています。ソルトはハッシュと一緒に保存してよい値で、別に用意するペッパーは「パスワードのデータベースとは分けて保管する」よう求めています。事象②のようにハッシュとソルトが一緒に取られた場合でも、ペッパーが別の場所にあれば照合を始められません。 ``` import hashlib import hmac import os PEPPER = b"load-from-secret-manager" MAXMEM = 256 * 1024 * 1024 def _derive(password, salt, n, r, p, dklen): key = hmac.new(PEPPER, password.encode(), hashlib.sha256).digest() return hashlib.scrypt(key, salt=salt, n=n, r=r, p=p, maxmem=MAXMEM, dklen=dklen) def hash_password(password): salt = os.urandom(16) dk = _derive(password, salt, 2**17, 8, 1, 32) return f"scrypt$17$8$1${salt.hex()}${dk.hex()}" def verify_password(password, stored): _, log_n, r, p, salt_hex, dk_hex = stored.split("$") dk = _derive(password, bytes.fromhex(salt_hex), 2**int(log_n), int(r), int(p), len(dk_hex) // 2) return hmac.compare_digest(dk.hex(), dk_hex) ``` [Pythonのhashlib.scrypt](https://docs.python.org/3/library/hashlib.html)はOpenSSLの機能を呼び出します。N=2^17、r=8では約128MiBのメモリを使うため、`maxmem`を指定しないとエラーになります。Python 3.14で実行すると、同じパスワードでも呼び出すたびに別のハッシュになり、正しいパスワードでは`True`、誤りでは`False`が返りました。1回の計算に秒単位の時間がかかる環境もあるため、ログインの待ち時間と合わせてパラメータを決めます。`PEPPER`は説明のための書き方で、実際は秘密情報の保管庫から読み込みます。 ### 管理用アカウントによる多数の利用者データの読み出しを日単位で検知する集計コード 事象③が約8か月続いたことは、管理用アカウントによる保存データの読み出しが長期間止められなかったことを示しています。運用担当者が利用者のファイルを開く場面は、通常は問い合わせ対応などに限られ、1日に何十人分ものファイルを開くことはまずありません。この性質を使って、1日に読み出した利用者の数で異常を拾います。 ``` import json from collections import defaultdict THRESHOLD = 50 def find_bulk_readers(lines): owners = defaultdict(set) for line in lines: ev = json.loads(line) if ev["action"] != "file.read": continue if not ev["actor"].startswith("admin:"): continue day = ev["time"][:10] owners[(ev["actor"], day)].add(ev["owner_id"]) return {k: len(v) for k, v in owners.items() if len(v) >= THRESHOLD} ``` 入力は、操作した主体（`actor`）、操作の種類、ファイルの持ち主（`owner_id`）、時刻を1行1件のJSONで記録した操作ログです。Python 3.14で、ある管理用アカウントが1日に60人分のファイルを読み、別の管理用アカウントが5人分を読んだ記録を渡すと、前者だけが`{('admin:ops01', '2026-08-27'): 60}`として返りました。しきい値の50は例で、自社の運用担当が普段開く人数の数倍に置きます。 ### 8か月気付けない状態を避けるログの保存期間と通知先の運用設計 検知のコードがあっても、ログが残っていなければ動きません。AWSなら、S3のオブジェクト単位の読み出しはCloudTrailのデータイベントを有効にしないと記録されません。設定と料金は[CloudTrailの証跡設計と料金実額](https://www.issoh.co.jp/tech/details/17649/)にまとめています。保存期間は最低でも1年とし、今回のように発覚が数か月後になっても、始まりの日まで遡れるようにします。 通知先に指定するのは、管理用アカウントを使う運用担当者とは別の担当者です。本人に届く通知は、本人のアカウントが乗っ取られたときに握りつぶされます。IDの乗っ取りを検知する製品の考え方は[ITDRの検知の仕組みと導入判断](https://www.issoh.co.jp/tech/details/13279/)で、ログから攻撃の痕跡を探す手順は[不正アクセスのログ確認・解析方法](https://www.issoh.co.jp/tech/details/2788/)で解説しています。 ## 漏えい等報告と外部点検の段取り｜利用者データを預かる自社が当事者になったら ### 個人情報保護委員会への漏えい等の報告対象と速報・確報の期限の確認 [個人情報保護委員会の案内](https://www.ppc.go.jp/personalinfo/legal/leakAction/)では、不正の目的をもって行われたおそれがある行為による個人データの漏えい等は、本人の数が1,000人を超える場合という件数の要件とは別の類型として、報告の対象です。速報は発覚から概ね3〜5日以内、確報は不正の目的によるものの場合60日以内とされています。楽天ドライブの発表も、対応の1つに関係当局への報告を挙げています。 保存データの中身を運営側が把握していないサービスでは、「どの個人データが漏れたか」を確報までに特定しにくいという問題があります。報告の4類型と、件数や中身が確定しない段階での速報の書き方は[個人情報保護委員会への報告義務と速報・確報の実務](https://www.issoh.co.jp/column/details/17840/)で解説しています。 ### 管理用アカウントの権限と認証基盤を外部の目で点検するときの順番 点検の順番は、管理用アカウントとアクセスキーの棚卸し、それぞれがMFAなしで使えないかの確認、利用者データに届く権限を持つアカウントの洗い出し、パスワードの保管方式とペッパーの保管場所の確認、管理操作のログの保存と通知先の確認です。[NIST SP 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html)のように、認証の強さを段階で定めた指針を物差しに使うと、どこまで固めれば足りるかの議論がしやすくなります。 運用担当が使う管理画面に後からMFAを足す、管理用の権限を期限付きで払い出す仕組みを作るといった改修は、既存の認証の作りに手を入れる工事になります。管理者と利用者の認証をまとめて設計し直したい場合は、[認証基盤・ID管理システム開発](https://www.issoh.co.jp/service/system/identity/)で、MFAの必須化から権限の払い出しと操作ログの設計まで相談できます。 ## よくある質問 楽天ドライブの不正アクセスについて、利用者と開発者から出やすい質問をまとめました。 ### 自分が対象かどうかはどうすれば分かりますか？ 対象となる利用者には、楽天ドライブから個別にメールなどで通知が送られると発表されています。自分で対象かを調べる画面は案内されていません。通知に似せた偽のメールも考えられるため、メールのリンクから操作せず、公式サイトのお問い合わせフォームか臨時サポート窓口（0800-600-6600、年中無休9時〜17時）で確認してください。 ### パスワードそのものが漏れたのですか？ 漏れたのはパスワードそのものではなく、復元を困難にする処理をしたパスワードと、その処理で加えた文字列で、対象は313件です。処理の方式は公表されていません。安全側に考えると、短いパスワードや推測しやすいパスワードは解読される可能性があります。対象者と、同じパスワードを他のサービスで使っている人は変更してください。 ### 保存していた写真や文書が見られた可能性があるのは何件ですか？ 保存データ（写真・文書等を含む）が取得・閲覧されたのは15,382件のアカウントです。期間は2026年1月29日から9月17日とされています。どのファイルが取得されたかの詳細は公表されていません。対象だった場合は、保存していたファイルの種類を書き出し、本人確認書類や仕事の資料があればなりすましや取引先への影響を前提に備えてください。 ### 7月の不審な通知と今回の不正アクセスは関係がありますか？ 公式の説明はありません。7月30日の不審なプッシュ通知について、当時の案内は保存データへの不正アクセスは確認されていないとしていました。10月6日の発表は保存データの取得期間を1月29日からとしていますが、2つの事象の関係には触れていません。報道やブログでの関連付けは推測として扱ってください。 ### 楽天ドライブを使い続けても大丈夫ですか？ 楽天ドライブは不正アクセス経路の遮断と監視体制の強化を行ったとしています。使い続けるかどうかは、置いているファイルの性質で判断するのが現実的です。本人確認書類や業務文書のように漏れたときの影響が大きいファイルは、端末内の暗号化された場所や勤務先が管理するストレージへ移し、写真のバックアップなど影響が限られる用途から残すかを決めてください。 ## 関連記事 - [Gyazoの不正アクセスと2,362万件の流出｜利用者の点検手順とアップロード基盤の見直し](https://www.issoh.co.jp/tech/details/17839/)：同時期に起きたファイル保管サービスの事案と対策 - [多要素認証（MFA）とは？3要素と実装方式・耐フィッシングMFAをコード付きで解説](https://www.issoh.co.jp/tech/details/13314/)：管理用アカウントに求めるMFAの方式を選ぶときに - [ハッシュ化とは？暗号化との違いとパスワード保管・改ざん検知の仕組みを解説](https://www.issoh.co.jp/column/details/13487/)：事象②で取得された情報の意味を確かめるときに - [CloudTrailとは？証跡設計と料金実額・Lake新規受付終了後の構成をCLIで解説](https://www.issoh.co.jp/tech/details/17649/)：保存データの読み出しを記録する設定 - [個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務](https://www.issoh.co.jp/column/details/17840/)：自社が当事者になったときの報告手順 --- 出典: [楽天ドライブの不正アクセスと保存データ1.5万件の流出｜管理用アカウントを守る認証と検知]()（株式会社一創）