O que é PPSK: comparando funcionalidades e modelos de implementação
Este guia fornece uma referência técnica definitiva sobre a arquitetura WiFi de Private Pre-Shared Key (PPSK) para promotores imobiliários, operadores de BTR e senhorios. Compara o PPSK com implementações de PSK partilhado e 802.1X, abrangendo o isolamento de VLAN por unidade, a compatibilidade com dispositivos IoT e a gestão automatizada do ciclo de vida das chaves. Os gestores de TI e os arquitetos de rede encontrarão orientações de implementação práticas, notas de implementação específicas do fabricante e estudos de caso reais que demonstram resultados operacionais mensuráveis.
Ouça este guia
Ver transcrição do podcast
- Resumo executivo
- Análise técnica detalhada
- O que é o PPSK?
- PPSK vs 802.1X vs PSK partilhada
- Como funciona a autenticação PPSK
- Guia de implementação
- Passo 1: Desenho lógico da rede
- Passo 2: Endereçamento IP e DHCP
- Passo 3: Seleção de hardware e configuração de PPSK
- Passo 4: Distribuição de chaves e gestão do ciclo de vida
- Melhores práticas
- Resolução de problemas e mitigação de riscos
- Modo de falha 1: O dispositivo falha na autenticação
- Modo de falha 2: Os dispositivos domésticos inteligentes não se conseguem descobrir uns aos outros
- Modo de falha 3: Limite de chaves do controlador atingido
- Modo de falha 4: VLANs não passam através de ligações trunk
- ROI e impacto empresarial
Resumo executivo
Para gestores de TI e arquitetos de rede que implementam WiFi em ambientes multi-inquilino, a escolha da arquitetura de autenticação determina tanto a postura de segurança como os custos operacionais. Este guia analisa a tecnologia Private Pre-Shared Key (PPSK) - o que é, como funciona e onde é a ferramenta certa. Ao atribuir uma chave criptográfica única a cada residente ou grupo de dispositivos, o PPSK permite o isolamento de VLAN por unidade num único SSID. Isto elimina o raio de impacto de uma palavra-passe partilhada, fornece suporte perfeito para dispositivos IoT sem interface de utilizador que não conseguem executar um suplicante 802.1X e automatiza o ciclo de vida das chaves desde a entrada até à saída do inquilino. Fornecemos orientações de implementação neutras em termos de fabricante para Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. A solução Multi-Tenant WiFi da Purple integra-se com todas estas plataformas através de uma sobreposição de cloud RADIUS, oferecendo aos operadores de BTR e proprietários a camada de orquestração para gerir chaves, VLANs e a integração de residentes à escala. Fundada em 2012, a Purple serve mais de 80.000 locais ativos e processou 440 milhões de inícios de sessão em 2024, mantendo um tempo de atividade de 99,999%.

