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). A rede é 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 sobre o design
Use uma topologia de rede baseada em 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 vários locais locais.
Precisa integrar uma rede de filial em grande escala diretamente no Azure, por meio de uma implantação de WAN DEFINIDA POR SOFTWARE (SD-WAN) ou requer mais de 30 sites de filial para terminação IPsec nativa.
Você precisa de roteamento transitivo entre VPN e ExpressRoute, por exemplo, branches remotos conectados por meio de VPN site a site ou usuários remotos conectados por meio de VPN ponto a site, e requer conectividade com um controlador de domínio conectado com ExpressRoute por meio do Azure.
As organizações usam a WAN Virtual para atender aos requisitos de interconectividade em larga escala. A Microsoft gerencia esse serviço, 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 apenas em 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 de 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 exigem 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 você possa adicionar aplicativos adicionais 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 de conversão de endereços de rede (NAT).
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 DNS do Azure. A configuração deles é feita com base recurso a recurso, mas os recursos suportados estão listados abaixo:
O Gerenciamento de API oferece suporte a 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 oferecem suporte a domínios personalizados para pontos de extremidade de armazenamento de blob.
O Data Factory, o Service Bus e a Grade de Eventos não oferecem suporte a 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 em uma rede virtual sem a necessidade de configurar uma solução DNS personalizada.
Para resolver os registros de uma zona DNS privada de sua rede virtual, você deve vincular a rede virtual com a zona. As redes virtuais vinculadas têm acesso total e podem resolver todos os registros DNS publicados na zona privada.
Considerações sobre o design
É importante definir corretamente as configurações de DNS para resolver o endereço IP do ponto de extremidade privado para o FQDN (nome de domínio totalmente qualificado) de seus recursos.
Os serviços do Azure existentes já podem ter uma configuração de DNS para um ponto de extremidade público, e essa configuração precisa ser substituída para se conectar usando o ponto de extremidade privado.
Criptografia e autenticação de certificado
Se o design da 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 o encerramento TLS.
Considerações sobre o design
Seu design exige que o tráfego entre os serviços do Azure seja criptografado? Sua criptografia pode ser encerrada em um Azure Front Door e, em seguida, não criptografada ao atravessar o backbone do Azure ou dentro de sua rede virtual?
Você precisará encerrar a criptografia em vários lugares?
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 sobre design
Se estiver usando um design de hub e 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 encerramento 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 sobre o design
O Azure ExpressRoute fornece conectividade privada dedicada aos recursos de IaaS (Infraestrutura como Serviço) e PaaS (Plataforma como Serviço) 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 da Infraestrutura como Serviço (IaaS) do Azure a partir de locais locais.
O Azure ExpressRoute e o Gateway de VPN do Azure têm recursos, 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 são práticos – as Conexões OPDG/Híbridas são exemplos de serviços de retransmissão, utilizando o Barramento de Serviço 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 oferece suporte (o limite de limitação), tem limites de tamanho de dados específicos 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 Aplicativo (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 Barramento de Serviço que permite retransmissões fora dos Serviços de Aplicativo ou OPDG.
Recomendações sobre design
Use o Azure ExpressRoute como o principal canal de conectividade para conectar uma rede local ao Azure.
Verifique se você está usando a SKU correta para a Rota Expressa e/ou o 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ê estiver usando um Recurso do Azure de suporte (por exemplo, Aplicativos Lógicos, Aplicativos de Função).
Conectividade com serviços de PaaS AIS
Os serviços de PaaS AIS do Azure geralmente são acessados por pontos de extremidade públicos. A plataforma Azure fornece funcionalidades para proteger esses pontos de extremidade ou até 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 sub-recurso específico para seus recursos de rede virtual, use um ponto de extremidade privado.
Se você quiser proteger uma conta de armazenamento específica para seus recursos de rede virtual, poderá usar um ponto de extremidade privado.
O Azure Private Link permite que você acesse os Serviços AIS do Azure (por exemplo, Gerenciamento de API e Barramento de Serviço) e os serviços de propriedade do cliente/parceiro hospedados no 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, a exposição do serviço à Internet pública não é mais necessária. Você pode criar o próprio serviço de link privado em sua rede virtual e oferecê-lo aos seus clientes. A configuração e o consumo usando o Link Privado do Azure são consistentes entre os serviços de parceiro de PaaS do Azure, de propriedade do cliente e de parceiros compartilhados.
Considerações sobre o design
A injeção de rede virtual fornece implantações privadas dedicadas para serviços com suporte. O tráfego do plano de gerenciamento ainda flui por meio de endereços IP públicos.
O Link Privado do Azure fornece acesso dedicado por meio de endereços IP privados para instâncias de PaaS do Azure ou serviços personalizados protegidos pela camada Standard 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 sobre design
Use a injeção de rede virtual para serviços do Azure com suporte para disponibilizá-los em sua rede virtual.
Os serviços de PaaS do Azure injetados em uma rede virtual ainda executam operações do plano de gerenciamento usando endereços IP públicos específicos do serviço. A conectividade precisa ser garantida para que o serviço opere corretamente.
Acesse os serviços de PaaS do Azure no local por meio do ExpressRoute com o emparelhamento privado. Use injeção de rede virtual para serviços dedicados do Azure ou Link Privado do Azure para serviços compartilhados do Azure disponíveis.
Para acessar os serviços de PaaS do Azure no local quando a injeção de rede virtual ou o Link Privado não estiver disponível, use a Rota Expressa com emparelhamento da Microsoft, que permite evitar atravessar a Internet pública.
Acessar os serviços de PaaS do Azure no local por meio do ExpressRoute com o emparelhamento da Microsoft não impede o acesso aos pontos de extremidade públicos do serviço de PaaS. Você precisa 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.
Design de rede para gerenciamento de API
Considerações sobre o design
Decida se as APIs são acessíveis externamente, internamente ou um híbrido de ambas.
Decida se você 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 Gateway de Aplicativo do Azure ou o Azure Front Door.
Decida se deve haver vários gateways implantados e como eles são balanceados 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 sobre 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 Gateway de Aplicativo 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 Link Privado do Azure.
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 Funções do Azure.
Recomendações sobre 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 tabela, fila e serviço de armazenamento de 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 sobre o 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) que permite que conexões externas usem um endereço IP visível publicamente, 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 rede virtual – eles estão automaticamente dentro da rede virtual 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 sobre design
- Use o ASE v3 sempre que possível, pois isso oferece 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 possa ser acessado pela Internet, considere o uso do Gateway de Aplicativo para expor o serviço de aplicativo.
Planeje suas sub-redes cuidadosamente para a integração de VNet de saída, considerando o número de endereços IP necessários. A integração de redes virtuais 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, são usados quatro endereços. Quando você aumenta ou reduz verticalmente, o espaço de endereço necessário é dobrado por um curto período de tempo. Isso afeta as instâncias reais e disponíveis com suporte em sua sub-rede.
Quando houver a necessidade de se conectar de um Serviço de Aplicativo a serviços locais, privados ou com restrição de IP, considere que:
Ao ser executada no ambiente multilocatário, a chamada do Serviço de Aplicativo pode se originar de uma ampla variedade de endereços IP, e a integração de rede virtual pode ser necessária para atender aos 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 sobre design
- Como os tamanhos de sub-rede não podem ser alterados após a atribuição, use uma sub-rede que seja 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 de rede virtual.
Design de rede para o Azure Data Factory
Considerações sobre o 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 de rede à fonte de dados de destino.
O Data Factory emprega ambientes separados chamados runtimes 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 rede virtual 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.
Pontos de extremidade privados gerenciados são pontos de extremidade privados criados na Rede Virtual Gerenciada do Azure Data Factory que estabelece um link privado para recursos do Azure (geralmente fontes de dados para ADF). O Azure Data Factory gerencia para você esses pontos de extremidade privados.
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 VNet
Considerações sobre o 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 o design de rede dos Aplicativos Lógicos.
O tráfego de saída de seus aplicativos lógicos flui pela 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 o design de rede dos Aplicativos Lógicos.
Design de rede para o Service Bus
Considerações sobre o design
Você está usando zonas DNS privadas ou seu próprio servidor DNS (com encaminhamento DNS) para resolver para um recurso de link privado?
A Filtragem de IP e as Redes Virtuais só são suportadas na camada de SKU Premium para o Service Bus. Se a camada Premium não for prática, considere usar tokens SAS como sua principal maneira de bloquear o acesso ao seu namespace.
Recomendações sobre design
O acesso à rede pública deve ser desabilitado usando a Filtragem de IP, que se aplica a todos os protocolos com suporte (por exemplo, AMQP e HTTPS).
O tráfego para esse namespace deve ser restrito somente a 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 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 de função
Considerações sobre o design
- Você está usando zonas DNS privadas ou seu próprio servidor DNS (com encaminhamento DNS) para resolver para um recurso de link privado?
Recomendações sobre design
O acesso à rede pública deve ser desabilitado.
O tráfego para esse namespace deve ser restrito somente a 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 Cofre de Chaves do Azure
Recomendações sobre design
O acesso à rede pública deve ser desabilitado.
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 sobre o design
- Você está usando zonas DNS privadas ou seu próprio servidor DNS (com encaminhamento DNS) para resolver para um recurso de link privado?
Recomendações sobre design
O acesso à rede pública deve ser desabilitado usando a Filtragem de IP.
O tráfego para seus tópicos e domínio deve ser restrito apenas a 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 sobre o design
- Restringir o acesso à rede não funciona com a camada de SKU Básica nos Hubs de Eventos
Recomendações sobre design
O acesso à rede pública deve ser desabilitado 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 vincule-o ao namespace dos 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óxima etapa
Revise as áreas críticas de design para fazer considerações e recomendações completas para sua arquitetura.