退職者のアカウントを止めるには｜セッション失効とAPI権限の確認表

1. 最初に何を停止対象として洗い出すか

本稿では、退職者が利用していたAI業務Webアプリについて、画面の利用者IDを起点にアクセス経路を一覧化することを提案する。例えば、問い合わせ文書を検索して回答案を作るアプリなら、ログイン画面だけでなく、会話履歴、添付ファイル、検索対象の文書保管先、回答の出力先まで対象になる。人事側の在籍状態とアプリ側の有効状態は、連動を確認できるまでは別項目として扱う。メールアドレスだけに依存せず、アプリ内IDと所属組織を対応付け、別環境や別テナントに同じ利用者の権限が残っていないかも洗い出す。

次に、本人が使う資格情報と、業務処理が使う資格情報を分ける。OWASPは秘密情報の用途、保管場所、アクセスできる人、更新方法、依存関係を把握し、最小権限で管理する考え方を示している。[2] これを踏まえ、本稿では個人用トークン、共有された鍵、業務用連携の管理権限を別々に記録することを提案する。例えば退職者が設定した文書取込処理でも、本人の資格情報で動くのか、専用の業務用資格情報で動くのかによって停止対象が変わる。所有者名だけで処理を止めず、実際の認証主体と秘密情報へのアクセス権を確認する。

• 利用者ID、所属組織、対象環境、停止予定日時を特定する。
• 画面、文書検索、ファイル取得、API、外部連携の入口を一覧化する。
• 個人用資格情報と業務用資格情報の所有者・保管先を区別する。

2. 停止確認表には何を記録するか

本稿では、停止操作の記録と拒否結果の記録を分けた確認表を提案する。管理画面に「無効」と表示されたことは操作の証跡であり、停止前の接続が拒否された証跡とは区別する。確認には、管理者が許可したテストアカウントや管理下の確認端末を使い、本人のパスワードを聞き出す方法は採らない。停止前に用意したセッションや資格情報は確認目的に限定し、安全に保管する。下表の担当は役割の例であり、実際の担当者、実施時刻、観測結果は作業時に追記する。期待結果が書かれていても、未実施の行は合格にはしない。

確認表では、製品仕様を調べる作業も未確認事項として残す。例えば管理操作が全端末を対象にするのか、特定のログイン方式だけを対象にするのかは、操作名から推測しない。停止前から失効していた資格情報で拒否を確認しても、今回の停止操作の効果を判定できないため、確認用の経路が停止前に利用可能だったことも記録する。期待結果と異なる場合は、対象環境、操作対象ID、実行時刻、応答内容を整理して再確認する。個人情報を含む画面全体を証跡として保存するのではなく、判断に必要な範囲へ絞る。

3. 既存セッションはどこで止めるか

ブラウザーを閉じる、ログアウト画面へ移動する、Cookieを消すといった端末側の変化だけで、サーバー側のセッション失効を判定しない。OWASPはセッションの終了時にサーバー側で無効化することと、タイムアウトをサーバー側で適用することを示している。また、操作が続けば維持され得る無操作タイムアウトと、活動にかかわらず終了する絶対タイムアウトを区別している。[1] 本稿では、退職時の停止確認を自然な時間切れ待ちに置き換えず、アプリの構成に応じた失効操作と、停止前のセッションを使った拒否確認を行うことを提案する。

具体例として、停止前に開いていた会話画面で回答生成を実行し、別の端末では履歴一覧を更新する。画面の表示が残っていても、保護対象への新しい要求が拒否されるかを観測する。OWASPはセッション終了後もブラウザーのキャッシュに機微な情報が残る可能性を説明し、機微な応答に対するキャッシュ制御を示している。[1] したがって、新たなサーバーアクセスの停止と、既に表示・保存された情報の扱いは分ける。本稿では、画面が見えることだけを失効失敗と決めず、通信結果を確認し、保存済みデータは端末管理の手順へ引き継ぐことを提案する。

• 停止前の複数の確認用セッションで保護対象への要求を試す。
• 画面の残存表示と、新たな通信の成功・拒否を区別する。

4. APIとWebhookの権限はどう切り分けるか

APIについては、ブラウザーのログイン状態とは別に、資格情報の発行元、利用主体、許可された操作を確認する。OWASPは秘密情報を失効可能にし、失効した秘密情報の使用試行を記録すること、平文の秘密情報をログへ残さないことを示している。[2] 本稿では、本人のトークンで文書検索、ファイル出力、処理の再実行など、実際に許可されていた操作を確認することを提案する。一つの読取APIが拒否された結果を、別の更新APIの停止確認に流用しない。旧トークンの値は確認記録へ貼らず、管理用識別子と操作結果で対応付ける。

Webhookは送信と受信を別の方向として整理する。本稿では、アプリが外部へ通知する資格情報と、外部からアプリへ要求を送るための資格情報を分けて点検することを提案する。例えば、文書取込完了の通知先を本人が管理していた場合は、通知先の管理権限と送信設定を確認する。一方、外部から取込処理を起動する連携なら、受信側の資格情報と実行可能な操作を確認する。共有鍵を更新するときは、依存先を把握するというOWASPの指針[2]に沿って接続先を洗い出し、旧鍵の拒否確認と、後任側の必要な連携の動作確認を別の結果として残す。

