Rede e conectividade para cargas de trabalho críticas
A distribuição regional de recursos na arquitetura de referência de missão crítica requer uma infraestrutura de rede sólida.
É recomendável um design distribuído globalmente em que os serviços do Azure se unam para fornecer um aplicativo altamente disponível. O balanceador de carga global combinado com selos regionais fornece essa garantia por meio de conectividade confiável.
Os selos regionais são a unidade implantável na arquitetura. A capacidade de implantar rapidamente um novo selo fornece escalabilidade e dá suporte à alta disponibilidade. Os carimbos seguem um design de rede virtual isolado. O tráfego com carimbo cruzado não é recomendado. Emparelhamentos de rede virtual ou conexões VPN com outros carimbos não são necessários.
A arquitetura é intencional ao definir os selos regionais como efêmeros. O estado global da infraestrutura é armazenado nos recursos globais.
Um balanceador de carga global é necessário para rotear o tráfego para carimbos saudáveis e prestar serviços de segurança. Ele deve ter determinadas funcionalidades.
A verificação de integridade é necessária para que o balanceador de carga possa verificar a integridade da origem antes de rotear o tráfego.
Distribuição de tráfego ponderada.
Opcionalmente, ele deve ser capaz de executar o cache na borda. Além disso, forneça alguma garantia de segurança para entrada usando o WAF (firewall do aplicativo Web).
Baixe um Arquivo Visio dessa arquitetura.
Entrada de tráfego
O aplicativo definido na arquitetura é voltado para a Internet e tem vários requisitos:
Uma solução de roteamento global e que pode distribuir o tráfego entre selos regionais independentes.
Baixa latência na verificação de integridade e a capacidade de parar de enviar tráfego para carimbos não íntegros.
Prevenção de ataques mal-intencionados na borda.
Forneça habilidades de cache na borda.
O ponto de entrada para todo o tráfego no design é por meio do Azure Front Door. O Front Door é um balanceador de carga global que roteia o tráfego HTTP(S) para back-ends/origens registrados. O Front Door usa sondas de integridade que realizam solicitações para um URI em cada back-end/origem. Na implementação de referência, o URI chamado é um serviço de integridade. O serviço de integridade anuncia a integridade do carimbo. O Front Door usa a resposta para determinar a integridade de um carimbo individual e rotear o tráfego para carimbos íntegros capazes de atender solicitações de aplicativo.
A integração do Azure Front Door com o Azure Monitor fornece monitoramento quase em tempo real de tráfego, segurança, métricas de êxito e falha e alertas.
O Firewall de Aplicativo Web do Azure, integrado ao Azure Front Door, é usado para evitar ataques na borda antes de entrar na rede.
Rede virtual isolada – API
A API na arquitetura usa redes virtuais do Azure como o limite de isolamento de tráfego. Componentes em uma rede virtual não podem se comunicar diretamente com componentes em outra rede virtual.
O Azure Load Balancer externo padrão distribui solicitações para a plataforma de aplicativo. Ele verifica se o tráfego que chegou ao balanceador de carga foi roteado por meio do Azure Front Door, garantindo que o Firewall de Aplicações Web (WAF) do Azure inspeccione todo o tráfego.
Os agentes de build usados para as operações e a implantação da arquitetura devem ser capazes de acessar a rede isolada. A rede isolada pode ser aberta para permitir que os agentes se comuniquem. Como alternativa, agentes auto-hospedados podem ser implantados na rede virtual.
O monitoramento da taxa de transferência de rede, o desempenho dos componentes individuais e a integridade do aplicativo são necessários.
Dependência de comunicação da plataforma de aplicações
A plataforma de aplicativo usada com os selos individuais na infraestrutura tem os seguintes requisitos de comunicação:
A plataforma de aplicativos deve ser capaz de se comunicar com segurança com os serviços de PaaS da Microsoft.
A plataforma de aplicativo deve ser capaz de se comunicar com segurança com outros serviços quando necessário.
A arquitetura definida usa o Azure Key Vault para armazenar segredos, como cadeias de conexão e chaves de API, para se comunicar com segurança pela Internet com os serviços de PaaS do Azure. Há possíveis riscos em expor a plataforma de aplicativos na Internet para essa comunicação. Os segredos podem ser comprometidos e recomenda-se aumentar a segurança e o monitoramento dos endpoints públicos.
Considerações de rede estendidas
Esta seção discute os prós e contras de abordagens alternativas ao design da rede. Considerações alternativas de rede e o uso de pontos de extremidade privados do Azure são o foco nas seções a seguir.
Sub-redes e grupos de segurança de rede
As sub-redes dentro das redes virtuais podem ser usadas para segmentar o tráfego dentro do design. O isolamento de sub-rede separa os recursos para funções diferentes.
Os grupos de segurança de rede podem ser usados para controlar o tráfego permitido dentro e fora de cada sub-rede. As regras usadas nos grupos de segurança de rede podem ser usadas para limitar o tráfego com base em IP, porta e protocolo para bloquear o tráfego indesejado na sub-rede.
Pontos de extremidade privados - Entrada
A versão premium do Front Door oferece suporte ao uso de Endpoints Privados do Azure. Pontos de extremidade privados expõem um serviço do Azure a um endereço IP privado em uma rede virtual. As conexões são feitas de forma segura e privada entre os serviços sem a necessidade de rotear o tráfego para pontos de extremidade públicos.
Os serviços Azure Front Door Premium e Azure Private Endpoints possibilitam clusters de computação totalmente privados em carimbos individuais. O tráfego está totalmente bloqueado para todos os serviços de PaaS do Azure.
O uso de pontos de extremidade privados aumenta a segurança do design. No entanto, ele apresenta outro ponto de falha. Os pontos de extremidade públicos expostos nos carimbos de aplicativo não são mais necessários e não podem mais ser acessados e expostos a um possível ataque DDoS.
O aumento da segurança deve ser ponderado em comparação com o aumento do esforço, do custo e da complexidade da confiabilidade.
Agentes de build auto-hospedados devem ser usados para a implantação do carimbo. O gerenciamento desses agentes vem com uma sobrecarga de manutenção.
Pontos de extremidade privados – Plataforma de aplicativos
Há suporte para pontos de extremidade privados para todos os serviços de PaaS do Azure usados neste design. Com pontos de extremidade privados configurados para a plataforma de aplicativos, toda a comunicação percorreia a rede virtual do carimbo.
Os pontos de extremidade públicos dos serviços de PaaS individuais do Azure podem ser configurados para não permitir o acesso público. Esse processo isola os recursos de ataques públicos que podem causar indisponibilidade e limitação de recursos, afetando a confiabilidade e a disponibilidade.
Agentes de build auto-hospedados devem ser usados para a implantação de carimbo, assim como anteriormente. O gerenciamento desses agentes vem com uma sobrecarga de manutenção.
Próximas etapas
Implante a implementação de referência para obter uma compreensão completa dos recursos e sua configuração usada nessa arquitetura.