Najlepsze rozwiązania dotyczące usługi Azure Front Door

Ten artykuł przedstawia najlepsze praktyki konfigurowania i korzystania z Azure Front Door.

Ogólne sprawdzone metody postępowania

Informacje o tym, kiedy połączyć usługę Traffic Manager i usługę Azure Front Door

W większości rozwiązań używaj Azure Front Door lubAzure Traffic Manager, ale nie obu. Traffic Manager to oparty na systemie DNS moduł równoważenia obciążenia. Wysyła ruch bezpośrednio do punktów końcowych źródła. Z kolei usługa Azure Front Door przerywa połączenia w punktach obecności (PoPs) w pobliżu klienta i ustanawia oddzielne długotrwałe połączenia ze źródłami. Produkty działają inaczej i są przeznaczone do różnych przypadków użycia.

Jeśli potrzebujesz buforowania i dostarczania zawartości, kończenia żądań PROTOKOŁU TLS, zaawansowanych funkcji routingu lub zapory aplikacji internetowej (WAF), rozważ użycie usługi Azure Front Door. W przypadku prostego globalnego równoważenia obciążenia z połączeniami bezpośrednimi od klienta do punktów końcowych rozważ użycie usługi Traffic Manager. Aby uzyskać więcej informacji na temat wybierania opcji równoważenia obciążenia, zobacz Opcje równoważenia obciążenia.

W ramach złożonej architektury wymagającej wysokiej dostępności można umieścić usługę Traffic Manager przed usługą Azure Front Door. W mało prawdopodobnym przypadku niedostępności usługi Azure Front Door usługa Traffic Manager może następnie kierować ruch do alternatywnego miejsca docelowego, takiego jak usługa Azure Application Gateway lub sieć dostarczania zawartości partnera (CDN).

Ogranicz ruch do swoich źródeł

Funkcje usługi Azure Front Door działają najlepiej, gdy ruch przepływa tylko przez usługę Azure Front Door. Należy skonfigurować źródło, aby blokować ruch, który nie jest wysyłany za pośrednictwem usługi Azure Front Door. Aby uzyskać więcej informacji, zobacz Bezpieczne przesyłanie ruchu do punktów końcowych Azure Front Door.

Korzystanie z najnowszej wersji interfejsu API i wersji zestawu SDK

Gdy pracujesz z Azure Front Door, korzystając z API, szablonów Azure Resource Manager, Bicep lub Azure SDKs, korzystaj z najnowszej dostępnej wersji API lub SDK. Aktualizacje interfejsu API i zestawu SDK są wykonywane, gdy są dostępne nowe funkcje i zawierają ważne poprawki zabezpieczeń i poprawki błędów.

Konfigurowanie dzienników

Usługa Azure Front Door śledzi obszerne dane wydajności dla każdego żądania. Po włączeniu buforowania serwery pochodzenia mogą nie odbierać każdego żądania. Korzystaj z logów Azure Front Door, aby zrozumieć, jak działa Twoje rozwiązanie i jak reaguje na klientów. Aby uzyskać więcej informacji na temat metryk i dzienników, które rejestruje usługa Azure Front Door, zobacz Monitorowanie metryk i dzienników w Azure Front Door oraz dzienniki zapory aplikacji sieci Web (WAF).

Aby skonfigurować rejestrowanie dla własnej aplikacji, zobacz Konfigurowanie dzienników usługi Azure Front Door.

Najlepsze rozwiązania dotyczące protokołu TLS

Używanie kompleksowego protokołu TLS

Usługa Azure Front Door przerywa połączenia TCP i TLS z klientów. Następnie ustanawia nowe połączenia z każdego punktu obecności (PoP) do punktu początkowego. Zabezpiecz każde z tych połączeń za pomocą TLS, nawet dla originów hostowanych w Azure. Takie podejście pozwala na szyfrowanie danych podczas przesyłania.

