Omówienie kończenia żądań protokołu TLS i kompleksowego szyfrowania TLS za pomocą usługi Application Gateway

Transport Layer Security (TLS), wcześniej znany jako Secure Sockets Layer (SSL), to standardowa technologia zabezpieczeń do ustanawiania szyfrowanego połączenia między serwerem internetowym a przeglądarką. Ten link gwarantuje, że wszystkie dane przekazywane między serwerem internetowym a przeglądarkami pozostaną prywatne i zaszyfrowane. Usługa Application Gateway obsługuje zarówno zakończenie protokołu TLS w bramie, jak i kompleksowe szyfrowanie TLS.

Zakończenie szyfrowania TLS

Usługa Application Gateway obsługuje kończenie żądań TLS w bramie, po czym ruch zwykle przepływa niezaszyfrowany do serwerów zaplecza. Istnieje wiele zalet kończenia żądań protokołu TLS w bramie aplikacji:

• Zwiększona wydajność — największą wydajnością podczas odszyfrowywania protokołu TLS jest początkowy uzgadnianie. Aby zwiększyć wydajność, serwer buforuje identyfikatory sesji PROTOKOŁU TLS i zarządza biletami sesji PROTOKOŁU TLS. W przypadku wykonania tej czynności w bramie aplikacji wszystkie żądania z tego samego klienta mogą używać wartości buforowanych. Jeśli odbywa się to na serwerach zaplecza, za każdym razem, gdy żądania klienta przechodzą do innego serwera, klient musi ponownie uwierzytelnić. Użycie biletów TLS może pomóc rozwiązać ten problem, ale nie są one obsługiwane przez wszystkich klientów i mogą być trudne do skonfigurowania i zarządzania.
• Lepsze wykorzystanie serwerów zaplecza — przetwarzanie protokołu SSL/TLS jest bardzo intensywnie obciążane procesorem CPU i staje się coraz bardziej intensywne w miarę zwiększania rozmiarów kluczy. Usunięcie tej pracy z serwerów zaplecza pozwala im skupić się na tym, co są najbardziej wydajne, dostarczając zawartość.
• Routing inteligentny — przez odszyfrowywanie ruchu brama aplikacji ma dostęp do zawartości żądania, takiej jak nagłówki, identyfikator URI itd., i może używać tych danych do kierowania żądań.
• Zarządzanie certyfikatami — certyfikaty muszą być kupowane i instalowane tylko w bramie aplikacji, a nie na wszystkich serwerach zaplecza. Pozwala to zaoszczędzić czas i pieniądze.

Aby skonfigurować kończenie żądań protokołu TLS, należy dodać certyfikat TLS/SSL do odbiornika. Dzięki temu usługa Application Gateway może odszyfrować ruch przychodzący i szyfrować ruch odpowiedzi do klienta. Certyfikat dostarczony do usługi Application Gateway musi być w formacie Wymiany informacji osobistych (PFX), który zawiera zarówno klucze prywatne, jak i publiczne. Obsługiwane algorytmy PFX są wyświetlane w funkcji PFXImportCertStore.

Ważne

Certyfikat na odbiorniku wymaga przekazania całego łańcucha certyfikatów (certyfikatu głównego z urzędu certyfikacji, pośrednich i certyfikatu liścia) w celu ustanowienia łańcucha zaufania.

Uwaga

Usługa Application Gateway nie zapewnia możliwości tworzenia nowego certyfikatu ani wysyłania żądania certyfikatu do urzędu certyfikacji.

Aby połączenie TLS działało, należy upewnić się, że certyfikat TLS/SSL spełnia następujące warunki:

• Bieżąca data i godzina mieści się w zakresie dat "Ważny od" i "Ważny do" w certyfikacie.
• „Nazwa pospolita” (CN) certyfikatu musi być zgodna z nagłówkiem hosta w żądaniu. Jeśli na przykład klient wysyła żądanie do domeny https://www.contoso.com/, nazwą pospolitą (CN) musi być www.contoso.com.

