Udostępnij za pośrednictwem

Szyfrowanie TLS za pomocą usługi Azure Front Door

Transport Layer Security (TLS), wcześniej znany jako Secure Sockets Layer (SSL), jest standardową technologią zabezpieczeń do ustanawiania szyfrowanego połączenia między serwerem internetowym a klientem, na przykład przeglądarką internetową. Ten link gwarantuje, że wszystkie dane przekazywane między serwerem a klientem pozostaną prywatne i zaszyfrowane.

Aby spełnić wymagania dotyczące zabezpieczeń lub zgodności, usługa Azure Front Door obsługuje kompleksowe szyfrowanie TLS. Odciążenie TLS/SSL w usłudze Azure Front Door polega na zakończeniu połączenia TLS, odszyfrowaniu ruchu w usłudze Azure Front Door, a następnie zaszyfrowaniu go ponownie przed przesłaniem do źródła. Gdy połączenia z źródłem korzystają z publicznego adresu IP źródła, dobrym rozwiązaniem jest skonfigurowanie protokołu HTTPS jako protokołu przekazywania w usłudze Azure Front Door. Używając protokołu HTTPS jako protokołu przekazującego, można wymusić kompleksowe szyfrowanie TLS dla całego przetwarzania żądania od klienta do źródła. Odciążanie protokołu TLS/SSL jest również obsługiwane, jeśli wdrażasz prywatne źródło za pomocą usługi Azure Front Door Premium z użyciem funkcji Private Link.

W tym artykule wyjaśniono, jak usługa Azure Front Door współpracuje z połączeniami TLS. Aby uzyskać więcej informacji na temat używania certyfikatów TLS z własnymi domenami niestandardowymi, zobacz HTTPS for custom domains (Protokół HTTPS dla domen niestandardowych). Aby dowiedzieć się, jak skonfigurować certyfikat TLS we własnej domenie niestandardowej, zobacz Konfigurowanie domeny niestandardowej w usłudze Azure Front Door przy użyciu witryny Azure Portal.

Kompleksowe szyfrowanie TLS

Kompleksowe szyfrowanie TLS umożliwia zabezpieczanie poufnych danych podczas przesyłania do źródła, a jednocześnie korzystanie z funkcji usługi Azure Front Door, takich jak globalne równoważenie obciążenia i buforowanie. Niektóre funkcje obejmują również routing oparty na adresach URL, podział TCP, buforowanie w lokalizacji brzegowej najbliżej klientów i dostosowywanie żądań HTTP na brzegu sieci.

Usługa Azure Front Door odciąża sesje protokołu TLS na urządzeniach brzegowych i odszyfrowuje żądania klientów. Następnie stosuje skonfigurowane reguły routingu w celu kierowania żądań do odpowiedniego źródła w grupie pochodzenia. Następnie usługa Azure Front Door uruchamia nowe połączenie TLS z źródłem i ponownie szyfruje wszystkie dane przy użyciu certyfikatu źródła przed przesłaniem żądania do źródła. Każda odpowiedź ze źródła jest szyfrowana za pośrednictwem tego samego procesu z powrotem do użytkownika końcowego. Usługę Azure Front Door można skonfigurować tak, aby używała protokołu HTTPS jako protokołu przekazywania w celu włączenia kompleksowego protokołu TLS.

Obsługiwane wersje protokołu TLS

Usługa Azure Front Door obsługuje dwie wersje protokołu TLS: TLS w wersji 1.2 i 1.3. Wszystkie profile usługi Azure Front Door utworzone po wrześniu 2019 r. używają protokołu TLS 1.2 jako domyślnego minimum z włączonym protokołem TLS 1.3. Obecnie usługa Azure Front Door nie obsługuje uwierzytelniania klienta/wzajemnego uwierzytelniania (mTLS).

Ważne

Od 1 marca 2025 r. protokoły TLS 1.0 i 1.1 nie są dozwolone w nowych profilach usługi Azure Front Door.

W przypadku usług Azure Front Door Standard i Premium można skonfigurować wstępnie zdefiniowane zasady protokołu TLS lub wybrać zestaw szyfrowania TLS na podstawie potrzeb organizacji w zakresie zabezpieczeń. Aby uzyskać więcej informacji, zobacz Zasady protokołu TLS usługi Azure Front Door i konfigurowanie zasad TLS w domenie niestandardowej Front Door.

