シングルサインオン（SSO）認証とは？仕組み、認証方式の種類、メリットや認証連携のパターン

　COVID-19の長期化に伴い、テレワークと相性の良いクラウドサービスの活用が進み、それに伴い社員が複数のIDやパスワードを管理する必要がでてきています。このような状況に悩んでいるシステム担当者は多いのではないでしょうか。そうした問題は「シングルサインオン（SSO）」で解決できます。シングルサインオン（SSO）の仕組みやメリット、製品選定のポイントなどを解説いたします。

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

　シングルサインオン（SSO）認証とは何か、認証と似た言葉の認可とは何かについて解説します。

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

　通常、アプリケーションやWebサービスを利用するときは、そのシステム毎にIDとパスワードを入力してログインを行う必要があります。
　そのため、システムの数だけIDとパスワードを管理する必要があり、高い運用負荷から簡単なパスワードの設定や、パスワードの使い回しなどセキュリティ上好ましくない状態を生み出しています。また、パスワード忘れなどの場合にはシステム毎に対応する必要があり、ユーザーやシステム管理者に負担がかかります。

　しかし、シングルサインオン（SSO）を導入していれば、最初のアプリケーションを利用する時に、一度だけログインすれば、以降は全てのアプリケーションやWebサービスを再ログインなしに利用できるようになります。
　IDとパスワードの管理も1つで済み、アカウント管理の運用負荷を軽減できます。さらに、そのパスワードに対して簡単なパスワードを設定させないように制限することで、攻撃されやすいパスワードの使用を回避することもできます。

　オンプレミスとクラウドサービスを横断的に利用することもできます。
例えば、最初にオンプレミスのWebサービスにログインし、その後クラウドサービスを利用する場合、クラウドサービスへのログインを求められることなく、すぐに利用できます。 　

シングルサインオン概要図

　また、社員のパスワード管理の負荷が軽減される点もシングルサインオン（SSO）の特徴です。
　社員は一つのIDとパスワードを管理するだけで良く、システム毎にIDとパスワードを管理する手間から解放されます。

シングルサインオンにおける認証と認可とは？その違いは？

　認証とは、ユーザーの本人確認を行うことです。
　例えば、パスワード認証であれば、ユーザー本人しか知らないパスワードを入力できることで、本人であると確認しています。
　指紋認証や顔認証であれば、その指紋や顔がユーザー本人を示すため、本人確認となります。

　認可とは、情報やシステムなどのリソースにアクセスする権限を付与することです。
　シングルサインオン（SSO）においては、サードパーティーのWeb APIへのアクセス許可を与えたり、認証に成功したユーザーに対して、アプリケーションやサービスへのアクセス許可を与えたりします。

シングルサインオン（SSO）認証の歴史

　企業内で利用するアプリケーションにおいて、クライアントに導入するアプリケーションの割合よりも、Webアプリケーションの割合が増加すると共に、利用するIDとパスワードが増え、シングルサインオン（SSO）認証の必要性がでてきました。
　シングルサインオン（SSO）認証は、もともとは企業内の各システムにシームレスにログインするために使われていました。

　インターネットの普及でYahoo！JapanのようなポータルサイトやSNSなどのサービスが開始され、利用者が増加するにつれ、それらのアカウントを利用して、他のサービスを利用するニーズが高まりました。
　ソーシャルログイン機能を備えたシングルサインオン（SSO）製品により、ポータルサイト、SNSのアカウントが他のサービスでも利用されるようになり、企業内の閉じたネットワークではなく、インターネットでのシングルサインオン（SSO）認証が使われるようになりました。
　また、SNSなどのデータに対してサードパーティー製のクライアントにIDとパスワードを渡すことなくアクセスできるように、標準の認可技術としてOAuthが登場しました。
　認可技術であるOAuthではユーザーを特定するためのID情報などの連携に関しての仕様がなく、認証には適していませんでした。そこで、OAuthを認証として活用するために拡張した、ID連携のための仕組みとして、OpenID Connectも登場しました。

