日本医科大学のランサムウェア被害における原因と再発防止策について

2026年2月16日 09:03

─ 構造的問題を踏まえた考察と提案 ─

はじめに

2026年2月、日本医科大学武蔵小杉病院において、
約1万人分の患者情報が漏えいするランサムウェア被害が発生しました。

本件については複数の報道が出ていますが、現時点で公開されている情報には限りがあり、すべての技術的背景を正確に把握できる状況にはありません。
そこで本記事では、
現時点で確認できている事実を整理したうえで、
その前提に基づき「構造的な原因の推察」と「再発防止策の提案」を行います。
なお、本記事の目的は以下の通りです。

個人や特定企業を批判・攻撃することではない
責任追及ではなく、構造的な問題の整理と改善策の提示を目的とする
日本の医療機関・自治体・企業に共通する課題を明らかにする

本記事は公開情報に基づく技術的・構造的な考察であり、
特定の個人・団体を誹謗中傷する意図は一切ありません。

また、「侵入されなければランサムウェア被害は起きない」という入口防御の重要性については、別記事で詳しく解説していますので、併せて参照いただくと理解が深まります。
👉 侵入されなければ、ランサムウェア被害は起こらない！
EDRアラートが鳴らない世界への鍵とは？
https://note.com/oki_g/n/n4bea63a4bc52

1. 現時点で確認できている事実（報道ベース）

医療機器保守用の VPN 装置を経由して侵入されたと報道されている
複数の外部業者が院外から VPN で病院ネットワークにアクセスしていた
一部の業者では「非常に甘いパスワード」が設定されていた
MFA（多要素認証）が利用されていた形跡はない
病院側は外部業者の VPN 設定まで指導していなかったとされる

※これらは報道内容に基づくものであり、実際の技術的詳細とは異なる可能性があります。

2. 外部からアクセスを行っていたのは“医療機器メンテナンス業者”である

今回の事件では「医療機器ベンダー」が例として挙げられていますが、
実際に外部から VPN や ZTN を通じて病院ネットワークにアクセスするのは、
医療機器のメンテナンスや保守を担当する外部業者です。

ナースコール
放射線機器
検査機器
生体情報モニタ
手術室設備
建物管理システム（空調・電源監視）

これらの医療機器は24時間365日稼働しており、停止すると診療や手術ができなくなるだけでなく生命維持が難しくなる場合もあり、トラブル時に現地対応だけでは充分とはいえません。

そのため、遠隔からの保守アクセスは「例外的な運用」ではなく、医療機関にとっては事実上の“必須”インフラであるという構造になっています。

3. 本当の問題は“ネットワーク管理の構造”にある

医療機器メンテナンス業者が外部アクセスを行うとしても、
その入口となる VPN 装置やネットワーク設定を管理しているのは、
病院が委託しているネットワーク管理業者であり医療機器のメンテナンスや保守を担当する外部業者とは通常異なります。

ネットワーク管理業者は以下の権限を持っています。

VPN 装置の設定
ルーティングの開放
外部ベンダー用アカウントの作成
ログの管理

つまり、ネットワークの“鍵束”を持っているのは委託元ではなくネットワーク管理業者です。

そして委託元（病院・自治体・企業）は、ネットワーク管理業者が設定した内容を技術的に評価することができず、実質的に「ブラックボックス」として扱わざるを得ません。その結果、

・パスワード強度が適切か
・MFAが設定されているか
・外部ベンダーのアクセス権限が最小化されているか
・ログが適切に取得・保管されているか

といった基本的な安全性すら確認できない状態に陥ります。
つまり、
委託元がネットワークの安全性を直接管理できない構造である以上、
実際に管理を担うネットワーク管理業者に対し、
「安全性を担保できる運用」を義務付ける仕組みを構築することが、
委託元の責任となります。

4. 「甘いパスワードが原因」と判断する構造こそが根本的な問題である

今回の事件で最も深刻なのは、「甘いパスワードが原因だった」という表層的な理解ではありません。
そのような理解を“標準”として許してしまう、日本の医療機関・自治体・企業に共通する構造そのものが根本的な問題です。
日本の現場で一般化している“標準運用”には、以下のような構造的欠陥が存在します。
【技術的な欠陥】

弱いパスワード
MFAなし
常時接続のVPN
ログ監査なし

【組織的な欠陥】

委託元（病院・自治体・企業）は設定内容を理解・監査できない
ネットワーク管理業者は“運用担当”であり、セキュリティ責任者ではない

このような構造では、現在のサイバー攻撃手法に対して
VPN経由の侵入を防ぐことは事実上不可能です。
にもかかわらず、事件後の議論が
「甘いパスワードが原因だった」
「ではパスワードを強化しよう」
という“対処療法”で終わってしまうと、同様の被害は今後も繰り返されます。

