SAML(Security Assertion Markup Language)
SAML (Security Assertion Markup Language)
異なる組織間でシングルサインオン(SSO)を実現するXMLベースの認証・認可プロトコル。エンタープライズセキュリティの標準です。
SAML(Security Assertion Markup Language)とは
SAMLは、異なる組織間で安全にシングルサインオン(SSO)を実現するためのXMLベースの認証プロトコルです。 従業員が会社のアカウントで一度ログインするだけで、複数のクラウドアプリケーション(SalesforceやSlackなど)にアクセスできるようにします。アイデンティティプロバイダー(IdP:会社のアカウントシステム)がユーザー認証を行い、サービスプロバイダー(SP:各アプリケーション)がSAMLアサーション(デジタル署名された認証情報)を検証するという信頼関係により、セキュアな連携が実現されます。
ひとことで言うと: 「あなたはこの会社の従業員で、これがあなたの身分証明です」という電子的な証明書を、組織間でやり取りして、複数のシステムへのログインを一本化する仕組みです。
ポイントまとめ:
- 何をするものか: 組織のアイデンティティシステムと複数のクラウドアプリを統合し、シングルサインオンを実現
- なぜ必要か: パスワード管理を一元化し、セキュリティと利便性を両立
- 誰が使うか: 大企業のIT部門、SaaS企業のセキュリティ管理者
なぜ重要か
SAMLがなければ、クラウドアプリケーションが増えるたびに、従業員は新しいパスワードを作成・記憶しなければなりません(パスワード疲労)。SAMLにより、会社のアカウント1つで複数システムにアクセスでき、パスワード管理の負担が大幅に軽減されます。また、企業のセキュリティポリシー(多要素認証、強力なパスワードルールなど)を一元的に適用できるため、セキュリティも向上します。さらに、従業員が退社した時も、会社のディレクトリからアカウントを削除するだけで、すべてのクラウドサービスへのアクセスが自動的に失われます。
仕組みをわかりやすく解説
SAML認証は5つのステップで進行します。(1)ユーザーがアプリにアクセス要求 → (2)アプリ(SP)がユーザーを会社のログインページ(IdP)にリダイレクト → (3)ユーザーが会社のユーザー名・パスワード(や多要素認証)で認証 → (4)会社システムがデジタル署名された「このユーザーは認証済み」というSAMLアサーションを発行し、ユーザーのブラウザ経由でアプリに送信 → (5)アプリがアサーションを検証して、ユーザーをログイン状態にする。
このプロセス全体がセキュアなXML形式で実行され、暗号化と電子署名により、途中で改ざんされたり盗聴されたりするリスクが最小化されます。
適用範囲
SAMLは主にエンタープライズ環境で採用されており、以下の範囲で活用されます:
- 対象組織 — 従業員数100名以上の企業、複数のクラウドアプリを利用する組織
- 対象アプリ — Salesforce、Office 365、Google Workspace、Slack、Jira、Confluenceなど、SAMLをサポートするSaaS
- 地理的範囲 — 特に制限なし。オンプレミスシステムとクラウドの統合を実現
- 業界 — 金融、医療、製造、教育など、セキュリティ要件が高い業界での採用が多い
主な要件
SAMLの実装に際して、組織が遵守すべき主要な要件:
- アイデンティティプロバイダーの設定 — 従業員ディレクトリ(Active Directory、Okta、Azure ADなど)をSAML IdPとして構成
- メタデータ交換 — IdPとSP間でSAMLメタデータ(構成情報)を交換し、信頼関係を確立
- デジタル署名と暗号化 — SAMLアサーションに電子署名し、エンコードして送信
- セッション管理 — ユーザーセッションの有効期限を管理し、ログアウト時にすべてのSP側セッションを終了
- 属性マッピング — IdP側のユーザー属性(部門、役職など)をSP側の属性に対応させる設定
違反した場合
SAMLの不適切な実装や運用上のセキュリティ違反には、以下の種類のリスク・影響があります:
- 認証の失敗による業務停止 — SAMLメタデータが古い、署名キーの更新ミスなどで、ユーザーがアプリにアクセスできなくなる。数千人規模の業務が停止する可能性
- 不正アクセス — SAMLアサーション署名が無効化された、暗号化キーが漏洩した場合、他人が権限を詐称してログイン可能に
- コンプライアンス違反 — SOX法、GDPRなど規制が求める「適切なアクセス制御」を実装していないと見なされ、罰金や是正命令
- 退職者のアクセス残存 — IdPから削除したはずのアカウントが、SPで誤ってアクティブなままだと、退職者が機密データにアクセス可能
- 監査不可能状態 — SAML ログが保全されていないと「誰がいつアクセスしたのか」が追跡できず、インシデント調査ができない
実際の活用シーン
グローバル企業の従業員ポータル 本社(米国)のActive Directoryを中央IdPとし、各地域の支社の従業員がそれぞれの地域のSalesforce、Slackなどに、統一認証でアクセス。本社での退職処理 1つで、全世界のシステムアクセスが失われます。
大学キャンパスシステム 学生が大学のアカウントで一度ログインすれば、図書館システム、学習管理システム、メールなど複数のサービスに自動的にアクセス可能。教授の追加・削除もディレクトリ更新で自動反映。
パートナー企業とのアクセス共有 医療プロバイダーと保険会社が患者情報共有システムをSAMLで連携。各社の従業員が自社のアカウントで相手企業のシステムにアクセス可能(信頼できるパートナー間のみ)。
メリットと注意点
SAMLの大きなメリットは、エンタープライズ環境でのセキュリティと利便性の両立です。一方、注意点は、実装が比較的複雑で、IdPとSP間のメタデータ設定ミスにより認証失敗が起こりうること。また、モバイルアプリではSAMLがサポートされていないことが多く、その場合はOAuth 2.0やAPIキー認証の併用が必要です。
関連用語
- シングルサインオン(SSO) — 1回のログインで複数システムにアクセス可能にする技術
- OAuth 2.0 — モバイルアプリ向けの認可プロトコル。SAML の補完となる
- LDAP — オンプレミスのディレクトリサービス。SAMLのIdPとして使われることが多い
- 多要素認証(MFA) — SAMLと組み合わせて使用される。セキュリティを強化
- フェデレーション — 複数の独立した組織間のアカウント連携。SAML実装の基盤概念
よくある質問
Q: SAMLは何の略か? A: Security Assertion Markup Language(セキュリティ アサーション マークアップ ランゲージ)。「security assertion」は「セキュアな認証情報」という意味です。
Q: OAuth 2.0 との違いは何か? A: SAMLはエンタープライズ(B2B)向け、OAuth 2.0は主にコンシューマー(B2C)向け。また、SAMLはアイデンティティ(「あなたは誰か」)を扱い、OAuth 2.0は認可(「あなたは何ができるか」)を扱います。
Q: SAMLをサポートしていないアプリは? A: 多くのモバイルアプリ、SNS連携ツール、小規模なSaaS。その場合、API キーやシングルサインオンの代替機能を使う必要があります。