SaaSアカウント管理の実務：シャドーITの可視化とSSO・SCIM

クラウドサービスを手軽に契約できるようになり、各部門が独自の予算でSaaSを契約することが増えています。管理部門が把握していないSaaS（シャドーIT）が増えると、次のような問題が起きます。

• 退職者のアカウントが残る
  退職者のメールアカウントを停止しても、部門で独自に契約したSaaS（例：デザインツール、カンバンボード、顧客管理システム）のIDが残っている場合があります。SaaS独自のID・パスワードでログインできる設定なら、IdPやメールの停止だけではアクセスが止まらず、退職後も会社のデータを閲覧できる状態が続くおそれがあります。
• パスワードの使い回しと共有アカウント
  「xxxチーム用」といった共通のID・パスワードを複数人で使う運用です。担当者が辞めるたびにパスワードの変更が必要になるうえ、ログイン履歴が残っても、どの個人が操作したのかを特定しにくくなります。事故や誤操作の調査と、退職者のアクセスの停止が難しくなります。
• 権限の過剰な付与と使われていない契約
  とりあえず全員に管理者権限を付けている、使っていないアカウントの費用を払い続けている、といった状態です。SaaSの数が増えるほど、権限と請求が妥当かを確認する担当が曖昧になります。

盗まれた認証情報でSaaSにログインされ、データが持ち出された公表事例（Snowflakeを利用する企業の事案）は、情報漏洩の原因とは？被害事例から見る侵入経路と対策で整理しています。

SaaSの乱立に気づくと、まずID統合の製品（Microsoft Entra IDやOktaなど）の導入を考えがちです。しかし、どのSaaSを誰が使い、誰が管理しているかが分からないまま連携を始めると、対象から漏れるサービスや、扱いの決まらない例外のIDが残ります。システムで制御する前に、現状を把握し、運用のルールを決めます。

対策は、次の3つの段階の順に進めます。

1. 発見（可視化）：使われているSaaS、利用者、管理者、契約を、複数の記録から洗い出す
2. 統制（ルール化）：導入の基準、管理者、例外の扱い、棚卸しの時期を決める
3. 自動化（ID連携）：対応するサービスからSSO・SCIMを設定し、連携できないサービスは手動の手順を決める

自動化した後も、連携先のサービスで処理が反映されたか、連携外のサービスに作業が残っていないかを確認します。結果の確認までを一連の運用として扱います。

SaaSの利用状況を、1つの記録だけで漏れなく把握するのは難しいものです。経費・請求、登録の通知、部門の申告と管理画面、通信の記録など、取得元の異なる記録を照合します。それでも見つからないサービスが残ることを前提に、確認した範囲と未確認の範囲を分けて台帳を作ります。

台帳には、サービス名、利用部門、業務責任者（オーナー）、管理者、利用者と権限、契約と更新日、扱うデータ、IdPとの連携の状態（SSO・SCIMの有無）、確認に使った記録と日付、未確認の事項を記録します。業務責任者は利用を判断する部門の責任者、管理者は設定を変更できる担当者です。同じ人が兼ねる場合も、役割を分けて記録します。

業務責任者や管理者が分からないサービスは、仮の確認担当と期限を決め、「未確認」として記録します。担当が分からないことやログインがないことだけを理由に、通信の遮断や解約は行いません。

可視化できたら、新しいSaaSの導入と、既存のSaaSを管理するルールを決めます。「申請が面倒」「許可が下りるまで1か月かかる」といった状況では、申請を通さない利用（新たなシャドーIT）が増えやすくなります。申請の手続きはできるだけ簡単にし、そのうえで次の項目を導入時と契約更新時に確認します。

ルールが決まったら、対応するサービスから自動化に入ります。中心になるのは、社員などのIDを管理するIdP（Identity Provider）です。

SSOは、IdPでの認証を使って、連携したSaaSにログインする仕組みです。SCIMは、IdPとSaaSの間で、ユーザーの作成・属性の更新・無効化などを連携するための標準の仕様です。SSOは「誰がログインできるか」という入口を、SCIMは「SaaS側にどのアカウントがあり、有効か」という状態を扱います。

