SSO（シングルサインオン）は、一度の認証を使って複数のアプリケーションへアクセスする仕組みです。利用者がサービスごとにログインを繰り返す負担を減らすために使われます。
ただし、SSOを導入しただけで、すべてのサービスのアカウント作成・削除や権限管理が完了するわけではありません。企業で検討するときは、ログインをまとめる範囲と、残る管理作業を分けて整理しましょう。
認証する仕組みと使うサービスを連携させる
SSOには複数の方式があります。ここでは、認証を担うIdP（Identity Provider）と、利用するアプリケーションを連携させる方式を中心に説明します。
Microsoftの公式資料では、IdPが利用者を認証し、その利用者の情報をアプリケーションへ伝える流れが示されています。SAMLやOpenID Connectは、このような連携に用いる方式です。Microsoft「SSOとは」
たとえば、社員が社内の認証基盤でログインし、連携済みの業務アプリへ移る場面を考えます。アプリ側が連携に対応し、利用者に必要なアクセスが割り当てられていることが前提です。認証の有効期間や追加確認の方針によって、再度の認証を求める場合もあります。
ログイン・アカウント・権限は分けて考える
導入範囲を決めるときは、次の三つを別々に確認すると見落としを防ぎやすくなります。
| 確認する対象 | 問いの例 |
|---|---|
| 認証 | この利用者であることを、どこで確認するか |
| アカウントの管理 | 入社・異動・退職時に、サービス側の登録をどう変えるか |
| 権限 | ログインした後、どのデータや操作を許すか |
アカウントの作成や変更などは、プロビジョニングと呼ばれる管理の対象です。Microsoftも、利用者のライフサイクルに伴う管理を説明しています。Microsoft「プロビジョニングとは」
具体例として、認証基盤からログインできても、アプリ側に利用者が登録されていなければ使えない構成を考えられます。逆にアカウントが存在しても、必要な業務権限がなければ目的の操作はできません。自社の各サービスで、どの仕組みがどこまで連携しているかを確かめてください。
導入前にアプリ一覧を作る
最初から全サービスをまとめようとせず、対象を一覧化します。本記事では次の項目をそろえることを勧めます。
- サービス名と業務上の用途。
- 利用者と管理担当。
- 対応する認証方式と利用プランの条件。
- 現在のログイン方法。
- アカウント作成・停止の方法。
- アプリ側に残る権限設定。
「SSO対応」と書かれていても、利用中のプランや構成で使えるかは個別に確認が必要です。対応していないサービスは、対象外の理由と今後の扱いを残します。アプリへのリンクを一か所に並べるだけで、認証も連携済みになったとは判断しません。
停止時と例外利用者の扱いも確認する
導入試験では、通常の社員がログインできることに加え、利用対象外の人、権限が異なる人、停止したアカウントについて、期待する結果になるかを確認します。
認証基盤や連携先に障害が起きた場合の問い合わせ先、業務への影響、管理者の復旧手段も整理してください。例外的なアカウントを作る場合は、管理する担当と見直し条件を残します。
SSOは認証をまとめる仕組みであり、あらゆる不正アクセスを自動で防ぐ保証ではありません。認証強化、権限、記録などを含む全体像は、クラウドのセキュリティ対策も参考になります。
一つのサービスで運用まで試す
試行では、ログインだけでなく、登録から異動・停止まで担当者が説明できるかを確かめます。誰のどの作業が減り、どの作業が残るかを確認してから範囲を広げる方法があります。
まずは利用頻度の高い一つのサービスについて、認証・アカウント・権限の担当を表にしてください。認証を含む基盤運用の相談は、インフラサポートをご覧いただけます。