Översikt över TLS-avslutning och TLS från Application Gateway

Transport Layer Security (TLS), tidigare kallat Secure Sockets Layer (SSL), är standardsäkerhetstekniken för att upprätta en krypterad länk mellan en webbserver och en webbläsare. Den här länken säkerställer att alla data som skickas mellan webbservern och webbläsarna förblir privata och krypterade. Application Gateway stöder både TLS-avslutning vid gatewayen samt TLS-kryptering från slutpunkt till slutpunkt.

TLS-avslutning

Application Gateway har stöd för TLS-avslutning vid gatewayen, varpå trafiken vanligtvis flödar okrypterat till backend-servrarna. Det finns ett antal fördelar med att göra TLS-avslutning vid programgatewayen:

• Bättre prestanda – Den största prestandan när du utför TLS-dekryptering är den första handskakningen. För att förbättra prestandan cachelagrar servern TLS-sessions-ID:er och hanterar TLS-sessionsbiljetter. Om detta görs på programgatewayen kan alla begäranden från samma klient använda de cachelagrade värdena. Om det görs på backend-servrarna måste klienten autentiseras igen varje gång klientens begäranden går till en annan server. Användning av TLS-biljetter kan hjälpa till att åtgärda det här problemet, men de stöds inte av alla klienter och kan vara svåra att konfigurera och hantera.
• Bättre användning av backend-servrarna – SSL/TLS-bearbetningen är mycket processorintensiv och blir mer intensiv allt eftersom nyckelstorlekarna ökar. Genom att ta bort det här arbetet från backend-servrarna kan de fokusera på vad de är effektivast på och leverera innehåll.
• Intelligent routning – Genom att dekryptera trafiken har programgatewayen åtkomst till begärandeinnehållet, till exempel rubriker, URI och så vidare, och kan använda dessa data för att dirigera begäranden.
• Certifikathantering – Certifikat behöver bara köpas och installeras på programgatewayen och inte alla backend-servrar. Detta sparar både tid och pengar.

För att konfigurera TLS-avslutning måste ett TLS/SSL-certifikat läggas till i lyssnaren. Detta gör att Application Gateway dekrypterar inkommande trafik och krypterar svarstrafiken till klienten. Certifikatet som tillhandahålls till Application Gateway måste vara i PFX-format (Personal Information Exchange), som innehåller både privata och offentliga nycklar.

För att TLS-anslutningen ska fungera måste du se till att TLS/SSL-certifikatet uppfyller följande villkor:

• Att aktuellt datum och tid ligger inom datumintervallet "Giltig från" och "Giltig till" för certifikatet.
• Att certifikatets ”vanliga namn” (CN) matchar värdhuvudet i begäran. Exempelvis om klienten gör en begäran till https://www.contoso.com/, måste CN vara www.contoso.com.

Certifikat som stöds för TLS-avslutning

Application Gateway stöder följande typer av certifikat:

• CA-certifikat (certifikatutfärdare): Ett CA-certifikat är ett digitalt certifikat utfärdat av en certifikatutfärdare (CA)
• EV-certifikat (utökad validering): Ett EV-certifikat är ett certifikat som följer riktlinjerna för branschstandardcertifikat. Då blir webbläsarens positionerarfält grönt och även företagets namn publiceras.
• Jokerteckencertifikat: Det här certifikatet stöder val av antal underdomäner baserat på *.site.com, där din underdomän ersätter *. Det stöder dock inte site.com, så om användarna kommer åt din webbplats utan att skriva inledande "www" kommer jokerteckencertifikatet inte att omfatta det.
• Self-Signed certifikat: Klientwebbläsare litar inte på dessa certifikat och varnar användaren om att den virtuella tjänstens certifikat inte ingår i en förtroendekedja. Själv signerade certifikat är bra för testning eller miljöer där administratörer styr klienterna och på ett säkert sätt kan kringgå webbläsarens säkerhetsaviseringar. Produktionsarbetsbelastningar bör aldrig använda själv signerade certifikat.

Mer information finns i Konfigurera TLS-avslutning med Application Gateway.

Certifikatets storlek

I avsnittet Application Gateway för att se vilken maximal TLS-/SSL-certifikatstorlek som stöds.

TLS-kryptering från slutpunkt till slutpunkt

Du kanske inte vill ha okrypterad kommunikation till backend-servrarna. Du kan ha säkerhetskrav, efterlevnadskrav eller så kanske programmet bara accepterar en säker anslutning. Azure Application Gateway har TLS-kryptering från slutpunkt till slutpunkt som stöd för dessa krav.

Med TLS från end-to-end kan du kryptera och på ett säkert sätt överföra känsliga data till Application Gateway samtidigt som du använder layer-7-funktionerna för belastningsutjämning. Dessa funktioner omfattar cookiebaserad sessionstillhörighet, URL-baserad routning, stöd för routning baserat på webbplatser, möjligheten att skriva om eller mata in X-Forwarded-* huvuden och så vidare.

När TLS-kommunikationsläget är konfigurerat från början till slut Application Gateway TLS-sessionerna vid gatewayen och dekrypterar användartrafiken. Därefter appliceras de konfigurerade reglerna för att välja en lämplig serverdels-serverpoolinstans att dirigera trafiken till. Application Gateway sedan en ny TLS-anslutning till backend-servern och krypterar om data med hjälp av serverserverns offentliga nyckelcertifikat innan begäran överförs till serverservern. Eventuella svar från webbservern genomgår samma process på väg tillbaka till användaren. TLS från end-to-end aktiveras genom att ange protokollinställningen i HTTP-inställningen för backend till HTTPS, som sedan tillämpas på en backend-pool.

