Expor os Aplicativos Spring do Azure por meio de um proxy reverso

Ao hospedar aplicativos ou microsserviços nos aplicativos do Azure Spring, nem sempre é necessário publicá-los diretamente na Internet. É possível expô-los por meio de um proxy reverso. Essa abordagem permite que você coloque um serviço na frente de seus aplicativos. O serviço pode definir funcionalidades transversais, como recursos de firewall de aplicativos da web (WAF) para ajudar a proteger seus aplicativos, balanceamento de carga, roteamento, filtragem de solicitações e limitação de taxa.

Quando você implanta um serviço de proxy reverso comum como Gateway de Aplicativo do Azure ou o Azure Front Door na frente dos aplicativos do Azure Spring, é necessário garantir que os aplicativos possam ser acessados somente por meio desse proxy reverso. Essa proteção ajuda a impedir que usuários mal-intencionados tentem contornar o WAF ou desviar os limites.

A Proteção contra DDoS do Azure, combinada com as práticas recomendadas de design de aplicativos, fornece recursos aprimorados de mitigação de DDoS para fornecer mais defesa contra ataques de DDoS. Você deve habilitar a Proteção contra DDOS do Azure em qualquer rede virtual do perímetro.

Este artigo descreve como impor restrições de acesso para que as aplicações hospedadas em Aplicativos Spring do Azure sejam acessíveis apenas através de um serviço de proxy reverso. A maneira recomendada de impor essas restrições depende de como a instância dos aplicativos do Azure Spring é implantada e qual proxy reverso é usado. Os pontos são diferentes a serem considerados, dependendo se você implanta dentro ou fora de uma rede virtual. Este artigo fornece informações sobre quatro cenários.

• Implante Aplicativos Spring do Azure em uma rede virtual e acesse seus aplicativos de forma privada de dentro da rede.

  • Você tem controle sobre a rede virtual na qual os aplicativos são executados. Use recursos de rede do Azure nativos, como NSGs (grupos de segurança de rede), para bloquear o acesso e permitir somente o proxy reverso.

  • É possível expor seus aplicativos publicamente à Internet usando o Gateway de Aplicativo do Azure e, em seguida, aplicar as restrições de acesso apropriadas para bloqueá-lo. Essa abordagem é descrita no cenário 1 mais adiante neste artigo.

  • Não é possível usar o Azure Front Door diretamente porque ele não consegue acessar a instância do Aplicativos Spring do Azure na sua rede virtual privada. O Azure Front Door só pode se conectar a backends por meio de um endereço IP público ou de serviços que usam um endpoint privado. Quando você tem uma implantação de várias regiões do Aplicativos Spring do Azure e exige balanceamento de carga global, você ainda pode expor suas instâncias do Aplicativos Spring do Azure por meio do Gateway de Aplicativo. Para obter esse cenário, coloque o Azure Front Door na frente do Gateway de Aplicativo. Essa abordagem é descrita no cenário 2 mais adiante neste artigo.

• Implante o Aplicativos Spring do Azure fora de uma rede virtual, e publique seus aplicativos diretamente na Internet se você atribuir um endpoint a eles.

  • Você não controla a rede e não pode usar NSGs para restringir o acesso. Portanto, para permitir que somente o proxy reverso acesse seus aplicativos, é preciso ter uma abordagem dentro do próprio Aplicativos Spring do Azure.

  • Como seus aplicativos podem ser acessados publicamente, você pode usar o Gateway de Aplicativo ou o Azure Front Door como o proxy reverso. A abordagem do Application Gateway é descrita no cenário 3 posteriormente neste artigo. A abordagem do Azure Front Door é descrita no Cenário 4 mais adiante neste artigo.

  • Você pode usar uma combinação de ambas as abordagens, conforme necessário. Se você usar o Application Gateway e o Azure Front Door, use as mesmas restrições de acesso entre os dois proxies reversos usados no Cenário 2.

Comparação entre cenários

A tabela a seguir fornece uma breve comparação dos quatro cenários de configuração de proxy reverso para os Aplicativos Spring do Azure. Para obter detalhes completos sobre cada cenário, confira a seção apropriada deste artigo.

