Expor o Azure Spring Apps por meio de um proxy reverso

Quando você hospeda seus aplicativos ou microsserviços no Azure Spring Apps, nem sempre deseja publicá-los diretamente na Internet. Em vez disso, você pode 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.

Ao implantar um serviço de proxy reverso comum, como o Azure Application Gateway ou o Azure Front Door , na frente do Azure Spring Apps, você deve garantir que seus aplicativos possam ser acessados somente por meio do proxy reverso. Essa proteção ajuda a evitar que usuários mal-intencionados tentem contornar o WAF ou contornar os limites de limitação.

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 DDoS. Você deve habilitar a Proteção DDOS do Azure em qualquer rede virtual de perímetro.

Este artigo descreve como impor restrições de acesso para que os aplicativos hospedados no Azure Spring Apps sejam acessíveis somente por meio de um serviço de proxy reverso. A maneira recomendada de impor essas restrições depende de como você implanta sua instância do Azure Spring Apps e qual proxy reverso você usa. São pontos 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 o Azure Spring Apps em uma rede virtual e acesse seus aplicativos de forma privada a partir da rede.

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

  • Você pode 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.

  • Você não pode usar o Azure Front Door diretamente porque ele não pode acessar a instância do Azure Spring Apps em sua rede virtual privada. O Azure Front Door pode se conectar a back-ends somente por meio de um endereço IP público ou por meio de serviços que usam um ponto de extremidade privado. Quando você tem uma implantação de várias regiões do Azure Spring Apps e precisa de balanceamento de carga global, ainda pode expor suas instâncias do Azure Spring Apps por meio do Application Gateway. Para alcançar esse cenário, coloque o Azure Front Door na frente do Application Gateway. Essa abordagem é descrita no Cenário 2 , mais adiante neste artigo.

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

  • Você não controla a rede e não pode usar NSGs para restringir o acesso. Permitir que apenas o proxy reverso acesse seus aplicativos requer uma abordagem dentro do próprio Azure Spring Apps.

  • Como seus aplicativos são acessíveis publicamente, você pode usar o Gateway de Aplicativo ou a Porta da Frente do Azure como proxy reverso. A abordagem do Application Gateway é descrita no Cenário 3 , mais adiante 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 Gateway de Aplicativo e a Porta Frontal do Azure, use as mesmas restrições de acesso entre os dois proxies reversos usados no Cenário 2.

Comparação de cenários

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

Implementação dentro da sua rede virtual

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

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

Como a sub-rede de tempo de execução do serviço contém o balanceador de carga para se conectar aos seus aplicativos, você pode definir um NSG nessa sub-rede de tempo de execução do serviço para permitir o tráfego somente do proxy reverso. Quando você bloqueia todo o outro tráfego, ninguém na rede virtual pode acessar seus aplicativos sem passar pelo proxy reverso.

Cada aplicativo que você deseja expor por meio de seu proxy reverso deve ter um ponto de extremidade atribuído para que o proxy reverso possa alcançar o aplicativo na rede virtual. Para cada aplicativo, você também deve mapear os domínios personalizados que ele usa para evitar substituir o 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 obter mais informações, consulte Preservação do nome do host.

Cenário 1: Usar o Application Gateway como proxy reverso

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

O diagrama a seguir mostra a arquitetura do Cenário 1:

Transfira um ficheiro do Visio desta arquitetura.

