SSOを導入すれば認証管理の問題はほぼ解決できる——そう考えている情シス担当者は多いはずです。しかし実際のところ、SSOを正しく運用している組織でも、認証絡みのインシデントは後を絶ちません。

SSOは確かに強力な仕組みです。ただ、それ単体では防げない攻撃手法が存在します。SSO対応外のSaaSや個人アカウントが発生する実際の運用環境では、管理の「穴」が生まれ続けるのです。

この記事では、SSOが持つ構造的な限界を整理したうえで、情シスが取るべき補完策と、SaaS管理プラットフォームとの組み合わせ方について解説します。

SSOとは何か、何を解決するのか

SSOのセキュリティ上の限界を理解するには、まずSSOが何を目的として設計されたかを整理しておく必要があります。SSOを「セキュリティツール」と誤解していると、その限界に気づけないからです。

SSOの本来の目的

SSO（Single Sign-On）は、1度の認証で複数のSaaSやWebアプリにアクセスできる仕組みです。IdP（Identity Provider）が認証を担い、SAML 2.0やOpenID Connect（OIDC）といった標準プロトコルで各サービス（SP: Service Provider）にトークンを渡します。

ユーザーは各サービスのID・パスワードを個別に管理しなくて済み、情シスはアカウント発行・停止を一元管理できます。SSOが解決するのは「ID管理の分散」と「認証の煩雑さ」です。本質は利便性の向上と運用効率化にあります。

SSOはセキュリティ向上ではなく「管理の集約」

ここが出発点として重要です。SSOの役割は「認証を1か所に集約すること」であり、「あらゆる不正アクセスを防ぐこと」ではありません。むしろ、1か所に集約したことで攻撃者の標的も一点に集中するという側面があります。

SaaSが50種類を超える組織では、アカウント管理の分散を防ぐ意味でSSOの価値は非常に大きいです。ただし、SSOを導入したことと、セキュリティが十分なこととは別の話です。

関連記事：SSO（シングルサインオン）とは？仕組み・メリット・導入方法を情シス向けに徹底解説

SSOだけでは防げない5つのセキュリティリスク

SSOの設計上の限界を、攻撃の観点と運用の観点から整理します。

1. AiTM攻撃によるセッションハイジャック

SSOと組み合わせてMFAを設定していても、AiTM（Adversary-in-the-Middle）攻撃で突破されるケースが増えています。

AiTM攻撃は、正規サービスとユーザーの間にプロキシサーバを挟む手法です。攻撃者はフィッシングサイトを経由して認証情報とセッションクッキーの両方を窃取し、MFAコードを入力した後のセッションをそのまま乗っ取ります。つまり、MFAが有効でもセッションを盗まれると不正アクセスは成立してしまいます。

2025年には国内の証券口座で同様の手口による被害が多発しました。SSOによってログイン認証が一元化されていると、IdPのセッションを盗まれた時点で連携済みの全SaaSへのアクセスが奪われるリスクがあります。

参考：多要素認証を突破する「AiTM攻撃」とは？その対策は？ | トレンドマイクロ

2. クレデンシャルスタッフィングとパスワード攻撃

IdPへの認証に使うメールアドレスとパスワードの組み合わせが他サービスで流出していた場合、そのまま不正ログインされるリスクがあります。これがクレデンシャルスタッフィングです。

SSOはパスワード管理を集約しますが、IdPに設定するパスワードが脆弱だったり、他サービスと使い回したりしていれば意味がありません。また、ユーザーがパスワードを忘れた際の「リセットフロー」に脆弱性がある場合も同様です。

MFAを適切に設定していればリスクは大幅に下がります。ただし、MFAが設定されていないアカウントが1つでも残っていれば、そこが侵入口になります。

3. SSO非対応のSaaSによる「管理の穴」

SSOで管理できるのは、IdPと連携設定を行ったSaaSだけです。SAML 2.0やOIDCに対応していないSaaS、部門が独自に契約したSaaS、個人のクレジットカードで払っているフリーミアムSaaSは、SSO管理の外側に存在します。

ガートナーの調査では、企業のSaaS利用のうち約30〜40%はIT部門が把握していないとされています。SSO管理下のSaaSが完璧に管理されていても、管理外のSaaSが残り続けるとシャドーIT問題は解消されません。

