「もう退職した人のアカウントが、まだ有効なまま残っている」

しかも本人は使っていないので誰も気づきません。
監査ログにも動きがないから、棚卸ししない限り存在すら忘れられる。
これが 孤立アカウント（Orphaned Account） です。

今回は「なぜ孤立アカウントが生まれるのか」と「人手に頼らず防ぐ仕組み」を整理します。

1. 孤立アカウントは"最も狙われる入口"

孤立アカウントとは、本来は不要になったのに有効なまま残っているアカウントです。
退職者、異動者、終了したプロジェクトのゲスト、使われなくなったサービスアカウント——発生源はさまざまです。

なぜ危険か。攻撃者は、ゼロデイを探すよりも正規の認証情報でログインすることを好むからです。
孤立アカウントは、

  • 誰も監視していない（オーナー不在）
  • パスワード変更もMFA再登録もされない
  • 動きがないので異常検知に引っかかりにくい

という、攻撃者にとって理想的な侵入経路になります。
「退職者アカウントが半年後に侵害の起点として発見された」という事故は、決して珍しくありません。

2. なぜ手作業のオフボーディングは必ず漏れるのか

退職処理は、たいてい人手のチェックリストで運用されています。
そして、ここに構造的な穴があります。

  • 主要なSaaS（メール・チャット）は無効化しても、周辺のSaaSが取り残される
  • HR部門・情シス・各サービス管理者が別々に動くため、誰かが止めたつもりになる
  • 派遣・業務委託・ゲストアカウントはそもそも台帳に載っていない
  • 「念のため当面残す」が、そのまま放置される

人間が頑張る限り、組織が使うSaaSの数だけ漏れる確率は増えます。
これは権限の棚卸しと同じで、「人の努力で維持する仕組みは破綻する」のです。

3. 解決の中核は SCIM による自動連携

ここで鍵になるのが SCIM（System for Cross-domain Identity Management） です。

SCIMは、HRシステムやIdP（Entra ID / Okta / Google Workspace等）で起きた
「入社・異動・退職」というイベントを、各SaaSへのAPI操作に自動変換する標準仕様です。

  • 入社 → 各SaaSにアカウントを自動作成（プロビジョニング）
  • 異動 → 所属に応じて権限を自動で付け替え
  • 退職 → IdPで無効化した瞬間、連携先SaaSも準リアルタイムで一斉に停止（デプロビジョニング）

つまり「IdPを正（Source of Truth）」とし、そこを止めれば全部止まる、という状態を作ります。
これにより、認証情報が露出している"窓"の時間を最小化できます。

4. 「IdP管理外」のSaaSをどう捕まえるか

SCIMだけでは終わりません。最大の盲点は SCIM非対応・IdP未連携のSaaS です。
現場が勝手に契約したシャドーITは、退職処理のスコープに入っていません。

ここは可視化から始めます。

  • SSOログイン・OAuth連携の状況から、実際に使われているSaaSを棚卸しする
  • IdP連携できるものはSCIM/SSOに寄せる
  • 連携できないSaaSは「退職処理チェックリスト」に明示的に登録し、責任者を決める
  • 全アカウントにオーナー（管理責任者）を必須化し、オーナー不在＝孤立、として検出する

「台帳に無いから止め忘れる」を防ぐには、台帳そのものを実態に合わせ続ける必要があります。

5. 「退職時」だけでなく「継続的に」検出する

オフボーディングを完璧にしても、過去の遺産や設定ミスで孤立アカウントは生まれます。
だから検出を継続プロセスにするのが2026年の標準です。

設計方針はこうです。

  • 一定期間（例：90日）ログインの無いアカウントを自動フラグ
  • オーナー不在のアカウントを定期的に洗い出す
  • サービスアカウント・APIトークンも対象に含める（人だけが対象ではない）
  • 検出結果はSIEMに集約し、対応状況を追跡する

「退職処理」という点のイベントだけでなく、「常に最小限を保つ」という面の運用に変えるイメージです。
これは権限管理でお話しした “棚卸しを卒業する” という思想とまったく同じです。

6. 目指す状態

人手のオフボーディングを、こう置き換えます。

  • 入退社・異動は HR/IdP起点で自動反映（SCIM）
  • IdP連携できないSaaSは 台帳＋オーナー必須で漏れを構造的に防ぐ
  • 休眠・オーナー不在アカウントは 継続検出してSIEMで追跡
  • サービスアカウント・トークンもライフサイクル管理の対象に含める

これにより、「退職者アカウントが半年後に発見される」という事故は、仕組みとして起きなくなります。

7. Colorkrew Securityの考え方

孤立アカウントは、特別な攻撃ではなく運用の隙間から生まれます。
そして運用の隙間は、人間の注意力では埋まりません。

アイデンティティのライフサイクルを自動化し、「作る・変える・消す」を仕組みに載せる。
これが、攻撃対象領域を増やし続けないための土台です。

参考にした最新記事