さくらインターネット第三報、136万件より重い「最長約3年」｜「流出の明確な事実なし」を安全と読まない

さくらインターネットは2026年9月10日、同社システムへの不正アクセスについて第三報を公表しました。販売管理システムに保存されていた会員情報等について、第三者が閲覧または取得した可能性がある対象は1,360,563アカウントです。しかし、経営者が自社へ置き換えて読むべき論点は、この大きな数字だけではありません。

第三報では、販売管理システムへの不正アクセスが2023年4月以降、2026年3月までの間に発生していたことが確認されました。レンタルサーバー環境には2025年7月以降と考えられる不審な活動の痕跡がありましたが、時間の経過に伴う記録の制約等により、今回の事案との同一性、具体的な侵入経路、顧客情報への影響を客観的に確認するには至っていません。また、販売管理システムには一部サービスの初期管理パスワードがハッシュ化されずに保存されていました。

一方、同社は、データが外部へ持ち出されたことを裏付ける明確な事実や、本件に起因する二次被害を現時点で確認していないと説明しています。ここで「明確な事実が確認されていない」を「アクセスも持ち出しもなかった」と読み替えてはいけません。事故報告では、確認できた事実、可能性がある範囲、記録不足などで判定できない範囲を分ける必要があります。

本記事は個社の対応を外部から採点するものではありません。公表された第三報を教材に、経営者が自社のログ保管、初期認証情報、管理環境、委託先との責任分界をどう見直すかを整理します。

結論：件数ではなく「証拠を出せる期間」と「初期認証情報の寿命」を聞く

経営会議で確認すべき質問は二つです。

第一に、「不正アクセスが疑われたとき、何か月前まで、どのシステムで、誰が何をしたかを証拠で追えるか」です。ログの保存期間だけでなく、必要なログを取得しているか、時刻が合っているか、検索できるか、退職者や委託先の操作と結び付けられるかまで確認します。

第二に、「システムが発行した初期パスワードは、利用者が変更するまで残るのか、初回利用後に失効するのか」です。初期パスワードを平文で長期保存し、現在も使われている契約を後から探す運用では、販売管理システムの侵害がサービス環境への足掛かりに広がる可能性があります。初期値は配布したら終わりではなく、発行、本人確認、初回変更、失効、再発行、監査までを一つのライフサイクルとして設計します。

「ログを取っています」「パスワードは暗号化しています」という回答だけでは足りません。調査対象期間のログを実際に検索した記録と、初期認証情報が残っていないことを示す件数表を証拠にします。

第三報の数字を混同しない

第三報には、性質の異なる複数の対象数が出ています。1,360,563、951、30を足したり、すべてを同じ被害件数と表現したりするのは誤りです。

さらに、同社はクレジットカード情報を保持しておらず、入力画面の改ざんも確認していないため、カード番号の漏えいのおそれはないと説明しています。「会員情報」という言葉から、保存していないカード番号まで対象だと広げてはいけません。

事故報告は「確認済み・可能性・判定不能」の3列で読む

インシデントの経営判断では、二択が危険です。「漏えいした」か「漏えいしていない」かを急いで決めると、証拠の限界を見落とします。第三報を三つの状態へ分けると、必要な対応が見えます。

「外部持ち出しを裏付ける明確な事実は確認されていない」は、確認済みの事実です。ただし、「持ち出しがなかったことを証明した」と同義ではありません。同社自身も、可能性がある情報の範囲を示し、対象者への案内と監視を続けています。経営者は、断定できない状態でもどの水準で顧客保護を実行するかを決めなければなりません。

個人情報保護委員会は、一定の漏えい等またはそのおそれを報告対象とし、不正の目的で行われたおそれのある行為や、本人1,000人を超える漏えい等のおそれなどを例示しています。報告要否は「持ち出しが確定したか」だけで決まりません。自社事故では、法務・個人情報保護担当と専門家に早期相談し、速報・確報の期限を確認してください。

最大の落とし穴1：ログの「保存期間」だけを仕様書に書く

