Konfigurowanie składników bramy aplikacja systemu Azure
aplikacja systemu Azure Gateway zawiera szereg składników, które łączą się w celu kierowania żądań do puli serwerów internetowych i sprawdzania kondycji tych serwerów sieci Web. Składniki te obejmują adres IP frontonu, pule zaplecza, reguły routingu, sondy kondycji i odbiorniki. Jako opcja brama może również zaimplementować zaporę.
Informacje o składnikach usługi Application Gateway
Przyjrzyjmy się, w jaki sposób składniki bramy aplikacji współpracują ze sobą.
Adres IP frontonu odbiera żądania klienta.
Opcjonalna zapora aplikacji internetowej sprawdza ruch przychodzący pod kątem typowych zagrożeń, zanim żądania dotrą do odbiorników.
Co najmniej jeden odbiornik odbiera ruch i kieruje żądania do puli zaplecza.
Reguły routingu definiują sposób analizowania żądania w celu kierowania żądania do odpowiedniej puli zaplecza.
Pula zaplecza zawiera serwery internetowe dla zasobów, takich jak maszyny wirtualne lub zestawy skalowania maszyn wirtualnych. Każda pula ma moduł równoważenia obciążenia do dystrybucji obciążenia między zasoby.
Sondy kondycji określają, które serwery puli zaplecza są dostępne do równoważenia obciążenia.
Poniższy schemat blokowy pokazuje, jak składniki usługi Application Gateway współpracują ze sobą w celu kierowania żądań ruchu między pulami frontonu i zaplecza w konfiguracji.
Adres IP frontonu
Żądania klientów są odbierane za pośrednictwem adresu IP frontonu. Brama aplikacji może mieć publiczny lub prywatny adres IP albo oba te adresy. Możesz mieć tylko jeden publiczny adres IP i tylko jeden prywatny adres IP.
Zapora aplikacji internetowej (opcjonalnie)
Zaporę aplikacji internetowej platformy Azure dla usługi aplikacja systemu Azure Gateway można włączyć do obsługi żądań przychodzących przed dotarciem do odbiornika. Zapora sprawdza każde żądanie zagrożeń w oparciu o projekt Open Web Application Security (OWASP). Typowe zagrożenia obejmują wstrzyknięcie kodu SQL, wykonywanie skryptów między witrynami, wstrzyknięcie poleceń, przemycanie żądań HTTP i dzielenie odpowiedzi oraz dołączanie plików zdalnych. Inne zagrożenia mogą pochodzić z botów, przeszukiwarki, skanerów i naruszeń protokołu HTTP oraz anomalii.
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. Usługa Azure Web Application Firewall obsługuje dwa zestawy reguł: CRS 2.2.9 i CRS 3.0. Zestaw CRS 3.0 jest zestawem domyślnym i jest nowszy niż zestaw CRS 2.2.9. W razie potrzeby możesz wybrać tylko określone reguły w zestawie reguł w celu kierowania 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.
Odbiorniki
Odbiorniki akceptują ruch przychodzący do określonej kombinacji protokołu, portu, hosta i adresu IP. Każdy odbiornik kieruje żądania do puli zaplecza serwerów zgodnie z regułami routingu. Odbiornik może być podstawowy lub obsługujący wiele witryn. Odbiornik podstawowy kieruje żądania 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 odbiorniki z pulami zaplecza. Reguła określa, jak interpretować elementy nazwy hosta i ścieżki w adresie URL żądania, a następnie 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łączenia, okres przekroczenia limitu czasu żądania i sondy kondycji.
Pule zaplecza
Pula zaplecza odwołuje się do kolekcji serwerów internetowych. Podczas konfigurowania puli podajesz adres IP poszczególnych serwerów internetowych oraz port, na którym nasłuchują one żądań. Każda pula może określać stały zestaw maszyn wirtualnych, zestawy skalowania maszyn wirtualnych, aplikację hostowaną przez usługi aplikacja systemu Azure lub kolekcję serwerów lokalnych. Każda pula zaplecza ma skojarzony moduł równoważenia obciążenia, który dystrybuuje pracę między pulą.
Sondy kondycji
Sondy kondycji określają, które serwery w puli zaplecza są dostępne do równoważenia obciążenia. Usługa Application Gateway używa sondy kondycji do wysł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 czeka 30 sekund przed zidentyfikowaniem serwera jako niedostępnego (w złej kondycji).