Delen via

TLS-versleuteling met Azure Front Door

Transport Layer Security (TLS), voorheen bekend als Secure Sockets Layer (SSL), is de standaard beveiligingstechnologie voor het tot stand brengen van een versleutelde verbinding tussen een webserver en een cliënt, zoals een webbrowser. Deze link zorgt ervoor dat alle gegevens die tussen de server en de client worden uitgewisseld, privé en versleuteld blijven.

Om aan uw beveiligings- of nalevingsvereisten te voldoen, ondersteunt Azure Front Door end-to-end TLS-versleuteling. TLS/SSL offload bij Front Door beëindigt de TLS-verbinding, versleutelt het verkeer bij de Azure Front Door en versleutelt het verkeer opnieuw voordat het naar de oorsprong wordt doorgestuurd. Wanneer verbindingen naar de oorsprong het openbare IP-adres van de oorsprong gebruiken, is het een goede beveiligingspraktijk om HTTPS te configureren als het doorstuurprotocol op uw Azure Front Door. Door HTTPS als doorstuurprotocol te gebruiken, kunt u end-to-end TLS-encryptie afdwingen voor de volledige verwerking van het verzoek van de klant tot aan de bron. TLS/SSL offload wordt ook ondersteund als je een private origin implementeert met Azure Front Door Premium met behulp van de Private Link-functie.

In dit artikel wordt uitgelegd hoe Azure Front Door werkt met TLS-verbindingen. Voor meer informatie over het gebruik van TLS-certificaten met uw eigen aangepaste domeinen, zie HTTPS voor aangepaste domeinen. Leer hoe u een TLS-certificaat kunt configureren op uw eigen domein door te kijken naar Een aangepast domein configureren op Azure Front Door met behulp van de Azure-portal.

End-to-end TLS-versleuteling

End-to-end TLS stelt je in staat om gevoelige gegevens te beveiligen terwijl ze onderweg zijn naar de oorsprong, terwijl je profiteert van Azure Front Door-functies zoals wereldwijde load balancing en caching. Sommige van de functies omvatten ook URL-gebaseerde routering, TCP-splitsing, caching op de edge-locatie die het dichtst bij de klanten ligt, en het aanpassen van HTTP-verzoeken aan de rand.

Azure Front Door ontlaadt de TLS-sessies aan de rand en decrypteert klantverzoeken. Vervolgens past het de geconfigureerde routeringsregels toe om de aanvragen door te sturen naar de juiste oorsprong in de oorspronggroep. Azure Front Door start dan een nieuwe TLS-verbinding met de oorsprong en her-encrypteert alle gegevens met behulp van het certificaat van de oorsprong voordat het verzoek naar de oorsprong wordt verzonden. Elke reactie van de oorsprong wordt op dezelfde manier versleuteld terug naar de eindgebruiker. U kunt uw Azure Front Door configureren om HTTPS te gebruiken als het doorstuurprotocol om end-to-end TLS mogelijk te maken.

Ondersteunde TLS-versies

Azure Front Door ondersteunt twee versies van het TLS-protocol: TLS-versies 1.2 en 1.3. Alle Azure Front Door-profielen die na september 2019 zijn aangemaakt, gebruiken TLS 1.2 als de standaard minimale versie, met TLS 1.3 ingeschakeld. Momenteel biedt Azure Front Door geen ondersteuning voor client-/wederzijdse verificatie (mTLS).

Belangrijk

Vanaf 1 maart 2025 zijn TLS 1.0 en 1.1 niet toegestaan op nieuwe Azure Front Door-profielen.

Voor Azure Front Door Standard en Premium kunt u vooraf gedefinieerd TLS-beleid configureren of de TLS-coderingssuite kiezen op basis van de beveiligingsbehoeften van uw organisatie. Zie Azure Front Door TLS-beleid en configureer TLS-beleid in een aangepast front oor-domein voor meer informatie.

