Partilhar via

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

Todas as soluções implantadas no Azure exigem alguma forma de rede. A forma como 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 orientações para os aspetos de rede de soluções multilocatárias 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 projetar sua própria solução, mas 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 considerações sobre o componente de rede dependem da categoria de serviços que você usa.

Serviços de infraestrutura

Ao usar serviços de infraestrutura, como máquinas virtuais (VMs) ou Serviço Kubernetes do Azure (AKS), considere e projete as redes virtuais que sustentam a conectividade dos 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 os serviços da plataforma 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 da sua plataforma da internet, use uma rede virtual. Dependendo dos serviços que você usa, 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 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 não seja necessário implantar e configurar sua própria rede virtual.

Decida se deseja 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 arquitetônicas para governança e conformidade em soluções multilocatário.

  • Requisitos dos seus inquilinos: Mesmo que sua organização não tenha requisitos definidos para isolamento ou controles da camada de rede, seus locatários podem. 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.

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

Dimensione suas sub-redes

Quando precisar implantar uma rede virtual, considere cuidadosamente o tamanho e o espaço de endereçamento 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 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, crie sub-redes grandes o suficiente para o crescimento esperado do locatário e o dimensionamento automático horizontal dos recursos.

Da mesma forma, ao trabalhar 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 do plano.

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

Acesso público ou privado

Considere se os seus inquilinos precisam de aceder aos seus serviços através da Internet ou através de endereços IP privados.

Para proteger o seu serviço para acesso (público) baseado na Internet, utilize regras de firewall, listagem e negação de endereços IP, segredos e chaves partilhados e controlos 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 usar o Azure ExpressRoute ou o Gateway de VPN do Azure para habilitar o acesso privado à sua solução. Normalmente, esta abordagem só faz sentido quando tem poucos inquilinos e quando implementa redes virtuais dedicadas para cada inquilino.

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ê 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 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 usar a NAT (conversão de endereços de rede) implantando o Azure NAT Gateway, 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 evento, para mensagens unidirecionais.

Abordagens e padrões a considerar

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 da 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 seus próprios propósitos, como estabelecer uma topologia hub-and-spoke para controlar centralmente a entrada e saída de 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ê criar, como usando emparelhamento de rede virtual. O espaço de endereço selecionado provavelmente entra em conflito com os 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 do 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 seu 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, é provável que selecionem intervalos que se sobrepõem uns aos outros.

Topologia de hub e raio

A topologia de rede virtual hub-and-spoke permite emparelhar uma rede virtual de hub centralizado com várias redes virtuais faladas . Você pode controlar centralmente a entrada e saída de tráfego para suas redes virtuais e controlar se os recursos na rede virtual de cada fala podem se comunicar uns com os outros. 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.

Ao usar 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 o uso da 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 torna-se 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 ao usar o padrão Carimbos de Implantação.

Sugestão

Se sua solução abrange várias regiões geográficas, implante hubs e recursos de hub separados em cada região para evitar que o tráfego cruze 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 as taxas 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 VMs 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 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 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 como você pode controlar endereços IP. Talvez seja necessário configurar o recurso de uma maneira específica, como implantando um recurso como uma VM em uma rede virtual e, em seguida, 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

Para permitir que seus locatários recebam mensagens iniciadas por 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 suas redes. Esta abordagem pode funcionar quer as redes dos seus inquilinos estejam no Azure, noutro fornecedor de nuvem ou no local.

O agente inicia uma conexão de saída com um ponto de extremidade que você especifica e controla. Ou mantém vivas as ligações de longa duração ou vota 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 elimina a necessidade de os inquilinos 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 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 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 Multilocação e link privado.

Nomes de domínio, subdomínios e TLS

Ao trabalhar com nomes de domínio e TLS (Transport Layer Security) em uma solução multilocatário, analise as principais considerações.

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 fornecem 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
  • Inspecionando 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 atingir alguns ou todos esses objetivos, incluindo o Azure Front Door, o 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. 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 de gateway é 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 serve conteúdo da Web de um serviço de armazenamento nativo da nuvem e usa uma rede de entrega de conteúdo para armazenar o conteúdo em cache.

Você pode usar o Azure Front Door ou outra rede de entrega de conteúdo 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 do design da sua solução, você também poderá armazenar em cache arquivos ou dados específicos do locatário em uma rede de entrega de conteúdo, como respostas de API formatadas em JSON. Essa prática pode ajudá-lo a melhorar o desempenho e a escalabilidade de sua solução. Certifique-se de que os dados específicos do locatário permaneçam 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

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

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

Não fazer o planeamento dos 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, quando você cria uma solução multilocatária 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 (Transmission Control Protocol) e as portas SNAT (Conversão de Endereço 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 dimensiona. Ao trabalhar com recursos 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. Mudar a abordagem pode ser difícil, portanto, considere cuidadosamente todos os requisitos antes de selecionar 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, você deve combinar a segurança da camada de rede com outros controles de segurança. Não confie apenas em firewalls ou segmentação de rede. Esta abordagem é por vezes chamada 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 extras de proteção. Suas opções 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 aplique 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 utilizar o padrão de transferência de gateway, poderá ponderar a reescrita do Host cabeçalho de solicitações HTTP. Essa prática pode simplificar a configuração do seu serviço de aplicativo Web back-end, descarregando o domínio personalizado e o gerenciamento TLS para o gateway.

Mas Host as 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 ocorrer quando você usa serviços back-end que são executados em infraestrutura multilocatário, como o Serviço de Aplicativo e o Azure Functions. Para obter mais informações, consulte Práticas recomendadas de preservação de nome de host.

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

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Autor principal:

  • John Downs | Engenheiro de Software Principal, Azure Patterns & Practices

Outros contribuidores:

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

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.

  • Last updated on