Jeśli występują błędy dotyczące nazwy pospolitej certyfikatu zaplecza (CN), zobacz nasz przewodnik rozwiązywania problemów.

Certyfikaty obsługiwane w przypadku kończenia żądań protokołu TLS

Usługa Application Gateway obsługuje następujące typy certyfikatów:

• Certyfikat urzędu certyfikacji (urząd certyfikacji): certyfikat urzędu certyfikacji jest certyfikatem cyfrowym wystawionym przez urząd certyfikacji (CA)
• Certyfikat EV (rozszerzonej weryfikacji): certyfikat EV jest certyfikatem zgodnym z wytycznymi dotyczącymi certyfikatów standardowych w branży. Spowoduje to przekształcenie paska lokalizatora przeglądarki na zielony i opublikowanie nazwy firmy.
• Certyfikat wieloznaczny: ten certyfikat obsługuje dowolną liczbę poddomen na podstawie *.site.com, gdzie domena podrzędna zastąpi *. Nie obsługuje to jednak site.com, więc w przypadku, gdy użytkownicy uzyskują dostęp do witryny internetowej bez wpisywania wiodącego "www", certyfikat wieloznaczny nie obejmie tego.
• Certyfikaty z podpisem własnym: przeglądarki klienckie nie ufają tym certyfikatom i ostrzegają użytkownika, że certyfikat usługi wirtualnej nie jest częścią łańcucha zaufania. Certyfikaty z podpisem własnym są dobre do testowania lub środowisk, w których administratorzy kontrolują klientów i mogą bezpiecznie pomijać alerty zabezpieczeń przeglądarki. Obciążenia produkcyjne nigdy nie powinny używać certyfikatów z podpisem własnym.

Aby uzyskać więcej informacji, zobacz konfigurowanie kończenia żądań protokołu TLS za pomocą bramy aplikacji.

Rozmiar certyfikatu

Sprawdź sekcję Limity usługi Application Gateway, aby poznać obsługiwany maksymalny rozmiar certyfikatu TLS/SSL.

Kompleksowe szyfrowanie TLS

Komunikacja z serwerami zaplecza może nie być niezaszyfrowana. Być może masz wymagania dotyczące zabezpieczeń, wymagania dotyczące zgodności lub aplikacja może akceptować tylko bezpieczne połączenie. aplikacja systemu Azure Gateway ma kompleksowe szyfrowanie TLS w celu obsługi tych wymagań.

Kompleksowe szyfrowanie TLS umożliwia szyfrowanie i bezpieczne przesyłanie poufnych danych do zaplecza podczas korzystania z funkcji równoważenia obciążenia warstwy 7 usługi Application Gateway. Te funkcje obejmują koligację sesji opartą na plikach cookie, routing oparty na adresach URL, obsługę routingu na podstawie witryn, możliwość ponownego zapisywania lub wstrzykiwania nagłówków X-Forwarded-* itd.

Po skonfigurowaniu w trybie kompleksowej komunikacji TLS usługa Application Gateway przerywa sesje protokołu TLS w bramie i odszyfrowuje ruch użytkowników. Następnie stosuje skonfigurowane reguły, aby wybrać odpowiednie wystąpienie puli serwerów zaplecza w celu skierowania do nich ruchu. Następnie usługa Application Gateway inicjuje nowe połączenie TLS z serwerem zaplecza i ponownie szyfruje dane przy użyciu certyfikatu klucza publicznego serwera zaplecza przed przesłaniem żądania do zaplecza. Każda odpowiedź z serwera sieci Web przechodzi przez ten sam proces z powrotem do użytkownika końcowego. Kompleksowa obsługa protokołu TLS jest włączona przez ustawienie protokołu w ustawieniu protokołu HTTP zaplecza na HTTPS, które jest następnie stosowane do puli zaplecza.

