Requisitos de RFP para WiFi para visitantes: o que especificar em termos de integração, segurança e analítica

Um RFP de WiFi para visitantes deve definir requisitos mensuráveis em cinco áreas. Integração: portal cativo, recolha de consentimento e acessibilidade WCAG 2.2. Segurança: IEEE 802.1X, RADIUS, Passpoint e WPA3. Hardware: suporte específico para Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist e Ubiquiti UniFi. Conformidade: GDPR, PCI DSS v4.0 e DNS de proteção. Análise de dados: dados próprios exportáveis. Avalie os concorrentes com base em evidências.

O que é que um RFP de WiFi para visitantes precisa realmente de especificar?

Um RFP de WiFi para visitantes transforma um resumo genérico, como "WiFi gratuito para visitantes", em requisitos que um concorrente pode cumprir ou não. Define a forma como as pessoas se ligam, como o tráfego é protegido e em que hardware a plataforma deve ser executada. Também estabelece como os dados pessoais são tratados e que relatórios irá receber.

Os RFP fracos tendem a falhar da mesma forma. Listam funcionalidades em vez de normas, pelo que todos os concorrentes respondem "sim" e as respostas parecem idênticas. A solução consiste em associar uma norma específica, as evidências esperadas e um teste piloto a cada linha.

Para um património com vários locais, o RFP também define o seu modelo operacional para a duração do contrato. Um portal cativo é a página web que um dispositivo vê antes de obter acesso à Internet. Pode executar um único portal cativo e um único registo de consentimento em todos os locais. A alternativa é uma configuração diferente para cada fornecedor de hardware. Desmantelar um património fragmentado mais tarde custa muito mais do que especificar um único agora.

Este guia fornece a redação dos requisitos, uma matriz de pontuação e testes piloto. Utilize-o como um modelo de RFP de WiFi para visitantes que pode adaptar para Hotéis, Comércio, Saúde, Comboios, estádios e espaços do setor público.

Do que precisa antes de escrever o RFP de WiFi para visitantes?

Reúna cinco elementos antes do primeiro rascunho. Cada um deles evita uma fonte comum de pedidos de alteração após a adjudicação.

• Um inventário de hardware por local. Registe o fornecedor do ponto de acesso (AP), modelo, plataforma de gestão e firmware em cada local. Note se cada local utiliza um painel na nuvem ou um controlador no local (on-premises). O nosso guia What is a WLC (Wireless LAN Controller) and Do You Still Need One? explica a diferença.
• Uma lista de locais por tipo. Agrupe os locais por setor e dimensão, pois o átrio de um estádio e a receção de um hotel precisam de integrações diferentes. Identifique o público que cada local serve: convidados, clientes, passageiros, adeptos, doentes ou visitantes.
• Um mapa de dados. Decida quem atua como responsável pelo tratamento de dados, que sistemas irão receber dados de WiFi e durante quanto tempo os irá guardar. O seu encarregado da proteção de dados deve aprovar este documento antes do lançamento do RFP.
• Os seus limites de pagamento. Liste todos os sites que aceitam pagamentos por cartão. Anote se os dispositivos de pagamento partilham switches ou circuitos com o tráfego de visitantes. Isto define o seu âmbito de aplicação da PCI DSS.
• Métricas de sucesso. Acorde os números que irá reportar, tais como inícios de sessão, taxa de adesão (opt-in), visitantes recorrentes e pedidos de suporte. Os concorrentes podem assim demonstrar como os seus relatórios geram cada um desses dados.

Envolva as equipas de TI, segurança, proteção de dados, marketing e operações do local desde o início. O WiFi para visitantes toca em todas estas cinco equipas. Um requisito escrito por uma equipa despropositadamente bloqueia muitas vezes outra.

Como escrever os requisitos de uma RFP para WiFi para visitantes, secção a secção?

Escreva cada requisito com "deve" ou "deveria", seguindo a convenção da RFC 2119. Um "deve" representa um critério eliminatório de aprovação ou reprovação. Um "deveria" é pontuado. Peça aos concorrentes para responderem a cada linha com evidências: um documento, um certificado, um site de referência ou uma demonstração ao vivo.

