IDライフサイクル管理とは？入社・異動・退職で権限を正しく管理する方法

なぜライフサイクル管理がIAMの「穴」になるのか

IAM設計に取り組んでいるのに、気づけばリスクが積み上がっている。よくある話です。

原因のほとんどは、設計の問題ではなく「変化に追従できていない」ことにあります。

入社・異動・退職— —人の動きにあわせてアカウントや権限が変わるはずが、実際の現場では後回しになりがちです。「明日やろう」が積み重なり、退職から3ヶ月後もアカウントが生きていた、というケースは珍しくありません。

IAM（Identity and Access Management）
誰が・何に・どこまでアクセスできるかを管理する仕組み。
詳しくは「IAMとは？認証と認可の違いから学ぶアクセス管理の基本」を参照。

IAMの設計方針やチェックポイントを整理した記事はこちら： クラウドIAM設計チェックリスト｜抜け漏れを防ぐ実践ガイド

IDライフサイクルの4フェーズ（JMLR）

ライフサイクル管理は、4つのフェーズで整理すると分かりやすくなります。

それぞれのフェーズで「やるべきこと」が異なります。

JMLR（Joiner / Mover / Leaver / Reviewer）
IDライフサイクル管理の4フェーズを表す業界用語。IGA（Identity Governance and Administration）の文脈でよく使われる。

参考：Microsoft Identity Governance の概要

フェーズごとの具体的な対応手順

入社時（Joiner）：最初から最小権限で始める

入社時は「とりあえず広めに権限を付与してから後で絞る」運用になりがちです。しかし実際には、後から絞ることはほぼ行われません。

最初から役割に必要な権限だけを付与することが、長期的に見て最も安全で管理しやすい方法です。

具体的には以下を確認します。

• 役割ごとの標準権限セット（ロール）が定義されているか
• 作成手順が明文化されていて、属人的な対応になっていないか
• 管理者権限は通常アカウントと分離されているか

ロール（Role）
特定の役割に紐づいた権限のセット。個人ではなく役割単位で管理することで、異動・退職時の対応が容易になる。

最小権限の考え方については「最小権限の原則とは？実務での考え方と設計例」で詳しく解説しています。

IAM設計の基本的な型については「クラウドIAM設計の基本パターン」も参考にしてください。

入社フローの図（申請→承認→アカウント作成→ロール付与の流れ）

異動・役割変更時（Mover）：権限の「足し算」をやめる

異動時に最もよく起きる問題は、「前の部署の権限が残ったまま、新しい権限が追加される」パターンです。

人が移動するたびに権限が積み上がり、気づけば誰も把握できない状態になります。

対応として重要なのは以下の2点です。

• 役割変更時には必ず「削除すべき権限」を確認する
• 異動手続きとIAM変更がセットで走る仕組みを作る

権限の蓄積（Permission Creep）
異動や役割変更のたびに権限が増え続け、最終的に過剰な権限を持つ状態になること。定期棚卸しで対処するが、仕組みで防ぐのが理想。

異動時の権限放置が招く失敗パターンは「Azure RBAC設計でよくある失敗6選と対策」で具体例を紹介しています。

退職時（Leaver）：削除漏れが最大のリスク

退職者のアカウントが残っていることは、セキュリティリスクの中でも特に発見しにくい問題です。

ログを見ても「最近ログインがない」だけでは怪しまれず、長期間放置されます。

対応のポイントは以下のとおりです。

• 退職日に「即日無効化」、一定期間後に「完全削除」を行う
• 退職手続きと連動した無効化フローを整備する
• 無効化と削除は別のステップとして管理する

無効化（Disable）と削除（Delete）の違い
無効化はアカウントを残したままログインを禁止する処理。削除は完全に除去する処理。退職直後は無効化し、一定期間後に削除するのが一般的。

参考：Microsoft Entra ID でのユーザーアカウントの無効化

退職フローの図（退職申請→即日無効化→30日後削除のタイムライン）

定期棚卸し（Reviewer）：半年に1回でも大きく変わる

設計が正しくても、時間とともに実態は崩れていきます。定期的な棚卸しは、その崩れを発見するための唯一の手段です。

最低でも半年に1回、以下を確認することを推奨します。

• 不要になったアカウントが残っていないか
• 権限がロールの想定範囲を超えていないか
• 例外対応で付与した一時権限が放置されていないか

棚卸しのチェックポイントを一覧で確認したい場合は「クラウドIAM設計チェックリスト」を活用してください。

よくある失敗パターン3つ

① 異動後に権限が増え続けている

気づいたら1人のユーザーが複数部署の権限を持っていた——これはMoverのフローが機能していないサインです。異動のたびに削除チェックをしていないと、数年で収拾がつかなくなります。

② 退職者アカウントが数ヶ月残っていた

「人事から連絡が来るまで待っていた」「担当者が不在で対応が遅れた」——退職対応が人任せになっている場合に起きます。退職日に自動で無効化される仕組みが理想です。

③ 棚卸しをしたことがない

「設定したときは正しかった」が通用するのは構築直後だけです。人が動き、システムが変わり、例外が積み重なる中で、IAMは必ず実態と乖離していきます。

認証まわりの失敗パターンはこちらも参考にしてください： クラウドIAM設計でよくある失敗5選と対策

まとめ：ライフサイクル管理は「仕組み」で回す

IDライフサイクル管理は、知識として知っているだけでは不十分です。Joiner・Mover・Leaver・Reviewerの4フェーズを「仕組み」として運用の中に組み込むことが、長期的なセキュリティの土台になります。

設計は正しくても、人の動きに追従できなければリスクは必ず積み上がります。まずは「入社・退職時のフローが明文化されているか」を確認するところから始めてみてください。

IAM設計の全体像を改めて確認したい場合は以下もあわせてご覧ください。

• クラウドIAM設計の基本パターン
• クラウドIAM設計チェックリスト