Migrazione del WiFi del personale da una password condivisa a 802.1X in una proprietà multi-sito

Esegui un nuovo SSID WPA-Enterprise affiancato all'SSID con password condivisa e sposta i dispositivi a scaglioni. I dispositivi gestiti ricevono i certificati EAP-TLS dal tuo MDM. I telefoni personali effettuano l'onboarding tramite un Captive Portal. I dispositivi che non possono memorizzare un certificato ottengono la propria chiave su una rete xPSK. Disattiva la password condivisa in ciascuna sede non appena il relativo registro di autenticazione non mostra più dispositivi legacy.

Cosa cambia quando si sposta il WiFi del personale da una password condivisa a 802.1X?

Una password condivisa per il personale è un singolo segreto posseduto da ogni collega, ogni dispositivo e ogni ex dipendente. Quando qualcuno se ne va, la conserva. Modificarla significa inserire nuovamente la chiave su ogni cassa, tablet e laptop in qualsiasi sede.

Il requisito 2.3.2 dello standard PCI-DSS v4.0.1 trasforma questa prassi in un obbligo. Riguarda gli ambienti wireless collegati all'ambiente dei dati dei titolari di carta o che trasmettono dati di conto. È necessario modificare le chiavi di crittografia wireless ogni volta che una persona a conoscenza delle stesse lascia l'azienda o il ruolo per cui erano necessarie. È inoltre necessario modificarle quando si sospetta o si sa che una chiave sia stata compromessa. In una rete aziendale con un elevato turnover, un'interpretazione letterale implica la modifica delle chiavi quasi ogni settimana.

IEEE 802.1X elimina il segreto condiviso. È lo standard per il controllo dell'accesso alla rete basato sulle porte. Un dispositivo deve dimostrare la propria identità prima che l'access point inoltri il suo traffico. L'access point invia la richiesta tramite RADIUS, il protocollo utilizzato dalle apparecchiature di rete per interrogare un server di autenticazione.

EAP-TLS (Extensible Authentication Protocol con Transport Layer Security, RFC 5216) è il metodo di risposta più sicuro. Il dispositivo e il server presentano ciascuno un certificato. Non esiste alcuna password da condividere, rubare tramite phishing o scrivere sulla lavagna del back-office.

L'identità determina quindi la VLAN (virtual LAN, un segmento di rete logicamente separato). RADIUS restituisce una VLAN per ciascun dispositivo utilizzando gli attributi del tunnel definiti in RFC 3580. Un laptop della contabilità e un tablet della cucina possono connettersi allo stesso SSID e finire in segmenti diversi.

Come si colloca questo aspetto su Purple Access

Purple Access gestisce tre reti su un'unica piattaforma:

• Open: un Captive Portal, la pagina web che un dispositivo visualizza prima di ottenere l'accesso alla rete. In questa migrazione gestisce l'onboarding dei telefoni personali.
• Secure: EAP-TLS, integrazione con identity provider, Passpoint e RADIUS in cloud. I laptop, i tablet e i telefoni del personale finiscono qui.
• xPSK: una chiave separata per ciascun dispositivo, chiamata iPSK o PPSK a seconda del vendor. Ogni dispositivo che non può memorizzare un certificato finisce qui.

Il WiFi ospiti rimane sulla propria rete ed è escluso da questo progetto. La guida Sicurezza della rete ospiti: una guida pratica per il 2026 copre questo aspetto. Il filtraggio DNS su qualsiasi di queste reti è gestito da Purple Shield. Per una panoramica più ampia, consulta la nostra guida generale sulla sicurezza WiFi.

Confronto tra i modelli di credenziali

PEAP-MSCHAPv2 (Protected EAP con nome utente e password) rappresenta la solita soluzione intermedia, quindi rientra a pieno titolo nel confronto.

