要件は多くの場合、(相互) 認証、完全性、機密性の観点から表現され、セキュリティ メカニズムの選択は実装者と導入者に委ねられます。 SAML の主な使用例は、Web ブラウザー シングル サインオン (SSO) と呼ばれます。 ユーザーはユーザー エージェント (通常は Web ブラウザ) を利用して、SAML サービス プロバイダーによって保護されている Web リソースを要求します。 サービス プロバイダーは、要求元のユーザーの ID を知りたい場合、ユーザー エージェントを通じて SAML ID プロバイダーに認証要求を発行します。
一般的な SAML セキュリティ
次のセクションでは、SAML の使用および実装におけるセキュリティ リスクを分析し、リスクを軽減するために miniOrange SAML SSO プラグイン/モジュールを使用する対策について説明します。
- SAML アサーション:
SAML アサーション自体のレベルでは、セキュリティ上の懸念についてはほとんど言うことがありません。ほとんどの懸念は、要求/応答プロトコルでの通信中、またはバインディングの XNUMX つを使用して SAML を使用しようとするときに発生します。 もちろん、コンシューマは、アサーションの有効期間とアサーション内に存在する要素を尊重することが常に期待されます。 ただし、アサーション レベルで分析が必要な問題が XNUMX つあります。それは、アサーションは一度発行されると、発行者の制御が及ばないということです。 この事実は多くの影響を及ぼします。 たとえば、発行者は、アサーションが消費者のシステムにどのくらいの期間保持されるかを制御できません。 また、発行者は、消費者/サービスプロバイダーがアサーション情報を共有する当事者を制御することもできません。 これらの懸念は、暗号化されずに (または暗号化が不十分なまま) ネットワーク上を通過するアサーションの内容を閲覧できる悪意のある攻撃者に関する懸念を上回るものです。 SAML 仕様内でこれらの問題の多くに対処する取り組みが行われてきましたが、仕様に含まれる内容によって、アサーションに何を含めるかを慎重に検討する必要性がなくなるわけではありません。 発行者は常に、アサーションの情報がリモート サイトに保存されている場合、その情報が直接悪用されたり、潜在的なハッカーにさらされたり、より独創的な不正使用のために保存されたりする可能性がある場合に起こり得る結果を考慮する必要があります。 発行者は、アサーション内の情報が意図的または不注意で他の当事者と共有されたり、さらには公開されたりする可能性も考慮する必要があります。
1.1. SAMLプロトコル:
次のセクションでは、特定のプロトコル バインディングの使用から生じる脅威とは別に、SAML 要求/応答プロトコル自体のセキュリティに関する考慮事項について説明します。
1.1.1. サービス拒否：
SAML プロトコルは、サービス拒否 (DOS) 攻撃を受けやすいです。 SAML リクエストの処理は、リクエスト メッセージの解析 (通常は DOM ツリーの構築を含む)、データベース/アサーション ストアの検索 (インデックスのないキーでの可能性がある)、応答メッセージの構築、および場合によっては XNUMX つ以上の処理を含む、非常にコストのかかる操作になる可能性があります。デジタル署名操作。 したがって、攻撃者がリクエストを生成するのに必要な労力は、それらのリクエストを処理するのに必要な労力よりもはるかに少なくなります。
1.1.2. 署名付きリクエストの要求
miniOrange SAML SSO プラグイン/モジュールはリクエストに署名し、SAML プラグインとレスポンダーによって実行される作業の間の非対称性の順序も狭めます。 署名を検証するために応答側に必要な追加作業は、応答側に必要な作業全体の比較的小さな割合ですが、デジタル署名を計算するプロセスは要求側にとって比較的大量の作業になります。 この非対称性を狭めると、DOS 攻撃に関連するリスクが軽減されます。 ただし、理論的には、攻撃者は署名付きメッセージをキャプチャし、それを継続的に再生して、この要件を回避できることに注意してください。 この状況は、XML 署名要素の使用を要求することで回避できます。 タイムスタンプを含む。 タイムスタンプを使用して、署名が最近のものかどうかを判断できます。 したがって、応答発行後の有効な署名の期間が狭いほど、リプレイ拒否攻撃に対するセキュリティが高くなります。
2. SAML バインディングのセキュリティ:
SAML 要求/応答プロトコルの設計におけるセキュリティに関する考慮事項は、使用される特定のプロトコル バインディング (SAML バインディング仕様 [SAMLBind] で定義されている) に大きく依存します。 OASIS セキュリティ サービス技術委員会によって認可されているバインディングは、SOAP バインディング、リバース SOAP バインディング (PAOS)、HTTP リダイレクト バインディング、HTTP リダイレクト/POST バインディング、HTTP アーティファクト バインディング、および SAML URI バインディングです。 miniOrange SAML SSO プラグインは、Http-Redirect および Http-POST バインディングをサポートします。
2.1. HTTPリダイレクトバインディング
2.1.2. サービス拒否
脅威： ID プロバイダーまたはサービス プロバイダーのターゲットへの悪意のあるリダイレクト。
説明: 偽のエンティティがユーザー エージェントへのリダイレクトを発行し、ユーザー エージェントがシングル サインオンを中断するリソースにアクセスする可能性があります。 たとえば、攻撃者はユーザー エージェントをサービス プロバイダーのログアウト リソースにリダイレクトし、プリンシパルを既存のすべての認証セッションからログアウトさせる可能性があります。
対策： 副作用を引き起こすリソースへのアクセスは、現在の認証セッションに対応する必要がある一時修飾子を使用して指定されます。 あるいは、同様のセマンティクスを持つ一時的な修飾子に依存する確認ダイアログを挿入することもできます。
2.2. HTTP POST バインディング
2.2.1. 盗まれたアサーション
脅威： 盗聴者が実際のユーザーの SAML 応答とそれに含まれるアサーションをコピーできる場合、盗聴者は適切な POST 本文を構築し、宛先サイトでユーザーになりすますことができます。
対策： SAML SSO プラグインとユーザーのブラウザ間で応答が通信されるときは常に機密性が維持されます。 これにより、実際のユーザーの SAML 応答とアサーションを盗聴者が取得することに対する保護が提供されます。 盗聴者が機密性を確保するために使用された手段を破った場合、追加の対抗策が利用可能です。
● アイデンティティ プロバイダー サイトとサービス プロバイダー サイトは、両方のサイトのクロック設定の差が最大でも数分であることを確認するための合理的な努力をすべきです (SHOULD)。 インターネット経由および独自のソースからの両方で、さまざまな形式の時刻同期サービスが利用可能です。
● 非 SSO SAML プロファイルが POST バインディングを使用する場合、受信者が適時にサブジェクト確認を実行できることを保証する必要があります。 この目的のために、プリンシパルの SAML 認証アサーションを POST されたフォーム応答に含める必要があります。
● SSO アサーションの NotBefore および NotOnOrAfter 属性の値は、アイデンティティ プロバイダーからサービス プロバイダー サイトへのアサーションの正常な通信と一致する、可能な限り短い有効期間を持つ必要があります (SHOULD)。 通常、これには数分程度かかります。 これにより、盗まれたアサーションは短い時間枠内でのみ正常に使用されることが保証されます。
● miniOrange SAML SSO プラグインは、アイデンティティ プロバイダー サイトから取得したすべてのアサーションの有効期間をチェックし、期限切れのアサーションを拒否します。 アサーションの IssueInstant または AuthnInstant 属性値が、サービス プロバイダー サイトでアサーションが受信されてから数分以内であることを要求するなど、SSO アサーションの有効性についてより厳密なテストを実装することを選択します。
● 受信した認証文に次の内容が含まれている場合要素にユーザーの IP アドレスを含めた場合、サービス プロバイダー サイトはブラウザの IP アドレスを認証ステートメントに含まれる IP アドレスと照合してもよい (MAY)。
2.2.2. 捏造された主張
脅威： 悪意のあるユーザーまたはブラウザ ユーザーが SAML アサーションを偽造または変更する可能性があります。
対策： ブラウザ/POST プロファイルでは、SAML アサーションを含む SAML 応答が署名される必要があるため、メッセージの整合性と認証の両方が提供されます。 miniOrange SAML SSO プラグインは署名を検証し、発行者を認証します。
2.2.3. ブラウザの状態の公開
脅威： ブラウザ/POST プロファイルには、Web ブラウザからサービス プロバイダー サイトへのアサーションのアップロードが含まれます。 この情報は Web ブラウザの状態の一部として利用でき、通常は完全に安全でない方法でユーザー システムの永続ストレージに保存されます。 ここでの脅威は、アサーションが後の時点で「再利用」される可能性があることです。
対策： このプロファイルを使用して通信されるアサーションは常に短い有効期間を持つ必要があり、 SAML アサーション要素。 サービス プロバイダー サイトは、アサーションが再利用されないことを保証することが期待されます。
2.2.4. リプレイ
脅威： リプレイ攻撃は、保護されたリソースに不正にアクセスするためにフォームを再送信することになります。
対策： miniOrange SAML SSO プラグインは、転送されるアサーションに XNUMX 回限りのプロパティを持たせることを義務付け、リプレイ攻撃の成功を防ぎます。
2.2.5. 状態情報の変更または公開
脅威： リレー状態の改ざんまたは捏造。 メッセージによっては、 この要素は、プロデューサーによって完全性が保護され、オプションで機密性が保護されることが推奨されます。 これらの慣行に従わない場合、敵対者が望ましくない副作用を引き起こす可能性があります。 さらに、この要素の値の機密性が保護されていないため、正規のシステム エンティティが不注意で ID プロバイダーや受動的攻撃者に情報を公開する可能性があります。
対策： RelayState データの機密性と整合性を保護するための推奨プラクティスに従ってください。 注: この要素の値は同じシステム エンティティによって生成および消費されるため、対称暗号化プリミティブを利用できます。
3. SAML プロファイルのセキュリティ
SAML プロファイル仕様 [SAMLProf] は SAML のプロファイルを定義します。これは、SAML アサーションをフレームワークまたはプロトコルに埋め込む方法、およびフレームワークまたはプロトコルから抽出する方法を説明する一連のルールです。
3.1. Web ブラウザのシングル サインオン (SSO) プロファイル
ソース サイトでのユーザー認証は、このソース サイトの認証に関連する問題と同様、明示的に対象外であることに注意してください。 重要な概念は、ソース システム エンティティは、対話している認証済みのクライアント システム エンティティが次の対話ステップのエンティティと同じであることを確認できなければならないということです。 これを達成する XNUMX つの方法は、最初の対話に使用されるプロトコル (HTTP など) の下でセッション層として TLS を使用して、これらの初期ステップを実行することです。
3.1.1. SSO プロファイル
3.1.1.1. メッセージの変更
脅威： このプロファイルのセットでは、ストリーム内のメッセージが変更される可能性があります。 潜在的な望ましくない結果としては、次のようなものがあります。
● 最初のリクエストを変更すると、SAML 発行者で拒否される可能性があります。
要求されたものとは異なるリソースを対象としたアーティファクトの作成
● アーティファクトを変更すると、SAML コンシューマでサービス拒否が発生する可能性があります。
● 転送中にアサーション自体が変更されると、あらゆる種類のエラーが発生する可能性があります。
悪い結果 (署名されていない場合) またはサービス拒否 (署名されている場合)
消費者はそれらを拒否します）。
対策： メッセージの変更を回避するには、エンドポイントからエンドポイントへのメッセージの整合性を保証するシステムを使用してトラフィックを転送する必要があります。 Web ブラウザベースのプロファイルの場合、転送中のメッセージの整合性を提供する推奨方法は、データ整合性チェックを提供する暗号スイートを備えた HTTP over TLS/SSL の使用です。
3.1.2. シングルログアウトプロファイル
脅威： 受動的攻撃者はプリンシパルの名前識別子を収集できます。 最初のステップで、受動的な攻撃者はリダイレクトで発行されたときの情報。 これらのデータを公開すると、プライバシーの脅威が生じます。
対策： すべての交換は、SSL や TLS などの安全なトランスポートを介して実行される必要があります。
脅威： 署名なし偽のシステム エンティティによって注入される可能性があるため、プリンシパルへのサービスが拒否されます。 NameID が推定または導出できると仮定すると、ユーザー エージェントが捏造されたメッセージを配信するよう指示される可能性があると考えられます。 メッセージ。
対策： miniOrange SAML SSO プラグイン/モジュールは、 メッセージ。 ID プロバイダーは、署名されたリクエストがない場合でもプリンシパルの ID を検証できます。
3.2. 名前識別子管理プロファイル
脅威： システム エンティティが情報を関連付けたり、アイデンティティ情報を不適切に公開したりしてプライバシーを侵害することを許可します。
対策： IDP は、同じプリンシパルに対して異なるサービス プロバイダーでは異なる名前識別子を使用するように注意する必要があります。 IDP は、サービス プロバイダーに返す名前識別子を暗号化し、その後の対話で不透明な識別子を使用できるようにする必要があります。
3.2.1. 属性プロファイル
属性プロファイルに関連付けられたバインディングに関連する脅威については上で説明しました。 プロファイル固有の追加の脅威は知られていません。
4. まとめ
ソーシャル エンジニアリング攻撃、ポリシーの問題、鍵管理と信頼管理、安全な実装、その他の要素などの人的問題はこの文書の範囲外であることを考慮して、セキュリティとプライバシーは体系的に対処する必要があります。 セキュリティ技術ソリューションにはコストがかかるため、要件とポリシーの代替案も法的および規制上の「必須」要件として考慮する必要があります。 この非規範的な文書には、一般的なセキュリティの問題とアプローチ、およびプライバシーを維持する安全な方法で SAML アサーション、プロトコル、バインディング、プロファイルを使用するための特定の脅威と対策がまとめられています。 規範的な要件は、規範的な SAML 仕様で指定されます。