特に問題になるのが退職者の取り扱いです。SSO連携済みのSaaSはIdPアカウントを無効化すれば一括でアクセスを止められます。しかし、SSO非対応のSaaSには個別に対応する必要があり、対応漏れが生じると退職後も個人アカウントが残り続けます。

4. 過剰なアクセス権の放置

SSOはアカウントの「認証」を管理しますが、「誰がどのSaaSのどの機能にアクセスできるか」という認可（権限）の管理は別の話です。

入社時に付与したSaaSの管理者権限が異動・昇格・降格後もそのまま残り続けるケースは、SSOを導入した組織でも頻繁に起きています。IdPを無効化すればログインはできなくなります。ただし、SSO非対応のSaaSや個人アカウントには権限が残り続けます。

最小権限の原則を徹底するには、SSOだけでなく、SaaS全体の権限状態を定期的にレビューする仕組みが必要です。

5. IdPそのものへの攻撃と可用性リスク

SSOのアーキテクチャでは、IdPが単一障害点（SPOF: Single Point of Failure）になります。IdPが障害を起こすと、連携済みの全SaaSへのアクセスが同時に失われます。

IdPの設定ミスやSAMLの実装不備を突いた攻撃も存在します。OktaやMicrosoft Entra IDといった大手IdPでも、過去に設定上の問題が原因でインシデントが発生したことがあります。IdPを「信頼して任せればよい」と設定を放置するのは危険です。

参考：SSO（シングルサインオン）とは？仕組みやメリット・デメリットを解説 | LAC WATCH

情シスが「SSOを過信してしまう」3つの理由

現場でよく見られる誤解を整理します。SSOの限界を正しく認識するために、なぜ過信が起きるかを知っておくことは重要です。

理由1: 「導入した=対策済み」という認知バイアス

SSOを導入したという事実が、セキュリティ対策が完了したという誤った安心感を生みやすいです。実際にはSSOはセキュリティ強化ツールというより、ID管理を集約するプラットフォームです。MFAとの組み合わせ・権限管理のルール整備・SSO非対応SaaSへの対応が揃って初めて、セキュリティの底上げにつながります。

理由2: MFA設定の不徹底

SSOとMFAを組み合わせる場合、「全アカウントにMFAを強制する」設定が必要です。ところが、外部パートナー・派遣社員・エグゼクティブ向けに例外設定を作ると、そこが穴になります。

2025年に発生した国内の大規模インシデントでは、業務委託先のアカウントにMFAが適用されていなかったことが原因の一つとされています。例外なく全員に適用する設定と、それを継続してモニタリングする運用が不可欠です。

理由3: SSOが届かない範囲の存在を知らない

IdPのダッシュボードに表示される連携済みSaaSだけを見て、全体を把握していると思い込むケースがあります。実際には部門が独自契約しているSaaSや、従業員が個人アカウントで利用しているSaaSは可視化されていません。

Assuredが2024年に発表した調査では、大手企業（従業員1,000名以上）の65.6%がシャドーIT対策を行えていないと回答しています。

参考：2024年最新シャドーIT対策実態調査レポート | Assured

SSOの限界を補う4つのアプローチ

SSOの限界を踏まえたうえで、どう補完するかを整理します。

アプローチ1: フィッシング耐性のある認証方式への移行

AiTM攻撃に対して最も有効なのは、TOTPやSMSといった「フィッシングで盗める」MFAではなく、FIDOベースのパスキーやハードウェアセキュリティキー（YubiKeyなど）への移行です。

これらはサーバとデバイスが証明書を交換する仕組みのため、フィッシングサイトを経由しても攻撃者がコードを取得できません。金融庁は2025年10月の改正で、証券会社に対して「フィッシング耐性のあるMFA」の実装を要求するようになりました。一般企業においても、段階的にFIDOベースの認証へ移行することが推奨されます。

参考：フィッシング耐性のある認証とは？クライアント証明書認証（mTLS）がAiTM攻撃に強い理由 | GMOグローバルサインカレッジ

アプローチ2: SSO対象外のSaaSを可視化する

SSO管理外のSaaSを発見するには、社内で利用されているすべてのSaaSを定期的にスキャンする仕組みが必要です。クレジットカード明細・経費精算データ・ブラウザ拡張機能・ネットワークログなどを横断的に分析して、IT部門が把握していないSaaSを洗い出します。

IdPのダッシュボードだけを見ていても、この可視化は実現しません。SaaS管理プラットフォームとの組み合わせが現実的なアプローチです。

