Considerações sobre topologia de rede e conectividade para o acelerador de zona de aterrissagem do Integration Services
Este artigo fornece considerações de design e recomendações para topologia de rede e conectividade que você pode aplicar ao usar o acelerador de zona de aterrissagem do Azure Integration Services (AIS). O networking é fundamental para quase tudo em uma zona de pouso.
As considerações de topologia de rede e conectividade para essa arquitetura dependem dos requisitos das cargas de trabalho hospedadas e dos requisitos de segurança e conformidade da sua organização.
Considerações de design
Use uma topologia de rede baseada na WAN Virtual se sua organização:
Planeja implantar recursos em várias regiões do Azure e requer conectividade global entre redes virtuais nessas regiões do Azure e em vários locais locais.
Precisa integrar uma rede de filial de grande escala diretamente no Azure, seja por meio de uma implantação de WAN (SD-WAN) definida por software ou requer mais de 30 sites de filial para terminação IPsec nativa.
Você precisa de roteamento transitivo entre VPN e Rota Expressa, como filiais remotas conectadas via VPN Site a Site ou usuários remotos conectados via VPN Ponto a Site, exigem conectividade com um DC conectado à Rota Expressa, via Azure.
As organizações usam a WAN Virtual para atender aos requisitos de interconectividade em grande escala. A Microsoft gerencia esse serviço, que ajuda a reduzir a complexidade geral da rede e moderniza a rede da sua organização.
Use uma topologia de rede tradicional do Azure baseada em uma arquitetura hub-and-spoke se sua organização:
Planeja implantar recursos em apenas regiões selecionadas do Azure.
Não precisa de uma rede global e interconectada.
Tem poucos locais remotos ou filiais por região e precisa de menos de 30 túneis de segurança IP (IPsec).
Requer controle total da configuração ou requer configuração personalizada manual da sua rede do Azure.
Topologia de rede de referência
O diagrama de arquitetura a seguir mostra a arquitetura de referência para uma implantação corporativa do AIS:
Planejar o endereçamento IP
As implantações corporativas do AIS devem incluir o uso de pontos de extremidade privados e redes virtuais. As seguintes considerações de design devem ser levadas em conta ao planejar seu endereçamento IP:
Alguns serviços AIS requerem sub-redes dedicadas
Você pode designar uma determinada sub-rede t0 um determinado serviço para criar instâncias desse serviço dentro da sub-rede. Por exemplo, você pode designar uma sub-rede para planos de serviço de aplicativo para que possa adicionar outros aplicativos ao longo do tempo.
O Gateway de VPN do Azure pode conectar sites locais sobrepostos com espaços de endereço IP sobrepostos por meio de seu recurso NAT (conversão de endereços de rede).
DNS Personalizado
A maioria dos serviços AIS permite que os clientes usem seus próprios nomes DNS para pontos de extremidade públicos, usando seus próprios servidores DNS ou por meio da oferta de DNS do Azure. A configuração destes é feita com base em recurso a recurso, mas os recursos suportados estão listados abaixo:
O Gerenciamento de API suporta domínios personalizados.
Os Aplicativos de Função e os Aplicativos Lógicos oferecem suporte a domínios personalizados, quando hospedados por um Plano do Serviço de Aplicativo ou Ambiente do Serviço de Aplicativo.
As contas de armazenamento suportam domínios personalizados para pontos de extremidade de armazenamento de blob.
O Data Factory, o Service Bus e o Event Grid não suportam domínios personalizados.
DNS Privado
O DNS Privado do Azure fornece um serviço DNS confiável e seguro para sua rede virtual. O DNS Privado do Azure gerencia e resolve nomes de domínio na rede virtual sem a necessidade de configurar uma solução DNS personalizada.
Para resolver os registos de uma zona DNS privada a partir da sua rede virtual, tem de ligar a rede virtual à zona. As redes virtuais vinculadas têm acesso total e podem resolver todos os registros DNS publicados na zona privada.
Considerações de design
É importante configurar corretamente as configurações de DNS para resolver o endereço IP do ponto de extremidade privado para o nome de domínio totalmente qualificado (FQDN) de seus recursos.
Os serviços existentes do Microsoft Azure podem já ter uma configuração de DNS para um ponto de extremidade público. Essa configuração deve ser substituída para se conectar usando seu ponto de extremidade privado.
Criptografia e autenticação de certificado
Se o design da sua rede exigir criptografia de tráfego em trânsito e/ou autenticação baseada em certificado, talvez seja necessário considerar onde e como essa criptografia/autenticação é executada. Por exemplo, você precisa identificar qual serviço executa a terminação TLS.
Considerações de design
Seu design exige que o tráfego entre os serviços do Azure seja criptografado? Sua criptografia pode ser encerrada em uma Porta da Frente do Azure e, em seguida, não ser criptografada ao atravessar o backbone do Azure ou dentro de sua rede virtual?
Você precisará encerrar a criptografia em vários locais?
Você precisa lidar com a autenticação em vários locais ou ela pode ser executada uma vez para uma solicitação externa?
Recomendações de design
Se estiver usando um design hub-and-spoke corporativo, considere usar o Azure Front Door como seu ponto de entrada para solicitações baseadas na Internet.
Considere usar o Gateway de Aplicativo do Azure como o ponto de término para quaisquer solicitações externas baseadas em TLS ou Gerenciamento de API para autenticação de certificado e/ou terminação SSL.
Conectividade com recursos locais
Muitos cenários de integração empresarial exigem a conexão de seus sistemas locais ao Azure. É importante considerar os modelos recomendados para fornecer essa conectividade.
Considerações de design
O Azure ExpressRoute fornece conectividade privada dedicada aos recursos de Infraestrutura como Serviço (IaaS) e Plataforma como Serviço (PaaS) do Azure a partir de locais locais.
O Gateway de VPN do Azure fornece conectividade compartilhada Site a Site (S2S) pela Internet pública para recursos de rede virtual IaaS (Infraestrutura como Serviço) do Azure a partir de locais locais.
O Azure ExpressRoute e o Azure VPN Gateway têm capacidades, custos e desempenho diferentes.
O gateway de dados local (OPDG) ou as Conexões Híbridas do Azure podem ser usados onde a Rota Expressa ou o Gateway VPN não é prático – OPDG/Conexões Híbridas são exemplos de serviços de retransmissão, utilizando o Service Bus para fazer conexões de saída de sua rede local para receber solicitações do Azure, sem precisar abrir portas em seu firewall/rede externa.
O OPDG é limitado no número de solicitações por minuto que suporta (o limite de limitação), tem limites específicos de tamanho de dados e só funciona com recursos limitados do Azure (Aplicativos Lógicos, Power BI, Power Apps, Power Automate, Analysis Services).
As conexões híbridas funcionam com os Serviços de Aplicativos (Aplicativos de Função ou Aplicativos Web) e têm seus próprios limites de limitação e dimensionamento.
As Conexões Híbridas de Retransmissão do Azure são uma parte fundamental do Service Bus que permite retransmissões fora dos Serviços de Aplicativo ou OPDG.
Recomendações de design
Use o Azure ExpressRoute como o canal de conectividade principal para conectar uma rede local ao Azure.
Certifique-se de estar usando a SKU certa para a Rota Expressa e/ou Gateway VPN com base nos requisitos de largura de banda e desempenho.
Use o Gateway de VPN do Azure para conectar filiais ou locais remotos ao Azure.
Use OPDG e/ou Conexões Híbridas onde a Rota Expressa ou o Gateway VPN não podem ser usados, onde os limites de taxa de transferência não serão um problema e onde você está usando um recurso do Azure de suporte (por exemplo, Aplicativos Lógicos, Aplicativos de Função).
Conectividade com serviços AIS PaaS
Os serviços PaaS do Azure AIS normalmente são acessados por pontos de extremidade públicos. A plataforma Azure fornece recursos para proteger esses pontos de extremidade ou até mesmo torná-los totalmente privados.
A proteção desses pontos de extremidade pode ser alcançada usando pontos de extremidade privados.
Para bloquear todo o tráfego da Internet para um recurso de destino, use um ponto de extremidade privado.
Se você quiser proteger um subrecurso específico para seus recursos de rede virtual, use um ponto de extremidade privado.
Se quiser proteger uma conta de armazenamento específica para seus recursos de rede virtual, você pode usar um ponto de extremidade privado.
O Azure Private Link permite que você acesse os Serviços AIS do Azure (por exemplo, Service Bus e Gerenciamento de API) e os serviços de propriedade/parceiro de propriedade do cliente hospedados pelo Azure em um ponto de extremidade privado em sua rede virtual.
Ao usar o Private Link, o tráfego entre sua rede virtual e o serviço atravessa a rede de backbone da Microsoft, portanto, expor seu serviço à Internet pública não é mais necessário. Pode criar o seu próprio serviço de ligação privada na sua rede virtual e fornecê-lo aos seus clientes. A configuração e o consumo através do Azure Private Link são consistentes em todos os serviços de PaaS do Azure, de propriedade do cliente e de parceiros partilhados.
Considerações de design
A injeção de rede virtual fornece implementações privadas dedicadas para serviços suportados. O tráfego do plano de gerenciamento ainda flui através de endereços IP públicos.
O Azure Private Link fornece acesso dedicado usando endereços IP privados para instâncias de PaaS do Azure ou serviços personalizados por trás da camada Padrão do Azure Load Balancer.
Os clientes corporativos geralmente têm preocupações sobre pontos de extremidade públicos para serviços de PaaS que devem ser adequadamente mitigados.
Recomendações de design
Use a injeção de rede virtual para serviços do Azure com suporte para disponibilizá-los de dentro de sua rede virtual.
Os serviços PaaS do Azure injetados em uma rede virtual ainda executam operações de plano de gerenciamento usando endereços IP públicos específicos do serviço. A conectividade deve ser garantida para que o serviço funcione corretamente.
Aceda aos serviços PaaS do Azure a partir do local através da Rota Expressa com emparelhamento privado. Use a injeção de rede virtual para serviços dedicados do Azure ou o Azure Private Link para serviços compartilhados disponíveis do Azure.
Para aceder aos serviços PaaS do Azure a partir do local quando a injeção de rede virtual ou a ligação privada não estiverem disponíveis, utilize o ExpressRoute com o emparelhamento da Microsoft, que lhe permite evitar atravessar a Internet pública.
O acesso aos serviços PaaS do Azure a partir do local através da Rota Expressa com o emparelhamento da Microsoft não impede o acesso aos pontos de extremidade públicos do serviço PaaS. Você deve configurar e restringir isso separadamente, conforme necessário.
Não habilite pontos de extremidade de serviço de rede virtual por padrão em todas as sub-redes.
Desative o acesso público aos serviços de PaaS do AIS.
Projeto de rede para gerenciamento de API
Considerações de design
Decida se as APIs são acessíveis externamente, internamente ou um híbrido de ambos.
Decida se deseja usar o gateway de Gerenciamento de API interno como seu ponto de extremidade principal ou se deseja usar um serviço WAF (Web Application Firewall), como o Azure Application Gateway ou o Azure Front Door.
Decida se deve haver vários gateways implantados e como eles têm balanceamento de carga - por exemplo, usando o Application Gateway na frente do gateway de Gerenciamento de API.
Decida se a conectividade com ambientes locais ou multicloud é necessária.
Recomendações de design
Implante sua instância de Gerenciamento de API em uma rede virtual para permitir o acesso a serviços de back-end na rede.
Use o Application Gateway para acesso externo ao Gerenciamento de API quando a instância de Gerenciamento de API for implantada em uma VNet no modo interno.
Use um ponto de extremidade privado para sua instância de Gerenciamento de API para permitir que os clientes em sua rede privada acessem com segurança a instância pelo Azure Private Link.
Design de rede para contas de armazenamento
O Armazenamento do Azure é usado como a solução de armazenamento para Aplicativos Lógicos do Azure e Azure Functions.
Recomendações de design
Para obter o melhor desempenho, seu aplicativo lógico/aplicativo de função deve usar uma conta de armazenamento na mesma região, o que reduz a latência.
Use pontos de extremidade privados para contas de Armazenamento do Azure para permitir que clientes em uma rede virtual (VNet) acessem dados com segurança por meio de um Link Privado.
Diferentes pontos de extremidade privados devem ser criados para cada serviço de armazenamento de tabela, fila e blob.
Design de rede para ambientes do Serviço de Aplicativo
Um Ambiente de Serviço de Aplicativo (ASE) é um ambiente dedicado e isolado para executar aplicativos Web, aplicativos de função e Aplicativos Lógicos (Padrão). Ele é implantado em sua rede virtual e contém vários Planos do Serviço de Aplicativo, cada um dos quais é usado para hospedar seus serviços de aplicativo.
Considerações de design
Um ASE é implantado em uma única sub-rede dentro de sua rede virtual. Um ASE pode ser implantado usando um endereço IP virtual (VIP), permitindo que conexões externas usem um endereço IP publicamente visível, que pode ser adicionado a um registro DNS público.
Os aplicativos dentro de um ASE terão acesso a todos os outros recursos dentro da Rede Virtual, dependendo das regras de acesso à rede. O acesso a recursos em outras redes virtuais pode ser obtido usando o emparelhamento de Rede Virtual.
Os aplicativos dentro de um ASE não precisam ser configurados para pertencer a uma VNet – eles estão automaticamente dentro da VNet em virtude de serem implantados no ASE. Isso significa que, em vez de ter que configurar o acesso à rede por recurso, você pode configurá-lo uma vez no nível ASE.
Recomendações de design
- Use o ASE v3 sempre que possível, pois isso proporciona a maior quantidade de flexibilidade de rede, enquanto reduz a configuração necessária para recursos individuais dentro do ASE. O ASE v3 também suporta redundância de zona.
Design de rede para Planos do Serviço de Aplicativo
Os Serviços de Aplicativo em um ambiente multilocatário podem ser implantados com um ponto de extremidade privado ou público. Quando implantado com um ponto de extremidade privado, a exposição pública do Serviço de Aplicativo é removida. Se houver um requisito para que o ponto de extremidade privado do Serviço de Aplicativo também seja acessível pela Internet, considere o uso do App Gateway para expor o serviço de aplicativo.
Planeje suas sub-redes cuidadosamente para integração de VNet de saída, considerando o número de endereços IP necessários. A integração de VNet requer uma sub-rede dedicada. Ao planejar o tamanho da sub-rede, lembre-se de que o Azure reserva 5 endereços IP em cada sub-rede. Além disso, um endereço é usado da sub-rede de integração para cada instância do plano. Quando você dimensiona seu aplicativo para quatro instâncias, quatro endereços são usados. Quando você aumenta ou diminui de tamanho, o espaço de endereçamento necessário é dobrado por um curto período de tempo. Isso afeta as instâncias reais com suporte disponíveis em sua sub-rede.
Quando houver a necessidade de se conectar de um Serviço de Aplicativo a serviços locais, privados ou restritos a IP, considere que:
Ao ser executada no ambiente multilocatário, a chamada do Serviço de Aplicativo pode ser originada de uma ampla variedade de endereços IP e a integração de rede virtual pode ser necessária para atender aos seus requisitos de rede.
Serviços como o Gerenciamento de API (APIM) podem ser usados para fazer proxy de chamadas entre limites de rede e podem fornecer um IP estático, se necessário.
Recomendações de design
- Como os tamanhos das sub-redes não podem ser alterados após a atribuição, use uma sub-rede grande o suficiente para acomodar qualquer escala que seu aplicativo possa alcançar. Para evitar problemas com a capacidade da sub-rede, você deve usar um sufixo /26 (64 endereços) para integração VNet.
Design de rede para o Azure Data Factory
Considerações de design
Para conectar o Data Factory a uma fonte de dados localizada em sua rede local, ou talvez em um serviço do Azure que tenha sido configurado para bloquear o acesso de todos os serviços do Azure, a menos que eles sejam especificamente permitidos, você precisa considerar a integração do Data Factory com uma rede virtual que forneça acesso à rede para a fonte de dados de destino.
O Data Factory emprega ambientes separados chamados tempos de execução de integração. O tempo de execução padrão do Data Factory, o tempo de execução de integração do Azure, não está associado a uma VNet e, como tal, não pode ser usado para se conectar a fontes de dados protegidas com os firewalls mais restritivos. Considere qual desses tempos de execução melhor atende às suas necessidades.
As VNets gerenciadas levam algum tempo para serem iniciadas, enquanto os tempos de execução normais do Azure estão disponíveis quase instantaneamente. Isso é algo que você precisa ter em mente ao agendar seus pipelines e depurá-los.
Os tempos de execução do SSIS com um tempo de execução integrado à rede virtual levarão até 30 minutos para serem iniciados.
Os tempos de execução de integração auto-hospedados só podem executar a atividade de cópia, que copia dados de uma fonte para outra no estado em que se encontram. Se você quiser executar transformações nos dados, não poderá fazê-las usando os fluxos de dados do Data Factory.
Os Pontos de Extremidade Privados Gerenciados são pontos de extremidade privados criados na Rede Virtual Gerenciada do Azure Data Factory estabelecendo um link privado para recursos do Azure (geralmente fontes de dados para ADF). O Azure Data Factory gere estes pontos finais privados em seu nome.
Os pontos de extremidade privados só estão disponíveis para tempos de execução de integração auto-hospedados para se conectar ao Data Factory.
Design de rede para aplicativos lógicos (padrão) - aplicativos integrados de rede virtual
Considerações de design
O tráfego de entrada para seus aplicativos lógicos virá por meio de pontos de extremidade privados. Consulte as considerações sobre o tráfego de entrada por meio da documentação de pontos de extremidade privados ao planejar seu design de rede de aplicativos lógicos.
O tráfego de saída de seus aplicativos lógicos flui através da rede virtual. Consulte as considerações sobre o tráfego de saída por meio da documentação de integração de rede virtual ao planejar seu design de rede de aplicativos lógicos.
Design de rede para Service Bus
Considerações de design
Você está usando zonas DNS privadas ou seu próprio servidor DNS (com encaminhamento de DNS) para resolver para um recurso de link privado?
A Filtragem de IP e as VNets só são suportadas na camada Premium SKU para Service Bus. Se a camada Premium não for prática, considere o uso de tokens SAS como sua principal maneira de bloquear o acesso ao seu namespace.
Recomendações de design
O acesso à rede pública deve ser desativado usando a Filtragem IP, que se aplica a todos os protocolos suportados (por exemplo, AMQP e HTTPS).
O tráfego para esse namespace deve ser restrito apenas em pontos de extremidade privados, restringindo o acesso à rede pública (usando a Filtragem de IP).
Coloque seu ponto de extremidade privado em sua própria sub-rede dedicada reservada para o Service Bus.
Adicione um registro DNS usando a zona DNS privada para o ponto de extremidade privado. Habilite os serviços confiáveis no Azure para acessar seu namespace diretamente (ignorando assim o firewall) para evitar problemas com seu design de integração.
Design de rede para aplicativos funcionais
Considerações de design
- Você está usando zonas DNS privadas ou seu próprio servidor DNS (com encaminhamento de DNS) para resolver para um recurso de link privado?
Recomendações de design
O acesso à rede pública deve ser desativado.
O tráfego para esse namespace deve ser restrito apenas em pontos de extremidade privados.
Coloque seu ponto de extremidade privado em sua própria sub-rede dedicada reservada para Funções.
Adicione um registro DNS usando a zona DNS privada para o ponto de extremidade privado.
Design de rede para o Azure Key Vault
Recomendações de design
O acesso à rede pública deve ser desativado.
Crie um ponto de extremidade privado para restringir o acesso somente via VNet.
Coloque seu ponto de extremidade privado em sua própria sub-rede dedicada reservada para o Cofre de Chaves.
Adicione um registro DNS usando a zona DNS privada para o ponto de extremidade privado.
Design de rede para grade de eventos
Considerações de design
- Você está usando zonas DNS privadas ou seu próprio servidor DNS (com encaminhamento de DNS) para resolver para um recurso de link privado?
Recomendações de design
O acesso à rede pública deve ser desativado usando a Filtragem de IP.
O tráfego para os seus tópicos e domínio deve ser restringido apenas aos Pontos de Extremidade Privados.
Coloque seu ponto de extremidade privado em sua própria sub-rede dedicada reservada para a Grade de Eventos.
Adicione um registro DNS usando a zona DNS privada para o ponto de extremidade privado.
Design de rede para Hubs de Eventos
Considerações de design
- Restringir o acesso à rede não funciona com a camada de SKU básica nos Hubs de Eventos
Recomendações de design
O acesso à rede pública deve ser desativado usando a Filtragem de IP.
O acesso à rede pública deve ser desabilitado usando pontos de extremidade de serviço: crie um ponto de extremidade de serviço de rede virtual em sua rede virtual e associe-o ao namespace de Hubs de Eventos usando uma regra de rede virtual
Habilite a opção Serviços Confiáveis para permitir que recursos selecionados do Azure acessem seu namespace.
Próximo passo
Analise as áreas críticas de design para fazer considerações e recomendações completas para sua arquitetura.