多要素認証・MFAまで含めた基本解説
1. この資料のゴール
この資料では、SSO、SAML、多要素認証・MFAの関係を、できるだけわかりやすく整理します。
最初に結論です。
| 用語 | ひと言でいうと |
|---|---|
| SSO | 1回ログインすれば、複数のサービスを使える仕組み |
| SAML | SSOを実現するための共通ルール |
| MFA | パスワードに加えて、もう1つ以上の認証を追加する仕組み |
この3つは別々に考えるよりも、セットで理解することが重要です。
SSOだけでは便利になりますが、ログイン情報が漏れたときの影響も大きくなります。
そのリスクを抑えるために、MFAを組み合わせます。
そして、SSOを実現する代表的な仕組みのひとつがSAMLです。
2. まず全体像をつかむ
SSO、SAML、MFAの関係は、次のように考えるとわかりやすいです。
ユーザー
↓
SSOのログイン画面
↓
MFAで追加確認
↓
SAMLなどの仕組みで各サービスへ連携
↓
メール、チャット、勤怠、経費精算、Zoomなどを利用
ホテルで例えると
| 用語 | ホテルでの例え |
| SSO | ホテルのフロント。1回チェックインすれば、客室・ジム・ラウンジなどを使える |
| SAML | フロントと各施設が使う共通の確認ルール |
| MFA | ルームキーに加えて、暗証番号や本人確認を追加する仕組み |
つまり、SSOは「入口をまとめる仕組み」、SAMLは「入口と各サービスをつなぐための共通ルール」、MFAは「入口の安全性を高める追加の鍵」です。
3. SSOとは何か
SSOは、Single Sign-On の略です。
日本語では「シングルサインオン」と呼ばれます。
簡単に言うと、一度ログインすれば、複数のサービスに再ログインせず利用できる仕組みです。
4. SSOがない場合の問題
SSOがない会社では、サービスごとにログインが必要になります。
たとえば、次のような状態です。
- メールにログイン
- 勤怠システムにログイン
- 経費精算システムにログイン
- TeamsやSlackにログイン
- Zoomにログイン
- 社内ポータルにログイン
それぞれのサービスでIDとパスワードが必要になると、次のような問題が起きます。
| 問題 | 内容 |
| パスワードの使い回し | 1つ漏れると、複数サービスに不正ログインされる危険がある |
| パスワード忘れ | ヘルプデスクへのリセット依頼が増える |
| 退職者管理の漏れ | サービスごとに停止作業が必要になり、削除漏れが起きやすい |
| セキュリティ低下 | 付箋やメモ帳にパスワードを書くなど危険な運用になりやすい |
SSOは、こうした問題を減らすために導入されます。
5. SSOがある場合のメリット
SSOを導入すると、ログインの入口をまとめることができます。
利用者側のメリット
- 何度もログインしなくてよい
- 覚えるパスワードが減る
- 業務開始がスムーズになる
管理者側のメリット
- アカウント管理を一元化しやすい
- 退職者の停止処理をまとめやすい
- ログイン履歴を確認しやすい
- パスワードリセット対応を減らせる
セキュリティ面のメリット
- パスワードの使い回しを減らせる
- 不審なログインを検知しやすい
- MFAと組み合わせることで防御力を高められる
ただし、SSOは便利な反面、ログインの入口が1か所に集中するという特徴があります。
そのため、SSOを導入する場合は、MFAとの併用が非常に重要です。
6. SSOの登場人物
SSOを理解するうえで、最低限覚えておきたい登場人物は2つです。
| 略語 | 正式名称 | 役割 | 具体例 |
| IdP | Identity Provider | 本人確認をする側 | Microsoft Entra ID、Google Workspace、Okta |
| SP | Service Provider | 実際に使うサービス側 | Slack、Zoom、Salesforce、Box、学内システム |
わかりやすい例え
| 用語 | 例え |
| IdP | 役所や身元保証人 |
| SP | お店や施設 |
IdPが「この人は本人です」と証明し、SPはその証明を信じてログインを許可します。
7. SAMLとは何か
SAMLは、Security Assertion Markup Language の略です。
簡単に言うと、SSOを実現するために、IdPとSPがやり取りする共通ルールです。
SSOを実現するには、IdPとSPが次のような情報を安全にやり取りする必要があります。
- このユーザーは誰なのか
- 認証は成功したのか
- どのサービスへのアクセスを許可するのか
- 情報が改ざんされていないか
SAMLでは、これらの情報を署名付きの証明書のような形でやり取りします。
この証明情報を SAMLアサーション と呼びます。
8. SAMLのログインの流れ
SAMLを使ったSSOの流れは、次のようになります。
1. ユーザーがサービスにアクセスする
2. サービス側が「本人確認が必要」と判断する
3. ユーザーはIdPのログイン画面に移動する
4. IdPでID・パスワードやMFAによる認証を行う
5. IdPが「この人は本人です」という証明情報を発行する
6. サービス側がその証明情報を確認する
7. 問題なければログイン完了
例:SlackにSAML SSOでログインする場合
| 手順 | 内容 |
| 1 | ユーザーがSlackにアクセスする |
| 2 | SlackがIdPへリダイレクトする |
| 3 | ユーザーがMicrosoft Entra IDなどでログインする |
| 4 | 必要に応じてMFAを実施する |
| 5 | IdPがSAMLアサーションを発行する |
| 6 | Slackがその情報を確認する |
| 7 | Slackへのログインが完了する |
9. SAMLの特徴
SAMLには、次のような特徴があります。
| 項目 | 内容 |
| 主な用途 | 企業向けSaaS、学内システム、業務システム |
| 形式 | XMLベース |
| 強み | 実績が豊富で、企業システムで広く使われている |
| 注意点 | 設定項目が多く、証明書や属性情報の管理が必要 |
SAMLは「古い」と言われることもありますが、企業や教育機関の業務システムでは今でも多く利用されています。
10. SAML、OAuth、OIDCの違い
SSOの話で混同されやすいものに、OAuthやOIDCがあります。
| 用語 | 主な役割 | ひと言でいうと |
| SAML | 認証 | この人は誰かを確認する |
| OAuth | 認可 | このアプリに何を許可するかを決める |
| OIDC | 認証 | OAuthをベースにしたログインの仕組み |
特に重要なのは、認証と認可は違うという点です。
| 区分 | 意味 |
| 認証 | あなたは誰ですか? |
| 認可 | あなたは何をしてよいですか? |
この違いを混同すると、設計ミスやセキュリティ事故につながる可能性があります。
11. MFAとは何か
MFAは、Multi-Factor Authentication の略です。
日本語では「多要素認証」と呼ばれます。
簡単に言うと、パスワードだけでなく、別の確認方法も組み合わせて本人確認をする仕組みです。
たとえば、次のようなものがあります。
- パスワード
- スマートフォンの認証アプリ
- SMSコード
- 指紋認証
- 顔認証
- ICカード
- ハードウェアキー
- パスキー
12. なぜSSOにMFAが必要なのか
SSOは便利ですが、1つ大きな注意点があります。
SSOでは、1回ログインすれば複数のサービスにアクセスできます。
つまり、SSOのアカウントが乗っ取られると、複数のサービスへ一気に不正アクセスされる危険があります。
そのため、SSOを導入する場合は、MFAを組み合わせることが重要です。
SSOだけ
便利だが、アカウントが漏れたときの影響が大きい
SSO + MFA
便利さを保ちながら、不正ログインのリスクを下げられる
SSOとMFAは、実務上セットで考えるべきです。
13. 認証要素の3分類
MFAで使われる認証要素は、大きく3つに分かれます。
| 分類 | 内容 | 例 |
| 知識要素 | 本人が知っているもの | パスワード、PIN、秘密の質問 |
| 所持要素 | 本人が持っているもの | スマートフォン、ICカード、ハードウェアキー |
| 生体要素 | 本人自身の特徴 | 指紋、顔、虹彩 |
MFAでは、これらのうち異なる種類の要素を2つ以上組み合わせることが重要です。
14. 2段階認証と多要素認証の違い
ここは非常に間違えやすいポイントです。
| 組み合わせ | 判定 | 理由 |
| パスワード + SMSコード | MFA | 知識要素 + 所持要素 |
| パスワード + 認証アプリ | MFA | 知識要素 + 所持要素 |
| パスワード + 指紋認証 | MFA | 知識要素 + 生体要素 |
| パスワード + 秘密の質問 | MFAとは言いにくい | どちらも知識要素 |
つまり、単に確認が2回あるだけでは不十分です。
重要なのは、異なる種類の要素を組み合わせているかです。
15. よく使われるMFA方式
| 方式 | 評価 | 特徴 |
| SMSコード | △ | 手軽だが、SIMスワップや盗み見に弱い |
| 認証アプリ | ○ | Google Authenticator、Microsoft Authenticatorなど。実用性が高い |
| プッシュ通知 | ○ | スマホに承認通知が届く。便利だが誤承認に注意 |
| FIDO2 / パスキー | ◎ | フィッシング耐性が高く、今後の主流候補 |
| ハードウェアキー | ◎ | YubiKeyなど。強力だが、紛失時の運用設計が必要 |
現在の実務では、認証アプリやプッシュ通知を使うケースが多くあります。
ただし、長期的にはフィッシング耐性の高いパスキーやFIDO2への移行も検討すべきです。
16. MFA疲れ攻撃に注意
プッシュ通知型MFAでは、MFA疲れ攻撃に注意が必要です。
これは、攻撃者が不正ログインを何度も試み、ユーザーのスマートフォンに認証通知を連続で送る攻撃です。
ユーザーが面倒になって、誤って「承認」を押してしまうと、不正ログインが成立する可能性があります。
対策
| 対策 | 内容 |
| 番号マッチング | ログイン画面に表示された番号を、スマホ側で入力させる |
| 不審な通知を承認しない教育 | 身に覚えのない通知は拒否するよう周知する |
| 条件付きアクセス | 不審な場所や端末からのログインを制限する |
| パスキー移行 | プッシュ承認に依存しない認証方式へ移行する |
17. 理想的なログインの流れ
SSO、SAML、MFAを組み合わせると、次のような流れになります。
1. 社員がPCを開く
2. Microsoft Entra IDなどのIdPにログインする
3. パスワードを入力する
4. MFAで追加確認する
5. SAMLなどの仕組みで各サービスにログイン連携する
6. メール、チャット、勤怠、経費精算などを利用する
7. 退職時はIdPアカウントを停止し、各サービスへのアクセスを遮断する
このように、ログインの入口を一元化することで、利便性と管理性を高めることができます。
18. よくある誤解
Q1. SSOを入れればパスワードを覚えなくてよいのですか?
いいえ。
IdPにログインするためのパスワードは必要です。
ただし、サービスごとに多くのパスワードを覚える必要は減ります。
その代わり、IdPのアカウントは非常に重要になるため、MFAで強く保護する必要があります。
Q2. SSOを入れればセキュリティは必ず強くなりますか?
SSO単体では、必ずしも強くなるとは言えません。
SSOはログインを便利にする仕組みですが、ログインの入口が集中します。
そのため、MFA、条件付きアクセス、ログ監査、退職者管理と組み合わせて初めてセキュリティ効果が高まります。
Q3. SAMLとOAuthは同じですか?
違います。
SAMLは主に認証の仕組みです。
OAuthは主に認可の仕組みです。
| 用語 | 役割 |
| SAML | あなたが誰かを確認する |
| OAuth | アプリにどこまで権限を与えるか決める |
| OIDC | OAuthをベースにしたログインの仕組み |
Q4. 中小企業にSSOは必要ですか?
必要性は高いです。
特に、次のような会社では効果があります。
- 利用しているクラウドサービスが多い
- 退職者アカウントの削除漏れが不安
- パスワード使い回しが多い
- ヘルプデスクのパスワードリセット対応が多い
- 社員のセキュリティ意識にばらつきがある
中小企業ほど、管理者の人数が限られているため、SSOによる一元管理は有効です。
19. 導入時のチェックリスト
SSOやSAMLを導入する際は、次の項目を確認します。
| チェック項目 | 確認内容 |
| IdPの選定 | Microsoft Entra ID、Google Workspace、Oktaなど、何を中心にするか |
| SaaS側の対応 | 利用中のサービスがSAML SSOに対応しているか |
| 契約プラン | SAML SSOが上位プラン限定になっていないか |
| MFAの必須化 | 全社員にMFAを適用できるか |
| 例外運用 | MFA除外アカウントを作りすぎていないか |
| 退職者対応 | IdP停止で各サービスの利用も止まる設計になっているか |
| 緊急用アカウント | IdP障害時に備えたブレークグラスアカウントがあるか |
| ログ監査 | 誰が、いつ、どこからログインしたか確認できるか |
| 端末管理 | 会社支給端末と個人端末の扱いを整理しているか |
| パスキー対応 | 将来的にパスキーやFIDO2へ移行できるか |
20. 実務で特に注意すべきポイント
1. SSO対応は有料プラン限定の場合がある
一部のSaaSでは、SAML SSOを利用するために上位プランの契約が必要です。
いわゆる「SSO税」と呼ばれる問題です。
導入前に、必ず契約プランと追加費用を確認してください。
2. 退職者アカウントの停止設計が重要
SSOの大きなメリットは、アカウント停止を一元化できる点です。
ただし、SaaS側にローカルアカウントが残っていたり、SSOを迂回できるログイン方法が残っていたりすると、退職者がアクセスできてしまう可能性があります。
退職時には、次の確認が必要です。
- IdPアカウントの無効化
- SaaS側のアカウント状態
- ローカルログインの有無
- 管理者アカウントの棚卸し
- 共有アカウントの有無
3. 緊急用アカウントを用意する
IdPやMFAに障害が起きると、管理者自身もログインできなくなる可能性があります。
そのため、緊急時用の管理アカウント、いわゆるブレークグラスアカウントを用意します。
ただし、これは非常に強い権限を持つため、次のような管理が必要です。
- 通常業務では使わない
- 強力なパスワードを設定する
- 利用時に通知や監査ログを残す
- 保管方法を厳格にする
- 定期的に存在と利用履歴を確認する
21. まとめ
最後に、重要ポイントを整理します。
| 用語 | まとめ |
| SSO | 1回のログインで複数サービスを使える仕組み |
| SAML | SSOを実現するための代表的な共通ルール |
| MFA | パスワード以外の要素を追加して安全性を高める仕組み |
| IdP | 本人確認を行う側 |
| SP | 実際に利用するサービス側 |
| OIDC | 現代的なWebアプリやスマホアプリでよく使われる認証方式 |
| OAuth | アプリに権限を与えるための認可の仕組み |
SSOは、単なる便利機能ではありません。
正しく設計すれば、アカウント管理、退職者管理、ログ監査、セキュリティ強化に大きく役立ちます。
ただし、SSOだけでは不十分です。
MFA、条件付きアクセス、ログ監査、緊急時対応まで含めて設計することが重要です。
ポイント
- SSOは、1回ログインすれば複数サービスを使える仕組み
- SAMLは、SSOを実現するための代表的な共通ルール
- MFAは、SSOの集中リスクを抑えるために必須
- SSO導入時は、退職者管理・例外運用・緊急用アカウントまで設計する
- 将来的には、パスキーやFIDO2への移行も検討する