Análise técnica detalhada
O que é o PPSK?
Private Pre-Shared Key (PPSK) - também designado por iPSK (Cisco Meraki), MPSK (HPE Aruba), DPSK (Ruckus) e ePSK (Juniper Mist) - é um método de autenticação WiFi no qual é atribuída a cada utilizador ou grupo de dispositivos uma palavra-passe única num SSID partilhado. O ponto de acesso ou controlador de cloud mapeia cada chave para uma VLAN específica, criando um segmento de rede privado e isolado para esse utilizador. Do ponto de vista do residente, basta introduzir uma palavra-passe e ligar-se. Do ponto de vista da rede, o seu tráfego é etiquetado para uma VLAN dedicada, completamente invisível para todos os outros residentes na mesma infraestrutura física.
O modelo padrão de chave pré-partilhada (PSK), conforme definido em WPA2/WPA3-Personal, utiliza um único segredo partilhado por todos os dispositivos de uma rede. Isto é simples do ponto de vista operacional, mas cria uma rede plana e indiferenciada. Num empreendimento de Build to Rent com 200 unidades, uma única palavra-passe partilhada significa que todos os residentes podem ver os dispositivos de todos os outros residentes, revogar o acesso de um inquilino que está a sair exige a rotação da palavra-passe em todo o edifício e uma única credencial comprometida expõe toda a rede.
A PPSK resolve isto ao nível da camada de associação. Quando um dispositivo se liga, apresenta a sua chave pré-partilhada durante o handshake de quatro vias do WPA2 ou WPA3. O controlador sem fios interpõe-se na ligação e valida a chave localmente (PPSK local do controlador) ou encaminha o endereço MAC do dispositivo para um servidor RADIUS para consulta. O servidor RADIUS devolve a PPSK correta para esse utilizador juntamente com um atributo de atribuição de VLAN. Se as chaves coincidirem, o dispositivo é autenticado e colocado na sua VLAN dedicada. Todo o processo é transparente para o utilizador final e não requer qualquer software especial no dispositivo.
PPSK vs 802.1X vs PSK partilhada
Compreender onde a PPSK se enquadra requer uma comparação clara com as duas alternativas entre as quais se posiciona.
PSK partilhada é o modelo mais simples: uma palavra-passe, todos os dispositivos na mesma rede. Não requer qualquer infraestrutura para além do próprio ponto de acesso. As limitações de segurança são graves em qualquer contexto multi-tenant. Não existe isolamento por utilizador, não há responsabilidade individual e a revogação do acesso para um único utilizador exige a alteração da chave para todos.
802.1X (WPA2/3-Enterprise), tal como definido pela norma IEEE 802.1X, oferece o nível mais elevado de segurança. Requer um servidor RADIUS, um fornecedor de identidade (Microsoft Entra ID, Okta ou Google Workspace) e um suplicante em cada dispositivo cliente. O suplicante lida com a troca do Extensible Authentication Protocol (EAP). Todos os portáteis geridos e smartphones corporativos possuem um suplicante. Os dispositivos IoT sem ecrã ou interface - smart TVs, colunas sem fios, controladores de climatização, câmaras de segurança - não possuem. Isto torna o 802.1X inviável como método de autenticação único para redes residenciais.
PPSK posiciona-se entre estes dois modelos. Oferece isolamento por utilizador e revogação instantânea de acesso sem necessitar de um suplicante no dispositivo cliente. Suporta todos os dispositivos IoT que os seus residentes possuem. Não fornece a responsabilidade individual baseada em certificados do 802.1X, razão pela qual a arquitetura recomendada para implementações de BTR e MDU utiliza PPSK para residentes e IoT, e 802.1X para a equipa de gestão de propriedades.
| Dimensão | PSK partilhada | PPSK | 802.1X Enterprise |
|---|---|---|---|
| Nível de segurança | Baixo - chave estática partilhada | Médio-alto - chave única por utilizador | Alto - chaves dinâmicas individuais |
| Suporte para dispositivos IoT | Sim | Sim | Não - requer suplicante |
| Complexidade de implementação | Muito simples | Simples | Complexa - RADIUS, PKI, IdP |
| Isolamento por utilizador | Não | Sim - VLAN por fração | Sim - por utilizador |
| Revogação de acesso | Requer alteração total | Eliminação instantânea da chave | Instantânea através da desativação no diretório |
| Caso de utilização ideal | Pequenas redes domésticas | BTR, MDU, alojamento de estudantes | Redes corporativas para colaboradores |

Como funciona a autenticação PPSK
Ao nível técnico, o PPSK opera dentro do modelo de autenticação WPA Personal. Quando um dispositivo se liga ao SSID, o ponto de acesso inicia o handshake de quatro vias. Numa implementação PSK standard, o AP valida a chave localmente. Numa implementação PPSK, o AP ou o controlador de nuvem intercetam a ligação e executam uma de duas operações, dependendo do modelo de implementação.
Numa implementação PPSK local ao controlador, a base de dados de chaves é armazenada diretamente no controlador sem fios. O controlador valida a chave apresentada face ao seu armazenamento local e atribui a VLAN correspondente. Este modelo não requer nenhum servidor RADIUS externo e é adequado para implementações até aproximadamente 200 unidades, dependendo da capacidade de chaves locais da plataforma do controlador.
Numa implementação PPSK baseada em RADIUS, o controlador reencaminha o endereço MAC do dispositivo para um servidor RADIUS externo. O servidor RADIUS procura o MAC no seu repositório de identidades, obtém o PPSK atribuído e devolve-o ao controlador através de uma resposta RADIUS Access-Accept. O controlador valida a chave que o dispositivo apresentou face à chave devolvida. Se coincidirem, a resposta RADIUS também transporta a atribuição de VLAN como um atributo Tunnel-Private-Group-ID. O dispositivo é autenticado e colocado na VLAN correta de forma automática. Este modelo escala para milhares de unidades e é a arquitetura recomendada para grandes implementações BTR e MDU.

