Stellen Sie sich vor, jemand schaut in einem Jahr in Ihr Protokoll und stellt eine einzige Frage: Woher wissen Sie, dass hieraus nichts verschwunden ist?
Nicht: Wurde etwas verändert. Nicht: Steht es in der Dokumentation. Sondern: Woher wissen Sie, dass am Ende nichts abgeschnitten wurde.
Auf diese Frage haben die meisten Tools keine Antwort. Wir schon, seit diesem Sommer — aber diese Antwort besteht zum Teil aus „in vier Situationen sehen wir es nicht“. Diese vier stehen hier.
Warum wir das aufschreiben
Ein Prüfpfad ist unser zentrales Versprechen. Ein Versprechen, das Sie nicht selbst nachrechnen können, ist ein Slogan.
Statt hier aufzuschreiben, was er verhindert — das machen alle anderen auch —, schreiben wir auf, was er nicht verhindert. Alles hier steht auch im Sicherheitsdokument bei unserem Quellcode. Es steht hier, weil ein Sicherheitsdokument, das niemand liest, keine Offenheit ist.
Was die Kette sehr wohl sieht
Jede Zeile im Protokoll trägt eine Berechnung über die vorherige Zeile plus das, was auf dieser Zeile geschehen ist. Die Prüfung beginnt bei Zeile null und rechnet alles neu durch.
Damit werden drei Dinge sichtbar.
Inhalt verändert. Die Neuberechnung stimmt nicht mehr.
Zeilen vertauscht. Die Reihenfolge muss strikt steigen — und bricht.
Eine Zeile mittendrin hinzugefügt oder entfernt. Die Verknüpfung zur vorherigen Zeile fällt weg.
Obendrein darf die Software selbst auf der Protokolltabelle nur anfügen und lesen. Ändern und Löschen sind nicht erlaubt.
Das ist, was ein gutes Protokoll leisten soll. Nun der Rest.
Lücke 1: das Ende abschneiden
Die Prüfung verankert nur die erste Zeile an einem festen Startpunkt und läuft dann vorwärts. Sie prüft nicht, ob die Kette bei Zeile eins beginnt, und nicht, ob das Ende einer erwarteten Zeilenzahl entspricht.
Denken Sie an ein Papier-Logbuch, aus dem jemand die letzten Seiten herausreißt. Was übrig bleibt, ist durchgehend nummeriert, sauber unterschrieben und vollständig konsistent. Genau das passiert hier: Löschen Sie die letzten Zeilen, und die Prüfung meldet schlicht, dass alles in Ordnung ist.
Hinzu kommt: Die Verknüpfungsberechnung nutzt kein Geheimnis. Wer die ganze Datenbank beschreiben kann, kann die ganze Kette neu ausrechnen.
Die Grenze, exakt: Die Kette hält gegen jeden, der nicht in die Datenbank schreiben kann — und gegen Verändern, Vertauschen und Herausnehmen aus der Mitte durch jemanden, der es kann. Nicht gegen Abschneiden am Ende.
Lücke 2: das Protokoll zu lesen hinterlässt keine Spur
Das Protokoll einzusehen erzeugt selbst keine Zeile. Wer hineingeschaut hat und wann, steht nicht darin.
Und es gibt kein Drehbuch dafür, wer gewarnt wird, wenn die Prüfung fehlschlägt oder jemand zehnmal hintereinander abgewiesen wird. Erkennung haben wir. Alarmierung nicht.
Heute ist das dadurch begrenzt, dass dieser Teil in einem einzigen Prozess läuft — ohne Netzwerkseite und ohne Trennung zwischen Administrator und Nutzer, gegen die man etwas durchsetzen könnte. In der Desktop-Version gehört es dazu.
Lücke 3: die Felder, nach denen Sie suchen, werden nicht nachgerechnet
Die Prüfung rechnet jede Zeile anhand ihres versiegelten Teils nach. Aber die einzelnen Felder, nach denen Sie suchen und die Sie zurückbekommen — Zeitpunkt, Art der Handlung, wer es tat, Dokumentname, Aktenzeichen —, werden nicht mit ihrer Kopie innerhalb dieses versiegelten Teils verglichen. Und ist ein Dokumentname leer, existiert diese Kopie gar nicht.
Jemand mit Schreibrechten kann also ein Suchfeld verändern. Ihre Suche liefert den geänderten Wert zurück, während die Prüfung weiter besteht.
Die Regel, die daraus folgt und an die wir uns selbst halten: Der versiegelte Teil ist maßgeblich; die Suchfelder sind Hilfsmittel zum Filtern. Das zu reparieren verändert die Prüfung selbst, und das tun wir nicht nebenbei.
Lücke 4: zwei Felder liegen lesbar auf der Festplatte, und Löschen berührt sie nicht
Das ist die schwerste — und der direkte Nachbar von Lücke 3: dieselben zwei Felder, dieselbe Ursache, nämlich dass sie außerhalb des versiegelten Teils liegen.
Der Dokumentname und das Aktenzeichen werden auf jeder Zeile unverschlüsselt geschrieben. In den Branchen, für die dieses Produkt gedacht ist, tragen beide routinemäßig identifizierende Daten. Ein Dokumentname ist oft ein Personenname oder ein Fallnummer. Ein Aktenzeichen ist per Definition eine Mandanten- oder Kundenkennung.
Die Folge, unumwunden: Ein Löschantrag berührt diese zwei Felder nicht. Wer die Handlung ausführte, wird sehr wohl über einen Schlüssel pro Person abgeschirmt — aber diese zwei fallen nicht darunter. Diesen Schlüssel zu vernichten ändert nichts an lesbarem Text. Eine gelöschte Person, die in einem Dokumentnamen vorkommt, bleibt zuordenbar.
Und es gibt keine nachträgliche Reparatur, die die Kette intakt lässt. Eine bereits geschriebene Zeile umzuschreiben oder zu schwärzen bricht sowohl die Kette als auch das Siegel darüber. Für bereits geschriebene Zeilen ist das also dauerhaft. Das ist eine Folge des Entwurfs, kein vergessenes Detail — aber eines, das Sie kennen müssen, bevor Sie anfangen.
Die Felder wegzulassen geht nicht: Es sind die Felder, über die das Protokoll durchsuchbar ist, sie tragen die Rekonstruktion des Geschehens, und das Aktenzeichen ist die Grundlage des Exports pro Akte.
Was Sie als Administrator dagegen tun: Behandeln Sie beide Felder als personenbezogene Daten auf der Festplatte, und verschlüsseln Sie den Speicher. Weder die Kette noch die Software wird sie für Sie abschirmen.
Dieser Beitrag ist allgemeine Information und keine Rechtsberatung. Für Ihre eigene Situation: Legen Sie ihn einer Juristin, einem Juristen oder Ihrer bzw. Ihrem Datenschutzbeauftragten vor.
Was wir gegen Lücke 1 getan haben — und wo das endet
Seit Juli 2026 kann Provenize regelmäßig ein unterschriebenes Siegel über das Protokoll setzen. Dieses Siegel enthält einen Fingerabdruck über alle Zeilen bis zu diesem Moment, die Zeilenzahl, den Zeitpunkt und eine Unterschrift.
Damit wird Abschneiden sichtbar: Die Zeilenzahl stimmt nicht mehr mit dem Versiegelten überein. Aber nur unter vier Bedingungen — und wir nennen das nie fälschungssicher, ohne alle vier dazuzuschreiben.
Das Siegel muss außer Reichweite dessen liegen, der in die Datenbank schreiben kann. Das Siegel steht nämlich selbst in derselben Datenbank. Arbeiten Sie nur lokal, kann jemand mit Schreibrechten das deckende Siegel wegwerfen. Die Prüfung fällt dann auf ein älteres Siegel zurück, das weiterhin stimmt, und meldet, dass alles in Ordnung ist — für ein Protokoll, dessen neuere, sehr wohl versiegelte Zeilen vernichtet wurden. Das Siegel anderswo zu veröffentlichen ist die einzige Verteidigung. Nur lokal zu arbeiten lässt dies konstruktionsbedingt offen.
Der Unterschriftsschlüssel darf nicht gestohlen sein. Dieser Schlüssel ist eine Datei, die nur vom Betriebssystem geschützt wird. Unter Windows stützt sich das auf die Dateirechte, und die sind dort weniger streng durchzusetzen als unter Linux. Die Schlüsseldatei selbst zu verschlüsseln steht auf dem Plan; es gibt sie noch nicht.
Es muss ein Schlüssel eingerichtet gewesen sein, als das Siegel gesetzt wurde. Wenn nicht, ist das Siegel nicht unterschrieben und bedeutet nichts. Die Prüfung meldet das gesondert.
Die Zeilen müssen vor dem letzten Siegel liegen. Alles, was danach hinzukam, fällt heraus. Schneidet jemand genau bis zum letzten Siegel zurück, stimmt es wieder. Wie oft Sie versiegeln, ist also Ihr eigenes Risikofenster. Wer nie versiegelt, hat nichts davon.
Das Detail, über das ich am längsten nachgedacht habe
Die naheliegende Lösung ist, das Setzen eines Siegels selbst als Zeile ins Protokoll zu schreiben. Dann sieht man später ja, dass versiegelt wurde.
Ich habe das bewusst nicht getan, denn es funktioniert nicht.
Eine solche Zeile landet nämlich direkt nach dem Punkt, an dem das Siegel endet. Das ist genau der Bereich, den jemand entfernt, der das Ende abschneidet. Die Zeile steht dann neben den Zeilen, die sie beweisen soll, und verschwindet mit ihnen. Es ist der Vermerk „hier endet das Protokoll“ auf der letzten Seite: Wer die Seiten herausreißt, reißt den Vermerk mit heraus.
Siegel aneinanderzuketten löst es nicht, und ein Zähler in der Datenbank auch nicht. Alles liegt innerhalb derselben Schreibreichweite.
Fünf Antworten, nicht zwei
Die Prüfung gibt nicht „gut“ oder „schlecht“ zurück, sondern fünf verschiedene Ergebnisse: Es stimmt; es stimmt nicht; das Siegel ist ungültig; das Siegel ist nicht unterschrieben; oder es gibt gar kein Siegel.
Das ist keine Wortklauberei. Ein Siegel, das fehlt, und ein Siegel, das existiert, aber mit nichts unterschrieben ist, dürfen niemals dasselbe Ergebnis teilen wie „alles wurde nachgerechnet und es stimmt“. Ein Prüfwerkzeug, das Abwesenheit mit Freigabe zusammenfaltet, belügt seinen Nutzer.
Aus demselben Grund nennen wir Lücke 1 nicht geschlossen. Wir nennen sie bedingt geschlossen. Der Mechanismus ist da; was bleibt, ist eine Pflicht auf Ihrer Seite — regelmäßig versiegeln, und das Siegel außer Reichweite aufbewahren.
Sechs Fragen an Ihren Anbieter
Diese Fragen funktionieren bei uns und bei jedem. Die Art, wie sie beantwortet werden, sagt oft mehr als die Antwort selbst.
- Was sieht Ihre Prüfung nicht? Ist die Antwort „alles“, sind Sie mit dem Gespräch fertig.
- Merkt Ihre Prüfung, wenn die letzten Zeilen abgeschnitten wurden — oder nur, wenn mittendrin etwas verändert wurde?
- Liegt der Bezugspunkt, gegen den Sie prüfen, außerhalb der Reichweite Ihrer eigenen Administratoren?
- Werden die Felder, nach denen ich suche, ebenfalls nachgerechnet — oder nur der versiegelte Inhalt?
- Welche Felder in diesem Protokoll sind personenbezogene Daten, und was geschieht mit ihnen bei einem Löschantrag?
- Und die wichtigste: Steht diese Antwort irgendwo, wo ich sie selbst nachlesen kann?
Frage sechs ist der Grund, warum dieser Beitrag existiert. Wir haben die Antworten aufgeschrieben, bevor jemand danach fragte — und Sie dürfen uns daran festhalten.
Wollen Sie die vollständigen Grenzen sehen? Was wir schützen (und was nicht) — schwarz auf weiß, ohne Marketing drumherum.
Wo wir stehen
Eine Aussage über Nachweisbarkeit aus Software, die niemand einsehen darf, ist ein Widerspruch. Das ist der Grund, warum das SDK Open Source ist.
Aber eine Aussage über Nachweisbarkeit ohne ausgeschriebene Grenze ist genauso ein Slogan. Die Zahl, die zählt, ist nicht, wie viele Angriffe wir verhindern, sondern wie genau wir sagen können, welche nicht.
Finden Sie eine fünfte Lücke, hören wir das lieber von Ihnen als von jemand anderem. Die Meldestelle steht offen.
Ehrlich dazu: Das SDK ist gebaut, aber noch vor 1.0, und Provenize Desktop ist noch nicht veröffentlicht — die Freigabe ist für Ende 2026 geplant. Bei keinem Kunden läuft bislang etwas produktiv. Das Siegel aus diesem Beitrag funktioniert und ist getestet; die Verbesserungen, die wir als „steht auf dem Plan“ bezeichnen, existieren noch nicht. Das Produkt ist dafür entworfen, Sie bei der Einhaltung Ihrer Pflichten zu unterstützen. Es ist kein Gütesiegel, kein Zertifikat und keine Garantie; diese Wörter verwenden wir bewusst nicht.
Möchten Sie mitdenken, bevor es fertig ist? Wir suchen eine begrenzte Zahl von Kanzleien und Teams, die das Produkt vor der Freigabe nutzen und mitgestalten. Das kostet nichts. Was wir zurückerbitten, ist ehrliches Feedback: info@provenize.ai.
Mehr für Ihr Fachgebiet: KI an Mandantenakten (Recht & Compliance) und alte Pentest-Berichte durchsuchen ohne Cloud.
v0.1 · September 2026 · Zurück zur Blogübersicht