Wir starten ein design partner program. Zum Programm

ENTWICKLER

Souveränen Speicher per Architektur ausliefern. Ohne eine Zeile Kryptografie zu schreiben.

Ein SDK für clientseitige Verschlüsselung, in TypeScript: installieren, auf den Object Storage richten, den Sie bereits betreiben, ausliefern. Verschlüsselung, Verteilung und öffentliche Verankerung laufen hinter einer sauberen API, nichts davon ist Code, den Sie schreiben, besitzen oder in einer Sicherheitsprüfung verteidigen. Ihre Nutzer sehen einfach Dateien.

Dokumentation lesen Beispiele ansehen

QUICKSTART

Installieren, ausrichten, ausliefern.

Einen Client initialisieren, ein Projekt anlegen, eine Datei hochladen, sie wieder lesen. Alles unterhalb der API-Linie, Schlüsselableitung, Zerlegung, Redundanz, Verankerung, ist Code, den Sie nie schreiben, testen oder gepatcht halten. Und wenn Ihre Sicherheitsprüfung fragt, was tatsächlich in diesen Aufrufen steckt, ist der nächste Abschnitt die Antwort.

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

UNTER DER HAUBE

Vier Stufen. Keine Magie.

Bevor Sie eine Verschlüsselungsschicht ausliefern, wird jemand auf Ihrer Seite genau fragen, was die Maschine verlässt und was passiert, wenn ein Anbieter ausfällt. Hier ist die Pipeline hinter upload(), Stufe für Stufe, mit einem Link auf die Dokumentationsseite, die das vollständige Detail jeder Stufe trägt. Genug, um diese Prüfung zu beantworten, ohne unseren Quellcode zu lesen.

  1. 01. CHUNKING

    Inhaltsdefiniertes Chunking

    Bearbeiten Sie eine große Datei und laden Sie sie erneut hoch, dann reisen nur die Teile erneut, die sich tatsächlich geändert haben: Dateien werden an natürlichen Inhaltsgrenzen geschnitten, nicht an festen Offsets, eine Einfügung zerschneidet also nicht alles Nachfolgende neu. Sie bekommen Re-Uploads in Delta-Größe, ohne ein eigenes Diff-Format zu pflegen.

    Chunking, in der Dokumentation zur Datei-Pipeline
  2. 02. VERSCHLÜSSELUNG

    Konvergente Verschlüsselung, auf Ihrer Maschine

    Jeder Chunk wird auf Ihrer Maschine verschlüsselt, bevor irgendetwas sie verlässt: kein Schlüsselverwaltungsdienst aufzusetzen, nichts zu hinterlegen. Die Ableitung ist deterministisch, unveränderter Inhalt wird also als bereits gespeichert erkannt: ein erneuter Upload bewegt nur das, was sich wirklich geändert hat, und identischer Inhalt belegt Ihren Speicher einmal statt einmal je Kopie.

    Konvergente Verschlüsselung, in der Dokumentation zur Datei-Pipeline
  3. 03. VERTEILUNG

    Redundanz über unabhängige Anbieter

    Verschlüsselte Chunks werden um die Redundanz erweitert, die Sie wählen, und über die unabhängigen Anbieter verteilt, die Sie konfiguriert haben, ein Ausfall eines Anbieters oder ein Anbieter, der Ihr Konto fallen lässt, bleibt also bis zu dieser Redundanz ein Nichtereignis. Kein eigener Failover-Pfad, den Sie schreiben, proben und synchron halten müssen.

    Redundanz, in der Dokumentation zur Datei-Pipeline
  4. 04. VERANKERUNG

    Ein versiegelter Index, verankert in einem öffentlichen Register

    Verankert wird ein verschlüsselter Index konstanter Größe, gleich welche Dateigröße, und seine Integrität ruht auf keinem Betreiber, uns eingeschlossen: Lesezugriffe rekonstruieren Ihre Daten aus einem beliebigen Quorum von Fragmenten und entschlüsseln lokal. Zu zeigen, dass eine Datei nicht verändert wurde, ist dann eine Prüfung, die der Fragende durchführt, kein Endpunkt, den Sie bauen und betreuen müssen.

    Prisms und Verankerung, in der Dokumentation
