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

You are a senior network consultant briefing a client in a confident, conversational, authoritative British English accent. Speak clearly, at a measured pace, as if in a one-to-one client meeting. Not a lecture - a briefing. Warm but direct. UK English pronunciation throughout: Bem-vindo ao Purple Technical Briefing. Hoje vamos abordar o PPSK xaverius - Private Pre-Shared Key authentication - o que é, como se compara com as alternativas e, especificamente, o que significa para promotores imobiliários, proprietários e operadores de Build to Rent que precisam de disponibilizar WiFi de classe empresarial em edifícios multi-inquilino. [medium pause] Comecemos pelo problema. Se está a gerir um empreendimento Build to Rent de 150 unidades, um bloco de alojamento estudantil ou um portfólio de unidades multifamiliares, tem um problema de WiFi que a maioria dos guias de TI não aborda diretamente. Não está a gerir um escritório corporativo. Não está a gerir um hotel. Está a gerir algo intermédio - um edifício cheio de habitações, onde cada uma espera a mesma experiência de internet privada e fiável que obteria com um router de banda larga doméstico. E precisa de disponibilizar isso a partir de uma infraestrutura partilhada, à escala, sem que uma equipa de suporte tenha de atender chamadas sempre que o Chromecast de alguém deixa de funcionar. [short pause] É esse o vazio que o PPSK preenche. E compreendê-lo devidamente - a arquitetura, os modelos de implementação, as diferenças entre fabricantes - é o que separa uma rede que funciona de uma que gera reclamações. [medium pause] Então, o que é o PPSK? Private Pre-Shared Key é um método de autenticação WiFi no qual cada residente, cada apartamento ou cada grupo de dispositivos recebe uma chave criptográfica única. Todos se ligam ao mesmo SSID - o mesmo nome de rede visível no telemóvel - mas cada chave é mapeada para uma VLAN separada. O apartamento doze está na VLAN dez. O apartamento treze está na VLAN vinte. Os dispositivos IoT estão na VLAN noventa e nove. O ponto de acesso trata do mapeamento da chave para a VLAN de forma automática. [short pause] Ora, a terminologia varia consoante o fabricante, e isto causa uma confusão real no mercado. A HPE Aruba chama-lhe MPSK - Multi Pre-Shared Key. A Cisco Meraki chama-lhe iPSK - Identity PSK. A Juniper Mist utiliza ePSK. A Ruckus chama-lhe DPSK - Dynamic PSK. A Extreme Networks chama-lhe Private PSK. A Ubiquiti UniFi chama-lhe simplesmente PPSK. O mecanismo subjacente é idêntico em todos eles: um SSID, múltiplas chaves únicas, com cada chave associada a uma VLAN ou a um grupo de políticas. O termo PPSK xaverius refere-se a esta categoria mais ampla de autenticação por chave privada por utilizador, independentemente da implementação do fabricante que estiver a instalar. [medium pause] Vamos falar sobre o mecanismo técnico, porque compreender isto é o que lhe permite tomar as decisões de arquitetura corretas. [short pause] Quando um dispositivo se liga a uma rede com suporte para PPSK, apresenta a sua chave pré-partilhada durante o handshake de quatro vias do WPA2. O ponto de acesso procura essa chave no armazenamento PPSK - seja localmente no controlador ou através de um servidor RADIUS - identifica a que VLAN esta se mapeia e etiqueta o tráfego do dispositivo em conformidade. O dispositivo deteta 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. Tudo se comporta como uma rede doméstica. [short pause] Esta é a principal distinção em relação ao 802.1X, que é o padrão IEEE para redes corporativas de funcionários. O 802.1X requer um servidor RADIUS, um fornecedor de identidade - Microsoft Entra ID, Okta ou Google Workspace - e um suplicante em cada dispositivo. Todos os portáteis geridos têm um. O frigorífico inteligente do seu residente não tem. O controlador AVAC do seu edifício não tem. O PPSK funciona com todos eles porque opera na camada WPA Personal, não na camada WPA Enterprise. [medium pause] Agora vamos comparar os três modelos de autenticação que irá encontrar numa decisão de implementação multi-tenant. [short pause] O PSK standard - o modelo de palavra-passe partilhada - é o ponto de partida para a maioria dos edifícios e aquilo de que a maioria dos edifícios se arrepende. Uma palavra-passe, todos os dispositivos, todos os residentes. Quando um residente se muda, ou altera a palavra-passe para toda a gente - avariando a smart TV, o termostato e a consola de todos os outros residentes no processo - ou deixa o antigo residente com acesso. Nenhuma das opções é aceitável em escala. O PSK standard também oferece zero isolamento de VLAN. Todos os dispositivos na rede conseguem ver todos os outros dispositivos. Isso é uma violação de privacidade prestes a acontecer num edifício residencial. [short pause] O PPSK situa-se no meio. Oferece isolamento por residente, compatibilidade com IoT e gestão automatizada do ciclo de vida das chaves. Não requer uma infraestrutura de certificados. Não requer um suplicante em cada dispositivo. Para um empreendimento BTR de 200 unidades, é a arquitetura correta. [short pause] O 802.1X é a resposta certa para a rede dos seus funcionários, para os seus sistemas de gestão de edifícios e para qualquer ambiente onde seja necessária responsabilidade individual e segurança baseada em certificados. Não é a resposta certa para o WiFi dos residentes, porque exclui os dispositivos IoT que os seus residentes realmente possuem. [medium pause] A recomendação prática é uma arquitetura híbrida: PPSK para residentes e IoT, 802.1X para funcionários e sistemas de gestão. Três modelos de autenticação distintos, três VLANs distintas, uma infraestrutura física. Esta é a arquitetura que a Purple recomenda e implementa nos seus mais de 80.000 locais ativos. É um consultor de redes sénior que continua uma sessão de esclarecimento com um cliente num tom confiante, informal e autoritário. Fale de forma clara, a um ritmo compassado. Caloroso mas direto: Agora vamos entrar nos modelos de implementação, porque é aqui que as verdadeiras decisões acontecem. [short pause] Modelo um: PPSK com controlador na nuvem. Os seus pontos de acesso 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 por e-mail ou através de um código QR num pacote de boas-vindas. Quando se muda, o utilizador elimina a chave. Os seus dispositivos deixam de se ligar. Ninguém mais é afetado. Este é o modelo mais simples operacionalmente e o que recomendamos para a maioria das implementações de BTR e MDU. [short pause] Modelo dois: PPSK baseado em RADIUS. O ponto de acesso encaminha a chave para um servidor RADIUS, que a valida num diretório e devolve a atribuição de VLAN. Isto adiciona sobrecarga de infraestrutura, mas oferece registo centralizado, pistas de auditoria e integração com a sua plataforma de gestão de identidade. Proporciona-lhe a responsabilidade do 802.1X com a compatibilidade de dispositivos do PPSK. Para implementações que excedam as 500 unidades, ou para operadores com infraestrutura RADIUS existente, este é o modelo correto. [short pause] Modelo três: híbrido. PPSK para residentes e IoT, 802.1X para funcionários e sistemas de gestão. Esta é a arquitetura para portfólios de BTR de grande escala e operadores de alojamento de estudantes construído para o efeito que precisam de simplicidade residencial e segurança de nível empresarial para os seus próprios sistemas. [medium pause] Vejamos dois cenários reais de implementação. [short pause] Cenário um: um empreendimento Build to Rent de 180 unidades. O operador implementou pontos de acesso HPE Aruba com a sobreposição de nuvem da Purple. Cada apartamento recebeu uma chave única gerada no momento da assinatura do contrato de arrendamento. A chave foi enviada por e-mail ao residente com um código QR. O residente digitalizou-o e todos os seus dispositivos ligaram-se. Quando um residente se mudou, o gestor da propriedade eliminou a chave no portal Purple. Zero problemas de rotação de palavras-passe. O operador reportou uma redução de 50% nos pedidos de suporte relacionados com WiFi nos primeiros seis meses. A rede suportou de 15 a 25 dispositivos por habitação sem degradação. [short pause] Cenário dois: um bloco de alojamento para estudantes construído para o efeito com 400 camas. O operador utilizou pontos de acesso Ruckus, implementando DPSK com uma chave por quarto. As chaves foram pré-geradas e incluídas no pacote de boas-vindas. Os estudantes digitalizaram o código QR no dia da chegada e ficaram ligados em segundos. A rede geriu o pico de entradas - com todos os 400 estudantes a chegar num período de 48 horas - sem degradação. O operador integrou o provisionamento de chaves com o seu sistema de gestão de propriedades através de API, pelo que as chaves foram geradas automaticamente quando as atribuições de quartos foram confirmadas. [medium pause] Agora vamos falar sobre as armadilhas, porque existem quatro que apanham os operadores repetidamente. [short pause] Erro um: proliferação de SSIDs. Cada SSID que transmite consome tempo de antena para tramas de sinalização (beacon frames). Mantenha um máximo de três SSIDs por rádio. Utilize PPSK para servir múltiplos segmentos de residentes a partir de um único SSID, em vez de criar um SSID separado por apartamento. Este é o erro mais comum no design de WiFi multi-tenant. [short pause] Erro dois: configuração insuficiente da porta trunk. Desenha um esquema de VLAN limpo, implementa os pontos de acesso e, em seguida, o tráfego cai silenciosamente porque alguém se esqueceu de permitir as VLANs relevantes numa ligação trunk. Valide todas as portas trunk durante o comissionamento. Teste com um dispositivo em cada VLAN antes de os residentes se mudarem. [short pause] Erro três: fluxo de trabalho de distribuição de chaves. Gerar chaves é fácil. Fazê-las chegar aos residentes de forma segura é mais difícil. Um código QR no pacote de boas-vindas funciona bem para o dia da mudança. Mas também precisa de um processo para residentes que perdem a sua chave, residentes que adicionam novos dispositivos a meio do contrato e residentes que mudam de telemóvel. Crie o fluxo de trabalho de distribuição de chaves antes de implementar, não depois. [short pause] Erro quatro: randomização de endereços MAC. Desde o iOS 14, Android 10 e Windows 11, os dispositivos utilizam endereços MAC randomizados por predefinição. Se o seu servidor RADIUS estiver a fazer uma pesquisa de MAC e o dispositivo apresentar um endereço randomizado, a pesquisa falha. Crie um fluxo de trabalho de pré-registo no seu processo de integração de residentes. A plataforma da Purple lida com isto automaticamente. [medium pause] Agora, uma secção de perguntas e respostas rápidas. [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. O Ubiquiti UniFi suporta até 1.000. Para um edifício de 200 frações, está bem dentro dos limites em qualquer plataforma. [short pause] O PPSK funciona com WPA3? Sim, na maioria das plataformas empresariais. O WPA3-SAE oferece maior proteção contra ataques de dicionário offline. A exceção é o Ubiquiti 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 fabricante. O Aruba Central, Meraki, Ruckus e Mist expõem todos APIs REST para gestão de chaves PPSK. A Purple fornece a camada de orquestração para gerir isto à escala, integrando-se com o seu software de gestão de propriedades para automatizar o aprovisionamento de chaves na entrada e a revogação na saída dos residentes. [short pause] E quanto à conformidade com o GDPR? O PPSK fornece a responsabilidade individual que o GDPR exige para WiFi residencial. Uma rede PSK partilhada não consegue dizer que residente estava a utilizar a rede num determinado momento. O PPSK consegue. A Purple armazena dados em conformidade com os requisitos do GDPR e CCPA, com residência de dados selecionável e um limite padrão de retenção de seis meses para registos que identifiquem residentes. [medium pause] To summarise. PPSK - whether you call it iPSK, MPSK, DPSK, ePSK, or PPSK xaverius - is the correct authentication architecture for multi-tenant residential environments. It delivers per-unit network isolation on a single SSID, supports every IoT device your residents own, and when backed by a cloud RADIUS service and API integration, automates the entire key lifecycle from move-in to move-out. [short pause] It is not a replacement for 802.1X in corporate environments. Use PPSK where you need IoT compatibility and operational simplicity. Use 802.1X where you need individual accountability and certificate-based security. And use both together in a hybrid architecture for large-scale BTR and student accommodation deployments. [short pause] Purple has been deploying this architecture since 2012. We serve 80,000-plus live venues, processed 440 million logins in 2024, and maintain 99.999% uptime. Our Multi-Tenant WiFi solution runs as a hardware-agnostic cloud overlay on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet access points. [short pause] For more detail on deploying PPSK across specific hardware platforms, or to speak with one of our network architects about your development, visit purple dot ai. Thank you for listening to this Purple Technical Briefing.