Bir hizmette Kimlik Doğrulaması için Genişletilmiş Korumayı (EPA) destekleme

Makale
03/20/2025

Özellik	Şunun için geçerlidir:
EPA	desteklenen tüm Windows işletim sistemi
EPA Denetim Modu	Windows Server 2019 Windows Server 2022 Windows Server 23H2

Sorun nedir?

Kimliği doğrulanmış hizmetlere yönelik iletme saldırıları adlı bir saldırı sınıfı vardır. Bu saldırılar saldırganların kimlik doğrulamasını atlamasına ve başka bir kullanıcı gibi davranmasına olanak tanır. Bunlar kimlik doğrulama protokollerinin kendisine değil hizmete yönelik saldırılar olduğundan, iletme saldırılarını engellemek kimliği doğrulanmış hizmete bağlıdır.

Yönlendirme saldırıları nasıl çalışır?

Bir hizmet veya uygulama, bir istemcinin kimliğini doğrulamak için AcceptSecurityContext api'sini çağırdığında, istemcinin çağrısından alınan bir veri blobunu InitializeSecurityContextiletir. Kimlik doğrulama protokolü, sağlanan blob'un belirtilen kullanıcıdan geldiğini doğrulamaktan sorumludur. AcceptSecurityContext, uygulama iletisinin geri kalanının görmediği orijinalliği hakkında onay yapamaz.

Uygulamalarda yaygın bir güvenlik hatası, iç kimlik doğrulama protokolü başarılı bir şekilde doğrulandığında uygulama trafiğini kimliği doğrulanmış olarak ele almaktır. Bu en yaygın olarak, kablo protokolü için TLS kullanan uygulamalarda oluşur. TLS genellikle istemci sertifikalarını kullanmaz; sunucuya kimlik doğrulaması yerine bütünlük ve gizlilik garantileri sağlar. İç kimlik doğrulaması, yalnızca blobu için istemci kimlik doğrulaması sağlar. TLS kanalının veya içinde yer alan uygulama protokolünün geri kalanının kimliğini doğrulamaz.

Saldırgan, bir kaynaktan bir kimlik doğrulama blobu ekleyerek, saldırgan tarafından hazırlanmış bir taleple bir iletme saldırısı gerçekleştirir. Örneğin, saldırgan ağdaki kimlik doğrulama trafiğini gözlemleyebilir ve bunu sunucuya kendi isteğine ekleyebilir. Bu, saldırganın yakalanan kimlik doğrulama trafiğinden istemci olarak sunucuya erişim kazanmasını sağlar.

Buradaki temel kavram, SSPI kimlik doğrulama iletilerinin kabloda kullanıma sunulacak şekilde tasarlanmasıdır; gizli tutulması beklenmez. Bu, TLS kanallarında her zaman gizli tutulan taşıyıcı belirteçleri kullanan birçok web tabanlı kimlik doğrulama düzeninden farklıdır.

Çözüm nedir?

Tercih edilen çözüm, kimlik doğrulama protokollerinin oturum anahtarını kullanarak diğer trafiği imzalamak veya şifrelemek ( MakeSignature EncryptMessage) kullanmaktır. Oturum anahtarı kimlik doğrulama protokolü değişimi sırasında şifresel olarak türetildiğinden, kimliği doğrulanmış verileri ve bu anahtar tarafından korunan tüm trafiğin kimliği doğrulanmış istemciden gelmesi garanti edilir.

Bu her zaman bir seçenek değildir. Bazı durumlarda, uygulama protokolü iletisinin biçimi taşıyıcı belirteçler için tasarlanmış standartlara göre sabitlenir. Bu durumda, Kanal Bağlama olarak da bilinen Kimlik Doğrulaması için Genişletilmiş Koruma (EPA), TLS/SSL kanalı üzerinden iletmeye karşı koruma sağlayabilir.

EPA nedir?

