はじめに

退職したユーザーは、社内の IdP や LDAP で無効化すれば Salesforce にもログインできなくなる、と考えがちです。

しかし、Salesforce には複数のログイン経路があります。SSO を設定していても、Salesforce のユーザー名とパスワードによる直接ログイン、モバイルアプリ、API、接続アプリ、既存セッションなどが残っていると、退職者が Salesforce にアクセスできてしまう可能性があります。

この記事では、退職者が Salesforce にログインできてしまう代表的な原因と、原因ごとの対策を整理します。

この記事は Salesforce の認証設計を一般化して整理したものです。特定の資格試験問題や選択肢の再現ではありません。

まず押さえたい前提

SSO を設定しただけでは、必ずしも Salesforce への直接ログインが無効になるわけではありません。

Salesforce の公式ヘルプでも、SSO を設定した状態ではユーザーが SSO プロバイダーまたは Salesforce からログインできるため、SSO を迂回させないには Salesforce ユーザー名とパスワードでのログインを無効化する必要がある、と説明されています。

つまり、退職者ログイン対策では次の3つを分けて考える必要があります。

認証元: IdP、LDAP、Salesforce のどこで本人確認しているか
ログイン経路: My Domain、login.salesforce.com、モバイル、API など、どこから入れるか
ログイン後の状態: ユーザー、権限、OAuth トークン、既存セッションが残っていないか

原因別のロードマップ

よくある原因と対策

原因A: IdP/LDAPでは無効化済みだが、Salesforce直接ログインが残っている

退職処理で IdP や LDAP のアカウントを無効化しても、Salesforce 側でユーザー名とパスワードによるログインが残っていると、SSO を通らずにログインできる場合があります。

確認するポイントは次のとおりです。

My Domain のログインポリシー
login.salesforce.com からのログイン可否
My Domain の認証設定に Login Form が残っていないか
対象ユーザーに SSO 必須化の権限が適用されているか

対策としては、標準ユーザーを SSO 経由に寄せ、Salesforce 直接ログインを制限します。具体的には、My Domain で login.salesforce.com からの直接ログインを防止し、SSO 対象ユーザーには Salesforce ログイン情報によるログインを無効化します。

ただし、Salesforce 公式ヘルプでは、SSO 障害時に対応できるようにシステム管理者には SSO を必須にしないことが推奨されています。管理者の緊急ログイン手段は、通常ユーザーとは分けて設計するのが現実的です。

原因B: Salesforceユーザーが有効なまま

IdP 側で退職者を無効化しても、Salesforce のユーザーが有効なままだと、他の経路からログインできる余地が残ります。

Salesforce ユーザーは削除ではなく無効化します。無効化すると、過去の活動履歴や所有レコードを保持したままアクセスを止められます。

一方で、対象ユーザーがリードやケースのデフォルト所有者、ワークフローユーザー、承認者などになっている場合、すぐに無効化できないことがあります。この場合は、所有者や参照設定の見直しを進めつつ、先にユーザーを凍結してログインを止めます。

退職時のチェックには、少なくとも次を含めるとよいです。

Salesforce ユーザーの有効チェック
最終ログイン日時の確認
プロファイル、権限セット、ロールの確認
所有レコード、承認プロセス、キューメンバー、デフォルト所有者の確認

原因C: OAuth・接続アプリ・既存セッションが残っている

ユーザー名とパスワードのログインを止めても、接続アプリや OAuth セッションが残っていると、モバイルアプリや外部ツールからアクセスが継続する可能性があります。

特に確認したいのは次の経路です。

Salesforce モバイルアプリ
データローダーや外部連携ツール
AppExchange やサードパーティ接続アプリ
API クライアント
既存のブラウザセッション

対策は、対象ユーザーまたは対象アプリの OAuth セッションを取り消すことです。Salesforce の接続アプリケーションの OAuth 利用状況では、現在の OAuth アプリ接続を確認し、アプリの有効なセッションを取り消したり、組織全体でブロックしたりできます。

退職者対応では、ユーザー無効化だけでなく、接続アプリとセッションの棚卸しもセットで実施すると安全です。

原因D: 退職処理がSalesforceに連動していない

退職時に人事システムや IdP ではアカウントが無効化されているのに、Salesforce への依頼や自動連携が漏れているケースです。

この場合、技術的な認証設定だけでなく、退職処理の業務フローも見直す必要があります。

対策としては、次のような仕組みを検討します。

IdP 側の退職処理を Salesforce のユーザー無効化に連動させる
SCIM やユーザープロビジョニングを使ってアカウント状態を同期する
手動運用の場合は、退職チェックリストに Salesforce 無効化を明記する
退職後のログイン履歴を監査する

重要なのは、IdP 側で止めることと Salesforce 側で止めることを別作業にしないことです。

原因E: 管理者・連携ユーザー・Sandboxが例外扱いになっている

退職者対策で見落としやすいのが、通常ユーザー以外のアカウントです。

たとえば、次のようなユーザーや環境は退職処理の対象外になりがちです。

システム管理者
連携用ユーザー
共有アカウントのように使われているユーザー
Sandbox のユーザー
Experience Cloud の外部ユーザー
API 専用ユーザー

対策は、例外をなくすことではなく、例外を明示的に管理することです。

管理者や連携ユーザーは、個人にひもづく通常ユーザーとは別の観点で管理し、最小権限、利用目的、所有者、認証方式、ローテーション手順を定義します。Sandbox も本番と同じ退職処理の観点で確認します。

ログインフローで止めればよいのか

ログイン時に外部システムへコールアウトして、ユーザーの有効状態を確認するカスタムログインフローを考えることもできます。

ただし、これは主対策にするよりも、補助的な制御として考えた方がよいです。理由は、ログインフローは Salesforce の認証設計そのものを置き換えるものではなく、実装・運用・障害時の考慮が増えるためです。

退職者ログインを防ぐ基本は、次の順番で考えるのが分かりやすいです。

SSO を正しく構成する
Salesforce 直接ログインを制限する
Salesforce ユーザーを無効化または凍結する
OAuth トークンと既存セッションを取り消す
退職処理と Salesforce のユーザー管理を連動させる

退職時チェックリスト

最後に、退職者対応で確認したい項目をチェックリスト化します。

IdP / LDAP のアカウントを無効化した
Salesforce ユーザーを無効化した
すぐ無効化できない場合はユーザーを凍結した
login.salesforce.com からの直接ログインを制限している
My Domain の認証設定を確認した
対象ユーザーに SSO 必須化が適用されている
接続アプリと OAuth セッションを確認した
モバイルアプリや API 経由のアクセスを確認した
管理者、連携ユーザー、Sandbox、Experience Cloud の例外を確認した
退職後のログイン履歴を確認した

まとめ

退職者が Salesforce にログインできてしまう原因は、IdP や LDAP の無効化漏れだけではありません。

むしろ多いのは、IdP では止まっているのに、Salesforce 側に別の入口が残っているケースです。

退職者ログインを防ぐには、SSO 設定だけでなく、Salesforce 直接ログイン、ユーザーの有効状態、OAuth トークン、既存セッション、例外ユーザーまでをセットで確認する必要があります。

結論としては、次の考え方が重要です。

IdP で止めるだけでなく、Salesforce 側の入口・ユーザー・トークン・例外経路を原因別に潰す。

参考

シングルサインオン (SSO) を使用したログインをユーザーに要求
[私のドメイン] 設定の構成
Add Identity Providers to the My Domain Login Page
Deactivate Users
現在の OAuth 接続アプリケーションセッションの管理
Manage Access to a Connected App