Requisitos de integração e portal cativo

A integração é o momento em que os visitantes avaliam a sua rede e onde os seus registos de consentimento são criados. Esta lista de verificação de RFP para portal cativo cobre os pontos essenciais.

• Métodos de início de sessão. A plataforma deve suportar e-mail, início de sessão por redes sociais, SMS e códigos de acesso, configuráveis por local.
• Adesões (opt-ins) por escolha consciente. O consentimento de marketing deve ser uma opção separada e desmarcada, nunca agregada à aceitação dos termos. O Artigo 7.º do GDPR exige que o consentimento seja demonstrável e tão fácil de retirar quanto de dar.
• Acessibilidade. O portal cativo deve cumprir a norma WCAG 2.2 nível AA.
• Deteção fiável do portal. A plataforma deveria suportar a API de Portal Cativo (RFC 8908) e a opção de portal cativo DHCP (RFC 8910). Ambas ajudam os dispositivos modernos a encontrar a página de início de sessão sem loops de redirecionamento.
• Reconhecimento de visitantes recorrentes. O iOS 14 e o Android 10 em diante utilizam endereços MAC aleatórios por predefinição. Pergunte aos concorrentes como reconhecem um visitante recorrente sem depender do endereço de hardware do dispositivo.
• Controlo centralizado. A sede deve gerir a imagem de marca, os termos e o texto de consentimento de forma centralizada, com sobreposições locais para cada local.

O Purple WiFi para visitantes integra adesões por escolha consciente no portal cativo e gere-o centralmente em todo o património de edifícios.

Requisitos de autenticação, RADIUS e Passpoint

O protocolo RADIUS é utilizado por um AP para perguntar a um servidor central se deve admitir um dispositivo. Está definido na RFC 2865. A contabilização RADIUS, definida na RFC 2866, regista o início, o fim e a utilização de dados da sessão. Para uma organização com múltiplos locais, especifique o seguinte.

• RADIUS na nuvem com redundância. A autenticação deve continuar a funcionar se um centro de dados falhar. Solicite a arquitetura e os dados medidos de disponibilidade dos últimos 12 meses.
• Transporte RADIUS encriptado. Onde o RADIUS cruza a internet pública, exija RadSec (RADIUS sobre TLS, RFC 6614) ou um túnel encriptado.
• Autorização dinâmica. A plataforma deveria enviar mensagens CoA (RFC 5176) para terminar ou alterar uma sessão sem forçar uma nova ligação.
• Segmentação. O tráfego de convidados deve estar na sua própria VLAN, um segmento de rede lógico isolado dos sistemas de colaboradores e de pagamentos. O isolamento de clientes deve impedir que os dispositivos dos convidados acedam entre si.
• Encriptação em redes abertas. Exija a WPA3, incluindo a Enhanced Open (Opportunistic Wireless Encryption, RFC 8110). Esta encripta cada ligação sem uma palavra-passe partilhada.
• Chaves individuais quando necessário. A iPSK (identity pre-shared key) atribui a cada pessoa ou dispositivo a sua própria palavra-passe de WiFi numa rede partilhada. É adequada para convidados de longa permanência, expositores e equipas de eventos. O Purple disponibiliza isto através do SecurePass.

O Passpoint, também chamado Hotspot 2.0, baseia-se no IEEE 802.11u. Permite que um dispositivo encontre e se junte a uma rede automaticamente, sem portal cativo. A autenticação corre sobre o IEEE 802.1X, o padrão para controlo de acessos à rede baseado em portas, para que as credenciais se mantenham encriptadas. O OpenRoaming, gerido pela Wireless Broadband Alliance, é uma federação construída com base no Passpoint. Permite que as pessoas se liguem a redes participantes com uma identidade que já possuem.

Especifique o Passpoint e o OpenRoaming como requisitos recomendados na primeira fase, com um plano de ação orçamentado. O Purple suporta o OpenRoaming, para que os convidados recorrentes se possam ligar automaticamente nos seus locais.

