はじめに

退職者のアカウントを削除し忘れていた——この問題を他人事と感じている情シス担当者は、実際のところ多くないかもしれません。しかし複数のSaaSを管理している環境では、退職者のアカウントが気づかないまま残り続けているケースは珍しくありません。

放置されたアカウントは「孤立アカウント」と呼ばれ、情報セキュリティ上の深刻なリスクです。正規のアカウントとして存在するため、攻撃者がそのまま社内システムへの入り口として悪用できます。多くのセキュリティインシデントで、孤立アカウントが侵入経路として使われたことが報告されています。

本記事では、孤立アカウントの定義・発生原因・セキュリティリスク・発見方法・削除手順まで、実務で必要な情報を体系的に解説します。

孤立アカウントとは

孤立アカウントとは、有効な利用者が存在しない状態のまま放置されているユーザーアカウントのことです。英語では「orphaned account」または「dormant account」と呼ばれます。

典型的なケースは退職者のアカウントです。従業員が退職した際に、情シスがSaaSや社内システムのアカウントを削除・無効化し忘れると、「誰も使っていないが、システム上は有効」という状態になります。これが孤立アカウントです。

退職者に限らず、長期休職者・出向者・プロジェクト終了後の外部委託者など、組織との関係が変化したにも関わらずアカウント処理が行われない場合にも発生します。

孤立アカウントが生まれる主なパターン

孤立アカウントはさまざまな場面で生まれます。どのような状況で発生するかを把握しておくことが、予防策の出発点です。

• 退職時にアカウント削除の対応が漏れた
• 異動時に旧部署のSaaSアクセス権限を削除しなかった
• プロジェクト終了後に付与した一時権限を削除しなかった
• 組織再編でシステムの引き継ぎが不完全だった
• 部署で独自に導入したSaaSが情シスに把握されていなかった（シャドーIT）
• 外部委託者・業務委託者のアカウントが契約終了後も残存した

管理対象のSaaSが多い環境では、退職時にすべてのSaaSのアカウント削除を完結させることが難しくなります。一元管理の仕組みがないと、どこかで必ず見落としが生じます。

孤立アカウントが引き起こすセキュリティリスク

孤立アカウントが放置されると、複数のリスクが生じます。これらは想定外のタイミングで顕在化するため、事前の対策が必要です。

リスク1: 外部攻撃者による不正利用

孤立アカウントは攻撃者にとって格好のターゲットです。有効な認証情報が存在するため、流出したID・パスワードを使い回すクレデンシャルスタッフィング攻撃やブルートフォース攻撃で突破された場合、正規ユーザーとして社内システムに侵入されます。

そのアカウントの権限範囲内で自由にデータを閲覧・取得できる状態になります。管理者権限の孤立アカウントが悪用されると、被害はさらに深刻です。

リスク2: 退職者・元従業員による不正アクセス

退職後もアカウントが有効なまま残っていれば、元従業員が自らのID・パスワードを使って社内システムにアクセスできます。悪意のある退職者による機密情報の持ち出しや、不正な設定変更のリスクがあります。

退社時のアカウント削除は、情報セキュリティの基本的な対策です。

リスク3: インシデント調査の複雑化

有効なアカウントが多く存在する環境では、セキュリティインシデントが発生した際の調査が複雑になります。不正操作がどのアカウントによって行われたかの追跡が困難になり、原因特定と被害範囲の確認に時間がかかります。

リスク4: コンプライアンス違反

ISMS（ISO27001）やSOX法対応では、アクセス権限の適切な管理と定期的な棚卸しが求められます。孤立アカウントの存在は、アクセス管理の不備として監査で指摘される原因となります。

リスク5: 不要なライセンスコストの発生

孤立アカウントはセキュリティリスクだけでなく、コスト上の問題も引き起こします。SaaSのライセンスはアカウント数に基づいて課金されることが多く、使われていないアカウントが残り続けると、その分のコストが無駄に発生します。

孤立アカウントが増える構造的な原因

孤立アカウントは担当者の不注意だけで生まれるわけではありません。情シス部門が抱える構造的な課題が背景にあります。

管理対象SaaSの増加による死角

社内で利用するSaaSの種類が増えると、すべてのSaaSのアカウントを把握・管理することが難しくなります。退職時に主要なSaaSのアカウントは削除できても、使用頻度の低いSaaSや情シスが把握していないシャドーITのアカウントが残るケースが典型です。

関連記事SaaSセキュリティとは

人事情報と情シスの連携不足

