シングルサインオン（SSO）とは概要や必要性を解説|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2025年12月09日更新日時: 2026年05月29日

クラウドサービスや SaaS の利用が前提となった今、企業にとって「ユーザー ID の管理」は情報システム・情報セキュリティの重要テーマの一つになりました。
メール、グループウェア、社内ポータル、経費精算、CRM、開発プラットフォームなど、1人の従業員が日常的に使うサービスは、10個を超えることも珍しくありません。そのたびに別々のログイン ID とパスワードを管理しなければならず、ユーザーも運用側も疲弊しがちです。

この状況を少しでも整理するために、多くの企業が導入しているのがシングルサインオン（Single Sign-On：SSO）です。
一方で、SSO は便利な仕組みであると同時に、うまく設計・運用しなければ「認証の単一障害点（Single Point of Failure）」にもなり得ます。万が一ここを突破されると、被害が一気に広がる可能性があります。

この記事では、企業の情報システム部門・情報セキュリティ担当者向けに、SSO の基本的な考え方から、代表的な方式、海外・国内のインシデント事例を踏まえたリスクと対策までを整理していきます。

1 シングルサインオン（SSO）とは
2 なぜ SSO が必要とされるのか
3 代表的な SSO 技術・方式
4 SSO／ID 基盤に関係する主な被害事例と教訓
5 SSO を「利便性の機能」から「セキュリティ戦略の中核」へ

シングルサインオン（SSO）とは

シングルサインオンとは、「ユーザーが一度認証を行うだけで、複数のシステムやクラウドサービスにアクセスできるようにする仕組み」です。

通常であれば、ユーザーは会社 PC にログインし、メール、グループウェア、社内ポータル、各種クラウドサービスごとに ID・パスワードを入力してログインする必要があります。
SSO を導入すると、最初に一度だけ認証を済ませれば、その後は対象となるサービスに追加のログイン操作なしでアクセスできるようになります。

ここでは、関係する役割を簡単に整理します。

IdP（Identity Provider）
Active Directory や Azure AD / Entra ID などのディレクトリを基盤として、ユーザーの本人確認を行う「認証の親玉」です。ユーザーは、まず IdP に対してログインします。
SP（Service Provider）／Relying Party
メール、グループウェア、SaaS など、実際に業務で利用するサービス側です。SP は、IdP が発行した「トークン」や「アサーション」を検証し、その結果をもとにユーザーをログイン済みとして扱います。
トークン／アサーション
「誰が」「いつ認証されたか」「どのような属性（部署やロール）を持っているか」といった情報が含まれた署名付きデータです。SAML アサーションや OpenID Connect の ID トークンが代表的な例です。

ユーザーから見ると、「最初に Office 365 や社内ポータルにログインしておけば、その後 Salesforce や Box にも自動的に入れる」といった体験になります。
運用側から見ると、「認証の処理を IdP に集約し、各サービス側では主に権限（ロール）の管理に集中できる」ことが大きなメリットです。

なぜ SSO が必要とされるのか

パスワード疲れとフィッシングリスクの増大

SaaS が増えれば増えるほど、ユーザーが覚えなければならないパスワードの数も増えます。
その結果として、現場では次のような行動が起こりがちです。

複数サービスで同じパスワードを使い回す
推測されやすい、覚えやすさ重視の弱いパスワードを使う
メモやブラウザに安易に保存してしまう

攻撃者はこうした傾向をよく理解しており、フィッシングやパスワードスプレー攻撃によって、どこか一つのサービスから認証情報を盗み取れば、同じパスワードを使っている他のサービスへ次々にアクセスを試みます。

SSO を導入し、「企業がコントロールできる強力な認証ポイント」を一箇所にまとめることで、
バラバラに散らばったパスワード管理を抑え込み、多要素認証（MFA）や FIDO2、端末認証など、フィッシングに強い認証方式を横断的に適用しやすくなります。

ゼロトラストと「ID 中心」のセキュリティ

ゼロトラスト・アーキテクチャでは、「社内ネットワークだから信頼する」という考え方ではなく、「ID とコンテキスト」をもとに都度信頼を判断します。
ユーザーがどこからアクセスしてきても、

そのユーザーは誰か（ID）
どの端末からアクセスしているか（デバイスの状態）
どのような挙動をしているか（行動のパターン）

といった情報を組み合わせて検証します。

このとき、SSO／IdP はゼロトラストを実現するうえでの「入り口」として非常に重要な位置付けになります。
IdP 側で条件付きアクセス（IP 制限、端末のコンプライアンスチェック、リスクベース認証など）を設定しておくことで、個々の SaaS にそうした機能が備わっていなくても、一定レベルの統一されたポリシーを適用できるようになります。

アカウント・ライフサイクル管理の効率化

