結論：アカウントは「作る仕組み」だけでなく「消す仕組み」がないと、退職のたびに侵入口が増える

セキュリティ投資の議論は、ファイアウォールやEDRといった「守る道具」に集まりやすい。だが攻撃者にとって最も楽な侵入方法は、防御を破ることではなく、正規のIDとパスワードでログインすることである。退職者のVPN・SaaS・クラウドのアカウントが停止されないまま残り、「admin」「deploy」といった共有IDのパスワードが何年も引き継がれ続けている組織は、退職者が出るたびに「現役の鍵」を社外へ持ち出させているのと変わらない。

  • 退職者のアカウントが残ると、社外の人間が正規の認証情報でログインできる入口が恒久的に残る。
  • 共有IDは退職してもパスワードが変更されないことが多く、歴代の退職者全員が今も使える鍵を知っている状態になる。
  • 共有IDは誰の操作か追跡できないため、不正の検知も事後調査も内部統制上の説明もできない。
  • 失敗の原因は担当者の怠慢ではなく、「作る手順はあるのに消す手順がない」という業務構造の非対称にある。
  • 対策の柱は、退職日の即日停止を含むオフボーディング手順、定期棚卸し、共有IDの個人ID化、SSO/IDaaSによる一元管理の四つである。

この連載「セキュリティ対策の失敗図鑑」は、中堅・中小企業が陥りやすいセキュリティ対策の失敗を一類型ずつ分解している。第7回となる本稿が扱うのは、「アカウントの存在自体の管理」である。正しい利用者に対して認証をどこまで強くするか、例外を誰に認めるかという認証強度の例外運用は第8回のMFAを役員だけ免除する失敗で扱う。また、委託先や外部開発者のアクセス権を契約でどう縛るかは第4回のサプライチェーン侵入を契約で縛らない失敗の論点である。本稿はその手前、自社の判断だけで今日から直せる「そもそも存在してはいけないアカウントが存在し続けていないか」に焦点を絞る。

なぜ「消し忘れたID」が最高の侵入口になるのか

正規の認証情報によるログインは防御をすり抜ける

退職者のアカウントによるログインは、システムから見れば正規利用者のログインと区別がつかない。マルウェアも脆弱性攻撃も使わないため、不正侵入を検知する仕組みの多くが反応しにくい。攻撃側にとっては、防御を破るより放置されたアカウントの認証情報でログインするほうが確実で、痕跡も残りにくい。境界防御にどれだけ投資しても、正面玄関の鍵が外部に残っていれば迂回される。

「作る手順」はあるのに「消す手順」がない非対称

入社時のアカウント発行は、なければ業務が始まらないため確実に実行される。一方で退職時の停止は、アカウントが残っていても誰の業務も止まらないため、誰かの必須業務として定義されない限り後回しにされる。これが放置の構造的な原因である。人事は退職手続きを終えれば完了と考え、情報システム部門は連絡が来なければ動けず、現場は引き継ぎに追われて忘れる。「誰が、いつまでに、どの一覧に基づいて止めるか」を決めていない組織では、消し忘れは必然的に起きる。

台帳がなく「どこにIDがあるか」を誰も知らない

SaaSの普及で、アカウントは社内システムの中だけに存在するものではなくなった。部門が独自に契約したクラウドサービス、プロジェクト単位で発行した外部ツール、クラウドの管理コンソールやAPIキーまで、IDの置き場所は分散している。退職処理がメールと社内システムの停止だけで終わると、VPN・SaaS・クラウドのアカウントがそのまま残る。全アカウントの台帳がなければ、「全部止めたか」を確認する手段自体が存在しない。

共有IDは便利さとリスクが一緒に引き継がれる

「admin」「deploy」といった共有IDは、引き継ぎが楽なため重宝される。だがパスワードを変更すると利用者全員に影響するため、誰も変えたがらない。結果として、歴代の担当者から退職者まで、そのパスワードを知る人間が増え続ける。さらに共有IDの操作ログは「誰がやったか」を特定できないため、不正利用があっても検知できず、事故後の調査でも行為者を絞り込めない。内部統制やセキュリティ監査の観点でも、「重要システムの操作者を特定できない」状態は説明がつかない。

