Sicherheit bei lionbackup
Wie wir Ihre Daten schützen – verständlich erklärt für Entscheider und im Detail dokumentiert für Technik und Revision.
Auf dieser Seite
Management-Überblick
lionbackup ist von Grund auf so gebaut, dass niemand außer Ihnen Ihre Inhalte lesen kann – auch wir als Betreiber nicht. Dafür sorgt ein durchgängiges Sicherheitskonzept aus clientseitiger Verschlüsselung, unveränderbarem Speicher, strikt getrennten Zonen und lückenloser Nachvollziehbarkeit.
Ihre Schlüssel, Ihre Daten
Verschlüsselt wird auf Ihrem System, bevor Daten das Haus verlassen. Die Schlüssel verbleiben bei Ihnen – wir haben keinen Zugriff auf Klartext.
Unveränderbar (WORN)
Während der gewählten Vorhaltezeit lassen sich Backups weder überschreiben noch löschen – ein wirksamer Schutz gegen Ransomware.
Getrennte Schreib-/Lese-Token
Ein Zugriffstoken hat entweder Schreib- oder Leseberechtigung. Ein Schreib-Token kann nur sichern, aber keine Backups wiederherstellen – dafür ist ein separates Token mit Leseberechtigung erforderlich.
Standort in Europa
Speicherung ausschließlich in geprüften europäischen Rechenzentren, geografisch von der Verwaltungszone getrennt.
SSO & 2FA/TOTP
Anmeldung nur über Single Sign-on mit verpflichtender Zwei-Faktor-Authentisierung (TOTP). Keine schwachen Passwort-Logins.
Lückenlose Protokollierung
Sicherheitsrelevante Ereignisse werden zentral und manipulationsarm protokolliert und ausgewertet.
Anomalie-Erkennung
Auffällige Upload-Muster werden automatisch erkannt und gemeldet – etwa unzureichend verschlüsselte Daten.
Ergänzend dokumentieren die technischen und organisatorischen Maßnahmen (TOMs), die Servicebeschreibung und die Auftragsverarbeitung (AVV/DPA) die Schutzmaßnahmen vertraglich.
Technische Details
1. Clientseitige Ende-zu-Ende-Verschlüsselung
Die Verschlüsselung erfolgt vollständig im quelloffenen lionbackup-Client, bevor Daten übertragen
werden. Jede Datei erhält einen frischen, zufälligen Datenschlüssel (DEK); die Nutzdaten werden mit
XChaCha20-Poly1305 in Blöcken authentifiziert verschlüsselt. Der DEK wird hybrid
gekapselt – klassisch über X25519 und post-quantum-sicher über ML-KEM-768
(age-Hybridverfahren). Die privaten Schlüssel verlassen niemals Ihr System und werden lokal mit
restriktiven Dateirechten gespeichert. Folge: Der Server sieht ausschließlich Chiffrat. Geht Ihr
Schlüssel verloren, ist eine Wiederherstellung technisch ausgeschlossen – das ist beabsichtigt.
2. Unveränderbarer Speicher (WORN) mit Vorhaltezeit
Backups landen in einem gehärteten, redundanten Speichersystem. Für unveränderbare Projekte stellt die Plattform selbst sicher, dass jedes Objekt für die vom Kunden konfigurierte Vorhaltezeit weder überschrieben noch gelöscht werden kann (Write Once, Read Never) – unabhängig von einzelnen Speicherkomponenten. So bleiben Ihre Sicherungen auch dann intakt, wenn ein kompromittiertes System sie zu zerstören versucht.
3. Getrennte Zonen & durchgängig verschlüsselter Verkehr
Die Plattform ist in eine zentrale Backup-Zone (Verwaltung, Portal, Steuerung) und mehrere geografisch getrennte Storage-Zonen aufgeteilt. Kunden-Uploads gehen direkt an den Speicher-Endpunkt („Citadel“) der gewählten Storage-Zone – nicht über die Verwaltungszone. Der zonenübergreifende Steuer- und Metadatenverkehr (z. B. Synchronisation, Audit-Weiterleitung) läuft ausschließlich über ein stark verschlüsseltes, gegenseitig authentisiertes Koppelnetz mit pro Zone separater Verbindung. Jede Zone ist netzwerkseitig isoliert.
4. Zentrales Single Sign-on & verpflichtende Mehr-Faktor-Authentisierung
Die einzige Anmeldeart ist Single Sign-on über eine zentrale, dedizierte Identitätsplattform. Es gibt keine lokalen Passwörter im Portal. Die Zwei-Faktor-Authentisierung per TOTP ist verpflichtend eingerichtet und lässt sich nicht umgehen. Benutzer und Gruppen werden zentral verwaltet; das Portal wertet ausschließlich kryptographisch signierte Berechtigungsnachweise aus.
5. Least-Privilege-Datenbankzugriff
Die Anwendung verbindet sich mit einem dedizierten, nicht privilegierten Datenbankbenutzer (kein Superuser), dessen Rechte auf das Anwendungsschema beschränkt sind. Lese-Abfragen werden, wo möglich, auf eine Replik geleitet; Schreibzugriffe gehen auf die Primärdatenbank. Die Zugangsdaten werden nicht im Code hinterlegt, sondern zur Laufzeit aus einem geschützten Geheimnisspeicher bezogen und lassen sich rotieren.
6. Zentrale Audit-Protokollierung & Anomalie-Erkennung
Sicherheits- und Anwendungsereignisse (Anmeldungen, Audit-Einträge, abgeschlossene Uploads) werden als strukturierte Einträge an ein zentrales, zugriffsgeschütztes Auswertesystem übermittelt und sind dort auswertbar. Zusätzlich prüft der Speicher-Endpunkt jeden Upload heuristisch: über eine Entropie-Messung (Shannon, Bit/Byte) wird erkannt, ob hochgeladene Daten tatsächlich verschlüsselt sind. Unterschreitet die gemessene Entropie einen Schwellwert (Verdacht auf unverschlüsselte oder schwach verschlüsselte Daten), wird ein Anomalie-Ereignis ausgelöst. Weitere Auffälligkeiten wie ungewöhnliche Größen oder Token-Missbrauch fließen in dieselbe Auswertung ein.
7. Netzwerksegmentierung & kontrollierter Egress
Die Zonen sind in getrennte, private Netzsegmente unterteilt. Der ausgehende Paketverkehr ist bündelig kontrolliert: Benötigte externe Quellen werden nur über eine kontrollierte, an das zonenprivate Netz gebundene Zwischenstation bereitgestellt, und der Internet-Egress läuft über einen dedizierten Austrittsknoten. So bleibt die Angriffsfläche nach außen minimal.
8. Verschlüsselte Übertragung & Replikation
Der gesamte Transport ist verschlüsselt: Die Übertragung zwischen Client und Speicher-Endpunkt erfolgt über HTTPS/TLS, der zonenübergreifende Steuerverkehr über stark verschlüsselte, gegenseitig authentisierte Verbindungen. Im Speichersystem wird der pro Datei gekapselte Datenschlüssel zusätzlich serverseitig umschlossen abgelegt – Ihre Inhalte selbst bleiben durch die clientseitige Verschlüsselung in jedem Fall unlesbar.
| Schutzziel | Maßnahme |
|---|---|
| Vertraulichkeit | Clientseitige E2E-Verschlüsselung (XChaCha20-Poly1305, X25519 + ML-KEM-768); Schlüssel verbleiben beim Kunden |
| Integrität & Manipulationsschutz | Authentifizierte Verschlüsselung (Poly1305), unveränderbarer WORN-Speicher mit Vorhaltezeit |
| Verfügbarkeit | Geografisch getrennte Storage-Zonen, isolierte Netzsegmente |
| Zugriffskontrolle | Zentrales SSO, verpflichtende TOTP-MFA, Least-Privilege-Datenbankzugriff |
| Nachvollziehbarkeit | Zentrales Audit-Logging, Anomalie- und Entropie-Erkennung |
| Transportsicherheit | HTTPS/TLS für Uploads, stark verschlüsselte Verbindungen für den Steuerverkehr zwischen den Zonen |
Diese Seite beschreibt den aktuellen Architekturstand. Verbindliche, vertraglich zugesicherte Aussagen ergeben sich aus den TOMs, der Servicebeschreibung und dem jeweiligen Vertrag.