> ## Content Index
> Fetch the complete content index at: https://www.azurebrasil.cloud/llms.txt
> Use this file to discover other available public pages before exploring further.

# Como expor serviços internos de forma segura e sem IP público
- URL: https://www.azurebrasil.cloud/blog/como-expor-servicos-internos-de-forma-segura-e-sem-ip-publico/
- Published: 2025-11-21T20:45:57.000Z
- Updated: 2025-11-24T12:46:30.000Z
- Author: Ricardo Martins

## 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:

1. Seu serviço roda em VMs ou pods no AKS
2. O tráfego interno chega em um ILB
3. O ILB está mapeado para um Private Link Service
4. Consumidores criam Private Endpoints para o seu PLS
5. O tráfego chega pelo backbone privado da Microsoft
6. 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

```bash
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.