Uwidacznianie usługi Azure Spring Apps za pośrednictwem zwrotnego serwera proxy

Podczas hostowania aplikacji lub mikrousług w usłudze Azure Spring Apps nie zawsze chcesz publikować je bezpośrednio w Internecie. Zamiast tego możesz udostępnić je za pośrednictwem zwrotnego serwera proxy. Takie podejście umożliwia umieszczenie usługi przed aplikacjami. Usługa może definiować funkcje krzyżowe, takie jak zapora aplikacji internetowej (WAF), które ułatwiają zabezpieczanie aplikacji, równoważenia obciążenia, routingu, filtrowania żądań i ograniczania szybkości.

Podczas wdrażania typowej usługi zwrotnego serwera proxy, takiej jak aplikacja systemu Azure Gateway lub Azure Front Door przed usługą Azure Spring Apps, upewnij się, że aplikacje mogą być dostępne tylko za pośrednictwem zwrotnego serwera proxy. Ta ochrona pomaga zapobiec próbom obejścia limitów ograniczania przepustowości przez złośliwych użytkowników lub obejścia zapory aplikacji internetowej.

Usługa Azure DDoS Protection w połączeniu z najlepszymi rozwiązaniami dotyczącymi projektowania aplikacji zapewnia ulepszone funkcje ograniczania ryzyka ataków DDoS w celu zapewnienia większej ochrony przed atakami DDoS. Należy włączyć usługę Azure DDOS Protection w dowolnej sieci wirtualnej obwodowej.

W tym artykule opisano sposób wymuszania ograniczeń dostępu, aby aplikacje hostowane w usłudze Azure Spring Apps były dostępne tylko za pośrednictwem usługi zwrotnego serwera proxy. Zalecany sposób wymuszania tych ograniczeń zależy od sposobu wdrażania wystąpienia usługi Azure Spring Apps i zwrotnego serwera proxy, którego używasz. Są to różne kwestie, które należy wziąć pod uwagę w zależności od tego, czy wdrażasz w sieci wirtualnej, czy poza siecią wirtualną. Ten artykuł zawiera informacje o czterech scenariuszach.

• Wdróż usługę Azure Spring Apps w sieci wirtualnej i uzyskaj dostęp do aplikacji prywatnie z poziomu sieci.

  • Masz kontrolę nad siecią wirtualną, w której działają aplikacje. Użyj natywnych funkcji sieciowych platformy Azure, takich jak sieciowe grupy zabezpieczeń, aby zablokować dostęp, aby zezwolić tylko na zwrotny serwer proxy.

  • Aplikacje można uwidocznić publicznie w Internecie przy użyciu usługi aplikacja systemu Azure Gateway, a następnie zastosować odpowiednie ograniczenia dostępu, aby je zablokować. To podejście zostało opisane w scenariuszu 1 w dalszej części tego artykułu.

  • Nie można używać usługi Azure Front Door bezpośrednio, ponieważ nie może nawiązać połączenia z wystąpieniem usługi Azure Spring Apps w prywatnej sieci wirtualnej. Usługa Azure Front Door może łączyć się z zapleczami tylko za pośrednictwem publicznego adresu IP lub za pośrednictwem usług korzystających z prywatnego punktu końcowego. Jeśli masz wdrożenie w wielu regionach usługi Azure Spring Apps i wymaga globalnego równoważenia obciążenia, nadal możesz uwidocznić wystąpienia usługi Azure Spring Apps za pośrednictwem usługi Application Gateway. Aby osiągnąć ten scenariusz, należy umieścić usługę Azure Front Door przed usługą Application Gateway. To podejście zostało opisane w scenariuszu 2 w dalszej części tego artykułu.