EPA, TLS oturum anahtarını kimlik doğrulama protokolünün oturum anahtarına şifrelemeyle bağlayarak TLS'nin kimlik doğrulama protokolünün anahtarıyla aynı istemci kimlik doğrulamasını sağlamasına olanak sağlar. Daha fazla bilgi için bkz. Kimlik Doğrulaması için Genişletilmiş Koruma'ya Genel Bakış.

Hizmet Bağlama

EPA'nın ikinci bölümü Hizmet Bağlama olarak adlandırılır. Kanal Bağlama'nın aksine bu, hizmete şifreleme garantileri sağlamaz ve kanal bağlamanın mümkün olmadığı son çarenin savunması görevi görür. Bu mekanizma sunucunun QueryContextAttributes çağırarak kimliği doğrulanmış istemcinin InitializeSecurityContext'a geçirilen adını içeren öznitelik SECPKG_ATTR_CLIENT_SPECIFIED_TARGET almasını sağlar.

Örneğin, TLS sonlandırıcı yük dengeleyicinin arkasında yer alan bir hizmet düşünün. TLS oturum anahtarına erişimi yoktur ve yalnızca kanal bağlamasından istemcinin kimlik doğrulamasının TLS korumalı bir hizmete yönelik olduğunu belirleyebilir. İstemci tarafından sağlanan ad, TLS sunucu sertifikasını doğrulamak için kullanılan adla aynı olmalıdır. İstemcinin yük dengeleyiciden sunucu TLS sertifikasıyla eşleşen bir adla kimlik doğrulaması yaptığı doğrulanarak hizmet, kimlik doğrulamasının TLS kanalıyla aynı istemciden geldiği konusunda yüksek güven kazanır.

Bu makalede servis bağlamanın nasıl destekleneceği açıklanmayacaktır. Daha fazla bilgi için bkz. Nasıl Yapılır: Yapılandırmada Hizmet Bağlaması Belirtme.

EPA'ya nasıl destek olursunuz?

EPA'yı zorunlu tutarken hizmetler, uyumluluk sorunları nedeniyle istemcilerin kimlik doğrulamasında başarısız olduğunu fark edebilir. Bu nedenle, hizmetlerin denetimi etkinleştirebileceği bir EPA denetim modu oluşturduk ve yöneticilere EPA'yı zorlamadan önce istemcilerin nasıl yanıt verdiğini gözlemlemeleri için denetimler verdik.

Denetim modunu destekleyen Microsoft hizmetleri şunları içerir:

LDAP

Not

Aşağıda EPA denetim işlevselliğini etkinleştirmek için isteğe bağlı adımlar bulabilirsiniz. EPA'yı zorlamadan EPA denetim işlevselliğini etkinleştirmenin geçiş saldırılarına karşı koruma sağlamadığını lütfen unutmayın. Önce EPA'yı yalnızca denetim modunda etkinleştirmeyi seçen hizmetlerin, daha sonra uyumsuz istemcileri düzeltmeye yönelik adımlar atmasını ve olası geçiş saldırılarını önlemek için EPA'yı kesin olarak zorunlu kılmasını öneririz.

Not

AcceptSecurityContext içine geçirilen kanal bağlamalarının, denetim sonuçlarını almak için sadece denetimle ilgili olmaları gerekmez. Hizmetler, EPA'yi uygularken denetim modunu çalıştırabilir.

Müşteri

Kanal bağlamalarını almak için QueryContextAttributes(TLS) kullanın (benzersiz mi uç nokta mı, belirtin)
InitializeSecurityContextçağrısını yapın ve SECBUFFER_CHANNEL_BINDINGS'de kanal bağlamalarını geçirin

Sunucu

