Captive Portal vs Splash Page

CAPTIVE PORTAL VS SPLASH PAGE - UM BRIEFING TÉCNICO DA PURPLE Guião de Podcast - Aproximadamente 10 Minutos Voz em Inglês do Reino Unido --- SEGMENTO 1: INTRODUÇÃO E ENQUADRAMENTO (aproximadamente 1 minuto) Bem-vindo à série de Briefings Técnicos da Purple. Sou o vosso anfitrião e hoje vamos esclarecer uma das fontes mais persistentes de confusão na aquisição e implementação de WiFi para convidados: a diferença entre um captive portal e uma splash page. Se já esteve numa reunião com fornecedores e ouviu estes dois termos serem usados de forma intercambiável, não está sozinho. Acontece constantemente - em documentos de RFP, em apresentações de estratégia de TI, até mesmo em conversas entre engenheiros de rede que deviam saber perfeitamente a diferença. E esta confusão é importante porque, quando confundimos os dois, acabamos por especificar demasiado o componente errado, investir a menos no correto ou, pior ainda, implementar uma solução de WiFi para convidados que tem excelente aspeto mas que não possui um controlo de rede adequado por baixo, ou uma que é tecnicamente sólida mas afasta os convidados com um ecrã de login feio e sem marca. Por isso, vamos resolver isso hoje. No final deste briefing, terá um modelo mental claro do que cada componente faz, como interagem e o que deve procurar ao avaliar soluções para o seu espaço - quer seja um hotel, uma rede de retalho, um estádio ou um edifício do setor público. --- SEGMENTO 2: ANÁLISE TÉCNICA DETALHADA (aproximadamente 5 minutos) Vamos começar com o captive portal, porque é a base sobre a qual tudo o resto assenta. Um captive portal é um mecanismo da camada de rede. A sua função é intercetar todo o tráfego de saída de um dispositivo recém-conectado e mantê-lo numa espécie de sala de espera digital até que esse dispositivo tenha sido autenticado. Quando um convidado se liga ao seu SSID de WiFi, o seu dispositivo obtém um endereço IP via DHCP - essa parte funciona normalmente. Mas antes que qualquer tráfego de internet real seja permitido, o captive portal intercepa-o. Aqui está a sequência técnica. O dispositivo do convidado envia um pedido HTTP ou HTTPS - pode estar a tentar carregar um website ou pode ser a própria verificação de conectividade do sistema operativo, que os dispositivos modernos como iPhones e telefones Android executam automaticamente. O controlador do captive portal - que reside no seu controlador sem fios, no seu router ou numa plataforma baseada na nuvem - intercepa essa consulta DNS ou pedido HTTP e redireciona-o. Em vez de aceder à internet, o dispositivo recebe uma resposta de redirecionamento que aponta para um URL específico. Esse URL é onde reside a splash page. Agora, o próprio mecanismo de redirecionamento utiliza uma de duas técnicas principais. A primeira é o desvio de DNS - o captive portal intercepta as consultas DNS e devolve o endereço IP do servidor do portal em vez do destino real. A segunda é o redirecionamento HTTP - o portal intercepta o pedido HTTP no gateway e emite uma resposta de redirecionamento 302. Para o tráfego HTTPS, isto é mais complexo, porque não se pode interceptar uma sessão encriptada sem acionar um aviso de certificado. É por isso que a maioria das implementações de captive portal dependem do Captive Network Assistant integrado no sistema operativo - o pop-up que aparece no seu telemóvel quando se liga a uma nova rede - que utiliza um endpoint HTTP conhecido para detetar captive portals antes de tentar ligações HTTPS. Na camada de rede, o captive portal impõe o controlo de acesso utilizando regras de firewall. Os dispositivos não autenticados são colocados numa VLAN ou sub-rede restrita, onde todo o tráfego é bloqueado, exceto o DNS e o HTTP para o servidor do portal. Assim que a autenticação é confirmada - seja através de um simples clique, um início de sessão social, a recolha de um e-mail ou uma troca completa de credenciais 802.1X - o controlador do portal atualiza as regras de firewall para o endereço MAC desse dispositivo, movendo-o da zona restrita para a zona autorizada com acesso total à internet. Isto é importante: o captive portal é invisível para o convidado. Eles nunca o veem diretamente. O que veem é a splash page. A splash page é a camada de aplicação - é o HTML, CSS e JavaScript que é renderizado no navegador do convidado ou no pop-up do Captive Network Assistant. É a interface visual: a sua marca, o seu logótipo, a sua mensagem de boas-vindas, os seus termos e condições, os seus botões de início de sessão social, as suas caixas de seleção de marketing. É o que transforma um evento frio de autenticação de rede numa experiência de convidado de marca. Pense nisto desta forma. O captive portal é o segurança à porta - decide quem entra e impõe as regras. A splash page é a receção - é o rosto do seu espaço, recolhe informações e faz com que o convidado se sinta bem-vindo. Precisa de ambos, e eles precisam de funcionar em conjunto de forma perfeita. Agora, por que razão esta distinção importa comercialmente? Porque quando está a avaliar uma solução de guest WiFi, precisa de fazer perguntas diferentes sobre cada componente. Para o captive portal, a pergunta é: Que métodos de autenticação suporta? Consegue gerir 802.1X para dispositivos corporativos a par do início de sessão social para convidados? Suporta o bypass de endereço MAC para dispositivos que não conseguem apresentar um navegador? Como gere os tempos de expiração da sessão e a nova autenticação? Está em conformidade com as suas obrigações de proteção de dados ao abrigo do GDPR? Integra-se com a sua infraestrutura RADIUS? Consegue segmentar o tráfego por tipo de utilizador - separando o tráfego de convidados do tráfego de funcionários na camada de rede? Para a página de splash, deve perguntar-se: Quão personalizável é? A sua equipa de marketing pode editá-la sem interferir na configuração da rede? Suporta testes A/B? Consegue apresentar conteúdos diferentes a diferentes segmentos de utilizadores - membros do programa de fidelidade versus visitantes estreantes, por exemplo? Suporta fundos de vídeo, banners promocionais ou páginas de redirecionamento pós-ligação? Como é o seu desempenho em dispositivos móveis? É acessível? Estes são critérios de aquisição fundamentalmente diferentes, e misturar os dois leva a más decisões. Temos visto organizações a investir fortemente no design de uma página de splash fantástica para depois descobrirem que o Captive Portal subjacente não suporta os métodos de autenticação exigidos pela sua política de segurança de TI. Também já vimos o inverso - implementações de Captive Portal tecnicamente robustas com páginas de splash tão mal desenhadas que as taxas de adesão dos convidados rondam os trinta por cento. Falemos sobre as normas que fundamentam tudo isto. O mecanismo do Captive Portal não tem uma norma de governação única, mas opera no âmbito de várias normas importantes. O IEEE 802.1X é a norma de controlo de acesso à rede baseada em portas que rege a forma como os dispositivos se autenticam numa rede utilizando credenciais, certificados ou tokens. É a base da segurança WiFi empresarial e é cada vez mais relevante, mesmo em contextos de WiFi para convidados, onde deseja oferecer um acesso contínuo e baseado em credenciais a visitantes frequentes. O WPA3, o mais recente protocolo de segurança WiFi, introduz a Opportunistic Wireless Encryption, que encripta o tráfego mesmo em redes abertas - o que é relevante para implementações de Captive Portal porque altera a forma como o handshake inicial da ligação funciona. Do ponto de vista da conformidade, o GDPR tem implicações significativas no design da página de splash. Se a sua página de splash recolhe dados pessoais - um endereço de email, um nome, um login social - precisa de um consentimento explícito e informado, de um aviso de privacidade claro e de uma base legal para o processamento. A página de splash é onde esse consentimento é captado, mas o Captive Portal é o que impõe a ligação entre o consentimento e o acesso. Se um convidado recusar a opção de marketing, o Captive Portal ainda precisa de lhe conceder acesso à internet - o consentimento para marketing não pode ser uma condição para aceder à rede sob o GDPR. O PCI-DSS é relevante se a sua rede WiFi para convidados estiver no âmbito de ambientes de dados de cartões - tipicamente no retalho ou na hotelaria. A segmentação de rede imposta pelo Captive Portal é um controlo essencial neste aspeto, garantindo que o tráfego de convidados é isolado dos sistemas de pagamento. - SEGMENTO 3: RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ERROS COMUNS (aproximadamente 2 minutos) Deixe-me apresentar dois cenários do mundo real que ilustram como isto se processa na prática. Primeiro, um grupo hoteleiro de 200 quartos. Implementaram uma solução de WiFi para convidados onde a splash page tinha um design de marca magnífico - o seu logótipo, uma mensagem de boas-vindas, uma oferta promocional para o spa. Mas o Captive Portal subjacente era uma implementação básica em código aberto que utilizava hijacking de DNS sem qualquer gestão de sessão. O resultado: os hóspedes que regressavam ao hotel eram solicitados a iniciar sessão novamente a cada visita, mesmo durante a mesma estadia. A splash page parecia excelente, mas o Captive Portal não tinha persistência de endereço MAC, nem configuração de tempo limite de sessão, nem integração com o sistema de gestão de propriedade. A correção exigiu a substituição total do controlador do Captive Portal - a splash page estava ótima. Segundo, uma cadeia de retalho nacional. Implementaram um Captive Portal de nível empresarial com suporte completo para 802.1X, integração RADIUS e segmentação de tráfego sofisticada. Mas a sua splash page era um modelo predefinido - totalmente em branco, sem marca, com uma mensagem genérica de "Ligue-se ao WiFi". A adesão dos convidados era de 34%. Após investirem numa splash page devidamente desenhada e personalizada com a marca, com uma opção de início de sessão social num único clique, a adesão subiu para 71% em três meses. O Captive Portal não tinha mudado de todo. A lição de ambos os cenários: estes componentes distintos exigem investimento separado e competências separadas. Não deixe que a sua equipa de rede controle o design da splash page e não permita que a sua equipa de marketing tome decisões sobre a arquitetura do Captive Portal. Erros comuns a evitar: primeiro, assumir que uma splash page é um Captive Portal. Não é. Uma splash page sem um Captive Portal é apenas uma página web que ninguém é forçado a visitar. Segundo, implementar um Captive Portal sem suporte HTTPS para a splash page. Quaisquer dados recolhidos numa splash page não encriptada - endereços de e-mail, credenciais de início de sessão - são transmitidos em texto simples. Isso é um risco de segurança e de incumprimento do GDPR. Terceiro, ignorar a experiência móvel. Mais de 80% das ligações de WiFi de convidados são feitas a partir de dispositivos móveis. Se a sua splash page não estiver otimizada para telemóvel, estará a criar fricção exatamente no momento em que deveria estar a criar uma impressão de marca positiva. - SEGMENTO 4: PERGUNTAS E RESPOSTAS RÁPIDAS (aproximadamente 1 minuto) Vou responder rapidamente a algumas perguntas que ouvimos regularmente. Posso ter uma splash page sem um Captive Portal? Tecnicamente sim - pode alojar uma página web e direcionar as pessoas para lá - mas sem o Captive Portal a forçar o redirecionamento, os convidados não têm motivos para a visitar. Não teria recolha de dados, nem gestão de consentimento, nem controlo de acesso à rede. Posso ter um Captive Portal sem uma splash page? Sim, e isto é comum em ambientes empresariais onde o 802.1X trata da autenticação de forma silenciosa. Mas para implementações destinadas a convidados, quase sempre vai querer uma splash page para gerir a experiência do utilizador e a recolha de dados. O WPA3 corrompe os portais cativos? Não se for implementado corretamente. O WPA3 com Opportunistic Wireless Encryption é compatível com implementações de Captive Portal, mas requer que o portal utilize HTTPS e que a rede anuncie o URL do portal corretamente. Alguns dispositivos cliente mais antigos apresentam problemas de compatibilidade, razão pela qual muitos locais utilizam configurações de SSID duplo. O início de sessão social através da splash page é seguro? Depende da implementação. O início de sessão social baseado em OAuth 2.0 - através da Google, Facebook ou Apple - é seguro quando implementado corretamente. A splash page gere o fluxo de OAuth e o Captive Portal recebe um token que confirma a autenticação. O principal risco reside na forma como esse token é validado e como a sessão é gerida. - SEGMENTO 5: RESUMO E PRÓXIMOS PASSOS (aproximadamente 1 minuto) Vamos concluir com as principais conclusões. Um: um Captive Portal e uma splash page não são a mesma coisa. O Captive Portal é o mecanismo de controlo de rede - intercetando o tráfego e aplicando as regras de acesso. A splash page é a interface visual - é o que o convidado vê e com o qual interage. Dois: eles trabalham em conjunto. O Captive Portal redireciona o convidado para a splash page. A splash page recolhe a autenticação ou o consentimento. O Captive Portal concede então o acesso com base nesse resultado. Três: avalie-os separadamente. Faça perguntas diferentes, aplique competências diferentes e orçamente ambos de forma independente. Quatro: a conformidade reside na interseção. O consentimento do GDPR é recolhido na splash page, mas aplicado pelo Captive Portal. Garanta a conformidade em ambos. Cinco: a Purple fornece ambos. Se procura uma plataforma que faça a gestão do controlo do Captive Portal de nível empresarial, juntamente com um design de splash page rico e personalizável - com análise completa, ferramentas de conformidade com o GDPR e integrações com a sua infraestrutura existente - é exatamente para isso que a Purple foi concebida. Para os seus próximos passos, recomendo a leitura dos guias de implementação da Purple sobre autenticação 802.1X e análise de WiFi de convidados. Os links estão nas notas do programa. E se estiver a meio de um processo de aquisição, entre em contacto com a equipa da Purple para uma avaliação técnica - vale a pena definir a arquitetura correta antes de avançar para uma implementação. Obrigado por nos ouvir. Até à próxima. - FIM DO ROTEIRO