Ters proxy ile arka uç web uygulaması arasında özgün HTTP ana bilgisayar adını koruma

Web uygulamasının önünde ters ara sunucu kullanırken özgün HTTP ana bilgisayar adını korumanızı öneririz. Ters proxy'de arka uç uygulama sunucusuna sağlanandan farklı bir ana bilgisayar adı olması, düzgün çalışmayan tanımlama bilgilerine veya yeniden yönlendirme URL'lerine yol açabilir. Örneğin oturum durumu kaybolabilir, kimlik doğrulaması başarısız olabilir veya arka uç URL'leri yanlışlıkla son kullanıcılara gösterilebilir. Uygulama sunucusunun web tarayıcısıyla aynı etki alanını görmesi için ilk isteğin ana bilgisayar adını koruyarak bu sorunları önleyebilirsiniz.

Bu kılavuz özellikle Azure Uygulaması Hizmeti ve Azure Spring Apps gibi hizmet olarak platform (PaaS) tekliflerinde barındırılan uygulamalar için geçerlidir. Bu makalede yaygın olarak kullanılan ters ara sunucu hizmetleri olan Azure Uygulaması lication Gateway, Azure Front Door ve Azure API Management için özel uygulama yönergeleri sağlanmaktadır.

Uçtan uca TLS/SSL (ters proxy ile arka uç hizmeti arasındaki bağlantı HTTPS kullanır) gerekiyorsa, arka uç hizmetinin özgün ana bilgisayar adı için eşleşen bir TLS sertifikasına da ihtiyacı vardır. Bu gereksinim, sertifikaları dağıtıp yenilediğinizde işlem karmaşıklığını artırır, ancak birçok PaaS hizmeti tam olarak yönetilen ücretsiz TLS sertifikaları sunar.

Bağlam

HTTP isteğinin konağı

Çoğu durumda, istek işlem hattındaki uygulama sunucusu veya bazı bileşenler, tarayıcı tarafından erişilmesi için kullanılan internet etki alanı adına ihtiyaç duyar. Bu, isteğin ana bilgisayarıdır. Bir IP adresi olabilir, ancak genellikle gibi contoso.com bir addır (tarayıcı daha sonra DNS kullanarak bir IP adresine çözümler). Konak değeri genellikle tarayıcının uygulamaya HTTP üst bilgisi olarak gönderdiği istek URI'sinin konak bileşeninden Host belirlenir.

Bazı senaryolarda, özellikle de istek zincirinde bir HTTP ters ara sunucusu olduğunda, özgün ana bilgisayar üst bilgisi uygulama sunucusuna ulaşmadan önce değiştirilebilir. Ters ara sunucu istemci ağ oturumunu kapatır ve arka uca yeni bir bağlantı ayarlar. Bu yeni oturumda, istemci oturumunun özgün ana bilgisayar adını taşıyabilir veya yeni bir tane ayarlayabilir. İkinci durumda, proxy genellikle veya X-Forwarded-Hostgibi Forwarded diğer HTTP üst bilgilerinde özgün ana bilgisayar değerini göndermeye devam eder. Bu değer, uygulamaların özgün ana bilgisayar adını belirlemesine olanak tanır, ancak yalnızca bu üst bilgileri okuyacak şekilde kodlanmışlarsa.

Web platformları neden ana bilgisayar adını kullanır?

Çok kiracılı PaaS hizmetleri, gelen bir isteği uygun kiracının arka uç sunucusuna yönlendirmek için genellikle kayıtlı ve doğrulanmış bir ana bilgisayar adı gerektirir. Bunun nedeni genellikle tüm kiracılar için gelen istekleri kabul eden paylaşılan bir yük dengeleyici havuzu olmasıdır. Kiracılar genellikle gelen ana bilgisayar adını kullanarak müşteri kiracısı için doğru arka ucu arar.

