Compartilhar via

Abordagens de arquitetura para rede em soluções multilocatário

Todas as soluções implantadas no Azure exigem alguma forma de rede. A forma como você interage com os serviços de rede do Azure depende do design e da carga de trabalho da sua solução. Este artigo fornece considerações e diretrizes para os aspectos de rede de soluções multilocatários no Azure. Ele inclui informações sobre componentes de rede de nível inferior, como redes virtuais, e se estende a abordagens de nível superior e de camada de aplicativo.

Observação

O Azure é um ambiente multilocatário, assim como muitos de seus componentes de rede. Você não precisa entender os detalhes para criar sua própria solução, mas pode saber mais sobre como o Azure isola o tráfego de rede virtual do tráfego de outros clientes.

Considerações e requisitos

Serviços de plataforma e infraestrutura

As considerações do componente de rede dependem da categoria de serviços que você usa.

Serviços de infraestrutura

Quando você usa serviços de infraestrutura, como máquinas virtuais (VMs) ou AKS (Serviço de Kubernetes do Azure), considere e projete as redes virtuais que sustentam a conectividade de seus serviços. Considere também as outras camadas de segurança e isolamento que você precisa incorporar ao seu design. Evite depender exclusivamente de controles de camada de rede.

Serviços de plataforma

Quando você usa serviços de plataforma do Azure, como o Serviço de Aplicativo do Azure, o Azure Cosmos DB ou o Banco de Dados SQL do Azure, sua arquitetura determina os serviços de rede necessários.

Para isolar os serviços de plataforma da Internet, use uma rede virtual. Dependendo dos serviços usados, você pode trabalhar com pontos de extremidade privados ou recursos integrados à rede virtual, como o Gateway de Aplicativo do Azure. Você também pode disponibilizar seus serviços de plataforma por meio de seus endereços IP públicos e usar as próprias proteções dos serviços, como firewalls e controles de identidade. Nessas situações, talvez você não precise implantar e configurar sua própria rede virtual.

Decida se deve usar redes virtuais para serviços de plataforma com base nos seguintes fatores:

  • Requisitos de conformidade: talvez seja necessário atender a um padrão de conformidade específico. Alguns padrões exigem que você configure seu ambiente do Azure de maneiras específicas, como usar controles de rede específicos. Para obter mais informações, consulte abordagens de arquitetura para governança e conformidade em soluções multilocatários.

  • Requisitos dos locatários: Mesmo que sua organização não tenha requisitos definidos para isolamento ou controles de camada de rede, seus locatários poderão. Entenda claramente como seus locatários planejam acessar sua solução e se eles têm alguma suposição sobre seu design de rede.

  • Complexidade: As redes virtuais introduzem complexidade. Certifique-se de que sua equipe entenda claramente os princípios envolvidos para evitar a implantação de um ambiente inseguro.

Verifique se você entende as implicações do uso da rede privada.

Dimensionar suas sub-redes

Quando você precisar implantar uma rede virtual, considere cuidadosamente o dimensionamento e o espaço de endereço de toda a rede virtual, incluindo as sub-redes.

Entenda como você planeja implantar seus recursos do Azure em redes virtuais e o número de endereços IP consumidos por cada recurso. Se você implantar nós de computação específicos do locatário, servidores de banco de dados ou outros recursos, crie sub-redes grandes o suficiente para o crescimento de locatário esperado e o dimensionamento automático horizontal de recursos.

Da mesma forma, quando você trabalha com serviços gerenciados, entenda como eles consomem endereços IP. Por exemplo, quando você usa o AKS com a CNI (Interface de Rede de Contêiner do Azure), o número de endereços IP consumidos de uma sub-rede é baseado em fatores como o número de nós, como você dimensiona horizontalmente e seu processo de implantação de serviço. Quando você usa o Serviço de Aplicativo e o Azure Functions com integração de rede virtual, o número de endereços IP consumidos é baseado no número de instâncias de plano.

Examine as diretrizes de segmentação de sub-rede ao planejar suas sub-redes.

Acesso público ou privado

Considere se seus locatários precisam acessar seus serviços por meio da Internet ou por meio de endereços IP privados.

Para proteger seu serviço para acesso baseado na Internet (público), use regras de firewall, lista de permissões de endereço IP e lista de negações, segredos e chaves compartilhados e controles baseados em identidade.

Para permitir que os locatários se conectem ao seu serviço usando endereços IP privados, considere usar o serviço de Link Privado do Azure ou o emparelhamento de rede virtual entre locatários. Para alguns cenários limitados, você também pode considerar o uso do Azure ExpressRoute ou do Gateway de VPN do Azure para habilitar o acesso privado à sua solução. Normalmente, essa abordagem só faz sentido quando você tem poucos locatários e quando implanta redes virtuais dedicadas para cada locatário.

