日本国内のクラウドサービスが、ランサムウェア被害を受け、多くの企業・自治体のサービスに甚大な障害が発生しました。JR東日本の会員向けメール配信サービスなどで一時的な不具合が生じ、個人情報の漏えい可能性や管理ポータルでの不正照会が確認されています。後日外部へのデータ流出は否定されたものの、バックアップ保管場所や管理境界の不備が復旧の遅れを招いたことから、クラウド利用におけるBCPの見直しや事前の出口設計の重要性が改めて浮き彫りとなりました。
また、ISMAP（イスマップ）認定を受けてる事業者であれば安全である、と言う概念が根本から覆る事態となったと言えます。
1. 政府認定（ISMAP）クラウド停止が突きつけた現実
2026年10月7日午前3時40分頃、政府の「政府情報システムのためのセキュリティ評価制度（ISMAP）」に登録されているI社のクラウドサービスの東日本リージョンにおいて、第三者からのランサムウェア攻撃を起因とする大規模なインフラ障害が発生しました。この事案は、国が厳格なセキュリティ基準への適合を認めた評価済クラウド基盤であっても、壊滅的なインフラ全面停止が起こり得るという冷徹な現実を突きつけています。従来多くの組織で運用されてきた「政府認定や各種セキュリティ認証を取得している事業者を選定していれば安全である」という調達・リスク管理の観念は、本インシデントによって根本からの刷新を迫られています。最高セキュリティ責任者（CISO）および情報システム部門責任者は、単なる一事業者の障害として片付けるのではなく、認証制度の限界と自社のガバナンス構造を解体・再定義しなければなりません。
本インシデントの影響規模は極めて広範かつ深刻でした。障害は東日本リージョンの4つのゾーンに及び、仮想サーバーの停止や再起動不可が引き起こされました。I社が直接契約する企業や自治体は495組織に上り、その影響は社会インフラや主要産業へと波及しました。具体的には、プロシーズが提供するLMS「LearningWare」での認証・通知メール機能の停止、シックス・アパートの「Movable Type クラウド版」における31台のサーバー停止、ソリトンシステムズの「Soliton SecureDesktop」の機能停止など、多数のSaaS・ITサービスが巻き込まれました。さらに、茨城県、東京都小平市、焼津市立図書館、湖西市立図書館などの自治体Webサイトが閲覧不能となったほか、日水物流の17拠点において商品の入出荷が一時停止するなど、実稼働する物理的な物流・経済活動にも直接的な支障が生じました。
本インシデントが告発する本質的なリスク（So What?）は、これが単なる「いちクラウド事業者の障害」という局所的な問題にとどまらない点にあります。自社が直接IaaSを契約していない場合であっても、利用しているSaaSの下方レイヤー（IaaSやデータセンター）が攻撃を受けて停止すれば、自社の業務プロセスそのものが麻痺する「多段サプライチェーンリスク」の脅威が顕在化しました。自社と直接契約関係にない深層のインフラ基盤の停止によってビジネスが強制停止するリスクを、現代の企業ガバナンスは正視しなければなりません。
ISMAP（政府認定）という看板があってもインフラの絶対的な安全は担保できないという前提に立つとき、我々は制度への盲目的な信頼が招く死角を検証する必要があります。次セクションでは、ISMAP等のセキュリティ評価制度が「保証するもの」と「保証しないもの」の境界線を明確に整理します。
2. セキュリティ評価制度（ISMAP等）の「適合」が保証するもの・しないもの
ISMAPをはじめとするセキュリティ評価制度や各種第三者認証は、組織が一定のセキュリティ基準や管理策を策定し、適切に運用しているかを評価・認証する仕組みです。しかし、経営層やリスク管理部門において、これらコンプライアンス（制度適合）の達成と、実際のインシデント発生時に事業を継続させる能力（サイバーレジリエンス）の担保との間に存在する「構造的ギャップ」を正しく認識できているケースは極めて稀です。このギャップを正しく理解することは、自社のサイバーガバナンスを再構築する上での戦略的な出発点となります。
明確に区別すべきは、認証基準が保証する領域と保証しない領域の境界線です。ISMAP等の適合評価が担保するのは、あくまで「あらかじめ定められた管理策（セキュリティガバナンス、組織的・技術的安全管理措置など）が整備され、評価・監査された状態にあること」です。一方で、高度化するサイバー攻撃における「インシデント発生率ゼロ」や、「侵害発生時の即時復旧性（許容停止時間内でのビジネス復元）」までは制度的に保証していません。どれほど強固な基準を満たした認証事業者であっても、未知の脆弱性や複合的な攻撃手順によって基盤が侵害される可能性（Assume Breach）を完全に排斥することは不可能です。
さらに、ガバナンス上の重大な盲点となるのが「標準契約およびSLA（サービスレベル合意書）の限界」です。クラウド事業者の多くは、標準利用規約において不可抗力や第三者による高度サイバー攻撃（ランサムウェア等）に起因する損害について免責条項を設けており、データの完全な復元責任や定常時同等の復旧時間（RTO）を法的に保証していません。
ガバナンス上の最大の死角（So What?）は、経営層や調達部門が「ISMAP登録事業者だから安全・任せておけば安心」と過信し、セキュリティやBCPの構築を委託先に丸投げしてしまう「チェックボックス・コンプライアンス」の姿勢にあります。クラウド利用における責任分界点において、インフラ事業者が責任を負うのは自社基盤の維持・運用管理であり、その上で動く業務データの保護、バックアップの実効性確保、そして自社業務の継続性維持（RTOの遵守等）は、どこまでも自社の責任範囲です。調達時のチェックシートで認証保有の有無を確認するだけでリスク管理を完了とする姿勢は、組織のBCPを無防備な状態に晒すことと同義です。
認証制度のカバー領域と自社で講じるべき対策の相違を明確化するため、以下の対比分析表に整理します。
| 認証制度（ISMAP等）が保証すること | 認証制度では保証されない（自社で講じるべき）こと |
| 規程・管理策の整備状況 第三者監査に基づくセキュリティ管理体制および運用プロセスの存在 |
実際のインシデント防止力 高度サイバー攻撃や未知の脆弱性攻撃を100%遮断する絶対的安全 |
| 提供インフラレイヤーの標準的安全管理 事業者側の物理・論理インフラにおける管理責任の遂行 |
自社データ・アプリの保護責任 責任分界点に基づく自社データのバックアップ、暗号化、アクセス権限管理 |
| 事業者の標準復旧プロセスの存在 事業者自身の手順に基づくインフラ復旧計画および基本SLA |
許容停止時間（RTO）内での業務再開 自社のビジネス許容限界時間内に合わせた代替環境への切り替え・データ復元 |
| 事業者基盤の影響調査・不具合対応 事業者側のシステム障害解析、ログ調査、一次対応 |
対外説明責任および縮退運用の遂行 顧客・規制当局への情報開示、手作業・紙等による代替業務フローの運用 |
システムが不慮の侵害によって停止した際、企業は直ちに事業継続の試練に直面するだけでなく、情報開示やステークホルダー対応という広範な対外コミュニケーションの難所に立たされることになります。次セクションでは、有事における対外発表の現実的な課題について掘り下げます。
3. サプライチェーンインシデントにおける「対外コミュニケーションの難所」
サイバーインシデントが発生した際、顧客、規制当局、株主、そして社会全体といったステークホルダーに対する情報開示と対外コミュニケーションの成否は、企業の社会的信用およびブランド価値に致命的な影響を及ぼします。自社に起因しないサプライチェーン（クラウド基盤）の障害であっても、自社サービスが停止し顧客データに懸念が生じた場合、その開示姿勢が企業のガバナンス品質を問われる踏み絵となります。
今回のクラウド障害では、基盤提供元であるI社と、その基盤を利用してサービスを提供する委託元・利用組織との間で、アナウンスのタイミングや内容（コミュニケーションの温度差）に顕著な乖離が見られ、二段階の時系列（一次公表と続報）を経る特徴的な経過を辿りました。
- 基盤提供元（I社）： 外部のセキュリティ専門企業と連携し、アクセスログ、認証ログ、操作ログの解析やファイルの調査など、技術的・法医学的（フォフォレンジック）な事実確定を優先する姿勢をとりました。結果として、障害発生（10月7日）から顧客仮想サーバー内データの持ち出し痕跡がないと判断した「第5報」の発表までに1週間（10月14日夕方）を要しました。
- 委託元・利用組織（JR東日本、ビューカード、JR九州、高島屋、JR東海、スカパーJSAT等）： メール配信外部サービス等の基盤障害を受け、技術的な確定報告を待つことなく、早い段階（10月9日〜13日）で「漏えいした可能性（閲覧・取得された可能性）を否定できない」とする第1段階の自主公表に踏み切りました。最大数百万件規模（JR東日本：えきねっと約167万件、大人の休日倶楽部約39万件、ビューカード：約403万件など）の影響可能性を自ら速やかに示し、二次被害防止を最優先としました。その後、10月14日夕方の基盤側発表を受け、10月15日頃に「調査の結果、流出の事実は確認されなかった」とする第2段階の確定続報を発表しています。
この時系列と対応のギャップは、企業の開示判断における根本的なジレンマを示しています。「フォレンジック調査の完了と確定情報を待つ姿勢」は客観的・技術的には正確ですが、完了までに数日から数週間を要するため、その間に噂や不審メールによる二次被害が発生するリスクを放置することになります。一方、「可能性ベースでの早期開示」は顧客保護と不快感・不信感の払拭に寄与する反面、確定していない情報による不要な混乱を招くリスクを伴います。
このジレンマに対する最適解（So What?）として、企業は「ベンダーからの連絡待ち」に依存しない自律的な開示プロトコルを確立しなければなりません。実際、UDトーク（10月7日9時32分公表）やネットアシストのように、ベンダーの公式第1報（10月7日13時52分）より前の段階から、外形監視や自社検知に基づき早期に障害を検知・公表した例が存在します。自社の顧客に対して誠実かつ混乱のない開示を行うためには、以下の二軸を備えた情報開示プロトコルが必要です。
- 外形監視と能動的早期検知: ベンダーからの障害通知を待つだけでなく、外形監視ツールやステータス情報の常時確認により、依存基盤の異常を自律的に早期察知する体制。
- 一次情報発信プロトコル: 「侵害の可能性が否定できない段階」において、対象となり得るデータ項目、影響範囲の最大数、当面の回避策、および確定情報の次回報告予定日時をセットで速やかに開示する基準の策定。
どれほど迅速で適切な対外対応・広報方針を定義していたとしても、それを裏で支えるシステム上の復旧手段やバックアップの設計が伴っていなければ、企業の事業継続は破綻します。次セクションでは、障害発生時に企業の運命を分けた技術的・運用的な背景を分析します。
4. 「何を、いつまで預けていたか」で分かれた企業の明暗
クラウド障害の発生時、数時間から翌日という短期間で事業を再開できた組織が存在する一方で、長期間のサービス停止やデータ失陥の危機に直面した組織が存在しました。この明暗を分けたのは、単なる運やシステムの規模ではなく、平時におけるバックアップの「配置場所」「世代管理」および「管理境界」の設計思想にありました。
本インシデントにおいて迅速な復旧（＝明）を果たした実例として、シックス・アパートの取り組みが挙げられます。同社は「Movable Type クラウド版」の障害対象31台のサーバーについて、I社クラウドとは全く異なるクラウド基盤である「Google Cloud」上に7世代分のバックアップを日次で保管していました。I社クラウド上での早期復旧が困難と判断するや否や、障害発生（10月7日）翌日の10月8日21時までに「さくらのクラウド」へと全31台の暫定移行・復旧を完了させました。また、サイバー大学（10月7日1時時点の独自バックアップを利用し別クラウドへ10月15日再構築完了）やポピンズも、退避保管していた独自のバックアップデータを活用し、別プラットフォームや別の安全なデータセンター環境上にシステムを短期間で再構築・段階再開させました。
一方で、復旧に難航・制約を受けた例（＝暗）としては、本番環境と同一基盤上にバックアップサーバーを配置していたケース（ソリトンシステムズなど）があります。基盤そのものが侵害・暗号化されたことで、バックアップサーバー自体も巻き込まれて利用不能となりました。また、事業者の「スナップショット機能」に復旧を全面的に依存していた194の組織は、事業者側でバックアップデータの安全性が確認され取り出しが可能と発表されるまでに、発生から1週間（10月14日の第5報）を要しました。さらに、同一事業者内の別リージョンへ複製していた場合でも、I社が被害拡大防止の予防措置として他リージョンの管理コンソールを一時停止したため、利用者が操作不能になる事態が生じました。
データ管理の頻度と世代管理の落とし穴を示す例として、茨城県のケースが挙げられます。同県では委託先に前年2月時点（約1年8ヶ月前）という極めて古いバックアップデータしか残っておらず、見つかったデータを基に情報を補完・手作業で再構築せざるを得ず、早期の完全復旧に多大な工数を要しました。
これらの差を裏付ける統計として、警察庁サイバー警察局の「サイバー空間をめぐる脅威の情勢等について（令和7年）」のデータが挙げられます。同統計によると、ランサムウェア被害を受けた組織のうちアンケートに有効回答した116件中105件（90.5%）がバックアップを取得していたものの、実際に入手・復元できたのは有効回答99件中20件（20.2%）にとどまっています。この事実は、「バックアップを取得しているか」という問いと「侵害時に実際に復元できるか」という実効性との間に絶望的な剥離が存在することを示しています。
実効性を決定づけるガバナンス上の評価軸（So What?）は、本番環境とバックアップ環境の「管理境界」および「距離（クラウド・ダイバーシティ）」です。同一のクラウド事業者、同一のリージョン、同一の管理者権限で管理されているバックアップは、基盤侵害や強マルチテナント権限の奪取が行われた際、本番データと同時に消失・破壊される運命にあります。真のレジリエンスを確保するには、本番環境から独立した別事業者クラウドへの保管や、権限を隔離した変更不可（イミュータブル）設定の導入が不可欠です。
バックアップ配置方針ごとの実効性を整理した比較表は以下の通りです。
| バックアップ配置方針 | 基盤侵害時の復旧可能性 | コスト・運用負荷 | 今回の事案に照らした評価・実効性 |
| 1. 本番と同一基盤内のスナップショット/バックアップのみ | 低い | 低 | 実効性薄。 同一基盤内のバックアップサーバーが同時に利用不能となった事例が発生。スナップショットも事業者側のデータ取り出し確定まで1週間を要し、初動のRTOを満たせない。 |
| 2. 同一事業者の別リージョン複製 | 中 | 中 | 不十分。 今回、I社が予防措置として他リージョンの管理コンソールを停止したように、事業者全体の管理プレーンが停止した場合、復旧操作そのものが不能となる。 |
| 3. 別事業者クラウドへのバックアップ保管（マルチクラウド） | 高い | 中〜高 | 有効。 シックス・アパートのように、障害基盤から完全に独立した別クラウド（Google Cloud等）のバックアップを用い、第三のクラウド（さくらのクラウド）へ翌日移行を達成した成功パターン。 |
| 4. 別事業者クラウド ＋ イミュータブル（変更不可）/オフラインコピー併用 | 最も高い | 高 | 最高度のレジリエンス。 基盤侵害だけでなく、管理者権限の奪取やランサムウェアによる暗号化・破壊攻撃に対しても確実に復元データを隔離・保護できる真の安全構成。 |
これらすべての技術的・運用的な教訓を統合し、自社の調達基準とリスク管理体制を刷新するための具体的な改革ステップへと進みましょう。
5. まとめ 調達基準のアップデートとこれからのクラウドリスク管理
I社クラウドの障害事案がセキュリティ実務者に与えた最大の示唆は、従来の「境界防御」や「認証への適合（コンプライアンス）」を中心としたリスク管理からの完全な脱却です。これからのクラウド戦略においては、強固なセキュリティ認証を前提として求めつつも、万が一インフラ基盤が完全に侵害・破壊されること（Assume Breach）を前提とした事業継続戦略（サイバーレジリエンス）へと、調達基準および運用基準をアップデートしなければなりません。
有事において事業を止めない組織へ変革するためには、情シス単体で対策を閉じるのではなく、「経営層」「事業部門」「情シス・セキュリティ部門」の3者が明確な役割分担のもと合意形成を図るガバナンス構造の構築が不可欠です。
- 経営層: 最終的なリスク受容判断、BCP投資（別基盤バックアップや訓練費用）の予算承認、および全社的な棚卸し指示を行う。
- 事業部門: 各業務が何時間止まると事業維持が困難になるかという「許容停止時間（RTO）」の線引きと、システム停止時の「手作業・紙等による代替業務フロー」を策定・運用する。
- 情シス・セキュリティ部門: 全社の依存関係を可視化・台帳化し、技術的な管理境界（権限分離・マルチクラウド構成）の基準提示とリストア演習の統括を行う。
このガバナンス構造に基づき、組織が取り組むべき3つの核心的アプローチおよび段階的実行ロードマップ（時間軸）を提示します。
- 依存関係の可視化と棚卸し: 自社が直接契約するIaaSだけでなく、利用しているすべてのSaaSおよび業務委託先がどのクラウド事業者（IaaS）、リージョン、データセンターに依存して稼働しているかを特定し、全社的な「クラウド依存関係台帳」を作成・維持する。
- バックアップ管理境界の点検・隔離: 本番環境の管理者権限や同一クラウド基盤から物理的・論理的に分離された「管理境界」を設計する。本番アカウントの侵害でも削除・暗号化されないイミュータブル（変更不可）保管や、別事業者クラウドへのバックアップ保管（クラウド・ダイバーシティ）を義務付ける。
- 出口戦略（Exit Strategy）と復旧訓練の定常化: 特定のクラウド事業者や基盤が長期間復旧しない事態を想定し、代替クラウド環境やオンプレミス環境への切り替え手順（DNS変更、証明書、縮退運用の手順）を事前に策定する。単にデータを「保存する」だけでなく、年1回以上の実地リストア演習を通じて「復元可能性」を検証・証跡化する。
段階的実行ロードマップ（アクションプラン）
- 今週中（即時リスクの把握）: 自社のバックアップ構成を確認し、本番環境と同一基盤・同一管理者権限で破滅し得る構成（同一クラウド内のスナップショットのみ等）が存在しないかを点検。重大リスクがあれば経営層へ即時報告する。
- 1か月以内（依存関係の棚卸し開始）: SaaS・業務委託先を含めた下方IaaS/データセンターの依存関係棚卸しに着手。新規契約審査時のチェックシートに「稼働IaaS」および「バックアップ分離状況」の確認項目を追加する。
- 3か月以内（管理境界の再設計・予算化）: 許容停止時間（RTO）を超えるリスクのある重要システムについて、別事業者クラウドへのバックアップ系統追加やイミュータブル保管の導入を設計し、必要なコスト・工数を予算化する。
- 6か月以内（リストア訓練と出口演習の実施）: 別基盤バックアップからの復元テスト（リストア訓練）および、主要クラウド停止を想定した事業継続机上演習を実施し、監査証跡として記録する。
現場の情報システム部門およびCISOが、社内監査シートとして即座に活用できるチェックリストを以下に用意しました。
【CISO・セキュリティ担当・情シス向け】クラウドリスク点検チェックリスト
- [ ] 自社で利用しているすべてのSaaS・委託先サービスの下方IaaS事業者・リージョン・データセンターを把握し、台帳化しているか
- [ ] 重要業務ごとに、システム停止時の許容停止時間（RTO）および許容データ損失地点（RPO）が定義され、事業部門および経営層と合意されているか
- [ ] システム停止時に事業を維持するための代替業務フロー（手作業・紙運用・代替ツール等）が事業部門側で策定されているか
- [ ] バックアップデータが、本番環境と異なるクラウド事業者（または異なる管理権限の境界）に保管されているか
- [ ] バックアップの削除・変更権限が、本番環境の管理者権限から独立・分離されているか
- [ ] ランサムウェアによる暗号化・削除を防ぐイミュータブル（変更不可）設定、またはオフラインコピーを少なくとも1系統保持しているか
- [ ] 本番基盤とは異なる代替環境（別クラウド等）へのリストア手順が文書化され、年1回以上の復元訓練（演習）を実施して証跡を残しているか
- [ ] 依存先の障害を能動的に検知する外形監視体制があり、ベンダーの公式連絡待ちに頼らない一次情報開示プロトコルを定めているか
セキュリティ投資やレジリエンス対策を、単なる「コスト」や「コンプライアンス上の義務」として捉える時代は終わりました。ISMAP認定のI社クラウド事案が示したように、依存先の障害は自社のセキュリティ投資だけでは防ぎきれませんが、平時の適切な設計と投資によって被害の極小化と早期復旧は十分に可能です。サイバーレジリエンスの強化を、企業の競争力と顧客信頼を揺るぎないものにするための「戦略的投資」と位置づけ、今すぐ自社基盤の点検とガバナンス改革に着手することを強く提言します。
これから取り組むべき具体的な施策について
SCSKでは、クラウドサービス「USiZE」を提供しております。USiZEでは、いち早く2024年からランサムウェア対応したバックアップサービスを実装しております。また、USiZEをご利用されていないお客様環境（オンプレミス）にあるサーバを守るためのランサムウェア対応したバックアップサービスも提供しております。また、USiZEは東西でBCP環境をご利用すること可能です。
今回のI社クラウドのランサムウェア被害は、公式で侵入経路（VPN機器の脆弱性悪用や認証情報奪取など）や、特定攻撃グループ名は公表されていません。
特に日本国内のランサムウェア被害では、侵入の原因となったVPN装置や、検知できなかったEDR製品を公表することは殆どありません。先日のデジタル庁の運用するガバメントソリューションサービス（GSS）の不正アクセスのようにVPN機器の脆弱性が原因であることは公表されても、利用していた機器名称が公表されることはありません（一部のサイトで、Palo Alto Networks の可能性を指摘）
ISMAP認証だけではなく、クラウドサービス自体のBCP対応、ランサムウェア対応（イミュータブルバックアップ他）はもちろんですが、クラウドサービス基盤の裏側の運営側システムで、きちんと多層防御が行われいてるか？ゼロトラストアーキテクチャが採用されているか？（VPN機器ではなくZTNAを利用しているか？）などの確認が今後は必要となっています。
フロンティアAI時代は、ゼロトラストの原則である「侵入は避けられない（Assume Breach）」としたサイバーレジリエンスが実装されていることが最も重要であり、フロンティアAIレディの「3層防御モデル」、特にランサムウェア被害で、最も課題となるラテラルムーブメント（横移動）を阻止する具体的なソリューションとしては 次世代マイクロセグメンテーション Zero Networks を強くお勧めしております。
具体的には、Zero Networks では、サーバ・クライアントといったホスト単位でネットワーク分離（＝セグメンテーション）するのはもちろんのこと、特許技術を用いて管理ポート（RDP/SSH等）をデフォルトで閉鎖し、ジャストインタイム（Just-In-Time：JIT）で多要素認証（MFA）を適用することが可能です（≒特権ID管理）これまでのレガシーマイクロセグメンテーションとは全く異なる”完全エージェントレス型”で、通信可視化からAIによるポリシー自動生成が可能なため短期間の導入が可能です。
すでに多くの引き合いをいただいておりますが、Zero Networks に興味をもたれた方は、ぜひお問い合わせください。
最後に、2026年11月11日、Zero Networks とマイクロセグメンテーションと組み合わせることで完全なゼロトラストを実現する SASE（Secure Access Service Edge、サッシー）、今までのウィルス対策ソフト・EDRと異なり、AI ディープラーニング（深層学習）にて非常に高い検知率を誇る次世代エンドポイントソリューション、そして攻撃者が侵入後に真っ先に狙うバックアップデータ破壊を保護し、確実な復旧を早期に実現するためのゼロトラストデータ保護ソリューションなど、多層防御とゼロトラストを実現する4つのベスト・オブ・ブリードのセキュリティソリューションをご紹介するオンラインセミナー（無料）を開催しますので、ぜひご参加ください。
最後までお読みいただき、ありがとうございました。