権限設計は、医療機関のセキュリティ対策のなかで最も理想論に流れやすい領域です。「最小権限の原則」「職務分掌」「特権IDの厳格な管理」——いずれも正しいのですが、そのまま現場に持ち込むと、夜間に必要な操作ができない、応援の看護師がカルテを開けない、緊急時に誰も対処できない、といった事態を招きます。医療は止められない業務であり、権限設計はその制約のなかで成立しなければなりません。
一方で、公表されている被害事例で被害が院内全体に広がった構造を見ると、権限の過剰付与と共有IDが繰り返し現れます。 最初の1台に侵入されたあと、そこから全システムに到達できてしまう距離の短さが被害を決定づけます。
本記事では、理想と現場の間にある実行可能な線を探ります。具体的には、職種別の権限設計、最小権限の適用範囲、異動・退職時の棚卸し、ベンダー保守アカウント、そして共有IDをやめられない現場での次善策を扱います。
免責：本記事は一般的な情報提供です。ガイドラインの解釈や診療報酬の算定要件は、厚生労働省をはじめとする関係省庁の公表資料および地方厚生局の通知が正本です。実際の対応判断はそれらに基づいて行ってください。
権限を「職種」で切るか「業務」で切るか
多くの電子カルテは職種別のロールを提供しています。医師、看護師、薬剤師、放射線技師、医事課、事務。これは出発点としては妥当ですが、職種と必要な権限は一致しません。
- 同じ「看護師」でも、病棟と外来と手術室で必要な情報が違う
- 「医事課」でも、受付と請求で扱う範囲が違う
- 非常勤医師と常勤医師で、参照すべき範囲が異なる場合がある
- 実習生・研修医・派遣職員の扱いが職種ロールに収まらない
したがって実務的には、職種ロールを土台にしつつ、業務単位で例外を定義する二層構造になります。重要なのは、例外を個人単位で無制限に作らないことです。例外が増えると、誰がどこまで見られるのかを誰も説明できなくなり、棚卸しも不可能になります。
設計の考え方
| 層 | 単位 | 決めること | 変更頻度 |
|---|---|---|---|
| 基本ロール | 職種 | その職種が通常必要とする範囲 | 低い（年単位） |
| 業務ロール | 部署・業務 | 病棟／外来／手術室などの差分 | 中程度 |
| 個別付与 | 個人 | どうしても必要な例外のみ | 最小限に。期限を必ず付ける |
個別付与には必ず期限を付けるのが要点です。「プロジェクトのため一時的に」付与された権限が数年残るのは典型的な失敗です。期限付きにしておけば、棚卸しをしなくても自動的に整理されます。
なお、医療の性質上、「見せない」ことがリスクになる場面があります。救急対応で患者の既往が参照できなければ、それ自体が医療安全上の問題です。したがって医療機関の権限設計は、一般企業のように「原則拒否」で組むと破綻します。現実的な解は、参照範囲を広めに取りつつ、参照した事実を記録して事後に点検するという組み合わせです。これが医療機関でログ管理が特に重要になる理由でもあります。詳しくは ログ管理と監査証跡 と 電子カルテのアクセスログ点検 をご覧ください。
最小権限をどこに適用するか
「最小権限」をすべてに適用しようとすると現場が止まります。適用すべき場所を絞ることが実務的です。
最小権限を厳格に適用すべき対象
| 対象 | 理由 |
|---|---|
| システム管理者権限 | 奪われると全体に到達される |
| データベースの直接操作権限 | 監査ログを回避した改変が可能になる |
| バックアップ領域への書込・削除権限 | バックアップごと暗号化される構造を作る |
| 監査ログの削除権限 | 痕跡の消去を許す |
| 権限付与の権限 | 攻撃者が自ら権限を拡張できる |
| 外部への一括出力機能 | 大量持ち出しの経路になる |
この6つが最優先です。 とくに3つ目は、バックアップ設計 で触れたとおり、本番の管理者権限でバックアップも削除できる構成は、権限が奪われた時点で復旧手段を失うことを意味します。バックアップ領域の認証情報は、本番環境と分離してください。
逆に、診療情報の参照権限を過度に絞ることは、医療安全との衝突を生みます。ここは「絞る」より「記録して点検する」で対応する領域です。
特権IDの管理については、次の4点が基本形です。
- 常用アカウントと分離する：日常業務用のIDと管理者用のIDを分ける。管理者IDでメールを読まない
- 共有しない／共有するなら払い出し記録を残す：誰がいつ使ったかを特定できる状態にする
- 多要素認証を必須にする：導入の優先順位として最上位。多要素認証の導入 を参照
- 利用ログを別管理にする：特権IDの操作ログは、その特権IDで消せない場所に保管する
システム連携やAPI経由の自動処理に与える権限も、同じ考え方で設計します。人間のアカウントと違って「必要だから広めに」が通りやすい領域ですが、処理内容から逆算して必要最小限に絞れます。この論点は 医療機関でMCPを使うときの権限設計とセキュリティ確認事項 で、AI連携の文脈に即して詳しく扱っています。
異動・退職時の棚卸しが効く理由
権限管理で最も実効性が高いのは、精緻な設計よりも棚卸しの仕組み化です。設計がどれほど正しくても、退職者のアカウントが有効なまま残っていれば意味がありません。
医療機関では、次の理由で棚卸しが難しくなります。
- 年度替わりに異動・入職が集中し、人事情報の反映が追いつかない
- 非常勤・派遣・委託・実習生など、人事システムに載らない人がいる
- システムが複数あり、それぞれに個別のアカウントが存在する
- 退職の連絡が情報システム担当まで届く経路が決まっていない
仕組み化のポイントは、人事イベントと連動させることです。
| イベント | やること | 期限の目安 |
|---|---|---|
| 入職 | 職種ロールに基づく付与。個別付与は申請ベース | 着任日まで |
| 異動 | 旧部署の権限を外してから新部署を付与 | 異動日 |
| 休職 | アカウントの一時停止 | 休職開始日 |
| 退職 | 全システムのアカウント無効化 | 退職日当日 |
| 委託終了 | ベンダーアカウントの無効化 | 契約終了日 |
| 定期 | 全アカウントの棚卸し | 年1回以上 |
**異動時の「外してから付ける」**が最も見落とされます。新しい部署の権限を追加するだけで旧部署の権限が残ると、長く在籍している職員ほど権限が積み上がっていきます。10年勤務した職員が院内のほぼすべてにアクセスできる、という状態はこうして生まれます。
棚卸しの実務的な進め方として、次の観点で一覧を出すと発見が多くなります。
- 90日以上ログインのないアカウント
- 人事名簿と突合して該当者のいないアカウント
- 管理者権限を持つアカウントの全数
- 個別付与された例外権限のうち、期限を過ぎているもの
- 委託先に払い出したアカウントの全数
ベンダーの保守アカウントをどう扱うか
院内職員のアカウントは管理されていても、委託先に渡しているアカウントは手つかずという医療機関は少なくありません。しかし公表されている被害事例では、保守・委託経路からの波及が繰り返し現れる型のひとつです。
保守アカウントが管理から外れる理由は構造的です。導入時にベンダーが自ら設定したため院内の台帳に載らない、担当者が交代してもアカウントは同じものが使い回される、契約は事務部門が管理し情報システム部門は知らない、といった事情が重なります。
契約・SLAで定めるべき事項
| 項目 | 決めること |
|---|---|
| アカウントの発行単位 | 会社単位か、作業者個人単位か（個人単位が原則） |
| 接続元 | どこからの接続を許可するか |
| 接続可能時間 | 常時接続か、申請時のみ開放か（申請時のみが望ましい） |
| 権限範囲 | 保守に必要な範囲に限定されているか |
| 作業記録 | 誰がいつ何をしたかの記録を、どちらが保管するか |
| 担当者変更時の通知 | 交代時に医療機関へ通知する義務 |
| 契約終了時の措置 | アカウント削除と、その完了報告 |
| 再委託 | 再委託の可否と、その場合の管理責任 |
「申請時のみ開放」が実現できると、リスクは大きく下がります。 常時接続の保守経路は、境界機器の脆弱性と組み合わさったときに被害が拡大しやすい構造です。VPN機器の脆弱性対策 と併せて設計してください。
委託先の管理体制そのものを確認する観点としては、事業者側が取得する認証の枠組みを知っておくと、質問すべき事項が整理できます。ISMS（ISO/IEC 27001）の全体像 と ベンダーへのセキュリティチェックシート をご覧ください。責任範囲の切り分けについては 責任分界点の決め方 が対応します。
共有IDをやめられない現場での次善策
ここが本記事の核心です。「共有IDをなくしましょう」は正論ですが、医療現場には共有IDが残る現実的な理由があります。
- 病棟の共用端末で、看護師が数分ごとに入れ替わって使う
- 手術室・救急で、清潔操作中に個人認証ができない
- 夜勤帯に少人数で複数の端末を使う
- 部門の受付端末を複数名が交代で使う
- 電子カルテ以外の部門システムが個人IDに対応していない
これらを「意識が低い」で片づけると対策が進みません。 業務の物理的な制約から生じているためです。したがって現実的な方針は、共有IDを段階的に減らしつつ、残るものについては被害を限定する措置を重ねることになります。
段階的な移行の考え方
| 段階 | 措置 | 効果 |
|---|---|---|
| 1 | 共有IDの全数を把握して台帳化する | どこにリスクがあるか分かる |
| 2 | 共有IDから特権を外す | 奪われても管理操作はできない |
| 3 | 共有IDでできる操作を限定する（参照中心、一括出力不可など） | 被害の上限を下げる |
| 4 | 端末側で誰が使っているかを記録する（ICカード、生体認証、簡易ログイン） | 事後追跡が可能になる |
| 5 | 共有IDのパスワード変更手順と頻度を決める | 退職者が使い続ける状態を防ぐ |
| 6 | 業務単位で置き換え可能なものから個人IDへ移行する | 根本的な解決 |
段階2と3は、共有IDを残したままでも実施できる点が重要です。共有IDそのものを消せなくても、「共有IDでは管理者操作ができない」「共有IDでは一括出力ができない」という状態を作れば、侵入されたときの被害の上限は下がります。
**段階4の「誰が使っているかの記録」は、医療機関で特に有効な打ち手です。ICカードや簡易ログインで操作者を識別できれば、共有IDのまま個人の追跡が可能になります。参照範囲を広めに取らざるを得ない医療機関では、「絞る」より「記録する」**のほうが業務との両立がしやすく、実効性も高いことが多いのです。
なお、パスワードポリシー全般の設計は パスワードポリシーの設計 で、操作記録の設計は ログ管理と監査証跡 で扱います。
制度との接続
2026年度診療報酬改定で新設された電子的診療情報連携体制整備加算は、共通要件として「医療情報システムの安全管理に関するガイドラインへの準拠」と「専任の医療情報システム安全管理責任者の配置」を求めています。加算1（160点）では加えて、複数方式によるバックアップ（一部はオフライン保管）と、サイバー攻撃等に対するBCPの策定・訓練が要件になります。
権限設計はこれらの土台に当たります。とくに、
- バックアップ領域の権限分離は、加算1のバックアップ要件を実質的に成立させる条件
- 安全管理責任者が判断するには、誰がどの権限を持つかの一覧が必要
- BCPの訓練では、緊急時に誰がどの権限で何をするかが決まっていなければ動けない
という接続があります。改定の全体像は 2026年度診療報酬改定の全体像、責任者については 医療情報安全管理責任者の役割と選任 をご覧ください。
まとめ
- 権限は職種ロールを土台に、業務単位の差分を重ね、個別付与は期限付きで最小限にという二層＋例外の構造で設計する
- 最小権限を厳格に適用すべきは、管理者権限・DB直接操作・バックアップ領域・監査ログ削除・権限付与・一括出力の6つ
- バックアップ領域の認証情報は本番環境から分離する。 同一だと、権限が奪われた時点で復旧手段を失う
- 医療は「見せない」ことがリスクになる業務。参照権限は絞るより記録して点検する方向で設計する
- 実効性が最も高いのは棚卸しの仕組み化。異動時は「外してから付ける」。人事システムに載らない非常勤・派遣・委託を取りこぼさない
- ベンダー保守アカウントは個人単位・申請時のみ開放・作業記録・契約終了時の削除報告を契約で定める
- 共有IDは業務上の制約から生じる。特権を外す／操作を限定する／操作者を記録するの3つは、共有IDを残したままでも実施でき、被害の上限を下げる
自院の権限一覧の棚卸しや、ベンダー契約における保守アカウントの条項の整理でお困りの場合は、お問い合わせ からご相談ください。
参考・出典
- 医療情報システムの安全管理に関するガイドライン｜厚生労働省
- 医療情報システムの安全管理に関するガイドライン 第6.0版｜厚生労働省
- 令和8年度診療報酬改定について｜厚生労働省
- 個人情報保護委員会
- 情報処理推進機構（IPA）
※ガイドラインの解釈および算定要件は、厚生労働省の公表資料・通知が正本です。改定により変わり得ますので、最新の一次情報をご確認ください。