シングルサインオン 🚪 - SSOとは？ その仕組みは？

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

シングルサインオン（SSO）を利用すると、利用者は1組のログイン情報で複数のサイトやアプリにアクセスできるようになります。SSOは利用者認証の仕組みに基づいており、どんなプラットフォームや環境、技術を使っていても、1つのアプリにログインすれば、他の関連アプリにもすぐに認証状態が引き継がれます。これにより、複数のユーザー名とパスワードを異なるシステムやサービスで管理する必要がなくなります。

わかりやすい例として、Googleにログインすることで、GmailやYouTubeなど関連サービスにも瞬時に認証情報が反映され、個別にログインする手間が省かれるケースが挙げられます。

‍

SSOトークン

SSOプロセスにおいて、システム間で送信される情報の集まりをSSOトークンといいます。トークンに含まれる情報は、利用者のメールアドレスや、トークンを送信するシステムに関する基本的なデータである場合があります。サービスプロバイダがトークンの出所を信頼できるものと確認するため、トークンには署名が施される必要があります。初期設定の段階で、この署名に使われる認証情報が交換されます。

SSOの重要性

近年、管理すべきシステムやサービスが増加し、従来のユーザー名とパスワードだけでは十分な安全性が確保しにくい状況となっています。しかし、各システムごとに認証情報を管理するのは手間がかかるため、シングルサインオンによって安全なアクセスと管理の簡素化が実現されます。

SSOの実現方法は複数ありますが、基本的な構造は共通です。重要なのは、各アプリが利用者認証を他のシステムやサービスに委譲できるようになっている点です。

SSOプラットフォームは、システム管理者にとって利用者IDを一元管理できる場となります。たとえば、従業員が組織を退職すると、複数の内部プロジェクトへのアクセスが一斉に停止される場合があります。

‍

仕組み

SSOの基盤は、サービスプロバイダ（アプリ）とアイデンティティプロバイダ（OneLoginのような企業）との間で築かれる信頼関係にあります。この信頼関係の根幹として、アイデンティティプロバイダとサービスプロバイダ間で交換される証明書が利用されることが一般的です。サービスプロバイダが送られてくる認証情報の出所が信頼できるものであると確認するため、証明書は認証情報に署名するために使用されます。SSOでは、利用者のメールアドレスやユーザー名などの識別情報を含むトークンによって認証データが表されます。

SSOは、アプリ（サービスプロバイダ）とアイデンティティプロバイダ（OneLoginなど）の間で構築された信頼関係に基づいて動作します。この信頼関係は、両者間で交換される署名により確立され、署名は送信される認証情報に付与されることで、その情報が信頼できるものであることを示します。結果として、利用者のメールアドレスやユーザー名などを含むトークンが作成されます。

一般的なログインの流れは以下の通りです:

• 利用者は、アクセスを希望するアプリまたはサイト（「サービスプロバイダ」）にアクセスします。
• サービスプロバイダは、SSOプラットフォーム（アイデンティティプロバイダとも呼ばれる）に利用者認証を要求するため、利用者のメールアドレスなど一部の情報を含むトークンを送信します。
• まずアイデンティティプロバイダは、利用者が既に認証済みであるかを確認します。
• 利用者が未ログインの場合、アイデンティティプロバイダからの認証情報（ユーザー名とパスワード、またはワンタイムパスワード（OTP）など）の入力が求められます。
• 認証情報が確認されると、アイデンティティプロバイダは認証成功を示すトークンをサービスプロバイダへ返送します。
• サービスプロバイダのアプリは、このトークンを処理します。
• 初期設定の際にサービスプロバイダとアイデンティティプロバイダの間で構築された信頼関係を利用し、受信したトークンの正当性が確認されます。
• サービスプロバイダは利用者にアクセスを許可します。
• もし別のサイトにアクセスする場合も、同様の信頼関係が構築され、認証プロセスが実施されます。

SSO構成の種類

1. SAML

オープンスタンダードであるセキュリティアクセスマークアップ言語（SAML）は、テキストを機械語に変換して利用者情報を交換します。現在、主要なSSOプロトコルのひとつとして、アプリ提供者が認証要求の正当性を確保するのに役立っています。SAML 2.0により、ウェブブラウザ上で情報を転送でき、ウェブアプリでの利用に最適化されています。

2. OAuth

OAuthは、機械語変換を用いてアプリ間でID情報を送信するオープンスタンダードな認可プロトコルです。特にネイティブアプリでは、利用者が各アプリに対して再度認証情報を入力せずに、情報の連携が可能となります。

3. Kerberos

不安定なネットワーク環境下でも、Kerberosプロトコルを用いることで、利用者とサーバが互いに相手の認証を行うことが可能です。メールクライアントやWikiサーバなどのアプリは、チケット発行サービスからのトークンによって認証されます。

4. OIDC

OIDCは、OAuth 2.0を拡張してSSOを実現し、利用者のプロフィール情報を組み込むことができます。これにより、複数のアプリに対して1回のログインでアクセスが可能となります。例えば、FacebookやGoogleアカウントを利用してサービスにログインすることができます。

5. Smart card authentication