アプローチ3: アクセス権限の定期レビュー

最小権限の原則を維持するには、SaaS全体の権限状態を定期的に棚卸しするプロセスが必要です。半年に1度、全SaaSの管理者・権限変更ログをレビューし、不要な権限を剥奪する運用を継続します。

この作業をすべて手動で行うのは現実的ではありません。SaaS全体の権限を一覧化し、レビューフローを自動化できる仕組みへの投資が、中長期的なコスト削減につながります。

アプローチ4: 退職者・異動者のオフボーディング自動化

退職者が出た際、SSO連携済みのSaaSはIdPアカウントを無効化すれば止まります。しかしSSO非対応のSaaSは手動対応が必要です。この手動対応に抜け漏れが生じると、退職者アカウントが残り続けます。

人事システムと連携して、退職・異動の情報を受け取った時点でSSO外のSaaSを含めた全アカウントを自動停止する仕組みを構築することが理想です。

関連記事：退職者アカウント削除の方法と自動化のポイントを解説

ジョーシスの資料では、SaaS管理の課題をどのように整理しているかを詳しく解説しています。

ジョーシスの資料をダウンロードする（5分でわかるジョーシス）

SaaS管理プラットフォームがSSOを補完する理由

ここまでの補完策をすべて手動・個別ツールで対応しようとすると、情シスの工数が膨大になります。複数のツールを組み合わせて運用している組織では「SaaSが増えるほど管理コストが増える」という負のスパイラルに陥りがちです。

SSOとSaaS管理プラットフォームの役割分担

SSOとSaaS管理プラットフォームは競合するものではなく、役割が異なります。以下に整理します。

SSOは「認証の質を高める」役割に特化し、SaaS管理プラットフォームが「管理の網羅性」を担う。この組み合わせで、互いの弱点を補えます。

ジョーシスがSSOと組み合わせられる理由

ジョーシスは350以上のSaaS（2026年5月時点）と連携し、シャドーIT検出・アカウント発行停止・ライセンス棚卸し・アクセス権レビューを一元的に管理するプラットフォームです。

既存のIdP（Okta、Microsoft Entra ID、Google Workspace など）とSCIM連携することで、IdPが管理できる範囲と、IdPが届かないSSO非対応SaaSの両方をカバーします。オンボーディング・オフボーディングのフローも人事システムと連携して自動化でき、退職者アカウントの放置リスクを排除できます。

Sales Marker社の事例では、ジョーシスの導入によってIT工数を約50%削減しています。Anker Japan社ではITコストを最大75%削減したケースもあります（効果は個社の状況により異なります）。

参考：Josys | ITデバイスとSaaSの統合管理 - NRIセキュア

関連記事：SaaS管理ツールとは？情シスが導入前に知るべき選び方と比較ポイント

IdP選定とSSO設定時のセキュリティチェックリスト

SSOを新規導入する場合、またはリプレイスを検討する場合に確認すべきポイントを整理します。

IdP選定時の確認事項

SSOの安全性はIdPの機能と設定に大きく依存します。選定基準に以下の点を含めてください。

• MFA強制機能があり、例外なく全ユーザーへの適用ができるか
• FIDO2・パスキー・ハードウェアキーに対応しているか
• 条件付きアクセス（デバイス状態・場所・リスクスコアに基づくアクセス制御）が設定できるか
• セッションタイムアウト・強制ログアウト機能があるか
• SCIM対応でプロビジョニングの自動化が可能か
• 監査ログが詳細に取得でき、SIEM連携できるか
• SLAと障害時のフォールバック設定が明確か

SSO設定後の継続的な確認事項

SSOを導入したら設定を放置するのではなく、以下の項目を定期的に確認します。

• 全ユーザーにMFAが強制されているか（例外アカウントがないか）
• 長期間ログインのないアカウントが放置されていないか
• 連携SaaSのリストが最新の状態に保たれているか
• 条件付きアクセスのポリシーが最新の脅威トレンドに対応しているか
• IdPの管理者アカウントに最小権限が適用されているか

これらを手動でチェックするのは限界があります。SaaS管理プラットフォームと組み合わせることで、アカウント状態の自動モニタリングと異常検知が実現します。

ゼロトラスト文脈でのSSOの位置づけ

IPA「情報セキュリティ10大脅威 2026」では、ランサムウェアに次いで「AIの利用をめぐるサイバーリスク」が初めて3位にランクインしました。AIを悪用した高度なフィッシングやソーシャルエンジニアリングが増加するなか、認証の強度がより重要になっています。