• Wdróż usługę Azure Spring Apps poza siecią wirtualną i opublikuj aplikacje bezpośrednio w Internecie, jeśli przypiszesz do nich punkt końcowy.

  • Nie kontrolujesz sieci i nie można ograniczyć dostępu za pomocą sieciowych grup zabezpieczeń. Zezwalanie na dostęp tylko odwrotnego serwera proxy do uzyskiwania dostępu do aplikacji wymaga podejścia w ramach samej usługi Azure Spring Apps.

  • Ponieważ aplikacje są publicznie dostępne, możesz użyć usługi Application Gateway lub usługi Azure Front Door jako zwrotnego serwera proxy. Podejście usługi Application Gateway zostało opisane w scenariuszu 3 w dalszej części tego artykułu. Podejście usługi Azure Front Door zostało opisane w scenariuszu 4 w dalszej części tego artykułu.

  • W razie potrzeby można użyć kombinacji obu podejść. Jeśli używasz zarówno usługi Application Gateway, jak i usługi Azure Front Door, użyj tych samych ograniczeń dostępu między dwoma zwrotnymi serwerami proxy, które są używane w scenariuszu 2.

Porównanie scenariuszy

Poniższa tabela zawiera krótkie porównanie czterech scenariuszy konfiguracji zwrotnego serwera proxy dla usługi Azure Spring Apps. Aby uzyskać szczegółowe informacje na temat każdego scenariusza, zapoznaj się z odpowiednią sekcją tego artykułu.

Wdrażanie wewnątrz sieci wirtualnej

Gdy usługa Azure Spring Apps jest wdrażana w sieci wirtualnej, używa dwóch podsieci:

• Podsieć środowiska uruchomieniowego usługi zawierająca odpowiednie zasoby sieciowe
• Podsieć aplikacji, która hostuje kod

Ponieważ podsieć środowiska uruchomieniowego usługi zawiera moduł równoważenia obciążenia do łączenia się z aplikacjami, można zdefiniować sieciową grupę zabezpieczeń w tej podsieci środowiska uruchomieniowego usługi, aby zezwolić na ruch tylko z zwrotnego serwera proxy. Jeśli zablokujesz cały inny ruch, nikt w sieci wirtualnej nie będzie mógł uzyskać dostępu do aplikacji bez przechodzenia przez zwrotny serwer proxy.

Każda aplikacja, którą chcesz uwidocznić za pośrednictwem zwrotnego serwera proxy, powinna mieć przypisany punkt końcowy, aby zwrotny serwer proxy mógł uzyskać dostęp do aplikacji w sieci wirtualnej. Dla każdej aplikacji należy również mapować używane domeny niestandardowe, aby uniknąć zastępowania nagłówka HTTP Host na zwrotnym serwerze proxy i zachować oryginalną nazwę hosta bez zmian. Ta metoda pozwala uniknąć problemów, takich jak uszkodzone pliki cookie lub adresy URL przekierowania, które nie działają prawidłowo. Aby uzyskać więcej informacji, zobacz Zachowywanie nazwy hosta.

Scenariusz 1. Używanie usługi Application Gateway jako zwrotnego serwera proxy

Scenariusz 1 opisuje sposób publicznego uwidaczniania aplikacji w Internecie przy użyciu usługi Application Gateway , a następnie stosowanie odpowiednich ograniczeń dostępu w celu jego zablokowania.

Na poniższym diagramie przedstawiono architekturę scenariusza 1:

Pobierz plik programu Visio z tą architekturą.

Gdy usługa Application Gateway znajduje się przed wystąpieniem usługi Azure Spring Apps, użyj przypisanego punktu końcowego aplikacji Spring Cloud Gateway jako puli zaplecza. Przykładowy punkt końcowy to myspringcloudservice-myapp.private.azuremicroservices.io. Punkt końcowy jest rozpoznawany jako prywatny adres IP w podsieci środowiska uruchomieniowego usługi. W związku z tym, aby ograniczyć dostęp, można umieścić sieciową grupę zabezpieczeń w podsieci środowiska uruchomieniowego usługi z następującymi regułami zabezpieczeń dla ruchu przychodzącego (dając regułę Odmowy najniższy priorytet):

Konfiguracja scenariusza 1 zapewnia, że podsieć środowiska uruchomieniowego usługi zezwala na ruch tylko z następujących źródeł:

• Dedykowana podsieć usługi Application Gateway
• Podsieć aplikacji (wymagana jest dwukierunkowa komunikacja między dwiema podsieciami usługi Azure Spring Apps).
• Moduł równoważenia obciążenia platformy Azure (co jest ogólnym wymaganiem platformy Azure)

Cały inny ruch jest blokowany.

