Dal default-deny delle whitelist al default-allow delle blacklist, passando per le greylist: guida pratica a pro, contro e implementazione del controllo degli accessi.

Che cos'è lo spettro del controllo degli accessi?

Lo spettro del controllo degli accessi si estende tra due estremi opposti: da una parte il default-deny, dove tutto è bloccato a meno che non venga autorizzato esplicitamente, dall'altra il default-allow, dove invece tutto è permesso tranne ciò che viene bloccato di proposito. Whitelist e blacklist incarnano proprio questi due poli, come sottolinea Binadox in un'analisi del settembre 2024. Instasafe, dal canto suo, nel febbraio 2024 descrive le whitelist come modello default-deny e le blacklist come modello default-allow. In mezzo ai due estremi troviamo soluzioni intermedie, come le greylist, che mettono in quarantena le fonti sospette prima di assegnarle a una categoria.

A ben guardare, però, questo spettro non va letto come una scelta secca tra due opzioni: è piuttosto un continuum. Più ti sposti verso il default-deny, più il controllo è rigoroso, ma anche più pesante da gestire; al contrario, più vai verso il default-allow, più l'implementazione risulta semplice, ma la protezione diventa di fatto reattiva. E chi si informa su whitelist e blacklist, cosa cerca in fondo? Vuole capirne le definizioni, le differenze, i pro e i contro, i passaggi pratici per implementarle e qualche esempio concreto che tocchi la sicurezza applicativa, il filtraggio delle email, l'accesso alla rete e i controlli parentali. È esattamente quello che faremo qui, seguendo un approccio comparativo.

Spesso si tende a sovrapporre questo concetto a quello di difesa a strati, la cosiddetta defense-in-depth: in realtà whitelist, blacklist e greylist non si escludono a vicenda, anzi possono convivere tranquillamente nello stesso sistema. Prendiamo un firewall: può usare una blacklist per bloccare indirizzi IP già noti come malevoli, e allo stesso tempo una whitelist per dare via libera solo al traffico verso i servizi critici. Stessa logica per un gateway di posta elettronica, che potrebbe applicare una greylist ai mittenti sconosciuti e una whitelist ai domini partner già verificati. Insomma, capire questo spettro significa saper scegliere lo strumento più adatto in base al livello di rischio e al controllo che vogliamo ottenere.

Come funziona una whitelist?

Una whitelist — detta anche allowlist o lista di approvazione — adotta una strategia di inclusione: si stabilisce in anticipo cosa è ammesso (indirizzi IP, applicazioni, utenti, domini) e tutto il resto viene bloccato per impostazione predefinita. In pratica si procede così: prima si individuano le entità autorizzate in base alle politiche di sicurezza, poi si mette insieme la lista vera e propria, infine la si integra nei sistemi attraverso configurazioni e regole. Il risultato è un modello proattivo, in cui niente passa senza un'approvazione esplicita.

Il punto di forza è senza dubbio la sicurezza: tutto ciò che non è esplicitamente approvato resta fuori, quindi le minacce sconosciute vengono bloccate per default e il rischio di accessi non autorizzati si riduce parecchio. C'è anche un lato pratico che spesso si sottovaluta, cioè che gestire una whitelist è più semplice che inseguire una blacklist esaustiva: le liste sono più piccole, più definite, e questo fa la differenza nel lavoro quotidiano. Poi però arriva il rovescio della medaglia, ed è la rigidità. Implementare una whitelist completa è tutt'altro che banale, la mancanza di flessibilità può rallentare le attività, e c'è un dettaglio che non va mai dimenticato: se un'entità autorizzata viene compromessa, mantiene comunque i suoi privilegi di accesso. Su questi limiti vale la pena tornare a leggere il NIST SP 800-167, la guida all'application whitelisting pubblicata nel 2015, che resta ancora oggi un riferimento tecnico piuttosto solido.

