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 LearnConectando o Azure Vmware Solution (AVS) com VPN Site to Site em topologia Hub Spoke.
A conexão de VPN entre AVS e o ambiente On-premises na maioria das vezes é realizada através do Virtual WAN, conforme descrito em: https://learn.microsoft.com/en-us/azure/azure-vmware/configure-site-to-site-vpn-gateway. Contudo, caso necessário utilizar em uma topologia Hub-Spoke, existem componentes adicionais que devem ser considerados para permitir o trânsito entre o ExpressRoute do AVS e o VPN Gateway, bem como a propagação das rotas para o ambiente On-premises, assim como é feito por padrão com o Virtual WAN. Nesta topologia, o Azure Route Server deve ser integrado para habilitar esse trânsito (propagação de rotas) O objetivo deste artigo é demonstrar em um ambiente de laboratório como conectar um ambiente On-premises com o Azure VMware Solution (AVS) através de uma VPN Site-to-Site em topologia Hub-Spoke. Arquitetura do Laboratório com topologia Hub-Spoke. Componentes Azure. Vnet 10.90.0.0/16 com 3 Subnets. Gateway Subnet - 10.90.0.0/24 RouteServerSubnet - 10.90.1.0/24 VmSubnet : 10.90.2.0/24 Virtual Network Gateway - VPN Virtual Network Gateway - Express Route Azure Route Server Azure Vm Linux Ubuntu Componentes On-premises Firewall VPN PfSense - 192.168.90.0/24 , 192.168.200.0/22 , 192.168.92.0/24 Componetes Azure Vmware Solution VMware SDDC Circuito Express Route *Este laboratório presume que os componentes como o Azure Vmware Solution e ambiente On-premises com Pfsense ou qualquer outro equipamento esteja presente. 1. Deploy componentes Azure # 1. Variáveis - Altere conforme necessário RESOURCE_GROUP="rg-avs-lab" LOCATION="eastus2" VNET_NAME="vnet-avs-lab" VNET_ADDRESS_PREFIX="10.90.0.0/16" SUBNET_GATEWAY_PREFIX="10.90.0.0/24" SUBNET_ROUTE_SERVER_PREFIX="10.90.1.0/24" SUBNET_GATEWAY_NAME="GatewaySubnet" SUBNET_ROUTE_SERVER_NAME="RouteServerSubnet" EXPRESSROUTE_GW_NAME="er-avs-lab" VPN_GW_NAME="vpn-avs-lab" VPN_GW_IP1_NAME="vpn-gw-ip1" VPN_GW_IP2_NAME="vpn-gw-ip2" VPN_GW_ASN=65515 EXPRESSROUTE_IP_NAME="er-ip" LOCAL_NETWORK_GATEWAY_NAME="local-gw-avs-lab" BGP_PEER_IP="192.168.90.1" ASN_LOCAL=65503 ROUTE_SERVER_NAME="rserver-avs-lab" # Variáveis para subnet e VM SUBNET_VM_NAME="subnet-vm" SUBNET_VM_PREFIX="10.90.5.0/24" VM_NAME="vm-ubuntu" VM_ADMIN_USERNAME='azureuser' VM_ADMIN_PASSWORD='P@ssword123!' # Use um método seguro em produção VM_NIC_NAME="vm-ubuntu-nic" VM_IMAGE="Canonical:0001-com-ubuntu-server-focal:20_04-lts:latest" VM_SIZE="Standard_B2ms" # 2. Criar grupo de recursos az group create --name $RESOURCE_GROUP --location $LOCATION # 3. Criar VNet e subnets az network vnet create \ --resource-group $RESOURCE_GROUP \ --location $LOCATION \ --name $VNET_NAME \ --address-prefixes $VNET_ADDRESS_PREFIX \ --subnet-name $SUBNET_GATEWAY_NAME \ --subnet-prefix $SUBNET_GATEWAY_PREFIX az network vnet subnet create \ --resource-group $RESOURCE_GROUP \ --vnet-name $VNET_NAME \ --name $SUBNET_ROUTE_SERVER_NAME \ --address-prefix $SUBNET_ROUTE_SERVER_PREFIX # Criar subnet para a VM az network vnet subnet create \ --resource-group $RESOURCE_GROUP \ --vnet-name $VNET_NAME \ --name $SUBNET_VM_NAME \ --address-prefix $SUBNET_VM_PREFIX # 4. Criar IP público para ExpressRoute az network public-ip create \ --resource-group $RESOURCE_GROUP \ --name $EXPRESSROUTE_IP_NAME \ --sku Standard \ --allocation-method Static # 5. Criar Gateway ExpressRoute az network vnet-gateway create \ --resource-group $RESOURCE_GROUP \ --name $EXPRESSROUTE_GW_NAME \ --location $LOCATION \ --vnet $VNET_NAME \ --public-ip-addresses $EXPRESSROUTE_IP_NAME \ --gateway-type ExpressRoute \ --sku Standard # 6. Criar IPs públicos para VPN Gateway ativo-ativo az network public-ip create \ --resource-group $RESOURCE_GROUP \ --name $VPN_GW_IP1_NAME \ --sku Standard \ --allocation-method Static az network public-ip create \ --resource-group $RESOURCE_GROUP \ --name $VPN_GW_IP2_NAME \ --sku Standard \ --allocation-method Static # 7. Criar VPN Gateway az network vnet-gateway create \ --resource-group $RESOURCE_GROUP \ --name $VPN_GW_NAME \ --location $LOCATION \ --vnet $VNET_NAME \ --public-ip-addresses $VPN_GW_IP1_NAME $VPN_GW_IP2_NAME \ --gateway-type Vpn \ --vpn-type RouteBased \ --sku VpnGw1 # Após a criação, configurar ativo-ativo e BGP az network vnet-gateway update \ --resource-group $RESOURCE_GROUP \ --name $VPN_GW_NAME \ --set activeActive=true enableBgp=true bgpSettings.asn=$VPN_GW_ASN # 8. Criar Local Network Gateway com BGP e ASN az network local-gateway create \ --resource-group $RESOURCE_GROUP \ --name $LOCAL_NETWORK_GATEWAY_NAME \ --gateway-ip-address $BGP_PEER_IP \ --local-address-prefixes "192.168.90.0/24" \ --asn $ASN_LOCAL \ --bgp-peering-address $BGP_PEER_IP \ --location $LOCATION # 9. Criar conexão VPN entre o Gateway de VPN e o Local Network Gateway az network vpn-connection create \ --resource-group $RESOURCE_GROUP \ --name vpn-s2s-connection \ --vnet-gateway1 $VPN_GW_NAME \ --local-gateway2 $LOCAL_NETWORK_GATEWAY_NAME \ --shared-key 'teste@123' \ --enable-bgp # 10. Criar NIC para a VM az network nic create \ --resource-group $RESOURCE_GROUP \ --name $VM_NIC_NAME \ --vnet-name $VNET_NAME \ --subnet $SUBNET_VM_NAME # 12. Criar VM com Ubuntu az vm create \ --resource-group $RESOURCE_GROUP \ --name $VM_NAME \ --nics $VM_NIC_NAME \ --image $VM_IMAGE \ --admin-username $VM_ADMIN_USERNAME \ --admin-password $VM_ADMIN_PASSWORD \ --size $VM_SIZE \ --location $LOCATION 2. Conectando o Express Route do AVS no VPN Gateway da Hub. No Virtual Network Gateway de ER , adicione uma conexão Defina o connection type como ExpressRoute No AVS, copie o authorization key e o ExpressRoute ID Para este cenário será utilizado o modelo de resiliência standard, o Virtual network gateway, informe um nome para conexão, insira a "authorization key" e "ExpressRoute ID" (per cirtuit URI) copiados nos passos acima e execute o deploy. Verificando que a conexão foi estabelecida com sucesso. Verificando as rotas na Vm de teste. Ao verificar as rotas do Pfsense ( onprem) , é possível observar que não temos as rotas do AVS, somente da Vnet do Azure. Para habilitar o trânsito e troca de rotas entre o Express Route do AVS e o VPN gateway precisamos inserir o Azure Route Server. 3. Deploy do Azure Route Server. #Criar Azure Route Server #Cria Public IP para o Route Server az network public-ip create --resource-group $RESOURCE_GROUP --name routeserver-pip --sku Standard --allocation-method Static # Identifica o ID da Subnet do Route Server SUBNET_ID=$(az network vnet subnet list --resource-group $RESOURCE_GROUP --vnet-name $VNET_NAME --query "[?name=='$SUBNET_ROUTE_SERVER_NAME'].id" --output tsv) # Cria o Route Server az network routeserver create \ --resource-group $RESOURCE_GROUP \ --name $ROUTE_SERVER_NAME \ --hosted-subnet $SUBNET_ID \ --location $LOCATION \ --public-ip-address routeserver-pip Após criado habilitamos a opção Branch-to-Branch Podemos verificar que agora as rotas do AVS (172.30.0.0/22), agora foram propagadas para o Pfsense. Validando acesso ao Vcenter do AVS. Referências: https://learn.microsoft.com/en-us/azure/route-server/overview https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/hub-spokeAcessar o Azure ARC com Private Endpoint e Azure Firewall Explicit Proxy - Parte 1
Benefícios de Usar o Azure ARC O Azure ARC permite gerenciar recursos de TI, independentemente de onde eles estejam hospedados, seja no Azure, em outras nuvens ou em infraestruturas locais (on-premises). Fonte: Azure Arc overview - Azure Arc | Microsoft Learn Entre os principais benefícios de usar o Azure ARC podemos citar os seguintes. Gestão Centralizada: Permite o gerenciamento de recursos multi-cloud e on-premises Consistência de Ferramentas: Com o Azure ARC, é possível usar as mesmas ferramentas e processos que você já utiliza no Azure para gerenciar recursos em qualquer infraestrutura, proporcionando uma experiência consistente. Segurança e Conformidade: A tecnologia permite aplicar políticas de segurança e conformidade de maneira uniforme em todos os ambientes, garantindo que os padrões corporativos sejam mantidos em qualquer lugar. Escalabilidade: O Azure ARC facilita a escala de operações de TI de acordo com as necessidades do negócio, sem as limitações típicas das infraestruturas locais. Automatização: A automatização de processos de gerenciamento através de scripts e ferramentas Azure Resource Manager (ARM) pode ser estendida a recursos fora do Azure, melhorando a eficiência operacional. Monitoramento e Insights: O Azure ARC integra-se com ferramentas de monitoramento do Azure, permitindo visibilidade centralizada e insights detalhados sobre o desempenho e a integridade de todos os recursos. Ao utilizar o Azure ARC, as organizações podem maximizar os investimentos existentes em infraestrutura, melhorar a governança e aprimorar a flexibilidade e a agilidade operacionais, tudo isso enquanto mantêm uma gestão centralizada e consistente. Benefício de usar Private Endpoints Utilizando o Azure ARC com private endpoints, o tráfego de rede entre os recursos gerenciados e o Azure permanece dentro da rede privada, aumentando a segurança, proteção dos dados e o desempenho. Essa configuração reduz a exposição a ameaças externas e cumpre exigências regulatórias ao assegurar que os dados sensíveis não transitem pela internet pública. Desafios no Acesso ao Azure Arc com Azure Firewall, Explicit Proxy e Private Endpoint Conectar um recurso local ao Azure por meio do Azure Arc e utilizar extensões habilitadas para Arc requer comunicação com um conjunto de serviços do Azure, cada um com seus próprios endpoints de destino. Para clientes que utilizam proxies corporativos, é necessário permitir o acesso a todos esses endpoints. Atualmente, o gateway do Arc reduz o número de url's que precisam ser permitidos por meio de um proxy corporativo, mas exige que o tráfego seja roteado para o Azure pela Internet pública. No entanto, alguns clientes precisam que todo o tráfego alcance o Azure por meio do seu circuito de ExpressRoute ou através da VPN Site a Site. Embora parte dos endpoints necessários podem ser roteados pelo Microsoft Peering ou Private Peering do ExpressRoute, nem todos os endpoints são compatíveis com essas opções. Firewall do Azure como um proxy sobre ER ou VPN site a site Os clientes que precisam que todo o tráfego alcance o Azure por meio do ExpressRoute ou VPN Site-to-Site pode hospedar um proxy de encaminhamento em sua rede virtual do Azure. O agente Arc pode então se comunicar com esse proxy de encaminhamento por meio de um IP privado, seja por meio do ExpressRoute ou VPN Site-to-Site. O Firewall do Azure com o recurso Proxy Explícito (Visualização Pública) pode ser aproveitado como esse proxy de encaminhamento. Disclaimer: O Azure Firewall com Explicit Proxy é um recurso atualmente em preview. Isso significa que ele está sujeito a alterações e pode não estar disponível em todas as regiões ou com todas as funcionalidades de produção. Para mais informações, consulte os termos de uso para preview. O diagrama abaixo representa essa arquitetura Etapas para o uso do Azure Firewall com explicit proxy Passo 1: Precisamos habilitar o uso do Azure Firewall com a feature de Explicit Proxy conforme a documentação de referência aqui Passo 2: Em seguida realizado o onboard dos servidores para o Azure ARC. Observe que o IP privado do Firewall do Azure como o proxy de encaminhamento nas configurações. No Portal do Azure Usando a CLI de comando Servidores ARC azcmagent config set proxy.url <Azure Firewall Private IP:Port> azcmagent config CLI reference - Azure Arc | Microsoft Learn Passo 3: Crie uma regra de aplicativo para permitir os endpoints necessários do Azure ARC para seu cenário de acesso através do Firewall No próximo artigo, vamos montar um laboratório passo a passo, detalhando as configurações e os requisitos necessários para utilizar o private endpoint e o explicit proxy do Azure Firewall, conforme ilustrado no diagrama abaixo Referências: Azure Arc overview - Azure Arc overview - Azure Arc | Microsoft Learn Informações gerais e preço - Azure Arc – Hybrid and Multi-Cloud Management and Solution (microsoft.com) Azure Firewall Explicit Proxy - Azure Firewall Explicit proxy (preview) | 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.
