Rede e conectividade para cargas de trabalho críticas

A distribuição regional de recursos na arquitetura de referência crítica requer uma infraestrutura de rede robusta.

É 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 selos seguem um design de rede virtual isolado. O tráfego entre selos não é recomendado. Emparelhamentos de rede virtual ou conexões VPN com outros selos não são necessários.

A arquitetura é intencional na definição dos selos regionais como de curta duração. O estado global da infraestrutura é armazenado nos recursos globais.

Um balanceador de carga global é necessário para rotear o tráfego para selos íntegros e fornecer serviços de segurança. Ele deve ter certas funcionalidades.

• A investigação de integridade é necessária para que o balanceador de carga possa marcar 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 por meio do uso do 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 selos 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 investigações de integridade que emitem 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 selo. O Front Door usa a resposta para determinar a integridade de um carimbo individual e rotear o tráfego para selos í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 das métricas de tráfego, segurança, ê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. Os componentes em uma rede virtual não podem se comunicar diretamente com componentes em outra rede virtual.

As solicitações para a plataforma de aplicativo são distribuídas com uma Azure Load Balancer externa de SKU padrão. Há uma marcar para garantir que o tráfego que chega ao balanceador de carga seja roteado por meio do Azure Front Door. Esse marcar garante que todo o tráfego tenha sido inspecionado pelo WAF do Azure.

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 aplicativo

A plataforma de aplicativo usada com os selos individuais na infraestrutura tem os seguintes requisitos de comunicação:

• A plataforma de aplicativo 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 Key Vault do Azure 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 para expor a plataforma de aplicativos pela Internet para essa comunicação. Os segredos podem ser comprometidos e é recomendável aumentar a segurança e o monitoramento dos pontos de extremidade públicos.

Considerações de rede estendidas

Esta seção discute os prós e contras de abordagens alternativas para o design de 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 NSG

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 NSGs 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

O SKU premium do Front Door dá suporte ao uso de pontos de extremidade 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 pontos de extremidade privados premium do Azure Front Door e do Azure habilitam clusters de computação totalmente privados nos selos 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 introduz outro ponto de falha. Os pontos de extremidade públicos expostos nos selos de aplicativo não são mais necessários e não podem mais ser acessados e expostos a um possível ataque de DDoS.

O aumento da segurança deve ser ponderado em relação ao aumento do esforço, do custo e da complexidade da confiabilidade.

Os agentes de build auto-hospedados devem ser usados para a implantação do selo. O gerenciamento desses agentes vem com uma sobrecarga de manutenção.

Pontos de extremidade privados – plataforma de aplicativo

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 aplicativo, toda a comunicação viajaria pela rede virtual do selo.

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. Isso isolaria os recursos de ataques públicos que poderiam causar tempo de inatividade e limitação que afetam a confiabilidade e a disponibilidade.

Os agentes de build auto-hospedados devem ser usados para a implantação do selo da mesma forma que acima. 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.