　企業においてもクラウドサービスの拡大により、企業内の環境とクラウドサービス間でのシングルサインオンが利用されるようになりました。
　また、テレワークの普及で社外クラウドサービスを利用することが急激に増え、利便性と安全性の点からシングルサインオン（SSO）認証に注目が集まっています。

シングルサインオン（SSO）の認証方式の種類とその仕組み

　シングルサインオン（SSO）を実現するには5つの方式があります。

1. エージェント方式
2. リバースプロキシ方式
3. 代理認証方式
4. フェデレーション方式
5. 透過型方式

　それぞれの方式とその特徴について紹介します。

エージェント方式

　Webサーバーやアプリケーションサーバーに専用のエージェントソフトウェアをインストールし、シングルサインオン（SSO）を実現する方式です。
　エージェントは、アプリケーションへのアクセスを受け、ユーザーが認証済みかどうか、アクセス権限があるかどうかなどを、認証サーバーに対して確認を行います。また、アプリケーション側でユーザー情報が必要な場合は、その通信のHTTPヘッダーなどに情報を格納して連携することができます。

エージェント方式の仕組み

　エージェント方式のメリットは、ネットワーク構成を変更せずに導入できることです。また、ユーザー認証を代行できるため、アプリケーションでの個別のパスワード管理が不要となることです。

　エージェント方式のデメリットは、Webサーバーやアプリケーションサーバーへのエージェントのインストールやアップデートが必要なことです。また、Webアプリケーション自体がエージェントに対応していない場合は利用できません。

リバースプロキシ方式

　WebブラウザとWebアプリケーションサーバーの間にリバースプロキシサーバーを設置し、リバースプロキシサーバーにエージェントソフトウェアを導入することで、シングルサインオン（SSO）を実現します。
　エージェントの動作は、エージェント方式と同様です。

リバースプロキシ方式の仕組み

　リバースプロキシ方式のメリットは、個々のWebサーバーやアプリケーションサーバーへのエージェント導入が不要で、OSやアプリケーションの種類に依存しないことです。また、システムの外部公開が必要な場合、リバースプロキシサーバーを介することでより安全にシステムを公開できる方式になります。

　リバースプロキシ方式のデメリットは、対象のWebアプリケーションをリバースプロキシサーバー経由にする必要があることです。
　リバースプロキシサーバーを経由する必要があるため負荷がかかりやすく、ボトルネックにならないようにするため、ロードバランサーの導入など、負荷分散を考慮する必要があります。

代理認証方式

　対象のアプリケーションのログインページに対して、ユーザーの代わりにIDとパスワードを送信し、ログインを完了させることで、シングルサインオン（SSO）を実現する方式です。
　エージェントがインストールされたリバースプロキシサーバーを経由して代理認証することが可能です。

代理認証方式の仕組み

　代理認証方式のメリットは、アプリケーション改修のできない古いアプリケーションや、パッケージソフトウェアに対しても、シングルサインオン（SSO）が実現可能なことです。

　代理認証方式のデメリットは、アプリケーションが管理しているIDとパスワードと、認証サーバーが管理しているIDとパスワードが完全に同期されている必要があることです。

フェデレーション方式

　クラウドサービスなどに対し、パスワード等の情報を渡すことなく、安全に認証されたユーザーの情報を連携することで、シングルサインオン（SSO）を実現します。
　ユーザー情報はサーバー間で直接連携するパターンと、ユーザーが利用しているWebブラウザ経由で連携されるパターンがあります。認証サーバーと異なるドメインのサーバーやクラウドサービスに対しても連携可能です。フェデレーション方式では、ユーザー情報を主にPOSTデータでやり取りするため、盗聴に対して強い方式になります。

フェデレーション方式（SAML）の仕組み

　フェデレーション方式のメリットは、プロトコルの標準化が進められており、SAMLやOpenID Connectに対応したアプリケーションやクラウドサービスに対して容易にシングルサインオン（SSO）が実現できることです。

