セキュリティ対策
レンタルサーバーが不正アクセスされたとき、利用者は何をすべきか
契約しているレンタルサーバー会社そのものが侵害されると、利用者側の設定では侵入を防げません。2026年8月にさくらインターネットが公表した事案を題材に、公式発表で『確定していること』と『まだ確定していないこと』を切り分け、利用者が今日できる被害の縮小策——保存物の棚卸し、認証の分離、事業者外バックアップ、確認すべきログ、便乗フィッシングへの備え——を手順で解説します。
対象：共用のレンタルサーバーでサイトやメールを運用している人。自分のミスではなく、契約している事業者の側が侵害されたとき、利用者に何ができるのかを整理します。本記事は公開情報（事業者の公式発表・報道）にもとづく解説で、攻撃手順は扱いません。
何が起きたのか（2026年8月17日 公表分）
さくらインターネット株式会社は2026年8月17日、同社のレンタルサーバーサービス「さくらのレンタルサーバ」の一部利用者環境に対する第三者による不正アクセスを確認したと公表しました。以下はすべて同社の公式発表に記載された内容です。
2026年8月9日（日）
同社が管理するサーバー環境で異常を検知し、調査を開始。調査により判明
第三者が同社の管理環境を経由して、「さくらのレンタルサーバ」の一部利用者環境へ不正アクセスを行っていたことを確認。一部のサーバーにマルウェアが設置されていたことも確認。確認後ただちに
認証情報の無効化・アクセス遮断その他の封じ込め対応を実施。マルウェアの除去も実施。2026年8月17日（月）
公表。あわせて総務省・個人情報保護委員会等の関係機関へ報告。対象となる利用者へは登録メールアドレス宛に個別連絡を開始。
- 不正ログインの対象
- 583アカウント（同社発表。影響を受けた可能性のある環境は調査継続中）
- 漏えいの可能性がある情報
- 「顧客領域内に保存された情報」「利用者識別子」（対象範囲は継続調査中）
- 到達範囲
- 攻撃者が「お客さま情報および通信の秘密に該当する情報へアクセス可能な状態であった」ことを確認
- 改ざん被害
- 現時点で被害申告は確認されていない
- 影響が確認されていないサービス
- さくらのVPS／さくらのクラウド／さくらの専用サーバ PHY／高火力 PHY
- 実施中の対応
- 一部機能の制限（データベースアップグレード機能・プラン変更・移行ツール等）、認証情報の失効、マルウェア除去、フォレンジック調査、監視強化
いちばん大事な読み方：確定と未確定を分ける
報道の見出しは数字だけを伝えますが、この事案で確定していない項目のほうが行動に直結します。①侵入経路の詳細は公表されていません（「管理環境を経由」以上の説明はありません）。②8月9日は「検知日」であって侵入日ではありません——発生時期は調査中です。③583は「現時点で判明している数」で、同社自身が調査継続を明記しています。④「アクセス可能な状態であった」は「取得された」と同義ではありません。未確定を確定として扱わないこと、同時に「確定していないから大丈夫」と読まないこと——この両方が必要です。
なぜ利用者側の対策では止まらないのか
攻撃者
↓ 侵入（経路は未公表）
事業者の管理環境
↓ ここを経由して降りてくる
利用者の環境（あなたのサーバー領域）
ファイル／データベース／メール
利用者が張れる防御線
強いパスワード・アプリ更新・IP制限 → いずれも上の経路には効かない
利用者ができるのは、その領域に何を置いてあるかを変えることだけです。だから対策は「侵入を防ぐ」ではなく「読まれても困らない状態にしておく」になります。
利用者では防げないこと
- 事業者の管理環境への侵入そのもの
- 管理経路から自分の領域に到達されること
- 事故を即座に知ること（今回は検知から公表まで8日。調査を要するため公表に時間がかかるのは一般的で、その間、利用者は自力では気づけない）
利用者が決められること
- その領域に何を保存しているか（秘密情報・個人データ・鍵）
- そのパスワードが他のサービスでも通用するか
- バックアップが同じ事業者の中だけにないか
- 異常に気づくための確認手段を持っているか
今日やる4手順
サーバー上の「秘密」を棚卸しして、置き場所を変える
公開ディレクトリやその周辺に、.env、データベースのダンプ、バックアップの圧縮ファイル、APIキーを含む設定ファイル、顧客名簿のCSVを置いていないか確認します。今回漏えいの可能性として挙げられているのは、まさに「顧客領域内に保存された情報」です。置いてあるものは読まれた前提で考えるしかありません。配置の具体策は レンタルサーバーで .env を公開しないための配置と設定 と 公開ディレクトリに置いてはいけないもの にまとめています。
認証を事業者の外と切り離す
コントロールパネル、FTP/SSH、メール、データベースのパスワードを他サービスと共有しない。1つ漏れても横に広がらない状態を作ります。管理画面には 多要素認証 を設定し、可能なら パスキー に寄せます。管理は パスワードマネージャー に任せるのが現実解です。
バックアップを事業者の外に置く
事業者側が侵害された場合、同じ事業者の中にあるバックアップも信頼度が下がります。手元またはまったく別の事業者に、復元を試したことのある控えを持ってください。考え方は バックアップと復旧の基本（3-2-1ルール） のとおりです。
確認と、便乗フィッシングへの警戒
同社が利用者に求めている確認項目は3つです——身に覚えのないファイルや管理者アカウントの追加／サイト・アプリの不審な変更／心当たりのないログインやメール送信。そして事故の直後は「サーバー会社を名乗る緊急連絡」型の フィッシング が必ず増えます。同社も「当社からパスワード、認証情報、クレジットカード情報等をメールや電話でお伺いすることはありません」と明記しています。メール内のリンクを踏まず、公式サイトへ自分でアクセスして確認する——これを徹底してください。
当サイトの視点：契約形態を変えるより「失うものを減らす」ほうが速い
この手の事故のたびに「共用サーバーはやめてVPSへ」という話が出ますが、当サイトはその処方を勧めません。VPSは分離の度合いこそ上がるものの、OSとミドルウェアの更新責任が丸ごと自分に移ります。運用体制がないまま移れば、放置された更新が新しい入口になるだけです。当サイト自身も専有ではない環境で動いており、そこでの原則は「そのホストが読まれても失うものを小さくする」——秘密は環境変数としてサーバー外の管理下に置き、認証情報は用途ごとに分け、バックアップと公開物の正本は別の場所に持つ。契約形態は防御そのものではなく、爆発半径を決める1つの変数にすぎません。
出典（公開記録）
本記事の事実関係は、以下の公開情報にもとづきます。侵入経路の推測や、公表されていない内容の断定は行っていません。
- さくらインターネット株式会社「当社レンタルサーバーサービスの一部環境に対する不正なアクセスについて」（2026年8月17日公表） — sakura.ad.jp
- 各種報道（INTERNET Watch／ITmedia NEWS／日本経済新聞、2026年8月17日） — いずれも上記公式発表にもとづく報道
更新履歴
2026-08-18：初版。公式発表（第一報）時点の確定情報にもとづく。侵入経路・発生時期・影響範囲は調査継続中と公表されているため、続報が公表され次第このセクションに追記します（最終確認日は記事上部の表示を参照）。
次に読む
- 実務：レンタルサーバーで .env を公開しない配置 ／ バックアップと復旧の基本 ／ 多要素認証の選び方
- 用語：フィッシングとは ／ マルウェアとは
- 事例：Codecov サプライチェーン事件（2021）（信頼された経路が侵害されると利用者側では止められない、という同じ構図）
よくある質問
Qレンタルサーバー会社が不正アクセスされた場合、利用者に落ち度はありますか？
事業者の管理環境を経由して顧客環境に侵入される類型では、利用者側の設定でその侵入を防ぐことはできません。弱いパスワードやアプリの脆弱性が原因の乗っ取りとは別の話です。ただし『何が読まれ得るか』は利用者側の設計で大きく変わります。公開ディレクトリに秘密情報を置かない、パスワードを使い回さない、バックアップを事業者の外に持つ、といった備えが被害範囲を縮めます。
Q今すぐ確認すべきことは何ですか？
身に覚えのないファイルや管理者アカウントが増えていないか、サイトやアプリに不審な変更がないか、心当たりのないログインやメール送信が発生していないか——この3点です。これはさくらインターネットが公式発表で利用者に求めている確認項目でもあります。あわせて、事故に便乗した『サーバー会社を名乗る』フィッシングにも注意してください。
Qパスワードは変更したほうがよいですか？
同じパスワードを他のサービスでも使っている場合は、ただちに使い回しをやめてください。これは事故の有無に関係なく効果があります。契約中のサービス側の変更については、事業者が対象者へ個別に案内する運用になっていることが多く、さくらインターネットも『必要な事項が判明した場合は個別に案内する』と公表しています。公式サイトで案内を確認し、メール内のリンクからではなく自分でログインして操作してください。
Q共用レンタルサーバーはやめてVPSにすべきですか？
一概には言えません。VPSや専用サーバーは分離の度合いは上がりますが、OSやミドルウェアの更新責任が自分に移ります。運用体制がないまま移ると、かえって危険な放置サーバーが生まれます。重要なのは契約形態そのものより、『そのサーバーが侵害されても失うものが小さい』設計になっているかどうかです。