Captive Portal vs Splash Page

CAPTIVE PORTAL VS SPLASH PAGE - UMA SESSÃO TÉCNICA 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 Sessões Técnicas da Purple. Eu sou o seu 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, saiba que não está sozinho. Acontece constantemente - em documentos de RFP, em apresentações de estratégia de TI, até em conversas entre engenheiros de rede que deviam saber melhor. E esta confusão é importante, porque ao misturar os dois conceitos, acaba por especificar em excesso o componente errado, investir de menos no componente correto, ou pior - implementar uma solução de WiFi para convidados que tem um aspeto fantástico mas não tem qualquer controlo de rede adequado por trás, ou uma que é tecnicamente sólida mas afasta os convidados com um ecrã de início de sessão pesado e sem marca. Por isso, vamos resolver isto hoje. No final desta sessão, terá um modelo mental claro do que cada componente faz, de como interagem e do que deve procurar ao avaliar soluções para o seu espaço - 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) Comecemos pelo captive portal, porque é a base sobre a qual tudo o resto assenta. Um captive portal é um mecanismo ao nível 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 de qualquer tráfego de internet real ser permitido, o captive portal interceta-o. Eis 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 telemóveis Android executam automaticamente. O controlador do captive portal - que reside no seu controlador sem fios, no seu router ou numa plataforma baseada na nuvem - interceta essa consulta DNS ou pedido HTTP e redireciona-o. Em vez de aceder à internet, o dispositivo recebe uma resposta de redirecionamento que o 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 de 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 assistente de rede cativa incorporado no sistema operativo - o pop-up que aparece no 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 acessos através de 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 clique simples, início de sessão social, captura de 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 assistente de rede cativa. É 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 com a identidade da marca. Pense nisto da seguinte 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, porque é que 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 são suportados? Consegue lidar com 802.1X para dispositivos corporativos a par de início de sessão social para convidados? Suporta desvio de endereço MAC para dispositivos que não conseguem apresentar um navegador? Como lida com a expiração de sessões e 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 do pessoal na camada de rede?Para a página de login, a pergunta a fazer é: quão personalizável é? A sua equipa de marketing pode editá-la sem tocar na configuração da rede? Suporta testes A/B? Pode disponibilizar conteúdos diferentes para diferentes segmentos de utilizadores - membros de programas de fidelização versus visitantes pela primeira vez, por exemplo? Suporta fundos de vídeo, banners promocionais ou páginas de redirecionamento pós-ligação? Como se comporta 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 investirem fortemente num design bonito de página de login 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 vimos o inverso - implementações de Captive Portal tecnicamente robustas com páginas de login tão mal concebidas que as taxas de adesão dos convidados rondam os trinta por cento. Vamos falar sobre as normas que sustentam tudo isto. O mecanismo do Captive Portal não tem uma norma reguladora única, mas opera dentro do quadro 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 de WiFi empresarial e é cada vez mais relevante mesmo em contextos de WiFi para convidados, onde se pretende oferecer um acesso contínuo e baseado em credenciais a visitantes que regressam. O WPA3, o mais recente protocolo de segurança WiFi, introduz a Encriptação Sem Fios Oportunista, que encripta o tráfego mesmo em redes abertas - 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 login. Se a sua página de login recolher dados pessoais - um endereço de email, um nome, um login social - precisa de consentimento explícito e informado, de um aviso de privacidade claro e de uma base legal para o tratamento de dados. A página de login é onde esse consentimento é capturado, 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 assim tem de lhe conceder acesso à internet - o consentimento para marketing não pode ser uma condição para aceder à rede ao abrigo do GDPR. O PCI-DSS é relevante se a sua rede WiFi para convidados estiver no âmbito de ambientes de dados de cartões - normalmente no retalho ou na hotelaria. A segmentação de rede imposta pelo Captive Portal é um controlo fundamental 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) Permita-me apresentar dois cenários do mundo real que ilustram como isto se desenrola na prática. Primeiro, um grupo hoteleiro de 200 quartos. Implementaram uma solução de guest WiFi onde a página de splash tinha uma marca excelente - 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 de código aberto que utilizava desvio 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 em cada visita, mesmo durante a mesma estadia. A página de splash parecia ótima, 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 página de splash estava bem. Segundo, uma cadeia de retalho nacional. Implementaram um captive portal de nível empresarial com suporte total a 802.1X, integração RADIUS e segmentação sofisticada de tráfego. Mas a página de splash era um modelo padrão - fundo branco, sem imagem de marca, com uma mensagem genérica de "Ligue-se ao WiFi". A taxa de adoção dos convidados foi de 34%. Após investirem numa página de splash devidamente concebida, com a sua marca e uma opção de início de sessão social com um único clique, a adoção aumentou para 71% em três meses. O captive portal não tinha sofrido qualquer alteração. A lição de ambos os cenários: estes componentes distintos exigem investimento e conhecimentos especializados separados. Não permita que a sua equipa de rede assuma a conceção da página de splash e não deixe que a sua equipa de marketing tome decisões sobre a arquitetura do captive portal. Erros comuns a evitar: primeiro, assumir que uma página de splash é um captive portal. Não é. Uma página de splash 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 página de splash. Quaisquer dados recolhidos numa página de splash não encriptada - endereços de e-mail, credenciais de início de sessão - são transmitidos em texto limpo. Trata-se de um risco de segurança e de incumprimento do GDPR. Terceiro, ignorar a experiência móvel. Mais de 80% das ligações guest WiFi provêm de dispositivos móveis. Se a sua página de splash não estiver otimizada para dispositivos móveis, está 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) Deixe-me passar por algumas perguntas que ouvimos regularmente. Posso ter uma página de splash sem um captive portal? Tecnicamente sim - pode alojar uma página Web e direcionar as pessoas para ela - mas sem o captive portal a impor o redirecionamento, os convidados não têm qualquer motivo para a visitar. Não teria captura de dados, nem gestão de consentimento, nem controlo de acesso à rede. Posso ter um captive portal sem uma página de splash? Sim, e isto é comum em ambientes empresariais onde o 802.1X lida com a autenticação de forma silenciosa. Mas para implementações viradas para clientes e convidados, quase sempre vai querer uma página de splash para gerir a experiência do utilizador e a captura 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 exige 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 login social através da splash page é seguro? Depende da implementação. O login 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. Primeiro: um Captive Portal e uma splash page não são a mesma coisa. O Captive Portal é o mecanismo de controlo de rede - interseta o tráfego e aplica as regras de acesso. A splash page é a interface visual - é o que o convidado vê e com o qual interage. Segundo: 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. Terceiro: avalie-os separadamente. Faça perguntas diferentes, aplique competências diferentes e orçamente ambos de forma independente. Quarto: a conformidade reside na interseção. O consentimento do GDPR é recolhido na splash page, mas aplicado pelo Captive Portal. Garanta a conformidade em ambos. Quinto: a Purple disponibiliza ambos. Se procura uma plataforma que faça a gestão do controlo de um Captive Portal de nível empresarial em conjunto com um design de splash page rico e personalizável - com análises completas, ferramentas de conformidade com o GDPR e integrações com a sua infraestrutura existente - é exatamente para isso que a Purple foi criada. Como próximos passos, recomendo a revisão dos guias de implementação da Purple sobre autenticação 802.1X e análises de guest WiFi. Os links estão nas notas do programa. E se estiver a meio de um processo de aquisição, contacte a equipa da Purple para uma avaliação técnica - vale a pena definir a arquitetura correta antes de se comprometer com uma implementação. Obrigado por nos ouvir. Até à próxima. --- FIM DO SCRIPT