Nama iPSK yang keren: a comprehensive guide for businesses
Este guia explica como projetar e implementar uma taxonomia estruturada de nomenclatura de iPSK (Identity Pre-Shared Key) para implantações de WiFi corporativo em ambientes residenciais multi-inquilino, hotelaria e varejo. Ele abrange toda a arquitetura de autenticação, uma estrutura de nomenclatura em quatro partes, o gerenciamento automatizado do ciclo de vida das chaves por meio da sobreposição em nuvem do Purple e estudos de caso reais de implantações em hotéis e BTR. Desenvolvedores imobiliários, proprietários e operadores de BTR encontrarão orientações práticas sobre como segmentar o tráfego de residentes, funcionários, IoT e visitantes em um único SSID, mantendo um isolamento estrito de Camada 2 e a conformidade com o GDPR e PCI-DSS.
Ouça este guia
Ver transcrição do podcast
- Resumo executivo
- Detalhamento técnico
- Como funciona a autenticação iPSK
- iPSK vs 802.1X: quando usar cada um
- Isolamento de Camada 2 e a bolha de WiFi
- Guia de implementação: a taxonomia "nama iPSK yang keren"
- A estrutura de nomenclatura em 4 partes
- Automatizando o gerenciamento do ciclo de vida das chaves
- Melhores práticas
- Resolução de problemas e mitigação de riscos
- ROI e impacto nos negócios

Resumo executivo
O iPSK (Identity Pre-Shared Key) fornece a cada usuário ou dispositivo em sua rede sua própria senha exclusiva de WiFi, enquanto todos se conectam ao mesmo SSID. Para incorporadores imobiliários, proprietários e operadores de BTR que gerenciam edifícios multi-inquilinos, isso significa que cada residente ganha uma bolha de WiFi privada - seus dispositivos se enxergam, mas não conseguem ver os dispositivos de nenhum outro residente. A tecnologia se posiciona entre o padrão WPA2-Personal (uma senha compartilhada para todos) e o WPA3 Enterprise com 802.1X (certificados, RADIUS, PKI). O iPSK oferece controle de acesso individual sem as restrições de compatibilidade de dispositivos do 802.1X.
A questão crítica e pouco abordada é: como você nomeia suas chaves iPSK? Uma taxonomia de nomenclatura estruturada - o que este guia chama de "nama iPSK yang keren" ou estratégia inteligente de nomenclatura iPSK - determina se sua implantação se expandirá para milhares de chaves em centenas de unidades ou se entrará em colapso devido à sobrecarga operacional. Este guia fornece a estrutura, a arquitetura e as orientações de implantação para acertar desde o início.
Detalhamento técnico
Como funciona a autenticação iPSK
Quando um dispositivo se conecta a um SSID habilitado para iPSK, o Wireless LAN Controller (WLC) intercepta a tentativa de conexão e encaminha o endereço MAC do dispositivo para um servidor RADIUS. O servidor RADIUS consulta seu armazenamento de identidade e retorna uma mensagem Access-Accept contendo um Par Atributo-Valor específico do fabricante: a PSK exclusiva atribuída a esse dispositivo. O WLC valida a chave apresentada pelo dispositivo em relação à PSK retornada. Se corresponderem, o dispositivo é autenticado.
Criticamente, a resposta RADIUS também carrega atributos de atribuição de VLAN e política de largura de banda. Isso significa que um único SSID pode atender residentes na VLAN 10, funcionários na VLAN 20, dispositivos IoT na VLAN 30 e visitantes na VLAN 40 - cada um com políticas de rede diferentes - sem a necessidade de SSIDs adicionais ou infraestrutura física.

