こんにちは、運用支援チームの ryuya です。
前回の記事で、退職・異動・役職者の権限が減らない理由は共通で、増やす処理には要求元がいるが、減らす処理には要求元がいない、と書きました。今回はその続きです。先に結論を書くと、IdP でアカウントを止めても、SaaS 側の退職・異動対応が終わったとは限りません。SaaS ごとに、IdP での停止がどこまで届き、何が残るかを確かめ、残る操作に担当と期限を付ける必要があります。この記事では、IdP と連携していない SaaS から、IdP からアカウントの無効化まで連携している SaaS まで、SaaS ごとに、減らす処理をどこまで自動で回せるのか、何が手作業と責任として残るのかを整理します。製品を選ぶ記事ではなく、いまの環境で何を設計すればよいかを確かめる記事です。
入社・異動・退職に合わせて各システムのアカウントと権限を作成・変更・停止する ID 管理のうち、この記事で扱うのは異動・退職で権限を減らす側です。これを、IdP での無効化が SaaS にどこまで届くかで分類します。IdP を経由せず、API や iPaaS で SaaS を直接操作する構成も、後半で扱います。
忙しい人向けのまとめ
- IdP で止めても、SaaS 側の退職・異動対応が終わったとは限らない。SaaS ごとに、どこまで届き、何が残るかを確認し、残る操作に担当と期限を付けて台帳に書く
- SaaS ごとに、IdP での無効化が届かない A、新規ログインが止まる B、SaaS 側のアカウントの無効化まで届く C に分類する。人事システム連携は、これとは別に起点を自動化する仕組み
- 退職時の停止と異動時の旧権限の剥奪は、別々に連携範囲を確認する。API・iPaaS で補える操作もある。役職者の棚卸しは、権限ごとの責任者を決め、不要と判断した権限の剥奪まで確認する
- どの環境でも、要求元・承認者・起点・実行担当・停止期限・失敗検知を決める。事前に承認したルールに基づく判定は自動化できるが、ルールと例外の判断には組織が責任を持つ
どの環境でも決めることは同じ
前回の確認ポイントを、ここでは実装の言葉に置き換えます。権限を減らす処理では、次の 4 つを最後まで分けて考えます。
- 要求元と承認者（判断・責任）: 誰がその権限を不要と決め、誰がそれを認めるか
- 起点: どの連絡やデータの変更で、処理が始まるか
- 実行: 誰が、または何が、実際に権限を外すか
- 期限と失敗検知: いつまでに終え、終わらなかったことに誰が気づくか
環境が変わって置き換わるのは、起点（人の連絡から人事データの変更へ）と実行（人の操作から仕組みへ）です。自動化できるのは、連絡や操作だけではありません。「異動時は旧部署の標準権限を外す」のように事前に承認したルールに基づく判定も自動化でき、通常の処理を個別の承認待ちにする必要はありません。一方、ルールの妥当性や例外を判断し、その結果に責任を持つのは組織です。
旧権限の要否を判断するのは、その権限に責任を持つ業務・情報資産のオーナーです。元の所属部門長が担う場合もありますが、誰を責任者とするかは権限ごとに定めます。情シスは、定められたルールに基づく設定変更と、実行結果の確認を担います。ここが決まっていないと、自動化しても「誰も決めていない権限が自動で残る」状態になります。
自社の連携パターンを見極める
IdP でユーザーを無効化したとき、その効果が SaaS にどこまで届くかで、この記事では 3 つのパターンに整理します。会社の成熟度ではなく、SaaS ごとの連携の違いです。
| パターン | IdP で無効化したとき | 典型像 |
|---|---|---|
| A | SaaS には何も起きない | SSO 非対応や部門契約の SaaS。SaaS ごとのローカルアカウント |
| B | IdP 経由の新規ログインが止まる | SSO はあるが、IdP から SaaS 側の無効化までは連携していない |
| C | SCIM などで SaaS 側のアカウントが無効化される | IdP から SaaS へ、無効化まで連携している |
大事なのは、会社を 1 つに分類しないことです。同じ会社でも、SSO と SCIM に対応した主要 SaaS は C、対応していない SaaS や部門契約の SaaS は A、という併存が普通です。だから判定は SaaS ごとに行います。判定の基準は、アカウントを作っているかではなく、無効化まで連携しているかです。判定の結果は SaaS 台帳に書き込みます。
どのパターンでも、処理の起点は人事からの退職・異動の情報です。IdP がある環境では、人事システムから IdP への連携により、情シスが連絡を受けて IdP に入力する手間を減らせます。ただし、A の SaaS 側の停止・権限変更やチケットの起票を自動で始めるには、別途連携が必要です。また、業務委託やゲストなど人事マスターに載らない利用者は、契約台帳や利用期限など別の管理情報と連携して起点を自動化できます。その連携がなければ、人の連絡が起点になります。人事から IdP への連携の有無と、IdP から SaaS への反映範囲は別のことなので、台帳では別々に記録します。
パターン別に、何が自動で減り、何が残るか
3 つのパターンを、退職と異動で自動化できる範囲、別途対応・確認する範囲、主な機能で並べます。失敗検知と役職者の棚卸しはパターンによらず共通なので、次の節でまとめて扱います。
| パターン A | パターン B | パターン C | |
|---|---|---|---|
| 退職の自動化 | IdP 経由ではなし | IdP 経由の新規ログインの停止まで | SaaS 側の無効化まで |
| 異動の自動化 | IdP 経由ではなし | アプリ割り当て解除。SSO 時の権限連動は SaaS 次第 | 連携対象の属性・グループに基づく権限変更 |
| 別途対応・確認する範囲 | 各 SaaS の停止・権限変更・完了確認 | SaaS アカウント、連動しない権限 | 連携対象外・直接付与の権限 |
| 主な機能 | 手動運用。または管理 API・iPaaS | SSO。異動時は割り当てルールや権限連動も確認 | 無効化までのプロビジョニング。異動時は属性・グループ連動も確認 |
「別途対応・確認する範囲」は、必ず手作業になるという意味ではありません。追加の連携で自動化できる操作も含み、どのパターンでも SaaS 側の状態を確認して完了とします。
どのパターンでも、SaaS ごとに次の 4 点を確認し、台帳に書きます。IdP での停止が本当に届いたかは、この 4 点で決まります。
- 無効化の意味: SCIM のコアスキーマを定める RFC 7643 も、
active属性の確定的な意味はサービスプロバイダーが決めると書いています（4.1.1 節）。ログインだけ止まるのか、データへのアクセスも止まるのかを確認します - 既存セッションと発行済みトークン: IdP で止まるのは、基本的にはその IdP を通じた新たな認証です。SaaS 独自のログイン経路や既存セッション、発行済みの OAuth・API トークンまで一律に失効するとは限らないので、追加の失効手順を確認します（SSO と SCIM の役割の違いは2026年の今、なぜSSOが重要なのかでも整理しています）
- 反映時間: 人事情報の更新日時、異動の発効日時、アクセス停止日時は分けて扱います。同期周期と SaaS 側の反映時間を確認し、停止期限に間に合わない場合の代替手順も用意します
- 連携の対象範囲: プロビジョニングや割り当ての対象に入っていない利用者には、停止が届きません。対象から外れたときに SaaS 側で何が起きるか、割り当てを外したときに IdP 経由のログインも止まるか、管理者などの例外があるかも確認します
IdP を経由しない自動化（API・iPaaS）
SSO や SCIM に対応していない SaaS や、IdP がない環境でも、手作業を減らす道はあります。人事の連絡やチケット、人事システムのイベントを起点に、iPaaS や SaaS の管理 API で停止や権限変更を実行する構成です。表でいえば、A の実行を情シスの手作業から仕組みに置き換える形です。
いちばんの利点は、人が手順書を追う工程が減ることです。手順の抜け、設定の入力ミス、対応忘れを減らせ、実行結果をログとして残せます。ログは証跡になりますが、完了は SaaS 側が期待する状態になったことを確認して判定します。同じ仕組みで、在籍と各 SaaS のユーザーの突合も自動化できます。
条件は 3 つです。
- その SaaS が管理 API を公開していて、無効化や権限変更まで API でできること。一覧の取得しかできない SaaS もあります
- API の認証情報を安全に保管し、権限を必要最小にすること。連携用のトークンや認証情報は、アプリ自身の権限で動くものも、特定の利用者の権限を借りて動くものも、人の退職・異動と連動して止まるとは限りません。台帳と棚卸しの対象に入れます
- API のエラーや未実行を検知して人に戻す経路があること。前述の確認 4 点は、この構成でも同じです
台帳の連携方式には「API／iPaaS」と書き、IdP 経由の連携と区別しておきます。
全パターン共通で決めること
パターンが違っても、次の 4 つは同じ形で決めます。
アクセス停止日時を退職日と分けて定義する
退職日は人事の日付で、アクセスを止める日時ではありません。停止日時を別に定義し、3 つの場合に分けます。
- 通常の退職: 最終出社日の終業後など、社内で 1 つに決める
- 即時停止: 解雇など非自発的な退職や高リスクの退職。個別の承認を待たず、事前に承認済みのルールで実行できるようにしておく
- 引き継ぎ・データ保全: 退職者本人のアクセスは停止し、必要なデータやアカウントを期限付きで保持する。所有権や管理権限は後任へ移管し、保持理由・承認者・削除予定日を記録する。停止経路が無効化ではなく SaaS 側のアカウント削除を実行する構成では、保持すべきデータが消えないかを実行前に確認する。本人による継続利用が必要な場合は別の例外として、契約関係・利用範囲・期限を再承認する
期限は「何日以内」を標準として示すものではなく、自社の停止日時の定義に対して守れたかどうかで測ります。
役職者の棚卸しは、管理者ロールの確認だけでは終わらない
IdP の管理者ロールの一覧だけでは、役職者の棚卸しは完結しません。棚卸しの対象は、管理者権限だけでなく、役職に伴う閲覧権限や承認権限、兼務やプロジェクトで足された権限、以前の所属から残った権限です。この多くは SaaS 側にあり、IdP の一覧には出ません。
どのパターンでも、役職者の棚卸しは責任者の設計から始まります。役職の上下だけで承認者を決めず、対象者本人の自己承認を避け、権限の必要性を判断できる責任者を権限ごとに割り当てます。レビューは台帳とチケットでも運用でき、アクセスレビューの機能があれば効率化できます。どちらでも、レビューの結果が剥奪まで到達して初めて棚卸しが終わります。承認者を誰にするかは、製品ではなく組織が決めます。
失敗検知は、処理が始まらない場合も含めて組む
- 起票の確認。人事上の対象者ごとに、停止処理やチケットが作成されているかを確認する。起票されなかった退職者は、完了確認では拾えない
- 処理ごとの完了確認。連携が正常終了しただけでなく、SaaS 側が期待する状態になったことを閉じる条件にする
- 期限超過の通知と担当。停止日時を過ぎて未完了のものを担当者と上長に通知し、誰が再実行や手動停止をし、誰へエスカレーションするかを決めておく
- 補助的な点検。在籍と所属は人事情報と、権限は承認済みの権限ルールや例外台帳と、ユーザー単位で突き合わせる。人数の一致では検知できない残存を拾う。頻度は運用例として月 1 回
SaaS 台帳に持つ項目
ここまでの設計は、SaaS ごとの台帳に落ちます。項目の例は次のとおりです。SaaS／テナント、権限オーナー、停止対象、連携方式（人事連携の有無と SaaS 側への反映範囲を別々に）、自動化範囲、反映時間、残る操作、完了証跡、失敗時の担当者、例外の期限。IdP 側に機能があっても、SaaS 側で SSO や SCIM が上位プラン限定のことがあるので、その SaaS が SSO と SCIM に対応しているか、対応がプランで縛られていないかも書いておくと、後で困りません。
おわりに
3 つのパターンを並べると、連絡や操作だけでなく事前に承認したルールの判定まで仕組みに置き換えられる一方で、ルールと例外を判断する責任は組織に残る、という形が見えます。退職の停止は、SaaS 側の無効化まで連携を組めば自動で届きます。異動や役職者の権限見直しでは、製品の連携範囲だけでなく、誰が不要と判断し、どのルールで外すかという責任設計が課題になります。
まず SaaS を 1 つ選び、退職時の停止経路・反映時間・残る操作・完了証跡を台帳に記録します。異動時に旧権限を外す経路も別に確認し、自動で届かない操作の担当者と期限を決めます。そのうえで、起点や実行を仕組みに置き換えられる箇所を検討します。製品を選ぶ前に、自社の処理と責任をこの順序で整理することから始めてください。
参考情報
- 情報源名：RFC 7643 System for Cross-domain Identity Management: Core Schema／発行元：IETF／種類：一次（標準化団体の文書）／公開日：2015年9月／URL：https://www.rfc-editor.org/rfc/rfc7643.html
- 情報源名：退職・異動・役職者の権限は、誰が減らすのか。CISAの内部脅威対策ガイド改訂を機に確認する6点／発行元：クラウドネイティブ／種類：自社ブログ／公開日：2026年9月24日／URL：https://blog.cloudnative.co.jp/articles/who-removes-access-insider-threat-guide-2026/
- 情報源名：2026年の今、なぜSSOが重要なのか／発行元：クラウドネイティブ／種類：自社ブログ／公開日：2026年6月6日／URL：https://blog.cloudnative.co.jp/articles/why-sso-matters-in-2026/
