Software · Computação em Nuvem & DevOps

Redes em Nuvem: VNets, Peering, Private Endpoints e Application Gateway no Azure

Como estruturar a arquitetura de redes privadas no Microsoft Azure: segmentação com Virtual Networks (VNets), roteamento Hub-and-Spoke com VNet Peering, isolamento com Private Endpoints e proteção perimetral com Application Gateway e Azure Firewall.

Diagrama de topologia de rede corporativa em nuvem Hub-and-Spoke com VNet Peering, Firewall, Application Gateway e Private Endpoints
Neste artigo

Em uma arquitetura de nuvem pública, a rede virtual é a espinha dorsal invisível que define os limites de segurança, a latência de comunicação e o isolamento de dados. Tratar recursos de computação e armazenamento como se fossem ilhas expostas diretamente na internet pública — protegidas unicamente por senhas ou tokens — viola o princípio básico de Defesa em Profundidade (Defense in Depth) e expõe a infraestrutura a ataques massivos de negação de serviço e vazamento de dados.

No Microsoft Azure, a construção de um perímetro seguro ancora-se nas Virtual Networks (VNets), no modelo de topologia Hub-and-Spoke interconectado por VNet Peering, no fechamento do acesso público através de Private Endpoints (Azure Private Link) e na inspeção profunda de tráfego com Azure Firewall e Azure Application Gateway.


Virtual Networks (VNets) e Subnets: O Espaço Privado de Endereçamento

Uma Azure Virtual Network (VNet) é a representação lógica da sua própria rede privada isolada no datacenter da Microsoft. Toda VNet opera sob blocos de endereçamento privado definidos pela especificação RFC 1918 (como 10.0.0.0/16):

flowchart TD
    subgraph VNet["VNet Corporativa (10.0.0.0/16)"]
        direction TB
        SubApp["Subnet Aplicação (10.0.1.0/24)<br/>Serviços Web e APIs de Backend"]
        SubData["Subnet Dados (10.0.2.0/24)<br/>Bancos de Dados e Caches"]
        SubAgw["Subnet Gateway Dedicada (10.0.0.0/24)<br/>Application Gateway WAF"]

        SubAgw -->|Tráfego HTTP/HTTPS Inspecionado| SubApp
        SubApp -->|Consultas SQL e TCP Caching| SubData
    end

Network Security Groups (NSGs): O Firewall Básico de Camada 4

No nível das sub-redes ou das placas de rede virtuais (NICs), o tráfego é filtrado por regras com estado (stateful) de Network Security Groups (NSGs):

  • Regras são avaliadas em ordem crescente de prioridade (de 100 a 4096).
  • Filtram portas TCP/UDP e endereços de origem e destino (Camada 4 do modelo OSI).
  • Service Tags: Atalhos gerenciados pela Microsoft (ex.: AzureActiveDirectory, Sql, VirtualNetwork) que simplificam regras permitindo o tráfego seguro para serviços da nuvem sem a necessidade de cadastrar faixas voláteis de IPs públicos.

Topologia Hub-and-Spoke com VNet Peering

Em organizações que operam dezenas de microsserviços e ambientes corporativos, criar uma rede única e gigante é inviável, enquanto manter VNets completamente isoladas impede a governança central.

O padrão arquitetural de referência é a topologia Hub-and-Spoke:

flowchart TD
    subgraph Hub["VNet Hub (Rede Central / Serviços Compartilhados)"]
        FW["Azure Firewall (Inspeção Central)"]
        DNS["Azure Private DNS Resolver"]
        Bastion["Azure Bastion (Acesso Seguro SSH/RDP)"]
    end

    subgraph Spoke1["Spoke A (Workload Produção)"]
        AppProd["Aplicações Prod"]
    end

    subgraph Spoke2["Spoke B (Workload Homologação)"]
        AppDev["Aplicações Dev/Test"]
    end

    Spoke1 <-->|"VNet Peering (Backbone Microsoft)"| Hub
    Spoke2 <-->|"VNet Peering (Backbone Microsoft)"| Hub
    Spoke1 -.->|"Proibido: Sem Peering Direto"| Spoke2
  • VNet Hub: Contém os serviços de perímetro compartilhados: Azure Firewall para inspeção e controle de saída para a internet, Azure Bastion para acesso administrativo seguro sem expor portas 22 ou 3389 para o mundo, e servidores DNS corporativos.
  • VNets Spoke: Contêm as cargas de trabalho específicas de cada time de negócio. Comunicam-se com o Hub via VNet Peering.
  • VNet Peering: Conecta redes virtuais utilizando exclusivamente o backbone de fibra ótica privado global da Microsoft. O tráfego nunca sai para a internet pública, opera na velocidade máxima da linha e não sofre com gargalos de criptografia de túneis VPN.