参考：情報セキュリティ10大脅威 2026 | IPA

ゼロトラストはSSOの上位概念ではない

ゼロトラストは「すべてのアクセスを検証する」という設計思想であり、SSOはその手段の一つです。ゼロトラストを実現するには、SSOによる認証の一元化だけでなく、デバイスの信頼性評価（MDM連携）・ネットワークセキュリティ（ZTNA）・アプリケーションのアクセス制御が組み合わさる必要があります。

SSOを軸にしながら、SIEM・MDM・SaaS管理プラットフォームを段階的に組み合わせていく構成が、実務的なゼロトラスト実装の姿です。

「最小権限」の実現にはSSOだけでは足りない

ゼロトラストの中核原則である最小権限（Least Privilege Access）は、SSOが管理できる認証レベルだけでは実現できません。各SaaSの内部権限（管理者か一般ユーザーか、閲覧のみか書き込み可か）を把握し、定期的に見直す仕組みが必要です。

人員が多い組織では、過去に付与した権限が累積して「権限過多」の状態になりがちです。SaaS管理プラットフォームのアクセスレビュー機能を使って、定期的な棚卸しを自動化することが現実的な解決策です。

関連記事：アクセス権限管理とは？情シスが押さえるべき原則と実務手順

SSOの限界を補完し、SSO非対応SaaSも含めて一元管理する方法について、ジョーシスのデモで詳しくご確認いただけます。

デモを予約する（無料）

まとめ：SSOはセキュリティの出発点であり、終着点ではない

SSOはID管理の分散を解消し、認証を一元化する優れた仕組みです。ただ、それはセキュリティ対策の出発点であって、終着点ではありません。

この記事で取り上げたSSOの限界を改めて整理します。

• AiTM攻撃はMFAが有効でもセッションを奪える
• SSO非対応のSaaSや個人アカウントは管理の圏外にある
• 過剰なアクセス権の放置はSSOで解決できない
• 退職者対応はSSO連携外のSaaSには届かない
• IdPの設定ミスや障害が全体に波及するリスクがある

これらの限界を認識したうえで、SSOにMFA強化・SaaS可視化・権限レビュー・オフボーディング自動化を組み合わせることが、現実的なセキュリティ強化の道筋です。

SaaSの種類が増えるほど管理の複雑さは増します。ジョーシスのようなSaaS管理プラットフォームを活用することで、SSOが届かない領域をカバーしながら、情シスの工数を増やさずにセキュリティの網羅性を高められます。

ジョーシスがSSOの補完としてどう機能するかを、資料でまとめています。

ジョーシスの資料をダウンロードする（5分でわかるジョーシス）

よくある質問（FAQ）

SSOを導入すればMFAは必要ありませんか？

SSOとMFAは別の仕組みです。SSOは「どのサービスに1度の認証でアクセスできるか」を管理し、MFAは「認証そのものの強度を高める」役割を担います。SSOのみでMFAを設定しない場合、パスワード1つが漏れると連携済みのすべてのSaaSへの不正アクセスが成立するため、MFAの適用は必須です。

SSOに対応していないSaaSはどう管理すればよいですか？

SAML 2.0やOIDCに非対応のSaaSについては、SaaS管理プラットフォームを使って個別にアカウント状態を管理するアプローチが有効です。人事システムと連携してオフボーディングを自動化することで、SSO対象外のSaaSでも退職者アカウントの削除漏れを防ぐことができます。

退職者のSaaSアカウント削除でよくある失敗は何ですか？

最も多いのは「IdPを無効化すれば完了」と思い込んで、SSO連携していないSaaSへの対応を漏らすケースです。個人クレジットカードで契約されているSaaSや、部門が独自に導入したSaaSはIdP管理の外側にあります。全SaaSのリストと担当者を把握し、退職時の棚卸しフローに含めることが重要です。

ゼロトラストの実現にSSOだけで足りますか？

SSOはゼロトラスト実現の重要な要素ですが、それだけでは不十分です。ゼロトラストは認証（SSO・MFA）だけでなく、デバイス信頼性（MDM）・ネットワーク制御（ZTNA）・アプリ内権限の最小化を組み合わせて初めて成立します。SSOを軸にしながら、段階的に各レイヤーを強化していく進め方が現実的です。