# 委託先と共通のパスワードから侵入されてランサムウェアの被害が広がった事案

給食の委託先の機器から侵入され、病院のサーバーと端末で共通だったパスワードで被害が広がりました。報告書が原因に挙げたのは、共通パスワード、全員への管理者権限、外部接続の役割分担の曖昧さです。

更新日: 2026-09-18

2022 年 10 月 31 日、公立の総合病院が、ランサムウェア(データを暗号化して身代金を要求するウイルス)の攻撃を受けました。電子カルテを含む基幹システムが止まり、病院の調査委員会の報告書と概要版は翌年の 3 月 28 日に公表されました。

## 何が起きたか

侵入の入口は、給食業務を委託していた事業者(給食事業者)のシステムでした。報告書概要は、攻撃の手順を 7 段階で推定しています。

1. 給食事業者の保守用の VPN 機器(外から社内につなぐための機器)の欠陥を使って侵入。公開されていた ID・パスワードで侵入された可能性もある。
2. 給食事業者内の ID・パスワードが弱く、他のシステムの情報やパスワードを盗んで攻撃を広げた。
3. 病院のサーバーの ID・パスワードを盗み、遠隔操作の通信で病院の給食サーバーに侵入。ウイルス対策ソフトを削除。
4. 病院内の他のサーバーの ID・パスワードを盗む。給食サーバーと共通だったため容易だった。
5. 盗んだ ID・パスワードで電子カルテなどの基幹サーバーに侵入。
6. サーバーを経由して端末にもログオンを試みた可能性。
7. 各サーバーでランサムウェアを動かし、身代金を要求。

被害は、電子カルテを含む基幹システムのサーバーの大部分が暗号化されたことです。院内約 2,200 台の端末にも[不正アクセス](/guides/incidents/what-is-unauthorized-access)の痕跡がありました。すべてのサーバーと端末を初期化し、基幹サーバーの再稼働に 43 日、全体の復旧に 73 日を要しています。個人情報の漏えいの可能性は、通信の記録と端末の調査から「極めて低い」とされています。

## 公表された原因

報告書は、原因を「外部接続(リモートメンテナンス)の管理不備」と「内部のセキュリティが脆弱」の 2 つに分けています。後者について概要は、初期設定が適切なら被害は大規模には広がらなかった可能性がある、と書いています。

| 被害を広げた設定 | 報告書が挙げた再発防止策 |
| --- | --- |
| 利用者すべてに管理者権限があり、攻撃者にウイルス対策ソフトを削除された | 利用者は管理者権限のない標準ユーザーにする |
| Windows のパスワードがサーバー・端末で共通で、1 つ盗まれると他のすべてを乗っ取れた | サーバー・端末ごとに個別のパスワードにする |
| ログイン失敗が続いてもアカウントを止める設定がなく、パスワードを数多く試された | 一定回数失敗したらアカウントを止める設定を有効にする |
| 電子カルテのサーバーにウイルス対策ソフトがなかった | 電子カルテのサーバーにも入れる |

外部接続については、報告書の表が 3 点を挙げています。VPN 機器などの外部通信機器の保守で、欠陥の管理の役割分担が曖昧だったこと。遠隔保守を許可する基準が曖昧で、保守を行う側の環境の確認が不十分だったこと。許可した後に、その利用状況を確認していなかったことです。組織面では、契約ごとに責任の境界と役割が明確でない領域があった、としています。電子カルテのベンダーは聞き取りに「パスワードが同じであることは(病院にも)認識してもらっていた」と答えましたが、報告書は、その合意を確認した記録はなかったとしています。

## 同じ給食事業者とつながる他の病院との違い

報告書は、同じ給食事業者と接続していた別の 2 病院と比べています。1 つの病院は給食サーバーに侵入されませんでした。もう 1 つは給食サーバーに侵入されましたが、その先の電子カルテのサーバー群とはパスワードもネットワークの区画も別で、先へは進まれていません。この病院は両方が共通でした。

## 公表された再発防止策

技術面では、上の表の 4 点に加え、外部接続や遠隔保守を許可する基準を定めるとしています。申請時に相手側の環境を確認し、接続後は通信の記録を確認する運用です。契約面では、契約ごとに受注者と役割分担・責任の境界を文書で確認すること、病院共通の方針にもとづく仕様で調達することを挙げています。復旧時の方針には、ID の共用と共通パスワードの禁止、16 桁以上のパスフレーズ(文のように長いパスワード)の推奨も含まれます。

## 同じ型の事故で一般に問われる管理

IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版は、第 2 部 実践編で、パスワードの設定と管理のルールを定めて周知するよう勧めています。内容は 3 つです。複雑さを保つこと、社内のシステムや機器で使い回しを防ぐルールを定めること、保管方法(紙・ファイル・パスワード管理アプリなど)の違いを知って自社のルールを定めることです。

厚生労働省の「医療情報システムの安全管理に関するガイドライン」第 7.0 版(システム運用編)は、「認証・認可に関する安全管理措置」の章に遵守事項(守るべき決まり)を置いています。その 1 つが、異なる医療情報システムでパスワードを使い回さないことです。同じ章は、サーバー群へのログインを踏み台の端末(サーバーに入る前に必ず通す中継用の端末)に限る構成も認めています。その条件の 1 つが、サーバー群と踏み台端末で共通のパスワードを使わないことです。どちらも、1 つのパスワードが盗まれたときに被害が広がる範囲を、分けることで狭める考え方です。

## 自分の現場を点検する問い

1. サーバー、端末、業務で使う Web サービスのうち、同じパスワードを使っている組み合わせはいくつあるか。
2. 委託先や保守業者が自社のシステムにつなぐ経路を一覧にしているか。その接続を止める権限と手順は誰にあるか。
3. 委託先が使うアカウントのパスワードは誰が知っており、担当者が代わったときに変えているか。
4. ログインの失敗が続いたときにアカウントを止める設定が、サーバーと業務サービスの両方で有効か。
5. 保守や欠陥の修正を誰が担うか、契約書や文書で確認できるか。


## よくある質問

**委託先の機器から侵入されても委託元の問題になりますか**

報告書は病院側の問題として、契約ごとに保守や欠陥の管理の役割分担が明確でなかったこと、外部接続の許可後に利用状況を確認していなかったことを挙げています。責任の有無は契約と法令の確認が要ります。

**サーバーごとにパスワードを分けると管理が大変ではありませんか**

報告書は復旧方針で、サーバーと端末の管理者パスワードをすべて個別にし、16 桁以上のパスフレーズを推奨しています。厚労省のガイドラインも定期変更は不要としており、分けることを優先します。

**この事案で個人情報は漏えいしましたか**

報告書概要は、通信の記録と端末の調査から、個人情報漏えいの可能性は極めて低いとしています。被害の中心は、電子カルテを含むシステムの停止による診療の制限でした。

## 参考資料

- [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf)
- [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 システム運用編」](https://www.mhlw.go.jp/content/10808000/001716295.pdf)
- [厚生労働省「医療情報システムの安全管理に関するガイドライン」関係資料一式](https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html)

## Junify の場合

**人手で続けると** 同じ型の事故を避けるなら、退職や契約終了のたびにその人が使えた ID をすべて止め、共有のパスワードを配り直し、記録を点検する人を決めて回し続けることになります。

**Junify なら** 取引先と共通のパスワードを使う、という入口は Junify では起きません。委託先の担当者に使わせるアカウントも、パスワードは管理者が登録し、担当者は見ないまま使います。誰がいつ使ったかは担当者ごとに残り、担当が代われば割り当てを外すだけです。サーバーや機器の設定は Junify の外です。

Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。

- [登録不要の体験デモを見る](https://www.junify.jp/bpo/try)
- [30 分デモを予約する](https://www.junify.jp/bpo/demo)

## 同じテーマの記事

- [退職を申し出てから退職日までに技術情報を持ち出された事案から分かる、退職予定者の権限の扱い](/guides/incidents/access-between-resignation-notice-and-last-day): 秘密保持契約を結んでいた元社員が、退職を申し出てから退職するまでの間に営業秘密に当たる技術情報を持ち出したとして逮捕されました。会社は再発防止策に、退職予定者のアクセス権限の停止・制限の強化を挙げています。
- [代行会社の Google アカウントへの不正アクセスで公式 X と YouTube が乗っ取られた事案](/guides/incidents/agency-google-account-breached): 代行会社が使用・管理する Google アカウントへの不正アクセスをきっかけに、公式 X で無関係な投稿が、YouTube でチャンネル名の変更や動画の削除が行われました。
- [委託先のパソコンの感染が社内システムへの侵入につながった事案から分かる、ログインの仕組みの共有](/guides/incidents/contractor-pc-malware-shared-auth): 委託先の従業者のパソコンが悪意のあるプログラムに感染し、関係会社と共通のログインの仕組みでつながっていた社内システムに侵入されました。ユーザー・取引先・従業者の情報 44 万件が漏えいしました。委託先と何を共有しているかが問われました。