退社情報が情シスに届くタイミングが遅れたり、情報共有のフローが不明確だったりすると、退社日を過ぎてもアカウントが有効なまま残ります。人事部門と情シスの連携体制が整っていないことが、孤立アカウント発生の根本原因のひとつです。

手作業管理の限界

アカウント管理をExcelや手作業で行っている環境では、担当者の交代や業務の繁忙期に対応が漏れやすくなります。管理台帳が最新の状態に保たれないまま運用されると、どのアカウントが有効でどれが孤立しているかの把握が困難になります。

孤立アカウントの発見方法

孤立アカウントを見つけるには、定期的な確認の仕組みが必要です。手動と自動の両アプローチを理解した上で、自社の状況に合った方法を選んでください。

手動での発見方法

SaaS管理プラットフォームがない環境でも、以下の手順で確認できます。

アカウント棚卸し（定期実施）では、各SaaSの管理画面からユーザー一覧を出力し、現在の在籍者リストと照合します。在籍者に存在しないアカウントが孤立アカウントの候補です。実施頻度は最低でも四半期に1回を推奨し、人事異動の多い時期（年度末・期初）の前後に実施すると漏れを早期に発見できます。

ログイン履歴の確認では、各SaaSの管理画面でログイン履歴を確認し、長期間（90日以上が目安）ログインされていないアカウントをリストアップします。在籍者であれば業務上の事情も考慮しながら、不要なアカウントかどうかを判断します。

自動化・ツールを使った発見方法

対象のSaaS数が増えると、手動対応には限界があります。SaaS管理プラットフォームを活用することで、孤立アカウントの発見を自動化できます。

SaaS管理プラットフォームは、連携しているすべてのSaaSのアカウント状況を一元的に可視化します。在籍者データと突合することで、孤立アカウントの候補を自動で検出できます。ジョーシスのプラットフォームでは、Access Reviewsの機能を通じて、全SaaSにわたるアクセス状況の定期レビューを効率化します。長期ログインなしのアカウントや在籍者リストと一致しないアカウントを自動で一覧表示し、対応を促すワークフローを実行できます。

退社・異動の情報が人事システムに登録されたタイミングで自動的に情シスへ通知が届き、アカウント無効化のトリガーとなる仕組みを構築することも有効です。SaaS管理プラットフォームと人事システムを連携させることで、人事変更に連動した自動通知・自動無効化が実現します。

孤立アカウントの削除・無効化手順

発見した孤立アカウントへの対応は慎重に進める必要があります。削除前の確認を怠ると、有効なアカウントを誤って削除してしまうリスクがあります。

Step1: 候補アカウントのリストアップと確認

孤立アカウントの候補を抽出したら、削除前に以下を確認します。

• 該当者が現在も在籍しているか（人事システムで確認）
• 業務上の事情（長期出張・育休・兼任など）でアカウントが未使用の可能性はないか
• システム間の連携に使うサービスアカウントではないか

確認なしに削除すると、業務上必要なアカウントを誤って削除する可能性があります。特にサービスアカウントはユーザーアカウントと見分けがつきにくいため、注意が必要です。

Step2: 対応方針の決定（無効化か削除か）

孤立アカウントへの対応は、一律に削除するのではなく状況に応じて使い分けます。

無効化は、削除前の一時的な措置として、または業務引き継ぎデータを確認するために一定期間残す必要がある場合に選択します。削除は、引き継ぎが完了し、アカウントが完全に不要と確認できた段階で実施します。

退社時のデフォルト対応として「退社日当日に無効化し、一定期間（例として30日）経過後に削除する」というフローをあらかじめ設定しておくと、業務データの引き継ぎと迅速なセキュリティ対応を両立できます。

Step3: 削除・無効化の実施と記録

対応方針が決まったら、対象SaaSの管理画面から順次アカウントを無効化または削除します。複数のSaaSにアカウントが存在する場合は、すべてで対応が完了したかを記録に残します。記録に含めるべき情報は以下のとおりです。

• 対象アカウントのユーザー情報（氏名・所属・役職）
• 対象のSaaSとアカウントID
• 対応日時と対応者
• 無効化または削除の判断理由
• 削除前のアカウント権限の記録

Step4: 定期レビューの仕組みを整備する

孤立アカウントへの対応は一度では終わりません。新たな孤立アカウントが生まれ続けるため、定期的なレビューの仕組みが必要です。最低でも四半期に1回の棚卸しと、退社・異動時の即時対応フローの両方を整備することで、孤立アカウントの蓄積を防げます。

