Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
AI時代における医療情報システムのセキュリティ / Security of Healthcar...
Search
Henry, Inc.
November 10, 2026
Technology
65
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
AI時代における医療情報システムのセキュリティ / Security of Healthcare IT Systems in the AI Era
2026年11月5日に開催したウェビナーで使用した資料を公開用に調整したものです。
https://lp.henry-app.jp/seminar/20261105
Henry, Inc.
November 10, 2026
More Decks by Henry, Inc.
See All by Henry, Inc.
クラウドネイティブ型 電子カルテとセキュリティ / Cloud-Native Electronic Medical Records and Security
henryofficial
1
980
ヘンリー これからの地域医療 vol.1
henryofficial
0
1.6k
ヘンリー会社紹介資料(エンジニア向け) / company deck for engineer
henryofficial
3
5.1k
サービスのReliabilityはチームから!Enablingを通じて実現する、信頼されるサービスづくり / Cloud Operator Days Tokyo 2025
henryofficial
2
1.9k
国内ランサムウェア3事例から学ぶ中小病院におけるサイバーセキュリティ対策 / Cybersecurity Learned from Cases
henryofficial
1
2k
ヘンリー会社説明資料 / Henry company deck
henryofficial
14
180k
楽ありゃ苦もあるモノレポ化 / Goodness and Difficulties of Monorepo
henryofficial
4
8.7k
クラウド電子カルテ事業者によるリスク・コミュニケーションの実践と課題 / risk-communication
henryofficial
1
3.1k
Other Decks in Technology
See All in Technology
An Introduction to Context Ontology Accelerator (teaching AI agents what your data means)
inariku
PRO
1
100
re:Invent2026 事前勉強会 歴史と愉しみ方10分LT編
toshi_atsumi
0
150
顧客合意を取りながら進めるAWSコスト削減の実践
optim
0
120
Sinatra on PicoRuby ローカルでセルフホスト
bash0c7
0
110
基本から分かる!AWSセキュリティ運用の考え方と任せ方
cmusudakeisuke
1
450
AI時代の組織作り:チーム開発から「個人×AI」への移行と、持続可能な「開発資本」の築き方
ham0215
2
300
BALLAS Technology Deck
ballas_inc
0
140
Context Ontology Accelerator 入門 (業務データの意味を、AI エージェントに渡す)
inariku
PRO
3
510
分析作業をどこまで任せるか自分で決められる AIネイティブBI『Golden Analytics』が 良さげな話 /golden-analytics-is-ai-native-bi
shinyaa31
0
120
続・ソフトウェアアーキテクトのための意思決定術: Decision Readiness, Revisited — When AI Changes the Economics of Software Architecture
snoozer05
PRO
9
2.7k
TSKaigi Sendai 2026 - tsgo時代のTypeScript Playgroundはどう動くか
teamlab
PRO
0
110
bpf_arenaとstruct_opsを使うのが難しかった話
masu_mi
0
210
Featured
See All Featured
How Software Deployment tools have changed in the past 20 years
geshan
3
35k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
37
6.7k
Conquering PDFs: document understanding beyond plain text
inesmontani
PRO
4
3.3k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
10k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.9k
The AI Revolution Will Not Be Monopolized: How open-source beats economies of scale, even for LLMs
inesmontani
PRO
3
3.8k
A better future with KSS
kneath
240
18k
How to optimise 3,500 product descriptions for ecommerce in one day using ChatGPT
katarinadahlin
PRO
3
3.9k
Building Experiences: Design Systems, User Experience, and Full Site Editing
marktimemedia
1
660
Test your architecture with Archunit
thirion
2
2.5k
DevOps and Value Stream Thinking: Enabling flow, efficiency and business value
helenjbeal
2
430
Testing 201, or: Great Expectations
jmmastey
46
8.4k
Transcript
※ 公開用資料 © 2026 Henry, Inc. 1
発表者について 株式会社ヘンリーの執行役員。15歳からシステ ム開発に親しみ、社会人として大企業向け基幹 システムの新規企画から保守までを経験。14年 間にわたり、オンプレミスな基幹業務システム のクラウドリフト化ならびにクラウドネイティ ブ化を実現しました。 医療情報技師、ならびに情報セキュリティの国 家資格である情報処理安全確保支援士(登録番 号
028693)を取得しています。 2
今回の目的 院長、事務長・医療情報担当者の皆様をはじめ、 医療情報システムのサイバーセキュリティ対策をご検討の 皆様に状況を整理するための参考情報を提示し、 明日からどうするかを検討するうえでの一助としていただく 紙と筆記用具を お手元にご用意ください 3
アジェンダ 1.サイバーセキュリティの近況 2.ガイドラインに基づく整理 3.必要な体制と対策 © 2026 Henry, Inc. 4
サイバー空間はもはや「戦時」 数多くの脆弱性が矢継ぎ早に発覚、医療業界を含む 多くの事業者で不正アクセスや情報漏えい、サービス 停止の公表が相次いでいます。 • デジタル庁「GSS」 • パーク24「タイムズカー」 • IDCフロンティア「IDCFクラウド」
• GMOインターネット「お名前.com デスクトップク ラウド」 • メドレー「アットリンク」 • エムスリー「MR君」 ※ 11月1日時点、敬称略 5
関係省庁会議が開かれ、省庁横断で注意喚起が出される状況 PHP脆弱性は総理大臣から直接の情報発信も。 • 国家サイバー統括室(NCO) • 一般社団法人JPCERTコーディネーションセンター (JPCERT/CC) • 経済産業省 •
金融庁 • 警察庁 • 個人情報保護委員会 • IPA 6
情報と論点が錯綜 セミナー 報道 学会 AI VPN ADR 注意喚起 ガイドライン ⼆要素認証
ノーウェアランサム? 研修 クラウドは危険? BCP 制度改定 ランサムウェア 報告書 7
単発の行動や解決(製品)に議論が集中してしまう セミナー 報道 学会 VPN AI ガイドラインに載ってる EDRってのが 必要なんだって!? ADR
注意喚起 ガイドライン いや、これからは XDRだってさ! ⼆要素認証 ノーウェアランサム? 研修 制度改定 クラウドは危険? クラウドはダメ! これからはオンプレ! ランサムウェア BCP 報告書 8
今後 AI 活用によってサイバー攻撃が加速すると考えられる 9
実際今年に入って攻撃は増加傾向にある 10
AIによる攻撃の加速と医療機関への影響 単純に「攻撃される確率が上がる」→「やるべきこと をちゃんとやる」ことが今まで以上に大切になる 攻撃の段階 → ① 偵察‧標的の選定 ② 侵⼊(⼊⼝) ③
侵⼊後の拡⼤‧ 持出し ④ 恐喝‧⼆次被害 既存の⼿⼝ 公開情報や機器を探索 し、侵⼊可能な標的を探 す。規模を問わず狙われる 脆弱性の悪⽤やフィッシ ングで侵⼊。公開直後の 悪⽤や巧妙な⽂⾯もある 内部を探索し、権限を奪 取。データやバックアッ プに到達する 暗号化やデータ窃取で恐 喝。情報の公開‧転売や 関係者への脅迫 AIによる 効率化 公開情報の収集‧分析や 標的の絞り込みを効率 化。より多くの対象を調べ やすくなる 脆弱性の分析や攻撃コー ドの作成を⽀援。⾃然な ⽂⾯や偽の⾳声‧動画を 作りやすくなる 内部探索や攻撃⼿順の実 ⾏、データの分類を⽀援 し、侵⼊後の活動を効率 化 盗んだデータの要約‧選 別や脅迫⽂の作成を効率 化。被害は件数だけでな く内容にも左右される 医療機関 への影響 「うちは狙われない」が 成り⽴たない。露出して いる機器(VPN‧ルーター ‧管理画⾯)を知らない と守れない 深刻度だけでなく、公開 の有無や悪⽤状況を踏ま えて優先順位を判断し、 迅速に対応する。更新は 仕組みで回す 検知から隔離までの時間 が重要。本体から分離 し、復元を確認したバッ クアップが復旧を左右す る 要配慮個⼈情報を含む個 ⼈データの漏えい等は原 則1⼈分でも報告対象。通 知‧公表‧紙運⽤に備え る 11
幸い「やるべきこと」は変化していない AI によって攻撃の速さと量が増えましたが、有効な 対策は変化していません。よって対策も不変です。 まずは、厚生労働省ガイドラインに基づき、貴院の サイバーセキュリティ対策状況を確認することが 大切です。 その後、AI 時代の速さと量に対応するための体制と 対策を検討しましょう。
12
アジェンダ 1.サイバーセキュリティの近況 2.ガイドラインに基づく整理 3.必要な体制と対策 © 2026 Henry, Inc. 13
医療情報を取り巻くガイドラインの構成 法令を土台に、医療機関向けと事業者向けのガイドラ インがある。両者は「事業者が説明・開示し、医療機 関が確認して選ぶ」合意でつながる 厚生労働省 安全管理ガイドライン 医療機関の責務 事業者を選び、確認し、院内を守る • 安全管理の体制・規程・BCP
• 端末・院内ネットワークの管理 • 利用者IDと認証の運用 • 委託先の監督 総務省・経済産業省 提供事業者ガイドライン 🤝 合意 利⽤規約‧利⽤契約書 サービスレベル共通合意書 サービス仕様適合開⽰書‧SDS 提供事業者の責務 リスクを管理し、説明し、合意を守る • クラウド上のシステムとデータの安全管理 • 対応状況と残存リスクの開示 • 定期報告・事故時の通知と再発防止 • 外部サービス・委託先の管理 14
事業者にしているのは「委託」であって「丸投げ」ではない システムの運用を委託しても、医療機関の安全管理や 委託先の監督の責任はなくなりません。役割・責任を 明確にし、医療機関が担う対策を実施しましょう。 厚生労働省 安全管理ガイドライン 医療機関の責務 事業者を選び、確認し、院内を守る • 安全管理の体制・規程・BCP
• 端末・院内ネットワークの管理 • 利用者IDと認証の運用 • 委託先の監督 総務省・経済産業省 提供事業者ガイドライン 🤝 合意 利⽤規約‧利⽤契約書 サービスレベル共通合意書 サービス仕様適合開⽰書‧SDS 提供事業者の責務 リスクを管理し、説明し、合意を守る • クラウド上のシステムとデータの安全管理 • 対応状況と残存リスクの開示 • 定期報告・事故時の通知と再発防止 • 外部サービス・委託先の管理 15
ものさしとしてのNIST CSF 2.0 16
厚労省ガイドライン第7.0版の全体像 NIST CSF 2.0 の6機能(統治・特定・防御・検知・対 応・復旧)で読むと、各編がどこを担うかが分かる。 CSF 2.0 の6機能 →
1 経営管理編 経営層が判断する 2 企画管理編 企画管理者が規程と契約に落とす 特定 防御 検知 対応 復旧 ⽅針‧責任者‧予 算∕リスク受容∕ 契約の承認 サポート切れ‧残 存リスクの判断 ∕BCPの承認 対策への投資の判 断 — 公表‧報告‧停⽌ の判断 復旧の優先順位の 判断 規程‧体制∕委託 先の契約‧監督 資産台帳∕リスク 評価∕BCP‧紙運 ⽤の策定と訓練∕ 改善 権限‧端末‧媒体 のルール∕教育∕ 委託先への要求事 項 ログ確認の体制‧ 頻度 対応⼿順‧連絡体 制∕当局報告‧本 ⼈通知 復旧の優先順位‧ ⼿順 — 構成‧設定‧資産 の管理∕脆弱性情 報の収集 ⼆要素認証∕機器 ‧端末‧媒体∕更 新∕バックアップ 取得‧分離∕ログ 取得‧保存 ログの監視‧異常 の分析 遮断‧隔離‧証拠 保全‧停⽌ 復元‧復旧⼿順の 実⾏ 3 システム運⽤編 運⽤担当(または委託先)が実施 する 保守委託機関編(新設) 統治 サーバの更新などを事業者に委託する医療機関向けに、②③のうち医療機関に残る項⽬(事業者の選定‧契約‧監督、端末‧アカウント‧教育‧BCP)をまとめた編 Henryをお使いの医療機関はここから 1 経営層が「判断」する編。⽅針‧予算‧残存リスクの受容。安全管理はコストではなく投資 2 企画管理者が規程‧体制‧教育と、委託先との契約‧監督を定める編。対応⼿順‧BCPもここ 3 運⽤担当が技術的対策を実施する編。クラウド型では、サーバ側の多くを事業者(当社)が担う 4 委託する医療機関のための編。医療機関に残る責務と、事業者に求める事項が⼀冊で分かる 4 横軸は NIST CSF 2.0 の6機能(IPA訳) 防御には教育‧バックアップの取得などの「備え」を含み、復旧は復元と紙運⽤の実⾏。 17
医療機関と事業者の役割分担も同様に整理できる 医療機関だけ、基幹システムだけ、部門システムだけ ではサイバーセキュリティ対策としては不足。 CSF 2.0 の6機能 → 医療機関 クラウド型 基幹システム
他の事業者 (部⾨システム ‧NW機器‧端末 保守など) 統治 特定 防御 検知 対応 復旧 経営層の⽅針‧予算、 責任者の指名、契約内 容の確認‧委託先の監 督 資産台帳‧⼊⼝(端末 ‧NW機器‧部⾨シス テム)の⼀覧、サポー ト切れの把握、BCP (紙運⽤)の策定‧訓 練 端末管理、アカウント 管理(⼊退職‧共有禁 ⽌)、院内NW‧VPN 機器の更新、職員教育 不審な事象の報告、ロ グ確認の依頼 連絡体制、厚労省への 連絡‧本⼈通知 紙運⽤への切替、診療 継続、復旧の優先順位 責任分界の⽂書(利⽤ 規約‧開⽰書‧合意 書)、第三者認証、年 次の運⽤報告 資産‧構成の管理、脆 弱性情報の⽇次確認、 復旧⼿順の整備‧訓 練、第三者診断の実施 アプリ‧基盤更新、認 証‧アクセス制御、海 外通信遮断、バック アップ(複数世代‧遠 隔‧隔離)、脆弱性修 正、ログ取得‧保存 ログ‧稼働状況の監 視、異常の分析 医療機関への通知、証 拠保全、所管官庁‧個 情委への報告対応 バックアップからの復 元、復旧後の再接続 責任分界の⽂書、保守 体制 サポート終了の計画、 構成の把握 部⾨システム‧NW機 器のアップデート、管 理画⾯の⾮公開、部⾨ システムのバックアッ プ、ログの取得‧保存 機器‧システムのログ 監視、異常の分析‧通 知 医療機関への通知、機 器の隔離 部⾨システムの復旧⽀ 援 18
「防御だけ」「復旧だけ」も不足、「ひとつだけの対策」も不足 入口だけ守る「閉域網神話」と同様、「防御だけ」 「復旧だけ」のサイバーセキュリティ対策では不足。 また「ワクチンは打つけどマスクはしない」と同様、 「システムは入れるが教育はしない」のようなひとつ だけの対策も不十分です。 解決(製品)をひとつ入れて終わりにならず、運用を 検討し、事業継続計画を立てましょう。 いらすとや「桶の理論のイラスト」 19
ということで…… 20 © 2025 Henry, Inc.
紙上演習1(1分) 予約システム事業者から「個人情報が漏えいした、 当面サービス提供を停止する」との連絡がありました。 どう動くべきでしょうか?そのためには、 どんな備えが必要ですか? 21 © 2025 Henry, Inc.
解説:どのような考慮点があるか • 個人情報漏えい時にやるべきことは? • 予約システムが扱う個人情報とは? • 予約システムは何と連携している? • 予約システムが止まると、どこで誰が困る? •
予約業務を予約システムなしでどう回す? • 予約システム事業者側の問い合わせ窓口は? • 患者からの問い合わせには誰が対応する? • このような有事の対応について、事業者との契約は どう定めている? 22
厚労省ガイドライン第7.0版の全体像(再掲) 『対応』『復旧』を支えるため、契約・役割分担・判 断権限を平時から定める『統治』が重要です CSF 2.0 の6機能 → 1 経営管理編 経営層が判断する
2 企画管理編 企画管理者が規程と契約に落とす 特定 防御 検知 対応 復旧 ⽅針‧責任者‧予 算∕リスク受容∕ 契約の承認 サポート切れ‧残 存リスクの判断 ∕BCPの承認 対策への投資の判 断 — 公表‧報告‧停⽌ の判断 復旧の優先順位の 判断 規程‧体制∕委託 先の契約‧監督 資産台帳∕リスク 評価∕BCP‧紙運 ⽤の策定と訓練∕ 改善 権限‧端末‧媒体 のルール∕教育∕ 委託先への要求事 項 ログ確認の体制‧ 頻度 対応⼿順‧連絡体 制∕当局報告‧本 ⼈通知 復旧の優先順位‧ ⼿順 — 構成‧設定‧資産 の管理∕脆弱性情 報の収集 ⼆要素認証∕機器 ‧端末‧媒体∕更 新∕バックアップ 取得‧分離∕ログ 取得‧保存 ログの監視‧異常 の分析 遮断‧隔離‧証拠 保全‧停⽌ 復元‧復旧⼿順の 実⾏ 3 システム運⽤編 運⽤担当(または委託先)が実施 する 保守委託機関編(新設) 統治 サーバの更新などを事業者に委託する医療機関向けに、②③のうち医療機関に残る項⽬(事業者の選定‧契約‧監督、端末‧アカウント‧教育‧BCP)をまとめた編 Henryをお使いの医療機関はここから 1 経営層が「判断」する編。⽅針‧予算‧残存リスクの受容。安全管理はコストではなく投資 2 企画管理者が規程‧体制‧教育と、委託先との契約‧監督を定める編。対応⼿順‧BCPもここ 3 運⽤担当が技術的対策を実施する編。クラウド型では、サーバ側の多くを事業者(当社)が担う 4 委託する医療機関のための編。医療機関に残る責務と、事業者に求める事項が⼀冊で分かる 4 横軸は NIST CSF 2.0 の6機能(IPA訳) 防御には教育‧バックアップの取得などの「備え」を含み、復旧は復元と紙運⽤の実⾏。 23
厚労省ガイドライン第7.0版の全体像(再掲) 予約システムから基幹システムなどへの攻撃・侵入を 想定した初動と防衛も検討しましょう CSF 2.0 の6機能 → 1 経営管理編 経営層が判断する
2 企画管理編 企画管理者が規程と契約に落とす 特定 防御 検知 対応 復旧 ⽅針‧責任者‧予 算∕リスク受容∕ 契約の承認 サポート切れ‧残 存リスクの判断 ∕BCPの承認 対策への投資の判 断 — 公表‧報告‧停⽌ の判断 復旧の優先順位の 判断 規程‧体制∕委託 先の契約‧監督 資産台帳∕リスク 評価∕BCP‧紙運 ⽤の策定と訓練∕ 改善 権限‧端末‧媒体 のルール∕教育∕ 委託先への要求事 項 ログ確認の体制‧ 頻度 対応⼿順‧連絡体 制∕当局報告‧本 ⼈通知 復旧の優先順位‧ ⼿順 — 構成‧設定‧資産 の管理∕脆弱性情 報の収集 ⼆要素認証∕機器 ‧端末‧媒体∕更 新∕バックアップ 取得‧分離∕ログ 取得‧保存 ログの監視‧異常 の分析 遮断‧隔離‧証拠 保全‧停⽌ 復元‧復旧⼿順の 実⾏ 3 システム運⽤編 運⽤担当(または委託先)が実施 する 保守委託機関編(新設) 統治 サーバの更新などを事業者に委託する医療機関向けに、②③のうち医療機関に残る項⽬(事業者の選定‧契約‧監督、端末‧アカウント‧教育‧BCP)をまとめた編 Henryをお使いの医療機関はここから 1 経営層が「判断」する編。⽅針‧予算‧残存リスクの受容。安全管理はコストではなく投資 2 企画管理者が規程‧体制‧教育と、委託先との契約‧監督を定める編。対応⼿順‧BCPもここ 3 運⽤担当が技術的対策を実施する編。クラウド型では、サーバ側の多くを事業者(当社)が担う 4 委託する医療機関のための編。医療機関に残る責務と、事業者に求める事項が⼀冊で分かる 4 横軸は NIST CSF 2.0 の6機能(IPA訳) 防御には教育‧バックアップの取得などの「備え」を含み、復旧は復元と紙運⽤の実⾏。 24
紙上演習2 給食システム事業者から「システムに不正アクセスがあ り、過去1ヶ月にわたり攻撃者が貴院のシステムに接続 していた可能性がある」との連絡がありました。どう動く べきでしょうか? 25 © 2025 Henry, Inc.
紙上演習3 オンライン資格確認システムについて「貴院のクライア ント証明書と対応する秘密鍵を使った不正アクセスを確 認したため、当該証明書を失効させた」との連絡があり ました。どう動くべきでしょうか? 26 © 2025 Henry, Inc.
アジェンダ 1.サイバーセキュリティの近況 2.ガイドラインに基づく整理 3.必要な体制と対策 © 2026 Henry, Inc. 27
まず、”締め切り”はいつなのか サイバー攻撃へのAI活用は既に始まっています。今 後、さらに高い能力を持つモデルの悪用や、攻撃の各 工程の自動化が進む可能性があります。 現在観測されている攻撃が、AIを使った攻撃の到達点 ではありません。医療情報システムへの攻撃がさらに 激化することを見据え、今から備えを進めましょう。 28
はじめに実態を把握しましょう 各システムのアカウント、実際に使っている職員、 VPNなどの外部接続点などを洗い出しましょう。 立入検査で使う「サイバーセキュリティ対策チェック リスト」で求められる 台帳管理 が便利です。 29
事業者に状況を確認しましょう 1. 責任分界を文書で示せるか 2. サーバ・OS等の更新は、誰が、どの頻度で行うか 3. 脆弱性の公開から修正の適用まで、どれくらい かかっているか 4. 事故のとき、いつまでに・誰に・どう通知するか
5. バックアップは本体と分離されているか 30
事業者に”契約離れ”した期待を持っていないか確認しましょう • 保守契約がない機器等を事業者は保守しません。 • 「専門家としての対応や責任を果たしていない」事業者 は存在します(半田病院様 有識者会議調査報告書)。 契約内容が守られているか監査することも医療機関の 責任です(厚生労働省ガイドライン)。 •
漏えいした認証情報を使ったアクセスは、多くのシステ ムでは正規のアクセスとの見分けがつきません。 • 情報漏えい時の個人情報保護委員会報告などの手続きも 多くの場合は医療機関が主体となります。 31
できていないことを探し、優先度をつけましょう 現在の規約や職員教育の「実態」を踏まえ、どこに穴 があるかを検討しましょう。 CSF 2.0 の6機能 → 1 経営管理編 経営層が判断する
2 企画管理編 企画管理者が規程と契約に落とす 特定 防御 検知 対応 復旧 ⽅針‧責任者‧予 算∕リスク受容∕ 契約の承認 サポート切れ‧残 存リスクの判断 ∕BCPの承認 対策への投資の判 断 — 公表‧報告‧停⽌ の判断 復旧の優先順位の 判断 規程‧体制∕委託 先の契約‧監督 資産台帳∕リスク 評価∕BCP‧紙運 ⽤の策定と訓練∕ 改善 権限‧端末‧媒体 のルール∕教育∕ 委託先への要求事 項 ログ確認の体制‧ 頻度 対応⼿順‧連絡体 制∕当局報告‧本 ⼈通知 復旧の優先順位‧ ⼿順 — 構成‧設定‧資産 の管理∕脆弱性情 報の収集 ⼆要素認証∕機器 ‧端末‧媒体∕更 新∕バックアップ 取得‧分離∕ログ 取得‧保存 ログの監視‧異常 の分析 遮断‧隔離‧証拠 保全‧停⽌ 復元‧復旧⼿順の 実⾏ 3 システム運⽤編 運⽤担当(または委託先)が実施 する 保守委託機関編(新設) 統治 サーバの更新などを事業者に委託する医療機関向けに、②③のうち医療機関に残る項⽬(事業者の選定‧契約‧監督、端末‧アカウント‧教育‧BCP)をまとめた編 Henryをお使いの医療機関はここから 1 経営層が「判断」する編。⽅針‧予算‧残存リスクの受容。安全管理はコストではなく投資 2 企画管理者が規程‧体制‧教育と、委託先との契約‧監督を定める編。対応⼿順‧BCPもここ 3 運⽤担当が技術的対策を実施する編。クラウド型では、サーバ側の多くを事業者(当社)が担う 4 委託する医療機関のための編。医療機関に残る責務と、事業者に求める事項が⼀冊で分かる 4 横軸は NIST CSF 2.0 の6機能(IPA訳) 防御には教育‧バックアップの取得などの「備え」を含み、復旧は復元と紙運⽤の実⾏。 32
クラウドネイティブ型 電⼦カルテの強み © 2026 Henry, Inc. 33
クラウドネイティブ型は攻撃が高速化する時代に適合 攻撃が速く、高度になるほど、防御を継続して更新す る能力が必要です。専門的な防御を集中し、改善を迅 速に届けられる方式が、安全性を高め続けるうえで最 も合理的だと考えます。 Henry では2025年には4,563回の更新を行い、2026 年には10月末時点で5,493回の更新実績があります。 この継続的な更新体制を、脆弱性修正の迅速な提供に も活用しています。
34
貴院のシステムは迅速な脆弱性対応を行えていますか? 10月は重大な脆弱性やセキュリティ事故の公表が相次 ぎました。多くのシステムで脆弱性が発見され、 eMudhra の中間 CA の秘密鍵侵害は暗号通信の前提 を崩しました。 弊社では関係するいずれ脆弱性も対応を迅速に行えた と考えています。院内でご利用のシステムがどうだっ
たか、通信の安全性は保てているか、一度ご確認いた だければと思います。 35
まとめ © 2026 Henry, Inc. 36
AI 時代、ガイドラインを灯火とし基本に立ち返ることがまず肝要 • • • • AI によって攻撃の速さと量が増しても、対策の基本は変わ りません。まずはガイドラインに沿って、自院の対策状況を 確認しましょう。
製品の導入だけで対策は完結しません。院内の運用・職員教 育から、被害の検知・対応・復旧まで備えましょう。 契約と実態を確かめ、誰が何を担うかを明確にしましょう。 事業者に委託しても、医療機関の判断と確認は残ります。 できていないことに優先順位をつけ、改善を始めましょう。 攻撃の速さと量に対応するには、対策を継続して実行・更新 できる体制が必要です。 37
電子カルテ標準仕様の「認証制度」解説のアーカイブ放送を行います https://lp.henry-app.jp/seminar/20261021_archive 38
Q&A 39 © 2025 Henry, Inc.
Q&A① Q. サイバーセキュリティに対するBCP作成において、 参考になる資料やウェブサイトなどありますか? A. 厚生労働省から専用ページが公開されています。災 害BCPと混同しないようご注意ください。 https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html#h2_4 40
Q&A② Q. 経営層より「費用をかければ、セキュリティ対策 はできるが、費用をかけない方法をまず検討してほし い」と言われることがあります。そうなった場合、担 当者としてどう検討・対応すればいいのか悩みます。 まずは、何をすればいいのでしょうか。 A. 端末やネットワーク機器、アカウントなどの台帳管 理を進めることをおすすめします。またサポート詐欺
やフィッシングメールなどの相談先を整備するなど、 職員教育も有効だと思われます。 41
Q&A③ Q. VPNルータのファームウェアアップデートなどの 責任分界が不明確となるケースについて、どう責任分 界を決めればいいのでしょうか。 A. まずは契約内容をご確認ください。メーカと保守契 約を結んでいない場合、または保守契約にファーム アップデートが含まれていない場合、医療機関側の責 任になると思われます。
42
Q&A④ Q. アンチウイルスソフトの採用はクラウド型システ ムの安全性を高めるのに有効か。 A. ソフトに期待する役割・効果によります。OS標準 機能で充分な場合も考えられますし、そのソフトが提 供する固有機能が有効な場合も考えられます。 「とりあえず〇〇を導入する」ではなく、不安に名前 をつけて「〇〇のために〇〇を導入する」と言えるよ
うになるために、今回ご紹介したガイドラインをご活 用いただければ幸いです。 43
紙上演習参考情報 44 © 2025 Henry, Inc.
紙上演習2(給⾷事業者の事例) 統治‧特定:給⾷に限らず部⾨システム経由での攻撃は充分に想定されます。VPN サーバなどの通信経路について契約内容を確認して責任分界点を明確にし、部⾨シ ステム停⽌時にどのような業務に影響が出るのか、平時から検討しBCP計画を作る ことが必要だと考えられます。 防御:⼤阪急性期‧総合医療センター様のランサムウェア事例がまさに給⾷事業者 を経由しての攻撃でした。通信の制限、OS管理ユーザを⼀般職員に使わせない、OS 管理ユーザのパスワードを共通のものにしないなどの対策を検討ください。本事例 の報告書や書籍「医療機関のサイバー対策」が参考になります。 また攻撃者は⻑期間潜伏することがあるため、時間経過でサーバや端末のログが消
えないよう、保存期間を⾒直すことも必要だと思われます。 対応に向けた準備:事故発⽣後のログの収集‧証拠保全‧原因調査の⼿順を検討し ておきましょう。 © 2026 Henry, Inc. https://www.gh.opho.jp/news/cyberbook 45
紙上演習3(クライアント証明書失効の事例) 特定:BCPとしては対象システムが停⽌した場合と同様に検討できます。サイバー攻 撃の増加にともない特定のシステムが停⽌することは充分に発⽣が想定されますの で、停⽌時‧失効時の⼿順を整理しておきましょう。 防御:連携が必要な端末‧サーバだけに証明書と秘密鍵を配置しましょう。管理者 権限の普段遣いを避け、導⼊後は秘密鍵を含むインストール⽤ファイルを作業⽤端 末から削除しましょう。調査に必要なログの保存も確認しましょう。 検知:事業者からの失効通知や認証エラー、不審な接続の記録を確認し、異常を把 握できるようにしましょう。失効や認証エラーが起きた場合は、その理由を事業者 に確認しましょう。
対応に向けた準備:認証情報(証明書‧秘密鍵)の流出経路を調べるため、必要な ログと調査⼿順を確認しましょう。 復旧に向けた準備:新しい秘密鍵と再発⾏した証明書で業務を再開する⼿順と、事 業者の窓⼝‧対応時間を確認しましょう。 © 2026 Henry, Inc. https://www.gh.opho.jp/news/cyberbook 46
参考資料 47 © 2025 Henry, Inc.
サイバーセキュリティ対策が経営の責任である理由 令和5年4⽉、医療法施⾏規則に、病院‧診療所‧助産所の 管理者がサイバーセキュリティ確保のために必要な措置を講 じる義務が明記されました。 対策を実⾏するには、専⾨的なリスク評価に加え、予算‧⼈ 員の確保や、⾮常時に診療をどう継続するかの判断が必要で す。経営層が⽅針と権限を定め、実施状況を確認する必要が あります。 安全管理ガイドラインは、医療情報システム安全管理責任者 を経営層が担うことを想定しています。企画管理者による兼
務も認めていますが、経営層には、必要な体制の整備と、⾮ 常時の業務継続に関する判断が求められます。 © 2026 Henry, Inc. https://www.mhlw.go.jp/content/10808000/001075881.pdf https://www.mhlw.go.jp/content/10808000/001716291.pdf https://note.com/henry_app/n/n8592b0763b33 48
事業者側の事故でも、医療機関の報告‧患者対応は必要になる 患者の情報を事業者に預けていても、医療機関の管理責任は 残ります。事業者側で漏えい等が起きた場合も、法令上の報 告対象に該当すれば、医療機関にも個⼈情報保護委員会への 報告や患者本⼈への通知が求められます。 事業者には原因調査や影響範囲の確認を求め、医療機関で は、その情報をもとに必要な報告‧患者への説明‧問い合わ せ対応を進めます。 事故が起きてから迷わないよう、事業者から何をいつまでに 知らせてもらうか、院内で誰が判断し、誰が報告‧説明する
かを、平時から決めておきましょう。 © 2026 Henry, Inc. 49
サイバーセキュリティ⼈材が院内にいない場合 IPAが公開している「中⼩企業向けサイバーセキュリ ティ対策⽀援者リスト」を使い、医療業界に理解のあ る情報処理安全確保⽀援⼠を探してみましょう。 © 2026 Henry, Inc. https://www.ipa.go.jp/security/sme/shien/list.html 50
サイバーセキュリティ⼈材になりたい場合 地域医療基盤開発推進研究事業の「安全な地域医療の継続性 確保に資する医療機関における情報セキュリティ⼈材の育成 と配置に関する研究」では、⽇常業務における基礎的なセ キュリティ対策を⾏う⼈材の教育においてIPAの「ITパス ポート試験」を参照しています。ITパスポート試験は教材も ⼊⼿しやすいのでオススメできます。 その後のステップとしては「情報セキュリティマネジメント 試験」「情報処理安全確保⽀援⼠試験」などが挙げられま す。
© 2026 Henry, Inc. https://mhlw-grants.niph.go.jp/project/177220 51
既存事業者との責任分界の⾒直し⽅ 経済産業省「医療情報システムの契約における当事者 間の役割分担等に関する確認表」の利⽤をおすすめし ています。 またVPNサーバをはじめとした事業者が持ち込んだ サーバやネットワーク機器の保守責任が誰にあるかを あわせて確認しましょう。 © 2026 Henry,
Inc. https://www.meti.go.jp/shingikai/mono_info_service/medical_information_system/checklist.html 52
厚⽣労働省から通知された対策をやれば充分か? 10⽉末に「オンライン診療システムにおける不正ログイン事案の発⽣に伴うセ キュリティ対策強化のお願い」として医療機関ないし医療情報システム事業者に 対する通知がありました。 この書類に記載されている対策は、リスト型アカウントハッキング(リスト型攻 撃)を想定した対策です。それ以外の攻撃に対してはその他の対策を組み合わせ ることが必要となります。たとえばVPNサーバの脆弱性を利⽤された事例、不正 プログラムを設置された事例などでは、この対応では不⾜する可能性が⾼いと⾔ えます。 いらすとや「桶の理論のイラスト」
© 2026 Henry, Inc. https://www.mhlw.go.jp/content/10808000/001764773.pdf 53
公⽴病院におけるランサムウェア事例の報告書 • つるぎ町立半田病院様 • 大阪急性期・総合医療センター様 • 岡山県精神科医療センター様 © 2026 Henry,
Inc. 54
弊社 note 関連記事 • 「オンプレとクラウド、どちらが安定稼働する か」問題について • ファイル連携やソケット連携ではなく、API連携が 求められる理由 •
ITシステムの専門家が不在の医療機関様が医療情 報システムを導入する現場におけるコミュニケー ション(個人情報漏洩 編) • 医療政策におけるサイバーセキュリティの現在地 © 2026 Henry, Inc. 55
弊社セミナー資料 • 国内ランサムウェア3事例から学ぶ中小病院におけ るサイバーセキュリティ対策(2025年6月) • クラウドネイティブ型電子カルテとセキュリティ (2026年3月) © 2026 Henry,
Inc. 56
今回の内容では物⾜りない⽅へ © 2026 Henry, Inc. 57
⼈もAIも、判断の根拠となる情報が必要 「このアカウントは誰のものか」「その職員は在職しているか」「この端末で何が 起きたか」。こうした情報を確認できなければ、⼈もAIも、状況に即した判断が難 しくなります。 従業員‧アカウント‧端末‧権限の⼀覧や各種マスタについて、どこで管理する か、誰が更新するかを決めましょう。ログと照合できるようにし、情報の更新⽇時 や変更履歴も確認できる状態にします。 この「信頼できる情報の参照元(Single Source of
Truth)」を整えることは、⽇々 の確認や事故対応を⽀えるだけでなく、防衛にAIを活⽤するための⼟台にもなると 期待できます。 © 2026 Henry, Inc. 58
59