Randomize MAC Address: Recupere o Controle do WiFi Analytics

! ==============================================================================
! WLAN Controller Profile: Passpoint Hotspot 2.0 and ANQP Identity Architecture
! Purpose: Neutralize MAC randomization impact and enable authenticated CRM roaming
! Network: RFC 1918 Private Subnet (10.10.30.0/24) | Safe RFC 5737 Doc RADIUS
! ==============================================================================

wlan passpoint-profile "PURPLE-SECURE-IDENTITY"
  enable
  he-profile "WIFI-6-AX-ENTERPRISE"
  venue-group "Commercial"
  venue-type "ShoppingMall"
  network-type "FreePublic"
  internet-access
  asra-capability
  ip-addr-type-avail "IPv4-Single-NAT,IPv6"

  ! ANQP Roaming Consortium OI for OpenRoaming / Hotspot 2.0
  roaming-consortium "5A-03-BA-00-00"
  roaming-consortium "BA-A2-F0-00-00"

  ! Domain list matching venue identity domain
  domain-name "guest.purple.ai"
  domain-name "connect.venue.internal"

  ! NAI Realm matching authenticated visitor federations
  nai-realm 1 name "purple.ai"
    eap-method eap-tls
    eap-method eap-ttls
      inner-auth mschapv2

  ! 3GPP Cellular Data Offload PLMN hints
  3gpp-plmn 234-15
  3gpp-plmn 234-30

exit

wlan ssid "Purple-Secure-Passpoint"
  vlan 30
  security wpa3-enterprise
  pmf-mode required
  passpoint-profile "PURPLE-SECURE-IDENTITY"

  ! Client Isolation on internal private broadcast domain
  station-isolation enable

  ! Remote RADIUS AAA Configuration (Safe RFC 5737 doc endpoints, placeholder secrets)
  radius-server primary host 192.0.2.10 auth-port 1812 acct-port 1813
    key <RADIUS_SHARED_SECRET>
    timeout 3
    retransmit 2

  radius-server secondary host 192.0.2.11 auth-port 1812 acct-port 1813
    key <RADIUS_SHARED_SECRET>
    timeout 3
    retransmit 2

  accounting-server-group "PURPLE-RADIUS-CLUSTER"
    interim-update-interval 600
exit

interface vlan 30
  description "Purple Guest Isolated Client Network"
  ip address 10.10.30.1 255.255.255.0
  ip access-group "ISOLATE-INTERNAL-SUBNETS" in
exit

Seu estabelecimento está movimentado. O saguão está cheio, a fila do café dobra a esquina e o seu painel de WiFi mostra que o retorno de visitantes despencou. Dispositivos que se conectaram ontem parecem completamente novos hoje. As sessões de Captive Portal continuam reaparecendo. As tendências de fluxo de pessoas oscilam sem nenhum motivo aparente.

Esse costuma ser o ponto em que as equipes começam a culpar a plataforma de análise, o fornecedor do AP ou uma versão de firmware ruim. Em muitos ambientes, a mudança real é mais simples. Os clientes agora usam a configuração de randomize mac address por padrão, e a rede ainda está tentando tratar os endereços MAC como se fossem identidades estáveis.

Essa incompatibilidade quebra mais do que os relatórios. Ela afeta o controle de acesso, a aplicação de políticas, a solução de problemas e a experiência do visitante. E também não vai desaparecer. Os recursos de privacidade agora estão integrados aos sistemas operacionais convencionais e estão fazendo exatamente o que foram projetados para fazer: dificultar o rastreamento de dispositivos em várias redes.

A resposta prática não é lutar contra o recurso para sempre. É reconhecer que o endereço MAC não é mais uma chave primária confiável para o WiFi moderno e, em seguida, redesenhar em torno de sinais de identidade mais fortes. É aí que o Passpoint, o OpenRoaming, a integração baseada em certificados e o acesso apoiado por diretório começam a ter importância.

O Misterioso Caso dos Dispositivos que Desaparecem

Segunda-feira de manhã, os números de WiFi de convidados parecem errados. Os visitantes recorrentes diminuíram, os novos dispositivos aumentaram e o suporte técnico tem uma fila de usuários que juram que já concluíram a integração na semana passada. Em hotéis, complexos comerciais, hospitais e condomínios residenciais, vi esse padrão desencadear a mesma reação todas as vezes. As equipes começam a verificar controladoras, logs do Captive Portal e notas de firmware, embora a WLAN muitas vezes esteja se comportando exatamente como projetada.

