はじめに
退職したユーザーは、社内の 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 側の入口・ユーザー・トークン・例外経路を原因別に潰す。