Requisiti RFP per il WiFi per ospiti: cosa specificare per onboarding, sicurezza e analisi

Un'RFP per la rete WiFi per ospiti deve stabilire requisiti misurabili in cinque aree. Onboarding: portale captive, acquisizione del consenso e accessibilità WCAG 2.2. Sicurezza: IEEE 802.1X, RADIUS, Passpoint e WPA3. Hardware: supporto nominale per Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist e Ubiquiti UniFi. Conformità: GDPR, PCI DSS v4.0 e DNS protettivo. Analitica: dati di prima parte esportabili. Valuti i partecipanti in base alle prove fornite.

Che cosa deve specificare concretamente un'RFP per il WiFi per ospiti?

Un'RFP per il WiFi per ospiti trasforma un brief generico, come "WiFi gratuito per gli ospiti", in requisiti che un offerente può soddisfare o meno. Definisce le modalità di accesso delle persone, la sicurezza del traffico e l'hardware su cui la piattaforma deve essere eseguita. Fissa inoltre le modalità di gestione dei dati personali e i report inviati dall'utente.

Le RFP deboli tendono a fallire allo stesso modo. Elencano le funzionalità anziché gli standard, così ogni offerente risponde "sì" e le risposte appaiono identiche. La soluzione consiste nell'associare a ogni voce uno standard stabilito, le prove attese e un test pilota.

Per una proprietà con più sedi, l'RFP stabilisce anche il modello operativo per tutta la durata del contratto. Un portale captive è la pagina web visualizzata da un dispositivo prima di accedere a Internet. È possibile gestire un unico portale captive e un unico registro dei consensi in tutte le sedi. L'alternativa è una configurazione diversa per ciascun fornitore hardware. Risolvere a posteriori una situazione frammentata costa molto di più che specificare un'unica configurazione fin da subito.

Questa guida fornisce la formulazione dei requisiti, una matrice di valutazione e i test pilota. La utilizzi come modello di RFP per il WiFi per ospiti da adattare a hotel, settore retail, sanità, treni, stadi e strutture del settore pubblico.

Di cosa ha bisogno prima di redigere l'RFP per il WiFi per ospiti?

Raccolga cinque elementi prima della prima bozza. Ognuno di essi previene una causa comune di richieste di modifica dopo l'aggiudicazione.

• Un inventario hardware per sede. Registri il fornitore dei punti di accesso (AP), il modello, la piattaforma di gestione e il firmware di ciascun sito. Indichi se ciascun sito utilizza una dashboard cloud o un controller on-premise. La nostra guida Che cos'è un WLC (Wireless LAN Controller) e serve ancora? spiega la differenza.
• Un elenco delle sedi per tipologia. Raggruppi i siti per settore verticale e dimensioni, poiché l'atrio di uno stadio e la hall di un hotel richiedono modalità di onboarding diverse. Indichi le categorie di persone servite da ciascuna struttura: ospiti, clienti, passeggeri, tifosi, pazienti o visitatori.
• Una mappa dei dati. Definisca chi funge da titolare del trattamento dei dati, quali sistemi riceveranno i dati del WiFi e per quanto tempo verranno conservati. Il Suo responsabile della protezione dei dati (DPO) deve approvare questo documento prima dell'invio dell'RFP.
• I confini di pagamento. Elencare tutti i siti che accettano pagamenti con carta. Verificare se i dispositivi di pagamento condividono switch o circuiti con il traffico degli ospiti. Questo definisce l'ambito PCI DSS.
• Metriche di successo. Concordare i dati da rendicontare, come gli accessi, il tasso di opt-in, i visitatori abituali e i ticket di supporto. I partecipanti alla gara potranno così mostrare in che modo i loro report generano ciascun dato.

Coinvolgere fin dall'inizio i team IT, sicurezza, protezione dei dati, marketing e gestione delle sedi. Il WiFi per ospiti impatta su tutti e cinque i team. Un requisito definito da un team spesso limita le attività di un altro.

