コラム一覧へ戻る

5分で解説!気になるIT用語

2019年10月29日

シングルサインオン1

第8回 「シングルサインオン」

 「シングルサインオン」とは、1つのIDとパスワードで複数のサービス・アプリケーションにログインできる仕組みのこと。「Single Sign On」を略して「SSO」ともいう。

 現代は、PCやスマートフォンなどで複数のWebサービス・アプリケーションを使用するのが当たり前だが、その全てに別のIDとパスワードを設定していると管理が大変になってしまう。また、それぞれのサービスにアクセスするごとにIDとパスワードを入力して認証(ログイン)、という労力もかかる。

 これらを解決するのがシングルサインオンである。利用者にとっては1つのIDとパスワードを記憶すればいいため非常に利便性が高く、またシステム管理者にとっても社員ごとの認証情報管理が楽になる。

 まずは、この事を含めた、シングルサインオンを導入することによるメリットを見ていこう。

【メリット】
  • ①利便性・生産性の向上
  •  前述のとおり、利用者は1つのIDとパスワードを記憶すれば済む。
     1回の認証で必要なサービスにアクセスできるため利便性は大きく向上し、「複数のパスワードを管理する」「サービスにアクセスするごとにいちいち認証する」という作業からも解放されるため、生産性の向上も見込める。

  • ②セキュリティ強化
  •  多数のパスワードを管理していると、紙に書いてデスクやモニターに貼っておいたり、忘れてしまっても大丈夫なように簡単なもので使い回したり、というケースがままある。
     紙の場合は紛失や盗難、簡単なパスワードの場合だと総当たりのサイバー攻撃などで解析されるリスクがあるが、これを防ぐためにもシングルサインオンは有効だ。
     設定するパスワードは複雑、かつ文字数も多くするという前提条件はあるものの、それさえしっかりと記憶しておけば不正侵入を防ぐ可能性が高くなる。

  • ③管理のしやすさ
  •  社員1人につき1つのIDとパスワードとなるため、システム・セキュリティ担当者は管理がしやすくなる。例えば、社員がパスワードを忘れて再発行する場合は一度の作業で済む。
     社員にとっても覚える情報は1つであるため、そもそもこうしたケースが発生する頻度も減るだろう。
     また、管理がシンプルになったことで、「退職者の情報削除に抜けが生じて、アクセス可能な状態になってしまう」「数が多すぎて弱いパスワードを設定している社員のチェックがしきれない」といった、人為的なセキュリティリスクにも対応しやすくなる。

シングルサインオン2

 次に、どのようなデメリットがあるかを挙げていこう。

【デメリット】
  • ①情報漏洩時の被害が大きい
  •  1つのIDとパスワードで全てのサービスが利用できるということは、裏を返せばその情報が漏洩してしまうと、全てのサービスに侵入されるということになる。
     当然ながら、受ける被害も甚大になってしまうため、セキュリティにはこれまで以上に注意を払わなくてはならない。
     対策としては、パスワードを「大文字・小文字のアルファベット、数字、記号の4種類を組み合わせ、かつ10文字以上」というように複雑化する、ワンタイムパスワードなどを使った2段階認証にする、IP・端末によるアクセス制限をかける、といった例が考えられる。
     同時に、システムの脆弱性に対しても常に情報収集を行っておかなければいけないだろう。

  • ②導入のハードル
  •  シングルサインオンは専用のソフトフェアやクラウドサービスによって構築するが、場合によっては大幅な社内システムの変更やそれに伴う労力が発生する。
     コストも相応にかかることになるため、社内の規模や目的に合ったものを適切に選ぶようにしたい。

  • ③システム停止の影響が大きい
  •  災害・事故などによってシングルサインオンを行っているシステムに障害が起きると、全てのサービスが利用できなくなってしまう。
     業務にも大きな支障が出てしまうため、絶対に使わなければならないものについては、本来のID・パスワードを使ってもアクセスできるようにしておく、といった対策が必要になるだろう。