半田病院でも同じ構造的問題が露呈していた

過去の半田病院のランサムウェア被害でも、VPN経由での侵入が指摘されていました。
半田病院では、「電子カルテは外部とつながっていない」
と委託業者から説明されていたにもかかわらず、
実際にはVPN経由で電子カルテに到達可能な経路が存在していたことが後に明らかになりました。
これは、病院側がネットワークの全体像を把握できない委託構造の中で、
“外とつながっていない”という説明を形式的に信じたためです。
しかし実態としては、VPNを通じて外部から内部ネットワークへ到達できる経路が残されていました。

つまり、
半田病院の時点で構造的問題は可視化されていたにもかかわらず、
抜本的な対策が取られなかったため、
今回の事件は必然的に再発したと言えます。

「脆弱性診断をすれば防げた」は正しいが、現実的ではない

病院側は別の外部業者に脆弱性診断を依頼する権限を持っていましたが、
実際にはそのような監査はほとんど実施されていませんし、今後も実施される可能性は高くありません。

理由は明確です。

病院側にネットワークを理解する技術力がない
脆弱性診断を継続的に実施する予算がない
委託構造の中で「何を診断すべきか」すら判断できない

つまり、
「脆弱性診断をすれば防げた」という指摘は正しいが、
そもそも病院側にはそれを実施できる能力も経済力もない。

だからこそ、
現実的に実施可能な“構造的な再発防止策”を考える必要があります。

5. 再発防止策は「IDaaSを使用したFIDOセキュリティキー必須化」を義務付けるしかない

第4章で述べた通り、今回の事件の本質は「甘いパスワード」ではなく、
外部ベンダーが院内ネットワークに入る“入口”を病院側が統制できない構造にあります。

この構造を変えない限り

VPNのパスワードを強化しても
設定を見直しても

同じ被害は必ず繰り返されます。

VPNログインにFIDOセキュリティキーを必須化すれば入口突破はほぼ不可能になる

別記事でも述べた通り、
VPNログインにFIDOセキュリティキーを必須化すれば、
外部からVPN経由での侵入される可能性はほぼゼロになります。
ここで重要なのは、

なぜ従来のMFAではダメなのか
なぜ同期パスキーでも不十分なのか
IDaaSとFIDOセキュリティキーは何を分担しているのか

という点です。

従来のMFAがダメな理由：リアルタイムフィッシングで突破される

ワンタイムパスワード（OTP）、SMS、認証アプリなどの従来型MFAは、
リアルタイムフィッシングで突破されます。
攻撃者は偽ログイン画面を用意し、
ユーザーが入力したパスワードとワンタイムコードを
そのままリアルタイムで正規サイトに転送することでログインできます。

つまり、
従来のMFAは「パスワードの延長」でしかなく、フィッシング耐性が不完全です。

同期パスキーがダメな理由：秘密鍵がクラウド経由で同期される

同期パスキーは便利ですが、
秘密鍵がクラウド経由で同期されるという構造的弱点があります。
クラウド同期アカウントをリアルタイムフィッシングで乗っ取られれば、
秘密鍵が攻撃者の端末にクラウド経由で自動的にダウンロードされます。

つまり、
直接攻撃のフィッシング耐性はあっても広義のフィッシング耐性は完全ではありません。

FIDOセキュリティキーだけが唯一の“完全なフィッシング耐性”を持つ

FIDOセキュリティキーは、

秘密鍵がデバイス外に出ない
フィッシング耐性が完全
中間者攻撃が成立しない
認証器自体が物理的に存在する必要がある

という特性を持ち、
現時点で唯一、リアルタイムフィッシングを完全に防げる認証方式です。
この点は、CISAが“ハードウェアFIDOキー”のみを最優先で推奨していることからも明らかです。

ここで誤解してはいけないのは、
FIDOセキュリティキーはパスワードを排除するための技術ではないという点です。

重要なのは、
パスワードが弱くても、外部から侵入されない構造を作ること。
FIDOセキュリティキーを入口のログインで必須化すれば、
パスワードの強弱に関係なく、外部からの侵入は不可能になります。

IDaaSとFIDOの関係：どちらか片方では不十分で、両方が必要

● FIDOセキュリティキーの役割（技術的防御）
FIDOセキュリティキーを必須化すれば、
パスワードが弱くても、外部からの侵入が技術的に不可能になる。
つまり、
弱いパスワードを“技術的に無害化”するのがFIDO。

● IDaaSの役割（運用的統制）
しかし、FIDOセキュリティキーを導入しただけでは、

外部ベンダーが勝手にパスワードログインを残す
外部ベンダーが勝手に自分のFIDOセキュリティキーを追加登録する
ネットワーク管理業者がFIDOセキュリティキー必須化を徹底しない
一部アカウントだけパスワードログインを許可する
監査ができない

