さくらインターネットの不正アクセス公表から学ぶ｜クラウド事業者が破られた前提で、法人は何を備えるか

こんにちは、株式会社TIMEWELLの濱本です。2026年8月19日、さくらインターネットが不正アクセスに関する第二報を公表しました¹。同日には適時開示も出ています。8月17日の第一報がレンタルサーバの一部環境の話だったのに対し、第二報では契約者情報や請求先情報を管理する販売管理システムまで対象が広がり、影響を受けうる会員情報は最大1,360,563アカウントとされました¹。

この記事は、同社の落ち度を探すためのものではありません。むしろ、8月9日の異常検知から8日で第一報を出し、調査の途中経過であっても続報を重ねて範囲を上方修正した姿勢は、日本企業のインシデント対応として率直に評価されるべきだと私は思っています。都合の悪い数字を握りつぶさずに出す判断は、経営として簡単ではありません。だからこの記事のテーマは「さくらインターネットの何が悪かったか」ではなく、「公表された事実から、クラウドを借りているすべての法人が何を持ち帰れるか」です。

なお、侵入経路や攻撃者、悪用された脆弱性は現時点で公表されていません。憶測でその空白を埋めることはしません。

何が公表されたのか。2つの事案を時系列で切り分ける

まず事実関係を、公式発表に沿って整理します。ここで書くのはすべて公表ベースの情報で、公表されていないことは「公表されていない」と明記します。

起点は2026年8月9日です。同社が管理するサーバー環境で異常を検知し、調査を開始しました。その結果、第三者が同社の管理環境を経由して、さくらのレンタルサーバの一部ユーザー環境へ不正アクセスを行っていたことが確認されます²。8月17日に公表された第一報の時点で、不正ログインが確認されたのは583アカウント³⁴。加えて一部のサーバーに攻撃者によってマルウェアが設置されていたこと、そして攻撃者が利用者の情報や通信の秘密に該当する情報、具体的にはサーバー領域内に保存された情報と利用者識別子へアクセス可能な状態だったことが公表されました²。一方で、さくらのVPS、さくらのクラウド、さくらの専用サーバ PHY、高火力 PHYへの影響は確認されていないとされています²。

そして8月19日の第二報で、話の輪郭が変わります。契約者情報および請求先情報等を管理する販売管理システムへの不正アクセスの可能性が確認され、対象となる可能性のある会員情報の総数は1,360,563アカウントと公表されました¹。報道によれば、対象項目には会員ID、会社名、部署名、住所、氏名、電話番号、メールアドレス、生年月日、性別、FAX番号、契約サービス、契約期間、請求金額などが含まれます⁵。一部の顧客についてはハッシュ化されたパスワード情報へのアクセスの可能性も確認されました。クレジットカード情報は同社では保存しておらず、現時点でデータの外部持出しは確認されていないとされています¹。

見落とされがちですが、重要なのは時系列の「ねじれ」です。販売管理システムへの不正アクセスは、レンタルサーバへの不正アクセスを検知した8月9日より前に発生した事象であり、両者の関連性を含めて調査が続いています¹。つまり、最初に見つかった穴が最初に開いた穴とは限りません。インシデント対応をやったことがある方なら、この一文の重さがわかると思います。検知した事象の対処だけで幕を引くと、先に開いていた別の穴を見逃します。

同社は認証情報の失効、マルウェアの除去、システム監視の強化、外部専門機関によるフォレンジック調査、対象利用者への個別通知、関係機関への報告と情報共有を進めているとしています²¹。上場企業として同日に適時開示も行い、2027年3月期連結業績への影響は精査中としました。この時点で確定していることと、していないことを分けて出しています。開示の作法として、私は正しい順番だと思います。

自社の情報リテラシーやインシデント時の初動が組織としてどの水準にあるか、感覚ではなく項目で確かめたい方は、AIリテラシー診断のような棚卸しツールから入ってみるのも一つの手です。

なぜ起きるのか。「管理環境」という構造上の急所

