Share via

Abordagens arquitetônicas para redes em soluções multilocatárias

  • 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 como você interage com os serviços de rede do Azure podem ser diferentes. Neste artigo, fornecemos considerações e orientações para os aspetos de rede de soluções multilocatárias 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 nível de aplicativo.

Nota

O próprio Azure é um ambiente multilocatário e os componentes de rede do Azure são projetados para multilocação. Embora não seja necessário entender os detalhes para projetar sua própria solução, você pode saber mais sobre como o Azure isola seu tráfego de rede virtual do tráfego de outros clientes.

Principais considerações e requisitos

Serviços de infraestrutura e plataforma

As preocupações que você tem com 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 o Serviço Kubernetes do Azure, 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 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 os serviços da plataforma da internet, precisará usar uma rede virtual. Dependendo dos serviços específicos que você usa, você pode trabalhar com pontos de extremidade privados ou recursos integrados à rede virtual, como o Application Gateway. No entanto, você também pode optar por disponibilizar os serviços da sua 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 de uma rede virtual.

A decisão de usar ou não redes virtuais 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 seu ambiente do Azure seja configurado de maneiras específicas.
  • Requisitos dos seus inquilinos: mesmo que a sua própria organização não tenha requisitos específicos para isolamento ou controlos da camada de rede, os seus inquilinos podem. Certifique-se de ter uma compreensão clara de como seus locatários acessarão sua solução e se eles têm alguma suposição sobre seu design de rede.
  • Complexidade: Pode ser mais complexo compreender e trabalhar com redes virtuais. Certifique-se de que sua equipe tenha uma compreensão clara dos princípios envolvidos, ou você provavelmente implantará um ambiente inseguro.

Certifique-se de entender as implicações do uso de redes privadas.

Dimensionamento de sub-redes

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

Certifique-se de ter uma compreensão clara de como você implantará seus recursos do Azure em redes virtuais 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 o 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 o Serviço Kubernetes do Azure com a Interface de Rede de Contêiner do Azure (Azure CNI), o número de endereços IP consumidos de uma sub-rede será baseado em fatores como o número de nós, 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 integração VNet, o número de endereços IP consumidos é baseado no número de instâncias do plano.

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

Acesso público ou privado

Considere se os seus inquilinos irão aceder aos seus serviços através da Internet ou através 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ços 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 usar o Azure ExpressRoute ou o Gateway de VPN do Azure para habilitar o acesso privado à sua solução. Só recomendamos que você use essa abordagem quando tiver um pequeno número de locatários e implante redes virtuais dedicadas para cada locatário.

Acesso aos pontos finais dos inquilinos

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 precisará enviar mensagens em tempo real para um locatário?

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

  • Inicie conexões de sua solução com os pontos de extremidade dos locatários através da Internet. Considere se as conexões devem ser originadas de um endereço IP estático. Dependendo dos serviços do Azure que você usa, talvez seja necessário implantar um Gateway NAT, firewall ou 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 onde eles estão localizados.
  • Para mensagens unidirecionais, considere usar um serviço como a Grade de Eventos do Azure, com ou sem domínios de evento.

Abordagens e padrões a considerar

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 os principais componentes de rede e, em seguida, seguimos com as abordagens que você pode considerar para HTTP e outras preocupações da camada de aplicativo.

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

Em algumas situações, você precisa executar recursos dedicados conectados à rede virtual 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 do locatário.

Considere implantar uma VNet 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 seus próprios propósitos, como se você precisar estabelecer uma topologia de hub e spoke para controlar centralmente a entrada e saída de tráfego.

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

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

Se os locatários precisarem emparelhar suas próprias VNets com a VNet que você gerencia em seu nome, considere implantar VNets específicas do locatário com um espaço de endereço IP selecionado pelo locatário. Esse sistema permite que cada locatário garanta que os intervalos de endereços IP na VNet do seu 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 para emparelhamento.

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

Topologia hub-and-spoke

A topologia de VNet hub e spoke permite emparelhar uma VNet de hub centralizada com várias VNets de raio. Você pode controlar centralmente a entrada e saída de tráfego para suas redes virtuais e controlar se os recursos na VNet de cada fala podem se comunicar entre si. Cada VNet 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.

Ao usar uma topologia de hub e spoke, certifique-se de planejar em torno de limites, como o número máximo de VNets emparelhadas, e certifique-se de não usar espaços de endereço sobrepostos para a VNet de cada locatário.

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

Gorjeta

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

Endereços IP estáticos

Considere se os locatários precisam que seu serviço use 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.

Ao trabalhar com máquinas virtuais e outros componentes de infraestrutura, considere o uso de um balanceador de carga ou firewall para endereçamento IP estático de entrada e saída. Considere o uso do NAT Gateway para controlar o endereço IP do tráfego de saída. Para obter mais informações sobre como usar o Gateway NAT em uma solução multilocatário, consulte Considerações sobre o Gateway NAT do Azure para multilocação.

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 uma maneira específica, como implantando o recurso em uma VNet e usando um gateway NAT ou firewall. Ou, você pode solicitar o conjunto atual de endereços IP que o serviço usa para o tráfego de saída. Por exemplo, o Serviço de Aplicativo fornece uma API e uma interface Web para obter os endereços IP de saída atuais para seu aplicativo.

