Omówienie zasad protokołu TLS w usłudze Application Gateway
Brama aplikacja systemu Azure umożliwia scentralizowanie zarządzania certyfikatami TLS/SSL oraz zmniejszenie obciążenia szyfrowania i odszyfrowywania z farmy serwerów zaplecza. Ta scentralizowana obsługa protokołu TLS umożliwia również określenie centralnych zasad protokołu TLS dostosowanych do wymagań dotyczących zabezpieczeń organizacji. Pomaga to spełnić wymagania dotyczące zgodności, a także wytyczne dotyczące zabezpieczeń i zalecane rozwiązania.
Zasady tls obejmują kontrolę wersji protokołu TLS, a także zestawy szyfrowania i kolejność, w której szyfry są używane podczas uzgadniania protokołu TLS. Usługa Application Gateway oferuje dwa mechanizmy kontrolowania zasad PROTOKOŁU TLS. Można użyć wstępnie zdefiniowanych zasad lub zasad niestandardowych.
Szczegóły użycia i wersji
Ważne
Od 31 sierpnia 2025 r. wszyscy klienci i serwery zaplecza współdziałające z usługą aplikacja systemu Azure Gateway muszą korzystać z protokołu Transport Layer Security (TLS) 1.2 lub nowszego, ponieważ obsługa protokołów TLS 1.0 i 1.1 zostanie przerwana.
- Protokoły SSL 2.0 i 3.0 są wyłączone dla wszystkich bram aplikacji i nie można ich konfigurować.
- Niestandardowe zasady protokołu TLS umożliwiają wybranie dowolnego protokołu TLS jako minimalnej wersji protokołu dla bramy: TLSv1_0, TLSv1_1, TLSv1_2 lub TLSv1_3.
- Jeśli nie zostaną wybrane żadne zasady protokołu TLS, zostaną zastosowane domyślne zasady protokołu TLS na podstawie wersji interfejsu API użytej do utworzenia tego zasobu.
- Zasady wstępnie zdefiniowane i niestandardowe 2022, które obsługują protokół TLS w wersji 1.3, są dostępne tylko w przypadku jednostek SKU usługi Application Gateway w wersji 2 (Standard_v2 lub WAF_v2).
- Użycie wstępnie zdefiniowanych zasad 2022 lub Customv2 zwiększa poziom zabezpieczeń protokołu SSL i wydajności całej bramy (w przypadku zasad SSL i profilu SSL). W związku z tym zarówno stare, jak i nowe zasady nie mogą współistnieć w bramie. Należy użyć dowolnej ze starszych wstępnie zdefiniowanych lub niestandardowych zasad w bramie, jeśli klienci wymagają starszych wersji protokołu TLS lub szyfrowania (na przykład TLS w wersji 1.0).
- Zestawy szyfrowania TLS używane na potrzeby połączenia są również oparte na typie używanego certyfikatu. Zestawy szyfrowania używane w połączeniach "klient-brama aplikacji" są oparte na typie certyfikatów odbiornika w bramie aplikacji. Podczas gdy zestawy szyfrowania używane podczas ustanawiania "bramy aplikacji do połączeń puli zaplecza" są oparte na typie certyfikatów serwera prezentowanych przez serwery zaplecza.
Wstępnie zdefiniowane zasady protokołu TLS
Usługa Application Gateway oferuje kilka wstępnie zdefiniowanych zasad zabezpieczeń. Bramę można skonfigurować przy użyciu dowolnej z tych zasad, aby uzyskać odpowiedni poziom zabezpieczeń. Nazwy zasad są oznaczone adnotacjami według roku i miesiąca, w którym zostały skonfigurowane (AppGwSslPolicy<RRRRMDD>). Każda zasada oferuje różne wersje protokołu TLS i/lub zestawy szyfrowania. Te wstępnie zdefiniowane zasady są konfigurowane zgodnie z najlepszymi rozwiązaniami i zaleceniami zespołu ds. zabezpieczeń firmy Microsoft. Zalecamy użycie najnowszych zasad protokołu TLS w celu zapewnienia najlepszych zabezpieczeń protokołu TLS.
W poniższej tabeli przedstawiono listę zestawów szyfrowania i minimalną obsługę wersji protokołu dla każdej wstępnie zdefiniowanej zasady. Kolejność zestawów szyfrowania określa kolejność priorytetów podczas negocjacji protokołu TLS. Aby poznać dokładną kolejność zestawów szyfrowania dla tych wstępnie zdefiniowanych zasad, możesz zapoznać się z blokiem Programu PowerShell, interfejsu wiersza polecenia, interfejsu API REST lub odbiorników w portalu.
| Wstępnie zdefiniowane nazwy zasad (AppGwSslPolicy<RRRRMDD>) | 20150501 | 20170401 | 20170401S | 20220101 | 20220101S |
|---|---|---|---|---|---|
| Minimalna wersja protokołu | 1.0 | 1.1 | 1.2 | 1.2 | 1.2 |
| Wersje protokołów z włączoną obsługą | 1.0 1.1 1.2 |
1.1 1.2 |
1.2 | 1.2 1.3 |
1.2 1.3 |
| Wartość domyślna | Prawda (dla interfejsu API w wersji < 2023-02-01) |
Fałsz | Fałsz | Prawda (dla wersji >interfejsu API = 2023-02-01) |
Fałsz |
| TLS_AES_128_GCM_SHA256 | ✗ | ✗ | ✗ | ✓ | ✓ |
| TLS_AES_256_GCM_SHA384 | ✗ | ✗ | ✗ | ✓ | ✓ |
| 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_ECDHE_RSA_WITH_AES_256_CBC_SHA | ✓ | ✓ | ✓ | ✗ | ✗ |
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA | ✓ | ✓ | ✓ | ✗ | ✗ |
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | ✓ | ✗ | ✗ | ✗ | ✗ |
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | ✓ | ✗ | ✗ | ✗ | ✗ |
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA | ✓ | ✗ | ✗ | ✗ | ✗ |
| TLS_DHE_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_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | ✓ | ✓ | ✓ | ✓ | ✓ |
| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | ✓ | ✓ | ✓ | ✓ | ✓ |
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 | ✓ | ✓ | ✓ | ✓ | ✗ |
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 | ✓ | ✓ | ✓ | ✓ | ✗ |
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA | ✓ | ✓ | ✓ | ✗ | ✗ |
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA | ✓ | ✓ | ✓ | ✗ | ✗ |
| TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 | ✓ | ✗ | ✗ | ✗ | ✗ |
| TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 | ✓ | ✗ | ✗ | ✗ | ✗ |
| TLS_DHE_DSS_WITH_AES_256_CBC_SHA | ✓ | ✗ | ✗ | ✗ | ✗ |
| TLS_DHE_DSS_WITH_AES_128_CBC_SHA | ✓ | ✗ | ✗ | ✗ | ✗ |
| TLS_RSA_WITH_3DES_EDE_CBC_SHA | ✓ | ✗ | ✗ | ✗ | ✗ |
| TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA | ✓ | ✗ | ✗ | ✗ | ✗ |
Domyślne zasady protokołu TLS
Jeśli w konfiguracji zasobu bramy aplikacji nie określono żadnych określonych zasad protokołu SSL, zostaną zastosowane domyślne zasady protokołu TLS. Wybór tych domyślnych zasad jest oparty na wersji interfejsu API użytej do utworzenia tej bramy.
- W przypadku interfejsu API w wersji 2023-02-01 lub nowszej minimalna wersja protokołu jest ustawiona na 1.2 (obsługiwana jest wersja do 1.3). Bramy utworzone przy użyciu tych wersji interfejsu API będą widzieć właściwość domyślną tylko do odczytuPredefinedSslPolicy:AppGwSslPolicy2020101 w konfiguracji zasobu. Ta właściwość definiuje domyślne zasady protokołu TLS do użycia.
- W przypadku starszych wersji < interfejsu API 2023-02-01 minimalna wersja protokołu jest ustawiona na 1.0 (wersje do 1.2 są obsługiwane), ponieważ używają wstępnie zdefiniowanych zasad AppGwSslPolicy20150501 jako domyślne.
Jeśli domyślny protokół TLS nie pasuje do wymagań, wybierz inne wstępnie zdefiniowane zasady lub użyj niestandardowego.
Uwaga
Obsługa programu Azure PowerShell i interfejsu wiersza polecenia dla zaktualizowanych domyślnych zasad protokołu TLS będzie dostępna wkrótce.
Niestandardowe zasady protokołu TLS
Jeśli należy skonfigurować zasady protokołu TLS zgodnie z wymaganiami, możesz użyć niestandardowych zasad protokołu TLS. Dzięki niestandardowym zasadom protokołu TLS masz pełną kontrolę nad minimalną wersją protokołu TLS do obsługi, a także obsługiwanymi zestawami szyfrowania i ich kolejnością priorytetu.
Uwaga
Nowsze, silniejsze szyfry i obsługa TLSv1.3 są dostępne tylko w zasadach CustomV2. Zapewnia on zwiększone korzyści z zakresu zabezpieczeń i wydajności.
Ważne
- Jeśli używasz niestandardowych zasad SSL w jednostce SKU usługi Application Gateway w wersji 1 (Standardowa lub WAF), upewnij się, że do listy dodano obowiązkowy szyfr "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256". Ten szyfr jest wymagany do włączenia metryk i rejestrowania w jednostce SKU usługi Application Gateway w wersji 1. Nie jest to obowiązkowe w przypadku jednostki SKU usługi Application Gateway w wersji 2 (Standard_v2 lub WAF_v2).
- Zestawy szyfrowania "TLS_AES_128_GCM_SHA256" i "TLS_AES_256_GCM_SHA384" są obowiązkowe dla TLSv1.3. Nie trzeba jawnie wspominać o tych zasadach podczas ustawiania zasad CustomV2 z minimalną wersją protokołu 1.2 lub 1.3 za pomocą programu PowerShell lub interfejsu wiersza polecenia. W związku z tym te zestawy szyfrowania nie będą wyświetlane w danych wyjściowych Get Details z wyjątkiem portalu.
Zestawy szyfrowania
Usługa Application Gateway obsługuje następujące zestawy szyfrowania, z których można wybrać zasady niestandardowe. Kolejność zestawów szyfrowania określa kolejność priorytetów podczas negocjacji protokołu TLS.
- TLS_AES_128_GCM_SHA256 (dostępne tylko w przypadku usługi Customv2)
- TLS_AES_256_GCM_SHA384 (dostępne tylko w przypadku usługi Customv2)
- 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_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA
- TLS_DHE_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_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
- TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
- TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
- TLS_DHE_DSS_WITH_AES_256_CBC_SHA
- TLS_DHE_DSS_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_3DES_EDE_CBC_SHA
- TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
Ograniczenia
- Połączenia z serwerami zaplecza są zawsze z minimalnym protokołem TLS w wersji 1.0 i maksymalnie TLS w wersji 1.2. W związku z tym tylko protokoły TLS w wersji 1.0, 1.1 i 1.2 są obsługiwane w celu nawiązania bezpiecznego połączenia z serwerami zaplecza.
- Od tej pory implementacja protokołu TLS 1.3 nie jest włączona z funkcją "Zero Round Trip Time (0-RTT)".
- Wznowienie sesji PROTOKOŁU TLS (identyfikatora lub biletów) nie jest obsługiwane.
- Usługa Application Gateway w wersji 2 nie obsługuje następujących szyfrów DHE. Nie będą one używane w przypadku połączeń TLS z klientami, mimo że są one wymienione w wstępnie zdefiniowanych zasadach. Zamiast szyfrów DHE zalecane są bezpieczne i szybsze szyfry ECDHE.
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA
- TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
- TLS_DHE_DSS_WITH_AES_128_CBC_SHA
- TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
- TLS_DHE_DSS_WITH_AES_256_CBC_SHA
- Klienci ograniczeni, którzy szukają obsługi "Maksymalna negocjacje długości fragmentu", muszą używać nowszych zasad wstępnie zdefiniowanych lub niestandardowych 2022.
Następne kroki
Jeśli chcesz dowiedzieć się, jak skonfigurować zasady protokołu TLS, zobacz Konfigurowanie wersji zasad PROTOKOŁU TLS i zestawów szyfrowania w usłudze Application Gateway.