Verschlüsselung

DATA_KEY ist Pflicht – ohne ihn startet Klokk nicht. Er verschlüsselt die Datenbank und schützt den Schlüssel der besonders schutzbedürftigen Angaben: MFA-Geheimnisse, Kommentare zu Abwesenheiten, Push- und Webhook-Geheimnisse sowie den besonderen Arbeitszeitschutz versiegelt Klokk zusätzlich einzeln (AES-256-GCM), mit einem zufälligen Schlüssel, der nur mit DATA_KEY verschlüsselt in der Datenbank liegt.

Je nach Datenbank:

• SQLite: Klokk verschlüsselt die gesamte Datenbankdatei samt Journal (SQLite3 Multiple Ciphers, ChaCha20-Poly1305). Eine bestehende Datenbank wird beim ersten Start mit DATA_KEY umgestellt: Klokk schreibt eine verschlüsselte Kopie, prüft sie gegen das Original (Integrität, Zeilen je Tabelle) und tauscht die Dateien erst dann. Dabei darf kein anderer Prozess die Datenbank geöffnet haben. Schlägt etwas fehl, bleibt das Original unverändert, Klokk läuft unverschlüsselt weiter, nennt Super-Admins den Grund und versucht es beim nächsten Start erneut. Kopien der Datei (Backups) sind ab dann ebenfalls verschlüsselt.
• PostgreSQL: Klokk versiegelt zusätzlich alle Freitexte – Tätigkeitsnotizen, Beschreibungen der Projektzeit, Begründungen und Kommentare von Korrektur- und Tauschanträgen, Notizen zu Schichten, Urlaubs- und Zeitkonto-Buchungen sowie die Webhook-Protokolle; vorhandene Texte beim ersten Start. Namen, E-Mail-Adressen und Arbeitszeiten bleiben lesbar, weil Klokk danach sucht und rechnet. Die Dateien des Datenbankservers kann Klokk nicht verschlüsseln: Dafür den Datenträger verschlüsseln (z. B. LUKS, ZFS) und die Verbindung per TLS absichern (sslmode=verify-full).
• SESSION_SECRET schützt keine Daten: Es signiert nur Anmelde-Cookies und Kalenderlinks und lässt sich jederzeit ändern (Kalender-Abos sind danach neu einzurichten).

Achtung

DATA_KEY sicher aufbewahren – ohne ihn sind die Daten verloren Fehlt DATA_KEY oder hat er einen anderen Wert, startet Klokk nicht: Die Datenbank lässt sich dann nicht mehr öffnen, auch nicht aus einem Backup. Bewahren Sie den Wert getrennt von den Backups auf, etwa in einem Passwortmanager. DATA_KEY lässt sich nicht wieder entfernen. Nach dem Umstellen einer bestehenden SQLite-Datenbank können Reste der unverschlüsselten Datei auf dem Datenträger bleiben, bis sie überschrieben werden; ältere Backups bleiben unverschlüsselt. Wer das ausschließen muss, verschlüsselt zusätzlich den Datenträger.