Come redigere i requisiti della RFP per il WiFi per ospiti, sezione per sezione?

Formulare ciascun requisito con l'indicazione "deve" o "dovrebbe", seguendo le convenzioni dell'RFC 2119. I requisiti vincolanti ("deve") determinano l'ammissione o l'esclusione. I requisiti preferenziali ("dovrebbe") sono oggetto di valutazione qualitativa. Richiedere ai partecipanti alla gara di rispondere a ogni punto fornendo prove concrete: un documento, un certificato, un sito di riferimento o una dimostrazione dal vivo.

Requisiti per la registrazione e per il portale captive

La registrazione è il momento in cui gli ospiti giudicano la rete e in cui vengono creati i registri dei consensi. Questa checklist per la RFP del portale captive ne copre gli elementi essenziali.

• Metodi di accesso. La piattaforma deve supportare e-mail, login tramite social, SMS e codici di accesso, configurabili per ciascuna sede.
• Opt-in con scelta consapevole. Il consenso al marketing deve essere un'opzione separata e non spuntata, mai inclusa nell'accettazione dei termini e condizioni. L'Articolo 7 del GDPR richiede che il consenso sia dimostrabile e semplice da revocare tanto quanto da concedere.
• Accessibilità. Il portale captive deve soddisfare lo standard WCAG 2.2 livello AA.
• Rilevamento affidabile del portale. La piattaforma dovrebbe supportare l'API Captive Portal API (RFC 8908) e l'opzione portale captive DHCP (RFC 8910). Entrambi gli standard consentono ai dispositivi moderni di individuare la pagina di login senza cicli di reindirizzamento.
• Riconoscimento dei visitatori abituali. Da iOS 14 e Android 10 in poi vengono utilizzati indirizzi MAC casuali come impostazione predefinita. Chiedere ai partecipanti alla gara come riconoscono un ospite abituale senza fare affidamento sull'indirizzo hardware del dispositivo.
• Controllo centralizzato. La sede centrale deve gestire il branding, i termini e il testo del consenso in modo centralizzato, con la possibilità di definire deroghe locali per ciascuna struttura.

Purple WiFi per ospiti integra opt-in con scelta consapevole nel portale captive e consente la gestione centralizzata su tutte le sedi dell'azienda.

Requisiti di autenticazione, RADIUS e Passpoint

Il protocollo RADIUS viene utilizzato da un AP per richiedere a un server centrale l'autorizzazione all'accesso di un dispositivo. È definito nello standard RFC 2865. L'accounting RADIUS, definito nello standard RFC 2866, registra l'inizio, la fine e l'utilizzo dei dati della sessione. Per un'azienda multisede, specificare quanto segue:

• RADIUS basato su cloud con ridondanza. L'autenticazione deve continuare a funzionare anche in caso di guasto a un data center. Richiedere l'architettura dettagliata e i dati sulla disponibilità misurata negli ultimi 12 mesi.
• Trasporto RADIUS crittografato. Laddove il traffico RADIUS attraversi la rete internet pubblica, richiedere l'uso di RadSec (RADIUS su TLS, RFC 6614) o un tunnel crittografato.
• Autorizzazione dinamica. La piattaforma dovrebbe inviare messaggi CoA (RFC 5176) per terminare o modificare una sessione senza forzare una riconnessione.
• Segmentazione. Il traffico degli ospiti deve risiedere su una propria VLAN, ovvero un segmento di rete logico isolato dal personale e dai sistemi di pagamento. L'isolamento dei client deve impedire ai dispositivi degli ospiti di comunicare tra loro.
• Crittografia sulle reti aperte. Richiedere WPA3, incluso Enhanced Open (Opportunistic Wireless Encryption, RFC 8110). Cifra ciascuna connessione senza bisogno di una password condivisa.
• Chiavi individuali laddove necessario. La tecnologia iPSK (identity pre-shared key) assegna a ogni persona o dispositivo una propria password WiFi su una rete condivisa. È ideale per ospiti a lungo soggiorno, espositori e personale degli eventi. Purple offre questa funzionalità tramite SecurePass.

