--- title: "大阪公立大学のランサムウェア被害と仮想化基盤の停止｜全授業休講に至った経緯とバックアップを守る設定" url: "https://www.issoh.co.jp/tech/details/18178/" published: 2026-10-08 updated: 2026-10-08 categories: ["セキュリティ"] publisher: "株式会社一創" --- # 大阪公立大学のランサムウェア被害と仮想化基盤の停止｜全授業休講に至った経緯とバックアップを守る設定 大阪公立大学は2026年10月2日未明、情報基盤システムで大規模な障害が起きたと公表しました。10月5日の記者会見では、原因をランサムウェアによるサイバー攻撃と判断していると説明しています。学内ネットワーク、メール、Webサイト、教務、財務会計、人事給与までが止まり、全キャンパスで授業が10月8日まで休講になりました。本記事では大学の公式資料をもとに経過を整理し、報道で伝えられた数値とは分けて扱います。後半では、被害の中心となった仮想化基盤の点検手順と、攻撃者に消されないバックアップの設定を示します。 ## まとめ：大阪公立大学のランサムウェア被害で確定した事実と点検すべき2つの層 公式資料で確定しているのは、10月2日午前0時20分ごろに保守を委託された事業者がサーバーの順次停止を確認したこと、調査で仮想サーバー群の停止と一部データの改ざんの形跡が見つかったこと、同日午前8時15分に危機対策本部を設けたことです。10月5日には個人情報保護委員会へ連絡し、会見でランサムウェア攻撃と判断していると述べました。医学部附属病院と獣医臨床センターのシステムには影響がないとしています。 侵入経路、使われた製品、攻撃者、身代金の要求、個人情報の流出の有無は公表されていません。同じ構成を持つ組織が見るべき点は二つです。一つは、多数の仮想サーバーをまとめて動かす管理基盤そのものの守りです。もう一つは戻す手段で、会見を伝えた報道では、復元に使うはずのバックアップの多くも暗号化されたとされています。 | 項目 | 内容 | 根拠 | | --------- | ------------- | -- | | 障害の発生 | 2026年10月2日 未明 | 公式 | | 被害の中心 | 仮想化基盤システム | 公式 | | 原因の判断 | ランサムウェア攻撃 | 公式 | | 授業 | 10月8日まで休講 | 公式 | | 停止したサーバー | 約500台 | 報道 | | 保管された個人情報 | 少なくとも約13万人分 | 報道 | | 流出の有無 | 調査中 | 公式 | ## 公式資料で時系列を確認する｜10月2日未明のサーバー停止から10月5日の会見まで ### 午前0時20分の停止確認から午前8時15分の危機対策本部設置までの8時間 [記者会見の配付資料](https://www.omu.moe/news-files/2026-10-06-7fb5a624/press-conference-materials%5F20261005.pdf)の資料2によると、経過は次のとおりです。 | 10月2日の時刻 | 状況・対応 | | -------- | ----------------- | | 0時20分ごろ | 委託先がサーバーの順次停止を確認 | | 1時40分ごろ | 委託先から大学の情報部門へ連絡 | | 2時00分ごろ | 遠隔での対応が難しく現地対応を決定 | | 4時00分ごろ | 委託先の技術者が到着し本格調査 | | 4時以降 | 仮想サーバー群の停止と改ざんの形跡 | | 7時00分ごろ | 学生向けに休講を案内 | | 8時15分 | 危機対策本部を設置 | | 11時00分ごろ | 文部科学省・関係団体・警察へ報告 | 停止の確認から大学への連絡まで約80分、技術者の現地到着まで約3時間40分がかかっています。深夜の障害で、遠隔からの調査が難しかったことが資料に書かれています。夜間に委託先が異常を見つけたとき、誰にどの順で連絡し、誰が現地に入るかは、運用契約を結ぶ段階で決めておく事項です。委託先を選ぶときに確かめる点は[システム運用保守の会社はどう選ぶ](https://www.issoh.co.jp/column/details/16402/)で整理しています。 ### 授業・入試・附属病院への影響と10月9日からの対面授業の再開予定 10月2日の[第1報](https://www.omu.moe/news/2026-10-02-outage-1.html)は、全キャンパスで学内システムの利用が止まったこと、復旧のめどは不明であることを伝えました。同日の[第2報](https://www.omu.moe/news/2026-10-02-outage-2.html)では、10月8日までの授業を休講とし、10月9日以降に対面授業を再開する予定だと示しています。オンライン授業の再開は復旧の状況を見て判断するとしました。 入試では、Web出願と入学手続のサイトが学外のサーバーで動いていたため、登録は続けられました。一方で募集要項と一部の出願書類が入手できなくなり、大学は[10月4日の追記](https://www.omu.moe/news/2026-10-02-exam-application.html)で、出願期間を10月22日17時まで、入学手続期間を10月22日12時まで延ばしています。外部に置いたシステムが残り、学内に置いたシステムが止まったという分かれ方は、どの業務をどこで動かすかを決める材料になります。 ### 製品名・侵入経路・情報流出が未公表の段階で書けることと書けないこと 10月6日掲載の[記者会見の報告](https://www.omu.moe/news/2026-10-06-7fb5a624.html)は、仮想化基盤システムで障害が起きたこと、ランサムウェア攻撃と判断していること、外部の専門事業者の支援で調査を進めていることを記しています。配付資料の資料3は、被害を受けた主なシステムとして学内ネットワーク、OMUメール、各Webサイト、教職員ポータル、事務端末、財務会計、人事・給与、教務、教育支援、入試の情報データベース、図書館を挙げました。 公式の資料は、仮想化に使っている製品、侵入経路、攻撃グループ、身代金の要求、データの持ち出しに触れていません。停止したサーバーが約500台、保管されていた個人情報が少なくとも約13万人分、バックアップの多くも暗号化された、という数値は会見を伝えた報道によるもので、配付資料には載っていません。本記事は特定の製品や攻撃者に結び付けた推測をせず、仮想化基盤を持つ組織の点検の観点として以降を書きます。 ## 仮想化基盤が狙われる構図｜ハイパーバイザーの暗号化で数百台が同時に止まる理由 ### 管理基盤を1か所押さえれば全ての仮想サーバーに届く攻撃者側の効率 仮想化基盤では、1台の物理サーバーの上で数十台の仮想サーバーが動き、その物理サーバー群を束ねるのが管理サーバーです。仕組みの基本は[仮想化技術とは](https://www.issoh.co.jp/tech/details/13097/)で解説しています。攻撃者がハイパーバイザーの管理者権限を得ると、仮想サーバーの一つひとつに侵入しなくても、その下に置かれたディスクのファイルを暗号化するだけで全ての仮想サーバーを止められます。 Microsoftは2024年7月の[セキュリティブログ](https://www.microsoft.com/en-us/security/blog/2024/07/29/ransomware-operators-exploit-esxi-hypervisor-vulnerability-for-mass-encryption/)で、ESXiのハイパーバイザーを狙う攻撃を報告しています。多くのセキュリティ製品はハイパーバイザーの中を見る手段が限られること、ファイルシステムの暗号化で全ての仮想マシンに一度に影響を与えられることを、狙われる理由として挙げました。同社のインシデント対応でESXiを狙った案件は、3年で2倍を超えたとしています。 ### Active Directoryの「ESX Admins」グループで管理者権限を得た手口 同じブログが報告した手口は、ESXiをActive Directoryに参加させている環境で、ドメインに「ESX Admins」という名前のグループを作り、そこに自分のアカウントを足すというものです。ESXiはこの名前のグループの所属者に、既定で完全な管理者権限を与えていました（CVE-2024-37085）。ドメインの権限を奪った攻撃者は、ハイパーバイザーの管理者にもなれたわけです。 2023年2月には、インターネットに公開されたESXiの古い脆弱性を突くESXiArgsが世界中で広がり、米CISAが[復旧の手引き](https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-039a)を出しました。ESXiを最新版にすること、ホストをインターネットへ直接さらさないことが基本の対策です。大阪公立大学の製品構成は公表されていないため、ここでの例は事案の原因を示すものではありません。仮想化基盤を持つ組織が確かめる点の例として読んでください。 ## PowerCLIでESXiホストの露出を棚卸しする｜SSH・ロックダウン・AD連携の3点 ### 全ホストのバージョン・SSH・ロックダウンモードを1行ずつ出すスクリプト VMware vSphereを使っている場合、管理サーバーに接続したPowerCLIで、全ESXiホストの状態を一覧にできます。読み取りの操作だけなので、運用中の環境で試せます。 ``` # PowerShellで実行する。VMware PowerCLI が入っていること Connect-VIServer -Server vcenter.example.ac.jp Get-VMHost | ForEach-Object { $h = $_ $svc = Get-VMHostService -VMHost $h $auth = Get-VMHostAuthentication -VMHost $h $auto = Get-AdvancedSetting -Entity $h ` -Name 'Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd' ` -ErrorAction SilentlyContinue [pscustomobject]@{ Host = $h.Name Version = "$($h.Version) build $($h.Build)" Lockdown = $h.ExtensionData.Config.LockdownMode SSH = ($svc | Where-Object Key -eq 'TSM-SSH').Running EsxiShell = ($svc | Where-Object Key -eq 'TSM').Running ADDomain = $auth.Domain AutoAdd = $auto.Value } } | Export-Csv .\esxi_inventory.csv -NoTypeInformation -Encoding UTF8 ``` 出力のうち、SSHとEsxiShellがTrueのホストは、保守の作業が終わったあとも遠隔からログインできる状態のまま残っています。Lockdownが`lockdownDisabled`のホストは、管理サーバーを通さない直接のログインが可能な状態です。Versionはベンダーの更新情報と突き合わせ、修正版が出ている脆弱性が残っていないかを確かめます。 ### ロックダウンモードを掛ける前に例外ユーザーと復旧手順を決めておく理由 ロックダウンモードは、ESXiホストへの直接ログインを止め、操作を管理サーバー経由に限る機能です。Broadcomの[ナレッジ記事 336894](https://knowledge.broadcom.com/external/article/336894/)によると、ノーマルとストリクトの2種類があり、ストリクトではホストの画面からの操作（DCUI）も止まります。管理サーバーとの接続を失ったとき、例外ユーザーを決めていないと、ホストを入れ直すしか戻す方法がなくなる場合があります。 まずノーマルモードを全ホストに掛け、例外ユーザーにはバックアップ製品などのサービス用アカウントだけを入れるのが現実的な順番です。AD連携のホストでAutoAddが`true`のまま残っていれば、「ESX Admins」グループの扱いを見直します。管理者のグループ名を独自のものに変え、ドメイン側の作成と所属の変更を監視の対象に加えてください。ログの見方は[不正アクセスのログ確認・解析方法](https://www.issoh.co.jp/tech/details/2788/)にまとめています。 ## バックアップの多くが暗号化された報道から考える｜消せない保管庫を作る設定 ### 警察庁の集計で復元を試みた40件のうち29件が戻せなかった理由 [警察庁の令和8年上半期の集計](https://www.npa.go.jp/news/release/2026/20260909001.html)では、ランサムウェアの被害報告は123件でした。バックアップから復元を試みた有効回答40件のうち、戻せたのは11件にとどまります。戻せなかった29件の理由は、バックアップ自体の暗号化・消去が14件、運用の不備が8件、その他が7件です。侵入経路の有効回答36件では、VPN機器が18件、リモートデスクトップが9件でした。 仮想化基盤のバックアップは、同じ管理者権限で操作できる場所に置かれやすい構造です。ハイパーバイザーやバックアップサーバーの管理者権限を取られれば、攻撃者は暗号化の前にバックアップを消すか暗号化できます。問うべきは取得の有無ではなく、本番の管理者権限を奪われても消せない場所に複製があるかです。戻す手順の考え方は[リカバリーとは](https://www.issoh.co.jp/column/details/13354/)で、方式の違いは[システムバックアップとは](https://www.issoh.co.jp/column/details/13448/)で解説しています。 ### AWS Backup Vault Lockのコンプライアンスモードで保管庫固定用CLI 学外に複製を置く方法の一つが、AWS Backupの[Vault Lock](https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html)です。コンプライアンスモードでロックを掛けると、猶予期間が過ぎたあとは、保管庫とロックの設定を誰も変更・削除できなくなります。AWS Backupはバックアップゲートウェイを置けば、オンプレミスのVMware仮想マシンも対象にできます。 ``` # バックアップ専用の保管庫を作る aws backup create-backup-vault \ --backup-vault-name univ-offsite-vault \ --region ap-northeast-1 # 最小保持7日・最大保持35日、猶予期間3日のコンプライアンスモードでロックする aws backup put-backup-vault-lock-configuration \ --backup-vault-name univ-offsite-vault \ --min-retention-days 7 \ --max-retention-days 35 \ --changeable-for-days 3 \ --region ap-northeast-1 # ロックの状態を確かめる（Locked・LockDate・保持日数） aws backup describe-backup-vault \ --backup-vault-name univ-offsite-vault \ --region ap-northeast-1 ``` `--changeable-for-days`を付けるとコンプライアンスモードになり、付けなければガバナンスモードになります。猶予期間は3日以上で、その間はロックを外せます。期間が過ぎると取り消せないため、保持日数とコストを猶予期間のうちに確かめてください。保管庫を操作するAWSアカウントは、学内のActive Directoryと切り離した別の認証で管理し、多要素認証を必ず掛けます。方式の選び方は[多要素認証（MFA）とは](https://www.issoh.co.jp/tech/details/13314/)で比べています。 ### 学外に複製を持つべき組織と管理基盤内のスナップショットで足りる場面 財務会計・人事給与・教務・入試のように、止まると学外への説明が要る業務を仮想化基盤に載せている組織は、管理基盤の外にある消せない複製を持つべきです。大阪公立大学の資料3に並ぶシステムは、ほぼこの条件に当てはまります。 逆に、仮想化基盤の上に載っているのが他のシステムから作り直せる検証環境だけなら、学外の複製は過剰です。その場合はハイパーバイザー側のスナップショットと、作り直しの手順書で足ります。判断の分かれ目は、データの作り直しにかかる日数が業務の許容停止日数を超えるかどうかです。兄弟記事の[佐賀大学のランサムウェア被害と事務NASの暗号化](https://www.issoh.co.jp/tech/details/18097/)では、NAS単体の事案でS3 Object Lockを使う例を示しています。 ## 大学と運用委託先が点検する順番｜夜間の連絡体制・報告・第三者の診断 ### 委託先との夜間の連絡経路と現地対応の取り決めに関する4項目の点検 今回の経過表は、夜間の異常の発見が委託先から始まったことを示しています。点検は次の4項目から始めます。 1. 委託先が異常を見つけたとき、大学側の誰に、電話とメール以外のどの手段で連絡するかを決める（メールが止まる前提で考える） 2. 遠隔で調査できない場合に、誰が何時間以内に現地へ入るかを契約か運用手順書に書く 3. ESXiホストと管理サーバーのバージョン・SSH・ロックダウンモードの一覧を、前章のスクリプトで月に一度出して委託先と共有する 4. バックアップから実際に仮想サーバーを1台戻す訓練を年に一度行い、かかった時間を記録する 1と2は書類を整える作業で、予算をかけずに今月中に済ませられる内容です。初動を担う体制の作り方は[CSIRT（シーサート）とは](https://www.issoh.co.jp/column/details/10174/)で、委託先のデータベースを起点に被害が広がった事例は[旭化成ファーマのサイバー攻撃](https://www.issoh.co.jp/tech/details/18166/)で扱っています。[IPAのランサムウェア対策特設ページ](https://www.ipa.go.jp/security/anshin/measures/ransom%5Ftokusetsu.html)には、被害に遭ったときの相談先がまとまっています。 ### 個人情報の漏えいのおそれがあるときの報告と第三者の診断を入れる時期 大阪公立大学は10月5日に個人情報保護委員会へ連絡し、流出の有無については調査中との説明です。不正の目的をもった行為による漏えいのおそれがあれば、件数に関係なく報告の対象となり、速報は発覚から3〜5日以内に出します。類型と期限は[個人情報保護委員会への報告義務](https://www.issoh.co.jp/column/details/17840/)で解説しています。 4項目の見直しを終えても、外から見えている入口の全体と、侵入されたときに仮想化の管理基盤まで届く経路を自組織で説明できない場合は、第三者の目を入れる時期です。[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)では、公開しているVPN機器やWebシステムから学内のサーバーに至る経路を含めて点検できます。 ## よくある質問 大阪公立大学のランサムウェア被害について、学生・受験生と情報システムの担当者から出やすい質問をまとめました。 ### 大阪公立大学のシステム障害は何が原因だったのですか？ 大学は2026年10月5日の記者会見で、ランサムウェアによるサイバー攻撃と判断していると説明しました。10月2日未明に仮想化基盤システムで大規模な障害が起き、仮想サーバー群の停止と一部データの改ざんの形跡が確認されています。侵入経路や攻撃者は公表されておらず、外部の専門事業者の支援で調査が続いています。 ### 授業はいつから再開されますか？ 10月2日の第2報では、10月8日までを休講とし、10月9日以降に対面授業を再開する予定と案内されています。オンライン授業の再開については、復旧の状況を見て判断するとの案内です。最新の案内は、大学の公式サイトが復旧するまでの間、臨時お知らせサイトに掲載されます。 ### 個人情報は流出したのですか？ 2026年10月8日時点の公式発表では、流出の有無は調査中です。大学は個人情報保護委員会へ連絡したうえで、専門事業者の調査結果を踏まえて事実を確かめるとしています。会見を伝えた報道では、攻撃を受けたシステムに少なくとも約13万人分の個人情報が保管されていたとされています。大学を名乗る不審な連絡には、臨時お知らせサイトを自分で開いて確かめる姿勢で臨んでください。 ### 受験生の出願や入学手続はどうなりますか？ Web出願と入学手続のサイトは学外のサーバーで動いているため、登録はできる状態です。大学は10月4日、10月8日または9日が締切の出願を10月22日17時まで、10月6日が締切の入学手続を10月22日12時まで延長しました。募集要項と出願様式は、記事執筆時点では確認できない状態です。 ### 仮想化基盤のバックアップはどう守ればよいですか？ ハイパーバイザーやバックアップサーバーの管理者権限を奪われても消せない場所に、複製を置くことが条件です。たとえばAWS Backup Vault Lockのコンプライアンスモードは、猶予期間を過ぎると誰も保管庫を変更・削除できません。そのうえで、実際に仮想サーバーを戻す訓練を定期的に行い、戻せることと戻る時間を確かめておきます。 ## 関連記事 - [佐賀大学のランサムウェア被害と事務NASの暗号化｜4日で業務再開した初動と戻せるバックアップ](https://www.issoh.co.jp/tech/details/18097/)：同時期の大学の事案（事務NAS） - [旭化成ファーマのサイバー攻撃：Pharma DIGITAL会員51.4万人の漏えいと委託先DBの監視設計](https://www.issoh.co.jp/tech/details/18166/)：委託先を起点にした事案 - [アスクルのランサムウェア攻撃｜流出74万件と追加60万件・行政指導・全面復旧までの経緯](https://www.issoh.co.jp/tech/details/10261/)：基幹システムが長期に止まった事例 - [ニチレイのサイバー攻撃とは？漏えい53,866件確定までの経緯とRansomHouse声明・防御設計を解説](https://www.issoh.co.jp/tech/details/15409/)：流出件数が後から確定した事例 - [ニコニコ動画（KADOKAWA）へのサイバー攻撃とは｜ランサムウェア被害の経緯・犯人・情報漏洩・復旧](https://www.issoh.co.jp/column/details/2807/)：データセンターのサーバー群が止まり復旧に2か月を要した事例 --- 出典: [大阪公立大学のランサムウェア被害と仮想化基盤の停止｜全授業休講に至った経緯とバックアップを守る設定]()（株式会社一創）