Em ambientes corporativos, é comum existir mais de um tenant Microsoft Entra ID envolvido em uma arquitetura Azure. Isso pode acontecer em cenários com empresas parceiras, unidades de negócio segregadas, ambientes adquiridos por fusão, laboratórios compartilhados ou integrações entre times com governanças diferentes.
Nesse contexto, uma dúvida recorrente é: como conectar redes virtuais que estão em tenants diferentes sem expor as VMs na Internet?
Neste laboratório, validei um cenário de VNet Peering Cross-Tenant no Azure, conectando uma VNet Consumer no meu tenant a uma VNet Provider em outro tenant. O objetivo foi manter a conectividade privada, sem Public IP, sem VPN, sem ExpressRoute, sem NAT Gateway, sem Load Balancer e sem Azure Firewall.
O Azure Virtual Network Peering permite conectar VNets para que recursos em redes diferentes se comuniquem usando endereços privados, inclusive em subscriptions e Microsoft Entra tenants diferentes. O tráfego entre VNets pareadas usa a infraestrutura privada da Microsoft, sem roteamento pela Internet pública.
Objetivo do laboratório
O objetivo foi validar três pontos:
- Criar um VNet Peering Cross-Tenant entre duas VNets em tenants diferentes.
- Permitir que a VM Consumer acesse apenas a VM de API do Provider.
- Bloquear o acesso da VM Consumer à subnet de Management do Provider usando NSG.
A ideia não foi criar uma arquitetura complexa, mas sim um laboratório direto, reproduzível e útil para entender o comportamento do peering cross-tenant na prática.
Arquitetura do laboratório
Consumer Tenant
Tenant Consumer
Subscription: sublableonardococo
Resource Group: rg-ct-consumer-brs-001
VNet: vnet-ct-consumer-brs-001
CIDR: 10.50.0.0/16
Subnet:
- snet-consumer-app: 10.50.1.0/24
VM:
- vm-consumer-test: 10.50.1.4Provider Tenant
Tenant Provider
Subscription: subprdadoniscopatftec001
Resource Group: rg-cross-tenant-adonis
VNet: vnet-ct-provider-brs-001
CIDR: 10.60.0.0/16
Subnets:
- snet-provider-service: 10.60.1.0/24
- snet-provider-mgmt: 10.60.2.0/24
VMs:
- vm-provider-api: 10.60.1.4
- vm-provider-mgmt: 10.60.2.4Desenho lógico
Arquitetura do laboratório com VNet Peering Cross-Tenant entre os tenants Consumer e Provider.
Regras de segurança usadas no Provider
O controle de acesso foi feito com Network Security Groups. NSGs permitem filtrar tráfego de entrada e saída para recursos em VNets do Azure, usando regras de allow e deny por origem, destino, protocolo e porta.
Na subnet de serviço do Provider, a regra principal permitiu somente:
Origem: 10.50.1.0/24
Destino: 10.60.1.0/24
Porta: TCP 8080
Ação: AllowEm seguida, foi criada uma regra de deny para bloquear outros acessos vindos da rede Consumer:
Origem: 10.50.0.0/16
Destino: 10.60.1.0/24
Porta: Any
Ação: DenyNa subnet de Management, o acesso do Consumer foi totalmente bloqueado:
Origem: 10.50.0.0/16
Destino: 10.60.2.0/24
Porta: Any
Ação: DenyCom isso, a conectividade entre tenants foi criada, mas o acesso ficou limitado ao serviço necessário.
Criação do VNet Peering Cross-Tenant
A criação do peering foi feita manualmente pelo Azure Portal. O ponto mais importante foi autenticar no diretório remoto durante a criação do peering.
Autenticação no diretório remoto
Durante a criação do VNet Peering Cross-Tenant, um ponto importante é a autenticação no diretório remoto. Ao informar o Resource ID da VNet Provider, o Azure Portal reconhece que a VNet pertence a outro Microsoft Entra tenant e solicita autenticação no respectivo diretório.
No laboratório, ao tentar criar o peering a partir da VNet Consumer, o Portal solicitou autenticação no diretório do tenant Provider antes de permitir a conclusão da configuração. Esse comportamento é esperado em cenários cross-tenant, pois o Azure precisa validar se o usuário possui permissão para acessar a VNet remota.
Isso significa que não basta conhecer o Resource ID da VNet do outro tenant. O usuário utilizado na operação precisa estar autorizado nos dois lados: no tenant local, onde o peering está sendo criado, e no tenant remoto, onde está a VNet de destino.
Na prática, para que a criação funcione, o usuário precisa ter permissão adequada nas duas VNets, normalmente Network Contributor ou superior, além de conseguir autenticar no diretório remoto. Caso contrário, o peering falha com erro de autorização, mesmo que o usuário tenha permissão total na VNet local.
Autenticação no diretório remoto exigida durante a criação do VNet Peering Cross-Tenant.
No lado Consumer, foi criado:
peer-consumer-to-providerNo lado Provider, foi criado:
peer-provider-to-consumerAmbos ficaram com estado:
Connected
Fully Synchronized
Cross-tenant: Yes
Peering no lado Consumer conectado ao tenant Provider.
Peering no lado Provider conectado ao tenant Consumer.
Um detalhe importante: no primeiro teste, a criação falhou porque a sessão ainda não estava autenticada no diretório remoto. Depois de autenticar no tenant Provider pelo próprio fluxo do Portal, o peering foi criado com sucesso.
Validação das rotas efetivas
Após a criação do peering, validei as rotas efetivas da NIC da VM Consumer diretamente pelo Azure Portal. A rota para o prefixo 10.60.0.0/16 apareceu como Active, com Next Hop Type definido como VNet peering.
Essa evidência confirma que o tráfego destinado à VNet Provider passou a ser encaminhado pelo peering cross-tenant, sem necessidade de VPN Gateway, ExpressRoute, NAT Gateway, Azure Firewall ou UDR.
Esse resultado confirmou que o tráfego da VM Consumer para a rede 10.60.0.0/16 passou a ser roteado pelo VNet Peering. A visualização de rotas efetivas é uma prática recomendada para diagnosticar caminhos de rede em NICs de VMs no Azure.
Após o peering, validei a rota efetiva na NIC da VM Consumer.
Rota efetiva confirmando o encaminhamento para a VNet Provider via VNet Peering.
Teste de acesso permitido: Consumer para Provider API
Para validar a conectividade real, executei um teste HTTP a partir da VM Consumer para a VM Provider API:
az vm run-command invoke \
--resource-group rg-ct-consumer-brs-001 \
--name vm-consumer-test \
--command-id RunShellScript \
--scripts "echo 'Teste Consumer -> Provider API'; curl -sS --connect-timeout 10 http://10.60.1.4:8080" \
--query "value[0].message" \
-o tsvResultado:
Acesso permitido da VM Consumer para a API Provider via VNet Peering Cross-Tenant.
Esse resultado confirmou que a VM Consumer, com IP 10.50.1.4, conseguiu acessar a aplicação HTTP privada na VM Provider API, com IP 10.60.1.4, pela porta 8080.
Teste de acesso bloqueado: Consumer para Provider Management
Também validei o acesso da VM Consumer para a VM de Management do Provider:
az vm run-command invoke \
--resource-group rg-ct-consumer-brs-001 \
--name vm-consumer-test \
--command-id RunShellScript \
--scripts "echo 'Teste Consumer -> Provider Management'; timeout 8 bash -c 'curl -sS --connect-timeout 3 --max-time 5 http://10.60.2.4:8080' && echo 'ERRO: management respondeu, revisar NSG' || echo 'OK: acesso ao management bloqueado pelo NSG, conforme esperado.'" \
--query "value[0].message" \
-o tsvResultado:
Acesso à subnet de Management bloqueado por NSG, mesmo com VNet Peering ativo.
Esse teste é importante porque prova que o peering não significa “liberar tudo”. A conectividade privada foi criada, mas o acesso permaneceu controlado por NSG.
O que este laboratório demonstrou
Este laboratório validou um cenário bastante comum em ambientes enterprise:
Conectar redes em tenants diferentes sem expor workloads com Public IP.O resultado final foi:
Consumer VM 10.50.1.4
-> Provider API 10.60.1.4:8080
Resultado: permitido
Consumer VM 10.50.1.4
-> Provider Management 10.60.2.4:8080
Resultado: bloqueadoAlém disso, o ambiente foi criado sem:
Public IP
NAT Gateway
Load Balancer
Azure Bastion
VPN Gateway
ExpressRoute
Azure Firewall
UDR
Private EndpointO VNet Peering resolveu a conectividade privada entre as VNets, enquanto os NSGs mantiveram o controle de tráfego entre as subnets.
Pontos de atenção
Alguns aprendizados importantes do laboratório:
- O peering cross-tenant exige autenticação no diretório remoto.
Apenas colar o resource ID da VNet remota não é suficiente se a sessão não estiver autenticada no outro tenant. - Permissão nos dois lados é obrigatória.
O usuário precisa ter permissão adequada nas VNets envolvidas, normalmente Network Contributor ou superior. - Connected não significa acesso irrestrito.
O estado Connected confirma o peering, mas o tráfego ainda pode ser permitido ou bloqueado por NSG. - Rota efetiva ajuda a provar o caminho.
Ver o NextHopType como VNetPeering na NIC da VM Consumer foi uma evidência importante. - Teste de aplicação é melhor que apenas ping.
O teste HTTP na porta 8080 comprovou conectividade real entre aplicações, não apenas alcance de rede.
Conclusão
O VNet Peering Cross-Tenant é uma alternativa simples e eficiente para conectar VNets em tenants diferentes quando existe necessidade de comunicação privada entre workloads Azure.
Neste laboratório, a VM Consumer conseguiu acessar a API do Provider por IP privado, usando o backbone da Microsoft e sem exposição pública. Ao mesmo tempo, o acesso à subnet de Management permaneceu bloqueado por NSG.
Esse tipo de validação é útil para cenários de integração entre empresas, ambientes segregados, squads com tenants diferentes ou laboratórios de arquitetura cloud. O principal cuidado é tratar o peering como conectividade de rede, não como controle de segurança. A segurança deve continuar sendo definida por NSGs, segmentação de subnets e regras claras de origem, destino e porta.
Referências oficiais
- Microsoft Learn — Create virtual network peering between different subscriptions and Microsoft Entra tenants.
- Microsoft Learn — Azure Virtual Network Peering overview.
- Microsoft Learn — Create, change, or delete Azure Virtual Network Peering.
- Microsoft Learn — Azure Network Security Groups overview.
- Microsoft Learn — Diagnose a virtual machine network routing problem.
- Microsoft Learn — Effective security rules overview.
