Saltar para o conteúdo principal

Guest WiFi Session Timeouts: Balancing UX and Security

Este guia fornece uma estrutura prática para configurar limites de tempo de sessão (session timeouts) de guest WiFi, equilibrando uma experiência de utilizador fluida com uma segurança robusta. Abrange limites de tempo por inatividade (idle timeouts), limites de tempo absolutos (absolute timeouts), estratégias de nova autenticação e cenários de implementação específicos do setor para líderes de TI e de operações de espaços.

📖 5 min de leitura📝 1,054 palavras🔧 2 exemplos práticos3 perguntas de prática📚 8 definições principais

Ouça este guia

Ver transcrição do podcast
[Música de Introdução - Eletrónica corporativa, profissional e otimista] Anfitrião: Bem-vindo ao Purple Technical Briefing. Sou o vosso anfitrião e hoje vamos abordar um tema que se situa mesmo na interseção entre a engenharia de rede e a experiência do cliente: os Tempos de Expiração de Sessão de Guest WiFi. Se é um gestor de TI, um arquiteto de rede ou um diretor de operações de espaços, conhece bem esta luta. A equipa de marketing quer que os clientes se liguem uma vez e nunca mais vejam um ecrã de início de sessão. As equipas de segurança e infraestrutura observam o esgotamento do pool de DHCP e preocupam-se com sessões obsoletas e não autenticadas. Hoje, vamos colmatar essa lacuna. Vamos discutir como definir tempos de expiração que mantêm os utilizadores ligados sem comprometer a sua postura de segurança ou a disponibilidade de IP. [Som de transição] Anfitrião: Vamos mergulhar na mecânica técnica. Quando falamos de um "tempo de expiração de sessão", estamos na verdade a falar de dois temporizadores distintos que operam no seu controlador de rede: o Idle Timeout (Tempo de Inatividade) e o Absolute Timeout (Tempo Absoluto). Pense no Idle Timeout como o seu monitor de inatividade. Ele monitoriza a transmissão ativa de dados. Se um dispositivo cliente não enviar ou receber absolutamente nada durante um período especificado, o controlador termina a sessão. O objetivo principal aqui é a recuperação de recursos. Liberta concessões de DHCP e memória do Ponto de Acesso alocada a dispositivos que abandonaram fisicamente o seu espaço sem se desligarem formalmente. No entanto, há um senão. Os smartphones modernos são incrivelmente agressivos na suspensão de atividade para poupar bateria. Quando entram em suspensão, param de transmitir. Se definir o seu idle timeout de forma demasiado agressiva — por exemplo, cinco minutos — vai desligar dispositivos em suspensão. Quando o utilizador tirar o telemóvel do bolso para verificar um e-mail, será forçado a voltar ao Captive Portal. É uma experiência de utilizador terrível. Para ambientes típicos, um idle timeout entre 30 e 60 minutos é o ponto ideal. Agora, vejamos o Absolute Timeout. Este é o temporizador rígido. Ele dita a duração total máxima de uma sessão, independentemente de o dispositivo estar ou não a transmitir dados ativamente. Assim que este temporizador chega a zero, a sessão é terminada e o utilizador deve autenticar-se novamente. Porque precisamos disto? Impõe limites de utilização diária, garante que os utilizadores aceitam periodicamente os seus Termos e Condições e força uma revalidação de segurança. O desafio é que é disruptivo. Irá interromper sessões ativas — mesmo chamadas VoIP. Portanto, o seu absolute timeout deve alinhar-se com o tempo de permanência típico do seu espaço. [Som de transição] Anfitrião: Vamos analisar algumas recomendações de implementação no mundo real. Não existe uma solução única para todos os casos aqui. Pense numa loja de retalho com elevada rotação. Os clientes movem-se rapidamente. O seu objetivo é captar análises precisas de tráfego pedonal e, talvez, apresentar marketing direcionado, evitando ao mesmo tempo a permanência prolongada. Neste cenário, um tempo limite de inatividade (idle timeout) de 15 a 30 minutos é perfeito. Se um dispositivo estiver inativo durante meia hora, significa que saíram da loja. O seu tempo limite absoluto deve ser de cerca de 2 a 4 horas, cobrindo a viagem de compras típica mais longa. E iria querer utilizar o bypass de autenticação MAC — ou MAB — para uma reautenticação silenciosa ao longo de 7 a 14 dias para monitorizar os clientes que regressam. Agora, compare isso com um ambiente de hotelaria empresarial — um hotel. Os hóspedes esperam uma experiência semelhante à de casa. Se os forçar a iniciar sessão a cada quatro horas, a sua receção será inundada de reclamações. Aqui, o seu tempo limite de inatividade precisa de ser muito mais longo — 4 a 8 horas. Os hóspedes deixam os dispositivos nos quartos enquanto vão para a piscina; esses dispositivos não devem ser desligados. O tempo limite absoluto deve ser de 24 horas ou, idealmente, associado diretamente à data de check-out através de uma integração com o Sistema de Gestão de Propriedades (PMS). E, finalmente, considere um grande centro de transportes, como um aeroporto ou um estádio. Os tempos de permanência são altamente variáveis e a exaustão de endereços IP é um risco crítico e imediato. Tem dezenas de milhares de dispositivos transitórios. Neste ambiente, a conservação de recursos supera uma UX fluida. Precisa de um tempo limite de inatividade agressivo — 15 minutos — para recuperar IPs rapidamente. O seu tempo limite absoluto pode ser de 4 horas e, geralmente, necessita de reautenticação manual para gerir os consumidores excessivos de largura de banda. [Som de transição] Apresentador: Antes de passarmos para as Perguntas e Respostas, quero destacar alguns erros críticos a evitar. Primeiro: Alugueres DHCP desalinhados. Este é o erro de configuração número um que vemos. Não defina um tempo limite de sessão de 2 horas e um aluguer DHCP de 8 horas. Se uma sessão terminou, o IP deve estar livre. O seu tempo de aluguer DHCP deve corresponder de perto ou exceder ligeiramente o seu tempo limite de sessão absoluto. Segundo: Ignorar a Randomização MAC. O iOS e o Android utilizam agora endereços MAC privados por predefinição. Se a sua rede depende fortemente da reautenticação baseada em MAC para essa experiência de regresso fluida, precisa de educar os utilizadores. Utilize a sua splash page para os instruir a desativar a randomização MAC para o seu SSID específico se pretenderem uma ligação fluida de vários dias. Terceiro: Operar às escuras. Utilize as suas análises de WiFi. Analise a duração das suas sessões. Se 90% dos seus utilizadores saem naturalmente em 45 minutos, definir um tempo limite absoluto de 12 horas é apenas correr um risco desnecessário. Baseie os seus temporizadores em dados reais de tempo de permanência. [Som de transição] Apresentador: Vamos fazer uma sessão rápida de Perguntas e Respostas com base nas dúvidas comuns dos clientes. Pergunta 1: 'Os utilizadores queixam-se de que têm de iniciar sessão sempre que voltam do almoço. Como resolvemos isto?' Resposta: Aumente o seu tempo limite de inatividade. Se o almoço for de uma hora, um tempo limite de inatividade de 30 minutos irá desligá-los. Aumente-o para 90 minutos. Pergunta 2: 'Estamos a ficar sem endereços IP todas as tardes, mas o nosso espaço não está cheio. Porquê?' Resposta: Sessões fantasma. O seu tempo limite de inatividade (idle timeout) está desativado ou configurado para um período demasiado longo, o que significa que os dispositivos que saíram há horas ainda estão a reter concessões de IP. Reduza o seu tempo limite de inatividade para 30 minutos e encurte o tempo de concessão DHCP. Pergunta 3: 'De que forma é que a Encriptação Sem Fios Oportunista, ou OWE, afeta os tempos limite?' Resposta: A OWE fornece encriptação individualizada para redes abertas sem palavra-passe. Não altera diretamente o funcionamento dos tempos limite, mas melhora significativamente a sua postura de segurança durante a sessão, tornando os tempos limite absolutos mais longos ligeiramente menos arriscados do ponto de vista da monitorização passiva (passive sniffing). [Som de transição] Anfitrião: Em resumo: Os tempos limite de sessão são o ponto de equilíbrio entre a experiência do utilizador e a segurança da rede. Utilize o seu tempo limite de inatividade para gerir o comportamento dos dispositivos e os recursos de rede. Utilize o seu tempo limite absoluto para gerir o comportamento humano e a conformidade. Adapte estas definições ao seu setor específico — a hotelaria necessita de temporizadores longos, o retalho de temporizadores médios e os transportes de alta densidade necessitam de temporizadores agressivos. Alinhe as suas concessões DHCP, tenha em conta a aleatorização de MAC e deixe que a sua análise guie a sua configuração. Acerte nisto e reduzirá os pedidos de suporte, protegerá a sua rede e fornecerá a conectividade contínua que os seus convidados esperam. Obrigado por se juntar a este Briefing Técnico da Purple. Até à próxima, mantenha as suas redes seguras e os seus convidados ligados. [Música de Encerramento - Desvanece]