Implantação dentro de sua rede virtual

Quando o Aplicativos Spring do Azure é implantado em uma rede virtual, ele usa duas sub-redes:

• Uma sub-rede de tempo de execução de serviço que contém os recursos de rede relevantes
• Uma sub-rede de aplicativos que hospeda seu código

Como a sub-rede do tempo de execução do serviço contém o balanceador de carga para conexão com seus aplicativos, você pode definir um NSG nessa sub-rede do tempo de execução do serviço para permitir o tráfego somente do seu proxy reverso Ao bloquear todos os outros tráfegos, ninguém na rede virtual pode acessar seus aplicativos sem passar pelo proxy reverso.

Cada aplicativo que pretende expor através do seu proxy reverso deve ter um endpoint atribuído para que o proxy reverso possa chegar ao aplicativo na rede virtual. Também é necessário mapear os domínios personalizados usados por cada aplicativo para evitar a substituição do cabeçalho HTTP Host no proxy reverso e manter o nome do host original intacto. Esse método evita problemas como cookies quebrados ou URLs de redirecionamento que não funcionam corretamente. Para saber mais, confira Preservação do nome do host.

Cenário 1: use o Gateway de Aplicativo como proxy reverso

O Cenário 1 descreve como expor seus aplicativos publicamente à Internet usando o Gateway de Aplicativo e, em seguida, aplicar as restrições de acesso apropriadas para bloqueá-lo.

O seguinte diagrama ilustra a arquitetura para o Cenário 1:

Baixe um Arquivo Visio dessa arquitetura.

Quando o Gateway de Aplicativo fica na frente da instância do Aplicativos Spring do Azure, o endpoint atribuído do aplicativo Spring Cloud Gateway é usado como o pool de back-end. Um ponto de extremidade de exemplo é: myspringcloudservice-myapp.private.azuremicroservices.io. O endpoint resolve para um endereço IP privado na sub-rede de runtime do serviço. Portanto, para restringir o acesso, é possível colocar um NSG na sub-rede de runtime do serviço com as seguintes regras de segurança de entrada (a regra de negação deve ter a prioridade mais baixa):

A configuração do Cenário 1 garante que a sub-rede de tempo de execução do serviço permita o tráfego somente das seguintes fontes:

• A sub-rede dedicada do Gateway de Aplicativo.
• A sub-rede de aplicativos (é necessária a comunicação bidirecional entre as duas sub-redes do Aplicativos Spring do Azure).
• O balanceador de carga do Azure (que é um requisito geral da plataforma do Azure)

Qualquer outro tráfego será bloqueado.

Cenário 2: use ambos, o Azure Front Door e o Gateway de Aplicativo como proxy reverso

Conforme observado anteriormente, não é possível colocar o Azure Front Door diretamente na frente do Aplicativos Spring do Azure porque ele não pode acessar a rede virtual privada. (O Azure Front Door Standard ou Premium pode se conectar a pontos de extremidade privados em uma rede virtual, mas o Aplicativos Spring do Azure não oferece no momento suporte a pontos de extremidade privados). Para usar o Azure Front Door mesmo assim, por exemplo, no caso do balanceamento de carga global entre diversas instâncias do Aplicativos Spring do Azure em diferentes regiões do Azure, é possível expô-las primeiro por meio do Gateway de Aplicativo e, em seguida, colocar o Azure Front Door na frente do Gateway de Aplicativo. Para obter esse cenário, coloque o Azure Front Door na frente do Gateway de Aplicativo.

O seguinte diagrama ilustra a arquitetura para o Cenário 2:

Baixe um Arquivo Visio dessa arquitetura.

A configuração do Cenário 2 implementa restrições de acesso entre o Gateway de Aplicativo e os Aplicativos Spring do Azure da mesma maneira que o Cenário 1. Você coloca um NSG na sub-rede de tempo de execução do serviço com as regras apropriadas.

