Jak działa usługa aplikacja systemu Azure Gateway
aplikacja systemu Azure Gateway zawiera szereg składników, które łączą się w celu bezpiecznego kierowania i równoważenia obciążenia żądań między pulą serwerów internetowych. Usługa Application Gateway zawiera następujące składniki:
- Adres IP frontonu: żądania klientów są odbierane za pośrednictwem adresu IP frontonu. Możesz skonfigurować bramę aplikacji w taki sposób, aby miała publiczny adres IP, prywatny adres IP lub oba te adresy. Usługa Application Gateway nie może mieć więcej niż jednego publicznego adresu IP i jednego prywatnego adresu IP.
- Odbiorniki: usługa Application Gateway używa co najmniej jednego odbiornika do odbierania żądań przychodzących. Odbiornik akceptuje ruch przychodzący na podstawie określonej kombinacji protokołu, portu, hosta i adresu IP. Każdy odbiornik kieruje żądania do puli zaplecza serwerów zgodnie z określonymi przez Ciebie regułami routingu. Odbiornik może być podstawowy lub obsługujący wiele witryn. Odbiornik podstawowy kieruje żądanie tylko na podstawie ścieżki w adresie URL. Odbiornik z wieloma witrynami może również kierować żądania przy użyciu elementu nazwa hosta adresu URL. Odbiorniki obsługują również certyfikaty TLS/SSL na potrzeby zabezpieczania aplikacji między użytkownikiem i usługą Application Gateway.
- Reguły routingu: reguła routingu wiąże odbiornik z pulami zaplecza. Reguła określa, jak interpretować nazwę hosta i elementy ścieżki w adresie URL żądania i kierować żądanie do odpowiedniej puli zaplecza. Reguła routingu ma również skojarzony zestaw ustawień protokołu HTTP. Te ustawienia PROTOKOŁU HTTP wskazują, czy ruch (i jak) jest szyfrowany między usługą Application Gateway i serwerami zaplecza. Inne informacje o konfiguracji obejmują protokół, trwałość sesji, opróżnianie Połączenie ion, okres przekroczenia limitu czasu żądania i sondy kondycji.
Równoważenie obciążenia w usłudze Application Gateway
Usługa Application Gateway automatycznie równoważy obciążenie żądań wysyłanych do serwerów w każdej puli zaplecza przy użyciu mechanizmu działania okrężnego. Równoważenie obciążenia działa wraz z routingiem warstwy OSI 7 implementowanym przez routing usługi Application Gateway, co oznacza, że równoważenie obciążenia żądań ma miejsce na podstawie parametrów routingu (nazwy hostów i ścieżki) używanych przez reguły usługi Application Gateway. Dla porównania inne moduły równoważenia obciążenia, takie jak Usługa Azure Load Balancer, działają na poziomie WARSTWy 4 OSI i dystrybuują ruch na podstawie adresu IP docelowego żądania.
Można skonfigurować trwałość sesji, jeśli musisz upewnić się, że wszystkie żądania klienta w tej samej sesji są kierowane do tego samego serwera w puli zaplecza.
Zapora aplikacji internetowej
Zapora aplikacji internetowej to opcjonalny składnik, który obsługuje żądania przychodzące zanim dotrą one do odbiornika. Zapora aplikacji internetowej sprawdza każde żądanie pod kątem wielu typowych zagrożeń w oparciu o projekt Open Web Application Security Project (OWASP). Typowe zagrożenia obejmują: wstrzyknięcie kodu SQL, wykonywanie skryptów między witrynami, wstrzyknięcie poleceń, przemyt żądań HTTP, dzielenie odpowiedzi HTTP, dołączanie plików zdalnych, boty, przeszukiwarki i skanery oraz naruszenia i anomalie protokołu HTTP.
Program OWASP definiuje zestaw ogólnych reguł wykrywania ataków. Reguły te są określane jako podstawowy zestaw reguł (CRS, Core Rule Set). Zestawy reguł są pod stałą kontrolą, ponieważ metody ataków są coraz bardziej wyszukane. Zapora aplikacji internetowej obsługuje cztery zestawy reguł: CRS 3.2, 3.1, 3.0 i 2.2.9. CrS 3.1 jest wartością domyślną. Jeśli to konieczne, możesz zdecydować się na wybranie tylko określonego zestawu reguł dotyczącego określonych zagrożeń. Ponadto możesz dostosować zaporę w taki sposób, aby określić elementy w żądaniu, które mają być sprawdzane, oraz ograniczyć rozmiar komunikatów w celu zapobiegania przeciążaniu serwerów przez masowe operacje przekazywania.
Pule zaplecza
Pula zaplecza to kolekcja serwerów internetowych, które mogą składać się z: stałego zestawu maszyn wirtualnych, zestawu skalowania maszyn wirtualnych, aplikacji hostowanej przez usługi aplikacja systemu Azure lub kolekcji serwerów lokalnych.
Każda pula zaplecza ma skojarzony moduł równoważenia obciążenia, który dystrybuuje pracę między pulą. Podczas konfigurowania puli należy podać adres IP lub nazwę każdego serwera internetowego. Wszystkie serwery w puli zaplecza powinny być skonfigurowane w taki sam sposób, w tym ich ustawienia zabezpieczeń.
Jeśli używasz protokołu TLS/SSL, pula zaplecza ma ustawienie HTTP odwołujące się do certyfikatu używanego do uwierzytelniania serwerów zaplecza. Brama ponownie szyfruje ruch przy użyciu tego certyfikatu przed wysłaniem go do jednego z serwerów w puli zaplecza.
Jeśli używasz usługi aplikacja systemu Azure do hostowania aplikacji zaplecza, nie musisz instalować żadnych certyfikatów w usłudze Application Gateway, aby nawiązać połączenie z pulą zaplecza. Cała komunikacja jest szyfrowana automatycznie. Usługa Application Gateway ufa serwerom, ponieważ zarządza nimi platforma Azure.
Usługa Application Gateway używa reguły do określania sposobu kierowania komunikatów odbieranych na porcie przychodzącym do serwerów w puli zaplecza. Jeśli serwery korzystają z protokołu TLS/SSL, należy skonfigurować regułę tak, aby wskazywała:
- Że serwery oczekują ruchu za pośrednictwem protokołu HTTPS.
- którego certyfikatu użyć do szyfrowania ruchu i uwierzytelniania połączenia z serwerem.
Routing usługi Application Gateway
Gdy brama kieruje żądanie klienta do serwera internetowego w puli zaplecza, używa zestawu reguł skonfigurowanych dla bramy w celu określenia, gdzie powinno nastąpić żądanie. Istnieją dwie podstawowe metody routingu ruchu żądań klienta: routing oparty na ścieżkach i routing wielu lokacji.
Routing oparty na ścieżkach
Routing oparty na ścieżkach wysyła żądania z różnymi ścieżkami adresów URL do różnych pul serwerów zaplecza. Można na przykład kierować żądania ze ścieżką /video/* do puli zaplecza zawierającej serwery zoptymalizowane pod kątem obsługi przesyłania strumieniowego wideo i kierować żądania /images/* do puli serwerów obsługujących pobieranie obrazów.
Routing wielu lokacji
Routing wielu witryn konfiguruje więcej niż jedną aplikację internetową w tym samym wystąpieniu usługi Application Gateway. W konfiguracji obejmującej wiele lokacji należy zarejestrować wiele nazw DNS (CNAM) dla adresu IP bramy aplikacji, określając nazwę każdej lokacji. Usługa Application Gateway używa oddzielnych odbiorników w celu oczekiwania na żądania dla poszczególnych witryn. Dany odbiornik przekazuje żądanie do innej reguły, która może kierować żądania do serwerów w innej puli zaplecza. Można na przykład kierować wszystkie żądania do http://contoso.com serwerów w jednej puli zaplecza i żądania do http://fabrikam.com innej puli zaplecza. Na poniższym diagramie przedstawiono tę konfigurację:
Konfiguracje wielu lokacji są przydatne do obsługi aplikacji wielodostępnych, w których każda dzierżawa ma własny zestaw maszyn wirtualnych lub inne zasoby hostowane przez aplikację internetową.
Routing usługi Application Gateway obejmuje również następujące funkcje:
- Przekierowanie. Przekierowanie może służyć do innej witryny lub z protokołu HTTP do protokołu HTTPS.
- Ponowne zapisywanie nagłówków HTTP. Nagłówki HTTP umożliwiają klientowi i serwerowi przekazywanie informacji o parametrach za pomocą żądania lub odpowiedzi.
- Niestandardowe strony błędów. Usługa Application Gateway umożliwia tworzenie niestandardowych stron błędów wyświetlanych zamiast domyślnych strony błędów. W przypadku niestandardowych stron błędów możesz użyć własnych oznakowań i układu.
Kończenie żądań PROTOKOŁU TLS/SSL
Po zakończeniu połączenia TLS/SSL w bramie aplikacji odciąża obciążenie kończenia żądań TLS/SSL intensywnie korzystających z procesora CPU z serwerów. Ponadto nie trzeba instalować certyfikatów i konfigurować protokołu TLS/SSL na serwerach.
Jeśli potrzebujesz kompleksowego szyfrowania, usługa Application Gateway może odszyfrować ruch w bramie przy użyciu klucza prywatnego, a następnie ponownie zaszyfrować klucz publiczny usługi uruchomionej w puli zaplecza.
Ruch przechodzi do bramy za pośrednictwem portu frontonu. Można otworzyć kilka portów, a usługa Application Gateway może odbierać komunikaty na dowolnym z nich. Odbiornik to pierwszy element, który napotyka ruch podczas przechodzenia przez bramę za pośrednictwem portu. Odbiornik jest skonfigurowany do nasłuchiwania określonej nazwy hosta i określonego portu na określonym adresie IP. Odbiornik może użyć certyfikatu TLS/SSL, aby odszyfrować ruch, który wchodzi do bramy. Następnie odbiornik używa zdefiniowanej reguły w celu kierowania żądań przychodzących do puli zaplecza.
Udostępnianie witryny internetowej lub aplikacji internetowej za pośrednictwem usługi Application Gateway oznacza również, że serwery nie są bezpośrednio połączone z Internetem. Ujawniasz tylko port 80 lub port 443 w bramie aplikacji, który jest następnie przekazywany do serwera puli zaplecza. W tej konfiguracji serwery internetowe nie są bezpośrednio dostępne z Internetu, co zmniejsza obszar ataków infrastruktury.
Sondy kondycji
Sondy kondycji określają, które serwery są dostępne do równoważenia obciążenia w puli zaplecza. Usługa Application Gateway używa sondy kondycji do wysyłania żądania do serwera. Gdy serwer zwraca odpowiedź HTTP z kodem stanu z zakresu od 200 do 399, serwer jest uznawany za w dobrej kondycji. Jeśli nie skonfigurujesz sondy kondycji, usługa Application Gateway utworzy domyślną sondę, która będzie oczekiwać przez 30 sekund przed podjęciem decyzji, że serwer jest niedostępny. Sondy kondycji zapewniają, że ruch nie jest kierowany do nieodpowiadanego lub nieudanego internetowego punktu końcowego w puli zaplecza.
Skalowanie automatyczne
Usługa Application Gateway obsługuje skalowanie automatyczne i może skalować w górę lub w dół na podstawie zmieniających się wzorców obciążenia ruchu. Dzięki skalowaniu automatycznemu nie trzeba również wybierać rozmiaru wdrożenia ani liczby wystąpień podczas aprowizowania usługi.
Ruch Protokołu WebSocket i HTTP/2
Usługa Application Gateway zapewnia natywną obsługę protokołów WebSocket i HTTP/2. Protokoły WebSocket i HTTP/2 umożliwiają pełną komunikację dwukierunkową między serwerem a klientem przez długotrwałe połączenie TCP. Ten typ komunikacji jest bardziej interaktywny między serwerem internetowym a klientem i może być dwukierunkowy bez konieczności sondowania zgodnie z wymaganiami w implementacjach opartych na protokole HTTP. Te protokoły mają niskie obciążenie (w przeciwieństwie do protokołu HTTP) i mogą ponownie używać tego samego połączenia TCP dla wielu żądań/odpowiedzi, co skutkuje bardziej wydajnym wykorzystaniem zasobów. Te protokoły są przeznaczone do pracy z użyciem tradycyjnych portów HTTP, tj. 80 i 443.