【シングルサインオンの認証方式】

 シングルサインオンを実現する仕組みは、以下のようなものがある。

  • ①エージェント方式
  •  シングルサインオンの対象とするサービス・アプリケーションがあるWebサーバそれぞれに、「エージェント」というソフトウェアを導入する方式。
     この「エージェント」がシングルサインオンサーバ(SSOサーバ)に対して認証の状態などを確認し、問題なければサービスへのアクセスを許可する。
     一度認証が成功すれば、SSOサーバに認証済の状態が返されるため、その状態が維持されている限り別のサービスにアクセスしてもIDとパスワードの再入力は必要ない。
     既存のネットワーク構成を一切変更せずにシングルサインオンを実現できるのが特徴だが、認証状態の識別にはCookie(クッキー)が使われているため、Cookieが有効な同一ドメイン内でしか使用できないという制限がある。
     また、そもそもエージェントと連携できないアプリケーションもあり、事前の調査が必要となる。

  • ②リバースプロキシ方式
  •  クライアント(ブラウザ)とWebサーバの間に「リバースプロキシ」サーバを設置し、そのサーバにエージェントを導入する方式。
     「リバースプロキシ」とは、クライアントとWebサーバの通信のやりとりを中継する機能のことで、クライアントからの要求を受けたリバースプロキシ内のエージェントがSSOサーバに認証可否を確認、問題なければWebサーバ(サービス)へのアクセスを許可する。
     エージェント方式との違いは、中継地点であるリバースプロキシサーバにのみエージェントが導入されていること。個々のWebサーバにエージェントを導入する必要がなく、またサービスに直接アクセスできなくなることで、セキュリティ強化にもつながる。
     デメリットとしては、サービスへのアクセス全てがリバースプロキシサーバを経由するようにネットワーク構成を変更しなければならないこと、リバースプロキシサーバにアクセス集中による負荷がかかるおそれがあること挙げられる。
     Cookieを使うため、同一ドメイン内でしか使用できない点もエージェント方式と同様だ。

  • ③代理認証方式
  •  「代理入力方式」とも言う。その名のとおり、エージェントがユーザーに代わって、サービスそれぞれのIDとパスワードを自動的に代理入力する方式。
     エージェントは個々のクライアントにインストールし、これに対して認証を行っている状態であれば、サービスのログインページで自動的にIDとパスワードが入力される。
     エージェント方式やリバースプロキシ方式と違い、複数のドメインに対応可能で、ローカルのアプリケーションにも適用できる。また、前の2つに比べて導入も容易だ。
     ただし、サービスそれぞれのIDとパスワードは別途クラウドのデータベースなどで管理しなければならず、代理認証に対応していないサービスもある点には注意したい。

  • ④フェデレーション方式
  •  複数のクラウドサービス間で、「チケット」というパスワードの代わりとなる情報を受け渡しすることでシングルサインオンを実現する方式。
     これにより、例えばマイクロソフト社のOffice365とグーグル社のG Suiteがシングルサインオンで利用できるようになるわけだ。
     サービス側が「SAML(Security Assertion Markup Language)」などの標準プロトコル(異なるドメイン間で認証を行うための規格)に対応していれば利用でき、各サービスの連携も非常に簡単。
     ただし、日本独自のサービスはまだ標準プロトコルに対応していないものが多く、そうしたものを主に利用している場合は先々の対応を待たなければならない。
     また、これらの方式は複数の組み合わせも可能だ。例えばリバースプロキシ方式と代理認証方式の組み合わせなら、リバースプロキシサーバ内に代理認証を行うエージェントを導入して……となる。
     いずれにせよ自社のみで構築するのは難しいため、導入の際は専門のベンダーに相談・依頼する方がいいだろう。

関連サービス

この記事は2019年10月29日時点のものです。

コラム一覧へ戻る