実例：CAMPFIREのGitHub不正アクセスが突き付けた「管理用アカウント」のリスク

2026年4月3日、クラウドファンディング大手CAMPFIREは、システム管理用GitHubアカウントへの不正アクセス被害を公表した。同社は不正アクセスの検知後、速やかに該当アカウントを無効化し、外部のセキュリティ専門機関と連携して調査を開始した。ユーザーの決済情報への直接的な影響は公表時点で確認されていないが、ソースコードや関連情報への不正閲覧が行われた可能性があるとされる。

注目すべきは、攻撃対象が個人の開発者アカウントではなく「システム管理用アカウント」だった点である。管理用アカウントは通常、複数のリポジトリへの広範な権限を持ち、一つの侵害が組織全体のコードベースを危険にさらす。そして管理用・共有のアカウントは、複数の担当者間での認証情報の共有、退職者のアクセス権の残存、多要素認証（MFA）設定の後回し、監視不足による不審なアクセスの検知遅れ、という問題を抱えやすい。まさに本稿が扱う失敗類型の縮図である。

教訓も明確で、「admin」「deploy」などの共有アカウントは廃止して個人アカウントに適切な権限を付与し操作の追跡可能性を確保すること、SSOを導入して退職者のアクセス権をIdP側で一括無効化できるようにすることが基本対策とされる。事件の経緯とGitHub側の具体的な設定項目はCAMPFIRE GitHub不正アクセス事件の解説で整理している。

開発基盤に限らず、VPN・SaaS・クラウドでも構造は同じで、広い権限を持つアカウントほど共有・放置されたときの被害が大きい。

退職時オフボーディング：即日停止チェックリスト

退職者アカウントの放置を防ぐ要点は、「退職日の終業をもって全アクセスを停止する」を原則にし、停止作業を人事手続きの一部として必須化することである。後日まとめて処理する運用は、その「後日」が来ないまま放置される。人事から情報システム部門への退職連絡の期日と様式を決め、次のチェックリストを退職一件ごとに消し込む。

  • 社内システム・ディレクトリサービスのアカウントを停止したか
  • VPN・リモートアクセスのアカウントと証明書を失効させたか
  • 業務で使う全SaaS（部門契約・プロジェクト契約を含む）のアカウントを停止したか
  • クラウドの管理コンソール・開発基盤のアカウントと権限を削除したか
  • 本人名義で発行したAPIキー・アクセストークンを失効させたか
  • 本人が知っている共有ID・サービスアカウントのパスワードを変更したか
  • 会社貸与端末・私物端末からの業務データアクセスを遮断したか
  • 入館証・物理鍵などの物理アクセスを回収したか
  • 委託先・取引先側に発行されている本人のアカウントの削除を依頼したか
  • 停止結果を台帳に記録し、第三者が完了を確認したか

注意したいのは六つ目の項目である。共有IDが残っている限り、本人のアカウントを全て止めても、本人が知っているパスワードは生きている。退職のたびに共有IDのパスワード変更を迫られる運用負担自体が、共有IDを廃止すべき理由でもある。

棚卸しと一元管理：消し忘れが起きない構造に変える

棚卸しの頻度と対象を決める

オフボーディング手順を整えても、過去の消し忘れと手順の漏れは残る。だから定期的な棚卸しで「在籍していない利用者のアカウント」「最終ログインが長期間ないアカウント」「用途不明の共有ID」を洗い出す。頻度は対象のリスクに応じて決める。目安を示す。

対象推奨頻度点検の観点
VPN・リモートアクセス四半期利用者の在籍照合、最終ログイン、不要証明書
クラウド管理コンソール・開発基盤四半期管理者権限の人数、在籍照合、権限の過剰
委託先・外部コラボレーター四半期契約状態との突合、契約終了後の残存
SaaS全般（部門契約を含む）半期利用者一覧と在籍の照合、未使用ライセンス
共有ID・サービスアカウント半期存続の必要性、知っている人の範囲、変更履歴
APIキー・トークン半期発行者・用途・失効期限の記録有無