Voor de klassieke Versie van Azure Front Door en microsoft CDN kunt u de minimale TLS-versie in Azure Front Door configureren in de HTTPS-instellingen voor aangepast domein met behulp van Azure Portal of de Azure REST API. Voor een minimale TLS-versie 1.2 probeert de onderhandeling TLS 1.3 en vervolgens TLS 1.2 tot stand te brengen. Wanneer Azure Front Door TLS-verkeer naar de oorsprong initieert, zal het proberen de beste TLS-versie te onderhandelen die de oorsprong betrouwbaar en consistent kan accepteren. Ondersteunde TLS-versies voor oorsprongverbindingen zijn TLS 1.2 en TLS 1.3. Als u de coderingssuite per behoeften wilt aanpassen, migreert u de klassieke Front Door - en Microsoft CDN-klassieke versie naar Azure Front Door Standard en Premium.

Opmerking

  • Clients met TLS 1.3 ingeschakeld moeten ondersteuning bieden voor een van de Microsoft SDL-conforme EC-curves, waaronder Secp384r1, Secp256r1 en Secp521, om succesvol verzoeken te kunnen doen met Azure Front Door via TLS 1.3.
  • Het wordt aanbevolen dat klanten een van deze curves als hun voorkeurscurve gebruiken tijdens verzoeken om verhoogde TLS-handshakevertraging te vermijden, wat zou kunnen voortvloeien uit meerdere retourvluchten om de ondersteunde EC-curve te onderhandelen.

Ondersteunde certificaten

Bij het aanmaken van uw TLS/SSL-certificaat moet u een volledige certificaathierarchie maken met een toegestane certificaatautoriteit (CA) die deel uitmaakt van de Microsoft Trusted CA List. Als u een niet-toegestane CA gebruikt, zal uw verzoek worden afgewezen.

Certificaten van interne CA's of zelfondertekende certificaten zijn niet toegestaan.

OCSP-koppeling (Online Certificate Status Protocol)

OCSP stapling wordt standaard ondersteund in Azure Front Door en er is geen configuratie vereist.

Origin TLS-verbinding (Azure Front Door naar bron)

Voor HTTPS-verbindingen verwacht Azure Front Door dat uw oorsprong een certificaat presenteert van een geldige certificeringsautoriteit (CA) met een onderwerpnaam die overeenkomt met de oorsprong hostname. Als voorbeeld, als uw oorsprong-hostnaam is ingesteld op myapp-centralus.contoso.net en het certificaat dat uw oorsprong presenteert tijdens de TLS-handshake geen myapp-centralus.contoso.net of *.contoso.net in de onderwerpnaam heeft, weigert Azure Front Door de verbinding en ziet de client een foutmelding.

Opmerking

Het certificaat moet een volledige certificaatketen hebben met blad- en tussencertificaten. De root CA moet onderdeel zijn van de Microsoft Trusted CA List. Als een certificaat zonder complete keten wordt gepresenteerd, is er geen garantie dat de verzoeken waarbij dat certificaat betrokken is, naar verwachting zullen werken.

In bepaalde gebruikssituaties, zoals testen, kunt u de controles op de subjectnaam van het certificaat uitschakelen voor uw Azure Front Door als een tijdelijke oplossing om mislukte HTTPS-verbindingen op te lossen. De bron moet nog steeds een certificaat met een geldige, vertrouwde keten presenteren, maar het hoeft niet overeen te komen met de hostnaam van de bron.

In Azure Front Door Standard en Premium kun je een oorsprong configureren om de controle van de certificaatonderwerpnaam uit te schakelen.

In Azure Front Door (classic) kunt u de controle van de onderwerpsnaam van het certificaat uitschakelen door de instellingen van Azure Front Door in het Azure-portaal te wijzigen. U kunt de controle ook configureren door de instellingen van de back-endpool in de Azure Front Door API's te gebruiken.

Opmerking

Vanuit een beveiligingsperspectief raadt Microsoft het af om de controle van de naam van het certificaatonderwerp uit te schakelen.

Frontend TLS-verbinding (client naar Azure Front Door)

