Compartilhar via

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

  • Artigo

Todas as soluções implantadas no Azure exigem algum tipo de rede. Dependendo do design da solução e da carga de trabalho, as maneiras pelas quais você interage com os serviços de rede do Azure podem ser diferentes. Neste artigo, fornecemos considerações e diretrizes para os aspectos de rede de soluções multilocatário no Azure. Incluímos informações sobre os componentes de rede de nível inferior, como redes virtuais, até abordagens de nível superior e de camada de aplicativo.

Observação

O Azure em si é um ambiente multilocatário e os componentes de rede do Azure foram projetados para uso multilocatário. Embora não seja necessário entender os detalhes para criar sua solução, você 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 preocupações que você tem para seus componentes de rede serão diferentes, dependendo da categoria de serviços que você usa.

Serviços de infraestrutura

Sempre que você usa serviços de infraestrutura, como máquinas virtuais ou Serviço de Kubernetes do Azure, você precisa considerar e projetar as redes virtuais, ou VNets, que sustentam a conectividade de seus serviços. Você também precisa considerar as outras camadas de segurança e isolamento que você precisa incorporar em seu design. Evite depender exclusivamente de controles de camada de rede.

Serviços de plataforma

Se você usar os serviços de plataforma do Azure, como Serviço de Aplicativo, Azure Cosmos DB ou Banco de Dados SQL do Azure, a arquitetura específica usada determinará os serviços de rede necessários.

Se você precisar isolar seus serviços de plataforma da Internet, precisará usar uma VNet. Dependendo dos serviços específicos usados, você pode trabalhar com pontos de extremidade privados ou recursos integrados à VNet, como o Gateway de Aplicativo. No entanto, você também pode optar por disponibilizar seus serviços de plataforma por meio de seus endereços IP públicos e usar as proteções dos próprios serviços, como firewalls e controles de identidade. Nessas situações, talvez você não precise de uma VNet.

A decisão de usar VNets para serviços de plataforma é baseada em muitos requisitos, incluindo os seguintes fatores:

  • Requisitos de conformidade: talvez seja necessário atender a um padrão de conformidade específico. Alguns padrões exigem que o ambiente do Azure seja configurado de maneiras específicas.
  • Requisitos dos seus locatários: mesmo que sua própria organização não tenha requisitos específicos para isolamento ou controles de camada de rede, talvez seus locatários tenham. Verifique se você tem uma compreensão clara de como seus locatários acessarão sua solução e se eles têm alguma suposição sobre o design de rede dela.
  • Complexidade: pode ser mais complexo entender e trabalhar com redes virtuais. Verifique se sua equipe tem uma compreensão clara dos princípios envolvidos, ou você provavelmente implantará um ambiente inseguro.

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

Dimensionar sub-redes

Quando você precisa implantar uma VNet, é importante considerar cuidadosamente o dimensionamento e o espaço de endereço de toda a VNet e das sub-redes dentro da VNet.

Verifique se você tem uma compreensão clara de como implantará seus recursos do Azure em VNets e o número de endereços IP que cada recurso consome. Se você implantar nós de computação específicos do locatário, servidores de banco de dados ou outros recursos, certifique-se de criar sub-redes grandes o suficiente para o crescimento esperado do locatário e para dimensionamento automático horizontal de recursos.

Da mesma forma, quando você trabalha com serviços gerenciados, é importante entender como os endereços IP são consumidos. Por exemplo, quando você usa Serviço de Kubernetes do Azure com a CNI (Interface de Rede de Contêiner do Azure), o número de endereços IP consumidos de uma sub-rede será baseado em fatores como o número de nós, o modo como você dimensiona horizontalmente e o processo de implantação de serviço que você usa. Quando você usa o Serviço de Aplicativo do Azure e o Azure Functions com a integração de VNet, 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 acessarão seus serviços por meio da Internet ou por meio de endereços IP privados.

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

Se você precisar habilitar a conectividade com 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. Geralmente, esta abordagem só faz sentido quando existe um número de locatários e quando você implementa VNets 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ê precisará invocar um webhook fornecido por um cliente ou você precisa enviar mensagens em tempo real para um locatário?

Se você precisar enviar dados para 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 usados, talvez seja necessário implantar um Gateway da NAT, um firewall ou um balanceador de carga.
  • Implante um agente para habilitar a conectividade entre os serviços hospedados no Azure e as redes dos clientes, independentemente de onde eles estejam localizados.
  • Para mensagens unidirecionais, considere usar um serviço como a Grade de Eventos do Azure, possivelmente em conjunto com os domínios de eventos.

