退職者のアカウントが生きている本当の理由

TT Labで続きを見る

一言でいうと

退職者のアカウントが生き残る理由は、退職処理をしないからではなく、人事システムとアカウントシステムをつなぐプロビジョニングがないからです。SSOはこの問題を解決しません。

監査で最初に聞かれること

情報保護監査やISMS-Pの審査で、アカウントに関する質問は、ほぼ決まっています。

退職者のアカウントは、ただちに無効化されますか。根拠を見せてください。
管理者権限を持つアカウントの一覧と、付与の理由を見せてください。
直近Nか月間ログインがないアカウントを、どのように管理していますか。
アカウントの作成・変更・削除の履歴が残りますか。
人事システムとアカウントシステムの突合を、定期的に行っていますか。

5つ目が核心です。残りの4つの答えは、すべてこれから出てきます。そして、ほとんどの組織が5つ目を人がExcelで行っています。

幽霊アカウントはなぜ生まれるのか

「退職処理をしないから」ではありません。構造的な原因があります。

原因1: プロビジョニングがない

最大の原因です。SSOを導入したからといって、アカウントのライフサイクルが解決するわけではありません。

「退職者がSaaSにまだログインできる」事故の大部分は、SSOではなくプロビジョニングの不在が原因です。

SSOは、「ログインするときに誰かを確認」するだけです。そのシステムの中にユーザーレコードを作ったり消したりすることは別の仕事で、それを自動化する標準がSCIM(RFC 7644)です。

SCIMがないと、こうなります。人が辞めると、IdPではログインがブロックされます。ところが個別のシステムにはアカウントが残っていて、そのシステムにローカルのログイン経路が1つでもあれば、まだ入れます。そして、ほとんどのシステムには、「IdP障害時の非常用ログイン」という名前のローカル経路があります。

原因2: 増分同期は削除を見られない

前のモジュールで扱った内容です。「最近変更されたユーザー」を取得する方式は、消えたユーザーを見られません。全件同期を定期的に一緒に回さないと、退職者が残り続けます。

原因3: 人ではないアカウント

バッチ用のアカウント、連携用のアカウント、ベンダーの保守アカウント、テストアカウント。これらは人事システムにないので、突合の対象から自動的に外れます。そして、これらはたいてい権限が強いです。

監査で指摘の順位が高いのも、こちらです。「このアカウントは誰のものですか」→「以前ベンダーが使っていたもののようですが」。

原因4: 退職ではない異動

休職、派遣、協力会社の契約終了、部署異動。こうした状態の変化は、退職ほど明確なトリガーがありません。そのため、権限がそのままついて回ります。部署を移ったのに前の部署の権限が残っていることは、監査で「権限の蓄積(privilege creep)」として指摘されます。

突合を機械的に行う方法

人事名簿(HR)とアカウント一覧(ディレクトリ)を両側から取り出して、集合演算を行います。

A = HR 재직자 uid 집합
B = 디렉터리 계정 uid 집합

B - A  →  유령 계정 (퇴사했는데 계정이 남음)          ★ 1순위
A - B  →  미생성 계정 (입사했는데 계정이 없음)         업무 지연
A ∩ B  →  정상. 단 부서·직급 불일치는 따로 본다

このコードブロックの韓国語は、Aが人事の在籍者のuidの集合、Bがディレクトリのアカウントのuidの集合を表し、B - Aは退職したのにアカウントが残っている幽霊アカウントで最優先、A - Bは入社したのにアカウントがない未作成アカウントで業務の遅延、A ∩ Bは正常だが部署・役職の不一致は別に見る、という意味です。

ここに3つの軸を加えます。

権限の軸: 幽霊アカウントのうち管理者グループに所属しているもの → 即時対応の対象
時間の軸: 90日以上ログインがない → 休眠処理の候補
属性の軸: HRの部署 ≠ ディレクトリの部署 → 人事異動が反映されていない

この5つの一覧を毎週自動で生成してメールで送れば、監査対応ではなく運用になります。手作業のExcel突合は四半期に1回行い、その間に事故が起きます。

アカウントの削除と無効化

退職者のアカウントは、削除してはいけません。理由が複数あります。

監査証跡: その人が残したデータの所有者情報が壊れます
法的な保存: 金融・医療などでは、アクセス履歴の保存期間が長いです
再入社: 同じ人が戻ってくる場合があります
参照整合性: 決裁ラインや、担当者の指定、文書の作成者にひも付いています

そのため、標準的な処理は隔離です。

1. 비활성화 (로그인 차단)          ← 즉시
2. 권한 그룹에서 제거              ← 즉시
3. 별도 OU 로 이동 (ou=Disabled)   ← 즉시
4. 사유·일자·처리자 기록           ← 즉시
5. 보존 기간 경과 후 삭제          ← 정책에 따라 (보통 1~5년)

このコードブロックの韓国語は、5つの処理を示しています。無効化(ログインをブロック)、権限グループから削除、別のOU(ou=Disabled)へ移動、理由・日付・処理者を記録は、いずれも即時、保存期間の経過後に削除は、ポリシーに従う(通常は1–5年)、という意味です。

項目3が実務的に有用です。隔離OUに移すと、「有効なユーザー」の検索フィルターから自動的に外れながらもデータは残ります。そして、隔離OUのエントリ数を数えるだけで、対応件数を報告できます。

権限付与の原則: グループだけを使う

個人に直接権限を付与し始めると、6か月後に誰も全体像がわかりません。原則は次のとおりです。

権限はロールグループにだけ付けます
人はロールグループのメンバーになります
個人の例外が必要なら、期限のある別のグループを作ります

そして、部署グループとロールグループを混ぜてはいけません。dev-teamは組織で、role-deployは権限です。組織再編はよく起こり、そのたびに権限が一緒に崩れてはいけません。

監査レポートに入れるべき5つの数字

レポートは長い必要はありません。この5つがあれば、対話が始まります。

項目	意味
全アカウント数	ベースライン
幽霊アカウント数	退職者の残存。0でなければなりません
未作成アカウント数	入社者の遅延。業務遅延の指標
特権アカウントのうち幽霊	最優先で対応
90日ログインなしのアカウント数	休眠の候補

数字があれば、トレンドを見られます。「幽霊アカウントが先月の12件から今月は3件」は、改善を証明します。数字がなければ、毎回最初から説明しなければなりません。

現場での姿

監査の質問5つのうち、最後の1つが核心です。「人事システムとアカウントシステムの突合を、定期的に行っていますか」。残りの4つの答えはすべてここから出てくるのに、ほとんどの組織がこれを人がExcelで行っています。

Excel突合の問題は、正確さではなく周期です。四半期に1回突き合わせる突合では、退職の翌日にアカウントが死にません。そして、その間のアクセスは記録としてだけ残ります。止められず、あとで発見するだけの統制です。

増分同期だけをかけている場合もよくありますが、これはさらに危険です。変更されたものだけを取得する方式は、削除を見られません。人事から消えた人は「変更」ではないので、永遠に流れてこず、アカウントは静かに残ります。

そのため、アカウントを削除する前に隔離する手続きが必要です。すぐに削除すると、その人が作った文書や決裁ラインも一緒に壊れ、元に戻すこともできません。