Rastreamento de Sessão de Locatário e Atribuição de Abuso em WiFi MDU: Mapeando Fluxos Meraki para Identidade iPSK da Purple

Para atribuir abusos em uma rede MDU de IP público único, você junta dois registros. A exportação de fluxo do Meraki MX mapeia o IP público, a porta de origem traduzida e o carimbo de data/hora de volta para um IP interno, MAC e VLAN. O iPSK de identidade do Purple e os registros de contabilidade RADIUS mapeiam esse MAC e VLAN para um apartamento. Mantenha ambos por 365 dias, sujeito a assessoria jurídica.

O que a atribuição de abuso realmente faz em uma rede MDU?

O Purple Multi-Tenant WiFi oferece a cada residente em uma unidade multifamiliar (MDU), bloco de aluguel residencial (BTR) ou residência estudantil uma rede privada que parece a banda larga doméstica. Por trás dessa experiência existe um fato arquitetônico incontestável. Cada residente sai do edifício através do mesmo endereço WAN público, usando tradução de endereço de porta (PAT). O PAT é uma forma de NAT em que muitos hosts internos compartilham um único IP público, distinguidos apenas pela porta de origem que o gateway atribui. Quando um detentor de direitos autorais, uma central de denúncias de abusos ou um policial procura por você, eles veem um único IP. Eles esperam um único assinante por trás dele. Você tem centenas.

A atribuição de abuso reconstrói esse mapeamento perdido. Ela faz isso a partir de dois planos de dados independentes: os fluxos de rede do gateway e os registros de identidade do Purple. Nenhum deles é suficiente sozinho. Juntos pelo endereço MAC, VLAN e horário, eles levam você de um IP público e porta até um apartamento identificado.

Por que um único IP público quebra a atribuição

Uma notificação típica sob a Lei de Direitos Autorais do Milênio Digital dos EUA (DMCA), 17 U.S.C. § 512, carrega três campos: IP público, porta de origem e carimbo de data/hora. O RFC 6302, a orientação do IETF para servidores voltados para a internet, recomenda registrar a porta de origem e um carimbo de data/hora preciso justamente porque o endereçamento compartilhado torna o IP isolado ambíguo. Seu trabalho é honrar esse design. Se os seus registros contiverem a porta traduzida e um relógio disciplinado, a notificação se torna respondível. Se não contiverem, você poderá identificar o edifício e nada mais.

O que o iPSK contribui

Este guia assume que você já sabe o que é iPSK (Identity Pre-Shared Key). Os guias do Purple "Implementing iPSK for secure IoT" e "iPSK vs 802.1X: a comparison" cobrem esse pré-requisito. Em resumo, o iPSK emite para cada inquilino uma senha exclusiva em um SSID compartilhado, e o servidor RADIUS vincula essa chave a uma identidade. O RADIUS (Remote Authentication Dial-In User Service, RFC 2865) autentica a sessão. A contabilidade RADIUS (RFC 2866) registra quando ela começa, quanto tempo dura e quando termina. Este guia cobre a camada operacional acima disso: transformar esses registros de identidade em evidências que você pode entregar ao departamento jurídico.

O que você precisa antes de começar?

Você precisa de quatro coisas implementadas antes que a primeira notificação chegue. Construí-las após o ocorrido não funciona, pois as evidências que você precisa já terão sumido.

1. Um design de VLAN-por-iPSK. A chave de cada inquilino coloca seus dispositivos em um segmento de camada 3 dedicado antes do limite do NAT.
2. Uma exportação de fluxo do Meraki MX contendo o endereçamento pré-NAT e pós-NAT com carimbos de data/hora.3. Purple RADIUS Accounting habilitado, mais uma exportação regular do mapeamento de iPSK para inquilino.
3. Uma política de retenção assinada pela assessoria jurídica, e NTP em execução em todos os dispositivos da cadeia.