Modello di credenziale	Cosa presenta ciascun dispositivo	Cosa porta con sé chi lascia l'azienda	Revoca di una singola persona o dispositivo	Impatto sui cambi chiave PCI DSS 2.3.2	Adatto a
Shared PSK	Un'unica password per tutti	La chiave di ogni sede	Riconfigurare la chiave su ogni dispositivo nell'SSID	Cambiare la chiave per tutti ogni volta che chi lascia l'azienda la conosceva	Una singola sede piccola senza dati di carte di credito su WiFi
PEAP-MSCHAPv2	Nome utente e password personali	La propria password finché l'account non viene disattivato	Disattivare l'account	Nessuna chiave condivisa, ma le password possono essere intercettate se i certificati del server non vengono convalidati	Strutture che non dispongono ancora di un'autorità di certificazione
EAP-TLS	Un certificato per dispositivo o persona	Nulla di utilizzabile una volta revocato il certificato	Revocare il certificato o disattivare l'identità	Nessuna chiave condivisa da modificare	Laptop gestiti, tablet, palmari e telefoni aziendali configurati
xPSK	Una chiave univoca per dispositivo	Solo le chiavi dei dispositivi inserite personalmente	Eliminare la chiave di quel dispositivo	Cambiare solo le chiavi gestite da chi lascia l'azienda	Casse, terminali POS, stampanti, TVCC, segnaletica digitale

Di cosa hai bisogno prima di migrare una password WiFi condivisa a 802.1X?

Non è necessario alcun nuovo access point. Purple Access è indipendente dall'hardware e funziona come overlay cloud su Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. Devi solo verificare questi sei requisiti prima del progetto pilota.

1. Un inventario dei dispositivi per sede. Esporta l'elenco dei client per l'SSID del personale dalla console di ciascuna sede, coprendo un periodo di almeno 14 giorni. Suddividi ogni dispositivo in una delle tre categorie. I dispositivi gestiti sono registrati nella tua piattaforma MDM (mobile device management). I dispositivi personali sono i telefoni di proprietà del personale. I dispositivi headless sono casse, terminali POS, stampanti, telecamere e qualsiasi altro dispositivo privo di un archivio certificati.
2. Un identity provider con gruppi ben definiti. Utilizza Microsoft Entra ID, Okta o Google Workspace. Ogni gruppo che necessita di un proprio segmento diventa una regola VLAN. La guida Okta WiFi Authentication: Setup Steps, Options and Fixes illustra tutti i passaggi relativi a Okta.
3. Un'autorità di certificazione a cui il tuo MDM possa inviare richieste. Microsoft Intune, Jamf Pro e la maggior parte degli altri MDM emettono certificati tramite profili SCEP (Simple Certificate Enrollment Protocol) o PKCS. Decidi fin da ora se un certificato deve identificare il dispositivo o la persona. I tablet e i palmari condivisi richiedono certificati di dispositivo.
4. Un piano VLAN esteso a ogni sede. Un piano tipico prevede cinque segmenti: personale, dispositivi aziendali gestiti, dispositivi di pagamento, altri dispositivi headless e un segmento legacy con restrizioni. Verifica che il trunk dello switch verso ciascun access point trasmetta ogni VLAN.
5. Purple Access impostato come server RADIUS per l'SSID sicuro. Se il tuo vendor utilizza il protocollo RADIUS per le chiavi per singolo dispositivo, indirizza ad esso anche la rete xPSK. L'architettura RADIUS-as-a-Service in cloud elimina la necessità di installare, aggiornare o configurare cluster di server nelle singole sedi.
6. Un responsabile identificato in ciascuna sede. È necessaria una persona in grado di identificare i dispositivi sconosciuti nell'inventario e di approvarne lo spegnimento.

Come migrare il WiFi del personale a 802.1X senza un fine settimana di fermo totale?

Tre principi permettono di eliminare il fine settimana di fermo. Configurare le nuove reti accanto a quella precedente. Spostare i dispositivi per classe, non per sede. Disattivare le reti sede per sede, basandosi sulle evidenze del registro di autenticazione.

È possibile eseguire entrambi gli SSID durante la migrazione?