Scenariusz 2. Używanie zarówno usługi Azure Front Door, jak i usługi Application Gateway jako zwrotnego serwera proxy

Jak wspomniano wcześniej, nie można umieścić usługi Azure Front Door bezpośrednio przed usługą Azure Spring Apps, ponieważ nie może nawiązać połączenia z prywatną siecią wirtualną. (Usługa Azure Front Door Standard lub Premium może łączyć się z prywatnymi punktami końcowymi w sieci wirtualnej, ale usługa Azure Spring Apps obecnie nie oferuje obsługi prywatnego punktu końcowego). Jeśli nadal chcesz użyć usługi Azure Front Door, takiej jak wymaganie globalnego równoważenia obciążenia w wielu wystąpieniach usługi Azure Spring Apps w różnych regionach świadczenia usługi Azure, nadal możesz uwidocznić aplikacje za pośrednictwem usługi Application Gateway. Aby osiągnąć ten scenariusz, należy umieścić usługę Azure Front Door przed usługą Application Gateway.

Na poniższym diagramie przedstawiono architekturę scenariusza 2:

Pobierz plik programu Visio z tą architekturą.

Konfiguracja scenariusza 2 implementuje ograniczenia dostępu między usługą Application Gateway i usługą Azure Spring Apps w taki sam sposób jak w scenariuszu 1. Sieciowa grupa zabezpieczeń jest umieszczana w podsieci środowiska uruchomieniowego usługi z odpowiednimi regułami.

W scenariuszu 2 należy również upewnić się, że usługa Application Gateway akceptuje ruch pochodzący tylko z wystąpienia usługi Azure Front Door. W dokumentacji usługi Azure Front Door wyjaśniono , jak zablokować dostęp do zaplecza, aby zezwolić tylko na ruch usługi Azure Front Door. Gdy zaplecze jest usługą Application Gateway, można zaimplementować to ograniczenie w następujący sposób:

• W podsieci usługi Application Gateway utwórz sieciową grupę zabezpieczeń, aby zezwolić tylko na ruch, który ma AzureFrontDoor.Backend tag usługi (nic poza usługą Azure Front Door może dotrzeć do usługi Application Gateway). Pamiętaj również, aby uwzględnić inne wymagane tagi usługi zgodnie z opisem w temacie Ograniczenia sieciowej grupy zabezpieczeń dla usługi Application Gateway.
• Utwórz niestandardową regułę zapory aplikacji internetowej w usłudze Application Gateway, aby sprawdzić, X-Azure-FDID czy nagłówek HTTP jest ustawiony na określony identyfikator wystąpienia usługi Azure Front Door. Ta metoda gwarantuje, że żadne wystąpienia usługi Azure Front Door innej organizacji, które używają tych samych zakresów adresów IP, mogą uzyskiwać dostęp do wystąpienia usługi Application Gateway.

Wdrażanie poza siecią wirtualną

Podczas wdrażania usługi Azure Spring Apps poza siecią wirtualną nie można używać natywnych funkcji sieciowych platformy Azure, ponieważ nie kontrolujesz sieci. Zamiast tego należy zastosować niezbędne ograniczenia dostępu do aplikacji, aby zezwolić na ruch tylko z zwrotnego serwera proxy. Jeśli masz wiele aplikacji, takie podejście może zwiększyć złożoność i istnieje ryzyko, że nie każda aplikacja może być odpowiednio skonfigurowana.

Udostępnianie i zabezpieczanie aplikacji przy użyciu usługi Spring Cloud Gateway

Aby usunąć odpowiedzialność za kontrolę dostępu od deweloperów poszczególnych aplikacji, możesz zastosować ograniczenia krzyżowe przy użyciu usługi Spring Cloud Gateway. Spring Cloud Gateway to często używany projekt Spring, który można wdrożyć w usłudze Azure Spring Apps, podobnie jak w przypadku każdej innej aplikacji. Korzystając z usługi Spring Cloud Gateway, możesz przechowywać własne aplikacje prywatne w wystąpieniu usługi Azure Spring Apps i upewnić się, że dostęp do niej można uzyskać tylko za pośrednictwem udostępnionej aplikacji Spring Cloud Gateway. Następnie skonfigurujesz tę aplikację z niezbędnymi ograniczeniami dostępu przy użyciu predykatów tras, które są wbudowaną funkcją usługi Spring Cloud Gateway. Predykaty tras mogą używać różnych atrybutów przychodzącego żądania HTTP, aby określić, czy należy kierować żądanie do aplikacji zaplecza, czy ją odrzucić. Predykat może używać atrybutów, takich jak adres IP klienta, metoda żądania lub ścieżka, nagłówki HTTP itd.

