Geh von kompromittierten Servern aus
Das ist das Sicherheitsmodell auf Plattformebene, das hinter jedem MindooDB-Deployment steht — einschließlich Haven Sicherheit & Datenschutz. MindooDB ist so entworfen, dass Speicher- und Sync-Infrastruktur nicht vertrauenswürdig sein muss. Drei unabhängige Verschlüsselungsschichten schützen die Vertraulichkeit der Daten. Kryptografische Signaturen belegen die Urheberschaft und verhindern Manipulation. Selbst ein vollständiger Server-Einbruch liefert nur Geheimtext und öffentliche Schlüssel — keine Klartextdaten, keine privaten Schlüssel, keine Benutzernamen.
Drei unabhängige Verschlüsselungsschichten
Das Sync-Protokoll von MindooDB staffelt den Schutz über mehrere Schichten. Selbst wenn eine Schicht kompromittiert ist, schützen die übrigen weiterhin die Vertraulichkeit der Daten. Das ist das architektonische Kernstück der Sicherheit von MindooDB: Du musst keiner einzelnen Schicht vertrauen, um sicher zu sein.
Bevor ein Eintrag überhaupt in den Store gelangt, wird seine Payload mit einem symmetrischen Schlüssel (AES-256-GCM) verschlüsselt. Diese Verschlüsselung gehört zum Datenmodell, nicht zum Transport. Der Server, der die Einträge speichert, kann ihren Inhalt nicht lesen — er sieht nur verschlüsselte Bytes.
Antwortet der Server auf eine Sync-Anfrage, verpackt er die Payloads der Einträge in eine zusätzliche RSA-Verschlüsselungsschicht mit dem öffentlichen Schlüssel des anfragenden Benutzers. Selbst wer die HTTP-Antwort abfängt, kann sie ohne den privaten RSA-Schlüssel des Empfängers nicht entschlüsseln.
Die gesamte Kommunikation läuft über TLS. Das schützt Metadaten (Eintrags-IDs, Zeitstempel, Anfrageparameter), die von den Payload-Schichten nicht abgedeckt sind. Zusammen sichern die drei Schichten die Daten vollständig ab: gespeichert, unterwegs und auf der Leitung.
Wie Vertrauen entsteht
Vertrauen hat in MindooDB genau eine Wurzel: den Ed25519-Signaturschlüssel des Admins. Der Admin signiert die Verzeichnis-Datenbank, in der die Registrierungen der Benutzer stehen. Der öffentliche Schlüssel jedes Benutzers ist in einem vom Admin signierten Verzeichniseintrag hinterlegt. Erhält ein Client oder Server eine Dokumentänderung, prüft er den öffentlichen Schlüssel des Signierenden gegen das Verzeichnis — ist der Schlüssel nicht registriert, wird die Änderung abgelehnt. Eine Serverauthentifizierung ist nicht nötig; Vertrauen entsteht über kryptografische Beweise.
Was der Server sieht und was nicht
Das ist die praktische Folge der Zero-Trust-Architektur. Ein Server (oder jede andere Zwischenstation, auch Relay-Knoten) verarbeitet ausschließlich verschlüsselte Daten und öffentliche Informationen. Alles Sensible bleibt auf den Geräten der Clients.
- Öffentliche Signaturschlüssel (Ed25519)
- Öffentliche Verschlüsselungsschlüssel (RSA-OAEP)
- Verschlüsselte Blobs (AES-256-GCM-Geheimtext)
- Metadaten der Einträge (Zeitstempel, Inhalts-Hashes)
- Hashes von Benutzernamen (SHA-256 — nicht die Namen selbst)
- Dokumentinhalte (Ende-zu-Ende-verschlüsselt)
- Benutzernamen (mit dem RSA-Schlüssel des Admins verschlüsselt)
- Private Signatur- oder Verschlüsselungsschlüssel
- Symmetrische Verschlüsselungsschlüssel (Tenant oder benannt)
- Geteilte Passwörter (nur out-of-band)
Zugriffskontrolle über Verschlüsselung
MindooDB setzt Zugriffskontrolle über Verschlüsselungsschlüssel durch, nicht über serverseitige Berechtigungen. Wer den Schlüssel hat, kann das Dokument entschlüsseln. Wer ihn nicht hat, sieht Geheimtext. Damit wirkt die Zugriffskontrolle überall gleich — ob die Daten auf einem Server liegen, auf einem Peer-Gerät oder auf einem Relay-Knoten, der sie nicht lesen kann. Für die feingranulare Kontrolle über Schreib-Operationen — wer Dokumente anlegen, ändern, löschen, snapshotten oder purgen darf — siehe die eigene Seite zur Zugriffskontrolle.
Alle Dokumente werden mit dem AES-256-Standardschlüssel des Tenants verschlüsselt, sofern kein anderer Schlüssel angegeben ist. Jeder registrierte Benutzer erhält diesen Schlüssel beim Onboarding. Geeignet für allgemeine Daten im gesamten Tenant.
Für sensible Dokumente legst du einen benannten Verschlüsselungsschlüssel an und teilst ihn nur mit berechtigten Benutzern. Schlüssel werden entweder offline verteilt (den verschlüsselten Schlüssel per E-Mail, das Passwort telefonisch oder persönlich) oder admin-blind per Policy: Wer den Schlüssel bereits hat, verpackt ihn für jeden Empfänger mit dessen persönlichem öffentlichem Schlüssel, sodass ein Admin ihn verteilen kann, ohne ihn je zu lesen. Entschlüsseln kann nur, wer den Schlüssel hat.
Ein spezieller Schlüssel, der ausschließlich die Zugriffskontrolleinträge des Verzeichnisses verschlüsselt (Benutzerregistrierungen, Widerrufe, Gruppen). Server prüfen damit, welchen Signaturschlüsseln vertraut wird — ohne Benutzernamen oder Geschäftsdaten zu sehen. Benutzernamen liegen als SHA-256-Hashes vor; die tatsächlichen Namen sind mit dem RSA-Schlüssel des Admins verschlüsselt.
| Operation | Durchgesetzt durch |
|---|---|
| Benutzerregistrierung | Admin-Signatur erforderlich (Ed25519) |
| Dokument anlegen | Verschlüsselungsschlüssel nötig (Standard oder benannt) |
| Dokument ändern | Signaturschlüssel (registrierter Benutzer) + Verschlüsselungsschlüssel nötig |
| Dokument lesen | Entschlüsselungsschlüssel nötig |
| Benutzer-Widerruf | Admin-Signatur erforderlich; blockiert Sync und lehnt künftige Änderungen ab |
Challenge-Response-Authentifizierung und sicheres Onboarding
MindooDB nutzt keine Passwörter und keine auf dem Server gespeicherten Tokens. Die Authentifizierung beruht auf Ed25519-Challenge-Response: Der Server erzeugt eine zufällige Challenge, der Client signiert sie mit seinem privaten Schlüssel, und der Server prüft die Signatur gegen den registrierten öffentlichen Schlüssel. Das belegt die Identität, ohne Geheimnisse zu teilen.
Jede Sync-Sitzung beginnt mit einem Challenge-Response-Handshake:
- Der Client schickt seinen öffentlichen Signaturschlüssel an den Server
- Der Server sucht den Schlüssel im Verzeichnis und schickt eine zufällige Challenge
- Der Client signiert die Challenge mit seinem privaten Schlüssel
- Der Server prüft die Signatur, kontrolliert den Widerrufsstatus und stellt ein kurzlebiges JWT aus
Keine Passwörter, keine Sitzungsdatenbank auf dem Server. Ein widerrufener Benutzer kann den Auth-Ablauf nicht einmal starten.
Neue Benutzer kommen über einen dreistufigen Handshake dazu, bei dem private Schlüssel das Gerät nie verlassen:
- Beitrittsanfrage — Der neue Benutzer erzeugt seine Schlüssel lokal und erstellt eine Anfrage, die nur öffentliche Schlüssel enthält. Sie lässt sich gefahrlos über jeden Kanal teilen.
- Freigabe durch den Admin — Der Admin registriert den Benutzer im Verzeichnis und verschlüsselt die symmetrischen Schlüssel mit einem einmaligen Share-Passwort.
- Austausch über getrennte Kanäle — Die Beitrittsantwort geht per E-Mail oder Chat; das Share-Passwort wird separat telefonisch oder persönlich übermittelt.
Algorithmen und Garantien
MindooDB setzt auf etablierte, breit auditierte kryptografische Algorithmen. Keine Eigenbau-Kryptografie. Die Auswahl wägt Sicherheitsniveau gegen plattformübergreifende Kompatibilität ab (Node.js, Browser, React Native).
- Signatur: Ed25519 (128 Bit Sicherheit, elliptische Kurve)
- Payload-Verschlüsselung: AES-256-GCM (256 Bit Sicherheit)
- Transportverschlüsselung: RSA-OAEP mit SHA-256 (3072-Bit-Schlüssel)
- Schlüsselableitung: PBKDF2 mit eigenem Salt je Schlüsseltyp
- Token-Signatur: HMAC-SHA256
- Hashing: SHA-256 (Content-Adressierung, Schutz von Benutzernamen)
- Vertraulichkeit: AES-256-GCM-Verschlüsselung — lesen kann nur, wer den Schlüssel hat
- Authentizität: Ed25519-Signaturen — belegen, wer eine Änderung erstellt hat
- Integrität: Hash-Verkettung — Manipulation bricht die Kette und ist an jeder Stelle erkennbar
- Unabstreitbarkeit: Signaturen sind fälschungssicher — die Urheberschaft ist beweisbar
- Datenschutz: Benutzernamen gehasht und verschlüsselt — der Server kann Benutzer nicht identifizieren
Wogegen das System schützt
MindooDB geht davon aus, dass Server, Netzinfrastruktur und sogar einzelne Peers kompromittiert oder bösartig sein können. Das Sicherheitsmodell ist darauf ausgelegt, Vertraulichkeit und Integrität der Daten auch unter diesen Bedingungen zu wahren.
- Server-Einbruch — Angreifer erhalten nur Geheimtext und öffentliche Schlüssel. Kein Klartext, keine privaten Schlüssel, keine Benutzernamen.
- Abhören des Netzverkehrs — Drei Verschlüsselungsschichten schützen die Daten selbst dann, wenn TLS kompromittiert ist.
- Unbefugte Änderungen — Jede Änderung ist signiert; unsignierte oder falsch signierte Änderungen werden abgelehnt.
- Manipulation — Hash-Verkettung macht jede Veränderung erkennbar.
- Zugriff widerrufener Benutzer — Der Widerruf wirkt bei der Challenge und bei der Token-Prüfung; er blockiert den Sync sofort.
- Mithören am Relay — Relay-Knoten speichern und übermitteln verschlüsselte Einträge, die sie nicht entschlüsseln können.
Der Inhalt der Payload ist immer verschlüsselt, einige Metadaten sieht der Server jedoch konstruktionsbedingt. Das ist ein bewusster Trade-off: Das Sync-Protokoll braucht Metadaten, um Einträge abzugleichen.
- Sichtbar: Zeitstempel der Einträge, Inhalts-Hashes, Dokumentstruktur (wie viele Einträge pro Dokument), Zugriffsmuster (wann Benutzer synchronisieren)
- Nicht sichtbar: Dokumentinhalte, Benutzernamen, Verschlüsselungsschlüssel, Inhalte von Anhängen
Inhalts-Hashes verraten, wenn zwei Einträge identische verschlüsselte Daten enthalten (zur Deduplizierung). Das ist ein akzeptierter Trade-off zugunsten der Speichereffizienz.
Was du wissen solltest
MindooDB ist Beta-Software mit einem starken kryptografischen Fundament. Ein umfassendes Sicherheitsaudit wurde durchgeführt; es benennt Bereiche, die vor dem Produktiveinsatz gehärtet werden müssen. Wir glauben, dass Transparenz über Grenzen mehr Vertrauen schafft als Marketingversprechen.
Wird ein Benutzer widerrufen, blockiert das jeden künftigen Sync und lehnt seine künftigen Änderungen ab. Bereits synchronisierte Daten auf seinem lokalen Gerät bleiben jedoch zugänglich — kein System kann die Löschung auf einem Gerät garantieren, das sich nie wieder verbindet. Abhilfe: benannte Schlüssel für sensible Dokumente nutzen (kleinerer Wirkungsradius) und Schlüssel rotieren, wenn Benutzer gehen. Haven Enterprise ergänzt dieselben Governance-Policies um eine admin-signierte Remote-Löschung des Geräts: Der Tenant wird beim nächsten Verbinden von einem gestohlenen oder ausgeschiedenen Gerät entfernt.
Mehrere Schlüssel pro Benutzer (Signatur, Verschlüsselung, benannte symmetrische Schlüssel) müssen sicher verteilt werden. Abhilfe: Ein einziges Passwort entsperrt über PBKDF2 mit unterschiedlichen Salts alle Schlüssel. Der KeyBag bietet einen einheitlichen Schlüsselspeicher. Der Ablauf aus Beitrittsanfrage und -antwort erledigt den Schlüsselaustausch für neue Benutzer. Haven Enterprise automatisiert die laufende Arbeit: Admin-signierte Policies zur Schlüsselverteilung geben Schlüssel an Benutzer und Gruppen aus — und widerrufen sie wieder —, jeweils für den Empfänger verpackt, und jeder Client gleicht seinen KeyBag beim nächsten Sync ab.
Standardmäßig kann der Server Dokumentinhalte nicht abfragen, weil er nur Geheimtext sieht. Abgefragt wird ausschließlich clientseitig über inkrementelle Indizierung. Braucht dein Anwendungsfall serverseitige Verarbeitung (etwa ein Online-Buchungssystem oder eine öffentliche Website), kannst du dem Serverprozess einen Entschlüsselungsschlüssel geben oder einen Teil der Daten mit ihm teilen. Das ist je Deployment eine bewusste Architekturentscheidung — der Standard ist Vertraulichkeit, Serverzugriff kommt nur dort dazu, wo du ihn ausdrücklich einschaltest.
Ein umfassendes Sicherheitsaudit hat Bereiche für die Härtung benannt: Rate Limiting an den Endpunkten, Widerruf von JWT-Tokens und Rotation des Admin-Schlüssels. Rückdatierte Änderungen widerrufener Benutzer verhindern inzwischen Witness-Receipts mit vertrauenswürdiger Zeit (siehe das Modell der Zugriffskontrolle). Das kryptografische Fundament (Ed25519, AES-256-GCM, RSA-OAEP) ist solide. Die operative Härtung läuft.
Technische Kontrollen, die Compliance unterstützen
MindooDB liefert kryptografische Bausteine, die zentrale technische Anforderungen gängiger Regelwerke adressieren. Compliance selbst bleibt eine organisatorische Aufgabe — MindooDB liefert dafür das technische Fundament.
- ✅ Vollständige Schreib-Historie (append-only)
- ✅ Kryptografische Signaturen (Nachweis der Urheberschaft)
- ✅ Manipulationssichere Aufzeichnungen (hash-verkettet)
- ✅ Time Travel (jeden Zustand rekonstruieren)
- ✅ Ende-zu-Ende-Verschlüsselung (Server kann nicht entschlüsseln)
- ✅ Feingranulare Zugriffskontrolle (benannte Schlüssel)
- ✅ Koordinierte Datenlöschung (
purgeDocHistory) - ⚙️ Protokollierung von Lesezugriffen (baust du auf App-Ebene)
Diese Kontrollen unterstützen Programme nach HIPAA (Gesundheitswesen), SOX (Finanzwesen), DSGVO (Datenschutz) und PCI-DSS (Zahlungsverkehr). Ausführliche Compliance-Dokumentation ansehen →
MindooDB Haven ist eine browserbasierte PWA, die dieselbe Ende-zu-Ende-Verschlüsselung, Apps in der Sandbox und Local-First-Sync in einen ruhigen, plattformübergreifenden Arbeitsbereich bringt. Teste die kostenlose Beta oder lies dich in die Details ein.