Stiamo aprendo un design partner program. Scopra il programma

SVILUPPATORI

Rilasci storage sovrano per architettura. Senza scrivere una riga di crittografia.

Un solo SDK di cifratura lato client, in TypeScript: lo installi, lo punti sull'object storage che già gestisce, rilasci. Cifratura, dispersione e ancoraggio pubblico avvengono dietro un'API pulita, quindi non è codice che scrive Lei, che mantiene Lei o che deve difendere in una revisione di sicurezza. I suoi utenti vedono solo file.

Legga la documentazione Veda gli esempi

QUICKSTART

Installi, punti, rilasci.

Inizializzi un client, crei un progetto, carichi un file, lo rilegga. Tutto ciò che sta sotto la linea dell'API, derivazione delle chiavi, chunking, ridondanza, ancoraggio, è codice che non scrive, non testa e non deve tenere aggiornato. E quando la sua revisione di sicurezza chiede che cosa c'è davvero dentro quelle chiamate, la risposta è la sezione successiva.

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,
});
const { index } = await pipeline.upload("contract.pdf", bytes, {
  chunkSize: 65_536,
  dataShards: 7,
  parityShards: 3,
});

// Download: shards fetched in parallel, reconstructed from any
// quorum, decrypted locally
const restored = await pipeline.download(index);

SOTTO IL COFANO

Quattro fasi. Nessuna magia.

Prima di rilasciare un livello di cifratura, qualcuno dalla sua parte chiederà esattamente che cosa lascia la macchina, e che cosa succede quando un provider si guasta. Ecco la pipeline dietro upload(), fase per fase, con un link alla pagina della documentazione che ne riporta tutto il dettaglio. Abbastanza per rispondere a quella revisione senza leggere il nostro sorgente.

  1. 01. CHUNKING

    Chunking definito dal contenuto

    Modifichi un file di grandi dimensioni e lo ricarichi: viaggiano di nuovo solo le parti che sono davvero cambiate. I file vengono tagliati sui confini naturali del contenuto, non a offset fissi, quindi un inserimento non ritaglia tutto ciò che viene dopo. Ottiene ricaricamenti grandi quanto il delta, senza mantenere un formato di diff suo.

    Il chunking, nella documentazione della file pipeline
  2. 02. CIFRATURA

    Cifratura convergente, sulla sua macchina

    Ogni chunk viene cifrato sulla sua macchina prima che qualsiasi cosa ne esca: nessun servizio di chiavi da allestire, niente da depositare. La derivazione è deterministica, quindi un contenuto invariato viene riconosciuto come già archiviato: un nuovo invio sposta solo ciò che è davvero cambiato, e un contenuto identico occupa il suo storage una sola volta, non una volta per copia.

    La cifratura convergente, nella documentazione della file pipeline
  3. 03. DISPERSIONE

    Ridondanza su provider indipendenti

    I chunk cifrati vengono espansi con la ridondanza che sceglie Lei e dispersi sui provider indipendenti che ha configurato, così l'interruzione di un provider, o un provider che chiude il suo account, resta un non evento fino a quella ridondanza. Nessun percorso di failover suo da scrivere, provare e tenere allineato.

    La ridondanza, nella documentazione della file pipeline
  4. 04. ANCORAGGIO

    Un indice sigillato, ancorato su un registro pubblico

    Ciò che viene ancorato è un indice cifrato di dimensione costante, qualunque sia la dimensione del file, e la sua integrità non poggia su nessun operatore, noi compresi: le letture ricostruiscono i suoi dati da un qualsiasi quorum di frammenti e decifrano in locale. Mostrare che un file non è stato alterato è allora una verifica che esegue chi la chiede, non un endpoint che deve costruire e mantenere Lei.

    I Prism e l'ancoraggio, nella documentazione
UN CICLO DI VITA DELLA CANCELLAZIONE CHE PUÒ MOSTRARE

Cancellato significa enumerato, poi cancellato

Quando un cliente o un'autorità chiede se cancellato significa davvero cancellato, può indicare un ciclo di vita documentato invece di una casella spuntata in una dashboard: la cancellazione è specificata nella reference dell'SDK per enumerare ogni frammento lasciato da un file, rimuoverlo presso il suo provider e segnalare tutto ciò che non è riuscito, provider per provider. È un lavoro di riconciliazione che non deve scrivere e mantenere Lei.

Il ciclo di vita della cancellazione, nella reference dell'SDK

COME RAGIONA L'SDK

Un solo SDK di cifratura lato client, tre garanzie.

LE CHIAVI RESTANO A LEI

Tutto ciò che esce è testo cifrato

Le chiavi dei chunk derivano dal contenuto stesso, ed è questo che rende economico rinviare dati invariati. L'indice che li assembla è sigillato con una chiave derivata da un segreto che lei controlla, e nessuna delle due ci viene mai inviata: tutto ciò che l'SDK manda all'esterno è già cifrato. Aggiungere un provider non allarga mai ciò che qualcuno può leggere.

Che cosa può e non può vedere ogni attore è illustrato in la nostra architettura di sicurezza verificabile.

INVISIBILE PER GLI UTENTI

Nessuna crittografia esposta agli utenti finali

Nessuna impalcatura crittografica viene mai esposta ai suoi utenti. Chiavi ed esecuzione restano dietro il login e l'interfaccia del suo prodotto, quindi non c'è nessun passaggio nuovo nel suo onboarding e niente in più a cui il suo team di supporto debba rispondere. Per loro è semplicemente storage che si dà il caso sia illeggibile per chiunque altro.

DOCUMENTATO DALL'INIZIO ALLA FINE

Documentazione completa e pubblica

Ogni livello è documentato allo scoperto su docs.dataprism.co: la reference dell'SDK, la file pipeline, i contratti, esempi eseguibili in Node.js e Next.js. Se sa leggere un README, può valutarci prima ancora di parlare con un commerciale.

TARGET DI INTEGRAZIONE

Lo punti sullo storage che già gestisce.

Nessun nuovo fornitore di storage da attivare, nessuna migrazione di infrastruttura, nessun protocollo da imparare: ovunque finiscano i frammenti, la pipeline dietro l'SDK resta la stessa. Aggiungere o togliere un provider è una modifica di configurazione, non un progetto.

  • AWS S3

    I bucket che già gestisce diventano target di dispersione per i frammenti cifrati.

  • CLOUDFLARE R2

    Un provider indipendente che allarga l'insieme di dispersione.

  • SCALEWAY

    Object storage europeo come target di dispersione indipendente.

  • ON-PREM

    L'object storage che gestisce in proprio entra nello stesso insieme.

Cominci dalla documentazione.

Questa pagina mostra la forma del sistema. La documentazione scende fino in fondo: la reference completa dell'SDK, gli interni della pipeline ed esempi eseguibili in Node.js e Next.js.

Legga la reference dell'SDK Parli con un ingegnere