Microsoft Entra ID Governance / Access Reviews / Entitlement Management の最新動向で最も重要なのは、機密レコードシステムのアクセス管理を「申請して付与する」だけで終わらせず、期限付きで付与し、定期的に見直し、不要になったら自動的に外す運用へ移すことです。
2026年4月19日に公開された Microsoft Tech Community の記事では、EHR（電子医療記録）を例に、Access Reviews と Entitlement Management を中核的なガバナンス統制として位置付けています。これは医療業界だけの話ではありません。人事台帳、財務システム、顧客マスター、契約管理、研究データ、行政・教育機関の記録システムなど、「権限が残ること自体がリスクになるシステム」を扱う組織にそのまま当てはまります。(TECHCOMMUNITY.MICROSOFT.COM)
結論として、Security teams、compliance leads、platform architects が優先すべきリスク低減策は、次の4つです。
- 機密システムへの直接割り当てを減らし、Access Package にまとめる
- Access Reviews で定期的に「持ち続けてよい権限か」を確認する
- HR属性・組織変更・退職情報と連動して、付与と削除を自動化する
- 例外グループ、外部ユーザー、管理者ロール、オンプレ連携部分を重点的に棚卸しする
Microsoft の発信は「EHRだけの話」ではなく、機密レコードシステム全体への警鐘
Microsoft は今回の発信で、EHRのようなデジタルヘルスレコードを例に、Microsoft Entra ID Governance による ID ライフサイクル管理、Access Package による権限管理、Access Reviews による再認証を組み合わせる流れを示しています。記事では、HRなどの権威あるデータソースを Entra に接続し、Joiner・Mover・Leaver のプロセスを自動化し、時間の経過とともにアクセスを再確認することが強調されています。(TECHCOMMUNITY.MICROSOFT.COM)
ここで注目すべき点は、Microsoft が「機密データを守るには、認証強化だけでは足りない」という方向に話を進めていることです。多要素認証や条件付きアクセスは重要ですが、そもそも不要な人に権限が残っていれば、侵害時の被害範囲は広がります。つまり、機密レコードシステムの安全対策では、誰がログインできるかだけでなく、なぜその権限を持ち、いつまで持つのかまで管理する必要があります。
Microsoft Entra ID Governance は、Microsoft の説明上、適切な人が適切なリソースにアクセスできる状態を支援し、IDとアクセスのリスクを保護・監視・監査するための仕組みとして位置付けられています。Microsoft の公式ドキュメントでも、IDライフサイクル、アクセスライフサイクル、管理者権限の保護が主要シナリオとして整理されています。(Microsoft Learn)
機密レコードシステムで最初に潰すべきリスク
機密レコードシステムでは、攻撃者が新しい権限を作るよりも、すでに残っている権限を悪用するほうが現実的なリスクになることがあります。特に、部署異動後の旧権限、退職者や外部委託先の残存アカウント、一時対応のために付けた管理権限、条件付きアクセスの除外グループは、監査でも問題になりやすい領域です。
| 優先度 | リスク | 典型例 | 先に取るべき対策 |
|---|---|---|---|
| 高 | 退職・契約終了後の残存アクセス | 外部委託先や非常勤スタッフのアカウントが残る | HR情報、契約終了日、Access Reviewsを連動させる |
| 高 | 直接割り当ての増殖 | アプリに個人単位で権限を付け、誰が承認したか不明 | Access Packageまたはグループ経由に統一する |
| 高 | 管理者権限の常時保持 | Global Administrator、Conditional Access Administratorなどが常時有効 | PIMとAccess Reviewsで定期確認する |
| 中〜高 | 例外グループの放置 | MFA除外、条件付きアクセス除外、緊急対応グループ | 月次または四半期でレビューする |
| 中 | 外部ユーザーの棚卸し不足 | 共同研究、取引先、監査法人、SIerのゲストが残る | ゲスト専用レビューと期限付きAccess Packageを使う |
| 中 | オンプレ同期グループの手動運用 | AD側のグループが実質的なアクセス元になっている | レビュー結果をCSVやGraph経由で運用に戻す |
Access Reviews の公式ドキュメントでも、過剰なアクセス権は侵害や監査指摘につながり得るため、ユーザーアクセスを定期的に確認し、適切な人だけがアクセスを保持している状態を維持することが目的とされています。(Microsoft Learn)
Entitlement Managementで権限を「業務単位」にまとめる
Entitlement Management の実務上の価値は、権限を個別に付け外しするのではなく、Access Packageとして業務単位にまとめられることです。Microsoft の説明では、Entitlement Management はアクセス要求、割り当て、レビュー、有効期限を自動化して、IDとアクセスのライフサイクルを大規模に管理する機能です。Access Package には、グループ、アプリケーション、Teams、SharePoint Online サイトなどのリソースを含められます。(Microsoft Learn)
たとえば、EHRであれば「救急外来医師」「病棟看護師」「医療事務」「臨床研究担当」といった業務単位で Access Package を作ります。医療以外なら、「給与計算担当」「財務承認者」「顧客データ閲覧者」「契約書管理者」「研究データ共同利用者」などが候補です。
重要なのは、Access Package を単なる権限セットではなく、承認・期限・再確認を含む統制単位として設計することです。
| 設計項目 | 推奨する考え方 | 悪い例 |
|---|---|---|
| パッケージ名 | 業務担当者が理解できる名称にする | EHR-Group-01 のようなIT都合の名前 |
| 対象者 | 部門、職種、雇用形態、外部組織で絞る | 全社員が申請可能 |
| 承認者 | 業務責任者、データオーナー、必要に応じてセキュリティ担当 | 情報システム部だけが判断 |
| 有効期限 | 一時業務は短く、定常業務も定期レビュー対象にする | 無期限付与 |
| レビュー | Access Packageのライフサイクル内で定期確認する | 付与後に棚卸ししない |
| 削除 | 不要・期限切れ・否認時に外す | 手動チケット待ち |
Access Package のポリシーでは、誰がリクエストできるか、承認プロセスをどうするか、アクセスをいつ失効させるかを定義できます。Microsoft のアクセスレビュー計画ガイドでも、Access Package の作成・編集時にアクセスレビューを構成できると説明されています。(Microsoft Learn)
直接割り当てを減らすことが最初の成果になる
多くの組織では、機密アプリケーションへのアクセスが次のように混在しています。
- アプリ側で直接付与されたユーザー
- Microsoft Entra IDのエンタープライズアプリに直接割り当てられたユーザー
- セキュリティグループ経由のユーザー
- Access Package経由のユーザー
- オンプレADグループ経由のユーザー
- 例外対応で追加された一時ユーザー
この状態では、監査時に「誰が、なぜ、この人に権限を付けたのか」を説明しにくくなります。まずは、機密システムごとに権限付与ルートを棚卸しし、恒久的な直接割り当てを Access Package または管理されたグループへ寄せることが重要です。
Access Reviewsで「持ち続ける権限」を定期的に確認する
Access Reviews は、権限を付けた後のリスクを下げるための中核機能です。Microsoft の公式説明では、グループメンバーシップ、エンタープライズアプリへのアクセス、ロール割り当てを効率的に管理し、適切な人だけが継続アクセスを持つよう定期的に確認できる機能とされています。(Microsoft Learn)
機密レコードシステムでは、レビュー対象を広げすぎるより、リスクの高い範囲から始めるほうが成功しやすくなります。最初から全社全権限をレビュー対象にすると、レビュー担当者が判断できず、形式的な承認だけが増えるためです。
| レビュー対象 | 推奨されるレビュー担当 | 頻度の目安 | 判断基準 |
|---|---|---|---|
| 機密アプリの閲覧・更新権限 | 業務責任者、データオーナー | 四半期〜半期 | 現在の職務で必要か |
| 管理者ロール | セキュリティ責任者、PIM管理者 | 月次〜四半期 | 常時必要か、JIT化できないか |
| 外部ユーザー | 取引先管理者、プロジェクトオーナー | 月次〜四半期 | 契約・案件が継続中か |
| 条件付きアクセス除外グループ | セキュリティチーム | 月次 | 例外理由が今も成立するか |
| 休眠ユーザー | IT管理者、業務責任者 | 月次〜四半期 | 直近利用実績と業務必要性があるか |
| オンプレ同期グループ | AD運用担当、業務責任者 | 四半期 | Microsoft Entra側の結果をAD運用へ反映できるか |
Access Reviews は、レビュー担当者をリソース所有者、指定された代理人、本人による自己申告、マネージャーなどから選べます。ただし、レビュー開始後に担当者設定を変更できないため、開始前に代替レビュー担当者やエスカレーション先まで設計しておく必要があります。(Microsoft Learn)
自動削除は「段階導入」が安全
Access Reviews では、レビュー結果に基づいてアクセス削除を自動適用できます。Microsoft の計画ガイドでは、Auto apply results to resource を有効にすると、レビュー終了後に承認されなかったユーザーをリソースから削除できると説明されています。(Microsoft Learn)
ただし、機密システムでいきなり自動削除を有効にすると、業務停止につながる可能性があります。初回は自動適用を無効にし、削除対象を確認してから手動で反映するのが現実的です。2回目以降、判断基準が安定した低リスク領域から自動適用を有効にします。
特に、夜間対応、兼務、臨時プロジェクト、監査対応、研究協力など、通常の組織図だけでは判断できない権限は注意が必要です。レビュー担当者には、単に「承認・拒否」を依頼するのではなく、「この人が今もこのデータにアクセスする業務上の理由があるか」を確認してもらうべきです。
HR属性とプロビジョニングでJoiner・Mover・Leaverを閉じる
Microsoft Entra ID Governance を機密レコードシステムで使う場合、Access Reviews と Entitlement Management だけを単独で導入しても限界があります。入社、異動、退職、契約終了、休職、復職などのイベントがIDと権限に反映されなければ、レビューは後追いの作業になります。
Microsoft のドキュメントでは、HR driven provisioning により、HRシステムをデジタルIDの開始点として扱い、採用、属性更新、退職、再雇用といったシナリオでユーザーアカウントを作成・更新・無効化できると説明されています。(Microsoft Learn)
さらに、Entitlement Management の自動割り当てポリシーでは、ユーザー属性の変化に基づいてグループメンバーシップ、アプリロール、SharePointサイトロールを追加・削除できます。Microsoft Entra のアプリプロビジョニングは、SCIM、LDAP、SQL、REST、SOAP、フラットファイル、カスタムECMAコネクタなど複数の方式をサポートし、対象アプリ側のユーザー作成・更新・削除にも使えます。(Microsoft Learn)
実務では、次のように役割分担すると整理しやすくなります。
| 領域 | 主な機能 | 目的 |
|---|---|---|
| HR-driven provisioning | HR情報をもとにIDを作成・更新・無効化 | 人の状態を正しく反映する |
| Lifecycle Workflows | 入社前、異動時、退職時の処理を自動化 | 手動チケット依存を減らす |
| Entitlement Management | Access Packageで権限要求・承認・期限を管理 | 業務単位で権限を統制する |
| Access Reviews | 継続アクセスの妥当性を確認 | 残存権限・過剰権限を減らす |
| App provisioning | 対象アプリ側のアカウントやロールを更新 | アプリ内に残る孤立アカウントを減らす |
ここで大事なのは、「Entra側では削除したが、業務アプリ側にローカルアカウントが残っている」という状態を避けることです。特に古い基幹システム、オンプレミスの業務アプリ、独自開発の記録システムでは、SSOだけでなくプロビジョニングとデプロビジョニングの経路も確認する必要があります。
アプリケーション側の前提設定も見落とさない
Access Reviews を使うには、レビュー対象となるアプリケーションやグループが Microsoft Entra ID 側で管理できる状態になっている必要があります。Microsoft の計画ガイドでは、アプリケーションのアクセスレビューを作成する前提として、対象アプリがテナント内のアプリケーションとして統合され、ユーザーがアプリロールに割り当てられ、User assignment required? が Yes になっている必要があると説明されています。No の場合、ディレクトリ内の全ユーザーがアクセス可能になり、アプリケーションアクセスをレビューできないとされています。(Microsoft Learn)
これは実務上かなり重要です。セキュリティチームがAccess Reviewsを設定しても、アプリ側が「全ユーザーアクセス可能」のままだと、レビュー対象の考え方が崩れます。機密レコードシステムでは、次の設定を確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
| エンタープライズアプリ統合 | 対象システムがMicrosoft Entra IDに統合されているか |
| ユーザー割り当て | 個人直接ではなく、グループまたはAccess Package経由にできているか |
| User assignment required | 機密アプリでは原則としてYesにできるか |
| アプリロール | 「閲覧」「更新」「管理」など業務上意味のあるロールに分かれているか |
| ローカルアカウント | Entra外のアカウントが残っていないか |
| 退職・異動時の削除 | Entra側とアプリ側の両方で削除・無効化されるか |
外部ユーザーと例外グループは別枠で管理する
機密レコードシステムでは、外部ユーザーを通常の従業員と同じ棚卸しに混ぜると、見落としが発生しやすくなります。共同研究、外部監査、SIer保守、委託業務、業務提携など、外部ユーザーのアクセス理由は期間限定であることが多いためです。
Microsoft のアクセスレビュー計画ガイドでは、外部IDはグループ、Teams、エンタープライズアプリ、Access Package、特権ロールなどに割り当てられる可能性があり、ゲストユーザーのみを対象にしたレビューも選択できると説明されています。ただし、Microsoft Entra B2B以外で共有されたユーザーや、userTypeがmemberになっている外部メンバーなどは対象外になる場合がある点にも注意が必要です。(Microsoft Learn)
つまり、「Access Reviewsを設定したから外部ユーザーはすべて見えている」とは考えないほうが安全です。SharePointの直接共有、アプリ内ローカルユーザー、オンプレAD由来の外部要員アカウント、例外的にmember扱いされている取引先アカウントも確認対象に含めます。
条件付きアクセスの除外グループも同じです。MFA除外、レガシー認証対応、緊急運用、特定ネットワークからの例外などは、作った時点では正当でも、時間が経つと危険な抜け穴になります。例外グループは「例外理由」「承認者」「期限」「次回レビュー日」をセットで管理し、通常の業務アクセスより短い周期で見直すべきです。
オンプレミス連携では「レビューできる」と「自動で直せる」を分けて考える
Microsoft Entra ID Governance を使っていても、すべてのアクセスがクラウド側で完結するとは限りません。特に、オンプレミスActive Directoryのグループを同期して機密システムの認可に使っている場合、Access Reviews の結果をそのまま自動反映できないケースがあります。
Microsoft の計画ガイドでは、オンプレミスADから同期されたグループについて、Access Reviews はメンバーシップを直接変更できないと説明されています。ソースオブオーソリティがオンプレミスADであるためです。その場合でも、Access Reviewsを定期レビューの仕組みとして使い、CSVやMicrosoft Graphで結果を取得して、オンプレミス側の作業に反映する運用が示されています。(Microsoft Learn)
この点を誤解すると、「レビューは完了しているのに実際の権限が消えていない」という危険な状態になります。オンプレミス連携環境では、レビュー完了後の反映責任者、反映期限、確認方法まで運用手順に入れてください。
30日・90日・継続運用で進める優先順位
Microsoft Entra ID Governance / Access Reviews / Entitlement Management の導入は、最初から完璧な設計を目指すより、リスクの高い範囲を短期間で狭めるほうが効果的です。
| フェーズ | 目的 | 実施内容 |
|---|---|---|
| 最初の30日 | 見えていない権限を可視化する | 機密システム一覧、所有者、管理者ロール、外部ユーザー、直接割り当て、例外グループを棚卸しする |
| 30〜90日 | 高リスク領域を統制下に置く | 主要ロールをAccess Package化し、管理者権限・外部ユーザー・例外グループのAccess Reviewsを開始する |
| 90日以降 | 自動化と監査証跡を強化する | HR連携、アプリプロビジョニング、レビュー結果の自動適用、Log Analytics連携を拡大する |
| 継続運用 | 形骸化を防ぐ | レビュー完了率、否認率、期限切れ権限、孤立アカウント、例外の滞留期間を定期確認する |
Microsoft の計画ガイドでも、Access Reviews の導入では関係者の役割を明確にし、最初は小規模なパイロットから開始し、自動適用しないレビューで影響をコントロールすることが推奨されています。監査ログを確認し、削除されたアクセスを復旧できるよう記録することも重要です。(Microsoft Learn)
失敗しやすいポイントと回避策
レビュー担当者が「判断できない人」になっている
情報システム部門は権限の仕組みを理解していても、その人が業務上アクセスを必要としているかまでは判断できないことがあります。機密レコードシステムでは、レビュー担当を業務責任者やデータオーナーに寄せるべきです。
ただし、業務部門だけに任せると「念のため承認」が増えます。高リスク権限では、業務責任者が必要性を判断し、セキュリティチームが例外や過剰権限を確認する二段構えが有効です。
Access Packageが細かすぎる、または大きすぎる
Access Package を細かく作りすぎると、申請者も承認者も選べなくなります。一方で、「機密システム利用者」という大きすぎるパッケージにすると、最小権限が崩れます。
実務では、まず「閲覧」「更新」「承認」「管理」のような操作レベルで分け、次に部門や職種で分けると整理しやすくなります。EHRなら「患者情報閲覧」と「記録更新」と「システム管理」を分ける、財務システムなら「参照」「仕訳入力」「支払承認」「管理者」を分ける、といった形です。
初回から自動削除を有効にしてしまう
自動削除は強力ですが、業務影響もあります。最初のレビューでは、削除候補を洗い出し、実際に業務停止が起きないか確認することを優先します。一定期間の運用で誤判定が少ない対象から自動適用を有効にしてください。
外部ユーザーを「ゲスト一覧」だけで確認している
外部ユーザーは、B2Bゲストとして見えるとは限りません。アプリ内アカウント、SharePointの直接共有、オンプレADの委託先アカウント、member扱いされた外部要員なども存在します。機密システムでは、Microsoft Entra上のゲストレビューに加え、アプリ側のユーザー一覧も突き合わせます。
証跡を残していない
監査で問われるのは、「レビューを実施したか」だけではありません。誰が、何を根拠に、どの権限を継続または削除したかが重要です。Microsoft の計画ガイドでは、Access Reviews のアクティビティは Microsoft Entra audit logs に記録され、より高度な分析やダッシュボード化のために Azure Monitor Log Analytics や Event Hubs へエクスポートできると説明されています。(Microsoft Learn)
役割別に見るべきチェックポイント
| 役割 | 最初に見るべきこと | 成果物 |
|---|---|---|
| Security teams | 管理者ロール、例外グループ、外部ユーザー、休眠アクセス | 高リスク権限レビュー計画、例外棚卸し、削除ルール |
| Compliance leads | レビュー頻度、承認証跡、監査ログ、職務分掌 | 監査対応用レポート、レビュー証跡、統制説明書 |
| Platform architects | アプリ統合方式、プロビジョニング経路、オンプレ連携、Access Package設計 | 権限モデル、統合アーキテクチャ、運用手順 |
| 業務責任者 | 誰がどの業務でアクセスを必要とするか | 業務ロール定義、承認基準、不要権限リスト |
| ID運用担当 | JMLイベント、属性変更、削除反映、復旧手順 | ライフサイクルワークフロー、例外処理、反映チェックリスト |
まとめ：次に取るべき行動
Microsoft Entra ID Governance / Access Reviews / Entitlement Management を機密レコードシステムの安全対策に使うなら、最初に目指すべき状態は明確です。権限を個人単位で場当たり的に付ける運用から、業務単位で申請・承認・期限・再確認・削除まで管理する運用へ移行することです。
次に取るべき行動は、次の3つです。
1つ目は、機密システムのアクセス経路を棚卸しすることです。直接割り当て、グループ、Access Package、外部ユーザー、管理者ロール、オンプレAD連携、アプリ内ローカルアカウントを分けて確認します。
2つ目は、高リスク領域からAccess Reviewsを開始することです。管理者権限、外部ユーザー、条件付きアクセス除外グループ、機密アプリの直接割り当てを優先し、初回は自動削除を無効にして影響を確認します。
3つ目は、Entitlement ManagementでAccess Packageを設計することです。業務ロールごとに必要なリソースをまとめ、承認者、有効期限、再レビュー、削除条件を設定します。
今回の Microsoft の発信は、単なる製品紹介ではなく、機密レコードシステムのアクセス管理を「付与中心」から「ライフサイクル中心」へ移すべきだというメッセージとして読むべきです。認証を強くするだけでなく、不要な権限を残さない仕組みを作ることが、これからのIDガバナンスの実務で最も重要なリスク低減策になります。
コメント