　フェデレーション方式のデメリットは、対象のアプリケーションがSAMLやOpenID Connectに対応している必要があることです。

透過型方式

　WebブラウザとWebアプリケーションサーバーの間に通信を監視するサーバーを設置し、ユーザーアクセス時に認証が必要なときのみ認証情報を送信することで、シングルサインオン（SSO）を実現します。

透過型方式の仕組み

　透過型方式のメリットは、ネットワーク構成を変更せずに導入できること、どんな端末やブラウザでも対応していること、クラウドサービスだけでなくオンプレミスのサービスでも対応できることです。

　透過型方式のデメリットは、透過型認証に対応したシングルサインオン製品が必要であることです。

各方式のまとめ一覧表

シングルサインオン（SSO）認証のメリットと注意点

　シングルサインオン（SSO）を導入すると以下のようなメリットがあります。

【メリット1】ログインの手間を軽減できる

　アプリケーションにログインするには、IDやパスワードを思い出す、メモから転記するなど多少の労力がかかります。アプリケーションが多くなるとその労力の積み重ねが、本来の業務を行うための時間を奪っていきます。
　シングルサインオン（SSO）であれば、一度のログインで、対応したすべてのアプリケーションを利用できるようになるため、それらの労力を軽減することができます。

【メリット2】アカウントを一元管理できる

　ユーザーは、1つのIDとパスワードで複数のアプリケーションにログインできるようになるため、アプリケーション毎にIDやパスワードを覚えなくて済みます。
　システム管理者にとっては、ユーザーのログインに利用するアカウントが認証サーバーで一元管理され、パスワードリセットなどの運用負荷が軽減されます。

【メリット3】セキュリティリスクを軽減できる

　フェデレーション方式であれば、クラウドサービス事業者にパスワード情報を渡すことなく利用できるので、事業者が事故などでアカウント情報が漏洩してもパスワード漏洩の影響を受けません。
　また、1つのIDとパスワードだけになるため、システム管理者にとってパスワード設定に文字種や文字数などの制限を効かせやすく、簡易なパスワード設定を抑止することができます。それによりブルートフォース攻撃による、なりすましなどのセキュリティリスクを軽減することができます。

【注意点1】不正アクセスへの対策

　認証を認証サーバーで1度だけ行っているため、悪意のある攻撃者が不正アクセスにより認証を突破してしまうと、認証連携している各サービスにも不正にアクセスできてしまいます。
　そのため、パスワードは安易なものが登録できないように厳格にするだけでなく、多要素認証を取り入れるなど認証強化を図る必要があります。

【注意点2】認証システム停止によるログイン不可

　シングルサインオン（SSO）の認証システムが停止すると、認証連携している各サービスにもログインができなくなります。それにより業務が滞るなどの影響が発生する可能性があります。
　稼働時間を担保するために、可用性の高い認証システムの導入などを検討する必要があります。

【注意点3】連携できるシステムかどうか

　認証連携させたいシステムが、シングルサインオン（SSO）に対応していない可能性があります。
　導入前には、いずれかの方式で連携できそうか確認しておく必要があります。

認証連携を実現するシングルサインオンの連携パターン

　シングルサインオン（SSO）を導入した際の連携パターンを紹介します。

グループ企業の共通基盤の連携パターン

　関連会社が多いグループ企業では、グループ企業が共通で利用できる福利厚生や保険、人事給与などのシステムがあります。また、各社には社内ポータルなどがあり、各社では社内ポータルを起点にシステムを利用しています。
　シングルサインオン（SSO）を導入することで、社内ポータルおよびグループ共通のシステムで認証連携することができます。社内ポータルへアクセスし最初に認証することで、その後グループ共通のシステムへアクセスした際にもシームレスにログインされ、利用できるようになります。

ポータルサイト連携パターン