ログ保管についてよくある発注ミスは、「ログを1年間保存する」とだけ仕様書に書くことです。一年分のファイルがあっても、必要な認証ログが含まれない、機器ごとに時刻がずれている、利用者IDと実在の担当者が結び付かない、検索に数週間かかる、委託先が持っていてすぐ出せないなら、事故調査の証拠として使えません。

最低限、次の七列をログ台帳に置きます。

保管期間の正解は、すべての会社で同じではありません。攻撃が発覚するまでの時間、個人情報・契約・業法上の要求、ストレージ費用、調査能力で決めます。ただし、短くする判断は「容量が高いから」だけでなく、「過去何か月より前は判定不能になる」という経営リスクを伴います。その残余リスクを責任者が承認し、代わりに重要操作のログだけ長期保管するなどの設計を選びます。

最大の落とし穴2：初期パスワードを「一時的な情報」と思い込む

第三報では、販売管理システムに、レンタルサーバーの一部の初期サーバーパスワードと、VPSの一部の管理者初期パスワードが保存されていたと説明されています。これらは30アカウントのハッシュ化された会員IDのパスワードとは異なり、ハッシュ化されていない情報でした。同社は、影響可能性がある初期パスワードが現在も利用されている契約について変更等の対応を行っています。

自社システムでも、「初回ログイン時に変更してください」と画面に書くだけでは、変更されないアカウントが残ります。初期認証情報は次の八項目で検収してください。

1. 初期値は利用者ごとに異なり、推測できない十分な長さか。
2. 配布経路は、ログイン画面と同じメールだけに依存していないか。
3. 初回ログインで変更を強制し、変更前は本来の機能を使えないか。
4. 未使用の初期値は短期間で自動失効するか。
5. 初期値の平文を業務データベースへ長期保存していないか。
6. 問い合わせ担当者が本人確認なしに初期化できないか。
7. 再発行時に以前の値が無効になり、監査ログが残るか。
8. 初期値の利用件数、未変更件数、期限超過件数を月次で確認できるか。

八つのうち一つでも確認できないなら、ベンダーへ画面説明ではなく、設定、データ保持、失効処理、監査ログの仕様を求めます。とくに「平文ではない」という説明は、可逆暗号化なのか、復元不能なハッシュなのか、秘密管理基盤で保護された一時値なのかを分けて確認します。用途によって適切な保存方法が異なります。

最大の落とし穴3：管理システムとサービス環境を別物として発注する

販売管理、顧客管理、請求、サポートの各システムは、顧客向けサービス本体と分かれていても、契約情報、初期設定、管理権限、連絡先を通じて接続します。攻撃者にとって、直接サービス基盤を破るより、管理系から認証情報や構成情報を得るほうが容易な場合があります。

発注時は、システムごとの境界だけでなく、境界を越えるデータと権限を書きます。販売管理からサービス環境へ渡る初期設定、保守ツールから本番へ接続する経路、問い合わせ担当が実行できるパスワード再発行、顧客一覧の出力権限などです。構成図に線が一本あればよいのではなく、その線で「誰が、何を、どの条件で動かせるか」が必要です。

重要システムの更新後にログと権限を確認する観点は、基幹システムの緊急更新後に確認するログレビューでも整理しています。更新が成功しても、古い認証情報、管理経路、監視の空白が残れば、運用上の入口は消えません。

自社の証拠十分性を15分で確認する10問

次の質問を、経営者、情報システム、開発・保守会社の三者へ同時に聞いてください。回答が一致しない箇所が、責任分界の空白です。

1. 重要システムごとに、調査可能な最古の日付はいつか。
2. 管理者の成功・失敗ログと、データ出力・閲覧ログは別に取れているか。
3. 委託先担当者の操作を、会社名ではなく個人まで特定できるか。
4. ログの削除権限を持つ人と、監査する人は分かれているか。
5. 一年前の日付を指定し、二時間以内に認証履歴を提出できるか。
6. 初期パスワードが現在も有効なアカウントは何件か。
7. 初期値、再発行値、現在値はどこにどの形式で保存されるか。
8. 販売管理や顧客管理から、本番サービスを操作できる権限は何か。
9. 不正アクセスを疑ったとき、誰が保存期間満了前のログを保全するか。
10. 「確認できない」範囲を顧客・監督機関へ誰が説明するか。

