+ Sicherheit & Compliance
Gebaut, um
verifizierbar zu sein.
Compliance-Aussagen sollten überprüfbar sein, nicht geglaubt. Diese Seite dokumentiert jeden Mechanismus hinter unseren Versprechen — die Krypto-Grenze, jeden Vendor in deinem Datenpfad, wie wir GDPRs härteste Spannung handhaben (Löschung vs. Immutability), wie du eine Schwachstelle meldest und wozu wir uns verpflichten, wenn etwas schiefgeht.
+ Krypto-Grenze
Envelope-Encryption mit
harter Schlüsselgrenze.
Objekte werden mit per-Object Data Encryption Keys (DEKs) verschlüsselt. Jeder DEK wird envelope-gewrappt von einem per-Tenant Key Encryption Key (KEK), der OpenBao niemals verlässt. Das Gateway hält entpackte DEKs ausschließlich im Prozessspeicher — nie auf der Platte, nie in Redis, nie in Logs.
KEKs leben in OpenBao
Key Encryption Keys werden in OpenBao (Linux-Foundation-Fork von Vault, MPL 2.0) generiert und gespeichert. Unwrap ist die einzige Operation, die einen nutzbaren DEK freilegt, und jeder Unwrap wird auditiert. Kein Recover-Engineer hält einen Schlüssel, mit dem sich deine Daten at rest entschlüsseln lassen.
DEKs nur im Speicher
Data Encryption Keys leben im Prozessspeicher des Gateways für die Lebensdauer des Requests. Das Cache-Key-Format lautet dek:{tenantId}:{bucketId} — tenant immer zuerst, wodurch Cross-Tenant-Bleed auf der Cache-Ebene strukturell unmöglich wird.
Strukturierte Logs redigieren Keys
Alle Services loggen als strukturiertes JSON mit erzwungenem Scrubbing von Feldern, die auf DEK-, KEK- oder Token-Muster matchen. Ein CI-Test stellt sicher, dass der Build failt, falls jemals ein Log-Eintrag mit Key-Material eingeführt wird.
+ Sub-Processors
Jeder Vendor in
deinem Datenpfad.
Die vollständige Liste der Dritten, die technisch Kundendaten, Metadaten oder Authentifizierung berühren könnten. Jede Änderung wird 30 Tage im Voraus über unseren Sub-Processor-Change-Log angekündigt.
| Vendor | Zweck | Standort | Welche Daten er sieht |
|---|---|---|---|
| Atlas (runatlas.is) | Object Storage, Managed Postgres, Kubernetes | Island | Verschlüsselte Kundenobjekte und Metadaten |
| Authentik | OIDC- + SAML-Authentifizierung (selbst gehostet) | Island (in unserer Atlas-Tenancy) | E-Mail, Org-ID — nie Objektdaten |
| OpenBao | Key-Management (selbst gehostet) | Island (in unserer Atlas-Tenancy) | KEKs. Verlassen OpenBao niemals. |
| Resend | Transaktionale E-Mail | USA | E-Mail-Adresse, Nachrichtentext — nie Objekte |
| Comet Backup | Backup engine (Recover Total only) | Software vendor (New Zealand). Engine runs in our Atlas tenancy in Iceland. | License check-ins only. Vendor never accesses customer data or metadata. |
Für Benachrichtigungen über Sub-Processor-Änderungen, Mail an security@recover.is.
+ GDPR Art. 17 im Detail
Löschung vs.
Immutability.
GDPR Art. 17 gibt Betroffenen das Recht auf Löschung. WORM-Storage (Write Once Read Many) verhindert Löschung per Design. Diese beiden Anforderungen stehen fundamental in Spannung. Das ist eine branchenweite Herausforderung ohne eine perfekte Einzellösung — hier, wie Recover das pro Produktstufe löst.
Natürliche Propagation
Kontinuierliche Replikation bedeutet: Sobald ein Nutzer aus der Produktions-DB gelöscht wird, propagiert der nächste Sync-Zyklus die Löschung automatisch. Ältere Point-in-Time-Snapshots rotieren innerhalb des konfigurierten RPO-Fensters aus (typisch Minuten bis Stunden).
Löschlatenz: Minuten bis Stunden
Mehrfach-Strategie
Echte Byte-Level-Löschung ist auf WORM-Storage unmöglich. Recover nutzt zwei komplementäre Strategien:
- 1.Crypto-Shredding — Jede Backup-Generation wird mit einem einzigartigen Schlüssel verschlüsselt. Das Zerstören des Schlüssels macht den Chiffretext unwiederbringlich. Laut GDPR Recital 26 sind Daten, die keiner Person mehr zuordenbar sind, keine personenbezogenen Daten mehr.
- 2.Restore-Filter-Rebackup — Backup wird in eine isolierte Umgebung restored, die Daten der betroffenen Person werden gelöscht, ein neues sauberes Backup wird erzeugt und gespeichert. Der Schlüssel des alten Backups wird anschließend geshreddet.
Löschlatenz: bis zur WORM-Retention (30–90 Tage)
Air-Gap + Crypto-Shred
Air-gapped Infrastruktur lässt sich nicht remote modifizieren. Crypto-Shredding wird im nächsten geplanten Sync-Fenster angewendet. Physische Isolation bedeutet: Die Restore-Filter-Rebackup-Pipeline erfordert Koordination mit dem Vault-Ops-Team.
Löschlatenz: nächster Sync-Zyklus (typisch 24–72 h)
Regulatorische Grundlage & ehrliche Grenzen
Warum Regulatoren das akzeptieren
- +GDPR Recital 26 — Daten, die irreversibel nicht mehr zuordenbar sind, sind keine personenbezogenen Daten.
- +Art. 17 Abs. 3 lit. b — Das Recht auf Löschung gilt nicht, wenn die Verarbeitung zur Erfüllung einer rechtlichen Verpflichtung erforderlich ist.
- +ICO-Leitlinie — Die britische ICO erlaubt ausdrücklich eine angemessene Verzögerung für Backup-Systeme, sofern die Aufbewahrungsfrist dokumentiert und der betroffenen Person mitgeteilt ist.
Ehrliche Grenzen
- —Crypto-Shredding braucht per-Generation- oder per-Subject-Key-Management. Ein einziger geteilter Schlüssel macht selektive Löschung unmöglich, ohne alle Daten zu zerstören.
- —Restore-Filter-Rebackup ist operativ teuer für große Datensätze. Die Verarbeitungszeit skaliert mit der Backup-Größe.
- —Unverschlüsselte Metadaten (Dateinamen, Subject-Identifier) auf WORM-Storage können weiterhin personenbezogene Daten sein. Zero-Knowledge-Modus ist nötig, um das vollständig zu mitigieren.
- —Es gibt keinen Gerichtspräzedenzfall, der abschließend bestätigt, dass Crypto-Shredding Art. 17 erfüllt. Aufsichts-Guidance ist günstig, aber keine bindende Rechtsprechung.
Lösch-Pipeline — pro Request
Request erhalten
DSR validiert & in unveränderlichem Audit-Trail geloggt
Produktionslöschung
Daten aus Live-Systemen gelöscht. Resilience-Stufe propagiert automatisch
Archive-Verarbeitung
Crypto-Shred oder Restore-Filter-Rebackup für WORM-Stufe angestoßen
Löschnachweis
Kryptografische Bescheinigung erzeugt. Betroffene Person benachrichtigt
+ Standards, denen wir folgen
Offene Standards,
kein Marketing.
Wir implementieren gut dokumentierte Standards und veröffentlichen die Evidenz, damit du sie verifizieren kannst. Wo wir noch an einem Standard arbeiten, sagen wir es klar.
GDPR
ErfülltIsländische Rechtsprechung, 72-Stunden-Breach-Notification, Art.-17-Lösch-Pipeline.
DORA
ReadyResilience-Testing-Framework, tamper-evident Recovery-Evidenz.
S3 Object Lock (Compliance mode)
EnforcedWORM-Retention kann nicht umgangen werden — nicht mal von Recover-Staff.
ISO 27001
SoA in ArbeitStatement of Applicability im Entwurf; formale Zertifizierung nach der Finanzierung.
SOC 2 Type I
GeplantAudit-Fenster öffnet nach erstem unterschriebenem Kunden; ETA Q4 2026.
Island / CLOUD Act Rechtsgutachten
Beauftragt zu GAWird im Trust-Repo veröffentlicht, bevor der erste Enterprise-Vertrag unterschreibt.
+ Responsible Disclosure
Schwachstelle
gefunden?
Wir nehmen Reports aus der Security-Research-Community dankend an. Wir bestätigen innerhalb von 72 Stunden und folgen koordinierten Disclosure-Timelines konsistent zu ISO 29147.
Wir bieten derzeit keine monetären Prämien. Ein Bounty-Programm ist für nach GA geplant. Researcher, die vor GA substanzielle Findings melden, werden auf unserer Hall of Thanks namentlich genannt.
Melden an
security@recover.isPGP-Fingerprint
Schlüssel wird vor GA veröffentlicht. Zuerst per Mail — wir koordinieren bei Bedarf einen verschlüsselten Kanal.
Im Scope
- +recover.is und alle Subdomains
- +Produktions-S3-Gateway-Endpoints
- +Dashboard und Admin-Konsole
- +Node-SDK (sobald veröffentlicht)
Out of Scope
- —Marketing-Site-Macken (danke — wissen wir)
- —Social Engineering unseres Staffs
- —DoS / Resource-Exhaustion (vorher fragen, wenn du testen willst)
- —Dritte (Atlas, Resend) — direkt dort melden
+ Incident Response
Wenn etwas
schiefgeht.
Wir committen uns zu Transparenz bei regulatorischen und Service-Level-Incidents. Für Availability- und Integrity-Events ist unsere Statusseite die Single Source of Truth.
Benachrichtigung betroffener Kunden und der isländischen Datenschutzbehörde (Persónuvernd) bei Breaches personenbezogener Daten — GDPR Art. 33.
Kundenbenachrichtigung bei jedem bestätigten Availability- oder Integrity-Incident, der den Produktionsbetrieb betrifft.
Öffentlicher Post-Mortem für jeden P1- oder P2-Incident — Root Cause, Timeline und präventive Maßnahmen, veröffentlicht auf unserer Statusseite.