Politica di sicurezza delle informazioni

Traduzione di cortesia. Fa fede la versione in inglese.

Questa politica spiega come LFW protegge i sistemi che gestisce e i sistemi dei clienti in cui lavora. È scritta per chi svolge una revisione di sicurezza e descrive la pratica, non l’intenzione.

Versione 1.0, 6 ottobre 2026. Fa parte delle pratiche pubblicate nella pagina Fiducia, insieme alla politica di controllo degli accessi, al piano di risposta agli incidenti e alla politica di uso accettabile.

1. Ambito e responsabile

La politica riguarda LFW.com, il Portale clienti su my.lfw.com, il sito di amministrazione del personale, il server su cui girano, l’attrezzatura di lavoro di LFW e l’accesso di LFW ai sistemi dei clienti.

Leland Fiegel, fondatore di LFW, è il responsabile di questa politica e il suo unico membro del personale al 27 settembre 2026. Quando un controllo dipende da una seconda persona, questa politica lo dice invece di lasciar intendere che esista.

2. Dove girano i sistemi di LFW

Le applicazioni di LFW girano su un server Hetzner ad Ashburn, in Virginia, dietro Cloudflare. Il firewall dell’host accetta traffico web solo dagli intervalli di indirizzi di Cloudflare, quindi il server non è raggiungibile direttamente da Internet sulle porte web.

L’accesso SSH avviene solo con chiave; l’accesso con password e le password vuote sono rifiutati. L’applicazione, il suo database e il suo indice di ricerca sono in ascolto sull’indirizzo di loopback. fail2ban blocca gli indirizzi dopo ripetuti tentativi di accesso falliti.

I visitatori raggiungono il sito con TLS 1.3 e una politica HSTS di un anno; TLS 1.0 e 1.1 sono rifiutati. Anche il traffico tra Cloudflare e il server è cifrato.

Il sito di amministrazione del personale e il Portale clienti sono origini separate (admin.lfw.com e my.lfw.com). Uno script iniettato in una pagina pubblica non può agire come un membro del personale o un cliente autenticato, perché nessuno dei due cookie di sessione raggiunge il sito pubblico.

3. L’applicazione

Ogni pagina invia una politica di sicurezza dei contenuti che autorizza script e stili tramite hash, senza consentire script inline, insieme alle intestazioni standard: nessun rilevamento del tipo MIME, una politica del referrer rigorosa e una politica dei permessi che nega fotocamera, microfono e posizione.

Ogni scrittura nell’applicazione viene verificata in base all’origine da cui proviene, e gli endpoint pubblici hanno un limite di richieste per indirizzo. Il tipo dei file caricati viene determinato esaminandone i byte, mai da ciò che dichiara il mittente; gli SVG sono rifiutati; una richiesta può contenere tre file di al massimo otto megabyte ciascuno.

I link privati (rapporti, preventivi, inviti) usano token casuali di almeno 72 bit. I segreti si trovano in un unico file sul server, limitato all’amministratore del server e all’account di servizio. Il repository non contiene segreti.

4. Costruzione e rilascio

Ogni versione viene costruita in un container usa e getta che non contiene chiavi, né file privati, né accesso al server. Gli script di installazione delle dipendenze sono disattivati; solo due pacchetti nativi vengono ricompilati, indicati per nome.

La build fallisce in caso di errore di lint, di errore sui muri di testo o sui link interrotti, di regola di componente duplicata, di vulnerabilità nota di gravità alta in uno dei due alberi di dipendenze di produzione, o di test non superato.

Una versione di dipendenza pubblicata da meno di sette giorni viene rifiutata. Le versioni compromesse vengono di solito ritirate entro quel periodo: l’attesa è il controllo.

Una versione viene attivata in un solo passaggio, dopo che la nuova versione ha superato i controlli delle sue rotte pubbliche e protette, e la versione precedente viene conservata per un eventuale ripristino.

5. Backup

La directory dei dati del server, i database, i segreti e la configurazione vengono salvati con restic: cifrati e deduplicati, una volta al giorno e a ogni rilascio. Solo l’amministratore del server può leggere i backup.