No Cenário 2, você tem que garantir que o Gateway de Aplicativo só aceite tráfego proveniente de sua instância do Azure Front Door. A documentação do Azure Front Door explica como bloquear o acesso a um backend para permitir somente o tráfego do Azure Front Door. Quando o back-end é o Gateway de Aplicativo, é possível implementar essa restrição da seguinte maneira:

• Na sub-rede do Gateway de Aplicativo, crie um NSG que permita somente tráfegos com a marca de serviço AzureFrontDoor.Backend (para que ninguém mais, além do Azure Front Door, possa acessar o Gateway de Aplicativo). Certifique-se de incluir também outras marcas de serviço necessárias, conforme descrito em Restrições de NSGs para o Gateway de Aplicativo.
• Crie uma regra de WAF personalizada no Gateway de Aplicativo que verifique se o cabeçalho HTTP X-Azure-FDID está definido para sua ID de instância do Azure Front Door específica. Esse método garante que nenhuma instância do Azure Front Door de outra organização, que usa os mesmos intervalos de IP, possa acessar sua instância do Gateway de Aplicativo.

Implantação fora de sua rede virtual

Ao implantar o Aplicativos Spring do Azure fora de uma rede virtual, não é possível usar os recursos de rede nativos do Azure porque você não controla a rede. Em vez disso, você precisa aplicar as restrições de acesso necessárias nos próprios aplicativos para que eles permitam somente o tráfego do proxy reverso. No caso de muitos aplicativos, essa abordagem pode adicionar complexidade e há o risco de que nem todos os aplicativos sejam configurados adequadamente.

Use o Spring Cloud Gateway para expor e ajudar a proteger seus aplicativos

Para remover a responsabilidade do controle de acesso dos desenvolvedores de aplicativos individuais, aplique essas restrições transversais usando o Spring Cloud Gateway. O Spring Cloud Gateway é um projeto Spring comumente usado que pode ser implantado no Aplicativos Spring do Azure como qualquer outro aplicativo. Ao usar o Spring Cloud Gateway, é possível manter seus próprios aplicativos privados na instância do Aplicativos Spring do Azure e garantir que eles possam ser acessados somente por meio do aplicativo Spring Cloud Gateway compartilhado. Em seguida, este aplicativo deve ser configurado com as restrições de acesso necessárias por meio de predicados de rota, que são um recurso integrado do Spring Cloud Gateway. Os predicados de rota podem usar atributos diferentes da solicitação HTTP de entrada para determinar se a solicitação deve ser roteada para o aplicativo backend ou rejeitada. O predicado pode usar atributos como o endereço IP do cliente, método ou caminho de solicitação, cabeçalhos HTTP e assim por diante.

Esse padrão é usado normalmente. Para os fins deste artigo, presumimos que você exponha seus aplicativos por meio do Spring Cloud Gateway. Esperamos que você use seus predicados de rota para configurar as restrições de acesso necessárias para garantir que apenas solicitações do proxy reverso sejam permitidas. Mesmo que o Spring Cloud Gateway não seja usado, os mesmos princípios gerais serão aplicados. No entanto, será necessário criar seus próprios recursos de filtragem de solicitação nos aplicativos, com base no mesmo cabeçalho HTTP X-Forwarded-For discutido posteriormente neste artigo.

Este artigo não discutirá o funcionamento do Spring Cloud Gateway. Ele é um serviço altamente flexível que pode ser personalizado por meio de códigos ou configuração. Para simplificar as coisas, esse artigo descreve apenas uma abordagem puramente orientada à configuração, que não requer alterações de código. É possível implementar essa abordagem incluindo o arquivo tradicional application.properties ou application.yml no aplicativo Spring Cloud Gateway implantado. Você também pode implementar a abordagem usando um Config Server no Aplicativos Spring do Azure, que externaliza esse arquivo de configuração em um repositório Git. Nos exemplos a seguir, implementamos a abordagem com a application.yml sintaxe YAML, mas a sintaxe equivalente application.properties também funciona.

Rotear solicitações para aplicativos

Por padrão, quando seu aplicativo no Aplicativos Spring do Azure não tem um ponto de extremidade atribuído ou um domínio personalizado configurado, ele não pode ser acessado externamente. Quando aplicativos fazem o registro no Registro de Serviço do Spring Cloud, o Spring Cloud Gateway pode descobri-los para usar regras de roteamento a fim de encaminhar o tráfego para o aplicativo de destino correto.

