学校のITシステムを強靭化するには

教育機関のITインフラストラクチャには、大勢の学生や教職員の個人情報に加え、学術研究に関する情報や論文など、社会的にも重要なデータが含まれるわりには、同規模の企業に比べ、システムのセキュリティ管理が手薄なことがままあります。大企業ほどには、システム管理に予算をかけられなかったり、ITの優先順位が高くなかったりするためかと思われます。

そのため、日本の大学がサイバー攻撃の標的にされる事例が近年、急増しています。直近では、10月2日に大阪公立大学で約500台のサーバー類が一斉に停止し、一週間の休講を余儀なくされました。報道によると、ランサムウェアの被害に遭い、約13万人の個人情報が流出したうえに、バックアップも含めた広範囲のデータが暗号化され、まだ復旧のめどが立っていないとのことです。

これは氷山の一角で、今年だけ見ても、2月に東海大学がランサムウェア被害、3月に東京大学、4月に千葉大学、5月に九州大学が不正アクセス被害、6月に武蔵野大学がランサムウェア被害、7月には富山県立大学、杏林大学の不正アクセスと福岡大学のランサムウェア被害、8月は日本大学、9月は東京科学大学、関西国際大学、佐賀大学ときて、10月の大阪公立大学まで、明らかにサイバー攻撃に狙われているふしがあります。

そこで、本稿では、教育機関のITインフラストラクチャの構成やセキュリティ体制について、海外の例も交え、検証していきたいと思います。

教育機関におけるITインフラストラクチャの構成

教育機関のITインフラストラクチャとは、一般的にサーバー、ストレージ、ネットワーク、IDシステム、クラウドサービスなどで構成され、生徒の個人データはもちろん、採点システムや学習管理システム（LMS）などを運用するものです。

 小中高や大学から専門学校まで、さまざまな規模がありますが、ITスタックの構成は基本的には変わりません。

構成要素	対象領域	典型的なワークロード
ネットワーク	建物ごとのLAN／Wi-Fi、サイト間をつなぐWANまたはSD-WAN	生徒および教職員によるWi-Fi利用、校舎間のリンク、フィルタ／ファイアウォールなど
コンピューティングと仮想化	Hyper-V、VMware vSphere、Proxmox／KVM ホストによるコアアプリケーションの実行	学生情報システム（SIS）／管理情報システム（MIS）、学習管理システム（Canvas、Google Classroomなど）、メール、印刷、ファイル共有
ストレージ	アプリケーションとユーザーのデータを格納するプライマリーストレージ	学生に関する記録、採点、評価、研究データ、メディアライブラリ
クラウド、SaaSプラットフォーム	ベンダーホストの各種サービス	Google Workspace、Microsoft 365、クラウドでホストされるLMS、SIS-as-a-service
ID／アクセス制御	認証、ディレクトリ サービス	シングルサインオン（SSO）、Active Directory／Entra ID、生徒や保護者のアカウントなど
エンドポイント管理	ユーザーデバイスのプロビジョニング、構成、制御	Chromebook、iPad、教職員のノートパソコン、BYOD（機器持ち込み）ポリシー
校舎設備、物理システム	校舎の運営のためのネットワーク システム	防犯カメラ、出入り口の管理、受付、空調など
モニタリング、セキュリティ	インフラストラクチャの可視化、セキュリティ管理、脅威検出	コンテンツフィルタ、侵入者検知、バックアップ検証

たとえば、米国の小学校レベルでは、2台程度のサーバーでローカルサービスを管理し、Google WorkspaceやMicrosoft 365に依存しているケースが一般的です。大学レベルになると、同様のサービスをデータセンター、学部ごとのサーバー室、キャンパス ネットワーク、複数のパブリッククラウド環境に拡大して、運用しているケースが一般的です。このような規模の違いに応じて、1人のシステム管理者がIT環境全般を担当しているケースから、個別のチームがネットワーキング、ストレージ、ID管理、セキュリティ管理、コンピューティングを担当しているケースまで、多種多様な管理モデルがあります。

幼稚園から大学までの多様なユースケース

教育機関のIT環境は多種多様です。幼児向けの教室では、数えるほどのアプリケーションしか運用していないかもしれませんが、大学レベルになると、数千人のユーザーと専門分野に特化されたリサーチシステム、それにともなう高性能コンピューティングクラスタ（HPC）、ゲノミクス パイプライン、アーカイブ ストレージなどを、通常の管理スタックとともに運用している場合があります。

規模に応じたIT構成と障害発生時に想定される影響の度合いを表にすると、以下のようになります。