EIN LÖSCHZYKLUS, DEN SIE VORZEIGEN KÖNNEN

Gelöscht heißt aufgelistet, dann gelöscht

Wenn ein Kunde oder eine Aufsichtsbehörde fragt, ob gelöscht wirklich gelöscht heißt, können Sie auf einen dokumentierten Ablauf verweisen statt auf ein Häkchen im Dashboard: Das Löschen ist in der SDK-Referenz so spezifiziert, dass jedes Fragment aufgelistet wird, das eine Datei hinterlassen hat, jedes einzelne bei seinem Anbieter entfernt wird und alles gemeldet wird, was fehlgeschlagen ist, Anbieter für Anbieter. Das ist eine Abgleicharbeit, die Sie nicht schreiben und nicht besitzen müssen.

Der Löschzyklus, in der SDK-Referenz

WIE DAS SDK DENKT

Ein SDK für clientseitige Verschlüsselung, drei Garantien.

SCHLÜSSEL BLEIBEN BEI IHNEN

Alles, was hinausgeht, ist Chiffretext

Chunk-Schlüssel werden aus dem Inhalt selbst abgeleitet, was den erneuten Upload unveränderter Daten günstig macht. Der Index, der sie zusammensetzt, wird mit einem Schlüssel versiegelt, der aus einem Geheimnis von Ihnen abgeleitet ist, und keiner der beiden wird je an uns gesendet: alles, was das SDK nach außen schickt, ist bereits verschlüsselt. Ein weiterer Anbieter erweitert nie, was jemand lesen kann.

Was jeder Akteur sehen kann und was nicht, steht in unserer überprüfbaren Sicherheitsarchitektur.

FÜR NUTZER UNSICHTBAR

Keine Kryptografie für Endnutzer sichtbar

Kein Kryptografie-Unterbau wird Ihren Nutzern je gezeigt. Schlüssel und Ausführung bleiben hinter dem Login und der Oberfläche Ihres eigenen Produkts, es gibt also keinen neuen Schritt in Ihrem Onboarding und nichts Zusätzliches, was Ihr Support beantworten müsste. Für sie ist es einfach Speicher, der zufällig für alle anderen unlesbar ist.

VON ENDE ZU ENDE DOKUMENTIERT

Vollständige, öffentliche Dokumentation

Jede Schicht ist offen dokumentiert auf docs.dataprism.co: die SDK-Referenz, die Datei-Pipeline, die Verträge, lauffähige Node.js- und Next.js-Beispiele. Wer eine README lesen kann, kann uns bewerten, bevor er je mit dem Vertrieb spricht.

INTEGRATIONSZIELE

Richten Sie es auf den Speicher, den Sie bereits betreiben.

Kein neuer Speicheranbieter aufzunehmen, keine Infrastrukturmigration, kein Protokoll zu lernen: Wo die Fragmente auch landen, die Pipeline hinter dem SDK bleibt dieselbe. Einen Anbieter hinzuzunehmen oder fallen zu lassen ist eine Konfigurationsänderung, kein Projekt.

  • AWS S3

    Die Buckets, die Sie bereits betreiben, werden zu Zielen für die Verteilung verschlüsselter Fragmente.

  • CLOUDFLARE R2

    Ein unabhängiger Anbieter, der die Menge der Verteilungsziele erweitert.

  • SCALEWAY

    Europäischer Object Storage als unabhängiges Verteilungsziel.

  • ON-PREM

    Object Storage, den Sie selbst betreiben, kommt in dieselbe Menge.

Mit der Dokumentation beginnen.

Diese Seite zeigt die Form des Systems. Die Dokumentation geht bis ganz nach unten: die vollständige SDK-Referenz, das Innenleben der Pipeline und lauffähige Node.js- und Next.js-Beispiele.

SDK-Referenz lesen Mit einem Ingenieur sprechen