Acesso a pontos de extremidade dos locatários

Considere se você precisa enviar dados para pontos de extremidade dentro das redes dos locatários, dentro ou fora do Azure. Por exemplo, você pode invocar um webhook fornecido pelo cliente ou enviar mensagens em tempo real para os sistemas de um locatário.

Se você precisar enviar dados para os pontos de extremidade dos locatários, considere as seguintes abordagens comuns:

  • Inicie conexões da sua solução com os pontos de extremidade dos locatários por meio da Internet. Considere se as conexões precisam se originar de um endereço IP estático. Dependendo dos serviços do Azure que você usa, talvez seja necessário usar a NAT (conversão de endereços de rede) implantando o Gateway nat do Azure, um firewall ou um balanceador de carga.

  • Implante um agente para habilitar a conectividade entre seus serviços hospedados no Azure e as redes de seus clientes, independentemente de sua localização.

  • Considere usar um serviço como a Grade de Eventos do Azure, potencialmente com domínios de eventos, para mensagens unidirecionais.

Abordagens e padrões a serem considerados

Esta seção descreve algumas das principais abordagens de rede a serem consideradas em uma solução multilocatário. Ele começa com abordagens de nível inferior para componentes de rede principais e, em seguida, descreve abordagens para HTTP e outras preocupações de camada de aplicativo.

Redes virtuais específicas do locatário com endereços IP selecionados pelo provedor de serviços

Em alguns cenários, você precisa executar recursos dedicados conectados à rede virtual no Azure em nome de um locatário. Por exemplo, você pode executar uma VM para cada locatário ou talvez precise usar pontos de extremidade privados para acessar bancos de dados específicos do locatário.

Considere implantar uma rede virtual para cada locatário usando um espaço de endereço IP que você controla. Essa abordagem permite que você emparelhe as redes virtuais para suas próprias finalidades, como estabelecer uma topologia hub-and-spoke para controlar centralmente a entrada e a saída do tráfego.

Evite usar endereços IP selecionados pelo provedor de serviços se os locatários precisarem se conectar diretamente à rede virtual que você cria, como usando o emparelhamento de rede virtual. O espaço de endereço que você seleciona provavelmente entra em conflito com seus espaços de endereço existentes.

Redes virtuais específicas do locatário com endereços IP selecionados pelo locatário

Se os locatários precisarem emparelhar suas próprias redes virtuais com a rede virtual que você gerencia em seu nome, considere implantar redes virtuais específicas de locatário usando um espaço de endereço IP selecionado pelo locatário. Essa configuração permite que cada locatário garanta que os intervalos de endereços IP na rede virtual do sistema não se sobreponham às suas próprias redes virtuais, o que permite a compatibilidade para emparelhamento.

Mas essa abordagem provavelmente impede que você emparelhe as redes virtuais de seus locatários ou adote uma topologia hub-and-spoke. As redes virtuais emparelhadas não podem usar intervalos de endereços IP sobrepostos e, quando os locatários selecionam seus próprios intervalos de endereços IP, provavelmente selecionarão intervalos que se sobrepõem entre si.

Topologia hub-spoke

A topologia de rede virtual hub-and-spoke permite emparelhar uma rede virtual de hub centralizada com várias redes virtuais spoke . Você pode controlar centralmente a entrada e a saída de tráfego para suas redes virtuais e controlar se os recursos na rede virtual de cada spoke podem se comunicar entre si. Cada rede virtual spoke também pode acessar componentes compartilhados, como o Firewall do Azure, e pode usar serviços como a Proteção contra DDoS do Azure.

Quando você usa uma topologia hub-and-spoke, planeje limites como o número máximo de redes virtuais emparelhadas. Não use espaços de endereço sobrepostos para a rede virtual de cada locatário.

Considere usar a topologia hub-and-spoke ao implantar redes virtuais específicas do locatário que usam endereços IP selecionados. A rede virtual de cada locatário se torna um spoke e pode compartilhar recursos comuns na rede virtual do hub. Você também pode usar a topologia hub-and-spoke ao dimensionar recursos compartilhados em várias redes virtuais ou quando usar o padrão Selos de Implantação.

Dica

Se sua solução abranger várias regiões geográficas, implante hubs e recursos de hub separados em cada região para impedir que o tráfego atravesse várias regiões do Azure. Essa prática incorre em um custo de recurso mais alto, mas reduz a latência da solicitação e reduz os encargos globais de emparelhamento.