人の出入りが多い組織では、アカウントのライフサイクル管理も大きな課題です。
各 SaaS に個別にアカウントを持たせていると、次のような問題が起こりやすくなります。

入社時に、担当者が多くのサービスに手作業でアカウントを作成する
部署異動のたびに権限変更が追いつかない
退職後も一部のアカウントが残ってしまう

SSO と ID プロビジョニング（例：SCIM）を組み合わせると、ディレクトリや人事システムの情報を起点に、アカウントの作成・権限変更・削除を自動化しやすくなります。
これにより、退職者アカウントが残り続けるといったリスクも減らせます。実際のランサムウェア被害の中には、「利用されていないアカウントが侵入の足がかりになった」と報告されているケースもあります。

監査・コンプライアンス対応のしやすさ

ISMS（ISO 27001）や SOC 2、各国の個人情報保護法などに対応するうえでも、

誰が、いつ、どのシステムにアクセスしたのかを説明できること
権限をどのようなルールで付与・剥奪しているのかが明確であること

は重要なポイントです。

SSO を導入している場合、IdP 側のログが「認証に関する一元的な記録」となります。
個別サービス側のログと組み合わせることで、監査対応やインシデント調査をスムーズに進めやすくなります。

代表的な SSO 技術・方式

SAML（Security Assertion Markup Language）

SAML は、企業向けの Web SSO で長く使われてきた標準プロトコルです。
XML 形式の「SAML アサーション」と呼ばれる署名付きデータを、IdP が発行し、SP が検証することで認証を行います。

部署や役職、ロールなどの属性情報（属性情報）を細かく連携できる点が強みで、Salesforce や Box など多くのエンタープライズ向け SaaS で採用されています。

OAuth 2.0 / OpenID Connect（OIDC）

OAuth 2.0 / OpenID Connect は、より新しい世代の方式で、モダンな Web アプリやモバイルアプリと相性が良い仕組みです。

本来 OAuth 2.0 は「認可」の仕組みですが、それを拡張して「認証」にも対応させたのが OpenID Connect（OIDC）です。
IdP は JWT 形式の ID トークンを発行し、SP はその署名や中身のクレーム情報を検証してユーザーを認証します。

API 連携が前提となるシステム構成や、モバイルアプリが絡む環境では、SAML よりも OIDC を選ぶケースが増えています。

Kerberos による Windows 統合認証

Kerberos による統合認証は、オンプレミスの Windows ドメイン環境で長年使われてきた方式です。
ユーザーが Windows にログオンするときに Kerberos チケットが発行され、社内のファイルサーバや社内 Web アプリなどに対して、追加のログインなしでアクセスできるようになります。

クラウド移行が進んでいるとはいえ、オンプレミスのシステムが残る企業も多く、Kerberos 環境とクラウド IdP（例：Azure AD / Entra ID）をどう連携させるかは、実務的な検討ポイントになります。

ソーシャルログイン型の SSO

Google アカウントや Apple ID、LINE などを使った「外部 ID でのログイン」も、技術的には OIDC をベースにした SSO の一種です。
企業内部システムでの利用は多くありませんが、BtoC のサービスで外部 ID と連携する場合には、SSO と同様に設計やリスク評価が必要になります。

SSO／ID 基盤に関係する主な被害事例と教訓

Okta：IdP ベンダーが狙われたときの影響

世界的に利用されている SSO／IDaaS ベンダーの Okta は、2023 年のサポートシステム侵害など、複数のセキュリティインシデントを経験しています。

公開されている情報によると、おおまかな流れは次の通りです。

サポート用のシステムに不正アクセスが発生
顧客企業が提出した HAR ファイル（トラブルシュート用の HTTP ログ）に含まれるセッショントークンが悪用された
一部の顧客環境で、セッション乗っ取りを試みる攻撃が確認された

ここから見えてくるのは、次のようなポイントです。

IdP／SSO ベンダーは、攻撃者にとって「多くの鍵を握る存在」であり、非常に狙われやすい
ベンダー側のサポートプロセス（ログの扱い方やマスキングの有無）も攻撃経路になり得る
利用企業側でも、IdP 連携アプリのセッション管理やログ監視を行わなければ、「すべてをベンダー任せ」にしてしまうことになる

技術的な脆弱性だけでなく、「人とプロセス」が弱点になることも忘れてはいけません。
いくら強固な SSO や MFA を導入しても、ヘルプデスクの本人確認プロセスが甘ければ、そこを突いて認証を迂回される可能性があります。

LastPass：パスワード管理基盤が侵害されたケース

パスワードマネージャーの LastPass は、2022〜2023 年にかけて大規模な情報漏えいを経験しました。
調査報告などによれば、開発者アカウントやバックアップストレージが侵害され、多数のユーザーデータが流出したとされています。

