利用するクラウドサービスが増えるほど、ログインの数も増えていきます。その負担を軽くする仕組みとして挙がるのがSSO(シングルサインオン)とIDaaSです。名前は聞くものの、両者の関係や自社にとって何が変わるのかは分かりにくいところだと思います。この記事では、用語と仕組みの考え方を整理し、アカウント管理システムの基本で扱った運用の話と、どうつながるのかを解説します。
SSO(シングルサインオン)とは
SSO(シングルサインオン)は、一度ログインすれば、連携している複数のサービスに対して改めてパスワードを入力せずに入れるようにする仕組みです。利用者から見ると「ログインは一回で済む」という体験になります。サービスごとに別々のIDとパスワードを覚えて入力していた状態と比べると、日々の手間が減り、パスワードを紙に書き留めるといった運用も起きにくくなります。
IDaaSとは何かSSOとどう違うのか
IDaaSは、IDの管理と認証の機能をサービスとして提供するものを指す言葉です。誰にどのアカウントを発行するか、どのサービスを使わせるか、ログイン時にどのように本人を確認するかといった機能がまとめて提供されます。SSOはそうした機能のひとつとして位置づけられることが多く、SSOは機能、IDaaSはその機能を含む提供形態と整理すると分かりやすいと思います。実際の製品では呼び方や機能の区切りが異なるため、比較の際は名称ではなく必要な機能が揃っているかで見るほうが確実です。
仕組みの考え方
考え方はシンプルです。各サービスがそれぞれパスワードを持って本人確認をするのではなく、信頼する一箇所に本人確認を任せ、各サービスはその結果を受け取って利用を許可するという形になります。利用者がサービスにアクセスすると、本人確認を担う側にいったん案内され、そこで確認が済んでいれば、確認済みであるという情報が各サービスに渡されます。
この受け渡しには標準化された手順が使われますが、細かな仕様よりも「パスワードを持つ場所が一箇所に寄る」という点を押さえておけば、検討の判断はしやすくなります。どの基盤を本人確認の中心に置くかという方式の選び方はローカルアカウント・ドメイン・Entra IDの違いで扱っています。
導入で得られること
利用者側の効果は、覚えるべきパスワードの数が減ることです。数が減れば、同じパスワードを複数のサービスで使い回す必要も薄れます。
管理側の効果は、入社時の発行と退職時の停止を一箇所で行いやすくなることです。サービスごとに個別に対応していると、どこか一つで止め忘れが起きても気づきにくくなります。集約されていれば、誰がどのサービスを使えるのかも把握しやすくなります。とはいえ、一箇所で止められる範囲がどこまでかは事前の確認が必要です。この点は退職者アカウントの棚卸しと合わせて考えると整理しやすくなります。なお、アカウントを一元管理する手段はSSOやIDaaSだけではないため、選択肢を並べて比べたい場合はアカウント一元管理の手段の比較を参照してください。
集約の裏返しとして残るリスク
ログインを一箇所にまとめると、その一箇所の重みが増します。集約先のアカウントが第三者に使われてしまえば、連携している範囲すべてに到達されうるということです。したがって、集約先のログインについては、パスワードだけに頼らない強い認証を用意しておくことが前提になります。管理者アカウントの扱いについては権限管理の考え方も併せてご確認ください。
もうひとつ見落とされやすいのが、SSOの対象外として残る範囲です。社内のPC本体へのログイン、社内に置いたサーバー、保守のために用意された経路などは、連携の対象に入らないまま残ることが少なくありません。ここがパスワードのみで守られていると、クラウド側を集約しても全体としての効果は限定されます。クラウド側の対策だけでは埋まらない範囲についてはUTM・ウイルス対策があれば認証は不要？守っている領域の違いで詳しく扱っています。端末側の認証を具体的に検討する場合はWindows OSログインの2要素認証も参考になります。
SSOを入れても残る範囲を先に把握する
SSOの導入検討で最も多い行き違いは、「これで全部のログインがまとまる」という期待です。実際には、まとまらない範囲が必ず残ります。導入前にそこを把握しておくと、後から想定外が出てきません。
| ログインの場面 | SSOでまとまるか |
|---|---|
| 連携に対応したクラウドサービス | まとまる |
| 連携に対応していない業務サービス | まとまらない（個別管理が残る） |
| PC本体へのログイン | 原則まとまらない |
| 社内サーバーへの接続 | 原則まとまらない |
| 保守ベンダー用の経路 | まとまらないことが多い |
まとまらない範囲が「対策済み」の認識に紛れ込むと、そこが手つかずのまま残ります。導入前に、上の表の下3行が自社ではどうなっているかを書き出しておいてください。
検討時に確認しておきたいこと
- 連携できるか — 自社が実際に使っているサービスが、集約の対象にできるかどうか
- 対象外の範囲 — 社内の端末やサーバー、保守用の経路が対象になるのか、別の対策が必要なのか
- 集約先の認証 — 一箇所にまとめたログインを、どのように強化するか
- 使えないときの備え — 集約先にアクセスできない状況で、業務をどう継続するか
- 停止の確実性 — 退職時に、本当に一箇所の操作で必要な範囲を止められるか
入れたあと日々の仕事で変わること
SSOでクラウドのログインがまとまると、退職者の停止や「パスワードを忘れた」問い合わせが減ります。同じ考え方を、SSOでまとまらない社内のPC・サーバーにも広げておくと、担当者の手間はもう一段減ります。全PC・サーバーのログイン記録を1か所で見られれば、「入れない」と言われたときに席まで行かずに確かめられます。退職・異動のときも、席まで行かずにスマホの登録を外し、ローカルアカウントを止められるので、クラウド側の停止と同じ日に片づきます。
いまの運用を棚卸ししてみる
SSOやIDaaSを検討すべきかどうかは、利用しているサービスの数や、現在のアカウント管理の状態によって変わります。applippliの無料棚卸しでは、10問・約3分で、自社のID・アカウント管理の対応状況を「解決済み／一部解決／人手で対応／未解決」に仕分けた一覧にできます。集約の検討を始める前の現状把握としてお使いください。