Por que a VLAN por iPSK supera um SSID compartilhado simples

Uma VLAN (LAN virtual) é um segmento lógico de camada 2, definido no IEEE 802.1Q, que isola um grupo de dispositivos de outro. A resposta RADIUS da Purple pode atribuir uma VLAN por iPSK, para que cada apartamento termine em sua própria sub-rede. Essa sub-rede se torna um segundo identificador independente. Mesmo que um MAC seja forjado ou randomizado, o IP de origem interno ainda identifica o segmento do apartamento.

Design	Granularidade de atribuição	Sobrevive à randomização de MAC	Isolamento de inquilinos	A quem se adequa
SSID compartilhado simples, uma PSK	Apenas edifício	Não	Nenhum por padrão	Rede WiFi para pequenos cafés ou recepção, não residencial
SSID compartilhado, iPSK, sem VLANs	MAC do dispositivo para o inquilino	Parcialmente, via registro de accounting no momento da sessão	Apenas isolamento de cliente	Etapa intermediária durante a migração
iPSK com VLAN por inquilino	Sub-rede do apartamento e MAC	Sim, a sub-rede ainda identifica o apartamento	Segmentação de camada 3 por apartamento	MDU, BTR, alojamento estudantil, apartamentos com serviços
802.1X com credenciais por pessoa	Indivíduo nomeado	Sim	Política por usuário	Escritórios corporativos multi-inquilino com dispositivos gerenciados

Para propriedades residenciais, a VLAN por iPSK é o padrão correto. Ela oferece dois identificadores que devem coincidir: a VLAN e o MAC. O 802.1X (o padrão IEEE de controle de acesso baseado em porta) alcança o indivíduo. No entanto, ele apresenta dificuldades com consoles de jogos, smart TVs e outros dispositivos que os moradores trazem.

Como configurar as duas capturas de dados?

Captura 1: fluxos de rede a partir do Meraki MX

O Meraki MX pode enviar dados de eventos e fluxos por Syslog (RFC 5424) e exportar registros de tráfego por NetFlow versão 9 (RFC 3954). Configure ambos no Meraki Dashboard nas configurações de relatório do equipamento. Siga a própria documentação da Cisco Meraki para os caminhos de menu atuais.

O que importa é o conjunto de campos que chega ao seu coletor. Para cada conexão traduzida, você precisa de:

• IP de origem interno e porta de origem
• Endereço MAC do cliente, ou uma associação IP para MAC confiável a partir dos logs de DHCP
• VLAN ou sub-rede de origem
• IP público pós-NAT e porta de origem traduzida
• Carimbos de data/hora de início e término, com resolução de milissegundos onde o exportador suportar

A porta pós-NAT é o campo que os operadores mais frequentemente sentem falta. No IPFIX (RFC 7011), os elementos de informação relevantes são postNATSourceIPv4Address e postNAPTSourceTransportPort, ambos definidos no registro IANA IPFIX. Antes de confiar na exportação, capture uma amostra. Confirme se o seu firmware preenche a porta traduzida. Se não preencher, sua alternativa é o firewall do MX e o Syslog de fluxo combinados com um log de tradução NAT de um dispositivo upstream que faça esse registro. Resolva isso antes de precisar.

Combine os dados de fluxo com os logs de concessão DHCP. As concessões fornecem uma associação IP para MAC vinculada ao tempo. Essa associação é a sua rede de segurança quando um registro de fluxo carrega o IP, mas não o MAC.

Captura 2: identidade do Purple

O Purple contribui com a metade de identidade da junção. Os registros de RADIUS Accounting carregam o MAC do cliente no atributo Calling-Station-Id, o access point no Called-Station-Id e os horários de início e término da sessão. O Accounting é uma parte padrão da configuração de RADIUS do Purple em todos os fabricantes compatíveis. O artigo de suporte do Purple para Avaya mostra uma configuração típica, com o accounting ativado e um intervalo de accounting temporário definido.