header_image.png

Resumo Executivo

Para os espaços modernos, a rede WiFi de convidados é um ponto de contacto crítico para a experiência do cliente e para a análise operacional. No entanto, definir os limites de tempo (timeouts) de sessão corretos torna-se frequentemente num braço de ferro entre as equipas de segurança de TI e os gestores de experiência do cliente. Se os limites forem demasiado curtos, os utilizadores enfrentam logins repetitivos e frustrantes no Captive Portal. Se forem demasiado longos, a rede sofre de esgotamento do pool de IPs, dados analíticos desatualizados e maiores riscos de segurança provenientes de dispositivos não autenticados.

Este guia fornece uma estrutura prática para configurar os limites de tempo de sessão de Guest WiFi . Exploramos as funções distintas dos temporizadores de inatividade, temporizadores absolutos e políticas de reautenticação, fornecendo recomendações práticas para os setores de Hospitality , Retail e ambientes do setor público. Ao alinhar as estratégias de timeout com o comportamento do utilizador e os mandatos de segurança, os arquitetos de rede podem garantir uma conectividade contínua, mantendo ao mesmo tempo uma conformidade robusta e dados precisos de WiFi Analytics .

Análise Técnica Detalhada: A Mecânica dos Limites de Tempo de Sessão

Um "timeout de sessão" não é uma configuração única, mas sim uma combinação de temporizadores distintos que operam em diferentes camadas da pilha de rede. Compreender esta mecânica é crucial para uma implementação eficaz.

