Ilegible
El cifrado ocurre antes de la subida. Nadie puede leer sus datos, nosotros incluidos. Así, cuando alguien pregunta quién más puede leer esto, la respuesta es una arquitectura y no una promesa: ni sus proveedores, ni nosotros.
Infraestructura de datos soberana
Sus datos, en ninguna parte.
En ninguna parte legible, y en ningún sitio nuevo: sus datos siguen en los servicios cloud que usted elija, pero recupera la soberanía sobre ellos.
El problema
La responsabilidad es local. El acceso, no.
El almacenamiento cloud tal y como existe hoy no permite establecer quién es capaz de leer los datos que aloja. Los proveedores cifran los ficheros con claves que guardan en su propio lado, y sus sistemas descifran a demanda: para cualquier empleado con el acceso adecuado, para cualquier autoridad que lo imponga. La cerradura es real. Pertenece al operador, y el registro de quién la abrió también.
La orden no tiene por qué venir de la autoridad de control que rige esos datos. Un proveedor con sede en el extranjero responde ante su propia ley estén donde estén sus servidores, y la revelación llega después, si es que llega. La notificación, la multa y la carta a los clientes afectados se quedan en la organización que recogió los datos, tuviera quien tuviera los bytes.
Toda evaluación acaba igual: describiendo un control que está en manos ajenas.
Lea por qué cifrado en reposo no significa privado.
La solución
Conserve a todos sus proveedores. Cambie lo que pueden entregar.
DataPrism es un overlay sobre el object storage existente. Los ficheros se cifran del lado del cliente antes de salir del perímetro, se dividen en fragmentos y se dispersan entre instancias y proveedores independientes. Ningún proveedor tiene la clave, así que una solicitud presentada ante cualquiera de ellos solo produce fragmentos que nadie puede abrir, y el número de direcciones distintas a las que tendría que llegar pasa a ser una cifra declarada en lugar de una suposición.
Un índice sellado del fichero queda anclado en un registro público, de tamaño constante sea cual sea el fichero: allí no va ningún contenido ni nada legible, y quien revisa puede recuperar el registro directamente. No hay plataforma a la que migrar: los mismos proveedores, las mismas regiones, las mismas facturas. Los datos se reescriben a través del pipeline, en cuentas que ya son suyas.
Vea cómo el cifrado del lado del cliente se convierte en prueba pública.
A cualquier escala
Un documento o todos los datos. Las mismas propiedades.
La adopción empieza donde merece la pena empezar: en todo lo que se escriba a partir de ahora, o en un perímetro existente que pasa una vez por el pipeline. Nada hay que rediseñar a medida que el alcance crece, y un documento decisivo se comporta igual que millones de registros.
La adopción no exige un programa, un ciclo presupuestario y un comité de dirección antes de que algo mejore: primero se cubre el perímetro más expuesto, se demuestra y se extiende desde ahí. Y donde los pipelines deben recoger datos sin poder leerlos, la misma infraestructura puede diseñarse para la ingesta ciega: recogida sin exposición.
Tres propiedades
Ilegible. Imparable. Demostrable.
Tres propiedades que hereda de la arquitectura, de modo que no hay que confiar en nadie para que las mantenga.
Imparable
Perder a un proveedor por una caída, un cambio de precio o una negativa a prestarle servicio deja de ser un escenario que haya que anticipar: cada fichero se fragmenta y se dispersa entre proveedores independientes, con redundancia integrada.
Demostrable
Demuestre a un tercero que un fichero existe y no ha cambiado, sin abrirlo y sin que nadie responda por usted: la integridad queda anclada en un registro público como una huella de tamaño constante, sea cual sea el tamaño del fichero.
¿Ya cifra?
El cifrado resuelve el primer problema. No los que hay detrás.
Cifrar antes de la subida impide que el proveedor lea los datos. Esa es la parte difícil, merece la pena y es donde también empieza este pipeline. Es además donde se detienen la mayoría de las arquitecturas, y quedan tres exposiciones en pie.
-
01
Una copia completa sigue estando en una sola dirección.
Lo que llega a esa dirección llega a todo, en una única operación. Los datos cifrados que se tomen hoy pueden guardarse indefinidamente, y la criptografía que aguanta ahora no aguanta siempre. La recogida masiva se apoya justo en esa premisa: llevárselo todo, guardarlo, leerlo más tarde.
-
02
El cifrado no es disponibilidad.
Una cuenta suspendida, una caída, un cambio de condiciones o un rescate se llevan los datos consigo, con claves o sin ellas. Quien tiene todos los bytes es también quien puede dejar de devolverlos.
-
03
La custodia de claves no se puede demostrar.
Es una afirmación sobre una configuración interna, y la prueba es la palabra del propio operador. Nada de eso lo puede comprobar quien tiene que dar el visto bueno.
La dispersión entre proveedores independientes cambia a cuántas direcciones distintas tiene que llegar una operación, la redundancia absorbe la pérdida de uno de ellos, y una huella anclada la comprueba quien pregunta. El cifrado sigue siendo el primer paso. Deja de ser el único.
Por qué ahora
La pregunta le llega de sus clientes antes que de su autoridad de control.
Los compradores corporativos ya incluyen la soberanía en sus procesos de compra, y la respuesta que quieren no es una promesa sobre quién guarda los bytes. Cuestionarios, auditorías, evaluaciones de impacto de las transferencias: todos preguntan lo mismo con otras palabras, y la mayor parte de las horas se va en repetir lo que no puede demostrar. Las sanciones han pasado de la teoría a la práctica, y la responsabilidad sigue siendo suya quienquiera que tuviese los bytes. La misma norma señala la salida: cuando los datos expuestos son ininteligibles, una brecha deja de ser una carta a todos y cada uno de sus clientes. La infraestructura de datos soberana es la respuesta hacia la que convergen los mandatos, y lo que falta es una arquitectura que la produzca sobre los clouds que ya utiliza.
485 M€
ya impuestos, por acceder a datos europeos desde fuera de la UE. Seis meses para corregirlo, o las transferencias se detienen. Dónde estaban los servidores no era la cuestión
Art. 34
sin obligación de informar a cada persona afectada cuando los datos expuestos eran ininteligibles. La notificación a la autoridad de control se mantiene
Casos de uso
Tres formas de que acabe en su mesa. Una sola cosa que resolver.
Distintas obligaciones, distintos equipos, distintos perímetros. En todos ellos el trabajo que deja de hacer es el mismo: argumentar que sus datos están protegidos, en lugar de enseñarlo.
Caso de uso 01
Un requerimiento a su proveedor solo devuelve fragmentos cifrados.
Para equipos cuyas obligaciones y cuya infraestructura están a lados opuestos de una frontera.
Cumplimiento en transferencias internacionales de datos
Caso de uso 02
Almacene archivos de usuario que ningún proveedor puede abrir.
Los archivos que suben sus usuarios, cifrados dentro de su proceso antes de salir de él, ilegibles para cada proveedor que los almacena.
Cifrar los datos de usuario antes de la subida
Caso de uso 03
Pierda un proveedor. Conserve el archivo.
Corte uno y el archivo sigue volviendo. Demostrable en una llamada, no una cláusula en un contrato.
Soberanía de datos sin cambiar de proveedor
Desarrolladores
Lance almacenamiento soberano por arquitectura. Sin escribir una línea de criptografía.
Instale el SDK, apúntelo a los proveedores que ya paga y lance: nada por encima ni por debajo tiene que cambiar.
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,
});Demostrado, no prometido
Deje que sus auditores lo comprueben, desde el primer día.
Cifrado, fragmentado, disperso: nada de esto pide su confianza, ni pide la nuestra. Los modelos de fiabilidad que siguen muestran lo que garantiza la arquitectura, y el registro que lo hace cumplir es público, así que un auditor puede revisarlo sin una llamada con nuestros ingenieros ni una cláusula en su contrato. La diferencia con todos los proveedores en los que ha confiado hasta ahora: esta vez, las claves las tiene usted.
-
Artículo de investigación
El diseño de extremo a extremo, con garantías formales y modelos de fiabilidad que su propio equipo puede cuestionar.
Lea la investigación que hay detrás de la integridad de datos demostrable
-
Contratos verificables
El registro es público y está documentado, hasta el detalle de cómo se lee cada entrada.
Construido sobre una arquitectura de seguridad verificable
Cifrado del lado del cliente
Lo que sale de su lado ya es ilegible, allá donde acabe.
Sin nueva dependencia de proveedor
Sus proveedores siguen siendo suyos, reemplazables y bajo contrato.
Un solo SDK que integrar
Un SDK de TypeScript, sin criptografía que su equipo tenga que acertar.
Abierto por diseño
Docs públicas, código verificable, investigación aún por llegar.
Empezar
Tenga la respuesta lista antes de la próxima revisión.
Lleve almacenamiento soberano, ilegible, imparable y demostrable a los buckets que ya tiene, sin cambiar ni un proveedor. Lo trazaremos sobre su arquitectura con usted.
30 minutos. Su sistema o su cuestionario, sin diapositivas.