医療機関のクラウド活用が進む一方で、オンプレミス環境も残るハイブリッド構成では、どこからでも安全に電子カルテやSaaSへアクセスさせる仕組み作りが課題になります。本記事では、Zero TrustをMicrosoft Entra IDと関連サービスで実装する具体的な方法を解説します。
医療機関ハイブリッド環境におけるZero Trustの前提
想定する環境は次のような病院です。
- オンプレミス Active Directory（AD）と Microsoft Entra ID をハイブリッド運用
- 医師・看護師・コメディカル・事務職が、院内・自宅・出張先から以下を利用
- Teams や Exchange Online などの Microsoft 365
- Epic などの電子カルテ／オーダリング（オンプレ Web アプリ）
- その他のSaaS（画像共有サービス、クラウドストレージなど）
- 端末は Intune 管理済みデバイスと未管理デバイスが混在
- 一部オンプレアプリは Application Proxy で公開予定、残りはまだVPN経由
- Entra ID の条件付きアクセスは既に運用中
- Defender for Endpoint / Microsoft Sentinel は評価中
このような環境で目指すのは、次の3点を同時に満たすZero Trust構成です。
- 患者データの保護：電子カルテ・検査結果・画像データなど高機密情報を扱うため、漏えいリスクを極小化する
- リアルタイムなリスクベースアクセス：ユーザーやデバイスの状態変化を即座にポリシーへ反映し、怪しい挙動を自動で抑止
- 診療業務の継続性：夜間・救急・当直など時間を問わない現場で、セキュリティが診療の妨げにならないこと
Zero Trust原則を医療システムに当てはめる
Zero Trustは「ネットワーク内だから安全」という前提を捨て、すべてのアクセスを常に検証する考え方です。Microsoftが整理している3つの原則に沿って、病院システムへ当てはめてみます。
- 明示的に検証する（Verify explicitly）
ユーザー、デバイス、場所、アプリ、データのラベル、リスクシグナルを総合的に見てアクセスを判断します。
→ 例：院内LANからのアクセスでも、共有端末 + 未ログインユーザーであれば電子カルテ画面へのアクセスをブロックする。 - 最小特権アクセス（Least privilege access）
必要最低限の権限だけを付与し、時間・デバイス・操作内容を絞ります。
→ 例：外部委託業者は、院外からのアクセス時は特定アプリの閲覧のみに制限し、ダウンロードやコピーを禁止する。 - 侵害を前提とする（Assume breach）
どこかは既に侵害されているかもしれない、という前提で、検知・分断・復旧を設計します。
→ 例：1つのアカウントが侵害されても、CAE（Continuous Access Evaluation）と条件付きアクセスでトークンを即失効し、被害範囲を最小化する。
全体アーキテクチャ：Entra IDを中心にしたZero Trust構成
ここでは、Microsoft Entra ID をアイデンティティの中枢に据え、オンライン・オンプレ問わずアプリへのアクセスを制御する構成をイメージします。
| コンポーネント | 主な役割 | Zero Trust観点でのポイント |
|---|---|---|
| オンプレAD + Entra ID (ハイブリッド) | ユーザー・グループのID基盤 | 医師・看護師・委託業者・システムアカウントなど、役割に応じたグループ設計と属性（部署・職種・勤務形態）を整備 |
| Entra ID 条件付きアクセス | アイデンティティベースのアクセス制御 | ユーザー／サインインリスク、デバイス準拠性、場所、アプリ単位でポリシーを定義 |
| Continuous Access Evaluation (CAE) | トークン有効期間中もリアルタイムに再評価 | ユーザーのリスク上昇・パスワード変更・ネットワーク急変などを即座に反映し、追加認証やブロックにつなげる |
| Defender for Cloud Apps（CASB） | SaaS / Webアプリのセッション制御 | 未管理端末からのダウンロード遮断、アップロード制御、クリップボード制御、シャドーITの発見とブロック |
| Application Proxy | オンプレWebアプリの安全な公開 | VPNなしで電子カルテなどをEntra ID配下に置き、条件付きアクセス＆セッション制御を適用 |
| Intune | デバイス管理・準拠性評価 | OSバージョン、暗号化、ウイルス対策、Jailbreak検知などを条件付きアクセスの「準拠デバイス」判定に連携 |
| Defender for Endpoint | エンドポイント保護・EDR | 端末リスクレベルを条件付きアクセスへ渡し、「リスク高」端末からのアクセスを自動ブロック／限定 |
| Microsoft Sentinel | SIEM / SOAR | サインインログ、CAログ、CASBログを統合分析し、異常行動を早期検知。自動レスポンスでポリシー強化も可能 |
Entra ID と条件付きアクセスでアクセスの「入り口」を固める
役割ごとのグルーピングとポリシーの基礎設計
条件付きアクセスをうまく使うためには、ユーザーを役割とリスクで整理することが重要です。
| 役割 | 例 | アクセス特性 | ポリシー設計の方向性 |
|---|---|---|---|
| 診療スタッフ（医師・看護師） | 常勤医、非常勤医、病棟看護師、外来看護師 | 24時間・院内外から電子カルテ・Teams・検査系システムへアクセス | 管理端末前提でフル機能許可。未管理端末はブラウザー閲覧＋ダウンロード禁止など制限付き |
| コメディカル | 検査技師、リハビリ、薬剤師など | 特定の業務アプリと電子カルテへのアクセス | アプリ単位でアクセス可能範囲を明確化し、不要なSaaS利用をCASBで制御 |
| 事務・経営企画 | 医事課、総務、人事、経営企画 | Office系ファイル、BIツール、メール中心 | 院外アクセスは原則MFA必須。高機密データへのアクセスはデバイス準拠性を必須化 |
| 外部委託・ベンダー | システム保守、清掃・警備、研究協力機関 | 限定的なアプリのみ。多くは院外から接続 | Just-In-Timeな権限付与、時間帯制限、IP制限、セッション制御で厳格に管理 |
Entra IDでは、これらを「職種」「所属」「業務アプリ」「デバイス条件」と組み合わせたグループに分け、そのグループ単位で条件付きアクセスを適用するのが運用しやすいパターンです。
管理端末・未管理端末・共有端末ごとの推奨ポリシー
特に医療現場では、ナースステーションの共有PCや、検査室のワークステーションなど「誰が使っているか分かりにくい」端末が多く存在します。これを単純に「院内＝安全」と扱うと、内部不正やなりすましのリスクが高まります。
| 端末種別 | 想定例 | 条件付きアクセス例 | ユーザー体験 |
|---|---|---|---|
| Intune管理端末（個人割当） | 医師のノートPC、リモート診療用PC | MFA + 準拠デバイス必須 全アプリへのフルアクセス許可 高リスクサインイン時はブロック | 日常利用ではシングルサインオン、リスク上昇時のみ追加MFA |
| 共有端末（院内、Intune未管理） | ナースステーションPC、処置室PC | 院内IPからのみアクセス許可 電子カルテ・検査系など一部アプリのみ許可 一定時間操作がない場合は必ず再認証を要求 | 短時間ごとの再認証は発生するが、アプリを絞ることで負荷を軽減 |
| 未管理端末（自宅PC・個人スマホ） | 在宅当直医の自宅PC、BYODスマホ | MFA必須 ブラウザー経由アクセスのみ許可 Defender for Cloud Appsでダウンロード・印刷・コピーを制御 | ブラウザー上での閲覧は可能だが、ファイル保存やコピーは制限 |
緊急用「ブレイクグラス」アカウントの設計
医療機関で忘れがちなのが、障害時でも診療を止めないためのバックアップ手段です。条件付きアクセスの設定ミスなどで全ユーザーがサインインできなくなった場合、誰もポリシーを修正できず、診療継続に支障が出る可能性があります。
対策として、以下のような「ブレイクグラス」アカウントを設計します。
- 通常運用では使用しない、強力なパスワードのクラウド専用アカウントを2つ以上用意
- 条件付きアクセスの対象外にするが、サインイン監査を必ず確認できるようにする
- 利用方法・連絡フロー・保管場所を文書化し、定期的にテストする
- 日本の医療情報ガイドラインに沿って、操作ログが確実に残るように設定
ブレイクグラスは「絶対に使ってはいけないアカウント」ではなく、「本当に困った時だけ使ってよいアカウント」です。存在を隠しすぎると、いざというとき誰も使えないため、適切なバランスが必要です。
Continuous Access Evaluation（CAE）でリスク変化を即反映
従来のアクセストークンは、有効期限内であれば原則として有効でした。例えば、1時間有効なトークンを発行した場合、その1時間の間にアカウントが侵害されても、トークン自体は無効にならないケースがありました。
Continuous Access Evaluation（CAE）を有効にすると、次のようなイベント発生時に、トークンを即時無効化し、再認証を要求できます。
- ユーザーのパスワードリセットやアカウント無効化
- ユーザーのサインインリスクが急上昇したとき
- 信頼できない場所からの急激なアクセス元変更（例：国内から数分で海外のIPへ移動）
- 条件付きアクセスポリシーの変更
医療現場でのCAE活用シナリオ
- なりすまし検知時の即時遮断
SentinelやDefenderからのシグナルで「不審なサインイン」が検知された場合、CAEによりTeamsやSharePointのトークンを即失効し、そのユーザーに再MFAを求めます。 - シフト交代時の安全性向上
共有端末で別のユーザーがログインしたタイミングで、前のユーザーのセッションを無効化し、誤って他人のアカウントで操作されるリスクを減らします。 - 高リスクネットワークからのアクセス制御
公衆Wi-Fiなど、事前にリスクが高いと判定しているIPレンジからのアクセスが発生した際、CAE連携で即ブロックや追加MFAを発動します。
CAE導入時の設計ポイント
- まずは Teams / Exchange / SharePoint / Defender for Cloud Apps など、CAE対応アプリから段階導入する
- 再認証がどのタイミングで発生するかを業務フローと合わせて検証し、夜間当直や手術中など業務への影響ポイントを洗い出す
- Epicなどの業務アプリ側のセッションタイムアウト設定と、CAEによる再認証タイミングを調整し、二重にユーザーを追い出さないようにする
Defender for Cloud Appsでセッション制御とシャドーIT対策
Defender for Cloud Apps（旧Cloud App Security）は、SaaS／オンプレWebアプリのセッションをリアルタイムに監視・制御できるCASB製品です。条件付きアクセスと連携することで、「未管理デバイスからはダウンロード禁止」「アップロード時に自動でラベル付与」など、きめ細かい制御が可能になります。
Conditional Access App Controlの基本パターン
条件付きアクセスの制御として「アクセスのブロック／許可」に加え、「セッションを制御する」という選択肢を使うと、Defender for Cloud Appsの制御に切り替えられます。代表的なシナリオを表にまとめます。
| シナリオ | ポリシー例 | ユーザー体験 |
|---|---|---|
| 未管理端末から電子カルテ（Epic）を閲覧 | 条件付きアクセスで「セッション制御（監視）」を選択 Defender for Cloud Apps側で「ダウンロード禁止」「印刷禁止」「クリップボード禁止」を設定 | 画面閲覧は可能だが、ローカル保存や印刷は不可。必要に応じて透かし表示も付与 |
| 外部クラウドストレージへの機密データアップロード | シャドーITとして検出したアプリをリスクレベルに応じてブロック 許可アプリでも、特定のラベル付きファイルのアップロードを禁止 | 業務で認められたクラウドストレージ以外へのアップロードが自動で止まる |
| 研究用クラウドサービスの利用 | 研究部門のみ特定SaaSを許可 利用ログを詳しく残し、機密ラベル付きデータはアップロード禁止 | 研究者は必要なサービスを利用できるが、医療情報ガイドラインに反する利用は自動で抑制 |
EpicをApplication Proxy経由で公開し、セッション制御を適用する
Epicのようなオンプレの電子カルテをインターネット経由で利用する場合、従来はVPNが前提でした。しかしZero Trustの考え方では、VPNで「ネットワーク丸ごと」開けるのではなく、Application Proxyで「アプリ単位」に公開し、Entra ID による認証・認可を通すのが望ましい設計です。
構成イメージは次の通りです。
- EpicをApplication Proxyで公開し、公開URLと内部URLを紐づける
- 公開エンドポイントへのアクセスをEntra IDで認証し、条件付きアクセスを適用
- 未管理デバイスや外部からのアクセスは、Conditional Access App ControlでDefender for Cloud Appsへ転送
- Defender for Cloud Appsで、ダウンロード・印刷・クリップボード・アップロード制御をポリシー化
こうすることで、「院内から管理端末でアクセスする医師はフル機能利用」「自宅の未管理端末から当直対応する医師は閲覧のみ」といった柔軟な体験を実現できます。
Application ProxyでオンプレアプリをZero Trust化する
Application Proxyは、オンプレWebアプリを安全にインターネットへ公開するためのゲートウェイです。ポイントは、外向きの接続のみで完結するため、オンプレ環境に新たな受信ポートを開ける必要がないことです。
Zero Trust観点のメリットは次の通りです。
- オンプレアプリもEntra IDの傘下に入り、条件付きアクセスやCAEの対象にできる
- VPN不要のため、ネットワークレベルではなくアプリレベルでアクセス制御できる
- Defender for Cloud Apps と組み合わせてセッション制御やDLPを適用できる
Epic以外にも、検査結果閲覧システム、各種ポータル、レポート閲覧ツールなど、WebベースのオンプレアプリはできるだけApplication Proxy配下に集約していくと、ポリシー統一と運用負荷軽減につながります。
Defender for Endpoint と Sentinel の連携による高度なリスクベースアクセス
Defender for Endpoint と Sentinelは必須ではありませんが、導入するとZero Trustを「継続的に最適化する」段階へ進めます。
Defender for Endpointのリスクシグナルを条件付きアクセスへ
- Defender for Endpointでマルウェア検出・疑わしいプロセス・不審な挙動が検知された端末を「リスク高」と評価
- 条件付きアクセスで「デバイスリスクが高」の場合は、電子カルテやメールへのアクセスをブロックまたは制限
- リスクが解消される（調査・修復完了）と、自動的にアクセス制限も解除
これにより、例えば「医師のノートPCが出張先でマルウェアに感染した」ような場合でも、その端末から患者データへアクセスさせない安全弁を用意できます。
Sentinelによる統合監視と自動対応
SentinelにEntra IDサインインログ、条件付きアクセスログ、Defender for Cloud Appsログ、Defender for Endpointログを集約すると、次のような分析・自動対応が可能になります。
- 1つのアカウントで短時間に複数の国からサインイン試行があれば、自動で強制パスワードリセット＋トークン失効
- 特定の電子カルテ画面へのアクセスが通常よりも急増した場合、不正閲覧の可能性をアラート
- 研究部門から深夜帯に大量のファイルがクラウドストレージへアップロードされていれば、DLPポリシーを一時的に厳格化
これらを自動化することで、セキュリティ担当者の負荷を下げつつ、ゼロトラストの「継続的な評価」を実現できます。
実装ロードマップ：診療業務を止めない段階的導入
ここからは、実際にどの順序で導入していくと安全かつ現実的かを整理します。
ステップ1：資産分類（ユーザー・デバイス・アプリ）
- ユーザーを職種・部署・雇用形態（常勤／非常勤／委託）で分類
- デバイスを「Intune管理」「共有端末」「未管理端末」に分類
- アプリを「電子カルテ」「検査系」「メール・コラボ」「研究用」「事務系」に分類し、機密度を評価
| アプリ分類 | 機密度 | 例 | 最初に保護すべきか |
|---|---|---|---|
| 電子カルテ・オーダリング | 非常に高い | Epic、診療支援ポータル | 最優先 |
| 検査結果閲覧・画像ビューア | 高い | PACSビューア、検査結果Web | 優先 |
| メール・コラボレーション | 中〜高 | Exchange Online、Teams | 早期にZero Trust化 |
| 事務・経営系システム | 中 | 会計、購買、勤怠など | 段階的 |
| 研究用SaaS | 変動 | 統計解析クラウドなど | CASBでの可視化とルール化が重要 |
ステップ2：条件付きアクセスの雛形を作り、影響を限定しながら適用
いきなり全ユーザー・全アプリに厳しいポリシーをかけるのは危険です。まずは「監査モード」や限定的なスコープで挙動を確認しながら導入します。
- 高リスクサインイン時にブロックするポリシー（ユーザーリスクが高い場合のサインイン拒否）
- 管理者アカウントに対する強制MFAポリシー
- 電子カルテやTeamsなど重要アプリに対する「管理端末必須」ポリシー
- 未管理端末に対する「ブラウザー経由 ＋ セッション制御」ポリシー
最初は特定部署（情報システム部、セキュリティチーム、ITリテラシーの高い診療科など）に限定して適用し、現場の声をフィードバックしながらルールを調整します。
ステップ3：CAEの有効化と再認証頻度の調整
- CAE対応アプリ（Teams / SharePoint / Exchange Online / Defender for Cloud Appsなど）から有効化
- セッションタイムアウトと再認証間隔を、外来・入院・救急などの業務フローと突き合わせる
- 「想定しないタイミングで急にログアウトされる」ケースが出ないよう、検証環境やパイロット部署でのテストを十分に行う
ステップ4：Defender for Cloud Appsで未管理端末のダウンロード制御
- まずは「監視のみ」で導入し、誰がどのクラウドサービスを使っているか可視化
- 医療情報ガイドラインに明確に反するサービス（個人向けクラウドストレージなど）を段階的にブロック
- 電子カルテやTeamsなどの重要アプリに対して、「未管理端末はダウンロード禁止・印刷禁止・クリップボード禁止」を段階導入
ステップ5：Application ProxyでEpicなどをVPNから切り離す
- 最初は閲覧専用のサブ機能からApplication Proxy配下へ移行し、パフォーマンスと安定性を評価
- 徐々に主要機能を移行し、最終的にはVPN依存のアクセスを削減
- Epic側の認証タイムアウトとEntra ID側のセッション設定の整合性を取りつつ、CAEや条件付きアクセスと組み合わせて運用
ステップ6：ログ統合と運用モニタリング
- Entra IDのサインインログ・監査ログ、条件付きアクセスログ、Defender for Cloud AppsログをLog AnalyticsやSentinelへ集約
- 定期的なダッシュボード（週次レポートなど）で、「どのポリシーがどの程度ブロックを発生させているか」を可視化
- ブロック件数が多いポリシーは、運用フローと合っているかを現場と一緒にレビューし、調整
ステップ7：Defender for Endpoint連携とアダプティブ保護への拡張
ある程度基盤が整った段階で、Defender for Endpointやアダプティブ保護（ユーザーの行動パターンに応じて自動的にポリシーを強化する仕組み）を導入すると、ゼロトラストをさらに高度化できます。
- 高リスク端末からのアクセス制限を自動化
- 「不審なデータ移動」が検知されたユーザーに対して、一時的にセッション制御を厳格化
- リスクが解消されると自動で元のポリシーへ戻すことで、ユーザー体験をなるべく損なわない
日本の医療機関向け特有の注意点
医療情報ガイドラインへの対応
日本の「医療情報システムの安全管理に関するガイドライン」では、アクセス制御や持ち出し制限、ログ保管などについて厳格な要件が定められています。Zero Trust構成で特に重要となるのは以下の点です。
- 持ち出し制限：未管理端末へのダウンロード禁止、印刷制御、クリップボード制御をDefender for Cloud Appsで実現
- アクセスログ・操作ログの長期保管：Entra IDサインインログ、CASBログ、重要アプリの監査ログを2年以上保管できるようストレージ設計を行う
- アクセス権限の定期レビュー：職種変更や部署異動時に自動でグループが更新されるよう、ID管理プロセスを整備
緊急医療時の業務継続性とセキュリティの両立
救急や災害医療など、秒単位の判断が求められる現場では、「MFAを要求したせいで診療が遅れた」といった事態は避けなければなりません。一方で、「緊急だから全部フリーにする」のも危険です。
現実的な落としどころとしては、次のような設計が考えられます。
- 院内の特定ネットワーク（ER・手術室）からのアクセスには、例外的にMFAを要求しない代わりに、IP制限と端末制限を厳格にする
- 特定の電子カルテ機能については、緊急時に限り、ブレイクグラスアカウントでの操作を許可し、その際の操作ログを必ずレビューする
- 「緊急操作時の連絡フロー」をマニュアル化し、訓練時に条件付きアクセスの挙動も確認しておく
利用者教育と「なぜこうなっているのか」の共有
Zero Trust構成は、どうしてもユーザーにとっては「面倒」「制限が多い」と感じられがちです。医療現場で受け入れてもらうには、次の工夫が有効です。
- 医療安全や個人情報保護の観点から、具体的なインシデント例を示し、「なぜこの制限が必要なのか」を説明する
- 条件付きアクセス導入前後での操作手順の差分を分かりやすくまとめたチートシートを配布する
- 夜間当直や休日診療時でも連絡できるサポート窓口と手順を整備し、「困ったときにすぐ相談できる」安心感を提供する
よくある失敗パターンと回避策
一気にポリシーを厳しくしすぎる
典型的な失敗は、「セキュリティ強化のタイミングで一気に厳しいポリシーを全院へ適用し、大量の業務障害を発生させる」パターンです。回避するには：
- 必ずスコープを絞ったパイロット導入を行う
- 「テスト用ポリシー」と「本番ポリシー」を分けて設計し、影響を把握してから本番適用する
- 導入直後は24時間体制に近いサポート体制を用意し、現場の声を素早く反映する
「院内ネットワーク＝信頼できる」と決め打ちしてしまう
院内ネットワークを「完全に信頼できるゾーン」とみなしてしまうと、内部不正や侵害済み端末からのアクセスを見逃すリスクが高まります。Zero Trustでは、院内であっても次のような制御が重要です。
- 共有端末は必ずユーザーごとにサインインさせる（共有アカウントを使わない）
- 重要な操作（大量データのエクスポートなど）には追加認証を要求する
- 端末自体の準拠性（パッチ・アンチウイルス・暗号化）を常に監査し、準拠していない端末からのアクセスを制限
ログは溜めているが、誰も見ていない
最後によくあるのが、「ログはきちんと保存しているが、実際には誰も見ておらず、事故が起きてから遡るだけ」という状況です。これでは、Zero Trustの「継続的な評価・改善」が実現できません。
- 週次・月次で確認するダッシュボードをあらかじめ決めておき、定例会議でレビューする
- しきい値を超えたイベント（ブロック件数急増、不審な地域からのアクセスなど）については、自動アラートを設定
- インシデント・ヒヤリハット事例を、ポリシー改善につなげるプロセスを整備する
まとめ：Zero Trustで「安全かつ止まらない医療」を実現する
病院のハイブリッド環境でZero Trustを実現するには、単に多要素認証を入れるだけでは不十分です。Entra ID と条件付きアクセスを軸に、CAEでリアルタイムにリスク変化を反映し、Defender for Cloud AppsやApplication Proxyでアプリ単位の制御を行うことで、初めて「どこからでも安全に使える」環境が整います。
重要なのは、「すべてを一気に完璧にしようとしない」ことです。まずは資産分類と条件付きアクセスの雛形作成から始め、CAE・CASB・Application Proxy・Defender for Endpoint・Sentinelへと段階的に拡張していくことで、診療を止めることなくZero Trustを実装していけます。
本記事で紹介した考え方と設計パターンをベースに、自院の業務フローや医療情報ガイドラインの要件に合わせてカスタマイズし、「安全で止まらない医療情報システム」を構築していきましょう。
コメント