Sì, ed è consigliabile eseguirli insieme per tutta la durata del progetto. La vera questione riguarda l'airtime. Ogni SSID trasmesso aggiunge beacon frame su ciascuna radio, motivo per cui le guide di progettazione dei fornitori, tra cui quella di Cisco Meraki, raccomandano di mantenere basso il numero di SSID.

La soluzione più ordinata consiste nel trasformare l'SSID legacy nella rete xPSK. Mantenere lo stesso nome e la stessa modalità di sicurezza. Aggiungere la vecchia password condivisa come una delle chiavi nell'elenco delle chiavi per dispositivo, associata alla VLAN legacy limitata. I dispositivi che conoscono la vecchia password si riconnettono senza problemi. A ogni dispositivo spostato viene assegnata una chiave propria.

Quando la chiave legacy non è più utilizzata da alcun dispositivo in una determinata sede, è possibile eliminarla. La password condivisa viene così disattivata, senza che sia mai comparso un nuovo SSID. Lo stato finale sarà composto da tre SSID: guest, personale sicuro e xPSK.

È opportuno testare questa procedura prima su una singola sede. Diversi fornitori eseguono le funzionalità per singola chiave su WPA2-Personal anziché su WPA3-SAE, pertanto è necessario verificare la documentazione del proprio fornitore. Se la piattaforma in uso non consente di mantenere la vecchia password come chiave singola, è possibile eseguire quattro SSID durante la migrazione e rimuovere l'SSID legacy al momento del passaggio definitivo.

Fase 1: configurare una sola volta e applicare a tutta l'infrastruttura

Configurare l'SSID sicuro e la rete xPSK una sola volta, quindi applicarli a ogni sede tramite un modello. Utilizzare WPA3-Enterprise se la flotta gestita lo supporta, altrimenti una modalità di transizione WPA2/WPA3.

Fornitore	Console	Impostazione SSID sicuro	Funzionalità chiave per dispositivo	Applicazione tra le sedi con
Cisco Meraki	Meraki Dashboard	Enterprise con il mio server RADIUS	Identity PSK (iPSK)	Modelli di configurazione
HPE Aruba	Aruba Central	Livello di sicurezza Enterprise	MPSK	Gruppi
Ruckus	SmartZone o RUCKUS One	Autenticazione 802.1X EAP	Dynamic PSK (DPSK)	Zone o strutture
Juniper Mist	Portale Mist	Sicurezza WLAN Enterprise (802.1X)	Multi PSK	Modelli WLAN
Ubiquiti UniFi	UniFi Network	WPA Enterprise con un profilo RADIUS	Private Pre-Shared Keys	Impostazioni per singola sede

Le etichette possono variare tra le diverse versioni del firmware, pertanto è raccomandato consultare la documentazione del fornitore per il percorso aggiornato. Ulteriori guide passo-passo sulla configurazione sono disponibili nelle nostre Guide di accesso.

Fase 2: progetto pilota in due o tre sedi rappresentative

Scegliere sedi differenti tra loro: una sede grande, una piccola e una con un modello di switch non standard. Eseguire ogni fase successiva da cima a fondo prima in queste sedi. Il progetto pilota serve a individuare il trunk che non trasporta una VLAN, il cassa che supporta solo WPA2 e il profilo MDM che si installa nell'ordine errato.

Fase 3: distribuire i certificati ai dispositivi gestiti tramite l'MDM

I dispositivi gestiti si muovono più velocemente perché l'MDM raggiunge ogni sede contemporaneamente. Distribuisci tre profili in ordine: il certificato root attendibile, il certificato del dispositivo e poi il profilo WiFi. La maggior parte degli MDM fallisce il profilo WiFi se il certificato a cui fa riferimento è mancante.

Il profilo WiFi assegna il nome all'SSID sicuro, imposta EAP-TLS e fissa il nome del certificato e il root del server RADIUS. Una volta che un dispositivo si è autenticato sull'SSID sicuro, invia un profilo che rimuove la rete legacy. In caso contrario, il dispositivo potrebbe tornare al vecchio SSID di cui si fida già.

Fase 4: onboarding dei telefoni personali sullo stesso SSID

Il personale si connette alla rete aperta, spesso scansionando un codice QR affisso nel back office. Effettua l'accesso sul Captive Portal con la propria identità aziendale e riceve il profilo di rete sicuro. Il nostro pilastro sui Captive Portal copre la progettazione del portale.

Un profilo Passpoint (Hotspot 2.0) è la soluzione migliore per una rete multi-sede. Passpoint consente a uno smartphone di individuare e connettersi a una rete tramite le sue credenziali piuttosto che tramite il nome dell'SSID. Un singolo onboarding funziona quindi in ogni sede. Associa i telefoni personali a una VLAN del personale riservata solo a internet, separata dai segmenti di pagamento e di back office. Esegui l'onboarding per regione in modo che l'helpdesk registri un flusso costante anziché un picco improvviso.

Fase 5: sposta ogni dispositivo che non può ospitare un certificato sulla propria chiave

Assegna a ciascun dispositivo headless una chiave univoca e associa le chiavi per classe alle VLAN. I terminali di pagamento vanno al segmento pagamenti e le telecamere al segmento telecamere. Registra il dispositivo, l'indirizzo MAC, la sede, la chiave e la persona che l'ha inserita.

Le stampanti e i registratori delle telecamere hanno di solito interfacce web che è possibile rigenerare da remoto. Le casse e i terminali potrebbero richiedere la piattaforma di gestione del fornitore o una visita in loco. PPSK for retail store devices: a deployment checklist for tills, scanners and CCTV on Cisco Meraki and Juniper Mist tratta questa fase in dettaglio.

Quanto dura un rollout 802.1X multi-sede?

Considera le durate indicate di seguito come ipotesi di pianificazione da verificare nel tuo pilot, non come benchmark. I dispositivi headless dettano il ritmo, poiché sono l'unica classe che potrebbe richiedere un intervento in loco.

Fase	Cosa succede	Ambito	Durata pianificata
0. Preparazione	Inventario, gruppi di identità, piano VLAN, autorità di certificazione	Intera rete, nessuna modifica ai dispositivi	2-3 settimane
1. Configurazione	SSID sicuro e rete xPSK nei template	Intera rete	1 settimana
2. Pilot	Ogni fase dall'inizio alla fine	2-3 sedi	3-4 settimane
3. Dispositivi gestiti	L'MDM invia i certificati e il profilo WiFi	Tutte le sedi contemporaneamente	2 settimane più 2 settimane per i ritardatari
4. Telefoni personali	Onboarding tramite la rete aperta	20-30 sedi per ondata	2 settimane per ondata
5. Dispositivi headless	Chiave univoca per dispositivo	Da remoto o visita in loco	Mezza giornata per sede, eseguita in parallelo
6. Spegnimento	Eliminazione della chiave legacy	Per sede	Minimo 14 giorni consecutivi senza problemi per sede

Le fasi 3, 4 e 5 si sovrappongono. In base a queste ipotesi, prevedi da 10 a 14 settimane per 50 sedi e da 20 a 26 settimane per 200.

Scenario reale: un gruppo di 64 hotel su Cisco Meraki

Cifre illustrative. Ogni hotel utilizzava circa 40 dispositivi su un'unica chiave condivisa dal personale. Ciò significava 22 dispositivi gestiti, sei telefoni personali e 12 dispositivi headless: terminali per carte di credito, stampanti di ricevute e schermi per digital signage. Il personale di pulizia interinale conosceva la chiave, quindi ogni rotazione dell'agenzia attivava la condizione di abbandono PCI-DSS 2.3.2.

Il team ha convertito il vecchio SSID in iPSK e ha mantenuto la vecchia password come un'unica chiave su una VLAN limitata. Hanno creato l'SSID Enterprise in un modello di configurazione. Intune ha distribuito i certificati a tutti i 1.408 dispositivi gestiti nella terza settimana successiva al pilota. I duty manager hanno registrato 384 telefoni personali regione per regione. Gli ingegneri hanno riconfigurato le chiavi dei 768 dispositivi headless durante le visite di manutenzione programmate.