教育機関の種別	IT構成の特徴	障害の発生対象／影響の範囲	システム設計の最優先事項
幼稚園、保育園など	最小限またはアウトソーシング	学生名簿、設備、保護者との連絡など	シンプルさ、管理のしやすさ
小中学校	小規模ITチーム、混成ハードウェア	学習管理システム（LMS）、採点／成績表、試験問題、コンテンツフィルタなど	信頼性の確保（IT専門スタッフほぼゼロでも確実に管理できる仕組み）
高等学校	サイト全体のIT中央管理	上記のすべて、複数の建屋（校舎）にわたる管理	標準化、中央管理の効率化
専門学校、短大など	研究室、専門分野に特化されたソフトウェア	カリキュラム、テスト環境、仮想デスクトップ（VDI）など	多様なワークロードに対応する柔軟性
大学	データセンター + 学部ごとのシステム	履修登録や研究を管理するコンピューティング、キャンパス全体を網羅するサービス	スケーラビリティ、研究や管理業務の継続性（アップタイム）
通信教育、遠隔学習	クラウド／ハイブリッド プラットフォーム	オンラインサービス	年中無休24時間の可用性、単一障害点（SPOF）の排除

上記のように教育機関の種別ごとに、必要となる障害対策やセキュリティ体制はかなり異なってきます。たとえば、小規模の学校には2ノード クラスタが適切ですが、シンプルなSaaSベースの環境に依存している学校にそこまでの障害対策は必要ないかもしれません。逆に、独自のSLA（サービスレベル アグリーメント）を満たさなければならない研究施設を備えた大学には不十分です。適切なセキュリティ体制を構築するには、まず、普段どのようなワークロードを実行しているのか、どのようなリカバリ要件があるのかを把握するところから始めなければなりません。

予測可能なピーク ワークロード

教育機関のIT環境には、他の業界に比べて一つ有利な点があります。ワークロードがもっとも高負荷になる時間帯や時期が予測しやすいことです。毎朝の出欠確認や、試験用のアプリケーションや採点システムが一斉に開かれるタイミングが決まっていたり、期末試験の時期や、生徒が課題に一斉にアクセスし出す時期も予測がつきます。

容量プランニングは、平均にではなく、ピーク時のワークロードに合わせるのが得策です。平時は何の問題もなく機能しているシステムが、数千人の生徒が一斉にアクセスしてきたときにも通常どおり機能するとは限りません。ピーク時にも対応できる体制を整える必要がありますが、可能な限り、独自のスケジュールに合わせたスケーリングを実践するのが効率的です。

システム障害／ダウンタイムの主な原因

教育機関にもっとも深刻な障害をもたらす主要因としては、相変わらず、ランサムウェアが君臨し続けています。英国のサイバーセキュリティ調査会社Comapritechが今年7月にまとめたレポートによると、2026年上半期の教育機関におけるランサムウェア被害は世界中で104件報告されており、2025年下半期より13％低下しているものの、高等教育機関の被害は8％増えています。また、身代金要求額の平均値も42万ドル（約6,650万円）超で、こちらは2025年下半期に比べ50％増です。

ランサムウェア被害ばかりが注目されがちですが、日常的なインフラストラクチャの不具合も教育機関に十分大きなダメージを与えるリスクがあります。大学などでは、入学登録時や期末試験時など、ピーク時と平時の違いが極端で、その分、ピーク時に障害が発生した場合の損害が甚大になります。小規模の学校では（特に日本では）、IT環境を一人のシステム管理者に依存しているケースも多々あり、担当者不在時の障害で影響が大きくなることも珍しくありません。

多くの教育機関に共通する課題としては、冗長性の欠如と、リカバリ手順の標準化／共有不足が挙げられます。一人のシステム管理担当者だけがサービスの復旧方法を熟知し、ハードウェアのスペアが用意してあっても、たまたまその人がいなければ何の意味もありません。

クラウドアクセスとWi-Fiへの依存

ここまで、校舎やキャンパス内のインフラストラクチャを中心に論じてきましたが、実際には、教育機関のITは外部に拡大しています。Google WorkspaceやMicrosoft 365から、独自のLMSまでSaaSに依存している大学も増えており、インフラストラクチャはキャンパス内の閉ざされた空間を脱却していますが、接続はローカル環境に依存せざるを得ません。校内のインターネット接続が途絶えたら、クラウドホストの授業やIDサービスはすべて利用できなくなってしまいます。