Le whitelist, però, richiedono un monitoraggio rigoroso di asset e utenti: ogni nuova risorsa va autorizzata manualmente, e questo le rende più impegnative da gestire rispetto a una semplice lista di blocco. Basti pensare a un amministratore IT che aggiunge un dominio non autenticato all'allowlist di un gateway di posta — rischia di aprire la porta allo spoofing. Del resto, l'inserimento in whitelist protegge solo il mittente nominato, e solo per quel determinato sistema destinatario. Ecco perché le whitelist danno il meglio di sé in ambienti stabili e controllati, dove le entità legittime sono poche e ben note: server critici, applicazioni aziendali, o magari i dispositivi di un reparto specifico.

Come funziona una blacklist?

La blacklist — detta anche blocklist o denylist — segue la logica inversa, quella dell'esclusione: si stilano gli attori considerati pericolosi e tutto il resto passa, salvo poi essere bloccato solo se compare nella lista. Partire è abbastanza facile: basta individuare i soggetti malevoli già noti e inserirli in firewall, filtri antispam e antivirus, che a quel punto scartano in automatico il traffico corrispondente. Il problema è che la lista va aggiornata di continuo, perché le minacce cambiano forma in fretta e una blacklist ferma a ieri rischia di lasciar passare proprio ciò che dovrebbe fermare.

Il modello, di per sé, è reattivo: ti difende da ciò che è già stato identificato, non certo da minacce zero-day o attacchi mirati. C'è poi un altro problema, e cioè che una blacklist troppo aggressiva rischia di bloccare per errore fonti legittime, magari segnalate come non sicure senza un vero motivo: il risultato sono falsi positivi che arrivano con una certa frequenza. SiteGround, in una nota di settembre 2026, lo dice chiaramente: basta una sola segnalazione su una blocklist importante come Spamhaus per compromettere la deliverability verso migliaia di caselle di posta nello stesso momento. È proprio questo l'effetto asimmetrico tipico delle blacklist: finire in lista danneggia tutti quelli che consultano quella lista, non solo chi è stato segnalato.

Certo, la blacklist ha dei limiti evidenti, eppure resta lo strumento più usato proprio perché è semplice da gestire: di base lascia passare quasi tutto, pesa poco sulle risorse e si innesta senza troppe complicazioni nei sistemi già in funzione. Il problema vero è che la copertura non è mai completa, e basta una singola voce dimenticata per spalancare la porta a una violazione. Per questo molti team la trattano come primo strato difensivo, affiancandola a whitelist e greylist nei contesti più delicati, quelli in cui un accesso non autorizzato costa davvero caro.

Che cos'è una greylist e dove si colloca?

La greylist rappresenta la via di mezzo all'interno dello spettro del controllo degli accessi. In pratica, mette in quarantena temporanea le fonti sconosciute o sospette, le esamina con calma e solo in un secondo momento decide se promuoverle a whitelist o retrocederle a blacklist. Il default, quindi, non è né il permesso né il blocco definitivo: è la sospensione. Mutant Mail parla a questo proposito di filtraggio adattivo, cioè un meccanismo in cui la fonte resta in una sorta di limbo finché non viene analizzata, dopodiché riceve una decisione di accesso definitiva.

Nel filtraggio delle email, la greylisting si rivela particolarmente utile contro lo spam di massa. Il motivo è semplice: molti sistemi di invio automatico non ritentano la consegna dopo un rifiuto temporaneo. In pratica, quando arriva un messaggio da un mittente sconosciuto, questo viene respinto in via provvisoria; se chi lo ha inviato è legittimo, di solito ritenta e a quel punto viene ammesso, mentre uno spammer tende a desistere. Così si alleggerisce il carico sui filtri senza escludere in modo definitivo fonti che potrebbero essere valide.

La greylist introduce però un ritardo nella consegna, che può essere accettabile per la posta ma non per applicazioni in tempo reale. In sintesi, mentre la whitelist dice «nega tutto tranne ciò che approvo» e la blacklist dice «permetti tutto tranne ciò che blocco», la greylist dice «sospendi finché non ho abbastanza informazioni». È la scelta giusta quando il rischio è incerto e si vuole evitare sia il blocco indiscriminato sia il permesso automatico.

Whitelist vs blacklist: pro e contro a confronto

