Verschlüsselung, Schlüsselverwaltung und Datenvernichtung

Geltungsbereich dieses Dokuments

Diese Seite ist die kanonische kryptografische Referenz von Zeuslock. Sie richtet sich an Sicherheitsarchitekten, die Lieferantenbewertungen durchführen, an CISOs für Risikoreviews und an Auditoren, die unsere Kontrollen auf SOC 2 Type II, ISO 27001 sowie BSI C5 abbilden. Jeder Algorithmus, jede Region und jede Rotationskadenz auf dieser Seite entspricht der tatsächlichen Produktionskonfiguration. Bei Rückfragen stellt Ihr Account-Team auf Anfrage KMS-Key-IDs, CloudTrail-Beispiele und das DPA zur Verfügung.

Unser Bedrohungsmodell unterstellt einen hochentwickelten, gut finanzierten Angreifer mit zeitweisem Zugriff auf Netzwerkpfade sowie die Möglichkeit, dass Cloud-Anbieter rechtlich zur Herausgabe gezwungen werden. Die nachstehenden Kontrollen sind darauf ausgelegt, die Vertraulichkeit der Daten auch in diesen Szenarien zu wahren und Kunden der Sovereign Edition jederzeit die Möglichkeit zu geben, unseren Zugriff zu entziehen.

Verschlüsselung in der Übertragung

Der gesamte Verkehr zwischen Browser-Erweiterung, Desktop-Agent, CLI und der Operator Console terminiert ausschließlich auf TLS 1.3. Ältere Protokolle (TLS 1.0, 1.1, 1.2) sind am Loadbalancer deaktiviert. Die Cipher-Auswahl folgt dem Mozilla-Modern-Profil: ausschließlich AEAD-Ciphers, ECDHE für Perfect Forward Secrecy und HTTP/2 als Anwendungsprotokoll.

Strict-Transport-Security wird auf jeder Antwort mit max-age=31536000; includeSubDomains; preload ausgeliefert, und zeuslock.ai ist in der HSTS-Preload-Liste von Chromium eingetragen. Der Desktop-Agent erzwingt zusätzlich Certificate Pinning. Wir verwenden mehrere Pin-Slots mit überlappenden Gültigkeitsfenstern, sodass eine Zertifikatsrotation keinen Agenten im Feld blockiert: Betreiber können ein neues Zertifikat Wochen vor dem Außerbetriebsetzen des alten Pins ausrollen.

TLS-Profil auf einen Blick

Verschlüsselung im Ruhezustand

Alle persistierten Daten werden mit AES-256-GCM verschlüsselt. Jeder Kunden-Tenant ist auf Storage-Ebene partitioniert; auch mit erhöhten Datenbank-Berechtigungen können Abfragen Tenant-Grenzen nicht überschreiten. Backups landen in einem separaten AWS-Konto, werden mit einem eigenen KMS-Key verschlüsselt und sind auf EU-Regionen beschränkt. Cross-Region-Replikation ist standardmäßig deaktiviert und nur auf ausdrücklichen Kundenwunsch aktivierbar.

Verschlüsselungsmatrix

Schlüsselverwaltung

Standard-Tenants: von Zeuslock verwaltete KMS-Keys

Standardpläne nutzen AWS KMS in eu-west-3 (Paris). Master-Keys (CMKs) werden automatisch alle 365 Tage rotiert; eine On-Demand-Rotation steht über unsere interne API zur Verfügung und propagiert innerhalb weniger Minuten auf alle verschlüsselten Ressourcen. Data Keys werden objektweise per GenerateDataKey erzeugt, sodass dieselbe DEK weder zwischen Kunden noch zwischen Vorfällen desselben Tenants wiederverwendet wird.

Der Zugriff auf administrative KMS-Operationen ist durch Dual Control geschützt: Kein einzelner Ingenieur kann Kundenmaterial entschlüsseln oder einen Key deaktivieren. Key Policies binden kms:Decrypt ausschließlich an die Service-Rolle der Produktion, und Break-Glass-Zugriffe erfordern zwei SREs plus einen Sicherheitsbeauftragten mit separaten Hardware-Tokens. Jeder Aufruf von Encrypt, Decrypt oder GenerateDataKey erzeugt ein CloudTrail-Event mit Principal, Quell-IP, Encryption Context und Request-ID.

Sovereign Edition: Bring Your Own Key (BYOK)

Kunden der Sovereign Edition stellen einen AWS-KMS-Key in ihrem eigenen AWS-Konto bereit. Zeuslock erhält einen Cross-Account-Grant — niemals eine Schlüsselkopie. Der Grant ist auf die minimal erforderlichen Operationen (Decrypt, GenerateDataKey) beschränkt und schließt destruktive Verben explizit aus. Widerruft der Kunde den Grant oder deaktiviert er den Key, verliert Zeuslock sofort den Zugriff, und sämtliches verschlüsseltes Material — Vorfälle, Payload-Snapshots, Audit-Logs — wird unlesbar.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ZeuslockProdGrant",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::ZEUSLOCK_PROD_ACCOUNT_ID:role/zeuslock-data-plane"
      },
      "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey",
        "kms:GenerateDataKeyWithoutPlaintext",
        "kms:DescribeKey"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "kms:ViaService": "dynamodb.eu-west-3.amazonaws.com",
          "kms:EncryptionContext:tenant_id": "${aws:PrincipalTag/TenantId}"
        }
      }
    },
    {
      "Sid": "DenyDestructive",
      "Effect": "Deny",
      "Principal": {
        "AWS": "arn:aws:iam::ZEUSLOCK_PROD_ACCOUNT_ID:role/zeuslock-data-plane"
      },
      "Action": [
        "kms:ScheduleKeyDeletion",
        "kms:DisableKey",
        "kms:PutKeyPolicy",
        "kms:RevokeGrant"
      ],
      "Resource": "*"
    }
  ]
}

