SAML 2.0 SSOのセキュリティ

SSO

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

SAML 2.0 SSOは利便性の高い認証連携プロトコルですが、その実装と運用には潜在的なセキュリティリスクが伴います。本記事では、SAML SSOにおける主要な脅威、攻撃シナリオ、およびそれらに対する実践的な対策について解説します。

SAML 2.0 SSOのセキュリティ実践ガイド

脅威モデル

SAML 2.0 SSOのセキュリティは、複数の要素に依存するため、多岐にわたる脅威が存在します。主な脅威は以下の通りです。

  1. 認証アサーションの偽造・改ざん: 信頼されていない主体によって、SAMLアサーションが作成または改ざんされ、不正な認証が行われる脅威です。これにはXML署名ラッピング（XML Signature Wrapping: XSW）攻撃などが含まれます。
  2. 認証アサーションのリプレイ: 攻撃者が有効なSAMLアサーションを傍受し、それを再送信することで不正な認証セッションを確立する脅威です。
  3. 情報漏洩: SAMLアサーションに含まれる個人情報や機密情報が、通信経路上の盗聴や不適切なログ保存によって漏洩する脅威です。
  4. サービス妨害 (DoS): 大量のSAMLリクエストや不正な形式のSAMLリクエストを送信することで、IdPやSPのサービス可用性を低下させる脅威です。
  5. 設定ミス: IdPまたはSPのSAML設定（例: 署名検証の無効化、脆弱なアルゴリズムの使用、有効期限の不適切設定）に起因する脆弱性です。
  6. 鍵・証明書の管理不備: 署名鍵の漏洩、証明書の失効チェック不足、不適切なキーローテーションポリシーによる脅威です。

攻撃シナリオ

SAML SSOにおける代表的な攻撃シナリオとして、XML署名ラッピング（XSW）攻撃とリプレイ攻撃が挙げられます。

XML署名ラッピング (XSW) 攻撃

XSW攻撃は、SAMLレスポンスのXML構造を悪用し、正規の署名を維持しつつ、不正なアサーションを挿入することで行われます。SPが署名検証後に誤ったXML要素をパース・処理してしまう脆弱性を突く攻撃です。

flowchart TD
    U["正規ユーザー"] -->|SSOリクエスト| IDP["IdP: 認証プロバイダ"]
    IDP -->|SAMLレスポンス生成(正規アサーション+署名)| ATK["攻撃者"]
    ATK -->|不正なアサーションを埋め込み| MAL["攻撃者: 不正SAMLレスポンス作成"]
    MAL -->|改ざんSAMLレスポンス送信| SPV["SP: SAMLレスポンス受信"]
    SPV -->|XML署名検証(正規部分)| SPV
    SPV -->|脆弱なXMLパース/アサーション選択| PARSE{"SPのロジック"}
    PARSE --|不正なアサーションを処理| UNAUTH["SP: 不正な認証"]
    UNAUTH -->|不正なユーザーとしてログイン| APP["アプリケーション"]
    APP -->|不正なリソースアクセス| RES["機密リソース"]

リプレイ攻撃

攻撃者は有効なSAMLアサーションを傍受し、そのアサーションの有効期限が切れる前にSPに再送信することで、正規ユーザーとしてログインします。これは、アサーションの有効期限が長すぎる場合や、一意なIDによる再利用チェックが適切に行われていない場合に発生します。

検出/緩和策

1. 厳格なXML署名検証と構造解析

  • 署名対象要素の厳格な指定: SPは、署名されたXML要素のみを信頼し、特にAssertion要素のIDと署名の参照URIが一致していることを確認します。また、信頼できる要素のホワイトリスト方式を採用します。
  • XMLパーサーのセキュアな設定: 外部エンティティ参照（XXE攻撃の原因）を無効化し、メモリ使用量に制限を設けるなど、XMLパーサーのセキュリティ設定を強化します。

2. 脆弱な署名アルゴリズムの排除

  • SHA-1の禁止: SAMLアサーションの署名には、SHA-1のような脆弱なハッシュアルゴリズムの使用を避けるべきです。IdPとSPは、より強力なSHA-256以上のアルゴリズムのみを受け入れるように設定します。

    誤用例（脆弱なアルゴリズム）:

    <ds:SignedInfo>
  <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
  <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
  <ds:Reference URI="#_a72ce790-2e4a-47d3-9097-742a122e2365">
    <ds:Transforms>
      <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
      <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
    </ds:Transforms>
    <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
    <ds:DigestValue>...</ds:DigestValue>
  </ds:Reference>
</ds:SignedInfo>

    安全な代替（推奨アルゴリズム）:

    <ds:SignedInfo>
  <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
  <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
  <ds:Reference URI="#_a72ce790-2e4a-47d3-9097-742a122e2365">
    <ds:Transforms>
      <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
      <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
    </ds:Transforms>
    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
    <ds:DigestValue>...</ds:DigestValue>
  </ds:Reference>
</ds:SignedInfo>

3. リプレイ攻撃対策

  • 有効期間の短縮: SAMLアサーションのNotOnOrAfter属性を可能な限り短く設定し、アサーションの有効期間を限定します（例: 数分以内）。
  • One-Time-Use: OneTimeUse条件を使用し、SPがアサーションを一度しか受け付けないようにします。
  • AssertionIDのキャッシュ: SPは、過去に処理したAssertionIDをキャッシュし、同じIDを持つアサーションの再利用を拒否します。
    • 現場の落とし穴: Replay Cacheの容量とパフォーマンスがボトルネックとなる可能性があります。大規模環境では、分散キャッシュや永続ストレージの検討が必要です。また、厳しすぎる有効期限設定はネットワーク遅延による誤検知（認証失敗）につながる可能性があります。

