O que é uma Splash Page de WiFi?

O que é uma Splash Page de WiFi? — Uma Sessão de Informação da Purple [INTRO — aproximadamente 1 minuto] Bem-vindo à Sessão de Informação da Purple. Sou o vosso anfitrião e hoje vamos abordar algo que se situa mesmo na interseção da infraestrutura de rede com a experiência do cliente: a splash page de WiFi. Se é um gestor de TI, um arquiteto de rede ou um diretor de operações de espaços públicos, quase de certeza que já implementou uma destas — ou está prestes a fazê-lo. Mas existe uma quantidade surpreendente de confusão no mercado sobre o que é realmente uma splash page, como difere de um captive portal e, crucialmente, o que separa uma página bem desenhada de uma que destrói silenciosamente a experiência dos seus convidados e deixa riscos de conformidade por resolver. Por isso, vamos a isso. Nos próximos dez minutos, vou guiar-vos pela arquitetura técnica, pelas principais decisões de design, por cenários de implementação reais na hotelaria e no retalho, e pelas armadilhas específicas que apanham desprevenidas até as equipas mais experientes. No final, terá uma estrutura clara para avaliar ou redesenhar a sua própria implementação. [TECHNICAL DEEP-DIVE — aproximadamente 5 minutos] Vamos começar pelos fundamentos. Uma splash page de WiFi — por vezes chamada de página de destino de WiFi para convidados ou página de login de WiFi — é a interface baseada na web que um utilizador vê quando se liga pela primeira vez a uma rede sem fios de convidados e abre um navegador. É a porta de entrada para a sua experiência de WiFi para convidados. Mas é aqui que a terminologia se confunde. Uma splash page não é o mesmo que um captive portal, embora os dois termos sejam usados indistintamente em conversas informais. Deixem-me ser preciso sobre isto, porque é importante em termos de arquitetura. Um captive portal é o mecanismo ao nível da camada de rede — o componente de infraestrutura que intercepta o tráfego HTTP não autenticado, realiza um redirecionamento de DNS e mantém o dispositivo num estado de rede restrito até que a autenticação seja concluída. Opera na camada dois e na camada três do modelo OSI. Envolve o seu controlador de acesso, o seu servidor RADIUS se estiver a executar 802.1X, a sua configuração de VLAN e o seu resolvedor de DNS. O captive portal é o guardião. A splash page, por contraste, é a camada de apresentação — a página web que o captive portal apresenta ao utilizador. É o HTML, CSS e JavaScript com que o convidado realmente interage e vê. Contém a sua marca, as suas opções de autenticação, o seu formulário de captura de dados, o seu mecanismo de consentimento do GDPR e os seus termos de serviço. Para simplificar: o captive portal é a fechadura; a splash page é a porta. Precisa de ambos, mas servem funções fundamentalmente diferentes e são geridos por equipas diferentes — os engenheiros de rede são proprietários da infraestrutura do portal, enquanto o marketing e as TI partilham a propriedade da experiência da splash page. Como é que isto funciona tecnicamente? Quando um dispositivo se liga ao seu SSID de convidados, é colocado numa VLAN restrita — chamemos-lhe VLAN de pré-autenticação. As consultas de DNS são interceptadas e resolvidas para o endereço IP do seu controlador de captive portal. Qualquer pedido HTTP — e note-se que é por isso que a navegação exclusiva em HTTPS criou alguns desafios interessantes para a deteção de captive portals — é redirecionado através de uma resposta 302 para o URL da splash page. O sistema operativo do dispositivo, seja iOS, Android ou Windows, tem um mecanismo de deteção de captive portal integrado. Os dispositivos Apple fazem ping a captivenetwork.apple.com; os dispositivos Android acedem a connectivitycheck.gstatic.com. Quando esses pedidos devolvem uma resposta inesperada, o SO sabe que está atrás de um captive portal e apresenta o aviso de login automaticamente. Assim que o utilizador conclui o fluxo da splash page — seja introduzindo um endereço de email, autenticando-se através de login social, aceitando os termos ou introduzindo um código de voucher — o controlador do captive portal atualiza o endereço MAC ou o endereço IP do dispositivo na sua tabela de autenticação, move-o para la VLAN pós-autenticação e concede acesso total à internet. A sessão é monitorizada, normalmente com um tempo limite configurável e uma política de largura de banda aplicada. Agora vamos falar sobre os métodos de autenticação, porque é aqui que o valor comercial realmente se começa a diferenciar. Tem várias opções. A mais simples é o clique de aceitação — o utilizador apenas aceita os termos e obtém acesso. Sem captura de dados, fricção mínima, mas também valor mínimo para o negócio. Um passo acima é o registo por email, onde captura um endereço de email verificado. Depois, há o login social — Facebook, Google, Apple ID — que lhe dá um perfil mais rico e uma identidade verificada, embora dependa de fluxos OAuth de terceiros e das políticas de partilha de dados dessas plataformas. E no extremo mais sofisticado, tem o registo baseado em formulários com campos personalizados, integração com programas de fidelização e sincronização com o CRM. A escolha do método de autenticação tem um impacto direto na qualidade dos seus dados, na sua taxa de conversão e na sua postura de conformidade. Um clique de aceitação garante-lhe taxas de ligação próximas dos 100%, mas zero dados primários (first-party data). Um formulário de registo detalhado pode reduzir a sua taxa de ligação para 60 ou 70 por cento, mas fornece-lhe dados de marketing acionáveis. O ponto ideal para a maioria das implementações empresariais é o login social ou o registo por email com uma única caixa de seleção para aceitação de marketing — fricção suficientemente baixa para manter uma conversão elevada, qualidade de dados suficientemente alta para ser comercialmente útil. Do lado da conformidade, isto é não-negociável. Se opera no Reino Unido ou na UE, o GDPR aplica-se. A sua splash page deve apresentar um mecanismo de consentimento claro e afirmativo para quaisquer comunicações de marketing. As caixas pré-selecionadas não são um consentimento válido ao abrigo do Artigo 7.º do GDPR. O seu aviso de privacidade deve estar acessível — não escondido num PDF de 40 páginas — e deve ser capaz de demonstrar que o consentimento foi dado de forma livre, específica, informada e inequívoca. Se estiver num ambiente de saúde, também precisará de considerar se quaisquer dados capturados podem constituir dados de categoria especial ao abrigo do Artigo 9.º. E se a sua rede WiFi de convidados transportar quaisquer dados de cartões de pagamento — mesmo que indiretamente —, a expansão do âmbito do PCI DSS é um risco real que precisa de ser abordado através de uma segmentação de rede adequada. [IMPLEMENTATION RECOMMENDATIONS AND PITFALLS — aproximadamente 2 minutos] Muito bem, vamos falar sobre a implementação. Quer esteja a fazer o lançamento num hotel de 200 quartos, numa cadeia de retalho com 50 filiais ou num estádio com capacidade para 40.000 pessoas, as decisões arquitetónicas que tomar no início determinarão o nível de dificuldade que irá registar à escala. Primeiro: gerido na nuvem versus local (on-premise). Para implementações multi-site, as soluções de captive portal geridas na nuvem são quase sempre a resposta certa. Proporcionam-lhe uma gestão centralizada da splash page, branding consistente em todos os locais, análises em tempo real e a capacidade de lançar atualizações sem tocar nos controladores de acesso individuais. As soluções locais têm o seu lugar — ambientes de alta segurança, locais com fraca conectividade WAN ou organizações com requisitos estritos de residência de dados —, mas os custos operacionais são significativamente mais elevados. A plataforma da Purple, por exemplo, funciona como uma solução gerida na nuvem que se integra com a sua infraestrutura de pontos de acesso existente, independentemente do fabricante, o que constitui uma vantagem significativa em ambientes multi-fornecedor. Segundo: não subestime o problema da latência de redirecionamento. Uma das queixas mais comuns sobre os captive portals é que a splash page demora demasiado tempo a aparecer. Isto é normalmente causado por uma de três coisas: tempos de resposta lentos no redirecionamento de DNS, a própria splash page estar alojada num servidor com poucos recursos ou — e isto é cada vez mais comum — a navegação exclusiva em HTTPS impedir o disparo do redirecionamento HTTP inicial. Os sistemas operativos modernos lidam razoavelmente bem com a deteção de captive portals, mas deve testar a sua implementação em iOS, Android, Windows e macOS antes do lançamento, porque o comportamento varia. Terceiro: gestão de sessões. Decida antecipadamente quanto tempo dura uma sessão, o que acontece quando expira e se os utilizadores recorrentes precisam de se voltar a autenticar. Para a hotelaria, faz sentido uma sessão de 24 horas associada a uma reserva de quarto. Para um ambiente de retalho, pode preferir uma sessão mais curta com um aviso de reautenticação que apresente uma nova mensagem promocional. Para um estádio ou recinto de eventos, uma sessão de um único dia é normalmente o adequado. Estas não são apenas decisões de UX — afetam a carga do seu servidor RADIUS e a qualidade dos seus dados analíticos. Agora, as armadilhas. A maior que vejo em implementações empresariais é tratar a splash page como um ativo estático. A sua splash page é um canal de marketing ativo. Deve ser atualizada sazonalmente, testada quanto à taxa de conversão e revista para alterações de conformidade — particularmente à medida que as diretrizes do GDPR evoluem. A segunda armadilha é a fraca otimização para dispositivos móveis. Mais de 80 por cento das ligações de WiFi de convidados são feitas a partir de smartphones. Se a sua splash page não for totalmente responsiva e não carregar em menos de três segundos numa ligação 4G, está a perder ligações. A terceira armadilha é negligenciar a experiência pós-autenticação. O que acontece depois de o utilizador se ligar? Aterra numa página de boas-vindas personalizada com uma oferta promocional? Ou é simplesmente direcionado para o site que estava a tentar aceder? Esse momento pós-ligação é um ponto de contacto de elevada atenção que a maioria dos operadores desperdiça por completo. [RAPID-FIRE Q&A — aproximadamente 1 minute] Deixem-me passar por algumas perguntas que oiço regularmente das equipas de TI e de operações. "Podemos utilizar os nossos pontos de acesso existentes?" — Na maioria dos casos, sim. As plataformas de captive portal geridas na nuvem, como a Purple, integram-se com Cisco Meraki, Aruba, Ruckus, Ubiquiti e a maioria dos outros fornecedores de AP empresariais através de integração padrão RADIUS ou API. "Como lidamos com dispositivos que não suportam a deteção de captive portal?" — Configura um walled garden: uma lista branca de endereços IP e domínios que estão acessíveis antes da autenticação. Isto garante que a sua própria splash page está sempre acessível. "Precisamos de um SSID separado para convidados?" — Sim, sempre. O tráfego de convidados deve ser isolado da sua rede corporativa. O requisito mínimo é a segmentação por VLAN; a melhor prática é uma rede física ou lógica completamente separada com a sua própria saída para a internet. "E quanto ao WPA3?" — O WPA3 é o padrão atual para segurança sem fios e deve ser a sua predefinição para qualquer nova implementação. Note que o WPA3 utiliza Simultaneous Authentication of Equals, o que altera o comportamento do handshake — certifique-se de que o seu controlador de captive portal o suporta. [SUMMARY AND NEXT STEPS — aproximadamente 1 minute] Para resumir. Uma splash page de WiFi é a interface web interativa e personalizada que se situa à frente da sua rede de WiFi para convidados. É o componente voltado para o utilizador de um sistema de captive portal e é, simultaneamente, um mecanismo de controlo de acesso à rede, uma ferramenta de captura de dados, um ponto de verificação de conformidade e um canal de marketing. As decisões fundamentais são: método de autenticação, campos de dados, mecanismo de consentimento, duração da sessão e experiência pós-ligação. Acerte nestes pontos e o seu WiFi de convidados torna-se um ativo de dados primários que gera um ROI de marketing mensurável. Erre e terá uma responsabilidade de conformidade e uma experiência de convidado frustrante. Se está a avaliar ou a redesenhar a sua implementação, recomendo começar com a plataforma de WiFi para convidados da Purple — esta gere a infraestrutura de captive portal, o construtor de splash pages, as análises e as integrações de CRM numa única solução gerida na nuvem. Há um link nas notas do programa para a página do produto de WiFi para convidados da Purple e para o seu guia sobre implementações de captive portal na nuvem versus locais. Obrigado por ouvirem. Até à próxima.