Könnte man eine DB schreiben, die alte Daten unwiderbringlich vergisst?

Eine seltsame und eher theoretische Frage, aber ich grübele schon eine Weile, und finde keine Lösung.

Natürlich kann man eine Datenbank so schreiben, dass jeder Record ein Verfallsdatum hat, und diesen dann löscht. Was mir aber vorschwebt ist, dass selbst jemand, der eine Kopie einer alten Datenbank gemacht hat, aus dieser Kopie „verfallene“ Datensätze nicht mehr auslesen kann. Datensätze müssten also nicht nur verschlüsselt sein, der Schlüssel dürfte auch nur bis zum Verfallsdatum funktionieren.

Um überhaupt eine Chance zu haben, so etwas zu schreiben, brauchte man vermutlich eine vertrauenswürdige Instanz im Internet (in etwa wie Zertifikat-Provider o.ä.), die Schlüssel u.s.w. generieren kann. Aber selbst da hat man das Problem, dass jemand einfach einen aktuellen Schlüssel speichern und später verwenden kann, obwohl der Record schon „verfallen“ ist.

Es klingt erst einmal ziemlich unmöglich, aber vielleicht fällt euch etwas dazu ein?

Ohja, das wäre schön, irgendwann verfallen alle Wikipedia-Artikel einfach. :smiley:

MMn. geht das nur mit einer „beweglichen Blackbox mit Halbwertszeit“… also einer „Apparatur“, auf die man von außen nicht zugreifen kann, denn sobald etwas lokal angezeigt wird, kann es auch gespeichert werden. Also sobald die Daten in irgendeiner Form entschlüsselt sind.

Also zum ersten kann man sich für die Internetverbindung ja ein Cert mieten oder kaufen (das ist nur für die vertrauenswürdige Verbindung…) und für die DB-Verschlüsselung ein weiteres Privates mit Ablaufdatum (…was man für die organisatorische DB-Verschlüsselung nicht braucht) tunneln und das sogar für jeden Datensatz der erstellt wird (vgl. OTP beim Onlinebanking).
Nun ist aber die Frage, ob die Daten tatsächlich vollkommen vernichtet werden oder für Admins noch lesbar bleiben sollen. Für Letzteres wird noch ein Master-Schlüsselpaar benötigt, ansonsten kann man den Datensatz random überschreiben (shred) und dann löschen.

Das Problem ist doch, dass die Daten bei Computern in den Speicher geladen werden müssen, und wenn sie dort einmal sind, auch gespeichert werden können.

Vgl. Mission Impossible… auch die verwenden stets eine Miniatur-Bombe.

Tja… irgendwas ist immer.

Security Through Obscurity (STO) sei noch schnell in den Raum gestellt, aber das ist nicht richtig sicher. :frowning:

Wäre das nicht ein Anwendungsfall für eine Blockchain? :wink:

Man könnte dann transparent für alle ersichtlich Rekorde speichern. Diese sind entsprechend signiert und können nicht mehr in der Historie verändert werden, ohne dass die komplette Blockchain berechnet wird.

Stichwort: Blockchain as a Service.

Alternativ müsste im Bereich Signaturen gesucht werden. Wenn die Einträge in der DB eine Signatur haben, dann würde ein Dritte nicht Fakeeinstellungen hinterlegen können.

Stichwort: JWT

Schöne Grüße
Martin

Mhmhm, wenn ich das Prinzip der Blockchain richtig verstanden haben, so kann man mit ihr „sicher in die Vergangenheit blicken“.
Landei fordert aber nun, „die Zukunft zu vergessen“. Ist das nicht physikalisch unmöglich (… Suche nach/synthetisiere Diskontinuität im Raum-Zeit-Kontinuum?)

Oder anders… Warum reicht es nicht aus, die Daten der DB nach einem Zeitpunkt x einfach zu droppen?

Blockchain hat auch ein Konzept für Smart Contracts, die eine Codeausführung erlauben, wenn bestimmte Bedinungen zutreffen.

Also ich denke da gibt es viele möglichkeiten. Ggf. ist Spring Vault etwas, dass man sich anschauen könnte.

Man muss auch bedenken, hat jemand eine alte Version der DB, was passiert, wenn er das Datum seines Rechners zwei Jahre zurückstellt und dann drauf zugreift?

Deshalb denke ich, dass man auf jeden Fall einen Provider braucht, falls es überhaupt möglich ist.

Was ist den hier überhaupt der Anwendungsfall?

Wie gesagt, mich interessiert hauptsächlich der theoretische Aspekt.

Der Anwendungsfall ist, dass wir eine kleine Webseite gebastelt haben, wo jedes Teammitglied eintragen kann, ob es heute vom Büro aus oder zuhause arbeitet (und die Website zieht auch Daten vom Urlaubskalender). Die Daten sind alle nur in Memory, weil es die Befürchtung gibt, dass das Management auch an dieser Information interessiert sein könnte, wenn es erst einmal eine Datenbank gibt. Aber ohne eine Form von Speicherung wird es schwierig, das Ding etwas komfortabler zu gestalten und mehr nützliche Informationen zu erfassen. Natürlich könnte man immer nur den aktuellen „Snapshot“ abspeichern, aber selbst der wäre wesentlich einfacher abzugreifen als In-Memory-Daten.

Hab das meiste hier nur überflogen. Aber wäre MongoDb mit TTL-Flag für die einzelnen Einträge ne Option?

Ich denke eher nicht. In diesem Fall sollen ja dritte nicht sehen können, was drin steht, um damit keine unnötigen Auswertungen zu machen.

Und da es sich um ein Server im Unternehmen handelt, kann dieser ständig gesichert werden, so dass wenn in der aktuellen Version die Daten entfernt sind, können diese aus den vorherigen Snapshots wiederhergestellt werden.

Du benötigst ein Schlüsselmanagement, dass außerhalb des Systems sich befindet. Sonst kann ein Administrator mit dem Key alles entschlüsseln - Klar.

Spring Voult kann man sich anschauen, um eine externe Schlüsselverwaltung zu implementieren.

Ich stell mir gerade vor, jemand ändert das Datum auf dem Server und alle Daten sind weg.
Ich denke man bräuchte einen speziellen Server mit einer eingebauten Atomuhr, anhand der hardwarebasiert zeitbasierte Schlüssel erstellt und Daten entschlüsselt werden. Würde auch noch bei einem Stromausfall funktionieren.

Meinst du dafür gibt es einen Markt?

Ich denke nicht.