• APIごとに発行元、利用主体、対象データ、許可操作を記録する。
• Webhookの送信設定と受信側の資格情報を分けて確認する。

5. RAGと再実行では何を確認するか

本稿では、個人情報を扱うRAGの退職時確認を、質問の送信だけでなく、検索結果、引用元の取得、会話履歴、添付ファイルの取得に分けることを提案する。前提は、これらが別の経路で取得される可能性のあるアプリ構成である。例えば回答画面の操作は拒否されても、引用元ファイルの取得経路について確認していなければ、その範囲は未確認と記録する。確認には架空の個人情報を含むテスト文書を使い、停止前に許可されていた取得経路が停止後に拒否されるかを調べる。実際の業務文書の内容を証跡として広く共有しない。

再実行や予約処理は、本人の操作権限と処理の実行主体を区別する。本稿では、利用者権限で走る処理、業務用主体で走る処理、既に実行中の処理を分類して判断することを提案する。例えば退職前に登録された定期要約が業務用主体で動くなら、継続の承認者と出力先を確認する。一方、本人が後から再実行できる入口は停止確認の対象にする。キュー投入後にいつ権限を確認するか、停止時に実行中の処理を中断できるかは取得資料では確定できないため、対象アプリの設計と仕様を調べ、取消可否や結果の閲覧者を個別に記録する。

• 回答、引用元、履歴、添付ファイルの取得結果を区別する。
• 予約・実行中・再実行可能な処理の実行主体と出力先を特定する。

6. 本番保守と引継ぎをどう完了させるか

引継ぎでは、退職者のアクセスを残すことと、必要な業務処理を維持することを同じ解決策にしない。OWASPはCI/CDで高い権限の資格情報が利用されることを踏まえ、最小権限での管理を示している。[2] 本稿では、本番公開、設定変更、障害時の再実行に必要な権限を後任の役割へ割り当て、個人用資格情報をそのまま渡さないことを提案する。例えばデプロイ設定の管理者を変更しただけで終えず、秘密情報の参照権限、実行権限、承認権限を分けて確認する。移管後は、後任が必要な保守操作を行えることを、停止確認とは別に記録する。

完了報告は「全件停止済み」の一文ではなく、確認済みの範囲と残った課題を示す。本稿では、確認表の各行に実施日時、確認者、観測結果、未確認事項の担当と期限を付けることを提案する。OWASPはセッションの生成・更新・破棄などの記録を推奨し、生のセッションIDをログへ含めないよう示している。[1] これを踏まえ、証跡には資格情報そのものではなく、操作対象の識別情報と結果を残す。未確認の外部連携があれば、対象経路の利用制限などの暫定措置と再確認予定を記録し、保守担当が残存リスクを追える状態で引き継ぐ。

• 後任の保守権限と必要な業務連携を確認する。
• 未確認事項に担当、期限、暫定措置を付けて引き継ぐ。

よくある質問

停止担当者が不在の場合はどう判断しますか。

本稿では、事前に代理担当と承認経路を定めることを提案します。代理者に操作権限がなければ、実施可能な入口の制限を管理責任者へ相談し、できていない停止対象を残します。権限を借りるために他人の管理者資格情報を共有するのではなく、正式な権限付与や既定の緊急手順を使います。

停止前のセッションを確認できる環境がない場合は合格にできますか。

実動作の確認ができていない範囲は、合格ではなく未確認です。本稿では、同じ構成の管理下のテストアカウントで確認する計画を立てることを提案します。環境差がある場合はその差を記録し、管理操作の証跡や公式仕様の確認と、実際の拒否確認を区別して報告します。

一時休職でも退職時と同じ停止が必要ですか。

本稿では、復帰を予定する状態変更と、アクセスを許可する範囲を分けて決めることを提案します。休職中の業務利用を認めないなら、その方針に沿う停止対象を設定します。復帰時は古い資格情報の復活を前提にせず、担当する業務と現在の権限を再確認して再開する手順を用意します。

引継ぎのため期限付きでアクセスを残す場合はどうしますか。

本稿では、退職者の従来アカウントを無期限に残す例外ではなく、別途承認した範囲・期限のアクセスとして扱うことを提案します。対象データ、許可操作、責任者、終了日時、終了後の確認担当を決めます。期限で実際に止まる仕組みを確認できない場合は、自動終了すると記載せず、手動停止の担当と確認予定を明示します。

参考・関連資料

• [1] Session Management - OWASP Cheat Sheet Series ↗
• [2] Secrets Management - OWASP Cheat Sheet Series ↗

公式資料の確認日：2026-10-13。業務例は説明用で、顧客の実績ではありません。編集：株式会社N2i。執筆にAI支援を使用し、別のAIによる出典・品質確認に合格した記事を公開する方針です。