答えが「ベンダーへ聞かないと分からない」でも、直ちに失格ではありません。ただし、ベンダーへの連絡先、回答期限、ログの提出形式が契約にないなら、事故時に調査が止まります。中小企業のセキュリティ外注先の選び方を使い、平時の保守、監視、事故調査、法務、広報の役割を分けてください。

7日、30日、90日で直す

7日以内：初期認証情報とログ消失を止める

• 全サービスの初期パスワード未変更件数と共有管理者IDを抽出する。
• 退職者、異動者、終了した委託先のアカウントを停止する。
• 事故が疑われる場合は、上書き・自動削除される前に対象ログを保全する。
• 外部公開資産と管理系システムの接続経路を一枚にする。
• 緊急連絡先と、法務・個人情報保護の判断者を決める。

事故の兆候がすでにある会社は、通常の改善計画より先に証拠保全と封じ込めが必要です。独断で端末やサーバーを初期化すると調査証拠が失われることがあるため、外部専門家や警察と相談してください。インシデント対応支援の対象は、こうした緊急時の初動整理です。

30日以内：一件を最後まで追う

• 架空の不審ログインを設定し、認証からデータ閲覧・出力まで時系列で追う。
• 一年前のログを検索し、提出にかかった時間と欠落項目を記録する。
• 初期パスワードの自動失効と初回変更強制を検証環境で試す。
• 販売管理、顧客管理、サービス基盤の権限対応表を作る。
• 保守会社から受け取れるログ、受け取れないログ、追加費用を確認する。

「全ログを確認する」必要はありません。重要業務を一つ選び、利用者作成、初回認証、権限変更、データ閲覧、退職時失効まで一本の流れを追います。途中で証拠が切れる場所が、次の投資対象です。

90日以内：契約と設計へ固定する

• ログ台帳の七列と初期認証情報の八項目を、要件定義・検収条件へ追加する。
• 保存期間、緊急提出時間、調査支援の追加費用を保守契約へ明記する。
• 本番、管理、開発、バックアップのネットワークと権限を分離する。
• 重要システムへ監視を追加し、検知から経営報告までの訓練を行う。
• 四半期ごとに未変更初期値、休眠ID、例外権限を経営会議へ報告する。

発注書・保守契約へ入れる検収条件

新しいシステムでは、完成画面の確認だけでなく、事故後に説明できることを検収します。例えば「管理者の認証成功・失敗、権限変更、個人情報の検索・出力が個人IDと時刻付きで記録され、指定期間保管される」「初期パスワードは初回利用または発行後72時間で失効し、平文で永続保存されない」「重大事故の連絡から四時間以内に対象ログを保全して提出する」といった条件です。

数字は自社のリスクと運用能力に合わせます。重要なのは、保存する、適切に管理する、速やかに対応するという曖昧語を減らすことです。誰が、何を、何時間以内に、どの形式で、いくらで行うかを書かなければ、事故時に発注側と受注側の理解が分かれます。

すでに稼働しているシステムで要件書がない場合は、脆弱性を経営課題として整理する基礎を入り口に、資産、責任者、更新期限、例外理由を一覧化してください。仕様を作り直すより、まず現在の証拠を集めたほうが、改修の優先順位を決めやすくなります。

「流出なし」と言い切らない広報の確認表

事故公表では、短く安心させようとするほど誤解が生じます。公表前に次を確認します。