Esse mesmo artigo sinaliza um detalhe que pode comprometer sua junção. Os fabricantes formatam endereços MAC de maneiras diferentes: hifenizado em letras maiúsculas em um, separado por dois pontos em letras minúsculas em outro. Normalize cada MAC para um único formato na ingestão, em ambos os planos de dados.

O segundo dado de identidade é o mapa iPSK para inquilino: qual chave pertence a qual apartamento e qual VLAN ela atribui. Exporte isso diariamente do Purple. Assim, você terá uma captura datada de quem possuía cada chave no dia em questão, e não apenas de quem a possui hoje. Os contratos de aluguel mudam. Uma chave que pertence ao apartamento 4.12 hoje pode ter pertencido a um residente anterior há seis meses.

Construindo o pipeline por conta própria

Se você ainda não centraliza o Meraki Syslog, um pipeline leve de código aberto dá conta do recado. Uma pequena máquina virtual Linux é suficiente para a maioria das propriedades de site único.

1. Coletor. Execute o Fluentd ou o Logstash. Monitore a porta UDP 514, a porta Syslog atribuída pela IANA, e a porta NetFlow de sua escolha; a porta UDP 2055 é a convenção comum. O Logstash analisa o NetFlow v9 e o IPFIX com seu codec netflow.
2. Normalize na ingestão. Converta todos os carimbos de data/hora para UTC. Converta todos os MACs para um único formato. Marque cada registro com o site e a VLAN.
3. Armazene. Direcione para o Elasticsearch ou Grafana Loki. No Elasticsearch, uma política de Gerenciamento do Ciclo de Vida do Índice (ILM) rotaciona os índices diariamente e os exclui no seu limite de retenção. No Loki, o compactador impõe um período de retenção. De qualquer forma, a exclusão é automática e auditável.
4. Captura de identidade. Agende uma tarefa cron diária que extraia o mapa iPSK para inquilino ativo do Purple. Grave-o em uma tabela de consulta local datada. Mantenha as capturas no mesmo cronograma de retenção dos fluxos.
5. Controle de acesso. Restrinja o acesso de consulta a funcionários nomeados. Registre cada pesquisa. Esses registros identificam os residentes, portanto, trate-os como dados pessoais nos termos do GDPR.

O resultado: no momento de uma intimação judicial, você realiza a junção offline, com seus próprios dados, sem depender de terceiros.

Como responder a uma notificação de abuso?

Quando uma notificação chegar, execute o mesmo fluxo de trabalho todas as vezes.

Notificação de abuso
(IP público, porta de origem, carimbo de data/hora)
        |
        v
[1] Log de fluxo Meraki
    corresponder IP pós-NAT + porta traduzida
    dentro da tolerância de relógio de +/- 
        |
        v
(IP interno, MAC, VLAN)
        |
        v
[2] Purple RADIUS Accounting
    corresponder MAC com sessão ativa no carimbo de data/hora
        |
        v
[3] Instantâneo iPSK por tenant datado
    corresponder iPSK + VLAN naquela data
        |
        v
Apartamento / ocupante registrado

Três verificações mantêm o resultado defensável:

• Disciplina de fuso horário. Converta o carimbo de data/hora da notificação para UTC primeiro. Muitas notificações chegam no horário local do remetente.
• Acordo entre identificadores. A VLAN do registro de fluxo deve corresponder à VLAN que o iPSK atribui. Uma divergência significa que algo está errado. Pare e investigue antes de nomear qualquer pessoa.
• A assessoria jurídica decide a divulgação. Seu resultado é um registro de atribuição interno. Divulgar ou não, notificar o morador ou contestar é uma decisão jurídica.

Exemplo prático: da notificação ao apartamento

Esta cadeia usa endereços de documentação (RFC 5737) e valores fictícios.