O que mudou foi o sinal de identidade. Os dispositivos dos clientes ainda aparecem. Eles apenas deixam de apresentar um endereço de hardware que você possa tratar como persistente. Um único telefone pode aparecer sob diferentes valores de MAC em varreduras, associações ou SSIDs, dependendo da plataforma e das configurações de privacidade ativas.

Isso quebra a confiança no lugar errado. Se a rede ainda tratar o endereço MAC como a chave primária, o comportamento normal do usuário começa a parecer rotatividade, novo registro ou falha de política.

O que os administradores costumam notar primeiro

As primeiras pistas costumam ser operacionais, não teóricas:

• As contagens de visitantes recorrentes flutuam: Um dispositivo conhecido parece novo, fazendo com que as análises superestimem a aquisição e subestimem a fidelidade.
• As solicitações do Captive Portal retornam: Os usuários se reconectam, mas são tratados como convidados de primeira viagem porque o endereço não corresponde mais à sessão original.
• As políticas baseadas em MAC falham de forma inconsistente: Regras vinculadas a um endereço específico deixam de ser aplicadas depois que o cliente rotaciona a identidade.
• A resolução de problemas fica mais lenta: As equipes de suporte veem vários registros de dispositivos para um único aparelho e perdem tempo analisando o histórico errado.

A rede ainda está transportando o cliente. Ela apenas não possui mais uma forma estável baseada em MAC para reconhecê-lo.

Por que isso vai além dos sistemas de análise

Este não é apenas um problema de relatórios. Os controles dependentes de MAC mostram sinais de desgaste rapidamente quando a rotação de endereços se torna o padrão. Reservas de DHCP, desvio de autenticação MAC, listas de permissões de dispositivos, alguns métodos de perfil de NAC e fluxos de trabalho de convidados mais antigos dependem de uma continuidade que muitos clientes modernos não oferecem mais.

Isso não torna a randomização de MAC um erro. Ela resolve um problema real de privacidade, especialmente em redes WiFi públicas, onde o rastreamento passivo costumava ser muito fácil. O problema operacional é que muitas redes foram construídas em torno de um identificador que os sistemas operacionais agora tratam como descartável.

A solução é arquitetônica. Use o endereço MAC apenas onde ele ainda for útil, depois mude o controle de acesso e as políticas para sinais de identidade mais fortes, como certificados, autenticação de usuário, postura do dispositivo, perfis Passpoint e modelos de federação como OpenRoaming. Se o seu design atual ainda depende muito da identidade de hardware estática, analise onde a autenticação de endereço MAC no WiFi começa a falhar e onde a integração baseada em identidade oferece políticas mais limpas, melhor capacidade de auditoria e análises mais confiáveis.

As redes que se adaptam a esse modelo param de perseguir dispositivos que desaparecem e passam a rastrear usuários autenticados, dispositivos confiáveis e sessões válidas.

O Que É a Randomização de Endereço MAC

Um endereço MAC de fábrica é como um crachá permanente impresso na fabricação. A randomização de endereço MAC é o crachá descartável que um dispositivo escolhe usar, para que as redes próximas não possam rastreá-lo facilmente de um local para outro.

Essa é a justificativa de privacidade em termos simples. Operadores de WiFi público, anunciantes e terceiros costumavam depender muito de MACs estáveis para reconhecimento passivo. A randomização reduz essa visibilidade substituindo o endereço de hardware por um administrado localmente.

Como identificar um endereço randomizado

Existe uma dica técnica rápida que a maioria dos administradores pode usar imediatamente. Um endereço MAC randomizado pode ser identificado porque seu segundo dígito hexadecimal será 2, 6, A ou E, conforme mostrado no guia da Mist sobre randomização de endereços MAC. A mesma orientação observa que políticas legadas que esperam um OUI atribuído pelo fabricante falharão com uma taxa de rejeição de 100% para esses endereços.

Exemplo:

• 92:B1:B8:42:D1:85 indica um endereço administrado localmente
• O segundo dígito hexadecimal é a pista
• Isso importa porque as premissas baseadas em OUI não se aplicam mais