このため、ネットワークの接続性も、システムの可用性プランニングに含めなければなりません。それには、デュアルWAN、セルラーフェイルオーバーなどで主要サービスがダウンした場合のバックアッププランも含まれます。複数の建屋で同じクラウドスタックを使用している学校法人などは、個々にセカンダリサーバーを用意するよりも、接続の冗長性を確保するほうが理にかなっています。

教育機関のIT環境を検証する際は、サーバールームだけにとらわれず、全体に視野を広げなければなりません。レジリエンスは、ユーザーのデバイスからアプリケーションにつながる経路全般と、そこで使用されるデータを網羅して、はじめて確立されます。学生が認証エラーでLMSにアクセスできなかったり、課題の提出に異常に長い時間がかかったりした場合、高可用性サーバーも問題解決の役には立ちません。

バックアップだけでは足りない理由

バックアップと高可用性は、それぞれ異なる課題を解決するためのセキュリティ対策です。教育機関のITプランでは、しばしばそれが混同されがちです。

バックアップはサーバーがダウンしたり、ランサムウェア攻撃を受けたり、ファイルの誤削除や破損が生じたりしたときに、データを復旧するためのソリューションです。そこでは時間軸が重要な評価基準となります。リカバリプロセスにおいて、データのリストアやサーバーの再構築または再プロビジョニング、アプリケーションの再起動とそれぞれの依存関係の再接続が必要になり、環境やデータセットの規模によっては、数時間から数日かかる場合があります。

一方、高可用性は障害に対応するメカニズムが異なります。サーバーがダウンしたら、すでに同期化されたデータを持つ他のノードが仮想マシンをオンラインに起動します。この自動フェイルオーバーによって、復旧は（環境設定や諸条件に拠りますが）数分で完了する仕組みになっています。

ただし、同期化されたレプリケーションには制限がともないます。他のノードでコミットされた書き込みをそのままコピーするので、不良データや誤削除、最悪の場合にはランサムウェアに暗号化されたデータもコピーしてしまう可能性があります。

このため、いくら高可用性が確立されていても、隔離されたイミュータブル／オフラインのバックアップは不可欠で、そのバックアップを使用したリカバリ手順もテストしておかなければなりません。

教育機関はダウンタイムをゼロにするために完全な可用性を確保しなければならいと言いたいところですが、常に完璧を目指すのは現実的ではありません。実際には、個々のサービスを分類して、それぞれの許容範囲を評価し、必要な保護レベルを選択する必要があります。たとえば、下表のように、個々のサービスの復旧要件に応じた保護レベルを定義することができます。

サービス	優先度	リカバリ目標	保護レベル
出入口のアクセス／警備システム	重要	数分	高可用性クラスタ＋接続の冗長性
SIS、出欠確認システム	高	1時間以内	高可用性または検証済みバックアップでのフェイルオーバー
アーカイブされた学習課程	低	数時間または翌日まで	検証／テスト済みバックアップ（高可用性は不要）

上の表はあくまでサンプルで、個々の教育機関によって、さまざまな異なる要件があるはずです。たとえば、研究費の補助を受けている大学が研究データのストレージの優先度を「高」する一方、小規模の学校では教材のストレージを「低」にするかもしれません。リカバリ目標を決める際は、そのサービスが何をサポートしているのか、ダウンしたら学生や教職員にどういう影響があるのかを見極める必要があります。重要なワークロードは高可用性と接続の冗長性を必要とします。一方、緊急のリカバリを必要としないワークロードには、より確実な検証済みのバックアップを使用すべきです。

2ノードクラスタの高可用性

エンタープライズレベルの費用をかけずに高可用性を確保するためのもっとも一般的な方法は、2ノードクラスタを活用することです。2ノードクラスタとは、2つのサーバー間でリアルタイムのレプリケーションを実行し、1つに障害が発生したら、もう1つがすぐに同じデータで稼働できるようにする仕組みです。

2ノードクラスタの実装方法は、両ノードが連携できなくなった場合にどちらがI/Oを受け持つか（クォーラム）を決定するメカニズムによって、次の2通りに分けられます。1つ目の方法は、小型のVMかクラウドインスタンスを軽量のウィットネス（仲裁役）として設置し、決選投票を仕切らせるやり方です。2つのノードのうち、このウィットネスと通信を維持していたほうがI/Oを引き継ぎます。この方法によって、両ノードが同じデータを書き込んでしまったり、スプリットブレインシナリオ（両方が同時に自己を正規ノードだと認識してしまう状況）を回避できます。