Il confronto testa a testa tra whitelist e blacklist, sintetizzato da WhitelistVideo, chiarisce bene le differenze operative. La tabella seguente riassume i parametri principali: stato predefinito, modello di sicurezza, comportamento verso i contenuti nuovi, rischio di bypass, sforzo richiesto, falsi positivi e negativi, rischio algoritmico e pubblico più adatto.

ParametroWhitelistBlacklist
Stato predefinitoBloccatoPermesso
Modello di sicurezzaProattivoReattivo
Contenuti nuoviBloccati fino ad approvazioneAperti fino a segnalazione
Rischio di bypassMolto bassoAlto (VPN, navigazione anonima)
Sforzo del genitore o adminModerato (curatela)Basso (imposta e dimentica)
Falsi positiviNessunoComuni
Falsi negativiImpossibiliComuni
Pubblico idealeBambini piccoli e ambienti safety-firstAdolescenti più grandi

I pro della whitelist sono sicurezza elevata, blocco delle minacce sconosciute per default, gestione più semplice di una blacklist esaustiva e minore rischio di accessi non autorizzati. I contro: difficile da implementare completamente, poco flessibile, potenzialmente penalizzante per la produttività se troppo restrittiva, e le entità autorizzate mantengono l'accesso anche se compromesse. I pro della blacklist sono la facilità di implementazione iniziale, il permesso della maggior parte delle azioni e il basso consumo di risorse. I contro: è reattiva, non protegge da minacce sconosciute e una singola dimenticanza può causare una violazione.

Whitelist e blacklist nella sicurezza applicativa

Nella sicurezza applicativa le whitelist sono alla base dei modelli zero trust: solo le applicazioni, i processi e gli indirizzi esplicitamente approvati possono essere eseguiti o comunicare. La guida NIST SP 800-167 del 2015 resta il riferimento per l'application whitelisting, utile a prevenire l'esecuzione di malware non firmato. Le blacklist, dal canto loro, sono integrate in firewall, antivirus e sistemi di rilevamento intrusioni per bloccare firme note di attacchi.

Nel networking, la documentazione Huawei sulle WLAN STA blacklist e whitelist mostra come gli stessi concetti si applichino alla gestione degli accessi wireless: una blacklist impedisce a determinati client di associarsi, una whitelist autorizza solo dispositivi specifici. Nel filtraggio email, la whitelist di un dominio richiede prima l'autenticazione SPF e DKIM, oltre alla registrazione dell'IP mittente su Microsoft SNDS e al monitoraggio della reputazione con Gmail Postmaster Tools.

Il controllo parentale è un caso di studio illuminante: un tipico setup con whitelist approva circa 50 canali e blocca tutti gli altri sulla piattaforma, come spiega WhitelistVideo. Con oltre 500 ore di video caricate ogni minuto su YouTube, pari a 720.000 ore di nuovi contenuti al giorno, la blacklist è impraticabile per un genitore. Le app basate su blacklist come Bark, Qustodio e Net Nanny funzionano meglio con adolescenti più grandi, mentre la whitelist è preferibile per bambini piccoli e famiglie attente alla sicurezza.

Esiste anche una curiosità terminologica: Spectrum Control, azienda di componenti RF/EMI fondata nel 1963, ha più di 70 anni di esperienza, 20 linee di prodotto, 1.100 dipendenti e 13 sedi, e ha assorbito oltre 40 aziende o linee di prodotto. Non ha nulla a che vedere con il controllo degli accessi, ma il nome ricorre spesso nelle ricerche su «spectrum control». Un'omonimia da tenere presente per non confondere i due ambiti.

Come implementare whitelist e blacklist in pratica

L'implementazione di una whitelist segue tre passaggi: definire le entità approvate in base alle politiche di sicurezza, compilare la lista e integrarla nei sistemi tramite configurazione. Quella di una blacklist ne segue due: enumerare gli attori pericolosi noti e integrarli negli strumenti di sicurezza perché blocchino automaticamente il traffico corrispondente. In entrambi i casi serve un processo di revisione periodica, perché liste obsolete diventano un rischio.

