Configurazione firmata: perché il tag manager è un componente della supply chain e come Ed25519 lo tiene onesto

Il modello delle minacce

Tre cose possono andare storte con una configurazione consegnata ai browser:

1. Qualcuno con accesso legittimo consegna qualcosa di dannoso — un tag HTML personalizzato che esfiltra i dati dei form, uno script «temporaneo» che resta per anni.
2. Il percorso di distribuzione viene manomesso — un edge CDN compromesso, un proxy configurato male, un man-in-the-middle su una rete ostile.
3. Nessuno sa dire cosa è cambiato — la configurazione live si allontana da ciò che era stato revisionato.

I template dichiarativi chiudono la prima porta

Track non ha alcun tipo di tag HTML personalizzato o JavaScript personalizzato. Ogni azione lato browser è un template preso da un insieme fisso (pixel di Meta, tag Google, pixel di TikTok, UET, Insight Tag e così via) con parametri tipizzati: ID, mappature degli eventi, finalità del consenso. Un template non può contenere codice; seleziona un loader che l'SDK già include e compila gli identificatori. Il bundle di configurazione è costituito da dati, validati rispetto a uno schema sul server e di nuovo sul client. Non c'è eval, non c'è new Function, e nulla in un bundle può far scaricare all'SDK uno script da un URL che il template non conosce già.

È una rinuncia deliberata alla flessibilità. La guida alla migrazione elenca ciò che non ha un equivalente; la risposta è sempre «metti quella logica nel codice del sito, dove viene revisionata come codice».

La firma chiude la seconda

Quando una versione viene pubblicata, il server serializza il bundle in forma canonica, ne calcola il digest SHA-256 e firma i byte con una chiave privata Ed25519 che esiste solo sul servizio di pubblicazione. L'artefatto pubblicato è { payload, digest, keyId, algorithm, signature }.

L'SDK include le chiavi pubbliche per gli ID chiave del sito. Prima di applicare un bundle ricalcola il digest, lo confronta con quello firmato e verifica la firma con Web Crypto (SubtleCrypto.verify con Ed25519). Un bundle che non supera la verifica viene scartato e l'SDK mantiene l'ultimo bundle verificato dalla cache di sessione — oppure gira senza alcuna destinazione, piuttosto che con una configurazione non verificata.

La firma non sostituisce TLS; protegge da tutto ciò che TLS non copre, compreso un edge compromesso che serve JSON dall'aspetto valido su un certificato valido.

Il manifest

Il loader scarica prima un piccolo manifest: tracking ID, ambiente, versione, URL del bundle, digest, ID della chiave, timestamp di pubblicazione e il flag del kill switch. Il manifest viene scaricato sempre fresco; il bundle viene messo in cache nel session storage per versione e digest. È questo che permette a un kill switch o a un rollback di avere effetto alla visualizzazione di pagina successiva senza dover invalidare la cache del bundle stesso.

Il versionamento chiude la terza

Ogni pubblicazione crea una versione immutabile con un diff rispetto alla precedente, l'autore, l'approvazione che l'ha autorizzata e l'ID della richiesta. La cronologia delle versioni mostra esattamente cosa ricevono i visitatori, e il rollback ripubblica una versione precedente come nuova versione — firmata di nuovo, registrata di nuovo nell'audit log. Bozze e versioni pubblicate non condividono mai lo stesso storage, così «cosa è live» è un unico fatto, non lo stato di più interruttori.

Gestione delle chiavi

• Le chiavi di firma vengono generate per ambiente e non lasciano mai il servizio di pubblicazione; la chiave privata non viene mai memorizzata nel database.
• Gli ID delle chiavi permettono la rotazione: si aggiunge una nuova chiave, le nuove versioni vengono firmate con quella, la vecchia chiave pubblica resta valida per la verifica finché ogni sito non ha ripubblicato, poi viene ritirata.
• Il key_id su ogni manifest ti dice quale chiave ha firmato la configurazione live.

Cosa significa per la tua revisione di sicurezza

Puoi descrivere il tag manager a un team di sicurezza in un solo paragrafo: consegna dati firmati e validati rispetto a uno schema a un SDK fisso; non può eseguire codice scritto dal sito; ogni modifica è versionata, approvata e attribuibile; e una compromissione del percorso di distribuzione non può alterare il comportamento senza la chiave di firma. La pagina sulla sicurezza rimanda agli ID chiave correnti e al codice sorgente di verifica dell'SDK.