Dela via

TLS-kryptering med Azure Front Door

Transport Layer Security (TLS), tidigare känt som Secure Sockets Layer (SSL), är standardsäkerhetstekniken för att upprätta en krypterad länk mellan en webbserver och en klient, till exempel en webbläsare. Den här länken säkerställer att alla data som skickas mellan servern och klienten förblir privata och krypterade.

För att uppfylla dina säkerhets- eller efterlevnadskrav stöder Azure Front Door TLS-kryptering från slutpunkt till slutpunkt. Front Door TLS/SSL-avlastning avslutar TLS-anslutningen, dekrypterar trafiken vid Azure Front Door och krypterar trafiken igen innan den vidarebefordras till ursprunget. När anslutningar till ursprunget använder ursprungets offentliga IP-adress är det en bra säkerhetspraxis att konfigurera HTTPS som vidarebefordringsprotokoll i Azure Front Door. Genom att använda HTTPS som vidarebefordranprotokoll kan du framtvinga TLS-kryptering från slutpunkt till slutpunkt för hela bearbetningen av begäran från klienten till ursprunget. TLS/SSL-avlastning stöds också om du distribuerar ett privat ursprung med Azure Front Door Premium med funktionen Private Link .

Den här artikeln förklarar hur Azure Front Door fungerar med TLS-anslutningar. Mer information om hur du använder TLS-certifikat med egna anpassade domäner finns i HTTPS för anpassade domäner. Information om hur du konfigurerar ett TLS-certifikat på din egen anpassade domän finns i Konfigurera en anpassad domän i Azure Front Door med hjälp av Azure Portal.

TLS-kryptering från slutpunkt till slutpunkt

Med TLS från slutpunkt till slutpunkt kan du skydda känsliga data under överföring till ursprunget samtidigt som du drar nytta av Azure Front Door-funktioner som global belastningsutjämning och cachelagring. Några av funktionerna omfattar även URL-baserad routning, TCP-delning, cachelagring på gränsen som är närmast klienterna och anpassning av HTTP-begäranden vid gränsen.

Azure Front Door avlastar TLS-sessionerna vid gränsen och dekrypterar klientbegäranden. Sedan tillämpas de konfigurerade routningsreglerna för att dirigera begäranden till lämpligt ursprung i ursprungsgruppen. Azure Front Door startar sedan en ny TLS-anslutning till ursprunget och krypterar om alla data med ursprungets certifikat innan begäran skickas till ursprunget. Alla svar från ursprunget krypteras via samma process tillbaka till slutanvändaren. Du kan konfigurera Azure Front Door att använda HTTPS som vidarebefordranprotokoll för att aktivera TLS från slutpunkt till slutpunkt.

TLS-versioner som stöds

Azure Front Door stöder två versioner av TLS-protokollet: TLS-versionerna 1.2 och 1.3. Alla Azure Front Door-profiler som skapats efter september 2019 använder TLS 1.2 som standardminimum med TLS 1.3 aktiverat. För närvarande stöder Inte Azure Front Door klient-/ömsesidig autentisering (mTLS).

Viktigt!

Från och med den 1 mars 2025 är TLS 1.0 och 1.1 inte tillåtna för nya Azure Front Door-profiler.

För Azure Front Door Standard och Premium kan du konfigurera fördefinierade TLS-principer eller välja TLS-chiffersviten baserat på organisationens säkerhetsbehov. Mer information finns i Azure Front Door TLS-principen och konfigurera TLS-principen på en anpassad Front oor-domän.

För klassiska Azure Front Door- och Microsoft CDN-klassiker kan du konfigurera den lägsta TLS-versionen i Azure Front Door i HTTPS-inställningarna för den anpassade domänen med hjälp av Azure-portalen eller Azure REST API. För en lägsta TLS-version på 1.2 kommer processen att försöka upprätta TLS 1.3 och sedan TLS 1.2. När Azure Front Door initierar TLS-trafik till ursprunget försöker den förhandla fram den bästa TLS-versionen som ursprunget kan acceptera på ett tillförlitligt och konsekvent sätt. TLS-versioner som stöds för ursprungsanslutningar är TLS 1.2 och TLS 1.3. Om du vill anpassa chiffersviten efter behov migrera Front Door Classic och Microsoft CDN Classic till Azure Front Door standard och premium.

Anteckning

  • Klienter med TLS 1.3 aktiverat krävs för att stödja en av Microsoft SDL-kompatibla EC-kurvor, inklusive Secp384r1, Secp256r1 och Secp521, för att kunna göra begäranden med Azure Front Door med hjälp av TLS 1.3.
  • Vi rekommenderar att klienter använder en av dessa kurvor som föredragen kurva vid förfrågningar för att undvika ökad fördröjning i TLS-handskakningen, vilket kan bero på flera rundor för att förhandla om den EC-kurva som stöds.

Certifikat som stöds

När du skapar ditt TLS/SSL-certifikat måste du skapa en fullständig certifikatkedja med en tillåten certifikatutfärdare (CA) som ingår i Microsofts lista över betrodda certifikatutfärdare. Om du använder en icke tillåten certifikatutfärdare kan din begäran avvisas.

Certifikat från interna certifikatutfärdare eller självsignerade certifikat tillåts inte.

Online Certificate Status Protocol (OCSP) sammanfogning

OCSP-häftning stöds som standard i Azure Front Door och ingen konfiguration krävs.

Origin TLS-anslutning (Azure Front Door mot ursprungsserver)