Agentes

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

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 longa execução ativas ou sonda intermitentemente. Considere usar o Azure Relay para estabelecer e gerenciar conexões do seu agente para 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 seu serviço possa mapear a conexão para o locatário correto.

Os agentes normalmente simplificam a configuração de segurança para seus locatários. Pode ser complexo e arriscado abrir portas de entrada, especialmente em um ambiente local. Um agente evita a necessidade de os inquilinos assumirem esse risco.

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

O serviço Azure Private Link 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 Private Link com sua própria VNet, 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 Private Link e multilocação, consulte Multilocação e Azure Private Link.

Nomes de domínio, subdomínios e TLS

Quando você trabalha com nomes de domínio e segurança de camada de transporte (TLS) em uma solução multilocatário, há várias considerações. Analise as considerações para multilocação e nomes de domínio.

Padrões de roteamento e descarregamento 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 de camada 7. Os gateways são úteis para fornecer serviços principais para um aplicativo multilocatário, incluindo os seguintes recursos:

  • Roteamento de solicitações para back-ends específicos do locatário ou carimbos de implantação.
  • Tratamento de nomes de domínio específicos do locatário e certificados TLS.
  • Inspecionar solicitações de ameaças à segurança, usando um firewall de aplicativo da Web (WAF).
  • Armazenamento em cache de respostas para melhorar 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 Azure Application Gateway e o Azure API Management. 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 que inclua todos os recursos necessários e verificar se os componentes do aplicativo continuam a funcionar como esperado. Você também deve entender como o componente de gateway será dimensionado para dar suporte ao tráfego e ao crescimento de locatários.

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

O padrão de hospedagem de conteúdo estático envolve o fornecimento de conteúdo da Web a partir de um serviço de armazenamento nativo da nuvem e o uso de uma rede de distribuição de conteúdo (CDN) 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 foi projetada, você também poderá armazenar em cache arquivos ou dados específicos do locatário em uma CDN, como respostas de API formatadas em JSON. Essa prática pode ajudá-lo a melhorar o desempenho e a escalabilidade de sua solução, mas é importante considerar se os dados específicos do 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, como 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 de todos os locatários.

Antipadrões a evitar

Falha ao planejar a conectividade de rede virtual

Ao implantar recursos em redes virtuais, você tem um grande controle sobre como o tráfego flui através dos 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 quaisquer problemas antes de implementá-la em um ambiente de produção.

Não planear limites

O Azure impõe vários 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ária de alta 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 à medida que dimensiona. Ao trabalhar com recursos de plataforma como serviço (PaaS), certifique-se de entender como a configuração e a escala do recurso afetarão o número de endereços IP necessários em sua sub-rede.

Segmentação de rede inadequada

Se sua solução requer 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 dentro de sua solução (leste-oeste). Decida se os locatários devem ter suas próprias VNets ou se você implantará recursos compartilhados em VNets compartilhadas. Mudar a abordagem pode ser difícil, portanto, certifique-se de considerar todos os seus requisitos e, em seguida, selecione uma abordagem que funcione para suas metas de crescimento futuras.

Confiando apenas em controles de segurança da camada de rede

Em soluções modernas, é importante combinar a segurança da camada de rede com outros controles de segurança, e você não deve confiar apenas em firewalls ou segmentação de rede. Isso às vezes é chamado de rede de confiança zero. Use controles baseados em identidade para verificar o cliente, chamador ou usuário em cada camada da sua solução. Considere o uso de serviços que permitem adicionar camadas adicionais de proteção. As opções disponíveis dependem dos serviços do Azure que você usa. No AKS, considere o uso de 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 autenticação, autorização e restrições de acesso.

Reescrevendo cabeçalhos de host sem testar

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

No entanto, Host regravações de cabeçalho podem causar problemas para alguns serviços de back-end. Se o seu aplicativo emitir redirecionamentos HTTP ou cookies, a incompatibilidade nos nomes de host pode interromper a funcionalidade do aplicativo. Em particular, esse problema pode surgir quando você usa serviços de back-end que são multilocatário, como o Serviço de Aplicativo do Azure, o Azure Functions e o Azure Spring Apps. Para obter mais informações, consulte a prática recomendada de preservação de nome de host.

Certifique-se de testar o comportamento do seu aplicativo com a configuração de gateway que você planeja usar.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

  • John Downs - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure

Outros contribuidores:

  • Arsen Vladimirskiy - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure
  • Joshua Waddell - Brasil | Engenheiro de Clientes Sênior, FastTrack for Azure

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

Próximos passos