Logo

Whitepaper su sicurezza e privacy (panoramica)Capitolo 10

Capitolo 10: Logging, monitoraggio e risposta agli incidenti

L'osservabilità di FileBolt deve rispettare i confini dello zero-knowledge: il sistema deve individuare i guasti, rilevare gli attacchi e quantificare le prestazioni senza introdurre nuovi vettori di fuga di dati sensibili. Questo capitolo definisce quali eventi vengono registrati, vieta esplicitamente di registrare determinate informazioni, descrive i metodi di allerta e di rilevamento delle anomalie e illustra nel dettaglio il processo di risposta agli incidenti di sicurezza (IR) e i principi della comunicazione esterna.

10.0 Riepilogo

  • DOVREBBE: log e monitoraggio coprono solo gli eventi operativi e di sicurezza necessari, usando aggregazione e campionamento per ridurre al minimo la conservazione dei dettagli grezzi.
  • NON DEVE: nessun log, APM o report di errore deve contenere la CEK, i frammenti degli URL (location.hash) o URL completi che contengono frammenti.
  • NON DEVE: non registrare contenuti in chiaro, blocchi decifrati o materiale da cui si possano derivare le chiavi.
  • DEVE: predisporre rilevamento e allerta per enumerazione, brute force, picchi di traffico e schemi anomali, con misure di contenimento già pronte.
  • DEVE: mantenere un processo di risposta agli incidenti (triage, contenimento, analisi forense, rimedio, revisione, comunicazione).

10.1 Eventi registrati (minimalismo)

I log di sistema e il monitoraggio DOVREBBERO coprire solo l'insieme di eventi «necessari per l'operatività e la sicurezza», evitando di inserire contenuti degli utenti o credenziali sensibili nei sistemi di osservabilità. Gli eventi sono suddivisi in ciclo di vita, autenticazione, archiviazione/rete e protezione della sicurezza; si raccomanda l'aggregazione.

10.1.1 Eventi del ciclo di vita del trasferimento

  • Creazione del trasferimento (generazione del transferId)
  • Completamento del caricamento di un blocco (registrato a livello di dati cifrati, non in chiaro)
  • Scrittura/aggiornamento del manifest
  • Pulizia alla scadenza, eliminazione/revoca da parte dell'utente (compresi l'avvio e il completamento dell'attività di pulizia)
  • Inizio/completamento del download (misurato a livello di download dei dati cifrati)

10.1.2 Eventi di autenticazione e autorizzazione

  • Emissione dei token di sessione, errori di convalida (scope non corrispondente, scaduto, revocato e così via)
  • Errore di convalida del token di accesso a lungo termine (azione amministrativa negata)
  • Schemi di accesso sospetti: picchi anomali di 401/403/404

Nota: registra solo il «risultato e il codice del motivo». NON DEVE essere registrato il testo in chiaro dei token, dell'intestazione Authorization o dei parametri di firma.

10.1.3 Metriche di stato e prestazioni del sistema

  • Latenza delle richieste (p50/p95/p99), tassi di errore, throughput
  • Tassi di errore di lettura/scrittura dell'archiviazione di oggetti, tassi di errore nel recupero dall'origine, numero di nuovi tentativi
  • Anomalie dei nodi edge, code accumulate, tassi di successo delle attività di pulizia in background
  • Andamento di banda e traffico (dimensioni aggregate)

10.1.4 Eventi di protezione della sicurezza

  • Attivazioni del rate limiting, regole WAF/firewall scattate
  • Superamenti di soglia per comportamenti sospetti di enumerazione/brute force
  • Schemi anomali di concorrenza e traffico (alta concorrenza dalla stessa origine, picchi anomali su singole risorse)

10.1.5 Aggregazione e campionamento

  • DOVREBBE: aggregare per minuto/ora i conteggi e i quantili di latenza, per ridurre i log di dettaglio.
  • DOVREBBE: campionare le richieste riuscite ad alta frequenza, conservando i dettagli necessari solo per errori e percorsi anomali.
  • DOVREBBE: mantenere campi di classificazione stabili (ad esempio eventType, reasonCode) per gli eventi anomali, per agevolare l'audit e l'analisi automatica.

10.2 Informazioni vietate (CEK, frammento, credenziali)