1. Timeout de Inatividade (Temporizador de Inatividade)

O timeout de inatividade monitoriza a transmissão ativa de dados. Se um dispositivo cliente não enviar ou receber dados durante um período especificado, o controlador de rede termina a sessão.

  • Objetivo: Recupera endereços IP (concessões DHCP) e memória de AP alocada a dispositivos que abandonaram o espaço sem se desligarem formalmente.
  • Desafio: Os smartphones modernos entram frequentemente em modo de suspensão para poupar bateria, interrompendo a transmissão de dados. Limites de inatividade agressivos (por exemplo, 5 minutos) irão desligar os dispositivos suspensos, forçando os utilizadores a reautenticarem-se quando ativarem os seus telemóveis.
  • Recomendação: Defina limites de inatividade entre 30 e 60 minutos para ambientes típicos.

2. Timeout Absoluto (Temporizador Rígido)

O timeout absoluto dita a duração total máxima de uma sessão, independentemente da atividade. Assim que este temporizador expira, a sessão é terminada à força e o utilizador deve reautenticar-se.

  • Objetivo: Aplica limites de utilização diária, garante que os utilizadores aceitam os Termos e Condições atualizados e força uma revalidação periódica de segurança.
  • Desafio: Interrompe sessões ativas, o que pode perturbar chamadas VoIP ou downloads de grande dimensão se não for comunicado claramente.
  • Recomendação: Alinhe o timeout absoluto com o tempo de permanência típico do espaço (por exemplo, 12 horas para um hospital, 2 horas para um café).