Risultato: entro la nona settimana, la chiave legacy supportava solo dispositivi headless. L'ultimo hotel l'ha eliminata nella settimana 16, senza alcuna notte di migrazione critica. L'uscita di un dipendente ora comporta la disattivazione di un solo account, anziché la riconfigurazione della chiave per 2.560 dispositivi in 64 hotel.

Scenario reale: un retailer con 180 punti vendita su Juniper Mist

Cifre illustrative. Ogni punto vendita utilizzava 27 dispositivi sulla chiave condivisa: 12 scanner portatili, tre PC di back-office, quattro stampanti di etichette, sei telecamere e due telefoni dei responsabili. La riconfigurazione delle chiavi a seguito dell'uscita del personale si era bloccata, perché nessuno riusciva a raggiungere ogni punto vendita nello stesso giorno.

Scanner e PC sono passati a EAP-TLS tramite MDM, per un totale di 2.700 dispositivi. Stampanti e telecamere sono passate a Multi PSK, con 1.800 chiavi univoche mappate su due VLAN. I punti vendita sono stati migrati in sei fasi da 30. Il pilota ha rilevato un formato di punto vendita i cui switch non eseguivano il trunking della VLAN delle telecamere. Il team ha corretto il modello prima della prima fase.

Risultato: il conteggio legacy per punto vendita ha raggiunto lo zero in tutti i 180 negozi entro la settimana 22. Oggi non esiste alcuna chiave condivisa per il personale in tutta la struttura.

Come si verifica che la migrazione funzioni, sede per sede?

Dimostra ogni fase nel pilota

Esegui quattro test in ogni sede pilota prima di estendere la soluzione:

• Test di connessione: un nuovo dispositivo gestito, un telefono registrato e una cassa con la chiave aggiornata si connettono al primo tentativo.
• Test VLAN: ogni dispositivo viene assegnato al segmento stabilito dalla sua identità o dalla sua chiave.
• Test di roaming: un dispositivo portatile mantiene la sessione attiva spostandosi tra i vari access point.
• Test per uscita personale: disabilita un'identità di prova e revoca il relativo certificato, quindi conferma che l'autenticazione successiva venga rifiutata.

Misura i progressi per singola sede dal registro di autenticazione

Riporta tre dati per sede ogni settimana, estraendoli dal registro di autenticazione e dall'elenco client del controller:

1. Dispositivi che si autenticano con EAP-TLS sull'SSID sicuro.
2. Dispositivi sulla propria chiave xPSK riservata.
3. Dispositivi che utilizzano ancora la chiave legacy.

Il progresso è dato dai primi due divisi per tutti i dispositivi del personale distinti visti negli ultimi 14 giorni. Ordina i siti in base al conteggio legacy e concentra gli sforzi dove il conteggio è più alto. Conta i telefoni personali in base all'identità, non all'indirizzo MAC. iOS e Android randomizzano gli indirizzi MAC per rete, quindi un telefono può sembrare due.

Quando si disattiva la password condivisa?

Elimina la chiave legacy in un sito quando si verificano tutte e quattro le seguenti condizioni:

• Il conteggio legacy è stato pari a zero per 14 giorni consecutivi, coprendo due cicli completi di turni.
• Ogni dispositivo headless nell'inventario ha una propria chiave.
• I ticket dell'helpdesk per quel sito sono tornati al livello di base.
• Il responsabile del sito ha dato la sua approvazione.

Registra la data. Da quel momento in poi, non esisterà più alcuna chiave condivisa che il punto 2.3.2 ti richieda di modificare. Il tuo registro delle chiavi e il log di autenticazione diventano le prove per soddisfare il requisito. Se in seguito compare un dispositivo tralasciato, assegnali una propria chiave. Non ripristinare mai quella condivisa.

