Segurança Corporativa no Azure VMware Solution (AVS): Como Inspecionar o Tráfego com Firewall NVA
Muitas vezes faz sentido usar uma NVA (Network Virtual Appliance) como firewall dentro do AVS, porque permite reaproveitar a solução de firewall já existente (Palo Alto, Check Point, etc..) e manter a proficiência do time de segurança, evita parte da complexidade de roteamento que pode surgir ao forçar o tráfego passar por um firewall “fora” do AVS . Além disso, administrar esse firewall dentro do AVS continua familiar para quem já opera VMware, e você ganha acesso a recursos avançados de inspeção do fabricante (como filtragem por aplicação em camada 7 e inspeção SSL/TLS), que são muito úteis para controle de tráfego outbound e políticas corporativas. Neste artigo eu demonstro e um laboratório prático de inspeção de tráfego Norte-Sul e Leste-Oeste, fazendo isolamento por ambiente (DEV/PRD) dentro do Azure VMware Solution (AVS) usando NSX-T (Tier-0/Tier-1) e um Firewall NVA (pfSense) implantado no SDDC. Também serão demonstradas as principais configurações no NSX (criação/associação de segments, gateways T0/T1 e ajustes de roteamento necessários para forçar o tráfego a passar pela NVA). Arquitetura Informações do Laboratório Segmentos de Trânsito Transit_Outside | CIDR: 192.168.30.0/24 | GW: 192.168.30.1 Transit_PRD | CIDR: 192.168.21.0/24 | GW: 192.168.21.1 Transit_DEV | CIDR: 192.168.22.0/24 | GW: 192.168.22.1 Segmentos de Workloads PRD_WEB | CIDR: 192.168.70.0/24 | GW: 192.168.70.1 PRD_DATA | CIDR: 192.168.71.0/24 | GW: 192.168.71.1 DEV_WEB | CIDR: 192.168.80.0/24 | GW: 192.168.80.1 DEV_DATA | CIDR: 192.168.81.0/24 | GW: 192.168.81.1 Interfaces da NVA (pfSense) Transit_Outside: 192.168.30.5 Transit_PRD: 192.168.21.5 Transit_DEV: 192.168.22.5 Configuração do Azure VMware Solution Na configuração Internet connectivity (egress/ingress) do Azure VMware Solution (AVS) irei utilizar a opção "Connect using Public IP down to the NSX Edge". Isso permite usar o NSX Data Center para criar regras de outbound e inbound (DNAT/SNAT) usando esses IPs públicos diretamente no Edge do AVS. Configuração de SNAT e NoSnat no NSX Regras “No SNAT” : Define que não deve haver tradução de origem quando o tráfego vai para redes privadas RFC1918. Isso preserva o IP original de origem para comunicação interna (ex.: on-prem, Azure, spoke VNets/rotas privadas), evita quebra de roteamento/retorno. Regra “SNAT”: Aplica tradução de origem para o restante do tráfego (Internet). Ou seja, quando uma VM com IP privado sai para fora, o NSX troca o IP de origem pelo IP público configurado ( 20.20.138.0/32). Criação dos Gateways TIER-1 (PRD e DEV). Importante: Estes gateway são "Isolados", portando não serão conectados ao TIER-0 T1_PRD_Isolado T1_DEV_Isolado Resultado Criação dos Segmentos de Trânsito PRD e DEV Importante: Estes Segmentos estarão conectados ao Tier-1 Gateway PRD (T1_PRD_Isolado) e DEV ( T1_DEV_Isolado) respectivamente criados na etapa anterior TRANSIT_PRD TRANSIT_DEV Criação do Segmento PRD WEB e DATA Importante: Estes Segmentos estarão conectados ao Tier-1 Gateway PRD (T1_PRD_isolado) e DEV ( T1_DEV_Isolado) respectivamente criados na etapa anterior PRD_WEB PRD_DATA DEV_WEB DEV_DATA Visão Geral dos Segmentos Configuração de Rotas Rotas no Gateway T1 Default No Gateway T1 Default que está conectado ao T0 , irei configurar rotas para todos os segmentos com Next Hop ao ip da interface Outside do meu PFsense (192.168.30.5) . obs: o nome do gateway T1 é diferente em cada AVS SDDC, no meu ambiente é "TNT13-T1" Informei o CIDR da Rede , neste caso é para o segmento TRANSIT_PRD Next Hop aqui é o ip da interface Outside do PFsense ( 192.168.30.5) , que está conectada diretamente a este GW T1. Repeti os mesmos passos para todos os outros Segmentos, sempre com next hop para 192.168.30.5. Interfaces Firewall Pfsense Neste cenário o Firewall possui apenas três interfaces. Deve ser configurada a rota default ( 0.0.0.0/0) para o gateway do Segmento Transit Outside ( 192.168.30.1) Interfaces do Pfsense Rotas no Gateways de Transito : T1_PRD_isolado Estarei criado uma rota default ( 0.0.0.0/0 ) , com next hop para a interface do Inside do PFsense (192.168.21.5 ) conectada ao Gateway T1 PRD. Devido a limitações do NSX, é necessário "quebrar" em duas: 0.0.0.0/1 e 128.0.0.1/1 Configuração da Rodas default Next Hop para ip da Interface Inside PFsense. Rotas no Gateways de Transito : T1_DEV_Isolado Estarei criado uma rota default ( 0.0.0.0/0 ) , com next hop para a interface do Inside do PFsense (192.168.22.5 ) conectada ao Gateway T1 PRD. Devido a limitações do NSX, é necessário "quebrar" em duas: 0.0.0.0/1 e 128.0.0.1/1 Configuração da Rodas default Next Hop para ip da Interface Inside PFsense. Teste de Acesso Tráfego Norte-Sul ( Saída Internet) Para comprovar que conseguimos agora ter o tráfego Norte-Sul, pelo NVA PFense , irei fazer um teste a partir da máquina no segmento PRD_WEB , com ip 192.168.70.1 É possivel observar que o ip públlico de saída é do AVS Agora vou criar uma regra no Pfsense bloqueando a porta 443 , mas deixando liberada as outras portas. Podemos comprovar que o tráfego está sendo inspersionado fazendo um teste de conexão na porta 53 e outro teste https. No Pfsense podemos ver o bloqueio Tráfego Leste-Oeste Para testar o tráfego leste oeste entre os Segmentos PRD_WEB ( VM 192.168.70.10 ) e DEV_WEB ( VM 192.168.80.10) , irei deixar ICMP liberado e bloquear a porta 3389 ( RDP) Fazendo o teste a partir da máquina 192.168.70.10 Verificando no PFsense o bloqueio da porta 3389 Resumo Neste laboratório demonstrei como integrar uma NVA ao Azure VMware Solution usando NSX-T com Tier-0/Tier-1, criando T1s isolados para DEV e PRD, segments de trânsito e a configuração de SNAT/NoSNAT no NSX para controlar o egress. Também mostrei o ajuste de rotas para garantir que o tráfego siga pelo caminho de inspeção no firewall. Validei a arquitetura com testes práticos de tráfego Norte-Sul (saída para Internet com IP público do AVS) e Leste-Oeste (controle entre DEV e PRD), comprovando a inspeção via logs e bloqueios aplicados no pfSense. Como próximos passos para produção, recomenda-se padronizar regras, logging, e revisar resiliência/HA do firewall e rotas para reduzir pontos únicos de falha. Referências Firewall integration in Azure VMware Solution | Microsoft Community Hub AVS How-to: 3rd Party Firewalls in Azure VMware SolutionProtegendo Máquinas no Azure VMware Solution com Azure Firewall
O Azure VMware Solution oferece três opções principais de conectividade outbound para a Internet. A primeira é o Managed SNAT, opção padrão e totalmente gerenciada pela plataforma, em que o próprio AVS realiza a tradução de endereços (SNAT) para permitir o acesso à Internet. Essa abordagem é simples e não requer configuração adicional, porém não oferece controle sobre os endereços IP públicos utilizados. A segunda opção é o uso de Public IPs no NSX-T Edge, onde o administrador atribui endereços públicos diretamente ao edge do ambiente AVS. Com isso, o tráfego de saída das máquinas virtuais utiliza esses IPs específicos, permitindo maior controle, ideal para cenários em que é necessário manter IPs fixos ou previamente autorizados em listas de acesso externas. Por fim, há a opção de rotear o tráfego via rede Azure (ou Azure Virtual WAN), em que uma rota padrão é anunciada por meio do ExpressRoute, direcionando o tráfego de saída para uma rede Azure que contém NVAs, Azure Firewall ou proxies. Essa abordagem oferece o maior nível de controle e segurança, pois permite aplicar inspeção, políticas e NAT centralizados, de forma integrada à arquitetura de rede do cliente. Neste artigo será demonstrado em um ambiente de laboratório como utilizar o Virtual Wan com Azure Firewall para inspeção do tráfego de saída das Vms em um segmento do AVS A arquitetura do laboratório. Virtual Wan com Azure Firewall ER Gateway conectado ao Express Route do Azure VMware Solution Os passos necessários são: Configuração da opção de Internet Connectivity do AVS Habilitar a propagação da Rota no Vwan Configuração do Routing Intent Configuração do Azure VMware Solution. Acesse o Private Cloud no portal do Azure e certifique que a opção abaixo esteja selecionada. Fazendo um "dump" das rotas no T0 do NSX, é possível verificar que não temos a rota default sendo propagada. Portanto não temos conectividade para internet a partir da máquina VM1 que está no AVS. Habilitando a propagação da Rota default no Virtual Wan Devemos agora habilitar a propagação da rota default pelo Virtual Wan , e para isso é necessário editar a conexão do Express Route do AVS, conectado ao Hub do Vwan . Habilite a propagação da Rota default Routing Intent O Routing Intent no Azure Virtual WAN é um recurso que simplifica e automatiza o roteamento de tráfego dentro do hub do Virtual WAN. Ele define como o tráfego entre redes (VNets, branches, e Internet) deve ser direcionado, sem necessidade de configurar manualmente tabelas de rotas complexas Observação: Em geral, no Brasil, caso já exista um Express Route On-premises, o Routing Intent já deve estar ativado para permitir o tráfego na comunicação com o Express Route do AVS, devido a não disponibilidade na região do Brasil do Express Route Global Reach Nas configurações do HUB, habilite o Routing Intent. Fazendo um novo "dump"das rotas BGP no NSX, agora é possível observar a rota default sendo propagada. Testando a partir da VM no AVS Conforme esperado é o mesmo IP público do meu Firewall no Vwan Nos Logs do Azure Firewall, comprovamos que o tráfego da VM (10.145.0.10) realmente está passando pelo Azure Firewall Referências: https://learn.microsoft.com/en-us/azure/azure-vmware/disable-internet-access
Zonas de Disponibilidade no Azure: Entendendo a Diferença entre Zonas Lógicas e Físicas
O que é o mapeamento de zonas do Azure (Zona Lógica vs Zona Física) No Azure, as Zonas de Disponibilidade (AZs) são agrupamentos de datacenters fisicamente separados dentros de uma mesma região. Cada zona possui infraestrutura independente - energia, refrigeração e rede - garantindo alta disponibilidade e resiliência. Porém, há uma distinção entre: Tipo de Zona Definição Zona Lógica Identificador exibido no portal do Azure (AZ1, AZ2, AZ3). Zona Física Grupo real de datacenters. O mapeamento entre lógica e física varia por assinatura O mapeamento entre zonas lógicas e físicas não é fixo. Isso significa que: AZ1 na assinatura A pode ser fisicamente igual à AZ3 na assinatura B. Sem verificação, você pode estar executando produção e DR na mesma infraestrutura física, anulando os benefícios da separação. Esse comportamento é intencional e inspirado no modelo da AWS, que também não garante consistência entre zonas lógicas em diferentes contas. Qual o objetivo desse design? A motivação por trás desse mapeamento dinâmico é: Distribuir a carga de consumo de forma mais eficiente entre os datacenters. Evitar hotspots e garantir resiliência operacional. Permitir flexibilidade de alocação conforme a capacidade física disponível. Esse modelo ajuda a balancear o uso da infraestrutura global, sem expor diretamente a topologia física aos clientes — o que também reforça a segurança e abstração da plataforma. Essa distinção é essencial: a zona lógica AZ1 em uma assinatura pode, na prática, ser a mesma zona física que a AZ3 em outra. Sem uma verificação adequada, o cliente pode acabar executando cargas de produção e de DR (Disaster Recovery) na mesma infraestrutura física, o que anula os benefícios esperados da separação entre zonas. Exemplo prático de risco Vamos considerar o seguinte cenário de um cliente: Produção: AZ1 e AZ2 em uma assinatura A DR: AZ3 em outra assinatura B, na mesma região O cliente acredita estar distribuindo suas cargas entre três zonas distintas. No entanto, ao verificar o mapeamento real, encontra a seguinte saída: [ { "logicalZone": "1", "physicalZone": "brazilsouth-az3" }, { "logicalZone": "2", "physicalZone": "brazilsouth-az1" }, { "logicalZone": "3", "physicalZone": "brazilsouth-az2" } ] Neste exemplo, a AZ3 lógica está mapeada para a AZ2 física, que já está sendo usada na produção. Ou seja, não há separação física real. Como verificar o mapeamento de zonas? Para evitar esse problema, é essencial verificar o mapeamento entre zonas lógicas e físicas em cada assinatura. Use o seguinte comando via Azure CLI: az rest --method get \ --uri "/subscriptions/<subscription-id>/locations?api-version=2022-12-01" \ --query "value[?name=='<region-name>'].{displayName: displayName,name: name,availabilityZoneMappings: availabilityZoneMappings }" \ -o json Substitua <subscription-id> e <region-name> (ex: brazilsouth) conforme necessário. Veja abaixo um exemplo de saída obtida no meu ambiente de laboratório, onde tenho duas assinaturas. Vou executar o mapeamento de zonas entre elas para a região Brazil South. Na primeira subscription 1 temos o seguinte mapeamento. Zona lógica: 1 – Zona Física: brazilsouth-az1 Zona lógica: 2 – Zona Física: brazilsouth-az2 Zona lógica: 3 – Zona Física: brazilsouth-az3 Na segunda subscription 2 temos o seguinte mapeamento. Zona lógica: 1 – Zona Física: brazilsouth-az3 Zona lógica: 2 – Zona Física: brazilsouth-az1 Zona lógica: 3 – Zona Física: brazilsouth-az2 Resumindo: Se minha estratégia de DR envolve o uso das zonas lógicas 1 e 2 na subscription 1, pois elas estão mapeadas fisicamente para as zonas AZ1 e AZ2, então, na subscription 2 destinada ao DR, devo utilizar a zona lógica 1 — já que, nessa assinatura, ela está mapeada fisicamente para a AZ3. Boas práticas Sempre verifique o mapeamento entre zonas lógicas e físicas antes de definir sua estratégia de DR. Evite assumir que AZ1, AZ2 e AZ3 representam zonas físicas distintas entre diferentes assinaturas. Considere utilizar regiões diferentes para DR quando a separação física for um requisito crítico. Documente e compartilhe o mapeamento com sua equipe de arquitetura e operações para garantir alinhamento e evitar riscos. Referência oficial Para mais detalhes, consulte a documentação oficial da Microsoft: https://learn.microsoft.com/en-us/azure/availability-zones/az-overview Comparing AWS and Azure regions and zones - Azure Architecture Center | Microsoft LearnPasso a Passo para Criar um Filtro de Tag no FinOps Hub
Recentemente, publiquei um blog sobre implementação e gerenciamento de custos do Azure usando FinOps Hub no formato FOCUS. Confira aqui. Agora, vou explicar como criar um filtro de Tag no FinOps Hub para otimizar a gestão de custos. 1. Acesse o Dashboard CostSummary do FinOps Hub Primeiro, abra o seu dashboard CostSummary do FinOps Hub. Esta versão que estamos trabalhando seria a V0.4. Em seguida, clique na aba de Resources. Você vai notar na tabela que existe uma coluna de Tag, porém ela não está formatada e não possui um filtro. O objetivo é corrigir a coluna e adicionar um filtro de tag para centro de custo. As Tags são referentes ao meu ambiente. De acordo com a figura abaixo, selecione a opção para transformar dados e adicionaremos o filtro de tag. 2. Navegue até a Seção de Filtragem No painel principal, localize e clique em CostDetails. Em seguida, encontre a coluna x_TagsDictionary, clique no item ao lado do nome e selecione a Tag centro_de_custo. No meu exemplo, também adicionei a Tag Environment. Antes de clicar em OK, desmarque a opção "Use original column name as prefix." E em seguida clique em OK 3. Selecione "Criar Novo Filtro" Ao clicar em OK, serão adicionadas mais duas colunas, centro_de_custo e Environment, conforme ilustrado no exemplo abaixo. Em seguida clique em Close & Apply 4. Criação do Fitro de Tag Na View de Resources, copie e cole o filtro de subscription com Ctrl+C e Ctrl+V e arraste-o para perto da view de Total Savings. 5. Alterar o Filtro Subscription para Filtro de Tag Selecione o filtro Subscription e, em Data, localize a tag centro_de_custo. Arraste o item centro_de_custo para field e depois exclua o Field Subscription. 6. Nova View para o Filtro Centro de Custo A visualização será parecida com o exemplo a seguir 7. Alterar a Tabela para fitrar por Tag Centro De Custo Precisamos agora modificar a tabela para aplicar o filtro ao centro de custo. Selecione a tabela e encontre no campo Data a tag centro_de_custo. Arraste o item centro_de_custo nas Colunas, como mostrado abaixo, e remova Tags da coluna. Com essas etapas concluídas, você deve ter uma nova visualização que reflete o filtro aplicado ao centro de custo. Essa configuração permitirá uma análise mais detalhada e específica, facilitando a identificação de gastos associados a cada centro de custo. Finalmente, salve as alterações feitas e atualize o dashboard para garantir que todas as modificações foram aplicadas corretamente. Agora, ao utilizar o filtro de centro de custo, você poderá visualizar apenas os dados relevantes conforme sua necessidade, tornando a análise financeira mais eficiente e direcionada.Como Implementar e Gerenciar Seus Custos do Azure com FinOps Hub no Formato FOCUS 🚀
Neste artigo ensino o passo a passo como você pode implementar e gerenciar eficientemente os custos do Azure utilizando o FinOps Hub. Além disso, mostro como aplicar o formato FOCUS, que é um padrão unificado para todas as clouds!Inspeção do tráfego destinado aos Private Endpoints para o Azure Firewall ou NVA
Este artigo possui a finalidade de demonstrar como podemos inspecionar o tráfego com destino aos recursos de Private Endpoint para o Azure Firewall ou NVA. O que é private Endpoint? Um private Endpoint fornece um endereço IP privado para uma lista de serviços de plataforma na Azure permitindo a comunicação privada com estes recursos.Monitorando Recursos Criados na Azure com Kusto Query Language (KQL) e Log Analytics
O monitoramento de atividades em nuvem é essencial para garantir a segurança, o desempenho e a conformidade das implantações na Microsoft Azure. A tabela AzureActivity, disponível no serviço Log Analytics, fornece informações detalhadas sobre todas as atividades realizadas em uma assinatura do Azure, incluindo criação de recursos, atualizações e exclusões. Usando a Linguagem de Consulta Kusto (KQL), podemos filtrar e analisar esses registros para obter insights valiosos sobre os recursos recém-criados.Provisionando um Azure Kubernetes Services (AKS) com AGIC + SSL
Um dos principais desafios ao implantar aplicativos em contêineres é fornecer uma maneira confiável e segura para que os usuários externos acessem esses aplicativos. É aqui que o Azure Application Gateway Ingress Controller (AGIC) desempenha um papel fundamental. O AGIC atua como um controlador de ingresso, direcionando o tráfego externo para os serviços corretos dentro do cluster AKS, tornando mais fácil e seguro o acesso a aplicativos em contêineres.Engenharia de Confiabilidade no Microsoft Azure (Realiability)
O pilar de confiabilidade do Well-Architected Framework concentra-se na capacidade do sistema de se recuperar automaticamente de falhas e gerenciar mudanças de forma segura e eficiente. Isso envolve a implementação de práticas e padrões para garantir que os sistemas sejam altamente disponíveis, resilientes e confiáveis.Adicionar sub-rede para um nodePool do AKS usando plugin Azure CNI
O Plugin de rede CNI usado nos ambientes produtivos requer um bom planejamento para os clusters do Azure Kubernetes Services (AKS) para que evitar a exaustão de endereço IP fornecido pela sub-rede do cluster devido ao crescimento do ambiente tendo a necessidade de recriar o cluster para atender essa demanda. Este artigo irá guiar sobre este cenário no qual encontramos em muitos ambientes produtivos com a possibilidade de adicionar um novo bloco de endereçamento IP da rede virtual do AKS e dedicá-la para um conjunto de node pool.