Se o seu controlador WLAN, plataforma NAC ou logs de RADIUS conseguirem expor os MACs dos clientes no momento da associação, você geralmente conseguirá filtrar esse padrão rapidamente.

Por que os designs antigos de WiFi falham

Os designs de WiFi legados assumiam que um endereço MAC representava um dispositivo de forma consistente o suficiente para ancorar o acesso e a política. É por isso que tantos ambientes ainda o utilizam para:

• Decisões de acesso: ACLs de MAC e desvio de autenticação de MAC
• Gerenciamento de endereços: Mapeamentos DHCP estáticos
• Atalhos de segmentação: Atribuição de VLAN ou função específica do dispositivo
• Integração legada: Mapeamentos simples de chaves pré-compartilhadas

Esses fluxos de trabalho faziam sentido quando o identificador de hardware permanecia inalterado. Eles não se sustentam quando os clientes realizam a randomização por design.

Para uma análise mais detalhada de onde isso colide com a integração legada, este guia de autenticação de endereço MAC para WiFi é uma leitura complementar útil.

Regra prática: Se a sua política depende de OUIs do fabricante, assuma que ela irá classificar incorretamente os dispositivos clientes com privacidade ativada.

A Evolução da Randomização em Diferentes Dispositivos

A mudança não atingiu todas as redes WLAN de uma vez. Uma rede construída na era da randomização por escaneamento poderia parecer saudável por anos, para então começar a exibir dispositivos duplicados, falhas de integração recorrentes e análises imprecisas após uma atualização de rotina dos aparelhos. A infraestrutura permaneceu a mesma. O modelo de identidade do cliente mudou.

Da privacidade de varredura à identidade de conexão

A randomização de MAC inicial protegia principalmente o tráfego de sondagem. Os dispositivos mascaravam a identidade enquanto procuravam redes e, depois, costumavam usar um endereço estável ao se conectarem. Isso ainda quebrava as análises passivas de fluxo de pessoas e alguns serviços de localização, mas muitas políticas de WLAN de produção sobreviveram porque o MAC do cliente associado permanecia previsível o suficiente para o controle de acesso.

Uma quebra operacional significativa ocorreu mais tarde, quando as principais plataformas de clientes começaram a aplicar a randomização à associação como um comportamento padrão de privacidade. Nesse ponto, o MAC deixou de ser uma âncora confiável para integração, aplicação e relatórios. Administradores que toleravam sondagens randomizadas de repente tiveram que lidar com identidades randomizadas na sessão ativa.

Essa distinção é importante. A randomização de sondagem afetava principalmente os observadores. A randomização de associação afeta os sistemas em que você confia todos os dias.

Os sistemas operacionais também seguiram caminhos diferentes. A Apple adotou padrões de privacidade rígidos desde cedo e continuou a aprimorá-los. O Android adotou a mesma direção geral, mas o comportamento ainda varia de acordo com o fabricante, o chipset e a política de gerenciamento. O Windows costuma ser o mais misto, especialmente em laptops que transitam entre SSIDs corporativos gerenciados e redes domésticas ou de convidados não gerenciadas.

Comportamento de Randomização de MAC por Sistema Operacional em 2026

Sistema Operacional	Comportamento Padrão	Escopo de Aleatorização	Notas do Administrador
iOS	Habilitado por padrão em redes WiFi modernas	Geralmente persistente por SSID	Fortes padrões de privacidade. Controles legados baseados em MAC costumam falhar, a menos que o SSID seja gerenciado explicitamente.
Android	Habilitado por padrão em versões modernas	Geralmente por SSID, com alguma variação por dispositivo e política	Diferenças de fornecedores são importantes. Teste Samsung, Pixel, Zebra e outros tipos de frota separadamente.
Windows 10 and 11	Varia de acordo com o perfil e a capacidade do dispositivo	Pode ser baseado em perfil, com comportamentos opcionais de rotação	Atenção a notebooks de uso misto. SSIDs corporativos podem precisar de configurações gerenciadas, enquanto SSIDs de convidados podem permanecer amigáveis à privacidade.

Por que o cronograma importa do ponto de vista operacional

