Entra ID 自動化 #5 PIM と監査 — 常時管理者をなくす、ログとアクセスレビュー

ツール Microsoft Graph Entra ID
読了 6分

トラック最後のテーマは、権限の頂点とその記録です。管理者権限をどう最小に保つか、そして誰が何をしたかをどう自動で監視するか。ここまでそろえば、第 1 回で描いた JML ライフサイクルが、権限と監査まで含む閉じたループになります。

問題 — 常時の管理者権限は待機中の事故です #

グローバル管理者(Global Administrator)権限を常時保有するアカウントが 5 つある組織を考えてみます。そのうちひとつがフィッシングに破られるだけで、テナント全体が乗っ取られます。権限は実際に使う時間より持っているだけの時間が圧倒的に長く、持っているすべての時間が攻撃面です。

PIM(Privileged Identity Management)のアプローチは、権限の時間軸を変えることです。Entra ID P2 または Governance ライセンスの機能です。

  • 資格(eligible)割り当て: ユーザーはロールの「候補」であるだけで、普段は権限がありません。
  • アクティブ化(activation): 必要なときに本人がアクティブ化を要求します。理由の入力、MFA、必要なら承認者の承認を経て、時間制限付きのアクティブ権限(最大 8 時間、ロール設定で短縮可能)を受け取ります。
  • 期限切れ: 時間が過ぎれば権限は自動で回収されます。回収を忘れるという概念自体が消えます。

結果として、常時のグローバル管理者は緊急アカウント(第 4 回の break-glass)だけを残し、人の日常権限はすべて資格 + アクティブ化に変わります。すべてのアクティブ化が理由とともに記録されるので、監査対応も「前四半期に誰がなぜ管理者だったのか」を照会一発で答えられるようになります。

PIM を API で — 割り当てとアクティブ化 #

PIM も Graph で完全に自動化できます。ロール管理は roleManagement/directory の下のスケジュール要求リソースで行います。

  • 資格割り当て(管理者): roleEligibilityScheduleRequests に対象ユーザー、ロール、期間を入れて POST します。オンボーディング自動化が「IT チームの入社者にヘルプデスク管理者の資格を付与」をコードで処理できます。
  • セルフアクティブ化(ユーザー): roleAssignmentScheduleRequests に SelfActivate アクションで POST します。理由(justification)が必須で、チケット番号を併記する運用が標準です。自分がアクティブ化できる資格の一覧は filterByCurrentUser 関数で照会します。
  • ロール設定: ロールごとに最大アクティブ化時間、承認の要否、MFA 要求をポリシーとして管理できます。

第 3 回で作ったロール割り当て可能グループとの組み合わせが実務パターンです。グループにロールの資格を付けておけば、チームのオンボーディングはグループへのメンバー追加で終わり、権限の使用は個人のアクティブ化で統制されます。管理の単位(グループ)と使用の統制(アクティブ化)が分離される構造です。

監査ログとサインインログ — 記録をコードで消費する #

Entra ID は 2 種類の中核ログを残し、どちらも Graph API で照会できます。

ログ照会リクエスト 
GET https://graph.microsoft.com/v1.0/auditLogs/directoryAudits
    ?$filter=activityDateTime ge 2026-09-01T00:00:00Z

GET https://graph.microsoft.com/v1.0/auditLogs/signIns
    ?$filter=status/errorCode ne 0
  • ディレクトリ監査ログ(directoryAudits): 誰がユーザー・グループ・ポリシー・ロールを作り、変えたかの記録です。
  • サインインログ(signIns): すべての認証試行の記録です。失敗コード、場所、クライアントアプリ、適用された条件付きアクセスポリシーまで入っています。第 4 回のレポート専用の影響分析も、このログが源泉です。

自動化の観点での活用は 2 段階です。第一に、定期レポート。新規の管理者ロール付与、緊急アカウントのログイン、新しいアプリ登録といった高リスクイベントを毎日照会してチャンネルに送るスクリプトは、半日の作業で作れて効果が大きいです。第二に、SIEM 連携。ログの量が多い、保持要件が長い場合は、診断設定でログを Log Analytics や SIEM に流し、アラートルールはそちらで管理するのが正解です。Graph のポーリングは小規模とプロトタイプ、ストリーミング連携は本格運用、という区分です。

アクセスレビュー — 権限に賞味期限を作る #

JML の自動化がどれだけうまくいっても、アクセス権は時間とともに蓄積します。プロジェクトが終わってもグループに残り、役割が変わっても古いアプリアクセスが生きています。アクセスレビュー(access reviews)は、この腐敗を定期的な棚卸しで掃除する機能です(P2 以上、シナリオによっては Governance)。

  • 対象(グループメンバーシップ、アプリ割り当て、管理者ロール)と周期(四半期など)、レビュー担当(グループ所有者、上司、または本人)を決めてレビューを作ります。
  • レビュー担当が期限内に応答しないときのデフォルト動作を「削除」に設定すれば、放置がそのまま掃除になります。この設定がアクセスレビューの実質を決めます。
  • レビューの作成と結果の収集も Graph の identityGovernance/accessReviews API で自動化できます。「すべての管理者ロールには四半期ごとに自動でレビューが作られる」をコードで保証できます。

特にゲストアカウントと管理者ロール、この 2 つがアクセスレビューの最優先対象です。第 3 回のアクセスパッケージの期限と併用すれば、「付与されたすべてのアクセスには賞味期限か定期レビューがある」状態を作れます。

トラックを終えて — 導入順序 #

5 回分を実際の組織に適用する現実的な順序を整理します。

  1. 属性の標準化とユーザーライフサイクル(第 2 回): 源泉データがきれいでないと残りが成立しません。退職処理の自動化が最も急ぎのセキュリティ改善です。
  2. グループの再設計(第 3 回): 動的グループ + グループベースライセンスで Mover を無人化します。
  3. 条件付きアクセスの整備(第 4 回): 基本ポリシーセットをレポート専用で検証してデプロイし、policy-as-code に移します。
  4. PIM と監査(今回): 常時管理者を資格ベースに転換し、高リスクイベントの通知とアクセスレビューでループを閉じます。

Graph API 呼び出しの基礎(認証、スロットリング、ページネーション)は Microsoft Graph 実務入門トラックが前提なので、コードに馴染みがなければそちらを先にどうぞ。

まとめ #

  • 常時の管理者権限は攻撃面です。PIM で資格 + 時間制限付きアクティブ化(最大 8 時間)+ 理由の記録という構造に変え、常時権限は緊急アカウントだけ残します。
  • PIM は roleEligibilityScheduleRequests(資格割り当て)と roleAssignmentScheduleRequests(アクティブ化)で完全に API 管理でき、ロール割り当て可能グループとの組み合わせが実務パターンです。
  • 監査ログとサインインログは Graph で照会して高リスクイベントの通知を作り、規模が大きくなったら SIEM ストリーミングに昇格させます。
  • アクセスレビューは権限に賞味期限を与えます。無応答時の削除をデフォルトにし、ゲストと管理者ロールから適用します。
  • 導入の順序はユーザーライフサイクル → グループ → 条件付きアクセス → PIM・監査です。源泉データの整備が常に最初の一歩です。
X