Abrimos un design partner program. Ver el programa

DESARROLLADORES

Lance almacenamiento soberano por arquitectura. Sin escribir una línea de criptografía.

Un solo SDK de cifrado del lado del cliente, en TypeScript: instálelo, apúntelo al object storage que ya opera y lance. El cifrado, la dispersión y el anclaje público ocurren detrás de una API limpia, así que nada de eso es código que usted escriba, mantenga o defienda en una revisión de seguridad. Sus usuarios solo ven ficheros.

Leer la documentación Ver ejemplos

INICIO RÁPIDO

Instale, apunte, lance.

Inicialice un cliente, cree un proyecto, suba un fichero, vuelva a leerlo. Todo lo que hay por debajo de la línea de la API, la derivación de claves, la división en bloques, la redundancia, el anclaje, es código que usted nunca escribe, ni prueba, ni mantiene parcheado. Y cuando su revisión de seguridad pregunte qué hay realmente dentro de esas llamadas, la siguiente sección es la respuesta.

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);

BAJO EL CAPÓ

Cuatro etapas. Sin magia.

Antes de que despliegue una capa de cifrado, alguien de su lado preguntará exactamente qué sale de la máquina y qué pasa cuando falla un proveedor. Este es el pipeline que hay detrás de upload(), etapa por etapa, con un enlace a la página de documentación que recoge todo el detalle de cada una. Suficiente para responder a esa revisión sin leer nuestro código fuente.

  1. 01. DIVISIÓN EN BLOQUES

    División en bloques definida por el contenido

    Edite un fichero grande y vuelva a subirlo: solo viajan de nuevo las partes que realmente cambiaron. Los ficheros se cortan en fronteras naturales del contenido, no en desplazamientos fijos, así que una inserción no vuelve a trocear todo lo que viene detrás. Obtiene resubidas del tamaño del delta sin mantener un formato de diff propio.

    La división en bloques, en la documentación del pipeline de ficheros
  2. 02. CIFRADO

    Cifrado convergente, en su máquina

    Cada chunk se cifra en su máquina antes de que nada salga de ella: ningún servicio de claves que levantar, nada que depositar en garantía. La derivación es determinista, así que un contenido sin cambios se reconoce como ya almacenado: un reenvío mueve solo lo que ha cambiado de verdad, y un contenido idéntico ocupa su almacenamiento una sola vez, no una vez por copia.

    El cifrado convergente, en la documentación del pipeline de ficheros
  3. 03. DISPERSIÓN

    Redundancia entre proveedores independientes

    Los bloques cifrados se expanden con la redundancia que usted elija y se dispersan entre los proveedores independientes que haya configurado, así que la caída de un proveedor, o un proveedor que cierre su cuenta, sigue siendo un no evento hasta ese nivel de redundancia. Ninguna ruta de conmutación propia que escribir, ensayar y mantener sincronizada.

    La redundancia, en la documentación del pipeline de ficheros
  4. 04. ANCLAJE

    Un índice sellado, anclado en un registro público

    Lo que se ancla es un índice cifrado de tamaño constante, sea cual sea el tamaño del fichero, y su integridad no se apoya en ningún operador, tampoco en nosotros: las lecturas reconstruyen sus datos a partir de cualquier quórum de fragmentos y descifran en local. Enseñar que un fichero no se alteró es entonces una comprobación que ejecuta quien pregunta, no un endpoint que usted tenga que construir y mantener.

    Prisms y anclaje, en la documentación
UN CICLO DE VIDA DEL BORRADO QUE PUEDE ENSEÑAR

Borrado significa enumerado, y después borrado

Cuando un cliente o un regulador pregunte si borrado significa de verdad borrado, puede señalar un ciclo de vida documentado en lugar de una casilla de un panel: el borrado está especificado en la referencia del SDK para enumerar cada fragmento que un fichero dejó tras de sí, eliminar cada uno en su proveedor e informar de todo lo que falló, proveedor por proveedor. Ese es un trabajo de conciliación que usted no tiene que escribir ni mantener.

El ciclo de vida del borrado, en la referencia del SDK

CÓMO PIENSA EL SDK

Un solo SDK de cifrado del lado del cliente, tres garantías.

LAS CLAVES SE QUEDAN CON USTED

Todo lo que sale es texto cifrado

Las claves de chunk se derivan del propio contenido, lo que abarata reenviar datos sin cambios. El índice que los ensambla se sella con una clave derivada de un secreto que usted controla, y ninguna de las dos se nos envía nunca: todo lo que el SDK manda hacia fuera ya va cifrado. Añadir un proveedor nunca amplía lo que alguien puede leer.

Lo que cada actor puede y no puede ver se detalla en nuestra arquitectura de seguridad verificable.

INVISIBLE PARA LOS USUARIOS

Ninguna criptografía expuesta a los usuarios finales

A sus usuarios no se les expone nunca ninguna fontanería criptográfica. Las claves y su ejecución se quedan detrás del login y la interfaz de su propio producto, así que no hay ningún paso nuevo en su onboarding ni nada extra que su equipo de soporte tenga que responder. Para ellos, es simplemente almacenamiento que resulta ser ilegible para todos los demás.

DOCUMENTADO DE EXTREMO A EXTREMO

Documentación completa y pública

Cada capa está documentada en abierto en docs.dataprism.co: la referencia del SDK, el pipeline de ficheros, los contratos, ejemplos ejecutables en Node.js y Next.js. Si sabe leer un README, puede evaluarnos antes de hablar con nadie de ventas.

DESTINOS DE INTEGRACIÓN

Apúntelo al almacenamiento que ya opera.

Ningún proveedor de almacenamiento nuevo que incorporar, ninguna migración de infraestructura, ningún protocolo que aprender: aterricen donde aterricen los fragmentos, el pipeline que hay detrás del SDK sigue siendo el mismo. Añadir o quitar un proveedor es un cambio de configuración, no un proyecto.

  • AWS S3

    Los buckets que ya opera se convierten en destinos de dispersión para fragmentos cifrados.

  • CLOUDFLARE R2

    Un proveedor independiente que amplía el conjunto de dispersión.

  • SCALEWAY

    Object storage europeo como destino de dispersión independiente.

  • ON-PREM

    El object storage que opera usted mismo entra en el mismo conjunto.

Empiece por la documentación.

Esta página muestra la forma del sistema. La documentación baja hasta el fondo: la referencia completa del SDK, el interior del pipeline y ejemplos ejecutables en Node.js y Next.js.

Leer la referencia del SDK Hablar con un ingeniero