Passpoint, noto anche come Hotspot 2.0, si basa sullo standard IEEE 802.11u. Consente a un dispositivo di individuare e connettersi a una rete automaticamente, senza alcun portale captive. L'autenticazione avviene tramite IEEE 802.1X, lo standard per il controllo dell'accesso alla rete basato su porte, garantendo che le credenziali rimangano cifrate. OpenRoaming, gestito dalla Wireless Broadband Alliance, è una federazione basata su Passpoint. Consente agli utenti di accedere alle reti partecipanti utilizzando un'identità già in loro possesso.

Specificare Passpoint e OpenRoaming come requisiti "auspicabili" nella prima fase, insieme a una roadmap con indicazione dei costi. Purple supporta OpenRoaming, consentendo agli ospiti abituali di connettersi automaticamente presso le Sue strutture.

Se l'RFP riguarda anche la rete WiFi del personale, richiedere l'integrazione con Microsoft Entra ID, Okta e Google Workspace. In questo modo, le fasi di ingresso, cambio ruolo e uscita dei dipendenti rimarranno sincronizzate con l'accesso alla rete, senza dover modificare manualmente le password.

Compatibilità AP indipendente dall'hardware

La dicitura "Compatibile con i principali hardware enterprise" non può essere oggetto di valutazione. È necessario indicare ogni piattaforma utilizzata o che si potrebbe adottare durante il contratto, richiedendo poi le medesime cinque funzionalità per ciascuna di esse.

1. Supporto per portale captive esterno.
2. Autenticazione e accounting RADIUS.
3. Walled garden: l'elenco di domini consentiti prima dell'accesso necessari per il portale e il social login.
4. Supporto CoA o un'alternativa documentata per la chiusura delle sessioni.
5. Una guida all'integrazione pubblicata e almeno un riferimento attivo su tale piattaforma.

Fornitore	Piattaforma di gestione da indicare nell'RFP	Documentazione minima da richiedere
Cisco Meraki	Dashboard Meraki	Guida all'integrazione, riferimento attivo, progetto pilota sul firmware in uso
HPE Aruba	HPE Aruba Networking Central o Mobility Controller	Guida all'integrazione, riferimento attivo, progetto pilota sul firmware in uso
Ruckus	RUCKUS SmartZone o RUCKUS One	Guida all'integrazione, riferimento attivo, progetto pilota sul firmware in uso
Juniper Mist	Cloud Juniper Mist	Guida all'integrazione, riferimento attivo, progetto pilota sul firmware in uso
Ubiquiti UniFi	Applicazione di rete UniFi	Guida all'integrazione, riferimento attivo, progetto pilota sul firmware in uso
Cambium	cnMaestro	Guida all'integrazione, riferimento attivo, progetto pilota sul firmware in uso
Extreme	ExtremeCloud IQ	Guida all'integrazione, riferimento attivo, progetto pilota sul firmware in uso
Fortinet	Controller wireless integrato FortiGate	Guida all'integrazione, riferimento attivo, progetto pilota sul firmware in uso

Richieda a ciascun offerente di indicare gli intervalli di firmware supportati, quindi esegua dei test sui propri sistemi. Purple è indipendente dall'hardware e funziona come overlay cloud su tutte e otto le piattaforme. Non è necessario sostituire l'infrastruttura esistente. L'articolo Perché il vostro prossimo aggiornamento del WiFi non richiede nuovo hardware esamina l'aspetto commerciale. Per le installazioni Ruckus, consultare Ruckus SmartZone e RUCKUS One guest WiFi rispetto alle piattaforme esterne con portale captive.

Clausole GDPR da richiedere

Il WiFi per ospiti raccoglie dati personali su larga scala, pertanto il contratto deve includere le seguenti clausole.

