SSO

SSO（Single Sign-On：シングルサインオン）とは、ユーザーが一度の認証で複数のアプリケーションやサービスにアクセスできるようにする認証方式です。ユーザーはIdP（IDプロバイダー）で一度ログインすれば、連携する各サービスに個別にパスワードを入力することなくシームレスにアクセスできます。SSOにより、パスワード管理の負担軽減、利便性の向上、そしてパスワード関連のセキュリティリスクの低減が同時に実現されます。

SSOの実現にはSAML 2.0やOpenID Connect（OIDC）などの標準プロトコルが使用されます。SAMLはエンタープライズ環境で広く採用されており、XMLベースのアサーションによって認証情報を安全にやり取りします。OIDCはOAuth 2.0の上に構築されたモダンなプロトコルであり、REST API/JSONベースの軽量な設計からWebアプリケーションやモバイルアプリケーションで急速に普及しています。

SSOは利便性とセキュリティの双方を向上させる一方で、SSOの認証情報が漏洩した場合には連携するすべてのサービスが危険にさらされるという集中リスクを伴います。このため、SSOの導入にあたっては多要素認証（MFA）の併用、セッション管理の厳格化、異常検知の強化が不可欠です。SSOはセキュリティの「強さの鎖」であると同時に「弱さの鎖」にもなり得る、設計と運用が極めて重要な技術です。

SAMLベースSSO

SAML（Security Assertion Markup Language）2.0は、エンタープライズ環境で最も広く使用されるSSO標準です。SAML SSOでは、IdPがユーザーを認証した後、SAMLアサーション（XML形式の認証証明書）を生成し、ブラウザを介してSP（サービスプロバイダー）に送信します。SPはアサーションのデジタル署名を検証し、ユーザーのアクセスを許可します。

SAML SSOにはSP-Initiated SSO（ユーザーがSPにアクセスしてIdPにリダイレクトされる方式）とIdP-Initiated SSO（ユーザーがIdPポータルからSPを選択する方式）の2種類があります。SP-Initiated SSOがセキュリティ上推奨されますが、IdP-Initiated SSOは利便性が高く、企業ポータルとの統合に適しています。

OIDCベースSSO

OIDC（OpenID Connect）は、OAuth 2.0を基盤とした認証プロトコルであり、モダンなSSO実装の標準として急速に普及しています。OIDCでは、認可コードフローを通じてIdP（OIDCではOPと呼ばれる）からIDトークン（JWT形式）とアクセストークンを取得し、IDトークンに含まれるユーザー情報に基づいてSSOを実現します。

OIDCの利点は、JSONベースの軽量な設計、モバイルアプリやSPAとの高い親和性、PKCE（Proof Key for Code Exchange）による認可コードインターセプト攻撃の防止、そしてUserInfoエンドポイントによる柔軟なユーザー情報の取得です。SAMLと比較して実装が容易であり、新規のSSO統合ではOIDCが第一選択となるケースが増えています。

デスクトップSSO

デスクトップSSOは、ユーザーがPCにログインした時点でWindowsドメイン認証（Kerberos）を通じて認証され、その認証情報を利用してWebアプリケーションやサービスにシームレスにアクセスできる方式です。Active Directory環境では、統合Windows認証（IWA）を使用したデスクトップSSOが広く利用されています。

デスクトップSSOは、ユーザーがパスワードを一切入力することなくアプリケーションにアクセスできるため、最高の利便性を提供します。ただし、Active DirectoryとIdPの連携設定が複雑であり、社外からのアクセスではKerberosが使用できないため、フォールバック認証の設計が必要です。また、端末の物理的なセキュリティ（画面ロック、BitLockerなど）が不十分な場合、SSOの恩恵が不正アクセスの温床となるリスクがあります。

SSOのセキュリティリスク

SSOは利便性とセキュリティの向上に貢献しますが、固有のセキュリティリスクも伴います。最大のリスクは単一障害点（Single Point of Failure）です。SSOの認証情報が漏洩すると、連携するすべてのサービスに不正アクセスされる可能性があります。また、IdP自体がダウンした場合、すべてのサービスにログインできなくなるという可用性リスクもあります。

