Zum Hauptinhalt springen
SVDY Logo

Sicherheitsarchitektur

Was svdy heute konkret tut, um Ihre Daten zu schützen. Keine Zertifikatsbehauptungen, die wir nicht erworben haben. Aktuelle SOC-2-Zeitleiste unter /trust/soc2; vollständige Liste der Unterauftragsverarbeiter unter /trust/sub-processors.

Zuletzt aktualisiert:24. Mai 2026

Infrastruktursicherheit

Konkrete, in Produktion betriebene Maßnahmen:

• AWS Multi-AZ-Deployment in us-east-1 — RDS Postgres mit synchroner Replikation, ECS Fargate über mehrere Availability Zones, S3 mit AZ-übergreifender Replikation. Architektur-Ziel: 99,95 % Uptime.

• Verschlüsselung bei der Übertragung: TLS 1.2+ an jedem öffentlichen Endpoint (svdy.com / qutime.com / pureoa.com / id.svdy.com / api.svdy.com), HSTS-Preload-Eignung und nur moderne Cipher Suites. Interner Service-zu-Service-Verkehr ebenfalls nur TLS.

• Verschlüsselung im Ruhezustand: AES-256 auf RDS, S3 und EBS-Volumes; verwaltet über AWS-KMS-Schlüssel mit auditiertem Zugriff. Kundenseitig verschlüsselte Secrets (OAuth-Tokens, Integration-Webhook-URLs) nutzen Fernet (AES-128-CBC + HMAC-SHA256) zusätzlich zur Festplattenverschlüsselung.

• Netzwerkisolierung: keine öffentlichen RDS-/Redis-Endpoints — Anwendungsserver erreichen Datenbanken über VPC-Private-Subnets und Security-Group-Regeln; Bastion-Zugriff nur JIT mit Audit-Logging.

• Secrets-Management: Produktionsanmeldedaten im AWS Secrets Manager, niemals in Quellcode oder Umgebungsdateien. Rotations-Runbooks dokumentiert; Schlüsselrotation ist ein SOC-2-Phase-2-Meilenstein.

Datenschutz

Was End-to-End mit Ihren Daten geschieht:

• Multi-Tenant-Isolation: jede Datenbankabfrage ist auf ORM-Ebene nach organization_id eingeschränkt; Integrationstests prüfen, dass mandantenübergreifende Abfragen keine Zeilen zurückgeben. Kein Roh-SQL-Zugriff für Anwendungscode.

• Audit-Logging: jede administrative Mutation (anlegen / aktualisieren / löschen von Mitarbeitenden, Schichten, Anwesenheiten, Abrechnungsänderungen) wird mit Akteur, Ziel, Vor-/Nach-Werten, IP-Adresse und Zeitstempel erfasst. Aufbewahrung tarifabhängig: 7 Tage (Free) / 1 Jahr (Starter+) / 3 Jahre (Pro+).

• Backups: tägliche automatische RDS-Snapshots, 30 Tage Aufbewahrung; Point-in-Time-Recovery bis auf jede Sekunde im Aufbewahrungsfenster. Wiederherstellungen werden quartalsweise gemäß DR-Runbook getestet.

• Recht-auf-Löschung-Fluss: GDPR-/CCPA-Löschanfragen laufen über /admin/identity/users — anonymisiert PII (Name, E-Mail, Telefon, biometrische Vorlage) bei gleichzeitigem Erhalt aggregierter Anwesenheitsdaten, die der Verantwortliche (Ihre Organisation) für arbeitsrechtliche Compliance benötigt. Vollständiger Mechanismus: Datenschutzerklärung §4.

• Biometrische Daten (Gesichtserkennung beim Stempeln): nur bei expliziter Einwilligung der Mitarbeitenden bei der ersten Nutzung erfasst (Art. 9 Abs. 2 lit. a DSGVO). Gesichtsvorlagen werden als Einweg-Hashes gespeichert — das Originalbild wird nie aufbewahrt. Org-Admins können die Gesichtserkennung global in den Anwesenheitsregeln deaktivieren; die Einwilligung kann jederzeit im Mitarbeitendenprofil widerrufen werden.

Betriebssicherheit

Wie wir Sicherheit als Funktion betreiben:

• Engineering-Praxis: jede Codeänderung durchläuft Pull-Request-Review mit mindestens einem zustimmenden Reviewer. Sicherheitsrelevante Änderungen (Auth, Verschlüsselung, IAM) erfordern einen zusätzlichen sicherheitsbenannten Reviewer.

• Abhängigkeitsverwaltung: Python via Poetry mit gesperrten Versionen; JavaScript via Bun-Lockfile. Verwundbare Abhängigkeiten werden via GitHub Dependabot sichtbar und nach Priorität bearbeitet.

• Zugriffskontrolle: Produktionszugriff standardmäßig nur lesend; Schreibzugriff erfordert ein dokumentiertes Change-Ticket. Engineer-Offboarding entzieht alle Zugriffe innerhalb von 24 Stunden nach Austritt.

• Incident Response: ein internes Runbook umfasst Identifikation → Eindämmung → Beseitigung → Wiederherstellung → Post-Incident-Review. Severity-1-Incidents lösen die 24-Stunden-Kunden-Benachrichtigungspflicht aus (Datenschutzerklärung §6).

• Vendor-Sicherheitsprüfung: jeder neu hinzugefügte Unterauftragsverarbeiter (derzeit 5 unter /trust/sub-processors) durchläuft eine dokumentierte Prüfung — DPA vorhanden, Sicherheitsfragebogen geprüft, Datenumfang minimiert.

Zertifikate und Bescheinigungen

Wir verpflichten uns auf eine öffentliche, datierte Roadmap statt auf nachträgliche Behauptungen. Aktueller Stand:

• SOC 2 Type II — ZIEL Q1 2027. Noch nicht zertifiziert. Vanta + A-LIGN ausgewählt (Entscheidung dokumentiert 2026-05-24). Öffentliche 8-Meilensteine-Zeitleiste unter /trust/soc2; Bericht im Q3 2027.

• GDPR-fähige Architektur — Datenschutz-Audit-Wave 1-4 abgeschlossen (Datenminimierung, Recht auf Löschung, Einwilligungs-Gates, biometrische Verarbeitung nach Art. 9). Keine formelle Zertifizierung durch eine Aufsichtsbehörde (GDPR hat keine formale Zertifizierungsstelle); wir stellen unser DPA auf Anfrage unter /trust/dpa bereit.

• ISO 27001 — NOCH NICHT ENGAGIERT. Kann SOC 2 in 2027 oder 2028 folgen, abhängig von der Kundennachfrage aus EU-Enterprise-Interessenten.

• Branchenspezifisch (HIPAA / PCI-DSS / FedRAMP) — HEUTE NICHT IN SCOPE. svdy zielt auf SMB-Workforce-Management; Healthcare PHI / Cardholder Data / Federal-Government-Workloads liegen außerhalb unseres Anwendungsfalls, bis sie ausdrücklich aufgenommen werden.

Müssen Sie einen Sicherheitsfragebogen ausfüllen, eine Vendor-Due-Diligence durchführen oder eine Schwachstelle melden? Schreiben Sie an security@svdy.com — wir bestätigen innerhalb 1 Werktags und antworten innerhalb von 3.