Rastreio de Sessão de Inquilino e Atribuição de Abuso em WiFi de MDU: Mapeamento de Fluxos Meraki para Identidade iPSK da Purple

Para atribuir abusos numa rede MDU com um único IP público, junta dois registos. A exportação de fluxos 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. A identidade iPSK do Purple e os registos de accounting RADIUS mapeiam esse MAC e VLAN para um apartamento. Guarde ambos por 365 dias, sujeito a aconselhamento jurídico.

O que faz realmente a atribuição de abusos numa rede MDU?

O Purple Multi-Tenant WiFi oferece a cada residente numa unidade de habitação multifamiliar (MDU), bloco build-to-rent (BTR) ou residência de estudantes uma rede privada que se assemelha à banda larga doméstica. Por trás dessa experiência reside um facto arquitetónico incontornável. Cada residente sai do edifício através do mesmo endereço WAN público, utilizando a tradução de portas (PAT). O PAT é uma forma de NAT onde muitos hosts internos partilham um IP público, distinguidos apenas pela porta de origem que o gateway atribui. Quando um detentor de direitos de autor, um departamento de abuso ou um agente da polícia o procuram, veem um único IP. Esperam um único subscritor por trás dele. No entanto, tem centenas.

A atribuição de abusos reconstrói esse mapeamento perdido. Faz isto a partir de dois planos de dados independentes: os fluxos de rede do gateway e os registos de identidade do Purple. Nenhum deles é suficiente por si só. Unidos pelo endereço MAC, VLAN e hora, levam-no de um IP público e porta até um apartamento identificado.

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

Uma notificação típica ao abrigo da lei de direitos de autor dos EUA (DMCA), 17 U.S.C. § 512, contém três campos: IP público, porta de origem e carimbo de data/hora. O RFC 6302, a orientação do IETF para servidores virados para a internet, recomenda o registo da porta de origem e de um carimbo de data/hora preciso precisamente porque o endereçamento partilhado torna o IP por si só ambíguo. O seu trabalho é honrar esse design. Se os seus registos contiverem a porta traduzida e um relógio disciplinado, a notificação torna-se respondível. Se não contiverem, conseguirá identificar o edifício e nada mais.

O que o iPSK contribui

Este guia pressupõe que já sabe o que é o iPSK (Identity Pre-Shared Key). Os guias do Purple "Implementing iPSK for secure IoT" e "iPSK vs 802.1X: a comparison" cobrem este pré-requisito. Em suma, o iPSK emite a cada inquilino uma frase de acesso única num SSID partilhado, e o servidor RADIUS vincula essa chave a uma identidade. O RADIUS (Remote Authentication Dial-In User Service, RFC 2865) autentica a sessão. O RADIUS Accounting (RFC 2866) regista quando esta se inicia, quanto tempo dura e quando termina. Este guia cobre a camada operacional superior: transformar esses registos de identidade em provas que pode entregar ao seu departamento jurídico.

De que precisa antes de começar?

Precisa de ter quatro coisas preparadas antes de a primeira notificação chegar. Construí-las após o acontecimento não funciona, porque as provas de que necessita já desapareceram.

1. Um design de VLAN por iPSK. A chave de cada inquilino coloca os seus dispositivos num segmento dedicado de camada 3 antes do limite de NAT.
2. Uma exportação de fluxo do Meraki MX que inclua o endereçamento pré-NAT e pós-NAT com carimbos de data/hora.
3. RADIUS Accounting do Purple ativado, além de uma exportação regular do mapeamento de iPSK para inquilino.
4. Uma política de retenção assinada pelo departamento jurídico, e NTP a correr em todos os dispositivos da cadeia.

Porque é que VLAN por iPSK supera um SSID partilhado simples

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

