Application Gateway ile TLS sonlandırma ve uçtan uca TLS'ye genel bakış

Daha önce Güvenli Yuva Katmanı (SSL) olarak bilinen Aktarım Katmanı Güvenliği (TLS), web sunucusu ile tarayıcı arasında şifreli bağlantı oluşturmaya yönelik standart güvenlik teknolojisidir. Bu bağlantı, web sunucusu ve tarayıcılar arasında geçirilen tüm verilerin özel ve şifreli kalmasını sağlar. Application Gateway hem ağ geçidinde TLS sonlandırmayı hem de uçtan uca TLS şifrelemesini destekler.

TLS sonlandırma

Application Gateway, ağ geçidinde TLS sonlandırmasını destekler ve bundan sonra trafik genellikle arka uç sunucularına şifrelenmemiş olarak akar. Uygulama ağ geçidinde TLS sonlandırması yapmanın çeşitli avantajları vardır:

  • Geliştirilmiş performans – TLS şifre çözme işlemi sırasında en büyük performans isabeti ilk el sıkışmadır. Performansı geliştirmek için şifre çözme işlemini yapan sunucu TLS oturum kimliklerini önbelleğe alır ve TLS oturum biletlerini yönetir. Bu işlem uygulama ağ geçidinde yapılırsa, aynı istemciden gelen tüm istekler önbelleğe alınmış değerleri kullanabilir. Arka uç sunucularında yapılırsa, istemcinin istekleri farklı bir sunucuya her gittiği zaman istemcinin yeniden kimlik doğrulaması yapması gerekir. TLS biletlerinin kullanılması bu sorunun azaltılmasına yardımcı olabilir, ancak tüm istemciler tarafından desteklenmez ve yapılandırılması ve yönetilmesi zor olabilir.
  • Arka uç sunucularının daha iyi kullanımı – SSL/TLS işleme çok YOĞUN CPU kullanımına sahiptir ve anahtar boyutları arttıkça daha yoğun hale gelmektedir. Bu çalışmayı arka uç sunucularından kaldırmak, içerik sunma konusunda en verimli oldukları şeye odaklanmalarını sağlar.
  • Akıllı yönlendirme – Uygulama ağ geçidi trafiğin şifresini çözerek üst bilgiler, URI gibi istek içeriğine erişebilir ve istekleri yönlendirmek için bu verileri kullanabilir.
  • Sertifika yönetimi – Sertifikaların tüm arka uç sunucularında değil, yalnızca uygulama ağ geçidinde satın alınması ve yüklenmesi gerekir. Bu hem zamandan hem de paradan tasarruf sağlar.

TLS sonlandırmayı yapılandırmak için dinleyiciye bir TLS/SSL sertifikası eklenmelidir. Bu, Application Gateway'in gelen trafiğin şifresini çözmesine ve istemciye gelen yanıt trafiğini şifrelemesine olanak tanır. Application Gateway'e sağlanan sertifika, hem özel hem de ortak anahtarları içeren Kişisel Bilgi Değişimi (PFX) biçiminde olmalıdır. Desteklenen PFX algoritmaları PFXImportCertStore işlevinde listelenir.

Önemli

