退職者アカウントの放置は危険｜削除・無効化の手順と再発を防ぐルール

退職者が使っていたアカウントが、退職後も有効なまま残っている——これは規模を問わず多くの企業で起きている状態です。アカウント管理システムの基本でも触れているとおり、アカウント管理の失敗が最も分かりやすく表れるのが退職者アカウントの放置です。この記事では、退職・異動というイベントが発生した時点で何を止めるべきか、そして対応漏れを繰り返さないためのルールの決め方を整理します。

退職者アカウントが放置されてしまう現場の理由

担当者が意図的に放置しているケースは多くありません。むしろ、業務上の事情から「消せない」状態になっていることが大半です。

• 引き継ぎのために残している — メールや作業中のファイルを後任が確認できるよう、一時的に残したまま期限が決まらずに放置される
• 共有フォルダやファイルの所有者になっている — 削除すると権限やデータの所有関係が壊れる懸念があり、手が止まる
• どの業務に紐づいているか分からない — 定期実行のバッチや外部サービスの連携に使われている可能性があり、消して業務が止まるのが怖い
• そもそも通知が来ていない — 人事側の退職手続きと、情報システム側のアカウント停止作業が連動していない

いずれも現場としては合理的な判断です。問題は、この「いったん残す」が期限も担当者も決まらないまま既定路線になってしまう点にあります。

放置されたアカウントが危険な理由

退職者アカウントのリスクは、大きく三つに分けて考えると整理しやすくなります。

• 退職者本人による利用 — 在職時の認証情報をそのまま使い、退職後に社内データへアクセスできてしまう場合があります。持ち出しが起きても、正規の認証情報でのログインであるため異常として検知しにくくなります
• 第三者による悪用 — 認証情報が外部に流出した場合、そのアカウントが有効である限り侵入口として使われ得ます(パスワード漏洩が招く影響も参照)
• 監視の目が向かない — 使われていないアカウントは、日常的に誰かが使っているアカウントと違い、不審なログインがあっても本人が違和感に気づく機会がありません。いわゆる休眠アカウントは、攻撃側から見れば発覚が遅れやすい足がかりになりがちです

「無効化」と「削除」を段階的に使い分ける

削除に踏み切れないことが放置の原因になっているのであれば、いきなり削除を目指す必要はありません。次の三段階に分けると、業務停止のリスクを抑えながら即時にリスクを下げられます。

• 1. 即時無効化 — 退職日をもってログインを不可にします。データやメールボックスは残るため、引き継ぎに必要な情報は失われません。まずここを確実に行うことが最優先です
• 2. 一定期間の保持 — 引き継ぎや監査対応のために、無効化した状態で一定期間保持します。保持期間は社内で明文化し、期限が来たら見直す運用にしておきます
• 3. 削除 — 保持期間を過ぎ、所有権の移管やデータの退避が完了したことを確認してから削除します

重要なのは、この「保持」の段階に期限と担当者を必ず付けることです。期限のない保持は、実質的に放置と同じ状態になります。

退職日までに止めるべき対象を洗い出す

無効化の対象は社内システムのIDだけではありません。実務上、次の範囲を一件ずつ確認する必要があります。

• OSログイン — 業務端末およびドメインアカウントのログイン停止。端末そのものの回収も併せて確認します(Windows OSログインの2要素認証も参照)
• VPN・リモートアクセス — 社外から社内網へ入る経路は、退職後も残っていると特に影響が大きくなります
• クラウドサービス・SaaS — 部門ごとに個別契約しているサービスは情報システム側の把握から漏れやすいため、退職者の所属部門にも確認します
• メール転送・自動応答の設定 — アカウントを無効化しても、個人の外部アドレスへの転送設定が残っていると情報が流れ続ける場合があります
• 共有アカウントの認証情報 — 退職者が知っていた共有IDのパスワードは変更が必要です。そもそも共有アカウントを減らす考え方は共有アカウントの廃止で扱っています
• 管理者権限・特権アカウント — 退職者が管理者権限を持っていた場合は影響範囲が広いため、優先して確認します(特権アカウントの管理も参照)
• 社外の人に発行したアカウント — 共有のために招待した取引先のIDは、相手先での退職を自社では把握できません。棚卸しの手順はゲストアカウントの棚卸しで扱っています

対応漏れを繰り返さないためのルール化

一度きりの対応で終わらせず、次の退職者でも同じ品質で処理できるようにするには、次の三点を決めておくと運用として回りやすくなります。

• 人事からの通知をトリガーにする — 退職・異動が決まった時点で情報システム担当へ通知が届く流れを作ります。担当者が個別に聞いて回る運用では漏れが発生しがちです
• チェックリスト化する — 前項の対象一覧をそのままチェックリストにし、誰が対応してもすべての項目を確認したことが残るようにします
• 定期棚卸しと二重の網にする — イベント時の対応をすり抜けたアカウントを拾うため、定期的な棚卸しを併用します。棚卸しの頻度や手順はアカウントの棚卸しで解説しています

なお、退職時だけでなく入社・異動を含めた一連の流れとして設計したい場合は、IDライフサイクル管理も併せてご覧ください。

削除漏れが起きる箇所と、それを潰す確認方法

ルールを決めても漏れは出ます。漏れは「忘れた」から起きるのではなく、情報システム側が存在を知らないアカウントから起きます。次の4か所は、人事からの退職通知だけでは拾えません。

漏れを徹底して潰す唯一の方法は、通知に頼らず定期的に全件を突き合わせることです。在籍者名簿と有効なアカウントの一覧を並べ、どちらか片方にしかないものを洗い出します。年に1〜2回で十分ですが、「最終ログインから一定期間動きがないアカウント」を先に見ると効率が上がります。実際の抽出手順はIDの棚卸しと監査にまとめました。

なお、突き合わせで出てきた不明なアカウントを、その場で削除しないでください。まず無効化して数週間置き、問い合わせが来ないことを確認してから削除します。稼働中の処理が使っていたアカウントだった場合、削除は元に戻せません。

まずは自社の状況を確認する

退職者アカウントの対応が仕組みとして回っているかどうかは、通知の流れとチェックリストが整っているかで大きく変わります。applippliの無料診断では、約3分の質問に回答するだけで、自社のID・アカウント管理の対応状況を確認できます。