• Un accordo sul trattamento dei dati conforme all'Articolo 28 del GDPR, che copra finalità, sicurezza, subresponsabili del trattamento e cancellazione.
• Registro dei consensi che mostri timestamp, versione dell'informativa e canale per ogni opt-in, esportabile su richiesta.
• Conservazione configurabile con cancellazione automatica, in linea con il principio di limitazione della conservazione di cui all'Articolo 5(1)(e).
• Strumenti per gli interessati per individuare, esportare ed eliminare i dati di una singola persona. È necessario rispondere alle richieste entro un mese ai sensi dell'Articolo 12(3).
• Notifica delle violazioni da parte del responsabile del trattamento senza ingiustificato ritardo, come richiesto dall'Articolo 33(2). Si avranno poi 72 ore di tempo per notificare l'autorità di controllo ai sensi dell'Articolo 33(1).
• Trasferimenti internazionali. L'offerente deve indicare dove sono archiviati i dati e il meccanismo di trasferimento per qualsiasi trattamento al di fuori del Regno Unito o dello SEE.
• Prove di sicurezza per l'Articolo 32, idealmente con certificazione ISO 27001.

Purple è certificato ISO 27001 e conforme a GDPR, CCPA e Cyber Essentials.

Clausole PCI DSS da richiedere

Il WiFi per ospiti non deve mai trovarsi all'interno dell'ambiente dei dati dei titolari di carta (CDE). Il CDE comprende i sistemi che archiviano, elaborano o trasmettono i dati delle carte. La norma PCI DSS v4.0 consente di ridurre l'ambito tramite la segmentazione, ma è necessario dimostrarne l'efficacia.

• L'offerente deve confermare per iscritto che il traffico degli ospiti non attraversa mai il CDE e documentarne la progettazione.
• L'architettura deve supportare il penetration test di segmentazione, richiesto almeno ogni 12 mesi ai sensi del requisito 11.4.5.
• Nessun dato della carta può essere inserito nel portale captive. Qualsiasi accesso a pagamento deve utilizzare un fornitore di servizi di pagamento conforme a PCI DSS, con relativa Attestation of Compliance fornita.
• I test trimestrali per individuare access point wireless non autorizzati ai sensi del requisito 11.2.1 continuano ad applicarsi alle aree riservate agli ospiti.

Clausole di DNS protettivo da richiedere

Il DNS protettivo impedisce ai dispositivi di risolvere domini noti per ospitare malware, phishing o server di comando e controllo. Il National Cyber Security Centre (NCSC) del Regno Unito fornisce un servizio di DNS protettivo agli enti del settore pubblico. Si prega di specificare quanto segue.

• Feed sulle minacce. L'offerente deve indicare le proprie fonti di threat intelligence e la frequenza con cui vengono aggiornate.
• Filtraggio per categoria in base alla sede, ad esempio bloccando i contenuti per adulti nelle biblioteche e nelle aree per famiglie.
• Una pagina di blocco personalizzata con il proprio brand che informi il visitatore del motivo per cui il sito è stato bloccato.
• Informativa sul DNS crittografato. Specificare come il servizio gestisce il DNS over HTTPS (RFC 8484) e il DNS over TLS (RFC 7858), che possono aggirare i filtri.
• Conservazione dei log allineata al proprio piano GDPR. I log DNS collegati a un'identità autenticata costituiscono dati personali.
• Reportistica mensile delle minacce bloccate per ciascuna sede.

I moduli di sicurezza aggiuntivi di Purple sono SecurePass, Verify e Shield. Richiedere una dimostrazione di ciascuno di essi in riferimento alle clausole sopra riportate.

Requisiti di analisi e integrazione

La gestione degli acquisti di soluzioni per il WiFi per ospiti enterprise sottovaluta spesso le funzionalità di analisi, che sono tuttavia la fonte del ritorno sull'investimento. Specificare quanto segue.