Cosa può andare storto in un rollout 802.1X multisito e come si risolve?

I dispositivi tornano al vecchio SSID legacy

I dispositivi ricordano entrambe le reti e potrebbero preferire quella vecchia. Rimuovi la rete legacy tramite profilo MDM una volta che l'SSID sicuro funziona. Sui telefoni personali, includi "dimentica la vecchia rete" nelle istruzioni di onboarding.

I dispositivi si collegano senza convalidare il server

Un profilo WiFi che salta la convalida del certificato del server si fiderà di un access point contraffatto che trasmette lo stesso SSID. Associa il root attendibile e il nome del server RADIUS in ogni profilo.

I client si autenticano ma non ottengono un indirizzo IP

RADIUS ha assegnato una VLAN che il trunk dello switch non gestisce. Esegui un audit dei trunk su ogni modello di switch nel progetto pilota, quindi correggi il template, non il singolo sito.

I laptop Windows non funzionano con PEAP

Microsoft documenta che Windows Defender Credential Guard blocca il single sign-on MSCHAPv2 con credenziali salvate. Il passaggio di tali laptop a EAP-TLS rimuove la dipendenza dalle password.

I certificati scadono contemporaneamente in tutta l'infrastruttura

I certificati emessi in un'unica operazione scadono tutti nell'arco di una settimana. Imposta il rinnovo automatico nell'MDM ben prima della scadenza e dilaziona l'invio iniziale se la tua autorità di certificazione lo consente.

Troppi SSID rallentano ogni rete

L'esecuzione simultanea degli SSID guest, legacy, sicuro e xPSK aggiunge overhead di beacon su ogni radio. Converti l'SSID legacy nella rete xPSK, come descritto sopra, per mantenere il conteggio a tre.

Quanto costa una migrazione a 802.1X e cosa si ottiene in cambio?

I costi riguardano le licenze e la manodopera, non l'hardware. Paghi per Purple Access, oltre al lavoro sui profili MDM, le visite in loco per i dispositivi headless e il tempo dell'helpdesk durante le fasi di onboarding. Access point, switch e controller rimangono così come sono.

Il ritorno sull'investimento risiede in ciò che smetti di fare. Nello scenario retail, una singola rotazione della chiave condivisa a livello di intera rete significava reinserirla su 4.860 dispositivi. Ipotizzando tre minuti per dispositivo, si tratta di 243 ore di lavoro del personale per ogni rotazione. Dopo la migrazione, la partenza di un dipendente richiede solo la disattivazione di un'unica identità, oltre alla modifica di eventuali chiavi di dispositivo inserite da quella persona.

Si ottiene inoltre un registro di autenticazione che indica quale identità o chiave si è connessa a quale sede e quando. Quel registro costituisce una prova ai fini del requisito PCI-DSS 2.3.2 e delle verifiche dei diritti di accesso previste dal controllo 5.18 dell'Allegato A della norma ISO 27001. Purple possiede la certificazione ISO 27001 e Cyber Essentials e garantisce un uptime del 99,999% in oltre 80.000 sedi attive. Questo uptime è fondamentale quando RADIUS determina se il personale può lavorare.

Domande frequenti

Abbiamo bisogno di nuovi access point per migrare il WiFi del personale a 802.1X?

No. 802.1X e le chiavi per singolo dispositivo funzionano sugli access point già in vostro possesso. Purple Access è indipendente dall'hardware e funziona come overlay in cloud su Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. È sufficiente configurare un SSID Enterprise che punta al RADIUS in cloud di Purple, oltre a una rete con chiavi per singolo dispositivo utilizzando la funzionalità nativa del vendor. L'unico controllo fisico consiste nel verificare che ogni trunk dello switch trasporti le nuove VLAN.

Possiamo gestire contemporaneamente l'SSID con password condivisa e l'SSID 802.1X?