Abordagens e padrões a serem considerados

Nesta seção, descrevemos algumas das principais abordagens de rede que você pode considerar em uma solução multilocatário. Começamos descrevendo as abordagens de nível inferior para componentes de rede principais e, em seguida, seguimos com as abordagens que você pode considerar para HTTP e outras preocupações relacionadas à camada de aplicativo.

VNets específicas a um locatário com endereços IP selecionados pelo provedor de serviços

Em algumas situações, você precisa executar recursos dedicados conectados à VNet no Azure em nome de um locatário. Por exemplo, você pode executar uma máquina virtual para cada locatário ou talvez precise usar pontos de extremidade privados para acessar bancos de dados específicos a um locatário.

Considere implantar uma VNet para cada locatário usando um espaço de endereços IP que você controla. Essa abordagem permite que você emparelhe as VNets para seus propósitos, como se você precisasse estabelecer uma topologia hub e spoke para controlar centralmente a entrada e a saída do tráfego.

No entanto, os endereços IP selecionados pelo provedor de serviços não serão apropriados se os locatários precisarem se conectar diretamente à VNet que você criou, por exemplo, usando o emparelhamento de VNet. É provável que o espaço de endereço selecionado seja incompatível com os espaços de endereço deles.

VNets específicas a um locatário com endereços IP selecionados pelo locatário

Se os locatários precisarem emparelhar as próprias VNets com a VNet gerenciada por você em nome deles, considere implantar VNets específicas a um locatário com um espaço de endereços IP selecionado pelo locatário. Esse sistema permite que cada locatário garanta que os intervalos de endereços IP na VNet do sistema não se sobreponham às suas próprias VNets. Usando intervalos de endereços IP não sobrepostos, eles podem garantir que suas redes sejam compatíveis com o emparelhamento.

No entanto, essa abordagem significa que é improvável que você possa emparelhar as VNets de seus locatários ou adotar uma topologia hub e spoke, porque é provável que haja intervalos de endereços IP sobrepostos entre VNets de locatários diferentes.

Topologia hub-spoke

A topologia de VNet de hub e spoke permite que você emparelhe uma VNet de hub centralizada com várias VNets spoke. Você pode controlar centralmente a entrada e a saída de tráfego para suas VNets e controlar se os recursos na VNet de cada spoke podem ou não se comunicar entre si. Cada VNet spoke também pode acessar componentes compartilhados, como Firewall do Azure, e pode ser capaz de usar serviços como a Proteção contra DDoS do Azure.

Ao usar uma topologia hub e spoke, planeje os limites, como o número máximo de VNets emparelhadas, e verifique se você não usa espaços de endereço sobrepostos para a VNet de cada locatário.

A topologia hub e spoke pode ser útil quando você implanta VNets específicas do locatário com endereços IP selecionados. A VNet de cada locatário se torna um spoke e pode compartilhar os seus recursos comuns na VNet que é o hub. Você também pode usar a topologia hub e spoke ao dimensionar recursos compartilhados em várias VNets para fins de escala ou ao usar o padrão de Selos de Implantação.

Dica

Se sua solução for executada em várias regiões geográficas, geralmente é uma boa prática implantar hubs separados e recursos de hub em cada região. Embora essa prática incorra em um custo de recurso mais alto, ela evita o tráfego passando por várias regiões do Azure desnecessariamente, o que pode aumentar a latência de solicitações e incorrer em encargos de emparelhamento global.

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 máquinas virtuais 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 da NAT para controlar o endereço IP do tráfego de saída. Para obter mais informações sobre a utilização do Gateway da NAT numa solução multi-inquilino, consulte Considerações sobre o Gateway da NAT do Azure para multilocatário.

Quando você trabalha com serviços de plataforma, o serviço específico que você usa determina se e como você pode controlar endereços IP. Talvez seja necessário configurar o recurso de maneira específica, como implantando o recurso como uma máquina virtual em uma VNet e então usando um Gateway da NAT ou firewall. Alternativamente, 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

Se você precisar permitir que seus locatários recebam mensagens iniciadas pela sua solução ou se precisar acessar dados existentes nas redes dos próprios locatários, considere fornecer um agente (às vezes chamado de gateway local) que eles possam implantar nas próprias redes. Essa abordagem pode funcionar se as redes de seus locatários estiverem no Azure, em outro provedor de nuvem ou implantadas localmente.

