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

Staff WiFi Captive Portal: Onboarding and Authenticating Employees Uma apresentação do Purple Enterprise WiFi Intelligence [INTRODUÇÃO - aproximadamente 1 minuto] Boas-vindas à série Purple Enterprise WiFi Intelligence. Hoje vamos abordar um tema que está na interseção da segurança, das operações de RH e da 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 se usa para visitantes? E esse é exatamente o equívoco que precisamos tratar logo de início. Um staff WiFi captive portal não é uma splash page de visitantes com um logotipo diferente. Ele é um portal de integração estruturado que autentica funcionários individualmente, impõe a aceitação de termos de uso e registra dispositivos antes de conceder acesso à sua rede operacional. Se você fizer isso da forma correta, eliminará a maior vulnerabilidade na maioria das implantações de WiFi corporativas: a chave pré-compartilhada compartilhada. Se fizer errado, terá ex-funcionários, prestadores de serviço e dispositivos pessoais conectados à sua rede interna por tempo indeterminado. Vamos entrar na arquitetura. [APROFUNDAMENTO TÉCNICO - 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, compartilhada em um grupo de WhatsApp e que nunca é alterada quando alguém sai da empresa. Em um hotel de 200 quartos com 80 funcionários, essa senha já foi compartilhada com cerca de 80 pessoas, seus parceiros que pegaram o celular 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 corporativa pela primeira vez, ele acessa um SSID de provisionamento. Esta é uma rede aberta, mas é uma rede restrita - 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 empresariais atuais, isso significa Single Sign-On via Microsoft Entra ID, Okta ou Google Workspace. Assim 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 do SSID de provisionamento e conecta-se automaticamente ao SSID corporativo seguro 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 de destino 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 fazer phishing. Não há hash para forçar por força bruta. O certificado está vinculado ao dispositivo. Se o dispositivo for perdido ou roubado, você revoga o certificado em sua Autoridade de Certificação e o servidor RADIUS nega o acesso na próxima tentativa de conexão. Se o funcionário sair da empresa, você desativa a conta dele no provedor de identidade e, como o certificado foi emitido para essa identidade, a integração SCIM propaga a descontinuação automaticamente. O acesso termina quando o vínculo da pessoa termina. Essa é 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 BYOD, porque é aqui que o Captive Portal se torna particularmente valioso. Na maioria dos ambientes de hospitalidade, varejo e eventos, uma proporção significativa de funcionários usa dispositivos pessoais para tarefas operacionais. A equipe de limpeza verifica as atribuições de quartos em seus próprios smartphones. Os associados do varejo usam tablets pessoais para consultas de inventário. As equipes de operações do estádio usam telefones pessoais para comunicações. Esses são dispositivos não gerenciados. Você não controla a versão do OS, o status do antivírus ou quais outros aplicativos estão instalados. Eles devem ser tratados como semitrusted, na melhor das hipóteses. O Captive Portal de WiFi para funcionários lida com 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 propriedade, 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. Esta é uma segmentação de VLAN aplicada no nível RADIUS e é a implementação prática do princípio de confiança zero: 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 de aceitação da política com carimbo de data/hora e auditável. 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 funcionários de alta densidade - um hotel durante um fim de semana lotado, um comércio varejista 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 do 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 dados da própria Purple. Para dispositivos de funcionários, 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 de 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 a serem observados. Comece com sua arquitetura de VLAN antes de configurar um único ponto de acesso. Defina três VLANs no mínimo: funcionários, convidados e IoT. Mapeie suas políticas de firewall. Obtenha a aprovação de 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 funcionários da rede simultaneamente. Em um hotel, isso significa que a recepção não pode processar check-ins. Em uma loja de varejo, isso significa que os sistemas de ponto de venda não podem autenticar. Implante pelo menos dois servidores RADIUS em uma configuração ativa-passiva 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 lacunas entre a saída e a remoção do acesso. Quarto, 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 personalizada com a marca e um número de contato da central de suporte visível em cada tela. Agora os problemas comuns. A falha mais comum é o walled garden ser muito permissivo. Se o seu SSID de provisionamento permitir acesso geral à internet, a equipe simplesmente continuará nele em vez de concluir o fluxo de integração. Bloqueie o acesso apenas ao portal, aos endpoints do provedor de identidade e ao servidor de download de certificados. Nada mais. O segundo obstáculo é a fragmentação do Android. O iOS gerencia perfis dot-mobileconfig de forma consistente. O Android não. Diferentes fabricantes e versões de sistema operacional gerenciam a instalação de certificados de maneira diferente. Teste seu fluxo de integração nos dispositivos Android específicos que sua equipe realmente usa antes de fazer a implantação. O Passpoint, também conhecido como Hotspot 2.0, melhora significativamente a experiência no Android ao permitir a descoberta e autenticação automáticas de rede após a configuração inicial. O terceiro obstáculo é a expiração do certificado. Emita certificados de curta duração - 90 dias é um padrão razoável para dispositivos BYOD. Quando o certificado expirar, o dispositivo deverá passar pela integração novamente através do portal. Isso remove naturalmente dispositivos inativos da rede e força a autenticação novamente em relação ao estado atual do provedor de identidade. Um dispositivo pertencente a um ex-funcionário cuja conta foi desativada há seis meses falhará na nova integração de forma automática. [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 um PSK compartilhado porque cada credencial é individual e revogável. É menos seguro do que o EAP-TLS porque ainda é baseado em senha. Use-o como um degrau intermediário, 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, o 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. A melhoria de segurança é significativa. "Como lidamos com prestadores de serviço que não possuem uma identidade corporativa?" Use iPSK ou uma credencial de convidado com tempo limitado emitida através do portal. Defina uma data de expiração correspondente à data de término do contrato. A plataforma da Purple oferece suporte nativo a credenciais de acesso por tempo limitado. [RESUMO E PRÓXIMOS PASSOS - aproximadamente 1 minuto] Permita-me resumir tudo isso. 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 compartilhada é um risco de conformidade e uma vulnerabilidade de segurança. Substitua-a por um fluxo de integração com verificação de identidade, 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 utilizando uma PSK compartilhada, essa deve ser sua prioridade máxima de correção. Se você estiver utilizando o 802.1X baseado em credenciais, avalie o caminho para o EAP-TLS baseado em certificados. E se você não possui 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 mais de 80.000 locais ativos, visite purple.ai. Obrigado por nos ouvir.