Acesso privado aos serviços Azure PaaS

Este artigo explica como se ligar a recursos da plataforma Azure como serviço (PaaS) através de ligações de rede privadas em vez da internet pública. Aprende as diferenças entre endpoints de serviço, endpoints privados e Private Link para poder escolher a abordagem que se adequa aos seus requisitos de segurança e conectividade.

O que este artigo aborda

O acesso PaaS privado remove a internet pública do caminho de dados entre a sua rede virtual Azure e os serviços PaaS do Azure como Armazenamento do Azure, Base de Dados SQL do Azure e Azure Key Vault. Este artigo aborda as opções de conectividade, os seus compromissos e como decidir qual abordagem usar para cada carga de trabalho.

Note

Os Pontos Finais Privados requerem integração com DNS para resolver os FQDNs de serviço para endereços IP privados. Este artigo aborda os requisitos de DNS no próprio texto, mas, para a arquitetura completa do DNS, incluindo o reencaminhamento híbrido, o DNS do Azure Private Resolver e a segurança do DNS, consulte Segurança do DNS e resolução de nomes privada.

Quem precisa deste artigo

Leia este artigo se uma ou mais destas condições se aplicarem:

  • As suas cargas de trabalho devem chegar aos serviços PaaS do Azure através de caminhos de rede privados em vez de endpoints públicos.
  • Tens de decidir entre Endpoints de Serviço e Endpoints Privados com base na segurança, custo e gestibilidade.
  • É necessário restringir o acesso a recursos PaaS específicos para reduzir o risco de exfiltração de dados.
  • É necessário planear DNS, capacidade de sub-redes ou alcance híbrido para conectividade PaaS privada.

Dica

Seguir um percurso do cenário? Selecione o seu cenário no topo da página para obter orientação personalizada. As orientações principais que se seguem aplicam-se a todos os leitores.

Foco em levantar e deslocar: Evite este artigo, a menos que partes da sua aplicação migrada já utilizem serviços PaaS do Azure. A maioria das cargas de trabalho lift-and-shift mantém-se em IaaS (VMs, discos geridos, redes padrão) e não necessita de Private Link na fase inicial de migração. Volte a este artigo mais tarde, quando começar a adotar serviços PaaS para componentes individuais de carga de trabalho.

Leia este artigo se:

  • Migraram cargas de trabalho que já consomem serviços PaaS do Azure (por exemplo, Base de Dados SQL do Azure ou Armazenamento do Azure).
  • Quer compreender quando começar a utilizar o Private Link como parte de um processo de modernização faseada após um lift and shift.
  • É necessário planear a capacidade das sub-redes para a futura adoção do Private Endpoint.

Foco de modernização: As sub-redes do Private Link em cada VNet spoke são essenciais. O seu AKS, Ambiente do Serviço de Aplicações (ASE) e cargas de base de dados geridas precisam de conectividade PaaS privada para cumprir os requisitos de conformidade e evitar a exfiltração de dados pela internet pública.

Leia este artigo se:

  • Armazena dados sensíveis ou regulados nos serviços PaaS do Azure e deve restringir o acesso a caminhos de rede privados.
  • É necessário criar sub-redes dedicadas do Private Link em cada spoke VNet para utilização pela equipa da aplicação.
  • Queremos evitar a exfiltração de dados garantindo que a conectividade PaaS alcance a instâncias específicas de recursos.
  • Estão a desenhar cargas de trabalho de produção onde os serviços PaaS devem ser acessíveis a partir de redes locais via VPN ou ExpressRoute.
  • É preciso compreender as compensações em termos de custo, DNS e segurança entre os Service Endpoints e os Private Endpoints.

Foco multicloud: Este artigo torna-se relevante após estabelecer trânsito e conectividade entre clouds, a menos que a arquitetura de destino já inclua o Azure PaaS com pontos finais privados. Volte a este artigo durante a otimização quando estiver pronto para proteger os caminhos de acesso PaaS.

Leia este artigo se:

  • Estão a usar o Azure Migrate com suporte para Endpoints Privados durante o processo de migração.
  • Planeio adotar os serviços PaaS do Azure como parte da arquitetura alvo pós-migração.
  • É necessário compreender como funcionam os Pontos Finais Privados antes de os integrar na sua arquitetura multicloud.

Serviços e funcionalidades do Azure

A tabela seguinte descreve os serviços e funcionalidades disponíveis para a conectividade PaaS privada no Azure.

