※本記事は2026年8月29日時点の情報です。さくらインターネットが公開しているニュースリリース、サポート情報および公式マニュアルをもとに執筆しています。本件は現在も調査が継続されているため、最新状況については必ず公式情報をご確認ください。
- この記事で分かること
- 2026年8月に公表された、さくらインターネットへの不正アクセスで何が確認されているのか
- 「1,360,563アカウント」という数字をどう理解すべきか
- 「さくらのクラウド」のサーバー自体にも影響があったのか
- ハッシュ化されたパスワードにアクセスされた可能性があるとはどういうことか
- クラウドやWebアプリを運用する側が、今確認しておきたい認証・パスワード・シークレット管理
- 同様のインシデントに備えて、アプリケーション開発・インフラ運用で何を見直すべきか
まず結論：「さくらのクラウドが侵害された」という発表ではない
今回のニュースを見て、
「さくらインターネットが不正アクセスを受けたということは、さくらのクラウド上のサーバーも侵害されたのではないか」
と考える方もいるかもしれません。
しかし、2026年8月19日に公表された第二報では、不正アクセスの可能性が確認された「販売管理システム」は、契約情報などを管理するシステムであり、「さくらのクラウド」をはじめとした各サービスの提供環境とは別のシステムであることが明記されています。
また、8月17日の第一報では、その時点で「さくらのVPS」「さくらのクラウド」「さくらの専用サーバ PHY」「高火力 PHY」への影響は確認されていないと公表されていました。
したがって、現時点の公開情報から、
さくらのクラウド上で稼働している仮想サーバーそのものが今回の不正アクセスによって侵害された
と判断することはできません。
一方で、今回の調査では会員情報や認証情報に関する影響の可能性が判明しています。
そのためクラウド利用者としては、「サーバーが侵入されたかどうか」だけを見るのではなく、アカウント・パスワード・管理者権限などの認証まわりを改めて確認する機会として捉えることが重要です。
何が起きたのか：第一報から第二報まで
今回の事象は、2026年8月9日にさくらインターネットが管理するサーバー環境で異常を検知したことから調査が始まりました。
8月17日の第一報では、第三者が同社の管理環境を経由して「さくらのレンタルサーバ」の一部顧客環境へ不正アクセスしていたことが公表されました。不正ログインの対象は583アカウントで、攻撃者が顧客アカウントからアクセス可能な領域へ到達し、マルウェアが設置されていたことなどが確認されています。
その後、認証情報の無効化やアクセス遮断などを実施したうえで調査を進めた結果、8月19日の第二報では、新たに契約情報等を管理する販売管理システムへの不正アクセスの可能性が確認されました。
この販売管理システムへのアクセスは、レンタルサーバーへの不正アクセスを検知した8月9日より前に発生した事象とされており、両者の関連性を含めて現在も調査が続けられています。
整理すると、現時点では次のようになります。
| 公表 | 主な内容 |
|---|---|
| 8月17日 第一報 | さくらのレンタルサーバの一部顧客環境への不正アクセスを確認 |
| 第一報 | 不正ログイン対象は583アカウント |
| 第一報 | 一部環境でマルウェアを確認 |
| 8月19日 第二報 | 販売管理システムへの不正アクセスの可能性を確認 |
| 第二報 | 会員情報にも影響した可能性 |
| 第二報 | 対象となる可能性のある会員情報は1,360,563アカウント |
| 第二報 | 一部顧客のハッシュ化されたパスワード情報にもアクセスされた可能性 |
| 8月26日 | 問い合わせ窓口などを更新。VPSの一部対象者には管理者初期パスワード変更を案内 |
「1,360,563アカウント流出」とは限らない
今回特に注意したいのが、「1,360,563アカウント」という数字です。
第二報では、
対象となる可能性のある会員情報総数が1,360,563アカウント
と公表されています。
しかし、これは「1,360,563件の個人情報が漏えいした」という意味ではありません。
公式FAQでも、1,360,563アカウントは対象となる可能性のある会員情報の総数であり、現時点で全件が漏えいした事実は確認されていないと説明されています。また、個別の利用者が対象に含まれるかどうかについても、現時点では確定的に案内できない段階とされています。
第二報では、現時点でデータの外部持ち出しは確認されていないとも説明されています。
したがって、
136万アカウントが流出した
ではなく、
最大1,360,563アカウントの会員情報が影響を受けた可能性があり、実際に閲覧・取得された範囲は調査中
と理解するのが正確です。
ハッシュ化されたパスワードへのアクセスとは
今回、エンジニアとして特に気になるのが、販売管理システムに保存されていた一部顧客の「ハッシュ化されたパスワード情報」にアクセスされた可能性です。
通常、Webサービスではパスワードそのものを平文でデータベースに保存するのではなく、パスワードから生成したハッシュ値を保存します。
イメージとしては次のような形です。
ユーザーが入力したパスワード
↓
ハッシュ関数
↓
ハッシュ値
↓
データベースへ保存ログイン時には、入力されたパスワードを同じ方法でハッシュ化し、保存されている値と比較します。
そのため、データベース上のハッシュ値を見ただけで、そのまま元のパスワードが表示されるわけではありません。
ただし、
「ハッシュ化されているから、取得されても何もする必要がない」
という考え方も危険です。
パスワード自体が短い、単純、推測しやすいなどの条件によっては、攻撃者が候補となるパスワードを大量に試し、そのハッシュ値と照合することで元のパスワードを推測する攻撃が考えられます。
また、同じパスワードを別サービスでも使い回していた場合、一つの認証情報が判明することで別サービスへの不正ログインにつながる可能性があります。
さくらインターネット自身も、複数サービスで同じ認証情報を使い回した場合、一つのサービスから情報が流出すると他サービスにも不正アクセスされる可能性があるとして、認証情報の使い回しを避けるよう案内しています。
まず確認したいこと1：パスワードを使い回していないか
今回のような事象が起きた際、利用者側で最初に確認しやすいのがパスワードです。
例えば、次のような状態になっていないでしょうか。
さくらインターネット
password-A
GitHub
password-A
Google Workspace
password-A
AWS
password-Aこの状態では、一つのサービスで認証情報が漏えいすると、他サービスにも同じID・パスワードでログインを試す「パスワードリスト攻撃」につながる可能性があります。
理想的には、
さくらインターネット
password-A
GitHub
password-B
Google Workspace
password-C
AWS
password-Dのように、サービスごとに異なるパスワードを設定します。
人間がすべてを暗記するのは現実的ではないため、業務ではパスワードマネージャーなどを利用して、長くランダムなパスワードをサービスごとに生成・管理する方法が現実的です。
なお、今回のFAQでは、自分が影響対象に含まれているか現時点では確認できない場合でも、不安がある場合には予防的措置としてパスワード変更を推奨しています。
まず確認したいこと2：2要素認証を有効にする
パスワードだけではなく、2要素認証も重要です。
通常のログインが、
ID
+
パスワードだとすると、2要素認証では、
ID
+
パスワード
+
ワンタイムパスワード
または
セキュリティキーなど、別の認証要素を追加します。
これにより、仮にパスワードが第三者に知られたとしても、それだけではログインできない構成にできます。
さくらインターネットでは、会員メニューについて2025年12月3日から2要素認証が必須化されています。また「さくらのクラウド」のコントロールパネルでも、ワンタイムパスワードやFIDO2対応セキュリティキーを利用した2要素認証の仕組みが用意されています。
特に、
- クラウド管理画面
- GitHubなどのソースコード管理
- Google Workspace / Microsoft 365
- CI/CDサービス
- ドメイン・DNS管理
- VPN
- 社内管理システム
といった、侵害された場合の影響が大きいアカウントでは2要素認証を前提にするのが安全です。
まず確認したいこと3：「人間のパスワード」だけを見ない
アプリケーションを運用している場合、確認対象は人間がログインするときのパスワードだけではありません。
システムにはさまざまな認証情報があります。
人間が利用する認証情報
├─ クラウド管理画面のパスワード
├─ GitHubアカウント
├─ VPNアカウント
└─ WordPress管理者
アプリケーションが利用する認証情報
├─ DB_PASSWORD
├─ API_KEY
├─ ACCESS_TOKEN
├─ SSH秘密鍵
├─ CI/CD用トークン
└─ 外部サービスの認証情報例えばWebアプリケーションでは、次のような値を扱うことがあります。
DATABASE_URL=...
DB_PASSWORD=...
API_KEY=...
SECRET_KEY=...これらがGitリポジトリに直接コミットされていたり、複数環境で同じ値を使っていたりすると、一つの環境への侵入が別環境へ波及する可能性があります。
そのためインシデント発生時には、
「ユーザーパスワードを変更したから終了」ではなく、どの認証情報をどこで利用しているかを棚卸しする
ことが重要です。
VPS利用者は「初期パスワード」の扱いにも注意
今回のインシデントを受けて、2026年8月26日には「さくらのVPS」の一部利用者に対して、管理者パスワード変更の案内も公開されています。
対象となるのは、販売管理システム内に管理者（root / Administrator）の初期パスワードが保存されていたことが確認されたVPS契約者のうち、契約時に受け取った初期パスワードを変更せず利用している一部ユーザーです。
さくらインターネットは対象者へ個別にメールを送付しており、パスワード変更に関するメールを受け取っていない利用者は対象外としています。また、2022年9月1日以降に契約したVPSなども対象外とされています。
ここから一般化できる教訓は、
初期パスワードを恒久的に使わない
ということです。
例えばサーバー構築時には、
サーバー作成
↓
初期パスワード発行
↓
初回ログイン
↓
パスワード変更
↓
可能ならSSH鍵認証等へ移行のように、初期認証情報を一時的なものとして扱います。
これは、さくらのVPSに限らず、クラウド・ネットワーク機器・SaaS・データベースなどでも同様です。
アプリ・クラウド運用者向け：今確認したいチェックリスト
今回の事象をきっかけに、クラウド環境を利用している場合は次の項目を確認しておくとよいでしょう。
アカウント・認証
- 他サービスと同じパスワードを使い回していない
- 管理者アカウントに2要素認証を設定している
- 退職者・異動者・不要なユーザーが残っていない
- 共用アカウントをできるだけ使用していない
- 初期パスワードをそのまま使用していない
- 不要になったAPIキーやアクセストークンを削除している
権限
- 全ユーザーに管理者権限を与えていない
- 開発者に本番環境の不要な権限を与えていない
- サービスアカウントにも必要最小限の権限を設定している
- 本番・ステージング・開発環境で認証情報を分離している
サーバー・ネットワーク
- SSHやRDPをインターネット全体へ公開していない
- 不要なポートを開放していない
- Firewallの設定を定期的に確認している
- OS・ミドルウェア・CMSを更新している
- 管理画面にアクセス制限を設定できないか確認している
アプリケーション
- APIキーをソースコードへ直接記述していない
.envファイルをGitへコミットしていない- 本番DBの認証情報を開発環境で使い回していない
- ログへパスワードやアクセストークンを出力していない
- シークレットを定期的に変更できる構成になっている
ログ・監視
- 管理者ログインを追跡できる
- 重要な設定変更の履歴を確認できる
- 不審なアクセスを調査できるだけのログを保持している
- インシデント発生時に誰が調査するか決まっている
すべてを一度に完璧にする必要はありません。
まずは、
①管理者アカウント → ②外部公開サーバー → ③本番環境の認証情報
の順に確認すると、優先順位を付けやすくなります。
特に危険なのは「一つの認証情報から横展開できる構成」
システム運用で避けたいのが、一つの認証情報を取得するだけで複数のシステムへアクセスできてしまう構成です。
例えば、
1つの共通パスワード
↓
┌──────┼──────┐
↓ ↓ ↓
GitHub VPN Cloud
↓
DBという構成では、一つの認証情報の侵害が大きな影響につながります。
一方、
GitHub
└─ 個別アカウント + 2要素認証
Cloud
└─ 個別ユーザー + 最小権限 + 2要素認証
Server
└─ SSH鍵
DB
└─ アプリ専用ユーザー
CI/CD
└─ 専用トークンのように認証経路を分離しておけば、一つの認証情報が漏えいした場合でも影響範囲を小さくできます。
これは「パスワードを強くする」こととは別の重要な考え方です。
認証情報そのものが漏れる可能性をゼロにするのではなく、漏れた場合でも被害が横に広がりにくい設計にする
ことがポイントです。
クラウド側だけではなく、アプリケーション側の対策も必要
クラウドサービスを利用すると、
「インフラのセキュリティはクラウド事業者が対策してくれる」
と考えてしまいがちです。
しかし実際には、
クラウド事業者側
├─ データセンター
├─ 物理サーバー
├─ クラウド基盤
└─ サービス提供基盤
利用者側
├─ OS設定
├─ Firewall
├─ ユーザー管理
├─ Webアプリ
├─ WordPress等のCMS
├─ APIキー
├─ DB
└─ アプリケーションの認証のように、利用者側で管理しなければならない範囲も多く存在します。
例えばクラウド基盤自体に問題がなくても、
- WordPressのパスワードが漏れる
- Webアプリに脆弱性がある
- SSHを全世界へ公開している
- GitHubからAPIキーが流出する
といった理由でシステムが侵害される可能性はあります。
そのため、
「利用しているクラウドサービスが安全か」だけではなく、「その上に自分たちがどうシステムを構築しているか」まで含めて考える
必要があります。
インシデント発生時にやってはいけない3つの判断
1. 「ハッシュ化されているから何もしなくていい」
ハッシュ化はパスワード保護に重要な仕組みですが、認証情報へのアクセス可能性が判明した場合に、利用者側の対応が一切不要になるという意味ではありません。
パスワードの使い回しがある場合などは特に、変更を検討する必要があります。
2. 「136万件の個人情報が流出した」と断定する
現時点で公式に発表されているのは、1,360,563アカウントが対象となる可能性のある会員情報総数ということです。
全件の情報流出が確認されたわけではありません。
3. 「さくらのクラウドそのものが危険」と判断する
今回不正アクセスの可能性が確認された販売管理システムと、「さくらのクラウド」などのサービス提供環境は別システムであると公式に説明されています。
インシデント発生時には、事業者名だけで判断せず、
どのシステムに侵入されたのか、どの情報に影響した可能性があるのか
を分けて読むことが重要です。
今回の事例から得られる3つの教訓
今回の事象から、クラウド・Webアプリケーションの運用者が改めて確認したいポイントは、大きく3つあります。
1. 認証情報は「漏れない前提」ではなく「漏れた場合」まで考える
パスワードを強くするだけではなく、
- 使い回さない
- 2要素認証を利用する
- 最小権限にする
- 認証情報を用途ごとに分離する
ことで、一つの認証情報が侵害された場合の影響を抑えます。
2. 初期パスワードや古い認証情報を残さない
今回、さくらのVPSでは一部の古い契約について、初期管理者パスワードを変更していない対象者へ変更が案内されました。
サーバー構築後は、
- 初期パスワード
- 一時APIキー
- 検証用ユーザー
- 不要になったアクセストークン
などを残さない運用が重要です。
3. 認証情報の棚卸しができる状態にしておく
インシデントが起きた際に、
どのパスワードを変更すればよいのか分からない
このAPIキーがどのシステムで使われているのか分からない
という状態では、迅速な対応が難しくなります。
最低限、
認証情報
↓
利用システム
↓
利用環境
↓
所有者
↓
最終更新日が追える状態にしておくと、インシデント対応が大きく変わります。
まとめ
2026年8月に公表されたさくらインターネットへの不正アクセスでは、「さくらのレンタルサーバ」の一部顧客環境に加え、契約情報等を管理する販売管理システムにも不正アクセスの可能性が確認されています。
対象となる可能性のある会員情報は1,360,563アカウントと公表されていますが、これは全件の情報流出が確認されたという意味ではなく、実際の影響範囲については現在も調査が続けられています。
また、不正アクセスの可能性が確認された販売管理システムは、「さくらのクラウド」をはじめとしたサービス提供環境とは別のシステムです。
今回の事象からクラウド利用者が学ぶべきなのは、「特定のクラウドが安全か危険か」という二択ではありません。
重要なのは、
- パスワードを使い回さない
- 2要素認証を利用する
- 初期パスワードを残さない
- 権限を必要最小限にする
- APIキーやトークンも含めて認証情報を管理する
- 本番・開発・検証環境の認証情報を分離する
- 万が一認証情報が漏れても横展開されにくい構成にする
といった基本的な対策を継続することです。
クラウドサービスを使うことで物理インフラの管理負担は減らせますが、その上で動かすアカウント・OS・アプリケーション・認証情報の管理までクラウド事業者に任せられるわけではありません。
今回の発表を、普段利用しているクラウド環境やWebアプリケーションの認証設計を見直す機会にしてみてはいかがでしょうか。
本記事執筆時点で未確定の事項
本件は現在も調査中です。2026年8月29日時点では、少なくとも以下については今後の公式発表を確認する必要があります。
- 販売管理システムへの具体的な侵入経路
- 「さくらのレンタルサーバ」への不正アクセスとの関連性
- 1,360,563アカウントのうち実際に影響を受けた範囲
- 実際に第三者が閲覧または取得した情報・件数の確定
- 今後策定される再発防止策
公式発表でも、原因や影響範囲について調査を継続し、新たに公表すべき事実が判明した場合には公表するとされています。
参考リンク
本記事は、以下のさくらインターネット公式情報を主な根拠としています。
- 当社システムへの不正アクセスに関するお知らせ（第二報）（2026年8月26日10:00更新）
さくらインターネット公式・第二報 - 当社レンタルサーバーサービスの一部環境に対する不正なアクセスについて（第一報）
さくらインターネット公式・第一報 - 当社システムへの不正アクセスに関するご案内・FAQ
さくらインターネット公式FAQ - さくらのVPS 管理者パスワード変更のお願い
さくらのVPS公式案内 - さくらのクラウド 2要素認証
さくらのクラウド公式マニュアル - 会員メニューの2要素認証
さくらインターネット公式サポート
