La difesa passiva non genera allarmi: aspetta. Un canary token è la sua forma più economica e più narrativa. Non devi configurare nulla di complesso, non devi installare agent, non devi aggiungere un componente che gira in produzione. Semplicemente semini qualcosa che non serve a nessuno e che, quindi, ha un solo motivo per essere toccato: la curiosità di qualcuno che non ha niente di legittimo da farci.
Un concetto più vecchio delle reti
L'idea non è nata nel 2010 con le piattaforme cloud. I cartografi del Settecento usavano la stessa astuzia: fake data mescolato a dati reali, città inesistenti tra nomi autentici, per smascherare chi copiava le mappe senza licenza. Chi copiava tutto, senza scegliere, si portava dietro anche le città inventate. Il copione era identico: fai in modo che il furto produca una traccia.
Lo stesso passaggio logico compare nella sicurezza informatica ben prima dei canary token "di prodotto". Nel 1986 Cliff Stoll descrive la caccia a un intruso che entrava nei sistemi del Los Alamos per rubare programmi militari, ricostruita incrociando il conteggio dei job di stampa e i costi di telecomunicazione. Nel 1991 Eugene Spafford racconta di intrusioni sulle sue stazioni Sun che non avevano attivato nessun allarme esistente, e che si erano concluse con una backdoor installata in modo da sembrare intatta. Sono due storie che portano alla stessa conclusione operativa: il rilevamento non è un accessorio, è il prodotto.
Honeytoken: dalla rete all'oggetto
Il termine honeypot si consolida negli anni '90 con i sistemi che simulano servizi reali per attirare e osservare. Ma un honeypot costa: va mantenuto, va patchato, e soprattutto non deve mai essere confuso con un sistema vero o diventa un vettore d'attacco. Il honeytoken risolve il problema alla radice: invece di simulare un servizio, simula un dato. Una chiave API finta, un account AD inesistente, un bucket vuoto, un indirizzo email che nessuno conosce. Nessuna superficie da mantenere, perché non c'è nulla che funzioni: c'è solo qualcosa che scotta.
Su cloud la meccanica è quasi gratuita. Un bucket S3 con un nome che sembra
contenere i backup, con un oggetto di 2 KB che promette un dump del database:
l'attaccante che lo trova prova a scaricarlo, l'oggetto chiama il tuo endpoint,
tu ricevi l'IP e l'user-agent in tempo reale. Lo stesso vale per un token
AWS "usa solo per il test" che non ha policy ma che qualcuno proverà lo stesso
a usare, ricevendo InvalidClientTokenId — e quella chiamata, da sola, è già
l'allarme.
Il punto cieco: il canario che nessuno guarda
Un canary token che genera traffico che nessuno monitora equivale a un honeypot che nessuno guarda. È il difetto più comune di questa tecnica, ed è la ragione per cui i token "usa e getta" diventano fastidio operativo invece che strumento. Tre requisiti per non sprecarli:
La raccolta è integrata in un canale che esiste già. Slack, PagerDuty, l'email del SOC. Se l'alerta arriva in una casella che nessuno apre, il canario è sprecato.
Il contesto è scritto al momento della creazione. Un token piazzato tra sei mesi in un bucket di test, quando scatterà, dovrà essere riconosciuto.
Si ruota e si rimuove. Un token dimenticato in un repository pubblico diventa rumore: gli scanner lo-indicano e l'alerta si attenua da sola.
Il valore di un canary token non è la trappola: è la certezza che nessun accesso legittimo lo toccherà. È un segnale a costo quasi nullo, e come segnale va trattato.
Canarytokens.org
Dal 2015 Thinkst ha messo a disposizione canarytokens.org, un servizio gratuito
e self-hostable che genera token di molti tipi — file, URL, credenziali,
indirizzi email, wallet bitcoin, silenziosamente monitorati dal servizio. Il
punto interessante è che l'attaccante non ha motivo di sospettare: il file si
chiama backup_credentials.docx, l'email sembra una casella di reparto, il
wallet ha un saldo. Sono ancora credibili nel 2026, e questa è la parte
difficile: la credibilità di un'esca dipende da quanto il mondo dell'attaccante
è simile a quello in cui è stato creato.
Cosa cambia con Nuxt (e cosa no)
I token non hanno a che fare con il frontend. Ma un motore di news in Nuxt
porta con sé una novità utile: il rendering statico e il prefetch dei link
generano richieste reali da parte di utenti reali. Ogni richiesta verso un
path inesistente è un segnale — e un percorso /news/che-non-esiste visitato
da un utente autenticato della vostra VPN è esattamente il tipo di cosa che un
canary token cerca di catturare.