W bramach jednostki SKU usługi Application Gateway w wersji 1 zasady protokołu TLS stosują wersję protokołu TLS tylko do ruchu frontonu i zdefiniowanych szyfrów zarówno do obiektów docelowych frontonu, jak i zaplecza. W bramach jednostki SKU usługi Application Gateway w wersji 2 zasady PROTOKOŁU TLS dotyczą tylko ruchu frontonu, połączenia TLS zaplecza będą zawsze negocjowane za pośrednictwem protokołu TLS 1.0 do wersji TLS 1.2.

Usługa Application Gateway komunikuje się tylko z tymi serwerami zaplecza, które mają certyfikat z listy dozwolonych z usługą Application Gateway lub których certyfikaty są podpisane przez dobrze znane urzędy certyfikacji, a nazwa pospolita certyfikatu jest zgodna z nazwą hosta w ustawieniach zaplecza HTTP. Obejmują one zaufane usługi platformy Azure, takie jak aplikacja systemu Azure Service/Web Apps i Azure API Management.

Jeśli certyfikaty członków w puli zaplecza nie są podpisane przez dobrze znane urzędy certyfikacji, każde wystąpienie w puli zaplecza z obsługą kompleksowego protokołu TLS musi być skonfigurowane z certyfikatem, aby umożliwić bezpieczną komunikację. Dodanie certyfikatu gwarantuje, że brama aplikacji komunikuje się tylko ze znanymi wystąpieniami zaplecza. Dodatkowo zabezpiecza to kompleksową komunikację.

Uwaga

Certyfikat dodany do ustawienia HTTP zaplecza w celu uwierzytelniania serwerów zaplecza może być taki sam jak certyfikat dodany do odbiornika w celu zakończenia protokołu TLS w usłudze Application Gateway lub inny w celu zwiększenia bezpieczeństwa.

W tym przykładzie żądania używające protokołu TLS1.2 są kierowane do serwerów zaplecza w puli Pool1 przy użyciu kompleksowego protokołu TLS.

Kompleksowe protokoły TLS i zezwalanie na wyświetlanie listy certyfikatów

Usługa Application Gateway komunikuje się tylko z tymi serwerami zaplecza, które mają certyfikat z listy dozwolonych z usługą Application Gateway lub których certyfikaty są podpisane przez dobrze znane urzędy certyfikacji, a nazwa pospolita certyfikatu jest zgodna z nazwą hosta w ustawieniach zaplecza HTTP. Istnieją pewne różnice w procesie kompleksowej konfiguracji protokołu TLS w odniesieniu do używanej wersji usługi Application Gateway. W poniższej sekcji opisano wersje osobno.

Kompleksowa obsługa protokołu TLS przy użyciu jednostki SKU w wersji 1

Aby umożliwić kompleksową obsługę protokołu TLS z serwerami zaplecza i usługą Application Gateway w celu kierowania żądań do nich, sondy kondycji muszą zakończyć się powodzeniem i zwrócić odpowiedź w dobrej kondycji.

W przypadku sond kondycji HTTPS jednostka SKU usługi Application Gateway w wersji 1 używa dokładnego dopasowania certyfikatu uwierzytelniania (klucza publicznego certyfikatu serwera zaplecza, a nie certyfikatu głównego), które mają zostać przekazane do ustawień PROTOKOŁU HTTP.

Następnie dozwolone są tylko połączenia ze znanymi i dozwolonymi zapleczami. Pozostałe zaplecza są uznawane za w złej kondycji przez sondy kondycji. Certyfikaty z podpisem własnym są przeznaczone tylko do celów testowych i nie są zalecane dla obciążeń w środowisku produkcyjnym. Takie certyfikaty muszą być wymienione na liście dozwolonych z bramą aplikacji zgodnie z opisem w poprzednich krokach, zanim będą mogły być używane.

Uwaga

Uwierzytelnianie i konfiguracja zaufanego certyfikatu głównego nie są wymagane dla zaufanych usług platformy Azure, takich jak usługa aplikacja systemu Azure Service. Są one domyślnie uznawane za zaufane.