• Metriche per sede e per l'intero portafoglio: visitatori unici, visitatori nuovi rispetto a quelli abituali, tempo di permanenza, frequenza delle visite e orari di punta.
• Dashboard e report programmati, con accesso basato sui ruoli affinché i responsabili delle sedi visualizzino esclusivamente la propria struttura.
• Integrazioni con le proprie piattaforme CRM e di marketing, tramite API o connettori nativi. Lo stato del consenso deve essere trasferito unitamente a ciascun record.
• Proprietà dei dati. I dati di prima parte appartengono al cliente. L'esportazione completa in formato CSV o JSON deve essere disponibile in qualsiasi momento e alla cessazione del contratto, senza costi aggiuntivi.

Purple WiFi Analytics riporta queste metriche per ogni sede e si integra con le piattaforme CRM e di marketing.

Livelli di servizio e certificazioni

• Disponibilità. Richiedere un SLA di operatività mensile con crediti di servizio. La piattaforma di Purple garantisce un'operatività del 99,999%.
• Supporto. Specificare orari, tempi di risposta in base alla gravità e un referente dedicato per le escalation.
• Certificazioni. Richiedere ISO 27001. I contratti del governo centrale del Regno Unito che trattano dati personali richiedono Cyber Essentials, ai sensi della Procurement Policy Note 09/14.
• Riferimenti di scalabilità. Richiedere referenze adeguate alle proprie dimensioni aziendali. Purple gestisce oltre 80.000 sedi attive in più di 90 Paesi e ha gestito 440 milioni di accessi nel 2024 (dati interni di Purple).

Matrice di valutazione dei requisiti

Area	Requisito	Priorità	Documentazione da richiedere
Onboarding	Consenso al marketing separato e deselezionato	Obbligatorio	Screenshot del portale e un campione di esportazione dei consensi
Onboarding	Portale captive conforme a WCAG 2.2 AA	Obbligatorio	Rapporto di audit di accessibilità indipendente
Autenticazione	RADIUS in cloud con failover	Obbligatorio	Schema dell'architettura e dati di disponibilità degli ultimi 12 mesi
Autenticazione	RadSec o tunnel RADIUS crittografato	Obbligatorio	Documento di progettazione
Autenticazione	Passpoint e OpenRoaming	Consigliato	Sito di riferimento attivo
Crittografia	WPA3 ed Enhanced Open	Consigliato	Test pilota sui propri AP
Hardware	Supporto dedicato per ogni piattaforma utilizzata	Obbligatorio	Guida all'integrazione e risultati del test pilota
GDPR	Accordo sul trattamento dei dati (DPA) ex Articolo 28 e controlli sulla conservazione	Obbligatorio	DPA firmato e dimostrazione delle impostazioni di conservazione
PCI DSS	Traffico degli ospiti esterno al CDE	Obbligatorio	Progettazione della segmentazione e dichiarazione di supporto ai test
Protective DNS	Filtraggio delle minacce e delle categorie con pagina di blocco	Obbligatorio per il settore pubblico, consigliato per gli altri settori	Test di blocco in tempo reale e report mensile campione
Analitica	Esportazione completa dei dati al recesso	Requisito obbligatorio	Clausola contrattuale e file di esportazione campione
Servizio	SLA di disponibilità con crediti di servizio	Requisito obbligatorio	Programma SLA

Come verificare che un offerente sia in grado di soddisfare i requisiti?

Effettuare la valutazione in due fasi: prima la documentazione, poi il progetto pilota. Qualsiasi requisito obbligatorio non soddisfatto comporta l'eliminazione dell'offerente nella fase documentale. Ponderare le restanti voci facoltative in base alle proprie priorità. Una suddivisione tipica prevede: sicurezza e conformità 30%, onboarding 20%, hardware 15%, analitica 15%, servizio 10% e aspetti commerciali 10%.