という“運用の穴”が残ります。

IDaaSは、

ユーザー自身による認証器追加を禁止できる
管理者が許可したFIDOセキュリティキーだけを登録可能にできる
FIDO以外の認証方式を無効化できる
外部ベンダーのアカウントを一元管理できる
ログ監査を強制できる

という“統制の仕組み”を提供します。

つまり、
FIDOが弱いパスワードを技術的に無害化し、
IDaaSがその運用を構造として強制する。
この組み合わせによって、
弱いパスワードが残っていても、
外部からの侵入は構造的に不可能になります。

病院は自分で設定できない。だからこそ業者に対して「委託契約による義務付け」が必要になる

病院はネットワークの専門家ではありません。
VPN設定、IDaaS連携、FIDOセキュリティキー必須化といった技術的作業を
自分たちで構築・監査することはできません。
実際に手を動かすのは：

院内ネットワークを運用するネットワーク管理業者
必要に応じてIDaaS事業者
外部ベンダー（医療機器メーカー）

という“外部の専門業者”です。

だから病院が担うべき責任は、
「外部アクセスはIDaaS経由でFIDOセキュリティキーを必須とする」
という安全基準を委託契約で義務付けること。

病院がやるべきことは、

自分で設定することではない
自分で監査することでもない
自分で技術的判断をすることでもない

病院がやるべきことはただ一つ。
“守らせる仕組み”を作ること。

これが、委託構造の中で病院が唯一実行可能な再発防止策です。

IDaaSによるFIDOセキュリティキー必須化のために内部システムを置き換える必要はない

電子カルテやナースコールなどの内部システムは、
現時点ではIDaaSに対応していません。
しかし、それでも問題ありません。

必要なのは、

外部ベンダーが院内ネットワークに入る入口
ネットワーク管理業者が保守に入る入口

これらの“入口”だけをIDaaSに統一し、FIDOセキュリティキーを必須化すること。
内部システムが古くても、
入口さえ統制できれば、
今回のような侵入は防げます。

つまり、
病院が“できること”と“やるべきこと”を一致させた唯一の現実的な解決策が
「IDaaSによるFIDOセキュリティキー必須化を委託契約で義務付け」することである。

6. 結論：今回の事件は“起こるべくして起きた”構造的な必然である

日本医科大学のランサムウェア被害は、
単なる「甘いパスワード」や「設定ミス」が原因ではありません。

外部ベンダーがVPNで院内ネットワークに入る構造
委託元が設定を理解・監査できない構造
ネットワーク管理業者がセキュリティ責任者ではない構造
医療機器ベンダーが独自VPN・独自アカウントを持つ構造
病院が入口を統制できない構造

これらが複合的に積み重なった結果として、
今回の事件は“必然的に”発生したと言えます。
そして、この構造は半田病院の事件から何も変わっていません。
必要なのは「運用改善」ではなく「構造改革」である

パスワード強化
VPN設定の見直し
一時的な監査

こうした“運用改善”では、
構造的な問題は何一つ解決しません。

必要なのは、
外部アクセスの入口をIDaaSによるFIDOセキュリティキー必須化で統一し、
病院がそれを外部の業者に委託契約で義務付けるという構造改革。
これだけが、委託構造の中で病院が実行可能で、
かつ再発防止に直結する唯一の方法です。

FIDOセキュリティキーは、
現時点で唯一リアルタイムフィッシングを完全に防げる認証方式です。
入口をIDaaS＋FIDOセキュリティキーで統制すれば、
VPN経由の侵入はほぼ不可能になります。

つまり、
構造を変えれば、同じ被害は再発しない。

おわりに

本記事で述べた内容は、
特定の個人や企業を批判するものではなく、
日本の医療機関・自治体・企業に共通する構造的問題を明らかにし、
現実的に実行可能な再発防止策を提示することを目的としています。
今回の事件を「不運な事故」として片付けるのではなく、
構造的な問題として捉え、構造的な解決策を実行すること。
それこそが、次の被害を防ぐ唯一の道です。

そして、IDaaSによるFIDOセキュリティキー必須化は、
医療機関だけでなく、あらゆる組織にとって
ランサムウェア対策の“入口防御”として最も効果的な方法です。

ただし、FIDOセキュリティキーを外部からアクセスする全員に配布するには、従来の高価なUSB型のセキュリティキーでは普及が進みません。
そのため私は、価格を数分の1に抑えられるカード型FIDOセキュリティキーを用意しています。これは、構造的な解決策である
「FIDOセキュリティキー全員配布 × IDaaSで必須化」
を現実に実行可能な形にするための手段です。

構造を変えれば、同じ被害は二度と起きない。
そのための現実的な一歩を、今こそ踏み出すべき時です。