あなたが管理している監視サーバーが1台乗っ取られたら、影響はどこまで及ぶでしょうか。
2026年8月、さくらインターネットで不正アクセスが発生しました。第一報では583アカウント、その2日後の第二報では最大約136万アカウントへと規模が拡大しています。
この事案で最も重要なのは件数ではありません。管理環境を経由して顧客環境へアクセスされたという点です。利用者がどれだけ自分のサーバーを固めていても、それでは防げない種類の侵害でした。
なお、本記事は公開されている情報をもとにした考察です。攻撃の詳細な経路には推測を含みます。正確な原因については今後の調査報告を参照してください。また、影響が確認されているのはレンタルサーバと販売管理システムであり、2026年3月にガバメントクラウドとして採択された「さくらのクラウド」とは別系統のサービスです。この点は最初に整理しておきます。
何が起きたのか
注目すべきは件数ではなく、経路です。
公表されている流れは次のとおりです。8月9日に不正アクセスを検知し、8月17日の第一報で583アカウントへの影響を公表。続く8月19日の第二報で、対象が最大1,360,563アカウントに拡大しました。
さくらは同時に、いくつかの機能を一時的に停止しています。データベースのアップグレード、プランの変更、サーバー移行ツール。いずれも顧客のデータに直接触れる機能です。
そして第二報にはこう書かれていました。管理環境を経由して顧客環境へのアクセスが行われた、と。この一文が、本記事で扱いたいすべてです。
利用者側の対策では防げなかった
責任共有モデルの事業者側が落ちると、利用者の対策は原理的に効かなくなります。
レンタルサーバの事故と聞くと、多くの人はCMSの脆弱性や弱いパスワードを思い浮かべます。実際そのケースがほとんどです。WordPressを放置していた、管理画面のパスワードが単純だった。これらは利用者の責任範囲で起きる事故であり、利用者の努力で防げます。
今回は違いました。破られたのは、その境界より上の層です。
利用者がWAFを入れていても、パスワードを32桁にしていても、脆弱性を毎週潰していても、結果は変わりませんでした。事業者側が持つ管理経路を通られたからです。ここは利用者が触れる場所ではありません。
そして、この構造は他人事ではありません。「利用者が守れない層」は、社内ネットワークでいえば運用管理セグメントに相当します。現場の担当者が触れない場所を、インフラ担当者だけが握っている。その構図はどの組織にもあります。
さくらは無対策だったのか
そうではありません。だから、この事案は考える価値があります。
ここで一度立ち止まる必要があります。「セキュリティ対策が甘かった会社の話」として読むと、得られるものがないからです。
さくらのクラウドは2026年3月27日、デジタル庁による305項目の技術要件をすべて満たしたことが確認され、ガバメントクラウドとして正式に採択されています。国内事業者としては初めてのことでした。ガバメントクラウドの要件には、情報セキュリティの確保やデータ保存の安全性に関する項目が含まれます。
繰り返しますが、認定を受けたのはさくらのクラウドであり、今回影響が出たレンタルサーバや販売管理システムとは別のサービスです。認定されたサービスが破られたわけではありません。
それでも、この事実は1つのことを示しています。国が検証する水準の対策を持つ組織であっても、別系統の管理環境では侵害が起きたということです。
つまり問題は、対策があったかなかったかではありません。対策が、どこで、どのように効いていたかの方にあります。
対策はなぜ効かなくなるのか
導入したときは正しかった設定が、運用の中で静かに崩れていきます。
管理プレーン、つまり機器やサーバーをまとめて操作するための仕組みは、攻撃者にとって条件の良い場所です。理由は3つあります。
届く範囲が広い。全台を管理するのですから、全台に届く必要があります。これは設計上の要請であって、不備ではありません。
できることが多い。設定変更、アカウント作成、データの移行。運用に必要な操作は、そのまま攻撃にも使えます。
見分けがつきにくい。移行ツールを動かす操作は、正規の作業でも攻撃でも、ログの上では同じに見えます。攻撃者が特別なツールを持ち込む必要がない理由がここにあります。
さくらが一時停止した機能を思い出してください。データベースのアップグレード、プラン変更、サーバー移行ツール。いずれもこの3条件を満たしています。停止の理由は公表されていませんが、顧客データに直接届く経路を優先的に塞いだと読むのが自然です。ここは推測を含みます。
「踏み台にされる」とは別の話
混同されやすいので整理しておきます。
踏み台は、次へ進むための経由地です。1台を取り、そこから隣へ、また隣へと横に広がっていく。よく言われるラテラルムーブメントがこれにあたります。
管理プレーンは違います。そこ自体が目的地になり得ます。到達性と権限を最初から持っているからです。段階を踏んで広げる必要がありません。
この違いは、対策の考え方を変えます。踏み台への対策は「通さない」ことが中心ですが、管理プレーンへの対策はそれだけでは足りません。奪われた後に影響が及ぶ範囲を、あらかじめ狭めておくという発想が必要になります。
崩れ方には型がある
対策が形骸化するとき、だいたい同じ壊れ方をします。
- 多要素認証は入れたが、運用ツールやAPIは例外にしてある
- 権限は分けたが、障害対応用の強い権限が常時有効のまま残っている
- ログは取っているが、正規の作業と攻撃を区別する設計になっていない
- 分離はしたが、後から利便性のために追加した経路が消されずに残っている
どれも導入時点では正しく、運用の都合で少しずつ緩んだものです。攻撃者が探しているのは、まさにこの隙間です。
3つの質問で棚卸しする
入れてあるかではなく、今も効いているか。ここが分かれ目です。
セキュリティの話は製品名や「ゼロトラスト」といった言葉から始まりがちですが、順番が逆だと思っています。今の状態を把握しないまま何かを導入しても、効いているかどうか確かめようがないからです。
管理している機器を1台ずつ思い浮かべながら、次の3つに答えてみてください。
質問① 設計したときの想定から、経路が増えていないか
この機器には、どのネットワークから、何番ポートで到達できますか。構築当初は管理セグメントからのみだったはずが、リモート作業のため、監視ツールの都合で、と例外が積み重なっていないでしょうか。
質問② 一時的に付与した権限が、今も残っていないか
このアカウントが1つ奪われたとき、他の機器にログインできますか。設定を変更できますか。障害対応のために渡した権限を、収束後に戻しましたか。
質問③ 今のログ設計で、正規の操作と攻撃を区別できるか
深夜に管理サーバーから全台へSSH接続があったとき、それが定期作業なのか侵害なのか、ログを見て判断できますか。判断できないなら、侵入されても記録の上では平穏なままです。
詰まりやすいのはどこか
この3問を機器ごとに埋めていくと、答えに詰まる場所が必ず出てきます。経験上、多いのは次の3つです。
監視サーバー。SNMPで全台をポーリングし、SSHでログインし、場合によっては自動復旧で設定変更まで行います。質問②で影響範囲を書き出すと、想像より広いはずです。
config配布用のファイルサーバー。全機器の設定情報が集まっている場所です。読まれるだけで、ネットワーク構成が丸ごと渡ります。
踏み台サーバー。経路を絞るために置いたはずが、質問①で確認すると、踏み台を経由しない直接ログインが残っていることがあります。
この3問を埋めていく作業は、専門用語で語られている設計思想と、結局のところ同じ場所に着地します。言葉から入る必要はありません。
関連記事：EDRとSASEはどっちを買えばいい?製品カテゴリで考えるのをやめた話
前例：LINEヤフーも「なかった」わけではない
分離は、ACL1行では終わりません。
構造がよく似た事案があります。2023年に発覚したLINEヤフーの情報漏えいです。
委託先企業の従業員のPCがマルウェアに感染し、そこを起点にNAVER Cloudの社内システムが侵害されました。そしてNAVER Cloudとネットワーク接続のあったLINEヤフーの社内システムへ、不正アクセスが行われています。従業員情報を扱う共通認証基盤を経由した侵害でした。
注目すべきは、総務省の行政指導での指摘です。認証基盤がなかったことを問題にしたのではありません。その重要性に照らせば厳重なふるまい検知の仕組みが取られてしかるべきだったのに、行われていなかったという指摘でした。仕組みはあった。監視されていなかった。
そして、対策にかかった時間です。
2023年10月に検知。2024年3月と4月に行政指導を2回受け、2度目の理由の1つは、NAVERとのネットワーク完全分離が2年以上先になるという計画そのものでした。実際の完了は、本体のシステムと認証基盤が2025年中、国内外の子会社を含めた分離がすべて終わったのは2026年3月末。不要な通信の遮断とファイアウォールポリシーの削除も同時期です。
検知から約2年半。
管理プレーンの分離は設定変更の作業ではありません。委託関係の見直し、運用フローの再設計、場合によっては資本関係にまで及ぶ経営判断を伴います。だからこそ、事故が起きてから始めたのでは間に合いません。
まとめ：対策には賞味期限がある
導入した時点では正しかった設定が、運用の中で緩んでいく。今回の事案が示しているのは、対策の有無ではなくこの点だと考えています。
改めて3つの質問です。
- 設計したときの想定から、経路が増えていないか
- 一時的に付与した権限が、今も残っていないか
- 今のログ設計で、正規の操作と攻撃を区別できるか
そして、費用をかけずに今日から着手できることを3つ挙げておきます。
管理系アクセスの送信元を棚卸しする。機器の管理アクセス設定を1台ずつ確認し、想定外の送信元が許可されていないか見る。まず現状を書き出すだけで十分です。
関連記事：FortiGate 60F 開封から初期設定まで完全ガイド｜現役NEが実機で進める手順
共有アカウントを洗い出す。誰が使っているか特定できないアカウントは、質問②に答えられない状態です。
syslogを外部に集約する。侵害された機器の上のログは、証拠として使えません。集約先が分かれているだけで、事故後にできることが変わります。
全台に届く経路は、便利だから作られています。その便利さは、そのまま攻撃者にとっての価値です。自分の環境で、その経路がどこにあるのか。まずはそこからだと思います。