Se a RFP também cobrir o WiFi para colaboradores, exija a integração com o Microsoft Entra ID, o Okta e o Google Workspace. Isso mantém as entradas, saídas e alterações de funções de colaboradores alinhadas com o acesso à rede, sem alterações manuais de palavras-passe.

Compatibilidade com APs independente do hardware

"Compatível com o hardware empresarial líder" não pode ser pontuado. Nomeie todas as plataformas que executa ou possa adotar durante o contrato. Em seguida, exija as mesmas cinco funcionalidades em cada uma delas.

1. Suporte para portal cativo externo.
2. Autenticação e contabilização RADIUS.
3. Walled garden: a lista de permissões pré-login de domínios de que o portal e o login social necessitam.
4. Suporte para CoA, ou uma alternativa documentada para terminar sessões.
5. Um guia de integração publicado e, pelo menos, uma referência ativa nessa plataforma.

Fornecedor	Plataforma de gestão a nomear na RFP	Evidência mínima a solicitar
Cisco Meraki	Painel do Meraki	Guia de integração, referência ativa, piloto no seu firmware
HPE Aruba	HPE Aruba Networking Central ou Mobility Controller	Guia de integração, referência ativa, piloto no seu firmware
Ruckus	RUCKUS SmartZone ou RUCKUS One	Guia de integração, referência ativa, piloto no seu firmware
Juniper Mist	Nuvem da Juniper Mist	Guia de integração, referência ativa, piloto no seu firmware
Ubiquiti UniFi	Aplicação de rede UniFi	Guia de integração, referência ativa, piloto no seu firmware
Cambium	cnMaestro	Guia de integração, referência ativa, piloto no seu firmware
Extreme	ExtremeCloud IQ	Guia de integração, referência ativa, piloto no seu firmware
Fortinet	Controlador sem fios integrado FortiGate	Guia de integração, referência ativa, piloto no seu firmware

Peça a cada concorrente para indicar os intervalos de firmware suportados e, em seguida, teste com os seus próprios. O Purple é agnóstico relativamente ao hardware e funciona como uma sobreposição na nuvem em todas as oito plataformas. Não há necessidade de substituição integral. Por que razão a sua próxima atualização do WiFi não precisa de novo hardware aborda o caso comercial. Para instalações Ruckus, consulte Ruckus SmartZone e RUCKUS One WiFi para visitantes vs. plataformas externas de portal cativo.

Cláusulas do GDPR a exigir

O WiFi para visitantes recolhe dados pessoais em grande escala, pelo que o contrato deve conter estas cláusulas.

• Um acordo de tratamento de dados que cumpre o Artigo 28.º do GDPR, abrangendo a finalidade, a segurança, os subencarregados do tratamento e a eliminação.
• Registos de consentimento que mostrem o carimbo de data/hora, a versão do texto e o canal para cada adesão, exportáveis a pedido.
• Retenção configurável com eliminação automática, em conformidade com o princípio da limitação da conservação constante do Artigo 5.º, n.º 1, alínea e).
• Ferramentas do titular dos dados para localizar, exportar e apagar os dados de uma pessoa. Deve responder aos pedidos no prazo de um mês, nos termos do Artigo 12.º, n.º 3.
• Notificação de violação por parte do subcontratante sem demora injustificada, conforme exige o Artigo 33.º, n.º 2. Dispõe de 72 horas para notificar a autoridade de controlo nos termos do Artigo 33.º, n.º 1.
• Transferências internacionais. O concorrente deve declarar onde os dados são mantidos e o mecanismo de transferência para qualquer tratamento fora do Reino Unido ou do EEE.
• Provas de segurança para o Artigo 32.º, idealmente certificação ISO 27001.

O Purple é certificado pela ISO 27001 e está em conformidade com o GDPR, a CCPA e a Cyber Essentials.

Cláusulas PCI DSS a exigir

O WiFi para visitantes nunca deve estar localizado dentro do seu ambiente de dados de titulares de cartões (CDE). O CDE abrange os sistemas que armazenam, processam ou transmitem dados de cartões. O PCI DSS v4.0 permite reduzir o âmbito através da segmentação, mas é necessário provar que esta funciona.

• O concorrente deve confirmar por escrito que o tráfego de visitantes nunca atravessa o CDE e documentar o projeto.
• O projeto deve suportar o seu teste de intrusão de segmentação, exigido pelo menos a cada 12 meses nos termos do requisito 11.4.5.
• Nenhum dado de cartão pode ser introduzido no portal cativo. Qualquer acesso pago deve utilizar um prestador de serviços de pagamento em conformidade com o PCI DSS, acompanhado do respetivo Atestado de Conformidade.
• Os seus testes trimestrais para pontos de acesso sem fios não autorizados nos termos do requisito 11.2.1 continuam a abranger as áreas de visitantes.

Cláusulas de DNS de proteção a exigir

O DNS de proteção impede que os dispositivos resolvam domínios conhecidos por alojar malware, phishing ou servidores de comando e controlo. O National Cyber Security Centre (NCSC) do Reino Unido fornece um serviço de DNS de proteção a organismos do setor público. Especifique o seguinte.

• Fontes de ameaças. O concorrente deve indicar as suas fontes de informação sobre ameaças e a frequência com que são atualizadas.
• Filtragem por categorias por local, por exemplo, bloqueando conteúdo para adultos em bibliotecas e áreas familiares.
• Uma página de bloqueio personalizada que informe o visitante sobre o motivo pelo qual um site foi bloqueado.
• Política de DNS encriptado. Defina como o serviço gere o DNS sobre HTTPS (RFC 8484) e o DNS sobre TLS (RFC 7858), que podem contornar a filtragem.
• Retenção de registos alinhada com o seu calendário de GDPR. Os registos de DNS associados a uma identidade com sessão iniciada são dados pessoais.
• Relatórios mensais de ameaças bloqueadas por local.

Os suplementos de segurança da Purple são o SecurePass, o Verify e o Shield. Solicite uma demonstração de cada um em relação às cláusulas acima.

Requisitos de analítica e integração

A aquisição de WiFi empresarial desvaloriza frequentemente a analítica, mas é aí que obtém o retorno. Especifique o seguinte:

• Métricas por local e propriedade: visitantes únicos, visitantes novos vs. recorrentes, tempo de permanência, frequência de visitas e horas de ponta.
• Painéis e relatórios agendados, com acesso baseado em funções para que os gestores de cada local vejam apenas o seu próprio espaço.
• Integrações com as suas plataformas de CRM e marketing, através de API ou conetores nativos. O estado do consentimento deve acompanhar todos os registos.
• Propriedade dos dados. Os dados próprios pertencem-lhe a si. Deve estar disponível uma exportação completa em CSV ou JSON a qualquer momento e após a cessação do contrato, sem custos adicionais.

O Purple WiFi Analytics apresenta estas métricas por local e integra-se com plataformas de CRM e marketing.

Níveis de serviço e certificações

• Disponibilidade. Exija um SLA de tempo de atividade mensal com créditos de serviço. A plataforma da Purple opera com 99,999% de tempo de atividade.
• Suporte. Especifique os horários, tempos de resposta por gravidade e um contacto de escalamento designado.
• Certificações. Exija o ISO 27001. Os contratos do governo central do Reino Unido que tratam dados pessoais exigem o Cyber Essentials, ao abrigo da Nota de Política de Aquisições 09/14.
• Referências de escala. Solicite referências para o seu dimensão. A Purple gere mais de 80 000 locais ativos em mais de 90 países e processou 440 milhões de sessões iniciadas em 2024 (dados próprios da Purple).

Matriz de pontuação de requisitos