Historicamente, serviços PaaS como Azure SQL Database, Blob Storage ou Cosmos DB eram acessados através de FQDNs públicos (meubanco.database.windows.net). Mesmo restringindo o firewall por IP, o tráfego cruzava o perímetro público da nuvem.

O Azure Private Link elimina completamente essa vulnerabilidade:

flowchart LR
    VM["VM na Subnet de Aplicação<br/>IP: 10.0.1.4"] --> PE["Private Endpoint (NIC Virtual)<br/>IP Privado: 10.0.2.15"]
    PE -->|"Conexão Privada via Backbone"| SQL[("Azure SQL Database<br/>(Acesso Público: Totalmente Desativado)")]
  1. Um Private Endpoint é uma placa de rede virtual (NIC) provisionada diretamente dentro de uma sub-rede da sua própria VNet, recebendo um IP privado da sua faixa interna (10.0.2.15).
  2. O Azure Private DNS intercepta a consulta ao domínio do banco e a resolve diretamente para esse IP privado interno.
  3. O recurso PaaS fecha seu firewall público para a internet inteira. Nenhum pacote de dados pode alcançá-lo fora da sua rede privada ou das VNets conectadas via Peering.

Perímetro Web Avançado: Azure Application Gateway e WAF

Enquanto os NSGs e o Azure Firewall operam primariamente nas camadas 3 e 4 (IP e Portas), aplicações web exigem inteligência na camada de aplicação (Camada 7 do modelo OSI).

O Azure Application Gateway é um balanceador de carga web com recursos avançados:

  • Terminação SSL/TLS Centralizada: Os certificados digitais são descriptografados no gateway, aliviando o processamento dos servidores de backend.
  • Roteamento Baseado em URL: Encaminha requisições /api/orders/* para o pool de microsserviços de pedidos, e requisições /static/* para contas de armazenamento de mídia.
  • Web Application Firewall (WAF): Equipado com as regras do OWASP Core Rule Set (CRS), o WAF inspeciona os payloads HTTP em tempo real, bloqueando ativamente ataques de SQL Injection (SQLi), Cross-Site Scripting (XSS), Remote File Inclusion e varreduras automatizadas de vulnerabilidade.

Conectividade Híbrida: VPN Gateway vs. Azure ExpressRoute

Para conectar os datacenters locais e escritórios corporativos à nuvem Azure:

Recurso Tipo de Meio Físico Largura de Banda Previsibilidade de Latência
Site-to-Site VPN Gateway Túnel criptografado IPsec/IKE trafegando pela internet pública. Até 1.25 Gbps por túnel. Variável; sujeita à congestão de provedores de telecomunicações públicos.
Azure ExpressRoute Circuito de conexão privada dedicada fornecido por operadoras parceiras. De 50 Mbps até 100 Gbps. Altíssima previsibilidade e SLA rigoroso; tráfego 100% fora da internet.

Conclusão

Redes em nuvem deixaram de ser meros cabos virtuais para se tornarem a fundação programável da postura de segurança corporativa. Ao adotar a arquitetura Hub-and-Spoke, conectar serviços gerenciados estritamente através de Private Endpoints, aplicar inspeção de pacotes com Azure Firewall e blindar APIs web com o Application Gateway WAF, sua infraestrutura estabelece um perímetro defensivo intransponível, resiliente e auditável.

Explorar este tema no Grafo de Conhecimento