Consequentemente, o único aplicativo que precisa ter um ponto de extremidade atribuído no Aplicativos Spring do Azure é o aplicativo Spring Cloud Gateway. Esse ponto de extremidade o torna acessível externamente. Não atribua um endpoint a nenhum dos outros aplicativos. Isso possibilita acessá-los diretamente em vez de por meio do Spring Cloud Gateway, o que permite que o proxy reverso seja ignorado.

Uma maneira fácil de expor todos os aplicativos registrados por meio do Spring Cloud Gateway é usar o localizador de definição de rota DiscoveryClient da seguinte forma:

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

Como alternativa, é possível expor seletivamente determinados aplicativos por meio do Spring Cloud Gateway definindo rotas de aplicativo específicas:

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

Com a abordagem do localizador de descoberta e as definições de rota explícitas, é possível usar predicados de rota para rejeitar solicitações inválidas. Neste caso, usaremos essa funcionalidade para bloquear solicitações que não são do proxy reverso esperado que fica na frente do Aplicativos Spring do Azure.

Restringir o acesso com o cabeçalho HTTP X-Forwarded-For

Ao implantar um aplicativo no Aplicativos Spring do Azure, o cliente HTTP ou o proxy reverso não se conecta diretamente a ele. O tráfego de rede passa primeiro por um controlador de entrada interno.

Devido ao serviço extra, o endereço IP do cliente de rede direta é sempre um componente interno do Aplicativos Spring do Azure. O endereço IP nunca é o cliente lógico como o proxy reverso que você espera chamar seu aplicativo. Não é possível usar o endereço IP do cliente para restrições de acesso. Portanto, não é possível usar o RemoteAddr predicado de rota interno do Spring Cloud Gateway para a filtragem de solicitação porque ele usa o endereço IP do cliente por padrão.

Felizmente, o Aplicativos Spring do Azure sempre adiciona o endereço IP do cliente lógico ao cabeçalho HTTP X-Forwarded-For na solicitação para seu aplicativo. Portanto, o último valor (mais à direita) do cabeçalho X-Forwarded-For sempre contém o endereço IP do cliente lógico.

Para filtrar solicitações com base no X-Forwarded-For cabeçalho, você pode usar o predicado de XForwarded Remote Addr rota interno. Esse predicado permite configurar uma lista dos endereços IP ou intervalos de IP do proxy reverso que são permitidos como o valor mais à direita.

Configuração do aplicativo para ver o nome do host e a URL de solicitação corretos

Quando você usa o Spring Cloud Gateway, há um fator importante a ser considerado. O Spring Cloud Gateway define o cabeçalho HTTP Host na solicitação de saída para o endereço IP interno da instância do aplicativo, como Host: 10.2.1.15:1025. Portanto, o nome do host da solicitação que o código do aplicativo vê não é mais o nome do host original da solicitação que o navegador enviou (por exemplo, contoso.com). Em alguns casos, isso pode levar a problemas como cookies quebrados ou URLs de redirecionamento que não funcionam corretamente. Para saber mais sobre esses tipos de problemas e como configurar um serviço de proxy reverso como o Gateway de Aplicativo ou o Azure Front Door para evitá-los, confira Preservação do nome do host.

O Spring Cloud Gateway fornece o Forwarded nome do host original no cabeçalho. Ele também define outros cabeçalhos como X-Forwarded-Port, X-Forwarded-Protoe X-Forwarded-Prefix assim seu aplicativo pode usá-los para reconstruir a URL de solicitação original. Em aplicativos Spring Framework, você pode obter essa configuração automaticamente definindo o parâmetro server.forward-headers-strategy como FRAMEWORK nas propriedades do aplicativo. (Não defina esse valor como NATIVE. Caso contrário, serão usados outros cabeçalhos que não levam em consideração o cabeçalho X-Forwarded-Prefix necessário). Para saber mais, confira Executando atrás de um servidor proxy front-end. Com essa configuração, o método HttpServletRequest.getRequestURL, por exemplo, leva em consideração todos esses cabeçalhos e retorna a URL de solicitação exata enviada pelo navegador.

