シリーズ『IDaaSの教科書』3)徹底解説！SSOの仕組みを理解する

IDaaSを語る上で必ずと言って良いほど耳にする言葉、「SSO（シングルサインオン）」。皆さんはこれがどのようなものなのか正しく理解されていらっしゃるでしょうか。今回は、シングルサインオンの仕組みについて分かりやすくご説明いたします。

前回（第2回 「IDaaSに必要な5つの機能を理解する」）は、IDaaSに備わっている5つの機能、すなわち「SSO」「ID管理」「ID·ディレクトリ連携」「アクセス権制御」「ログ取得」についてお伝えしました。今回は、5つの機能の中でもその中核となる「SSO：シングルサインオン」について解説いたします。

 

SSOとは

SSOは「Single Sign-On：シングルサインオン」の略称で、“1回”や“一度”を意味する「シングル (single)」と放送業界用語で“放送開始の合図”を意味していたものが転じて“システム利用開始時の認証”という意味の「サインオン (sign-on)」という2つの単語からなる造語になります。
「一度、特定のシステム・サービスで認証を行うと、連携する他のシステム・サービス利用時の認証が不要になる」ことを指します。

では、SSOはどのような経緯で進化を遂げてきたのでしょうか。その過去を知るためには、企業や組織においてシングルサインオンが大規模に採用された「Windows 95」の時代にまで遡る必要があります。

(1)社内SSOの時代 (1990年代後半～2000年代中盤)

Windows 95リリース以前は、「ビジネスにおいてパソコンを使わなかった」時代と言えるでしょう。これが、Windows 95リリース後に「1人1台、パソコンが支給」され、「パソコンで業務や社内処理を進める」ことが当たり前となります。
このため、これまで紙などで行っていた処理の一部がデジタル化され、パソコンを利用して完了させるようになりました。

各人が社内処理を行う上で、当然認証が必要です。しかし、社内の「勤怠システム」「ファイル共有」「営業データベース」などを利用する際に毎度認証を行うのは手間ですし、パスワード忘れや紛失による情報システム部門への問合せも発生します。このため、企業や組織においてSSOが広く利用されるようになりました。

SSO専用の製品も多数販売されましたが、特に多く利用されたのはマイクロソフトが提供する「Active Directory」です。SSOだけでなく、ユーザー管理、端末管理なども併せて製品であったこともあり、ある意味「SSO界のデファクトスタンダード」となりました。

(2)フェデレーションSSOの時代 (2000年代後半～2010年代前半)

Active Directoryを代表とするSSOの限界は、「1つの会社の社内ネットワーク内で利用することを前提」とされていたことです。
例えば、「親会社と子会社」「会社Aと取引先B」などでSSOを実現したくても、ネットワーク上の制限により行えなかったのです。

これを解決する方法として登場したのがフェデレーションです。
例えば、「親会社のドメイン」と「子会社のドメイン」が信頼関係を結ぶことで、社内ネットワークを超えてSSOが行えるようになりました。とはいえ、フェデレーションを必要としない企業も多いため、フェデレーションを利用したSSOを導入した企業はそこまで多くなかったのが実情です。

(3)クラウドSSOの時代（2010年代後半～）

クラウドという概念や具体的なサービスが登場したのは2000年代です。しかし、クラウドが普及し、企業や組織の業務の中核を担うようになったのは、ほんの10年前、2010年代に入ってからのことです。

クラウドサービスは、インターネット上の他社のサーバーにアクセスして利用します。特に信頼関係を結んでいるわけではありません。従来型のActive DirectoryによるSSO、またフェデレーションによるSSOの両方が利用できません。
この隙間を埋めるようにして登場したのが、クラウドサービスに対してSSOを行うIDaaSなのです。
SSO自体がクラウドサービス化することで、どのクラウドサービスに対してもSSOが可能となりました。

同時にIDaaS自体が、従来型のSSO製品が持っている機能を取り込むことで、「社内のSSOとクラウドサービスへのSSOを両方実現したい」という顧客のニーズを取り込むことになりました。

 

身近なSSOの例

自分の身の回りにどのようなSSOがあるかご存じでしょうか。ここで、いくつか具体的な例を上げてみましょう。