Muitos projetos corporativos ainda refletem premissas do período de transição. Uma equipe pode se lembrar de que a randomização era "principalmente um problema de varredura" e subestimar o que mudou depois que as versões mais recentes do sistema operacional tornaram os MACs privados parte do comportamento normal de associação. É assim que os fluxos de trabalho legados de MAB, reservas DHCP específicas do dispositivo e registros de convidados vinculados ao MAC permanecem em produção muito tempo depois que o lado do cliente deixou de cooperar.

Isso também faz parte de uma tendência de privacidade mais ampla, não de uma peculiaridade isolada do WiFi. O modelo de privacidade do iCloud Private Relay da Apple aponta na mesma direção. Os fornecedores de endpoints estão reduzindo os identificadores passivos em toda a pilha, o que significa que as equipes de rede precisam de métodos de identidade que sobrevivam a essa mudança.

A resposta prática não é forçar a identidade permanente de hardware de volta ao design. É mover a decisão de confiança para cima na pilha. O Passpoint, a integração baseada em certificados e o OpenRoaming oferecem aos administradores uma maneira estável de identificar usuários e dispositivos sem depender de um MAC de fábrica, que as plataformas modernas tratam cada vez mais como privado.

Se um design de WiFi depende de um endereço de hardware permanente para reconhecer um cliente, esse design está ficando obsoleto. O acesso baseado em identidade oferece um caminho mais limpo do que tentar recuperar a visibilidade do MAC.

Como a Randomização Interrompe as Operações de Rede

A maneira mais clara de descrever o estrago é esta. A randomização rompe o antigo atalho entre "dispositivo visto" e "dispositivo conhecido". Assim que esse atalho desaparece, várias práticas operacionais comuns se desfazem ao mesmo tempo.

Mais de 30% dos dispositivos móveis usam a randomização de MAC por padrão, e isso cria uma relação de 1 para muitos entre um dispositivo físico e seus MACs relatados, o que complica a contagem de dispositivos exclusivos e prejudica a análise e a personalização, de acordo com a análise da CUJO sobre o impacto nos operadores de serviços de rede.

Controles de segurança que deixam de ser confiáveis

As primeiras baixas costumam ser os controles baseados em MAC:

• As ACLs de MAC perdem o sentido: um dispositivo pode apresentar um endereço diferente daquele que você aprovou.
• Os fluxos de trabalho do tipo MAB tornam-se frágeis: a lista de permissões é tão estável quanto o identificador que ela contém.
• As reservas estáticas de DHCP falham: a reserva pertence a um endereço que o cliente pode não usar mais.
• Os mapeamentos de iPSK legados se fragmentam: um único usuário ou aparelho pode parecer vários endpoints.

Isso nem sempre falha de forma óbvia. É isso que o torna operacionalmente caro. As equipes veem reclamações de acesso intermitente, incompatibilidades de políticas ou funções de dispositivos aplicadas de forma inconsistente, e a causa raiz fica uma camada abaixo do sintoma.

Análises que se tornam mais difíceis de confiar

Para os estabelecimentos, o impacto nas análises é frequentemente o problema de negócios mais visível. Fluxo de pessoas, tempo de permanência, taxa de retorno e análise de jornada dependem de certa confiança de que observações repetidas pertencem à mesma entidade. A randomização enfraquece essa confiança.

Um shopping center ainda pode ter um tráfego forte, mas as visitas recorrentes podem parecer fracas porque aparelhos antes familiares agora aparecem sob novos identificadores. Um hotel pode pensar que tem mais hóspedes novos na rede do que realmente tem. Um local de saúde pode ter dificuldades para separar claramente a mobilidade dos funcionários da atividade dos visitantes.

Se a sua equipe depende de relatórios de presença e comportamento, este guia de WiFi analytics é uma referência útil para as métricas que têm mais probabilidade de serem afetadas.

Problemas de experiência do usuário que se escondem à vista de todos

Alguns dos problemas mais complexos ocorrem no limite da autenticação:

• Captive Portals podem solicitar novas credenciais aos usuários inesperadamente
• Os fluxos de reautenticação tornam-se inconsistentes entre as visitas
• A resolução de problemas torna-se mais lenta porque o MAC de ontem não é o MAC de hoje
• O histórico do dispositivo fica fragmentado nos registros do suporte

As equipes de operações frequentemente descrevem isso como "WiFi instável" quando a RF está boa e a falha real é a continuidade da identidade.

Técnicas Práticas para Detecção e Mitigação