Kompleksowa obsługa protokołu TLS przy użyciu jednostki SKU w wersji 2

Certyfikaty uwierzytelniania zostały wycofane i zastąpione przez zaufane certyfikaty główne w jednostce SKU usługi Application Gateway w wersji 2. Działają podobnie do certyfikatów uwierzytelniania z kilkoma kluczowymi różnicami:

• Certyfikaty podpisane przez dobrze znane urzędy certyfikacji, których cn pasuje do nazwy hosta w ustawieniach zaplecza HTTP, nie wymagają żadnego dodatkowego kroku, aby zakończyć pracę protokołu TLS.

  Jeśli na przykład certyfikaty zaplecza są wystawiane przez dobrze znany urząd certyfikacji i ma wartość CN contoso.com, a pole hosta ustawienia http zaplecza jest również ustawione na contoso.com, nie są wymagane żadne dodatkowe kroki. Protokół ustawień http zaplecza można ustawić na HTTPS, a zarówno sonda kondycji, jak i ścieżka danych będą włączone protokołem TLS. Jeśli używasz usługi aplikacja systemu Azure lub innych usług internetowych platformy Azure jako zaplecza, są one niejawnie zaufane, a żadne dalsze kroki nie są wymagane do kompleksowego protokołu TLS.

Uwaga

Aby certyfikat TLS/SSL był zaufany, ten certyfikat serwera zaplecza musi zostać wystawiony przez urząd certyfikacji, który jest dobrze znany. Jeśli certyfikat nie został wystawiony przez zaufany urząd certyfikacji, brama aplikacji sprawdzi, czy certyfikat urzędu wystawiającego certyfikat został wystawiony przez zaufany urząd certyfikacji i tak dalej, dopóki nie zostanie znaleziony zaufany urząd certyfikacji (w którym momencie zostanie nawiązane zaufane, bezpieczne połączenie) lub nie można odnaleźć zaufanego urzędu certyfikacji (w którym momencie brama aplikacji oznaczy kondycję zaplecza). W związku z tym zaleca się, aby certyfikat serwera zaplecza zawierał zarówno główne, jak i pośrednie urzędy certyfikacji.

• Jeśli certyfikat serwera zaplecza jest z podpisem własnym lub podpisany przez nieznany urząd certyfikacji/pośredników, należy przekazać pełny protokół TLS w usłudze Application Gateway w wersji 2, należy przekazać zaufany certyfikat główny. Usługa Application Gateway będzie komunikować się tylko z zapleczami, których certyfikat główny certyfikatu serwera jest zgodny z jedną z listy zaufanych certyfikatów głównych w ustawieniu http zaplecza skojarzonym z pulą.

• Oprócz dopasowania certyfikatu głównego usługa Application Gateway w wersji 2 sprawdza również, czy ustawienie Hosta określone w ustawieniu http zaplecza jest zgodne z nazwą pospolitą (CN) przedstawioną przez certyfikat TLS/SSL serwera zaplecza. Podczas próby nawiązania połączenia TLS z zapleczem usługa Application Gateway w wersji 2 ustawia rozszerzenie SNI (Server Name Indication) na hosta określonego w ustawieniu http zaplecza.

• Jeśli wybierz nazwę hosta z obiektu docelowego zaplecza zostanie wybrana zamiast pola Host w ustawieniu http zaplecza, nagłówek SNI jest zawsze ustawiony na nazwę FQDN puli zaplecza, a cn na serwerze zaplecza certyfikat TLS/SSL musi być zgodny z nazwą FQDN. Członkowie puli zaplecza z adresami IP nie są obsługiwani w tym scenariuszu.

• Certyfikat główny jest certyfikatem głównym zakodowanym w formacie base64 z certyfikatów serwera zaplecza.

Różnice sNI w jednostce SKU w wersji 1 i 2