• Googleアカウントにログインしておくと、Googleが提供するサービス「Gmail」「Googleフォト」「Googleドライブ」「Googleマップ」などに追加の認証なくログインできる
• オンプレミス型のActive Directory (AD) にログインすると、ADと連携する「データベース」「ファイル」「社内システム」などに追加の認証なくログインできる
• IDaaSであるトラスト・ログインなどのサービスを利用すると、サービスが対応するSaaSアプリ、Webサイト、社内システムなどに追加の認証なくログインできる

などなど、普段気にせずお使いだったりするものもあるのではないでしょうか。

では、このようなSSOが利用可能になると一体どのようなメリットがあるのでしょうか。

 

SSOを利用するメリット

1.セキュリティを強化できる

例えば、10個のサービスに都度ログインしなければならない場合、多くのユーザーは10個のサービス全てのパスワードを記憶できないので、「同じパスワードの使い回し」を行ってしまいます。
つまり、「Aサービス」のログインに使うパスワードを、「Bサービス」「Cサービス」でも使ってしまうのです。これが重大な問題になるのです。
なぜなら、悪意のある攻撃者が行う一般的な攻撃手法の一つに「リスト型攻撃」があります。
これは、過去に漏えいしてしまった「ID」と「パスワード」の組み合わせを利用して攻撃を行うというものです。
例えば、「Aサービス」でID・パスワードの漏えいが発生した場合、悪意のある攻撃者はその情報を入手し、「Bサービス」「Cサービス」などに不正アクセスを試み、クレジットカード情報や個人情報などを盗み出します。

こうした攻撃のターゲットになってしまうことからパスワードの使い回しはとても危険です。しかしながら、SSOを利用すればパスワードの使い回しを防げるのです。

例えば、SSOを利用するためIDaaSにログインした場合、そこから先にSSOで利用するサービスは「別なパスワードが設定されている」か、「そもそもパスワードを利用しないログインが可能」となっているかのいずれかであるためです。

2.「パスワード忘れ」「パスワードリセット」工数を減らせる

利用するサービスのパスワードを使い回しせずに、別々のものを用意した場合、セキュリティは保たれますが、別な問題があります。
人間にはパスワードを覚えようとしても限界があります。個人差はあるでしょうが、記憶できる量を超えては覚えていられないのです。その結果、何度か試してみることで、アカウントがロックされることもあります。

パスワード忘れやパスワードリセットが必要な場合に、その作業をセルフサービスにできる仕組みであれば、情報システム部門やヘルプデスクの工数はそこまで必要となりません。
しかし、「情報システム部門でパスワードリセットを行う仕様」となっているサービスの場合は、担当者の時間が奪われることになります。

しかしながら、SSOの場合、覚えておくべきパスワードは非常に少なくなりますので、そもそもパスワード忘れやパスワードリセットの必要が減少します。

結果、情報システム部門の生産性向上・ヘルプデスク人員最適化によるコスト削減が実現できるのです。

3.ユーザーが何度もログインする手間を省ける

SSOを使ってログインすると、対応するサービスやシステムへのログインはそれ以後不要となります。

仮に10個のサービスを利用する場合、SSOがなければ個別に10回の認証を行う必要がありますが、SSOを利用すれば必要な認証は最初の1回だけです。
「会社などのオフィスの入口の鍵を開けてしまえば、その後どの会議室に行くにも鍵は必要ない」というようなものだと理解すると分かりやすいかもしれません。（最近は会議室にもセキュリティキーがついているところも多くなりましたが…）

また、生産性の観点からもこんな計算が成り立ちます。

一度のログインに10秒かかるとして、SSOを利用し「1回の認証で済む」場合と、SSOを利用せず「10回の認証が必要」な場合を比較すると、単純比較で10秒と100秒の違いがあります。
これが月20営業日だと2000秒と200秒、1年だと6時間40分と40分の違いになります。SSOは、利用するサービスが増えるごとに生産性は急上昇すると考えることもできるのです。（あくまで机上の空論でしかありませんが、導入の際にはこんな数字が役に立つことも）