İstemcide olduğu gibi QueryContextAttributes(TLS) kullanın
(İsteğe bağlı olarak) SspiSetChannelBindingFlags çağırarak yalnızca denetim moduna geçirir
(İsteğe bağlı olarak) ASC için çıkış arabelleklerine kanal bağlama sonuç arabelleği ekleyin.
AcceptSecurityContext çağırarak ve SECBUFFER_CHANNEL_BINDINGS kullanarak EPA seviyesini ve diğer yapılandırmaları belirtin
(İsteğe bağlı olarak) Köşe durumlarında davranışı denetlemek için bayrakları kullanın:
- ASC_REQ_ALLOW_MISSING_BINDINGS - Eski üçüncü taraf cihazlar gibi hiçbir şey söylemeyen istemcileri başarısız yapmayın. SECBUFFER_CHANNEL_BINDINGS al(a)mayan bilinçli istemciler, hiçbir şey göndermek yerine boş bir bağlama gönderir.
- ASC_REQ_PROXY_BINDINGS : TLS'nin yük dengeleyicileri sonlandırması için nadir görülen bir durumdur. Geçirebileceğimiz bir SECBUFFER_CHANNEL_BINDINGS yok, ancak yine de istemcilerin isteği bir TLS kanalına yerleştirmesini zorunlu kılmak istiyoruz. Bu, istemcinin sunucu sertifikasının ismimizle eşleştiği bir TLS kanalını kullandığından emin olmak için hizmet bağlamalarında en kullanışlı yöntemdir.

EPA'yı nasıl uygularsınız?

Bir hizmet EPA'yı destekledikten sonra, yöneticiler EPA durumunu denetimden tam uygulanmaya kadar kontrol edebilir. Bu, hizmetlere ekosistemlerinin EPA için hazırlığını değerlendirme, uyumsuz cihazları düzeltme ve ortamlarını korumak için EPA'yı aşamalı olarak zorlama araçları sağlar.

Ortamınızda çeşitli EPA düzeylerini zorunlu kılmak için aşağıdaki öznitelikler ve değerler kullanılabilir:

İsim	Açıklama
Hiç kimse	Kanal bağlama doğrulaması yapılmaz. Bu, güncelleştirilmemiş tüm sunucuların davranışıdır.
İzin vermek	Güncelleştirilmiş tüm istemcilerin sunucuya kanal bağlama bilgileri sağlaması gerekir. Güncelleştirilmemiş istemcilerin bunu yapması gerekmez. Bu, uygulama uyumluluğuna izin veren bir ara seçenektir.
Gerektirmek	Tüm istemcilerin kanal bağlama bilgileri sağlaması gerekir. Sunucu, bunu yapmayan istemcilerden gelen kimlik doğrulama isteklerini reddeder.

Bu öznitelikler, çeşitli EPA zorlama düzeylerinde cihaz uyumluluğu hakkında bilgi toplamak için denetim işlevleriyle birleştirilebilir. İstediğiniz yapılandırmayı SspiSetChannelBindingFlagsaktaracaksınız.

Denetim - Denetim modu yukarıdaki EPA uygulama seviyelerinden herhangi biriyle birlikte kullanılabilir.

EPA denetim sonuçlarını nasıl yorumlursunuz?

Denetim sonuçları bir bit bayrakları kümesidir:

Bayrak	Açıklama
GÜVENLİ_KANAL_BAĞLANTILARI_SONUCU_MÜŞTERİ_DESTEK	İstemci, kanal bağlamaları özelliğine sahip olduğunu belirtti.
GÜVENLİK_KANAL_BAĞLANTISI_SONUCU_MEVCUT_DEĞİL	İstemci dış bir kanala bağlantı sağlamadı.
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH	İstemci bağlamaları sunucudan farklı bir kanal olduğunu gösterir.
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING	Kanal bağlama, SEC_CHANNEL_BINDINGS_RESULT_ABSENTnedeniyle başarısız oldu.
SEC_KANAL_BAĞLANTILARI_SONUCU_GEÇERLİ_ÇAKIŞMA	Kanallar başarıyla bağlandı.
SEC_CHANNEL_BINDINGS_RESULT_VALID_PROXY	Müşteri, ASC_REQ_PROXY_BINDINGSnedeniyle geçtiği için bir dış kanala bağlandığını belirtti.
GÜVENLİK_KANAL_BAĞLANTILARI_SONUCU_GEÇERLİ_EKSİK	ASC_REQ_ALLOW_MISSING_BINDINGSnedeniyle kanal bağlaması geçerli sayıldı.