3. Captive Portal e Reautenticação

Quando uma sessão expira, o utilizador é redirecionado para o Captive Portal. As implementações modernas utilizam frequentemente o bypass de autenticação MAC (MAB) ou o roaming contínuo para memorizar os dispositivos por um período definido (por exemplo, 30 dias). Nestas configurações, uma sessão expirada pode não exigir um início de sessão manual; o sistema reautentica silenciosamente o endereço MAC reconhecido, desde que o dispositivo não o tenha randomizado.

Para topologias de rede avançadas, a integração com ferramentas como Sensors e a garantia de uma infraestrutura de backend robusta — como a adequada RADIUS Server High Availability: Active-Active vs. Active-Passive — é essencial para lidar com picos de autenticação sem desligar utilizadores legítimos.

Guia de Implementação: Estratégias Específicas por Setor

Não existe uma configuração de timeout única para todos os casos. A estratégia deve refletir os objetivos operacionais do local e o comportamento dos visitantes.

Cenário A: A Loja de Retalho de Alta Rotatividade

No Retalho , o objetivo é captar análises precisas de tráfego pedonal e fornecer marketing direcionado, evitando ao mesmo tempo a permanência inativa.

  • Idle Timeout: 15–30 minutos. Os compradores movem-se rapidamente. Se um dispositivo estiver inativo durante 30 minutos, o utilizador provavelmente já saiu da loja.
  • Absolute Timeout: 2–4 horas. Isto cobre a viagem de compras típica mais longa.
  • Re-autenticação: Reautenticação MAC silenciosa por 7–14 dias para monitorizar os clientes que regressam sem fricção.

Cenário B: O Ambiente de Hotelaria Corporativo

Na Hotelaria , os hóspedes esperam uma experiência de WiFi "semelhante à de casa". Forçar um início de sessão a cada 4 horas é inaceitável e resultará em reclamações na receção.

  • Idle Timeout: 4–8 horas. Os hóspedes deixam os dispositivos nos quartos enquanto estão na piscina; estes dispositivos devem permanecer ligados.
  • Absolute Timeout: 24 horas ou associado à data de checkout (por exemplo, através de integração com PMS).
  • Re-autenticação: Roaming contínuo por toda a propriedade durante a estadia.

Cenário C: O Hub de Transportes Movimentado

Em hubs de Transportes como aeroportos, os tempos de permanência são altamente variáveis e a exaustão de endereços IP é um risco grave devido ao volume massivo de dispositivos transitórios.

  • Idle Timeout: 15 minutos. A recuperação agressiva é necessária para manter o pool de DHCP disponível.
  • Absolute Timeout: 4 horas (a escala típica máxima antes de um voo).
  • Re-autenticação: Reautenticação manual necessária após o absolute timeout para gerir os utilizadores que consomem muita largura de banda.

Boas Práticas para Equilibrar UX e Segurança

  1. Alinhar as Concessões DHCP com os Timeouts de Sessão: Uma configuração incorreta comum é definir um timeout de sessão de 2 horas, mas uma concessão DHCP de 8 horas. Isto esgota o pool de IPs. O tempo de concessão do seu DHCP deve corresponder de perto ou exceder ligeiramente o seu absolute timeout de sessão.
  2. Considere a Randomização de MAC: O iOS e o Android utilizam endereços MAC privados por predefinição. Se a sua rede depende fortemente de reautenticação baseada em MAC, instrua os utilizadores na splash page a desativarem a randomização de MAC para o SSID do local se pretenderem uma experiência contínua de vários dias.
  3. Aproveite a Análise de Dados: Utilize o WiFi Analytics para monitorizar a duração das sessões. Se 90% dos seus utilizadores saem naturalmente em 45 minutos, definir um timeout absoluto de 12 horas é desnecessariamente arriscado.
  4. Implemente WPA3-Open (OWE): Para uma segurança reforçada em redes de convidados abertas, implemente Opportunistic Wireless Encryption (OWE). Este fornece encriptação individualizada para cada sessão, mitigando o risco de sniffing passivo, independentemente da duração do timeout.

Resolução de Problemas e Mitigação de Riscos

  • Sintoma: Reclamações Constantes de Reautenticação.
    • Causa: O timeout de inatividade é demasiado curto, desligando smartphones em modo de suspensão.
    • Solução: Aumente o timeout de inatividade para pelo menos 30 minutos.
  • Sintoma: Esgotamento do Pool de IPs (Os utilizadores não conseguem ligar-se).
    • Causa: Sessões fantasma estão a reter IPs porque o timeout de inatividade está desativado ou é demasiado longo.
    • Solução: Implemente um timeout de inatividade rigoroso de 15 a 30 minutos e reduza os tempos de concessão (lease) de DHCP.
  • Sintoma: Dados de Análise Desatualizados.
    • Causa: Os dispositivos permanecem "ligados" muito tempo após o utilizador ter saído do local devido a temporizadores de inatividade longos.
    • Solução: Ajuste o temporizador de inatividade para corresponder ao tempo real de saída física do local.

ROI e Impacto no Negócio

A otimização dos timeouts de sessão tem um impacto direto nos resultados financeiros. Uma configuração bem ajustada reduz os pedidos de suporte relacionados com problemas de conectividade em até 40%. Além disso, dados de sessão precisos alimentam diretamente as plataformas de Wayfinding e de marketing. Se os timeouts forem configurados corretamente, as equipas de marketing recebem métricas precisas de tempo de permanência, permitindo campanhas com maior taxa de conversão.

À medida que as empresas modernizam a sua infraestrutura — talvez percebendo The Core SD WAN Benefits for Modern Businesses — a padronização destas políticas de timeout em todas as filiais torna-se um motor essencial para a eficiência operacional e para uma experiência de convidado consistente.

architecture_overview.png

stadium_network_ops.png

Definições Principais

Tempo Limite de Inatividade (Idle Timeout)

A duração durante a qual uma ligação de rede é mantida enquanto não estão a ser transmitidos dados pelo dispositivo cliente.

Crucial para recuperar recursos de rede de dispositivos que abandonaram fisicamente o local sem se desligarem.

Tempo Limite Absoluto (Absolute Timeout)

O limite estrito de quanto tempo uma sessão pode durar a partir do momento da autenticação, independentemente da atividade.

Utilizado para impor limites de utilização diária e exigir a aceitação periódica dos Termos e Condições.

Captive Portal

Uma página web que um utilizador de uma rede de acesso público é obrigado a visualizar e com a qual deve interagir antes de lhe ser concedido acesso.

A interface principal para autenticação de WiFi de convidados, branding e recolha de dados.

Ignorar Autenticação MAC (MAB)

Um processo em que a rede autentica um dispositivo utilizando o seu endereço MAC contra uma base de dados, evitando a necessidade de um início de sessão manual no Captive Portal.

Essencial para criar experiências fluidas de "regresso de visitantes" no retalho e hotelaria.

Tempo de Concessão DHCP (DHCP Lease Time)

O período de tempo que um dispositivo de rede retém um endereço IP atribuído antes de ter de solicitar uma renovação.

Deve ser cuidadosamente alinhado com os tempos limite de sessão para evitar a exaustão do pool de IPs em locais de alta densidade.

Aleatorização de MAC