Design	Granularidade de atribuição	Sobrevive à aleatoriedade de MAC	Isolamento de inquilinos	A quem se adequa
SSID partilhado simples, uma PSK	Apenas edifício	Não	Nenhum por predefinição	Pequeno café ou rede de convidados de lobby, não residencial
SSID partilhado, iPSK, sem VLANs	MAC do dispositivo para inquilino	Parcialmente, através do registo de accounting no momento da sessão	Apenas isolamento de clientes	Passo intermédio durante a migração
iPSK com VLAN por inquilino	Sub-rede do apartamento e MAC	Sim, a sub-rede continua a identificar o apartamento	Segmentação de camada 3 por apartamento	MDU, BTR, alojamento de estudantes, apartamentos com serviços
802.1X com credenciais por pessoa	Indivíduo nomeado	Sim	Política por utilizador	Escritórios multi-inquilino corporativos com dispositivos geridos

Para complexos residenciais, a VLAN por iPSK é a predefinição correta. Oferece-lhe dois identificadores que devem coincidir: a VLAN e o MAC. O 802.1X (a norma IEEE de controlo de acessos baseada em portas) chega ao indivíduo. No entanto, apresenta dificuldades com consolas de jogos, smart TVs e outros dispositivos que os residentes 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 de fluxo através de Syslog (RFC 5424) e exportar registos de tráfego por NetFlow versão 9 (RFC 3954). Configure ambos no Meraki Dashboard nas definições de relatórios do equipamento. Siga a documentação da própria Cisco Meraki para os caminhos de menu atuais.

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

• IP de origem interno e porta de origem
• Endereço MAC do cliente, ou uma associação IP-para-MAC fiável a partir dos registos 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 fim, com resolução de milissegundos onde o exportador o suporte

A porta pós-NAT é o campo que os operadores mais vezes consideram em falta. No IPFIX (RFC 7011), os elementos de informação relevantes são postNATSourceIPv4Address e postNAPTSourceTransportPort, ambos definidos no registo IANA IPFIX. Antes de confiar na exportação, capture uma amostra. Confirme se o seu firmware preenche a porta traduzida. Se não o fizer, a sua alternativa é o Syslog de firewall e fluxo do MX combinado com um registo de tradução NAT de um dispositivo a montante que o registe. Resolva isto antes de precisar.Combine os dados de fluxo com os registos de concessão DHCP. As concessões fornecem-lhe uma associação IP para MAC limitada no tempo. Essa associação é a sua rede de segurança quando um registo de fluxo contém o IP mas não o MAC.

Capture 2: identidade a partir da Purple

A Purple contribui com a metade da identidade da junção. Os registos de RADIUS Accounting transportam o MAC do cliente no atributo Calling-Station-Id, o ponto de acesso em Called-Station-Id, e as horas de início e fim de sessão. O Accounting é uma parte padrão da configuração de RADIUS da Purple em todos os fabricantes suportados. O artigo de suporte da Purple para a Avaya mostra uma configuração típica, com o accounting ativado e um intervalo de accounting provisório definido.

Esse mesmo artigo assinala um detalhe que pode comprometer a sua junção. Os fabricantes formatam os endereços MAC de forma diferente: maiúsculas com hífenes num, minúsculas separadas por dois pontos noutro. Normalize cada MAC para um único formato na ingestão, em ambos os planos de dados.

A segunda entrada de identidade é o mapa iPSK para inquilino: qual a chave que pertence a cada apartamento e qual a VLAN que esta atribui. Exporte isto diariamente da Purple. Desta forma, terá uma captura instantânea datada de quem possuía cada chave no dia em questão, e não apenas de quem a possui hoje. Os arrendamentos mudam. Uma chave que pertence ao apartamento 4.12 hoje pode ter pertencido a um residente anterior há seis meses.

Construir a pipeline por si próprio

Se ainda não centraliza o Syslog do Meraki, uma pipeline leve de código aberto resolve o problema. Uma pequena máquina virtual Linux é suficiente para a maioria das propriedades de local único.