Para mais detalhes sobre como o PPSK se compara em plataformas de hardware específicas, consulte o nosso diretório PPSK: comparando funcionalidades e modelos de implementação .
-
Guia de implementação
Implementar PPSK com sucesso exige um planeamento rigoroso ao nível da arquitetura de VLAN, âmbito de DHCP, seleção de hardware e gestão do ciclo de vida das chaves. Siga esta sequência para uma implementação pronta para produção.
Passo 1: Desenho lógico da rede
Não configure o hardware até que o desenho lógico esteja documentado. Num ambiente multi-tenant, a atribuição de VLAN é a principal barreira de segurança. Uma implementação BTR típica utiliza a seguinte estrutura de VLAN:
- VLANs de Residentes (10 a N): Uma VLAN exclusiva por apartamento. Isto cria o segmento de rede isolado onde os dispositivos de um residente se podem detetar uns aos outros via mDNS (permitindo Chromecast, Apple TV e Sonos), mas permanecem invisíveis para os vizinhos.
- VLAN IoT/BMS (99): Isola os sistemas de gestão técnica centralizada do edifício, CCTV e dispositivos IoT propriedade do senhorio com filtragem de saída rigorosa apenas para a internet.
- VLAN de Funcionários/Corporativa (100): Utiliza 802.1X contra o Microsoft Entra ID para a equipa de gestão da propriedade.
- VLAN de WiFi de Convidados (200): Acesso aberto ou com Captive Portal para áreas comuns e uso de visitantes.
Passo 2: Endereçamento IP e DHCP
Os lares modernos de BTR têm em média 15 a 25 dispositivos ligados. Um edifício de 200 frações registará 3.000 a 5.000 dispositivos simultâneos na rede. Dimensione os seus âmbitos DHCP em conformidade. Utilize o endereçamento privado RFC 1918. Uma sub-rede /24 fornece 254 endereços utilizáveis por VLAN, o que é suficiente para apartamentos individuais. As VLANs de IoT centrais podem necessitar de um /22 ou /23, dependendo da densidade de dispositivos.
Passo 3: Seleção de hardware e configuração de PPSK
O PPSK é suportado em todas as principais plataformas de pontos de acesso empresariais, com notas de implementação específicas do fabricante:
- Cisco Meraki (iPSK): Gerido através do Meraki Dashboard. Suporta até 5.000 entradas iPSK por rede. Integra-se com a Meraki API para o provisionamento automatizado de chaves.
- HPE Aruba (MPSK): Implementado nativamente no ArubaOS e Aruba Central. Suporta MPSK em configurações WPA2 e WPA3. Integra-se com o Aruba ClearPass para implementações empresariais suportadas por RADIUS.
- Ruckus (DPSK): Suportado através do SmartZone e Ruckus Cloud. O DPSK com SmartZone escala para milhares de chaves através de RADIUS externo.
- Juniper Mist (ePSK): Gerido na cloud com otimização de RF baseada em IA. O ePSK é configurado por WLAN no portal Mist.
- Ubiquiti UniFi (PPSK): Suporta até 1.000 entradas PPSK por rede. Nota: O UniFi PPSK é atualmente apenas WPA2 e não suporta a banda de 6 GHz.
- Cambium e Extreme: Ambos suportam PPSK através das suas respetivas plataformas de gestão na cloud.
Uma limitação crítica: a implementação do PPSK da UniFi é apenas WPA2. Se estiver a especificar pontos de acesso WiFi 6E e quiser utilizar a banda de 6 GHz para clientes PPSK, utilize Aruba, Ruckus ou Meraki, que suportam PPSK em configurações WPA3.
Passo 4: Distribuição de chaves e gestão do ciclo de vida
Gerar chaves é simples. Distribuí-las de forma segura e gerir o seu ciclo de vida é o desafio operacional que determina se o PPSK cumpre os benefícios prometidos.
- Integração na entrada: Integre o provisionamento de WiFi com o sistema de gestão de propriedades. Quando um arrendamento se inicia, gere automaticamente o PPSK e envie um código QR por e-mail para o residente. O residente digitaliza o código QR e todos os seus dispositivos ligam-se imediatamente à VLAN correta.
- Gestão contínua: Disponibilize um portal do residente onde este possa recuperar a sua chave e registar dispositivos adicionais.
- Revogação na saída: Quando um arrendamento termina, a API deve revogar imediatamente a chave. Os dispositivos do residente que está a sair perdem o acesso sem qualquer impacto nos outros inquilinos.
A solução Multi-Tenant WiFi da Purple fornece o cloud RADIUS, a orquestração de API e o portal do residente necessários para automatizar este ciclo de vida em todas as plataformas de hardware suportadas. Para orientações relacionadas sobre Guest WiFi e WiFi Analytics , consulte os recursos associados.
Melhores práticas
Limite a proliferação de SSIDs. Transmita no máximo três SSIDs por rádio: um para residentes (PPSK), um para funcionários (802.1X) e um para convidados (captive portal). Cada SSID adicional consome tempo de antena para tramas beacon, degradando o desempenho para todos os utilizadores. O PPSK permite que centenas de redes isoladas existam sob um único SSID, eliminando a necessidade de SSIDs por piso ou por apartamento. Consulte o nosso guia sobre Três SSIDs para dominar todos: convidado, Passpoint e IoT WiFi para obter a fundamentação completa da arquitetura.
Considere a aleatorização de MAC desde o primeiro dia. O iOS 14+, Android 10+ e Windows 11 utilizam endereços MAC aleatórios por predefinição. Se a sua implementação PPSK depender de consultas RADIUS baseadas em MAC, crie um fluxo de trabalho de pré-registo no processo de integração de residentes. Oriente os residentes a desativar "Endereço WiFi Privado" ou "Utilizar MAC aleatório" nas definições de dispositivo para o seu SSID específico, ou implemente uma etapa de pré-registo no captive portal que capture o MAC de hardware permanente.
Valide as portas trunk antes da entrada em funcionamento. Desenhe um esquema de VLAN limpo, implemente os pontos de acesso e, em seguida, verifique se cada ligação trunk entre os switches da camada de acesso e o núcleo de distribuição permite a gama completa de VLANs de residentes. O tráfego cairá silenciosamente se uma VLAN estiver em falta na lista de permissões do trunk. Teste com um dispositivo em cada VLAN antes de os residentes se mudarem.
Ative a reflexão mDNS por VLAN. Os residentes esperam que os seus dispositivos domésticos inteligentes funcionem. O Chromecast, Apple TV, Sonos e dispositivos semelhantes dependem de mDNS (Multicast DNS) para se descobrirem uns aos outros na rede local. Certifique-se de que o seu controlador sem fios está configurado para permitir o tráfego mDNS dentro de cada VLAN de residente, bloqueando-o ao mesmo tempo entre VLANs.
Utilize WPA3 onde os dispositivos clientes o suportem. O WPA3-SAE (Simultaneous Authentication of Equals) oferece uma proteção significativamente mais forte contra ataques de dicionário offline do que o WPA2-PSK. Implemente PPSK no modo de transição WPA3 para suportar clientes WPA2 e WPA3. A exceção é o Ubiquiti UniFi, que atualmente é apenas WPA2 para PPSK.
Para obter orientações sobre a experiência de WiFi para convidados em ambientes de hotelaria, consulte Como causar uma excelente primeira impressão com o seu WiFi para convidados .
-
Resolução de problemas e mitigação de riscos
Modo de falha 1: O dispositivo falha na autenticação
Sintoma: O dispositivo de um residente não consegue ligar-se ao SSID, apesar de utilizar a chave correta.
Causa mais provável: O dispositivo está a apresentar um endereço MAC aleatório. O servidor RADIUS realiza uma consulta MAC, não encontra nenhuma entrada correspondente para o endereço aleatório e devolve um Access-Reject.
Resolução: Oriente o residente a abrir as definições de WiFi do seu dispositivo para o seu SSID específico e a desativar "Endereço WiFi Privado" (iOS) ou "Utilizar MAC aleatório" (Android/Windows). Como alternativa, implemente um captive portal de pré-registo que capture o MAC de hardware permanente durante a integração.
Modo de falha 2: Os dispositivos domésticos inteligentes não se conseguem descobrir uns aos outros
Sintoma: O Chromecast, Apple TV ou coluna inteligente de um residente não é encontrado pelo seu telemóvel ou portátil, apesar de ambos estarem ligados ao mesmo SSID.
Causa mais provável: A isolação de clientes está ativada no SSID, ou a reflexão mDNS não está configurada corretamente no controlador sem fios.
Resolução: Desative a isolação de clientes para o SSID dos residentes. Ative a reflexão ou proxy mDNS em cada VLAN de residente no controlador sem fios. Verifique se o controlador não está a bloquear o tráfego multicast intra-VLAN.
Modo de falha 3: Limite de chaves do controlador atingido
Sintoma: Não é possível aprovisionar novos residentes porque o armazenamento de chaves PPSK está cheio.
Causa mais provável: A implementação está a utilizar PPSK local do controlador sem um servidor RADIUS externo. A maioria dos controladores limita as entradas PPSK locais a 500 ou 1000 chaves.
Resolução: Para implementações que excedam as 100 unidades, utilize sempre uma arquitetura PPSK baseada em RADIUS. O serviço de RADIUS na nuvem da Purple escala para dezenas de milhares de chaves concorrentes sem hardware para gerir.
Modo de falha 4: VLANs não passam através de ligações trunk
Sintoma: Os dispositivos em determinadas VLANs de residentes conseguem ligar-se ao SSID, mas não conseguem aceder à internet ou a outros serviços.
Causa mais provável: Os IDs de VLAN para esses residentes não são permitidos na ligação trunk entre o comutador da camada de acesso e o comutador de distribuição ou core.
Resolução: Audite todas as portas trunk no caminho desde o ponto de acesso até ao gateway de internet. Certifique-se de que todos os IDs de VLAN de residentes estão na lista de VLANs permitidas em cada trunk. Documente a configuração do trunk e inclua-a na lista de verificação de comissionamento.
ROI e impacto empresarial
A implementação de PPSK transforma o WiFi de um serviço utilitário problemático numa comodidade segura e gerida. Para operadores BTR e proprietários, o impacto empresarial é mensurável em três dimensões.
Redução dos custos de suporte. A eliminação de rotações de palavras-passe partilhadas e a resolução de problemas de conectividade IoT reduzem tipicamente os pedidos de suporte relacionados com WiFi em 40% a 60%. Um operador BTR de 180 unidades que migrou de uma PSK partilhada para HPE Aruba MPSK reportou uma redução de 50% nos pedidos de suporte nos primeiros seis meses de operação. O principal motor foi a eliminação dos problemas de emparelhamento de dispositivos domésticos inteligentes que afetavam a implementação de PSK partilhada.
Maior retenção de residentes. Oferecer uma experiência de rede segura e semelhante à de casa, que suporte dispositivos domésticos inteligentes, é um diferencial mensurável no mercado BTR premium. Os residentes que conseguem ligar todo o seu ecossistema de dispositivos - incluindo colunas inteligentes, sticks de streaming e consolas de jogos - no dia da mudança reportam pontuações de satisfação significativamente mais elevadas do que aqueles que enfrentam dificuldades de conectividade. Conformidade regulamentar. O GDPR exige que consiga demonstrar a responsabilidade pelo processamento de dados. Num contexto de WiFi, isso significa ser capaz de identificar qual o residente que gerou determinado tráfego de rede e responder a um pedido de acesso do titular dos dados com dados precisos e específicos do residente. Com uma PSK partilhada, todos os dispositivos na rede são indistinguíveis do ponto de vista do servidor RADIUS. Com PPSK, cada ligação está associada a uma chave de residente específica, que por sua vez está associada a um registo de arrendamento específico. O seu registo de auditoria fica completo.
Para obter orientações específicas do setor sobre como a inteligência WiFi impulsiona os resultados de negócio, consulte os nossos recursos sobre Hotelaria e Retalho .
Definições Principais
PPSK (Private Pre-Shared Key)
Um método de autenticação WiFi no qual é atribuída a cada utilizador ou grupo de dispositivos uma frase-passe única num SSID partilhado. Cada chave é mapeada para uma VLAN específica, proporcionando isolamento de rede sem necessitar de um suplicante no dispositivo cliente.
O principal modelo de autenticação para ambientes residenciais multi-inquilino onde o 802.1X é demasiado complexo ou incompatível com dispositivos IoT. Conhecido como iPSK (Cisco Meraki), MPSK (HPE Aruba), DPSK (Ruckus) e ePSK (Juniper Mist).
802.1X
Uma norma IEEE para controlo de acesso à rede baseado em portas. Utiliza um servidor RADIUS para autenticar utilizadores através de credenciais ou certificados individuais, fornecendo chaves de encriptação dinâmicas por utilizador e revogação instantânea de acesso.
O modelo de autenticação correto para redes de funcionários corporativos. Requer um suplicante em cada dispositivo cliente, tornando-o inadequado como o único método de autenticação para ambientes residenciais ou com forte presença de IoT.
VLAN (Virtual Local Area Network)
Um agrupamento lógico de dispositivos de rede que agem como se estivessem na mesma rede física, definido pela norma IEEE 802.1Q. As VLANs criam domínios de difusão (broadcast) separados numa infraestrutura física partilhada.
O mecanismo fundamental para isolar o tráfego de inquilinos numa implementação multi-tenant. Cada chave PPSK de residente é mapeada para uma VLAN única, criando a "bolha de WiFi" que impede os residentes de verem os dispositivos uns dos outros.
RADIUS (Remote Authentication Dial-In User Service)
Um protocolo de rede que fornece gestão centralizada de autenticação, autorização e faturação. Numa implementação PPSK, o servidor RADIUS armazena a base de dados de chaves e devolve os atributos de atribuição de VLAN ao controlador sem fios.
Necessário para implementações PPSK que excedam aproximadamente 200 unidades, onde o armazenamento de chaves local no controlador é insuficiente. A Purple fornece um serviço RADIUS na nuvem que elimina a necessidade de infraestrutura RADIUS local.
Suplicante
O componente de software num dispositivo cliente que lida com a troca EAP (Extensible Authentication Protocol) num fluxo de autenticação 802.1X. Apresenta credenciais ou certificados ao autenticador (ponto de acesso).
Presente em todos os computadores portáteis geridos e smartphones corporativos. Ausente em dispositivos IoT sem ecrã, razão pela qual o 802.1X não pode ser o único método de autenticação para redes residenciais.
Proliferação de SSIDs
A prática de transmitir demasiados nomes de rede (SSIDs) a partir de um único ponto de acesso. Cada SSID requer tramas de sinalização (beacon frames) transmitidas à taxa básica mais baixa, consumindo tempo de antena e degradando o desempenho para todos os utilizadores.
Um erro comum em implementações multi-tenant onde os operadores criam um SSID separado por andar ou por tipo de inquilino. O PPSK resolve isto ao permitir centenas de redes isoladas sob um único SSID.
mDNS (Multicast DNS)
Um protocolo que resolve nomes de host para endereços IP dentro de uma rede local sem um servidor DNS dedicado, utilizando pacotes UDP multicast na porta 5353.
Essencial para que os dispositivos IoT de consumo se descubram uns aos outros na VLAN de um residente. O Chromecast, Apple TV, Sonos e dispositivos semelhantes dependem do mDNS. Deve ser ativado dentro de cada VLAN de residente e bloqueado entre VLANs.
Aleatoriedade de endereços MAC
Uma funcionalidade de privacidade nos sistemas operativos modernos (iOS 14+, Android 10+, Windows 11) que gera um endereço MAC temporário e aleatório para cada rede WiFi, impedindo o rastreio entre redes.
Causa falhas de autenticação em implementações PPSK que dependem de endereços MAC de hardware permanentes para consultas RADIUS. Requer um fluxo de trabalho de pré-registo ou configuração ao nível do dispositivo para desativar em SSIDs específicos.
WPA3-SAE (Simultaneous Authentication of Equals)
O protocolo de autenticação utilizado em redes WPA3-Personal. Substitui o handshake de quatro vias do WPA2 por uma troca de chaves Dragonfly, proporcionando confidencialidade mútua e resistência a ataques de dicionário offline.
O padrão de encriptação recomendado para novas implementações PPSK. Suportado em Cisco Meraki, HPE Aruba e Ruckus. Ainda não suportado para PPSK em Ubiquiti UniFi à data de 2025.
Captive Portal
Uma página web que um utilizador de rede deve visualizar e com a qual deve interagir antes de lhe ser concedido acesso a uma rede WiFi pública. Aplica os termos de serviço, recolhe dados de marketing e gere os parâmetros da sessão.
Utilizado em redes WiFi abertas ou de convidados em áreas comuns de edifícios BTR, hotéis e ambientes de retalho. Uma camada de controlo empresarial, não um controlo de segurança - não encripta o tráfego WiFi.
Exemplos Práticos
Um operador de Build to Rent com 150 unidades utiliza atualmente uma única palavra-passe WiFi partilhada em todo o edifício. Os residentes queixam-se de que as suas colunas inteligentes não funcionam, o operador não consegue revogar o acesso quando um inquilino se muda e um inquilino cessante partilhou recentemente a palavra-passe publicamente online. Especificaram pontos de acesso HPE Aruba. Qual é a arquitetura correta?
Implementar HPE Aruba MPSK (Multiple PSK) suportado por um servidor RADIUS na nuvem. Configurar um único SSID de residente ('Residents_WiFi') em modo de transição WPA2/WPA3. Na base de dados RADIUS, mapear cada apartamento para uma VLAN exclusiva (VLANs 10 a 160 para 150 unidades). Integrar a API de provisionamento do RADIUS com o sistema de gestão de propriedade para que, quando um contrato de arrendamento começar, seja gerada automaticamente uma MPSK exclusiva de 16 caracteres e enviada por e-mail ao residente como um código QR. Ativar a reflexão mDNS dentro de cada VLAN de residente para que o Chromecast, Apple TV e Sonos funcionem corretamente. Desativar o isolamento de clientes no SSID de residente. Quando um contrato de arrendamento termina, o sistema de gestão de propriedade chama a API do RADIUS para eliminar a chave. Os dispositivos do residente cessante perdem o acesso em segundos. Nenhum outro residente é afetado.
Um fornecedor de alojamento para estudantes com 400 camas regista uma degradação grave da rede todos os anos em setembro, durante a semana de acolhimento. Atualmente, transmitem seis SSIDs para separar o tráfego por piso e tipo de alojamento. Utilizam hardware Cisco Meraki. Como deve ser redesenhada a rede?
Consolidar os seis SSIDs em três: 'Student_Secure' (iPSK), 'Staff' (802.1X) e 'Guest' (portal cativo). Implementar Meraki iPSK no SSID 'Student_Secure'. Pré-provisionar 400 chaves iPSK exclusivas através da API do Dashboard Meraki antes da semana de acolhimento, mapeando cada chave para uma VLAN de quarto específica. Distribuir as chaves através do portal do estudante durante o registo pré-chegada, com um código QR incluído no e-mail de boas-vindas. Dimensionar as gamas DHCP para 10 dispositivos por estudante (um /25 por VLAN fornece 126 endereços utilizáveis). Validar se todas as portas de trunk permitem toda a gama de VLAN antes do dia de acolhimento.
Perguntas de Prática
Q1. Um promotor imobiliário está a especificar o hardware de rede para um novo edifício BTR de 300 unidades. O seu consultor de TI recomenda a transmissão de um SSID separado para cada piso para "manter as coisas organizadas". Por que razão esta é uma má decisão de arquitetura e qual é a abordagem correta?
Dica: Considere o impacto das tramas de gestão no tempo de antena sem fios e como a tecnologia PPSK elimina a necessidade de SSIDs por piso.
Ver resposta modelo
A transmissão de múltiplos SSIDs causa a proliferação de SSIDs. Cada SSID exige que o ponto de acesso transmita tramas beacon à taxa básica mais baixa (normalmente 1 Mbps), consumindo tempo de antena antes de quaisquer dados do utilizador serem transmitidos. Num edifício residencial denso com 10 ou mais pontos de acesso por piso, a transmissão de um SSID por piso ao longo de 10 pisos cria 100 SSIDs no ambiente de RF, degradando severamente o desempenho de todos os utilizadores. A abordagem correta é transmitir um único SSID de residente e utilizar PPSK para atribuir cada apartamento à sua própria VLAN isolada. Isto proporciona isolamento por unidade sem qualquer sobrecarga de beacon além de um único SSID.
Q2. Um gestor de TI de um hotel deseja implementar 802.1X para todos os quartos de hóspedes para garantir a máxima segurança. Planeia emitir nomes de utilizador e palavras-passe no momento do check-in. Que barreira técnica crítica torna esta abordagem inviável para um ambiente de hotelaria e qual é a alternativa recomendada?
Dica: Pense nos tipos de dispositivos que os hóspedes trazem consigo, especificamente aqueles que não têm ecrãs ou sistemas operativos.
Ver resposta modelo
O 802.1X requer um suplicante no dispositivo cliente para processar a troca de autenticação EAP. Embora os computadores portáteis e os smartphones possuam suplicantes, os dispositivos IoT sem ecrã - smart TVs, consolas de videojogos, pens de streaming e colunas sem fios - não os possuem. Os hóspedes não conseguiriam ligar estes dispositivos à rede. A alternativa recomendada é o PPSK: emitir a cada hóspede uma chave exclusiva no momento do check-in (através da integração com o sistema de gestão de propriedade), que liga todos os seus dispositivos a uma VLAN dedicada. Quando o hóspede faz o check-out, a chave é revogada automaticamente.
Q3. Durante uma implementação de PPSK em Juniper Mist, os residentes reportam que conseguem ligar os seus smartphones ao WiFi, mas as suas colunas inteligentes não se conseguem ligar durante o processo de configuração inicial. A coluna inteligente aparece como tentando ligar-se, mas nunca conclui a autenticação. Quais são as duas causas mais prováveis e como se resolve cada uma delas?
Dica: Considere tanto a forma como a rede identifica o dispositivo durante a ligação inicial, como também se o dispositivo consegue concluir o handshake de autenticação.
Ver resposta modelo
As duas causas mais prováveis são a aleatorização de MAC e a ausência de um fluxo de trabalho de pré-registo. Primeiro, o smartphone pode ter sido pré-registado com o seu MAC de hardware permanente, enquanto a coluna inteligente apresenta um MAC aleatório que não corresponde a nenhuma entrada na base de dados RADIUS. Resolução: configurar o SSID para solicitar endereços MAC permanentes ou adicionar o MAC permanente da coluna inteligente ao perfil PPSK do residente. Segundo, algumas colunas inteligentes exigem que o dispositivo esteja na mesma rede que o telemóvel de controlo durante a configuração inicial. Se o isolamento de clientes estiver ativado, o telemóvel e a coluna não conseguem comunicar, mesmo que ambos estejam ligados. Resolução: desativar o isolamento de clientes no SSID de residente e verificar se a reflexão mDNS está ativada na VLAN de residente.
Q4. Um operador de BTR de 500 unidades implementou PPSK utilizando o armazenamento de chaves local do controlador na sua infraestrutura Ubiquiti UniFi. Após seis meses de operação, a equipa de rede descobre que os novos residentes não podem ser provisionados porque o armazenamento de chaves está cheio. O que correu mal e qual é a correção correta?
Dica: Considere o limite de escalabilidade do PPSK local do controlador e a arquitetura correta para implementações em grande escala.
Ver resposta modelo
O operador implementou o PPSK local no controlador, que armazena as chaves diretamente no controlador UniFi. O UniFi suporta um máximo de 1.000 entradas PPSK por rede. Um edifício de 500 unidades com múltiplos dispositivos por residente esgotará este limite rapidamente. A remediação correta é migrar para uma arquitetura PPSK baseada em RADIUS. Um servidor RADIUS externo - como o serviço cloud RADIUS da Purple - armazena a base de dados de chaves e escala para dezenas de milhares de chaves concorrentes. Os pontos de acesso UniFi consultam o servidor RADIUS para cada nova ligação, eliminando o limite de chaves locais do controlador. Como regra geral, qualquer implementação que exceda as 100 unidades deve utilizar PPSK baseado em RADIUS desde o início.
Continue a ler esta série
Staff WiFi vs. Guest WiFi: Melhores Práticas de Segmentação de Rede Corporativa
Um guia técnico abrangente para líderes de TI sobre como segmentar redes WiFi de funcionários e convidados. Abrange arquitetura de VLAN, autenticação 802.1X, políticas de firewall e o impacto comercial de um design de rede seguro.
Guia completo de iPSK: um guia abrangente para empresas
Este guia explica a arquitetura de Identity Pre-Shared Key (iPSK) para promotores imobiliários, operadores de BTR e senhorios que implementam WiFi multi-inquilino. Abrange a integração de RADIUS, atribuição dinâmica de VLAN, isolamento de Camada 2 e gestão automatizada do ciclo de vida das credenciais para proporcionar uma experiência de residente de ativação instantânea em escala. Detalha também o caso de negócio para eliminar os routers de consumo por fração e as vantagens operacionais de integrar o iPSK com fornecedores de identidade como o Microsoft Entra ID, Okta e Google Workspace.
Guia de PPSK em PDF: comparação de funcionalidades e modelos de implementação
Este guia de referência técnica compara a arquitetura WiFi de Chave Privada Pré-Partilhada (PPSK) com as implementações tradicionais de 802.1X e PSK padrão. Fornece aos arquitetos de rede e gestores de TI estratégias de implementação neutras em termos de fornecedor para ambientes multi-inquilino residenciais, IoT e BTR.