退職者・委託先アカウントの削除手順｜SaaS権限棚卸しと不正アクセス対策
退職者や契約終了した委託先のアカウントは、退職日を過ぎたら「利用されていないはず」では済みません。メール、ファイル共有、チャット、開発環境、クラウド、請求システムなどにアクセスが残れば、本人の意図にかかわらず、認証情報の流出や端末の紛失をきっかけに社外から入れる経路が残ります。対策は、利用者の一覧と各サービスの実際の権限を突き合わせ、退職・契約終了の時点で停止し、セッションやAPIトークンまで失効させ、必要な業務データを後任へ移し、第三者が結果を検証することです。
本記事は、情報システム担当者、人事、部門責任者、委託先の窓口担当者向けに、全社SaaSのオフボーディングを設計する手順をまとめます。WordPressだけのユーザー削除や一般的な委託先選定チェックリストではなく、雇用・契約の終了から権限消去の証拠までを一連の運用として扱います。手順中の「当日」「前日」などは実務の推奨順序で、法律が一律の時刻を定めているという意味ではありません。人事情報、契約、保存義務、各SaaSの仕様を確認して、自社の承認フローへ落としてください。
確認日：2026年10月30日。NISTのデジタルID関連資料、CISAのID・アクセス管理推奨事項、IPAの情報セキュリティ資料を基に整理しています。製品画面やAPIの操作方法は頻繁に変わるため、実行時には各サービスの最新の管理者向け公式文書も確認してください。
目次
退職者のアクセスを洗い出す：人事名簿とSaaSの実態を突き合わせる
削除漏れの多くは「どのサービスにアカウントがあるか分からない」状態から始まります。人事台帳に載る従業員、契約書に載る委託先、ID基盤にあるユーザー、各SaaSに直接作られたユーザー、招待された外部ゲストは同じ一覧ではありません。退職者のメールアドレスを検索して見つかったものだけを消しても、個人メールアドレスの招待、別名の開発者ID、共有アカウントのパスワード、OAuth連携、APIキーが残ることがあります。最初に「人」「ID」「アクセス経路」を別の台帳で定義し、結び付けることが必要です。
棚卸しの起点を人事イベントにする
オフボーディングの起点は、本人が申請した日でも、情シスが気付いた日でもなく、承認済みの退職・契約終了イベントです。人事は「社員番号または委託先ID、氏名、所属、雇用形態、最終業務日、最終アクセス許容時刻、上長、後任、法的な保管条件」を通知します。委託先なら発注番号、契約期間、社内スポンサー、再委託の有無も追加します。同姓同名や改姓に備え、メールアドレスだけを唯一の識別子にしません。異動者は退職者と異なり、すべてを止めるのではなく、旧部門の権限を剥がして新部門に必要な権限を付け直します。
人事からの連絡には機密性があります。広いメーリングリストに退職理由を流す必要はありません。オフボーディング担当には処理に必要な最小限の属性だけを渡し、詳細な人事情報は人事システムに残します。連絡の到達を確認できるチケットを一件発行し、担当者、承認者、締切、対象者IDを記録します。口頭や個人チャットだけだと、後から「誰がいつ止めるべきだったか」が追えません。
権限の一覧は五つの面から集める
第一にIDプロバイダーやディレクトリから、SSOアカウント、グループ、ロール、条件付きアクセス、MFA登録、認証端末を取得します。第二に主要SaaSの管理者一覧から、直接ログイン可能なローカルアカウント、外部ゲスト、管理者権限、所有者権限、請求権限、共有リンクを確認します。第三に開発・運用系の管理面から、コードリポジトリ、CI/CD、クラウド、ドメイン・DNS、監視、秘密情報管理、コンテナ基盤などを確認します。第四に端末管理から、社給PC、スマートフォン、VPN証明書、デバイス登録、物理認証器を調べます。第五に非人間のアクセスとして、個人発行のAPIキー、OAuth同意、サービスアカウント、ボット、Webhook、SSH鍵を調べます。
この五面を一度に完璧にそろえる必要はありません。まず顧客情報、決済、ソースコード、本番環境、外部公開設定へ影響するサービスを高リスクとして先に列挙します。次に業務チャットやカレンダーなど広く利用されるサービスを加えます。最後に経費精算、マーケティング、デザイン、アンケート等の部門導入SaaSを足します。優先順位は「漏れたときの影響」「管理者かどうか」「別経路でログインできるか」「現状の把握しやすさ」で決めます。低利用サービスでも、全顧客の連絡先を持つなら優先度は高くなります。
台帳の「利用中」を申告だけで判断しないことも大切です。請求明細、SSOの利用ログ、ブラウザ拡張の配布、MDMに入るアプリ、会社ドメインの招待メール、経費の支払先などから、管理外のSaaS候補を見つけます。発見した候補は、勝手にアクセスして調べるのではなく、サービス管理者とデータ所有者へ確認します。個人契約のツールに業務データがある場合は、アクセス停止と記録保全を並行し、契約上の権利や個人情報の扱いを法務・人事と確認してください。
人、アカウント、権限を別々に記録する
一人が複数IDを持つことがあります。通常の社員ID、開発者名のID、非常時用の管理者ID、取引先との共有ゲストIDを「一人＝一アカウント」に押し込むと見落とします。人の台帳には在籍・契約状態を、アカウント台帳にはサービス名とログイン方式を、権限台帳にはグループ、ロール、共有範囲、発行済みトークンを記録します。関連付けには社員番号や契約IDなど安定したキーを使い、メール別名や以前の会社ドメインも補助情報として保持します。台帳自体にはパスワードやAPIシークレットを記載しません。
| 確認対象 | 台帳に残す最低限の項目 | 照合先と担当 | 終了時に見るべき残存経路 |
|---|---|---|---|
| 人と契約 | 社員・委託先ID、終了時刻、上長、社内スポンサー | 人事・調達・発注部門 | 異動・延長・再契約の未反映 |
| ログインID | サービス、ID、SSO連携の有無、状態 | ID基盤・SaaS管理者 | ローカルID、ゲストID、別名ID |
| 権限 | ロール、グループ、共有資産、管理者権限 | データ所有者・部門管理者 | 公開リンク、共同所有、代理権限 |
| 秘密情報 | キーの識別子、発行者、利用先、失効予定 | 開発・運用・秘密情報管理者 | APIキー、OAuth、SSH鍵、Webhook |
| 端末と認証器 | 端末ID、証明書、MFA登録、返却状態 | 端末管理・総務 | 社外端末、オフラインコピー、物理鍵 |
「退職した本人に関連するIDはゼロ」「後任へ必要な所有権が移った」「共有データへの外部リンクを把握した」「個人発行キーを失効した」を別の完了条件にします。アカウント削除だけを完了条件にすると、連携で残ったセッションや別名IDを見逃します。また、業務データの所有者が退職者のままでは、削除後に復旧不能なファイルや自動化が出るため、停止とデータ移管の順序を分けます。
SSOを止めてもサービス側の経路は残り得る
SSOで中央管理していても、サービス側にローカルパスワードや既存セッションがあるとは限らず、あるとも限りません。仕様を確認して、SSO遮断と各サービスのアカウント停止を別の検査項目にします。NISTのセッション管理資料は、IDプロバイダーと利用先サービスのセッション終了が独立すること、アクセストークンやリフレッシュトークンがログアウト後も有効であり得ることを説明しています。したがって「IdPで無効化したから全サービスも即時に遮断された」と推測せず、対象SaaSでのセッション強制終了、トークン失効、ローカル認証無効化を確認します。
逆に、個別SaaSのアカウントを先に完全削除すると、共有フォルダーやフォーム、予約投稿、アプリ連携の所有者を移す画面に入れなくなることがあります。停止と削除は同義ではありません。まずログイン経路を遮断し、所有資産の移管と保存要件を処理した上で、削除または所定の保留状態へ移す運用が安全です。サービスによっては削除が可逆でないため、保管ポリシーと機能を確認してから実施します。
棚卸しで見つかった孤立アカウントを分類する
人事台帳に対応する在籍者がいないアカウントを、直ちにすべて削除するのは危険です。退職者の取り残し、外部委託先、サービスアカウント、共有管理者、データ移行用の一時ID、テスト用IDが混在するからです。まず所有者・発行理由・利用ログ・依存する自動化を調べ、①不要な人間アカウント、②所有者の移管が必要なアカウント、③無人運用だが責任者が必要なアカウント、④インシデント調査対象に分けます。期限を設け、誰も所有者を名乗らない例外を残さないことが目的です。
調査時には、アカウント名だけで本人を断定しません。監査ログのIP、端末、認証方式などは、適切な権限と保存期間の範囲で確認します。疑わしい活動を見つけたら通常の削除フローから切り離し、証拠保全とインシデント対応の手順へ移します。単純にログやアカウントを消すと、影響範囲を追う材料を失うことがあります。証拠へのアクセスを必要者に絞り、事実と推測を分けて記録します。
実務例：従業員一人のアクセス経路を発見する
架空の例として、営業担当Aさんが金曜日に退職するとします。人事台帳には会社メールと社員番号があり、IdPにはメール、CRM、チャット、ファイル共有が並びます。ところが部門が直接導入した提案書作成SaaSはSSOに未接続で、個別パスワードでログインできます。さらに顧客データを表計算へ転送するOAuth連携が、Aさんの権限で動いています。IdPだけを止めれば、提案書作成SaaSとOAuth連携が残る可能性があります。台帳の突き合わせでこの二経路を発見し、担当部門とデータ所有者を決め、移管後に停止するのが正しい順序です。
この例で必要な成果物は、AさんのID一覧、直接契約SaaSの管理者確認、OAuth連携のオーナーと使用範囲、引き継ぐ提案書の保存先、停止する正確な時刻、停止後の検証記録です。「Aさんが退職したのでメールを停止した」という記録だけでは不十分です。全社のSaaS台帳が未整備なら、今回見つかったサービスを台帳に追加し、次回の入社時の申請先にも反映します。オフボーディングは退職時だけの一時作業ではなく、入社・異動・退職を結ぶライフサイクルの品質検査でもあります。
退職当日の停止手順：アカウント、セッション、トークン、データを順番に処理する
退職当日に必要なのは、ボタンを一つ押すことではなく、アクセスを止める時刻と業務を引き継ぐ時刻の整合です。たとえば最終勤務日の17時まで引き継ぎが必要なら、その前に本人の利用を止めると業務が滞ります。一方、17時まで許す予定だったのに有給消化で最終作業が前倒しになった場合は、不必要にアクセスを長く残すことになります。人事と上長が最終アクセス許容時刻を確定し、情シスがその時刻を処理チケットに反映させます。本人へ告知するタイミングは雇用関係や契約の状況に応じて人事・法務が判断し、システム担当者だけで決めません。
停止前の準備：データ、所有権、連絡先を特定する
作業を始める前に、対象者が所有する共有フォルダー、プロジェクト、顧客対応履歴、予約投稿、カレンダー、フォーム、クラウドリソース、自動化ジョブを洗い出します。後任に引き継ぐものと保管するだけのものを分け、データ所有者から移管先の承認を得ます。個人メール箱を後任が無制限に読む設計は、プライバシーや社内規程との衝突を招きます。必要な業務連絡だけを規程に沿って転送・共有し、旧メール箱を一定期間保管する場合はアクセスできる人と終了日を明記します。メール転送は個人情報を含むため、転送先と範囲の確認が必要です。
顧客窓口として公開されたメールアドレスや電話番号は、本人のアカウント停止とは別に引き継ぎます。顧客が返信したときに不達や放置にならないよう、共通窓口または承認済みの後任へ案内します。一方、退職者本人のアカウントを後任に渡して継続利用しないことが重要です。同じIDを他人が使うと、監査ログで誰が操作したか識別できず、本人のMFA・個人端末・復旧先も混在します。権限は後任の本人IDに新規付与し、旧IDは停止します。
停止時刻に行う作業を役割別に分ける
人事は対象者と時刻を確定し、処理開始を通知します。ID管理担当は中心のアカウントを無効化し、グループ・管理者権限を除去します。各SaaS管理者はローカルアカウント、外部ゲスト、残存セッションを処理します。開発・運用担当はAPIキー、PAT、SSH鍵、クラウドアクセスキー、CI/CDの秘密情報を確認します。端末担当は端末回収、MDM、VPN、証明書、物理認証器を処理します。業務部門はデータと顧客窓口の引き継ぎを完了し、完了証跡をチケットへ返します。この分担を事前に決めておかないと、情シスの一人がすべてのSaaS管理権限を持たない現実に対応できません。
| 順番 | 作業 | 担当 | 完了条件 | 失敗時の扱い |
|---|---|---|---|---|
| 0 | 本人と停止時刻の二重確認 | 人事＋上長 | 社員ID・契約IDと承認時刻が一致 | 一致しなければ処理保留、本人を推定しない |
| 1 | 中心IDと管理者権限を停止 | ID管理者 | 新規認証を拒否、特権ロール除去 | 管理画面障害なら代替管理者へ即連絡 |
| 2 | 全セッション・トークン・ローカルIDを失効 | 各SaaS管理者 | 既存セッションと直接ログインを遮断 | 不可ならサービス側の緊急窓口へ依頼 |
| 3 | 秘密情報と自動化の移管・ローテーション | 開発・運用担当 | 旧キー無効、後任の新キーで稼働確認 | 依存先を特定し、限定的な暫定措置を記録 |
| 4 | データ所有権・窓口を後任へ移す | 業務部門＋データ管理者 | 後任の本人IDで必要な業務を再現 | 復元可能な保管策を先に確認 |
| 5 | 停止の第三者検証と証跡保存 | 別の管理者 | ログイン不可・権限残存なし | 未完了項目を期限付き例外にする |
上の順番は基本形です。自動化で本人のAPIキーを使っている場合、キーを無効化すると顧客向けサービスが止まる可能性があります。そのときは責任者が依存先を特定し、代替のサービスアカウントを準備し、移行テストを行ってから旧キーを失効します。ただし「本番停止が怖い」という理由だけで無期限に退職者のキーを残してはいけません。暫定運用が必要なら、利用先、承認者、監視方法、失効期限、後任、代替案を記録します。秘密値をチケット本文へ貼り付けず、秘密情報管理基盤で扱います。
セッションとトークンまで失効させる理由
SSOを止めれば新しいログインは拒否できる場合があります。しかし、すでに開いているブラウザやモバイルアプリのセッション、発行済みのアクセストークン、リフレッシュトークンまで即座に消えるとは限りません。NIST SP 800-63Bのセッション管理は、IDプロバイダーと利用先サービスのセッションが独立し、アクセストークンがログアウト後も有効であり得ることを示しています。各サービスの管理機能で「全端末からサインアウト」「セッション取り消し」「トークン取り消し」などを実施し、実際の結果を確認します。製品によって失効までの遅延や対象範囲が異なります。
OAuth連携は、本人が過去に許可したアプリに業務データへのアクセス権がある場合があります。連携アプリ名、許可したスコープ、最終使用時刻、所有者を見て、必要な連携は後任または組織管理の連携へ移し、不要な許可は取り消します。共有リンクも別経路です。「リンクを知っている人」が閲覧できる設定や外部ドメインへの共有を検査します。個別のローカルログインを残すサービスでは、その認証情報を無効化します。MFAは重要ですが、MFAを登録したままのIDが残れば、回復手段や登録端末を介したアクセスの余地が残るため、アカウント状態と併せて処理します。
管理者・特権アカウントは別の高リスク手順で扱う
通常の閲覧者と本番環境の管理者を同じ優先順位で処理しません。管理者はユーザーを再作成でき、ログを削除でき、データを一括取得できる権限を持つ場合があります。特権アカウントは、退職の最終時刻に合わせて事前に後任と緊急管理者を確保し、停止直後にロール一覧を再取得します。クラウド管理、ドメイン管理、DNS、請求、CI/CD、シークレット管理など、復旧能力を持つ権限を最優先で確認します。共通の管理者パスワードを知っていたなら、個人アカウントの停止とは別にパスワード変更と接続先の見直しが必要です。
ただし、権限が強いからといって、無確認の一括削除は危険です。唯一の所有者を消すと課金設定や更新手続きに入れなくなる場合があります。後任の管理者を先に用意し、権限移譲を記録し、二人目の管理者がログインできることをテストします。例外的な緊急停止では、業務継続よりアクセス遮断を優先する判断もあり得ます。その判断者、理由、影響、復旧案をチケットに残し、後から監査できるようにします。
端末回収とデータ保全はアカウント停止と別の作業
社給PCを回収しても、個人端末のアプリ、同期済みのローカルファイル、印刷物、外部ストレージは自動的には消えません。逆に端末を遠隔消去しても、クラウド側のアカウントが残れば別の端末からアクセスできます。端末とアカウントを別の管理対象として、返却物の一覧、MDM登録、証明書、VPN設定、モバイルアプリ、物理認証器を確認します。BYODで私物端末に業務データがある場合は、規程と同意内容に基づき、企業データ領域のみを削除できるか確認し、私物全体を無断で消去しないようにします。
業務データについては、保存義務、訴訟対応、監査、顧客との契約を確認します。退職者の個人領域を「監査のため」と言って無期限に残すことも、反対に履歴を即時に消して業務記録を失うことも避けます。保存対象と期間、閲覧権限、削除期限を情報管理規程に合わせます。保全が必要な場合は元データの完全性を維持し、アクセス権を限定して保管します。規程がないなら、個別判断を積み重ねる前に法務・情報管理責任者と方針を決めてください。
第三者が停止を検証する
作業者が「停止済み」のボタンを押しただけでは完了としません。別の管理者が、対象者のIDで新規ログインできないこと、既存セッションが終了していること、主要SaaSの管理者一覧から権限が消えていること、発行済みキーが無効になっていることを確認します。本人のパスワードを知るために無断でログインするのではなく、管理画面の状態、監査ログ、テスト用の適切な手段で確かめます。確認画面やAPI応答は時刻と対象IDを記録し、個人情報や秘密値が不要に残らない形式で保存します。
停止完了の報告には、対象者、停止時刻、処理済みサービス、残件、例外の期限、データ移管先、検証者を含めます。残件があれば「すべて完了」と書かず、影響と暫定防御を明示します。たとえば特定SaaSのセッション取り消しができないなら、当該アカウントの利用停止、パスワード変更、ネットワーク制限、ベンダーへの失効依頼、ログ監視など可能な対策を組み合わせます。例外が解消するまではチケットを閉じません。
失敗時の戻し方を決めておく
誤って在籍者のIDを停止した場合は、本人確認と人事・上長の承認を取り、停止した箇所と復旧対象を絞って戻します。全権限を一括で元に戻すと、本来削除すべき過剰権限まで復活する可能性があります。前日の権限スナップショットと承認済みの業務権限を照合し、必要最小限を再付与します。誤停止が原因で業務データが消えた場合は、サービスの復元期限とバックアップを確認し、保全した監査ログと照らして復旧します。発生理由を調べ、人事IDの選択画面や二重確認方法を修正します。
退職者だと思って停止したが契約延長が後から判明した場合も、即座に全権限を復旧しないでください。契約の有効期間、作業範囲、必要なサービス、承認者を更新し、新しい期限付き権限として付け直すほうが安全です。例外的な復旧は「失敗の修正」だけでなく、現在の身分と業務に合う権限の再審査として扱います。この原則は、一時停止した委託先が再契約で戻る場合にも同じです。
委託先の権限を期限で管理する：契約終了・再委託・サービスアカウントの分け方
委託先のアクセスを退職者と同じ一枚のリストで扱うと、契約主体と実際に作業する人が分からなくなります。発注先の会社が同じでも、作業メンバーは入れ替わります。発注元の担当者が契約延長を知っていても、SaaS管理者へ届いていない場合もあります。外部ユーザーには「会社」「個人」「契約」「プロジェクト」「社内スポンサー」「アクセス期限」を紐付け、個人ごとに必要な権限を与えます。会社名だけの共有IDは、退職・交代時に誰のアクセスを止めたか識別できないため避けます。
委託先のアカウントには終了日を必ず持たせる
外部ユーザーを招待する申請には、作業開始日、終了予定日、対象サービス、必要なロール、対象データ、社内スポンサー、承認者を記載します。終了日が未確定でも「いつか見直す」ではなく、暫定期限を設け、延長申請がなければ失効させる設計にします。製品が権限の自動失効に対応するなら利用し、対応しないなら期限日でチケットを自動起票し、担当者が停止を確認します。招待メールに期限が書かれていても、実際の権限がその日で切れるとは限りません。設定画面とログで実効性を確認してください。
権限の粒度は契約の「目的」に合わせます。Webサイト更新の委託先に、全社の人事ファイルや本番クラウド管理者権限は不要です。広告運用の委託先に顧客データの一括エクスポート権限を与える必要があるか、具体的な作業で判断します。「最初だけ広く付けて後で下げる」は、下げ忘れの原因になります。最初に閲覧・編集・承認・管理者の区別を決め、足りなければ追加申請させるほうが記録を残しやすくなります。CISAのIAM推奨は、職務に必要な権限に限定する最小権限の考え方を示しています。
契約と人の終了を別イベントとして扱う
委託契約が続いていても、担当者個人が離任すればその人の権限は止めます。逆に契約が終われば、まだ作業者の在籍が続いていても発注元の環境に対する権限は止めます。どちらか一方だけを終了トリガーにすると漏れが出ます。発注部門は月次で委託先のメンバー一覧と作業予定を確認し、メンバー変更のたびに新規付与と旧担当の失効をセットで申請します。契約終期が迫る案件は、調達部門が延長の有無を事前に確認します。契約書に記された会社が「担当者を誰に替えたか」を通知しない場合は、契約上の連絡義務と実務の連絡先を明確にしてください。
再委託がある場合、発注元の管理者が把握するのは元請会社だけでは不十分です。実際にアクセスする個人を識別できるよう、元請に登録と削除の連絡経路を求めます。ただし、再委託先の個人情報を必要以上に複製しないよう、識別子と作業権限、連絡先を必要範囲に限定します。契約上の再委託条件とシステム上の招待対象が一致しているか、スポンサーが確認します。許可されていない再委託を発見したら、直ちに誰かを責める前に、アクセス停止、事実確認、契約担当への連絡を並行します。
社内スポンサーを「承認者」だけで終わらせない
外部アカウントには社内スポンサーを一人置きます。スポンサーは初回申請を承認するだけでなく、期限延長時に作業の継続必要性を確認し、案件終了時に停止が済んだことを確かめます。スポンサーが異動・退職すると外部アカウントの責任者が消えるため、スポンサーの身分変更も棚卸しトリガーにします。スポンサー未設定の外部アカウントを「誰かが使っているはず」と放置せず、所属部門へ照会し、期限内に所有者が決まらなければ停止します。サービス運用上すぐ止められないなら、理由と暫定監視を例外として承認させます。
スポンサーが確認する項目は、作業の成果物とシステム権限を結び付けると具体的になります。「今月も契約中ですか」だけではなく、「この外部担当が今月更新する対象は何か」「編集権限が必要か」「管理者である必要があるか」「顧客情報のダウンロードが必要か」「来月も同じ人が担当するか」を確認します。アクセスが作業内容より広ければ権限を縮小します。活動がないだけで直ちに不要とは断定せず、繁忙期や保守待機の契約条件も確認します。ただし、使っていない管理者権限を保守待機という名目だけで保持することは避けます。
発注先のサービスアカウントは人間アカウントと分ける
外部の開発・運用会社が作った連携アカウントやAPIキーは、委託先の担当者が離れても自動化が継続する場合があります。これは本人の個人アカウントを残す理由ではありません。人間のアクセスと自動化のIDを分離し、後者には発注元の責任者、利用目的、利用システム、権限範囲、保管先、ローテーション方法を記録します。可能なら個人発行の長期キーではなく、短期資格情報やワークロードIDなどサービスが推奨する方式を使います。旧担当者が秘密値を知っていた可能性があれば、引き継ぎ後にローテーションします。
サービスアカウントを「無人だから退職イベントと無関係」と扱うと危険です。発行者の個人メールに復旧通知が届く、自動化の所有者が退職者のまま、二要素認証の復旧先が本人の私物端末、鍵が本人のローカルPCだけに保存されている、といった依存があり得ます。委託終了時に、アカウント所有権、メール、支払手段、通知先、鍵の保管先、運用手順を発注元へ移します。失効前に代替アカウントでジョブが動くことを確認し、旧アカウントの不要な管理権限を削除します。
委託終了時のチェックリスト
| 確認点 | 確認する人 | 合格の状態 |
|---|---|---|
| 契約終了日と作業者の離任日 | 調達担当・社内スポンサー | 両方の日時が記録され、延長の承認有無が明確 |
| 外部ゲストと直接作成されたID | 各SaaS管理者 | 対象者のログインと権限を停止 |
| 共有データと公開リンク | データ所有者 | 成果物を保管、不要な共有を解除 |
| 自動化とAPIキー | 運用担当 | 代替IDで動作確認し旧キー失効 |
| 貸与端末・証明書・VPN | 端末管理者 | 返却または失効の証跡あり |
| 最終検証 | 別の管理者 | 外部ログイン不可、例外に期限あり |
このチェックリストは一般的な委託先評価と役割が異なります。委託前の安全性や契約条件の評価は別の論点です。選定・契約段階の確認は委託先のセキュリティチェックリストも参照してください。本記事の主眼は、契約中に発行した具体的なアクセスが終了時に実際に消えたかです。契約書に「終了後はアクセスしない」と書くだけでは、SaaS側の権限は自動で消えません。発注部門と管理者の両方が完了条件を持つ必要があります。
例外を残すなら「期限・所有者・代替策」を同時に決める
契約終了後も、監査対応や瑕疵修補、移行支援で期間限定のアクセスが必要な場合があります。その場合、通常の契約延長と同じ強い権限をそのまま残すのではなく、対象データと操作を絞り、閲覧だけで足りるか再評価します。例外チケットに依頼者、理由、範囲、期限、承認者、監視方法、削除予定日を記録し、期限日に自動的に再確認します。後から「例外の例外」が重なって無期限化しないよう、再延長には上位承認を求める運用も有効です。
例外を承認する人は、リスクと業務必要性を理解できる責任者であるべきです。システム管理者が技術的に設定できることと、権限の継続を承認できることは別です。個人情報を含むデータの外部アクセスなら、個人情報管理の責任者や契約担当も関与します。管理画面の「期限なし」しか選べない場合は、カレンダー通知や定期チケットで代替します。製品の制約を理由に記録を省くのではなく、制約を明示して補完統制を設けます。
実務例：制作会社の交代とサイト運用
架空の例として、制作会社Bから制作会社CへWebサイト運用を移す場合を考えます。Bの担当者にはCMS編集権限、デザインファイル、解析ツール、DNS閲覧、緊急時のサーバー接続が与えられていました。契約終了日にCMSだけを止めても、デザインツールの共有、解析ツールの外部ゲスト、SSH鍵が残ります。まず各権限の所有者を特定し、Cの担当者には個別IDで必要な範囲を付与します。引き継ぎ用のファイルを組織管理の保存先へ移し、Bの全担当者と発行済みキーを失効します。公開サイトを維持するための自動化がBの個人アカウントに依存していれば、発注元が所有するサービスアカウントへ移します。
この例の完了条件は、Cが作業できることだけではありません。Bが編集できないこと、直接ログインできないこと、必要な過去データが契約に沿って保存されていること、通知先がCまたは発注元へ切り替わったことを確認します。Bが保管する発注元データの返却・消去は、SaaS権限の失効とは別に契約と証明の範囲で確認します。発注元が持つ権限を消しても、B社内のコピーまでは自動で消えません。システムと契約、両方の終了を別々に記録するのがポイントです。
権限棚卸しを定着させる：定期照合、例外管理、監査証跡、よくある質問
退職時だけの作業では、通知漏れや部門独自のSaaSを発見しにくくなります。定期的な権限棚卸しで、全社の人・契約の現状と各サービスの実際の権限を照合します。目的は「担当者に一覧を眺めてもらうこと」ではなく、孤立アカウント、過剰権限、期限切れの委託先、所有者不明のサービスアカウントを期限内に是正することです。IPAの情報セキュリティ資料やCISAのIAM推奨にも、退職者のアカウント削除、権限の見直し、最小権限に関する考え方があります。定期棚卸しは、その考え方を運用として続ける手段です。
頻度よりも「対象・差分・是正」の設計を先に決める
年一回の全件調査を行っても、結果が作業担当へ戻らなければリスクは減りません。高リスクサービスでは退職イベントと同時の停止に加え、月次や四半期など自社が処理できる頻度で照合します。一般的な部門SaaSは四半期または半期のレビューから始めても構いません。ただし、頻度は法律で一律に定められた値ではなく、扱うデータ、権限の強さ、委託先の入れ替わり、監査要件によって決めます。更新頻度の高い開発環境と、閲覧中心の学習サービスを同じ頻度にする必要はありません。
照合ではまず、人事・調達の在籍者一覧と各SaaSのユーザー一覧を突き合わせます。次に管理者ロール、外部ゲスト、共有権限、サービスアカウント、APIキーを別の差分として出します。差分は「退職者の残存」「契約期限超過」「スポンサー不在」「在籍者だが過剰権限」「利用者はいるがSaaS自体が台帳外」などに分類します。分類すると、削除担当、承認者、必要な調査が決まります。単に一覧から名前が消えたかだけでは、組織に残るアクセス経路を見つけられません。
是正には期限を付けます。高リスクの退職者管理者IDなら直ちに遮断し、原因を調べます。名前の表記ゆれで台帳上だけ一致しないものは、本人確認とIDの紐付けを直します。所有者が不明なサービスアカウントは、利用先を調べ、責任者を割り当てるか無効化します。期限を過ぎた項目は上長へエスカレーションし、放置を許さない運用にします。例外の承認と是正作業を同一担当だけで完結させず、重要権限は別の目で確認するのが有効です。
棚卸しレビューの画面で管理者が答えるべき問い
管理者へ大量のユーザー一覧を送って「問題がなければ承認」と依頼すると、形式的なクリックになりがちです。レビュー対象を担当部門・プロジェクトごとに分け、各人に「この人は現在この業務を担当しているか」「このロールが必要か」「この外部ユーザーの契約は有効か」「データの所有者は誰か」「権限の期限はいつか」を答えてもらいます。管理者が判断できない項目は承認扱いにせず「要調査」にします。質問を具体化すると、過剰権限と名簿の誤りを発見しやすくなります。
担当部門が知らないサービスに自社データがある場合、情報システム担当は単純な一括削除を避けます。業務上の必要性、契約、請求、連携先、利用者を調べ、承認された管理へ移すか、安全に終了させます。隠れて使っていた理由が「正式な申請に時間がかかる」なら、承認フローを改善しなければ別の非管理SaaSが増えます。セキュリティ部門だけで禁止を積み上げるのではなく、使いやすい代替サービスと短い申請ルートを提供することが継続的な対策になります。
証跡は「誰がいつ何を確認したか」が再現できる形にする
監査に必要なのは、全画面のスクリーンショットを無制限に保存することではありません。対象者ID、対象サービス、前の権限、実施した処理、実施時刻、処理者、確認者、確認結果、残存例外、参照したログの識別子を残します。画面やログの保存期間は、契約、社内規程、法令、サービスの仕様を考慮して決めます。個人情報や認証情報を含む資料を広いフォルダーへ置かず、閲覧者と保存期限を制限します。チケット番号で人事イベント、サービス側の操作、検証結果を紐付けると、後から経路を追えます。
証跡の見本としては、「社員ID 1234、退職確定 10月30日17時、IdP停止 17時02分、CRMローカルID停止 17時06分、チャットセッション失効 17時08分、APIキー移管 17時15分、管理者Bが17時30分に各サービスの状態を再確認、例外はなし」という形式です。これは架空の記録例であり、実在の作業を示すものではありません。長い自由記述より、項目名がそろった記録のほうが漏れを検出しやすくなります。一方、サービスの仕様上実行できない項目は空欄にせず、理由と代替措置を書く必要があります。
権限レビューで「承認」と判断された場合も、判断根拠を一言残します。「必要」とだけ書くのではなく「営業企画の月次レポート作成にCRM閲覧が必要、書き出し権限は不要」などです。次回のレビューで業務が変わったときに比較できます。強い管理者権限には、作業者本人ではなく業務責任者の承認が必要です。自動化された権限付与・剥奪は、設定が意図どおり動いていることをサンプルで検証し、エラー時の通知先を持たせます。
運用指標は「処理数」より「残存リスク」を見る
退職者を何人処理したかだけでは品質を評価できません。たとえば「承認された停止時刻から主要ID停止までの時間」「期限を超えて残った外部アカウントの件数」「所有者不明のサービスアカウント数」「退職イベントとSaaS側の削除記録が突合できた比率」「全セッション失効までの時間」「例外の期限超過件数」を見ると、実際の残存リスクに近づきます。数値はサービスの仕様やログ保存期間に依存するため、他社の基準値をそのまま目標にしないでください。まず測定できる範囲と分母を明確にし、改善を続けます。
例として「退職者100人のうち、主要SaaSの全停止を予定時刻の当日中に確認できたのは95人」という指標なら、95％だけを成果として示すのではなく、残り5人の原因を調べます。人事通知が遅れたのか、特定SaaSにAPIがないのか、担当者が不在だったのかで対策が違います。遅れの平均値は重大な一件を隠すことがあります。最大遅延と高権限者の遅延も別に見ると、優先順位を誤りにくくなります。
30日で始める小さな導入計画
全社のすべてのサービスを一度に自動化するのは現実的ではありません。最初の30日は、①重要なSaaS十件程度の一覧を確定する、②人事・調達イベントの通知先を一つ決める、③停止チケットの必須項目を作る、④退職者と委託終了者を数件サンプルで追跡する、⑤例外の扱いを決める、という小さな範囲で始めます。サービス件数は会社ごとの例示であり、固定の基準ではありません。顧客情報、本番運用、管理者権限を持つサービスから優先します。責任者は、企画を承認するだけでなく、担当者へ必要な管理権限と時間を確保します。
第1週は、対象SaaSと管理者、契約オーナーを決めます。第2週は、最近の退職・契約終了イベントを選び、台帳と実際のアカウントを突き合わせます。第3週は、停止と検証を二人で行う手順を試し、残った経路を分類します。第4週は、チケットの入力欄、承認、期限、再通知、完了条件を修正します。運用開始後は、月次の小さな照合と、四半期の権限レビューなど、部門が継続できる周期へ落とします。試行で見つかったサービス側の制約は、例外台帳に残して対応策を決めます。
自動化するなら、最初に人事イベントの品質を確認します。退職日の変更、休職、兼務、契約更新が誤って入力されれば、自動的に正しい処理はできません。IDの誤紐付けは、在籍者を止めたり、退職者を残したりします。自動化の対象範囲、例外時の手動対応、処理失敗のアラート、処理結果の照合を設計します。自動化後も高リスクの権限には定期的なサンプル検証を残します。「人手の作業をなくす」のではなく、「人手で確認すべき例外を絞る」のが実務上の目的です。
自動化の検収では、正常な退職だけを試すと不十分です。退職日が変更された場合、同姓同名の二人がいる場合、IdP停止は成功したがSaaSへの連携が失敗した場合、委託先の契約だけが延長された場合、管理者が不在の場合、APIが制限に達した場合を試します。各ケースで「誤った人を止めない」「止めるべき人を残さない」「失敗を検知して担当者へ届く」「処理履歴が残る」を検収条件にします。失敗時に作業を再実行できるか、二重実行でデータが壊れないかも確認します。自動化を導入した後にサービス設定が変わったら、連携の再試験も必要です。
情シスにとって改善の入口になるのは、事後のヒヤリハットを責任追及だけで終わらせないことです。退職した人の招待IDが一つ残ったなら、なぜ発見できなかったかを遡ります。サービスが台帳にないのか、台帳にはあるが管理者がいないのか、通知が届かなかったのか、操作はしたが検証をしなかったのか。原因ごとに修正する場所は違います。台帳漏れなら導入申請と請求情報の照合、通知漏れなら人事イベントとの連携、検証漏れならチケットの完了条件を直します。個人の注意力へ頼る改善より、次の担当者でも同じ結果を出せる仕組みにすることが大切です。
判断に迷う場面では、停止を遅らせるリスクと業務停止の影響を分けて評価します。たとえば請求サービスの唯一の管理者が退職するなら、後任の管理者を先に追加して操作を確認する必要があります。一方、その退職者の管理者権限を引き継ぎが終わるまで開けたままにする必要があるとは限りません。読み取り専用の移管支援、業務責任者が承認した一時的な操作、システム提供者の正式な移管手続きなど、より狭い代替策を検討できます。どの策を選んだか、なぜ選んだか、いつ終了するかを残すと、後から同じ問題が起きたときの判断が早くなります。
また、棚卸しの結果は次の入社・発注時に戻すべきです。退職時に毎回見つかる未管理SaaSがあるなら、新規利用の申請時点で管理者、支払主体、データ所有者、退職時の削除方法を登録します。委託先が毎回期限切れで残るなら、契約管理の更新通知とSaaSの失効予定を連動させます。オフボーディングで見つけた欠陥をオンボーディングへ反映して初めて、件数が増えても安全に運用できます。事後対処の報告書だけを増やさず、次の権限付与が変わったかを確認してください。
権限の判断を支えるRACI
情報システム部門だけが退職者の権限を決めることはできません。人事は在籍情報、部門責任者は業務必要性、サービス管理者は技術設定、情報セキュリティ担当は統制、法務や調達は契約・保管要件を持ちます。RACIを明示すると、情シスが権限を剥がす権限はあっても、重要データの保存判断まで独断で行う誤りを避けられます。以下は一例で、会社の組織とサービスに合わせて調整してください。
| 作業 | 実行責任 | 最終責任 | 相談先 | 共有先 |
|---|---|---|---|---|
| 終了イベントの確定 | 人事・調達 | 人事責任者・契約責任者 | 部門長 | 情シス |
| 権限の必要性判断 | 部門スポンサー | データ所有者 | 情シス・セキュリティ | 調達 |
| ID・セッション停止 | ID/SaaS管理者 | IT運用責任者 | 部門スポンサー | 人事・セキュリティ |
| 業務データの移管 | 後任・部門担当 | データ所有者 | 法務・情シス | 人事 |
| 停止結果の検証 | 別の管理者 | セキュリティ責任者 | サービス管理者 | 部門スポンサー |
RACIの「最終責任」を多人数に分散させないことが重要です。最終的な判断者が不明だと、必要な権限が残ったまま期限が過ぎます。たとえば顧客契約上、一定期間の閲覧権限が必要かどうかは業務責任者が判断し、技術的に可能かは管理者が答えます。管理者は依頼に不備があれば設定を止め、理由を記録します。部門スポンサーが休暇中に契約終了する案件は、代理承認者を事前に決めます。退職日になって初めて承認者を探す設計では間に合いません。
よくある質問：アカウントは「停止」と「削除」のどちらを先にする？
一般には、まず認証を停止し、既存セッションとトークンを失効させます。そのうえで業務データと所有権、保存義務、監査証跡を確認し、サービスの仕様に沿って削除または保留へ移します。理由は、削除を急ぐと後任へ移すファイルや自動化の所有者を失う場合があるからです。ただし、停止状態でも一部の連携や既存トークンが有効な製品があるため、停止ボタンだけを安全の証明にはできません。各SaaSの管理者文書で停止時の認証挙動とデータ保持を確認し、検証を残してください。
よくある質問：SSOから消せば、各SaaSのアカウントも消える？
必ずしもそうではありません。SSOは認証の入口を統一しますが、利用先SaaSのアカウントやセッション、ローカルパスワード、トークンがどう扱われるかは製品と設定によります。SCIMなどのプロビジョニング連携でSaaS側が自動停止する場合でも、連携の失敗通知、処理遅延、対象外ユーザー、管理者用の例外IDを確認します。停止した人を使ってテストする必要はありません。管理画面の状態と監査ログ、対象SaaSの設定確認で、実効的な遮断を確かめます。中央連携の設定内容を年に一度だけでなく変更後にも点検します。
よくある質問：退職者のメールを後任へ転送してよい？
一律には決められません。業務継続の必要性、プライバシー、雇用関係の規程、顧客との契約、保管期間を確認してください。後任が必要なのは顧客からの連絡か、過去の全メールかを分けます。一般に、本人のメールボックス全体を無制限に開示するより、共通窓口への案内、必要な業務案件の引き継ぎ、期間と範囲を限定した転送のほうが統制しやすくなります。承認者、閲覧者、目的、終了日を記録し、私的内容が混入する可能性にも配慮します。技術設定だけで決めず、人事・法務と合意してください。
よくある質問：委託先が再契約するかもしれない。IDを残してよい？
再契約の可能性だけで無期限に有効なIDを残すべきではありません。現在の契約が終了したなら、少なくともアクセスは停止し、所有データの扱いを決めます。再契約が成立したときに、期間、担当者、作業範囲、必要な権限を新たに承認し、必要に応じてIDを再有効化または再発行します。元の強い権限を丸ごと復活させると、再契約の内容に合わないアクセスを与える可能性があります。契約終了から再契約までの空白期間も、誰もアクセスできない状態にすることが原則です。
よくある質問：退職者が作ったAPIキーで本番処理が動いている
まずキーの利用先と依存する処理を特定し、担当部門とシステム責任者へ影響を共有します。組織管理のサービスアカウントやワークロードIDへ移行し、必要最小限の権限でテストしてから旧キーを失効します。旧キーを残す暫定期間が避けられないなら、利用範囲、承認者、失効期限、監視、漏えい時の停止手順を記録します。キーを新しい担当者の個人アカウントへ機械的に移すだけでは、次の退職時に同じ問題が再発します。運用が止まらないよう準備しつつ、個人への依存を解消します。
よくある質問：退職者本人にアカウント一覧を申告してもらえば足りる？
申告は役立ちますが、それだけでは足りません。本人が忘れている外部招待、過去の案件、個人発行トークン、裏側のサービスアカウント、部門管理のSaaSがあり得ます。人事・調達台帳とID基盤、各SaaSのユーザー一覧、請求明細、監査ログを突き合わせます。本人の協力を得られない緊急退職でも止められるよう、会社側がサービスの管理者と所有者を把握しておく必要があります。本人の申告にない利用先が見つかった場合は、悪意を決めつけず、契約・業務・実際の使用状況を確認します。
よくある質問：共同利用の管理者IDがある場合はどうする？
まず、誰がそのIDを知り得たか、どのサービスに入れるか、MFAや復旧先を誰が管理しているかを調べます。退職者や委託先が知るパスワードや回復情報は変更し、可能なら個人別の管理者IDへ移行します。共同IDのままだと、操作の本人性を証明しにくく、退職者だけの権限を切り離せません。製品上どうしても共有IDが必要なら、秘密情報管理、利用時承認、操作ログ、短時間の貸与、定期ローテーションなど補完策を設け、個人への恒久的な共有を避けます。緊急時の管理者IDも所有者と保管先を明確にします。
よくある質問：休職や長期休暇の場合も削除する？
退職とは異なります。休職中のアクセス可否は就業規則、人事判断、業務継続、本人の状況に応じて決め、必要に応じて一時停止・権限縮小を行います。削除してしまうと復職時のデータや設定が失われる場合があります。一方、休職中も本番管理者権限や外部からのアクセスを無条件に残すのは避けるべきです。復職予定日だけを頼りにせず、復職が確定したときに権限を再審査し、業務に必要な範囲だけ戻します。人事イベントの種類を正しく扱うことで、誤停止と権限残存の両方を防げます。
よくある質問：SaaSの管理権限がなくて委託先を削除できない
部門が導入したSaaSでは、会社の情シスに管理権限がないことがあります。まず契約オーナーと既存の管理者を特定し、部門責任者へ期限を切って停止を依頼します。管理者が退職済みならサービス事業者のサポートや組織アカウントの復旧手順を確認します。停止完了までの間、可能な範囲で共有リンクの解除、外部アクセス制限、関連する秘密情報の変更、ログ監視を行います。復旧後は会社が管理できる管理者IDを複数用意し、担当者一人だけに依存しない体制へ直します。
よくある質問：停止後に不審なログインが見つかったら？
通常のオフボーディング完了として閉じず、インシデント対応へ移します。ログの時刻、認証方式、アクセス先、端末、行われた操作を保全し、他のサービスへ同じ認証情報が使われていないか確認します。アカウントとトークンを遮断し、影響範囲を調べます。本人が操作したと早合点せず、認証情報の流出、共有ID、第三者の悪用など複数の可能性を検討します。顧客情報への影響が疑われる場合は、法務や個人情報保護の担当者と報告・通知要否を判断します。証拠を消す一括削除は避け、必要な保全と遮断を並行します。
よくある質問：すべてのSaaSを一度に管理できないときは？
まず重要データと強い権限に関わるサービスを優先します。全社メール、ファイル、チャット、顧客管理、開発基盤、クラウド、請求管理などから始め、部門導入のサービスを順次追加します。対象外にしたサービスも「未確認」と記録し、完了済みのように扱いません。優先サービスで人事イベントから停止、検証、例外までの一連の流れを完成させ、得た方法を横展開します。サービス数だけで進捗を測るより、退職者が実際にアクセスできる経路をどれだけ閉じられたかを確認してください。
まとめ：退職・契約終了をアクセス終了まで追跡する
退職者や委託先のアカウント管理は、ユーザーを削除する単発操作ではありません。まず人事・調達の終了イベントを正確に受け、全社のSaaSと直接アカウント、セッション、トークン、共有、端末を洗い出します。予定時刻に認証を止め、データを後任へ移し、別の管理者が実際の遮断を検証します。委託先には個人と契約の両方の終了日を持たせ、例外には期限と責任者を置きます。最後に定期棚卸しで取り残しと過剰権限を拾い、証跡を残します。
全社のアクセス管理を見直す際は、退職者の対応だけでなく、在籍者の最小権限、多要素認証、端末管理、バックアップも一緒に考えると効果的です。基礎的な対策の全体像は企業のセキュリティ対策の基本も参照してください。この記事の表を自社用のチケットと台帳に置き換え、次の退職・契約終了の一件で試してみてください。対象者一人分を最後まで追える運用ができてから、サービスと部門を広げると定着しやすくなります。
WithAIで社内の運用文書づくりを進める
台帳の項目、権限棚卸しの質問、委託先終了チェックリスト、作業記録の様式をゼロから作るのは負荷がかかります。WithAIでAI活用の基礎を学び、社内で使う運用文書の下書きや確認項目の整理に役立ててください。ただし、実在の従業員名、秘密鍵、認証情報、顧客データを外部AIへ入力しないでください。最終的なアクセス権の判断と実施・検証は、責任者と管理者が行う必要があります。