孤立アカウントを生まれにくくする予防策

孤立アカウントは発見・削除するだけでなく、そもそも生まれにくい体制を作ることが理想です。以下の予防策を組み合わせることで、発生リスクを大幅に低減できます。

退社時の対応フローを標準化する

退社が決まった段階で、情シスが対応すべきシステム一覧と手順を標準化します。「退社日の前日までに全SaaSのアカウントを無効化する」といった具体的な目標日を設定し、フローとして文書化します。

このフローを人事部門とも共有し、退社情報が情シスに届くタイミングを事前に合意しておくことが欠かせません。情報の伝達遅延が孤立アカウントの直接の発生原因になります。

人事システムとアカウント管理の連携

退社・異動の情報が人事システムに登録された時点で、自動的に情シスへ通知が届きアカウント無効化のトリガーとなる仕組みを構築します。SaaS管理プラットフォームと人事システムを連携させることで、手動対応なしに退社時のアカウント処理を自動化できます。

ジョーシスのプラットフォームでは、Access Automation機能を通じて、人事情報の変化をトリガーとした権限の付与・変更・削除を自動化できます。退社者のアカウントは退社日に合わせて自動で無効化されるため、手動対応の漏れが発生しません。

SSOによる一元的なアカウント管理

シングルサインオン（SSO）を導入し、IDプロバイダーで一元的にアカウントを管理することで、退社時にIDプロバイダー側で1つのアカウントを無効化するだけで、連携しているすべてのSaaSへのアクセスを停止できます。

ただしSSOに対応していないSaaSは死角になるため、SSSと合わせてSaaS管理プラットフォームでの全アカウント監視が必要です。‍

関連記事：SSO セキュリティ 限界

最小権限の原則による被害範囲の限定

孤立アカウントが発生した場合でも、そのアカウントに付与されている権限が最小限であれば、悪用された際の被害範囲を抑えられます。過剰な権限を持つアカウントを作らないという最小権限の原則が、孤立アカウントのリスク軽減にも機能します。

ジョーシスのプラットフォームによる孤立アカウント対策

孤立アカウントへの対応を手作業で行うには、管理するSaaSの種類が増えるほど限界があります。ジョーシスのプラットフォームは、孤立アカウントの発見・削除・予防を一元的に支援します。

全SaaSの横断的な可視化

ジョーシスのプラットフォームでは、連携しているすべてのSaaSのアカウント・権限状況をダッシュボードで一覧表示します。在籍者データと突合することで、孤立アカウントの候補を横断的に検出できます。各SaaSの管理画面をひとつひとつ確認していた作業が、一画面で完結します。

Access Automationによる退社時の自動対応

ジョーシスのAccess Automation機能では、退社情報をトリガーとして全SaaSのアカウントを自動で無効化します。人手に依存した対応では避けられない漏れや遅延がなくなり、退社日当日に確実なアカウント処理が完了します。

手動で複数のSaaSを個別に対応していた状態から、自動化によって情シスの工数を大幅に削減しながら、孤立アカウントの発生を防止できます。

Access Reviewsによる定期棚卸しの効率化

ジョーシスのAccess Reviews機能では、定期的なアクセスレビューを効率化します。長期ログインなしのアカウントや在籍者リストと一致しないアカウントを自動で検出し、対応を促すワークフローを実行できます。レビュー結果は記録として残り、ISMS対応などの監査証跡としても活用できます。

まとめ

孤立アカウントとは、退職者・異動者・外部委託者などの有効な利用者が存在しないにも関わらず放置されたユーザーアカウントです。攻撃者の侵入経路・元従業員による不正アクセス・コンプライアンス違反・不要なコストなど、複数の問題を引き起こします。

対応は3段階で進めます。棚卸しやログイン履歴の確認で孤立アカウントを発見し、無効化・削除を実施し、定期レビューと標準化フローで再発を防ぐ仕組みを整えます。

SaaSの種類が増える環境では、手動対応に限界があります。ジョーシスのプラットフォームは、横断的な可視化・退社時の自動処理・定期棚卸しの効率化を通じて、孤立アカウントのリスクを継続的に最小化します。まず自社のアカウント管理の現状を確認ところから始めてみてください。

無料デモを申し込む

参考情報

• 休眠アカウントの特定とリスク対策 | ジョーシス
• アクセス管理とは？| SmartStageサービスデスク
• アクセス権限はなぜ重要？| ワークフロー総研