2026年3月27日、日本のクラウドを巡る大きな動きがありました。
さくらインターネットが提供する「さくらのクラウド」について、デジタル庁がガバメントクラウドに必要なすべての技術要件を満たしたことを確認し、本番環境での提供が可能になったのです。
これは単に、クラウドサービスの選択肢が一つ増えたという話ではありません。
これまで日本のガバメントクラウドでは、AWS（Amazon Web Services）、Google Cloud、Microsoft Azure、Oracle Cloud Infrastructure（OCI）といった海外大手のクラウドサービスが大きな役割を担ってきました。
そこへ、日本国内に事業基盤を持つ「さくらのクラウド」が加わりました。
さらに、さくらインターネットは経済安全保障という観点からも重要性を増しています。
経済産業省は、日本の基盤クラウド市場について、国内に事業基盤を持つ事業者のシェアが約3割にとどまり、海外サービスへの依存度が高いことを問題として指摘しています。
そのうえで、経済安全保障推進法に基づき「クラウドプログラム」を特定重要物資に指定し、国内での安定供給を支援してきました。
さくらインターネットについても、基盤クラウドの技術開発に加え、生成AIに必要となるGPU計算資源の国内整備について、最大約501億円の助成を伴う供給確保計画が認定されています。
つまり現在のさくらインターネットは、レンタルサーバーを提供する一企業というだけではありません。
日本が国内に確保しようとしているデジタル基盤の一角を担う企業になっています。
その「さくらインターネット」で、2026年8月、不正アクセスが明らかになりました。
ただし、最初に明確にしておかなければならないことがあります。
今回確認された不正アクセスによって、「さくらのクラウド」が侵害されたという事実は確認されていません。
また、日本のガバメントクラウドや経済安全保障政策を狙った攻撃だったと判断できる証拠も、現時点ではありません。
「日本にとって重要性を増している企業が攻撃された」という事実と、「その重要性を理由として攻撃された」という推論は別問題です。
では、さくらインターネットの内部で、実際に何が起きていたのか…。
時計を2026年8月9日に戻してみたいと思います。
■ 8月9日――攻撃開始ではなく「異常検知」
2026年8月9日。
さくらインターネットは、同社が管理するサーバー環境において「異常」を検知し、調査を開始しました。
ここで非常に重要なのが…
8月9日＝攻撃開始日
…ではないということです。
これは後の調査によって明らかになっていきます。
8月9日は、攻撃が始まった日というよりも、防御側であるさくらインターネットが、攻撃者の存在につながる異常を認識した日と考える方が適切です。
では、その「異常」が発見される以前に何が起きていたのでしょうか。
■ 8月17日――583アカウントへの不正ログイン
8月17日、さくらインターネットは第一報を公表しました。
調査の結果、第三者が…
「当社管理環境を経由して」
「さくらのレンタルサーバ」の一部顧客環境へ不正アクセスしていたことが確認されています。
判明した不正ログインは583アカウントです。
しかし、今回の事件を見るうえで重要なのは「583」という数字だけではありませんでした。
調査では…
・攻撃者が顧客アカウントからアクセス可能な領域へ到達していたこと
・一部サーバーへマルウェアが設置されていたこと
・顧客情報および「通信の秘密」に該当する情報へアクセス可能な状態だったこと
・一部の個人データについて第三者に閲覧または取得された可能性があること
…などが確認されています。
特に注目したいのが…
「当社管理環境を経由して」
…という部分です。
単純に583人分の顧客パスワードが何らかの方法で盗まれ、それぞれのアカウントへ外部からログインされた、というだけでは説明できない可能性や、攻撃者がさくらインターネット側の何らかの管理領域へ到達し、それを足場として顧客環境へ展開した可能性があると推察しています。
ただし、ここから先は慎重に考えなければなりません。
- 具体的にどの管理システムが侵害されたのか。
- どの程度の権限を攻撃者が取得したのか。
- 脆弱性が利用されたのか。
- 認証情報が窃取されたのか。
こうした初期侵入の詳細については、現時点の公開情報だけでは分かりません。
この段階では、分からない部分を推測で埋めることは避けたいと思います。
■ 調べるほど事件の時間が過去へ延びていった
第一報からわずか2日後の8月19日。
さくらインターネットは第二報を公表しました。
ここで事件の見え方が大きく変わります。
レンタルサーバーへの不正アクセスについて封じ込めを行い、影響範囲を調査していく過程で、新たに顧客の契約情報などを管理する“「販売管理システム」”への不正アクセスの可能性が確認されたのです。
しかも重要なのは、その時期です。
さくらインターネットによれば、このアクセスは、8月9日にレンタルサーバーへの不正アクセスを検知する以前に発生していました。
つまり8月9日に見つかった異常を起点として調査を広げていった結果、事件の時間軸そのものが過去へ延びていったことになります。
販売管理システムには会員情報が保存されており、影響を受けた可能性がある会員情報の総数は、1,360,563アカウントに達しました。
ただし、この数字にも注意が必要です。
583アカウントと136万563アカウントは、同じ意味の数字ではありません。
583は不正ログインが確認されたレンタルサーバーのアカウント数です。
一方の136万563は、販売管理システムに保存されている会員情報のうち、影響を受けた可能性がある対象総数です。
136万563件すべての情報が窃取されたという意味ではありません。
さくらインターネットも、販売管理システムについて、現時点ではデータの外部持ち出しを確認していないとしています。
■ 攻撃者について、現在どこまで分かっているのか
ここで当然、一つの疑問が生まれます。
誰が、何のために攻撃したのか…です。
残念ながら、現時点で攻撃主体を特定できる情報はほとんど公表されていません。
- 攻撃グループ名
- 攻撃元IPアドレス
- C2サーバー
- ドメイン
- マルウェアのファミリー名
- ファイルハッシュ
- 利用された脆弱性
こうしたアトリビューションにつながるIOCは、現在までに確認した公開情報にはありません。
一方で、攻撃者の「行動」についてはいくつか分かっています。
- 攻撃者は、さくら側の管理環境を経由している。
- 複数の顧客環境へ到達している。
- 一部サーバーへマルウェアを設置している。
そして、実際の活動開始時期は8月9日より前まで遡る可能性があります。
逆に、現時点では典型的なランサムウェア事件で見られるような大規模暗号化、身代金要求、リークサイトへの掲載、攻撃グループによる犯行声明などは確認できません。
だからといって、国家支援型攻撃だったと結論付けることもできません。
- サイバー犯罪者なのか
- 標的型攻撃なのか
- 別の目的を持つ攻撃者なのか
現段階では判断できません。
しかし、今後一つ重要な手掛かりになる可能性があるものがあります。
設置されたマルウェアの正体です。
- バックドアだったのか
- Webシェルだったのか
- 認証情報を窃取するものだったのか
- 外部との通信を中継するプロキシだったのか
- データを収集するものだったのか
マルウェアの目的が判明すれば、攻撃者が何をしようとしていたのかについて、さらに踏み込んだ分析が可能になると思います。
■ もう一つ気になった「DoS攻撃」
今回の事件を調べていくなかで、私たちが気になったことがあります。
さくらインターネットのレンタルサーバーでは、この時期、DoS攻撃による障害が発生していました。
8月10日午前4時20分から5時27分にかけて、
「www4289.sakura.ne.jp」
で、外部からの不正なトラフィック、つまりDoS攻撃によってサーバーへ接続しにくくなる障害が発生しています。
時系列に並べてみると、
8月9日 さくらが異常を検知
↓
8月10日 レンタルサーバーでDoS障害
↓
8月17日 583アカウントへの不正ログインとマルウェア設置を公表
↓
8月19日 8月9日以前の販売管理システムへのアクセス可能性を公表
となります。
しかも攻撃者の活動そのものは8月9日以前から始まっていた可能性があります。
そこで一つの仮説を考えました。
DoSが別の侵入活動を隠すための「陽動」として使われた可能性はないのかということです。
■ DoS/DDoSを「煙幕」として利用する攻撃
DoSやDDoSの目的は、必ずしもWebサイトやサービスを停止させることだけではありません。
大量の通信を発生させ、システム管理者やセキュリティ担当者を障害対応へ集中させ、その裏側で別の侵入活動を行うという考え方があります。
いわば、サイバー空間における「煙幕」です。
過去には、2015年に英国通信会社TalkTalkが受けたサイバー攻撃で、DDoSとデータ侵害が並行して発生し、セキュリティ専門家からDDoSが別の侵入を隠す陽動だった可能性が指摘されました。
同じ2015年のCarphone Warehouseへの攻撃でも、DDoSが「スモークスクリーン」として利用された可能性が当時指摘されています。
つまり…
DoS/DDoSを陽動として利用するという発想そのものは、実際のサイバー攻撃の世界に存在しているのです。
では、今回のさくらインターネットへのDoSもそうだった可能性はないのでしょうか。
ここで私たちは、さくらインターネットが公開している過去の障害記録を遡ってみました。
すると、当初の仮説を修正する必要が出てきました。
■ DoSは今回だけに起きていたわけではありません
さくらインターネットの障害記録を調べると、レンタルサーバーに対するDoS攻撃は、今回の事件周辺だけに発生していたものではありませんでした。
例えば2026年5月1日には「www317.sakura.ne.jp」で、午前10時3分から午後2時59分までDoSによる通信障害が発生しています。
5月8日にも「www447b.sakura.ne.jp」でDoS障害が記録されています。
さらに7月10日には「www2432.sakura.ne.jp」に対するDoSによる障害が始まり、復旧が記録されたのは7月13日でした。
そして8月10日の「www4289.sakura.ne.jp」です。
少なくとも公開されている障害記録を見る限り、
「DoSが発生した」という事実そのものは、さくらインターネットにとって今回だけの特異な現象ではないようです。
これはホスティング事業者という性格も考慮する必要があります。
攻撃者が「さくらインターネット」という会社そのものを狙っているとは限りません。
共用サーバー上に存在する特定のWebサイトが攻撃対象となり、その影響が同じサーバーを利用する別の顧客へ波及することも考えられます。
業界全体を見てもDDoSは無視できない脅威です。
IPAの「情報セキュリティ10大脅威 2025」では、DDoS攻撃が組織向け脅威の第8位となり、5年ぶりに10大脅威へ入りました。
したがって…
DoSが発生したことだけを根拠として、今回の不正アクセスと結び付けることは今のところできません。
■ 「攻撃手法が存在する」と「今回使われた」は別問題です
ここは今回の検証で、とても重要なところでだと考えています。
DoSを陽動として利用する攻撃手法は、実際に存在しています。
だから私たちは、その可能性を疑いました。
しかし…
「そのような攻撃手法が存在すること」と、「今回その攻撃手法が使われたこと」は別問題です。
さくらインターネットでは以前からDoSによる障害が発生しています。
現在までに公表されている情報にも、8月10日のDoSと今回の不正アクセスを直接結び付ける証拠はありません。
したがって現時点での結論は…
関連性を否定することはできませんが、関連していたと判断することもできません。
…となります。
今後、フォレンジック調査によって攻撃者の侵入開始日時や活動時間帯が明らかになり、それがDoS発生時間と重なるのであれば、改めて検証する価値があるでしょう。
仮説に都合のよい事実だけを集めるのではなく、反証となる材料についても確認する。
サイバー事件を検証するうえでは、この姿勢が重要だと考えます。
■ 「発覚」と「攻撃開始」は違う
サイバー攻撃がニュースになると、
「○月○日にサイバー攻撃が発生しました」
と表現されることがあります。
しかし実際の攻撃は、その日から始まったとは限りません。
特に侵入型の攻撃では、攻撃者が内部へ侵入してから発覚するまでに時間があります。
- 認証情報を取得する。
- 権限を拡大する。
- ネットワークを探索する。
- 重要なサーバーを探す。
- 別のシステムへ横展開する。
- 情報を収集する。
そして、何らかの異常によって防御側がその存在に気付きます。
利用者や防御側から見える「事件発生日」は、攻撃開始日ではなく、
水面下で進んでいた攻撃が表面化した日である場合があります。
今回のさくらインターネットの事件は、そのことを非常に分かりやすく示しています。
8月9日に異常が見つかりました。
しかし調べてみると、それ以前にも不正アクセスの可能性がありました。
つまり、発覚とは、攻撃側と防御側の時間軸が初めて交差する瞬間です。
攻撃者にとってはすでに始まっていた攻撃を、防御側が初めて認識した瞬間とも言えます。
■ 必要なのは「不正アクセスの棚卸し」
では、どうすれば水面下の攻撃者を早く見つけることができるのでしょうか。
その一つの考え方が、「不正アクセスの棚卸し」です。
企業では定期的に資産を棚卸しします。
帳簿に記録されているものと、実際に存在するものが一致しているかを確認します。
情報システムでも、同じ考え方が必要です。
- 正規アカウントはいくつ存在するのか。
- 退職者や不要になったアカウントは残っていないか。
- 管理者権限を持つ人物は適切か。
- 昨日と今日で権限に変化はないか。
- 通常存在しないプログラムが動いていないか。
- 不審な外部通信はないか。
- ログが不自然に欠落していないか。
そして、正規に見えるログインは、本当に正規利用者によるものなのか。
- EDR
- ファイアウォール
- IDS／IPS
- 多要素認証
こうした技術は重要です。
しかし、製品を導入しただけで攻撃者を必ず発見できるわけではありません。
攻撃者が正規認証情報を取得すれば、ログインそのものは正常に見える場合があります。
正規の管理ツールを悪用すれば、プログラムの実行も一見すると正常に見えるかもしれません。
だからこそ、「異常なものを探す」だけではなく、「正常に見えているものが本当に正常なのか」を確認するという視点が必要になってきます。
■ そして再び「さくらのクラウド」へ
ここで記事の最初に戻りたいと思います。
さくらインターネットは、日本のガバメントクラウドを担う事業者の一つになりました。
経済安全保障推進法の下では、基盤クラウドや生成AIに必要となる計算資源を国内に確保する役割も期待されています。
だからといって、今回の事件を「日本政府のクラウドが攻撃された」と表現するのは正確ではありません。
第一報の段階でも、「さくらのクラウド」への影響は確認されていないとされています。
しかし、さくらインターネットという企業そのものの重要性が以前より大きくなっていることも事実です。
そのような企業に求められるセキュリティは、「絶対に侵入させない」という考え方だけでは成立しません。
侵入される可能性を前提として…
- 早く検知する
- 横展開を止める
- 認証情報を失効させる
- 攻撃者を排除する
- 証拠を保全する
- 侵害範囲を特定する
- 安全な状態へ復旧する
そして、なぜ侵入を許したのかを明らかにする。
こうした一連の能力――サイバーレジリエンスが重要になると考えます。
■ この事件は、まだ終わっていません
2026年9月4日現在、今回の事件について分かっていないことは数多く残されています。
- 侵入開始日時
- 最初の侵入口
- 利用された脆弱性または認証情報
- 8月9日に検知された「異常」の正体
- 販売管理システムへのアクセスとレンタルサーバー侵害との関係
- 攻撃者が取得した権限
- 設置されたマルウェアの種類と目的
- 実際に外部へ持ち出された情報
- そして攻撃者の目的と正体
これらが明らかにならない限り、事件の全体像は完成しません。
だからこそ現段階で、特定のランサムウェアグループやAPT、国家による攻撃、あるいは日本のガバメントクラウドを狙った攻撃などと結論付けるべきではありません。
分からないことを、推測で埋めて終わらせないこと。
一方で、新たな情報が公表されたときに、それまでに確認した事実と結び付けて再評価することも重要です。
特に今後注目したいのは、「8月9日に何を検知したのか」そして、「設置されたマルウェアは何だったのか」という二点です。
ここが明らかになれば、攻撃者がいつ、どこから入り、何を目的として活動していたのかが見えてくる可能性があります。
今回、DoSとの関連を疑って調べた結果、DoSそのものは以前から発生していたことも分かりました。
一つの仮説は一度後退しました。
しかし、その検証から別の重要な問題が見えてきました。
インターネット事業者には、日々大量の攻撃が飛んできます。
その大量の「異常」の中から、本当に内部へ入り込んだ攻撃者の痕跡を見つけなければなりません。
サイバー攻撃で本当に怖いのは、画面に身代金要求が表示されることでも、サーバーが突然停止することでもありません。
何事もなくシステムが動いているように見える、その裏側に、まだ発見されていない攻撃者が存在していることです。
だからこそ私たちは、「今、このシステムの中に、本当にいるべき者しかいないのか」と問い続ける必要があると考えます。
さくらインターネットへの不正アクセス事件は、その重要性を改めて示していると思います
ネット探検ラボでは、今後公表されるフォレンジック調査の結果や追加情報について、引き続き追跡していきたいと思います。
コメント