サービスでの認証の拡張保護 (EPA) のサポート
| 機能 | 適用対象 |
|---|---|
| EPA | サポートされているすべての Windows OS |
| EPA 監査モード | Windows Server 2019 Windows Server 2022 Windows Server 23H2 |
問題は何ですか?
転送攻撃と呼ばれる認証済みサービスに対する攻撃のクラスがあります。 これらの攻撃により、敵対者は認証をバイパスし、別のユーザーとして振る舞うことができます。 これらは認証プロトコル自体ではなくサービスに対する攻撃であるため、転送攻撃を阻止するのは認証済みサービス次第です。
転送攻撃のしくみ
サービスまたはアプリケーションが API AcceptSecurityContext を呼び出してクライアントを認証すると、クライアントの呼び出しから受信したデータの BLOB が InitializeSecurityContext に渡されます。 認証プロトコルには、指定された BLOB が示されたユーザーからのものであることを確認する役割があります。 AcceptSecurityContext では、表示されなかったアプリケーション メッセージの残りの部分の信頼性に関するアサーションを作成できません。
アプリケーションの一般的なセキュリティ上のミスは、内部認証プロトコル BLOB の認証が成功した後に、アプリケーション トラフィックを認証済みとして扱うことです。 これは、ワイヤ プロトコルに TLS を使用するアプリケーションで最もよく発生します。 TLS では通常、クライアント証明書は使用されません。サーバーに整合性と機密性の保証は提供されますが、認証は提供されません。 内部認証ではクライアント認証が提供されますが、その BLOB に対してのみとなります。 TLS チャネルやそこに含まれているアプリケーション プロトコルの残りの部分は認証されません。
攻撃者は、攻撃者が作成した要求を含む 1 つのソースから認証 BLOB を挿入することで、転送攻撃を実行します。 たとえば、攻撃者はネットワーク上の認証トラフィックを監視し、サーバーへの独自の要求にこれを挿入できます。 これにより、攻撃者は取り込まれた認証トラフィックからクライアントとしてサーバーにアクセスできます。
ここでの重要な概念は、SSPI 認証メッセージがネットワーク上で公開されるように設計されていることです。これらは秘密にすることは想定されていません。 これは、TLS チャネル内で常に機密性が保たれるベアラー トークンを使用する多くの Web ベースの認証スキームとは異なります。
ソリューションとは
推奨される解決策は、認証プロトコルのセッション キーを使用して、他のトラフィックに署名する、またはそれを暗号化する (MakeSignature、EncryptMessage) ことです。 セッション キーは認証プロトコルの交換中に暗号的に派生されるため、その認証されたデータと、そのキーによって保護されたトラフィックは、認証されたクライアントからのものであることが保証されます。
これは必ずしもオプションであるとは限りません。 場合によっては、ベアラー トークン用に設計された標準によって、アプリケーション プロトコル メッセージの形式が固定されます。 この場合、認証の拡張保護 (EPA) (チャネル バインディングとも呼ばれる) により、TLS/SSL チャネル経由の転送から保護することができます。
EPA とは
EPA では、認証プロトコルのセッション キーに TLS セッション キーが暗号的にバインドされるため、TLS で認証プロトコルのキーと同じクライアント認証を提供できます。 詳細については、「認証の拡張保護の概要」を参照してください。
サービス バインド
EPA の 2 番目の部分は、サービス バインディングと呼ばれます。 チャネル バインディングとは異なり、これは、サービスに暗号化の保証が提供されず、チャネル バインディングが不可能な場合の最終防御手段として機能します。 このメカニズムにより、サーバーでは QueryContextAttributes を呼び出して、InitializeSecurityContext に渡された認証済みクライアントの名前を含む属性 SECPKG_ATTR_CLIENT_SPECIFIED_TARGET を取得できます。
たとえば、TLS 終了ロード バランサーの背後にサービスが存在するとします。 TLS セッション キーへのアクセス権がないため、クライアントの認証が TLS で保護されたサービスを対象としていたのはチャネル バインディングからのみ判断できます。 クライアントによって指定される名前は、TLS サーバー証明書の検証に使用した名前と同じにする必要があります。 クライアントがロード バランサーのサーバー TLS 証明書と一致する名前に対して認証を行っていたことを確認することで、サービスでは、認証が TLS チャネルと同じクライアントからのものであることを十分確信できます。
この記事では、サービス バインディングをサポートする方法については説明しません。 詳細については、「方法: 構成でサービス バインディングを指定する」を参照してください。
EPA のサポート方法
EPA を適用すると、互換性の問題が原因でクライアントが認証に失敗したことをサービスが認識する場合があります。 そのため、サービスが監査を有効にできる EPA 監査モードを作成し、EPA を適用する前にクライアントがどのように応答するかを監視する制御を管理者に任せています。
監査モードをサポートする Microsoft サービスは次のとおりです。
Note
以下に、EPA 監査機能を有効にするための省略可能な手順を示します。 EPA を適用せずに EPA 監査機能を有効にしても、リレー攻撃から保護されないことに注意してください。 最初に監査モードでのみ EPA を有効にすることを選択したサービスでは、後で互換性のないクライアントを修復し、最終的に潜在的なリレー攻撃を回避するために EPA を厳密に適用する手順を行うことをお勧めします。
Note
AcceptSecurityContext に渡されるチャネル バインディングは、監査結果を得るために監査専用のバインディングである必要はありません。 サービスでは、引き続き EPA を適用しながら監査モードを実行できます。
クライアント
- QueryContextAttributes (TLS) を使用して、チャネル バインディングを取得する (一意またはエンドポイント)
- InitializeSecurityContext を呼び出し、SECBUFFER_CHANNEL_BINDINGS でチャネル バインディングを渡す
サーバー
- QueryContextAttributes (TLS) を使用する (クライアントと同様)
- (省略可能) SspiSetChannelBindingFlags を呼び出して、監査専用にする
- (省略可能) ASC の出力バッファーにチャネル バインディングの結果バッファーを追加します。
- SECBUFFER_CHANNEL_BINDINGS で AcceptSecurityContext を呼び出して、EPA レベルとその他の構成を指定する
- (省略可能) フラグを使用して、コーナー ケースでの動作を制御します。
- ASC_REQ_ALLOW_MISSING_BINDINGS - 古いサード パーティ製デバイスのように、まったく何も示さなかったクライアントを失敗させないようにします。 SECBUFFER_CHANNEL_BINDINGS を取得しなかった対応クライアントは、何もないのではなく、空のバインディングを送信します。
- ASC_REQ_PROXY_BINDINGS - TLS 終了ロード バランサーのまれなケース。 渡す SECBUFFER_CHANNEL_BINDINGS はありませんが、それでもクライアントが TLS チャネルに要求を送信するように強制したいと考えています。 これは、サーバー証明書が名前と一致する TLS チャネルにもクライアントが送信していることを確かめるために、サービス バインディングで最も役立ちます。
EPA の適用方法
サービスで EPA がサポートされるようになったら、管理者は監査から完全な適用まで EPA の状態を制御できます。 これにより、エコシステムの EPA の準備状況を評価し、互換性のないデバイスを修復し、環境を保護するために EPA を段階的に適用するためのツールがサービスに提供されます。
次の属性と値を使用して、環境内でさまざまなレベルの EPA を適用できます。
| 名前 | 内容 |
|---|---|
| なし | チャネル バインディングの検証は実行されません。 更新されていないすべてのサーバーの動作です。 |
| 許可 | 更新されたすべてのクライアントは、サーバーにチャネル バインディング情報を提供する必要があります。 クライアントが更新されていなければ、その必要はありません。 アプリケーションの互換性を許容する中間のオプションです。 |
| 必須 | すべてのクライアントがチャネル バインディング情報を提供する必要があります。 サーバーは、クライアントが要求しないクライアントからの認証要求を拒否します。 |
これらの属性を監査機能と組み合わせて、EPA 適用のさまざまなレベルでデバイスの互換性に関する情報を収集できます。 必要な構成を SspiSetChannelBindingFlags に渡します。
- Audit - 監査モードは、上記の EPA 適用レベルのいずれかと組み合わせて使用できます。
EPA 監査結果の解釈方法
監査結果は、一連のビット フラグです。
| フラグ | 説明 |
|---|---|
| SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT | クライアントは、チャネル バインディングが可能であることを示しました。 |
| SEC_CHANNEL_BINDINGS_RESULT_ABSENT | クライアントは、外部チャネルへのバインディングを提供しませんでした。 |
| SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH | クライアント バインディングでは、サーバーとは異なるチャネルが示されています。 |
| SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING | SEC_CHANNEL_BINDINGS_RESULT_ABSENT が原因でチャネル バインディングに失敗しました。 |
| SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED | チャネルは正常にバインドされました。 |
| SEC_CHANNEL_BINDINGS_RESULT_VALID_PROXY | クライアントは外部チャネルへのバインディングを示しました。これは、ASC_REQ_PROXY_BINDINGS が原因で渡されました。 |
| SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING | ASC_REQ_ALLOW_MISSING_BINDINGS が原因でチャネル バインディングが渡されました。 |
ビットのセットの定義もあります。
| フラグ | 説明 |
|---|---|
| SEC_CHANNEL_BINDINGS_RESULT_VALID | すべての SEC_CHANNEL_BINDINGS_VALID_* ケースをテストするために使用されます。 |
| SEC_CHANNEL_BINDINGS_RESULT_NOTVALID | すべての SEC_CHANNEL_BINDINGS_NOTVALID_* ケースをテストするために使用されます。 |
監査フロー
結果をサポートする OS では常に、SEC_CHANNEL_BINDINGS_RESULT_VALID および SEC_CHANNEL_BINDINGS_RESULT_NOTVALID から少なくとも 1 ビットが設定されます。
チャネル バインディングに失敗しました:SEC_CHANNEL_BINDINGS_RESULT_NOTVALID からの任意のビットをテストします。 監査専用ではないバインディングの場合、これは ASC が STATUS_BAD_BINDINGS または SEC_E_BAD_BINDINGS で失敗した場合に対応します。
- SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH: クライアントとサーバーの両方がチャネル バインディングについて認識していますが、チャネルについて同意していません。 これは、(Fiddler など) トラフィックを検査する HTTPS が構成によって侵害されたため、攻撃と区別できない攻撃ケースまたは不適切なセキュリティ構成です。 また、クライアントとサーバーが、一意のバインディングとエンドポイントのバインドについて同意していない可能性もあります。
- SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING は、次の 2 つのケースに分けられます。
- SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT がある場合、クライアントはチャネル バインディングについて認識し、チャネルがないことを証明することを意味します。 これは TLS 以外のサービスからの転送攻撃である可能性がありますが、TLS を実行しているものの、そのことを内部認証には伝えていないクライアントで実行されている未対応のアプリケーションが存在する可能性があります。
- SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT がない場合、チャネル バインディングが可能でないクライアントになります。 サポートされているすべての Windows バージョンではチャネル バインディングが可能であるため、これはサードパーティ製か、レジストリ値 SuppressExtendedProtection が設定されたシステムのいずれかです。 これは、ASC_REQ_ALLOW_MISSING_BINDINGS を渡すと、SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING に変わるケースです。
チャネル バインディングに成功しました: これは、失敗の確認の逆です。そうでなければ、SEC_CHANNEL_BINDINGS_RESULT_VALID をテストします。
- SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED は成功したケースです。 セキュリティ保護が機能しています (または、EPA が監査専用として有効になっている場合は機能します)。
- SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING は、ASC_REQ_ALLOW_MISSING_BINDINGS が渡されたことを意味するため、チャネル バインディングのサポートを要求していないクライアントを許可しました。 このケースにヒットしているクライアントは保護されていないため、何が間違っているかを確認するために調査する必要があります。 チャネル バインディングをサポートするために更新する必要があるか、壊れたアプリケーションが更新されたら SuppressExtendedProtection レジストリ値をクリアする必要があります。
- SEC_CHANNEL_BINDINGS_RESULT_VALID_PROXY は、サーバーに到達するのではなく、ロード バランサーで TLS が終了したときに使用されるフラグ ASC_REQ_PROXY_BINDINGS に関連付けられた特殊なケースです。 サーバーでは、ロード バランサーで終了したのと同じ TLS 接続がクライアントによって使用されていることを確認することはできません。 監査目的で、これは SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED と同じように扱われます。
関連項目
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示