Cenário 3: Usar o Application Gateway com o Spring Cloud Gateway

O cenário 3 descreve como usar o Application Gateway como o proxy reverso para aplicativos acessíveis publicamente por meio de um ponto de extremidade do Spring Cloud Gateway.

O seguinte diagrama ilustra a arquitetura para o Cenário 3:

Baixe um Arquivo Visio dessa arquitetura.

Quando o Gateway de Aplicativo fica na frente da instância do Aplicativos Spring do Azure, o endpoint atribuído do aplicativo Spring Cloud Gateway é usado como o pool de back-end. Um ponto de extremidade de exemplo é: myspringcloudservice-mygateway.azuremicroservices.io. Como o Aplicativos Spring do Azure é implantado fora de uma rede virtual, essa URL faz a resolução para um endereço IP público. Quando o pool de back-end é um ponto de extremidade público, o Gateway de Aplicativo usa seu próprio endereço IP público de front-end para acessar o serviço de back-end.

Para permitir que apenas solicitações da instância do Application Gateway cheguem ao Spring Cloud Gateway, você pode configurar o XForwarded Remote Addr predicado de rota. Configure o predicado para permitir apenas solicitações do endereço IP público dedicado do seu Gateway de Aplicativo, conforme mostrado no exemplo a seguir:

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

Cenário 4: Usar o Azure Front Door com o Spring Cloud Gateway

O cenário 4 descreve como usar o Azure Front Door como o proxy reverso para aplicativos acessíveis publicamente por meio de um endpoint do Spring Cloud Gateway.

O seguinte diagrama ilustra a arquitetura para o Cenário 4:

Baixe um Arquivo Visio dessa arquitetura.

Semelhante ao Cenário 3, essa configuração usa a URL pública do aplicativo Spring Cloud Gateway como o pool de back-end ou a origem no Azure Front Door. Um ponto de extremidade de exemplo é: https://myspringcloudservice-mygateway.azuremicroservices.io.

Como o Azure Front Door é um serviço global que tem muitos locais de borda, ele usa muitos endereços IP para se comunicar com o pool de back-end. A documentação do Azure Front Door descreve como bloquear o acesso a um backend para permitir somente o tráfego do Azure Front Door. No entanto, neste cenário, você não controla a rede do Azure na qual seus aplicativos estão implantados. Infelizmente, não será possível usar a marca de serviço AzureFrontDoor.Backend para obter uma lista completa de endereços IP de saída do Azure Front Door garantidamente atualizada. Em vez disso, você precisa baixar os intervalos de IP e marcas de serviço do Azure, encontrar a seção AzureFrontDoor.Backend e copiar todos os intervalos de IP da matriz addressPrefixes para a configuração do predicado de rota XForwarded Remote Addr.

Como os intervalos de IP do Azure Front Door são compartilhados com outras organizações, você também precisa garantir o bloqueio do acesso apenas à sua instância específica do Azure Front Door, com base no cabeçalho HTTP X-Azure-FDID que contém seu Front Door ID exclusivo. Você pode restringir o acesso usando o Header predicado de rota, que rejeita uma solicitação, a menos que um cabeçalho HTTP especificado tenha um determinado valor.

Nesse cenário, a configuração do predicado de rota do Spring Cloud Gateway pode ser semelhante ao seguinte exemplo:

(...)
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"

Colaboradores

A Microsoft faz a manutenção desse conteúdo. O seguinte Colaborador desenvolveu o conteúdo original.

Autor principal:

• Jelle Druyts | Engenheiro de cliente principal

Para ver perfis não públicos no LinkedIn, entre no LinkedIn.

Próximas etapas

• Arquitetura de referência do Aplicativos Spring do Azure
• Responsabilidades do cliente ao executar o Aplicativos Spring do Azure em uma redes virtuais do Azure

Recursos relacionados

• Preservação do nome do host
• Opções de balanceamento de carga
• Estilo de arquitetura de microsserviços