Serviço ou funcionalidade O que oferece Quando usar
Endpoint público (predefinido) Aceda aos serviços PaaS do Azure pela internet através do seu domínio público totalmente qualificado (FQDN). Não é necessária nenhuma configuração extra. Apenas ambientes de desenvolvimento/teste. Não recomendado para cargas de produção com dados sensíveis.
Pontos Finais de Serviço Estende a sua identidade de rede virtual para serviços Azure PaaS. O tráfego permanece na rede principal da Microsoft. O serviço PaaS vê o VNet como a fonte de tráfego. Não cria um endereço IP privado. Baixo risco de exfiltração. Configuração mais simples do que o Private Link. Útil quando o Private Link não está disponível para um serviço específico. Grátis.
Private Endpoint / Azure Private Link Cria uma interface de rede com um endereço IP privado dentro da sua rede virtual que corresponde a uma instância específica de recurso PaaS. O tráfego mantém-se na espinha dorsal da Microsoft e nunca atravessa a internet pública. Requer integração com DNS. Cargas de trabalho de produção. Dados sensíveis. Conformidade regulamentar. Prevenção da exfiltração de dados. Preferível aos pontos finais de serviço para novas arquiteturas.
Serviço de Link Privado Exponha o seu próprio serviço de forma privada a consumidores noutras redes virtuais ou em inquilinos da Microsoft Entra. Os consumidores criam um Endpoint Privado no seu próprio VNet para aceder ao seu serviço, sem necessidade de peering VNet. ISVs ou equipas internas de plataforma que publicam serviços para consumidores que não deveriam ter acesso ao nível da rede à rede virtual anfitriã.
Integração com VNet (Serviço de Aplicação, Funções) Permite ao App Service ou ao Funções do Azure encaminhar o tráfego de saída através de uma rede virtual. Só de saída: não fornece conectividade privada de entrada. Quando o App Service ou o Funções do Azure precisam de aceder a recursos privados do VNet, como bases de dados ou APIs internas, através de Endpoints Privados.

Como escolher

Diagrama que compara três métodos de acesso PaaS: endpoint público, endpoint de serviço via backbone e endpoint privado com IP privado.

Use as tabelas de decisão nesta secção para selecionar a abordagem de conectividade certa para a sua carga de trabalho.

Endpoints de Serviço comparados com Endpoints Privados

A tabela seguinte compara as duas abordagens mais comuns para restringir o acesso PaaS a caminhos de rede privada.

Fator Pontos Finais de Serviço Pontos finais privados
Percurso de trânsito Espinha dorsal da Microsoft. O destino continua a usar o seu endereço IP público. Espinha dorsal da Microsoft. O destino usa um endereço IP privado no seu VNet.
IP privada em VNet No. O IP de origem torna-se privado (endereço VNet), mas o serviço é resolvido para o IP público. Yes. Uma interface de rede com um IP privado da sua sub-rede é mapeada para o recurso específico.
Alterações DNS necessárias No. A resolução DNS mantém-se inalterada. Yes. É necessária uma zona DNS privada para que o FQDN do serviço seja resolvido para o IP privado.
Prevenção da exfiltração de dados Limitado. Aplica-se ao nível do VNet a todas as instâncias de um tipo de serviço (por exemplo, todas as contas do Armazenamento do Azure). Forte. O acesso está limitado a uma instância específica de um recurso. Apenas o recurso mapeado é acessível através desse endpoint.
Acesso nas instalações Não é acessível a partir de redes locais. Solução alternativa: adicione os seus endereços IP públicos ou NAT às regras de firewall IP do serviço Azure. Acessível a partir do local via VPN ou ExpressRoute porque o endpoint tem um endereço IP privado roteável.
Cost Grátis. Sem custos adicionais. Cobrança horária por endpoint mais taxa de processamento de dados.

Quando usar qual abordagem