1. Notificação. Um detentor de direitos relata um evento de compartilhamento de arquivos de 203.0.113.10, porta de origem 41822, às 22:17:05 UTC em 14 de março.
2. Consulta de fluxo. Você pesquisa no índice de fluxo do MX o IP pós-NAT 203.0.113.10 e a porta traduzida 41822, entre 22:17:03 e 22:17:07. Um registro corresponde. Origem interna 10.40.12.37, porta 51544, VLAN 412.
3. IP para MAC. O log de concessão DHCP mostra 10.40.12.37 vinculado ao MAC 3C-22-FB-1A-7E-09 das 19:02 às 23:58 daquele dia.
4. Consulta de identidade. O Purple RADIUS Accounting mostra aquele MAC com uma sessão ativa das 19:02 às 00:41. A sessão foi autenticada com o iPSK atribuído à VLAN 412.
5. Busca de tenant. O instantâneo do iPSK de 14 de março mapeia essa chave e a VLAN 412 para o apartamento 4.12. Você entrega a cadeia para a assessoria jurídica.

Cada etapa é um registro com carimbo de data/hora de um sistema independente. Essa independência é o que torna a cadeia confiável.

Como você verifica se a cadeia funciona?

Não espere por uma notificação real para descobrir uma lacuna. Realize um teste trimestral:

• A partir de um dispositivo de teste em um iPSK conhecido, abra uma conexão com um servidor externo que você controla. Registre o IP público, a porta e a hora dos logs desse servidor.
• Execute todo o fluxo de trabalho às cegas, começando apenas pelo registro do lado do servidor.
• Confirme se você chegou ao apartamento de teste correto. Anote quanto tempo levou.
• Verifique se o registro mais antigo em cada índice está no seu limite de retenção e não além. A retenção excessiva é um problema de GDPR por si só.

Se o teste falhar, a causa mais comum é a falta de uma porta pós-NAT ou um desvio de relógio. Ambos são abordados abaixo.

O que quebra a cadeia de atribuição e como corrigir?

Desvio de relógio

A junção depende do tempo. As portas traduzidas são reutilizadas em segundos em um gateway movimentado, de modo que alguns segundos de desvio podem corresponder ao fluxo errado. Aponte o MX, seus pontos de acesso, o coletor e qualquer dispositivo NAT upstream para as mesmas fontes NTP (Network Time Protocol, RFC 5905). Registre tudo em UTC. Alerte quando o desvio de qualquer dispositivo exceder um segundo. Se dois fluxos corresponderem dentro da sua janela de tolerância, relate a ambiguidade à assessoria jurídica em vez de escolher um.

Carrier-grade NAT upstream

Alguns provedores de internet (ISPs) colocam sua WAN atrás de um NAT de nível de operadora (CGNAT, descrito na RFC 6888). O endereço público do seu MX é, portanto, privado por si só. A notificação trará o endereço compartilhado e a porta do ISP. Somente o ISP pode mapear isso para sua WAN, e somente seus logs podem mapear sua WAN para um apartamento. Seus registros tornam-se o único registro de atribuição dentro do edifício. Pergunte ao seu ISP se você está atrás de um CGNAT e solicite um IP público dedicado sempre que possível.

Compartilhamento de PSK entre inquilinos

Se um morador fornecer seu iPSK a um vizinho, ambas as residências aparecerão como um único apartamento. Imponha o registro de dispositivos: limite o número de dispositivos por iPSK e exija que os moradores registrem novos dispositivos através do Purple. Revise as chaves cujo número de dispositivos ou sessões simultâneas aumente repentinamente. Altere uma chave no mesmo dia da desocupação, como parte do seu processo de admissões, mudanças e desligamentos.

Randomização de MAC

As versões atuais do iOS e Android apresentam um MAC privado por rede por padrão, e algumas configurações o rotacionam. É por isso que você se baseia no registro de RADIUS Accounting ativo no carimbo de data/hora, e não em um registro estático de dispositivos inscritos. Com VLAN por iPSK, a sub-rede ainda identifica o apartamento, mesmo quando um MAC é novo.