Bit kümeleri için tanımlar da vardır:

Bayrak	Açıklama
SEC_CHANNEL_BINDINGS_RESULT_VALID	Tüm SEC_CHANNEL_BINDINGS_VALID_* durumlarını test etmek amacıyla kullanılır.
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID	Tüm SEC_CHANNEL_BINDINGS_NOTVALID_* durumları test etmek için kullanılır.

Denetim akışı

Sonuçları destekleyen tüm işletim sistemi her zaman SEC_CHANNEL_BINDINGS_RESULT_VALID ve SEC_CHANNEL_BINDINGS_RESULT_NOTVALIDiçin en az bir bit ayarlar.

Kanal bağlama başarısız oldu:SEC_CHANNEL_BINDINGS_RESULT_NOTVALID'dan herhangi bir bit için test edin. Yalnızca denetim olmayan bağlamalar için bu, STATUS_BAD_BINDINGS veya SEC_E_BAD_BINDINGSile başarısız olan ASC'ye karşılık gelir.

SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH: İstemci ve sunucu kanal bağlamalarını bilir ancak kanal hakkında aynı fikirde değildir. Bu, saldırı vakası veya saldırıdan ayırt edilemeyen bir uygunsuz güvenlik yapılandırmasıdır çünkü yapılandırma trafiği incelemek için HTTPS'yi tehlikeye atmıştır (örneğin Fiddler). Ayrıca istemci ve sunucu benzersiz ve uç nokta bağlamaları konusunda aynı fikirde olmayabilir.
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING iki duruma ayrılır:
- SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORTile, istemcinin kanal bağlamalarını bildiğini ve herhangi bir kanal olmadığını belirttiğini ifade eder. Bu, TLS olmayan bir hizmetten gelen bir iletme saldırısı olabilir, ancak muhtemelen TLS kullanan ancak iç kimlik doğrulama sürecine bunu bildirmeyen istemci üzerinde çalışan bilinçsiz bir uygulamadır.
- SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORTolmadan, kanal bağlamaları yapamayan bir istemcidir. Desteklenen tüm Windows sürümleri kanal bağlama özelliğine sahiptir, bu nedenle bu üçüncü taraf veya SuppressExtendedProtection kayıt defteri değerine sahip bir sistemdir. Bu, eğer ASC_REQ_ALLOW_MISSING_BINDINGSgeçirirseniz SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING'ye dönüştürülen durumdur.

Kanal bağlaması başarılı oldu: Bu, hatanın zıddını veya SEC_CHANNEL_BINDINGS_RESULT_VALIDiçin testi ifade eder.

SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED başarı durumu olan durumdur. Güvenlik koruması çalışıyor (veya EPA yalnızca denetim olarak etkinleştirildiyse çalışır).
SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING, ASC_REQ_ALLOW_MISSING_BINDINGS geçirildiği anlamına gelir, bu nedenle kanal bağlama için destek talep etmemiş bir istemciye izin verdik. Bu durumu yaşayan istemciler korunmuyor ve sorunun ne olduğunu görmek için araştırılmalıdır. Kanal bağlamasını destekleyecek şekilde güncelleştirilmeleri veya bozuk uygulamalar güncelleştirildikten sonra SuppressExtendedProtection kayıt defteri değerinin temizlenmesi gerekir.
SEC_CHANNEL_BINDINGS_RESULT_VALID_PROXY, TLS'in sunucuya ulaşmak yerine bir yük dengeleyicide sonlandırıldığı durumlarda kullanılan ASC_REQ_PROXY_BINDINGS bayrağıyla ilişkili özel bir durumdur. Sunucunun, istemcinin yük dengeleyicide sonlandırılan TLS bağlantısını kullandığını doğrulaması mümkün değildir. Denetim amacıyla, bu, SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHEDile aynı şekilde değerlendirilir.