その他のリスクとして、セッションハイジャック（IdPセッショントークンの窃取による横断的なアクセス）、セッション固定攻撃、リプレイ攻撃（傍受したSAMLアサーションの再利用）、トークン窃取（OIDCトークンの漏洩によるなりすまし）が挙げられます。これらのリスクに対しては、MFAの強制、セッションタイムアウトの適切な設定、トークンの有効期限の短縮、異常なアクセスパターンの検知が有効です。

SSO実装パターン

SSOの実装には複数のパターンがあります。リバースプロキシ型は、SSOゲートウェイがすべてのリクエストを仲介し、認証済みユーザーのリクエストのみをバックエンドサービスに転送する方式です。エージェント型は、各Webサーバーにエージェントを導入し、エージェントがIdPと連携して認証を行う方式です。

フェデレーション型は、SAML/OIDCなどの標準プロトコルを使用してIdPとSPが直接連携する方式であり、クラウドサービスとのSSO統合で最も一般的です。また、パスワードボールティング型は、SSOプラットフォームがユーザーの各サービスのパスワードを暗号化して保管し、自動入力する方式です。レガシーアプリケーションとのSSO統合に使用されますが、パスワードの集中管理に伴うリスクがあります。

SSOとゼロトラストの統合

現代のSSO実装では、ゼロトラストの原則との統合が重要です。従来のSSOは「一度認証すればすべてにアクセス可能」という考え方でしたが、ゼロトラスト時代のSSOでは継続的な認証とコンテキストベースのアクセス制御が求められます。

具体的には、デバイスのセキュリティ状態（OSのパッチレベル、EDRの稼働状態）、ユーザーの行動パターン（通常と異なる時間帯やロケーションからのアクセス）、アクセス先のリソースの機密レベルに応じて、リアルタイムにアクセス可否を判断し、必要に応じて追加の認証（ステップアップ認証）を要求する仕組みが必要です。

• 01
  多要素認証（MFA）の必須化：SSOの認証情報は全サービスへのアクセスキーとなるため、パスワードのみの認証は絶対に避けてください。FIDO2対応のハードウェアセキュリティキーやAuthenticatorアプリによるMFAを全ユーザーに必須化し、SMSベースのMFAはSIMスワップ攻撃のリスクがあるため極力避けましょう。
• 02
  セッション管理の厳格化：SSOセッションの有効期限を適切に設定し、アイドルタイムアウト（操作がない場合のセッション切断）と絶対タイムアウト（最長セッション時間）の両方を実装してください。機密性の高いアプリケーションへのアクセス時にはステップアップ認証を要求し、一度の認証ですべてに無制限にアクセスできる状態を避けましょう。
• 03
  SSOトークンの保護と検証：SAMLアサーションの署名検証を厳格に行い、アサーションの有効期限（NotBefore/NotOnOrAfter）、宛先（Destination）、対象者（Audience）の検証を省略しないでください。OIDCでは、IDトークンの署名検証、issクレームとaudクレームの検証、nonceの一致確認を必ず実施し、トークンリプレイ攻撃を防止しましょう。
• 04
  異常なSSOアクティビティの監視と検知：通常と異なるIPアドレスや地域からのSSOログイン、短時間での大量のサービスアクセス、通常利用しないサービスへの初回アクセスなどの異常なパターンを検知する仕組みを構築してください。UEBA（User and Entity Behavior Analytics）を活用し、不正アクセスの兆候をリアルタイムで検知・対応しましょう。
• 05
  SSOのシングルログアウト（SLO）の実装：ユーザーがIdPからログアウトした際に、連携するすべてのSPからも確実にログアウトされるシングルログアウト（SLO）を実装してください。SLOが不完全な場合、IdPからログアウトしてもSP側のセッションが残存し、不正アクセスのリスクが生じます。
• 06
  SSO障害時のフォールバック計画：IdP障害によるSSO停止時の事業継続計画を策定してください。緊急用のローカル管理者アカウント（Break Glass Account）を各サービスに用意し、定期的にアクセス可能であることを確認しましょう。ローカルアカウントは厳格に管理し、使用時には必ず監査ログに記録される仕組みを整えてください。