Como expor serviços internos de forma segura e sem IP público
Introdução
Expor serviços internos com segurança sempre foi um desafio. Especialmente quando o requisito é claro. nada de IP público, nada de tráfego aberto na internet e controle absoluto de quem consome cada endpoint.
O Azure Private Endpoint resolve o consumo privado de serviços PaaS. Mas e quando você precisa expor seu próprio serviço para outras VNets, outros clientes ou até outras assinaturas.
É aí que entra o Azure Private Link Service (PLS). Ele permite publicar qualquer aplicação interna como um serviço privado, acessível apenas via Private Endpoint, sem IP público, sem NAT, sem internet.
Neste artigo você vai aprender:
- A diferença entre Private Endpoint e Private Link Service
- Arquiteturas ideais para PLS
- Como usar PLS em cenários multi-tenant e B2B
- Como integrar com Load Balancer interno
- Melhores práticas de segurança e governança
1. Private Endpoint x Private Link Service - o que muda
Apesar dos nomes parecidos, eles resolvem problemas diferentes.
Private Endpoint
Ponto privado usado para consumir serviços oferecidos pela Microsoft.
Exemplos. Storage, SQL, Key Vault, App Configuration, OpenAI, Cosmos DB.
- Você é consumidor do serviço
- O serviço é da Microsoft
- O endpoint privado é criado dentro da sua VNet
Private Link Service
Ponto privado usado para publicar seu próprio serviço para outras redes.
Exemplos. APIs internas, aplicações internas, serviços de bancos de dados, gateways.
- Você é o provedor do serviço
- O serviço é seu. hospedado em VM, AKS, AppService VNet Integration etc.
- Outras empresas, clientes ou VNets acessam seu serviço via Private Endpoint
Em resumo:
Private Endpoint = consumo
Private Link Service = publicação
2. Como o Private Link Service funciona
O PLS funciona como uma camada de abstração sobre um Internal Load Balancer (ILB).
A arquitetura padrão segue este fluxo:
- Seu serviço roda em VMs ou pods no AKS
- O tráfego interno chega em um ILB
- O ILB está mapeado para um Private Link Service
- Consumidores criam Private Endpoints para o seu PLS
- O tráfego chega pelo backbone privado da Microsoft
- Nenhuma conexão exposta na internet
Cliente → Private Endpoint → Backbone Microsoft → Private Link Service → Load Balancer Interno → Serviço
3. Arquiteturas típicas com Private Link Service
3.1. Expor APIs internas para clientes externos B2B
Perfeito para empresas que vendem um serviço hospedado no Azure e precisam entregar acesso privado isolado por cliente.
Cada cliente.
- cria um Private Endpoint
- acessa apenas o próprio canal
- não enxerga outros clientes
3.2. Multi-tenant seguro
Você pode criar um PLS único e deixar que várias assinaturas consumam o mesmo serviço via Private Endpoint.
O benefício. cada cliente tem um NIC privado dedicado.
3.3. Comunicação segura entre ambientes distintos
Casos de:
- Matrizes e filiais
- Parceiros conectando workloads internos
- ISVs expondo APIs internas para integrações
3.4. AKS + Private Link Service
Quando o workload roda em AKS, você usa:
- A aplicação exposta em ClusterIP
- Um Internal Load Balancer
- O PLS conectado ao ILB
É a forma mais avançada de expor serviços privados de contêineres para outras VNets com isolamento forte.
4. Exemplo prático - criando um Private Link Service
Requisitos
- Um ILB (Internal Load Balancer)
- Backend configurado (VMs ou AKS)
- Uma VNet dedicada para o provedor
Exemplo com Azure CLI
az network lb create \
--resource-group rg-core \
--name ilb-service \
--sku Standard \
--frontend-ip-name fe \
--backend-pool-name bepool \
--private-ip-address 10.0.0.10 \
--vnet-name vnet-core \
--subnet default \
--frontend-ip-configurations Private
az network private-link-service create \
--resource-group rg-core \
--name pls-api-core \
--lb-name ilb-service \
--lb-frontend-ip-configs fe \
--location eastus \
--visibility subscription
Consumidores agora podem criar Private Endpoints apontando para seu PLS.
5. Segurança. onde o PLS realmente brilha
O Private Link Service atende cenários de alta segurança por natureza.
Mas existem práticas essenciais:
-> Controle de quem pode consumir
Defina:
- assinaturas autorizadas
- tenants permitidos
- VNets específicas
-> Use NSGs e UDRs para limitar trafego lateral
-> Combine com Azure Firewall para inspeção
-> Ative logs de conexão
Envie para Log Analytics:
- conexões aprovadas
- negações
- falhas de resolução
-> Utilize tags de serviço (Privatelink.*) para granularidade nas regras
6. Multi-tenant e Saa - o melhor cenário possível para PLS
Para empresas que entregam serviços como:
- API de dados
- gateway financeiro
- processamento de IA
- microsserviços internos
O PLS resolve três problemas críticos:
- Isolamento. cada cliente tem uma interface privada própria
- Segurança. nada passa pela internet
- Simplicidade. toda conexão acontece pelo backbone da Microsoft
Regra prática para SaaS.
Se seu cliente exige conexão privada e sem internet, Private Link Service é obrigatório.
Conclusão
O Azure Private Link Service é um dos recursos mais poderosos e pouco explorados do Azure para conectar serviços de maneira privada, segura e isolada. Com ele você consegue:
- publicar serviços internos sem IP público
- entregar integração segura para clientes B2B
- habilitar multi-tenant privado
- operar workloads críticos com isolamento real
É a evolução natural da segurança de rede no Azure, trazendo um nível de controle que antes exigia VPNs complexas, firewalls avançados e múltiplos túneis.