【SaaS乱立対策】シャドーITの可視化とID統合管理（SCIM/SSO）入門
DefinitionSaaS乱立によるセキュリティ低下と無駄なコストを防ぐ仕組みです。全社員のIDを「IdP（統合認証基盤）」で一元管理し、入社時のアカウント自動作成（SCIM）や退職時の即時ロックを単一の操作で完了させます。これにより、情報漏洩の最大の原因である「退職者の亡霊アカウント」を根絶します。
TL;DR (要約)
部門ごとに無秩序に導入されるSaaS（シャドーIT）は、退職者のアカウント消し忘れや請求の重複といった深刻なリスクを生みます。「とりあえずSSOを入れる」のではなく、まずは現状のSaaSを可視化（棚卸し）し、最低限のルールを敷くことが先決です。そのうえで、Entra ID等の統合基盤を用いて「入社・異動・退職」のアカウントライフサイクルを自動化する仕組み（SCIM）を構築することで、監査に耐えうる堅牢な最小権限の環境が完成します。
この記事でわかること
- なぜSaaS乱立は「セキュリティ事故」と「コスト損」を同時に生むのか
- まず押さえる全体像：シャドーIT対策は「発見→統制→自動化」の順
- Step1 可視化：今あるSaaSを“棚卸し”する現実的な方法
- Step2 統制：ルールを作る
- Step3 ID統合の本丸：SSO/MFA/SCIM（プロビジョニング）入門
- 実装パターン：Entra IDを例にした段階別構成
- 運用フローの雛形（Joiner / Mover / Leaver）
- よくある落とし穴（導入・運用の失敗パターン）と監査目線
なぜSaaS乱立は「セキュリティ事故」と「コスト損」を同時に生むのか
クラウドサービスの導入ハードルが下がったことで、各部門が独自の予算でSaaSを契約するケースが増えています。しかし、管理部門が把握していないSaaS（シャドーIT）の増殖は、以下のような致命的なリスクを引き起こします。
- 退職者の「亡霊アカウント」による情報漏洩
退職者のメールアカウントを停止しても、部門で独自契約したSaaS（例：デザインツール、カンバンボード、顧客管理システム）のログイン権限が残ったままになるケースです。退職者が自宅から会社の機密データにアクセスできてしまう非常に危険な状態です。 - パスワードの使い回しと共有アカウントの横行
「xxxチーム用」といった共通のID・パスワードを使ってSaaSを使い回す運用です。スタッフが辞めるたびにパスワードを変更する手間を惜しむため、誰がいつログインして操作したのかというログ（証跡）が一切残らず、インシデント発生時の原因特定が不可能になります。 - ライセンスの過剰付与と重複請求
「とりあえず全員にフル権限を付与する」「すでに使っていないアカウントの月額費用を払い続けている」といったコストの無駄です。SaaSの数が増えるほど、誰も請求の妥当性を確認できなくなります。
▼ 結論：SaaS統制で目指すべき5つの状態
- すべてのSaaSの利用状況と管理者が可視化（棚卸し）されている
- 業務に必要なシステムへ、1つのID・パスワードで安全にアクセスできる（SSO）
- 入社・異動・退職時に、必要なSaaSのアカウント発行と停止が自動化されている（SCIM）
- 誰がいつ、どのSaaSにアクセスしたかの監査ログが一元的に残っている
- 例外的なアクセス権限は、期限付きで正しく承認・記録されている
まず押さえる全体像：シャドーIT対策は「発見→統制→自動化」の順
SaaSの乱立問題に直面すると、すぐに「ID統合ツール（OktaやEntra ID）を導入しよう」と考えがちですが、これは失敗の典型パターンです。システムで制御する前に、まずは現状を把握し、運用ルールを定める必要があります。
対策は必ず以下の3ステップで進めます。
- 発見（可視化）：現在何が使われているかをあぶり出す
- 統制（ルール化）：導入基準と棚卸しの仕組みを作る
- 自動化（ID統合）：仕組み化されたルールをシステムで強制する
Step1 可視化：今あるSaaSを“棚卸し”する現実的な方法
完璧な可視化は困難ですが、複数の手法を組み合わせることで実態の8割〜9割を把握できます。まずは管理部門のデータ（カネとネットワーク）をたどるのが確実です。
| 手法 | 難易度 | コスト | 拾える範囲・特徴 | 注意点 |
|---|---|---|---|---|
| 経費・請求データの確認 | 低 | 低 | 会社のお金で支払われているSaaS全般 | 無料SaaSや個人の立て替えは漏れる。 |
| メール・DNSの監査 | 低 | 低 | 社名ドメインで登録されたサービスの宛先完了メール | 社員への事前告知や規程整備が必須。 |
| SaaS管理台帳（申告） | 中 | 低 | 業務フローに組み込まれている公式SaaS | 定期的な棚卸し運用（年1回等）が必要。 |
| CASB連携・NWログ | 高 | 高 | 社内NW/VPN経由でのSaaSアクセス履歴 | 自宅回線からのアクセスは検知不能。 |
Step2 統制：ルールを作る
可視化できたら「勝手にSaaSを入れさせない」ルールを作ります。しかし、「申請が面倒」「許可が下りるまで1ヶ月かかる」といった状況は、新たなシャドーITを生む最大の原因です。申請フローは極力軽くし、その代わりに最低限のセキュリティ要件を満たしているかをチェックする方針をとります。
チェックリスト
- □ 認証基盤（SSO）に対応しているか？（SAML / OIDC非対応は原則導入不可）
- □ プロビジョニング（SCIM）に対応しているか？（手動管理は破綻するため）
- □ 管理者（オーナー）は部門の責任者になっているか？（属人化の防止）
- □ 誰が権限の棚卸しを定期的に行うか？（運用担当者の明確化）
- □ データの保存場所とエクスポート機能はあるか？（国内法対応とデータポータビリティ）
- □ 監査ログ（ログイン履歴や操作履歴）は一定期間保存されるか？
Step3 ID統合の本丸：SSO/MFA/SCIM（プロビジョニング）入門
ルールが整備されたら、システムによる自動化（Step3）に入ります。ここで必要になる中核技術が「IdP（Identity Provider）」を中心とした各種ソリューションです。
■ 必須用語の再定義
- IdP（Identity Provider）: 全社員のIDを束ねる「身分証発行センター」。Entra IDやGoogle Workspaceなど。
- SSO（シングルサインオン）: IdPの身分証を1回提示するだけで、全連携SaaSにパスワードなしでログインできる仕組み。
- MFA（多要素認証）: スマホ等で本人確認を行う仕組み。SSOとMFAは必ずセットで導入する。
- SCIM（System for Cross-domain Identity Management）: IdPとSaaS間で「ユーザーの作成・更新・削除」を自動同期する世界標準規格。
SSOはあくまで「ログインを便利に（かつ安全に）する仕組み」です。SSOを導入しただけでは、SaaS側に「ログインできないが、存在はしているアカウント情報（ライセンス）」が残り続けます。退職者のアカウント消し忘れや、余分なライセンス費用を防ぐには、SCIMによるプロビジョニング（自動同期）が不可欠です。
| 運用方式 | できること | できないこと（残るリスク） |
|---|---|---|
| 手動管理 | 各SaaSごとの細かい権限設定 | 退職時の消し忘れ多発、パスワード使い回し、ログ分散 |
| SSOのみ | 1つのパスワードで全SaaSにログイン。IdPを止めれば全SaaSへの「ログイン」は防げる | SaaS側のデータ（アカウント／ライセンス枠）は消えず、手動削除が必要 |
| SSO + SCIM | IdPでユーザーを停止すると、SaaS側の「即時停止・ライセンス回収」まで自動で連動 | 連携未対応のSaaS（レガシー系）は手動運用が残る |
実装パターン：Entra IDを例にした段階別構成
概念論だけでなく、具体的な実装アプローチを3段階で示します（例としてシェアの高いMicrosoft Entra IDを挙げますが、OktaやGoogle Workspaceでも考え方は同じです）。
- 最小構成：SSO + MFA
すべての公式SaaSをEntra IDに連携させます。ユーザーはEntra IDでログインし、必ずMFA（Microsoft Authenticator等）を求められます。これで「パスワードの使い回し」と「外部からの不正アクセス」の脅威を大幅に減らせます。 - 標準構成：SSO + SCIM（グループ連動）
「営業部グループ」「エンジニアグループ」といったIdP上のグループを作成し、それぞれのグループに必要なSaaSを紐づけます。SCIMを設定し、ユーザーが「営業部」に所属した瞬間にSFA（営業支援ツール）のアカウントが自動作成され、退職時には即死（アクセスログアウトおよびライセンス剥奪）する仕組みを作ります。 - 高度構成：入退社自動化 + 条件付きアクセス + 例外管理
人事システム（SmartHRなど）とEntra IDを連動させます。人事データが更新されると、Entra IDの属性情報が変わり、それが各SaaSのSCIMに波及する完全な自動化（ゼロタッチプロビジョニング）です。さらに「社給PCからのみアクセス許可」などのコンテキスト制御（Device Trust）を追加します。
運用フローの雛形（Joiner / Mover / Leaver）
システムを導入しても、それを回す運用フローがなければ形骸化します。社員のライフサイクル（JMLプロセス）に合わせた責任分解の雛形です。
1. 入社時（Joiner プロセス）
2. 異動・昇進時（Mover プロセス）
3. 退職時（Leaver プロセス）
よくある落とし穴（導入・運用の失敗パターン）と監査目線
SSO/SCIMを導入する過程で、多くの企業が以下の罠に直面します。
- 「SSOを導入したのに」共有アカウントが残る
ライセンス料を節約するために代表アドレスでSSO連携し複数人で使い回すケースです。監査の観点では完全にアウトであり、コスト削減ではなくセキュリティの放棄です。 - グループ設計がぐちゃぐちゃでSCIMが破綻する
場当たり的にIdPのグループを作りすぎると誰の権限か分からなくなります。組織図ベースの「所属グループ」と特定のSaaSを使える「アプリケーション許可グループ」は明確に分けて設計してください。 - 例外アカウント（外部委託・派遣）の扱いが曖昧
社員の退職フローは整っていても、業務委託メンバーの契約終了時にアカウントが消し忘れられるケースが多発します。委託用アカウントには必ず「有効期限設定」を行い、定期的な棚卸しプロセスを回す必要があります。
| 監査要求（コントロール） | IdP(SSO/SCIM)連携で提示できる証拠（証跡） |
|---|---|
| 退職者のアカウントは確実に停止されているか？ | IdPの退職者ブロックログとSCIMのプロビジョニング停止ログ（1箇所） |
| 最小権限の付与基準が守られているか？ | IdPのグループ付与履歴（ワークフロー承認後）とSaaS権限要件の合致 |
| 定期的な棚卸しは実行されているか？ | IdP側の休眠アカウント抽出レポート（過去90日アクセスなし）と対処ログ |
重要ポイント
よくある質問
Q. とりあえず全てのSaaSをSSO連携すべきですか？
原則は「Yes」ですが、SaaS側の仕様によりSSOを設定すると既存のローカルパスワードが無効になり、一時的に現場が混乱する場合があります。小規模な部門ごとのSaaSから段階的に連携（フェーズ分け）するのが確実です。
Q. 「オーナーが不在のSaaS」を見つけたらどうすればいいですか？
直ちにアクセスログを確認し、利用中の社員がいれば新しいオーナー（主管理者）に任命します。誰も利用していない場合は当該SaaSへのネットワークアクセスをブロックし、解約手続き（カード停止など）を進めます。
DX推進やIT戦略でお悩みですか？
現状分析から戦略立案、実行まで、専門家が伴走型で支援します。