Ihre Architektur bleibt, wie sie ist
Ihre Anbieter bleiben: kein Infrastrukturprojekt zu finanzieren.
Produkt
Speicher, den Ihre eigene Cloud nicht lesen, nicht verlieren und nicht unbemerkt verändern kann.
DataPrism legt sich über die Cloud, die Sie bereits betreiben: Eine Pipeline bringt die Eigenschaft auf diesen Speicher, sodass sich ändert, was Sie über Ihre Daten belegen können, während Ihre Architektur genau so bleibt, wie sie ist.
Verschlüsselt vor dem Upload. Verteilt mit Redundanz. Öffentlich belegt.
Die Eigenschaft beginnt mit client-seitiger Verschlüsselung: Schlüssel werden auf Ihrer Seite abgeleitet, und was hinausgeht, ist bereits unlesbar. Jede Stufe unten überführt eine Zusage aus dem Versprechen eines Anbieters in ein Verhalten der Daten selbst, und genau das macht sie gegenüber einem Kunden, einem Prüfer oder einer Aufsicht belegbar. Wo Verschlüsselung vor dem Upload bereits steht, beginnen Sie mit den drei Lücken, die sie offen lässt.
-
Datei
-
Verschlüsselt
-
Fragmentiert
-
Verteilt
-
Verankert
Datei
Verschlüsselt
Fragmentiert
Verteilt
Verankert
Was es ist
Ein souveränes overlay, kein weiteres Silo.
Sie behalten Ihre Object-Storage-Anbieter. DataPrism setzt sie zu etwas zusammen, das keiner von ihnen allein bieten kann: Speicher, bei dem ein Anbieter weiterhin Ihre Bytes hält, sie aber nicht mehr lesen kann und nicht mehr darüber entscheidet, ob Sie sie behalten. Ihre Anbieter zu ersetzen hieße auch, Ihre Verträge, Ihre Regionen und Ihre Compliance-Aufstellung zu ersetzen. Das overlay lässt alle drei, wo sie sind, und macht aus einer Infrastrukturentscheidung eine Entscheidung, die Ihre Sicherheits- und Compliance-Teams allein treffen können.
Schon verschlüsselt?
Ihr Anbieter kann es nicht lesen. Das ist eines von drei Problemen.
Verschlüsseln Sie vor dem Upload mit einem Schlüssel, den Sie halten, dann ist Ihr Anbieter blind für Ihre Daten. Das ist real, und dort beginnt auch unsere eigene Pipeline. Drei Dinge bleiben genau so, wie sie waren: Er hält weiterhin alles davon, er kann Sie weiterhin daran hindern, heranzukommen, und Sie haben weiterhin nichts, was ein Prüfer ohne Sie nachprüfen kann.
Was er weiterhin hält
Ein Bestand, eine Adresse
Ihr Chiffretext liegt vollständig im Bestand eines einzigen Anbieters. Was diesen Bestand erreicht, erreicht alles davon, in einem Vorgang, und eine heute genommene Kopie lässt sich aufbewahren, bis sie sich zu lesen lohnt. Dateien werden zerlegt, verschlüsselt und mit Redundanz über die unabhängigen Anbieter verteilt, die Sie konfigurieren: Derselbe Vorgang muss jetzt so oft gelingen, wie Sie es festlegen. Diese Zahl wählen Sie, und Sie können sie nennen, wenn jemand fragt, was eine einzelne Kompromittierung erreicht.
Was er nicht auffangen kann
Vertraulichkeit ist nicht Verfügbarkeit
Ein Schlüssel, den Sie halten, ändert nichts an einem Ausfall, einem gesperrten Konto oder geänderten Bedingungen. Ihre Daten gehen dahin, wohin dieser eine Anbieter geht. Mit Redundanz verteilt, wird der Verlust eines Anbieters von der Schwelle aufgefangen, die Sie konfiguriert haben, nicht von Ihrem Wiederanlaufplan.
Was er nicht zeigen kann
Nichts, was ein Dritter prüfen kann
Die Schlüsselverwahrung ist eine Aussage über Ihre eigene Konfiguration, und der Beleg dafür ist Ihr Wort plus das Ihres Anbieters. Ein Fingerabdruck konstanter Größe in einem öffentlichen Register ist für den Fragenden prüfbar, in dem Moment, in dem er fragt, ohne dass von Ihnen etwas nötig wäre.
Nichts davon ist ein Argument dagegen, zuerst zu verschlüsseln. Es ist die Liste dessen, was Verschlüsseln offenlässt.
Wie sich die Integration anfühlt
Ein SDK zum Integrieren. Ihr Produkt verhält sich genau wie heute.
Sie fügen ein TypeScript-SDK dem Code hinzu, der Ihre Uploads bereits abwickelt. Seine Upload- und Download-Aufrufe treten an die Stelle Ihrer heutigen, die Typen kommen mit, und der Rest Ihres Produkts läuft weiter: dieselben Bildschirme, dasselbe Support-Handbuch, dasselbe Release, das Sie ohnehin ausgeliefert hätten.
- 01
Installieren
Fügen Sie das TypeScript-SDK dort ein, wo Ihr Upload-Handler bereits liegt. Es läuft in Ihrem eigenen Prozess, im Browser oder auf Ihrem Server.
- 02
Ausrichten
Richten Sie es auf den Speicher, den Sie bereits betreiben: dieselben Konten, dieselben Regionen, dieselben Verträge.
- 03
Ausliefern
Liefern Sie es in einem gewöhnlichen Release aus. Was sich ändert, ist das, was Ihre Anbieter herausgeben können, und Ihr Produkt behält sein Verhalten.
Die Entwicklerseite zeigt den Code: das SDK für clientseitige Verschlüsselung.
Warum es hält
Durch Konsens durchgesetzt, nicht durch einen Betreiber.
Jede Garantie, die ein Betreiber durchsetzt, kann ein Betreiber auch still brechen. Integrität hängt hier also nicht am Wohlverhalten irgendeines Beteiligten, unseres eingeschlossen: Der verankerte Wurzelindex wächst nie mit Ihren Daten, und jedes Fragment ist inhaltsadressiert, jede Veränderung ist damit von Ende zu Ende erkennbar. Wenn ein Kunde oder ein Prüfer fragt, woher Sie wissen, dass nichts verändert wurde, zeigen Sie einen Nachweis, den jeder prüfen kann, statt eines Berichts, den nur Ihr Anbieter erstellen kann. Und ihn zu beantworten heißt nicht, bei irgendjemandem ein Ticket zu öffnen.
Die Garantien sind formal: siehe belegbare Datenintegrität, spezifiziert in unserer Forschung. Was jeder Akteur sehen kann, steht unter Vertrauen und Sicherheit.
Was Sie bekommen
Was in Ihrem Stack landet.
Eine einzelne Kompromittierung reicht nicht
Verschlüsselte Fragmente über die Anbieter, die Sie konfigurieren: Einen Bestand zu erreichen heißt nicht mehr, Ihre Daten zu erreichen.
Sie überstehen den Verlust eines Anbieters
Ausfälle und Weigerungen von Anbietern sind keine Ereignisse mehr, um die Sie herumplanen.
Eine Prüfung, bei jedem Volumen
Ein Fingerabdruck, gleich welches Volumen dahintersteht: dieselbe einzelne Prüfung in jeder Größenordnung.
Sie würden merken, wenn sich etwas ändert
Jedes Fragment inhaltsadressiert: Veränderung tritt zutage, statt unbemerkt durchzugehen.
Verschlüsselung, die Ihr Team nicht schreibt
Ein TypeScript-SDK: kein Kryptografie-Unterbau, den Sie bauen oder in einer Prüfung verteidigen müssen.
Entdecken Sie wo der Schutz sensibler Daten greift.
FAQ
Vor jeder Demo gefragt.
- Müssen wir unsere Daten migrieren?
- Ihre Anbieter, Regionen und Verträge bleiben genau so, wie sie sind, und es gibt keine Plattform, auf die umgezogen wird. Durch die Pipeline gehen die Daten selbst, und es gibt zwei Wege zu beginnen: alles anwenden, was ab jetzt geschrieben wird, was den Bestand unberührt lässt, oder einen bestehenden Bereich einmal hindurchführen, was diese Dateien als Fragmente in dieselben Konten neu schreibt. So oder so ist es eine Änderung, die ein Team ausliefert, kein Infrastrukturprogramm mit eigenem Budget. Die Menge der Ziele gehört Ihnen und lässt sich jederzeit ändern: mehrere Konten bei einem Anbieter, mehrere Anbieter nebeneinander, Ihr eigener On-Premise-Speicher oder jede Mischung daraus. Alles, was die S3-API spricht, ist heute ein Ziel, und später eines hinzuzunehmen ist eine Konfigurationsänderung, keine zweite Integration. Das Overlay wird oben unter „Was es ist“ beschrieben.
- Wir verschlüsseln bereits clientseitig. Ersetzt DataPrism das?
- Nein, und es verlangt auch nicht, das zurückzubauen. Das SDK verschlüsselt ebenfalls auf Ihrer Seite, ein Objekt, das Sie ihm bereits verschlüsselt übergeben, durchläuft die Pipeline also als Ihr Chiffretext. Was sich ändert, ist alles nach der Verschlüsselung: an wie vielen Orten die Fragmente landen und was ein Dritter prüfen kann. Der Abschnitt oben legt dar, was Verschlüsselung allein offenlässt.
- Was landet tatsächlich im öffentlichen Register?
- Ein versiegelter Index, und sonst nichts: die Karte, die Ihre Fragmente wieder zusammensetzt, verschlüsselt mit einem Schlüssel, den wir nie erhalten. Kein Inhalt und nichts Lesbares gelangt je dorthin, jeder kann Ihre Integritätsaussage also prüfen, ohne dass Sie irgendetwas über Ihre Daten veröffentlichen. Was jeder Akteur sehen kann und was keiner von ihnen sehen kann, legt der Überblick zur Sicherheitsarchitektur dar.
- Was geschieht mit unseren Daten, wenn DataPrism aufhört?
- Ihre Dateien bleiben in Ihren eigenen Konten, und der Schlüssel bleibt auf Ihrer Seite abgeleitet, sodass die Wiederherstellung auch ohne uns trägt. Die Rekonstruktion läuft clientseitig aus den Fragmenten, die Ihre Anbieter halten, und aus dem Index im öffentlichen Register, und das SDK liest diesen Index über eine Schnittstelle, die jeder öffentliche Knoten bedienen kann. Der Wiederherstellungsweg ist eine Eigenschaft des Entwurfs und keine Zusage von uns, wie es der Überblick zur Sicherheitsarchitektur darlegt.
- Welchen Speicher kann es zusammensetzen?
- Jeden Object Storage, den Sie betreiben, wo immer er läuft: AWS, GCP, Azure oder on-prem. Die Pipeline ist überall dieselbe, und kein Teil Ihrer Integration ändert sich, wenn sich die Zusammenstellung der Anbieter ändert.