また、単にログインにかかる時間以外の手間もかかります。
例えば、都度ログインが必要だと管理するパスワードが多いことから、「パスワードを調べる・探す時間」「パスワードの問い合わせにかかる時間」「パスワードが再発行にかかる時間」もかかる場合があります。

 

このようなメリットをもたらすSSOですが、デメリットはないのでしょうか？

 

SSOを利用するデメリット

1.パスワードが盗まれると、連携先すべてに不正アクセスされる

例えば、1つのパスワードを使って（SSOに）ログインすることで、その後10個の連携先にSSOできている場合です。
この場合、ログインに利用している1つのパスワードをハッキングしてしまえば、他のシステム全てにアクセス可能となることを意味します。これは大きなセキュリティ上のリスクとなります。

ホテルに例えると、マスターキーを盗まれてしまい、どの客室にでも入れてしまうような極めて危険な状態です。

こうしたリスクを防ぐために、現在では多要素認証：MFAが用いられます。（逆にMFAが使用されない仕組みの場合は要注意と言えるでしょう）
例えば、パスワードを入力した後に、以下のような追加の認証を行います。

• スマートフォンの「認証システム (Authenticator)」に表示される数列を入力
• パソコンやスマートフォンにインストールされた「電子証明書」を確認する
• 特定のIPアドレスからのみアクセスを許可（ホワイトリスト）、または特定のIPアドレスからの接続を拒否する
• クッキーを利用し、ユーザーが登録したブラウザ以外からの接続を拒否する

2.SSO製品に障害が発生すると各種サービスログインできなくなる

SaaS/クラウドサービスにSSOする製品 (IDaaS) を思い浮かべてください。
例えば、業務で利用するSaaSのパスワードを全て、情報システム部門が IDaaS 上で管理している場合、従業員は「IDaaSのパスワードは知っているが、各SaaSへアクセスしている実際のパスワードは知らない」という状態になります。

この状態で、IDaaSに障害が発生すると、従業員は利用したSaaS全てにアクセスできなくなります。
これを回避するには全従業員が利用する全てのSaaSのID＆パスワードを開示することになりますが、実際問題、情報システム部門が全従業員に「各種SaaSのパスワードを全て通知」するわけにもいかず、結局のところ「IDaaSの障害が復旧するまで待たねばならない」という事態になります。

こうしたリスクを防ぐためには、以下のポイントにも注意が必要です。

• 製品が信頼できる会社から提供されていること
• 稼働実績が公開されていること
• 製品が内部統制の認証 (SOCなど)を取得していること

とかく価格だけに目がいきがちですが、信頼性なども考慮してSSO製品/サービスを選ぶべきなのです。

3.SSO製品/サービスは無料でなく有料

SSOを行うための製品/サービスは、多くのベンダーから提供されていますが、基本的には有料と考えましょう。中にはGMOグローバルサインが提供する「トラスト・ログイン」のように利用期間無制限で無料で使い続けられるものもありますが、企業ユースを考えると機能的に不足している部分もあります。（しかしながら、使い方として自社にマッチするのであれば、無料は強み方です）
また、「買い切り」「月額制（サブスクリプション）」といった販売方法の違いもありますが、原則として、ユーザー数（アカウント）に応じた課金であることが一般的です。よって、ユーザー数が多い企業ほどその金額は大きくなる場合があります。

コストをできるだけ抑えるためには、「SSOが必要な従業員」と「そうでない従業員」を正しく選別すること、また「利用者数を定期的に確認し、契約者数が実際の利用者数を大幅超過する事態を防ぐことが大切です。

しかしながら、先にも述べたように機能的な制限はあるものの、無期限に利用可能なSSOサービスも存在するので、何をどう使うかしっかり決めて利用することで、コストを抑えることも可能ではないでしょうか。

 

主なSSOの方式を理解する

次に、企業や組織が利用可能なSSOの方式にはどのようなものがあるか、導入検討する目線で調べてみましょう。
なお、各SSO製品は下記の中の1つだけに対応しているわけでなく、複数の方式に対応しているのが一般的です。

SSOの方式は多岐に渡るため、特によく利用されるもののみをご紹介します。

