医療機関のサイバー被害は、報道されるたびに「他人事ではない」と語られます。しかし、事例を個別の事件として読むと、学びは「大変そうだ」という感想で止まりがちです。施設名や時期ではなく、構造として読むと違う景色が見えます。
公表されている被害事例を並べると、規模も地域も異なる施設に、驚くほど同じ失敗の型が現れます。守りが薄かったから被害が大きくなったのではなく、ある種の構造を持っていた施設が、同じところで同じように詰まっているのです。逆に言えば、その構造を自院が持っているかどうかは、事故が起きる前に点検できます。
本記事は、公表事例に共通する構造を7つのパターンとして整理し、それぞれに対する備えを示すものです。特定の医療機関を名指しすることはしません。 また、攻撃側の手順には踏み込まず、防御側の観点に限ります。
免責：本記事は一般的な情報提供です。個別の事案の詳細や原因については、各機関が公表する報告書および公的機関の注意喚起をご確認ください。本記事は特定の事案の分析ではありません。
パターン1：境界機器の既知脆弱性が入口になる
最も繰り返し現れる構造です。VPN装置、リモート保守用の機器、外部公開されたサーバ。修正プログラムが公開されていたにもかかわらず適用されていなかった、あるいはサポートが終了した機器が稼働し続けていた、という状態です。
なぜ放置されるのかには理由があります。境界機器は止めると診療に影響するため、更新の窓が取りにくい。保守事業者に任せており、自院で状態を把握していない。設置した時期が古く、資産台帳に載っていない。技術の問題ではなく管理の問題です。
| 備え | 具体的に |
|---|---|
| 資産台帳に境界機器を載せる | 機種、版数、保守契約、サポート期限、管理者 |
| 更新の窓を先に決める | 年間の計画に組み込む。緊急時の適用手順も別に定める |
| サポート期限を管理する | 終了の1年前に更改の検討を開始する |
| 外部からの到達点を棚卸しする | 外部公開されているものを、実際に外から確認する |
詳しくは VPN機器の脆弱性対策 と ネットワーク分離と資産管理 をご覧ください。
パターン2：バックアップが同時に暗号化される
被害が長期化した事例に共通するのが、バックアップが本番と同じネットワーク上にあり、同時に暗号化されたという構造です。バックアップは取得されていたのです。取得されていたにもかかわらず、使えなかった。
派生形もあります。バックアップサーバが本番と同じ管理者アカウントで運用されていた。NASが常時接続されていた。世代管理がなく、汚染後のデータで上書きされていた。「取得している」と「復旧できる」の間には距離があります。
2026年度診療報酬改定で新設された電子的診療情報連携体制整備加算の加算1が、**複数方式によるバックアップ（一部はオフライン保管）**を要件としたのは、この構造への対処です。
| 加算1のバックアップ要件を満たすとされる方式 | 要点 |
|---|---|
| 外部媒体方式 | RDX等の別媒体で保管し、世代管理も実施する |
| 自動転送方式 | NAS等へ自動転送し、常時ネットワークから切り離された状態にする |
| クラウド内方式 | クラウドサービス内の論理的に切り離された領域へのバックアップで、速やかな復旧が可能な場合 |
世代管理については、日次でバックアップする場合に少なくとも3世代を確保するという整理が示されています。構成の設計は 医療機関のバックアップ設計｜3-2-1ルール で詳しく扱っています。
パターン3：復旧手順が文書化されていない
バックアップが無事でも、そこから戻す手順が誰の頭の中にもないという事態が起きます。取得は自動化されている。しかし復元は一度も試したことがない。担当者は退職しているか、当日たまたま連絡がつかない。
この構造は平時には見えません。「取得できているか」は監視されていても、「戻せるか」は監視されていないからです。
- 復元試験を年次の計画に入れる。 実際に戻して、所要時間を測る
- 手順を文書化する。 画面の操作まで書く。書いた人以外が読んで実施できるかを確認する
- 順序を決める。 何から戻すか。基幹システムか、部門システムか、認証基盤か
- 依存関係を書く。 認証が戻らないと他が戻らない、といった前後関係を明示する
測定した復元時間は、そのまま サイバー攻撃を想定したBCP のRTOの根拠になります。
パターン4：連絡先が被害システムの中にしかない
対応の初動が遅れた事例で繰り返し現れる構造です。職員の連絡網が院内グループウェアにある。ベンダーの連絡先が共有フォルダのExcelにある。保守契約書がファイルサーバにある。すべて同時に失われます。
さらに、契約書に書かれた代表番号が夜間につながらない、担当者の携帯番号を誰も知らない、といった形で、紙で持っていても到達しないことがあります。
| 持ち方 | 中身 |
|---|---|
| 紙の連絡網（施錠して複数箇所に保管） | 職員、主要ベンダー、保健所、警察、連携医療機関、保険会社 |
| 到達可能性の確認 | 夜間・休日の受付方法。契約上の到達時間。平時に一度かけてみる |
| 院内ネットワークに依存しない連絡手段 | 携帯電話、別系統のメッセージ手段。疎通確認を定期的に |
| 契約書等の写し | 保守契約、SLA、保険証券の要点を紙で |
計画への落とし込みは 医療機関のインシデント対応計画 をご覧ください。
パターン5：ネットワークが平坦で、切り離しの選択肢がない
院内ネットワークが実質的に1つのセグメントで、電子カルテも部門システムも検査機器も事務端末も同じ空間にいる。この構造だと、被害が一部でも「全部止める」以外の選択肢がありません。
加えて、医療機関には更新できない機器が存在します。古いOSで動く検査機器、メーカー保証の関係で手を入れられない装置。これらは更新できない以上、分離して守るしかありません。
- ネットワークを役割で分ける（基幹系・部門系・事務系・機器系・来客用）
- 更新できない機器を専用のセグメントに置き、通信を必要最小限に絞る
- 切り離しの単位と、その影響を図にしておく
- 無線LANの来客用と業務用を分離する
詳細は ネットワーク分離と資産管理、ネットワーク接続医療機器のセキュリティ、無線LANの安全管理 をご覧ください。
パターン6：権限が広く、退職者のアカウントが残る
侵入後に被害が広がるかどうかは、権限の設計で決まります。共通して見られるのは、管理者権限を持つアカウントが多い、保守用アカウントが常時有効、退職者・異動者のアカウントが残っている、職員がID・パスワードを共有している、という状態です。
医療現場でID共有が起きるのは、業務上の必要からです。夜勤帯に交代で使う端末、緊急時にすぐログインしたいという事情。責めるべきは個人ではなく、共有せずに済む運用を用意していない設計です。
| 備え | 具体的に |
|---|---|
| 特権IDの棚卸し | 誰が管理者権限を持つか。四半期ごとに見直す |
| 保守用アカウントの制御 | 常時有効にしない。使用時に有効化し、ログを残す |
| 退職・異動時の削除 | 人事プロセスと連動させる。削除の記録を残す |
| 多要素認証 | 外部からのアクセスと管理者アカウントを優先 |
| ID共有をなくす運用 | 素早くログインできる仕組みを用意して代替する |
アクセス権限設計と特権ID管理、多要素認証の導入、リモートメンテナンスの安全管理 で個別に扱っています。
パターン7：判断する人が決まっていない
最後は技術ではなく組織の構造です。誰が「止める」と決めるのかが決まっていない。 情報システム担当は権限がないと考え、事務長は技術判断ができず、院長は状況が分からない。その間、被害は広がります。
関連する構造として、次のものも繰り返し現れます。
- 医療情報システムの安全管理責任者が名目上の配置に留まり、実質的な権限がない
- 委託先との責任分界が曖昧で、「相手がやっていると思っていた」領域が生じる
- インシデントの定義がなく、現場が「これは報告すべきか」を判断できない
- 経営層がセキュリティを情シスの課題と捉え、投資判断が下りない
これらは事故の当日には直せません。平時に決めておく以外の解決策がない種類の問題です。体制の作り方は 医療機関のセキュリティ体制の作り方、責任者の位置づけは 医療情報安全管理責任者の役割と選任、委託先との切り分けは 責任分界点の決め方 をご覧ください。
自院の構造を点検する
7つのパターンを、点検可能な問いに変換します。答えられない項目があれば、そこが自院の構造的な弱点です。
| # | 問い | 答えられるか |
|---|---|---|
| 1 | 外部に接している機器を全部挙げられるか。最後に更新したのはいつか | |
| 2 | バックアップのうち、ネットワークから切り離されているものはどれか | |
| 3 | 復元を最後に試したのはいつか。所要時間は何時間だったか | |
| 4 | 主要ベンダーの夜間連絡先を、システムを使わずに調べられるか | |
| 5 | 電子カルテだけを切り離すことはできるか。できないなら何が一緒に止まるか | |
| 6 | 管理者権限を持つアカウントは何個あるか。退職者のものは残っていないか | |
| 7 | 今夜、システムを止める判断は誰がするか。その人が不在なら誰か |
この7問は、厚生労働省が2025年5月14日に公表した「医療機関等におけるサイバーセキュリティ対策チェックリスト」の観点とも重なります。チェックリストの使い方は 厚労省のチェックリストをどう使うか をご覧ください。
まとめ
公表事例の構造から学ぶべき点は次のとおりです。
- 入口の多くは境界機器の既知脆弱性。技術の問題ではなく資産管理と更新の窓の問題
- 被害が長期化する最大の要因はバックアップが同時に暗号化される構造。加算1が複数方式・一部オフラインを求める理由がここにある
- 取得できていることと戻せることは別。 復元試験の実測値がRTOの根拠になる
- 連絡先を被害システムの外に置く。 紙で持つだけでなく、夜間に到達するかを平時に確かめる
- 平坦なネットワークは「全部止める」以外の選択肢を奪う。 更新できない機器は分離して守る
- 被害の広がりは権限設計で決まる。特権IDの棚卸しと退職者アカウントの削除を人事と連動させる
- 最後は判断者が決まっているか。平時に決めておく以外に解決策がない
自院の構造を点検する作業は、外部の目が入ると進みやすい領域でもあります。ポテックは医療情報システムの設計・運用の立場から、構成と体制の整理についてご相談を受けています。お問い合わせ からご連絡ください。委託先事業者側の管理体制を評価する枠組みは ISMS（ISO/IEC 27001）とは が参考になります。
参考・出典
※本記事は公表されている事例に共通する構造を一般化して整理したものであり、特定の事案の分析ではありません。個別の事案については各機関の公表資料をご確認ください。