Área	Requisito	Prioridade	Evidência a solicitar
Integração	Consentimento de marketing separado e desmarcado	Obrigatório	Capturas de ecrã do portal e amostra de exportação de consentimento
Integração	Portal cativo WCAG 2.2 AA	Obrigatório	Relatório de auditoria de acessibilidade independente
Autenticação	RADIUS na nuvem com tolerância a falhas	Obrigatório	Diagrama de arquitetura e 12 meses de dados de disponibilidade
Autenticação	RadSec ou túnel RADIUS encriptado	Obrigatório	Documento de design
Autenticação	Passpoint e OpenRoaming	Recomendado	Local de referência ativo
Encriptação	WPA3 e Enhanced Open	Recomendado	Teste piloto nos seus APs
Hardware	Suporte designado para cada plataforma em utilização	Obrigatório	Guia de integração e resultado do piloto
GDPR	DPA ao abrigo do Artigo 28.º e controlos de retenção	Obrigatório	DPA assinado e demonstração das definições de retenção
PCI DSS	Tráfego de visitantes fora do CDE	Obrigatório	Design de segmentação e declaração de suporte a testes
DNS de Proteção	Filtragem de ameaças e categorias com página de bloqueio	Obrigatório para o setor público, recomendado nos restantes	Teste de bloqueio ativo e amostra de relatório mensal
Analítica	Exportação completa de dados na saída	Obrigatório	Cláusula contratual e ficheiro de amostra de exportação
Serviço	SLA de disponibilidade com créditos de serviço	Obrigatório	Calendário de SLA

Como verificar se um concorrente consegue dar resposta?

Avalie em duas fases: documental e, em seguida, piloto. Qualquer requisito "obrigatório" não cumprido elimina o concorrente na fase documental. Pondere as restantes linhas "desejáveis" de acordo com as suas prioridades. Uma divisão típica é: segurança e conformidade 30%, integração 20%, hardware 15%, analítica 15%, serviço 10% e comercial 10%.

Execute um piloto de 30 dias em dois ou mais locais com plataformas de hardware diferentes. Teste cada um dos seguintes pontos e registe a aprovação ou reprovação.

• O portal cativo aparece à primeira tentativa em iOS, Android, Windows e macOS.
• Um visitante recorrente é reconhecido numa segunda visita.
• Uma exportação de consentimentos mostra o carimbo de data/hora e a versão do texto.
• Um pedido de eliminação remove a pessoa da plataforma e do seu CRM ligado.
• A autenticação continua durante um failover simulado de RADIUS.
• Uma mensagem CoA termina uma sessão sem que ocorra uma nova ligação.
• Um domínio de teste conhecido é bloqueado, exibindo a sua página personalizada.
• Uma tentativa de ligação de VLAN para visitantes para a rede de pagamentos falha.

Teste o débito e a cobertura separadamente da plataforma. O artigo WiFi para a internet: Como funciona e o que verificar aborda os aspetos fundamentais.

Como é que isto se traduz na prática?

Os três cenários abaixo são modelos ilustrativos criados com base em padrões comuns de contratação. Não constituem casos de estudo de clientes.

Um grupo de 45 hotéis em duas plataformas de hardware

Situação. O grupo operava com Cisco Meraki em 30 hotéis e HPE Aruba em 15 locais adquiridos. Cada propriedade tinha o seu próprio portal cativo. Nos 15 locais adquiridos, o consentimento de marketing estava associado à aceitação dos termos.

O que foi feito. O RFP definiu ambas as plataformas como requisitos "obrigatórios". Exigiu um único portal, um único registo de consentimento e aceitações separadas. O piloto abrangeu um hotel em cada plataforma.

Resultado. Dois dos cinco concorrentes falharam a validação de hardware porque suportavam apenas uma plataforma. A solução vencedora manteve todos os 15 locais Aruba nos respetivos APs existentes. O consentimento associado foi removido em todos os 15 locais antes da entrada em funcionamento.

Uma cadeia de retalho de 120 lojas no âmbito da PCI DSS

Situação. Os terminais de pagamento partilhavam switches com os APs de visitantes em lojas mais antigas. Por conseguinte, WiFi para visitantes estava dentro do âmbito de avaliação da PCI DSS da cadeia.

O que foi feito. O RFP exigiu uma arquitetura de segmentação documentada e apoio por escrito para o teste de intrusão 11.4.5. Proibiu também a introdução de dados de cartões no portal cativo.

Resultado. O teste anual de segmentação foi aprovado em todas as 120 lojas. WiFi para visitantes saiu do âmbito da PCI DSS, o que reduziu o número de sistemas que o avaliador teve de analisar.

Um município com 25 bibliotecas e centros desportivos