Om het HTTPS-protocol in te schakelen voor de veilige levering van inhoud op een Azure Front Door-aangepast domein, kunt u ervoor kiezen om een certificaat te gebruiken dat wordt beheerd door Azure Front Door, of uw eigen certificaat gebruiken.

Voor meer informatie, zie HTTPS voor aangepaste domeinen.

Het beheerde certificaat van Azure Front Door biedt een standaard TLS/SSL-certificaat via DigiCert en wordt opgeslagen in de Key Vault van Azure Front Door.

Als u ervoor kiest om uw eigen certificaat te gebruiken, kunt u een certificaat van een ondersteunde certificeringsinstantie aan boord brengen dat een standaard TLS-, uitgebreide validatiecertificaat of zelfs een wildcard-certificaat kan zijn. Zelfondertekende certificaten worden niet ondersteund. Leer hoe u HTTPS voor een aangepast domein kunt inschakelen.

Certificaat autorotatie

Voor de Azure Front Door beheerde certificaatoptie worden de certificaten beheerd en automatisch vernieuwd binnen 90 dagen na de vervaldatum door Azure Front Door. Voor de Azure Front Door Standard/Premium optie voor beheerde certificaten, worden de certificaten beheerd en automatisch vernieuwd binnen 45 dagen na de vervaldatum door Azure Front Door. Als je een door Azure Front Door beheerd certificaat gebruikt en je ziet dat de vervaldatum van het certificaat binnen 60 dagen is of binnen 30 dagen voor de Standard/Premium SKU, dien dan een ondersteuningsverzoek in.

Voor uw eigen aangepaste TLS/SSL-certificaat:

  1. Stel de geheime versie in op 'Laatste' zodat het certificaat automatisch wordt bijgewerkt naar de nieuwste versie wanneer er een nieuwere versie van het certificaat beschikbaar is in uw sleutelkluis. Voor maatwerkcertificaten wordt het certificaat binnen 3-4 dagen automatisch vervangen door een nieuwere versie van het certificaat, ongeacht de vervaltijd van het certificaat.

  2. Als een specifieke versie is geselecteerd, wordt de automatische rotatie niet ondersteund. Je moet de nieuwe versie handmatig opnieuw selecteren om het certificaat te roteren. Het kan tot 24 uur duren voordat de nieuwe versie van het certificaat/geheim wordt uitgerold.

    Opmerking

    Azure Front Door (Standard en Premium) beheerde certificaten worden automatisch geroteerd als het domein CNAME-record direct naar een Front Door-endpoint wijst of indirect naar een Traffic Manager-endpoint wijst. Anders moet u de eigendom van het domein opnieuw verifiëren om de certificaten te draaien.

    De service-principal voor Front Door moet toegang hebben tot de sleutelkluis. De bijgewerkte certificaatuitrol door Azure Front Door zal geen productiestilstand veroorzaken, zolang de onderwerpnaam of het alternatieve onderwerpnaam (SAN) voor het certificaat niet is gewijzigd.

Ondersteunde cijferreeksen

Voor TLS 1.2/1.3 worden de volgende cijferreeksen ondersteund:

  • TLS_AES_256_GCM_SHA384 (alleen TLS 1.3)
  • TLS_AES_128_GCM_SHA256 (alleen 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

Opmerking

Oude TLS-versies en zwakke ciphers worden niet langer ondersteund.

Gebruik TLS-beleid om specifieke cijferreeksen te configureren. Azure Front Door Standard en Premium bieden twee mechanismen om het TLS-beleid te beheren: je kunt zowel een vooraf gedefinieerd beleid als een aangepast beleid naar eigen behoefte gebruiken. Voor meer informatie, zie Configureer TLS-beleid op een aangepast domein van Front Door.

Opmerking

Voor Windows 10 en latere versies raden we aan om een of beide van de ECDHE_GCM encryptiecijfers in te schakelen voor betere beveiliging. Windows 8.1, 8 en 7 zijn niet compatibel met deze ECDHE_GCM cijferreeksen. De ECDHE_CBC en DHE versleutelsuites zijn verstrekt voor compatibiliteit met die besturingssystemen.

Verwante inhoud