Jak wspomniano wcześniej, usługa Application Gateway przerywa ruch TLS z klienta na odbiorniku usługi Application Gateway (nazwijmy go połączeniem frontonu), odszyfrowuje ruch, stosuje reguły niezbędne do określenia serwera zaplecza, do którego ma zostać przekazane żądanie, i ustanawia nową sesję protokołu TLS z serwerem zaplecza (nazwijmy go połączeniem zaplecza).

W poniższych tabelach opisano różnice w sieci SNI między jednostkami SKU w wersji 1 i w wersji 2 pod względem połączeń frontonu i zaplecza.

Połączenie TLS frontonu (klient z bramą aplikacji)

Scenariusz	v1	v2
Jeśli klient określa nagłówek SNI, a wszystkie odbiorniki z wieloma lokacjami są włączone z flagą "Wymagaj SNI"	Zwraca odpowiedni certyfikat i jeśli lokacja nie istnieje (zgodnie z server_name), połączenie zostanie zresetowane.	Zwraca odpowiedni certyfikat, jeśli jest dostępny, w przeciwnym razie zwraca certyfikat pierwszego odbiornika HTTPS zgodnie z kolejnością określoną przez reguły routingu żądań skojarzone z odbiornikami HTTPS
Jeśli klient nie określi nagłówka SNI i jeśli wszystkie nagłówki z wieloma witrynami są włączone z komunikatem "Wymagaj interfejsu SNI"	Resetuje połączenie	Zwraca certyfikat pierwszego odbiornika HTTPS zgodnie z kolejnością określoną przez reguły routingu żądań skojarzone z odbiornikami HTTPS
Jeśli klient nie określi nagłówka SNI i jeśli istnieje podstawowy odbiornik skonfigurowany przy użyciu certyfikatu	Zwraca certyfikat skonfigurowany w podstawowym odbiorniku do klienta (domyślny lub rezerwowy certyfikat)	Zwraca certyfikat skonfigurowany w odbiorniku podstawowym

Uwaga

Jeśli klient nie określa nagłówka SNI, zaleca się, aby użytkownik dodał podstawowy odbiornik i regułę, aby przedstawić domyślny certyfikat SSL/TLS.

Napiwek

Flagę SNI można skonfigurować przy użyciu programu PowerShell lub przy użyciu szablonu usługi ARM. Aby uzyskać więcej informacji, zobacz RequireServerNameIndication i Szybki start: bezpośredni ruch internetowy z aplikacja systemu Azure Gateway — szablon usługi ARM.

Połączenie TLS zaplecza (brama aplikacji z serwerem zaplecza)

Dla ruchu sondy

Scenariusz	v1	v2
Nagłówek SNI (server_name) podczas uzgadniania protokołu TLS jako nazwa FQDN	Ustaw jako nazwę FQDN z puli zaplecza. Zgodnie z RFC 6066 adresy IPv4 i IPv6 literału nie są dozwolone w nazwie hosta SNI. Uwaga: nazwa FQDN w puli zaplecza powinna rozpoznawać dns jako adres IP serwera zaplecza (publiczny lub prywatny)	Nagłówek SNI (server_name) jest ustawiany jako nazwa hosta z niestandardowej sondy dołączonej do ustawień HTTP (jeśli skonfigurowano), w przeciwnym razie z nazwy hosta wymienionej w ustawieniach HTTP, w przeciwnym razie z nazwy FQDN wymienionej w puli zaplecza. Kolejność pierwszeństwa to niestandardowa pula ustawień > http sondy > HTTP. Uwaga: Jeśli nazwy hostów skonfigurowane w ustawieniach PROTOKOŁU HTTP i sondy niestandardowej są inne, zgodnie z pierwszeństwem, nazwa hosta sieci SNI zostanie ustawiona jako nazwa hosta z sondy niestandardowej.
Jeśli adres puli zaplecza jest adresem IP (wersja 1) lub jeśli niestandardowa nazwa hosta sondy jest skonfigurowana jako adres IP (wersja 2)	SNI (server_name) nie zostanie ustawiona. Uwaga: W takim przypadku serwer zaplecza powinien mieć możliwość zwrócenia certyfikatu domyślnego/rezerwowego. Powinno to być wymienione na liście dozwolonych w ustawieniach protokołu HTTP w ramach certyfikatu uwierzytelniania. Jeśli na serwerze wewnętrznej bazy danych nie skonfigurowano certyfikatu domyślnego/rezerwowego, serwer może zresetować połączenie, co doprowadzi do niepowodzeń sondy	W kolejności pierwszeństwa wymienionej wcześniej, jeśli mają adres IP jako nazwę hosta, SNI nie zostanie ustawiona zgodnie z RFC 6066. Uwaga: SNI nie zostanie również ustawiona w sondach w wersji 2, jeśli nie skonfigurowano niestandardowej sondy i nie ustawiono nazwy hosta w ustawieniach protokołu HTTP lub puli zaplecza