Uma funcionalidade de privacidade nos sistemas operativos móveis modernos que gera um endereço MAC falso para cada rede WiFi à qual o dispositivo se liga.

Complica o MAB e a análise de dados, exigindo que os locais ajustem as suas estratégias de monitorização e de nova autenticação.

Encriptação Sem Fios Oportunista (OWE)

Um padrão da WiFi Alliance que fornece encriptação individualizada para dispositivos em redes abertas e sem palavra-passe.

Melhora a postura de segurança do WiFi de convidados sem exigir que os utilizadores introduzam uma chave pré-partilhada.

Tempo de Permanência (Dwell Time)

A quantidade média de tempo que um convidado ou cliente passa fisicamente presente dentro do local.

A métrica fundamental utilizada para determinar as configurações adequadas de tempo limite absoluto e de inatividade.

Exemplos Práticos

Um hotel de 200 quartos está a registar um elevado volume de chamadas para o suporte técnico porque os hóspedes têm de iniciar sessão novamente no WiFi sempre que regressam da piscina. A configuração atual tem um idle timeout de 30 minutos e um absolute timeout de 8 horas.

  1. Aumentar o idle timeout para 8 horas. Os dispositivos deixados nos quartos ou em suspensão nas malas junto à piscina não serão desligados prematuramente.
  2. Alterar o absolute timeout para 24 horas ou, idealmente, integrar o controlador WiFi com o Property Management System (PMS) para definir o absolute timeout para a hora exata do checkout do hóspede.
  3. Ativar a nova autenticação fluida baseada em MAC por 7 dias para que os hóspedes que regressam ignorem completamente o Captive Portal.
Comentário do Examinador: Esta abordagem prioriza a experiência de utilizador "semelhante à de casa" esperada na hotelaria. Ao integrar com o PMS, a rede lida automaticamente com o requisito de segurança de revogar o acesso quando o hóspede já não está autorizado, eliminando a necessidade de temporizadores rígidos arbitrários.

Um grande estádio desportivo (capacidade para 50.000 pessoas) está a ficar sem endereços IP durante o primeiro quarto dos jogos. Os utilizadores reportam sinal de WiFi no máximo, mas não conseguem ligar-se à internet. Definições atuais: Idle timeout de 4 horas, Absolute timeout de 12 horas.

  1. Reduzir drasticamente o idle timeout para 15 minutos. Isto recupera imediatamente IPs de adeptos que saíram do alcance ou desligaram o WiFi.
  2. Reduzir o tempo de concessão (lease time) de DHCP para 20 minutos para alinhar com o novo idle timeout.
  3. Reduzir o absolute timeout para 5 horas (a duração máxima de um jogo mais o tempo de saída).
Comentário do Examinador: Em ambientes de alta densidade, como estádios, a conservação de recursos (endereços IP, memória de AP) sobrepõe-se a uma experiência de utilizador fluida. Os idle timeouts agressivos são obrigatórios para garantir que os novos visitantes se consigam ligar.

Perguntas de Prática

Q1. O diretor de TI de um hospital quer garantir que os visitantes na sala de espera não tenham de iniciar sessão várias vezes, mas também precisa de garantir que os dispositivos de doentes que receberam alta sejam removidos da rede rapidamente para libertar IPs. O tempo médio de espera é de 3 horas e o internamento médio dos doentes é de 2 dias.

Dica: Diferencie os utilizadores transitórios da sala de espera dos doentes internados a longo prazo. Consegue aplicar uma única política a ambos?

Ver resposta modelo

O hospital deve implementar dois SSIDs de Visitantes separados ou utilizar o controlo de acesso baseado em funções através do Captive Portal. Para o nível "Visitante", defina um limite de tempo absoluto de 4 horas e um limite de inatividade de 30 minutos. Para o nível "Doente" (talvez autenticado através de um código de admissão), defina um limite de tempo absoluto de 48 horas e um limite de inatividade de 8 horas. Isto equilibra a elevada rotatividade da sala de espera com as necessidades de UX dos doentes internados.

