Staff WiFi Captive Portal: Onboarding and Authenticating Employees

Staff WiFi Captive Portal: Onboarding and Authenticating Employees Uma Apresentação de Inteligência de WiFi da Purple Enterprise [INTRODUÇÃO - aproximadamente 1 minuto] Bem-vindo à série de Inteligência de WiFi da Purple Enterprise. Hoje estamos cobrindo um tópico que fica na interseção de segurança, operações de RH e arquitetura de rede: o staff WiFi captive portal. Agora, eu sei o que alguns de vocês podem estar pensando. Um captive portal para funcionários? Isso não é o que você usa para convidados? E esse é exatamente o equívoco que precisamos abordar de antemão. Um staff WiFi captive portal não é uma splash page de convidados com um logotipo diferente. É um portal de integração estruturado que autentica funcionários individualmente, impõe a aceitação de políticas e registra dispositivos antes de conceder acesso à sua rede operacional. Faça isso da maneira certa e você eliminará a maior vulnerabilidade na maioria das implantações de WiFi corporativas: a chave pré-compartilhada compartilhada. Faça errado e você terá ex-funcionários, prestadores de serviços e dispositivos pessoais conectados à sua rede de funcionários indefinidamente. Vamos entrar na arquitetura. [MERGULHO TÉCNICO PROFUNDO - aproximadamente 5 minutos] O problema fundamental com a maioria das implantações de WiFi para funcionários é a senha compartilhada. Uma única chave pré-compartilhada WPA2, escrita em um post-it no escritório administrativo, compartilhada em um grupo de WhatsApp e nunca alterada quando alguém sai. Em um hotel de 200 quartos com 80 funcionários, essa senha foi compartilhada com cerca de 80 pessoas, seus parceiros que pegaram o telefone emprestado e pelo menos três ex-funcionários. Isso não é uma rede. Isso é uma porta aberta. O staff WiFi captive portal resolve isso substituindo a credencial compartilhada por um fluxo de integração com identidade verificada. Veja como funciona na prática. Quando um novo funcionário conecta seu dispositivo à rede de funcionários pela primeira vez, ele acessa um SSID de provisionamento. Esta é uma rede aberta, mas é um jardim murado - ela roteia apenas para o portal de integração e para o seu provedor de identidade. Nada mais. O funcionário é redirecionado para o captive portal, onde se autentica usando sua identidade corporativa. Na maioria dos ambientes corporativos atuais, isso significa Single Sign-On via Microsoft Entra ID, Okta ou Google Workspace. Uma vez que o provedor de identidade confirma que o funcionário está ativo e no grupo correto, o portal faz uma de duas coisas, dependendo da sua arquitetura de autenticação. Em uma implantação baseada em credenciais usando PEAP e MSCHAPv2, o portal valida as credenciais e emite um token de acesso à rede. Em uma implantação baseada em certificado usando EAP-TLS, o portal aciona a geração do certificado. Um certificado X.509 específico do dispositivo é emitido pela sua Autoridade de Certificação, empacotado em um perfil de configuração - um arquivo .mobileconfig no iOS ou um perfil Passpoint no Android - e enviado para o dispositivo. O dispositivo instala o perfil, desconecta-se do SSID de provisionamento e conecta-se automaticamente ao SSID seguro de funcionários usando o certificado para autenticação EAP-TLS. A partir desse momento, toda vez que o dispositivo se conecta à rede de funcionários, o servidor RADIUS valida o certificado. Sem solicitação de senha. Sem login manual. O dispositivo simplesmente se conecta, de forma silenciosa e segura. Agora vamos falar sobre por que o EAP-TLS é o estado-alvo para a maioria das implantações corporativas. O padrão IEEE 802.1X define a estrutura, mas o EAP-TLS é o método que elimina totalmente o roubo de credenciais do caminho de autenticação. Não há senha para sofrer phishing. Não há hash para sofrer força bruta. O certificado está vinculado ao dispositivo. Se o dispositivo for perdido ou roubado, você revoga o certificado em sua Autoridade Certificadora e o servidor RADIUS nega o acesso na próxima tentativa de conexão. Se o funcionário sair da empresa, você desativa sua conta no provedor de identidade e, como o certificado foi emitido contra essa identidade, a integração SCIM propaga o desprovisionamento automaticamente. O acesso termina quando o vínculo da pessoa termina. Esta é a arquitetura que organizações como Premier Inn e Whitbread precisam ao gerenciar centenas de propriedades com milhares de dispositivos de funcionários em uma propriedade distribuída. Você não pode gerenciar isso em escala com senhas compartilhadas e revogação manual. Vamos também abordar a dimensão do BYOD, porque é aqui que o Captive Portal se torna particularmente valioso. Na maioria dos ambientes de hotelaria, varejo e eventos, uma proporção significativa de funcionários usa dispositivos pessoais para tarefas operacionais. A equipe de governança verifica as atribuições dos quartos em seus próprios smartphones. Os associados de varejo usam tablets pessoais para consultas de inventário. As equipes de operações de estádios usam telefones pessoais para comunicações. Esses são dispositivos não gerenciados. Você não controla a versão do sistema operacional, o status do antivírus ou quais outros aplicativos estão instalados. Eles devem ser tratados, na melhor das hipóteses, como semiconfiáveis. O Captive Portal de WiFi para funcionários lida com o BYOD colocando esses dispositivos em uma VLAN dedicada após a autenticação. A VLAN dá a eles acesso aos aplicativos internos específicos de que precisam - o sistema de gerenciamento de propriedades, a interface de ponto de venda, o aplicativo de agendamento - e nada mais. Eles não podem acessar seus servidores corporativos, seus sistemas financeiros ou sua rede de dispositivos gerenciados. Isso é segmentação de VLAN aplicada no nível do RADIUS, e é a implementação prática do princípio de zero-trust: verificar a identidade e, em seguida, conceder o acesso mínimo necessário. Mais um elemento arquitetônico que vale a pena cobrir: a Política de Uso Aceitável, ou AUP. O Captive Portal é o ponto de aplicação natural para a aceitação da AUP. Antes que um funcionário obtenha acesso à rede da equipe, o portal apresenta a política - cobrindo uso aceitável, monitoramento, manuseio de dados e consequências de uso indevido - e exige um reconhecimento explícito. Isso cria um registro auditável e com carimbo de data/hora da aceitação da política. Sob a GDPR, isso importa. Sob a PCI DSS, para qualquer rede que toque em dados de titulares de cartão, isso importa. E no caso de uma investigação disciplinar envolvendo uso indevido da rede, isso importa consideravelmente. Agora, largura de banda. É aqui que o Purple Shield se torna diretamente relevante. Em ambientes de equipe de alta densidade - um hotel durante um fim de semana de lotação máxima, uma rede de varejo na Black Friday, um estádio em dia de jogo - a disputa por largura de banda na rede de funcionários é um problema operacional real. O Purple Shield opera no nível de DNS, bloqueando payloads de anúncios, scripts de rastreamento e domínios de malware antes que cheguem ao dispositivo. O efeito prático é uma redução de até 40% no total de dados baixados na rede, de acordo com os próprios dados da Purple. Para os dispositivos da equipe, isso significa carregamentos de página mais rápidos, menor consumo de bateria do dispositivo e mais largura de banda disponível para o tráfego operacional. As páginas carregam até 3,5 vezes mais rápido quando as mais de 120 consultas DNS típicas de uma página cheia de anúncios são eliminadas antes de atingirem a rede. Você obtém essa melhoria sem tocar no hardware, sem reconfigurar os pontos de acesso e sem qualquer configuração por dispositivo. [RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ARMADILHAS - aproximadamente 2 minutos] Deixe-me apresentar a sequência de implementação e os modos de falha que você deve observar. Comece com sua arquitetura de VLAN antes de configurar um único ponto de acesso. Defina no mínimo três VLANs: equipe, convidados e IoT. Mapeie suas políticas de firewall. Obtenha a aprovação da sua equipe de segurança. Os erros mais caros em implantações de WiFi acontecem quando a rede é construída primeiro e a arquitetura de segurança é adicionada depois. Segundo, implante sua infraestrutura RADIUS com redundância. Uma única falha no servidor RADIUS bloqueia todos os membros da equipe fora da rede simultaneamente. Em um hotel, isso significa que a recepção não pode processar check-ins. Em uma loja de varejo, significa que os sistemas de ponto de venda não podem autenticar. Implante pelo menos dois servidores RADIUS em uma configuração ativo-passivo e teste o failover antes de entrar em operação. Terceiro, integre seu servidor RADIUS com seu provedor de identidade via LDAP ou SAML. É isso que permite o desprovisionamento automático. Quando um funcionário é desativado no Microsoft Entra ID ou Okta, o servidor RADIUS para de aceitar suas credenciais ou seu certificado na próxima tentativa de conexão. Sem etapa manual, sem fila de chamados, sem lacuna entre a saída e a remoção do acesso. Em quarto lugar, projete o fluxo de integração do seu Captive Portal para o usuário menos técnico da sua equipe. Não para o gerente de TI. Pense no operador de armazém temporário que nunca instalou um perfil de configuração. Instruções claras, interface com a identidade visual da marca e um número de contato do suporte visível em todas as telas. Agora, as armadilhas. O modo de falha mais comum é o "walled garden" ser permissivo demais. Se o seu SSID de provisionamento permitir acesso geral à internet, a equipe simplesmente permanecerá nele em vez de concluir o fluxo de integração. Bloqueie-o apenas para o portal, os endpoints do provedor de identidade e o servidor de download de certificados. Nada mais. A segunda armadilha é a fragmentação do Android. O iOS lida com perfis dot-mobileconfig de forma consistente. O Android não. Diferentes fabricantes e versões de sistema operacional lidam com a instalação de certificados de maneiras distintas. Teste seu fluxo de integração nos dispositivos Android específicos que sua equipe realmente usa antes de implementar. O Passpoint, também conhecido como Hotspot 2.0, melhora significativamente a experiência no Android ao permitir a descoberta automática de rede e autenticação após a configuração inicial. A terceira armadilha é a expiração do certificado. Emita certificados de curta duração — 90 dias é um padrão razoável para dispositivos BYOD. Quando o certificado expira, o dispositivo deve passar novamente pela integração através do portal. Isso remove naturalmente dispositivos inativos da rede e força a reautenticação em relação ao status atual do provedor de identidade. Um dispositivo pertencente a um ex-funcionário cuja conta foi desativada há seis meses falhará na reintegração automaticamente. [PERGUNTAS E RESPOSTAS RÁPIDAS - aproximadamente 1 minuto] Algumas perguntas que ouvimos com frequência. "Podemos usar iPSK em vez de 802.1X completo?" Sim, para ambientes onde a implantação de certificados não é viável. O iPSK, ou Identity Pre-Shared Key, atribui uma senha de WiFi exclusiva para cada usuário ou dispositivo. É mais seguro do que uma PSK compartilhada porque cada credencial é individual e revogável. É menos seguro do que o EAP-TLS porque ainda é baseado em senha. Use-o como um degrau de transição, não como o destino final. "Precisamos de WPA3 se já estamos no WPA2-Enterprise?" Se o seu hardware for compatível, sim. O WPA3-Enterprise introduz a Autenticação Simultânea de Iguais (SAE), que elimina ataques de dicionário offline contra o handshake. O custo de migração em hardware compatível é apenas uma alteração de configuração. O ganho de segurança é substancial. "Como lidamos com prestadores de serviços que não possuem uma identidade corporativa?" Use iPSK ou uma credencial de convidado com tempo limitado emitida pelo portal. Defina uma data de expiração que coincida com a data de término do contrato. A plataforma da Purple oferece suporte nativo a credenciais de acesso com limite de tempo. [RESUMO E PRÓXIMOS PASSOS - aproximadamente 1 minuto] Deixe-me resumir tudo. Um Captive Portal de WiFi para funcionários não é um recurso de conveniência. É o ponto de aplicação para verificação de identidade, aceitação de políticas, registro de dispositivos e controle de acesso em sua rede operacional. A chave pré-compartilhada (PSK) compartilhada é um passivo de conformidade e uma vulnerabilidade de segurança. Substitua-a por um fluxo de integração com identidade verificada, segmentação de VLAN e autenticação baseada em RADIUS. Seus próximos passos imediatos: audite seu método atual de autenticação de rede de funcionários. Se você estiver executando uma PSK compartilhada, essa é sua prioridade máxima de correção. Se você estiver usando 802.1X baseado em credenciais, avalie o caminho para EAP-TLS baseado em certificado. E se você não tem o Purple Shield implantado em sua rede de funcionários, a redução de largura de banda por si só já justifica a conversa. Para orientações de implementação, modelos de arquitetura e estudos de caso das implantações da Purple em 80.000 locais ativos, visite purple.ai. Obrigado por ouvir.