Scenario Abordagem recomendada Porquê
Dev/test, baixa sensibilidade de dados Endpoint público com firewall de serviço A configuração mais simples. Restringa o acesso por IP, permitindo listagem. Sem custos extra ou alterações ao DNS.
Restrição simples de VNet, baixo risco de exfiltração Pontos Finais de Serviço Grátis. Rápido de ativar. Apropriado quando não precisas de um âmbito de acesso ao nível dos recursos.
Cargas de trabalho em produção, dados sensíveis, conformidade Pontos finais privados A mais forte proteção contra exfiltração. Trabalha a partir das instalações. Suporta resolução baseada em DNS a partir de qualquer rede ligada.
Publicar o seu próprio serviço de forma privada a outros inquilinos Serviço de Link Privado Os consumidores criam um Endpoint Privado no seu VNet. Não é necessário peering de VNet. Suporta fluxos de trabalho de aprovação e controlos de visibilidade.
O App Service ou o Functions precisa de aceder aos recursos da VNet Integração de VNet Conectividade apenas de saída. Requer a delegação de sub-rede a Microsoft.Web/serverFarms. Combine com Pontos Finais Privados para acesso seguro aos dados de serviços PaaS.

O Azure Front Door Premium suporta origens do Private Link, que são utilizadas para ligar o Front Door aos seus serviços de back-end (App Service, Storage ou balanceadores de carga internos) através de uma ligação privada. O tráfego entre o Front Door e a sua origem permanece na rede backbone da Microsoft, e pode desativar totalmente o acesso público na origem. Este padrão é a integração mais amplamente documentada do Private Link entre os serviços de rede do Azure.

Utilize o Front Door Premium com origens do Private Link quando precisar de:

  • Balanceamento de carga global com proteção por firewall de aplicações Web (WAF).
  • Conectividade privada às origens sem as expor à internet pública.
  • Terminação TLS centralizada com tráfego backend por caminhos privados.

Integração VNet para acesso de saída

A integração VNet não fornece conectividade privada de entrada. Permite que o App Service ou o Funções do Azure encaminhem chamadas de saída através da sua rede virtual. Isto significa que a sua aplicação pode aceder a recursos protegidos por Endpoints Privados ou a serviços privados da VNet. A integração com VNet requer uma sub-rede dedicada delegada a Microsoft.Web/serverFarms.

Combine a integração da VNet com Pontos Finais Privados quando a sua aplicação precisar de:

  • Ligue ao Base de Dados SQL do Azure ou ao Armazenamento do Azure através de um IP privado.
  • Aceda a APIs internas ou a serviços implementados em redes virtuais spoke.
  • Encaminhe o tráfego de saída através de um dispositivo virtual de rede (NVA) para inspeção.

Considerações de design

A maioria dos projetos lift-and-shift adia a adoção do Private Link para uma fase posterior. A tua prioridade imediata é migrar VMs e estabelecer conectividade básica. Considere o Private Link quando:

  • Componentes individuais da carga de trabalho já utilizam PaaS: Se uma aplicação levantada se ligar ao Base de Dados SQL do Azure ou Armazenamento do Azure, adicione um Endpoint Privado para esse serviço específico. Não precisa de converter todo o acesso PaaS de uma vez.
  • A conformidade exige conectividade privada: Algumas cargas de trabalho reguladas requerem caminhos de dados privados desde o primeiro dia. Neste caso, crie Pontos Finais Privados durante a migração, não depois.
  • Planeie já a capacidade da sub-rede: Mesmo que adie o Private Link, reserve uma sub-rede /27 ou /28 em cada rede spoke para futuros pontos finais privados. Adaptar o espaço de sub-rede mais tarde é mais difícil do que reservá-lo antecipadamente.

Para a maioria das migrações lift-and-shift, ignore a implementação detalhada do Private Link e volte a este artigo quando a adoção do PaaS começar.

Crie uma sub-rede dedicada do Private Link em cada spoke VNet. As equipas de aplicações utilizam esta sub-rede para criar Endpoints Privados para os serviços PaaS que as suas aplicações consomem:

  • Sub-rede dedicada do Private Link para cada spoke: Dimensione cada sub-rede com base no número de serviços PaaS que as cargas de trabalho do spoke requerem (um IP por Ponto Final Privado). Um /27 (32 endereços) suporta até 27 Pontos Finais Privados, depois de o Azure reservar 5 desses endereços.
  • Os administradores da aplicação decidem as ligações PaaS: A equipa de TI fornece a sub-rede e a infraestrutura DNS. As equipas de aplicações criam Endpoints Privados para os seus recursos PaaS específicos (SQL do Azure, Key Vault, Storage) com base nos requisitos da aplicação.
  • Centralize as zonas DNS no hub: As zonas DNS privadas (por exemplo, privatelink.database.windows.net) estão alojadas na subscrição de conectividade e estão ligadas a todas as VNets spoke. Esta abordagem garante uma resolução consistente dos nomes e evita o DNS de cérebro dividido.
  • Desligue o acesso público nos recursos PaaS: Depois de criar um Endpoint Privado, desligue o acesso público à rede no recurso PaaS alvo. Caso contrário, o tráfego ainda pode chegar ao serviço através da internet, anulando o propósito da conectividade privada.
  • Combine com a integração com a VNet: O App Service e o Funções do Azure utilizam a integração com a VNet para encaminhar chamadas de saída através da VNet spoke, para aceder a serviços PaaS através de pontos finais privados na mesma VNet ou numa VNet emparelhada.