Você não pode modernizar uma propriedade se primeiro não quantificar o problema. O objetivo imediato não é eliminar a randomização. É identificar onde ela está surgindo, quais fluxos de trabalho dependem de MACs estáveis e quais SSIDs estão mais expostos.

Comece com a detecção nas ferramentas que você já executa

A maioria das arquiteturas de WLAN corporativas já expõe telemetria suficiente para identificar endereços de privacidade. Em plataformas como Meraki, Aruba, Mist, Ruckus e similares, inspecione as listas de clientes, falhas de autenticação e histórico de sessões em busca de padrões de MAC administrados localmente. Associe isso aos logs de RADIUS se você utilizar NAC ou mecanismos de políticas.

Procure por três coisas:

1. Clientes com o segundo dígito hexadecimal igual a 2, 6, A ou E
2. Falhas repetidas de integração vinculadas ao mesmo usuário, mas com MACs diferentes
3. Anomalias específicas de SSID, especialmente em redes de convidados, BYOD e residenciais compartilhadas

Uma revisão interna simples frequentemente revela que a randomização não é distribuída uniformemente. Os SSIDs de visitantes costumam mostrá-la primeiro. Os SSIDs de funcionários começam a apresentar problemas quando dispositivos não gerenciados ou pouco gerenciados se conectam. Ambientes multi-tenant costumam ser os mais afetados porque a rede tenta suportar dispositivos de consumo e a aplicação de políticas ao mesmo tempo.

Decida onde o bloqueio é defensável

Muitas equipes fazem a mesma pergunta em seguida. Devemos bloquear MACs randomizados? A resposta honesta é que isso pode ser útil como um controle temporário em um conjunto restrito de casos, mas é uma estratégia ruim a longo prazo.

O bloqueio pode ajudar quando:

• Um SSID corporativo exige uma postura rígida de dispositivos gerenciados
• Você precisa preservar um fluxo de trabalho legado enquanto uma substituição está sendo implantada
• Uma classe de dispositivo específica deve usar uma identidade fixa e conhecida por motivos operacionais ou de conformidade

O bloqueio geralmente traz resultados indesejados quando:

• O SSID é público, voltado para visitantes ou com alta rotatividade
• Os usuários não conseguem entender facilmente como desativar o recurso
• Sua equipe de suporte não está equipada para instruir cada variação de sistema operacional
• Você precisa de acesso sem atrito, não de outro caminho de exceção

A compensação é simples. O bloqueio restaura um pouco de controle, mas geralmente prejudica a experiência do usuário e gera custos de suporte evitáveis.

Mitigações táticas que funcionam hoje

Vale a pena usar mitigações de curto prazo se elas garantirem tempo para uma reformulação adequada:

• Segmente por caso de uso: Mantenha o acesso gerenciado da equipe separado do acesso de convidados e BYOD.
• Use MDM onde você controla os dispositivos: Em SSIDs corporativos, envie perfis de rede em vez de depender que os usuários alterem as configurações de privacidade manualmente.
• Elimine premissas dependentes de MAC: Audite reservas de DHCP, atalhos de NAC e regras específicas de dispositivos.
• Documente fluxos de trabalho de exceção: Se um dispositivo médico, impressora ou console precisar de uma identidade estável, trate-o como uma exceção específica, não como o modelo padrão.

Nenhuma dessas correções resolve o problema de identidade subjacente. Elas apenas impedem que ele se espalhe por todos os cantos das operações.

Abraçando o Futuro com Redes Baseadas em Identidade

A resposta mais forte à randomização de MAC é parar de tratar o endereço MAC como o centro da confiança. Essa é a mudança fundamental de design. A rede baseada em identidade move o ponto de decisão de um token de hardware mutável para algo em que a rede pode confiar: um usuário, um certificado, um objeto de diretório, uma decisão de postura de dispositivo ou um estado de integração federado.

Por que o Passpoint e o OpenRoaming mudam a equação

O Passpoint e o OpenRoaming tornam-se, portanto, mais do que recursos de conveniência. Eles reduzem a dependência de Captive Portals e senhas compartilhadas, e permitem que a rede tome decisões de confiança antes mesmo que o antigo fluxo de trabalho de visitantes comece.