Endereços IP estáticos

Considere se seus locatários precisam de seu serviço para usar endereços IP públicos estáticos para tráfego de entrada, tráfego de saída ou ambos. Diferentes serviços do Azure habilitam endereços IP estáticos de maneiras diferentes.

Quando você trabalha com VMs e outros componentes de infraestrutura, considere usar um balanceador de carga ou firewall para endereçamento IP estático de entrada e saída. Considere usar o Gateway nat do Azure para controlar o endereço IP do tráfego de saída. Para obter mais informações, consulte considerações do Gateway NAT do Azure parade multilocatário.

Quando você trabalha com serviços de plataforma, o serviço específico que você usa determina como você pode controlar endereços IP. Talvez seja necessário configurar o recurso de uma maneira específica, como implantar um recurso como uma VM em uma rede virtual e, em seguida, usar um gateway ou firewall nat. Ou você pode solicitar o conjunto atual de endereços IP que o serviço usa para tráfego de saída. Por exemplo, o Serviço de Aplicativo fornece uma API e uma interface da Web para obter os endereços IP de saída atuais para seu aplicativo.

Agentes

Para permitir que seus locatários recebam mensagens iniciadas pela sua solução ou acessem dados nas redes de seus locatários, considere fornecer um agente, às vezes chamado de gateway local, que eles implantam em sua rede. Essa abordagem pode funcionar se as redes dos locatários estiverem no Azure, em outro provedor de nuvem ou localmente.

O agente inicia uma conexão de saída com um ponto de extremidade que você especifica e controla. Mantém as conexões de longa duração vivas ou vota intermitentemente. Considere usar a Retransmissão do Azure para estabelecer e gerenciar conexões do seu agente com o seu serviço. Quando o agente estabelece a conexão, ele autentica e inclui algumas informações sobre o identificador de locatário para que o seu serviço possa mapear a conexão com o locatário correto.

Normalmente, os agentes simplificam a configuração de segurança para seus locatários. Abrir portas de entrada pode ser complexo e arriscado, especialmente em um ambiente local. Um agente elimina a necessidade de os locatários assumirem esse risco.

Os serviços da Microsoft que fornecem agentes para conectividade com redes de locatários incluem os seguintes exemplos:

O serviço link privado fornece conectividade privada do ambiente do Azure de um locatário para sua solução. Os locatários também podem usar o serviço de Link Privado com sua própria rede virtual para acessar seu serviço de um ambiente local. O Azure roteia com segurança o tráfego para o serviço usando endereços IP privados.

Para obter mais informações, consulte Multilocatário e Link Privado.

Nomes de domínio, subdomínios e TLS

Quando você trabalha com nomes de domínio e TLS (Transport Layer Security) em uma solução multilocatário, examine as principais considerações.

Padrões de descarregamento de gateway e roteamento de gateway

O padrão de Roteamento de Gateway e o padrão de Descarregamento de Gateway envolvem a implantação de um proxy reverso de Camada 7 ou gateway. Os gateways fornecem serviços principais para um aplicativo multilocatário, incluindo os seguintes recursos:

  • Roteamento de solicitações para back-ends ou carimbos de implantação específicos do locatário
  • Manipulando nomes de domínio específicos do locatário e certificados TLS
  • Inspecionando solicitações de ameaças à segurança usando um WAF (firewall de aplicativo Web)
  • Respostas de cache para melhorar o desempenho

O Azure fornece vários serviços que podem atingir algumas ou todas essas metas, incluindo o Azure Front Door, o Gateway de Aplicativo e o Gerenciamento de API do Azure. Você também pode implantar sua própria solução personalizada usando software como NGINX ou HAProxy.

Se você planeja implantar um gateway para sua solução, uma boa prática é primeiro criar um protótipo completo. Inclua todos os recursos necessários e verifique se os componentes do aplicativo funcionam conforme o esperado. Você também deve entender como o componente do gateway é dimensionado para dar suporte ao seu tráfego e ao crescimento do locatário.

Padrão de Hospedagem de Conteúdo Estático

O padrão de Hospedagem de Conteúdo Estático atende ao conteúdo da Web de um serviço de armazenamento nativo de nuvem e usa uma rede de distribuição de conteúdo para armazenar o conteúdo em cache.

Você pode usar o Azure Front Door ou outra rede de distribuição de conteúdo para os componentes estáticos da solução, como aplicativos JavaScript de página única e para conteúdo estático, como arquivos de imagem e documentos.

