Prepare-se para implantar a carga de trabalho de aplicativo Web do Amazon Web Services (AWS) para Azure

Este artigo fornece um guia abrangente sobre como implantar uma infraestrutura robusta e pronta para produção para facilitar a hospedagem, a proteção, o dimensionamento e o monitoramento de um aplicativo Web na plataforma Azure.

Implantação do Yelb no AWS

O aplicativo Web de exemplo yelb no AWS é implantado usando Bash, CLI do AWS, eksctl, kubectl e Helm. O sample complementar contém scripts Bash e manifestos YAML que você pode usar para automatizar a implantação do aplicativo Yelb no AWS Elastic Kubernetes Service (EKS). Esta solução demonstra como implementar um firewall de aplicativo Web usando o WAF do AWS para proteger um aplicativo Web em execução no Amazon Elastic Kubernetes Service (EKS). Você pode usar os scripts bash para criar um cluster EKS e implantar o aplicativo Yelb . O aplicativo Web Yelb é exposto à Internet pública usando um aplicativo Web Amazon Application Load Balancer (ALB) e protegido usando AWS WAF web access control list (WEB ACL). Para obter instruções detalhadas, consulte Porting a Web Application from AWS Elastic Kubernetes Service (EKS) to AKS (Serviço de Kubernetes do Azure).

Captura de tela da interface de serviço Yelb.

Implantação do Yelb no Azure

Nas seções a seguir, você aprenderá a implantar o Yelb aplicativo Web de exemplo em um cluster AKS (Serviço de Kubernetes do Azure) e expô-lo por meio de um controlador de entrada como o controlador de entrada NGINX. O serviço do controlador de entrada é acessível por meio de um balanceador de carga interno (ou privado), que equilibra o tráfego dentro da rede virtual que abriga o cluster do AKS. Em um cenário híbrido, o front-end do balanceador de carga pode ser acessado de uma rede local. Para saber mais sobre o balanceamento de carga interno, consulte Use um balanceador de carga interno com AKS (Serviço de Kubernetes do Azure).

O exemplo complementar sample oferece suporte à instalação de um controlador de ingresso NGINX gerenciado com o complemento de roteamento de aplicativos ou de um controlador de ingresso NGINX não gerenciado usando o gráfico do Helm. O complemento de roteamento de aplicativos com o controlador de entrada NGINX fornece os seguintes recursos:

  • Configuração fácil de controladores de entrada NGINX gerenciados com base no controlador de entrada do Kubernetes NGINX.
  • Integração com o DNS do Azure para gerenciamento de zona pública e privada.
  • Terminação SSL com certificados armazenados no Azure Key Vault.

Para outras configurações,

Para aprimorar a segurança, o aplicativo Yelb é protegido por um recurso Gateway de Aplicativo do Azure. Esse recurso é implantado em uma sub-rede dedicada dentro da mesma rede virtual que o cluster do AKS ou em uma rede virtual emparelhada. O Firewall de Aplicativo Web do Azure (WAF) protege o acesso ao aplicativo web hospedado no AKS (Serviço de Kubernetes do Azure) e exposto por meio do Gateway de Aplicativo do Azure contra explorações e vulnerabilidades comuns.

Pré-requisitos

Architecture

Este exemplo fornece uma coleção de modelos Bicep, scripts bash, e manifestos YAML para criar um cluster do AKS, implantar o aplicativo Yelb, expor o serviço de interface do usuário usando o controlador de entrada NGINX e protegê-lo com o Gateway de Aplicativo do Azure e Firewall de Aplicativo Web do Azure (WAF).

Este exemplo também inclui dois arquivos de parâmetro Bicep separados e dois conjuntos de scripts Bash e manifestos YAML, cada um voltado para a implantação de duas opções de solução diferentes. Para obter mais informações sobre Bicep, consulte O que é Bicep?

Terminação TLS no Gateway de Aplicativo e invocação do Yelb via HTTP

