退職・契約終了時、アクセスは本当に止まっていますか？Cloudflareと確認するセッション管理

退職や委託契約の終了時、「アカウントを止めた」で作業を終えていませんか。社内アプリやSaaSでは、すでにログインした状態や、個別に発行した連携用の認証情報も確認対象です。今回は認証方式の選び方から視点を移し、利用終了時にアクセスを閉じ、結果を確かめる運用を整理します。

「次のログイン」と「ログイン済み」を分ける

セッションとは、ログイン後に利用者として操作できる状態を保つ仕組みです。Cloudflare Accessの公式資料では、継続的にアクセスを取り消す際、認証基盤（IdP）のアカウント無効化と、Access側のセッション失効を組み合わせる手順を案内しています。セッションだけを失効させても、認証基盤の利用者が有効なら、新しいセッションを作れるためです。

また、AccessでSaaSへのログインを連携していても、SaaS内部のセッション時間は、そのSaaS自身が管理します。入口での制御だけで、利用中のすべての画面や接続が終了すると判断せず、サービスごとの停止方法を確認しましょう。

担当者が変わっても実行できるチェック表にする

以下は公式資料を踏まえた実務上の点検案です。人事・契約担当からIT担当へ、対象者と利用終了日時を伝える経路を決め、各システムの管理者が結果を記録します。異動の場合は全面停止ではなく、業務に必要な権限へ変更する手順にします。

• 対象を洗い出す：認証基盤、メール、SaaS、社内アプリ、VPNなどの利用先を一覧化し、外部委託先の利用者も含める。
• 引き継ぎを確認する：共有ファイル、業務データ、処理の所有者を整理し、必要な引き継ぎと利用停止を担当者間で調整する。
• 停止を実行する：アカウントや権限の変更に加え、ログイン済みセッション、登録端末、APIキーなどの連携用認証情報に必要な対応を確認する。
• 結果を残す：実施者、実施日時、対象システム、確認結果を記録し、未完了の項目には対応期限を付ける。

共有アカウントや自動処理を見つけたときは、本人のアカウントと同じ扱いで機械的に削除せず、業務への影響と管理責任者を確認します。サービス用の認証情報が個人の退職手続きから抜け落ちないよう、別の管理台帳と照合する方法も考えられます。

Cloudflareの連携で自動化する範囲を決める

Cloudflare Oneには、認証基盤との間で利用者情報などを同期するSCIM連携があります。SCIMは、サービス間で利用者情報をやり取りするための標準です。公式資料では、ユーザーのプロビジョニング解除を有効にした構成で、連携対象からの削除に伴いAccessの稼働中セッションを失効させる機能が説明されています。

ただし、同期対象や解除設定、認証基盤側の構成を確認する必要があります。Zero TrustのSCIM連携と、Cloudflare管理画面へのSSO・SCIM連携も別です。自動化の対象外にあるSaaSや管理者権限まで処理されたとは考えず、実際の契約・対応機能・設定を導入時に確認します。

設定完了より「使えなくなった」の確認を

CloudflareのUser logsでは、登録端末やログイン履歴、セッション情報を確認できます。運用の試験では、管理者が用意したテスト用アカウントで、停止後の再ログインや既存セッションの扱いを確かめましょう。本番の利用者で不用意に試すのではなく、業務影響を避けて手順を検証します。

最初の一歩は、新しい製品を増やすことではなく、重要なサービスの停止手順と担当者をそろえることです。社内アプリへの入口と既存の認証基盤の役割を整理したい場合は、ｉソフトのCloudflare・ゼロトラスト支援内容をご覧ください。

参考情報

• Cloudflare：Session management（2026年11月2日更新）
• Cloudflare：SCIM provisioning（2026年10月30日更新）
• Cloudflare：User logs（2026年11月6日更新）

確認日：2026年11月9日。各資料の公開日は明記されていません。機能・条件は変更される場合があります。