IDガバナンスとは？アクセスレビューの実務フローと権限肥大化を防ぐ設計

「そのアカウント、まだ使ってますか？」——退職した社員のアカウントが半年後も有効だったと気づいたとき、背筋が凍ります。

権限の付与は「設計」で終わりではありません。付与した権限が時間の経過とともに「必要以上」になっていないか、定期的に確認する仕組みが必要です。それがIDガバナンスとアクセスレビューです。

この記事では、IDガバナンスの考え方とアクセスレビューの実務フローを整理します。

「権限、付けたまま放置してませんか？」——棚卸しをしない組織のリスク
IDガバナンスとは——「誰が・何に・なぜアクセスできるか」を管理する仕組み
1. IDガバナンスが必要になった背景
2. IAMとIDガバナンスの違い——設計と運用の関係
アクセスレビューとは——定期的に権限の正当性を確認するプロセス
1. なぜアクセスレビューが必要なのか
2. レビューの対象——何を・誰が確認するか
アクセスレビューの実務フロー
Microsoft Entra IDのアクセスレビュー機能を使う
よくある失敗パターン——「やったつもり」で終わるレビューの落とし穴
実務チェックリスト——IDガバナンス・アクセスレビューの確認ポイント
まとめ——今日確認すべきことは1つです

「権限、付けたまま放置してませんか？」——棚卸しをしない組織のリスク

権限の放置が引き起こすリスクは2つあります。

① セキュリティリスク：退職者・異動者のアカウントが有効なまま残っていると、元従業員による不正アクセスや、アカウント侵害時の被害範囲拡大につながります。

② コンプライアンスリスク：「誰が何にアクセスできるか」を説明できない状態は、監査・法令対応で問題になります。特に個人情報や機密情報へのアクセス権限は、正当な理由のある人だけに限定されていることを証明できる必要があります。

最小権限の原則の基本については「最小権限の原則とは？」で解説しています。

IDガバナンスとは——「誰が・何に・なぜアクセスできるか」を管理する仕組み

IDガバナンス（Identity Governance） 組織内のユーザーIDとアクセス権限を継続的に可視化・制御・監査する仕組み。権限の付与だけでなく、維持・変更・削除までのライフサイクル全体を管理する。

IDガバナンスが必要になった背景

クラウドサービスの普及により、管理すべきIDとアクセス権限の数が急増しました。オンプレミスのADだけでなく、Microsoft 365・AWS・SaaSアプリケーションなど複数のシステムにまたがってIDが存在する現代では、「付与した権限を継続的に管理する」仕組みなしに最小権限を維持することは困難です。

IAMとIDガバナンスの違い——設計と運用の関係

IDガバナンスはIAMと混同されやすいですが、役割が異なります。

比較項目	IAM	IDガバナンス
主な役割	認証・認可の仕組みを設計・実装する	付与した権限が今も正しいかを継続的に管理する
タイミング	入社・異動・退職時などのイベント駆動	定期的・継続的
主なアウトプット	権限設計・アクセス制御ポリシー	アクセスレビュー結果・監査レポート
担当者	IT管理者・セキュリティ担当	IT管理者＋業務部門の管理者

IAMの基本については「IAMとは？」を、IDライフサイクル管理の考え方については「IDライフサイクル管理とは？」をそれぞれ参照してください。

アクセスレビューとは——定期的に権限の正当性を確認するプロセス

アクセスレビュー（Access Review） ユーザーが保有するアクセス権限を定期的に確認し、業務上の必要性がなくなった権限を削除するプロセス。権限の肥大化（Permission Creep）を防ぐための運用サイクル。

なぜアクセスレビューが必要なのか

権限は「付与するとき」には適切でも、時間の経過とともに不要になります。

