PPSK WiFi: comparando funcionalidades e modelos de implementação

Bem-vindo ao Purple Technical Briefing. Hoje vamos falar sobre PPSK WiFi - Private Pre-Shared Key - o que é, como se compara com as alternativas e onde realmente faz sentido implementá-lo. [medium pause] Comecemos pelo problema que resolve. Numa rede WPA2 Personal tradicional, todos os dispositivos partilham a mesma palavra-passe. Isso é aceitável para uma casa. É um risco de segurança para um empreendimento Build to Rent de 200 frações, uma residência de estudantes ou um hotel com 300 quartos. Quando um residente se muda, ou se altera a palavra-passe para todos - afetando a TV inteligente, o termóstato e a consola de todos os outros residentes - ou se deixa o antigo residente com acesso. Nenhuma das opções é aceitável. [short pause] PPSK resolve isto atribuindo a cada residente, a cada apartamento ou a cada grupo de dispositivos a sua própria chave WiFi única. Todos se ligam ao mesmo SSID - o mesmo nome de rede - mas cada chave é mapeada para uma VLAN separada. O apartamento 12 está na VLAN 10. O apartamento 13 está na VLAN 20. Os dispositivos IoT estão na VLAN 99. O ponto de acesso trata do mapeamento da chave para a VLAN de forma automática. Sem necessidade de servidor RADIUS. Sem infraestrutura de certificados. Sem suplicante 802.1X no dispositivo. [medium pause] Agora vamos falar sobre a terminologia, porque varia de acordo com o fabricante e isso causa uma real confusão no mercado. A Aruba chama-lhe PPSK - Private Pre-Shared Key. A Cisco Meraki chama-lhe iPSK - Identity PSK, ou Personal Private Network. A Juniper Mist utiliza ePSK. A Extreme Networks, que originalmente desenvolveu o conceito sob a marca Aerohive, chama-lhe Private PSK. A Ubiquiti UniFi chama-lhe simplesmente PPSK. A Cambium também utiliza ePSK. O mecanismo subjacente é idêntico em todas: um SSID, múltiplas chaves únicas, com cada chave associada a uma VLAN ou a um grupo de políticas. [short pause] Tecnicamente, eis o que acontece na camada de associação. Quando um dispositivo se liga, apresenta a sua chave pré-partilhada durante o handshake de quatro vias do WPA2. O ponto de acesso - ou o controlador cloud por trás dele - procura essa chave no armazenamento PPSK, identifica a qual VLAN está mapeada e etiqueta o tráfego do dispositivo em conformidade a partir desse momento. O dispositivo vê uma ligação WiFi normal. Não faz ideia de que foi colocado num segmento isolado. O seu Chromecast funciona. A sua coluna inteligente emparelha. A sua consola obtém o tipo de NAT correto. Tudo se comporta como uma rede doméstica - porque, do ponto de vista do dispositivo, ela é. [medium pause] Esta é a principal diferença em relação ao 802.1X, que é o padrão empresarial para redes de funcionários e ambientes corporativos. O 802.1X requer um servidor RADIUS, um fornecedor de identidade - Microsoft Entra ID, Okta ou Google Workspace - e um suplicante em cada dispositivo. Esse suplicante é o componente de software que lida com a troca de autenticação EAP. Cada portátil gerido, cada telemóvel corporativo, tem um. O frigorífico inteligente do seu residente não tem. O controlador HVAC do seu edifício não tem. Os seus sensores IoT não têm. O PPSK funciona com todos eles porque opera na camada WPA Personal, não na camada WPA Enterprise. [short pause] Dito isto, o PPSK não é um substituto para o 802.1X em ambientes corporativos. É uma ferramenta diferente para um problema diferente. Se está a gerir uma rede de colaboradores onde a responsabilidade individual importa - onde precisa de saber que uma pessoa específica se autenticou num momento específico, e precisa de revogar o seu acesso no momento em que sai da organização - o 802.1X é a resposta certa. Se está a gerir uma rede residencial onde necessita de isolamento por habitação, suporte IoT e simplicidade operacional à escala, o PPSK é a resposta certa. [medium pause] Vamos olhar para os modelos de implementação. Existem três padrões principais em produção atualmente. [short pause] O primeiro é o modelo de controlador na nuvem, que é o mais comum para novas implementações. Os seus pontos de acesso - sejam Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme ou Fortinet - ligam-se a uma plataforma de gestão na nuvem. O armazenamento de chaves PPSK reside no controlador na nuvem. Quando provisiona um novo residente, cria uma chave no portal, atribui-a a uma VLAN, e o controlador envia a política para todos os pontos de acesso no edifício. O residente recebe a sua chave - via e-mail, SMS ou um código QR num pacote de boas-vindas - e liga-se. Quando se muda, elimina a chave. Os seus dispositivos deixam de se ligar. Ninguém mais é afetado. [short pause] O segundo modelo é o PPSK com um backend RADIUS local. Algumas implementações empresariais utilizam um servidor RADIUS para armazenar e validar credenciais PPSK, o que lhe dá registo centralizado, trilhos de auditoria e integração com a sua plataforma de gestão de identidade. Isto adiciona custos de infraestrutura, mas dá-lhe a responsabilidade do 802.1X com a compatibilidade de dispositivos do PPSK. É o modelo certo para ambientes mistos - por exemplo, um espaço de coworking onde tem tanto dispositivos corporativos geridos como equipamentos IoT pertencentes aos membros. [short pause] O terceiro modelo é o híbrido: PPSK para residentes e IoT, 802.1X para colaboradores e sistemas de gestão. Esta é a arquitetura que a Purple recomenda para implementações Build to Rent e edifícios multi-habitacionais. Os residentes utilizam PPSK. Os sistemas de gestão do edifício, CCTV e controlo de acessos recebem a sua própria VLAN de IoT com PPSK. Os dispositivos da equipa de gestão da propriedade utilizam 802.1X contra o Microsoft Entra ID ou Okta. Três modelos de autenticação distintos, três VLANs distintas, uma infraestrutura física. Agora vamos entrar na implementação. Se está a implementar PPSK para um empreendimento Build to Rent ou uma propriedade multi-habitacional, aqui está a sequência que funciona. [short pause] Comece pelo seu design lógico antes de tocar no hardware. Mapeie o seu número de residentes, as suas categorias de dispositivos IoT e quaisquer sistemas de colaboradores ou de gestão. Atribua VLANs. Uma implementação típica de BTR tem este aspeto: VLAN 10 até ao que o seu número de frações exigir para os residentes, uma VLAN por apartamento ou uma VLAN por piso, dependendo da sua densidade. VLAN 99 para IoT. VLAN 100 para gestão do edifício. VLAN 200 para WiFi de convidados nas áreas comuns. [short pause] Depois, documente o seu esquema de endereçamento IP. Num edifício de 200 frações, está a olhar para 3.000 a 5.000 dispositivos na rede em qualquer momento. Essa é a estimativa de 15 a 25 dispositivos por habitação da pesquisa da British Property Federation. Os seus escopos DHCP precisam de acomodar isso. Utilize o endereçamento privado RFC 1918 com tamanhos de sub-rede suficientes por VLAN. Um slash 24 oferece 254 endereços utilizáveis. Um slash 23 oferece 510. Dimensione em conformidade. [medium pause] Sobre a seleção de hardware: o PPSK é suportado em todas as principais plataformas de pontos de acesso empresariais. A Cisco Meraki chama-lhe iPSK e gere-o através do dashboard Meraki com políticas de chaves por SSID. A HPE Aruba implementa-o nativamente no ArubaOS e Aruba Central. A Ruckus suporta-o através do SmartZone e da plataforma Ruckus Cloud. A Juniper Mist utiliza ePSK com gestão de RF orientada por IA. A Ubiquiti UniFi possui PPSK desde 2023, embora note que atualmente é apenas WPA2 e não funcionará na banda de 6 gigahertz. A Cambium e a Extreme suportam-no através das suas respetivas plataformas cloud. [short pause] Uma limitação crítica a assinalar: a implementação PPSK da UniFi é apenas WPA2. Se estiver a especificar pontos de acesso WiFi 6E e quiser utilizar a banda de 6 gigahertz para clientes PPSK, precisará de uma plataforma que suporte WPA3-SAE com PPSK, ou precisará de restringir os clientes PPSK às bandas de 2,4 e 5 gigahertz. A Aruba, a Ruckus e a Meraki suportam PPSK em configurações WPA3. [medium pause] Agora vamos falar sobre as armadilhas. Estes são os modos de falha que vejo repetidamente em implementações de produção. [short pause] O primeiro é a proliferação de SSIDs. Cada SSID que transmite consome tempo de antena para tramas de beacon. Num edifício residencial denso, se estiver a transmitir seis ou oito SSIDs por ponto de acesso, está a degradar o desempenho para todos. Mantenha um máximo de quatro SSIDs por rádio. Utilize o PPSK para servir múltiplos segmentos de residentes a partir de um único SSID, em vez de criar um SSID separado por apartamento ou por piso. [short pause] A segunda armadilha é a configuração insuficiente das portas trunk. Desenha um esquema de VLAN limpo, implementa os pontos de acesso e, depois, o tráfego cai silenciosamente porque alguém se esqueceu de permitir as VLANs relevantes numa ligação trunk entre o switch de distribuição e a camada de acesso. Valide cada porta trunk durante o comissionamento. Documente-o. Teste-o com um dispositivo em cada VLAN antes de os residentes se mudarem. [short pause] A terceira armadilha é a distribuição de chaves. Gerar chaves é fácil. Entregá-las aos residentes de uma forma que seja segura e operacionalmente gerível é mais difícil. Um código QR no pacote de boas-vindas funciona bem para o dia da mudança. Um portal do residente onde estes podem recuperar a sua chave e adicionar novos dispositivos é melhor para as operações em curso. Construa o fluxo de trabalho de distribuição de chaves antes de implementar, não depois. [short pause] O quarto erro, específico para IoT, é colocar dispositivos domésticos inteligentes no segmento PPSK do residente sem pensar nas implicações. Um dispositivo IoT comprometido na VLAN de um residente pode potencialmente atacar outros dispositivos nessa mesma VLAN. Para categorias de IoT de alto risco, considere uma VLAN de IoT separada com filtragem de saída, mesmo que isso signifique que os residentes precisem de configurar as suas aplicações de casa inteligente para usar uma rede diferente. [medium pause] Vamos analisar dois cenários do mundo real. [short pause] Cenário um: um empreendimento Build to Rent de 180 unidades no centro da cidade. O operador queria WiFi incluído no arrendamento como uma comodidade, com ativação no dia da mudança e suporte total para casa inteligente. Implementaram pontos de acesso HPE Aruba geridos através do Aruba Central. Cada apartamento recebe uma chave PPSK única gerada no momento da assinatura do contrato. A chave é enviada por e-mail ao residente com um código QR. Eles digitalizam-no, todos os seus dispositivos ligam-se, e o seu Chromecast, coluna inteligente e consola funcionam imediatamente. Quando um residente se muda, o gestor da propriedade elimina a chave no portal. O novo residente recebe uma chave nova na mudança. Zero drama de rotação de palavras-passe. O operador relata uma redução de 30% nos pedidos de suporte relacionados com WiFi em comparação com a sua implementação anterior de palavra-passe partilhada. [short pause] Cenário dois: um bloco de alojamento para estudantes de 400 camas. O desafio aqui é a semana de mudança de coorte, com centenas de estudantes a chegar simultaneamente, todos a tentar ligar dezenas de dispositivos ao mesmo tempo. O operador utilizou pontos de acesso Ruckus com SmartZone, implementando PPSK com uma chave por quarto. As chaves foram pré-geradas e incluídas no pacote de boas-vindas enviado antes da chegada. Os estudantes digitalizaram o código QR à chegada e ficaram ligados em segundos. A rede lidou com o pico de entradas sem degradação porque o tráfego de cada estudante estava isolado no seu próprio segmento de VLAN. [medium pause] Agora, uma sessão rápida de perguntas e respostas sobre as questões que surgem com mais frequência. [short pause] Quantas chaves PPSK pode um único ponto de acesso suportar? A maioria das plataformas empresariais suporta milhares de chaves por SSID. O Cisco Meraki suporta até 5.000 entradas iPSK por rede. A Aruba suporta uma escala semelhante. O Ubiquiti UniFi suporta até 1.000 entradas PPSK por rede. Para um edifício de 200 unidades, está bem dentro dos limites em qualquer plataforma. [short pause] O PPSK funciona com WPA3? Sim, na maioria das plataformas empresariais. O WPA3-SAE fornece uma proteção mais forte contra ataques de dicionário offline em comparação com o WPA2-PSK, pelo que implementar PPSK em WPA3 onde os seus dispositivos clientes o suportam é a abordagem correta. A exceção é o UniFi, que atualmente suporta apenas WPA2 para PPSK. [short pause] Posso integrar o PPSK com o meu sistema de gestão de propriedades? Sim, através da API do fornecedor. O Aruba Central, Meraki, Ruckus e Mist expõem APIs REST para gestão de chaves PPSK. Pode automatizar a criação e revogação de chaves como parte do seu fluxo de trabalho de gestão de arrendamentos. [short pause] Qual é a diferença de segurança entre PPSK e 802.1X? A diferença fundamental é que o PPSK é um modelo de segredo partilhado. A chave é uma cadeia de caracteres que pode ser partilhada ou intercetada. O 802.1X com EAP-TLS utiliza certificados digitais, que não podem ser partilhados da mesma forma e fornecem autenticação mútua. Para ambientes residenciais onde o modelo de ameaça é principalmente o isolamento entre residentes, o PPSK oferece uma segurança adequada. Para redes corporativas de funcionários, o 802.1X é a escolha correta. [medium pause] Para resumir: o PPSK WiFi é o modelo de autenticação correto para implementações residenciais multi-tenant, ambientes com forte presença de IoT e qualquer cenário onde necessite de isolamento por utilizador ou por habitação sem a sobrecarga de infraestrutura do 802.1X. Funciona em Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Integra-se com sistemas de gestão de propriedades via API. E resolve os três problemas operacionais fundamentais que as redes de palavra-passe partilhada não conseguem: saídas de residentes sem perturbar os restantes, suporte a dispositivos domésticos inteligentes e responsabilidade por residente. [short pause] O enquadramento de decisão é simples. Se os seus dispositivos suportam 802.1X e tem uma infraestrutura RADIUS, utilize o 802.1X para funcionários e dispositivos geridos. Se está a gerir uma propriedade residencial multi-tenant, utilize o PPSK. Se tem dispositivos IoT que não suportam 802.1X, utilize o PPSK com uma VLAN IoT dedicada. Se precisa de WiFi para convidados em áreas comuns, utilize uma PSK padrão ou uma rede aberta com um Captive Portal por cima. [short pause] Para os próximos passos: reveja o diagrama de visão geral da arquitetura no guia, que mostra toda a pilha de implementação PPSK desde a ligação do ISP até ao dispositivo do residente. Utilize o fluxograma de decisão para mapear o seu ambiente específico para o modelo de autenticação correto. E se está a planear uma implementação BTR ou MDU e quer compreender como a plataforma Multi-Tenant WiFi da Purple se posiciona sobre o seu hardware existente para fornecer a gestão de chaves, o portal do residente e a camada de analítica, o link está no guia. [medium pause] Por hoje é tudo no nosso briefing. Obrigado por ouvir. Permita-me aprofundar o modelo de segurança, porque é aqui que vejo a maior confusão no mercado. [short pause] O PPSK opera na camada WPA Personal. Cada chave é um segredo pré-partilhado. A garantia de segurança que o PPSK oferece é o isolamento entre residentes - o dispositivo A na chave A não se pode comunicar com o dispositivo B na chave B, mesmo quando estão associados ao mesmo ponto de acesso físico. Esse isolamento é imposto na camada VLAN, não na camada de encriptação. A encriptação entre cada dispositivo e o ponto de acesso utiliza o mesmo conjunto de cifras WPA2 ou WPA3, independentemente da chave PPSK que o dispositivo utilizou para autenticar. [short pause] O que o PPSK não fornece é a autenticação mútua que o 802.1X oferece. Numa implementação de 802.1X com EAP-TLS, o cliente autentica-se na rede e a rede autentica-se no cliente. Ambos os lados apresentam certificados. Isto previne ataques de pontos de acesso fraudulentos (rogue AP). Com PPSK, o cliente não tem forma de verificar se está ligado à rede legítima em vez de um rogue AP que esteja a transmitir o mesmo SSID. Para um edifício residencial onde o modelo de ameaça se foca principalmente em isolar os residentes uns dos outros, este é um compromisso aceitável. Para um ambiente corporativo que lida com dados confidenciais, não o é. [medium pause] Agora vamos falar sobre o caminho de atualização para o WPA3. O WPA3-SAE, que significa Simultaneous Authentication of Equals, substitui o handshake de quatro vias do WPA2 por um protocolo de troca de chaves mais seguro chamado Dragonfly. A melhoria crítica para implementações de PPSK é o forward secrecy: mesmo que um atacante capture o tráfego WiFi e mais tarde obtenha a chave pré-partilhada, não conseguirá decifrar o tráfego capturado. O WPA2-PSK não fornece forward secrecy. O WPA3-SAE fornece. Se está a implementar novo hardware hoje, especifique o suporte para WPA3-SAE e ative-o para o seu SSID de PPSK. Os clientes que não suportem WPA3 irão reverter para WPA2 no modo de transição, por isso não precisa de forçar uma transição abrupta. [short pause] A perspetiva do GDPR merece ser abordada diretamente. Numa implementação residencial multi-tenant, está a processar dados pessoais - especificamente, a associação entre uma chave WiFi e um residente identificado. Essa associação constitui dados pessoais ao abrigo do UK GDPR e do EU GDPR. Precisa de uma base jurídica para processar esses dados. Num contexto de BTR, a base jurídica é tipicamente a execução de um contrato - o contrato de arrendamento - ou interesses legítimos. Precisa de um aviso de privacidade que cubra o processamento de dados WiFi. Precisa de uma política de retenção de dados para os registos de ligação. E precisa de ser capaz de responder a pedidos de acesso do titular dos dados, o que significa que a sua plataforma de gestão de PPSK tem de ser capaz de exportar todos os dados associados à chave de um residente específico. [short pause] A plataforma de Multi-Tenant WiFi da Purple foi construída com isto em mente. Os dados são armazenados numa infraestrutura certificada pela ISO 27001. Estamos em conformidade com o GDPR e o CCPA. A residência dos dados é selecionável - Reino Unido, UE ou EUA - para que possa cumprir as suas obrigações regulamentares independentemente de onde as suas propriedades estejam localizadas. E a nossa plataforma fornece o registo de auditoria e as capacidades de exportação de dados de que necessita para a conformidade. Deixe-me abordar a questão do ROI, porque este assunto surge em todas as conversas de aquisição de BTR. [short pause] A investigação da British Property Federation mostra consistentemente a qualidade do WiFi como um dos cinco principais fatores de comodidade nas decisões de arrendamento de Build to Rent. Os operadores que incluem WiFi gerido como uma comodidade reportam prémios de renda de quinze a trinta libras por unidade, por mês, em comparação com propriedades equivalentes sem conectividade incluída. Num edifício de 200 unidades, isto representa entre trinta e seis mil e setenta e duas mil libras por ano em receitas de arrendamento adicionais. Em comparação com um custo típico de implementação PPSK - hardware amortizado ao longo de cinco anos mais uma licença de software de sobreposição - o período de retorno é normalmente inferior a 18 meses. [short pause] A poupança operacional é igualmente significativa. Uma rede de palavra-passe partilhada num edifício de 200 unidades gera um volume previsível de pedidos de suporte: residentes que não conseguem ligar o seu Chromecast, residentes cuja coluna inteligente não emparelha, residentes cuja consola mostra um tipo de NAT estrito. Estes pedidos custam tempo e dinheiro para serem resolvidos. Uma rede PPSK corretamente implementada elimina a maioria deles. Um operador com quem trabalhamos relatou uma redução de 30% nos contactos de suporte relacionados com WiFi nos primeiros seis meses após a migração de uma palavra-passe partilhada para uma implementação PPSK. [short pause] Os períodos de vacatura são o outro fator de influência. Um edifício onde o WiFi está ativo e a funcionar no dia da mudança reduz a fricção para os novos residentes. Um edifício onde um novo residente tem de esperar pela marcação de um técnico de banda larga - normalmente de sete a catorze dias no Reino Unido - cria uma primeira impressão negativa que afeta a retenção. O PPSK com ativação no dia da mudança elimina totalmente essa fricção. [medium pause] Mais uma área a cobrir: a aplicação em coworking e uso misto. O PPSK não serve apenas para habitação residencial. É também o modelo certo para espaços de coworking onde se pretende o isolamento por membro ou por empresa sem a sobrecarga do 802.1X. Um operador de coworking com 200 membros pode dar a cada membro a sua própria chave PPSK, mapeá-la para uma VLAN dedicada e garantir que os dispositivos do membro A são invisíveis para o membro B. Quando uma adesão expira, a chave é revogada. Quando um novo membro adere, é gerada uma nova chave. A experiência do membro é idêntica à de uma rede doméstica. [short pause] Para o coworking, o modelo híbrido funciona particularmente bem. Os membros obtêm PPSK. Os visitantes dos membros - clientes que participam em reuniões, por exemplo - obtêm um SSID de WiFi para convidados separado com um Captive Portal. O pessoal do edifício obtém 802.1X através do fornecedor de identidade do operador. Três modelos de autenticação, uma infraestrutura física, separação limpa entre os três grupos de utilizadores. [medium pause] Isto cobre a totalidade do cenário. O PPSK WiFi é uma tecnologia madura e bem suportada que resolve um problema específico e importante: o isolamento por utilizador ou por agregado familiar em ambientes multi-inquilino, sem a sobrecarga de infraestrutura do 802.1X. É agnóstico em relação ao hardware, baseado em API e pode ser implementado hoje mesmo nos pontos de acesso que já possui. Os critérios de decisão são claros. Os padrões de implementação estão comprovados. E o caso de negócio, particularmente em Build to Rent e alojamento para estudantes construído especificamente para o efeito, está bem fundamentado.