För Application Gateway och WAF v1 SKU gäller TLS-principen för både trafik på både frontend- och backend-trafik. På frontend Application Gateway fungerar som server och tillämpar principen. På serversidan fungerar Application Gateway som klient och skickar protokoll-/chifferinformation som inställning under TLS-handskakningen.

För SKU:n Application Gateway och WAF v2 gäller TLS-principen endast för klientdelstrafiken och alla chiffer erbjuds till serverdelsservern, som har kontroll över att välja specifika chiffer och TLS-version under handskakningen.

Application Gateway kommunicerar bara med de backend-servrar som antingen har tillåtet sina certifikat med Application Gateway eller vars certifikat signeras av välkända CA-utfärdare och certifikatets CN matchar värdnamnet i HTTP-serverinställningarna. Dessa omfattar betrodda Azure-tjänster som Azure App Service/Web Apps och Azure API Management.

Om certifikaten för medlemmarna i serverpoolen inte signeras av välkända CA-utfärdare, måste varje instans i serverpoolen med TLS från end till end vara aktiverad konfigurerad med ett certifikat för att tillåta säker kommunikation. Genom att lägga till certifikatet säkerställer du att programgatewayen endast kommunicerar med kända serverinstanser. Detta skyddar ytterligare kommunikationen från ena änden till slutet.

I det här exemplet dirigeras begäranden som använder TLS1.2 till backend-servrar i Pool1 med hjälp av TLS från end till end.

TLS från slut till slut och tillåt att certifikat listas

Application Gateway kommunicerar bara med kända serverinstanser som har tillåtet angivna certifikat med programgatewayen. Det finns vissa skillnader i TLS-konfigurationsprocessen från slutet till slut vad gäller vilken version av Application Gateway används. I följande avsnitt förklaras de individuellt.

TLS från end-to-end med v1-SKU:n

Om du vill aktivera TLS från end-to-end till backend-servrarna och för Application Gateway att dirigera begäranden till dem, måste hälsoavsökningarna lyckas och returnera felfritt svar.

För HTTPS-hälsoavsökningar använder SKU:n Application Gateway v1 en exakt matchning av autentiseringscertifikatet (offentlig nyckel för servercertifikatet och inte rotcertifikatet) som ska överföras till HTTP-inställningarna.

Endast anslutningar till kända och tillåtna backends tillåts sedan. De återstående backends betraktas som felaktiga av hälsoavsökningarna. Självsignerade certifikat är enbart för testningsändamål och rekommenderas inte för produktions-arbetsbelastningar. Sådana certifikat måste tillåtas i listan med programgatewayen enligt beskrivningen i föregående steg innan de kan användas.

TLS från slutet till slut med v2-SKU:n

Autentiseringscertifikat har gjorts inaktuella och ersatts av betrodda rotcertifikat i Application Gateway v2 SKU. De fungerar på samma sätt som autentiseringscertifikat med några viktiga skillnader:

• Certifikat som signerats av välkända CA-utfärdare vars CN matchar värdnamnet i HTTP-serverinställningarna kräver inte något ytterligare steg för att TLS från slut till slut ska fungera.

  Om servercertifikaten till exempel utfärdas av en välkänd certifikatutfärdare och har ett CN på contoso.com, och http-inställningens värdfält för serveruppsättningen också är inställt på contoso.com, krävs inga ytterligare steg. Du kan ange HTTP-inställningsprotokollet för backend till HTTPS, och både hälsoavsökningen och datasökvägen skulle vara TLS-aktiverad. Om du använder Azure App Service eller andra Azure-webbtjänster som din backend, är dessa implicit betrodda och inga ytterligare steg krävs för TLS från slutet till slut.

• Om servercertifikatet är själv signerat eller signerat av okänd certifikatutfärdare/-utfärdare måste ett betrott rotcertifikat överföras för att aktivera TLS från Application Gateway till slut i Application Gateway v2. Application Gateway kommunicerar endast med serverservrar vars servercertifikats rotcertifikat matchar en av listan över betrodda rotcertifikat i backend http-inställningen som är associerad med poolen.

• Förutom rotcertifikatmatchningen verifierar Application Gateway v2 även om inställningen Värd som anges i http-inställningen för serverdatorn matchar det eget namn (CN) som presenteras av serverplatsens TLS/SSL-certifikat. När du försöker upprätta en TLS-anslutning till Application Gateway v2 anger Servernamnindikator-tillägget (SNI) till den värd som anges i http-inställningen för backend.

• Om du väljer värddatornamn från serverpartsmålet i stället för fältet Värd i http-inställningen för serveruppsättningen är SNI-huvudet alltid inställt på serverpoolens FQDN och CN på backend-serverns TLS/SSL-certifikat måste matcha dess FQDN. Medlemmar i backend-pooler med IP-adresser stöds inte i det här scenariot.

• Rotcertifikatet är ett base64-kodat rotcertifikat från serverdelscertifikaten.

SNI-skillnader i SKU:n v1 och v2

Som tidigare nämnts avslutar Application Gateway TLS-trafik från klienten på Application Gateway-lyssnaren (vi kallar den klientanslutningen), dekrypterar trafiken, tillämpar de nödvändiga reglerna för att fastställa vilken serverserver som begäran måste vidarebefordras till och upprättar en ny TLS-session med serversidan (vi kallar den för serverdanslutningen).

I följande tabeller beskrivs skillnaderna i SNI mellan v1- och v2-SKU:n vad gäller anslutningar mellan frontend och backend.

Klient-TLS-anslutning (klient till programgateway)

Backend-TLS-anslutning (programgateway till backend-servern)

För avsökningstrafik

För livetrafik

Nästa steg

När du har lärt dig mer om TLS från slutet till slut går du till Konfigurera TLS från slutet till slut med hjälp av Application Gateway med PowerShell för att skapa en programgateway med hjälp av TLS från slutet till slut.