SCIM連携や自動プロビジョニングで退職者アカウントがSaaSに残る原因を整理。同期対象、グループ、手動招待、provisioning logs、active=false、証跡確認、エスカレーション条件まで情シス・SaaS管理者向けに解説します。
冒頭要約
SCIM連携や自動プロビジョニングは、IdPからSaaSへユーザー、グループ、属性、無効化状態を同期するための仕組みです。退職者や委託終了者のアカウントをSaaSに残さないために有効ですが、設定ずれ、同期対象外、手動招待、ログ失敗があると、SaaS側に有効なアカウントや権限が残ることがあります。
最初に確認すべきなのは、「SSOでログインできないか」だけではありません。人事・IdPの状態、SCIMの割り当て範囲、SaaS側の実ユーザー一覧、provisioning logs、手動で作られたローカルアカウントを同じ時間軸で照合します。
この記事では、情シス、SaaS管理者、開発組織の管理者向けに、SCIM連携の確認方法、退職者アカウントを残さないチェックリスト、初動対応、エスカレーション条件を整理します。攻撃手順、悪用コード、侵入再現、探索クエリは扱いません。
SSOは「ログインできるか」を主に扱い、SCIMは「対象SaaSにユーザーやグループを作る・更新する・無効化する」運用に関わります。SSOを止めたつもりでも、SaaS側のメンバーシップ、外部共有、トークン、手動招待が残る場合があります。
読者別の影響：誰が何を見るべきか
SCIM連携の確認は、IdP担当だけで完結しません。退職・異動・委託終了の情報、SaaS側の実状態、監査ログ、開発基盤の外部コラボレーターまでつなげて判断します。
| 読者・担当者 | まず見るもの | 見落としたときの問題 |
|---|---|---|
| 情シス・IdP管理者 | IdPのユーザー状態、割り当てグループ、SCIMアプリ設定、provisioning logs | 無効化がSaaSへ反映されず、退職者が対象SaaSに残る |
| SaaS管理者 | SaaS側のユーザー一覧、ロール、外部ユーザー、手動招待、監査ログ | IdPで見えないローカルアカウントや高権限ロールが残る |
| 開発者・GitHub管理者 | Organization member、Enterprise Managed User、外部コラボレーター、PATやSSH key | リポジトリやCI/CDのアクセスが退職後も残る |
| CSIRT・SOC | 同期失敗、手動追加、権限変更、退職後ログイン、トークン利用 | 不審操作の有無を判断できず、初動が遅れる |
| 人事・監査担当 | 退職日、最終稼働日、契約終了日、例外承認、再確認期限 | アカウント停止の証跡が説明できない |
関連する基礎概念は、SCIM、SSO、IAM、Access Reviewで整理できます。ログイン可否と利用権限の違いは、認証と認可の違いを先に確認すると判断しやすくなります。
SCIM連携とは：SSOとの違いを先に分ける
SCIM（System for Cross-domain Identity Management）は、複数ドメイン間でID情報を管理するための標準プロトコルです。実務では、Microsoft Entra ID、OktaなどのIdPから、GitHub、Slack、業務SaaS、開発基盤へ、ユーザー作成、属性更新、グループ同期、無効化を自動化する用途で使われます。
ただし、SCIMは「設定すれば全SaaSの退職者が必ず消える魔法」ではありません。特に次の違いを分けて見ます。
| 観点 | SSO | SCIM / 自動プロビジョニング |
|---|---|---|
| 主な目的 | ログイン時の認証をIdPへ集約する | SaaS側のユーザー・グループ・属性を作成、更新、無効化する |
| 退職時の意味 | IdP認証を止める | 対象SaaSのアカウントやメンバーシップを無効化・削除する |
| 見るべきログ | サインインログ、MFA、条件付きアクセス | provisioning logs、SaaS監査ログ、グループ同期ログ |
| 見落としやすい対象 | SSO外アカウント、ローカル管理者 | 手動招待、同期対象外グループ、外部コラボレーター |
GitHubのように、SCIMを使ってアカウントやOrganization membershipを管理できる一方、手動招待や手動削除でSCIMのリンクがずれる可能性を公式ドキュメントが注意しているサービスもあります。製品ごとの仕様差を前提に、IdPとSaaSの両方を確認します。
まず確認すること：SCIM同期ずれチェックリスト
退職者アカウントや委託終了者のアクセスが残っていないかを確認するときは、次の順番で見ると抜けにくくなります。
| 確認項目 | 見るポイント | 記録すること |
|---|---|---|
| 1. 対象SaaSの確定 | SCIM対象、SSOのみ、個別ID、部門契約SaaSを分ける | SaaS名、管理者、契約部門、SCIM有無 |
| 2. Source of truth | 人事、IdP、委託先台帳のどれを正とするか | 退職日、最終稼働日、契約終了日 |
| 3. IdPユーザー状態 | disabled、suspended、deleted、グループ未所属などの状態 | 変更日時、実施者、チケット番号 |
| 4. SCIMアプリ割り当て | 対象グループ、ユーザー割り当て、スコープ条件 | どのグループから外したか |
| 5. グループ同期 | ネストしたグループ、除外グループ、手動ロール付与 | 反映対象と対象外の理由 |
| 6. SaaS側ユーザー | active、disabled、pending、guest、external collaborator | ユーザー状態、ロール、最終利用日時 |
| 7. 手動招待・ローカルアカウント | IdPに紐づかないユーザー、管理者が直接招待したユーザー | 招待者、作成日、所有部門 |
| 8. provisioning logs | Create、Update、Disable、Delete、Skipped、Failure、Warning | 対象ユーザー、Action、Status、エラー |
| 9. SCIM認可ユーザー・トークン | SCIMアプリを認可した管理者、API token、連携アカウント | 所有者、失効日、ローテーション有無 |
| 10. 残るアクセス | セッション、Personal Access Token、SSH key、OAuth app、外部共有 | 失効・削除・保留の判断 |
特に、provisioning logsでは「成功したか」だけでなく、ActionとStatusを分けて見ます。Microsoft Entraのログでは、Create、Update、Delete、Disable、Skipped、Warning、Failureのような状態を手掛かりに、対象ユーザーがどのステップで止まったかを確認できます。
provisioning logsでSuccessになっていても、SaaS側で期待どおりのロールやグループから外れているとは限りません。IdPログ、SaaSユーザー一覧、SaaS監査ログを同じユーザー・同じ時刻で見ます。
初動対応：やること、やらないこと、記録すること
やること
- 退職日、最終稼働日、委託終了日を確認し、対象者のIdP状態とSaaS側状態を一覧化する。
- 対象SaaSごとに、SCIM対象、SSOのみ、手動管理、外部コラボレーターを分ける。
- provisioning logsで、対象者に対するDisable、Delete、Update、Failure、Skipped、Warningを確認する。
- SaaS側で、activeなユーザー、管理者ロール、外部共有、APIトークン、SSH key、OAuth appを確認する。
- SCIMアプリを認可している管理者や連携アカウントが退職・異動していないか確認する。
- 説明できないactiveユーザーや管理者権限が残っている場合は、削除前に証跡を残してセキュリティ担当へ上げる。
やらないこと
- 「SSOでログインできないから完了」と判断しない。
- IdPグループから外しただけで、SaaS側のロール、外部共有、トークン確認を省略しない。
- 証跡を取る前に対象アカウントを完全削除し、後続調査に必要なログや属性を失わない。
- 手動招待で一時対応を続け、SCIMのリンクずれを増やさない。
- 製品ごとの制約を確認せず、複数IdPや複数SCIM経路を混在させない。
記録すること
| 記録項目 | 例 |
|---|---|
| 対象者 | 氏名ではなく管理用ID、メール、社員番号、委託先ID |
| 人事イベント | 退職日、異動日、契約終了日、最終稼働日 |
| IdP状態 | disabled、グループ削除、アプリ割り当て解除、実施時刻 |
| SCIMログ | Action、Status、Source、Target、エラー、最終成功時刻 |
| SaaS状態 | active/disabled、ロール、外部共有、最終ログイン、手動招待 |
| 追加対応 | セッション失効、トークン失効、外部共有停止、所有権移管 |
| 判断 | 削除、無効化、保留、例外承認、再確認日 |
この記録は、退職者アカウント確認チェックリストとSaaS権限棚卸しチェックリストにそのまま接続できます。ログの読み方に不安がある場合は、セキュリティログの読み方とアクセスログ解析ミニCTFで基礎を確認できます。
判断基準：どこまでエスカレーションするか
SCIM連携のずれは、すべてが重大インシデントではありません。実務では、残っている権限の強さ、対象データ、退職後の利用有無、ログの説明可能性で優先度を決めます。
| 優先度 | 状況 | 初動判断 |
|---|---|---|
| 高 | 退職者、異動者、委託終了者がSaaS側でactiveなまま | 証跡保全、即時無効化、SaaS監査ログ確認、関係者へエスカレーション |
| 高 | 管理者ロール、リポジトリ管理、顧客データ、請求、監査ログに触れる権限が残る | インシデント候補として扱い、トークン・セッション・外部共有も確認 |
| 高 | provisioning logsにFailure/Warningが継続し、複数ユーザーへ影響 | 一括同期失敗として、IdP/SaaS管理者と復旧計画を作る |
| 中 | 手動招待やローカルアカウントが台帳にない | 所有者確認、停止、SCIM管理へ戻す計画を作る |
| 中 | グループ同期は成功しているが、SaaS側ロールが想定と違う | ロールマッピング、例外付与、手動ロールを確認する |
| 低 | pending招待、未使用アカウント、説明済みの例外 | 期限と承認者を記録し、次回レビューに入れる |
退職後ログイン、退職後のトークン利用、外部共有の新規作成、管理者ロール付与、監査ログ設定変更が見つかった場合は、SCIM設定ミスだけで終わらせず、漏えい疑い初動テンプレートへ進みます。
よくある誤解
「SCIMを入れたのでアクセスレビューはいらない」
SCIMは自動化の仕組みであり、棚卸しの代替ではありません。同期対象外、手動招待、外部ユーザー、ローカル管理者、OAuthアプリ、Personal Access Tokenは別途確認が必要です。
「active=falseなら完全削除された」
多くのサービスでは、deprovisioning時にアカウントを無効化し、必ずしも即時削除しません。データ保持、所有権移管、監査ログ、セッション無効化の扱いはSaaSごとに異なります。公式ドキュメントと管理画面の実状態を確認します。
「IdPグループから外したらSaaSのロールも消える」
グループ同期とSaaS内部ロールの関係は製品ごとに違います。手動ロール付与、ネストグループ非対応、例外グループ、同期遅延があると、期待どおりに外れない場合があります。
「SCIMアプリの認可ユーザーは誰でもよい」
SCIM連携を認可している管理者やAPIトークンが退職・異動・権限変更されると、同期が止まることがあります。専用の運用アカウントや所有者、ローテーション、監査ログを確認します。
「手動で直せば早い」
一時的な手動修正が必要な場合もありますが、手動招待や手動削除はSCIMのリンクずれを増やすことがあります。証跡を残し、恒久的にはSCIM管理へ戻す計画を作ります。
関連用語・関連ページ
| 目的 | ページ |
|---|---|
| 退職・異動時の作業へ落とす | 退職者アカウント確認チェックリスト、SaaS権限棚卸しチェックリスト |
| 残存アカウントを見つけた時の初動 | 退職者アカウントが残っていた時の初動対応、管理者権限付与の初動対応 |
| SaaS全体の棚卸しへ広げる | SaaS権限棚卸しの進め方、SaaS外部共有リンクの棚卸し、委託先・外部パートナーアカウントの棚卸し |
| 基礎概念を確認する | SCIM、IdP、SSO、IAM、Service Account |
| 違いを理解する | 認証と認可の違い、SSOとMFAの違い |
| 学習・演習へ進む | ゼロトラストアーキテクチャ、認証と認可のミニCTF、クイズで用語を復習する |
公式情報・参考情報
- RFC 7644: System for Cross-domain Identity Management: Protocol — SCIMのプロトコル仕様と、複数ドメイン間のID管理を標準化する目的を確認できる。
- Microsoft Learn: How Application Provisioning works in Microsoft Entra ID — Entra IDの自動プロビジョニングがユーザー作成、更新、削除、SCIM endpoint連携を扱うことを確認できる。
- Microsoft Learn: What are the Microsoft Entra user provisioning logs? — provisioning logsのAction、Status、Source/Target、詳細ステップ、変更プロパティの見方を確認できる。
- GitHub Docs: Configuring SCIM provisioning for Enterprise Managed Users — Enterprise Managed UsersでIdPからSCIMを使ってユーザーライフサイクルを管理する方法を確認できる。
- GitHub Docs: About SCIM for organizations — GitHub OrganizationでSCIMを使わない場合や手動操作で残存・リンクずれが起きる可能性を確認できる。
- Okta Developer: Understanding SCIM — SCIMのsource of truth、active=false、out-of-sync属性、rate limit時の考え方を確認できる。
まとめ
SCIM連携と自動プロビジョニングは、退職者アカウントをSaaSに残さないための重要な仕組みです。ただし、SSO停止、IdPグループ解除、SCIM同期成功、SaaS側の実権限は別々に確認する必要があります。
実務では、対象SaaS、source of truth、SCIM割り当て、グループ同期、SaaS側ユーザー、手動招待、provisioning logs、SCIM認可ユーザー、残るトークンや外部共有を順番に見ます。退職者や委託終了者がactiveなまま、または管理者権限や顧客データに触れる権限が残っている場合は、証跡を取ってから即時無効化とエスカレーションを行います。
次に実務へ落とすなら、退職者アカウント確認チェックリストに「SCIM対象/対象外」「provisioning logs」「手動招待」「SCIM認可ユーザー」「SaaS側active確認」を追加し、四半期のSaaS権限棚卸しで再確認します。