Un elemento chiave per mantenere l'impegno zero-knowledge è applicare con rigore una politica di «divieto dei dati sensibili» in tutti i sistemi di osservabilità. Questa politica deve coprire: log del server, APM, segnalazione degli errori, monitoraggio di terze parti, log del client e output della console del browser.

10.2.1 Lato server: cosa NON DEVE essere registrato

  • La CEK (Content Encryption Key, chiave di cifratura del contenuto) e qualsiasi materiale da cui sia possibile derivarla
  • Il frammento dell'URL (#...), location.hash e gli URL completi che contengono frammenti
  • Contenuti in chiaro: il contenuto in chiaro dei file, i contenuti delle anteprime, i blocchi decifrati o qualsiasi riepilogo in chiaro
  • Testo in chiaro delle credenziali sensibili: token di sessione, token a lungo termine, testo in chiaro dell'intestazione Authorization, testo in chiaro dei campi di firma negli URL firmati

Se per il debug è necessario registrare gli URL: DEVE essere eseguita la sanitizzazione (rimozione del frammento; oscuramento o rimozione delle query sensibili) e applicata a livello di codice (senza affidarsi a convenzioni manuali).

10.2.2 Lato client: cosa NON DEVE essere registrato

  • Non stampare location.href (può contenere frammenti) negli ambienti di produzione
  • Non includere nei report di errore URL con frammenti, la CEK o il noncePrefix
  • I log di debug e gli output degli strumenti per sviluppatori dovrebbero essere disattivati o ridotti al minimo per impostazione predefinita

DOVREBBE: incapsulare nel frontend una funzione unificata di log/report che esegua al suo interno la sanitizzazione degli URL e il filtraggio dei campi sensibili prima di scrivere o inviare i dati.

10.3 Metriche di monitoraggio e allerte (disponibilità, prestazioni, sicurezza)

10.3.1 Allerte su disponibilità e prestazioni

  • Allerte sul tasso di errore: picchi di 5xx, aumento anomalo di 4xx (distinguere i fallimenti di autenticazione dagli abusi)
  • Allerte sulla latenza: superamento delle soglie p95/p99, anomalie regionali nel recupero dall'origine
  • Allerte sull'archiviazione: aumento dei fallimenti di scrittura e dei timeout di lettura dell'archiviazione di oggetti
  • Allerte sulle attività di pulizia: accumulo di pulizie alla scadenza, troppi nuovi tentativi nelle attività di eliminazione

10.3.2 Allerte di sicurezza

  • Aumento anomalo della frequenza di attivazione del rate limiting
  • Alta frequenza di 401/403/404 dalla stessa origine, sospetta enumerazione/brute force
  • Banda/concorrenza di download anomala su una singola risorsa, sospetto flooding di traffico o hotlinking
  • Le modifiche critiche alle politiche (ad esempio regole WAF, modifiche a CSP/intestazioni) dovrebbero far scattare audit delle modifiche e allerte (se applicabile)