1. Coletor. Execute o Fluentd ou Logstash. Escute na porta UDP 514, a porta Syslog atribuída pela IANA, e na porta NetFlow escolhida; a porta UDP 2055 é a convenção comum. O Logstash analisa o NetFlow v9 e o IPFIX com o seu codec netflow.
2. Normalizar na ingestão. Converta todos os carimbos de data/hora para UTC. Converta todos os MACs para um único formato. Identifique cada registo com o local e a VLAN.
3. Armazenar. Encaminhe para o Elasticsearch ou Grafana Loki. No Elasticsearch, uma política de Index Lifecycle Management (ILM) roda os índices diariamente e elimina-os no seu limite de retenção. No Loki, o compactador aplica um período de retenção. De qualquer forma, a eliminação é automática e auditável.
4. Captura instantânea de identidade. Agende uma tarefa cron diária que extraia o mapa iPSK para inquilino ativo a partir da Purple. Escreva-o numa tabela de consulta local datada. Mantenha as capturas instantâneas no mesmo esquema de retenção que os fluxos.
5. Controlo de acesso. Restrinja o acesso a consultas a funcionários designados. Registe todas as pesquisas. Estes registos identificam residentes, por isso trate-os como dados pessoais ao abrigo do GDPR.

O resultado: no momento de uma intimação, executa a junção offline, com os seus próprios dados, sem esperar por terceiros.

Como responder a um aviso de abuso?

Quando um aviso chegar, execute sempre o mesmo fluxo de trabalho.

Aviso de abuso
(IP público, porta de origem, carimbo de data/hora)
        |
        v
[1] Registo de fluxo Meraki
    corresponder IP pós-NAT + porta traduzida
    dentro da tolerância do 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-to-tenant datado
    corresponder iPSK + VLAN nessa data
        |
        v
Apartamento / ocupante registado

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

• Disciplina de fuso horário. Converta primeiro o carimbo de data/hora da notificação para UTC. Muitas notificações chegam na hora local do remetente.
• Acordo entre identificadores. A VLAN do registo de fluxo deve corresponder à VLAN que o iPSK atribui. Uma divergência significa que algo está errado. Pare e investigue antes de nomear alguém.
• O consultor jurídico decide sobre a divulgação. O seu resultado é um registo de atribuição interno. Divulgar, notificar o residente ou contestar é uma decisão jurídica.

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

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

1. Notificação. Um titular de direitos reporta um evento de partilha de ficheiros a partir do IP 203.0.113.10, porta de origem 41822, às 22:17:05 UTC de 14 de março.
2. Consulta de fluxo. Procura no índice de fluxo do MX pelo IP pós-NAT 203.0.113.10 e porta traduzida 41822, entre as 22:17:03 e as 22:17:07. Um registo corresponde. Origem interna 10.40.12.37, porta 51544, VLAN 412.
3. IP para MAC. O registo de concessão DHCP mostra 10.40.12.37 associado ao MAC 3C-22-FB-1A-7E-09 das 19:02 às 23:58 desse dia.
4. Consulta de identidade. O Purple RADIUS Accounting mostra esse 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. Pesquisa de inquilino. O instantâneo iPSK de 14 de março mapeia essa chave e a VLAN 412 para o apartamento 4.12. Entrega a cadeia ao consultor jurídico.

Cada etapa é um registo com carimbo de data/hora de um sistema independente. Essa independência é o que torna a cadeia credível.

Como verificar se a cadeia funciona?

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

• A partir de um dispositivo de teste num iPSK conhecido, abra uma ligação a um servidor externo que controle. Registe o IP público, a porta e a hora a partir dos registos desse servidor.
• Execute o fluxo de trabalho completo às cegas, começando apenas pelo registo do lado do servidor.
• Confirme que chega ao apartamento de teste correto. Registe o tempo que demorou.
• Verifique se o registo mais antigo em cada índice se encontra no seu limite de retenção e não além dele. A retenção excessiva é, por si só, um problema de GDPR.

Se o simulacro 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 associação depende do tempo. As portas traduzidas são reutilizadas em segundos num gateway ocupado, pelo que alguns segundos de desvio podem corresponder ao fluxo errado. Aponte o MX, os seus pontos de acesso, o coletor e qualquer dispositivo NAT a montante para as mesmas fontes NTP (Network Time Protocol, RFC 5905). Registe em UTC em todo o lado. Alerte quando o desvio de qualquer dispositivo exceder um segundo. Se dois fluxos corresponderem dentro da sua janela de tolerância, reporte a ambiguidade ao consultor jurídico em vez de escolher um.

NAT de nível de operador (Carrier-grade NAT) a montante

