Microsoft Entra ID Governance を使う組織が今回の更新からまず読み取るべきことは、EHR（Electronic Health Record、電子健康記録）へのアクセス管理を「一度付与して終わり」にせず、入社・異動・兼務・契約終了・退職までのライフサイクル全体で制御する必要がある、という点です。特に医療機関やヘルスケア企業では、臨床現場のスピードを止めずに、過剰権限・退職者アカウント・監査証跡不足を減らす設計が重要になります。
2026年4月19日にMicrosoft Tech Communityで公開された記事では、Microsoft Entra Identity Governanceを使い、HRなどの信頼できる人事データを起点にJoiner-Mover-Leaverを自動化し、Access Packageでアクセスを管理し、Access Reviewで定期的に再認証する流れが示されています。記事は医療業界向けの文脈ですが、実務上は「高機密データへ誰が、なぜ、いつまでアクセスできるか」を問われるすべての組織に関係します。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft highlights Entra Identity Governance for digital health record access lifecycle control の要点
今回のMicrosoftのメッセージは、単なる製品紹介ではありません。EHRのような業務クリティカルなシステムでは、アクセス権限が細かく、職種・所属・勤務形態・担当患者・委託契約などの条件によって必要な権限が変わります。そのため、手作業のアカウント作成やスプレッドシートによる権限棚卸しでは、運用負荷とリスクが同時に高まります。
Microsoftは、EHRアクセス管理の課題として、クラウドとオンプレミスをまたぐ臨床ワークフロー、監査可能性への要求、そして「必要な臨床担当者に必要なアクセスだけを付与する」ことを挙げています。その解決策として、Microsoft Entra Identity GovernanceによるIDライフサイクル自動化、アプリケーションプロビジョニング、Entitlement Management、Access Reviewsを組み合わせる方向性を示しています。(TECHCOMMUNITY.MICROSOFT.COM)
ここで重要なのは、Entra ID Governanceを「ID管理ツール」として狭く見るのではなく、アクセス権限の発生・変更・期限切れ・削除を制御する安全対策基盤として見ることです。
優先して下げるべきリスクは「アクセスの残り続け」
Microsoft Entra ID Governance の導入で最初に狙うべきリスクは、ゼロデイ攻撃のような派手なものではありません。実務で問題になりやすいのは、退職者・異動者・外部委託先・一時的な支援者のアクセスが、業務上の必要性を失った後も残り続けることです。
Microsoft Learnでは、Microsoft Entra ID Governanceが「誰がどのリソースにアクセスすべきか」「そのアクセスで何をしているか」「管理統制があるか」「監査人が統制の有効性を確認できるか」といった問いに対応するためのソリューションとして説明されています。これは、医療データのような高機密情報に限らず、財務、人事、顧客データ、研究データにも当てはまります。(Microsoft Learn)
| 優先リスク | よくある原因 | Microsoft Entra ID Governanceでの対策 | 優先度 |
|---|---|---|---|
| 退職者・契約終了者のアクセス残存 | HR情報、Active Directory、EHR側アカウントの更新タイミングがずれる | HR連携、API-driven inbound provisioning、Lifecycle Workflows、アプリの自動デプロビジョニング | 最優先 |
| 異動後も旧部門の権限を保持 | 部門変更時にグループやアプリロールを見直していない | Moverイベントで旧Access Packageを削除し、新職務のAccess Packageを割り当てる | 高 |
| EHR権限の過剰付与 | 細かい権限を個別に手動付与している | 職務別Access Package、承認、期限、定期レビューを組み合わせる | 高 |
| 外部委託先・パートナーの放置 | 招待後の有効期限や責任者が不明確 | Entitlement Managementで申請範囲、承認者、期限、外部組織を制御する | 高 |
| 監査証跡の不足 | メール承認やExcel管理が残っている | Access Reviews、プロビジョニングログ、承認履歴を監査証跡として整備する | 高 |
| 緊急対応用アクセスの常態化 | 一時的に広い権限を付けたまま戻していない | 期限付きアクセス、緊急用ロールの別管理、レビュー頻度の引き上げ | 高 |
リスク低減策はこの順番で実施する
信頼できる人事・職務データをアクセス制御の起点にする
最初に整えるべきなのは、Access PackageでもAccess Reviewでもなく、ユーザー属性です。所属、職種、雇用形態、勤務開始日、退職日、契約終了日、勤務地、上長、コストセンターなどの属性が不正確なまま自動化すると、誤った権限が高速に配布されます。
MicrosoftのAPI-driven inbound provisioningは、HRアプリ、給与システム、スプレッドシート、SQLテーブルなどのシステムオブレコードからMicrosoft Entra IDへワークフォースデータを取り込む考え方を示しています。取り込まれたデータは属性マッピングや変換ルールを通じて処理され、その後のJoiner-Mover-Leaverプロセスに利用できます。(Microsoft Learn)
実務では、まず次の属性を棚卸ししてください。
| 属性 | 使い道 | 確認すべきポイント |
|---|---|---|
| employeeId | EHR、HR、Entra ID間の同一人物突合 | 重複、欠番、再雇用時の扱い |
| department / costCenter | 部門別Access Packageの自動割り当て | 組織改編時に値が更新されるか |
| jobTitle / jobCode | 臨床職、事務職、委託先などの権限設計 | 表記ゆれがないか |
| employeeHireDate | 入職前オンボーディング | 入職日前に必要な準備アクセスだけを出せるか |
| employeeLeaveDateTime | 退職・契約終了時の削除 | 退職日当日に無効化されるか |
| manager | 承認者、Access Review担当者 | 上長未設定ユーザーを例外扱いにしていないか |
| userType / employeeType | 職員、契約社員、外部ユーザーの区別 | 外部ユーザーに内部職員相当の権限が付いていないか |
この段階での判断基準は明確です。属性が曖昧なユーザーには、自動で高リスク権限を付けないことです。自動化の前に、属性品質を改善する対象リストを作るだけでも、アクセス管理の事故は減らせます。
Joiner-Mover-Leaverを手続きではなくイベントとして扱う
Joiner-Mover-Leaverは、入社・異動・退職を表すIDガバナンスの基本です。Lifecycle Workflowsは、Joiner、Mover、Leaverの各フェーズでMicrosoft Entraユーザーに対する処理を自動化する機能として説明されています。たとえば、入社日の前に上長へ通知する、退職時にアクセスを削除する、既存のLogic Appsと連携して複雑な処理を拡張するといった使い方ができます。(Microsoft Learn)
医療系システムでは、次のようにイベント単位で設計すると運用しやすくなります。
| イベント | 自動化すべき処理 | 注意点 |
|---|---|---|
| 入職前 | アカウント作成、必要最小限の事前アクセス、上長通知 | 入職前からEHR本番データへ広くアクセスさせない |
| 初日 | 職務に応じたAccess Package割り当て、MFA・利用規約確認 | 初日だけ手作業で例外付与する運用を残さない |
| 部門異動 | 旧部門の権限削除、新部門の権限追加 | 「追加」だけで終わらせると権限が積み上がる |
| 兼務開始 | 期限付きで追加Access Packageを付与 | 兼務終了日が未設定なら承認を必須にする |
| 契約終了 | サインイン無効化、アプリ権限削除、外部ユーザー整理 | 委託先は契約延長時の再承認を必須にする |
| 退職 | アクセス削除、アプリ側デプロビジョニング、監査ログ確認 | 共有アカウント利用があると個人単位の削除が効かない |
特にMover、つまり異動時の設計が弱い組織は多いです。新しい職務に必要な権限を追加するだけで、旧職務の権限を削除しないと、時間の経過とともに「複数部署の情報を見られる人」が増えます。これはアクセスクリープの典型です。
Access PackageでEHR権限を業務ロールに変換する
EHRには、閲覧、更新、オーダー入力、請求、監査、管理、レポート出力など、多数の権限があります。これらを個別に承認していると、承認者は何を許可しているのか理解しにくくなります。
Entitlement Managementでは、Access Packageという単位で、グループ、アプリケーション、Teams、SharePointサイトなど、業務に必要なリソースをまとめて管理できます。Access Packageにはポリシーを設定でき、誰が要求できるか、誰が承認するか、どれくらいの期間アクセスを保持できるかを制御できます。(Microsoft Learn)
EHR向けに考えるなら、技術的な権限名をそのままAccess Package名にしないことが重要です。承認者が判断できる業務語彙に変換します。
| 悪い設計例 | 改善例 | 理由 |
|---|---|---|
| EHR_ROLE_489_READ | 救急外来：患者記録閲覧 | 承認者が業務内容を理解しやすい |
| MED_SYS_ADMIN_FULL | EHR運用管理：期間限定管理者 | 高権限であることと期限が明確になる |
| CER_GROUP_A12 | 請求部門：診療報酬確認 | システム都合ではなく業務目的で判断できる |
| TEMP_ACCESS_ALL | 夜間オンコール：緊急対応アクセス | 一時利用であることを前提にできる |
Access Packageを設計する際は、少なくとも次の項目を決めてください。
| 設計項目 | 実務上の判断基準 |
|---|---|
| 対象者 | 部門、職種、雇用形態、勤務地、外部組織で絞り込む |
| 承認者 | IT部門だけでなく、データオーナーまたは業務責任者を含める |
| 有効期限 | 常時必要な職務か、一時的なプロジェクト・兼務かで分ける |
| 正当化理由 | 高機密データ、外部ユーザー、管理者権限では入力を必須にする |
| レビュー頻度 | 患者データや管理者権限は通常業務システムより短い周期にする |
| 競合制御 | 請求承認と監査、開発と本番管理など、分離すべき権限を洗い出す |
Access Packageは細かく作りすぎても運用が破綻します。目安として、承認者が「この人にこの業務は必要か」を30秒以内に判断できる粒度にすると、レビュー品質が上がります。
Access Reviewsを「棚卸し」ではなく「削除の仕組み」にする
Access Reviewsは、Microsoft Entra IDでグループメンバーシップ、エンタープライズアプリケーションへのアクセス、ロール割り当てを定期的に確認し、適切な人だけが継続アクセスできるようにする機能です。Microsoft Learnでは、過剰なアクセス権が侵害や監査上の指摘につながる可能性があること、週次・月次・四半期・年次などの定期レビューを設定できることが説明されています。(Microsoft Learn)
よくある失敗は、Access Reviewを「監査のための確認作業」として扱い、実際にはアクセス削除につながらないことです。レビュー結果が承認・否認・未回答のまま残るだけでは、リスクは下がりません。
実務では、次のルールを決めてから開始します。
| ルール | 推奨する考え方 |
|---|---|
| レビュー対象 | まずEHR、患者データ、管理者権限、外部ユーザーから始める |
| レビュー担当者 | IT管理者ではなく、業務責任者またはデータオーナーを基本にする |
| 未回答の扱い | 高リスク権限では「未回答なら継続」ではなく、エスカレーションや削除候補にする |
| 否認後の処理 | 否認されたアクセスが自動または確実な運用手順で削除されるようにする |
| 例外管理 | 例外には期限、責任者、理由を必ず残す |
| 証跡 | 誰が、いつ、何を根拠に承認・否認したかを残す |
レビュー頻度は、すべて同じにしない方が現実的です。高リスクなEHR管理者権限や外部委託先アクセスは短い周期、低リスクな一般情報閲覧は長い周期にするなど、リスクベースで調整します。
アプリプロビジョニングでEHRと周辺システムのアカウントを連動させる
Microsoft Entraのアプリプロビジョニングは、アプリケーション内のユーザーIDやロールを自動で作成・保守・削除する仕組みです。Microsoft Learnでは、SCIM、LDAP、SQL、REST、SOAP、PowerShell、Custom ECMA connectorsなどの方式に触れ、ユーザーの参加・変更・離脱に応じてアプリ側のIDを管理できることが説明されています。(Microsoft Learn)
EHR本体だけでなく、周辺システムも対象にしてください。たとえば、診療データ分析、請求、予約、検査、レポート、データ連携基盤などです。EHR本体のアクセスを削除しても、周辺システムに患者データを見られる経路が残っていれば、リスクは下がりません。
導入時は、いきなり全システムを接続しようとせず、次の順で進めると失敗しにくくなります。
| 段階 | やること | 成功条件 |
|---|---|---|
| 既存調査 | EHRと周辺システムのアカウント一覧を取得する | 退職者、休職者、外部ユーザー、共有アカウントを識別できる |
| 突合 | Entra ID、HR、アプリ側アカウントを照合する | 所有者不明アカウントをリスト化できる |
| パイロット | 1部門または1ロールだけで自動プロビジョニングを試す | 作成・変更・削除が想定通り動く |
| 拡張 | 高リスクアプリから順に接続する | 手作業のアカウント変更依頼が減る |
| 監視 | プロビジョニング失敗、遅延、429などを監視する | 失敗時の再実行と責任者が決まっている |
特に注意したいのは、既存環境に残るローカルアカウントです。SSOやプロビジョニングを導入しても、アプリ側に直接作られた管理者アカウントや共有アカウントが残っていると、Entra ID Governanceの統制外になります。
Security teams、compliance leads、platform architectsが分担すべきこと
Microsoft Entra ID Governanceの導入は、セキュリティチームだけで完結しません。アクセスの正当性は業務側が判断し、証跡はコンプライアンス側が求め、設計と接続はプラットフォーム側が担います。
| 役割 | 優先タスク | 成果物 |
|---|---|---|
| Security teams | 高リスクアプリ、特権ロール、外部ユーザー、異常なアクセス残存を洗い出す | リスク別の優先順位表、例外アクセス一覧 |
| Compliance leads | 監査要件、レビュー頻度、証跡要件、承認責任者を定義する | Access Review方針、監査証跡テンプレート |
| Platform architects | HR連携、属性設計、プロビジョニング方式、Access Package構造を設計する | ID属性マッピング、連携アーキテクチャ、運用設計 |
| Application owners | EHR内の権限体系を業務ロールへ翻訳する | 業務ロール一覧、権限マッピング表 |
| Data owners | 誰にアクセスを許可すべきかを最終判断する | 承認ルール、例外承認基準 |
重要なのは、IT部門がすべてのアクセス可否を判断しないことです。ITは仕組みを作れますが、「この職員がこの患者データ領域にアクセスする業務上の必要性があるか」は、業務責任者やデータオーナーが判断すべきです。
すぐ始めるための90日ロードマップ
最初の30日：高リスクアクセスを可視化する
最初の1か月は、設定変更よりも可視化を優先します。対象は全社ではなく、EHRや患者データに近いシステムから始めます。
| タスク | 具体的な作業 |
|---|---|
| 対象アプリを決める | EHR本体、患者データ分析、請求、検査、連携基盤から優先順位を付ける |
| ユーザーを分類する | 職員、契約社員、委託先、外部監査、休職者、退職予定者に分ける |
| 権限を棚卸しする | 高権限、閲覧権限、更新権限、管理者権限、共有アカウントを洗い出す |
| 属性品質を確認する | department、jobCode、manager、leaveDateなどの欠損を確認する |
| リスクを順位付けする | 退職者残存、異動者残存、外部ユーザー、管理者権限から着手する |
この段階のゴールは、完璧な設計図ではありません。「どのアクセスが危ないか」「どこから自動化すべきか」を合意することです。
31〜60日：Access PackageとLifecycle Workflowsを小さく試す
次の段階では、1つの部門または1つの業務ロールを選び、Access PackageとLifecycle Workflowsを組み合わせます。
たとえば「救急外来の臨床担当者」というロールを選ぶ場合、必要なEHR権限、関連グループ、承認者、有効期限、レビュー頻度を定義します。入職時には必要なアクセスを付与し、異動時には旧ロールを削除し、退職時にはアクセスを削除する流れをテストします。
この段階で見るべき指標は、次の通りです。
| 指標 | 見るべき変化 |
|---|---|
| 手動申請件数 | Access Package化により減っているか |
| 承認にかかる時間 | 業務に支障がない範囲で短縮しているか |
| 異動後の旧権限 | 追加だけでなく削除も実行されているか |
| プロビジョニング失敗 | 属性不備や接続エラーの原因を特定できているか |
| 例外アクセス | 期限と責任者が設定されているか |
61〜90日：レビューと自動削除を運用に組み込む
最後の30日では、Access Reviewsを設定し、レビュー結果がアクセス削除につながる運用にします。ここで「レビューしたが何も変わらない」状態を避ける必要があります。
高リスクアクセスについては、レビュー完了率だけでなく、否認後に本当に削除されたか、未回答が放置されていないかを確認します。監査向けには、承認者、理由、期限、削除結果を追跡できる状態にします。
導入時に失敗しやすいポイント
| 失敗パターン | 何が起きるか | 回避策 |
|---|---|---|
| 属性品質を確認せず自動化する | 誤った部門や職種に基づいて権限が付く | 高リスク権限の自動付与前に属性欠損リストを解消する |
| Access Packageを細かく作りすぎる | 承認者が内容を理解できず、形式承認になる | 業務ロール単位でまとめ、技術権限は裏側に隠す |
| IT部門だけで承認する | 業務上の必要性を判断できない | データオーナー、部門責任者、アプリ所有者を承認に入れる |
| Access Reviewを年1回だけにする | 高リスク権限の残存期間が長くなる | 患者データ、外部ユーザー、管理者権限は短い周期で見直す |
| 否認後の削除が手作業のまま | レビュー結果がリスク低減につながらない | 否認後の自動削除または明確な運用手順を設定する |
| 緊急アクセスに期限がない | 一時的な強権限が恒久化する | 緊急用Access Packageに期限、理由、事後レビューを必須化する |
| 周辺システムを見落とす | EHR以外の経路からデータへアクセスできる | レポート、連携、検査、請求などの関連アプリも対象にする |
| 共有アカウントを残す | 個人単位の監査と削除ができない | 共有アカウントを例外台帳に載せ、廃止計画を作る |
グローバル組織で考えるべき追加論点
グローバルに医療・ヘルスケア関連システムを運用する場合、国や地域ごとに医療情報、個人情報、監査、データ保管に関する要件が異なります。そのため、Microsoft Entra ID Governanceの設定だけで法令対応が完了すると考えるのは危険です。
実務では、次のように「共通統制」と「地域別要件」を分けて設計します。
| 項目 | 共通化しやすいもの | 地域別に調整すべきもの |
|---|---|---|
| IDライフサイクル | 入職・異動・退職時の基本処理 | 退職時の猶予期間、契約終了時の処理 |
| Access Package | 職務別ロール、承認フローの基本形 | 地域固有の医療制度や業務分掌 |
| Access Review | 高リスク権限の定期レビュー | レビュー周期、証跡保管期間 |
| ログ管理 | 誰が何を承認したかの記録 | ログ保管場所、越境移転の制約 |
| 外部ユーザー | 期限付きアクセス、スポンサー管理 | 委託契約、データ処理契約、地域規制 |
特に多国籍企業では、グローバル標準を作ったうえで、各地域の法務・コンプライアンス担当者が例外条件を定義する形が現実的です。プラットフォーム側だけで地域要件を解釈しすぎないようにしてください。
効果測定は「設定した数」ではなく「残存リスク」で見る
Microsoft Entra ID Governanceの導入効果を測るとき、「Access Packageを何個作ったか」「レビューを何回実施したか」だけでは不十分です。見るべきなのは、危険なアクセスがどれだけ減ったかです。
| 指標 | 意味 | 改善の方向 |
|---|---|---|
| 退職後アクセス残存時間 | 退職・契約終了からアクセス削除までの時間 | 短くする |
| 異動後の旧権限保持率 | Mover後も旧部門権限が残っている割合 | 下げる |
| 外部ユーザーの期限未設定率 | 委託先・パートナーアクセスに期限がない割合 | 下げる |
| 高権限Access Packageのレビュー完了率 | 管理者・高機密アクセスが定期確認されているか | 上げる |
| 否認後の削除完了率 | レビュー結果が実際の削除につながった割合 | 上げる |
| 所有者不明アカウント数 | 誰の責任か分からないアカウント | 下げる |
| 手動権限変更件数 | 例外運用や個別依頼の多さ | 下げる |
| プロビジョニング失敗率 | 自動化の信頼性 | 下げる |
これらの指標は、Security teams、compliance leads、platform architectsが同じ状況認識を持つためにも有効です。セキュリティはリスク低減、コンプライアンスは証跡、アーキテクトは自動化の安定性を確認できます。
まとめ：まずは高リスクな1アプリからライフサイクル制御を始める
Microsoft highlights Entra Identity Governance for digital health record access lifecycle control の文脈で重要なのは、EHRアクセスを単なるアカウント管理ではなく、業務ロール、承認、有効期限、棚卸し、削除まで含むライフサイクルとして扱うことです。
最初にやるべきことは、全社一括導入ではありません。EHRや患者データに近い高リスクな1アプリを選び、次の順番で進めることです。
- HR・職務属性の品質を確認する
- 退職者、異動者、外部ユーザー、高権限ユーザーを洗い出す
- 業務ロール単位でAccess Packageを設計する
- Joiner-Mover-LeaverをLifecycle Workflowsで自動化する
- Access Reviewsで継続アクセスを確認し、不要な権限を削除する
- アプリプロビジョニングでEHRと周辺システムのアカウントを連動させる
Microsoft Entra ID Governanceの価値は、アクセスを増やすことではなく、必要な人に必要な期間だけアクセスを与え、不要になったら確実に消すことにあります。まずは最も監査指摘や情報漏えいの影響が大きいアクセスから、ライフサイクル制御を実装してください。
コメント