Ten wzorzec jest często używany. Na potrzeby tego artykułu zakładamy, że udostępniasz aplikacje za pośrednictwem usługi Spring Cloud Gateway. Oczekujemy, że używasz predykatów tras do skonfigurowania niezbędnych ograniczeń dostępu, aby upewnić się, że dozwolone są tylko żądania z zwrotnego serwera proxy. Nawet jeśli nie używasz usługi Spring Cloud Gateway, obowiązują te same ogólne zasady. Należy jednak utworzyć własne możliwości filtrowania żądań w aplikacjach na podstawie tego samego X-Forwarded-For nagłówka HTTP omówionego w dalszej części tego artykułu.

Opis działania usługi Spring Cloud Gateway wykracza poza zakres tego artykułu. Jest to wysoce elastyczna usługa, którą można dostosować za pomocą kodu lub konfiguracji. Aby zachować prostotę, w tym artykule opisano tylko podejście oparte wyłącznie na konfiguracji, które nie wymaga zmian kodu. To podejście można zaimplementować, uwzględniając tradycyjne application.properties lub application.yml plik we wdrożonej aplikacji Spring Cloud Gateway. Można również zaimplementować podejście przy użyciu serwera konfiguracji w usłudze Azure Spring Apps , który zewnętrznie udostępnia plik konfiguracji do repozytorium Git. W poniższych przykładach zaimplementujemy application.yml podejście ze składnią YAML, ale równoważna application.properties składnia również działa.

Kierowanie żądań do aplikacji

Domyślnie jeśli aplikacja w usłudze Azure Spring Apps nie ma przypisanego do niej punktu końcowego ani skonfigurowanej dla niej domeny niestandardowej, nie jest ona osiągalna z zewnątrz. Gdy aplikacja zarejestruje się w rejestrze Spring Cloud Service Registry, usługa Spring Cloud Gateway może odnaleźć aplikację, aby mogła przekazywać ruch do odpowiedniej aplikacji docelowej przy użyciu reguł routingu.

W związku z tym jedyną aplikacją, która musi mieć przypisany do niego punkt końcowy w usłudze Azure Spring Apps, jest aplikacja Spring Cloud Gateway. Ten punkt końcowy sprawia, że jest osiągalny z zewnątrz. Nie należy przypisywać punktu końcowego do innych aplikacji. W przeciwnym razie aplikacje można uzyskać bezpośrednio, a nie za pośrednictwem usługi Spring Cloud Gateway, co z kolei umożliwia obejście zwrotnego serwera proxy.

Łatwym sposobem uwidocznienia wszystkich zarejestrowanych aplikacji za pośrednictwem usługi Spring Cloud Gateway jest użycie lokalizatora definicji trasy DiscoveryClient w następujący sposób:

spring:
  cloud:
    gateway:
      discovery:
        locator:
          enabled: true
          predicates:
          - Path="/"+serviceId+"/**" # Include the Path predicate to retain default behavior
          - (...)

Alternatywnie możesz selektywnie uwidocznić niektóre aplikacje za pomocą usługi Spring Cloud Gateway, definiując trasy specyficzne dla aplikacji:

spring:
  cloud:
    gateway:
      routes:
      - id: my_app1_route
        uri: lb://MY-APP1
        filters:
        - RewritePath=/myapp1(?<segment>/?.*), $\{segment}
        predicates:
        - (...)

Zarówno w przypadku podejścia lokalizatora odnajdywania, jak i jawnych definicji tras, można użyć predykatów tras, aby odrzucić nieprawidłowe żądania. W takim przypadku używamy tej funkcji do blokowania żądań, które nie pochodzą z oczekiwanego zwrotnego serwera proxy, który znajduje się przed usługą Azure Spring Apps.