2つ目の方法は、ウィットネスを置かずに、両ノードが専用リンクを通じて相互に直接監視し合うハートビート方式です。この方法は、ウィットネス役として余計なコンポーネントを追加しなくて済む代わりに、相互リンクの安定した接続性に完全依存するので、どちらを選択するかは個々の環境や要件によります。どちらの方法も、StarWind VSANを使用して実装することができます（詳細はクライムにお問い合わせください）。

2ノードクラスタの基盤となるメカニズムは、複数ベンダーを組み合わせた構成が考えられます。たとえば、Microsoftの記憶スペースダイレクト（Storage Spaces Direct）を利用することも可能ですが、Datacenterエディションが必須になります。一方、ProxmoxとCephの組み合わせなら、オープンソースなので無料で利用できますが、Cephは通常、3つ以上のノードのほうがよく機能します。VMware vSANはvSphere内でこのメカニズムをサポートしますが、Broadcomの2023年以降のライセンス設定でvSphere FoundationとCloud Foundationのティアとバンドルされている点は、学校規模によっては費用対効果を損なうかもしれません。

教育機関のITチームにとって、どのようなプラットフォームを基盤とすべきかは、リカバリ要件に拠るところが大きいです。具体的なソリューションの選択を決定する際は、事前に以下の問いについて慎重に検討すべきです。 

決定要因	質問
リカバリ	必要となるRPO（目標復旧時点）とRTO（目標復旧時間）は？
パフォーマンス	クラスタが許容できるIOPSとレイテンシは？
障害ドメイン	どのレベルの障害まで対応すべきか（ノード、サイト、サーキット、停電など）？
ネットワーク	レプリケーションと再同期化のトラフィックに適合できるか？
オペレーション	既存のチームでプラットフォームを管理できるか？
ハードウェア	既存の設備でサポートできるか（再利用する価値があるか）？
拡張性	3年、5年後の規模、必要な容量はどうなるか？

これらの質問への回答を整理しておくことで、技術的に可用性がサポートされるという理由だけで（既存インフラストラクチャが対応できるかどうかを確認せずに）クラスタを選択してしまうという、よくあるミスを未然に防ぐことができます。互換性のあるHyper-V、VMware、Proxmoxのいずれかをホストとして使用している教育機関は、すぐにでもStarWind VSANを導入して2ノードの高可用性を共有SANストレージなしで実現できます。ただし、既存のハードウェアが実際のワークロードに対応可能かどうかの検証は必要です。複数サイトで運営している学校法人もStarWind HCIアプライアンスで同様のデプロイメントを実現できます。この場合、個々のサイトのハードウェアを一つひとつ検証する必要はありません。

2ノードのデプロイメントを導入する際の検証事項は、どのベンダーを使用していても基本的に変わりありません。両方のサーバーに十分なコンピューティングとローカル ストレージの容量があり、レプリケーションのネットワークに通常の書き込みと再同期をサポートするのに十分な帯域幅があることが最低条件です。ウィットネスを使用する場合は、この2ノードの障害ドメインの外に置かれなければなりません。2ノードのネットワークがダウンした場合に、ウィットネスもダウンしてしまったら意味がありません。

データの保護

教育機関においてシステムの可用性（サービスの継続性）は重要ですが、学生の個人情報や研究データ、教職員のデータ、学校運営上の管理情報や財務レコードの保護も、ハードウェアの冗長性と同じくらいに重要です。

他の一般企業と同様、強固なIDとアクセス制御で認証情報を管理し、適切なネットワークセグメンテーションを施行し、システムの定期的なアップデートを怠らず、特に重大なパッチは直ちに適用する必要があります。たとえば、管理スタッフのアカウントには多要素認証（MFA）が不可欠で、学生用、ゲスト用、さらには校舎システム用のトラフィックを分離させる必要があり、中央システムのパッチとデプロイメントのモニタリングを徹底しなければなりません。サイバー攻撃の対象となり得る露出面を極力減らし、最悪の場合、攻撃を受けてしまっても、影響する範囲を分離させる必要があります。これは、一般企業に比べて少人数のITチームで管理している学校にとっては、特に重要なセキュリティ アプローチです。

重要データを保存時も転送時も暗号化できる仕組みも、一般企業同様、教育機関にも欠かせません。暗号化キーの保存先、誰がアクセスできるのか、サーバーがダウンした場合にどのようにアクセスを確保するのは、必ずドキュメント化しておく必要があります。

ランサムウェア対策として、バックアップの確実かつ頻繁な保存、3‐2‐1ルールの徹底は言うまでもなく、オフラインやイミュータブルのバックアップを確保して必ずテストすることも含め、3-2-1-1-0ルールを取り入れることは、規模を問わず、すべての教育機関が実践すべきベストプラクティスです。