Nesta solução, o WAF (Firewall de Aplicativo Web do Azure(WAF) garante a segurança do sistema bloqueando ataques mal-intencionados. O Gateway de Aplicativo do Azure recebe chamadas recebidas de aplicativos cliente, executa a terminação TLS e encaminha as solicitações para o serviço yelb-ui hospedado pelo AKS. Essa comunicação é obtida por meio do balanceador de carga interno e do controlador de entrada NGINX usando o protocolo de transporte HTTP. O diagrama a seguir ilustra a arquitetura:

Diagrama da solução baseada em Application Gateway WAFv2 e no controlador de ingresso NGINX via HTTP.

O fluxo de mensagens é o seguinte:

Diagrama do fluxo de mensagens da solução baseada em Application Gateway WAFv2 e no controlador de ingresso NGINX via HTTP.

  1. O Gateway de Aplicativo do Azure manipula a terminação TLS e envia chamadas de entrada para o serviço de yelb-ui hospedado pelo AKS por HTTP.
  2. O Ouvinte do Gateway de Aplicativo usa um certificado SSL obtido de Azure Key Vault para garantir a comunicação segura.
  3. A política de WAF Azure associada ao Ouvinte aplica regras OWASP e regras personalizadas a solicitações de entrada, impedindo efetivamente muitos tipos de ataques mal-intencionados.
  4. As configurações de HTTP do backend do Application Gateway acessam o aplicativo Yelb por HTTP na porta 80.
  5. O pool de back-end do Gateway de Aplicativo e a Investigação de Integridade chamam o controlador de entrada do NGINX por meio do balanceador de carga interno do AKS, usando o protocolo HTTP para gerenciamento de tráfego.
  6. O controlador de entrada NGINX usa o balanceador de carga interno do AKS para garantir a comunicação segura dentro do cluster.
  7. Um objeto de entrada do Kubernetes usa o controlador de entrada NGINX para expor o aplicativo por meio de HTTP por meio do balanceador de carga interno.
  8. O yelb-ui serviço com o ClusterIP tipo restringe sua invocação para dentro do cluster ou por meio do controlador de entrada NGINX.

Implementando o TLS de ponta a ponta usando Gateway de Aplicativo do Azure

terminação TLS

Gateway de Aplicativo do Azure dá suporte à terminação TLS no nível do gateway, o que significa que o tráfego é descriptografado no gateway antes de ser enviado para os servidores de back-end. Para configurar a terminação do TLS, você precisa adicionar um certificado TLS/SSL ao ouvinte. O certificado deve estar no formato PFX (Exchange de Informações Pessoais), que contém as chaves privadas e públicas. Você pode importar o certificado de Azure Key Vault para o Gateway de Aplicativo. Para obter mais informações, confira Encerramento de TLS com certificados do Key Vault.

modelo de segurança Confiança Zero

Se você adotar um modelo de segurança Confiança Zero, deverá impedir a comunicação não criptografada entre um proxy de serviço como Gateway de Aplicativo do Azure e os servidores de back-end. Com o modelo de segurança Confiança Zero, a confiança não é concedida automaticamente a nenhum usuário ou dispositivo que tente acessar recursos em uma rede. Em vez disso, requer verificação contínua de identidade e autorização para cada solicitação, independentemente do local ou da rede do usuário. Em nosso cenário, a implementação do modelo de segurança Confiança Zero envolve o uso do Gateway de Aplicativo do Azure como um proxy de serviço, que atua como um front-end para solicitações de entrada. Essas solicitações, em seguida, viajam até o controlador de entrada NGINX em AKS (Serviço de Kubernetes do Azure) em um formato criptografado.

TLS de ponta a ponta no Gateway de Aplicativo

Você pode implementar uma abordagem Confiança Zero configurando Gateway de Aplicativo do Azure para criptografia TLS de ponta a ponta com os servidores de back-end. A criptografia TLS de ponta a ponta permite transmitir dados confidenciais com segurança para o back-end, aproveitando os recursos de balanceamento de carga da camada 7 do Gateway de Aplicativo, incluindo afinidade de sessão baseada em cookie, roteamento baseado em URL, roteamento baseado em sites e a capacidade de reescrever ou injetar cabeçalhos X-Forwarded-*.

Quando o Application Gateway é configurado no modo de comunicação TLS de ponta a ponta, ele encerra as sessões TLS no gateway e descriptografa o tráfego dos usuários. Em seguida, ele aplica as regras configuradas para selecionar a instância de pool de back-end apropriada para a qual rotear o tráfego. Em seguida, o Application Gateway inicia uma nova conexão TLS com o servidor de back-end e criptografa novamente os dados usando o certificado de chave pública do servidor de back-end antes de encaminhar a solicitação ao servidor de back-end. A resposta do servidor Web segue o mesmo processo antes de chegar ao usuário final. Para habilitar o TLS de ponta a ponta, você precisa definir a configuração de protocolo na Configuração HTTP de Back-end como HTTPS e aplicá-la a um pool de back-end. Essa abordagem garante que sua comunicação com os servidores de back-end esteja protegida e em conformidade com seus requisitos.

Para obter mais informações, consulte a criptografia TLS de ponta a ponta do Gateway de Aplicativo e as práticas recomendadas para proteger o Gateway de Aplicativo.

Nesta solução, o WAF (Firewall de Aplicativo Web do Azure(WAF) garante a segurança do sistema bloqueando ataques mal-intencionados. O Gateway de Aplicativo do Azure processa chamadas recebidas de aplicativos clientes, realiza a terminação de TLS e implementa TLS de ponta a ponta invocando o serviço yelb-ui subjacente hospedado no AKS usando o protocolo de transporte HTTPS por meio do balanceador de carga interno e do controlador de entrada NGINX. O diagrama a seguir ilustra a arquitetura:

Diagrama da solução baseada no Application Gateway WAFv2 e no controlador de ingresso NGINX via HTTPS.

O fluxo de mensagens é o seguinte:

  1. O Gateway de Aplicativo do Azure manipula a terminação TLS e se comunica com o aplicativo de back-end via HTTPS.
  2. O Listener do Gateway de Aplicativo usa um certificado SSL obtido do Azure Key Vault.
  3. A política de WAF Azure associada ao Ouvinte executa regras OWASP e regras personalizadas contra solicitações de entrada para bloquear ataques mal-intencionados.
  4. As Configurações HTTP de back-end do Application Gateway estão definidas para invocar o serviço yelb-ui hospedado no AKS via HTTPS na porta 443.
  5. O pool de back-end do Gateway de Aplicativo e a Investigação de Integridade chamam o controlador de entrada do NGINX por meio do balanceador de carga interno do AKS usando HTTPS.
  6. O controlador de entrada NGINX é implantado para usar o balanceador de carga interno do AKS.
  7. O cluster do SAKS é configurado com o provedor do Azure Key Vault para o complemento do Driver CSI do repositório de segredos para recuperar segredos, certificados e chaves do Azure Key Vault por meio de um volume CSI.
  8. Um SecretProviderClass é usado para recuperar o certificado usado pelo Gateway de Aplicativo do Key Vault.
  9. Um objeto de entrada do Kubernetes usa o controlador de entrada NGINX para expor o aplicativo por meio de HTTPS por meio do balanceador de carga interno do AKS.
  10. O yelb-ui serviço tem um ClusterIP tipo, que restringe sua invocação para dentro do cluster ou por meio do controlador de entrada NGINX.

Para ajudar a garantir a segurança e a estabilidade do sistema, considere as seguintes recomendações:

  • Atualize regularmente a política de WAF Azure com as regras mais recentes para garantir a segurança ideal.
  • Implemente mecanismos de monitoramento e registro em log para acompanhar e analisar solicitações de entrada e possíveis ataques.
  • Execute regularmente a manutenção e as atualizações do cluster do AKS, do controlador de entrada NGINX e do Gateway de Aplicativo para resolver quaisquer vulnerabilidades de segurança e manter uma infraestrutura segura.
  • Implemente mecanismos de monitoramento e registro em log para acompanhar e analisar solicitações de entrada e possíveis ataques.
  • Execute regularmente a manutenção e as atualizações do cluster do AKS, do controlador de entrada NGINX e do Gateway de Aplicativo para resolver quaisquer vulnerabilidades de segurança e manter uma infraestrutura segura.

Nome do host

O listener do Application Gateway e o ingress do Kubernetes estão configurados para usar o mesmo nome de host. É importante usar o mesmo nome de host para um proxy de serviço e um aplicativo Web de back-end pelos seguintes motivos:

  • Preservação do estado da sessão: quando você usa um nome de host diferente para o proxy e o aplicativo de back-end, o estado da sessão pode ser perdido. Isso significa que as sessões de usuário podem não persistir corretamente, resultando em uma experiência ruim do usuário e potencial perda de dados.
  • Falha de autenticação: se o nome do host for diferente entre o proxy e o aplicativo de back-end, os mecanismos de autenticação poderão falhar. Essa abordagem pode fazer com que os usuários não consigam fazer logon ou acessar recursos seguros dentro do aplicativo.
  • Exposição inadvertida de URLs: se o nome do host não for preservado, há o risco de que AS URLs de back-end possam ser expostas aos usuários finais. Isso pode levar a possíveis vulnerabilidades de segurança e acesso não autorizado a informações confidenciais.
  • Problemas de cookie: os cookies desempenham um papel crucial na manutenção das sessões do usuário e na passagem de informações entre o cliente e o servidor. Quando o nome do host é diferente, os cookies podem não funcionar conforme o esperado, levando a problemas como autenticação com falha, tratamento de sessão inadequado e redirecionamento incorreto.
  • Requisitos TLS/SSL de ponta a ponta: se o TLS/SSL de ponta a ponta for necessário para uma comunicação segura entre o proxy e o serviço de back-end, um certificado TLS correspondente para o nome do host original será necessário. O uso do mesmo nome de host simplifica o processo de gerenciamento de certificados e garante que a comunicação segura seja estabelecida perfeitamente.

Você pode evitar esses problemas usando o mesmo nome do host para o proxy do serviço e o aplicativo web de back-end. O aplicativo de back-end vê o mesmo domínio que o navegador da Web, garantindo que o estado da sessão, a autenticação e a função de tratamento de URL funcionem corretamente.

Fluxo de Mensagens

O diagrama a seguir mostra as etapas para o fluxo de mensagens durante a implantação e o tempo de execução.

Diagrama do fluxo de mensagens da solução baseada no Gateway de Aplicativo WAFv2 e no controlador de ingresso NGINX via HTTPS.

Fluxo de trabalho de implantação

As etapas a seguir descrevem o processo de implantação. Esse fluxo de trabalho corresponde aos números verdes no diagrama anterior.

  1. Um engenheiro de segurança gera um certificado para o domínio personalizado que a carga de trabalho usa e o salva em um cofre de chaves Azure. Você pode obter um certificado válido de uma AC (autoridade de certificação) conhecida.
  2. Um engenheiro de plataforma especifica as informações necessárias no arquivo de parâmetros main.bicepparams Bicep e implanta os modelos de Bicep para criar os recursos de Azure. As informações necessárias incluem:
    • Um prefixo para os recursos de Azure.
    • O nome e o grupo de recursos do Azure Key Vault existente que contém o certificado TLS para o nome de host da workload e o domínio personalizado do ouvinte do Gateway de Aplicativo.
  3. Você pode configurar o script de implantação para instalar os seguintes pacotes no cluster do AKS. Para obter mais informações, verifique a seção de parâmetros do módulo Bicep.
  4. O ouvinte do Gateway de Aplicativo recupera o certificado TLS do Azure Key Vault.
  5. O objeto de entrada de Kubernetes usa o certificado obtido do provedor do Azure Key Vault para o Driver CSI do repositório de segredos para expor o serviço de interface do usuário do Yelb via HTTPS.
  6. O ouvinte do Gateway de Aplicativo recupera o certificado TLS do Azure Key Vault.
  7. O objeto de entrada de Kubernetes utiliza o certificado obtido do provedor do Azure Key Vault para o Driver CSI do repositório de segredos para expor o serviço de interface do usuário do Yelb via HTTPS.

Runtime de fluxo de trabalho

  1. O aplicativo cliente chama o aplicativo Web de exemplo usando seu nome de host. A zona DNS associada ao domínio personalizado do ouvinte do Gateway de Aplicativo usa um registro A para resolver a consulta DNS com o endereço de IP do Azure usado pela configuração de IP de front-end do Gateway de Aplicativo.
  2. A solicitação é enviada para o IP público Azure usado pela configuração de IP front-end do Gateway de Aplicativo.
  3. O Gateway de Aplicativo executa as seguintes ações:
    1. O Gateway de Aplicativo do Azure lida com a terminação TLS e se comunica com o aplicativo de backend via HTTPS.
    2. O Listener do Gateway de Aplicativo usa um certificado SSL obtido do Azure Key Vault.
    3. A política de WAF Azure associada ao Ouvinte executa regras OWASP e regras personalizadas contra a solicitação de entrada e bloqueia ataques mal-intencionados.
    4. As configurações HTTP de back-end do Gateway de Aplicativo são configuradas para invocar o aplicativo Web de exemplo via HTTPS na porta 443.
  4. O pool de back-end do Gateway de Aplicativo acessa o controlador de entrada do NGINX por meio do balanceador de carga interno do AKS usando HTTPS.
  5. A solicitação é enviada a um dos nós do agente que hospeda um pod do controlador de entrada NGINX.
  6. Uma das réplicas do controlador de ingresso do NGINX processa a solicitação e a envia para um dos endpoints do serviço yelb-ui.
  7. O yelb-ui chama o serviço yelb-appserver.
  8. O yelb-appserver chama o serviço yelb-db e o serviço yelb-cache.
  9. O yelb-ui chama o serviço yelb-appserver.
  10. O yelb-appserver chama os serviços yelb-db e yelb-cache.

Deployment

Por padrão, os modelos Bicep implantam o cluster AKS com o plugin de rede Azure CNI Overlay e o plano de dados Cilium. Você pode usar um plug-in de rede alternativo. Além disso, o projeto mostra como implantar um cluster do AKS com as seguintes extensões e recursos:

Em um ambiente de produção, recomendamos fortemente implantar um cluster AKS privado com SLA de Tempo de Atividade. Para obter mais informações, consulte o cluster do AKS privado com um endereço DNS público.

Como alternativa, você pode implantar um cluster público do AKS e proteger o acesso ao servidor de API usando intervalos de endereços IP autorizados. Para obter informações detalhadas e instruções sobre como implantar a infraestrutura em Azure usando modelos de Bicep, consulte o companion Azure exemplo de código.

Em um ambiente de produção, recomendamos fortemente implantar um cluster AKS privado com SLA de tempo de atividade. Para obter mais informações, consulte o cluster do AKS privado com um endereço DNS público. Como alternativa, você pode implantar um cluster público do AKS e proteger o acesso ao servidor de API usando intervalos de endereços IP autorizados. Para obter informações detalhadas e instruções sobre como implantar a infraestrutura em Azure usando modelos Bicep, consulte o companion Azure exemplo de código.

Próxima etapa

Implantar uma carga de trabalho de aplicativo web da AWS para o Azure

Colaboradores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram originalmente este artigo:

Autor principal:

Outros colaboradores:

  • Last updated on