Bu platformlar, kullanmaya başlamayı kolaylaştırmak için genellikle trafiği dağıtılan örneğine yönlendirmek için önceden yapılandırılmış bir varsayılan etki alanı sağlar. App Service için bu varsayılan etki alanı şeklindedir azurewebsites.net. Oluşturduğunuz her web uygulaması kendi alt etki alanına (örneğin, contoso.azurewebsites.net) sahip olur. Benzer şekilde, varsayılan etki alanı azuremicroservices.io Spring Apps ve azure-api.net API Management içindir.

Üretim dağıtımları için bu varsayılan etki alanlarını kullanmazsınız. Bunun yerine, kuruluşunuzun veya uygulamanızın markasıyla uyumlu olması için kendi etki alanınızı sağlarsınız. Örneğin, contoso.com arka planda App Service'te web uygulamasına contoso.azurewebsites.net çözümlenebilir, ancak bu etki alanının web sitesini ziyaret eden son kullanıcı tarafından görülememesi gerekir. Ancak platformun isteği yanıtlaması gereken arka uç sunucusunu tanımlayabilmesi için bu özel contoso.com ana bilgisayar adının PaaS hizmetine kaydedilmesi gerekir.

Uygulamalar neden ana bilgisayar adını kullanır?

Bir uygulama sunucusunun ana bilgisayar adına ihtiyacı olmasının iki yaygın nedeni, mutlak URL'ler oluşturmak ve belirli bir etki alanı için tanımlama bilgileri vermektir. Örneğin, uygulama kodunun şunları yapması gerektiğinde:

• HTTP yanıtında göreli URL yerine mutlak bir URL döndürür (ancak genellikle web siteleri mümkün olduğunda göreli bağlantıları işleme eğilimindedir).
• Web sitesinin bağlantısını kullanıcıya e-postayla göndermek gibi göreli URL'lerin kullanılamadığı HTTP yanıtının dışında kullanılacak bir URL oluşturun.
• Dış hizmet için mutlak bir yeniden yönlendirme URL'si oluşturun. Örneğin, başarılı bir kimlik doğrulamasından sonra kullanıcının nerede döndürülmesi gerektiğini belirtmek için Microsoft Entra ID gibi bir kimlik doğrulama hizmetine.
• Tanımlama bilgisinin özniteliğinde tanımlandığı gibi belirli bir ana bilgisayarla sınırlı HTTP tanımlama bilgileri Domain verme.

Uygulamanın yapılandırmasına beklenen ana bilgisayar adını ekleyerek ve istekte gelen ana bilgisayar adı yerine statik olarak tanımlanan değeri kullanarak tüm bu gereksinimleri karşılayabilirsiniz. Ancak bu yaklaşım, uygulama geliştirme ve dağıtım konularını karmaşıklaştırır. Ayrıca, uygulamanın tek bir yüklemesi birden çok ana bilgisayara hizmet verebilir. Örneğin, tek bir web uygulaması, tümü kendi benzersiz ana bilgisayar adlarına (ve gibi tenant1.contoso.comtenant2.contoso.com) sahip olan birden çok uygulama kiracısı için kullanılabilir.

Bazen de gelen ana bilgisayar adı, uygulama kodunun dışındaki bileşenler veya üzerinde tam denetime sahip olmadığınız uygulama sunucusundaki ara yazılımda kullanılır. Burada bazı örnekler verilmiştir:

• App Service'te, web uygulamanız için HTTPS'yi zorunlu kılabilirsiniz. Bunun yapılması güvenli olmayan http isteklerinin HTTPS'ye yeniden yönlendirilmesini sağlar. Bu durumda, gelen ana bilgisayar adı HTTP yeniden yönlendirmesinin üst bilgisinin mutlak URL'sini Location oluşturmak için kullanılır.
• Spring Apps, HTTPS'yi zorunlu kılmak için benzer bir özellik kullanır. Ayrıca HTTPS URL'sini oluşturmak için gelen ana bilgisayarı kullanır.
• App Service' in yapışkan oturumları etkinleştirmek için bir ARR benzimi ayarı vardır, böylece aynı tarayıcı örneğinden gelen istekler her zaman aynı arka uç sunucusu tarafından sunulur. Bu, HTTP yanıtına tanımlama bilgisi ekleyen App Service ön uçları tarafından gerçekleştirilir. Tanımlama bilgisi Domain gelen konağa ayarlanır.
• App Service, kullanıcıların API'lerde kolayca oturum açmasına ve verilere erişmesine olanak sağlayan kimlik doğrulaması ve yetkilendirme özellikleri sağlar.
  • Gelen ana bilgisayar adı, kimlik sağlayıcısının başarılı kimlik doğrulamasından sonra kullanıcıyı döndürmesi gereken yeniden yönlendirme URL'sini oluşturmak için kullanılır.
  • Bu özelliğin varsayılan olarak etkinleştirilmesi, HTTP'den HTTPS'ye yeniden yönlendirmeyi de açar. Yeniden yönlendirme konumunu oluşturmak için gelen ana bilgisayar adı kullanılır.

