退職者のアカウントが残る理由。無効化・セッション失効・データ移管を分けて止める

編集部の実務提案

退職対応は「削除」ではなく「アクセスの停止列」である

退職対応のゴールを「アカウントを消すこと」に置くと、危険な期間を見落とす。アカウントが存在しなくなることと、その人が業務データへ到達できなくなることは、同じではない。削除までの間に残る到達可能性こそがリスクであり、対応の設計は「いつ、どの経路が、どの順序で閉じるか」を決めることから始まる。

停止列は大きく4層に分かれる。第1にID基盤でのサインイン停止、第2に発行済みのセッションとトークンの失効、第3にID基盤と連携していないSaaSや業務システム側の利用停止、第4に端末や物理的な入館手段の回収である。層ごとに担当も効くまでの時間も違うため、一覧化して順序付けることが要る。

人事の退職確定と、ITの停止実行の間にも時間差がある。退職日が金曜の夜で、情シスの対応が月曜になる組織では、その週末が丸ごと露出する。退職の連絡を受けた時点で実行できる「先行停止」と、退職日に実行する「本停止」を分けて定義しておくと、曜日や担当者の不在に左右されなくなる。

緊急度でも分岐が要る。通常の円満退職と、アカウント侵害や懲戒を伴う退職では、求められる速度が違う。Microsoftのガイドが侵害と退職を同じ「全アクセス取消し」の文脈に置いているように、手順書には通常手順と緊急手順の2系統を用意し、発動条件を人事とあらかじめ合意しておく。

停止列の全体像を1枚のチェックリストにしておくことも重要である。項目ごとに実行者、実行時刻、確認方法を記入する欄を付け、退職のたびに使い回す。属人的な「覚えている範囲の対応」から、再現可能な手順へ変えることが、この記事全体の前提になる。

最後に、停止と保存は矛盾しない。アクセスを止めることと、業務データを保全することは別の判断である。訴訟や監査に備えた保全が必要なケースでは、アクセス停止と同時にデータの保全指示を出す。この切り分けを手順の冒頭に書いておくと、現場が「消すべきか残すべきか」で止まらなくなる。

担当の割り当ても停止列に含める。人事から連絡を受ける人、基盤を操作する人、各SaaSの管理画面を触る人、端末を受け取る人。小さな組織では兼任になるが、「誰がやるはずだったか」が曖昧な項目ほど漏れる。チェックリストの各行に担当欄を必須とし、空欄のまま開始しない運用にする。

本稿の手順は特定のID基盤の画面操作を説明するものではない。基盤ごとに用語や操作は異なるが、「止める対象を層で分ける」「効くまでの時間を前提にする」「連携外を台帳で管理する」という骨格は共通して使える。自社基盤の用語に読み替えて使ってほしい。

出典：[1]

編集部の実務提案

サインインの無効化とセッション失効は別の操作である

ID基盤でアカウントを無効化すると、新しいサインインは止まる。しかし、無効化の時点で有効だったセッションが、そのまま生き続けることがある。「ログイン画面ではじかれるのに、開いていたアプリでは作業できた」という現象は、この差から生まれる。無効化と失効は、手順書でも別の行にする。

Microsoftの手順では、管理センターでサインインをブロックすることと、「セッションを取り消す」操作が別々に示されている。基本の型は、サインインの無効化、更新トークンの失効、登録済みデバイスの無効化、という3点セットである。どれか一つで完了としないことが、退職対応の事故を防ぐ。

加えて、アプリ側が独自に発行したセッションは、ID基盤側から直接失効できない場合がある。ガイドも、アプリが発行したセッショントークンはアプリ側の認可ポリシーに基づいて取り消す必要があると述べている。つまり、基幹のID基盤で全てが止まるわけではなく、主要な業務アプリについては個別の失効手順を持っておく必要がある。