Eseguire un progetto pilota di 30 giorni in due o più sedi su piattaforme hardware differenti. Testare ciascuno dei seguenti elementi e registrarne l'esito positivo o negativo.

• Il portale captive viene visualizzato al primo tentativo su iOS, Android, Windows e macOS.
• Un ospite che ritorna viene riconosciuto alla seconda visita.
• Un'esportazione del consenso mostra il timestamp e la versione dell'informativa.
• Una richiesta di cancellazione rimuove la persona dalla piattaforma e dal CRM collegato.
• L'autenticazione continua durante un failover simulato di RADIUS.
• Un messaggio CoA termina una sessione senza riconnessione.
• Un dominio di test noto viene bloccato, mostrando la pagina personalizzata con il proprio marchio.
• Un tentativo di connessione dalla rete VLAN per ospiti alla rete dei pagamenti ha esito negativo.

Testare la velocità di trasferimento e la copertura separatamente dalla piattaforma. L'articolo WiFi per internet: come funziona e cosa verificare ne illustra i concetti fondamentali.

Come si presenta questa situazione nella pratica?

I tre scenari riportati di seguito sono modelli illustrativi basati su schemi di approvvigionamento comuni. Non si tratta di casi di studio di clienti reali.

Un gruppo di 45 hotel su due piattaforme hardware

Situazione. Il gruppo utilizzava Cisco Meraki in 30 hotel e HPE Aruba in 15 strutture acquisite. Ogni proprietà disponeva di un proprio portale captive. Nelle 15 strutture acquisite, il consenso al marketing era abbinato all'accettazione dei termini e condizioni.

Intervento effettuato. La richiesta di offerta (RFP) indicava entrambe le piattaforme come requisiti obbligatori. Richiedeva un unico portale, un unico registro dei consensi e opzioni di opt-in separate. Il progetto pilota ha interessato un hotel per ciascuna piattaforma.

Risultato. Due offerenti su cinque non hanno superato il filtro relativo all'hardware perché supportavano una sola piattaforma. La soluzione sovrapposta vincente ha mantenuto tutte le 15 strutture Aruba sugli AP esistenti. Il consenso abbinato è stato rimosso in tutte le 15 strutture prima del rilascio in produzione.

Una catena retail di 120 negozi nell'ambito di applicazione PCI DSS

Situazione. Nei negozi più datati, i terminali di pagamento condividevano gli switch con gli AP per gli ospiti. La rete WiFi per ospiti rientrava quindi nell'ambito della valutazione PCI DSS della catena.

Intervento effettuato. La richiesta di offerta richiedeva una struttura di segmentazione documentata e un supporto scritto per il penetration test 11.4.5. Vietava inoltre l'inserimento dei dati della carta di credito sul portale captive.

Risultato. Il test annuale di segmentazione è stato superato in tutti i 120 negozi. La rete WiFi per ospiti è stata esclusa dall'ambito PCI DSS, riducendo il numero di sistemi che il valutatore ha dovuto esaminare.

Un comune con 25 biblioteche e centri sportivi

Situazione. Il comune necessitava di una rete WiFi per ospiti sicura per le famiglie, di Cyber Essentials e di una pagina di login accessibile.

Azioni intraprese. Il DNS protettivo era un elemento fondamentale, con filtraggio per categoria per le aree dedicate ai bambini e una politica DNS crittografata. I log DNS sono stati conservati per 90 giorni, in linea con il piano di conservazione del comune.

Risultati. Tre offerenti su sette non hanno superato la fase WCAG 2.2. Nel progetto pilota, il filtraggio di un offerente preselezionato è stato aggirato tramite DNS over HTTPS, il che ne ha comportato l'esclusione.

Cosa va storto nell'approvvigionamento del WiFi per ospiti e come porvi rmedio?

Ogni offerente risponde "sì"

Causa: i requisiti descrivono funzionalità, non standard. Rimedio: specificare l'RFC, lo standard IEEE o l'articolo GDPR per ciascuna voce e richiedere prove concrete.