Dinleyicideki sertifika, güven zincirini oluşturmak için sertifika zincirinin tamamının (CA'dan kök sertifika, aralar ve yaprak sertifika) yüklenmesini gerektirir.

Dekont

Application Gateway, yeni bir sertifika oluşturma veya sertifika yetkilisine sertifika isteği gönderme özelliği sağlamaz.

TLS bağlantısının çalışması için TLS/SSL sertifikasının aşağıdaki koşulları karşıladığından emin olmanız gerekir:

  • Geçerli tarih ve saatin sertifikadaki "Geçerlilik tarihi" ve "Geçerlilik tarihi" tarih aralığında olması.
  • Sertifikanın "Ortak Ad" (CN) değeri, istekteki ana bilgisayar üst bilgisiyle eşleşiyor. Örneğin istemci isteğinin hedefi https://www.contoso.com/ ise CN www.contoso.com olmalıdır.

Arka uç sertifikası ortak adı (CN) ile ilgili hatalarla karşı karşıyaysanız sorun giderme kılavuzumuza bakın.

TLS sonlandırma için desteklenen sertifikalar

Application Gateway aşağıdaki sertifika türlerini destekler:

  • CA (Sertifika Yetkilisi) sertifikası: CA sertifikası, sertifika yetkilisi (CA) tarafından verilen dijital bir sertifikadır
  • EV (Genişletilmiş Doğrulama) sertifikası: EV sertifikası, endüstri standardı sertifika yönergelerine uyan bir sertifikadır. Bu, tarayıcı bulucu çubuğunu yeşile çevirir ve şirket adını da yayımlar.
  • Joker Sertifika: Bu sertifika, *.site.com tabanlı herhangi bir sayıda alt etki alanını destekler; burada alt etki alanınız * öğesinin yerini alır. Ancak, site.com desteklemez, bu nedenle kullanıcıların öndeki "www" yazmadan web sitenize erişmesi durumunda joker karakter sertifikası bunu kapsamaz.
  • Otomatik olarak imzalanan sertifikalar: İstemci tarayıcıları bu sertifikalara güvenmez ve kullanıcıyı sanal hizmetin sertifikasının bir güven zincirinin parçası olmadığı konusunda uyarır. Otomatik olarak imzalanan sertifikalar, yöneticilerin istemcileri denetlediği ve tarayıcının güvenlik uyarılarını güvenli bir şekilde atladığı test veya ortamlar için uygundur. Üretim iş yükleri hiçbir zaman otomatik olarak imzalanan sertifikaları kullanmamalıdır.

Daha fazla bilgi için bkz . Application Gateway ile TLS sonlandırmasını yapılandırma.

Sertifikanın boyutu

Desteklenen en yüksek TLS/SSL sertifika boyutunu öğrenmek için Application Gateway sınırları bölümüne bakın.

Uçtan uca TLS şifrelemesi

Arka uç sunucularına şifrelenmemiş iletişim sağlamak istemeyebilirsiniz. Güvenlik gereksinimleriniz, uyumluluk gereksinimleriniz olabilir veya uygulama yalnızca güvenli bir bağlantı kabul edebilir. Azure Uygulaması lication Gateway,bu gereksinimleri desteklemek için uçtan uca TLS şifrelemesine sahiptir.

Uçtan uca TLS, Application Gateway'in Katman 7 yük dengeleme özelliklerini kullanırken hassas verileri şifrelemenize ve güvenli bir şekilde arka uca iletmenize olanak tanır. Bu özellikler tanımlama bilgisi tabanlı oturum benzimliği, URL tabanlı yönlendirme, site tabanlı yönlendirme desteği, X-Forwarded-* üst bilgilerini yeniden yazma veya ekleme gibi özellikleri içerir.

Application Gateway, uçtan uca TLS iletişim moduyla yapılandırıldığında, ağ geçidindeki TLS oturumlarını sonlandırır ve kullanıcı trafiğinin şifresini çözer. Ardından trafiğin yönlendirileceği uygun arka uç havuzunu seçmek için yapılandırılan kuralları uygular. Application Gateway daha sonra arka uç sunucusuna yeni bir TLS bağlantısı başlatır ve isteği arka uca iletmeden önce arka uç sunucusunun ortak anahtar sertifikasını kullanarak verileri yeniden şifreler. Web sunucusundan alınan herhangi bir yanıt, son kullanıcıya dönerken aynı süreci izler. Uçtan uca TLS, Arka Uç HTTP Ayarı'nda protokol ayarı HTTPS olarak ayarlanarak etkinleştirilir ve bu ayar arka uç havuzuna uygulanır.

Application Gateway v1 SKU ağ geçitlerinde TLS ilkesi TLS sürümünü yalnızca ön uç trafiğine ve tanımlı şifreleri hem ön uç hem de arka uç hedeflerine uygular. Application Gateway v2 SKU ağ geçitlerinde TLS ilkesi yalnızca ön uç trafiği için geçerlidir, arka uç TLS bağlantıları her zaman TLS 1.0 ile TLS 1.2 sürümleri arasında anlaşılır.

Application Gateway yalnızca sertifikalarını Application Gateway ile izin verilen şekilde listeleyen veya sertifikaları iyi bilinen CA yetkilileri tarafından imzalanan ve sertifikanın CN'si HTTP arka uç ayarlarındaki ana bilgisayar adıyla eşleşen arka uç sunucularıyla iletişim kurar. Bunlar Azure Uygulaması Service/Web Apps ve Azure API Management gibi güvenilir Azure hizmetlerini içerir.

Arka uç havuzundaki üyelerin sertifikaları iyi bilinen CA yetkilileri tarafından imzalanmamışsa, arka uç havuzundaki uçtan uca TLS'nin etkinleştirildiği her örnek, güvenli iletişime izin vermek için bir sertifikayla yapılandırılmalıdır. Sertifikanın eklenmesi, uygulama ağ geçidinin yalnızca bilinen arka uç örnekleriyle iletişim kurmasını sağlar. Bu, uçtan uca iletişimin güvenliğini daha da sağlar.

Dekont

Arka uç sunucularının kimliğini doğrulamak için Arka Uç HTTP Ayarı'na eklenen sertifika, uygulama ağ geçidinde TLS sonlandırması için dinleyiciye eklenen sertifikayla aynı veya gelişmiş güvenlik için farklı olabilir.

end to end TLS scenario

Bu örnekte TLS1.2 kullanan istekler, uçtan uca TLS kullanılarak Pool1'deki arka uç sunucularına yönlendirilir.

Uçtan uca TLS ve sertifikaların listelenmesine izin ver

Application Gateway yalnızca sertifikalarını Application Gateway ile izin verilen şekilde listeleyen veya sertifikaları iyi bilinen CA yetkilileri tarafından imzalanan ve sertifikanın CN'si HTTP arka uç ayarlarındaki ana bilgisayar adıyla eşleşen arka uç sunucularıyla iletişim kurar. Kullanılan Application Gateway sürümüyle ilgili olarak uçtan uca TLS kurulum işleminde bazı farklılıklar vardır. Aşağıdaki bölümde sürümler ayrı ayrı açıklanmaktadır.

v1 SKU ile uçtan uca TLS

Arka uç sunucularıyla uçtan uca TLS'yi etkinleştirmek ve Application Gateway'in istekleri bunlara yönlendirmesi için sistem durumu yoklamalarının başarılı olması ve iyi durumda yanıt döndürmesi gerekir.

HTTPS sistem durumu yoklamaları için Application Gateway v1 SKU'su, HTTP ayarlarına yüklenecek kimlik doğrulama sertifikasının (kök sertifikanın değil arka uç sunucu sertifikasının ortak anahtarı) tam eşleşmesini kullanır.

Daha sonra yalnızca bilinen ve izin verilen arka uçlara bağlantılara izin verilir. Geri kalan arka uçlar sistem durumu yoklamaları tarafından iyi durumda değil olarak kabul edilir. Otomatik olarak imzalanan sertifikalar, yalnızca test amaçlarına yöneliktir ve üretim iş yükleri için önerilmez. Bu tür sertifikaların kullanılabilmesi için önceki adımlarda açıklandığı gibi uygulama ağ geçidiyle birlikte izin verilenler listelenmesi gerekir.

Dekont

Azure Uygulaması Hizmeti gibi güvenilen Azure hizmetleri için kimlik doğrulaması ve güvenilen kök sertifika kurulumu gerekli değildir. Bunlar varsayılan olarak güvenilir olarak kabul edilir.

v2 SKU ile uçtan uca TLS

Application Gateway v2 SKU'sunda Kimlik Doğrulama Sertifikaları kullanım dışı bırakıldı ve yerini Güvenilen Kök Sertifikalar aldı. Kimlik Doğrulama Sertifikaları'na benzer şekilde çalışır ve birkaç önemli fark vardır:

  • CN'si HTTP arka uç ayarlarındaki ana bilgisayar adıyla eşleşen iyi bilinen CA yetkilileri tarafından imzalanan sertifikalar, uçtan uca TLS'nin çalışması için ek bir adım gerektirmez.

    Örneğin, arka uç sertifikaları iyi bilinen bir CA tarafından verildiyse ve CN contoso.com sahipse ve arka uç http ayarının konak alanı da contoso.com olarak ayarlandıysa, ek adım gerekmez. Arka uç http ayarı protokolunu HTTPS olarak ayarlayabilirsiniz ve hem sistem durumu yoklaması hem de veri yolu TLS etkin olur. Arka ucunuz olarak Azure Uygulaması Hizmeti veya diğer Azure web hizmetlerini kullanıyorsanız, bunlar da örtük olarak güvenilirdir ve uçtan uca TLS için başka adım gerekmez.

Dekont

Bir TLS/SSL sertifikasına güvenilebilmesi için arka uç sunucusunun sertifikasının iyi bilinen bir CA tarafından verilmiş olması gerekir. Sertifika güvenilir bir CA tarafından verilmediyse, uygulama ağ geçidi sertifika veren CA'nın sertifikasının güvenilir bir CA tarafından verildiğini denetler ve bu şekilde, güvenilen bir CA bulunana (bu noktada güvenilir, güvenli bağlantı kurulacak) veya hiçbir güvenilir CA bulunamayana kadar (bu noktada uygulama ağ geçidi arka ucu iyi durumda değil olarak işaretler). Bu nedenle, arka uç sunucu sertifikasının hem kök hem de ara CA'ları içermesi önerilir.

  • Arka uç sunucu sertifikası otomatik olarak imzalanmışsa veya bilinmeyen CA/aracılar tarafından imzalanmışsa, Application Gateway v2'de uçtan uca TLS'yi etkinleştirmek için güvenilir bir kök sertifikanın karşıya yüklenmesi gerekir. Application Gateway yalnızca sunucu sertifikasının kök sertifikası havuzla ilişkilendirilmiş arka uç http ayarındaki güvenilen kök sertifikalar listesinden biriyle eşleşen arka uçlarla iletişim kurar.

  • Kök sertifika eşleşmesine ek olarak, Application Gateway v2 arka uç http ayarında belirtilen Konak ayarının arka uç sunucusunun TLS/SSL sertifikası tarafından sunulan ortak adla (CN) eşleşip eşleşmediğini de doğrular. Application Gateway v2, arka uçla TLS bağlantısı kurmaya çalışırken, Sunucu Adı Göstergesi (SNI) uzantısını arka uç http ayarında belirtilen Konak olarak ayarlar.

  • Arka uç http ayarında Konak alanı yerine arka uç hedefinden konak adı seçin seçilirse, SNI üst bilgisi her zaman arka uç havuzu FQDN'sine ayarlanır ve arka uç sunucusu TLS/SSL sertifikasındaki CN, FQDN'si ile eşleşmelidir. IP'leri olan arka uç havuzu üyeleri bu senaryoda desteklenmez.

  • Kök sertifika, arka uç sunucu sertifikalarından base64 ile kodlanmış bir kök sertifikadır.

v1 ve v2 SKU'sunda SNI farklılıkları

Daha önce belirtildiği gibi Application Gateway, Application Gateway Dinleyicisi'ndeki istemciden gelen TLS trafiğini sonlandırır (bunu ön uç bağlantısı olarak adlandıralım), trafiğin şifresini çözer, isteğin iletilmesi gereken arka uç sunucusunu belirlemek için gerekli kuralları uygular ve arka uç sunucusuyla yeni bir TLS oturumu oluşturur (arka uç bağlantısı diyelim).

Aşağıdaki tablolarda, ön uç ve arka uç bağlantıları açısından v1 ile v2 SKU arasındaki SNI farklılıkları özetlenmiştir.

Ön uç TLS bağlantısı (istemciden uygulama ağ geçidine)

Senaryo v1 v2
İstemci SNI üst bilgisini belirtirse ve tüm çok siteli dinleyiciler "SNI gerektir" bayrağıyla etkinleştirilirse Uygun sertifikayı döndürür ve site yoksa (server_name göre) bağlantı sıfırlanır. Varsa uygun sertifikayı döndürür, aksi takdirde, https dinleyicileriyle ilişkilendirilmiş istek yönlendirme kuralları tarafından belirtilen sıraya göre ilk HTTPS dinleyicisinin sertifikasını döndürür
İstemci bir SNI üst bilgisi belirtmezse ve tüm çok siteli üst bilgiler "SNI gerektir" ile etkinleştirildiyse Bağlantıyı sıfırlar https dinleyicileriyle ilişkilendirilmiş istek yönlendirme kuralları tarafından belirtilen sıraya göre ilk HTTPS dinleyicisinin sertifikasını döndürür
İstemci SNI üst bilgisini belirtmezse ve sertifikayla yapılandırılmış temel bir dinleyici varsa İstemcinin temel dinleyicisinde yapılandırılan sertifikayı döndürür (varsayılan veya geri dönüş sertifikası) Temel dinleyicide yapılandırılan sertifikayı döndürür

Bahşiş

SNI bayrağı PowerShell ile veya arm şablonu kullanılarak yapılandırılabilir. Daha fazla bilgi için bkz. RequireServerNameIndication ve Hızlı Başlangıç: Azure Uygulaması lication Gateway ile web trafiğini yönlendirme - ARM şablonu.

Arka uç TLS bağlantısı (arka uç sunucusuna uygulama ağ geçidi)

Yoklama trafiği için

Senaryo v1 v2
TLS el sıkışması sırasında FQDN olarak SNI (server_name) üst bilgisi Arka uç havuzundan FQDN olarak ayarlayın. RFC 6066'ya göre, SNI ana bilgisayar adında değişmez IPv4 ve IPv6 adreslerine izin verilmez.
Not: ARKA uç havuzundaki FQDN, DNS'nin arka uç sunucusunun IP adresine (genel veya özel) çözümlenmesi gerekir
SNI üst bilgisi (server_name), HTTP ayarlarına eklenen özel yoklamadan (yapılandırıldıysa) konak adı olarak ayarlanır; aksi takdirde HTTP ayarlarında belirtilen ana bilgisayar adından( aksi takdirde arka uç havuzunda belirtilen FQDN'den). Öncelik sırası, özel yoklama > HTTP ayarları > arka uç havuzudur.
Not: HTTP ayarlarında ve özel yoklamada yapılandırılan konak adları farklıysa, önceliğe göre SNI, özel yoklamadan konak adı olarak ayarlanır.
Arka uç havuzu adresi bir IP adresi (v1) ise veya özel yoklama ana bilgisayar adı IP adresi (v2) olarak yapılandırılmışsa SNI (server_name) ayarlanamaz.
Not: Bu durumda, arka uç sunucusu varsayılan/geri dönüş sertifikası döndürebilmelidir ve bu, kimlik doğrulama sertifikası altındaki HTTP ayarlarında izin ver listesinde olmalıdır. Arka uç sunucusunda yapılandırılmış varsayılan/geri dönüş sertifikası yoksa ve SNI bekleniyorsa, sunucu bağlantıyı sıfırlayabilir ve yoklama hatalarına yol açabilir
Daha önce bahsedilen öncelik sırasına göre, ana bilgisayar adı olarak IP adresleri varsa, SNI RFC 6066'ya göre ayarlanmayacaktır.
Not: Özel yoklama yapılandırılmamışsa ve HTTP ayarlarında veya arka uç havuzunda konak adı ayarlı değilse v2 yoklamalarında da SNI ayarlanamaz

Dekont

Özel bir yoklama yapılandırılmamışsa Application Gateway bu biçimde bir varsayılan yoklama gönderir: <protocol>://127.0.0.1:<port>/. Örneğin, varsayılan BIR HTTPS yoklaması için olarak https://127.0.0.1:443/gönderilir. Burada bahsedilen 127.0.0.1 yalnızca HTTP ana bilgisayar üst bilgisi olarak kullanılır ve RFC 6066'ya göre SNI üst bilgisi olarak kullanılmaz. Sistem durumu yoklaması hataları hakkında daha fazla bilgi için arka uç sistem durumu sorun giderme kılavuzuna bakın.

Canlı trafik için

Senaryo v1 v2
TLS el sıkışması sırasında FQDN olarak SNI (server_name) üst bilgisi Arka uç havuzundan FQDN olarak ayarlayın. RFC 6066'ya göre, SNI ana bilgisayar adında değişmez IPv4 ve IPv6 adreslerine izin verilmez.
Not: ARKA uç havuzundaki FQDN, DNS'nin arka uç sunucusunun IP adresine (genel veya özel) çözümlenmesi gerekir
SNI üst bilgisi (server_name) HTTP ayarlarından ana bilgisayar adı olarak ayarlanır, aksi takdirde PickHostnameFromBackendAddress seçeneği seçilirse veya ana bilgisayar adından bahsedilmediyse arka uç havuzu yapılandırmasında FQDN olarak ayarlanır
Arka uç havuzu adresi bir IP adresiyse veya ana bilgisayar adı HTTP ayarlarında ayarlanmadıysa Arka uç havuzu girişi bir FQDN değilse SNI RFC 6066'ya göre ayarlanamaz SNI, istemciden gelen giriş FQDN'sinden konak adı olarak ayarlanır ve arka uç sertifikasının CN'sinin bu ana bilgisayar adıyla eşleşmesi gerekir.
Http Ayarlar ana bilgisayar adı sağlanmamıştır, ancak arka uç havuzu üyesi için Hedef olarak bir FQDN belirtilir SNI, istemciden gelen giriş FQDN'sinden konak adı olarak ayarlanır ve arka uç sertifikasının CN'sinin bu ana bilgisayar adıyla eşleşmesi gerekir. SNI, istemciden gelen giriş FQDN'sinden konak adı olarak ayarlanır ve arka uç sertifikasının CN'sinin bu ana bilgisayar adıyla eşleşmesi gerekir.

Sonraki adımlar

Uçtan uca TLS hakkında bilgi edindikten sonra, uçtan uca TLS kullanarak uygulama ağ geçidi oluşturmak için PowerShell ile Application Gateway kullanarak uçtan uca TLS yapılandırma bölümüne gidin.