SAML【情報処理安全確保支援士試験 令和6年度 春期 午前Ⅱ 問4】
情報処理安全確保支援士試験 令和6年度 春期 午前Ⅱ 問4
【出典：情報処理安全確保支援士試験 令和6年度 春期 午前Ⅱ（一部、加工あり）】
標準化団体OASISが、Webサイトなどを運営するオンラインビジネスパートナー間で認証、属性及び認可の情報を安全に交換するために策定してものはどれか。
ア SAML
イ SOAP
ウ XKMS
エ XML Signature
今回は、認証連携の仕組みとして非常に重要な「SAML（Security Assertion Markup Language）」について、じっくりと解説していきます。
SAMLは、IDaaS（Identity as a Service）やクラウドサービスの普及に伴い、その重要性が増している技術です。試験対策としてはもちろん、実務においても必ず知っておきたい概念ですので、ぜひ最後までお付き合いください！
SAMLって何？
SAMLは、「Security Assertion Markup Language」の頭文字をとったもので、異なるシステム間でユーザー認証情報や属性情報を安全にやり取りするためのXMLベースの標準規格です。
ちょっと難しそうに聞こえるかもしれませんが、簡単に言うと「一度ログインすれば、いろんなサービスにログインできる仕組みを実現するための共通言語」だと思ってください。
私たちが普段使っているWebサービスでは、サービスごとにIDとパスワードを入力してログインするのが一般的ですよね。でも、複数のサービスを使う場合、それぞれにログインするのは手間がかかりますし、パスワードの管理も大変です。
そこでSAMLの出番です！SAMLを使うことで、例えば会社のポータルサイトに一度ログインすれば、そこからグループウェアや勤怠管理システム、経費精算システムなど、様々なサービスに再ログインすることなくアクセスできるようになります。これを「シングルサインオン（SSO）」と呼びます。
SAMLが生まれた背景と経緯
なぜSAMLのような規格が必要になったのでしょうか？その背景には、主に以下の2つの変化があります。
- 企業システムの複雑化・分散化
以前は社内ネットワークに閉じたシステムが主流でしたが、企業のグローバル化やM&A、グループ会社の増加などにより、システムが地理的に分散し、かつ多様なシステムが混在するようになりました。 - クラウドサービスの普及
Salesforce、Microsoft 365、Google Workspaceなど、様々なクラウドサービスがビジネスに活用されるようになりました。これらのサービスは社外に存在するため、従来の社内認証基盤との連携が課題となりました。
こうした状況の中で、各サービスがそれぞれ独自に認証連携の仕組みを構築するのは非効率的で、セキュリティリスクも高まります。そこで、業界標準の認証連携プロトコルとして、OASIS（Organization for the Advancement of Structured Information Standards）によってSAMLが策定されました。SAML 1.0が2002年に公開され、その後、現在の主流であるSAML 2.0が2005年に策定されました。
SAMLの登場人物と認証の流れ
SAMLにおけるシングルサインオンの仕組みを理解するために、主要な登場人物と認証の流れを見ていきましょう。
SAMLには主に以下の3つの役割があります。
- ユーザー（Principal）
サービスを利用する私たち自身です。 - IDプロバイダ（IdP: Identity Provider）
ユーザーの認証を行うエンティティです。ユーザー名とパスワードの認証を行い、認証に成功するとSAMLアサーション（認証情報）を発行します。企業の認証基盤（Active Directoryなど）と連携するIDaaSなどがこれにあたります。 - サービスプロバイダ（SP: Service Provider）
ユーザーが利用したいサービスを提供するエンティティです。SAMLアサーションを受け取り、ユーザーを認証してサービスへのアクセスを許可します。クラウドサービスなどがこれにあたります。
では、具体的な認証の流れを見ていきましょう。SAMLの認証フローには、主に以下の2つのタイプがあります。
- IdP-initiated SSO（IDプロバイダ起点）
- ユーザーがまずIDプロバイダ（例えば会社のポータルサイト）にログインします。
- IDプロバイダの画面から、利用したいサービス（サービスプロバイダ）へのリンクをクリックします。
- IDプロバイダは、ユーザーが認証済みであることを示すSAMLアサーションを生成し、ユーザーのWebブラウザ経由でサービスプロバイダへ送信します。
- サービスプロバイダはSAMLアサーションを検証し、正しければユーザーを認証してサービスへのアクセスを許可します。
- SP-initiated SSO（サービスプロバイダ起点）
- ユーザーが直接サービスプロバイダのURLにアクセスします。
- サービスプロバイダは、ユーザーが未認証であることを認識し、IDプロバイダへの認証要求（SAMLリクエスト）を生成し、ユーザーのWebブラウザ経由でIDプロバイダへリダイレクトします。
- IDプロバイダは認証要求を受け取り、ユーザーにログインを促します。
- ユーザーがIDプロバイダで認証に成功すると、IDプロバイダはSAMLアサーションを生成し、ユーザーのWebブラウザ経由でサービスプロバイダへ送信します。
- サービスプロバイダはSAMLアサーションを検証し、正しければユーザーを認証してサービスへのアクセスを許可します。
どちらのフローでも、ユーザーは一度認証すれば、複数のサービスにログインできるのがSAMLの大きなメリットです。
SAMLの主な構成要素
SAMLの認証を支える重要な要素がいくつかあります。
- SAMLアサーション（SAML Assertion）
ユーザーが認証されたことを証明する情報や、ユーザーの属性情報（氏名、メールアドレス、所属部署など）をXML形式で記述したものです。デジタル署名が付与されており、改ざんやなりすましを防ぎます。 - SAMLプロトコル（SAML Protocol）
SAMLメッセージのやり取りの形式を定義します。認証要求や認証応答などがこれにあたります。 - バインディング（Binding）
SAMLメッセージをWebブラウザやHTTPプロトコル上でどのように運ぶかを定義します。HTTP Redirect BindingやHTTP POST Bindingなどがあります。 - プロファイル（Profile）
特定のユースケースにおけるSAMLプロトコルとバインディングの組み合わせを定義します。Web Browser SSO Profileが最も一般的です。
SAMLの課題と対策
SAMLは非常に強力な認証連携の仕組みですが、いくつか課題も存在します。
課題
- 設定の複雑さ
IDプロバイダとサービスプロバイダ双方で、メタデータ（証明書情報やエンドポイントURLなど）の交換や設定が必要になります。この設定が複雑で、誤るとSSOが機能しないことがあります。 - モバイルアプリへの対応
Webベースの認証連携に特化しているため、スマートフォンアプリのようなネイティブアプリケーションでのSSO実装には追加の考慮が必要です。近年ではOpenID Connectがモバイルアプリでの利用に適しているとされています。 - セッション管理
SSOが実現されても、各サービスでのセッション管理はSAMLの範疇外です。SP側でのセッションタイムアウト設定なども考慮が必要です。 - リプレイトラブル（Replay Attack）対策
盗聴されたSAMLアサーションを再利用されるリスクがあります。これに対しては、アサーションの有効期限を短くしたり、一度しか利用できないようNonce（使い捨ての乱数）を利用するなどの対策が必要です。
対策
- IDaaSの活用
多くのIDaaSサービスがSAMLをサポートしており、SAML設定のGUIを提供することで設定の複雑さを軽減しています。また、既製のテンプレートが用意されていることも多く、導入をスムーズに進められます。 - 詳細なドキュメントとテスト
設定ミスを防ぐため、IDプロバイダとサービスプロバイダのそれぞれのドキュメントを熟読し、入念なテストを行うことが不可欠です。 - OpenID Connectとの連携
モバイルアプリなど、SAMLでは対応が難しいケースでは、OpenID Connectのような別の認証プロトコルとの連携も検討します。IDaaSが複数の認証プロトコルに対応している場合は、それらを組み合わせることで柔軟な認証基盤を構築できます。 - セキュリティベストプラクティスの適用
デジタル署名、暗号化、有効期限の設定など、SAMLのセキュリティ機能と、TLS/SSLによる通信の暗号化を適切に組み合わせることで、より安全な認証連携を実現します。
今後の動向
SAMLは依然として多くの企業システムで利用されている重要な規格ですが、近年ではRESTful APIとの相性が良いOpenID Connect（OIDC）の利用も増えています。特に、コンシューマ向けサービスやモバイルアプリケーションではOIDCが主流になりつつあります。
しかし、SAMLが持つエンタープライズ向けの豊富な機能や、既存の多くのシステムがSAMLをサポートしているという事実から、SAMLの重要性がすぐに失われることはないでしょう。むしろ、SAMLとOIDCが共存し、それぞれの得意分野で活用されていくと予想されます。
情報処理安全確保支援士やネットワークスペシャリストを目指す皆さんにとっては、SAMLとOpenID Connectの両方を理解し、それぞれの特性やユースケースに応じて適切なプロトコルを選択・設計できる知識が求められるでしょう。
まとめ
今回はSAMLについて、その定義から背景、仕組み、課題、そして今後の動向まで、幅広く解説しました。
- SAMLは、異なるシステム間で認証情報を安全にやり取りするためのXMLベースの標準規格であり、シングルサインオン（SSO）を実現する上で不可欠な技術です。
- IDプロバイダ（IdP）とサービスプロバイダ（SP）の連携により、一度の認証で複数のサービスにアクセスできるようになります。
- 設定の複雑さなどの課題はあるものの、IDaaSの活用や適切なセキュリティ対策によって安全かつ効率的な認証連携が可能です。
SAMLは、クラウドサービスが当たり前になった現代において、企業のセキュリティと利便性を両立させる上で非常に重要な役割を担っています。この知識は、資格取得はもちろんのこと、今後のキャリアにおいてもきっと役立つはずです。
さて、問題の解説です
標準化団体OASISが、Webサイトなどを運営するオンラインビジネスパートナー間で認証、属性及び認可の情報を安全に交換するために策定してものはどれか。
ア SAML
イ SOAP
ウ XKMS
エ XML Signature
ア SAML
正解です。
- SAML は、認証や属性情報などのセキュリティ情報（アサーション）をXML形式でやり取りするためのフレームワークです。
- OASISが標準化しており、異なるドメイン間でシングルサインオン（SSO）を実現するための仕組みとして広く使われています。
- 例えば、IDプロバイダ（IdP）とサービスプロバイダ（SP）間でユーザーのログイン状態を共有できます。
- 特に、B2Bやクラウドサービス間の認証連携などに活用されます。
イ SOAP
誤りです。
- SOAP は、Webサービス間でメッセージをやり取りするための通信プロトコルです。
- 認証や認可というより、リモートの手続きを呼び出すための汎用的な枠組みです。
- OASISも関わっていますが、この問題の文脈（認証・属性・認可）には直接該当しません。
ウ XKMS
誤りです。
- XKMS は、公開鍵の管理や登録、取得をXMLベースで行うための仕様です。
- 認証基盤（PKI）に関係しますが、SAMLのように属性や認可情報の交換を目的としたものではありません。
エ XML Signature
誤りです。
- XML Signature は、XMLデータに電子署名を付与するための仕様です。
- データの改ざん検知や署名者の認証には使えますが、属性や認可情報の交換自体は行いません。