Neden konak adını geçersiz kılmak isteyebilirsiniz?

App Service'te varsayılan etki alanı olan bir web uygulaması oluşturduğunuzu contoso.azurewebsites.netvarsayalım. (Veya Spring Apps gibi başka bir hizmette.) App Service'te özel bir etki alanı yapılandırmadınız. Application Gateway (veya benzer bir hizmet) gibi bir ters proxy'yi bu uygulamanın önüne koymak için, çözümlenmesi için contoso.com DNS kaydını Application Gateway'in IP adresine ayarlarsınız. Bu nedenle, isteği contoso.com tarayıcıdan alır ve bu isteği şu çözümlenen IP adresine contoso.azurewebsites.net iletecek şekilde yapılandırılır: bu, istenen ana bilgisayar için son arka uç hizmetidir. Ancak bu durumda App Service özel etki alanını tanımaz contoso.com ve bu konak adı için gelen tüm istekleri reddeder. İsteğin nereye yönlendirileceğini belirleyemiyor.

Bu yapılandırmanın çalışmasını sağlamanın kolay yolu, Application Gateway'de HTTP isteğinin Host üst bilgisini geçersiz kılmak veya yeniden yazmak ve değerine contoso.azurewebsites.netayarlamak gibi görünebilir. Bunu yaparsanız, Application Gateway'den gelen giden istek, özgün isteğin yerine contoso.comgerçekten hedeflenmiş contoso.azurewebsites.net gibi görünmesini sağlar:

Bu noktada App Service konak adını tanır ve özel bir etki alanı adının yapılandırılmasını gerektirmeden isteği kabul eder. Aslında Application Gateway, arka uç havuzunun konağıyla konak üst bilgisini geçersiz kılmayı kolaylaştırır. Azure Front Door bunu varsayılan olarak bile yapar.

Ancak bu çözümle ilgili sorun, uygulama özgün ana bilgisayar adını görmediğinde çeşitli sorunlara yol açabilir.

Olası sorunlar

Yanlış mutlak URL'ler

Özgün ana bilgisayar adı korunmazsa ve uygulama sunucusu mutlak URL'ler oluşturmak için gelen ana bilgisayar adını kullanırsa, arka uç etki alanı son kullanıcıya açıklanabilir. Bu mutlak URL'ler uygulama kodu tarafından veya daha önce belirtildiği gibi App Service ve Spring Apps'te HTTP'den HTTPS'ye yeniden yönlendirme desteği gibi platform özellikleriyle oluşturulabilir. Bu diyagramda sorun gösterilmektedir:

1. Tarayıcı, ters ara sunucuya için contoso.com bir istek gönderir.
2. Ters proxy, istekte ana bilgisayar adını contoso.azurewebsites.net arka uç web uygulamasına (veya başka bir hizmet için benzer bir varsayılan etki alanına) yeniden yazar.
3. Uygulama, gelen contoso.azurewebsites.net ana bilgisayar adını temel alan mutlak bir URL oluşturur, örneğin, https://contoso.azurewebsites.net/.
4. Tarayıcı bu URL'yi izler ve bu URL' de ters ara contoso.comsunucu yerine doğrudan arka uç hizmetine gider.

