Sicherheitsmodell

Vaultigen speichert verschlossene Kisten in der Datenbank, hält den Schlüssel zu jedem Tresor hinter einem separaten Installationsschlüssel und öffnet eine angeforderte Kiste erst, nachdem der Server bestätigt hat, dass der Benutzer sie sehen darf.

Die Kurzfassung

1. Geheime Werte werden vor dem Speichern verschlüsselt. Datenbank und Anhangspeicher erhalten Chiffretext, keine nutzbaren Passwörter.
2. Jeder Tresor hat einen eigenen Schlüssel. Tresorschlüssel sind mit einem Installationsschlüssel verpackt, der außerhalb der Datenbank liegt.
3. Bei jeder sensiblen Anfrage wird der Zugriff geprüft. Anzeigen, Downloads, Freigaben, Verschiebungen und Löschungen werden auf dem Server autorisiert.
4. Der Host bleibt vertrauenswürdig. Das ist serverseitige Verschlüsselung, keine Zero-Knowledge-Verschlüsselung. Diese Grenze ist bewusst gewählt und dokumentiert.

Vertrauensgrenze

Entworfen zum Schutz vor:

• einem gestohlenen SQL-Dump oder Datenbank-Backup ohne den Installationsschlüssel,
• gestohlenem Anhangspeicher ohne dessen Schlüssel,
• versehentlicher Offenlegung über gewöhnliche Datenbankwerkzeuge und Replikate,
• Benutzern, die auf nicht freigegebene Tresore zugreifen wollen,
• unbemerkter Veränderung verschlüsselter Werte (Authentifizierungs-Tags erkennen sie),
• versehentlichem Überschreiben oder Löschen (Revisionen und Papierkorb).

Nicht entworfen zum Schutz vor:

• einem kompromittierten Betriebssystem oder PHP-Prozess,
• einem Betreiber, der veränderten Code oder Konfiguration einspielen kann,
• dem Diebstahl von Daten und Schlüsseln,
• Schadsoftware oder bösartigen Browser-Erweiterungen auf dem Gerät eines berechtigten Benutzers,
• einem Passwort, das ein Benutzer bereits gesehen, sich gemerkt oder kopiert hat.

Der Vaultigen-Server kann ein Geheimnis für einen berechtigten Benutzer entschlüsseln. Genau das macht serverseitiges Teilen, Suchen, den sysPass-Import, Auditing, Wiederherstellung und die TOTP-Erzeugung praktikabel. Ein künftiger clientseitig verschlüsselter Modus wäre ein eigener Produktmodus, kein unsichtbarer Schalter.

Verschlüsselung

Vaultigen verwendet Envelope-Verschlüsselung:

Ebene	Details
Installations-KEK	Schlüsselbund in einer geschützten Datei (kek.json) außerhalb der Datenbank, unabhängig von APP_KEY.
Tresorschlüssel	Ein zufälliger 256-Bit-Schlüssel pro Tresor, versioniert. Die Datenbank speichert nur verpackte Kopien.
Eintragsdokumente	Mit dem Tresorschlüssel versiegelt, mit libsodium XChaCha20-Poly1305 und frischer Nonce.
Anhänge	Ein zufälliger Schlüssel pro Datei, verpackt mit dem Tresorschlüssel; Inhalt verschlüsselt mit libsodium secretstream (XChaCha20-Poly1305).

Jeder verschlüsselte Wert beschreibt sich selbst (Format, Algorithmus, Zweck, Schlüssel-ID, Nonce) und ist an Installation, Tresor, Objekt, Zweck und Schlüsselversion gebunden. In einen anderen Eintrag oder Tresor verschobener Chiffretext besteht die Prüfung nicht. Identische Passwörter ergeben unterschiedlichen Chiffretext. Sodium ist Pflicht; eine Ausweich-Verschlüsselung gibt es nicht.

Was lesbar bleibt

Ein kleiner Satz Metadaten bleibt lesbar, damit der Server suchen und Listen anzeigen kann:

Lesbar	Verschlüsselt
Eintragstitel	Benutzername und Passwort
Bereinigter Host, etwa example.com	Vollständige URL, Query-String und Fragment
Namen von Tresoren, Ordnern, Kunden und Tags	Notizen und jeder Wert eigener Felder
Besitzer und Zeitstempel	Dateiname und Inhalt von Anhängen
Audit-Aktion, Person, Ziel, IP und Browser	Geheime Werte, Schlüssel, Request-Bodies

Ein Datenbank-Dump verrät also weiterhin Ihre Kontostruktur (Benutzer, Teams, Berechtigungen, Tresornamen, Eintragstitel, Hosts, Audit-Metadaten), aber nicht die Zugangsdaten.

Zugriffssteuerung

• Benutzer erhalten nie Tresorschlüssel. Der Server entscheidet pro Anfrage, ob er das angeforderte Feld ausliefert.
• Der Zugriff eines Benutzers ist die höchste aktive Berechtigung auf Eintrag, Ordner und Tresor, direkt oder über ein Team.
• Berechtigungen werden nicht über Anfragen hinweg zwischengespeichert: Deaktivierung, Entzug und Ablauf wirken ab der nächsten Anfrage.
• Jedes Anzeigen schreibt sein Audit-Ereignis, bevor der Wert zurückgegeben wird. Schlägt das Schreiben fehl, wird der Wert nicht ausgeliefert.
• Plattformrollen, auch Super-Admin, geben keinen Zugriff auf Geheimnisse. Siehe Rollen und Berechtigungen und Notfallzugriff.

Authentifizierung

Konten nur auf Einladung, verpflichtende Multi-Faktor-Authentifizierung (Authenticator-App oder E-Mail-Code), kurze Sitzungen, erneute Authentifizierung bei riskanten Aktionen und kein anonymer Wiederherstellungsweg über das Web. Anmeldung mit Passkeys ist geplant. Siehe Authentifizierung.

Audit

Ein per Hash verkettetes Log mit HMAC-Prüfpunkten, deren Schlüssel außerhalb der Datenbank liegt. Es erkennt Manipulationen allein an der Datenbank. Gegen jemanden, der Host und Audit-Schlüssel kontrolliert, ist es nicht unveränderlich. Siehe Audit-Log.

Umgang mit Klartext

Klartext-Geheimnisse existieren nur kurz im Browser des berechtigten Benutzers und im Arbeitsspeicher der Anwendung. Sie werden nicht absichtlich in Queues, Sitzungen, Caches, Logs, Berichten oder UI-Zustands-Snapshots gespeichert. Antworten beim Anzeigen werden mit Cache-Control: no-store gesendet.

Wiederherstellung

Zwei Ebenen: verschlüsselte Revisionen und Papierkorb für alltägliche Fehler, und vollständige verschlüsselte Backups mit eigenem Backup-Schlüssel für größere Vorfälle. Geht der Installationsschlüssel verloren, sind die Daten nicht wiederherstellbar; eine versteckte Hintertür gibt es bewusst nicht. Siehe Backups und Schlüsselverwaltung.

Keine Verbindung zum Hersteller

Vaultigen kontaktiert nie den Hersteller: keine Telemetrie, keine Aktivierung, keine Update-Prüfung. Die einzige optionale ausgehende Anfrage ist die Funktion Website-Icons, die das Icon eines Logins direkt von dessen Website lädt und sich in den Einstellungen abschalten lässt.