W przypadku klasycznej usługi Azure Front Door i klasycznej usługi Microsoft CDN można skonfigurować minimalną wersję protokołu TLS w usłudze Azure Front Door w ustawieniach protokołu HTTPS domeny niestandardowej przy użyciu witryny Azure Portal lub interfejsu API REST platformy Azure. W przypadku minimalnej wersji protokołu TLS 1.2 negocjacje podejmą próbę ustanowienia protokołu TLS 1.3, a następnie protokołu TLS 1.2. Gdy usługa Azure Front Door inicjuje ruch TLS do źródła, podejmie próbę wynegocjowania najlepszej wersji protokołu TLS, którą źródło może niezawodnie i spójnie zaakceptować. Obsługiwane wersje protokołu TLS dla połączeń pochodzenia to TLS 1.2 i TLS 1.3. Jeśli chcesz dostosować zestaw szyfrów do swoich potrzeb, przeprowadź migrację klasycznej usługi Front Door i usługi klasycznejMicrosoft CDN do usługi Azure Front Door w warstwie Standardowa i Premium.

Uwaga

  • Klienci z włączonym protokołem TLS 1.3 muszą obsługiwać jedną z zgodnych krzywych EC microsoft SDL, w tym Secp384r1, Secp256r1 i Secp521, aby pomyślnie wysyłać żądania w usłudze Azure Front Door przy użyciu protokołu TLS 1.3.
  • Zaleca się, aby klienci używali jednej z tych krzywych jako preferowanej krzywej podczas żądań, aby uniknąć zwiększonego opóźnienia w uzgadnianiu połączenia TLS, co może wynikać z wielokrotnych rund wymiany danych do negocjowania obsługiwanego wykresu EC.

Obsługiwane certyfikaty

Podczas tworzenia certyfikatu TLS/SSL należy utworzyć pełny łańcuch certyfikatów z dozwolonym urzędem certyfikacji, który jest częścią listy zaufanych urzędów certyfikacji firmy Microsoft. Jeśli skorzystasz z nieautoryzowanego urzędu certyfikacji, żądanie zostanie odrzucone.

Certyfikaty z wewnętrznych urzędów certyfikacji lub certyfikaty z podpisem własnym nie są dozwolone.

Spajanie protokołu OCSP (Online Certificate Status Protocol)

Zszycie OCSP jest domyślnie obsługiwane w usłudze Azure Front Door i nie jest wymagana żadna konfiguracja.

Połączenie TLS od źródła (połączenie z usługą Azure Front Door do serwera źródłowego)

W przypadku połączeń HTTPS usługa Azure Front Door oczekuje, że źródło przedstawi certyfikat od prawidłowego urzędu certyfikacji, z nazwą podmiotu zgodną z nazwą hosta pochodzenia. Jeśli na przykład nazwa hosta źródłowego jest ustawiona na myapp-centralus.contoso.net, a certyfikat, który twój serwer źródłowy prezentuje podczas uzgadniania protokołu TLS, nie zawiera myapp-centralus.contoso.net lub *.contoso.net w nazwie podmiotu, wtedy usługa Azure Front Door odrzuca połączenie, a klient widzi błąd.

Uwaga

Certyfikat musi mieć kompletny łańcuch certyfikatów z certyfikatami końcowymi i pośrednimi. Główny urząd certyfikacji musi być częścią listy zaufanych urzędów certyfikacji firmy Microsoft. Jeśli zostanie wyświetlony certyfikat bez pełnego łańcucha, żądania, które obejmują ten certyfikat, nie będą działać zgodnie z oczekiwaniami.

W niektórych przypadkach użycia, takich jak testowanie, można wyłączyć sprawdzanie nazwy podmiotu certyfikatu dla usługi Azure Front Door jako obejście w celu rozwiązania problemów z nieudanym połączeniem HTTPS. Źródło musi nadal prezentować certyfikat z prawidłowym, zaufanym łańcuchem, ale nie musi odpowiadać nazwie hosta źródła.

W usługach Azure Front Door Standard i Premium można skonfigurować pochodzenie, aby wyłączyć sprawdzanie nazwy podmiotu certyfikatu.

W usłudze Azure Front Door (wersja klasyczna) możesz wyłączyć sprawdzanie nazwy podmiotu certyfikatu, zmieniając ustawienia usługi Azure Front Door w witrynie Azure Portal. Sprawdzanie można również skonfigurować przy użyciu ustawień puli zaplecza serwera w interfejsach API Azure Front Door.

Uwaga

Z punktu widzenia zabezpieczeń firma Microsoft nie zaleca wyłączania sprawdzania nazwy podmiotu certyfikatu.

Połączenie TLS interfejsu frontowego (klient do Azure Front Door)

