Logo

Whitepaper su sicurezza e privacy (panoramica)Capitolo 10

Capitolo 10: Registrazione, monitoraggio e risposta agli incidenti

L'osservabilità di FileBolt deve allinearsi ai limiti della Zero-Knowledge: il sistema deve identificare 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, proibisce esplicitamente la registrazione di determinate informazioni, delinea metodi di avviso e rilevamento di anomalie, e descrive in dettaglio il processo di risposta agli incidenti di sicurezza (IR) e i principi di comunicazione esterna.

10.0 Riepilogo

  • SHOULD: I registri e il monitoraggio coprono solo gli eventi operativi e di sicurezza necessari, utilizzando l'aggregazione e il campionamento per ridurre al minimo la conservazione dei dettagli grezzi.
  • NON DEVE: eventuali log, APM o segnalazioni di errori non devono contenere CEK, frammenti di URL (location.hash) o URL completi contenenti frammenti.
  • NON DEVE: non registrare contenuti in testo normale, parti decrittografate o materiale chiave derivabile.
  • MUST: Stabilire il rilevamento e l'allarme per enumerazione, forza bruta, picchi di traffico e modelli anomali, con misure di contenimento in atto.
  • MUST: Mantenere un processo di risposta agli incidenti (triage, contenimento, analisi forense, bonifica, revisione, comunicazione).

10.1 Eventi registrati (minimalismo)

I registri di sistema e il monitoraggio DOVREBBERO coprire solo l'insieme di eventi "necessari per le operazioni e la sicurezza", evitando l'inserimento di contenuti utente o credenziali sensibili nei sistemi di osservabilità. Gli eventi sono classificati in Ciclo di vita, Autenticazione, Archiviazione/Rete e Protezione della sicurezza, con l'aggregazione consigliata.

10.1.1 Trasferimento di eventi del ciclo di vita

  • Crea trasferimento (genera transferId)
  • Caricamento pezzo completato (registrato a livello di testo cifrato, non di testo in chiaro)
  • Scrittura/aggiornamento manifest
  • Pulizia della scadenza, eliminazione/revoca dell'utente (inclusi l'attivazione e il completamento dell'attività di pulizia)
  • Inizio/completamento download (misurato a livello di download del testo cifrato)

