AI・IT経営ケース 2026-09-03

自社が侵入されていなくても、安全とは限らない

さくらインターネットの不正アクセスから考える「委託先・クラウド障害時の初動」

今日は木曜日なので、セキュリティ事故・ITリスクの実例を取り上げます。

今回のテーマは、

「自社のサーバーやPCに異常が見えないときでも、利用しているIT事業者側でインシデントが起きたら、企業はどこまで自分ごととして動くべきか」

です。

■ 何が起きたのか【事実】

さくらインターネットは2026年8月9日、自社が管理するサーバー環境で異常を検知し、調査を開始しました。

8月17日の第一報では、第三者が同社の管理環境を経由して「さくらのレンタルサーバ」の一部顧客環境へ不正アクセスしていたこと、不正ログインの対象が583アカウントだったこと、一部サーバーにマルウェアが設置されていたこと、一部の顧客情報を含むデータが閲覧・取得された可能性があることが公表されました。

その後、8月19日の第二報では、調査範囲がさらに広がりました。

顧客の契約情報等を管理する販売管理システムにも不正アクセスの可能性が判明し、影響を受けた可能性のある会員情報は1,360,563アカウントとされました。ただし、現時点でデータの外部持ち出しは確認されておらず、原因や実際の影響範囲については引き続き調査中とされています。

さらに8月31日には、対象となる一部利用者について、さくらインターネット側でサーバーパスワードを変更し、利用者自身にもサーバーパスワードの再変更と、予防措置としてメールパスワードの変更を推奨しました。

ここで注目したいのは、最初の公表時点では「583アカウントへの不正ログイン」と見えていたものが、その後の調査で「販売管理システム」「最大約136万アカウントの会員情報への影響可能性」まで確認対象が広がったことです。

これは、最初の数字が間違っていたという意味ではありません。インシデント初期には、調査が進むほど影響範囲が変わることがある、という点が重要です。

■ ここで考えてみましょう

問1

自社が利用しているクラウド、レンタルサーバー、SaaSなどの事業者から「不正アクセスを確認したが、自社への影響はまだ調査中」と連絡が来た場合、確定報を待ってから動けばよいでしょうか。それとも、影響が未確定の段階から自社側で確認・対処を始めるべきでしょうか。

問2

今回のように、最初は数百アカウントだった調査対象が、その後100万単位まで広がる可能性がある場合、自社のインシデント対応計画には「影響範囲がまだ分からない期間」をどう組み込むべきでしょうか。

―― ここから解説 ――

■ 問1の答え

基本的には、確定報を待つだけでは不十分です。

ただし、慌てて全システムを止めるのでもありません。

重要なのは、「事業者側の事故」と「自社側で確認すべきこと」を分け、影響が未確定でも低コストで実施できる確認から始めることです。

例えば、

・自社が対象サービスを利用しているか
・どのサイト、メール、業務システムがそのサービスに依存しているか
・同じ認証情報を他サービスでも使っていないか
・管理者ログインや設定変更に不審な履歴がないか
・事業者からパスワード変更等の案内が出ていないか
・自社顧客や取引先への説明が必要になる可能性があるか

を確認します。

今回の事例では、8月31日に一部利用者へサーバーパスワード変更が行われ、メールパスワード変更も推奨されました。

つまり、「詳細がすべて確定するまで何もしない」よりも、事業者の公式情報を追いながら、自社側でも認証情報・利用サービス・影響範囲を並行して確認する方が実務的です。

■ 問2の答え

インシデント対応計画は、「原因と被害範囲が最初から分かる」前提で作らないことが重要です。

現実には、

第一報：一部環境への不正アクセス
↓
調査：別システムにもアクセスの可能性
↓
続報：影響対象となる可能性のある情報・アカウントが拡大
↓
追加対応：認証情報変更、個別通知、監視強化

というように、数日から数週間かけて事実関係が更新されることがあります。

したがって、自社側では対応を3段階に分けると整理しやすくなります。

第1段階：影響未確定
対象サービスの利用有無、依存システム、管理者権限、認証情報を確認する。

第2段階：影響可能性あり
パスワード変更、ログ確認、重要データの保全、代替手段の確認、社内連絡を進める。

第3段階：自社への影響確認
顧客・取引先への説明、復旧、追加調査、再発防止まで進める。

この形にしておけば、「まだ分からないので待つ」か「全部止める」かの二択になりにくくなります。

■ このケースの経営上のポイント

今回の事例から考えたいのは、クラウドやSaaSを使うこと自体が危険なのではなく、外部サービスを使った瞬間にセキュリティ責任がすべて事業者へ移るわけでもない、ということです。

企業側で重要なのは、

1. どの業務がどの外部サービスに依存しているかを把握する
2. 管理者アカウント・認証情報を特に重要資産として扱う
3. ベンダー事故時の連絡先・確認項目・社内責任者を決める
4. 「影響未確定」の状態でも動ける初動手順を持つ
5. 一度の第一報で判断を固定せず、続報に応じて対応レベルを上げ下げする

ことです。

今回のケースで特に重要なのは、攻撃者が「顧客企業そのもの」ではなく、事業者側の管理環境を経由して顧客環境へ到達したと公表されている点です。

自社側で通常のウイルス対策やファイアウォールを実施していても、利用している外部サービスの管理経路で問題が起これば影響を受ける可能性があります。

そのため、セキュリティ対策を「自社ネットワークを守る」だけで考えるのではなく、

自社
＋クラウド
＋SaaS
＋レンタルサーバー
＋委託先

まで含めた依存関係として見る必要があります。

■ すぐ確認できる実務ポイント

自社で外部ITサービスを利用している場合、最低限、次の4つを一覧化しておくと初動が早くなります。

・サービス名
・管理者アカウント
・そのサービスが止まった場合に影響する業務
・事故発生時の代替手段／連絡先

大がかりなBCP資料を作る前でも、この4項目だけで「何が止まり、誰が動くか」がかなり見えやすくなります。

■ 事実と推測の区分

【公表されている事実】
・8月9日に異常を検知
・583アカウントへの不正ログインを確認
・一部サーバーへのマルウェア設置を確認
・販売管理システムにも不正アクセスの可能性
・影響を受けた可能性のある会員情報は1,360,563アカウント
・8月19日時点でデータの外部持ち出しは確認されていない
・一部利用者について8月31日にサーバーパスワード変更対応を実施し、メールパスワード変更も推奨

【まだ断定できないこと】
・侵入経路や原因の全容
・販売管理システムとレンタルサーバーへの不正アクセスの具体的な関連性
・対象情報のうち実際に第三者が取得した範囲

これらは、さくらインターネットが引き続き調査中としているため、推測で原因を決めつけないことが重要です。

■ 今日のポイント

サイバー事故では、「何が起きたか」が最初から全部分かるとは限りません。

企業に必要なのは、確定報が出るまで待つことでも、すべてを止めることでもなく、影響未確定の段階から自社の依存関係と認証情報を確認し、続報に合わせて対応を段階的に変える仕組みです。

参考情報

・さくらインターネット 2026年8月17日
「当社レンタルサーバーサービスの一部環境に対する不正なアクセスについて」
https://www.sakura.ad.jp/corporate/information/newsreleases/2026/08/17/1968225614/

・さくらインターネット 2026年8月19日（8月26日更新）
「当社システムへの不正アクセスに関するお知らせ（第二報）」
https://www.sakura.ad.jp/corporate/information/newsreleases/2026/08/19/1968225633/

・さくらインターネット 2026年8月31日
「サーバーパスワードおよびメールパスワード変更のお願い」
https://help.sakura.ad.jp/notification/n-2692/