外部から到達できる入口という意味では、アカウントの棚卸しはVPN機器や外部公開システムの棚卸しと表裏一体である。設備側の棚卸しはVPN・外部公開システムの棚卸しで扱っているため、あわせて年間の点検計画に組み込みたい。

共有IDは個人ID化し、残すものは管理を引き上げる

共有IDの根本対策は廃止である。個人ごとのIDに必要最小限の権限を付与すれば、操作の追跡可能性が確保され、退職時は本人のIDを止めるだけで済む。システムの制約などでやむを得ず残す共有ID・サービスアカウントは、台帳に用途と管理責任者を記録し、パスワードを金庫的な仕組みで管理して「人がパスワードを覚えている」状態をなくし、利用のたびに記録が残る形に引き上げる。

SSO/IDaaSで「止める場所」を一つにする

アカウントがシステムごとに散在している限り、停止漏れの可能性は消えない。SSO（シングルサインオン）とIDaaSで認証を一元化すれば、退職時はIdP側で一人を無効化するだけで、連携している全サービスへのアクセスを一括で止められる。CAMPFIREの事案の教訓として挙げられている「IdP側での一括無効化」は、まさにこの構造への転換である。主要IDaaSの選び方はIDaaS/SSOの比較で整理している。

さらに進めるなら、「社内ネットワークにいるから信頼する」のではなく、アクセスのたびに利用者と端末を検証するゼロトラストの考え方にID管理を位置づけ直すとよい。中小企業での進め方はゼロトラスト導入ガイドで解説しており、設計から導入までの支援はゼロトラスト導入支援で扱っている。

関連記事

よくある質問

Q1. 退職者のアカウントはいつまでに停止すべきか。

原則は退職日の終業時点での即日停止である。アカウントが残っている期間は、そのまま不正アクセスが可能な期間になるため、「後日まとめて」の運用は避けたい。即日停止を実現するには、人事から情報システム部門への退職連絡の期日をルール化し、停止対象の一覧（台帳）とチェックリストをあらかじめ用意しておく必要がある。円満退職かどうかにかかわらず、例外なく同じ手順を適用することが重要である。

Q2. 共有IDをすぐには廃止できない場合、何から手を付けるべきか。

まず共有IDの台帳化から始める。どの共有IDが、どのシステムに、何の用途で存在し、誰がパスワードを知っているかを一覧化するだけで、リスクの大きさが見える。次に、廃止できるものから個人IDへ切り替え、残すものは管理責任者を決めてパスワードを定期変更し、退職者が出た際の変更を必須化する。広い権限を持つ管理用の共有IDから優先して着手するのが効果的である。

Q3. SSOやIDaaSを導入すれば退職者アカウントの問題は解決するか。

大部分は解決に近づくが、それだけでは完結しない。IdPで一括無効化できるのは連携済みのサービスだけであり、未連携のSaaSやローカルアカウント、APIキー、共有IDは個別に止める必要が残る。したがってSSO/IDaaSの導入と、オフボーディング手順・定期棚卸しは併用が前提である。導入時は、退職処理で漏れやすいVPNや主要SaaSから優先的に連携対象へ組み込むとよい。

Q4. アカウント棚卸しはどの範囲を対象にすればよいか。

社内システムだけでなく、VPN・リモートアクセス、部門契約を含むSaaS、クラウドの管理コンソール、開発基盤、APIキー・トークン、委託先に発行してもらっているアカウントまでを対象にする。観点は「在籍していない利用者」「長期間使われていないID」「用途不明の共有ID」の三つである。外部から到達できる入口と強い権限を持つものは四半期、その他は半期程度とし、結果を台帳に反映して次回と比較できるようにする。

退職者アカウントと共有IDの放置は、道具を買い足さなくても、手順と台帳と一元管理で確実に潰せる失敗である。一方で、IDの散らばりの洗い出しやSSO/IDaaS・ゼロトラストへの移行設計は、自社だけでは手が回りにくい。GXOではID管理の現状整理からゼロトラスト導入までを一貫して支援しているので、退職処理の抜け漏れや共有IDの整理に不安があれば、無料相談から自社のアカウント管理の現在地を一緒に棚卸ししてほしい。

出典