退職者が使っていたアカウントが、退職後も有効なまま残っている——これは規模を問わず多くの企業で起きている状態です。アカウント管理システムの基本でも触れているとおり、アカウント管理の失敗が最も分かりやすく表れるのが退職者アカウントの放置です。この記事では、退職・異動というイベントが発生した時点で何を止めるべきか、そして対応漏れを繰り返さないためのルールの決め方を整理します。
退職者アカウントが放置されてしまう現場の理由
担当者が意図的に放置しているケースは多くありません。むしろ、業務上の事情から「消せない」状態になっていることが大半です。
- 引き継ぎのために残している — メールや作業中のファイルを後任が確認できるよう、一時的に残したまま期限が決まらずに放置される
- 共有フォルダやファイルの所有者になっている — 削除すると権限やデータの所有関係が壊れる懸念があり、手が止まる
- どの業務に紐づいているか分からない — 定期実行のバッチや外部サービスの連携に使われている可能性があり、消して業務が止まるのが怖い
- そもそも通知が来ていない — 人事側の退職手続きと、情報システム側のアカウント停止作業が連動していない
いずれも現場としては合理的な判断です。問題は、この「いったん残す」が期限も担当者も決まらないまま既定路線になってしまう点にあります。
放置されたアカウントが危険な理由
退職者アカウントのリスクは、大きく三つに分けて考えると整理しやすくなります。
- 退職者本人による利用 — 在職時の認証情報をそのまま使い、退職後に社内データへアクセスできてしまう場合があります。持ち出しが起きても、正規の認証情報でのログインであるため異常として検知しにくくなります
- 第三者による悪用 — 認証情報が外部に流出した場合、そのアカウントが有効である限り侵入口として使われ得ます(パスワード漏洩が招く影響も参照)
- 監視の目が向かない — 使われていないアカウントは、日常的に誰かが使っているアカウントと違い、不審なログインがあっても本人が違和感に気づく機会がありません。いわゆる休眠アカウントは、攻撃側から見れば発覚が遅れやすい足がかりになりがちです
「無効化」と「削除」を段階的に使い分ける
削除に踏み切れないことが放置の原因になっているのであれば、いきなり削除を目指す必要はありません。次の三段階に分けると、業務停止のリスクを抑えながら即時にリスクを下げられます。
- 1. 即時無効化 — 退職日をもってログインを不可にします。データやメールボックスは残るため、引き継ぎに必要な情報は失われません。まずここを確実に行うことが最優先です
- 2. 一定期間の保持 — 引き継ぎや監査対応のために、無効化した状態で一定期間保持します。保持期間は社内で明文化し、期限が来たら見直す運用にしておきます
- 3. 削除 — 保持期間を過ぎ、所有権の移管やデータの退避が完了したことを確認してから削除します
重要なのは、この「保持」の段階に期限と担当者を必ず付けることです。期限のない保持は、実質的に放置と同じ状態になります。
退職日までに止めるべき対象を洗い出す
無効化の対象は社内システムのIDだけではありません。実務上、次の範囲を一件ずつ確認する必要があります。
- OSログイン — 業務端末およびドメインアカウントのログイン停止。端末そのものの回収も併せて確認します(Windows OSログインの2要素認証も参照)
- VPN・リモートアクセス — 社外から社内網へ入る経路は、退職後も残っていると特に影響が大きくなります
- クラウドサービス・SaaS — 部門ごとに個別契約しているサービスは情報システム側の把握から漏れやすいため、退職者の所属部門にも確認します
- メール転送・自動応答の設定 — アカウントを無効化しても、個人の外部アドレスへの転送設定が残っていると情報が流れ続ける場合があります
- 共有アカウントの認証情報 — 退職者が知っていた共有IDのパスワードは変更が必要です。そもそも共有アカウントを減らす考え方は共有アカウントの廃止で扱っています
- 管理者権限・特権アカウント — 退職者が管理者権限を持っていた場合は影響範囲が広いため、優先して確認します(特権アカウントの管理も参照)
- 社外の人に発行したアカウント — 共有のために招待した取引先のIDは、相手先での退職を自社では把握できません。棚卸しの手順はゲストアカウントの棚卸しで扱っています
退職日に行う操作（Active Directory・Microsoft 365・PC本体）
ここからは、退職日に実際に行う操作です。環境ごとに操作する場所が分かれているため、1人の退職で、次の操作が環境の数だけ発生します。
Active Directory：無効化してから、退職者用のOUへ移す
「Active Directory ユーザーとコンピューター」で対象のユーザーを右クリックし、「アカウントを無効にする」を選びます。PowerShellでは次のとおりです。
Disable-ADAccount -Identity ユーザー名
Get-ADUser ユーザー名 -Properties Enabled, LastLogonDate | Select-Object Name, Enabled, LastLogonDate無効化したアカウントは「退職者」などのOUにまとめて移しておくと、保持期限の管理と後の削除が楽になります。
注意：ADで無効化しても、社外にあるノートPCにはサインインできることがあります。ドメイン参加のPCは、社内ネットワークにつながっていないとき、前回サインインしたときの情報をPCの中で照合するためです。ノートPCは退職日までに回収するか、回収できない場合は後述のPC本体の対応も行います。
Microsoft 365（Entra ID）：サインインをブロックし、サインイン中の状態も切る
- Microsoft 365 管理センターで「ユーザー」→「アクティブなユーザー」を開き、対象のユーザーを選びます。
- 「サインインのブロック」を選び、ブロックします。
- 同じ画面の「すべてのセッションからサインアウトする」を実行します。ブロックだけでは、スマートフォンのメールアプリなど、すでにサインインしている端末からしばらく使えることがあります。
- メールを後任が確認する場合は、メールボックスを共有メールボックスに変換してから、ライセンスを外します。
Microsoft Graph PowerShellでは次のとおりです。
Update-MgUser -UserId user@example.co.jp -AccountEnabled:$false
Revoke-MgUserSignInSession -UserId user@example.co.jp転送ルールや外部への自動転送が設定されていないかも、この時点で確認します。確認の場所は不審なサインインを検知したときの対処手順の転送ルールの項目と同じです。
PC本体：ローカルアカウントを止める
ドメインに参加していないPCや、PCに個別に作ったアカウントは、そのPCで止めるしかありません。管理者として開いたコマンドプロンプトで次のように入力します。
net user ユーザー名 /active:noそのPCにどんなアカウントがあるかは、PowerShellの Get-LocalUser | Select-Object Name, Enabled, LastLogon で一覧にできます。退職者が知っていたローカル管理者のパスワードも変更します。全PCで同じパスワードになっている場合の問題はローカル管理者パスワードの管理で扱っています。
操作の場所が多いこと自体が、漏れの原因になる
AD、Microsoft 365、PC本体、VPN、部門のクラウドサービス。ログインの入口が分かれているほど、退職1人あたりの操作は増え、どこか1か所の止め忘れが起きやすくなります。チェックリストで漏れは減らせますが、操作の数そのものは減りません。退職のたびに担当者が複数の管理画面を回っているなら、入口をまとめて「1か所で止めれば全部止まる」状態に近づけることが、手間と漏れを同時に減らす方法です。
対応漏れを繰り返さないためのルール化
一度きりの対応で終わらせず、次の退職者でも同じ品質で処理できるようにするには、次の三点を決めておくと運用として回りやすくなります。
- 人事からの通知をトリガーにする — 退職・異動が決まった時点で情報システム担当へ通知が届く流れを作ります。担当者が個別に聞いて回る運用では漏れが発生しがちです
- チェックリスト化する — 前項の対象一覧をそのままチェックリストにし、誰が対応してもすべての項目を確認したことが残るようにします
- 定期棚卸しと二重の網にする — イベント時の対応をすり抜けたアカウントを拾うため、定期的な棚卸しを併用します。棚卸しの頻度や手順はアカウントの棚卸しで解説しています
なお、退職時だけでなく入社・異動を含めた一連の流れとして設計したい場合は、IDライフサイクル管理も併せてご覧ください。
削除漏れが起きる箇所と、それを潰す確認方法
ルールを決めても漏れは出ます。漏れは「忘れた」から起きるのではなく、情報システム側が存在を知らないアカウントから起きます。次の4か所は、人事からの退職通知だけでは拾えません。
| 漏れが起きる箇所 | 確認方法 |
|---|---|
| 部門が個別契約したクラウドサービス | 経費精算の記録から契約中のサービスを洗い出す。情報システムの台帳だけでは出てきません |
| 氏名と紐づかないアカウント | 共有ID・作業用IDは退職者と結びつかないため通知では拾えません。共有アカウントの廃止を参照 |
| 外部の人に発行したアカウント | 相手先での退職は自社では分かりません。ゲストアカウントの棚卸し |
| 機器・システムのローカルアカウント | サーバーやネットワーク機器に直接作られたIDは中央の管理下にありません |
漏れを徹底して潰す唯一の方法は、通知に頼らず定期的に全件を突き合わせることです。在籍者名簿と有効なアカウントの一覧を並べ、どちらか片方にしかないものを洗い出します。年に1〜2回で十分ですが、「最終ログインから一定期間動きがないアカウント」を先に見ると効率が上がります。実際の抽出手順はIDの棚卸しと監査にまとめました。
なお、突き合わせで出てきた不明なアカウントを、その場で削除しないでください。まず無効化して数週間置き、問い合わせが来ないことを確認してから削除します。稼働中の処理が使っていたアカウントだった場合、削除は元に戻せません。
いまの運用を棚卸ししてみる
退職者アカウントの対応が仕組みとして回っているかどうかは、通知の流れとチェックリストが整っているかで大きく変わります。applippliの無料棚卸しでは、10問・約3分で、自社のID・アカウント管理の対応状況を「解決済み／一部解決／人手で対応／未解決」に仕分けた一覧にできます。