既報の通り、ソフトバンクグループIDCFが運営するクラウドにランサムウェア攻撃があり、公表されているだけで、官公庁、民間企業等495利用者に影響が出ています。
みんカラのサービスもこのクラウドを利用していた為、サービスが停止しました。
IDCFのサイバー攻撃について、公表されている概要は、以下の通りです。
○ 発生日時: 2026年10月7日 午前3時40分ごろ。
○ 被害箇所: IDCFクラウドの「東日本第1リージョン」（福島県白河市のデータセンター）が標的となった
○ 影響: 茨城県など495の自治体や企業で、Webサイトの閲覧不可やシステムの一斉停止といった広範囲な障害が発生
○ 現在、ネットワークの遮断とシステムの停止措置が行われ、侵入経路の特定と復旧作業が進められています。
推定されている手口等は、以下の通りです。
個別のクラウド利用者（テナント）ではなく、クラウドの土台となる「仮想化基盤（ハイパーバイザー）」や管理コントロールプレーンそのものが乗っ取られた非常に深刻な事態です。
攻撃者が利用者の管理画面に残したとされる犯行声明（※IDCFによる公式確認は未了）では、以下のような甚大な被害が主張されています。
① 管理基盤の突破にかかった時間はわずか「7分」。
② 239台のハイパーバイザーと、リージョン内の全225のデータストアを制圧。
③ 3.6PB（ペタバイト）に及ぶ本番データ（16,600以上の仮想マシンディスク）を暗号化。
復旧を困難にし、要因事態をさらに悪化させているのが、バックアップデータの同時喪失です。
攻撃者は、本番データの約11倍にあたる41.5PBのバックアップ容量と、55万件以上のスナップショット（復元ポイント）を破壊したと主張しています。
多くの利用者は「本番データと同じリージョン・同じ管理基盤内」にバックアップを保存していたため、本番環境と同時にバックアップも破壊される共倒れが発生しました。
報道等のインタビューに答えていた利用企業の担当者が、運営会社から「復元が難しい」との通達があったそれていることと一致しています。
以下、IDCFの発表内容は、以下を確認願います。
https://www.idcf.jp/
画像は第２報です（10月11日現在、第４報まで出ています）
みんカラは、10月7日21:59頃、突然、サービスが停止し、利用画面から、障害発生のテンプレート画面が表示されました。
10月7日22:07頃には、公式Xで、障害告知が行われました。
社内規定を盾に障害発生の告知を頑なに拒んできたみんカラの運営としては異例の早さでした。
ランサムウェア攻撃の被害の大きさに敏感に反応したのかもしれないです。
翌日には、トップ画面の障害告知画面のテンプレートも差し替えられました。
さて、IDCFが公表している攻撃を受けた10月7日03:40頃から利用者がサービス停止を知った22:00頃までのラグですが、以下の要因が考えられます。
１． 侵入完了と「破壊・暗号化」のタイムラグ
「7分で侵入を許した」というのは、攻撃者が認証を破り、特権権限（管理者権限）を取得して管理システム内に足場を固めるまでの時間（初期アクセス〜制圧）を指します。
権限を奪取した後、攻撃者は通常以下のステップを踏みます。
① ネットワーク構造の把握と標的（データストアやバックアップ）の特定
② 悪意のあるランサムウェアの全ハイパーバイザーへの配布
③ バックアップの消去処理と、データ暗号化スクリプトの一斉実行
この為、権限を取ってから実際に破壊コマンドを実行するまでにはタイムラグが発生します。
２．メモリ上で動作するWebサーバーの特性
みんカラのWebサーバーやアプリケーションサーバー（IDCF上の仮想マシン）は、すでに起動してメモリ（RAM）上で動いていたと推定されます。
例え、バックエンドの管理基盤が乗っ取られたり、ストレージ領域へのアクセスが遮断され始めたりしても、メモリ上ですでに動いていたプロセスはすぐには停止せず、一定時間Webレスポンスを返し続けることができます。
サービス停止前にレスポンス低下（〜20:00頃）を感じていましたが、これは、ストレージへのアクセス制限や、基盤側での暗号化処理（I/O負荷の急増）、あるいはIDCF側によるネットワークの緊急遮断作業が始まったことで処理が遅延し始めた可能性を示唆していると推察しています。
完全停止（21:00頃）は、暗号化処理が完了してOSがクラッシュしたか、IDCFア側が被害拡大を防ぐために物理サーバーの電源オフやネットワークの物理切断（強制隔離）を完了したタイミングの可能性が考えられます。
３．DB層（AWS）が生存していたことによる粘り
みんカラの場合、ユーザーからのリクエストの多くは「AWS上のデータベース」から読み出す処理（記事閲覧や検索など）です。
アプリサーバー（IDCF）側が瀕死の状態にあっても、データ本体（AWS）が生きていたため、完全停止する最後の瞬間まで一部の閲覧処理などが維持され、結果として「20時頃まで粘っていた」ように見えたと推察されます。
４．キャッシュ層（CDNなど）の残存
大型Webサービスであるみんカラでは、ユーザーとサーバーの間にCDN（コンテンツ配信ネットワーク）やキャッシュサーバーが設置されている可能性が高いと考えられます。
IDCF上のオリジンサーバーが攻撃の影響を受け始めても、CDN上に残っていた静的キャッシュデータがユーザーに返され続けていたため、表面上はサービスが稼働しているように見えていた可能性があります。
以上が、以前からIT業界内で公開されていた情報、Webシステムの特性、本件のプレスリリースから推定した概要になります。
ここで、標準的なWebシステムの構成（Web３層光添え）について、簡単に説明します。
ここまでの説明もこのWebシステムの「3層アーキテクチャ（3層構造）」を前提に説明して来ました。
Webシステムの「3層アーキテクチャ（3層構造）」は、システム全体の処理を「受付・画面表示」「計算・プログラム実行」「データの保存・管理」の3つの役割に分割して運用する設計手法です。
レストランに例えると、フロントサーバーが「ウェイター（接客）」、アプリケーションサーバーが「シェフ（調理）」、データサーバーが「食材庫（保管）」の役割を果たします。
一部推測が含まれますが、みんカラの場合
○ フロントサーバー
ユーザーからのリクエスト受付、静的コンテンツの配信、処理の振り分け
みんカラの場合は、各コンテンツ（ブログ、何シテル、整備手帳、パーツレビュー等）をユーザーからのリクエストに従い振り分ける機能になります。
おそらくの基盤はYahoo！のコンテンツの共通基盤ではないかと推察しています。
そして、ここは外部からの検索機能が直接流入してくる場所ですので、大量アクセスや、悪意のあるスクレイピング（データの無断自動収集）、サイバー攻撃（DDoS攻撃など）をフロントサーバーの段階で検知・制限（レートリミット）していると推察しています。
あと、実際、どの程度の処理構成なのか不明ですが、一般的には、ここに負荷分散機能を持たせます。
大量アクセスは1台のフロントサーバーではさばききれない為、複数台のフロントサーバーを並べ、アクセスを均等に分散して受け止める構造にします。
今までのみんカラの傾向を見ていると、この負荷分散機能が若干弱いのではないかと感じることがありました。
○ アプリケーションサーバー（バックエンドサーバー）
ビジネスロジック（計算・認証・決済など）の実行、動的コンテンツの生成
みんカラの場合は、各コンテンツ（ブログ、何シテル、整備手帳、パーツレビュー等）の機能（アプリケーション）本体が配置されている場所になると推察されます。
また、これも一般的な推測ですが、これだけ異なるコンテンツ（機能）を配置する場合、機能毎にサーバーを分けるのが一般的です（処理の重さによって同居することもある）
おそらくカービュー（オートビレッジを含む）がYahoo！に統合されるまでの約26年間の変遷の中で迷宮建築のような構成になって、その再編が十分できていないのではないかと感じます（特にWebとモバイルのUIの不一致等で）。
○ データサーバー（DBサーバー）
データを格納するDB層、動画や画像等、重いデータを主に扱う場合には、ここはデータ管理層（インデックス管理）として機能し、データ本体はストレージに格納するのが一般的
みんカラの場合、ここは Amazon RDS で構築されていると推察しています。
そして、機能としては、ストレージのどこに・誰の・どんな写真が入っているかを記録したインデックス（索引・目録）として機能している考えられます。
推論になりますが、「誰が誰をフォローしているか」「イイね！が何件ついたか」「燃費記録の計算データ（走行距離÷給油量）」は、ここに保管されていると推察しています。
○ ストレージ
3層と言いながらもう１つあるのがデータ本体を格納している場所
巨大で高性能なHDDの塊とイメージして頂ければ良いかと思います。
みんカラの場合、ここに画像データの本体が格納されていると思います。
プラットフォームは、AWS S3を使用していると推察しています。
本体側とストレージの構成イメージは略図の通りです。
今回のサイバー攻撃で、みんカラが無事に復旧できたのは、全てをIDCFのクラウド上に構築しないで、機能的に幾つかのクラウドを使い分けるマルチクラウドの構成になっていたことが大きいと推察しています。
サービスが十分に提供されず、障害が発生していても社内規定を盾に頑なに告知を拒否する姿勢から、まともなサーバー構成ではないと思われがちですが、実はかなり高度な構成になっていると推察され、問題は、扱う人間（運用）のスキルとモラルではないかと思っています。
連日のようにサイバー攻撃がニュースで扱われ、実際、利用者登録を行っているサイトから毎日のように情報流失を知らせるメールが届いていますが、攻撃元の多くは、中露、北朝鮮と言った敵国であり、我が国の経済、国民の安全の脅威になっている訳ですから、これは相手側からの侵略行為（電子的攻撃）と捉え、敵地攻撃（反撃）を国として徹底的に行って欲しいと強く思います。
国家規模の攻撃でなく単なる犯罪者集団の行為だとしても
日本は攻撃しても反撃してこない
脅せば金を出す
これでは、益々相手の行為はエスカレートするだけだと思います。
#サイバー攻撃 #ランサムウェア #電子的侵略行為
IDCFクラウドに対するサイバーウェア攻撃 
既報の通り、ソフトバンクグループIDCFが運営するクラウドにランサムウェア攻撃があり、公表されているだけで、官公庁、民間企業等495利用者に影響が出ています。
10月3日、防衛省は「北朝鮮のミサイル等関連情報」を以下の通り、発表しました。
いまいまお客様対応と決算処理が重なり、ブログのアップ数は低下していますが、平常時はかなり多いので、相手によっては、私のブログ等でタイムラインを埋めてしまい迷惑になる可能性があり、こちらからフォローのお誘いは、この10年近く一切行っていません。
＜ハイタッチ！drive利用履歴＞
明日、2026年10月1日