O dispositivo do Azure Migrate suporta a conectividade do Private Endpoint, que protege o tráfego do plano de controlo da migração. Para além disso, adie o planeamento do Private Link para a fase de otimização pós-migração:

  • Azure Migrate com Private Endpoint: Durante o processo de migração, o appliance Azure Migrate pode usar um Private Endpoint para comunicar com o projeto Azure Migrate. Esta abordagem mantém o tráfego de controlo de migração fora da internet pública.
  • Adie a adoção generalizada do Private Link: Dê prioridade, primeiro, à conectividade de trânsito entre clouds. Depois de migrar e estabilizar as cargas de trabalho no Azure, planeie os Endpoints Privados para serviços PaaS como uma passagem de otimização separada.
  • Reserva espaço de sub-rede: Mesmo que saltes o Private Link agora, reserva uma sub-rede em cada spoke para futuros Endpoints Privados. Cargas de trabalho cross-cloud que mais tarde adotam serviços Azure PaaS necessitam desta capacidade.

Pré-requisitos

Antes de implementar o acesso privado a PaaS, confirme que tem os seguintes recursos e conhecimentos disponíveis:

  • Uma rede virtual implementada com pelo menos uma sub-rede. Os endpoints privados requerem uma sub-rede com endereços IP disponíveis. Para o design de redes virtuais, veja Redes e subredes virtuais.
  • Um serviço Azure PaaS para se ligar privadamente. O serviço deve suportar ou Service Endpoints ou Private Link. Consulte a documentação de disponibilidade do Azure Private Link para o seu serviço.
  • Compreensão da infraestrutura DNS. Endpoints privados requerem uma zona DNS privada. Se utilizar servidores DNS personalizados, tem de configurar reencaminhadores condicionais que apontem para o DNS do Azure (168.63.129.16). Para padrões de conceção de DNS, consulte o artigo sobre a integração de DNS para Pontos Finais Privados em Recursos relacionados.
  • Planeamento de endereços IP. Cada Endpoint Privado consome um endereço IP privado da sub-rede. Planeie os tamanhos das suas subredes em conformidade. Consulte planeamento de endereços IP para orientações.

Considerações de segurança

A conectividade privada PaaS afeta diretamente a sua postura de exfiltração de dados, a fiabilidade do DNS e a aplicação das políticas de rede. Considere as seguintes orientações ao desenhar a sua implementação.

Prevenção da exfiltração de dados

Os Endpoints Privados oferecem a proteção de exfiltração mais forte porque cada endpoint é mapeado para uma única instância de recurso. Um utilizador ou aplicação na sua VNet só pode aceder à conta de armazenamento ou base de dados específica para a qual o Endpoint Privado está configurado. Eles não podem redirecionar dados para uma instância diferente do mesmo tipo de serviço.

Os Endpoints de Serviço, por outro lado, restringem o acesso ao nível do VNet, mas aplicam-se a todas as instâncias de um tipo de serviço. Por exemplo, um Service Endpoint para Armazenamento do Azure significa que o VNet pode aceder a qualquer conta Armazenamento do Azure que conceda acesso, não apenas à conta pretendida. Esta lacuna torna os Endpoints de Serviço insuficientes para ambientes onde a exfiltração de dados é uma preocupação de conformidade.

Configuração da zona DNS

Diagrama que mostra o fluxo de resolução de DNS do endpoint privado, desde o cliente, através do DNS do Azure e da zona DNS privada, até à conta de armazenamento.

Os endpoints privados dependem da resolução DNS correta para funcionarem. Quando crias um Endpoint Privado, configuras uma zona DNS privada (por exemplo, privatelink.blob.core.windows.net para Armazenamento de Blobs do Azure) para que o FQDN do serviço seja resolvido para o IP privado em vez do IP público.