4. 通信経路とアサーションの暗号化

  • トランスポート層の保護: SAMLメッセージの交換には、必ずTLS 1.2以上のプロトコルを使用し、エンドツーエンドの通信経路を暗号化します。

  • アサーションの暗号化: 機密情報を含むアサーション全体を暗号化します。IdPはEncryptedAssertion要素を使用してアサーションを暗号化し、SPは適切な鍵で復号します。AES-256のような強力な対称鍵暗号アルゴリズムと、RSA-OAEPのような鍵交換アルゴリズムを組み合わせます。

    Python (概念例):

    # SAMLライブラリを使用したアサーション暗号化の概念
# config.py (設定ファイルの一部)
# security = {
#     'requestedAuthnContext': False,
#     'requestedAuthnContextComparison': 'exact',
#     'signMetadata': False,
#     'metadataCacheDuration': None,
#     'logoutRequestSigned': False,
#     'logoutResponseSigned': False,
#     'signAssertion': True, # アサーションに署名
#     'encryptAssertion': True, # アサーションを暗号化
#     'encryptNameId': True,   # NameIDを暗号化
#     'authnRequestsSigned': False,
#     'wantAssertionsSigned': True,
#     'wantMessagesSigned': True,
#     'wantNameIdEncrypted': True,
#     'signatureAlgorithm': 'http://www.w3.org/2001/04/xmldsig-more#rsa-sha256',
#     'digestAlgorithm': 'http://www.w3.org/2001/04/xmlenc#sha256',
#     'blockEncryptionAlgorithm': 'http://www.w3.org/2001/04/xmlenc#aes256-cbc', # AES-256-CBC推奨
#     'keyEncryptionAlgorithm': 'http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p', # RSA-OAEP推奨
# }

5. 証明書の検証と属性フィルタリング

  • 証明書パス検証: IdP/SPの署名証明書は、有効なCAによって発行され、失効していないことをOCSPまたはCRLで確認します。
  • 属性フィルタリング: SPは、SAMLアサーションから必要な属性のみを抽出し、それ以外の不要な属性や予期せぬ属性は破棄します。ホワイトリスト方式で許可する属性を厳密に定義します。

運用対策

1. 鍵/秘匿情報の取り扱い

  • 専用のキー管理システム (KMS/HSM): SAML署名鍵、暗号化鍵、証明書は、専用のKMSまたはハードウェアセキュリティモジュール（HSM）で厳重に管理します。
  • 最小権限の原則: 鍵や証明書へのアクセスは、最小限の担当者とサービスアカウントに限定し、アクセス制御ポリシーを厳格に適用します。
  • 鍵のローテーション: 鍵や証明書は定期的に（例: 1年ごと）ローテーションし、古い鍵を安全に破棄します。緊急時には迅速なローテーションが可能な体制を整えます。
  • 証明書の期限管理: IdPおよびSPは、相互の証明書の有効期限を監視し、期限切れ前に更新作業を完了させます。

2. 監視と監査

  • SAMLイベントログの収集: IdPおよびSPは、SAML認証の成功/失敗、署名検証結果、アサーションID、ユーザー情報など、すべてのSAML関連イベントを詳細にログに記録します。
  • 異常検知とアラート: 認証失敗の多発、同一アサーションIDの複数回使用、無効な署名アルゴリズムの検出など、異常なSAMLイベントをリアルタイムで監視し、アラートを発報します。これらはSIEM (Security Information and Event Management) システムと連携して集約・分析します。
  • 定期的なログレビュー: 定期的にSAML関連ログを監査し、潜在的なセキュリティインシデントや設定ミスを発見します。
    • 現場の落とし穴: 検出遅延を防ぐためには、リアルタイムに近いログ収集と相関分析が必要です。誤検知によるアラート疲れを防ぐため、アラートの閾値やルールをチューニングすることが大切です。

3. 設定管理とパッチ適用

  • メタデータの定期レビュー: IdPとSP間のメタデータ（エンティティID、証明書、エンドポイントURLなど）は、定期的にレビューし、最新かつ正確であることを確認します。
  • 自動化された設定プロビジョニング: 可能であれば、SAML設定のプロビジョニングを自動化し、手動による設定ミスを削減します。
  • セキュリティパッチの適用: SAMLライブラリ、SSOコンポーネント、基盤となるOSやミドルウェアに対して、常に最新のセキュリティパッチを適用します。既知の脆弱性への対策は迅速に行います。

まとめ

SAML 2.0 SSOのセキュリティは、プロトコル設計の理解に基づいた適切な設定、堅牢な鍵管理、そして継続的な監視と運用によって確立されます。XML署名ラッピングやリプレイ攻撃のような既知の脅威に対しては、厳格な検証ロジック、強力な暗号アルゴリズム、有効期限の管理など多層的な防御策を講じることが不可欠です。また、現場での落とし穴を認識し、誤検知や可用性への影響を考慮しながら、バランスの取れたセキュリティ対策を実践していくことが求められます。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました