Trust CenterSicurezza
Pratiche di sicurezza
La postura di sicurezza di un MSP che gestisce infrastrutture critiche per ospitalità, PMI e operazioni remote. Nessun audit inventato.
Questa pagina descrive processi e impegni reali. Quando qualcosa non è ancora stato fatto — come un penetration test esterno indipendente — lo diciamo esplicitamente invece di lasciarlo intendere.
Crittografia in transito e a riposo
Tutto il traffico viaggia crittografato; anche i dati sensibili sono crittografati dove vengono archiviati.
- TLS 1.2/1.3 obbligatorio su tutto il traffico del sito e delle API, servito ai margini della rete da Vercel e Cloudflare.
- I dati di pagamento vengono tokenizzati lato Stripe / MercadoPago; DITAP non vede né memorizza mai i numeri di carta completi.
- I database gestiti (Supabase / Postgres) cifrano i dati a riposo per impostazione predefinita a livello dell'infrastruttura del fornitore.
- I segreti applicativi (API key, token, webhook) risiedono in variabili d'ambiente gestite dal provider di hosting — mai nel repository di codice.
Controllo degli accessi
Accesso con il minimo privilegio possibile, autenticazione a più fattori e revisione periodica dei permessi.
- Principio del minimo privilegio: ogni persona e ogni integrazione accede solo a ciò che il proprio ruolo richiede.
- Autenticazione a più fattori (MFA) obbligatoria sugli account amministrativi di hosting, DNS, pagamenti ed email.
- L'accesso dei clienti ai propri pannelli (ad esempio /status) è separato dall'accesso amministrativo interno.
- Revisione periodica degli accessi attivi e revoca immediata al termine di una collaborazione o di un progetto.
Gestione delle patch
Dipendenze e sistemi operativi aggiornati in modo continuo, dando priorità alle vulnerabilità critiche.
- Le dipendenze del sito e dei sistemi gestiti vengono aggiornate in modo continuo; gli avvisi di vulnerabilità critiche hanno priorità sul resto del backlog.
- Sull'infrastruttura on-site dei clienti (switch, firewall, access point), la manutenzione include l'aggiornamento del firmware secondo il calendario del produttore.
- Le modifiche all'infrastruttura passano per il controllo di versione e, quando applicabile, per un ambiente di test prima della produzione.
Backup e continuità
Backup automatici e piani di ripristino testati, con RTO/RPO concordati per progetto.
- I database gestiti dispongono di backup automatici giornalieri e recupero point-in-time forniti dal fornitore dell'infrastruttura.
- Nei progetti di infrastruttura gestita, definiamo insieme al cliente gli obiettivi di tempo di ripristino (RTO) e punto di ripristino (RPO) in base alla criticità del servizio.
- Le configurazioni di rete e dei sistemi critici sono documentate e versionate per poterle ricostruire in caso di guasto hardware.
Valutazione delle vulnerabilità e penetration test
Posizione onesta: oggi ci basiamo sulle certificazioni dei nostri fornitori e su revisioni interne; un penetration test indipendente è in valutazione.
- Non abbiamo ancora commissionato un penetration test esterno indipendente su ditap.io — non lo affermiamo perché non è avvenuto. Commissionarne uno prima di scalare verso clienti enterprise è in valutazione.
- Nel frattempo, ci affidiamo alle certificazioni e ai programmi di sicurezza dei nostri fornitori di infrastruttura (Vercel, Cloudflare, Supabase, Stripe), che sono sottoposti ad audit indipendenti.
- Effettuiamo revisioni interne della configurazione di rete e della superficie di attacco nei progetti di infrastruttura gestita che consegniamo ai clienti.
- Le segnalazioni di vulnerabilità esterne vengono ricevute e gestite secondo la nostra politica di divulgazione responsabile (/security/disclosure).
Risposta agli incidenti
Un processo definito di rilevamento, contenimento, comunicazione al cliente e postmortem.
- Rilevamento: monitoraggio degli errori (Sentry) e dello stato dei servizi (/status) con avvisi al team responsabile.
- Triage e contenimento: classificazione per gravità e isolamento del componente interessato per limitare l'impatto.
- Comunicazione: i clienti con SLA gestito ricevono una notifica entro i tempi definiti in /trust/sla in base alla gravità.
- Postmortem: gli incidenti critici vengono documentati con causa principale e azioni correttive, condivise con il cliente interessato quando applicabile.
Gestione di fornitori e sub-responsabili
Ogni fornitore che tratta dati viene valutato prima dell'adozione ed elencato pubblicamente.
- Prima di aggiungere un fornitore che elabora dati, ne valutiamo la politica sulla privacy, le certificazioni e il meccanismo di trasferimento internazionale (DPA / SCC).
- L'elenco completo e aggiornato dei sub-responsabili è pubblicato in /trust/sub-processors.
- Le modifiche rilevanti all'elenco dei sub-responsabili sono riportate in quella pagina; le modifiche sostanziali possono essere notificate ai clienti con un contratto attivo.
Hai bisogno di un dettaglio tecnico specifico per la tua valutazione fornitori?
Rispondiamo ai questionari di sicurezza e condividiamo documentazione aggiuntiva sotto NDA quando appropriato.
Scrivi a [email protected]