Situação. O município precisava de WiFi pública segura para famílias, de Cyber Essentials e de uma página de início de sessão acessível.

O que foi feito. O DNS de proteção era um requisito obrigatório, com filtragem de categorias para áreas infantis e uma política de DNS encriptado. Os registos de DNS foram mantidos durante 90 dias, em conformidade com o plano de retenção do município.

Resultado. Três dos sete concorrentes falharam o requisito WCAG 2.2. No projeto-piloto, a filtragem de um dos concorrentes pré-selecionados foi contornada através de DNS sobre HTTPS, o que o excluiu da competição.

O que corre mal na aquisição de WiFi para visitantes e como pode corrigi-lo?

Todos os concorrentes respondem "sim"

Causa: os requisitos descrevem funcionalidades e não normas. Solução: indique a RFC, a norma IEEE ou o artigo do GDPR para cada linha e exija provas.

O portal cativo não é apresentado

Causa: um jardim murado incompleto ou uma deteção fraca do portal cativo. Solução: exija o suporte aos RFC 8908 e RFC 8910 e teste quatro sistemas operativos no projeto-piloto.

O número de visitantes parece inflacionado

Causa: os endereços MAC aleatórios fazem com que um dispositivo pareça vários. Solução: exija o reconhecimento com base na identidade de início de sessão e peça aos concorrentes que expliquem como contam os visitantes de regresso.

O consentimento não é válido

Causa: autorizações agrupadas com os termos ou ausência de registo do texto apresentado. Solução: exija autorizações separadas, desmarcadas e registos de consentimento com controlo de versões.

Não é possível cancelar

Causa: ausência de cláusula de exportação de dados. Solução: exija a exportação completa em CSV ou JSON no momento da saída, sem custos adicionais.

O contrato obriga a novo hardware

Causa: um fornecedor associado a apenas uma marca de AP. Solução: uma cláusula neutra em relação ao hardware que especifique todas as plataformas que utiliza.

Quanto custa e qual é o retorno?

Faça o orçamento para seis rubricas de custos: licenças de software, hardware eventual, instalação, circuitos de internet, suporte e o tempo da sua própria equipa. A arquitetura que escolher é responsável pela maior parte da diferença.

Abordagem	Custo de hardware	Parque multifornecedor	Consentimento e dados	Alteração em cada local
Sobreposição na nuvem nos APs existentes (Purple)	Nenhum: executa nos APs existentes	Um portal único em Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet	Registos de consentimento centralizados e dados próprios que lhe pertencem	Configuração de SSID e RADIUS nos APs existentes
Portal cativo integrado do fornecedor de AP	Nenhum na plataforma atual	Um portal separado para cada plataforma de hardware	Consentimento e dados de visitantes mantidos separadamente em cada plataforma	Configuração repetida em cada plataforma
Substituição total da rede gerida	Novos APs e licenças em cada local	Um único fornecedor de hardware imposto em todo o parque	Definido pelos termos do contrato do fornecedor	Instalação de novos APs em todos os locais

Peça aos concorrentes para apresentarem propostas com base num critério único: um preço anual fixo por local para a totalidade do contrato. Exija a discriminação dos custos de integração, suporte, atualizações e saída. A Purple apresenta orçamentos com base em três planos, Connect, Capture e Engage, com o SecurePass, Verify e Shield como suplementos de segurança.

O retorno provém de quatro vertentes. Obtém dados próprios respaldados por consentimento legítimo. Visualiza as horas de ponta e o tempo de permanência para planear as necessidades de pessoal. Evita custos de hardware através da sobreposição na nuvem (overlay). Dispõe de uma única plataforma para gerir em vez de várias. A Purple disponibiliza isto desde 2012, em mais de 80 000 edifícios e recintos ativos.

Perguntas frequentes

Uma plataforma de WiFi para visitantes pode ser executada nos pontos de acesso que já possuímos?

Sim. A Purple é independente de hardware e é executada como uma sobreposição na nuvem (cloud overlay) em Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Os seus APs continuam a gerir a rádio e o tráfego. A Purple fornece o portal cativo, o RADIUS na nuvem, os registos de consentimento e as análises. No seu RFP, especifique todas as plataformas que utiliza e exija um projeto-piloto no seu próprio firmware antes da adjudicação.

