Entendendo o mecanismo do Reverse Connect no AVD e Windows 365
- Steps and Tech

- 22 de jun. de 2025
- 3 min de leitura

Olá Pessoal!
Se tem uma coisa que sempre tirou o sono de arquitetos, engenheiros de infraestrutura e segurança foi a bendita porta 3389 exposta para a internet.😒 Durante anos, esse foi um mal necessário em ambientes de virtualização de desktops e também uma das maiores superfícies de ataque.
A boa notícia é que, com Azure Virtual Desktop (AVD) e Windows 365, esse modelo ficou para trás...espero que já saibam! 😊
O jogo mudou completamente por causa de um conceito fundamental (e ainda mal compreendido): o Reverse Connect (Conexão Reversa).
Mesmo assim, ainda vejo muita gente tentando:
Criar NAT
Abrir inbound no firewall
Liberar RDP “só para teste” - Sim, existe mesmo!!!
Tudo isso vai contra o desenho do serviço.
Neste post, vamos explicar como o Reverse Connect funciona de verdade, na prática, e por que ele muda completamente a forma como você deve pensar na rede e segurança em seus ambientes.
Antigamente ou historicamente, lá dos tempos de RDS eles funcionavam assim:
A VM ficava parada, com uma porta aberta, esperando alguém da "internet bater". ✌️
Isso exigia:
Portas inbound abertas
Regras de firewall expostas
Muito cuidado (e mesmo assim, risco)
No AVD e no Windows 365, esse modelo simplesmente não existe mais. SIM, NÃO existe mais!

Com Reverse Connect, nenhuma porta de entrada precisa ser aberta para o usuário se conectar.
Não há listener TCP aguardando conexões externas na VM.
A conexão nasce dentro do ambiente e vai em direção à nuvem da Microsoft.
→ Como isso funciona na prática
O Reverse Connect estabelece duas conexões de saída, independentes e seguras:
Do dispositivo do usuário → Gateway do serviço
Do session host ou Cloud PC → Gateway do serviço
Essas duas pontas nunca se conectam diretamente entre si.
O Gateway gerenciado pela Microsoft atua como intermediário, “costurando” as sessões de forma segura.
Se sua VM consegue sair para a internet (ou para os endpoints da Microsoft), ela consegue receber conexões.
O impacto real na arquitetura de segurança
Esse modelo muda completamente o desenho de rede e segurança e e para melhor.
Superfície de ataque drasticamente menor
Sem portas de entrada abertas:
Não existe força bruta em RDP
Não existe scanner encontrando desktops expostos
Não existe “acesso direto” ao host (Tinha muito disso)!!!
A VM simplesmente não está ouvindo ninguém.
Adeus, porta 3389 👋
A recomendação arquitetural é clara:
Não abra 3389. Nunca.
Exemplo de Porta 2289 aberta outbound e inbound - Alto risco!

Mesmo em ambientes AVD, ainda é comum encontrar NSGs com RDP e HTTPS abertos para a internet. Essas regras não são apenas desnecessárias, mas também elas vão contra o modelo de Reverse Connect e aumentam a superfície de ataque sem nenhum ganho funcional.
Todo o acesso de usuário deve acontecer via:
AVD
Windows 365
Reverse Connect

✓A própria Microsoft já passou a bloquear 3389 por padrão em novos Cloud PCs e e isso não é detalhe, é direção de produto.
Tráfego criptografado por padrão
Como tudo roda sobre HTTPS:
O tráfego já é criptografado de ponta a ponta
Não há necessidade de proxy com inspeção TLS
Inspeção, além de desnecessária, degrada a experiência
Se você tentar “quebrar” esse tráfego no meio, o efeito colateral normalmente é:
Input Delay alto
Latência perceptível
Usuário reclamando de lentidão
Principais aprendizados
Pense de dentro para fora...
No AVD e no Windows 365:
O firewall não é para proteger entrada
Ele serve para controlar saída
Seu trabalho como arquiteto e engenheiro é:
Permitir outbound apenas para os endpoints necessários
Bloquear destinos desnecessários
Reduzir o raio de explosão em caso de incidente
Troubleshooting não justifica abrir RDP
Se você precisar acessar um host para manutenção ou diagnóstico:
Vamos abrir a porta 3389?
Não, não...use:
Azure Bastion
Just-in-Time (JIT)
Acesso administrativo via rede privada
Abrir RDP “temporariamente” quase nunca é temporário, sabemos disso!
Dá para ir além com Private Link
Para ambientes mais exigentes, o Reverse Connect ainda pode:
Trafegar exclusivamente pela rede privada da Microsoft
Usar Azure Private Link
Eliminar até a dependência da internet pública
Isso é comum em:
Ambientes regulados
Setores financeiros
Órgãos governamentais
Se você entende que:
A conexão nasce no session host e vai para a nuvem
…você evita praticamente todos os erros clássicos de rede em AVD e Windows 365.
Reverse Connect não pode ser considerado um detalhe técnico, mas sim um pilar de segurança e arquitetura.ão de rede em seus projetos.






Comentários