A conveniência operacional dos serviços de plataforma como serviço (PaaS) frequentemente mascara uma vulnerabilidade arquitetônica severa: a exposição nativa à internet pública. Quando corporações provisionam bancos de dados SQL ou aplicações web na nuvem e confiam exclusivamente em regras lógicas de firewall baseadas em IP para proteção de entrada, elas criam uma superfície de ataque global. Um único erro de configuração no controle de acesso ou o vazamento acidental de uma credencial resulta em exfiltração imediata de dados corporativos. A conformidade regulatória rigorosa exige a remoção completa de pontos de extremidade públicos. A implementação arquitetônica do Azure Private Link acoplada ao VNet Integration resolve essa deficiência sistêmica. Ao injetar o tráfego de saída da computação em uma sub-rede delegada e forçar a entrada do banco de dados através de uma interface de rede privada (NIC) ancorada na mesma malha, o sistema roteia os pacotes estritamente sobre o backbone isolado da Microsoft. Essa topologia institui um modelo Zero Trust inquebrável em nível de rede, protegendo ativos de missão crítica contra varreduras externas e tentativas de movimentação lateral.

Pré-requisitos

A orquestração deste perímetro de segurança exige proficiência em topologias de rede Hub-Spoke, delegação de sub-redes e resolução de zonas DNS privadas. A infraestrutura deve ser provisionada utilizando o Terraform versão 1.7.0 ou superior acoplado ao provedor HashiCorp AzureRM versão 3.90.0 ou superior. A camada de aplicação necessita do Python 3.12, além da biblioteca de mapeamento objeto-relacional SQLAlchemy (versão 2.0) e do azure-identity para gerenciamento criptográfico de tokens. Privilégios administrativos na assinatura do Azure são mandatórios para alterar as configurações do plano de controle de rede dos recursos PaaS e orquestrar as ligações de rede virtual (VNet Links) no DNS.

Passo a Passo

Injeção de Tráfego de Saída via VNet Integration

O estabelecimento do isolamento inicia configurando a camada de computação efêmera para rotear todo o seu tráfego de saída (Egress) diretamente para dentro da rede corporativa. Serviços como o Azure App Service ou o Azure Functions operam em uma infraestrutura multilocatária isolada que, por padrão, utiliza IPs de saída aleatórios para alcançar a internet. Provisionamos uma Rede Virtual (VNet) contendo uma sub-rede estritamente delegada ao serviço de computação web. O raciocínio técnico para utilizar o recurso de VNet Integration regional baseia-se na captura total do fluxo de rede. Ao ativar essa integração, a infraestrutura da Microsoft provisiona interfaces de rede ocultas que injetam os pacotes TCP da aplicação diretamente na sub-rede especificada. Habilitamos o parâmetro vnet_route_all_enabled para garantir que 100% do tráfego de saída, incluindo invocações para outros serviços do Azure, seja forçado a transitar pela VNet, permitindo a inspeção centralizada por um Network Security Group (NSG) ou um firewall de próxima geração.

resource "azurerm_virtual_network" "enterprise_vnet" {
  name                = "vnet-enterprise-core"
  address_space       = ["10.0.0.0/16"]
  location            = var.location
  resource_group_name = var.resource_group_name
}

resource "azurerm_subnet" "app_subnet" {
  name                 = "snet-app-integration"
  resource_group_name  = var.resource_group_name
  virtual_network_name = azurerm_virtual_network.enterprise_vnet.name
  address_prefixes     = ["10.0.1.0/24"]

  delegation {
    name = "app-service-delegation"
    service_delegation {
      name    = "Microsoft.Web/serverFarms"
      actions = ["Microsoft.Network/virtualNetworks/subnets/action"]
    }
  }
}

resource "azurerm_linux_web_app" "secure_api" {
  name                      = "app-enterprise-api-core"
  resource_group_name       = var.resource_group_name
  location                  = var.location
  service_plan_id           = azurerm_service_plan.compute_plan.id
  virtual_network_subnet_id = azurerm_subnet.app_subnet.id

  site_config {
    vnet_route_all_enabled = true
    application_stack {
      python_version = "3.12"
    }
  }
}

Uma vez que o tráfego de saída da aplicação agora flui nativamente dentro da rede privada, como blindamos o banco de dados de destino para aceitar conexões exclusivas desta sub-rede e extirpar sua exposição à internet pública?

Fechamento de Perímetro via Azure Private Link

Blindamos o repositório de dados provisionando um Azure Private Endpoint ancorado em uma sub-rede de infraestrutura separada e desabilitando matematicamente o acesso público no plano de controle do Azure SQL. O Private Endpoint atua como uma ponte física, projetando o banco de dados PaaS para dentro da VNet corporativa ao consumir um endereço IP privado estático alocado diretamente do bloco CIDR da sub-rede. A justificativa arquitetônica vital aqui é a negação por padrão (Deny-by-Default). Regras de firewall baseadas em IP no Azure SQL são vulneráveis a falsificações (IP spoofing) e falhas humanas. Ao configurar public_network_access_enabled = false via Terraform, instruímos o Azure Resource Manager a rejeitar qualquer tentativa de handshake TCP originada fora do backbone privado, independentemente das credenciais apresentadas. Isso assegura que a única rota matematicamente possível para alcançar os dados corporativos seja originada de dentro da VNet, especificamente do bloco de endereços ocupado pela aplicação web integrada.

Press enter or click to view image in full size