Il portale captive non viene visualizzato

Causa: un walled garden incompleto o un rilevamento debole del portale captive. Rimedio: richiedere il supporto per RFC 8908 e RFC 8910 e testare quattro sistemi operativi durante il pilota.

Il numero di visitatori appare gonfiato

Causa: gli indirizzi MAC casuali fanno sì che un singolo dispositivo sembri molteplici. Rimedio: richiedere il riconoscimento basato sull'identità di accesso e chiedere agli offerenti di spiegare come conteggiano i visitatori di ritorno.

Il consenso non è conforme

Causa: opt-in associati ai termini di servizio o nessuna registrazione del testo mostrato. Rimedio: richiedere opt-in separati e non preselezionati, oltre a registri del consenso con cronologia delle versioni.

Impossibile svincolarsi

Causa: assenza di una clausola per l'esportazione dei dati. Rimedio: richiedere l'esportazione completa in CSV o JSON al termine del contratto, senza costi aggiuntivi.

Il contratto impone l'acquisto di nuovo hardware

Causa: un fornitore vincolato a un solo marchio di AP. Rimedio: inserire una clausola di neutralità hardware che indichi ogni piattaforma attualmente in uso.

Quali sono i costi e quali i vantaggi?

È necessario prevedere un budget per sei voci di costo: licenze software, eventuale hardware, installazione, circuiti Internet, supporto e il tempo impiegato dal proprio team. L'architettura scelta determina la maggior parte delle differenze.

Approccio	Costo hardware	Parco fornitori multipli	Consenso e dati	Modifiche in ciascuna sede
Cloud overlay sugli AP esistenti (Purple)	Nessuno: funziona sugli AP esistenti	Un unico portale per Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet	Registri del consenso centralizzati e dati di prima parte di propria proprietà	Configurazione SSID e RADIUS sugli AP esistenti
Portale captive integrato del fornitore AP	Nessuno sulla piattaforma attuale	Un portale separato per ciascuna piattaforma hardware	Dati sul consenso e sui visitatori conservati separatamente su ciascuna piattaforma	Configurazione ripetuta su ciascuna piattaforma
Rete gestita con sostituzione completa	Nuovi AP e licenze per ogni sede	Un unico fornitore di hardware imposto su tutto il parco	Definito dai termini contrattuali del fornitore	Installazione di nuovi AP in ogni sede

Richiedere agli offerenti un preventivo basato su un unico criterio: un prezzo annuale fisso per sede per l'intera durata del contratto. Richiedere la dettagliatura dei costi di onboarding, supporto, aggiornamenti e uscita. Purple fornisce preventivi su tre piani: Connect, Capture ed Engage, con SecurePass, Verify e Shield come add-on di sicurezza.

Il ritorno sull'investimento proviene da quattro fattori. Ottieni dati di prima parte supportati da un consenso conforme alle normative. Visualizzi gli orari di punta e i tempi di permanenza per pianificare il personale. Eviti spese in hardware grazie all'overlay. Ottieni un'unica piattaforma da gestire anziché diverse. Purple offre tutto questo dal 2012, in oltre 80.000 location attive.

Domande frequenti

Una piattaforma guest WiFi può essere eseguita sugli access point che già possediamo?

Sì. Purple è indipendente dall'hardware e funziona come overlay cloud su Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. I tuoi AP continuano a gestire le frequenze radio e il traffico. Purple fornisce il Captive Portal, il RADIUS cloud, il registro dei consensi e gli analytics. Nella tua RFP, indica ogni piattaforma in uso e richiedi un pilot sul tuo firmware attuale prima dell'aggiudicazione.

In che modo dovremmo richiedere ai fornitori la quotazione del guest WiFi in una RFP?