Uwaga

Jeśli sonda niestandardowa nie jest skonfigurowana, usługa Application Gateway wysyła sondę domyślną w tym formacie — <protocol>://127.0.0.1:<port>/. Na przykład w przypadku domyślnej sondy HTTPS zostanie ona wysłana jako https://127.0.0.1:443/. Należy pamiętać, że wymieniona tutaj wersja 127.0.0.1 jest używana tylko jako nagłówek hosta HTTP i zgodnie z specyfikacją RFC 6066 nie będzie używana jako nagłówek SNI. Aby uzyskać więcej informacji na temat błędów sondy kondycji, zapoznaj się z przewodnikiem rozwiązywania problemów z kondycją zaplecza.

W przypadku ruchu na żywo

Scenariusz	v1	v2
Nagłówek SNI (server_name) podczas uzgadniania protokołu TLS jako nazwa FQDN	Ustaw jako nazwę FQDN z puli zaplecza. Zgodnie z RFC 6066 adresy IPv4 i IPv6 literału nie są dozwolone w nazwie hosta SNI. Uwaga: nazwa FQDN w puli zaplecza powinna rozpoznawać dns jako adres IP serwera zaplecza (publiczny lub prywatny)	Nagłówek SNI (server_name) jest ustawiany jako nazwa hosta z ustawień HTTP, w przeciwnym razie jeśli wybrano opcję PickHostnameFromBackendAddress lub jeśli nazwa hosta nie zostanie wymieniona, zostanie ustawiona jako nazwa FQDN w konfiguracji puli zaplecza
Jeśli adres puli zaplecza to adres IP lub nazwa hosta nie jest ustawiona w ustawieniach protokołu HTTP	SNI nie zostanie ustawiona zgodnie z specyfikacją RFC 6066 , jeśli wpis puli zaplecza nie jest nazwą FQDN	Nazwa SNI zostanie ustawiona jako nazwa hosta z wejściowej nazwy FQDN z klienta, a nazwa pospolita certyfikatu zaplecza musi być zgodna z tą nazwą hosta.
Nazwa hosta nie jest podana w ustawieniach protokołu HTTP, ale nazwa FQDN jest określona jako element docelowy dla elementu członkowskiego puli zaplecza	Nazwa SNI zostanie ustawiona jako nazwa hosta z wejściowej nazwy FQDN z klienta, a nazwa pospolita certyfikatu zaplecza musi być zgodna z tą nazwą hosta.	Nazwa SNI zostanie ustawiona jako nazwa hosta z wejściowej nazwy FQDN z klienta, a nazwa pospolita certyfikatu zaplecza musi być zgodna z tą nazwą hosta.

Następne kroki

Po zapoznaniu się z kompleksową obsługą protokołu TLS przejdź do tematu Konfigurowanie kompleksowego protokołu TLS przy użyciu usługi Application Gateway i programu PowerShell , aby utworzyć bramę aplikacji przy użyciu kompleksowego protokołu TLS.