Illeggibile
La cifratura avviene prima dell'upload. Nessuno può leggere i suoi dati, noi compresi. Così, quando qualcuno chiede chi altro può leggerli, la risposta è un'architettura invece di una promessa: non i suoi provider, non noi.
Infrastruttura dati sovrana
I suoi dati non dovrebbero essere da nessuna parte.
Da nessuna parte in forma leggibile, e in nessun posto nuovo: i suoi dati restano nei servizi cloud che sceglie, ma ne riprende la sovranità.
Il problema
La responsabilità resta locale. L'accesso no.
Lo storage cloud, così come esiste oggi, non è in grado di stabilire chi può leggere i dati che ospita. I provider cifrano i file con chiavi che tengono dalla loro parte, e i loro sistemi decifrano su richiesta: per qualsiasi dipendente con i permessi giusti, per qualsiasi autorità che lo imponga. La serratura esiste davvero. Appartiene all'operatore, e con essa il registro di chi l'ha aperta.
L'ordine non deve per forza arrivare dall'autorità che governa quei dati: un provider con sede all'estero risponde alla propria legge ovunque si trovino i suoi server, e la divulgazione arriva dopo, ammesso che arrivi. La notifica, la sanzione e la lettera ai clienti coinvolti restano all'organizzazione che ha raccolto i dati, chiunque detenesse i byte.
Ogni valutazione finisce allo stesso modo: descrivendo un controllo che sta in mano ad altri.
Legga perché cifrato a riposo non significa privato.
La soluzione
Tenga tutti i suoi provider. Cambi ciò che possono consegnare.
DataPrism è un overlay sull'object storage esistente. I file vengono cifrati lato client prima di lasciare il perimetro, divisi in frammenti e dispersi su istanze e provider indipendenti. Nessun provider detiene la chiave, quindi una richiesta presentata a uno qualsiasi di essi produce solo frammenti che nessuno può aprire, e il numero di indirizzi distinti che una richiesta dovrebbe raggiungere diventa una cifra dichiarata anziché un'ipotesi.
Un indice sigillato del file viene ancorato su un registro pubblico, di dimensione costante qualunque sia il file: lì non finiscono mai contenuti né nulla di leggibile, e chi effettua la revisione può recuperare il record direttamente. Non c’è una piattaforma verso cui migrare: stessi provider, stesse regioni, stesse fatture. I dati vengono riscritti attraverso il pipeline, in account già suoi.
Scopra come la cifratura lato client diventa prova pubblica.
Ogni scala
Un documento o l'intero patrimonio. Stesse proprietà.
L'adozione parte dove conviene partire: su tutto ciò che verrà scritto da qui in avanti, oppure su un perimetro esistente fatto passare una volta nel pipeline. Niente da riprogettare man mano che il perimetro si allarga, e un solo documento decisivo si comporta esattamente come milioni di record.
L'adozione non richiede un programma, un ciclo di budget e un comitato di indirizzo prima che qualcosa migliori: si copre prima il perimetro più esposto, lo si dimostra e si estende da lì. E dove le pipeline devono raccogliere dati senza poterli leggere, la stessa infrastruttura può essere progettata per la blind ingestion: raccolta senza esposizione.
Tre proprietà
Illeggibile. Inarrestabile. Dimostrabile.
Tre proprietà che eredita dall'architettura: nessuno deve essere creduto sulla parola perché siano garantite.
Inarrestabile
Perdere un provider per un'interruzione, un aumento di prezzo o un rifiuto di servirla smette di essere uno scenario da mettere in conto: ogni file è frammentato e disperso su provider indipendenti, con ridondanza integrata.
Dimostrabile
Dimostri a un terzo che un file esiste e non è cambiato, senza aprirlo e senza che nessuno debba garantire per Lei: l'integrità è ancorata su un registro pubblico come impronta di dimensione costante, qualunque sia la dimensione del file.
Già cifra i dati?
La cifratura risolve il primo problema. Non quelli dietro.
Cifrare prima dell'upload impedisce al provider di leggere i dati. È la parte difficile, vale la pena farlo, ed è anche da lì che parte questa pipeline. È anche il punto in cui la maggior parte delle architetture si ferma, e restano in piedi tre esposizioni.
-
01
Una copia completa resta a un solo indirizzo.
Ciò che raggiunge quell'indirizzo raggiunge tutto, in una sola operazione. I dati cifrati presi oggi possono essere conservati a tempo indeterminato, e una crittografia che tiene ora non tiene per sempre. La raccolta su larga scala si basa proprio su questa premessa: prendere tutto, conservarlo, leggerlo dopo.
-
02
La cifratura non è disponibilità.
Un account sospeso, un'interruzione, un cambio di condizioni o un riscatto si portano via i dati, chiavi o non chiavi. Chi detiene ogni byte è anche chi può smettere di restituirlo.
-
03
La custodia delle chiavi non è dimostrabile.
È un'affermazione su una configurazione interna, e la prova è la parola dell'operatore. Nulla di tutto ciò è verificabile da chi deve dare l'approvazione.
La dispersione su provider indipendenti cambia quanti indirizzi distinti un'operazione deve raggiungere, la ridondanza assorbe la perdita di uno di essi, e un'impronta ancorata è verificabile da chi la chiede. La cifratura resta il primo passo. Smette di essere l'unico.
Perché adesso
La domanda le arriva dai suoi clienti prima che dall'autorità.
I buyer enterprise mettono ormai la sovranità nei capitolati d'acquisto, e la risposta che vogliono non è una promessa su chi detiene i byte. Questionari, audit, valutazioni d'impatto dei trasferimenti: chiedono tutti la stessa cosa con parole diverse, e gran parte delle ore se ne va nel riformulare ciò che non può dimostrare. Le sanzioni sono passate dalla teoria alla pratica, e la responsabilità resta sua chiunque detenesse i byte. La stessa normativa indica la via d'uscita: quando i dati esposti sono inintelligibili, una violazione smette di essere una lettera a ogni suo cliente. L'infrastruttura dati sovrana è la risposta verso cui convergono gli obblighi, e ciò che manca è un'architettura che la produca sui cloud che già utilizza.
485 mln €
già inflitti, per aver raggiunto dati europei dall’esterno dell’UE. Sei mesi per rimediare, altrimenti i trasferimenti si fermano. Dove si trovassero i server non era la questione
Art. 34
nessun obbligo di informare ogni persona interessata, quando i dati esposti erano inintelligibili. La notifica all'autorità resta dovuta
Casi d'uso
Tre modi in cui le arriva sulla scrivania. Una sola cosa da sistemare.
Obblighi diversi, team diversi, perimetri diversi. In ognuno di essi il lavoro che smette di fare è lo stesso: sostenere che i suoi dati sono protetti, invece di mostrarlo.
Caso d'uso 01
Una richiesta al suo provider restituisce solo frammenti cifrati.
Per i team i cui obblighi e la cui infrastruttura si trovano ai due lati opposti di un confine.
Compliance dei trasferimenti transfrontalieri di dati
Caso d'uso 02
Archivi i file dei suoi utenti, che nessun provider può aprire.
I file caricati dai suoi utenti, cifrati nel suo processo prima di uscirne, illeggibili per ogni provider che li conserva.
Cifrare i dati degli utenti prima dell'upload
Caso d'uso 03
Perda un provider. Mantenga il file.
Ne stacchi uno e il file torna comunque. Dimostrabile durante una chiamata, non una clausola in un contratto.
Sovranità dei dati senza cambiare provider
Sviluppatori
Rilasci storage sovrano per architettura. Senza scrivere una riga di crittografia.
Installi l'SDK, lo punti sui provider che già paga, rilasci: niente sopra o sotto deve cambiare.
import { readFile } from "node:fs/promises";
import { DataPrismKey, DEFAULT_ENCRYPTION } from "@dataprism/sdk/crypto";
import { CloudStandard } from "@dataprism/sdk/standard";
import { FilePipeline } from "@dataprism/sdk/files";
// Client, providers, project and key secret, one config file in your project:
// docs.dataprism.co/sdk/client
import { client, providers, project, secret } from "./dataprism";
// Create a project: an encrypted namespace you control
const key = DataPrismKey.fromSecret(secret, DEFAULT_ENCRYPTION);
const standard = new CloudStandard(key);
const { cloudId } = await client.prism(standard).create(project);
// Upload: encrypted on this machine, dispersed with redundancy,
// integrity anchored on a public registry
const bytes = await readFile("contract.pdf");
const pipeline = new FilePipeline({ standard, execution: client.execution, cloudId, providers });
await pipeline.upload("contract.pdf", bytes, {
chunkSize: 65_536,
dataShards: 7,
parityShards: 3,
});Dimostrato, non promesso
Lasci verificare ai suoi revisori, dal primo giorno.
Cifrati, frammentati, dispersi: niente di tutto questo chiede la sua fiducia, e niente chiede la nostra. I modelli di affidabilità qui sotto mostrano cosa garantisce l'architettura, e il registro che la applica è pubblico: un revisore può esaminarlo senza una chiamata preliminare. La differenza rispetto a ogni fornitore usato finora: questa volta le chiavi e l'intero processo restano da una parte sola, ed è la sua.
-
Paper di ricerca
Il design da un capo all'altro, con garanzie formali e modelli di affidabilità che il suo team può mettere alla prova.
-
Contratti verificabili
Il registro è pubblico e documentato, fin nel dettaglio di come si legge ogni record.
Costruito su un'architettura di sicurezza verificabile
Cifratura lato client
Ciò che lascia i suoi sistemi è già illeggibile, ovunque finisca.
Nessun nuovo vendor lock-in
I suoi provider restano suoi, sostituibili e sotto contratto.
Un solo SDK da integrare
Un solo SDK TypeScript, nessuna crittografia che il suo team debba implementare correttamente.
Aperto per costruzione
Docs pubbliche, codice verificabile, ricerca ancora in arrivo.
Per iniziare
Abbia la risposta pronta prima della prossima revisione.
Porti storage sovrano, illeggibile, inarrestabile e dimostrabile sui bucket che già ha, senza cambiare un solo provider. Lo mappiamo sulla sua architettura insieme a Lei.
30 minuti. Il suo sistema o il suo questionario, niente slide.