O agente inicia uma conexão de saída com um ponto de extremidade que você especifica e controla e mantém as conexões de execução prolongada ativas ou sonda-as 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 evita a necessidade de locatários assumirem esse risco.

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

O Serviço de Link Privado do Azure fornece conectividade privada do ambiente do Azure de um locatário para a sua solução. Os locatários também podem usar o serviço de Link Privado com a VNet deles próprios 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 sobre Link Privado e multilocatário, consulte Multilocatário e Link Privado do Azure.

Nomes de domínio, subdomínios e TLS

Quando você trabalha com nomes de domínio e protocolo TLS em uma solução multilocatário, há várias considerações a fazer. Examine as considerações sobre nomes de domínio e multilocatário.

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 ou gateway da camada 7. Os gateways são úteis para fornecer serviços principais para um aplicativo multilocatário, incluindo as seguintes funcionalidades:

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

O Azure fornece vários serviços que podem ser usados para atingir algumas ou todas essas metas, incluindo o Azure Front Door, o Gateway de Aplicativo do Azure e o Gerenciamento de API do Azure. Você também pode implantar uma solução personalizada própria 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 que inclua todos os recursos necessários e verificar se os componentes do aplicativo continuam funcionando conforme o esperado. Você também deve entender como o componente do gateway será 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 envolve o fornecimento de conteúdo da Web de um serviço de armazenamento nativo de nuvem e o uso de uma CDN (rede de distribuição de conteúdo) para armazenar o conteúdo em cache.

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

Dependendo de como sua solução for projetada, você também poderá armazenar em cache arquivos ou dados específicos a um locatário em uma CDN, como respostas de API em formato JSON. Essa prática pode ajudar você a aprimorar o desempenho e a escalabilidade da solução, mas é importante considerar se os dados específicos a um locatário estão isolados o suficiente para evitar o 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 VNets

Ao implantar recursos em VNets, você tem muito controle sobre como o tráfego flui pelos componentes da sua solução. No entanto, a integração de VNet também introduz complexidade, custo e outros fatores adicionais que você precisa considerar. Esse efeito é especialmente verdadeiro com componentes de plataforma como serviço (PaaS)

É importante testar e planejar sua estratégia de rede, para que você descubra eventuais problemas antes de implementá-la em um ambiente de produção.

Não planejar limites

O Azure impõe uma série de limites que afetam os recursos de rede. Esses limites incluem limites de recursos do Azure e limites fundamentais de protocolo e plataforma. Por exemplo, quando você cria uma solução multilocatário de grande escala em serviços de plataforma, como o Serviço de Aplicativo do Azure e o Azure Functions, talvez seja necessário considerar o número de conexões TCP e portas SNAT. Ao trabalhar com máquinas virtuais e balanceadores de carga, você também precisa considerar limitações para regras de saída e para portas SNAT.

Sub-redes pequenas

É importante considerar o tamanho de cada sub-rede para permitir o número de recursos ou instâncias de recursos que você implantará, especialmente conforme dimensiona. Ao trabalhar com recursos de PaaS (plataforma como serviço), verifique se você entende como a configuração e a escala do seu recurso afetarão o número de endereços IP necessários em na sub-rede dele.

Segmentação de rede inadequada

Se sua solução exigir redes virtuais, considere como você configura a segmentação de rede para permitir que você controle os fluxos de tráfego de entrada e saída (norte-sul) e os fluxos em sua solução (leste-oeste). Decida se os locatários devem ter as próprias VNets ou se você implantará recursos compartilhados em VNets compartilhadas. Alterar a abordagem pode ser difícil, portanto, certifique-se de considerar todos os seus requisitos e selecione uma abordagem que funcionará para suas futuras metas de crescimento.

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

Nas redes modernas, é importante combinar a segurança da camada de rede com outros controles de segurança e você não deve depender apenas de firewalls ou segmentação de rede. Às vezes, isso é chamado 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 sua solução. Considere o uso de serviços que permitem adicionar outras camadas de proteção. As opções disponíveis dependem dos serviços do Azure que você usa. No AKS, considere usar uma malha de serviço para autenticação TLS mútua e 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.

No entanto, as regravações do cabeçalho Host 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 surgir quando você usa serviços de back-end que são multilocatários, como o Serviço de Aplicativo do Azure, o Azure Functions e o Aplicativos Spring do Azure. Para obter mais informações, confira a melhor prática de preservação do nome do host.

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

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

Outros colaboradores:

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

Próximas etapas