Controlli tecnici che sostengono la conformità

L'Health Insurance Portability and Accountability Act richiede la protezione dei dati dei pazienti, controlli degli accessi e audit trail.

• La cifratura end-to-end fa sì che i dati dei pazienti non siano mai visibili ai server
• Cronologia delle scritture firmata — ogni modifica è firmata con Ed25519 e dimostra chi ha scritto cosa e quando
• Controllo degli accessi granulare con chiavi con nome per i diversi team di cura
• Strategie di conservazione dei dati tramite database con sharding temporale e archiviazione
• Funzionamento offline per il personale sanitario sul territorio e le cliniche remote

⚠️ HIPAA richiede anche il registro degli accessi in lettura, i BAA, misure di salvaguardia amministrative e la sicurezza fisica: sta a te implementarli attorno a MindooDB.

Vedi i casi d'uso in sanità → | Schemi dettagliati →

Il Sarbanes-Oxley Act richiede audit trail finanziari, registrazioni immutabili e controlli degli accessi.

• Registrazioni immutabili grazie all'architettura append-only
• Integrità crittografica — le voci concatenate via hash dimostrano che le registrazioni non sono state alterate
• Cronologia completa delle scritture con paternità firmata, per i requisiti di audit
• Viaggio nel tempo per ricostruire qualsiasi stato passato
• Modifiche firmate: la paternità di ogni modifica è dimostrabile

⚠️ SOX richiede anche controlli interni, attestazioni del management e separazione dei compiti: sono responsabilità organizzative.

Vedi i casi d'uso per i servizi finanziari → | Schemi dettagliati →

Il Regolamento generale sulla protezione dei dati richiede il diritto all'oblio, la portabilità dei dati, la tracciabilità dei consensi e la protezione dei dati sin dalla progettazione.

• Cancellazione coordinata dei dati — purgeDocHistory() propaga le richieste di eliminazione tramite il database directory a tutti i client sincronizzati
• Portabilità dei dati grazie alle funzioni di esportazione dei documenti
• Protezione dei dati sin dalla progettazione tramite la cifratura end-to-end
• Audit trail delle scritture — cronologia firmata e append-only di tutte le modifiche ai dati

⚠️ Le richieste di purge raggiungono i client alla successiva sincronizzazione della directory: i dispositivi che non si riconnettono mai conservano i dati. Il GDPR richiede anche la gestione dei consensi, la nomina di un DPO e il registro delle attività di trattamento: sta a te provvedere.

Vedi gli schemi di conformità →

Il Payment Card Industry Data Security Standard richiede la protezione dei dati delle carte di pagamento, controlli degli accessi e audit trail.

• Cifratura forte — AES-256-GCM a riposo, RSA per ogni utente in transito, TLS sulla linea
• Controlli degli accessi con chiavi con nome, per limitare l'accesso ai dati sensibili
• Audit trail delle scritture — cronologia firmata e append-only di tutte le modifiche ai dati

⚠️ PCI-DSS è uno standard ampio, che copre la segmentazione della rete, la gestione delle vulnerabilità, il monitoraggio e altro ancora. MindooDB risponde ai requisiti su cifratura e controllo degli accessi: il resto è responsabilità tua. Valuta se ti serve davvero archiviare i dati delle carte.

Vedi gli schemi di conformità →

• ✅ 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)
• ✅ Modifiche con marca temporale

• ✅ Cifratura lato client (AES-256-GCM)
• ✅ Controllo degli accessi granulare (chiavi con nome)
• ✅ Gestione delle chiavi (KeyBag protetto da password)
• ✅ Cancellazione coordinata dei dati (purge propagato dalla directory)
• ✅ Sovranità dei dati (tenant lato client)

• ⚙️ Registro degli accessi in lettura (livello applicativo)
• ⚙️ Gestione dei consensi (livello applicativo)
• ⚙️ Controllo degli accessi basato sui ruoli (con chiavi con nome)
• ⚙️ Politiche di conservazione dei dati (con sharding temporale)
• ⚙️ Reporting di conformità (con i dati di audit)

• Ogni scrittura è firmata crittograficamente con la chiave Ed25519 dell'autore
• Le marche temporali sono incluse in ogni voce di modifica
• La cronologia dei documenti si può percorrere con iterateDocumentHistory()
• Il viaggio nel tempo permette di ricostruire qualsiasi stato passato
• Le eliminazioni sono marcate con tombstone (la cronologia resta intatta)

Nota: MindooDB registra automaticamente le scritture (chi ha cambiato cosa). Il registro degli accessi in lettura (chi ha visto cosa) va implementato a livello di applicazione.

• Dimostrare chi ha cambiato cosa e quando
• Ricostruire lo stato in qualsiasi momento del passato
• Dimostrare l'integrità dei dati a chi svolge l'audit
• Costruirci sopra un registro degli accessi in lettura a livello di applicazione
• Sostenere i requisiti di legal discovery

Vedi la documentazione sul viaggio nel tempo →

• Sharding temporale — Creare database per periodo (annuali, mensili)
• Database di archivio — Spostare i dati vecchi in database di archivio in sola lettura
• Ciclo di vita dei documenti — Marcare i documenti come archiviati invece di eliminarli
• Purge coordinato — Le richieste di purge firmate dall'admin si propagano tramite il database directory; i client le eseguono alla sincronizzazione successiva

Vedi gli schemi di modellazione dei dati →

• La natura append-only comporta che i dati si accumulino nel tempo
• Pianifica la gestione della crescita dall'inizio
• Usa lo sharding temporale per un'archiviazione efficiente
• Valuta i requisiti di conservazione per ogni tipo di documento
• Il purge coordinato raggiunge i client sincronizzati; i dispositivi offline conservano i dati

Vedi gli schemi di conformità →