確認すべきは、管理者がどこまで顧客データにアクセスでき、その証拠がどこに残るかです。 楽天ドライブの公表は、利用者のパスワード対策だけでなく、特権IDと保存コンテンツを結ぶ経路を見直す契機になります。
楽天ドライブが確認したこと
同社は、第三者が管理用アカウントの認証情報を不正取得し、一部システムにアクセスしたと説明しています。10月6日の公式発表は、対象を次の3つに分けています。
| 事象 | 対象アカウント数 | 公表された時期 | 取得・閲覧された情報 |
|---|---|---|---|
| ① | 687件 | 2026年8月27日 | アカウント名、ディスプレイネーム、プロフィール用画像URL |
| ② | 313件 | 2026年8月27日 | 上記の項目と、変換処理されたパスワード、その保護のために加えた文字列 |
| ③ | 15,382件 | 2026年1月29日〜9月17日 | 写真・文書などの保存データ |
重複関係は説明されていません。件数を合算したり、15,382件すべてでパスワード関連情報も対象になったと解釈したりしないでください。 アカウント数はファイル数や実人数とは異なります。プロフィール用画像のURLと画像そのものも同一ではありません。
同社は、侵入経路の遮断、監視強化、アプリのダウンロードと新規アカウント発行の制限、利用者への通知、関係当局への報告を挙げています。公表時点で二次被害は確認されていないとしています。攻撃者、認証情報の窃取方法、パスワードのアルゴリズム、検知日は明らかにされていません。保存データの対象期間は、その全期間にわたる連続アクセスを証明するものではありません。公式発表。
セキュリティ態勢にどう影響するか
以下は同様の環境に向けた当サイトの分析であり、楽天ドライブの既存対策の有無を認定するものではありません。
1. 管理機能から顧客コンテンツへの経路を守る
一般利用者のログインと、事業者の管理用アクセスは別の信頼境界です。利用者の認証を強化しても、別の特権IDを掌握した第三者が、そのIDに認められた機能を使うことまで自動的に防げるわけではありません。
管理ロールごとに、アカウント一覧の取得、コンテンツの閲覧、ファイルの出力、利用者の代理操作、権限変更、アクセストークン発行の可否を整理します。サポート担当者が、内容を開かずにメタデータだけで対応できるかも確認してください。内容へのアクセスが必要なら、理由の記録、限定した承認、有効時間の制限、当該管理者が消せない監査証跡を組み合わせます。
自社では、管理者のフィッシング耐性のある認証、通常業務用と特権IDの分離、必要時だけの権限昇格、管理専用端末の対策、セッション失効を見直します。これらは確認項目であり、今回いずれかが欠けていたと断定するものではありません。
2. 保存ファイルの影響は、中身を調べなければ分からない
写真、契約書、データベースのエクスポートでは、対応の判断が異なります。対象となった従業員に、保存・共有した業務ファイル、責任者、他者の個人情報の有無、有効な認証情報や再利用可能な共有リンクの記載を確認してください。
アカウントとファイル単位で、ファイルID、所有者、機密性、アクセスイベント、時刻、実行ID、確度を記録します。閲覧成功、ダウンロード、メタデータの一覧取得、失敗した要求を区別します。事業者からファイル単位の証拠を得られない場合は、その制約を明記してください。利用者側のログに記録がないことを、安全の根拠にしてはいけません。
対象ファイルに秘密情報が含まれる場合は、証拠を保全したうえで該当する認証情報を失効・更新します。利用者のパスワードを変えても、既にコピーされた文書を回収したり、その中に記載された別の認証情報を無効化したりはできません。
3. パスワードの保護方式を示す表現だけでは安全性を判断できない
発表には、保護処理されたパスワードと追加文字列の説明がありますが、具体的な方式は示されていません。平文流出と決めつけることも、ハッシュ方式を特定することも、解析時間を見積もることも、全アカウントが即座に利用可能だと断定することもできません。
一般的なパスワードハッシュでは、一意のソルトにより、事前計算した候補の使い回しや同一パスワードの照合を難しくします。通常ソルトはハッシュと一緒に保存され、その流出だけでパスワードが判明するわけではありません。オフライン推測への耐性は、アルゴリズム、コスト設定、パスワードの強度にも左右されます。別に保護するペッパーは、ソルトとは異なる対策です。OWASPのパスワード保存ガイダンス。
ID管理チームが確認すべきなのは、対象の認証情報ストア、認証方式とアカウントの範囲、リセット・セッション失効・トークン無効化の必要性です。楽天ドライブの認証情報が、楽天の全サービスで同じように使えるとは仮定しないでください。
4. 証拠の調査期間を合わせる
直近7日間のダッシュボードでは、数か月に及ぶ保存データのアクセスを評価できません。ID、アプリケーション、ストレージ、サポートツール、セキュリティ製品のログを、保持期限で失われる前に保全します。各情報源について、完全な記録が残る最も古い日、タイムゾーン、収集の欠落を記録してください。
事業者側の調査では、安定したID・オブジェクトID・セッションIDを使い、特権ログインと、その後のファイルアクセスや権限変更を関連付けます。正規の一括サポート作業、移行、バックアップを不審な操作と区別する必要があります。件数の多さは調査の入口であり、侵害の判定そのものではありません。
どのチームが何を確認するか
| チーム | 判断と具体的な対応 | 必要な証拠 |
|---|---|---|
| IT運用・IAM・クラウド | 管理権限を限定し、侵害された認証情報、セッション、トークン、委任ロールを確認する。 | ロール変更履歴、認証イベント、セッション失効と認証情報更新の記録。 |
| SIEM・SOC | 認証からファイルアクセスまでを再構成し、ログ保持の欠落を明記する。 | 管理操作、閲覧・ダウンロード・出力のイベント、オブジェクトIDとセッションID、収集範囲。 |
| 委託先リスク管理・データ責任者 | 組織内の利用、対象アカウント、業務ファイルを把握し、個別の影響範囲を事業者に求める。 | 事業者からの通知、アカウント・ファイル台帳、続報。 |
| 法務・プライバシー | ファイル内の情報と対象者を確認し、契約と適用法令に応じた義務を専門家と判断する。 | データ項目、対象者との対応関係、証拠の確度、対応判断の記録。 |
| メールセキュリティ・サービスデスク | 漏えいした文脈を利用するサポート・復旧・請求・脅迫の連絡に備える。 | ヘッダーを含む通報メール、誘導先URL、確認済みの事業者連絡。 |
| EDR | 管理者端末や、不審な追加ファイルを開いた利用者など、関連のある端末を調べる。 | ブラウザー・プロセス履歴と端末ログ。利用者端末の異常なしという結果だけでは、事業者側の侵害を否定できない。 |
7月の不審な通知とは、関係を断定しない
楽天ドライブは以前、不審なアプリ通知から偽のGoogleログイン画面や暗号資産での支払い要求へ誘導される例を案内していました。その発表は、当時の調査結果と対応を述べたものです。10月の発表は、その通知事案と今回の情報取得が同じ攻撃者・侵入経路によるものだとは示していません。 1つの確定した攻撃経路として結び付けないでください。以前の公式注意喚起（英語）。
実務上は、緊急性を強調する連絡を別経路で確認することが重要です。既知のサービスやサポートページを自分で開いてください。ブランド、見覚えのある表示名、具体的な文書への言及だけでは、正当な連絡だと判断できません。
IOCと実務的なハンティング
確認した10月の発表には、再現可能なIOC検索に使える攻撃者のIP・ドメイン・ファイルハッシュ・CVEは掲載されていません。 楽天ドライブの正規ドメインは参照先であり、遮断用IOCではありません。
以下の2本は、自社の特権認証を確認するための出発点です。今回の侵害を検出するルールではなく、楽天ドライブがMicrosoft Entra IDや以下のSplunkスキーマを使っているという主張でもありません。事業者内部のファイルアクセスや、対象顧客を確認することはできません。
KQL：対象を限定して管理者の成功ログインを確認する
Microsoft Sentinel／Azure Monitor Logsで、Entraの対話型サインインがSigninLogsに取り込まれ、下記のフィールドとワークスペースへの検索権限がある場合の例です。2つのプレースホルダーを自社の管理者UPNとアプリケーションIDに置換します。管理者リストは承認済み範囲だけに限定してください。7日間の成功イベントを最新200件まで返し、攻撃を自動判定するものではありません。Microsoftのテーブル定義。
let EndTime = now();
let StartTime = EndTime - 7d;
let AdminUPNs = dynamic(["REPLACE_WITH_ADMIN_UPN"]);
let TargetAppId = "REPLACE_WITH_APPLICATION_ID";
SigninLogs
| where TimeGenerated between (StartTime .. EndTime)
| where UserPrincipalName in~ (AdminUPNs)
| where AppId == TargetAppId
| where ResultType == "0"
| project TimeGenerated, UserPrincipalName, AppDisplayName, AppId,
IPAddress, UserAgent, AuthenticationRequirement,
ConditionalAccessStatus, CorrelationId
| order by TimeGenerated desc
| take 200
送信元IP、アプリの文脈、認証の詳細を承認済み操作と比較します。VPN、出張、正規の管理操作でも見慣れないイベントは発生します。認証の要約フィールドだけでは、各アクセスで新たにフィッシング耐性のある認証が行われたとは証明できません。非対話型トークン、サービスプリンシパル、別のIdP、保持されていないログは別途確認が必要です。過去の事案では、管理可能な期間ごとに検索範囲を広げてください。
Splunk SPL：IDと送信元ごとに認証成功を集計する
検索権限のあるインデックス・sourcetypeで、user、src、dest、app、action、_timeがCIM Authenticationの定義に沿って抽出されている場合の例です。成功がaction="success"にマッピングされることを確認します。アプリケーションと管理者を含む全プレースホルダーを置換してください。7日間を検索し、ID・送信元の組み合わせを最大100組返します。
index="REPLACE_WITH_AUTH_INDEX" sourcetype="REPLACE_WITH_AUTH_SOURCETYPE"
earliest=-7d latest=now
app="REPLACE_WITH_ADMIN_APPLICATION" user="REPLACE_WITH_ADMIN_ID"
action="success"
| stats count AS successful_events min(_time) AS first_seen
max(_time) AS last_seen values(dest) AS destinations by user src
| sort 0 - successful_events
| head 100
| convert ctime(first_seen) ctime(last_seen)
初回・最終時刻は検索期間内の値であり、IDの利用開始以来の値ではありません。共通の出口IP、自動処理、保守作業でもまとまった成功イベントが生じます。フィールド抽出の欠落やsrcの欠損は、この集計から活動を見えなくすることがあります。封じ込めを決める前に元イベントを確認し、アプリケーションのファイルアクセスログと関連付けてください。認証だけでは、ファイルをダウンロードしたとは分かりません。
クエリのダウンロード：KQL · Splunk SPL。
クエリの確認状況： 2026年10月6日に上記のスキーマ文書と照合しました。実環境のSentinel・Splunkでは実行していません。日英のコードは同一です。結果がないことは、安全の証明ではありません。
対象となった利用者ができること
楽天ドライブの公式サポートで通知の真偽と自分のアカウントの範囲を確認します。公式窓口を別途開き、アカウントごとの復旧案内に従ってください。影響が疑われるパスワードを他のサービスでも使い回していた場合は、それぞれ固有のものに変更し、利用できるセッション管理や認証保護も確認します。
機密性の高い保存コンテンツを整理してください。業務文書、本人確認書類、他者の個人情報が含まれる場合は、既存のインシデント対応手順で組織内のデータ責任者に連絡します。不審な添付を開いたり支払い要求に返信したりせず、メッセージと証拠を保全してください。「流出ファイルを削除できる」とする連絡や、有料の復旧勧誘にも注意が必要です。
今後確認したいこと
続報で確認したいのは、管理者認証情報の取得方法、対象ロールとシステム境界、閲覧とコピーを区別するログ、アカウント群の重複、対象ファイル、認証情報の保護パラメーター、封じ込め・復旧を裏付ける証拠の範囲です。
不明点を根拠に、特定の脆弱性、ランサムウェア集団、MFAの欠如、他の楽天サービスへの影響を断定することはできません。出典を確認できる情報が得られた時点で分析を更新します。
2026年10月6日 — 初版公開。 リンク先の公式発表と技術文書に基づく独立した日英分析です。影響範囲の表は同社の3区分に従っています。流出ファイル、非公開のテナント情報、架空のIOCは使用していません。