10.3.3 Governance delle allerte

  • DOVREBBE: classificare le allerte (P0/P1/P2) con percorsi di turnazione/escalation.
  • DOVREBBE: applicare debounce/aggregazione a finestre alle metriche rumorose, per evitare l'affaticamento da allerte.
  • DOVREBBE: allegare a ogni allerta le informazioni diagnostiche minime (codice del motivo, grafico dell'andamento, regione/percorso interessato), senza dati sensibili.

10.4 Rilevamento delle anomalie e individuazione degli abusi

I servizi di trasferimento file sono per natura esposti a rischi di enumerazione, brute force, flooding di traffico e abuso di risorse. Questa sezione descrive i segnali rilevabili e i principi di risposta. Soglie e strategie specifiche devono essere adeguate in modo dinamico in base alla scala dell'attività e al costo dei falsi positivi.

10.4.1 Schemi di anomalia più comuni

  • Enumerazione: sondaggio massiccio di transferId / percorsi di risorse in poco tempo, picchi di 404/401/403.
  • Brute force: tentativi ad alta frequenza su codici brevi/password/token, curva anomala del tasso di errore.
  • Flooding di traffico: banda anomala su una singola risorsa, moltissime connessioni simultanee dalla stessa origine, download ripetuti.
  • Anomalie di protocollo: ordine dei blocchi illogico, caricamenti duplicati, interruzioni/nuovi tentativi frequenti, schemi anomali negli user agent.

10.4.2 Strategie di mitigazione (principi)

  • DOVREBBE: rate limiting, blocchi a più livelli, meccanismi di verifica (se applicabile), politiche dinamiche basate su ASN/regione/fingerprint.
  • DOVREBBE: adottare strategie più morbide (ad esempio ritardo, limitazione a segmenti) per i percorsi sensibili ai falsi positivi (gli utenti normali possono scaricare spesso).
  • DEVE: conservare i fattori scatenanti verificabili (codice del motivo, categoria della soglia) per le azioni intraprese e mettere a disposizione canali di assistenza (se applicabile).

10.5 Processo di risposta agli incidenti

FileBolt DEVE stabilire un processo di risposta agli incidenti di sicurezza (IR) per garantire un rapido contenimento dei danni, la possibilità di revisione e una comunicazione trasparente. Gli eventi che possono compromettere gli impegni zero-knowledge (ad esempio XSS, supply chain injection, fuga di frammenti nei log) dovrebbero essere trattati con la massima priorità.

  1. Triage: classificare in base all'ambito dell'impatto e alla gravità (ad esempio P0/P1/P2), definire percorsi di escalation e responsabili.
  2. Contenimento: isolare rapidamente le fonti di rischio (bloccare le origini dell'attacco, disattivare temporaneamente funzioni, rafforzare le politiche, ruotare chiavi/token).
  3. Analisi forense e revisione: ricostruire la cronologia a partire da log e metriche minimi; documentare decisioni, impatto, rimedi e miglioramenti.
  4. Rimedio e verifica: rilasciare le patch, eseguire test di regressione e verifiche di sicurezza e, se necessario, ripetere le scansioni di terze parti.
  5. Comunicazione e divulgazione: spiegare in modo trasparente agli utenti e al pubblico, senza ampliare la superficie di attacco; se necessario, pubblicare report sugli incidenti nella pagina di stato.

La comunicazione esterna dovrebbe chiarire: se materiale di chiavi o contenuti in chiaro sono stati potenzialmente esposti, l'ambito dell'impatto, le misure adottate e le azioni che gli utenti devono eventualmente intraprendere.

10.6 Conservazione dei dati e controllo degli accessi

I log e i dati di monitoraggio sono a loro volta risorse sensibili. Per ridurre al minimo i rischi di fuga di dati e di abuso, dovrebbero essere applicati i periodi di conservazione utili più brevi possibili e un controllo degli accessi basato sul privilegio minimo.

  • DOVREBBE: stabilire periodi di conservazione differenziati per tipo di log (un po' più lunghi per errori ed eventi di sicurezza, più brevi o nulli per i dettagli delle richieste riuscite).
  • DOVREBBE: usare l'accesso con privilegio minimo (RBAC) per le piattaforme di log e monitoraggio e conservare gli audit degli accessi.
  • DOVREBBE: eseguire sanitizzazione e minimizzazione quando si esportano o condividono i log (vietando di includere credenziali sensibili e dati personali).

10.7 Principi per il monitoraggio e le integrazioni di terze parti

Gli strumenti APM/di tracciamento degli errori di terze parti possono raccogliere per impostazione predefinita URL, intestazioni, campi dei moduli e informazioni sul dispositivo. Se si usa un monitoraggio di terze parti, bisogna assicurarsi che i suoi confini di raccolta non violino gli impegni zero-knowledge.

  • DEVE: non caricare script di terze parti nelle pagine di download/decifratura (in coerenza con il capitolo 9).
  • DEVE: configurare in modo esplicito la raccolta di terze parti: nessun frammento, nessun testo in chiaro di intestazioni sensibili, nessun contenuto in chiaro.
  • DOVREBBE: unificare la sanitizzazione degli URL nei report; vietare o mascherare con forza i payload che potrebbero contenere campi sensibili.
  • DOVREBBE: privilegiare le metriche aggregate lato server rispetto al tracciamento di dettaglio lato client, per ridurre la superficie di raccolta sugli endpoint.

10.8 ID delle affermazioni correlati (riservato)

Questo capitolo tratta «il divieto di registrare dati sensibili, le allerte e l'IR, i vincoli sul monitoraggio di terze parti». Gli ID delle affermazioni corrispondenti verranno aggiunti all' Appendice: elenco principale degli ID delle affermazioni, che ne è l'unica fonte autorevole.