Ogni database viene copiato con il backup a caldo di SQLite prima di essere archiviato, così ogni snapshot è coerente. Il repository viene verificato ogni settimana.

Conservazione: i dieci snapshot più recenti, 30 giornalieri, 26 settimanali, 24 mensili e 10 annuali. Una copia cifrata del repository è conservata anche fuori dall’account di hosting, in un bucket privato Cloudflare R2.

I backup del sito di un cliente sono quelli dell’hosting. LFW verifica periodicamente che vengano eseguiti e li usa per il ripristino quando serve, come previsto dall’allegato di gestione.

6. Registrazione e monitoraggio

Il server web registra ogni richiesta con il suo indirizzo di origine. Il Portale clienti conserva uno storico in sola aggiunta delle modifiche a richieste e documenti, registra ogni visualizzazione di un account cliente da parte del personale, e registra ogni token di accesso al momento dell’uso perché nessuno possa essere riutilizzato.

LFW Monitor controlla LFW.com ogni giorno come controlla i siti dei clienti: accessibilità, link interrotti, velocità, TLS, record di autenticazione della posta, politica di sicurezza dei contenuti e altre intestazioni di sicurezza. La disponibilità viene controllata ogni minuto, e il piè di ogni pagina la mostra.

Sul sito di un cliente, LFW Activity Logs registra chi ha modificato che cosa in WordPress e quando, così un incidente può essere ricostruito insieme ai log di accesso dell’hosting.

7. Siti dei clienti

LFW prende in carico un sito solo se ci sono tre elementi: un hosting gestito a nome del cliente, un firewall dentro WordPress (Wordfence Premium) con licenza per il sito, e Cloudflare davanti all’hosting con il firewall per applicazioni e la protezione dagli attacchi DDoS attivati.

Il core di WordPress, i temi e i plugin vengono aggiornati ogni mese dal controllo di versione, con verifiche automatiche dopo ogni pubblicazione. Un rilascio di sicurezza viene applicato prima del ciclo mensile. Tra un aggiornamento e l’altro, i firewall bloccano gli attacchi noti, anche contro una falla pubblicata prima che esista la correzione.

8. Revisione dei sistemi di LFW

LFW ha esaminato LFW.com, i suoi endpoint, il server, il DNS e l’autenticazione della posta, insieme al repository, il 16 settembre 2026, tramite ispezione e verifiche non autenticate delle proprie risorse. Non è stata trovata alcuna vulnerabilità sfruttabile da un visitatore non autenticato.

L’unico rilievo moderato, permessi dei file che consentivano a un secondo account di servizio dell’host di leggere i database di LFW, è stato corretto il giorno stesso ed è ora verificato da un test. Gli altri rilievi erano punti di rafforzamento, accettati così come sono, e sono registrati in forma riservata.

Non è stato ancora commissionato alcun test di penetrazione indipendente dei sistemi di LFW. Quando il contratto di un cliente ne prevede uno per il sito del cliente, LFW lo organizza e ne riporta il risultato.

9. Segnalare un problema

Le segnalazioni di sicurezza vanno a security@lfw.com, indicato in security.txt (in inglese). La politica di divulgazione delle vulnerabilità, con il suo ambito, le sue regole e il suo impegno a non avviare azioni legali, è pubblicata su lfw.com/security.

Una persona risponde entro due giorni lavorativi. Orario lavorativo: Dal lunedì al venerdì, dalle 9 alle 17, ora della costa est (dalle 6 alle 14, ora del Pacifico), esclusi i festivi federali. Non offriamo assistenza fuori da questo orario né reperibilità.

10. Che cosa questa politica non afferma

LFW non ha alcun rapporto SOC 2 o ISO 27001 e non dichiara conformità ad alcun framework specifico. Non dichiara la cifratura del disco per il database di produzione del suo server, né crittografia convalidata FIPS, né un sistema di rilevamento delle intrusioni di rete.

Questa politica cambia in modo trasparente: la versione e la data qui sopra cambiano quando cambia, e il testo precedente resta nella cronologia del repository.