Alguns ISPs colocam a sua WAN atrás de um NAT de nível de operador (CGNAT, descrito na RFC 6888). O endereço público da sua MX passa a ser ele próprio privado. O aviso conterá o endereço partilhado e a porta do ISP. Apenas o ISP pode mapear isso para a sua WAN, e apenas os seus registos podem mapear a sua WAN para um apartamento. Os seus registos tornam-se o único registo de atribuição dentro do edifício. Pergunte ao seu ISP se está atrás de um CGNAT e solicite um IP público dedicado sempre que possível.

Partilha de PSK entre inquilinos

Se um residente der a sua iPSK a um vizinho, ambos os agregados familiares aparecem como um único apartamento. Imponha o registo de dispositivos: limite o número de dispositivos por iPSK e exija que os residentes registem novos dispositivos através da Purple. Reveja as chaves cujo número de dispositivos ou sessões simultâneas aumente subitamente. Altere uma chave no mesmo dia da saída do inquilino, como parte do seu processo de entradas, transferências e saídas.

Randomização de MAC

As versões atuais do iOS e Android apresentam um MAC privado por rede por predefinição, e algumas definições rodam-no. É por isso que se associa ao registo ativo de RADIUS Accounting no carimbo de data/hora, e não a um registo estático de dispositivos inscritos. Com VLAN por iPSK, a sub-rede continua a identificar o apartamento mesmo quando um MAC é novo.

Durante quanto tempo deve guardar os registos?

A retenção é uma questão jurídica. Acorde-a com o seu aconselhamento jurídico local antes de configurar o que quer que seja. Como base de trabalho, a maioria dos operadores guarda registos de fluxo e de identidade durante 365 dias. Isso cobre o tempo que uma intimação civil ou um pedido policial costuma demorar a chegar.

Duas pressões puxam em direções opostas. Ao abrigo do Artigo 5.º, n.º 1, alínea e), do GDPR, apenas pode conservar dados pessoais durante o período necessário para a respetiva finalidade. No Reino Unido, o Investigatory Powers Act 2016 limita os avisos de retenção de dados a 12 meses. Nos EUA, as intimações do DMCA § 512(h) podem chegar muito depois do evento. Escreva o período acordado no seu aviso de privacidade e nos termos de arrendamento. Em seguida, deixe que a retenção do ILM ou do Loki a aplique automaticamente.

Quanto custa e o que obtém em troca?

A infraestrutura DIY funciona numa máquina virtual modesta mais armazenamento. Dimensione o armazenamento medindo uma semana de volume de fluxo, multiplicando por 52 e adicionando uma margem de segurança. A contribuição da Purple, a camada de identidade iPSK e o RADIUS Accounting, funciona nos pontos de acesso que já possui. A Purple é agnóstica em termos de hardware para Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet, sem necessidade de substituição de equipamentos.

O retorno é medido pela prevenção de perturbações. Dois cenários ilustrativos mostram a diferença.

Cenário 1: apartamentos de luxo num empreendimento hoteleiro

Um bloco de 180 apartamentos de luxo, gerido em conjunto com uma operação de hotel, recebia repetidos avisos de direitos de autor numa rede partilhada simples. Sem forma de os atribuir, o operador enviou um aviso por e-mail a todos os residentes. Seguiram-se reclamações e o ISP ameaçou suspender o serviço. O operador mudou para um sistema de VLAN-per-iPSK na sua infraestrutura Meraki existente e implementou o pipeline Logstash acima. O aviso seguinte foi associado a um único apartamento em menos de 20 minutos. Apenas esse residente foi contactado 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, propriedade do município e perto de um hospital, recebeu um pedido de dados da polícia sobre um IP público e respetiva porta. A equipa de habitação tinha iPSK e VLANs por apartamento, mas guardava apenas 30 dias de registos. O evento ocorreu fora desse período. Após uma revisão jurídica, a equipa alargou a retenção para 365 dias, adicionou a captura diária de identidade e iniciou testes trimestrais. Um pedido posterior foi respondido no prazo de um dia útil, identificando um apartamento, com todos os saltos documentados para a assessoria jurídica.

Onde isto se enquadra na sua infraestrutura mais ampla

