Parti dal presupposto che i server siano compromessi
Questo è il modello di sicurezza a livello di piattaforma che regge ogni deployment di MindooDB, incluso Haven Sicurezza e privacy. MindooDB è progettato perché l'infrastruttura di archiviazione e sincronizzazione possa non essere affidabile. Tre livelli di cifratura indipendenti proteggono la riservatezza dei dati. Le firme crittografiche dimostrano la paternità e impediscono le manomissioni. Anche una violazione completa del server restituisce solo testo cifrato e chiavi pubbliche: nessun dato in chiaro, nessuna chiave privata, nessun nome utente.
Tre livelli di cifratura indipendenti
Il protocollo di sincronizzazione di MindooDB distribuisce la protezione su più livelli. Anche se uno viene compromesso, gli altri continuano a proteggere la riservatezza dei dati. È il fulcro architetturale della sicurezza di MindooDB: non devi fidarti di un singolo livello per essere al sicuro.
Prima che una voce entri nello store, il suo payload viene cifrato con una chiave simmetrica (AES-256-GCM). Questa cifratura fa parte del modello dei dati, non del trasporto. Il server che archivia le voci non può leggerne il contenuto: vede solo byte cifrati.
Quando il server risponde a una richiesta di sincronizzazione, avvolge i payload delle voci in un ulteriore livello di cifratura RSA, usando la chiave pubblica dell'utente che ha fatto la richiesta. Anche intercettando la risposta HTTP, non è possibile decifrarla senza la chiave RSA privata del destinatario.
Tutta la comunicazione passa da TLS. Così sono protetti anche i metadati (ID delle voci, marche temporali, parametri delle richieste) che i livelli di cifratura del payload non coprono. Insieme, i tre livelli proteggono i dati a riposo, in transito e sulla linea.
Come nasce la fiducia
In MindooDB la fiducia ha una sola radice: la chiave di firma Ed25519 dell'admin. L'admin firma il database directory, che contiene le registrazioni degli utenti. La chiave pubblica di ogni utente è registrata in una voce della directory firmata dall'admin. Quando un client o un server riceve una modifica a un documento, verifica la chiave pubblica di chi ha firmato contro la directory: se la chiave non è registrata, la modifica viene rifiutata. Non serve alcuna autenticazione sul server; la fiducia nasce da prove crittografiche.
Cosa vede il server e cosa non vede
È la conseguenza pratica dell'architettura zero-trust. Un server (o qualsiasi intermediario, compresi i nodi relay) tratta esclusivamente dati cifrati e informazioni pubbliche. Tutto ciò che è sensibile resta sui dispositivi dei client.
- Chiavi di firma pubbliche (Ed25519)
- Chiavi di crittografia pubbliche (RSA-OAEP)
- Blob cifrati (testo cifrato AES-256-GCM)
- Metadati delle voci (marche temporali, hash del contenuto)
- Hash dei nomi utente (SHA-256 — non i nomi veri)
- Il contenuto dei documenti (cifrato end-to-end)
- I nomi utente (cifrati con la chiave RSA dell'admin)
- Le chiavi private di firma o di crittografia
- Le chiavi simmetriche (del tenant o con nome)
- Le password condivise (solo out-of-band)
Controllo degli accessi basato sulla cifratura
MindooDB applica il controllo degli accessi tramite le chiavi di crittografia, non con permessi lato server. Chi ha la chiave può decifrare il documento. Chi non l'ha vede testo cifrato. Così il controllo degli accessi funziona allo stesso modo sia che i dati siano su un server, su un dispositivo peer o su un nodo relay che non può leggerli. Per il controllo granulare delle operazioni di scrittura — chi può creare, modificare, eliminare, snapshottare o purgare i documenti — vedi la pagina dedicata al controllo degli accessi.
Tutti i documenti sono cifrati con la chiave AES-256 predefinita del tenant, se non ne viene indicata un'altra. Ogni utente registrato la riceve durante l'onboarding. Va bene per i dati generali di tutto il tenant.
Per i documenti sensibili crei una chiave di crittografia con nome e la condividi solo con gli utenti autorizzati. Le chiavi viaggiano offline (la chiave cifrata via e-mail, la password per telefono o di persona) oppure in modo cieco per l'admin tramite una policy: chi detiene la chiave la incapsula per ciascun destinatario con la chiave pubblica (RSA) personale di quest'ultimo, così un admin può distribuirla senza mai leggerla. Solo chi ha la chiave può decifrare.
Una chiave speciale che cifra soltanto le voci di controllo degli accessi della directory (registrazioni di utenti, revoche, gruppi). I server la usano per convalidare di quali chiavi di firma fidarsi, senza vedere nomi utente o dati aziendali. I nomi utente sono salvati come hash SHA-256; i nomi veri sono cifrati con la chiave RSA dell'admin.
| Operazione | Applicata tramite |
|---|---|
| Registrazione di un utente | Richiede la firma dell'admin (Ed25519) |
| Creazione di un documento | Serve la chiave di crittografia (predefinita o con nome) |
| Modifica di un documento | Servono chiave di firma (utente registrato) + chiave di crittografia |
| Lettura di un documento | Serve la chiave di decifratura |
| Revoca di un utente | Richiede la firma dell'admin; blocca la sincronizzazione e rifiuta le modifiche successive |
Autenticazione challenge-response e onboarding sicuro
MindooDB non usa password né token archiviati sul server. L'autenticazione si basa su challenge-response Ed25519: il server genera una challenge casuale, il client la firma con la propria chiave privata e il server verifica la firma contro la chiave pubblica registrata. Così l'identità è dimostrata senza condividere segreti.
Ogni sessione di sincronizzazione inizia con un handshake challenge-response:
- Il client invia al server la propria chiave di firma pubblica
- Il server cerca la chiave nella directory e invia una challenge casuale
- Il client firma la challenge con la propria chiave privata
- Il server verifica la firma, controlla lo stato di revoca ed emette un JWT di breve durata
Nessuna password e nessun database di sessioni sul server. Un utente revocato non riesce nemmeno ad avviare l'autenticazione.
I nuovi utenti entrano con un handshake in tre passi, durante il quale le chiavi private non lasciano mai il dispositivo:
- Richiesta di adesione — Il nuovo utente genera le chiavi in locale e crea una richiesta che contiene solo chiavi pubbliche. Si può condividere senza rischi su qualsiasi canale.
- Approvazione dell'admin — L'admin registra l'utente nella directory e cifra le chiavi simmetriche con una password di condivisione monouso.
- Scambio su canali separati — La risposta di adesione arriva via e-mail o chat; la password di condivisione viene comunicata a parte, per telefono o di persona.
Algoritmi e garanzie
MindooDB usa algoritmi crittografici consolidati e largamente verificati. Nessuna crittografia fatta in casa. La scelta bilancia il livello di sicurezza con la compatibilità tra piattaforme (Node.js, browser, React Native).
- Firma: Ed25519 (sicurezza a 128 bit, curva ellittica)
- Cifratura del payload: AES-256-GCM (sicurezza a 256 bit)
- Cifratura nel trasporto: RSA-OAEP con SHA-256 (chiavi a 3072 bit)
- Derivazione delle chiavi: PBKDF2 con un salt distinto per ogni tipo di chiave
- Firma dei token: HMAC-SHA256
- Hashing: SHA-256 (indirizzamento per contenuto, privacy dei nomi utente)
- Riservatezza: cifratura AES-256-GCM — legge solo chi ha la chiave
- Autenticità: firme Ed25519 — dimostrano chi ha creato ogni modifica
- Integrità: concatenamento tramite hash — una manomissione rompe la catena ed è rilevabile in qualsiasi punto
- Non ripudio: le firme non sono falsificabili — la paternità è dimostrabile
- Privacy: nomi utente sottoposti a hash e cifrati — il server non può identificare gli utenti
Da cosa protegge il sistema
MindooDB presuppone che server, infrastruttura di rete e anche qualche peer possano essere compromessi o malevoli. Il modello di sicurezza è pensato per mantenere riservatezza e integrità dei dati anche in queste condizioni.
- Violazione del server — Chi attacca ottiene solo testo cifrato e chiavi pubbliche. Nessun dato in chiaro, nessuna chiave privata, nessun nome utente.
- Intercettazione di rete — Tre livelli di cifratura proteggono i dati anche se TLS è compromesso.
- Modifiche non autorizzate — Ogni modifica è firmata; quelle non firmate o firmate male vengono rifiutate.
- Manomissione — Il concatenamento tramite hash rende rilevabile qualsiasi alterazione.
- Accesso di utenti revocati — La revoca agisce sia sulla challenge sia sulla convalida del token; blocca subito la sincronizzazione.
- Ascolto sui relay — I nodi relay archiviano e inoltrano voci cifrate che non possono decifrare.
Il contenuto del payload è sempre cifrato, ma per come è fatto il sistema alcuni metadati sono visibili al server. È un compromesso deliberato: al protocollo di sincronizzazione servono metadati per riconciliare le voci.
- Visibili: marche temporali delle voci, hash del contenuto, struttura dei documenti (quante voci per documento), schemi di accesso (quando gli utenti sincronizzano)
- Non visibili: contenuto dei documenti, nomi utente, chiavi di crittografia, contenuto degli allegati
Gli hash del contenuto rivelano quando due voci contengono dati cifrati identici (per la deduplicazione). È un compromesso accettato in favore dell'efficienza di archiviazione.
Cosa dovresti sapere
MindooDB è software in beta con basi crittografiche solide. È stato svolto un audit di sicurezza completo, che ha individuato gli ambiti da irrobustire prima dell'uso in produzione. Crediamo che la trasparenza sui limiti crei più fiducia delle promesse di marketing.
Revocare un utente blocca ogni sincronizzazione futura e rifiuta le sue modifiche successive. I dati già sincronizzati sul suo dispositivo locale restano però accessibili: nessun sistema può garantire la cancellazione su un dispositivo che non si riconnette più. Mitigazione: usa chiavi con nome per i documenti sensibili (raggio d'azione più piccolo) e ruota le chiavi quando qualcuno lascia il team. Haven Enterprise aggiunge alle stesse policy di governance una cancellazione remota del dispositivo firmata dall'admin: il tenant viene rimosso da un dispositivo rubato o dismesso alla connessione successiva.
Più chiavi per utente (firma, crittografia, chiavi simmetriche con nome) vanno distribuite in modo sicuro. Mitigazione: una sola password sblocca tutte le chiavi tramite PBKDF2 con salt diversi. Il KeyBag offre un archivio unificato delle chiavi. Il flusso di richiesta e risposta di adesione gestisce lo scambio di chiavi per i nuovi utenti. Haven Enterprise automatizza il lavoro ricorrente: le policy di distribuzione delle chiavi firmate dall'admin forniscono le chiavi a utenti e gruppi — e le ritirano di nuovo — incapsulate per ciascun destinatario, e ogni client riconcilia il proprio KeyBag alla sincronizzazione successiva.
Per impostazione predefinita il server non può interrogare il contenuto dei documenti, perché vede solo testo cifrato. Si interroga sempre lato client, con indicizzazione incrementale. Se però il tuo caso d'uso richiede elaborazione lato server (per esempio un sistema di prenotazioni online o un sito web pubblico), puoi dare al processo server una chiave di decifratura o condividere con esso una parte dei dati. È una scelta architetturale consapevole, deployment per deployment: il valore predefinito è la riservatezza, e l'accesso del server si attiva solo dove serve.
Un audit di sicurezza completo ha individuato gli ambiti da irrobustire: rate limiting sugli endpoint, revoca dei token JWT e rotazione della chiave di admin. Le modifiche retrodatate di utenti revocati sono ormai impedite dalle ricevute dei testimoni con tempo attendibile (vedi il modello di controllo degli accessi). Le basi crittografiche (Ed25519, AES-256-GCM, RSA-OAEP) sono solide. L'irrobustimento operativo è in corso.
Controlli tecnici che sostengono la conformità
MindooDB fornisce mattoni crittografici che coprono i requisiti tecnici centrali dei principali quadri normativi. La conformità in sé resta una responsabilità organizzativa: MindooDB ti dà le basi tecniche.
- ✅ Cronologia completa delle scritture (append-only)
- ✅ Firme crittografiche (prova della paternità)
- ✅ Registrazioni a prova di manomissione (concatenate via hash)
- ✅ Viaggio nel tempo (ricostruzione di qualsiasi stato)
- ✅ Cifratura end-to-end (il server non può decifrare)
- ✅ Controllo degli accessi granulare (chiavi con nome)
- ✅ Cancellazione coordinata dei dati (
purgeDocHistory) - ⚙️ Registro degli accessi in lettura (lo costruisci a livello di app)
Questi controlli sostengono programmi HIPAA (sanità), SOX (finanza), GDPR (protezione dei dati) e PCI-DSS (pagamenti). Vedi la documentazione dettagliata sulla conformità →
MindooDB Haven è una PWA per browser che porta la stessa cifratura end-to-end, le app in sandbox e la sincronizzazione local-first in un'area di lavoro tranquilla e multipiattaforma. Prova la beta gratuita o leggi gli approfondimenti.