権限が不要になる主な原因	例
異動・役職変更	営業部から開発部へ異動したが旧部門の共有フォルダへのアクセスが残っている
プロジェクト終了	特定プロジェクト用に付与した権限がプロジェクト終了後も残っている
退職	退職処理でアカウントを無効化したが権限の棚卸しをしていない
業務範囲の変更	担当業務が変わったが権限が累積して肥大化している

権限の肥大化（Permission Creep） ユーザーが異動・昇格・プロジェクト参加を繰り返すうちに、古い権限が削除されないまま累積し、必要以上の権限を保有してしまう状態。

レビューの対象——何を・誰が確認するか

アクセスレビューの対象は大きく3種類です。

レビュー対象	確認内容	レビュー担当者
ユーザーのグループ・ロール所属	このユーザーはこのグループに所属する必要があるか	業務部門の管理者
特権アカウントの権限	この管理者権限は今も必要か	IT管理者・セキュリティ担当
ゲスト・外部ユーザーのアクセス	この外部ユーザーはまだアクセスが必要か	IT管理者・業務担当者

アクセスレビューの実務フロー

ステップ1：レビュー対象の洗い出し

まずレビューする対象を明確にします。一度にすべてをレビューしようとすると負担が大きくなるため、優先度をつけて段階的に進めてください。

優先度の高いレビュー対象：

優先度	対象	理由
高	特権アカウント（Domain Admins・グローバル管理者）	侵害時の影響が最大
高	退職・異動から90日以内のアカウント	権限が残っているリスクが高い
中	外部ユーザー・ゲストアカウント	管理が属人化しやすい
中	機密情報・個人情報へのアクセス権限	コンプライアンス要件
低	一般ユーザーの標準権限	リスクは低いが定期確認は必要

ステップ2：レビューの実施——承認・否認・エスカレーション

レビューは「IT管理者だけ」で完結させないことが重要です。「このユーザーがこの権限を今も必要としているか」は、業務の実態を知る業務部門の管理者が判断するのが正しいあり方です。

レビューの判断基準：

このユーザーは今もこの権限が業務上必要か？

Yes → 承認（権限を維持）
No  → 否認（権限を削除）
わからない → 業務部門の管理者にエスカレーション

レビュー期限の設定：レビュー依頼を送っても回答がないケースに備え、「期限までに回答がない場合は否認（削除）とみなす」というルールを事前に周知してください。「承認とみなす」ルールにすると権限が残り続けるリスクがあります。

ステップ3：否認後の対応——権限の削除と記録

否認と判断した権限は、速やかに削除します。削除前に以下を確認してください。

削除前の確認事項：
1. 削除対象の権限・グループ・ロールを記録する
2. 業務への影響がないか業務部門に最終確認する
3. 削除を実行する
4. 削除後に対象ユーザーへ通知する（必要に応じて）
5. 削除日時・実施者・理由を台帳に記録する

ステップ4：結果の記録と次回レビューへの反映

レビュー結果は必ず記録し、次のレビューサイクルに活かします。

記録すべき内容：レビュー実施日・対象アカウント数・承認数・否認数・削除した権限の一覧・レビュー担当者。

この記録は監査対応の証跡にもなります。「いつ・誰が・何を確認して・どう判断したか」を追跡できる状態を維持してください。

Microsoft Entra IDのアクセスレビュー機能を使う

Microsoft Entra ID P2ライセンスでは、アクセスレビューを自動化できます。

Entra IDアクセスレビュー（Azure AD Access Reviews） Microsoft Entra IDの機能。グループメンバーシップ・アプリケーションへのアクセス・特権ロールの割り当てを定期的に自動レビューし、業務部門の管理者にメールで確認依頼を送る仕組み。

主な機能は以下の通りです。

機能	内容
定期レビューの自動スケジュール	月次・四半期・年次でレビューを自動作成
レビュー担当者へのメール通知	業務部門の管理者に自動でレビュー依頼を送信
期限切れ時の自動処理	回答がない場合に自動で承認・否認を設定できる
レビュー結果のレポート	監査用のレポートを自動生成