Por quanto tempo você deve manter os logs?

A retenção é uma questão jurídica. Alinhe isso com sua assessoria jurídica local antes de configurar qualquer coisa. Como base de trabalho, a maioria dos operadores mantém registros de fluxo e identidade por 365 dias. Isso cobre o tempo que uma intimação cível ou solicitação policial geralmente leva para chegar.

Duas pressões puxam em direções opostas. Sob o Artigo 5(1)(e) da GDPR, você pode manter dados pessoais apenas pelo tempo que a finalidade exigir. No Reino Unido, o Investigatory Powers Act 2016 limita as notificações de retenção de dados a 12 meses. Nos EUA, as intimações do DMCA § 512(h) podem chegar bem após o evento. Escreva o período acordado em seu aviso de privacidade e nos termos de locação. Em seguida, deixe que a retenção do ILM ou Loki o imponha automaticamente.

Quanto custa e qual é o retorno?

A estrutura de processamento própria roda em uma máquina virtual modesta mais armazenamento. Dimensione o armazenamento medindo o volume de fluxo de uma semana, multiplicando por 52 e adicionando uma margem de segurança. A contribuição do Purple, a camada de identidade iPSK e o RADIUS Accounting, roda nos pontos de acesso que você já possui. O Purple é agnóstico em relação a hardware, sendo compatível com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet, sem necessidade de substituição de infraestrutura.

O retorno é medido pela interrupção evitada. Dois cenários ilustrativos mostram a diferença.

Cenário 1: flats de alto padrão em um complexo hoteleiro

Um bloco de 180 apartamentos servidos, operado em conjunto com uma operação de hotel, recebeu repetidos avisos de direitos autorais em uma rede compartilhada simples. Sem nenhuma maneira de atribuí-los, a operadora enviou um aviso por e-mail para todos os residentes. Seguiram-se reclamações e o provedor de internet ameaçou a suspensão. A operadora mudou para VLAN-per-iPSK em sua infraestrutura Meraki existente e implementou o pipeline Logstash mencionado acima. O aviso seguinte foi resolvido para um único apartamento em menos de 20 minutos. Apenas esse residente foi contatado, e não foram necessários mais avisos para todo o edifício.

Cenário 2: habitação para trabalhadores essenciais do setor público

Um bloco de 90 apartamentos para trabalhadores essenciais, de propriedade do conselho, próximo a um hospital, recebeu uma solicitação de dados da polícia sobre um IP público e uma porta. A equipe de habitação tinha iPSK e VLANs por apartamento, mas mantinha apenas 30 dias de logs. O evento ocorreu fora dessa janela. Após revisão jurídica, a equipe estendeu a retenção para 365 dias, adicionou o snapshot diário de identidade e iniciou simulações trimestrais. Uma solicitação posterior foi respondida em um dia útil, identificando um apartamento, com cada etapa documentada para os consultores jurídicos.

Onde isso se encaixa em sua infraestrutura mais ampla

O mesmo problema surge em escritórios corporativos multi-tenant. Uma operadora de coworking, ou um provedor SaaS que executa uma infraestrutura compartilhada entre clientes inquilinos, enfrenta um IP público e muitas organizações por trás dele. O Purple Staff WiFi aplica o mesmo modelo baseado em identidade primeiro lá, normalmente com 802.1X e Microsoft Entra ID, Okta ou Google Workspace como fonte de identidade. A integração de fluxo descrita aqui é aplicada de forma idêntica. O mesmo padrão atende a empreendimentos de varejo de uso misto com apartamentos acima das lojas e propriedades de saúde com alojamento para funcionários.

Para mais informações, consulte os guias Purple Multi-Tenant WiFi e os guias de iPSK da Purple, "Implementing iPSK for secure IoT" e "iPSK vs 802.1X: a comparison". Se você estiver comparando provedores de RADIUS na nuvem para essa função, leia IronWiFi Alternatives for Enterprise Deployments.

