さくらインターネット不正アクセス事件に学ぶ「委託先が破られた側」に立った時の実務対応
投稿日:2026.08.20
CATEGORY
- Web開発
さくらインターネットは 2026 年 8 月 17 日、「さくらのレンタルサーバ」の一部顧客環境が第三者による不正アクセスを受けたと発表しました。その 2 日後の 8 月 19 日には、これとは別に、顧客の契約情報を管理するシステムでも不正アクセスの可能性があり、最大で約 136 万アカウントの契約情報に影響が及ぶ可能性があると公表されています。ただし、第一報だけを見て「自分の契約先ではないから関係ない」と判断すると、この続報の内容を見落とす可能性があります。

経緯 — 583 アカウントの不正ログインと、別システムで判明した約 136 万アカウントへの影響
第一報と第二報の間には、規模と発生時期の両方で大きな差があります。この差そのものが、事件の実態を理解するための出発点になります。
さくらインターネットの発表によると、同社は 2026 年 8 月 9 日にサーバ環境の異常を検知し調査を開始しました。調査の結果、第三者が同社の管理環境を経由して顧客環境へ不正アクセスしていたことが判明し、583 アカウントへの不正ログインと、一部サーバへのマルウェア設置が確認されています。漏えいの可能性がある情報は、顧客領域内に保存された情報や利用者識別子で、攻撃者が「通信の秘密」(通信の内容や当事者に関する情報を無断で第三者に開示・利用することを禁じる保護原則)に該当する情報にアクセス可能だったことも確認されたと報じられています。ここまでが 8 月 17 日の第一報の内容です。

ところが、その調査を進める過程で、8 月 19 日に第二報が公表されます。顧客の契約情報を管理する「販売管理システム」にも第三者による不正アクセスの可能性があることが新たに判明し、このシステムへの侵害は、レンタルサーバへの攻撃を検知した 8 月 9 日より前に発生していた可能性があるとされています。影響範囲は、最大で約 136 万アカウントの契約情報が閲覧・取得された可能性がある規模だとされ、うち 30 アカウント分についてはハッシュ化されたパスワード情報へアクセスされた可能性も判明したと発表されています。583 アカウントという第一報の数字だけでは見えていなかった被害の広がりが、この第二報で新たに明らかになった形です。
なお、583 アカウントの被害と約 136 万アカウントの被害の関連性については、さくらインターネット自身が「関連性を含め調査継続中」としており、2 つの侵害がどうつながっているかは本稿執筆時点では確定していません。
なぜ影響が大きいか — 「サーバの中身」ではなく「契約情報そのもの」が対象になった
この事件が実務上重い理由は、漏えいの可能性がある情報の種類にあります。第二報で対象とされた情報は、会員 ID・会社名・部署名・住所・氏名・電話番号・メールアドレス・生年月日・性別・FAX 番号・契約サービス・契約期間・請求金額と報じられており、単なるログイン痕跡ではなく契約者を特定できる個人情報・法人情報のまとまりです。
さらに、うち 30 アカウント分についてはハッシュ化されたパスワード情報へアクセスされた可能性も判明しています。ハッシュ化されているとはいえ、対象アカウントが同じパスワードを他のサービスでも使い回していれば、そちらへの不正ログインに転用されるリスクが生まれます。583 アカウントの「サーバ内の情報」と、約 136 万アカウントの「契約情報」は、影響を受ける情報の性質が異なる別レイヤーの被害だと理解しておく必要があります。
自社が同じ立場に置かれたら何を確認・実行すべきか
レンタルサーバやクラウドサービスを使っている以上、自社の委託先が同じような通知を出す立場になる可能性は誰にでもあります。フォレンジック調査の結果を待つ間にも、自社の担当者が今日から着手できる対応があります。
パスワード使い回しの確認。契約している委託先のアカウントで使っているパスワードを、他のサービスと使い回していないか確認します。今回のように一部アカウントのパスワード情報へアクセスされた可能性がある事案では、使い回し先のサービスまで被害が波及するリスクがあります。使い回しがあれば、通知を待たずに変更しておく方が安全です。
二要素認証の状態確認。委託先のサービスに二要素認証の設定があるなら、有効になっているかを確認します。パスワードだけに依存しない認証手段があれば、認証情報が漏えいした場合でも不正ログインの成立を難しくできます。
委託先が調査を進めている間は、今回のように続報が段階的に出ることがあります。第一報から 2 日後に対象範囲が大きく変わる第二報が出た今回の事件は、その典型例です。だからこそ契約先からの通知を監視する体制を先に作っておく必要があります。委託先からのメール・お知らせページ・プレスリリースを定期的に確認する担当者を決めておくと、続報を見落とさずに済みます。
フォレンジック公表を待つ間の対応方針を決めておく。調査結果が出るまでの間、社内向け・取引先向けにどこまで情報共有するか、問い合わせが来た時に誰が答えるかを事前に決めておくことが実務上の備えになります。詳細が分からない段階で憶測を発信するのは避けつつ、「委託先で調査中の事案があり、状況を注視している」という事実は共有できる形にしておくと、後から状況が動いた時に慌てずに済みます。
以上の 4 点はいずれも、委託先からの続報の内容が確定する前に着手できます。パスワード使い回しの確認と二要素認証の状態確認はすぐに完了し、残る 2 点(通知の監視体制・対応方針の取り決め)は担当者と方針を先に決めておくことが実質的な着手になります。
まとめ
次に同じ種類の通知が届くとしたら、規模や対象システムが第一報の内容から変わらない保証はありません。数字が確定するまでの数日間に何を済ませておくかで、通知が届いた後の対応の速さが変わります。
今日からすぐ手を付けられるのは、委託先で使っているパスワードが他のサービスと重複していないかの洗い出しです。そこから二要素認証の設定確認、通知の監視体制、対応方針の取り決めへと順に整えておくと、次に自社が同じ立場に置かれた時に慌てずに済みます。
出典
- ITmedia「さくらインターネット、レンタルサーバに不正アクセス 583アカウントへの不正ログイン確認」: https://www.itmedia.co.jp/news/article/2608/17/2000000563/
- さくらインターネット公式ニュースリリース「販売管理システムへの不正アクセスについて」: https://www.sakura.ad.jp/corporate/information/newsreleases/2026/08/19/1968225633/
- Internet Watch: https://internet.watch.impress.co.jp/docs/news/2133984.html
- ITmedia @IT: https://atmarkit.itmedia.co.jp/ait/articles/2608/18/news046.html
※ この記事は AI を使用しています。Leadeas が自社開発した AI エージェント基盤で下書きを作成し、人間のレビューを経て公開しています。AI ネイティブ開発会社として自社の技術をそのまま実演する目的で、この手法を用いています。(詳しくは AI 利用ポリシー)