För HTTPS-anslutningar förväntar sig Azure Front Door att ditt ursprung visar ett certifikat från en giltig certifikatutfärdare (CA) med ett ämnesnamn som matchar ursprungsvärdens namn. Om ditt ursprungsvärdnamn till exempel är inställt på myapp-centralus.contoso.net och certifikatet som ditt ursprung visar under TLS-handskakningen inte har myapp-centralus.contoso.net eller *.contoso.net i ämnesnamnet, nekar Azure Front Door anslutningen och klienten ser ett fel.

Anteckning

Certifikatet måste ha en fullständig certifikatkedja med slutcertifikat och mellanliggande certifikat. Rotcertifikaten måste vara en del av Microsofts lista över betrodda certifikatutfärdare. Om ett certifikat utan fullständig kedja visas kommer de begäranden som omfattar certifikatet inte att fungera som förväntat.

I vissa användningsfall, till exempel testning, kan du inaktivera kontroller av certifikatets ämnesnamn för din Azure Front Door som en lösning för att undvika misslyckade HTTPS-anslutningar. Ursprunget måste fortfarande presentera ett certifikat med en giltig, betrodd kedja, men det behöver inte matcha värdnamnet för ursprunget.

I Azure Front Door Standard och Premium kan du konfigurera ett ursprung för att inaktivera certifikatmottagarens namnkontroll.

I Azure Front Door (klassisk) kan du inaktivera certifikatmottagarens namnkontroll genom att ändra inställningarna för Azure Front Door i Azure Portal. Du kan också konfigurera kontrollen med hjälp av serverdelspoolens inställningar i Azure Front Door-API:erna.

Anteckning

Från säkerhetssynpunkt rekommenderar Microsoft inte att du inaktiverar certifikatmottagarens namnkontroll.

TLS-anslutning för front-end (klient till Azure Front Door)

Om du vill aktivera HTTPS-protokollet för säker leverans av innehåll på en anpassad Azure Front Door-domän kan du välja att använda ett certifikat som hanteras av Azure Front Door eller använda ditt eget certifikat.

Mer information finns i HTTPS för anpassade domäner.

Azure Front Door hanterade certifikat tillhandahåller ett TLS/SSL-standardcertifikat via DigiCert och lagras i Key Vault i Azure Front Door.

Om du väljer att använda ett eget certifikat kan du anskaffa ett certifikat från en stöttad certifikatutfärdare som kan vara ett vanligt TLS-certifikat, ett utökat valideringscertifikat, eller till och med ett wildcard certifikat. Självsignerade certifikat stöds inte. Lär dig hur du aktiverar HTTPS för en anpassad domän.

Autorotation av certifikat

För det hanterade certifikatalternativet i Azure Front Door hanteras certifikaten och roteras automatiskt inom 90 dagar efter att Azure Front Door har upphört att gälla. För alternativet Azure Front Door Standard/Premium-hanterat certifikat hanteras certifikaten och roteras automatiskt inom 45 dagar efter förfallotiden av Azure Front Door. Om du använder ett Hanterat Azure Front Door-certifikat och ser att certifikatets utgångsdatum är mindre än 60 dagar eller 30 dagar för Standard/Premium SKU kan du skicka in ett supportärende.

För ditt eget anpassade TLS/SSL-certifikat:

  1. Ange den hemliga versionen till "Senaste" för att certifikatet ska roteras automatiskt till den senaste versionen när en nyare version av certifikatet är tillgänglig i ditt nyckelvalv. För anpassade certifikat roteras certifikatet automatiskt inom 3–4 dagar med en nyare version av certifikatet, oavsett vad certifikatets utgångna tid är.

  2. Om en viss version har valts stöds inte autorotation. Du måste välja den nya versionen manuellt för att rotera certifikatet. Det tar upp till 24 timmar innan den nya versionen av certifikatet/hemligheten distribueras.

    Anteckning

    Hanterade Azure Front Door-certifikat (Standard och Premium) roteras automatiskt om domänens CNAME-post pekar direkt till en Front Door-slutpunkt eller indirekt pekar på en Traffic Manager-slutpunkt. Annars måste du verifiera domänägarskapet igen för att rotera certifikaten.

    Tjänsthuvudmannen för Front Door måste ha åtkomst till nyckelvalvet. Den uppdaterade distributionsåtgärden för certifikat från Azure Front Door orsakar ingen produktionsavbrott, så länge certifikatets ämnesnamn eller alternativt namn (SAN) för certifikatet inte har ändrats.

Chiffersviter som stöds

För TLS 1.2/1.3 stöds följande chiffersviter:

  • TLS_AES_256_GCM_SHA384 (TLS 1.3 endast)
  • TLS_AES_128_GCM_SHA256 (endast TLS 1.3)
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

Anteckning

Gamla TLS-versioner och svaga chiffer stöds inte längre.

Använd TLS-princip för att konfigurera specifika chiffersviter. Azure Front Door Standard och Premium erbjuder två mekanismer för att kontrollera TLS-principen: du kan använda antingen en fördefinierad princip eller en anpassad princip enligt dina egna behov. Mer information finns i Konfigurera TLS-princip på en anpassad Front Door-domän.

Anteckning

För Windows 10- och senare versioner rekommenderar vi att du aktiverar en eller båda ECDHE_GCM chiffersviter för bättre säkerhet. Windows 8.1, 8 och 7 är inte kompatibla med dessa ECDHE_GCM chiffersviter. ECDHE_CBC- och DHE-chiffersviterna har tillhandahållits för kompatibilitet med dessa operativsystem.

Relaterat innehåll