シングルサインオン（Single Sign-On、SSO）は、1 つの ID とパスワードで一度ログインすれば、つながっている複数のサービスを、それぞれにログインし直さずに使えるようにする仕組みです。社内で使うクラウドのサービスが増えると、社員はサービスの数だけ ID とパスワードを覚える必要があり、同じパスワードを使い回したり、紙や表計算のファイルに書き留めたりしがちです。SSO にすると、社員が覚えるのは 1 つだけになり、会社の側も、入口を 1 か所で管理できるようになります。退職した社員の ID を止めれば、つながっているサービスにまとめて入れなくなるのも大きな利点です。
SSO の仕組み
SSO では、社員の ID とパスワードを確かめる役目を、ID の管理の仕組み（ID プロバイダ）に任せます。各サービスは、自分でパスワードを確かめる代わりに、ID の管理の仕組みに「この人は本人か」を問い合わせ、確かめた結果を受け取ってログインを認めます。
| 役割 | 中身 |
|---|---|
| ID の管理の仕組み（ID プロバイダ） | 社員の ID を持ち、本人かどうかを確かめる。多要素認証もここで行う |
| 各サービス | ID の管理の仕組みから、確かめた結果を受け取ってログインを認める |
| 受け渡しの方式 | SAML、OpenID Connect など、決まった形式で結果を受け渡す |
社内のメールやファイルの共有に使っている仕組みが、ID の管理の仕組みの役目を兼ねられることも多くあります。その場合は、別に仕組みを入れなくても、今の仕組みの設定で各サービスとつなげることがあります。
パスワードの使い回しとの関係
パスワードの使い回しが危ないのは、どこか 1 つのサービスからパスワードが漏れると、同じパスワードを使っているほかのサービスにも入られてしまうためです。漏れたパスワードの一覧を使って、さまざまなサービスにログインを試す攻撃は、広く行われています。
使い回しは、社員の意識の問題として語られがちですが、覚えるべきパスワードの数が多すぎることが根本の原因です。サービスが 10 を超えれば、全部に別々の長いパスワードを付けて覚えるのは現実的ではありません。SSO は、覚えるべきパスワードの数を減らすことで、使い回しが起きにくい状態を作ります。
SSO でつなげないサービスについては、会社で認めたパスワードの管理の道具を使い、サービスごとに別々のパスワードを自動で作って保管する方法があります。
導入でよくなること
ログインの手間が減る
社員は朝に一度ログインすれば、つながっているサービスを使えます。パスワードを忘れて問い合わせる件数も減り、情報システムの担当者の手間も減ります。
入口を 1 か所で守れる
多要素認証や、ログインを認める端末や場所の条件を、ID の管理の仕組みでまとめて設定できます。サービスごとに設定を確かめて回る必要がなくなります。
入社と退職の手続きが確実になる
入社のときは ID を 1 つ作れば、つながっているサービスを使い始められます。退職のときは ID を止めれば、つながっているサービスにまとめて入れなくなります。退職時の手順の全体は、退職者のアカウント削除の手順で説明しています。
誰が何に入ったかを確かめやすくなる
ログインの記録が ID の管理の仕組みに集まるため、いつ、誰が、どのサービスにログインしたかを 1 か所で確かめられます。
導入の手順
手順 1：使っているサービスを洗い出す
社内で使っているサービスを一覧にし、それぞれが SSO の方式に対応しているか、対応しているならどの契約の種類で使えるかを確かめます。部署が独自に使っているサービスも含めます。把握されていないサービスの洗い出し方は、シャドーITとはで扱っています。
手順 2：ID の管理の仕組みを決める
今使っているメールやファイルの共有の仕組みが ID の管理の役目を持てるか、別に仕組みを入れる必要があるかを決めます。社員の情報（氏名、所属、在籍の状態）の元をどこに置くかも決めます。社員の情報を 1 か所で正しく保つ考え方は、マスタデータ管理とはで説明しています。
手順 3：多要素認証を必ず使う
SSO の入口では、パスワードに加えて、スマートフォンのアプリや専用の鍵などで本人を確かめる多要素認証を、全社員に使ってもらいます。SSO は入口が 1 つにまとまる分、その入口が破られたときの影響が大きくなるためです。
手順 4：影響の小さいサービスから順につなぐ
一度に全部のサービスをつなぐと、ログインできないといった問い合わせが集中します。社員の多くが使うが、止まっても業務への影響が小さいサービスから順につなぎ、手順を確かめながら広げます。
手順 5：つないだ後に元のパスワードを使えなくする
SSO でつないだ後も、サービスごとの ID とパスワードでログインできる状態が残っていると、そこが抜け道になります。サービスの設定で、SSO からのログインだけを認める形にできるかを確かめます。管理者のためのログインの手段は、ID の管理の仕組みが止まったときに備えて、別に安全に残しておきます。
導入の前に考えておくこと
SSO は、ID の管理の仕組みが止まると、つながっている全部のサービスにログインできなくなるという弱みもあります。ID の管理の仕組みを選ぶときは、止まったときの対応や、提供元の稼働の実績を確かめておきます。止まったときに管理者だけが入れる手段を用意し、その手順を文書にしておきます。
費用の面では、SSO の機能が上位の料金の契約でだけ使えるサービスがあることに注意します。社員全員を上位の契約にすると、費用が大きく増えることがあります。つなぐサービスを選ぶ段階で、費用と、パスワードの管理の手間や退職時の止め忘れの危険とを比べて判断します。
社外から社内の情報に入るときに、場所ではなく人と端末で判断する考え方は、ゼロトラストとはで扱っています。SSO と多要素認証は、この考え方の土台になります。
実行時の落とし穴
多要素認証を後回しにする
SSO だけを入れて多要素認証を後回しにすると、1 つのパスワードが漏れただけで、全部のサービスに入られる状態になります。多要素認証は SSO と同時に始めます。
つなげないサービスを放っておく
SSO に対応していないサービスが一覧から抜けると、そのサービスのアカウントだけが退職後も残ります。つなげないサービスは、一覧で個別に管理し、退職時の手順に入れます。
管理者を 1 人にする
ID の管理の仕組みの管理者が 1 人だけだと、その人が不在のときに設定を直せません。管理者は 2 人以上にし、権限の範囲も決めておきます。