ここからは一般論です。さくらインターネットの事案がこうだったという話ではなく、なぜホスティングやクラウドの事業者を経由した侵入が繰り返し起きるのか、その構造の話をします。繰り返しますが、今回の侵入経路は公表されていません。

クラウドや共用サーバは、利用者から見える面と、事業者だけが触る面の二層でできています。前者がデータ面、後者が管理面です。管理面には、契約者のサーバーを作る、止める、パスワードを再発行する、バックアップを取り出すといった強力な権限が集まっています。ここが攻撃者にとってどれほど魅力的かは、少し想像すればわかります。利用者のサーバーを一台ずつ攻略するより、それらを束ねている管理側にたどり着いたほうが、圧倒的に効率がいいのです。集約すればコストが下がるというクラウドの原理は、そのまま「破られたときの被害も集約される」という原理でもあります。

そして今回のように、事業者の管理環境を経由して顧客環境へ到達された場合、利用者が自分のサーバーをどれだけ堅牢にしていても、その努力は迂回されます。パスワードを長くしても、WordPressを最新に保っても、管理面から来る相手には効きません。これは利用者の落ち度ではなく、共有責任モデルの構造そのものです。責任分界点の向こう側で起きたことは、こちら側の対策では止められません。この当たり前を、頭ではわかっていても設計に反映できている会社は少ないように思います。

この種の攻撃が例外ではないことは、統計にも表れています。IPAの「情報セキュリティ10大脅威 2026」組織編では、「サプライチェーンや委託先を狙った攻撃」が4年連続で2位に選ばれました⁶。1位は4年連続でランサム攻撃です。守りの堅い組織を正面から攻めるより、その組織が使っている事業者や委託先から入るほうが早いからです。攻撃者にとってはとっくに標準戦術で、私たちの側の設計だけが「事業者は破られない」という前提のまま止まっている、というのが実情ではないでしょうか。

もう一点、私が気にしているのは検知の非対称性です。事業者側の基盤で起きた侵入は、利用者からはほとんど見えません。自社のアクセスログを眺めていても、管理面での不審な操作は映りません。だからこそ、利用者側にできる備えは「防ぐ」ではなく「巻き込まれた後に自力で立ち上がれるか」に軸足を移す必要があります。この考え方は、開発リポジトリからの情報漏えいを扱ったGitHubから個人データはなぜ漏れるのかでも書きましたが、預けた先が破られる前提でどこまで自分の足で立てるか、という同じ問いです。

借りている側の法的責任は、事業者の公表では消えない

実務でいちばん誤解されているのがここです。事業者が漏えいを公表したのだから、自社は静観していればよい。そう考えたくなりますが、法律はそう作られていません。

個人情報保護法では、個人データの漏えい等が生じ、個人の権利利益を害するおそれがあるときに、個人情報保護委員会への報告と本人への通知が必要になります。報告は速報と確報の二段構えで、速報は事態を知った後速やかに、目安として概ね3日から5日以内。確報は30日以内で、不正の目的をもって行われたおそれがある漏えいの場合は60日以内です⁷。不正アクセスによる漏えいは、件数にかかわらず報告対象になり得ます。

では、レンタルサーバに自社の顧客名簿を置いていた法人はどうなるのか。ここで効いてくるのが、その事業者との関係が「委託」に当たるかどうかです。個人データの取扱いを委託している関係であれば、委託先は委託元へ速やかに通知することで自らの報告義務と本人通知義務を免除されます⁸。裏を返せば、報告義務は委託元、つまり自社に残るということです。事業者が公表したことと、自社が委員会へ報告することは、まったく別の手続きになります。

一方、契約上クラウド事業者が保存された個人データを取り扱わないことになっており、適切にアクセス制御されている場合は、いわゆるクラウド例外として提供にも委託にも当たらないと整理されます。ただしその場合でも、自社は自らの安全管理措置義務の一環として、事業者側の取扱いを含めて適切に管理する責任を負い続けます⁹。個人情報保護委員会は2024年3月に、クラウドサービス提供事業者が個人情報取扱事業者に該当する場合の留意点として注意喚起も出しています⁹。委託でなければ免責、ではないのです。