O mesmo problema surge em escritórios corporativos multi-inquilino. Um operador de coworking, ou um fornecedor de SaaS que execute uma infraestrutura partilhada entre inquilinos de clientes, depara-se com um único IP público e muitas organizações por trás dele. O Purple Staff WiFi aplica o mesmo modelo focado na identidade nesse cenário, normalmente com 802.1X e Microsoft Entra ID, Okta ou Google Workspace como fonte de identidade. A integração de fluxos descrita aqui aplica-se sem alterações. O mesmo padrão serve projetos mistos de retalho com apartamentos por cima de lojas, e complexos de saúde que gerem alojamento para pessoal de saúde.

Para mais contexto, consulte os guias do Purple Multi-Tenant WiFi e os guias de iPSK da Purple, "Implementing iPSK for secure IoT" e "iPSK vs 802.1X: a comparison". Se estiver a comparar fornecedores de RADIUS na nuvem para esta função, leia IronWiFi Alternatives for Enterprise Deployments.

Perguntas frequentes

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

Não. O Purple funciona como uma camada de sobreposição na nuvem por cima dos seus pontos de acesso e dispositivos MX da Cisco Meraki existentes. Ative o iPSK com atribuição de VLAN através do RADIUS da Purple, ligue o RADIUS Accounting e configure a exportação de fluxos no MX. A mesma abordagem funciona em HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. O gateway apenas precisa de exportar o endereçamento pré-NAT e pós-NAT com carimbos de data/hora.

O Purple armazena os registos de fluxo da Meraki por nós?

Não. O Purple guarda a metade da identidade da cadeia: atribuições de iPSK, mapeamento de VLAN e sessões de RADIUS Accounting. Os registos de fluxo e NAT da Meraki permanecem num coletor controlado por si, quer seja o Elasticsearch, o Grafana Loki ou um SIEM existente. Essa divisão garante que mantém o controlo sobre a retenção, o controlo de acessos e a partilha de informações. Essas são decisões que devem pertencer ao seu departamento jurídico, e não a terceiros.

Quanto tempo devemos conservar os registos de fluxo e de identidade?

A maioria dos operadores conserva ambos por 365 dias, mas a retenção é uma decisão legal para o seu departamento jurídico. O Artigo 5(1)(e) do GDPR limita a retenção ao que a finalidade exige. No Reino Unido, os avisos de retenção de dados ao abrigo do Investigatory Powers Act 2016 estão limitados a 12 meses. Independentemente do período que acordar, publique-o no seu aviso de privacidade e aplique a eliminação automática com retenção ILM ou Loki.

O registo do tráfego de residentes é compatível com o GDPR?

Sim, desde que registe metadados de ligação, não conteúdos, e os trate como dados pessoais. Registe um fundamento jurídico, normalmente interesses legítimos ou obrigação legal, e indique a finalidade e o período de retenção no 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 o GDPR, pelo que a parte da identidade já se encontra dentro de uma estrutura de controlo certificada.

E se um residente partilhar a sua iPSK com um vizinho?

As chaves partilhadas fundem dois agregados familiares num único registo de apartamento, pelo que deve impedi-las. Limite o número de dispositivos por iPSK e exija que os residentes registem novos dispositivos através do Purple. Monitorize aumentos súbitos no número de dispositivos ou sessões simultâneas. Com VLAN-per-iPSK, a chave partilhada continua a ser mapeada para o segmento de um único apartamento. Isso dá ao departamento jurídico um ponto de partida defensável, com uma ressalva documentada.

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

Sim, mas apenas se os seus próprios registos estiverem completos. Atrás de um CGNAT, a notificação traz o endereço partilhado do ISP. O ISP mapeia-o para a sua WAN, e os seus registos devem mapear a sua WAN para um apartamento. Os seus registos passam a ser o único registo de atribuição dentro do edifício. Solicite ao seu ISP um IP público dedicado, sempre que possível, e mantenha uma disciplina rigorosa do NTP.

Quanto esforço é necessário para implementar um pipeline de registo próprio (DIY)?

Um engenheiro de redes competente consegue implementar o pipeline de código aberto numa ú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 reside na validação. Confirme que o firmware do seu MX exporta a porta de origem traduzida e, em seguida, realize um teste de atribuição cego antes de confiar no pipeline para uma notificação real.