A terminologia dos fabricantes varia: a Cisco Meraki chama isso de iPSK, a HPE Aruba chama de MPSK (Multi-PSK) e a Ruckus chama de DPSK (Dynamic PSK). O padrão subjacente IEEE 802.11 e a troca de atributos RADIUS são consistentes em todos os três; apenas os dicionários RADIUS específicos de cada fabricante diferem. A sobreposição em nuvem da Purple abstrai essa complexidade de fabricante, apresentando uma interface unificada de gerenciamento de chaves, independentemente de seus pontos de acesso serem Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks ou Fortinet.
iPSK vs 802.1X: quando usar cada um
WPA3 Enterprise com 802.1X é a escolha correta para uma frota de dispositivos corporativos totalmente gerenciada. Se os seus laptops e telefones estão registrados em um MDM com certificados já implantados, o 802.1X oferece a postura de segurança mais robusta. O iPSK é a escolha correta quando você não controla os dispositivos que se conectam à sua rede - o que descreve todos os ambientes residenciais multi-tenant, hotelaria e varejo. Dispositivos IoT, smart TVs, consoles de videogame e aparelhos de streaming não possuem suplicante 802.1X. O iPSK os suporta sem comprometer a segurança.
Isolamento de Camada 2 e a bolha de WiFi
A característica que define o iPSK para implantações multi-tenant é o isolamento de Camada 2. Os dispositivos vinculados à chave do Residente A não conseguem ver os dispositivos na chave do Residente B, mesmo quando ambos estão conectados ao mesmo ponto de acesso físico. Com a reflexão mDNS ativada, o Chromecast, o alto-falante inteligente e os eletrodomésticos conectados do Residente A descobrem uns aos outros como fariam em uma rede doméstica. Esta é a arquitetura de Multi-Tenant WiFi da Purple: uma rede, uma bolha de WiFi por residente, suporte completo a IoT e isolamento estrito entre residentes.
Guia de implementação: a taxonomia "nama iPSK yang keren"
Uma implantação de iPSK escalável exige uma convenção de nomenclatura estruturada e legível por máquina. Sem ela, gerenciar milhares de chaves em múltiplos locais torna-se um gargalo operacional. O nome da chave não é estético - ele é o identificador principal que vincula a política de rede ao sistema de provisionamento.
A estrutura de nomenclatura em 4 partes
Recomendamos uma estrutura em quatro partes: [Segmento]-[Localização]-[Identificador]-[Função]
Segmento define a categoria de rede de alto nível. Use prefixos curtos e consistentes: RES para Residente, STF para Equipe (Staff), IOT para Internet das Coisas, VIS para Visitante, GST para Hóspede (transitório, como em hotel). Mantenha os prefixos com três caracteres para facilitar a leitura nos logs do RADIUS.
Localização codifica o local físico ou edifício. Use um código de local consistente do seu sistema de gestão de propriedades: LND para Londres, BLD1 para Edifício 1, HTLMCR para Hotel Manchester. Isso permite que operadoras multi-site filtrem chaves por localização sem precisar consultar um banco de dados separado.
Identificador especifica a unidade, departamento ou grupo de dispositivos. Para residencial: APT204, UNIT07B. Para equipe: HR, HOUSEKEEPING, MAINTENANCE. Para IoT: HVAC, CCTV, LIFT. Mantenha os identificadores curtos e derivados do seu registro de ativos ou sistema de locação existente.
Função define o nível da política de acesso. FULL para acesso residencial irrestrito, ADMIN para acesso elevado da equipe, SENSOR para leitura exclusiva de IoT, CAPTIVE para acesso ao portal de visitantes. Este campo mapeia diretamente para o perfil de política do RADIUS retornado na autenticação.
Exemplos práticos:
RES-BLD1-APT204-FULL: Residente no Edifício 1, Apartamento 204, acesso total à rede.STF-LND-HR-ADMIN: Equipe em Londres, departamento de RH, acesso de nível admin.IOT-BLD2-HVAC-SENSOR: Dispositivo IoT no Edifício 2, sistema HVAC, acesso apenas a sensores.GST-HTLMCR-RM312-FULL: Hóspede de hotel em Manchester, Quarto 312, acesso total de hóspede.
Automatizando o gerenciamento do ciclo de vida das chaves
A convenção de nomenclatura só entrega seu valor real quando está integrada aos seus sistemas de provisionamento. Em um ambiente BTR, o nome da chave deve ser mapeado para um campo em seu Property Management System (PMS). Quando um registro de locação é criado, o PMS aciona o Purple para gerar a chave RES-BLD1-APT204-FULL e ativá-la. Quando a locação termina, o PMS aciona o Purple para revogá-la. Sem intervenção manual. Sem rotação de senhas para outros residentes.
O Purple integra-se com Microsoft Entra ID, Okta e Google Workspace como provedores de identidade. Para WiFi de funcionários, o provisionamento SCIM garante que, quando a conta de um funcionário é desprovisionada em seu IdP, sua chave iPSK seja revogada automaticamente. Isso elimina a lacuna de acesso que os processos manuais deixam aberta.
Melhores práticas
Quatro padrões operacionais definem uma implantação de iPSK de nível de produção.
Primeiro, force o uso de endereços MAC permanentes. O iOS 14 e posterior, o Android 10 e posterior, e o Windows 11 usam a randomização de endereços MAC por padrão. Um endereço MAC randomizado não corresponderá ao repositório de identidade RADIUS e falhará na autenticação. Implemente um portal de pré-registro onde os usuários registram o endereço MAC permanente de seus dispositivos antes de conectar, ou configure seu SSID para exigir endereços MAC permanentes por meio das configurações do WLC.
Segundo, planeje para a resiliência do RADIUS. Sua implantação de iPSK é tão confiável quanto sua infraestrutura RADIUS. Implante servidores RADIUS primários e secundários com failover automatizado configurado no WLC. O RADIUS-as-a-Service do Purple oferece 99,999% de tempo de atividade, removendo a carga operacional de gerenciar a infraestrutura RADIUS internamente.
Terceiro, valide os dicionários RADIUS específicos do fornecedor durante a fase de testes. O Cisco Meraki usa o atributo Tunnel-Password. O HPE Aruba usa Aruba-MPSK-Passphrase. O Ruckus usa Ruckus-DPSK-Passphrase. Seu servidor RADIUS deve ter o dicionário correto do fornecedor carregado e seus perfis de política devem referenciar o nome do atributo correto para o seu hardware. Teste isso em um ambiente de homologação antes da implantação em produção.
Quarto, segmente o tráfego de IoT desde o primeiro dia. Sempre atribua dispositivos IoT a uma VLAN dedicada com acesso de saída restrito. O prefixo IOT- em sua convenção de nomenclatura deve acionar automaticamente o perfil de política RADIUS de IoT, que coloca o dispositivo na VLAN 30 com regras de firewall que bloqueiam o movimento lateral para as VLANs de residentes ou funcionários.
Resolução de problemas e mitigação de riscos
| Modo de falha | Causa raiz | Mitigação |
|---|---|---|
| Tempo limite de autenticação excedido na primeira conexão | A latência do servidor RADIUS excede o limite de tempo limite do WLC | Otimize o desempenho das consultas RADIUS; ative o cache RADIUS local no WLC quando suportado pelo fornecedor |
| Dispositivo rejeitado apesar da senha correta | Dispositivo cliente apresentando um endereço MAC aleatório | Impor MAC address permanente via política de MDM ou portal de pré-registro |
| Atribuição incorreta de VLAN | Mapeamento incorreto de atributos RADIUS para o fornecedor de hardware específico | Validar dicionários RADIUS específicos do fornecedor durante a fase de testes; testar explicitamente a atribuição de VLAN para cada segmento |
| Esgotamento de chaves em SSID de alta densidade | Limite de hardware do WLC para o máximo de PSKs exclusivas por SSID | Descarregar o gerenciamento de chaves para o cloud RADIUS da Purple; segmentar áreas de alta densidade em múltiplos SSIDs se os limites de hardware forem rígidos |
| Chaves obsoletas após a saída de funcionários | Processo manual de revogação de chaves não seguido | Integrar com o Microsoft Entra ID ou Okta via SCIM; automatizar a revogação no desprovisionamento de contas |
ROI e impacto nos negócios
Para operadoras de BTR, o WiFi gerenciado como uma comodidade fornecida via iPSK garante um prêmio de aluguel de £15 a £30 por unidade por mês, de acordo com a pesquisa do setor da British Property Federation. Os períodos de inatividade na mudança de inquilinos reduzem de 5 a 10 dias porque a conectividade está disponível no primeiro dia, sem a espera de uma instalação de banda larga. Com 200 unidades, um prêmio mensal de £20 por unidade representa £48.000 por ano em receita incremental - contra um custo de overlay de software que é uma fração desse valor.
Para operadoras de hotelaria, o gerenciamento automatizado do ciclo de vida das chaves via integração com PMS elimina inteiramente o fluxo de trabalho de senha de WiFi na recepção. Os hóspedes recebem sua chave exclusiva no check-in, e ela é revogada no check-out. O log de auditoria da rede fornece um registro completo de qual quarto estava conectado em qualquer momento específico, apoiando tanto investigações de segurança quanto evidências de conformidade com PCI-DSS.
Para o varejo, o iPSK permite a segmentação em conformidade com o PCI-DSS de dispositivos de processamento de pagamento em uma VLAN isolada criptograficamente, mesmo em uma infraestrutura física compartilhada. Isso elimina a necessidade de redes físicas separadas para terminais de POS e WiFi de convidados, reduzindo os custos de hardware e cabeamento em cada local.
Para explorar mais esses recursos, consulte nossos materiais sobre Guest WiFi , WiFi Analytics e nossos guias verticais para Varejo , Saúde , Hotelaria e Transporte . Para leituras técnicas relacionadas, consulte Três SSIDs para governar todos: guest, Passpoint e IoT WiFi e o guia complementar Guia de logo iPSK: um guia completo para empresas .
Definições principais
iPSK (Identity Pre-Shared Key)
Um mecanismo de autenticação onde cada usuário ou dispositivo recebe uma chave pré-compartilhada exclusiva para um único SSID. O WLC encaminha o endereço MAC do dispositivo para um servidor RADIUS, que retorna o PSK correto e a política de rede associada. Também chamado de MPSK (HPE Aruba) ou DPSK (Ruckus).
As equipes de TI encontram o iPSK quando precisam de controle de acesso por dispositivo em ambientes onde o 802.1X é impraticável - implantações residenciais multi-inquilino, hospitalidade, varejo e IoT.
RADIUS (Remote Authentication Dial-In User Service)
Um protocolo de rede definido na RFC 2865 que fornece autenticação, autorização e contabilização (AAA) centralizadas para acesso à rede. Em uma implantação iPSK, o servidor RADIUS mantém o armazenamento de identidade mapeando endereços MAC para PSKs exclusivos e atribuições de VLAN.
O RADIUS é a camada de inteligência em uma implantação iPSK. Sem um servidor RADIUS funcionando, nenhum novo dispositivo pode se autenticar. A resiliência do RADIUS - servidores primários e secundários com failover - é um requisito de projeto inegociável.
VLAN (Virtual Local Area Network)
Um segmento de rede lógico definido na Camada 2 do modelo OSI. Em uma implantação iPSK, o RADIUS retorna uma tag de VLAN com cada resposta Access-Accept, colocando o dispositivo autenticado no segmento de rede correto - residente, equipe, IoT ou visitante.
A atribuição de VLAN via RADIUS é o que torna o iPSK útil para implantações multi-inquilino. Sem isso, todos os dispositivos compartilham o mesmo segmento de rede, independentemente de sua chave, eliminando os benefícios de segurança e de política.
WLC (Wireless LAN Controller)
O dispositivo de rede que gerencia os pontos de acesso e aplica as políticas de WiFi. Em uma implantação iPSK, o WLC intercepta as tentativas de conexão, consulta o servidor RADIUS e aplica o PSK retornado e a política de VLAN ao dispositivo que está se conectando.
A escolha do fornecedor de WLC determina quais atributos do RADIUS e dicionários específicos do fornecedor você precisa. Cisco Meraki, HPE Aruba e Ruckus implementam o iPSK com nomes de atributos ligeiramente diferentes.
Randomização de endereço MAC
Um recurso de privacidade no iOS 14+, Android 10+ e Windows 11 que faz com que os dispositivos apresentem um endereço MAC gerado aleatoriamente em vez de seu endereço MAC de hardware permanente ao se conectarem a redes WiFi.
A randomização de MAC é a causa mais comum de falhas de autenticação iPSK em novas implantações. Como o iPSK depende de consultas de endereço MAC no armazenamento de identidade do RADIUS, um MAC randomizado não corresponderá a nenhum registro e a conexão será rejeitada.
SSID (Service Set Identifier)
O nome de uma rede WiFi conforme transmitido pelos pontos de acesso. Em uma implantação iPSK, todos os segmentos de usuários - moradores, funcionários, IoT, visitantes - conectam-se ao mesmo SSID. O servidor RADIUS os diferencia pelo endereço MAC e retorna a chave e a política apropriadas.
Um objetivo principal de design do iPSK é minimizar o número de SSIDs. Cada SSID adicional consome tempo de transmissão com pacotes de gerenciamento. Uma implantação iPSK bem projetada atende a todos os segmentos a partir de um único SSID.
Isolamento de Camada 2
Segmentação de rede na camada de enlace (Camada 2 do modelo OSI) que impede que dispositivos em diferentes segmentos de rede se comuniquem diretamente, mesmo quando compartilham a mesma infraestrutura física e SSID.
O isolamento de Camada 2 é o mecanismo técnico que cria a bolha de WiFi em implantações multi-inquilino. Ele garante que os dispositivos do Residente A não possam ver os dispositivos do Residente B, atendendo tanto aos requisitos de segurança quanto às obrigações do GDPR sobre a privacidade dos residentes.
mDNS (Multicast DNS)
Um protocolo que permite aos dispositivos se descobrirem em uma rede local sem um servidor DNS central, usado pelo Chromecast, Apple AirPlay, Sonos e pela maioria dos dispositivos de casa inteligente para descoberta de dispositivos.
A reflexão mDNS deve ser habilitada explicitamente dentro de cada segmento de rede do residente para que os dispositivos de casa inteligente funcionem corretamente. Sem isso, o Chromecast e o telefone do residente estarão na mesma chave, mas incapazes de se descobrir, gerando chamados de suporte.
SCIM (System for Cross-domain Identity Management)
Um protocolo padrão aberto (RFC 7643, RFC 7644) para automatizar a troca de informações de identidade de usuário entre provedores de identidade e provedores de serviços. Em um contexto iPSK, o SCIM permite o provisionamento e a revogação automática de chaves quando contas de funcionários são criadas ou excluídas no Microsoft Entra ID ou Okta.
A integração SCIM elimina a lacuna de acesso que os processos manuais deixam abertos. Sem ela, a chave iPSK de um funcionário pode permanecer ativa após ele deixar a organização, representando um risco de segurança difícil de auditar em escala.
Exemplos práticos
Um hotel de 200 quartos precisa fornecer WiFi para hóspedes, funcionários e dispositivos IoT (fechaduras de portas, sensores de HVAC, câmeras IP) a partir de uma única infraestrutura física. A equipe de TI deseja um provisionamento automatizado de chaves vinculado ao fluxo de trabalho de check-in/check-out do PMS. Como eles devem estruturar sua convenção de nomenclatura de iPSK e sua arquitetura de provisionamento?
Defina quatro segmentos: GST (hóspede), STF (funcionário), IOT (dispositivos IoT) e MGT (gerenciamento). Use o código do local do hotel (por exemplo, HTLMCR para Manchester) como o campo de localização. Para chaves de hóspedes, use o número do quarto como identificador: GST-HTLMCR-RM201 até GST-HTLMCR-RM400. Para chaves de funcionários, use o departamento: STF-HTLMCR-HOUSEKEEPING, STF-HTLMCR-RECEPTION. Para IoT, use o tipo de dispositivo e o andar: IOT-HTLMCR-DOORLOCK-FL1, IOT-HTLMCR-HVAC-FL2.
Integre o PMS com a API do Purple. No check-in, o PMS aciona o Purple para ativar a chave do quarto atribuído. No check-out, ele aciona a revogação. As chaves dos funcionários são provisionadas por meio da integração SCIM do Microsoft Entra ID e revogadas no desprovisionamento da conta.
Os perfis de política RADIUS mapeiam cada segmento para uma VLAN: VLAN 10 para hóspedes (acesso à internet, desvio de Captive Portal após ativação do PMS), VLAN 20 para funcionários (acesso corporativo), VLAN 30 para IoT (saída restrita, sem movimentação lateral). Implante servidores RADIUS primários e secundários com failover configurado no WLC.
Um operador de BTR está implantando WiFi multi-inquilino em um edifício residencial de 150 unidades. Os residentes esperam um comportamento de rede doméstica: Chromecast, alto-falantes inteligentes e dispositivos IoT devem funcionar juntos. O operador também precisa garantir que, quando um residente se mudar, seu acesso seja encerrado sem afetar nenhum outro residente. Como o iPSK deve ser configurado e nomeado?
Atribua a cada residente uma chave exclusiva seguindo o padrão RES-BLD1-APT[número da unidade]-FULL, por exemplo, RES-BLD1-APT047-FULL. Todos os dispositivos pertencentes a esse residente - telefone, laptop, Chromecast, alto-falante inteligente, eletrodomésticos conectados - usam a mesma chave. A política RADIUS para o segmento RES- ativa a reflexão mDNS dentro da VLAN do residente, para que os dispositivos na mesma chave se descubram como fariam em uma rede doméstica.
O isolamento de Camada 2 é aplicado entre as chaves: os dispositivos do Residente A não conseguem ver os dispositivos do Residente B, mesmo no mesmo ponto de acesso. Integre com a plataforma de gestão de propriedades por meio da API do Purple. Na mudança de entrada (move-in), a plataforma ativa a chave para o apartamento atribuído. Na mudança de saída (move-out), ela a revoga. O próximo residente recebe uma nova chave na data de sua mudança.
Para IoT de áreas comuns (elevadores, controle de acesso, CFTV), use um segmento IOT- separado com uma VLAN restrita. Para acesso de visitantes (entregadores, prestadores de serviços), implante um segmento VIS- com um Captive Portal e chaves com limite de tempo.
Questões práticas
Q1. Você é o diretor de TI de um empreendimento BTR de 300 unidades. O gerente de propriedade deseja permitir que os residentes adicionem novos dispositivos à sua rede sem ligar para o helpdesk. A randomização de endereços MAC está habilitada na maioria dos dispositivos dos residentes. Projete um fluxo de integração que resolva ambos os problemas sem comprometer o modelo de segurança iPSK.
Dica: Considere um portal de autoatendimento que captura o endereço MAC permanente durante a etapa de registro do dispositivo e como isso se integra ao repositório de identidades RADIUS.
Ver resposta modelo
Implante um portal de autoatendimento para residentes acessível via Captive Portal do edifício na primeira conexão. Quando um residente conecta um novo dispositivo, o portal detecta o endereço MAC e solicita que ele faça login com suas credenciais de residente (integradas ao sistema de gestão de propriedades via OAuth). No login, o portal registra o endereço MAC permanente do dispositivo associado à chave iPSK existente do residente (ex: RES-BLD1-APT204-FULL) no repositório de identidades RADIUS. O dispositivo é então adicionado ao segmento VLAN 10 existente do residente. Para lidar com a randomização de MAC, o portal inclui um guia passo a passo para desabilitar a randomização de MAC no tipo de dispositivo específico (iOS, Android, Windows), com o endereço MAC permanente exibido para confirmação antes do registro. Essa abordagem mantém o modelo de segurança - apenas residentes autenticados podem registrar dispositivos - enquanto elimina chamados de helpdesk para adições de dispositivos.
Q2. Uma rede de varejo com 50 lojas deseja usar iPSK para segmentar terminais de PDV, tablets de funcionários, sinalização digital e WiFi de convidados em VLANs separadas. A equipe de TI está preocupada com a conformidade com o PCI DSS para o segmento de PDV. Qual convenção de nomenclatura e design de política RADIUS você recomendaria?
Dica: O PCI DSS exige que os ambientes de dados de portadores de cartão sejam isolados de outros segmentos de rede. Considere como a atribuição de VLAN via RADIUS pode impor esse isolamento e quais evidências a trilha de auditoria fornece.
Ver resposta modelo
Defina quatro segmentos com atribuições de VLAN distintas: POS- (VLAN 10, ambiente de dados de portadores de cartão PCI-DSS, regras rígidas de firewall de saída, sem movimento lateral), STF- (VLAN 20, tablets da equipe e acesso corporativo), SGN- (VLAN 30, sinalização digital, apenas internet, sem acesso corporativo), GST- (VLAN 40, WiFi de convidados com Captive Portal). Use o código da loja como o campo de localização: POS-STORE042-TILL01, STF-STORE042-TABLET03, SGN-STORE042-DISPLAY01, GST-STORE042-GUEST.
A política RADIUS para POS- deve retornar a VLAN 10 com regras de firewall que restrinjam o tráfego de saída apenas ao intervalo de IPs do processador de pagamento e bloqueiem todas as conexões laterais de entrada. Para fins de evidência de auditoria PCI-DSS, os logs do RADIUS fornecem um registro com data e hora de cada autenticação de terminal de PDV, incluindo endereço MAC, atribuição de VLAN e duração da sessão. Isso demonstra que os dispositivos de PDV são colocados de forma consistente na VLAN isolada, atendendo ao Requisito 1.3 do PCI-DSS (restringir o tráfego de entrada e saída ao que for necessário para o ambiente de dados do portador do cartão).
Q3. Seu servidor RADIUS fica offline durante um sábado movimentado em um hotel de 200 quartos. Novos hóspedes não conseguem se conectar ao WiFi, mas os dispositivos já conectados não são afetados. O fornecedor de TI do hotel diz que a correção levará quatro horas. Quais mitigações imediatas estão disponíveis e qual mudança de arquitetura evitaria esse cenário no futuro?
Dica: Considere tanto o impacto imediato na experiência do convidado quanto o design de resiliência de longo prazo. Pense no que acontece com as sessões existentes em comparação com as novas autenticações quando o RADIUS estiver indisponível.
Ver resposta modelo
Mitigação imediata: a maioria das plataformas WLC suporta um modo de failover do RADIUS que recorre a uma PSK local se o servidor RADIUS estiver inacessível. Configure um SSID de fallback temporário com uma PSK compartilhada com tempo limitado para novas conexões de hóspedes durante a interrupção, comunicada pela recepção. As sessões já autenticadas não são afetadas porque a WLC apenas consulta o RADIUS para novas tentativas de conexão, não para sessões em andamento.
Mudança de arquitetura de longo prazo: implante um servidor RADIUS secundário em uma zona de disponibilidade ou data center diferente, com failover automático configurado na WLC. O RADIUS-as-a-Service da Purple oferece essa redundância por padrão, com um SLA de tempo de atividade de 99,999%. Para implantações do RADIUS locais, configure a WLC com um endereço de servidor RADIUS primário e secundário e defina o tempo limite de failover para no máximo três segundos para minimizar o impacto para os hóspedes durante uma falha no servidor primário. Teste o failover trimestralmente como parte do seu cronograma de manutenção de rede.
Continue a ler esta série
Uu PPSK 2023: comparando recursos e modelos de implantação
Este guia de referência técnica compara a arquitetura WiFi Unique per-User Private Pre-Shared Key (UU PPSK) com as implantações tradicionais de PSK compartilhado e 802.1X, com foco específico no cenário de 2023 de implementações de fornecedores e recursos de plataforma. Ele fornece a desenvolvedores imobiliários, operadores de BTR e proprietários de MDU estratégias de implantação práticas, orientações de arquitetura de VLAN e fluxos de trabalho automatizados de gerenciamento de ciclo de vida. O guia abrange três modelos de implantação, estudos de caso do mundo real e as implicações de conformidade de cada abordagem de autenticação.
PPSK xaverius: comparando recursos e modelos de implantação
Este guia definitivo examina a arquitetura PPSK xaverius para ambientes multi-inquilinos, como Build to Rent e alojamentos estudantis. Ele compara modelos de implantação, detalha estratégias de implementação e explica como o isolamento de VLAN por unidade oferece uma experiência de WiFi semelhante à residencial, mantendo a segurança corporativa.
PPSK mun: comparando recursos e modelos de implantação
Este guia de referência técnica compara a arquitetura Private Pre-Shared Key (PPSK) com as implantações tradicionais de 802.1X e PSK padrão. Ele fornece aos arquitetos de rede e gerentes de TI estratégias de implementação independentes de fornecedor para ambientes residenciais multi-tenant, IoT e BTR.