Perguntas frequentes

Precisamos substituir nosso hardware Meraki para obter atribuição no nível do inquilino?

Não. O Purple funciona como uma camada de sobreposição na nuvem sobre os seus pontos de acesso e dispositivos MX existentes da Cisco Meraki. Você ativa o iPSK com atribuição de VLAN por meio do RADIUS do Purple, ativa o RADIUS Accounting e configura a exportação de fluxo no MX. A mesma abordagem funciona em HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. O gateway só precisa exportar o endereçamento pré-NAT e pós-NAT com carimbos de data/hora.

O Purple armazena os logs de fluxo do Meraki para nós?

Não. O Purple retém a metade de identidade da cadeia: atribuições de iPSK, mapeamento de VLAN e sessões de RADIUS Accounting. Os registros de fluxo e NAT do Meraki permanecem em um coletor que você controla, seja Elasticsearch, Grafana Loki ou um SIEM existente. Essa divisão mantém você no controle da retenção, do controle de acesso e da divulgação. Essas são decisões que seus consultores jurídicos devem tomar, não terceiros.

Por quanto tempo devemos reter logs de fluxo e de identidade?

A maioria das operadoras retém ambos por 365 dias, mas a retenção é uma decisão legal do seu conselho. O Artigo 5(1)(e) da GDPR limita a retenção ao que o propósito exige. No Reino Unido, os avisos de retenção de dados sob a Investigatory Powers Act 2016 são limitados a 12 meses. Seja qual for o período acordado, publique-o em seu aviso de privacidade e force a exclusão automática com retenção de ILM ou Loki.

O registro de logs de tráfego de residentes é compatível com a GDPR?

Sim, desde que você registre metadados de conexão, não o conteúdo, e os trate como dados pessoais. Registre uma base legal, normalmente interesses legítimos ou obrigação legal, e declare a finalidade e o período de retenção em seu aviso de privacidade. Restrinja o acesso a consultas a funcionários nomeados e audite cada pesquisa. O Purple possui certificação ISO 27001 e está em conformidade com a GDPR, de modo que o lado da identidade já se encontra dentro de uma estrutura de controle certificada.

E se um residente compartilhar sua iPSK com um vizinho?

Chaves compartilhadas agrupam duas residências em um único registro de apartamento, portanto você deve evitá-las. Limite o número de dispositivos por iPSK e exija que os moradores registrem novos dispositivos através do Purple. Monitore saltos repentinos na contagem de dispositivos ou sessões simultâneas. Com VLAN por iPSK, a chave compartilhada ainda é mapeada para o segmento de um único apartamento. Isso dá ao conselho um ponto de partida defensável, com uma ressalva documentada.

Podemos responder a uma intimação judicial se o nosso ISP usar NAT de nível de operadora (CGNAT)?

Sim, mas apenas se seus próprios logs estiverem completos. Por trás do CGNAT, a notificação traz o endereço compartilhado do ISP. O ISP mapeia isso para a sua WAN, e seus registros devem mapear sua WAN para um apartamento. Seus logs tornam-se, então, o único registro de atribuição dentro do edifício. Solicite ao seu ISP um IP público dedicado sempre que possível e mantenha a sincronização do NTP rigorosa.

Quanto esforço é necessário para implantar uma pipeline de logs própria?

Um engenheiro de rede competente pode configurar a pipeline de código aberto em uma única máquina virtual Linux. Isso abrange um coletor Fluentd ou Logstash, armazenamento Elasticsearch ou Loki, uma política de retenção automatizada e uma exportação diária de identidade do Purple. O maior esforço é a validação. Confirme se o firmware do seu MX exporta a porta de origem traduzida e, em seguida, realize um teste de atribuição cega antes de depender da pipeline para uma notificação real.