Bu durum, ters proxy'nin web uygulaması güvenlik duvarı olarak da görev yaptığı yaygın durumlarda güvenlik riski bile doğurabilir. Kullanıcı doğrudan arka uç uygulamasına giden ve ters ara sunucuyu atlayan bir URL alır.

Yanlış yeniden yönlendirme URL'leri

Mutlak yeniden yönlendirme URL'leri oluşturulduğunda önceki senaryoya ilişkin yaygın ve daha belirgin bir durum oluşur. Bu URL'ler OpenID Bağlan, OAuth 2.0 veya SAML 2.0 gibi tarayıcı tabanlı kimlik protokollerini kullandığınızda Microsoft Entra Id gibi kimlik hizmetleri için gereklidir. Bu yeniden yönlendirme URL'leri, uygulama sunucusu veya ara yazılım tarafından veya daha önce belirtildiği gibi App Service kimlik doğrulaması ve yetkilendirme özellikleri gibi platform özellikleri tarafından oluşturulabilir. Bu diyagramda sorun gösterilmektedir:

1. Tarayıcı, ters ara sunucuya için contoso.com bir istek gönderir.
2. Ters ara sunucu, istekte ana bilgisayar adını contoso.azurewebsites.net arka uç web uygulamasına (veya başka bir hizmet için benzer bir varsayılan etki alanına) yeniden yazar.
3. Uygulama, gelen contoso.azurewebsites.net ana bilgisayar adını temel alan mutlak bir yeniden yönlendirme URL'si oluşturur. Örneğin, https://contoso.azurewebsites.net/.
4. Tarayıcı, kullanıcının kimliğini doğrulamak için kimlik sağlayıcısına gider. İstek, başarılı kimlik doğrulamasından sonra kullanıcının döndürüleceği yeri belirtmek için oluşturulan yeniden yönlendirme URL'sini içerir.
5. Kimlik sağlayıcıları genellikle yeniden yönlendirme URL'lerinin ön sırada kaydedilmesini gerektirir, bu nedenle bu noktada kimlik sağlayıcısının isteği reddetmesi gerekir çünkü sağlanan yeniden yönlendirme URL'si kaydedilmez. (Kullanılmaması gerekiyordu.) Ancak, bir nedenle yeniden yönlendirme URL'si kayıtlıysa, kimlik sağlayıcısı tarayıcıyı kimlik doğrulama isteğinde belirtilen yeniden yönlendirme URL'sine yönlendirir. Bu durumda, URL şeklindedir https://contoso.azurewebsites.net/.
6. Tarayıcı, ters ara sunucu yerine doğrudan arka uç hizmetine giden bu URL'yi izler.

Bozuk tanımlama bilgileri

Ana bilgisayar adı uyuşmazlığı, uygulama sunucusu tanımlama bilgileri verildiğinde ve tanımlama bilgisinin özniteliğini oluşturmak Domain için gelen ana bilgisayar adını kullandığında da sorunlara yol açabilir. Domain özniteliği, tanımlama bilgisinin yalnızca ilgili etki alanı için kullanılmasını sağlar. Bu tanımlama bilgileri uygulama kodu tarafından veya daha önce belirtildiği gibi App Service ARR benzinim ayarı gibi platform özellikleri tarafından oluşturulabilir. Bu diyagramda sorun gösterilmektedir:

1. Tarayıcı, ters ara sunucuya için contoso.com bir istek gönderir.
2. Ters ara sunucu, arka uç web uygulamasına (veya başka bir hizmet için benzer bir varsayılan etki alanına) istekte bulunmak contoso.azurewebsites.net üzere ana bilgisayar adını yeniden yazar.
3. Uygulama, gelen contoso.azurewebsites.net ana bilgisayar adına göre etki alanı kullanan bir tanımlama bilgisi oluşturur. Tarayıcı, kullanıcının gerçekten kullandığı etki alanı yerine contoso.com bu belirli etki alanı için tanımlama bilgisini depolar.
4. Tanımlama bilgisinin etki alanı isteğin etki alanıyla eşleşmediğinden tarayıcı sonraki isteklerde contoso.com tanımlama bilgisini contoso.azurewebsites.net içermez. Uygulama daha önce yayımladığı tanımlama bilgisini almaz. Sonuç olarak, kullanıcı tanımlama bilgisinde olması gereken durumu kaybedebilir veya ARR benzimliği gibi özellikler çalışmaz. Ne yazık ki, bu sorunların hiçbiri hata oluşturmaz veya doğrudan son kullanıcı tarafından görülebilir. Bu, sorun gidermeyi zorlaştırıyor.