従来のSSOとは異なり、同様の仕組みをサポートするハードウェアも存在します。具体例として、PCに接続する物理的なスマートカードリーダーが挙げられます。アプリは、スマートカードに保存された暗号鍵と通信することで利用者を認証します。スマートカードは利用者自身が携帯する必要があり、紛失のリスクがある上、高コストであるうえ、PINを入力する必要があります。

‍

SSOにおけるSAMLとOAuthの利用

認証トークンの正当性を確認するために通信プロトコルが利用されます。認証トークンを生成するための言語であるSAMLは、基本的な規格です。SAML規格では、拡張可能なマークアップ言語（XML）を用いて、利用者認証や認可情報を安全な通信路で伝達します。SSOにおいては、利用者、サービスプロバイダ（SP）、アイデンティティプロバイダ（IdP）間の通信でSAMLが機能します。

利用者情報は、1回のログインで複数のサービスに安全にアクセスできるよう扱われるべきです。これは、外部サービスが利用者情報を活用できるオープン認可（OAuth）プロトコルによって実現されます。SPは利用者のアクセス要求をIdPに伝え、IdPがそれを確認してからアクセスを許可します。Facebookアカウントを利用してサイトにサインアップする例は、この仕組みのよい例です。

SSOは、OAuthやSAMLといった単体プロトコルと連携して利用できます。SAMLが利用者認証を行うのに対し、OAuthは認可に用いられます。

‍

シングルサインオンの利点と課題

利点

• 攻撃面の縮小：SSOによりパスワードの疲弊や安全でないパスワードの使用が解消され、フィッシング攻撃に対する脆弱性が低減されます。また、手間とコストのかかるパスワードリセットが減り、利用者は1つの安全で固有のパスワードを覚えるだけで済みます。
• シンプルで安全な利用者アクセス：SSOは、どの利用者がいつどこからどのアプリにアクセスしたかの情報をすぐに把握できるため、システムの整合性を守るのに役立ちます。また、端末紛失などのセキュリティリスクに対しても、ITチームが迅速にアカウントや重要データへのアクセスを遮断できます。
• 利用者アクセスの評価向上：変化の激しい企業環境では、適切な権限で正しい情報や資源にアクセスできるよう管理することが求められます。利用者の職務や部署、役職に基づいてSSO上でアクセス権を設定することで、一貫性と明瞭性が保たれます。
• 効率的で便利な利用者体験：利用者は、必要なアプリへ迅速かつ簡便にアクセスできる恩恵を受けます。認証情報の手入力といった手間がなくなり、ワンクリックで多くのアプリにログインできるため、ストレスが軽減されます。
• SSOは、企業と利用者の安全を守る上で欠かせない要素です。SSOを基盤とすることで、多要素認証（MFA）やアイデンティティ検証、リスク評価、コンプライアンスといった他のセキュリティ対策を統合し、企業の安全なスタートと今後のセキュリティ強化につながります。

課題

• SSOはシンプルで利便性が高い反面、適切に実装・管理されなければセキュリティリスクとなる場合があります。具体的な課題としては、
• 利用者アクセスに関するリスク：攻撃者が利用者のSSO認証情報を入手すると、その利用者が許可されているすべてのサービスへアクセスできてしまいます。そのため、パスワード以外の認証手法を採用することが重要です。
• 潜在的な脆弱性：最近、SAMLやOAuthの弱点を突かれ、不正アクセスが発生した事例もあります。SSOを他の認証要素やアイデンティティ管理と統合して提供するプロバイダとの連携が不可欠です。
• ソフトウェアの互換性：アプリがSSOプラットフォームと連携できないケースもあります。SAML、Kerberos、OAuthなど、いずれの方式でも、アプリ提供者は真のSSO機能を提供する必要があります。そうでなければ、完全な統合が実現されず、新たなパスワード管理の負担となります。

‍

SSOは安全か？

ただし、SSOが万能な解決策であるとは言えません。コスト、管理、標準化（SAMLとOAuthの違い）、セキュリティといった課題が存在し、Sign in with Appleの脆弱性やMicrosoft OAuthの欠陥のような認証上の問題で、攻撃者が標的にされる可能性もあります。

さらに、SSOプラットフォームは企業全体のIT設計に組み込む必要があるため、全体のセキュリティを維持しながら導入方法を慎重に検討する必要があります。例えば、SSOプラットフォームは、利用者がシステムにアクセスする際の発信元IPアドレスがセキュリティツールで検出されにくくなる場合があります。

それにもかかわらず、多くの場合、企業アプリの複数ログイン情報を個別に管理させるよりも、SSOを採用したほうが安全性は高まります。利用者がログインする回数が減り、覚えるパスワードも少なくなるため、攻撃面は確実に縮小されます。管理者は2FAや強固なパスワードなどの対策を一元的に実施しやすくなり、総じてSSO非採用のシステムよりも安全です。

‍

WallarmとSSOソリューションの連携方法

適切なセキュリティ設定を通じ、企業はWallarmセキュリティプラットフォーム（アクセス制御システム）を活用してデータ漏洩を防止できます。Wallarmを用いることで、オンプレミスとクラウド環境の両方でSSOを統合管理可能です。また、イベントや時間に応じてワンタイムパスワード（OTP）を生成するモバイルアプリもサポートされ、企業全体で一貫した安全な2FAが実現されます。