• 「確認されていない」の対象は、外部持ち出し、公開、不正利用、金銭被害のどれか。
• 調査した期間、システム、ログ、外部機関の範囲が示されているか。
• 記録不足や技術的制約で確認できない範囲が分かれているか。
• 影響可能性の対象数と、実際に閲覧・取得されたと確認した数を区別しているか。
• 顧客が今取るべき行動と、便乗詐欺への注意が明確か。
• 次の更新条件、問い合わせ窓口、個別通知の範囲があるか。

「現時点で」「裏付ける明確な事実」「可能性がある」といった限定は、逃げの表現ではありません。証拠に合わせた正確な説明です。ただし見出しで限定を落とし、「流出なし」だけを強調すると、本文との意味が変わります。経営者は広報・法務・技術の三者が同じ事実分類を使っているかを確認します。

GXOのセキュリティ優先順位診断

自社のログと認証情報について、保守会社の説明だけでは判断できない場合は、GXOのセキュリティ優先順位診断で、重要システムを一つ選び、証拠の連続性を確認できます。対象資産、認証、操作ログ、保管期間、検索手順、初期値の失効、委託先の提出条件を「確認済み」「可能性」「判定不能」に分け、直ちに直す項目と契約更新時に直す項目を整理します。

目的は、あらゆるログを長期保存することではありません。売上停止、顧客説明、法令報告に必要な証拠を、会社の規模に合う費用で残すことです。ログ製品や認証製品を選ぶ前に、何を何日分追えなければ経営判断が止まるかを決めます。

よくある質問

Q. 1,360,563アカウントの情報がすべて漏えいしたのですか。 A. 第三報は、販売管理システムに保存されていた会員情報等について、第三者による閲覧または取得の可能性がある対象総数と説明しています。全対象の全情報が実際に閲覧・取得されたと示す数字ではありません。また、同社はカード情報を保持していないと説明しています。

Q. 外部持ち出しの明確な事実がないなら、通知や対応は不要ですか。 A. 不要とは限りません。個人情報保護委員会は、一定の漏えい等だけでなく「おそれ」も報告対象にしています。個別事案の報告・本人通知の要否と期限は、対象情報、件数、原因、法令・業法を踏まえて専門家へ確認してください。

Q. ログは何年間残せばよいですか。 A. 一律の年数を本記事では示しません。重要データ、攻撃の発覚までの想定期間、法令・契約、調査費用をもとに決めます。年数だけでなく、必要項目、時刻同期、改ざん耐性、検索可能性、事故時の提示時間をセットで検収してください。

Q. パスワードをハッシュ化すれば十分ですか。 A. ログイン判定用の現在パスワードと、利用者へ一時的に伝える初期値では、必要な処理が異なります。保存形式だけでなく、初回変更の強制、短期失効、再発行、アクセス権、監査を含むライフサイクル全体を確認します。

Q. クラウド事業者へ任せていれば、自社でログを持たなくてもよいですか。 A. 事業者がログを保持していても、自社の契約プランで取得できる範囲、保存期間、事故時の提供時間、追加費用は別問題です。自社が顧客や監督機関へ説明する責任を果たせるよう、契約と手順を確認してください。

この記事の確認範囲

本記事は、さくらインターネットが2026年9月10日に公表した第三報と、個人情報保護委員会の「漏えい等の対応とお役立ち資料」を2026年9月11日に確認して執筆しました。第三報の「確認した」「可能性がある」「明確な事実は確認されていない」「記録の制約等により客観的に確認するには至らなかった」を区別しています。

本記事は、公表外の侵入経路、攻撃者、実際の情報持ち出し、法令報告の内容を推測していません。「最長約3年」は、販売管理システムへの不正アクセスが2023年4月以降から2026年3月までの間に発生していたという公表期間を読みやすく要約した表現であり、約3年間連続して侵入状態だったと断定するものではありません。公表後に第四報、訂正、監督機関の判断が追加されていないか、個別判断の直前に一次資料を再確認してください。

参考資料

• 当社システムへの不正アクセスに関する調査結果および再発防止策について（第三報）（さくらインターネット・2026年9月10日）
• 漏えい等の対応とお役立ち資料（個人情報保護委員会）