退職者アカウントや委託終了者のSaaS権限が残っていた時に、まず何を止め、どのログを確認し、どこまで記録するかを実務手順で整理します。
残存アカウントは「削除漏れ」ではなく初動対応の入口
退職者、異動者、委託終了者のアカウントがSaaSやGitHubに残っていた。メール転送、外部共有、OAuthアプリ、APIトークンも残っているかもしれない。こうした状況では、単にアカウントを削除して終わらせるのではなく、まず「いつから、どの権限が、どのデータに触れられる状態だったか」を確認する必要がある。
この記事では、退職者アカウントや残存権限を見つけた時の初動対応を、防御・確認・記録の観点で整理する。攻撃再現や侵入手順ではなく、情シス、SaaS管理者、開発者、人事・総務が同じ判断基準で動けるようにするための実務ガイドである。
実際の作業表として使う場合は、退職者アカウント確認チェックリスト と SaaS権限棚卸しチェックリスト を併用すると確認漏れを減らせる。
不審な利用が疑われる場合、アカウント削除だけを急ぐと、監査ログ、所有物、共有設定、トークン利用状況の確認が難しくなることがある。緊急停止と証跡保全を分け、社内規程に沿って記録を残す。
読者別に起きる影響
退職者アカウントの残存は、担当部門ごとに見える問題が違う。誰か一人の作業にせず、関係者で影響範囲を切り分ける。
| 読者・担当 | 影響 | 最初に見ること |
|---|---|---|
| 情シス | SaaS、IdP、端末、メールの停止漏れ | IdPのユーザー状態、SSO対象外SaaS、最終サインイン |
| SaaS管理者 | 外部共有、OAuth同意、管理者ロールが残る | 監査ログ、共有リンク、連携アプリ、ゲストユーザー |
| 開発者・DevOps | GitHub、CI/CD、Deploy Key、個人トークンが残る | Organization membership、outside collaborator、PAT、SSH鍵、Webhook |
| 人事・総務 | 退職日、委託終了日、端末・貸与物回収と実作業がずれる | 最終出社日、契約終了日、例外承認、回収記録 |
| CSIRT | 不審アクセスやデータ持ち出し疑いの判断が必要になる | タイムライン、ログ保全、エスカレーション条件 |
Google Workspaceでは、アカウント停止と削除でデータや共有先への影響が異なる。GitHubでは、OrganizationやEnterpriseから外しても、private fork、outside collaborator、IdP/SCIM管理、個人アカウント由来の権限などを確認する必要がある。製品ごとの細部は変わるため、公式ドキュメントと自社の規程を確認しながら進める。
まず確認すること
残存権限を見つけたら、最初の15〜30分で次の項目を整理する。ここでは「誰が悪いか」ではなく、「どのアクセス経路が残っていたか」を明確にする。
| 確認項目 | 見るポイント | 記録すること |
|---|---|---|
| 対象者 | 退職者、異動者、委託終了者、長期休職者、外部ゲスト | 氏名またはID、所属、終了日、管理責任者 |
| 対象システム | IdP、メール、ファイル共有、SaaS、GitHub、クラウド、端末 | サービス名、アカウント状態、SSO/SCIM対象か |
| 権限の強さ | 一般ユーザー、管理者、請求管理、リポジトリ管理、外部共有可能権限 | できる操作、触れるデータ、管理者ロール |
| 最終利用 | 最終ログイン、最終API利用、最終コミット、最後の共有変更 | 時刻、IP、端末、操作、ログソース |
| 所有物 | ファイル、共有ドライブ、GitHubリポジトリ、Bot、Webhook、定期ジョブ | 移管先、停止可否、業務影響 |
| 継続アクセス | OAuth同意、APIトークン、SSH鍵、メール転送、共有リンク | 発行者、scope、最終利用、失効状況 |
この時点で重要なのは、「有効なアカウントがあった」だけでインシデントと断定しないことだ。一方で、最終利用や権限変更が退職日後にある場合、外部共有や管理者操作が残っている場合は、単なる事務ミスとして処理しない。
初動対応：止める、見る、残すを分ける
1. すぐ止めるもの
被害拡大につながる可能性が高い経路は、調査を待たずに停止・無効化を検討する。ただし、実施時刻と担当者を必ず記録する。
- IdPの対象ユーザーを無効化またはサインイン禁止にする。
- 全セッションの失効、MFA登録方法の確認、パスワードリセットを行う。
- SaaS上の管理者ロール、外部ゲスト、共有アカウントを一時停止する。
- OAuthアプリ、APIトークン、アプリパスワード、SSH鍵、Deploy Keyを棚卸し、不要なものを失効する。
- メール転送、代理送信、共有メールボックス、カレンダー委任を確認する。
2. 削除前に見るもの
削除や完全消去の前に、監査ログと所有物を確認する。後から説明できるよう、スクリーンショットよりも時刻、ID、ログ名、操作内容を記録する。
- 退職日・委託終了日以降のサインイン成功、失敗、MFA結果。
- SaaS監査ログ上の外部共有、権限変更、ファイルダウンロード、アプリ同意。
- GitHubのOrganization membership、team membership、outside collaborator、PATやSSH鍵の利用状況。
- 退職者が所有していたBot、Webhook、CI/CDジョブ、共有ドライブ、管理者アプリ。
- 削除すると業務停止する自動化や請求・監査・バックアップ関連の所有物。
3. 必ず残す記録
記録は「誰が、いつ、何を確認し、何を止めたか」を中心にする。秘密情報の値そのものは貼らない。
| 記録欄 | 例 |
|---|---|
| 発見時刻 | 2026-06-03 10:15 JST |
| 対象 | user-1234、委託終了日 2026-05-31 |
| 残存していた権限 | GitHub outside collaborator、SaaS管理者、メール転送 |
| 最終利用 | 2026-06-01 09:22 JST SaaSサインイン成功、退職後 |
| 実施対応 | セッション失効、OAuth同意取り消し、共有リンク停止、所有物移管 |
| 未確認事項 | 個人端末のローカルコピー、外部SaaSのゲスト権限 |
| エスカレーション | CSIRT、法務、システムオーナーへ共有済み |
判断基準：どこまで上げるか
残存アカウントは、すべてを重大インシデント扱いにすると運用が止まる。一方で、退職後の利用や高権限が絡む場合は、早めに上げるべきだ。
| 優先度 | 条件 | 対応 |
|---|---|---|
| 高 | 退職日後のサインイン成功、API利用、外部共有、管理者操作がある | 漏えい疑いとしてCSIRT、法務、システムオーナーへエスカレーション |
| 高 | 管理者、請求管理、GitHub owner、クラウド管理者、顧客データ閲覧権限が残っている | 即時停止、ログ保全、影響範囲確認 |
| 中 | SSO対象外SaaSや外部ゲストとして残っているが利用ログはない | 失効・削除、所有物移管、次回棚卸し対象へ追加 |
| 中 | OAuthアプリやAPIトークンが残っているが所有者不明 | 一時停止または期限付き保留、所有部門確認 |
| 低 | 退職前に利用停止済みで、所有物移管も完了している | 台帳更新、再発防止としてチェックリストへ反映 |
判断に迷う場合は、扱うデータの重要度で優先する。メール、ファイル共有、GitHub、クラウド、CRM、請求、人事SaaSは、一般的な情報共有ツールよりも重めに見る。退職後アクセスがない場合でも、管理者権限や長期トークンが残っていれば放置しない。
よくある誤解
SSOを切れば全部止まる
SSOは重要だが、すべてのアクセス経路を自動で止めるとは限らない。個別ID、外部ゲスト、共有リンク、OAuthアプリ、APIトークン、メール転送、GitHub outside collaboratorは別枠で残る場合がある。SCIMを使っている場合も、同期エラーと対象外SaaSを確認する。
ユーザー削除が一番安全
削除は強い対応だが、データ移管、監査ログ、所有物、法務・人事上の保持要件を確認せずに実施すると、復旧や説明が難しくなることがある。Google Workspaceでも、削除前のデータ移管や削除後の影響が公式ドキュメントで整理されている。緊急時は停止とセッション失効を先に行い、削除は確認後に進める方が安全な場合がある。
GitHub Organizationから外せば終わる
GitHubではOrganizationメンバー、Enterpriseメンバー、outside collaborator、SCIM管理、private fork、個人アカウントのローカルコピーなど、複数の論点がある。Organizationから外しただけで、全ての関連アクセスやコピーの問題が消えるとは限らない。開発組織では GitHub secret leak対応チェックリスト も合わせて確認する。
退職者本人に悪意がなければ低リスク
本人の悪意がなくても、残存アカウントはフィッシング、パスワード使い回し、個人端末侵害、放置トークンの悪用で使われる可能性がある。残存アカウントは個人の問題ではなく、組織のアクセス管理の問題として扱う。
関連用語・関連ページ
- 退職者アカウント確認チェックリスト — 退職・異動・委託終了時に確認する実務項目。
- SaaS権限棚卸しチェックリスト — 外部共有、OAuth同意、管理者権限を定期確認する。
- 漏えい疑い初動テンプレート — 退職後アクセスや外部共有が疑われる場合の記録・報告に使う。
- SaaS権限棚卸しの進め方 — 初回30日でSaaS権限を棚卸しする進め方。
- セキュリティログの読み方 — IdP、SaaS監査ログ、Webログを同じ時間軸で読む。
- 認証と認可の違い — アカウント停止と権限削除の違いを整理する。
- Access Review、IAM、SCIM、Service Account — 残存権限対応で使う基礎用語。
- 認証と認可の違いミニCTF — 架空シナリオで権限判断を練習する。
まとめ：退職者対応は「止めたか」ではなく「残った経路がないか」で見る
退職者アカウントが残っていた時は、単に削除して終わらせない。まず対象者、対象システム、権限の強さ、最終利用、所有物、継続アクセスを整理する。緊急度が高いものは止め、削除前に必要なログと所有物を確認し、判断理由を記録する。
特にSaaSとGitHubでは、SSOやSCIMの外側にある個別ID、外部ゲスト、OAuth同意、APIトークン、メール転送、private fork、outside collaboratorが見落とされやすい。退職者対応は人事イベントではなく、アクセスレビューとインシデント初動の境界にある実務である。
次の作業として、退職者アカウント確認チェックリスト で対象者ごとの確認を行い、四半期の SaaS権限棚卸しチェックリスト に同じ観点を組み込むとよい。ログ確認が必要な場合は セキュリティログの読み方 から始める。
公式情報・参考情報
- Google Workspace Admin Help: Delete or remove a user from your organization — Google Workspaceでユーザーを削除する前のデータ移管、削除後の影響、削除すべきでないケースを確認できる。
- Google Workspace Admin Help: ユーザーを一時的に停止する — アカウント停止時にアクセスできなくなる範囲と、共有済みデータの扱いを確認できる。
- GitHub Docs: About user offboarding on GitHub Enterprise Cloud — GitHub Enterprise Cloudでのオフボーディングの影響を確認できる。
- GitHub Docs: Removing a member from your organization — GitHub Organizationからメンバーを削除する場合の影響とSCIM利用時の考え方を確認できる。
- Microsoft Learn: Access reviews in Microsoft Entra ID Governance — アクセスレビューでユーザー、ゲスト、アプリ権限を定期確認する考え方を確認できる。
- CISA: Google Common Controls — Google Workspace向けのSCuBA共通コントロールと安全な設定確認の観点を確認できる。