Como devemos solicitar aos fornecedores a orçamentação do WiFi para visitantes num RFP?

Solicite um preço anual fixo por espaço/recinto para a totalidade do período contratual, com os suplementos discriminados separadamente. Exija que os concorrentes incluam a integração (onboarding), o suporte, as atualizações de software e a exportação de dados na rescisão, e que especifiquem eventuais custos de hardware. A Purple apresenta orçamentos com base em três planos, Connect, Capture e Engage, tendo o SecurePass, o Verify e o Shield como suplementos de segurança. Isto permite-lhe comparar propostas linha a linha.

A nossa rede de WiFi para visitantes está no âmbito do PCI DSS?

Não deverá estar, desde que esteja segmentada do seu ambiente de dados de titulares de cartões. O PCI DSS v4.0 permite-lhe reduzir o âmbito através da segmentação, mas é necessário provar que esta funciona. O Requisito 11.4.5 exige testes de intromissão aos controlos de segmentação, no mínimo, a cada 12 meses. Especifique que o tráfego de visitantes nunca se cruza com os sistemas de pagamento e que não são introduzidos dados de cartões no portal cativo.

Quem é o responsável pelo tratamento dos dados do WiFi para visitantes ao abrigo do GDPR?

Geralmente, a sua organização é o responsável pelo tratamento, e o fornecedor de WiFi é o subcontratante. O contrato necessita, portanto, de um acordo de tratamento de dados ao abrigo do Artigo 28.º, que cubra a finalidade, a segurança, os subcontratantes posteriores, a eliminação e a notificação de violações. O seu RFP deve também exigir registos de consentimento exportáveis e uma retenção configurável. Adicione ferramentas para responder a pedidos de acesso e eliminação dentro do prazo de um mês estabelecido pelo Artigo 12.º, n.º 3.

Precisamos do Passpoint ou do OpenRoaming desde o primeiro dia?

Não, mas deve exigir um plano de evolução orçamentado para ambos. Um portal cativo continua a ser a experiência ideal na primeira visita para captar o consentimento e dados próprios. O Passpoint e o OpenRoaming permitem depois que os visitantes recorrentes se conetem automaticamente, utilizando autenticação 802.1X encriptada sem página de início de sessão. A Purple suporta o OpenRoaming, pelo que pode adicionar a ligação automática mais tarde no âmbito do mesmo contrato.

O DNS de proteção deve fazer parte do contrato de WiFi para visitantes?

Sim, especialmente para recintos do setor público e familiares. O DNS de proteção impede que os dispositivos acedam a domínios associados a malware, phishing e servidores de comando e controlo. Também pode aplicar filtragem por categorias por recinto. Torne-o num requisito essencial para câmaras municipais, bibliotecas e locais de prestação de cuidados de saúde. Exija uma página de bloqueio personalizada, uma política de DNS encriptado, relatórios mensais e retenção de registos alinhada com o seu plano de GDPR.

Quanta perturbação causa a mudança de plataformas de WiFi para visitantes?WiFi

A mudança é uma alteração de configuração em cada recinto, e não um projeto de hardware, quando a nova plataforma funciona como uma sobreposição. A Purple sobrepõe-se à infraestrutura existente, para que os seus AP, cablagem e circuitos permaneçam no mesmo local. Execute um piloto de 30 dias em dois recintos com hardware diferente e, em seguida, faça a implementação por fases. Exporte primeiro os registos de consentimento da plataforma anterior, para que nenhum consentimento legal se perca.

Por que não utilizar o portal cativo integrado na plataforma do nosso fornecedor de AP?

Porque um portal integrado vincula a integração, o consentimento e os dados a uma única marca de hardware. As propriedades com vários recintos raramente se mantêm numa única plataforma após aquisições e ciclos de atualização. Uma plataforma independente mantém um único portal, um único registo de consentimento e uma única vista de análise em todos os locais, seja qual for o hardware. Isso protege os seus dados e a sua posição de negociação em cada atualização futura de hardware.