# シングルサインオンとは

一度の本人確認を利用して複数のサービスにログインする仕組みです。認証と権限管理の違い、退職時の停止、共通アカウントの不正利用や障害への備えを解説します。

## シングルサインオンとは

シングルサインオン（Single Sign-On、SSO）は、一度の本人確認を利用し、複数のサービスにログインする仕組みです。例えば社員が共通の認証画面で本人確認した後、メールや文書共有の画面にアクセスするたびに別々のパスワードを入力する手間を削減できます。対象のサービスは、事業者のクラウド上で稼働するソフトウェアをネットワーク経由で利用する[SaaS（Software as a Service）](https://csrc.nist.gov/glossary/term/software_as_a_service)に限らず、社内のシステムも含みます。受付で本人確認を完了し、許可された部屋に入室する流れに類似しています。ただし、どの部屋に入室できるかは別に決定する必要があります。SSOの代表的な方式では、共通の画面で本人を確認する仕組みである認証基盤が、[本人確認の結果を各サービスへ伝達し、サービス側がその結果を検証します](https://pages.nist.gov/800-63-4/sp800-63c.html)。同じパスワードを複数のサービスに登録するだけではSSOではありません。SSOは認証の共通化であり、複数の要素で本人を確認する多要素認証とは異なります。

![利用者が認証基盤で一度本人確認し、認証基盤がその結果をメールと文書共有に伝達する例。](https://media.marketing.kdotdev-tunnel.org/glossary-single-sign-on-ed3e1cf44643f5c7217936f71acb633e1fbbef1091c14beb83ff83e7ae7f154c.png)

## 認証を共通化しても利用先の権限は別に管理する

例えば、認証基盤は、複数のサービスで共通に利用する利用者ごとの共通アカウントで本人を確認し、その結果をメールや文書共有などのサービスへ伝達します。認証基盤から認証結果を受信し、利用者が実際に操作するメールや文書共有などのサービスを利用先と呼びます。利用権限は利用先が判断します。メールと文書共有に同じ利用者でログインできても、文書を閲覧・編集できるかは文書共有側の設定次第です。

SSOを設定した後も、利用先ごとに次の点を確認します。[SSOの設定とは別に利用者登録が必要か](https://learn.microsoft.com/en-us/entra/identity/app-provisioning/user-provisioning)、権限をどう付与するか、既存の個別ログインを併用できるか、再認証を求める条件は何かです。

![認証基盤が利用者本人を確認し、メールと文書共有は認証結果を検証したうえで、それぞれの利用権限や閲覧・編集の権限を判断します。](https://media.marketing.kdotdev-tunnel.org/glossary-single-sign-on-36c4df7037358ebe0e3fb16c7357f6115ac6c34141fd2f42070b7c6c588cadf3.png)

## SSOと多要素認証の役割

[多要素認証](https://www.cisa.gov/mfa)はパスワードのような知識と端末の所持など、異なる種類の要素を併用して本人を確認する方法です。SSOは多要素認証を使わず、パスワードなど1種類の要素だけでも成立します。共通アカウントが不正利用されると連携する複数のサービスへ影響が拡大するおそれがあるため、共通アカウントには多要素認証を設定します。

多要素認証でも[手入力のワンタイムコードは偽の認証画面から攻撃者に中継される可能性があります](https://pages.nist.gov/800-63-4/sp800-63b.html)。対応する端末とサービスがある場合は、登録先のサイトやアプリに対応して認証する[パスキー](https://developers.google.com/identity/passkeys)も選択肢です。利用する方法が多要素認証に該当するか、サービスの仕様と設定を確認します。

[ゼロトラスト](https://csrc.nist.gov/pubs/sp/800/207/final)はネットワーク上の場所などだけで信頼せず、利用者や端末と対象の資源に応じてアクセスを判断する考え方です。SSOは認証を共通化する仕組みであり、ゼロトラストと同義ではありません。

![多要素認証を利用する例。認証基盤内でパスワードと登録端末の所持を併用して本人確認し、結果をメールと文書共有に伝達します。SSO自体に多要素認証は必須ではありません。](https://media.marketing.kdotdev-tunnel.org/glossary-single-sign-on-9a14305f9ab24de8f586496fcc71a9d4b7e05af500fe37a927beb44f713d4309.png)

## どのサービスからSSOを適用するか

SSOの適用は、機密情報や管理者権限を扱うサービスから開始します。その中でも、SSO連携の動作、共通アカウントの停止、利用先のアクセス停止、障害時の復旧を利用する組織が事前に検証できるサービスを先にします。共通アカウントが不正利用されると、そのアカウントに権限のある複数のサービスへ影響が拡大する可能性があるためです。

メール、管理画面、文書共有などを優先候補にし、対応する認証方式と利用プランに連携機能が含まれるかを確認します。

既存のメールや文書共有のアカウントと共通アカウントを対応づける条件、重複や不一致がある場合の扱いも確認します。対応に誤りがあると別人のデータに接続したり、本人が従来のデータを利用できなくなったりするおそれがあります。

少数の利用者でSSOへ移行し、元のデータと権限を確認してから対象を拡大します。サービスごとの権限と操作履歴を確認する担当者も決定します。

切り替え時は、管理担当による設定と利用者への案内に工数がかかります。連携機能に追加料金が必要な場合もあります。

移行後は、アカウントの棚卸しと、連携エラーの調査や認証手段の再登録が発生したときの対応に工数がかかります。

機密情報や他サービスとの連携がなく、短期間だけ試用するツールなら、SSOを優先せず、管理担当が各サービスでアカウントを個別に管理する選択肢もあります。その場合も試用の終了日、担当者、取扱可能な情報の範囲、ログインの保護とアカウントの停止・削除手順を決定し、終了時にアカウントを停止します。

![同じ利用者の共通アカウントと既存サービスのアカウントを対応づけ、少数の利用者で移行し、本人のデータと権限を確認してから、移行対象の利用者の範囲を拡大する流れ。](https://media.marketing.kdotdev-tunnel.org/glossary-single-sign-on-f7cf38201dd03ab60de176959f9d3eb11630a3a88ee54e3d0168900c86fb71aa.png)

## 退職者の各サービスへのアクセスは共通アカウントの停止だけで無効化できるか

共通アカウントを停止しても、各サービスのアカウントやログイン状態がすべて直ちに停止するとは限りません。認証基盤と利用先はそれぞれ別にログイン状態を維持する場合があり、[利用先が発行したログイン状態は、利用先で無効化する必要がある場合があります](https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access)。

退職時に停止すべきサービスと権限を把握できるよう、入社時と異動時の登録も管理します。入社時は必要なサービスに利用者を登録し、役割に応じた権限を付与します。異動時は新規の権限の追加だけでなく、不要になった権限も削除します。

退職時は共通アカウントの停止とともに、各サービスのログイン状態、利用者の権限、SSOを経由しない個別ログインの残存を確認します。本人の資格情報を利用する自動処理があれば、業務を継続できるよう引継ぎと停止の必要性も確認します。

[Microsoft Entra IDの自動プロビジョニング](https://learn.microsoft.com/en-us/entra/identity/app-provisioning/how-provisioning-works)のように、対象と設定に応じて利用者の停止を連携先へ反映する機能もあります。SSOを設定しただけで登録や停止が自動的に連携されるわけではないため、対象のサービスと反映結果を確認します。

![共通アカウントを停止した後も、各サービスにログイン状態・権限・個別ログインが残存していないか確認します。共通アカウントの停止だけで各サービスの停止が自動的に完了するとは限りません。](https://media.marketing.kdotdev-tunnel.org/glossary-single-sign-on-3996660929a995b36b152020caa2b84a69f64ec6f07be9baf2beeda4d62e31b9.png)

## 不正利用と障害に備える

共通アカウントが第三者に利用された疑いがあるときは、管理担当が正規の管理画面でアカウントを停止します。各サービスで可能な範囲で[ログイン状態を無効化](https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access)し、個別ログインを停止して反映を確認します。自社で停止できない場合は利用先へ連絡します。アクセス権のあったサービスごとに、閲覧・変更の履歴や設定変更を調査します。

認証基盤が停止すると新たにSSOでログインする必要があるサービスを利用できないことがあります。利用中のログイン状態や各サービスへの影響は設定と障害の範囲によって異なります。メールや連絡ツールも同じ認証基盤を利用する場合に備え、代替の連絡先を認証基盤なしで参照できる場所に準備します。

重要なサービスでは、通常の管理者がアクセスできなくなったときの緊急用アカウントを準備できるか、利用先ごとに確認します。緊急用アカウントが、通常の認証基盤や認証手段に障害が起きても利用できるか、その障害時に何を操作できるかを確認します。

同じ認証基盤に依存する緊急用アカウントは、その基盤自体の障害時には利用できない場合があります。別の認証基盤や個別ログインなどを用意していても、サービス自体の障害時には利用できない場合があります。

例えばMicrosoft Entra IDの[緊急アクセスの案内](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access)では、緊急用アカウントを個人の端末に依存しないフィッシング耐性のある認証手段で保護し、サインインを監視し、定期的にログインと管理操作を検証することを挙げています。認証の要求が緊急時の利用を妨げないかも確認します。

![利用先ごとに緊急時のアクセス手段が通常の認証基盤や認証手段から独立しているかを確認します。次にサービスの稼働と必要な操作の可否を確認します。利用できる手段で操作し、利用できない場合は別の復旧手段を準備します。緊急時のアクセス手段でも多要素認証と利用の監視を維持します。](https://media.marketing.kdotdev-tunnel.org/glossary-single-sign-on-e35225271e40edf79bf1cbad3cf333d14bd75d835322cc01ba0f89090654baf9.png)

本人のスマートフォン紛失は認証基盤全体の障害とは別の問題です。例えばGoogle Workspaceでは、[管理者アカウント用の予備のセキュリティキーや、特権管理者が他の管理者用に生成するバックアップコードを事前に準備します。スマートフォンを紛失した利用者には、ユーザー管理権限を持つ管理者がバックアップコードを生成できます](https://knowledge.workspace.google.com/admin/security/recover-an-account-protected-by-2-step-verification?hl=ja)。本人確認の方法、予備手段の保管先、認証手段の再登録を担当する人を事前に決定します。