Microsoft Entra ID Governanceを検討しているIAMチームやコンプライアンス担当者にとって、最初に押さえるべき実装パターンは「Access Reviews」「ゲストガバナンス」「Entitlement Management」を組み合わせたアクセスライフサイクル管理です。医療機関の電子カルテのように、機密性が高く、職務変更が多く、監査証跡が求められる環境で有効なこの設計は、金融、製造、公共、法務、研究開発など、規制対応が必要な企業にもそのまま応用できます。
2026年4月19日にMicrosoft Tech Communityで公開された記事では、Microsoft Entra Identity Governanceを使って、EHRなどの機密記録システムに対するアクセス付与、アクセスパッケージ、定期的なアクセスレビューを統制する考え方が示されました。ポイントは、単に「誰に権限を付けるか」ではなく、誰が、何の目的で、どの期間、どの承認を経て、いつ見直されるかまでを1つの運用パターンにすることです。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Entra ID Governanceが規制業界で重視される理由
Microsoft Entra ID Governanceは、従業員、外部パートナー、ベンダーなどのIDとアクセスを、ライフサイクル全体で管理するためのIDガバナンス機能です。Microsoft Learnでは、適切な人が適切なリソースへアクセスできる状態を、プロセス自動化、業務部門への委任、可視性の向上によって支援するソリューションと説明されています。(Microsoft Learn)
規制業界で問題になりやすいのは、「アクセスを付与できないこと」よりも、「付与したアクセスがいつまでも残ること」です。たとえば、次のような状態は監査や内部統制で指摘されやすくなります。
- 異動前の部署のデータに引き続きアクセスできる
- 退職者、契約終了者、外部委託先のゲストアカウントが残っている
- 管理者権限や例外アクセスの棚卸しが属人的
- アクセス申請の理由、承認者、有効期限が記録されていない
- 監査時に「なぜこの人がアクセスできるのか」を説明できない
医療のEHR、金融の顧客情報、製造業の設計データ、公共機関の住民情報、法律事務所の案件資料などは、どれも「アクセスできる人を最小限に保ち、継続的に確認する」ことが求められます。そのため、医療向けに示されたEntraのアクセス統制パターンは、業界固有の話ではなく、規制対象データを扱う企業全体に再利用しやすいのです。
2026年4月19日の更新で示された重要ポイント
MicrosoftのHealthcare and Life Sciences Blogでは、医療機関がEHRシステムへのアクセスを管理する際に、Microsoft Entra Identity Governanceを使って、HRデータ、ライフサイクルワークフロー、アプリプロビジョニング、Entitlement Management、Access Reviewsを組み合わせる考え方が紹介されています。対象として、Epic、Oracle Health（Cerner）、MeditechのようなEHRプラットフォームにも触れられています。(TECHCOMMUNITY.MICROSOFT.COM)
この記事から読み取れる実務上のメッセージは明確です。Entraは「認証の入口」だけではなく、機密アプリケーションに対するアクセス権の発行、維持、期限切れ、再認証、削除までを扱う統制基盤として位置付けられています。
特に重要なのは、次の3つです。
| 領域 | 役割 | 実務での意味 |
|---|---|---|
| Entitlement Management | アクセス要求、承認、割り当て、有効期限を管理 | 個別権限の手作業付与から、職務・業務単位のアクセスパッケージへ移行する |
| Access Reviews | 継続アクセスの妥当性を定期的に確認 | 異動者、不要権限、ゲスト、例外アクセスを棚卸しする |
| Guest governance | 外部ユーザーの招待、期限、削除を管理 | 委託先、取引先、共同研究者などの外部アクセスを放置しない |
この3つを組み合わせると、「アクセスを付ける」「使い続ける」「不要になったら外す」という一連の流れを、監査に耐えやすい形で設計できます。
Access Reviewsは「権限棚卸し」を運用に組み込む仕組み
Access Reviewsは、Microsoft Entra IDでグループメンバーシップ、エンタープライズアプリケーションへのアクセス、ロール割り当てを定期的に確認し、適切な人だけが継続アクセスできるようにする機能です。Microsoft Learnでも、過剰なアクセス権は侵害や監査指摘につながる可能性があるため、リソース所有者が定期的に確認する必要があると説明されています。(Microsoft Learn)
実務では、Access Reviewsを「年1回の監査対応」ではなく、通常運用の中に組み込むことが重要です。たとえば、四半期ごとに機密アプリのアクセスを確認し、月次でゲストアカウントを確認し、管理者ロールはより短い周期で確認するといった設計が考えられます。
Access Reviewsが特に効果を発揮する場面
Access Reviewsは、すべての権限に同じ頻度で適用すればよいわけではありません。優先度を付けることで、レビュー疲れを防ぎながらリスクを下げられます。
| 優先度 | 対象 | 推奨される考え方 |
|---|---|---|
| 高 | 管理者ロール、特権グループ、本番環境アクセス | 短い周期でレビューし、承認者を明確にする |
| 高 | 電子カルテ、顧客DB、設計情報、財務データ | 業務責任者が継続アクセスの必要性を確認する |
| 中 | 外部ゲスト、委託先、共同プロジェクト | 契約・案件の終了とアクセス削除を連動させる |
| 中 | 例外ポリシー、条件付きアクセスの除外対象 | 例外理由と期限を残し、定期的に再承認する |
| 低 | 一般的な社内閲覧グループ | 自動化や動的グループで代替できるか確認する |
失敗しやすいのは、IT部門だけで全レビューを処理しようとするケースです。IT部門はシステム構成を理解していても、「その人が今も業務上必要としているか」までは判断できません。Access Reviewsでは、業務部門の責任者、アプリ所有者、グループ所有者に判断を委任する設計が欠かせません。
Microsoftのデプロイ計画でも、アクセスレビューにはIT管理、セキュリティ、開発、業務部門、コーポレートガバナンスなど複数のステークホルダーが関与すると整理されています。レビュー頻度が高すぎる、またはレビュー担当者が少なすぎると品質が落ちる可能性があるため、責任分担と周期設計が重要です。(Microsoft Learn)
Entitlement Managementは「申請と承認」を再利用可能な型にする
Entitlement Managementは、アクセス要求ワークフロー、アクセス割り当て、レビュー、有効期限を自動化し、IDとアクセスのライフサイクルを大規模に管理するための機能です。中心になるのは「アクセスパッケージ」で、業務やプロジェクトに必要なグループ、アプリケーション、Teams、SharePointサイトなどを1つの単位にまとめて管理できます。(Microsoft Learn)
この機能が強いのは、アクセス権を「個別の権限一覧」ではなく、「業務で必要なセット」として扱える点です。
たとえば医療機関では、「救急外来医師」「病棟看護師」「臨床研究チーム」「外部監査担当」といった役割ごとに必要なアクセスが異なります。金融機関なら「融資審査チーム」「AML調査担当」「外部監査法人」、製造業なら「設計委託先」「品質保証チーム」「工場システム保守ベンダー」といった単位に置き換えられます。
アクセスパッケージ設計の具体例
| アクセスパッケージ名 | 対象者 | 含めるリソース例 | ポリシー例 |
|---|---|---|---|
| EHR閲覧・診療担当 | 医師、看護師、診療支援スタッフ | EHR関連アプリ、診療部門グループ、関連SharePoint | 所属部門に基づき自動付与、有効期限なしまたは定期レビュー |
| 共同研究プロジェクト | 研究者、外部共同研究者 | Teams、SharePoint、研究データアプリ | 申請制、研究責任者承認、90日または180日で期限切れ |
| 外部監査対応 | 監査法人、外部レビュー担当 | 監査用資料サイト、限定アプリ | 多段階承認、短期有効期限、終了後自動削除 |
| 本番運用保守 | SRE、委託先保守担当 | 本番監視ツール、運用グループ | セキュリティ承認、短期付与、Access Reviews必須 |
| 例外アクセス | 障害対応者、緊急対応者 | 一時的な特権グループ | 理由入力必須、短時間または短期間、レビュー対象 |
アクセスパッケージを作るときは、「アプリごと」ではなく「業務目的ごと」にまとめるのが実務的です。アプリ単位で細かく作りすぎると、申請者は何を選べばよいか分からず、承認者も判断しにくくなります。
ゲストガバナンスはB2Bアクセスの放置を防ぐ
規制業界では、外部ユーザーの管理が大きなリスクになります。外部委託、共同研究、サプライチェーン、監査法人、システム保守ベンダーなど、社外の人が機密データに関わる場面は増えています。一方で、プロジェクト終了後にゲストアカウントが残り続けると、監査や情報漏えいリスクの温床になります。
Microsoft Entra ID Governanceでは、Entitlement Managementによって外部組織のユーザーがアクセスを要求できる範囲を指定し、承認後にB2Bゲストとしてディレクトリへ追加し、権限の期限切れや取り消しに応じて不要なB2Bゲストを削除する考え方が示されています。また、Access Reviewsにより既存ゲストを定期的に見直すこともできます。(Microsoft Learn)
ゲストアクセスで決めるべき項目
ゲストガバナンスで重要なのは、「招待できるか」ではなく「誰が責任を持つか」です。最低限、次の項目を決めてから運用を始めるべきです。
| 設計項目 | 判断基準 |
|---|---|
| ゲストのスポンサー | 社内の誰が外部ユーザーの利用目的を説明できるか |
| 承認者 | 業務責任者、データ所有者、セキュリティ部門のどこまで承認が必要か |
| 有効期限 | 契約期間、案件期間、監査期間に合わせて期限を設定する |
| 更新条件 | 延長時に理由入力と再承認を必須にするか |
| レビュー周期 | 月次、四半期、案件終了時など、リスクに応じて決める |
| 削除条件 | アクセスパッケージがなくなったゲストをどう扱うか |
よくある失敗は、ゲストを「社外ユーザー」という1つの大きなカテゴリで扱うことです。実際には、監査法人、保守ベンダー、共同研究者、代理店、サプライヤーでは必要な権限も期間も異なります。ゲストの種別ごとにアクセスパッケージと承認ポリシーを分けると、運用が安定します。
医療から他の規制業界へ応用しやすい理由
医療のEHRガバナンスは、他業界にも再利用しやすい特徴を持っています。理由は、アクセス管理の難しさが業界固有のシステム名ではなく、共通する業務構造から生まれているためです。
医療では、医師、看護師、薬剤師、研究者、外部委託先、監査担当者など、多様な職務が同じ患者情報に異なる目的でアクセスします。金融、製造、公共、法務でも同じです。顧客情報、設計情報、住民情報、契約情報、研究データなど、機密データの種類は違っても、アクセス統制の問いは共通しています。
| 医療での課題 | 他業界での置き換え例 | Entraで使うパターン |
|---|---|---|
| 電子カルテへの職務別アクセス | 顧客情報、案件情報、設計データへの職務別アクセス | アクセスパッケージ、属性ベース割り当て |
| 医師・看護師の異動や退職 | 部門異動、出向、契約終了 | ライフサイクルワークフロー、Access Reviews |
| 外部監査や共同研究 | 監査法人、外部委託、サプライヤー | ゲストガバナンス、期限付きアクセス |
| 緊急対応時の例外アクセス | 障害対応、インシデント対応 | 例外アクセスの期限設定、レビュー |
| 監査証跡の提示 | 内部監査、外部監査、規制当局対応 | 承認履歴、レビュー結果、アクセス削除記録 |
つまり、医療向けのEntra ID Governanceパターンは、「患者情報」に限ったものではありません。機密レコードシステムに対して、最小権限、期限付きアクセス、定期レビュー、外部ユーザー管理を実装する標準パターンとして捉えるべきです。
RBACとABACをどう使い分けるか
Microsoftのブログでは、EHRの細かな権限をアクセスパッケージでモデル化し、RBACやABACのシナリオを実現しやすくする考え方にも触れています。(TECHCOMMUNITY.MICROSOFT.COM)
RBACは「役割」に基づくアクセス制御です。たとえば、「看護師」「営業マネージャー」「製造品質担当」といった職務ロールに応じて権限を付与します。ABACは「属性」に基づくアクセス制御です。部署、勤務地、雇用形態、コストセンター、プロジェクトコードなどの属性を使ってアクセスを判断します。
実務では、RBACとABACを対立するものとして考えるより、組み合わせて設計するのが現実的です。
| 設計方式 | 向いている場面 | 注意点 |
|---|---|---|
| RBAC | 職務ごとに必要権限が明確な場合 | ロールを細分化しすぎると管理不能になる |
| ABAC | 部門、勤務地、雇用形態、契約期間で制御したい場合 | 属性データの品質が低いと誤付与・未付与が起きる |
| アクセスパッケージ | 申請、承認、期限、レビューをまとめたい場合 | パッケージ名と説明が分かりにくいと申請ミスが増える |
| Access Reviews | 自動判定だけでは不十分な権限を確認する場合 | レビュー担当者に判断材料を渡さないと形骸化する |
おすすめは、標準的な職務アクセスはRBACと属性で自動化し、例外的・短期的・外部向けのアクセスはアクセスパッケージで管理し、重要リソースはAccess Reviewsで定期確認する設計です。
IAMチームが最初に作るべき実装順序
Microsoft Entra ID Governanceを導入するとき、いきなり全社展開を目指すと失敗しやすくなります。まずは、監査上の重要度が高く、関係者が明確で、影響範囲を限定できるリソースから始めるのが現実的です。
推奨ステップ
| ステップ | やること | 成果物 |
|---|---|---|
| 1 | 重要アプリと機密データを棚卸しする | 対象アプリ一覧、データ分類 |
| 2 | 権限を「業務目的」で整理する | アクセスパッケージ候補 |
| 3 | 承認者とデータ所有者を決める | 承認マトリクス |
| 4 | ゲストアクセスの期限とスポンサーを定義する | ゲストポリシー |
| 5 | Access Reviewsの対象と周期を決める | レビュー計画 |
| 6 | 小規模パイロットを実施する | 運用手順、通知文、例外処理 |
| 7 | 監査ログとレビュー結果を確認する | 監査証跡、改善リスト |
| 8 | 高リスク領域から段階展開する | 本番展開ロードマップ |
Microsoft Learnでも、Access Reviewsの展開では最初に小規模なパイロットを行い、重要度の低いリソースから試し、結果を自動適用しない状態で影響を確認することが推奨されています。(Microsoft Learn)
最初のパイロットに向いている対象
最初の対象としては、次のようなリソースが扱いやすいです。
- 外部監査用SharePointサイト
- 共同プロジェクト用Teams
- 特定部門の業務アプリ
- 委託先保守ベンダー用アクセス
- 例外アクセス用グループ
- 期限付きの研究・開発プロジェクト
反対に、全社員が使う基幹システムや、業務停止リスクが高い本番アクセスから始めるのは避けた方が安全です。まずは、申請、承認、期限切れ、レビュー、削除の流れを小さく検証し、通知文や復旧手順まで整えてから対象を広げます。
コンプライアンス担当者が確認すべき監査ポイント
Access ReviewsやEntitlement Managementを導入しても、監査で説明できなければ統制としては不十分です。コンプライアンス担当者は、機能の有無ではなく、証跡として何を残せるかを確認する必要があります。
監査で説明しやすい状態
| 監査観点 | 確認すべき内容 |
|---|---|
| アクセス付与の正当性 | 申請理由、承認者、承認日時が残っているか |
| 最小権限 | 職務や業務目的に対して過剰な権限がないか |
| 有効期限 | 短期アクセスやゲストアクセスに期限があるか |
| 継続確認 | Access Reviewsの周期、対象、結果が記録されているか |
| 削除・失効 | 不要と判断されたアクセスが削除されているか |
| 例外管理 | 例外アクセスの理由、期限、再承認が管理されているか |
| 責任分担 | IT、業務部門、データ所有者の役割が明確か |
重要なのは、「レビューを実施した」だけで終わらせないことです。レビューで否認されたアクセスが実際に削除されたか、未回答の場合にどう扱うか、例外的に残したアクセスの理由は何かまで確認する必要があります。
失敗しやすい設計と回避策
Microsoft Entra ID Governanceは強力ですが、設計が曖昧なまま導入すると、手作業をクラウドに移しただけになります。特に次の失敗はよく起きます。
| 失敗パターン | 起きる問題 | 回避策 |
|---|---|---|
| アクセスパッケージを細かく作りすぎる | 申請者が選べず、承認者も判断できない | 業務目的単位でまとめ、説明文を明確にする |
| すべてIT部門が承認する | 業務上の必要性を判断できない | データ所有者、アプリ所有者、部門長に委任する |
| レビュー頻度を高くしすぎる | 形だけの承認になり、レビュー品質が落ちる | リスク別に周期を分ける |
| ゲストに期限を設定しない | プロジェクト終了後も外部アクセスが残る | 有効期限とスポンサーを必須にする |
| 属性データを整備しない | 自動付与や削除が誤動作する | HRデータ、部署、雇用形態、契約終了日の品質を確認する |
| 例外アクセスを通常運用にする | 最小権限が崩れる | 例外は短期・理由必須・定期レビューにする |
| 監査証跡の保存方針がない | 監査時に説明できない | 申請、承認、レビュー、削除の記録を確認する |
特に注意したいのは、承認者の負担です。レビュー画面に名前だけが並んでいても、承認者は判断できません。「所属」「最終サインイン」「利用目的」「前回レビュー結果」「スポンサー」など、判断材料をどこまで見せるかを設計段階で確認しましょう。
グローバル企業での展開時に注意すべきこと
Microsoft Entra ID Governanceはグローバル企業でも使いやすい一方で、国や地域、事業部によって規制、雇用形態、委託契約、データ分類が異なります。グローバル展開では、全社共通ルールと地域別ルールを分けて考える必要があります。
共通化しやすいルール
- ゲストアクセスにはスポンサーを必須にする
- 機密データへのアクセスは有効期限付きにする
- 管理者ロールは定期的にAccess Reviewsを行う
- 外部ユーザーはプロジェクト終了時に削除または失効する
- 例外アクセスは理由、期限、再承認を必須にする
地域・部門ごとに調整すべきルール
- レビュー頻度
- 承認者の階層
- データ分類の名称
- 保管すべき監査証跡
- ゲストアクセスの最大期間
- ローカル規制に応じた例外処理
グローバルで成功しやすい設計は、「1つの巨大なルール」を作ることではありません。基本ポリシーは共通化し、アクセスパッケージや承認フローは業務・地域・リスクに応じて調整できる形にすることです。
次に取るべきアクション
Microsoft Entra ID Governanceを使ったアクセス統制を始めるなら、まずは全社展開ではなく、機密性が高く、関係者が明確な1つの業務領域を選びましょう。医療のEHRで示されたパターンを、自社の「最も監査で説明が必要なシステム」に置き換えるのが近道です。
最初にやるべきことは、次の3つです。
- 重要リソースを1つ選ぶ
顧客情報、電子記録、設計データ、監査資料、本番運用環境など、過剰アクセスが問題になりやすい対象を選びます。 - アクセスパッケージに置き換える
個別権限ではなく、「誰が何の業務目的で必要とするか」を基準に、申請・承認・期限付きのアクセスパッケージを設計します。 - Access Reviewsで継続確認する
付与したアクセスを定期的に見直し、不要なアクセス、外部ゲスト、例外アクセスを削除できる運用にします。
Access Reviews、ゲストガバナンス、Entitlement Managementは、単独機能として見るより、1つの再利用可能なガバナンスパターンとして設計することで効果を発揮します。規制業界のITリーダーやIAMチームは、まず「アクセスを付ける仕組み」ではなく、「アクセスが正当であり続けることを証明できる仕組み」を作るべきです。
コメント