Unlesbar
Die Verschlüsselung erfolgt vor dem Upload. Niemand kann Ihre Daten lesen, wir eingeschlossen. Wenn also jemand fragt, wer das sonst noch lesen kann, ist die Antwort eine Architektur statt eines Versprechens: nicht Ihre Anbieter, nicht wir.
Souveräne Dateninfrastruktur
Ihre Daten sollten nirgends sein.
Nirgends lesbar, und nirgends neu: Ihre Daten bleiben bei den Cloud-Diensten Ihrer Wahl, aber Sie holen sich die Souveränität darüber zurück.
Das Problem
Die Verantwortung bleibt lokal. Der Zugriff nicht.
Cloud-Speicher, wie es ihn heute gibt, kann nicht feststellen, wer die gespeicherten Daten lesen kann. Anbieter verschlüsseln Dateien mit Schlüsseln, die sie selbst behalten, und ihre Systeme entschlüsseln auf Anforderung: für jeden Mitarbeiter mit den passenden Rechten, für jede Behörde, die es verlangt. Das Schloss ist echt. Es gehört dem Betreiber, ebenso das Protokoll darüber, wer es geöffnet hat.
Die Anordnung muss nicht von der Aufsichtsbehörde kommen, der die Daten unterstehen. Ein Anbieter mit Sitz im Ausland untersteht seinem eigenen Recht, wo auch immer seine Server stehen, und die Offenlegung folgt hinterher, wenn überhaupt. Meldung, Bußgeld und der Brief an die betroffenen Kunden bleiben bei der Organisation, die die Daten erhoben hat, gleich wer die Bytes hielt.
Jede Bewertung endet gleich: mit der Beschreibung einer Kontrolle, die bei jemand anderem liegt.
Lesen Sie, warum Verschlüsselung im ruhenden Zustand nicht Vertraulichkeit bedeutet.
Die Lösung
Behalten Sie jeden Anbieter. Ändern Sie, was er herausgeben kann.
DataPrism ist ein overlay auf vorhandenem Object Storage. Dateien werden clientseitig verschlüsselt, bevor sie den Perimeter verlassen, in Fragmente zerlegt und über unabhängige Instanzen und Anbieter verteilt. Kein Anbieter hält den Schlüssel, deshalb bringt eine Anfrage bei einem von ihnen nur Fragmente hervor, die niemand öffnen kann, und die Zahl der getrennten Adressen, die eine Anfrage erreichen müsste, wird zur genannten Größe statt zur Annahme.
Ein versiegelter Index der Datei wird in einem öffentlichen Register verankert, von konstanter Größe unabhängig von der Dateigröße: kein Inhalt und nichts Lesbares gelangt je dorthin, und ein Prüfer kann den Eintrag direkt abrufen. Es gibt keine Plattform, auf die migriert wird: dieselben Anbieter, dieselben Regionen, dieselben Rechnungen. Die Daten werden durch die Pipeline neu geschrieben, in Konten, die bereits Ihre sind.
Sehen Sie, wie clientseitige Verschlüsselung zu öffentlich prüfbarem Nachweis wird.
Jede Größenordnung
Ein Dokument oder alle Daten. Gleiche Eigenschaften.
Die Einführung beginnt dort, wo sie sich lohnt: bei allem, was ab jetzt geschrieben wird, oder bei einem bestehenden Bereich, der einmal durch die Pipeline läuft. Nichts muss neu gebaut werden, wenn der Umfang wächst, und ein einzelnes entscheidendes Dokument verhält sich genau wie Millionen Datensätze.
Die Einführung braucht kein Programm, keinen Budgetzyklus und keinen Lenkungsausschuss, bevor sich etwas verbessert: Zuerst wird der am stärksten exponierte Bereich abgedeckt, gezeigt und von dort erweitert. Und wo Pipelines Daten erfassen müssen, ohne sie lesen zu können, kann dieselbe Infrastruktur auf blinde Datenerfassung ausgelegt werden: erfassen, ohne offenzulegen.
Drei Eigenschaften
Unlesbar. Unaufhaltsam. Belegbar.
Drei Eigenschaften, die Sie von der Architektur erben, damit niemandem vertraut werden muss, sie einzuhalten.
Unaufhaltsam
Einen Anbieter durch einen Ausfall, eine Preisänderung oder eine Weigerung, Sie weiter zu bedienen, zu verlieren, ist kein Szenario mehr, um das Sie herumplanen müssen: jede Datei wird fragmentiert und über unabhängige Anbieter verteilt, mit eingebauter Redundanz.
Belegbar
Weisen Sie einem Dritten nach, dass eine Datei existiert und unverändert ist, ohne sie zu öffnen und ohne dass jemand für Sie bürgt: die Integrität wird in einem öffentlichen Register als Fingerabdruck konstanter Größe verankert, unabhängig von der Dateigröße.
Schon verschlüsselt?
Verschlüsselung löst das erste Problem. Nicht die dahinter.
Verschlüsselung vor dem Upload hindert den Anbieter daran, die Daten zu lesen. Das ist der schwierige Teil, er lohnt sich, und genau dort beginnt auch diese Pipeline. Dort hören die meisten Architekturen aber auch auf, und drei Expositionen bleiben stehen.
-
01
Eine vollständige Kopie liegt weiterhin an einer Adresse.
Was diese Adresse erreicht, erreicht das Ganze, in einem einzigen Vorgang. Heute abgegriffene verschlüsselte Daten lassen sich unbegrenzt aufbewahren, und Kryptografie, die heute hält, hält nicht für immer. Massenerfassung beruht genau auf dieser Annahme: alles nehmen, aufbewahren, später lesen.
-
02
Verschlüsselung ist keine Verfügbarkeit.
Ein gesperrtes Konto, ein Ausfall, geänderte Bedingungen oder ein Lösegeld nehmen die Daten mit, mit oder ohne Schlüssel. Wer jedes Byte hält, kann es auch nicht mehr herausgeben.
-
03
Schlüsselverwahrung lässt sich nicht nachweisen.
Das ist eine Aussage über eine interne Konfiguration, und der Beleg dafür ist das Wort des Betreibers. Nichts daran kann prüfen, wer am Ende freigeben muss.
Verteilung über unabhängige Anbieter ändert, wie viele getrennte Adressen ein Vorgang erreichen muss, Redundanz fängt den Ausfall eines von ihnen ab, und ein verankerter Fingerabdruck ist für jeden Fragenden prüfbar. Verschlüsselung bleibt der erste Schritt, aber nicht mehr der einzige.
Warum jetzt
Die Frage erreicht Sie von Ihren Kunden, bevor sie von Ihrer Aufsichtsbehörde kommt.
Einkäufer in Unternehmen schreiben Souveränität inzwischen in die Beschaffung, und die Antwort, die sie erwarten, ist kein Versprechen darüber, wer die Bytes hält. Sicherheitsfragebögen, Audits, Transfer-Folgenabschätzungen: alle fragen dasselbe mit anderen Worten, und die meisten Stunden gehen dafür drauf, erneut zu formulieren, was Sie nicht zeigen können. Sanktionen sind von der Theorie in die Praxis gewandert, und die Haftung bleibt bei Ihnen, wer auch immer die Bytes gehalten hat. Dieselbe Verordnung benennt den Ausweg: wenn die offengelegten Daten unlesbar sind, ist eine Verletzung kein Brief mehr an jeden Kunden, den Sie haben. Souveräne Dateninfrastruktur ist die Antwort, auf die Vorgaben zulaufen, und was fehlt, ist eine Architektur, die sie auf den Clouds erzeugt, die Sie bereits betreiben.
485 Mio. €
bereits verhängt, dafür, EU-Daten von außerhalb der EU aus erreicht zu haben. Sechs Monate zur Abhilfe, sonst enden die Übermittlungen. Wo die Server standen, war nicht die Frage
Art. 34
keine Pflicht, jede betroffene Person zu benachrichtigen, wenn die offengelegten Daten unlesbar waren. Die Meldung an die Aufsichtsbehörde bleibt bestehen
Anwendungsfälle
Drei Wege, auf denen es auf Ihrem Schreibtisch landet. Eine Sache zu lösen.
Andere Pflichten, andere Teams, andere Bereiche. In jedem einzelnen entfällt dieselbe Arbeit: zu argumentieren, dass Ihre Daten geschützt sind, statt es zu zeigen.
Anwendungsfall 01
Eine Anordnung an Ihren Anbieter bringt nur verschlüsselte Fragmente.
Für Teams, deren Pflichten und deren Infrastruktur auf verschiedenen Seiten einer Grenze liegen.
Compliance bei grenzüberschreitender Datenübermittlung
Anwendungsfall 02
Nutzerdateien speichern, die kein Anbieter öffnen kann.
Was Ihre Nutzer hochladen, in Ihrem Prozess verschlüsselt bevor es ihn verlässt, unlesbar für jeden Anbieter, der es speichert.
Nutzerdaten vor dem Upload verschlüsseln
Anwendungsfall 03
Einen Anbieter verlieren. Die Datei behalten.
Trennen Sie einen ab, und die Datei kommt trotzdem zurück. In einem Gespräch vorführbar, keine Vertragsklausel.
Datensouveränität ohne Anbieterwechsel
Entdecken Sie Anwendungsfälle für den Schutz sensibler Daten
Entwickler
Souveränen Speicher per Architektur ausliefern. Ohne eine Zeile Kryptografie zu schreiben.
SDK installieren, auf die Anbieter richten, für die Sie ohnehin zahlen, ausliefern: darüber und darunter muss sich nichts ändern.
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,
});Belegt, nicht versprochen
Lassen Sie Ihre Prüfer es nachsehen, vom ersten Tag an.
Verschlüsselt, fragmentiert, verteilt: nichts davon verlangt Ihr Vertrauen, und nichts davon unseres. Die Zuverlässigkeitsmodelle unten zeigen, was die Architektur garantiert, und das Register, das sie durchsetzt, ist öffentlich: ein Prüfer kann es ohne vorheriges Gespräch durchgehen. Der Unterschied zu allen bisher genutzten Anbietern: diesmal bleiben die Schlüssel und der gesamte Ablauf auf einer Seite, und das ist Ihre.
-
Forschungspapier
Das Design von Anfang bis Ende, mit formalen Garantien und Zuverlässigkeitsmodellen, die Ihr eigenes Team infrage stellen kann.
-
Überprüfbare Verträge
Das Register ist öffentlich und dokumentiert, bis hin dazu, wie jeder Eintrag gelesen wird.
Aufgebaut auf einer überprüfbaren Sicherheitsarchitektur
Clientseitige Verschlüsselung
Was Ihre Seite verlässt, ist bereits unlesbar, wo immer es landet.
Kein neuer Vendor-Lock-in
Ihre Anbieter bleiben Ihre, bleiben austauschbar und unter Vertrag.
Ein SDK zu integrieren
Ein TypeScript-SDK, keine Kryptografie, die Ihr Team richtig hinbekommen muss.
Offen von Grund auf
Öffentliche Docs, prüfbarer Code, Forschung folgt noch.
Loslegen
Haben Sie die Antwort bereit, bevor die nächste Prüfung kommt.
Bringen Sie souveränen, unlesbaren, unaufhaltsamen und belegbaren Speicher in die Buckets, die Sie bereits haben, ohne einen einzigen Anbieter zu wechseln. Wir bilden das gemeinsam mit Ihnen auf Ihre Architektur ab.
30 Minuten. Ihr System oder Ihr Fragebogen, keine Folien.