Per l'email, il percorso di whitelisting di un dominio parte dall'autenticazione: configurare SPF e DKIM, registrare l'IP mittente su Microsoft SNDS, monitorare la reputazione con Gmail Postmaster Tools e solo dopo richiedere l'inserimento in whitelist. Per il controllo parentale, il flusso è: scegliere i canali validi, lasciare che l'app blocchi tutto il resto, far richiedere al bambino nuovi contenuti e approvare o negare la richiesta. La tabella seguente riassume i passaggi chiave per contesto.

ContestoPassaggi principali
Whitelist applicativaDefinire entità approvate, compilare la lista, integrare nei sistemi
Blacklist di reteEnumerare attori pericolosi, integrare in firewall e filtri
Whitelist emailSPF e DKIM, registrazione IP su SNDS, monitoraggio Postmaster Tools
Controllo parentaleApprovare canali, bloccare il resto, gestire le richieste dei figli

La scelta tra i due approcci dipende dal contesto: la whitelist è preferibile dove il numero di entità legittime è piccolo e stabile, la blacklist dove serve una copertura ampia con poco sforzo iniziale. In molti sistemi la soluzione migliore è ibrida: blacklist per il traffico generale, whitelist per le risorse critiche e greylist per le fonti ambigue. Questo approccio a strati riduce sia i falsi positivi sia il rischio di minacce sconosciute.

Rischi e limiti di whitelist e blacklist

Le blacklist non possono difendere da minacce zero-day o attacchi mirati, perché per definizione bloccano solo ciò che è già noto. Gli strumenti troppo aggressivi possono inoltre bloccare fonti legittime erroneamente segnalate come non sicure, con impatti concreti sulla deliverability: una singola voce su una blocklist importante come Spamhaus può danneggiare migliaia di caselle di posta in una volta.

Le whitelist richiedono un monitoraggio rigoroso di asset e utenti e non eliminano il rischio interno: un'entità autorizzata ma compromessa conserva l'accesso. Aggiungere un dominio non autenticato a un allowlist di un gateway di posta è un errore frequente che espone al spoofing. Inoltre, l'inserimento in whitelist aiuta solo il mittente nominato e solo per il sistema destinatario che lo ha autorizzato.

La conclusione operativa è che nessun approccio è sufficiente da solo. La combinazione di default-deny per le risorse critiche, blacklist aggiornate per le minacce note e greylist per le fonti incerte offre la copertura più equilibrata. La chiave è la revisione periodica: liste non aggiornate, in entrambe le direzioni, diventano rapidamente un punto debole. Questo articolo ha scopo informativo e non costituisce consulenza in materia di sicurezza o investimenti.

Domande frequenti su whitelist e blacklist

Qual è la differenza tra una whitelist e una blacklist?

Una whitelist definisce le entità approvate a cui è consentito l'accesso, seguendo un approccio default-deny in cui tutto è bloccato salvo autorizzazione esplicita. Una blacklist definisce le entità proibite a cui l'accesso è negato, seguendo un approccio default-allow in cui tutto è permesso salvo blocco specifico. Rappresentano le due estremità opposte dello spettro del controllo degli accessi.

Che cos'è una greylist e in cosa differisce da whitelist e blacklist?

Una greylist offre una via intermedia, mettendo temporaneamente in quarantena le fonti sospette o sconosciute. Dopo la revisione, le fonti passano alla whitelist o alla blacklist. Il default delle greylist è la quarantena preventiva, che consente un'indagine prima della decisione finale di accesso, evitando sia il blocco indiscriminato sia il permesso automatico.

Quali sono i pro e i contro del whitelisting?

Il whitelisting è molto sicuro, blocca le minacce sconosciute per default e riduce il rischio di accessi non autorizzati. Tuttavia può essere difficile da implementare completamente, manca di flessibilità ai cambiamenti, può penalizzare la produttività se troppo restrittivo e le entità autorizzate mantengono l'accesso anche se compromesse.

Quali sono i pro e i contro del blacklisting?

Il blacklisting è facile da implementare inizialmente bloccando gli attori malevoli noti e permette la maggior parte delle azioni per default. Tuttavia è reattivo, richiede aggiornamenti costanti, non difende da minacce sconosciute e una singola voce mancante può portare a una violazione della sicurezza.