公立大学で、ランサムウェアにより学内のサーバー約500台が停止した

何が起きたか

この事故で流出した、または流出したおそれがある情報は、在学生・卒業生など少なくとも13万人分の氏名、住所、メールアドレスなどが基盤上に保存されていたと報じられている。流出は確認されておらず、件数は公表されていないです。その後の対応と影響は、10月2日から8日まで全授業を休講し、10月9日に対面授業を再開した。出願・入学手続の期限を延ばし、全学で認証パスワードの強制変更を行った。メールは10月13日から再開したが、基盤システム全体の復旧時期は未定としているです。

原因になったのは「学内システムの仮想化基盤への侵入とランサムウェア」です。公表された内容では、生成AIは事故に関わっていません。

なぜ起きたか

仮想化基盤に侵入されたと報じられているが、侵入経路や攻撃者は公表されていない。詳しい経緯は公表されていない。

原因の種類は「ランサムウェア」です。データを暗号化して身代金を求める攻撃で、業務が止まった事故を指します。このサイトに掲載している事故のうち、同じ種類の原因で起きた事故は19件あります。

事故が起きてから公表されるまで

1. 10月2日未明に情報基盤システムで障害が起き、大学が第1報を出した
2. 10月5日の記者会見でランサムウェアによる攻撃と判断したと説明した
3. 10月8日の第4報で10月9日からの対面授業再開を知らせた
4. 10月10日以降に全学の認証パスワードを切り替え、10月13日にメールを再開した

どうすれば防げたか

上の流れでは、最初から公表まで、途中で異常に気づいて止める仕組みが働いていません。

止められた可能性がある所（当社の見立て）

仮想化基盤の管理画面を学内の限られた端末からしか操作できないようにし、バックアップを基盤から切り離した場所に置いておけば、停止の範囲と復旧の時間を小さくできた可能性がある。

この見立ては、公表された原因から当社が考えたものです。当事者の調査の結果とは異なる場合があります。

自社で確認する3つの手順

上から順に、短い時間で確認できるものを並べています。

1. 仮想化基盤やバックアップサーバーの管理画面に、どの端末・どのアカウントから入れるかを一覧にする
2. バックアップの少なくとも1つが、本番と同じ認証情報では消せない場所にあるかを確かめる
3. 全サーバーが止まった想定で、授業・業務を何日で再開できるか手順を書き出す

自社に同じ原因があるか

当てはまるものを選んでください。1つでも当てはまれば、この事故と同じ原因が自社にもある可能性があります。

出典と更新の履歴

• 本学情報基盤システムにおける障害の発生について【第4報】対面授業再開のお知らせ2026.10.08
• 大阪公立大学ランサムウェア被害の続報（セキュリティ対策Lab）2026.10.05
• 大阪公立大が対面授業再開 ランサム攻撃で障害続く（熊本日日新聞・共同通信）2026.10.09