Captive Portal para WiFi de Funcionários: Integração e Autenticação de Colaboradores

Staff WiFi Captive Portal: Onboarding and Authenticating Employees Uma Sessão de Informação sobre Inteligência de WiFi de Grande Empresa Purple [INTRODUÇÃO - aproximadamente 1 minuto] Bem-vindo à série de Inteligência de WiFi de Grande Empresa Purple. Hoje estamos a abordar um tema que se situa na interseção entre segurança, operações de recursos humanos e arquitetura de rede: o Captive Portal de WiFi para colaboradores. Ora, eu sei o que alguns de vocês podem estar a pensar. Um Captive Portal para colaboradores? Isso não é o que se usa para convidados? E é exatamente esse equívoco que precisamos de esclarecer desde o início. Um Captive Portal de WiFi para colaboradores não é uma página de entrada de convidados com um logótipo diferente. É um portal estruturado de integração que autentica colaboradores individuais, impõe a aceitação de políticas e regista dispositivos antes de conceder acesso à sua rede operacional. Se fizer isto bem, elimina a maior vulnerabilidade na maioria das implementações de WiFi empresariais: a chave pré-partilhada. Se fizer mal, terá ex-colaboradores, subcontratados e dispositivos pessoais na sua rede interna indefinidamente. Vamos analisar a arquitetura. [ANÁLISE TÉCNICA DETALHADA - aproximadamente 5 minutos] O problema fundamental com a maioria das implementações de WiFi para colaboradores é a palavra-passe partilhada. Uma única chave pré-partilhada WPA2, escrita num post-it no escritório, partilhada num grupo de WhatsApp e que nunca é alterada quando alguém se demite. Num hotel de 200 quartos com 80 colaboradores, essa palavra-passe já foi partilhada com cerca de 80 pessoas, com os respetivos parceiros que pediram o telemóvel emprestado e com pelo menos três ex-colaboradores. Isso não é uma rede. É uma porta aberta. O Captive Portal de WiFi para colaboradores resolve isto ao substituir a credencial partilhada por um fluxo de integração com identidade verificada. Eis como funciona na prática. Quando um novo colaborador liga o seu dispositivo à rede interna pela primeira vez, acede a um SSID de aprovisionamento. Esta é uma rede aberta, mas é um jardim vedado - apenas encaminha para o portal de integração e para o seu fornecedor de identidade. Mais nada. O colaborador é redirecionado para o Captive Portal, onde se autentica utilizando a sua identidade corporativa. Na maioria dos ambientes empresariais atuais, isso significa Single Sign-On via Microsoft Entra ID, Okta ou Google Workspace. Assim que o fornecedor de identidade confirma que o colaborador está ativo e no grupo correto, o portal faz uma de duas coisas, dependendo da sua arquitetura de autenticação. Numa implementação baseada em credenciais que utilize PEAP e MSCHAPv2, o portal valida as credenciais e emite um token de acesso à rede. Numa implementação baseada em certificados que utilize EAP-TLS, o portal inicia a geração de certificados. É emitido um certificado X.509 específico para o dispositivo pela sua Autoridade de Certificação, empacotado num perfil de configuração - um ficheiro dot-mobileconfig em iOS, ou um perfil Passpoint em Android - e enviado para o dispositivo. O dispositivo instala o perfil, desliga-se do SSID de aprovisionamento e liga-se automaticamente ao SSID seguro para colaboradores utilizando o certificado para autenticação EAP-TLS. A partir desse momento, sempre que o dispositivo se liga à rede de funcionários, o servidor RADIUS valida o certificado. Sem pedidos de palavra-passe. Sem início de sessão manual. O dispositivo simplesmente liga-se, de forma silenciosa e segura. Falemos agora sobre a razão pela qual o EAP-TLS é o estado ideal para a maioria das implementações empresariais. A norma IEEE 802.1X define a estrutura, mas o EAP-TLS é o método que elimina totalmente o roubo de credenciais do processo de autenticação. Não há palavra-passe para pescar (phishing). Não há hash para forçar por força bruta. O certificado está associado ao dispositivo. Se o dispositivo for perdido ou roubado, revoga-se o certificado na Autoridade de Certificação e o servidor RADIUS recusa o acesso na tentativa de ligação seguinte. Se o funcionário sair da empresa, desativa-se a sua conta no fornecedor de identidade e, como o certificado foi emitido associado a essa identidade, a integração SCIM propaga a desativação automaticamente. O acesso termina quando a pessoa sai. Esta é a arquitetura de que organizações como a Premier Inn e a Whitbread necessitam ao gerir centenas de propriedades com milhares de dispositivos de funcionários em toda uma infraestrutura distribuída. Não é possível gerir isto à escala com palavras-passe partilhadas e revogação manual. Abordemos também a dimensão BYOD, porque é aqui que o captive portal se torna particularmente valioso. Na maioria dos ambientes de hotelaria, retalho e eventos, uma proporção significativa do pessoal utiliza dispositivos pessoais para tarefas operacionais. O pessoal de limpeza verifica a atribuição de quartos nos seus próprios smartphones. Os assistentes de retalho utilizam tablets pessoais para consultas de inventário. As equipas de operações dos estádios utilizam telemóveis pessoais para comunicações. Estes são dispositivos não geridos. Não controla a versão do seu OS, o estado do antivírus ou que outras aplicações estão instaladas. Devem ser tratados, na melhor das hipóteses, como semi-confiáveis. O captive portal de WiFi para funcionários gere o BYOD colocando estes dispositivos numa VLAN dedicada após a autenticação. A VLAN dá-lhes acesso às aplicações internas específicas de que necessitam - o sistema de gestão de propriedade, a interface do ponto de venda, a aplicação de agendamento - e a nada mais. Não conseguem aceder aos seus servidores corporativos, aos seus sistemas financeiros ou à sua rede de dispositivos geridos. Esta é uma segmentação de VLAN aplicada ao 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 de arquitetura que vale a pena cobrir: a Política de Utilização Aceitável, ou AUP. O Captive Portal é o ponto de aplicação natural para a aceitação da AUP. Antes de um colaborador obter acesso à rede de pessoal, o portal apresenta a política - cobrindo a utilização aceitável, monitorização, tratamento de dados e consequências do uso indevido - e exige um consentimento explícito. Isto cria um registo auditável e com carimbo data/hora da aceitação da política. Sob o GDPR, isto é importante. Sob o PCI-DSS, para qualquer rede que toque em dados de titulares de cartões, isto é importante. E no caso de uma investigação disciplinar que envolva o uso indevido da rede, isto é consideravelmente importante. Agora, a largura de banda. É aqui que o Purple Shield se torna diretamente relevante. Em ambientes de pessoal de alta densidade - um hotel durante um fim de semana de casa cheia, um espaço de retalho na Black Friday, um estádio em dia de jogo - a disputa de largura de banda na rede de pessoal é um problema operacional real. O Purple Shield opera ao nível do DNS, bloqueando payloads de anúncios, scripts de rastreamento e domínios de malware antes que estes cheguem ao dispositivo. O efeito prático é uma redução de até 40% no total de dados descarregados em toda a rede, de acordo com os próprios dados da Purple. Para os dispositivos da equipa, 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 carregada de anúncios são eliminadas antes de chegarem à rede. 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 ERROS A EVITAR - aproximadamente 2 minutos] Permita-me apresentar-lhe a sequência de implementação e os modos de falha que deve monitorizar. Comece com a sua arquitetura VLAN antes de configurar um único ponto de acesso. Defina no mínimo três VLANs: pessoal, convidados e IoT. Mapeie as suas políticas de firewall. Obtenha a aprovação da sua equipa de segurança. Os erros mais dispendiosos em implementações de WiFi acontecem quando a rede é construída primeiro e a arquitetura de segurança é adicionada depois. Segundo, implemente a sua infraestrutura RADIUS com redundância. Uma única falha no servidor RADIUS bloqueia todos os membros do pessoal fora da rede em simultâneo. Num hotel, isso significa que a receção não pode processar check-ins. Numa loja de retalho, significa que os sistemas de ponto de venda não conseguem autenticar. Implemente pelo menos dois servidores RADIUS numa configuração ativo-passivo e teste a capacidade de failover antes de entrar em produção. Terceiro, integre o seu servidor RADIUS com o seu fornecedor de identidade através de LDAP ou SAML. É isto que permite o desaprovisionamento automático. Quando um colaborador é desativado no Microsoft Entra ID ou Okta, o servidor RADIUS deixa de aceitar as suas credenciais ou o seu certificado na tentativa de ligação seguinte. Sem passos manuais, sem filas de pedidos de suporte, sem lacunas entre a saída e a remoção do acesso. Quarto, desenhe o fluxo de integração do seu captive portal para o utilizador menos técnico da sua equipa. Não o gestor de TI. O operador de armazém sazonal que nunca instalou um perfil de configuração. Instruções claras, interface de marca e um número de contacto do suporte visível em todos os ecrãs. Agora as armadilhas. O modo de falha mais comum é o walled garden ser demasiado permissivo. Se o seu SSID de aprovisionamento permitir o acesso geral à internet, a equipa simplesmente continuará nele em vez de concluir o fluxo de integração. Bloqueie-o para o portal, para os endpoints do fornecedor de identidade e para 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 do OS lidam com a instalação de certificados de forma diferente. Teste o seu fluxo de integração nos dispositivos Android específicos que a sua equipa realmente utiliza 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 a autenticação após a configuração inicial. A terceira armadilha é a expiração de certificados. Emita certificados de curta duração - 90 dias é um padrão razoável para dispositivos BYOD. Quando o certificado expirar, o dispositivo deve voltar a integrar-se através do portal. Isto remove naturalmente os dispositivos inativos da rede e força a reautenticação em relação ao estado atual do fornecedor de identidade. Um dispositivo pertencente a um ex-funcionário cuja conta foi desativada há seis meses falhará a 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 implementação de certificados não é viável. O iPSK, ou Identity Pre-Shared Key, atribui uma palavra-passe de WiFi única a cada utilizador ou dispositivo. É mais seguro do que uma PSK partilhada porque cada credencial é individual e revogável. É menos seguro do que o EAP-TLS porque continua a ser baseado em palavra-passe. Use-o como um trampolim, não como um destino final. "Precisamos de WPA3 se já estamos no WPA2-Enterprise?" Se o seu hardware o suportar, sim. O WPA3-Enterprise introduz Simultaneous Authentication of Equals, o que elimina ataques de dicionário offline contra o handshake. O custo de migração em hardware suportado é uma alteração de configuração. A melhoria de segurança é relevante. "Como lidamos com prestadores de serviços que não têm uma identidade corporativa?" Utilize iPSK ou uma credencial de convidado com tempo limitado emitida através do portal. Defina uma data de expiração correspondente à data de fim do contrato. A plataforma da Purple suporta nativamente credenciais de acesso limitadas no tempo. [RESUMO E PRÓXIMOS PASSOS - aproximadamente 1 minuto] Deixe-me resumir. Um captive portal de WiFi para funcionários não é uma funcionalidade de conveniência. É o ponto de aplicação para verificação de identidade, aceitação de políticas, registo de dispositivos e controlo de acesso na sua rede operacional. A chave pré-partilhada partilhada é uma responsabilidade 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. Os seus próximos passos imediatos: audite o seu método atual de autenticação de rede de funcionários. Se estiver a utilizar uma PSK partilhada, essa é a sua correção de maior prioridade. Se estiver a utilizar 802.1X baseado em credenciais, avalie o caminho para EAP-TLS baseado em certificados. E se não tem o Purple Shield implementado na sua rede de funcionários, a redução de largura de banda por si só justifica a conversa. Para orientações de implementação, modelos de arquitetura e estudos de caso das implementações da Purple em 80.000 locais ativos, visite purple.ai. Obrigado por ouvir.