　シングルサインオン（SSO）を導入することで、自社のWebサービスと、Yahoo!JAPANのようなポータルサイトやLINEのようなSNSといった外部のサービスと認証連携することができます。そうすることで認証を外部のサービスに任せることがで、外部のサービスを利用しているユーザーにとっては馴染みのある認証方式でWebサービスを利用できるようになります。

シングルサインオン認証を実現するSSOシステムの選び方ポイント

　シングルサインオン（SSO）を導入するにあたり、どのような製品を選定すれば良いか、そのポイントを解説します。

提供形態がオンプレミス型かクラウド型か

　シングルサインオン（SSO）の製品にはオンプレミス型とクラウド型があります。それぞれの特徴を加味して選択する必要があります。

　オンプレミス型は、自社の利用状況にあわせてカスタマイズができることがメリットです。
　製品費用はかかりますが、月額費用は一定の費用に収めることができます。

　クラウド型は、設定のみで利用できるようになるため、短時間で導入できることがメリットです。
　製品費用はかかりませんのでスモールスタートが可能です。一方で月額費用はユーザー数に依存して変動するケースが多いです。

既存システムや将来導入を検討しているシステムと連携できるか

　シングルサインオン（SSO）対象とする既存の業務システムやWebサービスが、いずれかの方式で連携できそうか確認します。試用ができる場合は、実際に導入して確認するのが確実です。
　将来導入予定のアプリケーションに対しても連携可能か確認します。例えば、SAMLに対応したクラウドサービスの導入を予定している場合、SAMLに対応した製品を選定条件とします。

　またアカウント一元管理のために、社内でアカウントを管理しているデータベースやActive Directory、LDAPなどのディレクトリが利用できるかを確認します。

運用・管理しやすいか

　システムは導入して終わりではなく、運用していく必要があります。アプリケーションの追加や、問題発生時のログ確認など、扱いやすいものを選びます。

サポート体制が充実しているか

　導入時や導入初期に製品を熟知したベンダーの支援が受けられるか、運用していく中で発生するトラブルに対し影響を最小限にするために迅速にサポートしてくれるかどうかを確認します。

　海外製品の場合は、サポートが日本語対応か、サポート時間が日本時間に対応しているか、という点も重要となります。

まとめ

　シングルサインオン（SSO）は、1つのID・パスワードで複数のWebサービス・クラウドサービス・アプリケーションにログインできます。ID・パスワードを一元管理することにより、運用負荷の軽減だけでなくセキュリティリスクを軽減するメリットがあります。
　シングルサインオン（SSO）を実現する方式は5つあり、それぞれにメリットとデメリットがあるため、自社に適した方式や対応製品を選定する必要があります。

　シングルサインオンの製品を選定する際は、本番稼働後の運用を見据え、機能面だけでなくサポート体制が充実していることもポイントとなります。
　導入の際には、注意点も踏まえ支援してくれるベンダーと協力するということも、有効な選択肢となります。

ThemiStruct-WAMなら社内/社外システムのシングルサインオンを実現できます

　社内/社外システムのシングルサインオンを実現する統合認証基盤「ThemiStruct-WAM」はID/パスワード以外の認証要素を組合せることで、利用者のアクセス環境に応じて最適なセキュリティ強度の認証方法を適用できます。
　また、社内システムをはじめ、様々なクラウドサービスとのシングルサインオンが可能となり、パスワードレス認証や多要素認証など必要な認証方式を備えているので、基盤全体でのセキュリティ強度の統一やユーザー利便性の向上が実現できます。

　当社では統合認証基盤の導入において上流工程～移行・リリースまでのフルサポート、特定工程のみに限定した部分サポートなど、お客様のニーズやご予算に応じた導入支援が可能です。

　これまで当社が十数年に渡り統合認証基盤の開発・構築・運用に取り組んできた実績を基に、導入段階から本稼働後の運用段階に至るまでお客様が抱える課題に対して、安心・確実・迅速なサポートを提供できます。

※この記事に掲載されている内容、および製品仕様、所属情報（会社名・部署名）は公開当時のものです。予告なく変更される場合がありますので、あらかじめご了承ください。