パスワードのリセットも位置付けを決めておく。無効化と組み合わせることで、資格情報の使い回しを断つ意味がある。特にハイブリッド環境では、同期の遅延を見越した扱いがガイドでも示されている。自社環境の同期サイクルを把握し、「基盤側で止めたがオンプレ側ではまだ有効」という窓を手順に織り込む。

実行の証跡も残す。無効化と失効の実行時刻を記録し、退職者本人の最終サインイン時刻と並べて確認する。後から「退職後にもアクセスがあったのでは」という疑義が出たときに、証跡の有無が調査の速度を決める。操作ログの保管先と保管期間も、手順書に併記しておきたい。

緊急時には順序も変わる。侵害が疑われる場合は、データ移管や連絡より先に無効化と失効を実行し、保全を並行させる。通常時と緊急時で「最初の一手」が違うことを、手順書の分岐として明記しておくと、現場の判断が速くなる。

失効の確認では、テスト用の検証も有効である。停止後に退職者アカウントでのサインイン試行が拒否されること、主要なアプリで既存セッションが切れることを、実機で確認して記録に残す。管理画面の表示だけで「止まった」と判断しないことが、確認工程の質を分ける。

出典：[1]

編集部の実務提案

トークンの寿命が「まだ入れる時間」を作る

失効操作をしても、アクセスが即座にゼロになるとは限らない。ガイドは、失効の開始から実際にアクセスが失われるまでに時間差が生じる場合があると注意している。この時間差の正体は、発行済みトークンの残り寿命である。Microsoft Entra IDのアクセストークンは既定で1時間有効であり、その間は既存のトークンでアクセスが継続し得る。

この性質を理解していないと、「止めたはずなのにログにアクセスが残っている」ことを事故と誤認したり、逆に本当の異常を見逃したりする。手順書には、基盤ごとの「失効が効くまでの目安時間」を記載しておく。目安が分かっていれば、確認のタイミングと判断基準がぶれない。

アプリの種類でも効き方は変わる。アクセストークンを使うアプリはトークンの期限で、セッショントークンを使うアプリはそのセッションの期限と基盤との同期頻度で決まる、とガイドは整理している。主要アプリごとに「どの種類か」「失効後どれくらいで閉じるか」を台帳に持つことが、退職対応の精度を上げる。

継続的アクセス評価（CAE）に対応したアプリでは、失効がほぼリアルタイムに反映される場合もある。自社の主要アプリが対応しているかを棚卸ししておくと、「即時停止が要る場面で使ってよいアプリ」と「時間差を前提にするアプリ」の線引きができる。

時間差を前提にした監視も要る。退職後の一定時間は、その利用者のサインイン試行とアクセスを重点的に確認する。失効の目安時間を過ぎてもアクセスが続くなら、それは時間差ではなく未対応の経路の存在を示す。再調査のトリガーを時間で定義しておくことが、確認作業を形骸化させない。

利用者側への説明も用意したい。退職当日に「まだメールが見える時間がある」ことは、仕組み上あり得る。関係者へ事前に時間差の存在を共有しておくと、現場の混乱と不要なエスカレーションを避けられる。

時間差の扱いは、関係部門との合意文書にも残しておく。退職当日に完全な遮断が仕組み上難しい範囲があるなら、その範囲と監視の強化策を人事と共有し、合意しておく。後から「なぜ即座に止めなかったのか」と問われたときに、技術的な前提と合意の記録が組織を守る。

出典：[1]

編集部の実務提案

連携外のSaaSは、手作業の台帳で止める

ID基盤とSSO連携しているSaaSは、基盤側の無効化と自動プロビジョニングで利用停止が伝播する。Microsoftのガイドは、自動プロビジョニングとデプロビジョニングの仕組みの導入を推奨し、その実行間隔は通常20〜40分ごとだと述べている。連携の有無と伝播の間隔を、SaaS台帳の属性として持っておくことが出発点である。