Yaygın Azure hizmetleri için uygulama kılavuzu

Burada ele alınan olası sorunları önlemek için, ters proxy ile arka uç uygulama sunucusu arasındaki çağrıda özgün ana bilgisayar adını korumanızı öneririz:

Arka uç yapılandırması

Birçok web barındırma platformu, izin verilen gelen konak adlarını açıkça yapılandırmanızı gerektirir. Aşağıdaki bölümlerde, en yaygın Azure hizmetleri için bu yapılandırmanın nasıl uygulandığı açıklanmaktadır. Diğer platformlar genellikle özel etki alanlarını yapılandırmak için benzer yöntemler sağlar.

Web uygulamanızı App Service'te barındıracaksanız, web uygulamasına özel bir etki alanı adı ekleyebilir ve arka uca doğru varsayılan azurewebsites.net ana bilgisayar adını kullanmaktan kaçınabilirsiniz. Web uygulamasına özel bir etki alanı eklerken DNS çözümlemenizi değiştirmeniz gerekmez: Normal veya A kayıtlarınızı etkilemeden bir TXT kayıt kullanarak etki alanını doğrulayabilirsinizCNAME. (Bu kayıtlar yine de ters proxy'nin IP adresine çözümlenir.) Uçtan uca TLS/SSL gerekiyorsa, Key Vault'tan mevcut bir sertifikayı içeri aktarabilir veya özel etki alanınız için app service sertifikası kullanabilirsiniz. (Ücretsiz Etki alanının DNS kaydının ters proxy'ye değil doğrudan App Service'e çözümlenmesi gerektirdiğinden App Service tarafından yönetilen sertifika bu durumda kullanılamaz.)

Benzer şekilde, Spring Apps kullanıyorsanız, konak adını kullanmaktan azuremicroservices.io kaçınmak için uygulamanız için özel bir etki alanı kullanabilirsiniz. Uçtan uca TLS/SSL gerekiyorsa mevcut veya otomatik olarak imzalanan bir sertifikayı içeri aktarabilirsiniz.

API Management'ın önünde ters proxy'niz varsa (kendisi de ters ara sunucu işlevi görür), konak adını kullanmaktan azure-api.net kaçınmak için API Management örneğinizde özel bir etki alanı yapılandırabilirsiniz. Uçtan uca TLS/SSL gerekiyorsa mevcut veya ücretsiz yönetilen sertifikayı içeri aktarabilirsiniz. Ancak daha önce belirtildiği gibi, API'ler konak adı uyuşmazlıklarının neden olduğu sorunlara daha az duyarlıdır, bu nedenle bu yapılandırma o kadar önemli olmayabilir.

Uygulamalarınızı Kubernetes veya doğrudan sanal makineler gibi diğer platformlarda barındırıyorsanız, gelen ana bilgisayar adına bağlı yerleşik bir işlev yoktur. Ana bilgisayar adının uygulama sunucusunun kendisinde nasıl kullanıldığından siz sorumlusunuz. Ana bilgisayar adını koruma önerisi, uygulamanızın ters proxy'leri özellikle tanımasını ve veya üst bilgilerine saygı forwardedX-Forwarded-Host duymasını sağlamadığınız sürece, uygulamanızda buna bağlı olan bileşenler için genellikle geçerlidir.

Ters proxy yapılandırması