10.1.2 Eventi di autenticazione ed autorizzazione

  • Emissione di token di sessione, errore di convalida (mancata corrispondenza dell'ambito, scaduto, revocato, ecc.)
  • Errore di convalida del token di accesso a lungo termine (azione amministrativa negata)
  • Modelli di accesso sospetti: picchi anomali in 401/403/404

Nota: registrare solo il "codice risultato e motivo". NON DEVE testo in chiaro del token di registrazione, testo in chiaro dell'intestazione di autorizzazione o testo in chiaro del parametro della firma.

10.1.3 Metriche sullo stato e sulle prestazioni del sistema

  • Latenza della richiesta (p50/p95/p99), tassi di errore, velocità effettiva
  • Tassi di errori di lettura/scrittura dell'archiviazione di oggetti, tassi di errori di recupero dell'origine, numero di tentativi
  • Anomalie dei nodi edge, arretrati di code, percentuali di successo delle attività di pulizia in background
  • Tendenze della larghezza di banda e del traffico (dimensioni aggregate)

10.1.4 Eventi di protezione della sicurezza

  • Trigger di limitazione della velocità, riscontri delle regole WAF/firewall
  • Trigger di soglia per sospetta enumerazione/comportamento di forza bruta
  • Concorrenza e modelli di traffico anomali (concorrenza elevata dalla stessa origine, calore anomalo delle risorse)

10.1.5 Aggregazione e campionamento

  • SHOULD: conteggi aggregati e quantili di latenza per minuto/ora per ridurre i log granulari.
  • SHOULD: campiona le richieste riuscite ad alta frequenza, conservando i dettagli necessari solo per errori e percorsi anomali.
  • SHOULD: Mantieni campi di classificazione stabili (ad esempio, eventType, ReasonCode) per eventi anomali per facilitare il controllo e l'analisi della macchina.

10.2 Informazioni vietate (CEK, frammento, credenziali)

Una chiave per mantenere l’impegno Zero-Knowledge è applicare rigorosamente una politica di “divieto dei dati sensibili” in tutti i sistemi di osservabilità. Questa policy 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 Il lato server NON DEVE registrare

  • CEK (Chiave di crittografia del contenuto) e qualsiasi materiale derivabile
  • Frammento dell'URL (#...), location.hashe URL completi contenenti frammenti
  • Contenuto in testo normale: file di testo in chiaro, anteprima del contenuto, blocchi decrittografati o qualsiasi riepilogo di testo in chiaro
  • Testo in chiaro delle credenziali sensibili: token di sessione, token a lungo termine, testo in chiaro dell'intestazione di autorizzazione, testo in chiaro del campo della firma negli URL firmati

Se la registrazione degli URL è necessaria per il debug: MUST disinfettare (rimuovere il frammento; oscurare o rimuovere query sensibili) e applicarlo a livello di codice (senza fare affidamento sulla convenzione manuale).

10.2.2 Il lato client NON DEVE registrare

  • Non stampare location.href (può contenere frammenti) negli ambienti di produzione
  • Non includere URL con frammenti, CEK o noncePrefix nei rapporti sugli errori
  • I log di debug e gli output dello strumento di sviluppo dovrebbero essere disabilitati o ridotti a icona per impostazione predefinita

SHOULD: incapsula una funzione di log/report unificata sul frontend che esegue internamente la sanificazione degli URL e il filtraggio dei campi sensibili prima dell'output/del reporting.

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

10.3.1 Avvisi su disponibilità e prestazioni

  • Avvisi sulla percentuale di errori: picchi in 5xx, aumento anomalo in 4xx (per distinguere il fallimento dell'autenticazione dall'abuso)
  • Avvisi di latenza: superamento delle soglie p95/p99, anomalie nel recupero dell'origine regionale
  • Avvisi di archiviazione: aumento degli errori di scrittura dell'archiviazione di oggetti e dei timeout di lettura
  • Avvisi sulle attività di pulizia: arretrato di pulizia in scadenza, numero eccessivo di tentativi di eliminazione delle attività

10.3.2 Avvisi di sicurezza

  • Aumento anomalo del tasso di successo del limite di velocità
  • Alta frequenza 401/403/404 dalla stessa fonte, sospetta enumerazione/forza bruta
  • Concorrenza/larghezza di banda di download di una singola risorsa anomala, sospetto inondazione di traffico o hotlinking
  • Le modifiche critiche alle policy (ad esempio, regole WAF, modifiche CSP/intestazione) dovrebbero attivare controlli e avvisi di modifica (se applicabile)

10.3.3 Governance degli avvisi

  • SHOULD: categorizza gli avvisi (P0/P1/P2) con percorsi di rotazione/escalation.
  • SHOULD: applica l'aggregazione del rimbalzo/finestra ai parametri rumorosi per evitare l'affaticamento degli avvisi.
  • SHOULD: allega informazioni diagnostiche minime (codice motivo, grafico delle tendenze, regione/percorso interessato) a ciascun avviso, esclusi i dati sensibili.

10.4 Rilevamento di anomalie e identificazione di abusi

I servizi di trasferimento file sono naturalmente esposti a rischi di enumerazione, forza bruta, inondazione del traffico e abuso di risorse. Questa sezione descrive i segnali rilevabili e i principi di risposta. Soglie e strategie specifiche devono essere adattate dinamicamente in base alla scala aziendale e ai costi falsi positivi.

10.4.1 Modelli di anomalie comuni

  • Enumeration: Sondaggio massiccio di transferId/percorsi di risorse in breve tempo, picchi in 404/401/403.
  • Forza bruta: Tentativi ad alta frequenza su codici brevi/password/token, curva del tasso di fallimento anomala.
  • Inondazione del traffico: larghezza di banda anomala per una singola risorsa, massicce connessioni simultanee dalla stessa origine, download ripetuti.
  • Anomalie del protocollo: Ordine dei blocchi irrazionale, caricamenti duplicati, frequenti interruzioni/ripetizioni, modelli UA anomali.

10.4.2 Strategie di mitigazione (Principi)

  • SHOULD: Limitazione della velocità, divieto a più livelli, meccanismi di sfida (se applicabile), politiche dinamiche basate su ASN/Regione/Impronta digitale.
  • SHOULD: Adotta strategie più delicate (ad esempio ritardo, limitazione segmentata) per percorsi sensibili ai falsi positivi (gli utenti normali possono scaricare frequentemente).
  • MUST: conservare i trigger verificabili (codice motivo, categoria soglia) per le azioni intraprese e fornire canali di supporto (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 controllo dei danni, verificabilità e comunicazione trasparente. Gli eventi che potrebbero incidere sugli impegni Zero-Knowledge (ad esempio, XSS, supply chain injection, log leak di frammenti) dovrebbero essere trattati con la massima priorità.

  1. Triage: classificare in base all'ambito e alla gravità dell'impatto (ad esempio, P0/P1/P2), definire percorsi di escalation e proprietari.
  2. Containment: Isolare rapidamente le fonti di rischio (vietare le fonti di attacco, disabilitare temporaneamente le funzionalità, rafforzare le policy, ruotare chiavi/token).
  3. Forense e revisione: Ricostruire la sequenza temporale in base a registri e metriche minimi; documentare decisioni, impatto, soluzioni correttive e miglioramenti.
  4. Bonifica e verifica: distribuzione di patch, test di regressione, verifica della sicurezza, nuovi test di scansione di terze parti, se necessario.
  5. Comunicazione e divulgazione: spiegare in modo trasparente agli utenti e al pubblico senza espandere la superficie di attacco; pubblicare rapporti sugli incidenti nella pagina di stato, se necessario.

La comunicazione esterna dovrebbe chiarire: se il materiale chiave o il testo in chiaro è stato potenzialmente esposto, la portata dell'impatto, le misure adottate e le azioni che gli utenti devono intraprendere (se presenti).

10.6 Conservazione dei dati e controllo degli accessi

I registri e i dati di monitoraggio sono essi stessi risorse sensibili. Per ridurre al minimo i rischi di fuga di dati e di abuso, dovrebbero essere applicati periodi di conservazione utili più brevi e un controllo degli accessi con privilegi minimi.

  • SHOULD: imposta periodi di conservazione differenziati per i tipi di registro (leggermente più lunghi per errori ed eventi di sicurezza, conservazione più breve o nessuna conservazione per i dettagli delle richieste riuscite).
  • SHOULD: utilizzare l'accesso con privilegi minimi (RBAC) per le piattaforme di registro e monitoraggio e conservare i controlli di accesso.
  • SHOULD: eseguire la sanificazione e la minimizzazione durante l'esportazione/condivisione dei registri (vietare il trasporto di credenziali sensibili e PII).

10.7 Principi di monitoraggio e integrazione di terze parti

Gli strumenti APM/di tracciamento degli errori di terze parti possono raccogliere URL, intestazioni, campi modulo e informazioni sul dispositivo per impostazione predefinita. Se si utilizza il monitoraggio di terze parti, assicurarsi che i limiti della raccolta non violino gli impegni di Zero-Knowledge.

  • MUST: non caricare script di terze parti nelle pagine di download/decrittografia (coerentemente con il capitolo 9).
  • MUST: configura esplicitamente la raccolta di terze parti: nessun frammento, nessun testo in chiaro di intestazione sensibile, nessun contenuto in testo in chiaro.
  • SHOULD: unifica la sanificazione degli URL per i report; vietare o mascherare fortemente i payload potenzialmente contenenti campi sensibili.
  • SHOULD: dare priorità ai parametri aggregati lato server rispetto al monitoraggio granulare lato client per ridurre la superficie di raccolta degli endpoint.

10.8 ID richiesta correlati (riservati)

Questo capitolo tratta il "Divieto di registrazione di dati sensibili, avvisi e IR, vincoli di monitoraggio di terze parti". Gli ID richiesta corrispondenti verranno aggiunti al file Appendice: Elenco principale degli ID delle richieste come unica fonte autorevole.