さらに今回の第一報には「通信の秘密に該当する情報」という表現がありました²。電気通信事業者は、通信の秘密の漏えいが生じたときに総務大臣へ報告する義務があり、事案発覚後速やかに第一報、認知した日から30日以内に詳報を提出することとされています¹⁰。自社が電気通信事業の届出をしている場合、この線でも義務が発生し得ます。メール配信やメッセージ機能を持つサービスを運営している会社は、一度自社の届出状況を確認しておいたほうがよいでしょう。

私がこの章で言いたいのは一つだけです。「借りている」は「任せている」ではありません。預けたデータの主体としての義務は、預けた瞬間には移りません。契約書のどこにも書いていないこの前提を、事故が起きてから読み解くのは無理があります。

事業者が破られた前提で、今週やり直せること

では具体的に何をするか。防御の話ではなく、巻き込まれた後に自力で立ち上がるための設計として、私が優先度をつけて考えている項目を並べます。

優先度	やること	具体的な確認方法
高	認証の分離	サービス管理画面のパスワードを他サービスと共用していないか。管理者アカウントの多要素認証が全員分有効か。退職者・元委託先のアカウントが残っていないか
高	バックアップの分離	バックアップが同じ事業者の同じアカウント配下だけに置かれていないか。別事業者またはオフラインの世代を最低1系統持てているか
高	預けているデータの棚卸し	各サービスに個人データ、認証情報、機密情報のどれが入っているかを一覧化。報告義務の要否を事前に判定できる状態にする
中	鍵の分離	重要データの暗号化鍵を事業者側の管理下だけに置いていないか。顧客管理鍵に対応するサービスかを確認
中	ログの外部保全	監査に使うログが事業者側にしか残らない設計になっていないか。保全期間と、侵害時に自社で取り出せるかを確認
中	契約条項の点検	インシデント発生時の通知期限、原因情報の開示範囲、監査受入れ、再委託の可否が契約に書かれているか
低	退避可能性	データを他事業者へ移せる形式で取り出せるか。年1回、実際に取り出して確かめているか
低	事業者選定基準の明文化	第三者認証の有無だけでなく、登録範囲、準拠法、裁判管轄まで見る基準になっているか

この8項目は、経済産業省とIPAの「サイバーセキュリティ経営ガイドライン Ver3.0」が挙げる重要10項目のうち、委託先を含めた対策とインシデント発生に備えた体制づくりの部分を、クラウド利用の文脈に落としたものだと考えていただければ近いです¹¹。表の使い方を補足します。上の3つは今週中に着手できる性質のもので、しかも今回の事案で直接効く項目です。特に認証の分離は軽視されがちですが、ハッシュ化されたパスワード情報へのアクセス可能性が公表された以上¹、同じパスワードを他サービスで使い回している法人は、今日中にすべて変更してください。ハッシュ化されていれば即座に解読されるわけではありませんが、「解読に時間がかかる」は「安全」の同義語ではありません。

中段の3つは設計の話で、合意形成に時間がかかります。なかでも私が最も見落とされていると感じるのはログの外部保全です。侵害の範囲を確定できるかどうかは、報告義務の履行にも、顧客への説明にも直結します。ところが多くの企業で、調査に必要なログは事業者側にしか存在しません。事業者が調査中の間、自社は何も言えない状態になります。この沈黙が顧客の不信を招くのであって、事故そのものが招くわけではないと私は思っています。

契約条項の点検も、平時にしかできない仕事です。インシデント時の通知期限が書かれていない契約は珍しくありません。書かれていなければ、いつ知らされるかは相手の判断次第になります。自社が3日から5日以内に速報を出さなければならない立場である以上⁷、通知が2週間後に来る契約は、それだけで自社の法令遵守を危うくします。この視点は、組織のセキュリティ教育でもほとんど扱われていない領域です。当社が提供しているWARP SECURITYでも、技術者向けの攻撃手法よりも、こうした平時の設計と契約の話に時間を割くようにしています。