Ograniczanie dostępu za pomocą nagłówka X-Forwarded-For HTTP

Podczas wdrażania aplikacji w usłudze Azure Spring Apps klient HTTP lub zwrotny serwer proxy nie łączy się bezpośrednio z aplikacją. Ruch sieciowy przechodzi najpierw przez wewnętrzny kontroler ruchu przychodzącego.

Ze względu na dodatkową usługę adres IP klienta sieci bezpośredniej jest zawsze wewnętrznym składnikiem usługi Azure Spring Apps. Adres IP nigdy nie jest logicznym klientem, takim jak zwrotny serwer proxy, którego oczekujesz wywołania aplikacji. Nie można użyć adresu IP klienta do ograniczeń dostępu. Nie można również używać wbudowanego RemoteAddr predykatu trasy usługi Spring Cloud Gateway do filtrowania żądań, ponieważ domyślnie używa on adresu IP klienta.

Na szczęście usługa Azure Spring Apps zawsze dodaje adres IP klienta logicznego X-Forwarded-For do nagłówka HTTP w żądaniu do aplikacji. Ostatnia (najbardziej prawa) wartość nagłówka X-Forwarded-For zawsze zawiera adres IP klienta logicznego.

Aby filtrować żądania na podstawie nagłówka X-Forwarded-For , możesz użyć wbudowanego XForwarded Remote Addr predykatu trasy. Ten predykat umożliwia skonfigurowanie listy adresów IP lub zakresów adresów IP zwrotnego serwera proxy, które są dozwolone jako najbardziej odpowiednia wartość.

Skonfiguruj aplikację, aby wyświetlić poprawną nazwę hosta i adres URL żądania

W przypadku korzystania z usługi Spring Cloud Gateway należy wziąć pod uwagę ważny czynnik. Usługa Spring Cloud Gateway ustawia nagłówek HTTP Host dla żądania wychodzącego na wewnętrzny adres IP wystąpienia aplikacji, taki jak Host: 10.2.1.15:1025. Nazwa hosta żądania widoczna w kodzie aplikacji nie jest już oryginalną nazwą hosta żądania wysłanego przez przeglądarkę, na przykład contoso.com. W niektórych przypadkach ten wynik może prowadzić do problemów, takich jak uszkodzone pliki cookie lub adresy URL przekierowania nie działają prawidłowo. Aby uzyskać więcej informacji na temat tego typu problemów i sposobu konfigurowania usługi zwrotnego serwera proxy, takiej jak Application Gateway lub Azure Front Door, aby ich uniknąć, zobacz Zachowywanie nazw hostów.

Usługa Spring Cloud Gateway udostępnia oryginalną nazwę hosta w nagłówkuForwarded. Ustawia również inne nagłówki, takie jak X-Forwarded-Port, X-Forwarded-Protoi X-Forwarded-Prefix , aby aplikacja mogła ich używać do odtworzenia oryginalnego adresu URL żądania. W aplikacjach platformy Spring Framework tę konfigurację można uzyskać automatycznie, ustawiając server.forward-headers-strategy ustawienie na FRAMEWORK wartość we właściwościach aplikacji. (Nie ustawiaj tej wartości na NATIVE. W przeciwnym razie używane są inne nagłówki, które nie uwzględniają wymaganego X-Forwarded-Prefix nagłówka). Aby uzyskać więcej informacji, zobacz Running behind a front-end proxy server (Uruchamianie za serwerem proxy frontonu). W przypadku tej konfiguracji metoda HttpServletRequest.getRequestURL uwzględnia wszystkie te nagłówki i zwraca dokładny adres URL żądania wysyłany przez przeglądarkę.

Scenariusz 3. Używanie usługi Application Gateway z usługą Spring Cloud Gateway

Scenariusz 3 opisuje sposób używania usługi Application Gateway jako zwrotnego serwera proxy dla publicznie dostępnych aplikacji za pośrednictwem punktu końcowego usługi Spring Cloud Gateway.

Na poniższym diagramie przedstawiono architekturę scenariusza 3:

Pobierz plik programu Visio z tą architekturą.