SSOだけを設定した場合、IdPでの認証を止めても、SaaS側のアカウント・権限・ライセンスの割り当ては残ります。SaaS独自のログインやAPIの認証情報が使える設定なら、そこからのアクセスも残ります。SCIMで無効化を連携すると、一般にSaaS側のアカウントをサインインできない状態にできますが、無効化と削除が具体的に何を意味するかは連携先の実装によって異なります（Microsoft：プロビジョニングの仕組み）。無効化を受けた後に、権限の変更やライセンスの解除を行うかどうかも、SaaS側の処理によります（Okta：Understanding SCIM）。既存のセッションの終了、データの保持・削除、ライセンスの割り当て解除、契約数と請求の変更は、それぞれ別の処理として確認します。割り当て解除と契約数・請求の変更の違いは、ITコスト適正化の実務で扱っています。

自動連携を始める前に、対象にするユーザーとグループ、SaaS側に既にあるIDとの照合の方法、同期する属性と権限、利用中のプランで使える機能、無効化・削除したときの動きを確認します。Microsoft Entra IDの自動プロビジョニングでは、アプリへの割り当てやスコープの条件で対象のユーザーが決まり、照合に使う属性でSaaS側の既存のアカウントと結び付けます。連携先で失敗した処理は次の同期で再試行され、結果はプロビジョニングログで確認します。グループそのものを連携できるのは、グループに対応するアプリに限られます（Microsoft：プロビジョニングの仕組み、確認日：2026年10月）。連携のエラー、対象外のID、管理用の認証情報の失効に気付ける通知を設定し、担当者が残る作業を確認する手順も決めておきます。

SSOは認証を扱う仕組みで、SaaSの中での権限や役割は別に確認します。管理用のAPIトークンやパスワードそのものは、台帳や確認表に書きません。

具体的な構成を3段階の例で示します。例としてMicrosoft Entra IDを挙げますが、OktaやGoogle Workspaceなど、ほかのIdPでも段階の考え方は使えます。すべての企業が同じ製品・プラン・構成を必要とするわけではありません。各段階は導入の候補の例で、必要な機能のプラン、対象のサービスの対応、運用する体制を確認してから選びます。

1. 最小構成：SSO + MFA
   業務で使う主なSaaSのうち、SSOに対応するものからEntra IDと連携します。セキュリティの既定値群では、MFAなどのあらかじめ用意された基本的な保護をまとめて適用します。対象や条件を個別に選ぶことはできず、利用者に追加の認証を求める場面はMicrosoftが判断します（Microsoft：セキュリティの既定値群）。利用者・サービス・サインインの条件を細かく指定する場合は、条件付きアクセスのポリシーを使い、必要な機能・ライセンスと既存の設定を確認します（Microsoft：MFAの概要）。どちらの場合も、どの条件で、どの認証を求めるかを確認します。パスワードの使い回しや、盗まれたパスワードによる不正なログインのリスクを下げることが目的です。連携しないサービスと、SaaS独自のログインが残るサービスは台帳に記録します。
2. 標準構成：SSO + SCIM（グループ連動）
   「営業部」「経理部」などの所属のグループと、サービスごとに利用を許可するグループを作り、必要なSaaSに割り当てます。SCIMに対応するサービスでは、割り当てに合わせてアカウントの作成・属性の更新・無効化を連携します。反映のタイミング、グループの連携への対応、無効化と削除のどちらになるかはサービスと設定によるため、導入時に試験用のユーザーで動きを確かめます。
3. 高度構成：人事データとの連携 + 条件付きアクセス + 例外管理
   人事システムの情報をIdPに取り込み、入社・異動・退職の変更をIdPの属性に反映して、そこからSCIMなどで各サービスへ連携する構成です。人事システムとの連携は、利用する製品に対応するコネクタやAPI、連携する項目を確認して設計します。製品の組み合わせだけで、設定なしに自動で接続されるわけではありません。さらに、管理された端末からのアクセスに限るなどの条件付きアクセスと、例外のIDの期限・承認の管理を加えます。