Aby uzyskać więcej informacji, zobacz Pełne wdrożenie TLS z usługą Azure Front Door.

Wybierz kompatybilne grupy wymiany kluczy TLS

W przypadku niestandardowych domen Azure Front Door Standard i Premium zacznij od polityki wymiany kluczy Standard TLS, chyba że wymagania wymagają innego wyboru. Przetestuj przeglądarki, urządzenia, SDK i zautomatyzowanych klientów przed ograniczeniem obsługiwanych grup. Jeśli zezwalasz na TLS 1.2, uwzględnij przynajmniej jedną grupę klasyczną w niestandardowej polityce.

Hybrydowa wymiana kluczy postkwantowych wymaga TLS 1.3. Polityka wymiany kluczy domeny kontroluje połączenia klient-Front Door; nie konfiguruje wymiany kluczy na oddzielnym połączeniu źródłowym. Kontynuuj konfigurowanie HTTPS dla źródła. Opcje polityki i wytyczne dotyczące kompatybilności można znaleźć w artykule o polityce wymiany kluczy TLS.

Użyj przekierowania z HTTP na HTTPS

Klienci powinni używać HTTPS, aby łączyć się z twoją usługą. Jednak czasami należy zaakceptować żądania HTTP, aby zezwolić na starszych klientów lub klientów, którzy mogą nie przestrzegać zasad najlepszych praktyk.

Usługę Azure Front Door można skonfigurować tak, aby automatycznie przekierowywać żądania HTTP do korzystania z protokołu HTTPS. Włącz opcję Przekierowania ruchu na HTTPS na swojej trasie.

Używanie zarządzanych certyfikatów TLS

Gdy usługa Azure Front Door zarządza certyfikatami TLS, zmniejsza koszty operacyjne i pomaga uniknąć kosztowych przestojów spowodowanych zapominaniem o odnowieniu certyfikatu. Azure Front Door automatycznie wydaje i rotuje zarządzane certyfikaty TLS dla większości niestandardowych domen.

W przypadku domen wierzchołkowych automatyczna rotacja certyfikatów wymaga ponownego zatwierdzenia własności domeny. Gdy domena wejdzie w stan Oczekującej rewalidacji , wygeneruj ponownie token DNS TXT i zaktualizuj rekord TXT. Więcej informacji można znaleźć w Azure Front Door managed TLS certificate rotation. Aby dowiedzieć się, jak skonfigurować HTTPS, zobacz Configure HTTPS on an Azure Front Door custom domain.

Używanie najnowszej wersji dla certyfikatów zarządzanych przez klienta

Jeśli zdecydujesz się używać własnych certyfikatów TLS, rozważ ustawienie wersji certyfikatu usługi Azure Key Vault na Najnowsza. Korzystając z najnowszej wersji, należy unikać ponownego konfigurowania usługi Azure Front Door w celu używania nowych wersji certyfikatu i oczekiwania na wdrożenie certyfikatu w środowiskach usługi Azure Front Door.

Aby uzyskać więcej informacji, zobacz Wybieranie certyfikatu dla usługi Azure Front Door do wdrożenia.

Najlepsze rozwiązania dotyczące domeny

Wdrażanie domen niestandardowych

Wdrażanie domen niestandardowych dla punktów końcowych usługi Azure Front Door w celu zapewnienia lepszej dostępności i elastyczności podczas zarządzania domenami i ruchem. Nie zapisuj na stałe domen udostępnianych przez usługę Azure Front Door (na przykład *.azurefd.z01.net) w klientach, bazach kodu lub zaporach. W takich scenariuszach należy używać domen niestandardowych.

Użyj tej samej nazwy domeny w usłudze Azure Front Door oraz w oryginale.

Usługa Azure Front Door może przepisać Host nagłówek żądań przychodzących. Ta funkcja może być przydatna w przypadku zarządzania zestawem niestandardowych nazw domen przeznaczonych dla klientów kierowanych do pojedynczego źródła. Ta funkcja może również pomóc, jeśli chcesz uniknąć konfigurowania niestandardowych nazw domen w usłudze Azure Front Door i w miejscu pochodzenia.