Richiedi un prezzo annuale fisso per location per l'intera durata del contratto, con i moduli aggiuntivi dettagliati separatamente. Imponi ai partecipanti alla gara di includere onboarding, supporto, aggiornamenti software ed esportazione dei dati in fase di recesso, indicando chiaramente eventuali costi hardware. Purple offre preventivi su tre piani (Connect, Capture ed Engage) con SecurePass, Verify e Shield come componenti aggiuntivi per la sicurezza. Questo permette di confrontare le offerte voce per voce.

La nostra rete guest WiFi rientra nell'ambito del PCI-DSS?

Non dovrebbe rientrarci, a condizione che sia segmentata rispetto al tuo ambiente di dati dei titolari di carta. Il PCI-DSS v4.0 consente di ridurre l'ambito tramite la segmentazione, ma è necessario dimostrarne l'efficacia. Il requisito 11.4.5 richiede penetration test dei controlli di segmentazione almeno ogni 12 mesi. Specifica che il traffico guest non deve mai incrociare i sistemi di pagamento e che nessun dato relativo alle carte di credito deve essere inserito nel Captive Portal.

Chi è il titolare del trattamento per i dati del guest WiFi ai sensi del GDPR?

Di norma il titolare sei tu, mentre il fornitore WiFi è il responsabile del trattamento. Il contratto necessita quindi di un accordo sul trattamento dei dati ai sensi dell'Articolo 28 che copra finalità, sicurezza, sub-responsabili, cancellazione e notifica delle violazioni. La tua RFP dovrebbe anche richiedere registri di consenso esportabili e tempi di conservazione configurabili. Aggiungi strumenti per rispondere alle richieste di accesso e cancellazione entro la scadenza di un mese prevista dall'Articolo 12(3).

Abbiamo bisogno di Passpoint o OpenRoaming fin dal primo giorno?

No, ma dovresti richiedere una roadmap con relativi costi per entrambi. Il Captive Portal rimane l'esperienza ideale per la prima visita per acquisire il consenso e i dati di prima parte. Passpoint e OpenRoaming consentono poi agli ospiti che ritornano di connettersi automaticamente, utilizzando l'autenticazione crittografata 802.1X senza pagina di login. Purple supporta OpenRoaming, permettendoti di aggiungere la connessione automatica in un secondo momento all'interno dello stesso contratto.

Il DNS protettivo dovrebbe far parte del contratto guest WiFi?

Sì, soprattutto per il settore pubblico e le strutture per famiglie. Il DNS protettivo impedisce ai dispositivi di raggiungere domini collegati a malware, phishing e server di comando e controllo. Può anche applicare il filtraggio per categoria in base alla sede. Considerarlo un elemento imprescindibile per enti locali, biblioteche e strutture sanitarie. Richiedere una pagina di blocco personalizzata con il proprio marchio, una politica DNS crittografata, report mensili e una conservazione dei log allineata con la tempistica di GDPR.

Quanto scompiglio causa il passaggio a un'altra piattaforma WiFi per ospiti?

Il passaggio è una modifica della configurazione in ciascuna sede, non un progetto hardware, quando la nuova piattaforma funziona come overlay. Purple si sovrappone all'infrastruttura esistente, consentendo di mantenere gli AP, il cablaggio e i circuiti attuali. Avviare un pilota di 30 giorni in due sedi con hardware diverso, quindi distribuire la soluzione gradualmente. Esportare prima i registri del consenso dalla piattaforma uscente, in modo da non perdere i consensi legittimi acquisiti.

Perché non utilizzare il portale captive integrato nella piattaforma del fornitore di AP?

Perché un portale integrato vincola l'onboarding, il consenso e i dati a un unico marchio hardware. Le proprietà con più sedi raramente mantengono una sola piattaforma dopo acquisizioni e cicli di aggiornamento. Una piattaforma indipendente mantiene un unico portale, un unico registro dei consensi e un'unica vista analitica per ogni sede, indipendentemente dall'hardware. Ciò protegge i dati e la propria posizione contrattuale in occasione di ogni futuro aggiornamento dell'hardware.