Arka uçları ters ara sunucu içinde tanımladığınızda, arka uç hizmetinin varsayılan etki alanını kullanmaya devam edebilirsiniz; örneğin, https://contoso.azurewebsites.net/. Bu URL, arka uç hizmetinin doğru IP adresini çözümlemek için ters ara sunucu tarafından kullanılır. Platformun varsayılan etki alanını kullanırsanız, IP adresinin her zaman doğru olduğu garanti edilir. Genel kullanıma yönelik etki alanını genellikle kullanamazsınız, contoso.comçünkü bunun ters proxy'nin IP adresine çözümlenmesi gerekir. (Split-horizon DNS gibi daha gelişmiş DNS çözümleme teknikleri kullanmadığınız sürece).

Çoğu ters proxy, arka uç hizmetine hangi ana bilgisayar adının geçirildiğini yapılandırmanıza olanak sağlar. Aşağıdaki bilgiler, en yaygın Azure hizmetleri için gelen isteğin özgün ana bilgisayar adının kullanılmasının nasıl sağlandığını açıklar.

Application Gateway

Ters proxy olarak Application Gateway kullanıyorsanız, arka uç HTTP ayarında Yeni ana bilgisayar adıyla geçersiz kıl ayarını devre dışı bırakarak özgün ana bilgisayar adının korundığından emin olabilirsiniz. Bunu yaptığınızda hem Arka uç adresinden konak adı seç hem de Belirli bir etki alanı adıyla Geçersiz Kıl devre dışı bırakılır. (Bu ayarların her ikisi de konak adını geçersiz kılar.) Application Gateway için Azure Resource Manager özelliklerinde, bu yapılandırma özelliğinin hostNamenull ve pickHostNameFromBackendAddress olarak ayarlanmasına falsekarşılık gelir.

Sistem durumu yoklamaları gelen isteğin bağlamının dışına gönderildiğinden, doğru ana bilgisayar adını dinamik olarak belirleyemezler. Bunun yerine, özel bir sistem durumu yoklaması oluşturmanız, Arka uç HTTP ayarlarından ana bilgisayar adı seçin ayarını devre dışı bırakmanız ve konak adını açıkça belirtmeniz gerekir. Bu konak adı için tutarlılık için uygun bir özel etki alanı da kullanmalısınız. (Ancak, sistem durumu yoklamaları yanlış tanımlama bilgilerini yoksaydığından veya yanıttaki URL'leri yeniden yönlendirdiğinden burada barındırma platformunun varsayılan etki alanını kullanabilirsiniz.)

Azure Front Door

Azure Front Door kullanıyorsanız arka uç konak üst bilgisini arka uç havuzu tanımında boş bırakarak konak adını geçersiz kılmaktan kaçınabilirsiniz. Arka uç havuzunun Resource Manager tanımında, bu yapılandırma ayarına backendHostHeadernullkarşılık gelir.

Azure Front Door Standard veya Premium kullanıyorsanız, kaynak ana bilgisayar üst bilgisini kaynak tanımında boş bırakarak konak adını koruyabilirsiniz. Kaynağın Resource Manager tanımında, bu yapılandırma ayarına originHostHeadernullkarşılık gelir.

API Management

Varsayılan olarak, API Management arka uca gönderilen ana bilgisayar adını API'nin web hizmeti URL'sinin ana bilgisayar bileşeniyle geçersiz kılar (API'nin Resource Manager tanımının değerine karşılık gelirserviceUrl).

Aşağıdaki gibi bir inboundHTTP üst bilgi ilkesi ayarlayarak API Management'ı gelen isteğin ana bilgisayar adını kullanmaya zorlayabilirsiniz:

<inbound>
  <base />
  <set-header name="Host" exists-action="override">
    <value>@(context.Request.OriginalUrl.Host)</value>
  </set-header>
</inbound>

Ancak daha önce belirtildiği gibi, API'ler konak adı uyuşmazlıklarının neden olduğu sorunlara daha az duyarlıdır, bu nedenle bu yapılandırma o kadar önemli olmayabilir.

Sonraki adımlar

• App Service
• Spring Apps
• Application Gateway
• Azure Front Door
• API Management

İlgili kaynaklar

• Azure Güvenlik Duvarı ve Application Gateway ile web uygulamaları için sıfır güven ağı
• Application Gateway ve API Management ile API'leri koruma
• App Services Ortamı'nın kullanıldığı kurumsal dağıtım