Sicurezza

Il nostro approccio

La sicurezza di una piattaforma che tiene i contenuti e l'identità di marca dei suoi clienti non è una funzione da aggiungere in fondo: è un vincolo di progetto.

Applichiamo tre principi semplici. Raccogliamo il minimo indispensabile, diamo a ciascuno soltanto gli accessi che gli servono, e rendiamo verificabile ciò che succede.

Le misure descritte qui sono quelle che il GDPR richiede all'articolo 32: adeguate al rischio, non massime in astratto. Le rivediamo quando cambia il prodotto o quando un incidente ci insegna qualcosa.

Cifratura in transito

Tutto il traffico verso la piattaforma e verso il sito viaggia su HTTPS. Le connessioni in chiaro vengono reindirizzate alla versione cifrata.

I cookie tecnici che il sito imposta portano l'attributo Secure, quindi non vengono mai inviati su una connessione non cifrata, e quelli di sessione portano anche HttpOnly.

Le chiamate verso i fornitori collegati, dai modelli linguistici ai servizi di pubblicazione, avvengono su canali cifrati e autenticati.

Cifratura a riposo

I dati archiviati, inclusi contenuti, materiali caricati e backup, sono cifrati a riposo dalla piattaforma o dall'infrastruttura che li ospita.

Le bozze di registrazione, che possono contenere dati aziendali prima ancora che l'account esista, vengono cifrate lato server e non restano mai nel browser.

Le password non sono conservate in chiaro in nessuna forma recuperabile.

Gestione dei segreti

Le chiavi delle interfacce dei fornitori, i token dei servizi collegati e le credenziali che il cliente configura per pubblicare sul proprio sito sono segreti, e li trattiamo come tali.

• Sono cifrati a riposo con cifratura autenticata.
• Non compaiono mai nei log, nei messaggi di errore o nelle risposte delle interfacce.
• Una volta salvati non vengono mostrati di nuovo nell'interfaccia: si possono solo sostituire.
• Sono accessibili solo ai componenti dell'applicazione che devono usarli.

Controllo degli accessi

Ogni accesso ai sistemi di produzione è nominativo. Non esistono utenze condivise fra più persone.

Applichiamo il principio del minimo privilegio: ciascuno riceve i permessi che il suo ruolo richiede, e nulla di più. I permessi vengono rivisti quando il ruolo cambia e revocati quando il rapporto finisce.

L'accesso del nostro personale ai dati di un cliente avviene solo per assistenza richiesta, diagnosi di un guasto o obbligo di legge, e lascia traccia.

Isolamento fra clienti

Ogni cliente lavora in uno spazio separato. I contenuti, i materiali, le configurazioni e le chiavi di un cliente non sono raggiungibili da un altro.

La separazione è applicata a livello di dati e verificata a ogni richiesta: l'identificativo dello spazio di lavoro fa parte del controllo di autorizzazione, non è solo un filtro di interfaccia.

I contenuti di un cliente non alimentano i contenuti di un altro e non contribuiscono ad alcun modello condiviso.

Backup e ripristino

Eseguiamo backup periodici dei dati della piattaforma, conservati cifrati e separati dall'ambiente di produzione.

Le procedure di ripristino sono documentate e vengono provate: un backup che non è mai stato ripristinato non è un backup, è una speranza.

La conservazione dei backup segue la stessa logica di minimizzazione applicata ai dati: si tiene quanto serve a ripristinare, non di più.

Log e monitoraggio

Registriamo gli eventi rilevanti per la sicurezza e per la diagnosi: autenticazioni, operazioni sui dati, esiti delle elaborazioni, errori applicativi.

I log servono a capire che cosa è successo, non a profilare le persone. Non contengono segreti né, per quanto tecnicamente evitabile, contenuti sensibili del cliente.

Un sistema di monitoraggio degli errori ci segnala le anomalie in tempo reale, così un difetto viene visto da noi prima che dal cliente.

Gestione degli incidenti

Abbiamo una procedura documentata per gestire un incidente di sicurezza. In sintesi.

1. Rilevazione: l'anomalia arriva dal monitoraggio, da una segnalazione interna o da una segnalazione esterna.
2. Contenimento: si limita subito la propagazione, anche a costo di degradare temporaneamente una funzione.
3. Valutazione: si stabilisce che cosa è stato esposto, quali clienti sono coinvolti e se ci sono dati personali.
4. Comunicazione: si informano i clienti coinvolti e, quando previsto, si assistono nelle notifiche di legge.
5. Rimedio: si corregge la causa e si verifica che la correzione tenga.
6. Analisi: si scrive che cosa è successo e che cosa cambia perché non si ripeta.

Notifica di un incidente

Se un incidente coinvolge dati personali trattati per conto di un cliente, informiamo quel cliente senza ingiustificato ritardo, come previsto dall'articolo 33 paragrafo 2 del GDPR.

La prima comunicazione parte appena l'incidente è confermato, anche se il quadro non è ancora completo, e viene seguita dagli aggiornamenti man mano che l'analisi procede.

Il cliente, in quanto titolare, resta il soggetto tenuto alla notifica all'autorità di controllo entro il termine previsto dall'articolo 33 del GDPR e, quando ricorre, alla comunicazione agli interessati. Lo assistiamo con le informazioni tecniche necessarie.

Obblighi previsti dall'accordo sul trattamento

Divulgazione responsabile

Se hai individuato una vulnerabilità, scrivi a info@flarseo.com con oggetto "sicurezza". Leggiamo e rispondiamo.

• Descrivi il problema, il percorso per riprodurlo e l'impatto che immagini.
• Non accedere a dati che non ti appartengono, non modificarli e non cancellarli.
• Non pubblicare la vulnerabilità prima che sia stata corretta o che ne abbiamo discusso insieme.
• Evita test che degradino il servizio per gli altri clienti.

Non intraprendiamo azioni verso chi segnala in buona fede rispettando queste condizioni. Non gestiamo un programma di ricompense: ringraziamo e, se lo desideri, ti citiamo.

Che cosa non dichiariamo

Preferiamo una pagina onesta a una pagina impressionante.

• Non dichiariamo certificazioni che non abbiamo: nessuna certificazione ISO, nessun rapporto di attestazione di terze parti.
• Non dichiariamo test di intrusione periodici svolti da terzi come se fossero una prassi consolidata.
• Non promettiamo l'assenza di vulnerabilità: nessun sistema può prometterla.

Se una di queste voci cambierà, questa pagina lo dirà con una nuova versione e una nuova data, non prima.

Le misure descritte qui sono quelle in essere alla data indicata sopra. Gli obblighi contrattuali in materia di sicurezza sono quelli dell'accordo consegnato come allegato al contratto, in italiano, alla registrazione.