Q2. O seu cliente de retalho queixa-se de que as suas análises de clientes recorrentes estão a diminuir significativamente, embora a afluência de público se mantenha estável. Atualmente, têm uma política de autenticação MAB de 30 dias.

Dica: Pense nas alterações recentes nas funcionalidades de privacidade dos sistemas operativos móveis.

Ver resposta modelo

A quebra nas análises deve-se provavelmente à aleatorização de MAC (Endereços Wi-Fi Privados) no iOS e Android. Como os dispositivos rodam os seus endereços MAC, a política MAB de 30 dias não consegue reconhecer os dispositivos que regressam, tratando-os como novos visitantes. A solução é atualizar a splash page do Captive Portal para instruir os utilizadores a desativarem os Endereços Privados para a rede da loja para receberem benefícios de fidelização, ou desviar a dependência das análises para a monitorização ao nível da aplicação em vez de dados puramente MAC de Camada 2.

Q3. Um centro de conferências acolhe eventos que variam de seminários de 1 dia a convenções de 5 dias. A equipa de rede utiliza atualmente um limite de tempo absoluto estático de 24 horas para todos os eventos, o que gera reclamações durante convenções de vários dias.

Dica: Como pode a política de limite de tempo tornar-se dinâmica em vez de estática?

Ver resposta modelo

A equipa de rede deve integrar o backend de autenticação WiFi (RADIUS) com o sistema de gestão de eventos do espaço, ou utilizar vouchers dinâmicos. Em vez de um limite de tempo estático de 24 horas, o Captive Portal deve emitir durações de sessão com base no código de evento específico introduzido pelo participante. Um código de seminário de 1 dia concede um limite de tempo absoluto de 12 horas, enquanto um código de convenção de 5 dias concede um limite de tempo absoluto de 120 horas, eliminando as desconexões a meio do evento.

Continue a ler esta série

How to Configure SCEP for Automated Enterprise WiFi Certificate Enrollment

Este guia explica como configurar o SCEP (Simple Certificate Enrollment Protocol) para a atribuição automatizada de certificados WiFi empresariais, cobrindo toda a arquitetura desde PKI e NDES até à implementação de perfis MDM e validação RADIUS. Destina-se a gestores de TI, arquitetos de rede e CTOs em hotéis, cadeias de retalho, estádios, centros de conferências e organizações do setor público que necessitam de ir além das chaves pré-partilhadas e implementar uma autenticação 802.1X EAP-TLS escalável e baseada em identidade. A plataforma de sobreposição na nuvem da Purple, independente de hardware, integra-se diretamente com esta arquitetura, fornecendo a camada de WiFi para convidados e BYOD que coexiste com a sua rede de colaboradores autenticada por certificado.

Ler o guia →

O Guia Empresarial do SCEP: Implementar o Simple Certificate Enrollment Protocol para Segurança Automatizada de WiFi em Campus

Este guia de referência técnica fornece um modelo arquitetónico definitivo e uma estratégia de implementação passo a passo para a implementação de certificados de WiFi empresariais utilizando SCEP. Abrange as diferenças críticas entre SCEP e PKCS, a sequência exata de implementação necessária para o sucesso e estratégias reais de mitigação de riscos para líderes de TI.

Ler o guia →

Como Implementar SCEP para a Inscrição Automatizada de Certificados WiFi

Este guia explica como implementar o SCEP (Simple Certificate Enrollment Protocol) para a inscrição automatizada de certificados WiFi em espaços empresariais. Abrange todo o plano de arquitetura - desde o design de PKI e integração de MDM até à sequência de implementação obrigatória de três passos - e mostra aos gestores de TI e arquitetos de rede como eliminar credenciais partilhadas, automatizar a gestão do ciclo de vida dos certificados e cumprir os requisitos de PCI DSS e GDPR à escala.

Ler o guia →