入社・異動・退職を自動化し、アカウントライフサイクルを途切れなく管理する方法
入社・異動・退職で変化するSaaSアカウントと権限を、JMLワークフロー、SSO、SCIM、MFA、監査ログで一貫して管理する方法を解説します。
ユーザーアカウントのリスクは、ログイン時だけに発生するものではありません。入社初日に必要なアプリを利用できない、異動後も前の部署の権限が残る、退職者の外部SaaSアカウントが数日間有効なままになる、といった問題があります。この三つの変更をJML（Joiner・Mover・Leaver）という一つのライフサイクルで管理することが重要です。
近年のIAMでは、認証機能を追加するだけでなく、人、アプリ、権限の変化を継続的に統制する考え方が重視されています。自動化の目的はアカウントを速く作ることではありません。承認された状態をすべての接続先へ同じ基準で反映し、その結果を記録することです。
JMLの各段階で必要な統制は異なる
Joiner：初回ログイン前に最小権限を準備する
所属、役割、入社日を基準にグループとアプリを割り当て、MFA登録を求めます。OIDC・SAMLアプリはSSOポリシーへ接続しますが、初回ログインだけで不要なアプリまで作成されないよう、初期権限は狭く設定します。アカウント作成と業務アクセスの許可も分けて考えましょう。
Mover：新しい権限の追加より古い権限の失効を優先する
異動やプロジェクト変更時に新しいグループだけを追加すると、権限は増え続けます。変更前後のグループとアプリ割り当てを比較し、以前の役割によるアクセスを外してから新しい権限を適用します。グループベースのアプリアクセスポリシーを基準にすれば、ユーザーごとの例外を減らせます。
Leaver：中央ログインと外部アカウントを同時に閉じる
IdPのユーザーを停止しても、SaaSのローカルセッション、SCIMアカウント、SWAのログイン情報が残れば、アクセス経路は完全には閉じません。退職イベントでSSOセッションとアプリ割り当てを失効し、接続先へ無効化を送った後、実際の反映まで確認します。詳しい手順はSCIMによるオフボーディングの自動化で確認できます。
安全な自動化に必要な三つの仕組み
承認、再試行、監査記録を分ける
自動化ルールには、誰がどの条件で変更を承認したか、一部のSaaS連携に失敗した場合はどこから再試行するか、最終結果をどう確認するかを含めます。一つのサービス障害によって退職処理全体を元に戻してはいけません。中央アクセスは直ちに遮断し、外部への反映失敗は別の対応項目として残す設計が安全です。
例外には所有者と期限を設定する
管理者アカウント、共有アカウント、SCIM非対応アプリは自動化から漏れやすい対象です。例外を認める場合も、責任者、理由、確認日を記録し、期限後に再点検します。定期的なアイデンティティドリフト点検を組み合わせれば、自動化の外で生じた差分も発見できます。
AxiPassでアカウント変更の始点と終点をつなぐ
AxiPassは、顧客企業ごとのマルチテナント環境でOIDC/SAML SSO、SCIMプロビジョニング、MFA、グループベースのアクセス、SWA、監査ログを一元管理できるよう支援します。まず退職のようなリスクの高い変更から標準化し、入社と異動にも同じユーザー・グループ・アプリ基準を広げてください。優れたJML自動化の完了条件は、処理の実行ではなく、必要なアクセスだけが残ったことの確認です。