Jednak ponowne zapisywanie nagłówka Host może spowodować przerwanie żądań plików cookie i przekierowań adresów URL. W szczególności w przypadku korzystania z platform, takich jak usługi Azure App Service, funkcje, takie jak afinitet sesji oraz uwierzytelnianie i autoryzacja, mogą nie działać poprawnie.

Przed ponownym zapisem Host nagłówka żądań należy dokładnie zastanowić się, czy aplikacja będzie działać poprawnie. pl-PL: Aby uzyskać więcej informacji, zobacz Zachowywanie oryginalnej nazwy hosta HTTP między serwerem proxy zwrotnym a jego aplikacją internetową zaplecza.

Najlepsze praktyki dotyczące zapór aplikacji internetowych

W przypadku aplikacji dostępnych z Internetu włącz usługę Azure Front Door WAF. W Azure Front Door Premium konfiguruj WAF tak, aby korzystał z reguł zarządzanych przez Microsoft, które pomagają chronić Twoją aplikację przed szerokim zakresem ataków. Aby uzyskać dostępność funkcji WAF specyficznych dla poziomów, zobacz Compare Azure Front Door tiers. Aby uzyskać więcej informacji, zobacz Web Application Firewall (WAF) w usłudze Azure Front Door.

Zapora aplikacji internetowej dla usługi Azure Front Door ma własny zestaw najlepszych rozwiązań dotyczących konfiguracji i użycia. Aby uzyskać więcej informacji, zobacz Najlepsze rozwiązania dotyczące zapory aplikacji internetowej w usłudze Azure Front Door.

Najlepsze rozwiązania dotyczące sond kondycji

Wyłącz sondy zdrowia, gdy istnieje tylko jedno źródło w grupie pochodzenia

Sondy zdrowotne w usłudze Azure Front Door mogą wykrywać sytuacje, w których źródło jest niedostępne lub nie jest w dobrym stanie. Usługę Azure Front Door można skonfigurować tak, aby wysyłała ruch do innego źródła w grupie pochodzenia, gdy sonda kondycji wykryje problem ze źródłem.

Jeśli masz tylko jedno źródło, usługa Azure Front Door zawsze kieruje ruch do tego źródła, nawet jeśli jego sonda kondycji zgłasza nieprawidłowy stan. Stan sondy kondycji nie robi nic, aby zmienić zachowanie usługi Azure Front Door. W tym scenariuszu sondy kondycji nie zapewniają korzyści i należy je wyłączyć, aby zmniejszyć ruch w miejscu pochodzenia.

Aby uzyskać więcej informacji, zobacz Sondy kondycji.

Wybieranie dobrych punktów końcowych

Rozważ lokalizację, w której sonda zdrowotna usługi Azure Front Door ma przeprowadzać monitoring. Zazwyczaj dobrym pomysłem jest monitorowanie strony internetowej lub lokalizacji, którą specjalnie projektujesz pod kątem monitorowania kondycji. Logika aplikacji może uwzględniać stan wszystkich krytycznych składników wymaganych do obsługi ruchu produkcyjnego, w tym serwerów aplikacji, baz danych i pamięci podręcznych. W ten sposób, jeśli jakikolwiek składnik ulegnie awarii, Azure Front Door może kierować ruch do innej instancji usługi.

Aby uzyskać więcej informacji, zobacz Wzorzec monitorowania punktu końcowego kondycji.

Korzystanie z sond kondycji HEAD

Sondy kondycji mogą używać metody HTTP GET lub HEAD. Dobrym rozwiązaniem jest użycie HEAD metody dla sond kondycji, ponieważ zmniejsza ilość ruchu w źródłach.

Aby uzyskać więcej informacji, zobacz Obsługiwane metody HTTP dla sond kondycji.

Następny krok