Der Encryption Context bindet jede Operation an eine konkrete Tenant-ID, sodass selbst eine kompromittierte Data-Plane-Rolle Daten eines anderen Kunden nicht entschlüsseln kann. Wir empfehlen, diese Policy wortwörtlich zu übernehmen und nur den Principal-ARN sowie das Tenant-Tag-Schema anzupassen.

Rotationskadenz

• Data Keys (DEKs): automatische Rotation pro Objekt via GenerateDataKey. Keine Wiederverwendung.
• Master Keys (CMKs): jährliche Rotation durch AWS KMS; sofortige Neu-Verschlüsselung der Header, faule Neu-Verschlüsselung der Payloads.
• Auf Anfrage: jeder Kunde kann über den Support oder die Management-API eine außerplanmäßige Rotation anstoßen; wir schließen sie innerhalb von 24 Stunden ab und bestätigen sie mit einem CloudTrail-Extract.
• TLS-Zertifikate: alle 90 Tage erneuert; Pin-Slots überlappen sich mindestens 30 Tage.

Interner Umgang mit Secrets

Kein Klartext-Secret befindet sich jemals im Quellcode, in Container-Images, in Umgebungsvariablen oder in CI-Logs. Produktiv-Credentials liegen im AWS Secrets Manager und werden zur Laufzeit über kurzlebige Federation-Tokens (TTL 1 Stunde) bezogen, die AWS STS ausstellt. Statische IAM-Access-Keys sind in Produktionskonten verboten und durch eine Service Control Policy blockiert.

Entwickler erhalten niemals Produktions-Secrets auf ihren Arbeitsplätzen. Lokale Entwicklung erfolgt in isolierten Sandbox-Konten mit synthetischen Daten; Pre-Commit-Hooks und die Zeuslock-CLI selbst scannen jeden Commit vor dem Push auf Credential-Muster.

Löschgarantien

Recht auf Löschung (DSGVO Artikel 17)

Ein über die Operator Console oder die REST-API eingereichter Löschantrag löst innerhalb von 24 Stunden eine harte Löschung in der Live-Datenebene aus. Dieselben Identifier werden anschließend innerhalb von 30 Tagen aus den rollierenden Backups entfernt — passend zum Retention-Fenster. Nach Abschluss stellen wir ein signiertes Löschzertifikat aus.

Kunden-Offboarding

Beendet ein Kunde den Vertrag, führen wir zunächst kryptografisches Shredding durch: Der Tenant-Master-Key wird gelöscht, wodurch jeder verschlüsselte Blob — einschließlich laufender Backups — innerhalb von Sekunden mathematisch unwiderbringlich verloren ist. Die physische Löschung der zugrunde liegenden Speicherobjekte wird danach geplant und innerhalb von 30 Tagen abgeschlossen. Kunden der Sovereign Edition können das Shredding selbst durchführen, indem sie ihren KMS-Key löschen; wir können diese Aktion weder blockieren noch verzögern.

Backup-Aufbewahrung

Backups werden in einem 30-tägigen rollierenden Fenster gehalten. Ältere Snapshots werden in situ überschrieben; wir archivieren Kundendaten ohne ausdrückliche Zustimmung nicht in kalte Speicherklassen.

Audit und Transparenz

Jede kryptografische Operation — TLS-Handshakes, KMS-Aufrufe, Secret-Abrufe — erzeugt einen strukturierten Log-Eintrag, der an unser SIEM gesendet wird. KMS-Eventaufzeichnungen werden ein Jahr aufbewahrt und können dem Kunden auf Anfrage als CloudTrail-JSON-Dump oder als CSV-Abgleich exportiert werden. Kunden der Sovereign Edition sehen diese Events direkt in ihrem eigenen CloudTrail — ohne Umweg über uns.

Unsere Kontrollen sind an SOC 2 Type II (Security, Availability, Confidentiality) und ISO 27001 Anhang A ausgerichtet. Wir werden jährlich auditiert; der letzte Bericht und das Bridge Letter sind unter NDA verfügbar.

FAQ

Kann Zeuslock meine Daten herausgeben, wenn US-Behörden eine Anordnung erlassen?

Sovereign Edition: Nein. Wir besitzen den Schlüssel nicht. Wir können Chiffretext herausgeben, den wir selbst nicht lesen können, und werden Sie benachrichtigen, sofern uns das nicht rechtlich untersagt ist. Standardplan: Die Daten werden in Frankreich gehostet und nach französischem Recht verarbeitet. Wir wehren extraterritoriale Anfragen ab, bestehen auf dem Weg über das Rechtshilfeabkommen (MLAT) und veröffentlichen einen jährlichen Transparenzbericht.

Welche Hash-Algorithmen verwenden Sie für sensible Identifier?

SHA-256 mit einem Tenant-spezifischen Salt für jede kryptografische Nutzung (deterministische Lookups, Fingerprints, Deduplizierung sensibler Identifier). Für nicht-kryptografische Deduplizierung großer Payloads, bei der Geschwindigkeit zählt und adversarielle Kollisionen nicht zum Bedrohungsmodell gehören, nutzen wir BLAKE3. MD5 und SHA-1 sind in neuem Code verboten.