Rede e conectividade para cargas de trabalho críticas para a missão
A distribuição regional de recursos na arquitetura de referência crítica para a missão requer uma infraestrutura de rede robusta.
Recomenda-se um design distribuído globalmente em que os serviços do Azure se reúnam para fornecer uma aplicação de elevada disponibilidade. O balanceador de carga global combinado com selos regionais fornece essa garantia através de uma conectividade fiável.
Os selos regionais são a unidade implementável na arquitetura. A capacidade de implementar rapidamente um novo selo proporciona escalabilidade e suporta elevada disponibilidade. Os selos seguem uma estrutura de rede virtual isolada. O tráfego entre carimbos não é recomendado. Não são necessários peerings de rede virtual ou ligações VPN a outros selos.
A arquitetura é intencional na definição dos selos regionais como de curta duração. O estado global da infraestrutura é armazenado nos recursos globais.
É necessário um balanceador de carga global para encaminhar o tráfego para selos em bom estado de funcionamento e fornecer serviços de segurança. Tem de ter determinadas capacidades.
A pesquisa de estado de funcionamento é necessária para que o balanceador de carga possa verificar o estado de funcionamento da origem antes de encaminhar o tráfego.
Distribuição de tráfego ponderada.
Opcionalmente, deve conseguir efetuar a colocação em cache na extremidade. Além disso, forneça alguma garantia de segurança para a entrada através da utilização da firewall de aplicações Web (WAF).
Transfira um ficheiro do Visio desta arquitetura.
Entrada de tráfego
A aplicação definida na arquitetura tem acesso à Internet e tem vários requisitos:
Uma solução de encaminhamento global e que pode distribuir o tráfego entre selos regionais independentes.
Baixa latência na verificação de estado de funcionamento e capacidade de parar o envio de tráfego para carimbos em mau estado de funcionamento.
Prevenção de ataques maliciosos na periferia.
Forneça capacidades de colocação em cache na extremidade.
O ponto de entrada para todo o tráfego na estrutura é através do Azure Front Door. O Front Door é um balanceador de carga global que encaminha o tráfego HTTP(S) para back-ends/origens registados. O Front Door utiliza sondas de estado de funcionamento que emitem pedidos para um URI em cada back-end/origem. Na implementação de referência, o URI chamado é um serviço de estado de funcionamento. O serviço de saúde anuncia o estado de funcionamento do selo. O Front Door utiliza a resposta para determinar o estado de funcionamento de um selo individual e encaminhar o tráfego para carimbos em bom estado de funcionamento com capacidade de manutenção de pedidos de aplicações.
A integração do Azure Front Door com o Azure Monitor fornece monitorização quase em tempo real das métricas de tráfego, segurança, êxito e falha e alertas.
O Azure Firewall de Aplicações Web, integrado no Azure Front Door, é utilizado para evitar ataques na periferia antes de entrarem na rede.
Rede virtual isolada - API
A API na arquitetura utiliza as Redes Virtuais do Azure como limite de isolamento de tráfego. Os componentes numa rede virtual não conseguem comunicar diretamente com componentes noutra rede virtual.
Os pedidos para a plataforma de aplicações são distribuídos com uma Balanceador de Carga do Azure externa de SKU padrão. Existe uma verificação para garantir que o tráfego que atinge o balanceador de carga foi encaminhado através do Azure Front Door. Esta verificação garante que todo o tráfego foi inspecionado pela WAF do Azure.
Os agentes de compilação utilizados para as operações e implementação da arquitetura têm de conseguir aceder à rede isolada. A rede isolada pode ser aberta para permitir que os agentes comuniquem. Em alternativa, os agentes autoalojados podem ser implementados na rede virtual.
É necessária a monitorização do débito de rede, o desempenho dos componentes individuais e o estado de funcionamento da aplicação.
Dependência de comunicação da plataforma de aplicações
A plataforma de aplicações utilizada com os selos individuais na infraestrutura tem os seguintes requisitos de comunicação:
A plataforma de aplicações tem de conseguir comunicar de forma segura com os serviços PaaS da Microsoft.
Quando necessário, a plataforma de aplicações tem de conseguir comunicar de forma segura com outros serviços.
A arquitetura definida utiliza Key Vault do Azure para armazenar segredos, como cadeias de ligação e chaves de API, para comunicar de forma segura através da Internet com os serviços PaaS do Azure. Existem possíveis riscos para expor a plataforma de aplicações através da Internet para esta comunicação. Os segredos podem ser comprometidos e é recomendada uma maior segurança e monitorização dos pontos finais públicos.
Considerações sobre redes alargadas
Esta secção aborda os prós e os contras de abordagens alternativas à estrutura da rede. Considerações de rede alternativas e a utilização de pontos finais privados do Azure é o foco nas secções seguintes.
Sub-redes e NSG
As sub-redes nas redes virtuais podem ser utilizadas para segmentar o tráfego na estrutura. O isolamento da sub-rede separa os recursos para diferentes funções.
Os grupos de segurança de rede podem ser utilizados para controlar o tráfego permitido dentro e fora de cada sub-rede. As regras utilizadas nos NSGs podem ser utilizadas para limitar o tráfego com base no IP, na porta e no protocolo para bloquear o tráfego indesejado para a sub-rede.
Pontos finais privados - Entrada
O SKU premium do Front Door suporta a utilização de Pontos Finais Privados do Azure. Os pontos finais privados expõem um serviço do Azure a um endereço IP privado numa rede virtual. As ligações são efetuadas de forma segura e privada entre serviços sem a necessidade de encaminhar o tráfego para pontos finais públicos.
O Azure Front Door premium e os Pontos Finais Privados do Azure permitem clusters de computação totalmente privados nos selos individuais. O tráfego está totalmente bloqueado para todos os serviços PaaS do Azure.
A utilização de pontos finais privados aumenta a segurança da estrutura. No entanto, introduz outro ponto de falha. Os pontos finais públicos expostos nos selos da aplicação já não são necessários e já não podem ser acedidos e expostos a um possível ataque DDoS.
O aumento da segurança tem de ser ponderado em comparação com o aumento do esforço de fiabilidade, do custo e da complexidade.
Os agentes de compilação autoalojados têm de ser utilizados para a implementação do selo. A gestão destes agentes inclui uma sobrecarga de manutenção.
Pontos finais privados - Plataforma de aplicações
Os pontos finais privados são suportados para todos os serviços PaaS do Azure utilizados nesta estrutura. Com os pontos finais privados configurados para a plataforma de aplicações, toda a comunicação percorreria a rede virtual do selo.
Os pontos finais públicos dos serviços PaaS individuais do Azure podem ser configurados para não permitir o acesso público. Isto isolaria os recursos de ataques públicos que poderiam causar tempo de inatividade e limitação que afetam a fiabilidade e a disponibilidade.
Os agentes de compilação autoalojados têm de ser utilizados para a implementação de selos da mesma forma que acima. A gestão destes agentes inclui uma sobrecarga de manutenção.
Passos seguintes
Implemente a implementação de referência para obter uma compreensão completa dos recursos e da respetiva configuração utilizada nesta arquitetura.