Isso é importante porque 72% dos dispositivos móveis do Reino Unido agora randomizam MACs por padrão, e redes sem o suporte adequado podem apresentar até 40% de falhas de autenticação no primeiro pacote. O mesmo rascunho da IETF observa que a implementação do Hotspot 2.0 com dicas de randomização ANQP pode reduzir as reassociações em 35%, e é por isso que o rascunho da IETF sobre randomização de endereços MAC merece uma leitura atenta por parte dos arquitetos que planejam ambientes de visitantes e residenciais.

O Passpoint muda o modelo de "quem é este MAC?" para "este dispositivo tem uma relação de integração válida para esta rede?". Essa é uma pergunta muito melhor.

Como é um design moderno

Uma arquitetura prática geralmente apresenta as seguintes características:

• O acesso de convidados usa Passpoint ou OpenRoaming: O usuário se autentica uma vez e obtém conectividade criptografada desde o primeiro pacote nas visitas seguintes.
• O acesso da equipe usa identidade integrada ao diretório: Entra ID, Google Workspace ou Okta podem ancorar o acesso com base na pessoa e no status do dispositivo gerenciado.
• Certificados substituem segredos compartilhados sempre que possível: Eles escalam melhor e sobrevivem às mudanças de privacidade de forma muito mais limpa do que a lógica vinculada ao MAC.
• Dispositivos legados ganham uma rota de exceção controlada: O iPSK ainda tem espaço para impressoras, IoT e endpoints complexos, mas não deve definir todo o seu modelo de acesso.

Por que isso é melhor do que tentar reverter a privacidade

Você pode passar meses tentando convencer os usuários a desativar os recursos de privacidade, escrevendo artigos de suporte para cada modelo de celular e lidando com comportamentos inconsistentes após cada atualização de sistema operacional. Ou você pode migrar a rede para um design que assume que os clientes protegerão sua identidade por padrão.

O segundo caminho é mais sustentável. Ele também melhora a segurança. Senhas compartilhadas, Captive Portals frágeis e consultas de MAC sempre foram concessões. A randomização apenas expôs o quão fracas essas concessões haviam se tornado.

O objetivo não é restaurar o antigo modelo de visibilidade. O objetivo é construir uma rede que não precise mais dele.

Perguntas Frequentes Sobre Randomização de MAC

A randomização de MAC melhora a segurança ou apenas a privacidade

Principalmente privacidade. Ajuda a evitar o rastreamento entre redes, ocultando o endereço de hardware permanente. Isso não prova automaticamente que o usuário é confiável, que o dispositivo está em conformidade ou que a sessão é segura. É por isso que os controles de identidade, certificado e postura ainda importam.

Devemos pedir aos usuários para desativá-la

Apenas em casos restritos. Para dispositivos de funcionários gerenciados em um SSID corporativo, isso pode ser razoável se a configuração for enviada por meio de MDM e vinculada a uma política clara. Para visitantes, residentes ou usuários casuais, pedir às pessoas para desativarem um recurso de privacidade costuma ser uma experiência ruim e um fardo para o suporte.

Por que o setor de habitação estudantil e Build-to-Rent é tão afetado

Porque esses ambientes geralmente misturam dispositivos de consumo, padrões legados de integração e alta sensibilidade ao suporte. No Reino Unido, o setor de Build-to-Rent e moradias estudantis registraram um aumento de 31% nas reclamações de acesso WiFi, com 55% vinculadas a MACs randomizados fragmentando as políticas de iPSK, de acordo com este guia sobre problemas de endereços MAC randomizados.

O que funciona melhor em ambientes multi-tenant

Separe o problema em etapas. Use a integração baseada em identidade para residentes e funcionários, mantenha as exceções legadas sob rígido controle e evite projetar a rede dependendo da visibilidade persistente de MAC. Quanto mais um site depende de iPSK como a resposta universal, mais frágil ele se torna à medida que os recursos de privacidade do cliente se expandem.

---

Se você está repensando o WiFi para visitantes, funcionários ou múltiplos inquilinos com base em identidade em vez de endereços de hardware, a Purple foi feita para essa transição. Ela suporta Passpoint e OpenRoaming, integra-se com Entra ID, Google Workspace e Okta, e ajuda a substituir senhas compartilhadas e o atrito do Captive Portal por um acesso seguro e sem senha que funciona em ambientes de hotelaria, varejo, saúde, transporte e residenciais.