1.フォームベース方式（代行入力方式）

フォームベース方式は、ブラウザ上のID・パスワード入力フォームに対して、SSO製品がユーザーの代わりにパスワードを入力してくれる方法です。シンプルな方法で、多くのサービスに対して利用できること、また各サービス運営者側で設定や準備が不要であることから、幅広く利用されています。

2.SAML方式

SSO製品と各サービスの間で直接ID・パスワードをやり取りしない方法として普及してきたのがSAML方式です。ID・パスワードを送る代わりに「認証リクエスト」「リクエストへの回答」をやり取りします。このため、万が一やり取りしている情報が盗聴されたとしても、ID・パスワードは含まれないため安全性が高いといえます。

3.リバースプロキシ方式

ユーザーが利用するパソコンやスマートフォンと、アクセス先のサーバーとの間に入り、Cookieを利用しサーバーとのやり取りを中継するためのサーバーをリバースプロキシと呼びます。
これをSSOに利用したものがリバースプロキシ方式のSSOとなります。一般的にはリバースプロキシ用のサーバーを新たに立てる必要があります。

4.エージェント方式

SSOを行うサーバーにエージェントをインストールすることで、安全な認証を可能とする方式です。リバースプロキシ型と同様、Cookieを利用しますが、ユーザーがログイン先サービスに直接アクセスする点が異なります。同一SSO製品を利用しての最初のログインはユーザー認証を行いますが、2回目以降はアクセス権の確認のみ (SSO) となります。

 

SSOを使うということ

これまでSSOについての解説を行ってきました。概念的には既にご理解いただけたとは思いますが、実際にSSOを利用するとはどのような操作になるのかを紹介したいと思います。

サンプルには、ユーザー数無制限、連携アプリ数無制限で、しかも無料で使い続けることもできるGMOグローバルサインの「トラスト・ログイン」を使い、実際にSSOを利用する際の手順を紹介します。

今回は、マーケティング担当者が Facebook にログインすると仮定したフローをお見せします。

1.ブラウザのアドオンをクリック

各種サービスにSSOするためには、まずIDaaSにログインする必要があります。トラスト・ログインの場合は、ブラウザのアドオンをインストールすれば、「ログイン画面を開く」をワンクリックするだけでログイン画面に移動できます。

2.IDaaSにログイン

IDaaSへログインするために必要な情報を入力し、「ログイン」をクリックします。

3.各サービスのアイコンをクリック

再びブラウザのアドオンをクリックすると、今度はSSO可能なサービス一覧が表示されます。
今回は Facebook アイコンをクリックします。

4.ログイン完了

Facebookアイコンをワンクリックするだけで、Facebookにログインが完了しました。表示された他のアイコンもワンクリックするだけでログインできます。

毎度のID・パスワード入力が不要となるため、短時間でのログインが可能となること、また各サービスのパスワード忘れからも解放されるため、生産性の向上とセキュリティ向上の両方を享受できます。

 

リスクを理解したうえでセキュリティと生産性向上を実現

お伝えしました通り、SSOは「セキュリティ」と「生産性」の両方を実現できるというメリットがあります。その反面、「パスワードが盗難時のリスク」「SSOサービス障害リスク」「有償」という留意点もあります。

しかしながら、近い将来にはFIDO2などの認証デバイスが一般的になり、「パスワードを全く利用せずに認証を行う」パスワードレスの時代が来るとされています。

現在のリスクに対応するには、「SSOを用いる」ことに加えて、「多要素認証：MFAを行う」ことでリスクをミニマイズしておくことが現実的です。

また、SSO導入検討の際には、「SSO導入によるリスクをどのようにカバーして、メリットならびセキュリティを最大化するか」という観点で製品選定を実施されるとよいでしょう。

 

---

中山　ゆか（なかやま　ゆか）

GMOグローバルサイン株式会社
トラスト・ログイン事業部 部長

GMOグローバルサイン新規事業部としてサービスの立ち上げを行う。
～全てのログインを簡単でセキュアに～をミッションに日々進化する
「トラスト・ログイン」で企業の成長を止めない環境づくりを目指す。

---

 

＜バックナンバー＞