Aby włączyć protokół HTTPS do bezpiecznego dostarczania zawartości w domenie niestandardowej usługi Azure Front Door, możesz użyć certyfikatu zarządzanego przez usługę Azure Front Door lub użyć własnego certyfikatu.

Aby uzyskać więcej informacji, zobacz HTTPS for custom domains (Protokół HTTPS dla domen niestandardowych).

Zarządzany certyfikat usługi Azure Front Door zapewnia standardowy certyfikat TLS/SSL za pośrednictwem firmy DigiCert i jest przechowywany w usłudze Key Vault usługi Azure Front Door.

Jeśli zdecydujesz się używać własnego certyfikatu, możesz zainstalować certyfikat z obsługiwanego urzędu certyfikacji, który może być standardowym certyfikatem TLS, rozszerzonym certyfikatem weryfikacji, a nawet certyfikatem wieloznacznym. Certyfikaty z podpisem własnym nie są obsługiwane. Dowiedz się , jak włączyć protokół HTTPS dla domeny niestandardowej.

Autorotacja certyfikatu

W przypadku opcji zarządzanego certyfikatu w usłudze Azure Front Door, certyfikaty są zarządzane i automatycznie odnawiane przez usługę Azure Front Door w ciągu 90 dni przed ich wygaśnięciem. W przypadku opcji zarządzanego certyfikatu Azure Front Door Standard/Premium, certyfikaty są zarządzane i automatycznie odnawiane przez Azure Front Door w ciągu 45 dni od daty wygaśnięcia. Jeśli używasz certyfikatu zarządzanego usługi Azure Front Door i widzisz, że data wygaśnięcia certyfikatu jest mniejsza niż 60 dni lub 30 dni dla SKU Standardowa/Premium, złóż zgłoszenie do pomocy technicznej.

W przypadku własnego niestandardowego certyfikatu TLS/SSL:

  1. Ustaw wersję tajnego na wartość "Latest", aby certyfikat był automatycznie aktualizowany do najnowszej wersji, gdy nowsza wersja certyfikatu jest dostępna w magazynie kluczy. W przypadku certyfikatów niestandardowych certyfikat jest automatycznie odnawiany w ciągu 3-4 dni na nowszą wersję, niezależnie od czasu wygaśnięcia.

  2. Jeśli wybrano określoną wersję, autorotacja nie jest obsługiwana. Musisz ponownie wybrać nową wersję ręcznie, aby obrócić certyfikat. Wdrożenie nowej wersji certyfikatu/wpisu tajnego trwa do 24 godzin.

    Uwaga

    Certyfikaty zarządzane przez Azure Front Door (Standardowa i Premium) są automatycznie odnawiane, jeśli rekord CNAME domeny wskazuje bezpośrednio na punkt końcowy usługi Front Door lub pośrednio na punkt końcowy usługi Traffic Manager. W przeciwnym razie należy ponownie zweryfikować własność domeny w celu rotacji certyfikatów.

    Jednostka zabezpieczeń dla usługi Front Door musi mieć dostęp do magazynu kluczy. Zaktualizowana operacja wdrażania certyfikatu przez usługę Azure Front Door nie spowoduje przestoju produkcyjnego, o ile nazwa podmiotu lub alternatywna nazwa podmiotu (SAN) certyfikatu nie uległa zmianie.

Obsługiwane zestawy szyfrowania

W przypadku protokołu TLS 1.2/1.3 obsługiwane są następujące zestawy szyfrowania:

  • TLS_AES_256_GCM_SHA384 (tylko protokół TLS 1.3)
  • TLS_AES_128_GCM_SHA256 (tylko protokół 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

Uwaga

Stare wersje protokołu TLS i słabe szyfry nie są już obsługiwane.

Użyj zasad PROTOKOŁU TLS , aby skonfigurować określone zestawy szyfrowania. Usługa Azure Front Door Standard i Premium oferują dwa mechanizmy kontrolowania zasad TLS: można użyć wstępnie zdefiniowanych zasad lub zasad niestandardowych zgodnie z własnymi potrzebami. Aby uzyskać więcej informacji, zobacz Konfigurowanie zasad PROTOKOŁU TLS w domenie niestandardowej usługi Front Door.

Uwaga

W przypadku systemu Windows 10 i nowszych wersji zalecamy włączenie jednego lub obu zestawów szyfrowania ECDHE_GCM w celu zapewnienia lepszych zabezpieczeń. Systemy Windows 8.1, 8 i 7 nie są zgodne z tymi zestawami szyfrowania ECDHE_GCM. Zestawy szyfrowania ECDHE_CBC i DHE zostały udostępnione pod kątem zgodności z tymi systemami operacyjnymi.

Powiązana zawartość