高いセキュリティが要るならISMAP登録を優先する。ただし「範囲」を必ず読む

ここからが、私がこの記事で最も伝えたい部分です。

機微な情報を扱うシステムの事業者を選ぶとき、ISMAP、正式には政府情報システムのためのセキュリティ評価制度に登録されているサービスを優先することを、私は強く勧めます。ISMAPは、政府が求めるセキュリティ要求を満たしているクラウドサービスをあらかじめ評価してリストに登録する制度で、NISC、デジタル庁、総務省、経済産業省の4組織が所管し、運用支援をIPAが担っています¹²。2020年1月のサイバーセキュリティ戦略本部決定により、政府機関がクラウドを調達する際は登録されたサービスから調達することが原則とされました¹²。

民間企業がこれを選定基準に使う価値は、私は3点あると考えています。

第一に、更新の頻度です。ISMAPクラウドサービスリストの登録期間は、登録の対象となった監査の対象期間の末日の翌日から1年4ヶ月と定められています¹²。つまり毎年、内部監査と外部監査を受け直さないとリストから落ちます。取ったきり放置できない制度設計になっている点は、他の認証と比べても実務的な意味が大きいと感じます。

第二に、インシデント時の外部への報告義務が制度に組み込まれていることです。登録事業者は、登録期間中に利用者に重大な影響を及ぼしうる情報セキュリティインシデントが発生した場合、遅滞なくISMAP運営委員会へ報告することを宣誓します¹²。事業者の自主判断だけに委ねない仕組みがある、というのは利用者から見て安心材料になります。

第三に、選定時に見るべき項目が制度側で言語化されていることです。登録申請にあたって、事業者は資本関係や役員等の情報、国内法以外の法令が適用されて意図しないまま情報にアクセスされ得るリスクに関する情報、契約に定める準拠法と裁判管轄、ペネトレーションテストや脆弱性診断など第三者による検査の実施状況の提供を求められます¹²。この4項目は、ISMAP登録の有無にかかわらず、自社が事業者を選ぶときの質問リストとしてそのまま使えます。制度の中身を、自社の調達基準に輸入してしまえばよいのです。

そのうえで、必ず添えなければならない留保が2つあります。

1つ目は、ISMAP登録は安全の保証ではないということです。これは私の意見ではなく、制度の公式資料にはっきり書かれています。制度概要には、本制度における監査業務は「結論の報告も、保証も提供しない」「保証業務とはその性質を異にする」と明記されています¹²。第三者が「このサービスは安全です」と太鼓判を押す制度ではなく、事業者が自ら言明した統制について、決められた手続きが実施された事実を確認する制度です。この違いを理解せずにリストを見ると、登録されていれば無条件に安心という誤読が生まれます。

2つ目は、登録がサービス単位であり、登録範囲が明示されているということです。ここは今回の件でも具体的に確認できます。さくらインターネットの場合、ISMAPに登録されているのは「さくらのクラウド」であり、同社の公式マニュアルには東京リージョンの第1・第2ゾーン、石狩リージョンの第1・第2ゾーンといったゾーンと、対象機能まで登録範囲として明示されています¹³。レンタルサーバはこの登録範囲には含まれていません。念のため書き添えますが、これは同社に問題があるという話ではまったくありません。共用のレンタルサーバと政府調達を想定したIaaSでは、そもそも想定する用途も価格も違うのですから、登録範囲が違うのは当然です。

伝えたいのは、利用者側の読み方の問題です。「あの会社はISMAP登録があるから安心」という判断は、会社ではなくサービスを見なければ意味を持ちません。同じ事業者の中でも、範囲に入るサービスと入らないサービスがあり、同じサービスでも範囲に入るリージョンと入らないリージョンがあります。自社が実際に使う構成が登録範囲に入っているかどうかは、ISMAPポータルのクラウドサービスリストと、事業者が公開している登録範囲の記載で確認してください。