Dependendo do design da solução, você também pode armazenar em cache arquivos ou dados específicos do locatário em uma rede de distribuição de conteúdo, como respostas de API formatada por JSON. Essa prática pode ajudá-lo a melhorar o desempenho e a escalabilidade da solução. Verifique se os dados específicos do locatário permanecem isolados o suficiente para evitar vazamento de dados entre locatários. Considere como você planeja limpar o conteúdo específico do locatário do cache, por exemplo, quando os dados são atualizados ou uma nova versão do aplicativo é implantada. Ao incluir o identificador de locatário no caminho da URL, você pode controlar se limpa um arquivo específico, todos os arquivos relacionados a um locatário específico ou todos os arquivos para todos os locatários.

Antipadrões a serem evitados

Falha ao planejar a conectividade de rede virtual

A implantação de recursos em redes virtuais oferece um controle significativo sobre como o tráfego flui por meio dos componentes da solução. Mas a integração de rede virtual também apresenta mais complexidade, custo e outros fatores que você precisa considerar, especialmente para componentes paaS (plataforma como serviço).

Teste e planeje sua estratégia de rede para identificar quaisquer problemas antes de implementá-lo em um ambiente de produção.

Não planejar limites

O Azure impõe muitos limites que afetam os recursos de rede. Esses limites incluem limites de recursos do Azure e limites fundamentais de protocolo e plataforma. Por exemplo, ao criar uma solução multilocatário de alta escala em serviços de plataforma, como o Serviço de Aplicativo e o Azure Functions, talvez seja necessário considerar o número de conexões TCP (Protocolo de Controle de Transmissão) e portas SNAT (Conversão de Endereços de Rede de Origem). Ao trabalhar com VMs e balanceadores de carga, você também precisa considerar limitações para regras de saída e portas SNAT.

Sub-redes pequenas

Dimensione cada sub-rede para dar suporte ao número de recursos ou instâncias de recursos que você planeja implantar, especialmente à medida que você dimensiona. Ao trabalhar com recursos de PaaS, entenda como a configuração e a escala do recurso afetam o número de endereços IP necessários em sua sub-rede.

Segmentação de rede inadequada

Se sua solução exigir redes virtuais, considere como você configura a segmentação de rede para controlar o tráfego de entrada e saída (conhecido como tráfego norte-sul), bem como o tráfego dentro de sua solução (conhecido como tráfego leste-oeste). Decida se os locatários devem ter suas próprias redes virtuais ou se você deve implantar recursos compartilhados em redes virtuais compartilhadas. Alterar a abordagem pode ser difícil, portanto, considere cuidadosamente todos os requisitos antes de selecionar uma abordagem que funcione para suas metas futuras de crescimento.

Depender apenas de controles de segurança de camada de rede

Em soluções modernas, você deve combinar a segurança da camada de rede com outros controles de segurança. Não dependa apenas de firewalls ou segmentação de rede. Essa abordagem às vezes é chamada de rede de confiança zero. Use controles baseados em identidade para verificar o cliente, o chamador ou o usuário em cada camada da solução. Considere o uso de serviços que permitem adicionar camadas extras de proteção. Suas opções dependem dos serviços do Azure que você usa. No AKS, considere usar uma malha de serviço para autenticação mútua do TLS e aplicar políticas de rede para controlar o tráfego leste-oeste. No Serviço de Aplicativo, considere usar o suporte interno para restrições de autenticação e autorização e restrições de acesso.

Reescrever cabeçalhos de host sem teste

Ao usar o padrão de descarregamento de gateway, você pode considerar reescrever o cabeçalho Host de solicitações HTTP. Essa prática pode simplificar a configuração do serviço de aplicativo Web de back-end descarregando o domínio personalizado e o gerenciamento de TLS para o gateway.

Mas Host as reescritas de cabeçalho podem causar problemas para alguns serviços de back-end. Se o aplicativo emitir redirecionamentos HTTP ou cookies, a incompatibilidade em nomes de host poderá interromper a funcionalidade do aplicativo. Em particular, esse problema pode ocorrer quando você usa serviços de back-end executados em infraestrutura multilocatário, como o Serviço de Aplicativo e o Azure Functions. Para obter mais informações, consulte as práticas recomendadas de preservação do nome do host.

Teste o comportamento do aplicativo com a configuração de gateway que você planeja usar.

Colaboradores

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Autor principal:

  • John Downs | Principal Engenheiro de Software, Padrões do Azure & Práticas

Outros colaboradores:

Para ver perfis não públicos no LinkedIn, entre no LinkedIn.

  • Last updated on