Quando o Application Gateway fica na frente da sua instância do Azure Spring Apps, você usa o ponto de extremidade atribuído do aplicativo Spring Cloud Gateway como o pool de back-end. Um ponto final de exemplo é myspringcloudservice-myapp.private.azuremicroservices.io. O ponto de extremidade é resolvido para um endereço IP privado na sub-rede de tempo de execução do serviço. Portanto, para restringir o acesso, você pode colocar um NSG na sub-rede de tempo de execução do serviço com as seguintes regras de segurança de entrada (dando à regra Negar 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 tráfego somente das seguintes fontes:

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

Todo o restante tráfego está bloqueado.

Cenário 2: Usar o Azure Front Door e o Application Gateway como proxy reverso

Como observado anteriormente, você não pode colocar o Azure Front Door diretamente na frente do Azure Spring Apps porque ele não pode acessar sua rede virtual privada. (O Azure Front Door Standard ou Premium pode se conectar a pontos de extremidade privados em uma rede virtual, mas o Azure Spring Apps atualmente não oferece suporte a ponto de extremidade privado.) Se você ainda quiser usar o Azure Front Door, como exigir balanceamento de carga global em várias instâncias do Azure Spring Apps em diferentes regiões do Azure, ainda poderá expor seus aplicativos por meio do Application Gateway. Para alcançar esse cenário, coloque o Azure Front Door na frente do Application Gateway.

O diagrama a seguir mostra a arquitetura do Cenário 2:

Transfira um ficheiro do Visio desta arquitetura.

A configuração do Cenário 2 implementa restrições de acesso entre o Gateway de Aplicativo e os Aplicativos Azure Spring 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ê também precisa garantir que o Application Gateway aceite tráfego proveniente apenas da sua instância do Azure Front Door. A documentação do Azure Front Door explica como bloquear o acesso a um back-end para permitir apenas o tráfego do Azure Front Door. Quando o back-end é o Application Gateway, você pode implementar essa restrição da seguinte maneira:

• Na sub-rede do Gateway de Aplicativo, crie um NSG para permitir apenas o tráfego que tenha a marca de serviço (nada, exceto o Azure Front Door, pode acessar o AzureFrontDoor.Backend Application Gateway). Certifique-se de incluir também outras tags de serviço necessárias, conforme descrito em Restrições NSG para o Application Gateway.
• Crie uma regra WAF personalizada no Application Gateway para verificar se o X-Azure-FDID cabeçalho HTTP está definido como sua ID de instância específica do Azure Front Door. Esse método garante que nenhuma instância do Azure Front Door de outra organização que use os mesmos intervalos de IP possa alcançar sua instância do Gateway de Aplicativo.

Implementação fora da sua rede virtual

Quando você implanta o Azure Spring Apps fora de uma rede virtual, não pode usar recursos de rede nativos do Azure porque não controla a rede. Em vez disso, você tem que aplicar as restrições de acesso necessárias nos próprios aplicativos para permitir o tráfego apenas do proxy reverso. Se você tiver muitos aplicativos, essa abordagem pode adicionar complexidade e há o risco de que nem todos os aplicativos possam ser 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, você pode aplicar restrições transversais usando o Spring Cloud Gateway. O Spring Cloud Gateway é um projeto Spring comumente usado que você pode implantar no Azure Spring Apps como qualquer outro aplicativo. Usando o Spring Cloud Gateway, você pode manter seus próprios aplicativos privados na instância do Azure Spring Apps e garantir que ele possa ser acessado somente por meio do aplicativo compartilhado do Spring Cloud Gateway. Em seguida, você configura este aplicativo com as restrições de acesso necessárias usando predicados de rota, que são um recurso interno do Spring Cloud Gateway. Os predicados de rota podem usar diferentes atributos da solicitação HTTP de entrada para determinar se a solicitação deve ser encaminhada para o aplicativo back-end ou rejeitada. O predicado pode usar atributos como o endereço IP do cliente, método de solicitação ou caminho, cabeçalhos HTTP e assim por diante.

Este padrão é comumente usado. Para os fins deste artigo, assumimos que você expõe 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 você não use o Spring Cloud Gateway, os mesmos princípios gerais se aplicam. No entanto, você precisa criar seus próprios recursos de filtragem de solicitações em seus aplicativos com base no mesmo X-Forwarded-For cabeçalho HTTP discutido mais adiante neste artigo.

A descrição do funcionamento do Spring Cloud Gateway está fora do escopo deste artigo. É um serviço altamente flexível que você pode personalizar via código ou configuração. Para simplificar, este artigo descreve apenas uma abordagem puramente orientada por configuração que não requer alterações de código. Você pode implementar essa abordagem incluindo o tradicional application.properties ou application.yml o arquivo no aplicativo Spring Cloud Gateway implantado. Você também pode implementar a abordagem usando um Config Server no Azure Spring Apps que externaliza o arquivo de configuração em um repositório Git. Nos exemplos a seguir, implementamos a abordagem com sintaxe YAML, mas a sintaxe application.yml equivalente application.properties também funciona.

Encaminhar solicitações para seus aplicativos

Por padrão, quando seu aplicativo no Azure Spring Apps não tem um ponto de extremidade atribuído a ele ou um domínio personalizado configurado para ele, ele não pode ser acessado do lado de fora. Quando um aplicativo se registra no Spring Cloud Service Registry, o Spring Cloud Gateway pode descobrir o aplicativo para que ele possa usar regras de roteamento para encaminhar o tráfego para o aplicativo de destino certo.

Como resultado, o único aplicativo que precisa ter um ponto de extremidade atribuído a ele no Azure Spring Apps é seu aplicativo Spring Cloud Gateway. Este ponto final torna-o acessível a partir do exterior. Você não deve atribuir um ponto de extremidade a nenhum outro aplicativo. Caso contrário, os aplicativos podem ser acessados diretamente em vez de através do Spring Cloud Gateway, que por sua vez permite que o proxy reverso seja ignorado.

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

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

Como alternativa, você pode expor seletivamente determinados aplicativos por meio do Spring Cloud Gateway definindo rotas específicas do aplicativo:

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 definições de rota explícitas, você pode usar predicados de rota para rejeitar solicitações inválidas. Nesse caso, usamos essa funcionalidade para bloquear solicitações que não vêm do proxy reverso esperado que fica na frente do Azure Spring Apps.

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

Quando você implanta um aplicativo no Azure Spring Apps, o cliente HTTP ou proxy reverso não se conecta diretamente ao aplicativo. 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 Azure Spring Apps. 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. Você também não pode usar o predicado de rota interno RemoteAddr do Spring Cloud Gateway para filtragem de solicitações porque ele usa o endereço IP do cliente por padrão.

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

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

Configure seu aplicativo para ver o nome de host correto e a URL de solicitação

Quando você usa o Spring Cloud Gateway, há um fator importante a considerar. 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 seu aplicativo, como Host: 10.2.1.15:1025. O nome de host da solicitação que o código do aplicativo vê não é mais o nome de host original da solicitação enviada pelo navegador, como contoso.com. Em alguns casos, esse resultado pode levar a problemas como cookies quebrados ou URLs de redirecionamento que não funcionam corretamente. Para obter mais informações sobre esses tipos de problemas e como configurar um serviço de proxy reverso como o Application Gateway ou o Azure Front Door para evitá-los, consulte Preservação do nome do host.

O Spring Cloud Gateway fornece o nome do host original no Forwarded cabeçalho. Ele também define outros cabeçalhos como X-Forwarded-Port, X-Forwarded-Protoe X-Forwarded-Prefix para que seu aplicativo possa usá-los para reconstruir a URL de solicitação original. Em aplicativos do Spring Framework, você pode obter essa configuração automaticamente definindo a configuração como FRAMEWORK nas propriedades do server.forward-headers-strategy aplicativo. (Não defina este valor como NATIVE. Caso contrário, serão usados outros cabeçalhos que não levam em conta o cabeçalho necessário X-Forwarded-Prefix .) Para obter mais informações, consulte Executando atrás de um servidor proxy front-end. Com essa configuração, o método HttpServletRequest.getRequestURL leva todos esses cabeçalhos em consideração e retorna a URL de solicitação exata conforme 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 proxy reverso para aplicativos publicamente acessíveis por meio de um ponto de extremidade do Spring Cloud Gateway.

O diagrama a seguir mostra a arquitetura do Cenário 3:

Transfira um ficheiro do Visio desta arquitetura.

Quando o Application Gateway fica na frente da sua instância do Azure Spring Apps, você usa o ponto de extremidade atribuído do aplicativo Spring Cloud Gateway como o pool de back-end. Um ponto final de exemplo é myspringcloudservice-mygateway.azuremicroservices.io. Como o Azure Spring Apps é implantado fora de uma rede virtual, essa URL é resolvida para um endereço IP público. Quando o pool de back-end é um ponto de extremidade público, o Application Gateway usa seu endereço IP público front-end para alcançar o serviço back-end.

Para permitir que apenas solicitações de sua instância do Application Gateway cheguem ao Spring Cloud Gateway, você pode configurar o predicado de XForwarded Remote Addr rota. Configure o predicado para permitir somente solicitações do endereço IP público dedicado do seu Application Gateway, 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 proxy reverso para aplicativos publicamente acessíveis por meio de um ponto de extremidade do Spring Cloud Gateway.

O diagrama a seguir mostra a arquitetura do Cenário 4:

Transfira um ficheiro do Visio desta 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 origem no Azure Front Door. Um ponto final de exemplo é https://myspringcloudservice-mygateway.azuremicroservices.io.

Como o Azure Front Door é um serviço global com muitos pontos de presença, ele usa muitos endereços IP para se comunicar com seu pool de back-end. A documentação do Azure Front Door descreve como bloquear o acesso a um back-end para permitir apenas o tráfego do Azure Front Door. No entanto, nesse cenário, você não controla a rede do Azure na qual seus aplicativos são implantados. Infelizmente, você não pode usar a AzureFrontDoor.Backend marca de serviço para obter uma lista completa de endereços IP de saída do Azure Front Door que é garantido para ser atual. Em vez disso, você precisa baixar intervalos de IP do Azure e tags de serviço, localizar a seção e copiar todos os intervalos de IP da addressPrefixes matriz para a AzureFrontDoor.Backend configuração de predicados de XForwarded Remote Addr rota.

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

Nesse cenário, sua configuração de predicado de rota do Spring Cloud Gateway pode se parecer com o exemplo a seguir:

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

Contribuidores

A Microsoft mantém este conteúdo. O seguinte colaborador desenvolveu o conteúdo original.

Autor principal:

• Jelle Druyts - Brasil | Engenheiro de Clientes Principal

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos

• Arquitetura de referência do Azure Spring Apps
• Responsabilidades do cliente pela execução dos Aplicativos Azure Spring nas Redes Virtuais do Azure

Recursos relacionados

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