Microsoft Entra ID Governance を使った高リスク記録アクセス管理で、規制業種が学ぶべきポイントは明確です。「誰に、いつ、どの記録システムへのアクセスを与え、いつ外し、誰が承認し、後から監査で説明できるか」までを、手作業ではなくライフサイクルとして設計することです。
2026年4月19日に Microsoft は、医療機関の電子健康記録、いわゆる EHR へのアクセス管理を題材に、Microsoft Entra ID Governance によるデジタルヘルス記録ガバナンスの考え方を示しました。対象は医療ですが、そこから得られる教訓は、金融、公共、製薬、保険、法務、研究機関など、機密性の高い記録を扱う規制業種にもそのまま応用できます。(TECHCOMMUNITY.MICROSOFT.COM)
この記事では、Microsoft Entra ID Governance の最新動向を踏まえ、高リスク記録アクセスを「監査に耐えるIDワークフロー」として設計するための考え方、導入手順、失敗しやすいポイントを実務目線で整理します。
Microsoft Entra ID Governance の最新動向から見る高リスク記録アクセス管理の本質
Microsoft が取り上げたテーマは、医師や看護師などの臨床スタッフが、必要なタイミングで必要な EHR にアクセスできるようにしながら、過剰権限や退職者・異動者の残存アクセスを防ぐことです。
Microsoft の記事では、Epic、Oracle Health(Cerner)、Meditech などの EHR システムが例示され、Microsoft Entra ID Governance を使って、HR データ、プロビジョニング、ライフサイクルワークフロー、エンタイトルメント管理、アクセスレビューをつなぐパターンが説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
ここで重要なのは、EHR そのものの機能比較ではありません。規制業種にとっての本質は、次のようなアクセス管理の型です。
| 観点 | 従来のありがちな運用 | Entra ID Governance で目指す運用 |
|---|---|---|
| アカウント作成 | 申請メールやチケットで手動対応 | HR・職員マスターなどの権威データを起点に自動化 |
| 権限付与 | 個別システムごとに担当者が判断 | ロールや業務単位のアクセスパッケージで標準化 |
| 異動時の変更 | 旧権限が残りやすい | 属性変更に応じてアクセスを追加・削除 |
| 退職・契約終了 | アカウント停止漏れが発生しやすい | ライフサイクルワークフローで無効化・削除を自動化 |
| 定期確認 | Excel やメールで棚卸し | アクセスレビューで承認・否認・証跡を管理 |
| 監査対応 | 「誰が承認したか」を後から探す | 承認、期限、レビュー結果を説明しやすい形で残す |
高リスク記録アクセスでは、「ログインできるか」だけでは不十分です。なぜその人がその記録にアクセスできるのか、今も必要なのか、誰が確認したのかまで説明できなければ、ガバナンスとしては弱い状態です。
規制業種が抱えるアクセス管理の典型的な問題
医療の EHR だけでなく、規制業種では次のような記録が高リスク領域になります。
- 患者記録、診療情報、処方情報
- 金融機関の顧客情報、取引履歴、与信情報
- 保険の契約情報、査定情報、請求情報
- 行政機関の住民情報、税務情報、福祉情報
- 製薬・研究機関の臨床試験データ、研究データ
- 法務・監査部門の訴訟資料、調査記録
これらの情報に対して、よく起きる問題は共通しています。
「必要な人に早く出す」と「不要な人から確実に外す」が両立しにくい
現場はスピードを求めます。たとえば医療現場では、担当チームに入った臨床スタッフがすぐに記録を確認できなければ業務に支障が出ます。一方で、異動・退職・委託終了後もアクセスが残ると、情報漏えいや監査指摘のリスクが高まります。
この両立を人手だけで行うと、どうしても属人的になります。申請者、承認者、ID管理者、システム管理者の間で情報がずれ、棚卸し時に「なぜこの権限があるのか分からない」という状態になりがちです。
業務ロールとシステム権限が一致していない
現場では「救急外来看護師」「循環器内科医」「請求担当」「外部監査人」のような業務ロールで会話します。しかしシステム側では、グループ、アプリロール、属性、個別権限、部門コードなどに分解されます。
この変換を毎回手作業で行うと、似たような職務なのに権限が違う、同じ人に重複した権限がある、例外対応が増えすぎる、といった問題が起きます。
監査で説明できる証跡が分散している
監査や内部統制では、「アクセス権があること」よりも、「アクセス権が適切に管理されていること」を示す必要があります。
しかし実際には、承認はメール、作業履歴はチケット、アカウント状態は各システム、棚卸し結果は Excel というように証跡が分散していることがあります。この状態では、監査対応に時間がかかるだけでなく、統制の実効性を示しにくくなります。
Entra ID Governance のパターンは「アクセスの一生」を管理する考え方
Microsoft Entra ID Governance は、組織が生産性、セキュリティ、コンプライアンス要件を満たしやすくするための ID ガバナンスソリューションとして位置付けられています。Microsoft Learn では、オンプレミスとクラウドのアプリケーションをまたいで、「どの ID がどのリソースにアクセスすべきか」「そのアクセスで何をしているか」「管理統制があるか」「監査人が統制の有効性を確認できるか」といった問いに対応する機能群として説明されています。(Microsoft Learn)
高リスク記録アクセスでは、この考え方を次の5つの層で設計すると分かりやすくなります。
| 層 | 目的 | Entra ID Governance で使う主な考え方 |
|---|---|---|
| 権威データ | 誰が組織に属し、どの役割かを定義する | HR データ、職員マスター、契約者情報、API-driven inbound provisioning |
| ID ライフサイクル | 入社・異動・退職に合わせて ID を管理する | Lifecycle Workflows、joiner-mover-leaver |
| アプリ連携 | 各記録システムにアカウントや属性を反映する | 自動アプリプロビジョニング、SCIM、LDAP、SQL、REST など |
| アクセス付与 | 業務ロールに必要な権限をまとめて管理する | Entitlement Management、Access Package |
| 継続確認 | 権限が今も必要かを定期的に確認する | Access Reviews、再認証、期限付きアクセス |
この5層をつなげることで、アクセス管理は単なる「申請処理」ではなく、「採用から退職までの継続的な統制」に変わります。
権威データを起点にしなければ、アクセス制御は破綻しやすい
高リスク記録アクセスの最初の設計ポイントは、何を正とするかです。
Microsoft の記事では、プロビジョニングは権威あるソースから始まると説明されています。HR システムだけでなく、資格管理システム、給与システム、スプレッドシート、フラットファイル、SQL テーブルなど、さまざまな記録システムから Microsoft Entra ID へデータを取り込む考え方が示されています。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Learn の API-driven inbound provisioning でも、企業には複数の権威システムがあり、HR アプリ、給与アプリ、スプレッドシート、SQL テーブルなどの workforce data を Microsoft Entra ID と同期する必要があると説明されています。API-driven inbound provisioning では、任意の自動化ツールを使って権威データを取り込み、属性マッピングで処理を制御できます。(Microsoft Learn)
実務では、次のように整理します。
| データ項目 | 高リスクアクセスでの使い道 | 注意点 |
|---|---|---|
| 雇用区分 | 職員、委託、派遣、外部監査人などの区別 | 外部ユーザーに内部職員と同じ標準権限を与えない |
| 部門・施設 | 病院、支店、研究所、事業部ごとのアクセス制御 | 組織改編時に古い部門コードが残りやすい |
| 職務・資格 | 医師、看護師、薬剤師、審査担当などの判断材料 | 資格失効や職務変更を反映できる仕組みが必要 |
| 雇用開始日・終了日 | アカウント有効化、アクセス期限設定 | 契約延長・早期終了の更新漏れに注意 |
| 上長・責任者 | 承認者、アクセスレビュー担当者の決定 | 組織変更時に承認者が空欄にならないようにする |
ここで失敗しやすいのは、「とりあえず Entra 側でグループを作る」ことから始めてしまうケースです。権威データが曖昧なままグループを増やすと、後からアクセスレビューを実施しても、判断材料が不足します。
まずは、どの属性をアクセス判断に使うのかを決める必要があります。
プロビジョニングは「作る」だけでなく「更新する・外す」まで設計する
高リスク記録アクセスでは、新規アカウント作成だけを自動化しても十分ではありません。むしろ重要なのは、異動、休職、契約終了、退職時にアクセスを確実に変更・削除することです。
Microsoft Learn では、Microsoft Entra のアプリプロビジョニングを、アプリケーションに必要なユーザー ID やロールを自動作成する仕組みとして説明しています。自動プロビジョニングには、ユーザー作成だけでなく、状態やロール変更に応じた ID の保守、削除も含まれます。SCIM、LDAP、SQL、REST、SOAP、PowerShell、Custom ECMA connectors などの連携方式も示されています。(Microsoft Learn)
規制業種での実務例は次の通りです。
| イベント | 自動化したい処理 | 判断基準 |
|---|---|---|
| 入社・着任 | 基本 ID 作成、必要な初期アクセス付与 | 所属、職務、勤務地、資格を確認する |
| 部門異動 | 旧部門アクセス削除、新部門アクセス付与 | 旧権限を残す必要がある場合は期限を付ける |
| プロジェクト参加 | 特定記録システムへの一時アクセス | 目的、期間、承認者を必須にする |
| 休職 | 高リスクシステムへのアクセス停止 | 復職時の再付与プロセスも決める |
| 退職・契約終了 | アクセス削除、アカウント無効化 | 終了日当日の自動処理を原則にする |
「退職者アカウントは無効化する」という方針は多くの組織にあります。しかし、委託先担当者、共同研究者、外部監査人、短期プロジェクトメンバーのアクセス終了日は、現場任せになりやすい領域です。
高リスク記録アクセスでは、内部職員よりも外部・一時利用者の管理漏れがリスクになることがあります。期限付きアクセスと定期レビューを組み合わせることが重要です。
Access Package で「業務に必要な権限セット」を標準化する
Entra ID Governance の中で、実務上とくに重要なのが Entitlement Management と Access Package です。
Microsoft Learn では、Entitlement Management を、アクセス要求ワークフロー、アクセス割り当て、レビュー、有効期限を自動化し、ID とアクセスのライフサイクルを大規模に管理する機能と説明しています。Access Package は、特定の業務やプロジェクトに必要なリソースをまとめた単位です。(Microsoft Learn)
高リスク記録アクセスでは、個別権限を直接付与するのではなく、業務で理解できる単位にまとめるのが実用的です。
Access Package の設計例
| Access Package 例 | 対象者 | 含めるリソース例 | ポリシー例 |
|---|---|---|---|
| 救急外来 EHR 基本アクセス | 救急外来に所属する臨床スタッフ | EHR アプリ、関連グループ、Teams、SharePoint | 上長承認、90日ごとのレビュー |
| 外部監査用記録閲覧アクセス | 監査法人、外部監査人 | 監査対象アプリ、限定フォルダー | 期限付き、二段階承認、自己延長不可 |
| 請求・レセプト業務アクセス | 医事課、請求担当 | 請求システム、患者基本情報参照 | 部門責任者承認、異動時自動削除 |
| 臨床研究データアクセス | 研究者、統計担当 | 研究データセット、解析環境 | 研究責任者承認、プロジェクト終了日で失効 |
| 緊急時例外アクセス | 限定された当直責任者など | 通常より広い記録参照権限 | 短時間、理由記録、事後レビュー必須 |
Access Package を設計する際は、「システム管理者が分かる名前」ではなく、「業務責任者が承認できる名前」にすることが重要です。
悪い例は、「EHR_Group_Access_01」「AppRole_Level3」のような名称です。承認者が内容を理解できず、実質的に形だけの承認になります。
良い例は、「循環器内科 入院患者記録参照」「外部監査 2026年度限定アクセス」のように、対象業務、対象範囲、期間が分かる名称です。
Access Reviews で「今も必要か」を定期的に問い直す
アクセス付与よりも難しいのが、アクセスの見直しです。
Microsoft Learn では、Access Reviews を、グループメンバーシップ、エンタープライズアプリへのアクセス、ロール割り当てを効率的に管理し、適切な人だけが継続アクセスできるよう定期的に確認する機能として説明しています。過剰なアクセス権は侵害や監査指摘につながる可能性があるため、リソース所有者による定期レビューが重要です。(Microsoft Learn)
さらに、Access Reviews の展開計画では、定期レビューやアドホックレビュー、特定管理者・ビジネスオーナー・本人による自己証明への委任、レビュー結果に基づくアクセス削除の自動化などが説明されています。(Microsoft Learn)
高リスク記録アクセスでは、レビュー設計を次のように分けると運用しやすくなります。
| レビュー対象 | 推奨されるレビュー担当 | 頻度の考え方 |
|---|---|---|
| 重要記録システムの基本アクセス | 部門責任者、アプリ所有者 | 四半期または半期ごと |
| 外部ユーザーのアクセス | 契約責任者、プロジェクト責任者 | 月次または契約期間ごと |
| 例外アクセス | セキュリティ、コンプライアンス担当 | 利用直後または短周期 |
| 管理者・特権ロール | IT 管理責任者、セキュリティ責任者 | 月次または四半期ごと |
| 長期間未使用のアクセス | アプリ所有者、ID ガバナンスチーム | 利用状況に基づき随時 |
レビューの目的は、単に「承認ボタンを押してもらう」ことではありません。レビュー担当者が判断できる情報を提示し、不要なアクセスを削除することです。
そのため、レビュー時には少なくとも次の情報を見えるようにします。
- 対象ユーザーの所属、職務、雇用区分
- 付与されているアクセスパッケージ名
- 付与理由、申請時の業務目的
- 承認者、承認日、有効期限
- 直近の利用状況
- 前回レビュー結果
- 例外扱いかどうか
これらが見えないレビューは、実務上ほとんど意味がありません。承認者が不安になって全員承認するか、判断できずに ID 管理チームへ差し戻すだけになるからです。
医療以外の規制業種にどう応用するか
Microsoft の発信は医療の EHR を中心にしていますが、パターン自体は「高リスク記録」全般に適用できます。
金融機関
金融機関では、顧客情報、取引履歴、与信情報、AML 関連情報などが高リスク記録になります。
Entra ID Governance の考え方を使う場合、営業担当、審査担当、監査担当、システム運用担当のアクセスを分けます。たとえば、営業担当は担当顧客の情報に限定し、審査担当は審査案件に必要な範囲、内部監査担当は監査期間中の読み取り専用アクセスに限定する、といった設計が考えられます。
公共機関
公共機関では、住民情報、税務情報、福祉情報、教育記録などが対象になります。
異動が多い組織では、前部署の権限が残ることが大きなリスクです。人事異動情報を起点に、旧部署のアクセスを自動削除し、新部署の業務に必要なアクセスだけを付与する設計が重要です。
製薬・研究機関
製薬や研究領域では、臨床試験データ、研究データ、被験者情報、知的財産関連資料が対象になります。
研究プロジェクトは期間限定で、外部研究者や委託先が関与することもあります。そのため、Access Package に研究期間、研究責任者、データ範囲を紐づけ、終了日で自動失効させる設計が向いています。
法務・監査部門
法務や監査では、訴訟資料、調査資料、内部通報関連資料など、閲覧者を厳しく制限すべき情報があります。
通常の部門アクセスとは別に、案件単位のアクセスパッケージを作り、事前承認、期限、事後レビューを必須にすることで、過剰な共有を防ぎやすくなります。
導入時に最初に決めるべき設計項目
Microsoft Entra ID Governance を高リスク記録アクセスに適用する場合、いきなり全社展開を目指すより、重要な1〜2システムから始める方が現実的です。
最初に決めるべき項目は次の通りです。
| 設計項目 | 決める内容 | 実務上のポイント |
|---|---|---|
| 対象システム | どの記録システムから始めるか | 監査指摘が多い、手作業が多い、外部ユーザーが多い領域を優先 |
| 権威データ | どのデータを正とするか | HR、職員マスター、契約管理、資格管理などを確認 |
| ロール定義 | 業務上のアクセス単位 | システム権限名ではなく業務ロール名で整理 |
| 承認者 | 誰がアクセスの妥当性を判断するか | IT ではなく業務責任者・データ所有者を含める |
| 有効期限 | いつ自動失効させるか | 外部・一時アクセスは期限なしにしない |
| レビュー頻度 | どの周期で棚卸しするか | 高リスク・外部・例外アクセスほど短周期にする |
| 証跡 | 監査で何を示すか | 申請理由、承認者、レビュー結果、削除履歴を残す |
特に重要なのは、IT 部門だけで決めないことです。高リスク記録へのアクセスは、業務上の必要性を理解している部門責任者、データ所有者、コンプライアンス担当、セキュリティ担当を巻き込まなければ、実効性のある設計になりません。
実装前に確認したいチェックリスト
導入プロジェクトでは、次のチェックリストを使うと抜け漏れを減らせます。
| チェック項目 | 確認すべきこと |
|---|---|
| 権威データは明確か | 誰の所属・職務・契約終了日を何のシステムで管理しているか |
| アクセスロールは業務用語で説明できるか | 承認者が内容を理解できる名称になっているか |
| 期限なしアクセスを減らせるか | 外部ユーザー、プロジェクトアクセス、例外アクセスに期限を設定しているか |
| 異動時に旧権限を削除できるか | 新権限の追加だけでなく、旧権限の削除条件を決めているか |
| 退職・契約終了時の処理が自動化されているか | 終了日をトリガーにアクセスを削除できるか |
| レビュー担当者が判断材料を持っているか | 所属、目的、利用状況、前回結果を確認できるか |
| 監査用の証跡が残るか | 申請、承認、レビュー、削除の記録を説明できるか |
| 例外アクセスの扱いが決まっているか | 緊急アクセスや特別承認を事後レビューできるか |
このチェックで多くの未決項目が出る場合、先に業務ロールとデータ所有者を整理するべきです。ツール設定を急ぐと、既存の曖昧な運用をクラウド上に移すだけになります。
失敗しやすいポイント
すべてを動的グループだけで解決しようとする
属性ベースの自動化は有効ですが、すべてのアクセス判断を属性だけで完結できるとは限りません。
たとえば、「この研究プロジェクトに参加している」「今年度の外部監査に関与している」「一時的に別部門を支援している」といった条件は、HR 属性だけでは表現しにくいことがあります。
その場合は、Access Package と承認ワークフロー、期限付きアクセスを組み合わせる方が自然です。
承認者を IT 管理者にしてしまう
IT 管理者はシステム操作には詳しくても、その人が特定の患者記録、顧客情報、研究データにアクセスする業務上の妥当性を判断できるとは限りません。
高リスク記録アクセスでは、承認者をデータ所有者、業務責任者、プロジェクト責任者に寄せるべきです。IT は仕組みを運用し、業務部門がアクセス妥当性を判断する役割分担が望ましいです。
アクセスレビューを形式的な棚卸しにしてしまう
アクセスレビューを実施しても、全員を自動的に承認しているだけでは統制になりません。
レビュー対象を絞り、判断材料を提示し、否認されたアクセスを実際に削除するところまで設計する必要があります。レビュー後の削除処理が手動で止まると、監査で「レビューはしたが是正されていない」と見られる可能性があります。
例外アクセスを放置する
規制業種では、緊急対応や障害対応のために例外アクセスが必要になることがあります。問題は、例外が長期化することです。
例外アクセスには、短い有効期限、理由の記録、責任者承認、事後レビューを設定します。例外アクセスを通常権限の代わりに使い始めると、最小権限の設計が崩れます。
まず着手すべき現実的なステップ
最初から全システムを対象にする必要はありません。むしろ、スコープを絞った方が成功しやすくなります。
おすすめの進め方は次の通りです。
| ステップ | 実施内容 | 成果物 |
|---|---|---|
| 現状把握 | 高リスク記録システム、利用者、権限、承認経路を棚卸しする | 対象システム一覧、権限一覧 |
| 優先順位付け | 監査リスク、外部ユーザー数、手作業量で対象を選ぶ | PoC 対象の決定 |
| ロール整理 | 業務ロールと必要アクセスを対応付ける | Access Package 候補 |
| 権威データ確認 | 所属、職務、終了日、資格情報の取得元を決める | 属性マッピング方針 |
| ワークフロー設計 | 申請、承認、期限、失効、レビューを決める | アクセス管理ポリシー |
| 小規模展開 | 1部門または1システムで試す | 運用課題、改善点 |
| 監査証跡確認 | 申請から削除まで説明できるか確認する | 監査用レポート方針 |
PoC の対象は、全社で最も複雑なシステムではなく、改善効果が見えやすく、業務責任者の協力を得やすい領域が向いています。
たとえば、外部監査人向けアクセス、研究プロジェクトアクセス、特定部門の EHR 閲覧アクセスなどは、期限や承認者を明確にしやすいため、最初の対象として扱いやすいです。
まとめ:高リスク記録アクセスは「権限管理」ではなく「ライフサイクル管理」として設計する
Microsoft Entra ID Governance の EHR ガバナンスパターンから規制業種が学ぶべきことは、ツールの導入そのものではありません。
重要なのは、高リスク記録へのアクセスを、次の流れで一貫して管理することです。
- 権威データを起点にユーザーを定義する
- 入社・異動・退職に合わせて ID とアクセスを更新する
- 業務ロール単位の Access Package で権限を標準化する
- 期限付きアクセスと承認ワークフローで過剰権限を防ぐ
- Access Reviews で「今も必要か」を定期的に確認する
- 申請、承認、レビュー、削除の証跡を監査で説明できるようにする
高リスク記録アクセスの管理で最初にやるべきことは、Entra の設定画面を開くことではありません。まず、自社の重要記録システムを洗い出し、「誰が、どの業務目的で、どの期間、何にアクセスすべきか」を業務ロールとして整理することです。
そのうえで Microsoft Entra ID Governance のプロビジョニング、エンタイトルメント管理、アクセスレビューを組み合わせれば、手作業中心の ID 管理から、監査に耐えるアクセスライフサイクル管理へ移行しやすくなります。

コメント