Udostępnij za pośrednictwem

Kompleksowe protokoły TLS z usługą Azure Front Door

  • Artykuł

Ważne

Wsparcie dla protokołów TLS 1.0 i 1.1 zostanie przerwane 1 marca 2025 r.

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ążanie protokołu TLS/SSL usługi Front Door kończy połączenie TLS, odszyfrowuje ruch w usłudze Azure Front Door i ponownie szyfruje ruch przed przekazaniem go 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 w przypadku wdrażania prywatnego źródła w usłudze Azure Front Door Premium przy użyciu 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 obecnie cztery wersje protokołu TLS: TLS w wersji 1.0, 1.1, 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, ale protokoły TLS 1.0 i TLS 1.1 są nadal obsługiwane w celu zapewnienia zgodności z poprzednimi wersjami. Wsparcie dla protokołów TLS 1.0 i 1.1 zostanie przerwane 1 marca 2025 r.

Chociaż usługa Azure Front Door obsługuje protokół TLS 1.2, który wprowadził uwierzytelnianie między klientami/wzajemnymi w standardach RFC 5246, obecnie usługa Azure Front Door nie obsługuje jeszcze uwierzytelniania klienta/wzajemnego uwierzytelniania (mTLS).

Minimalną wersję protokołu TLS w usłudze Azure Front Door można skonfigurować w ustawieniach protokołu HTTPS domeny niestandardowej przy użyciu witryny Azure Portal lub interfejsu API REST platformy Azure. Obecnie można wybrać od 1.0 do 1.2. W związku z tym określenie protokołu TLS 1.2 jako minimalnej wersji kontroluje minimalną akceptowalną wersję protokołu TLS, która zostanie zaakceptowana przez usługę Azure Front Door od klienta. W przypadku minimalnej wersji protokołu TLS 1.2 negocjacje będą próbowały ustanowić protokół TLS 1.3, a następnie tls 1.2, podczas gdy minimalna wersja protokołu TLS 1.0 zostanie podjęta próba nawiązania wszystkich czterech wersji. 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.0, TLS 1.1, TLS 1.2 i TLS 1.3. Wsparcie dla protokołów TLS 1.0 i 1.1 zostanie przerwane 1 marca 2025 r.

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 uzgadniania protokołu TLS, co może wynikać z wielu rund do negocjowania obsługiwanej krzywej 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 niedozwolonego urzędu certyfikacji, żądanie zostanie odrzucone.

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

Zszywania 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 źródła (z usługą Azure Front Door do źródła)

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

Uwaga

Certyfikat musi mieć kompletny łańcuch certyfikatów z certyfikatami liścia i certyfikatów pośrednich. 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 na potrzeby testowania, jako obejście problemu z niepowodzeniem połączenia HTTPS, można wyłączyć sprawdzanie nazwy podmiotu certyfikatu dla usługi Azure Front Door. Należy pamiętać, że źródło nadal musi przedstawić certyfikat z prawidłowym zaufanym łańcuchem, ale nie musi być zgodne z nazwą hosta pochodzenia.

W usługach Azure Front Door Standard i Premium można skonfigurować źródło, 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 w interfejsach API usługi Azure Front Door.

Uwaga

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

Połączenie TLS frontonu (klient z usługą 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 dołączyć certyfikat z obsługiwanego urzędu certyfikacji, który może być standardowym certyfikatem TLS, rozszerzonym certyfikatem weryfikacji, a nawet certyfikatem wieloznacznymi. Certyfikaty z podpisem własnym nie są obsługiwane. Dowiedz się , jak włączyć protokół HTTPS dla domeny niestandardowej.

Autorotacja certyfikatu

W przypadku opcji certyfikatu zarządzanego usługi Azure Front Door certyfikaty są zarządzane i obracane automatycznie w ciągu 90 dni od wygaśnięcia przez usługę Azure Front Door. W przypadku opcji certyfikatu zarządzanego usługi Azure Front Door Standard/Premium certyfikaty są zarządzane i obracane automatycznie w ciągu 45 dni od czasu wygaśnięcia przez usługę Azure Front Door. Jeśli używasz certyfikatu zarządzanego usługi Azure Front Door i sprawdź, czy data wygaśnięcia certyfikatu jest mniejsza niż 60 dni lub 30 dni dla jednostki SKU w warstwie Standardowa/Premium, utwórz bilet pomocy technicznej.

W przypadku własnego niestandardowego certyfikatu TLS/SSL:

  1. Należy ustawić wersję wpisu tajnego na "Latest", aby certyfikat był automatycznie obracany do najnowszej wersji, gdy nowsza wersja certyfikatu jest dostępna w magazynie kluczy. W przypadku certyfikatów niestandardowych certyfikat jest automatycznie obracany w ciągu 3–4 dni z nowszą wersją certyfikatu, bez względu na czas wygaśnięcia certyfikatu.

  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 usługi Azure Front Door (Standardowa i Premium) są automatycznie obracane, jeśli rekord CNAME domeny wskazuje bezpośrednio punkt końcowy usługi Front Door lub wskazuje pośrednio punkt końcowy usługi Traffic Manager. W przeciwnym razie należy ponownie zweryfikować własność domeny w celu rotacji certyfikatów.

    Należy się upewnić, że jednostka usługi dla usługi Front Door ma dostęp do magazynu kluczy. Zobacz, jak udzielić dostępu 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

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.

W przypadku korzystania z domen niestandardowych z włączonym protokołem TLS 1.0 i 1.1 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_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

Usługa Azure Front Door nie obsługuje wyłączania ani konfigurowania określonych zestawów szyfrowania dla twojego profilu.

Następne kroki