Sì, ed è consigliabile farlo, perché l'esecuzione di entrambi elimina la necessità di effettuare il passaggio durante il fine settimana. Laddove la piattaforma lo consenta, convertire l'SSID legacy nella rete iPSK. Mantenere la vecchia password come un'unica chiave su una VLAN limitata, in modo che i dispositivi continuino a funzionare durante il loro trasferimento. Eliminare tale chiave in ciascuna sede una volta che il relativo registro di autenticazione mostra che nessun dispositivo la utilizza da 14 giorni consecutivi.

Cosa succede ai dispositivi che non supportano 802.1X?

Vengono trasferiti sulla rete iPSK, ciascuno con la propria chiave. Cassa, terminali POS, stampanti, telecamere e lettori per digital signage raramente dispongono di un certificato, ma quasi tutti accettano una passphrase WPA2. Ogni chiave si associa a una VLAN per la propria classe di dispositivi, consentendo di revocare un singolo dispositivo senza toccare gli altri. Mantenere un registro di chi ha inserito ciascuna chiave, poiché la norma PCI-DSS 2.3.2 si applica comunque alle chiavi conosciute da chi lascia l'azienda.

Quanto tempo richiede una migrazione 802.1X multisito?

È opportuno pianificare da 10 a 14 settimane per 50 sedi e da 20 a 26 settimane per 200 sedi, per poi verificare tali stime durante la fase pilota. I dispositivi gestiti si muovono più velocemente perché l'MDM effettua il push a tutte le sedi contemporaneamente. I dispositivi headless dettano il ritmo, poiché alcuni richiedono un intervento in loco. Ogni sede necessita di almeno 14 giorni senza anomalie nel registro di autenticazione prima di poter disattivare la password condivisa.

L'implementazione di 802.1X rende il WiFi del personale conforme allo standard PCI-DSS?

Nessun singolo controllo garantisce la conformità da solo, e la valutazione finale spetta all'auditor. EAP-TLS e le chiavi per singolo dispositivo forniscono la documentazione probatoria per il requisito 2.3.2 di PCI-DSS v4.0.1. Una volta eliminata la chiave condivisa, l'uscita di un dipendente non costringe più a sostituire la chiave su tutta l'infrastruttura. Il registro di autenticazione mostra quale identità o chiave si è connessa a quale sede e quando, supportando anche le verifiche dei diritti di accesso previste dalla norma ISO 27001.

È opportuno utilizzare PEAP con password anziché i certificati?

Usa EAP-TLS ovunque possibile. PEAP-MSCHAPv2 rimuove la chiave condivisa ma si basa ancora sulle password. Tali password possono essere intercettate se un dispositivo non valida il certificato del server. Microsoft documenta inoltre che Windows Defender Credential Guard blocca il single sign-on MSCHAPv2 con credenziali salvate. Questo compromette il WiFi basato su password su molti laptop Windows gestiti. I certificati distribuiti dal tuo MDM evitano entrambi i problemi e non richiedono alcuna azione da parte del personale.

Abbiamo bisogno di server RADIUS on-premise per l'802.1X?

No. Purple Access fornisce RADIUS in cloud, quindi non c'è nulla da installare, aggiornare o rendere ridondante in ciascuna sede. I tuoi access point inviano le richieste di autenticazione a Purple. Purple verifica il certificato o la chiave, applica le regole di identità da Microsoft Entra ID, Okta o Google Workspace e restituisce la VLAN. Purple funziona con un uptime del 99,999% e possiede le certificazioni ISO 27001 e Cyber Essentials.

Il personale può utilizzare i telefoni personali sullo stesso SSID 802.1X?

Sì, se le tue policy lo consentono. Il personale si connette alla rete aperta, effettua l'accesso sul Captive Portal con la propria identità aziendale e riceve il profilo di rete sicuro. Un profilo Passpoint connette quindi automaticamente il telefono in ogni sede della struttura. Associa i telefoni personali a una VLAN per il personale con solo accesso a Internet, separata dai segmenti di pagamento e di back-office. Verifica nella fase pilota che la procedura di disattivazione degli ex dipendenti rimuova il loro accesso.