A má configuração das zonas DNS pode causar:

  • Aplicações resolvendo para o IP público, contornando completamente o Endpoint Privado.
  • Clientes on-premises que não conseguem aceder ao IP privado porque os encaminhadores condicionais não estão configurados.
  • Problemas de DNS de cérebro dividido, onde alguns clientes resolvem de forma privada e outros resolvem publicamente.

Centralize as zonas DNS privadas numa subscrição de serviços partilhados ou de conectividade e ligue-as a todas as redes virtuais que necessitem de resolução. Use o Azure Policy para impor a integração de zonas DNS privadas quando os Endpoints Privados forem criados.

Políticas de rede em sub-redes de pontos finais privados

Os grupos de segurança de rede (NSGs) e as rotas definidas pelo utilizador (UDRs) são agora suportados em sub-redes Private Endpoint. Este suporte está desativado por defeito e deve ser explicitamente ativado em cada sub-rede. Depois de ativar as políticas de rede:

  • Pode aplicar regras NSG para controlar quais as fontes que podem chegar ao Endpoint Privado.
  • Pode usar UDRs para encaminhar o tráfego de Pontos Finais Privados por um dispositivo virtual de rede para fins de inspeção.
  • Pode referenciar pontos finais privados nas regras ASG do grupo de segurança de aplicações.

Ative as políticas de rede nas sub-redes de Ponto Final Privado em ambientes de produção para assegurar uma postura de segurança consistente em todas as sub-redes da sua rede virtual.

Importante

Depois de configurares um Endpoint Privado para um serviço PaaS, desativa o acesso à rede pública nesse serviço. Se o acesso público continuar ativado, o tráfego ainda pode chegar ao serviço através da internet, o que anula o propósito da conectividade privada.

Zonas DNS Privado para serviços comuns

A tabela seguinte lista as zonas DNS privadas necessárias para os serviços Azure PaaS mais comuns.

Serviço do Azure Zona DNS Privado
Armazenamento de Blobs do Azure privatelink.blob.core.windows.net
Base de Dados SQL do Azure privatelink.database.windows.net
Azure Key Vault privatelink.vaultcore.azure.net
Azure Cosmos DB privatelink.documents.azure.com
Serviço de Aplicações do Azure privatelink.azurewebsites.net

Dica

Quando cria um endpoint privado no portal do Azure, muitas vezes cria-se automaticamente uma zona DNS privada associada. Eliminar o endpoint privado nem sempre remove a zona ou as suas ligações virtuais de rede. Auditar periodicamente endpoints privados órfãos e zonas DNS privadas. Aumentam os custos e a complexidade da sua configuração de resolução de nomes.

Perímetro de Segurança de Rede para acesso PaaS

O Private Link controla como o tráfego chega a um serviço PaaS, através de um endereço IP privado. O Perímetro de Segurança de Rede (NSP) controla quais as redes e recursos autorizados a comunicar com esse serviço. O NSP adiciona um limite explícito em torno de recursos PaaS como Armazenamento do Azure, Base de Dados SQL do Azure e Azure Key Vault: recursos dentro do perímetro comunicam livremente, enquanto o acesso externo é negado por defeito, a menos que uma regra de acesso o permita. Use o NSP juntamente com os Endpoints Privados quando precisar de proteção contra exfiltração de dados ao nível PaaS em designs de alta segurança. Para saber onde o NSP se encaixa entre os níveis de segurança, consulte a matriz de postura de segurança na visão geral.

Saiba mais

Passos seguintes

Dica

Explorar sozinho? Volte ao navegador de visão geral para encontrar o seu próximo artigo por capacidade.

A seguir na sua jornada de levantar e deslocar:

Acesso à internet de saída: Controle como as suas cargas de trabalho migradas chegam à internet através de um caminho centralizado de saída.

Próximo passo na sua jornada de modernização:

Acesso de saída à Internet: Encaminhe todo o tráfego de saída dos spokes através do firewall do hub para garantir um controlo consistente, gerido pela TI.

A seguir na sua jornada através da cloud:

Monitorização e diagnóstico de rede: Obtenha visibilidade do tráfego cross-cloud e da conectividade dos endpoints privados.

Se a sua arquitetura entre clouds incluir egresso centralizado para a Internet, leia primeiro Acesso de saída à Internet.

  • Last updated on