問題は連携していないSaaSである。部門が個別に契約したツール、無料プランから始まったツール、ID基盤の対象外になっている古い業務システム。これらは誰かが管理画面を開いて止めなければ、退職後も入り続けられる。台帳にないツールは、止めようがない。退職対応の質は、平時のSaaS台帳の質で決まる。

台帳には、ツール名、管理者、連携方式、デプロビジョニングの方法、退職時の操作担当、データの保管場所を記録する。操作が手作業のツールについては、退職チェックリストから台帳の該当行へリンクを張り、実行漏れを防ぐ。実行したらチェックリスト側に時刻を残す、という双方向の記録が要る。

自動化できないツールには、チケット起票の自動化だけでも効く。ガイドでも、自動デプロビジョニングに対応しないアプリ向けに、権利管理と連携してチケットを自動作成する発想が示されている。止める操作自体は手作業でも、「止めるべき事実の発生」を機械的に拾えれば漏れは減る。

契約者と利用者のずれにも注意する。部門契約のSaaSでは、管理者が退職者本人や部門担当であることが珍しくない。管理者権限の所在を台帳に含め、退職時に管理者の引き継ぎも同時に行う。止める人がいなくなる事態を先に潰しておく。

定期的な棚卸しで台帳を磨く。請求書やカード明細との突合、SSOの利用ログの確認、新規ツールの申請フロー。退職対応のたびに「台帳にないツールが見つかる」ことが続くなら、それは退職対応の問題ではなく、導入統制の問題である。

台帳の保守では、SSOのアプリ一覧と台帳の差分を機械的に出す仕組みが効く。SSOに登録されたのに台帳にないアプリ、台帳にあるのにSSOから消えたアプリ。差分の定期レポートを情シスの定例に組み込めば、台帳は退職対応のときだけ慌てて直すものではなくなる。

出典：[1]

編集部の実務提案

データの移管は、止める前に決めておく

アクセスを止める前に、その人のデータの行き先を決める。メール、ドキュメント、担当顧客の記録、進行中の案件ファイル。本人がいなくなってからでは、どこに何があるかを確認する手段自体が失われる。退職の連絡を受けた時点で、上長と「引き継ぐデータ」「保全するデータ」「破棄してよいデータ」の3区分を確定させる。

移管の方式もデータごとに違う。共有ドライブへ移すもの、後任へ所有権を移すもの、自動転送や代理アクセスで期間を区切って参照させるもの。無期限の転送や共有は、退職者の情報が流れ続ける経路になるため、期限と終了手順をセットで決める。

個人の領域と業務の領域の切り分けも要る。私的なファイルや個人宛の連絡まで一律に移管すると、プライバシー上の問題を生む。会社の規程に基づく範囲を事前に決め、線引きに迷う場合は人事・法務へ確認する経路を手順書に書いておく。現場の独断にしないことが、後日の紛争を防ぐ。

削除のタイミングは、移管と保全の完了後に置く。アカウントの保持期間を規程として決め、期間中はサインインを止めた状態で保持し、期間経過後に削除とデータの最終処理を行う。削除日を退職日と同一にしない設計が、引き継ぎ漏れと保全漏れの両方を防ぐ。

移管の完了確認は、受け手側で行う。後任が実際にファイルへアクセスできること、顧客対応の履歴が読めること、進行中案件の最新版が特定できること。「渡した」ではなく「使える状態になった」ことをもって完了とする。

顧客や取引先との接点情報も忘れがちである。退職者が窓口だった取引先への連絡、共有メールアドレスの担当変更、予約済みの会議の引き継ぎ。ITの停止列と業務の引き継ぎ列は別の表でよいが、同じ退職案件として進捗を突き合わせる場を一度は持つ。

移管では、進行中の自動処理や予約送信も対象に含める。退職者のアカウントで動いている定期ジョブ、共有されている自動返信、予約済みの配信。これらは本人がいなくなっても動き続け、事故や誤送信の原因になる。アカウント停止の前に「その人の名義で動き続けるもの」を洗い出す行を、チェックリストに加えておきたい。