システムを導入しても、依頼・承認・処理・確認の担当が決まっていなければ、処理の漏れに気付けません。入社（Joiner）・異動（Mover）・退職（Leaver）の各段階で、次の5つの役割を分けます。専任の情シスや人事システムがない企業でも、社員名簿と依頼のチケット（または確認表）を使って同じ流れで進められます。

• 人事：入社・異動・退職の事実と日付を確定し、依頼を出す
• 業務責任者：必要なサービスと権限を承認し、異動・退職時の引継ぎと不要な権限を確認する
• 管理者・委託先：IdPと各サービスで、アカウントの発行・変更・停止を行う
• 自動連携（SCIMなど）：対応するサービスで、設定した範囲の作成・更新・無効化を行う
• 結果確認者：各サービスで処理が反映されたか、残る作業がないかを確認して記録する

異動では、新しい権限の付与に加えて、旧部門の権限・役割・例外が残っていないかを確認します。人事の属性を変えただけで、すべての旧サービスの権限やログインの状態がすぐに変わるとは限りません。

退職時は、会社が定めたアクセスの終了日時に合わせて、IdPと各サービスで必要なアクセスを止めます。IdPでサインインを止めても、アプリ自身が発行したセッションはIdPから直接取り消せない場合があり、連携による無効化が反映されるまでの時間もサービスと設定によって異なります（Microsoft：アクセスの取り消し）。終了日時に間に合わせるため、サービス側のセッション・アクセス・連携の結果も確認し、必要な手動の処理を用意しておきます。アクセスの停止は、データの削除や契約の変更が済むまで待たずに行います。データの保持・移管、アカウントの削除、ライセンスと請求の変更は、それぞれ条件を確認して別に判断します。Google Workspace・Microsoft 365で管理者、データの保持・移管、共有を確認する手順は、Google Workspace・Microsoft 365の運用を引き継ぐで製品別に扱っています。

処理の結果は、連携の範囲ごとに分けて記録します。次の表は記入の仕方を示すための例です。実際の企業の診断結果や、処理の実績ではありません。

未確認の項目を、停止済み・安全・費用0円として扱いません。連携の遅延やエラー、連携外のサービスが残る場合は「完了」とせず、担当・期限・代わりの対応と確認の結果を残します。SCIMの処理が完了した記録があっても、それだけでデータの保持や、すべてのアクセスの停止が済んだとは扱いません。

SSO・SCIMを導入する過程では、次のような問題が起きやすくなります。

• SSOを導入した後も、共有アカウントが残る
  ライセンスの費用を抑えるために代表アドレスでSSO連携し、複数人で使い回す場合です。サインインの記録は残っても、どの個人が操作したかを特定しにくく、利用者が辞めるたびに認証情報の変更が必要になります。共有IDが必要な場合は、用途・利用者・承認・追跡の方法を確認し、例外として期限と是正の予定を記録します。
• IdPで停止しただけで、全サービスで完了したと扱う
  IdPで処理しても、連携先への反映の遅れやエラー、SaaS独自のログイン、アプリが発行したセッション、連携外のIDが残る場合があります。IdPでの処理の記録と、連携先での状態の確認は分けて記録します。IdPのサインインの記録は、各SaaSの中で行われた操作の記録とは別のものです。
• グループ設計が場当たり的で、権限の根拠が分からなくなる
  IdPのグループを場当たり的に作りすぎると、誰に何の権限があるのか分からなくなります。組織図に基づく「所属グループ」と、特定のSaaSの利用を許可する「アプリ利用グループ」は分けて設計します。
• 例外のアカウント（外部委託・派遣）の扱いが曖昧
  社員の退職の手順は整っていても、業務委託や派遣のメンバーの契約が終わったときに、アカウントが残りやすくなります。委託先のIDは契約の終了予定日を記録し、有効期限や見直しの期限を設けて、定期的な棚卸しで確認します。

監査や審査で求められる内容は、制度、対象の範囲、監査人などによって異なります。次の表は、アクセス管理の状態を説明するためにそろえておく記録の例で、合否の基準や必須の要件の一覧ではありません。これらの記録だけで、監査や上場審査の判断が決まるわけでもありません。IT全般統制（ITGC）として整える範囲は、IPO準備のIT全般統制（ITGC）で扱っています。