リスクの小さい業務に使うSaaSについては、外部監査の範囲を縮減したISMAP-LIUという枠組みもあります¹⁴。制度そのものの詳しい解説と、通常のISMAPとの使い分けはISMAP入門にまとめてありますので、選定基準を作る段階の方はそちらもあわせて読んでみてください。ISO/IEC 27001との関係が気になる方にはISMS入門も用意しています。

まとめ。事故を防ぐ設計から、事故に耐える設計へ

事実の骨格をもう一度だけ確認します。公表されたのは、レンタルサーバの一部ユーザー環境への不正アクセスと583アカウントへの不正ログイン、一部サーバーへのマルウェア設置²、そして販売管理システムへの不正アクセスの可能性と、対象となりうる最大1,360,563アカウントの会員情報¹です。データの外部持出しは現時点で確認されておらず、クレジットカード情報は保存されていません¹。侵入経路と攻撃者は公表されておらず、この記事に書いた攻撃の構造はすべて一般論です。

私がこの一件から受け取ったのは、事故を防ぐ設計から、事故に耐える設計へ重心を移す時期が来た、ということです。事業者を選ぶ目は当然磨くべきで、その物差しとしてISMAPは有効です。ただしそれは足切りであって、保証ではありません。どれだけ慎重に選んでも、預けた先が破られる可能性はゼロにならず、そのとき自社の顧客に説明する責任は自社に残ります。バックアップの置き場所、ログの保全先、鍵の管理者、契約の通知期限。地味な4項目ですが、事故の当日に価値が決まるのはここです。

自社の構成でどこまで自力で立ち上がれるのか、まずはバックアップとログの2点だけでも今週中に確認してみてください。事業者選定の基準づくりや、経営層まで巻き込んだセキュリティ研修の設計について相談したい方は、個別相談からお声がけいただければ、状況を伺ったうえで一緒に考えます。

参考

本記事の事実関係は、さくらインターネットの公式発表とISMAPおよび各省庁の一次資料を柱とし、報道は補助的な確認のために参照しています。

Footnotes

1. 当社システムへの不正アクセスに関するお知らせ（第二報） — さくらインターネット株式会社 — 2026年8月19日 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹

2. 当社レンタルサーバーサービスの一部環境に対する不正なアクセスについて — さくらインターネット株式会社 — 2026年8月17日 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

3. 「さくらのレンタルサーバ」で不正アクセス、583アカウントへの不正ログインを確認（報道・補助的参照） — INTERNET Watch — 2026年8月17日 ↩

4. 「さくらのレンタルサーバ」に不正アクセス 583アカウントが不正ログイン被害（報道・補助的参照） — ITmedia NEWS — 2026年8月17日 ↩

5. さくらインターネット、最大136万アカウントに不正アクセスの影響か（報道・補助的参照） — ASCII.jp — 2026年8月19日 ↩

6. 情報セキュリティ10大脅威 2026 — 独立行政法人情報処理推進機構（IPA） ↩

7. 漏えい等報告・本人への通知の義務化について — 個人情報保護委員会 ↩ ↩²

8. 委託先において個人データが漏えいしてしまった場合の対応はどのようにすればよいでしょうか。 — 個人情報保護委員会 ↩

9. クラウドサービス提供事業者が個人情報保護法上の個人情報取扱事業者に該当する場合の留意点について（注意喚起） — 個人情報保護委員会 — 2024年3月25日 ↩ ↩²

10. 電気通信事業における通信の秘密の漏えい事案の報告 — 総務省 ↩

11. サイバーセキュリティ経営ガイドラインと支援ツール — 経済産業省 ↩

12. 政府情報システムのためのセキュリティ評価制度（ISMAP）の概要 — NISC・デジタル庁・総務省・経済産業省 — 令和5年11月 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

13. 政府情報システムのためのセキュリティ評価制度（ISMAP） — さくらのクラウド マニュアル ↩

14. ISMAP-LIUについて — NISC・デジタル庁・総務省・経済産業省 — 令和7年4月1日 ↩