パスワードマネージャーは SSO とは別の技術ですが、

多数のサービスの認証情報を一元管理している
ここが侵害されると、ユーザー側の多くのシステムが一気にリスクを抱える

という点では、「単一の鍵束」を扱うという意味で SSO とよく似ています。

このインシデントを受けて、海外では次のような点がベストプラクティスとして挙げられています。

メールや IdP、金融系など「最重要システム」の認証情報を優先的にローテーションする
IdP／SSO の管理者アカウントや管理コンソールへのアクセスは、一般ユーザーアカウントと完全に分けて管理する

さらに 2025 年には、LastPass ユーザーを狙ったフィッシングキャンペーンとして、「あなたの死亡証明書が提出され、アカウント継承の手続きが進んでいる」といった内容の偽メールを送り、偽サイトへ誘導してマスターパスワードを盗もうとする手口も報告されています。
SSO やパスワードマネージャーのように「鍵」を扱うサービスは、技術的な攻撃だけでなく、社会工学的な攻撃にも執拗に狙われることが分かります。

日本企業の事例：認証情報の窃取とアカウント乗っ取り

日本企業でも、ランサムウェアやサプライチェーン攻撃の裏で、認証情報の窃取やクラウドサービスのアカウント乗っ取りが入り口になっているケースが増えています。

多くの企業で、Slack や Microsoft Teams などのコラボレーションツールの認証に SSO が利用されていますが、SSO セッションやリフレッシュトークンが盗まれた場合、影響は広範囲に及ぶ可能性があります。
業務用アカウントを私物 PC から利用することや、ブラウザの自動保存に頼ることが、SSO 時代の新たなリスクになり得ます。

2025 年 10 月に発生した ASKUL（アスクル）のランサムウェア攻撃では、物流や EC システムが停止し、その後の調査で顧客情報の漏えいも確認されています。この攻撃の影響は取引先にも波及し、無印良品（良品計画）の EC サイトも停止しました。
公開情報だけでは SSO の直接的な関与は分かりませんが、日本の大手小売・物流企業の多くが、基幹システムとクラウドサービスをつなぐ認証基盤として SSO を使っている現状を考えると、「ID／SSO 基盤が侵害された場合の影響」をあらかじめ洗い出しておく重要性が浮き彫りになります。

アサヒグループホールディングスのランサムウェア攻撃では、最大 190 万件規模の個人情報が影響を受けた可能性があると報じられています。
また、佐川急便では、不正ログインの原因として「漏えいした認証情報を用いた攻撃」が指摘されています。

これらの事案は、SSO 特有の問題とは限りませんが、一度認証情報が漏えいすると、そこを起点に複数システムに攻撃が広がる可能性があるという点で、SSO 環境とも地続きのリスクです。
日本企業では、レガシーシステムとクラウドが入り混じり、部門ごとに異なる認証方式が併存しているケースも多いため、「どこが SSO 配下で、どこがそうでないか」を整理し、影響範囲を評価しておくことが大切です。

SSO を「利便性の機能」から「セキュリティ戦略の中核」へ

シングルサインオンは、もともとユーザーの利便性を高める目的で普及してきた技術です。
しかし、クラウドシフトとゼロトラストの潮流の中で、現在は企業のセキュリティ戦略の中核コンポーネントになりつつあります。

一方で、Okta や LastPass の事例が示すように、「認証基盤そのもの」が標的になり、そこが破られた場合の影響は、従来のシステム単体の被害とは比べものにならない規模に膨らむ可能性があります。

情報システム・情報セキュリティ担当者として、SSO を検討・運用する際に意識しておきたいポイントを、最後に整理します。

SSO は利便性だけの機能ではない
パスワード疲れやフィッシングのリスクを抑え、ゼロトラストを支える「統制ポイント」として設計することが重要です。
IdP／SSO は単一障害点になり得る
管理者アカウントやサポートプロセスも含めたリスク評価が必要です。
MFA の必須化、管理コンソールへのアクセス制限、専用端末からのみ管理する運用などを検討すべきです。
人とプロセスも含めた防御設計が必要
ソーシャルエンジニアリングによる MFA リセットや、サポート窓口の悪用は技術だけでは防げません。
本人確認フローの見直しや、ヘルプデスク向けの教育・訓練が欠かせません。
アカウント・ライフサイクルとログ管理の一体運用
Joiner／Mover／Leaver の自動化と、IdP ログの長期保管・可視化は、監査対応とインシデント対応の双方に効果があります。
日本企業としての現実的なシナリオを想定する
レガシーとクラウドが混在する環境、委託先や海外拠点を含むサプライチェーン、個人 PC 利用など、日本の事情を踏まえ、「どこが破られたらどこまで影響するか」を具体的に想定しておくことが重要です。