Verschlüsselung
TLS 1.2+ für jeden Request, AES-256 für Daten im Ruhezustand, gehashte Secrets in der Datenbank. Sensible API-Keys liegen ausschließlich verschlüsselt im serverseitigen Vault.
Sicherheit als Grundhaltung, nicht als Add-on.
Diese Seite beschreibt, wie wir Hetrex-Projekte technisch und organisatorisch absichern. Sie ersetzt keine Zertifizierung – sie sagt klar, was wir tun und was Ihre Verantwortung als Auftraggeber:in bleibt.
Sechs Säulen
Was wir konkret tun
Sicherheitsmaßnahmen, die in jedem Hetrex-Projekt aktiv sind – unabhängig von Care-Stufe oder Branche.
Zugriff & Rollen
Rollen in einer separaten Tabelle, geprüft über SECURITY-DEFINER-Funktionen. Multi-Faktor-Login, Passkeys und protokollierte Admin-Aktionen.
Infrastruktur
Hosting in der EU, Edge-Schutz durch Cloudflare, DDoS- und Bot-Mitigation. Trennung von Preview- und Produktionsumgebungen.
Monitoring
Uptime-Checks, Fehler-Capture, Web-Vitals und Audit-Logs für sicherheitsrelevante Aktionen – mit Alerts an das Hetrex-Team.
Updates & Patches
Automatisierte Dependency-Scans und ein verbindlicher Patch-Rhythmus für Sicherheits-Updates – nicht nur „wenn Zeit ist".
Backups & Recovery
Tägliche Datenbank-Backups mit Point-in-Time-Recovery, regelmäßig getestet. Klare RTO/RPO-Ziele pro Care-Paket.
Grundprinzipien
Diese vier Prinzipien leiten jede Architekturentscheidung – von der ersten Skizze bis zur Wartung.
Least Privilege
Jeder Dienst, jede Rolle und jeder API-Key bekommt nur die Rechte, die für seine Aufgabe nötig sind – nicht mehr.
Defense in Depth
Wir verlassen uns nicht auf eine einzelne Schutzschicht. Edge-Firewall, Auth, RLS und serverseitige Validierung ergänzen einander.
Auditability
Sicherheitsrelevante Aktionen sind nachvollziehbar protokolliert – ohne sensible Inhalte in den Logs zu spiegeln.
Privacy by Default
DSGVO ist Grundlage, nicht Add-on. Datenminimierung, klare Aufbewahrungsfristen, EU-Hosting, transparente Subprozessoren.
Subprozessoren
Sub-Auftragsverarbeiter nach Art. 28 DSGVO. Sitz und Zweck der Verarbeitung sind transparent gelistet. Änderungen werden hier dokumentiert.
| Dienst | Zweck | Region |
|---|---|---|
| Cloudflare | Edge-Hosting, CDN, DDoS- und Bot-Schutz | EU (Frankfurt/Amsterdam) + global Edge |
| Supabase / AWS Frankfurt | Datenbank, Auth, Storage | EU (eu-central-1) |
| Resend | Transaktionale E-Mails (Bestätigungen, Benachrichtigungen) | EU |
| Stripe | Zahlungsabwicklung (nur bei Online-Zahlung) | EU / Irland |
| Sentry / Web-Vitals | Fehler- und Performance-Telemetrie (anonymisiert) | EU |
Reaktion auf Vorfälle
Was passiert, wenn doch etwas passiert. Unser Incident-Response-Prozess in fünf Schritten.
- 01Erkennen
Monitoring, Logs und Meldungen werden in einem zentralen Kanal zusammengeführt.
- 02Einordnen
Schweregrad, Reichweite und betroffene Daten werden innerhalb von Stunden bewertet.
- 03Eindämmen
Betroffene Endpunkte werden isoliert, Schlüssel rotiert, ggf. Notfall-Patch eingespielt.
- 04Informieren
Betroffene Kund:innen werden zeitnah informiert; bei meldepflichtigen Vorfällen erfolgt eine Meldung an die zuständige Aufsichtsbehörde.
- 05Aufarbeiten
Post-Mortem mit Ursache, Maßnahme und Frist – als Grundlage für strukturelle Verbesserungen.
Responsible Disclosure
Sie haben eine Schwachstelle gefunden?
Wir freuen uns über jeden Hinweis. Bitte melden Sie potenzielle Schwachstellen direkt an unsere Sicherheits-Adresse und geben Sie uns angemessene Zeit zur Behebung, bevor Sie sie veröffentlichen. Wir bedanken uns mit einer namentlichen Erwähnung (sofern gewünscht) und – je nach Schweregrad – einem kleinen Dankeschön.
security@hetrex.deBitte enthalten
- • Beschreibung der Schwachstelle
- • Schritte zur Reproduktion
- • Betroffene URL / Komponente
- • Mögliche Auswirkung
- • Optional: PoC, ohne fremde Daten zu exfiltrieren