出典：[1]

編集部の実務提案

端末と物理的な鍵は、IT台帳とつないで回収する

デジタルなアクセスを止めても、貸与端末の中に残ったデータは残る。端末の回収、端末内データの扱い、ワイプの実施は、退職対応の物理層である。ガイドでも、管理対象端末のリセットや、管理アプリからの業務データのワイプが、データ除去の手段として挙げられている。ただしオフラインの端末では、ローカルに保存されたデータへ到達できる点にも注意が要る。

回収の対象は端末だけではない。入館カード、セキュリティキー、貸与した周辺機器、紙の鍵。IT台帳と総務の貸与台帳を突き合わせ、回収漏れをゼロにする。特にセキュリティキーのような認証器は、回収しないまま放置すると認証基盤側の登録削除だけが頼りになるため、両側での処理を対にする。

私物端末の業務利用がある場合は、回収ではなくデータの分離で対応する。業務データの領域だけをワイプするのか、アプリの登録を解除するのかを規程で決めておく。退職当日に規程がないと、個人の端末を巡る交渉が発生し、対応が滞る。

回収できない場合の手順も先に決める。遠隔地勤務で返送が遅れる、紛失の申告がある、連絡が取れない。返送期限、遠隔ワイプの発動条件、紛失時の届け出。例外のパターンを列挙しておけば、当日の判断は「どのパターンか」を選ぶだけになる。

回収した端末の再利用にも注意する。初期化と再配布の手順を標準化し、前任者のデータや登録が残らない状態で次へ渡す。退職対応の終わりは、次の入社対応の始まりとつながっている。

回収の記録は、資産管理の記録と一致させる。端末のシリアル番号、回収日、初期化の実施日、再配布先。退職対応のチェックリストと資産台帳の二重管理は齟齬のもとになるため、チェックリスト側は資産台帳への参照を持ち、状態そのものは台帳側で一元管理するのが扱いやすい。

出典：[1]

編集部の実務提案

退職後の残存チェックを、定例に組み込む

対応が終わった退職者について、一定期間後に「本当に全て閉じたか」を再確認する工程を置く。チェックの対象は、ID基盤のアカウント状態、主要SaaSのメンバー一覧、共有アカウントのパスワード変更、認証器の登録削除、転送設定の残存である。退職当日の確認と、後日の再確認は別の価値を持つ。

共有アカウントやサービスログインの扱いは、個人アカウントの停止だけでは終わらない。退職者が知っていた共有の資格情報は、その人の退職をもって変更するのが原則である。対象の洗い出しは難しいが、少なくとも管理者権限に触れる共有資格情報は、退職のたびに変更対象として列挙する。

再確認のタイミングは、トークンやプロビジョニングの伝播が完了した後、たとえば退職の翌営業日と1週間後に置く。2回目の確認で見つかる漏れは、台帳の不備として台帳側を直す。漏れを個人のミスで終わらせず、仕組みの改善へつなげることが、残存チェックの本来の目的である。

四半期ごとには、退職者全員分のアカウント残存を一括で棚卸しする。有効なまま残っているアカウント、所有者不明のアカウント、長期間未使用のアカウント。退職対応の漏れは、この定期棚卸しで初めて表面化することも多い。棚卸しの結果を台帳と手順書へ反映する。

最後に、対応記録を案件単位で保管する。誰の退職に、いつ、どの操作を行い、誰が確認したか。監査や事故調査で求められるのは、この地味な記録である。チェックリストを使い回す運用は、そのまま記録の蓄積になる。

残存チェックの結果は、件数で経営層にも見える形にする。四半期で何件の漏れが見つかり、台帳のどの属性が不足していたか。退職対応は地味な業務だが、漏れの傾向は組織のSaaS利用の統制状態そのものである。数字で示すことで、台帳整備への投資判断がしやすくなる。

退職対応の成熟は、特別な道具ではなく、この再確認が滞りなく回っているかどうかで測れる。

出典：[1]