Gdy usługa Application Gateway znajduje się przed wystąpieniem usługi Azure Spring Apps, użyj przypisanego punktu końcowego aplikacji Spring Cloud Gateway jako puli zaplecza. Przykładowy punkt końcowy to myspringcloudservice-mygateway.azuremicroservices.io. Ponieważ usługa Azure Spring Apps jest wdrażana poza siecią wirtualną, ten adres URL jest rozpoznawany jako publiczny adres IP. Gdy pula zaplecza jest publicznym punktem końcowym, usługa Application Gateway używa publicznego adresu IP frontonu do dotarcia do usługi zaplecza.

Aby zezwolić na dostęp do usługi Spring Cloud Gateway tylko żądań z wystąpienia usługi Application Gateway, możesz skonfigurować XForwarded Remote Addr predykat trasy. Skonfiguruj predykat tak, aby zezwalał tylko na żądania z dedykowanego publicznego adresu IP usługi Application Gateway, jak pokazano w poniższym przykładzie:

(...)
predicates:
- XForwardedRemoteAddr="20.103.252.85"

Scenariusz 4. Korzystanie z usługi Azure Front Door z usługą Spring Cloud Gateway

Scenariusz 4 opisuje sposób używania usługi Azure Front Door jako zwrotnego serwera proxy dla publicznie dostępnych aplikacji za pośrednictwem punktu końcowego usługi Spring Cloud Gateway.

Na poniższym diagramie przedstawiono architekturę scenariusza 4:

Pobierz plik programu Visio z tą architekturą.

Podobnie jak w scenariuszu 3, ta konfiguracja używa publicznego adresu URL aplikacji Spring Cloud Gateway jako puli zaplecza lub źródła w usłudze Azure Front Door. Przykładowy punkt końcowy to https://myspringcloudservice-mygateway.azuremicroservices.io.

Ponieważ usługa Azure Front Door jest usługą globalną z wieloma lokalizacjami brzegowymi, używa wielu adresów IP do komunikowania się z pulą zaplecza. W dokumentacji usługi Azure Front Door opisano sposób blokowania dostępu do zaplecza w celu zezwolenia tylko na ruch usługi Azure Front Door. Jednak w tym scenariuszu nie kontrolujesz sieci platformy Azure, w której są wdrażane aplikacje. Niestety, nie można użyć tagu AzureFrontDoor.Backend usługi, aby uzyskać pełną listę wychodzących adresów IP usługi Azure Front Door, które mają gwarancję aktualności. Zamiast tego musisz pobrać zakresy adresów IP platformy Azure i tagi usługi, znaleźć sekcję AzureFrontDoor.Backend i skopiować wszystkie zakresy adresów IP z addressPrefixes tablicy do XForwarded Remote Addr konfiguracji predykatu trasy.

Ponieważ zakresy adresów IP usługi Azure Front Door są współużytkowane przez inne organizacje, musisz również upewnić się, że dostęp jest zablokowany tylko do określonego wystąpienia usługi Azure Front Door na X-Azure-FDID podstawie nagłówka HTTP zawierającego unikatowy Front Door IDadres . Dostęp można ograniczyć przy użyciu Header predykatu trasy, który odrzuca żądanie, chyba że określony nagłówek HTTP ma określoną wartość.

W tym scenariuszu konfiguracja predykatu trasy usługi Spring Cloud Gateway może wyglądać następująco:

(...)
predicates:
- XForwardedRemoteAddr="13.73.248.16/29","20.21.37.40/29","20.36.120.104/29","20.37.64.104/29", ...(and many more)...
- Header="X-Azure-FDID", "e483e3cc-e7f3-4e0a-9eca-5f2a62bde229"

Współautorzy

Firma Microsoft utrzymuje tę zawartość. Następujący współautor opracował oryginalną zawartość.

Główny autor:

• Jelle Druyts | Główny inżynier klienta

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

• Architektura referencyjna usługi Azure Spring Apps
• Obowiązki klienta dotyczące uruchamiania usługi Azure Spring Apps w sieciach wirtualnych platformy Azure

Powiązane zasoby

• Zachowywanie nazwy hosta
• Opcje równoważenia obciążenia
• Styl architektury mikrousług