Wer dein ERP betreibt, trägt deine Firma.
Hier steht, was im Maschinenraum läuft — Hosting, DSGVO, Sicherheit, Backups, Rollen, API und Export. Ohne Marketing- Versprechen, mit klar markierten Reifegraden.
Verfügbarkeit, live aus dem Health-Endpoint.
Diese Karte fragt alle 60 Sekunden den Backend-Health-Endpoint ab und zeigt den aktuellen Stand. Kein Marketing-Wert, sondern derselbe Aggregator wie unsere Status-Page.
Bis die Incident-Historie greift, weisen wir hier bewusst keinen geschätzten Prozentwert aus. Den aktuellen Live-Zustand siehst du rechts in den Status-Lights.
Gemeldet wird jede Störung im Verlauf, mit Zeitraum und Ursache. Diese Karte liest denselben Verlauf.
- Backend
- Datenbank
- Storage
Server stehen in Nürnberg. Nicht in den USA.
Tarev läuft auf einer Hetzner-Cloud-VM in Deutschland. Kein US-Hyperscaler als Plattform. Einzelne Fachdienste wie Mailversand oder Fehler-Monitoring sind US-Anbieter mit EU-Verarbeitung, siehe Auftragsverarbeiter unten.
- Provider
- Hetzner Online GmbH, Industriestraße 25, 91710 Gunzenhausen
- Rechenzentrum
- Nürnberg (Datacenter Park NBG1)
- Physische Sicherheit
- 24/7-Zutrittskontrolle, Vereinzelungsanlagen, Videoüberwachung, redundante Stromversorgung.
- Zertifizierung
- Hetzner-Rechenzentrum ISO/IEC 27001-zertifiziert (Tarev selbst noch nicht — siehe Reifegrad-Hinweise weiter unten).
- Energie
- 100 % Ökostrom (Hetzner-Bezug)
- Kein US-Hyperscaler
- Kein AWS, kein Azure, kein GCP. Datenbank, Dateien und Anwendung liegen ausschließlich bei Hetzner in Nürnberg.
- US-Auftragsverarbeiter
- Vier, jeweils nur wenn das zugehörige Feature aktiv ist: Resend (Mailversand), Sentry (Fehler-Monitoring), Stripe (Zahlungen), Mindee (Beleg-OCR). Grundlage ist das EU-US Data Privacy Framework beziehungsweise Standardvertragsklauseln. Details in der Datenschutzerklärung.
DSGVO-konform betrieben.
Auftragsverarbeitung-Vertrag, dokumentierte technisch-organisatorische Maßnahmen nach Art. 32, Datenresidenz in Deutschland und strikte Mandanten-Trennung.
Standard-Vertrag inklusive aller TOM nach Art. 32, EWR- Unterauftragsverarbeiter-Liste und Anlage zur Datenresidenz Deutschland. Eingegrenzt auf Hetzner Nürnberg.
- Art. 32 TOM
- Verschlüsselung at-rest und in-transit, Access-Logs, regelmäßige interne Audits, Least-Privilege-Prinzip im Backend.
- Standard
- Mandanten-Trennung
- PrismaService-Middleware hängt where.tenantId automatisch an jede Query (TENANT_SCOPED_MODELS-Whitelist). CI-Audit prüft, dass kein Modell vergessen wird.
- Standard
- Companion-Tenant
- Mitarbeiter-Privatdaten (Halt, Falk, Remo) liegen in einem separaten PERSONAL-Tenant. Der OWNER der Firma sieht diese Daten technisch nicht — gleiche Isolations-Schicht wie zwischen fremden Mandanten.
- Standard
- Daten-Residenz
- Datenbank, Dateien und Backups bleiben in Deutschland, ohne Spiegelung in Drittländer. Vier Fachdienste mit US-Mutter werden feature-abhängig angesprochen, siehe Hosting-Block oben.
- Standard
- Externe Tools
- Mailpit lokal in Dev, Resend (EU-Endpoint) für Prod-Mails. Keine Analytics-Pixel, keine externen Cookies auf der Marketing-Seite.
- Standard
Verschlüsselung, MFA, Audit-Log.
Standard-Krypto, kein Eigenbau. Zwei-Faktor optional. Kritische Aktionen protokolliert.
- In-Transit
- TLS 1.3, HSTS, automatische Zertifikats-Erneuerung via Caddy/Lets-Encrypt.
- Standard
- At-Rest (sensitive Felder)
- AES-256-GCM mit AI_KEY_ENCRYPTION_SECRET (32 Byte Key, Boot-Check verhindert schwache Keys).
- Standard
- Passwörter
- bcrypt (Cost-Faktor 10). Keine Klartext-Passwörter, keine reversible Speicherung.
- Standard
- Zwei-Faktor (TOTP)
- RFC-6238-Standard mit Google-Authenticator / 1Password / Authy. bcrypt-gehashte Recovery-Codes als Backup.
- Standard
- Session-Management
- JWT (Access 15 min, Refresh 7d mit Rotation), HTTPOnly-Cookies, SameSite=Strict, server-seitiges Logout.
- Standard
- Audit-Log
- Kritische Aktionen (Login, Rollen-Änderung, Daten-Export, Löschungen) werden protokolliert und sind über das Admin-Dashboard einsehbar.
- Standard
- Rate-Limiting
- Throttle auf Login-, Order-Tracking- und Public-API-Endpoints (30 GET / 10 POST pro Minute).
- Standard
Was Tarev konkret erfüllt.
Punkt für Punkt entlang der DSGVO-Artikel und der relevanten technischen Schutzmaßnahmen. Jeder Eintrag ist im Code oder im Betrieb verankert.
Was unter der Haube läuft.
Konsolidierte Liste der Schutzmaßnahmen, die ohne weiteres Zutun aktiv sind. Plus offener Hinweis zum externen Audit, statt es zu verstecken.
Ausgeliefert wird derzeit frame-ancestors 'self' gegen Clickjacking, dazu X-Frame-Options und HSTS mit Preload. Die vollständige Policy mit script-src und connect-src ist vorbereitet und wird erst scharf geschaltet, wenn sie im Report-Only-Betrieb keine echten Verstöße mehr meldet.
Throttle auf Login, Order-Tracking und Public-API. 30 GET / 10 POST pro Minute und IP.
Alle ausgehenden Webhooks tragen einen HMAC-Signatur-Header, damit Empfänger die Herkunft verifizieren können.
TLS-Zertifikate via Caddy und Lets-Encrypt, Auto-Renewal alle 60 Tage. Kein manuelles Hantieren mit Zertifikaten.
AES-256-GCM für sensible Felder (BYOK-Keys, Recovery-Codes), 32-Byte-Master-Key mit Boot-Check gegen schwache Keys.
PrismaService-Middleware hängt tenantId an jede Query. CI-Audit prüft, dass kein Model die Whitelist umgeht.
Ein externer Pentest und ein begleitender Code-Audit sind für Sommer 2026 fest eingeplant. Wir schreiben das hier offen rein, anstatt es bis zum Abschluss zu verstecken. Bericht-Auszug wird auf Anfrage geteilt.
Backup- und Restore-Garantie, schwarz auf weiß.
Konkrete Zahlen aus dem laufenden Betrieb. Keine Marketing-Phrasen, sondern was die Cron-Jobs und Skripte tatsächlich tun.
Vollständiger pg_dump jede Nacht 03:30 UTC. Touch-File markiert den letzten Erfolg, Health-Endpoint alarmiert bei Lücke über 26 Stunden.
14 Tage rollierend für schnelle Tag-Rollbacks, 8 Wochen monatlich für mittlere Sicht, 12 Monate jährlich für Audit-Anforderungen.
Interne Zielgröße für den Restore aus dem jüngsten pg_dump. Ein wöchentlicher Restore-Drill auf einer Schatten-Datenbank prüft das automatisch. Eine vertraglich zugesicherte Wiederherstellungszeit gibt es nur im Rahmen eines individuellen SLA.
Zweite Kopie auf einer getrennten Hetzner-Storage-Box. Schützt vor Total-Verlust der Produktions-VM und vor versehentlichem Löschen.
Details zu den einzelnen Stufen, Cron-Zeiten und Touch-Files stehen darunter in der ausführlichen Backup-Tabelle.
Drei Stufen. Wöchentlicher Restore-Test.
Backups, die nie zurückgespielt werden, sind keine Backups. Deshalb läuft jeden Sonntag automatisch ein Restore-Test.
- Stufe 1 — Daily pg_dump
- Täglich 03:30 UTC lokal auf dem Server, Retention 14 Tage / 8 Wochen / 12 Monate. Touch-File .last-success für Monitoring.
- Standard
- Stufe 2 — Hetzner VM-Backup
- Hetzner-Cloud-Backups in separater Storage-Region, 7-Tage-Rolling. Schützt vor Komplett-Verlust der VM.
- Standard
- Stufe 3 — Restore-Test
- Wöchentlich Sonntag 04:30 UTC: pg_dump wird in eine Schatten-DB eingespielt und auf Tabellen-Anzahl geprüft. Ergebnis im /api/health/full-Endpoint.
- Standard
- Stufe 4 — Off-Site
- Externes Off-site-Backup (StorageBox / S3 außerhalb von Hetzner) für den Fall eines kompletten Hetzner-Ausfalls.
- Geplant
Zwei Schichten, additiv kombinierbar.
Grob über System-Rollen, fein über Custom-Permissions. OWNER bekommt jede Permission als Notausgang automatisch.
- System-Rollen
- 5-stufig — OWNER, ADMIN, MANAGER, EMPLOYEE, EXTERNAL. Coarse-grained, über den @Roles-Decorator und den RolesGuard durchgesetzt.
- Standard
- Custom-Permissions
- Feingranular pro Endpoint. Über 240 Default-Permission-Keys (default-permissions.ts), eigene Rollen pro Tenant zusammenstellbar im Admin-UI unter /dashboard/admin/rollen.
- Standard
- JWT-Payload
- Beim Login werden permissions[] in den JWT geladen. PermissionsGuard prüft pro Request gegen den @RequirePermissions-Decorator.
- Standard
- Self-Service
- me/*- und my-*-Endpoints bleiben unabhängig von Custom-Permissions. Service-Layer macht weiterhin den Self-vs-Privileged-Check.
- Standard
- Audit-Pflicht
- Rollen- und Permission-Änderungen sind im Audit-Log nachvollziehbar.
- Standard
Live-Status, klare Wartungsfenster.
Aktuell tracken wir Uptime intern — ein offizielles SLA gibt es in der Pilot-Phase noch nicht. Sobald Tarev aus der Pilot-Phase ist, wird das nachgereicht.
- Uptime
- Wird intern protokolliert (Health-Check + Watchdog). Offizielles SLA in der Pilot-Phase noch nicht zugesichert.
- In Pilot-Phase
- Wartungsfenster
- Maximal 1× pro Monat, angekündigt mit 48h Vorlauf via Status-Page + E-Mail.
- Standard
REST-API offen, kein Vendor-Lock-in.
Tarev hält deine Daten nicht als Geisel. Vollständiger DSGVO-Export jederzeit, Webhooks für kritische Events, dokumentierte REST-API.
- REST-API
- Komplette OpenAPI/Swagger-Dokumentation unter /api/docs. Authentifizierung via JWT (Bearer-Token).
- Standard
- Webhooks
- Outgoing-Webhooks für Bestellung, Lohn-Lauf, Rechnung, Lieferung und Service-Ticket-Stage-Änderungen. Signierte Payloads (HMAC).
- Standard
- DSGVO-Export
- Artikel-20-Export jederzeit. JSON-Format mit allen verknüpften Daten — keine Teildatensätze.
- Standard
- DATEV-Export
- Lohn- und Buchhaltungs-Export im DATEV-CSV-Format. SEPA-Export für Zahlungen.
- Standard
- Vendor-Lock-in
- Daten gehören dir. Export ist immer komplett. Kein „Pro-Tarif für Export-Funktion"-Spiel.
- Standard
Was schon angeschlossen ist.
Reifegrad explizit markiert. Provider-Slots sind im Daten-Layer bereits vorgesehen — die externe Anbindung kommt jeweils im Folge-Sprint.
Frage zur Sicherheit offen geblieben?
Sicherheits-Fragebogen, AV-Vertrag, Pentest-Bericht oder Architektur-Detail. Wir antworten direkt unter support@tarev.de, nicht über drei Vertriebs-Stufen.
Auf Anfrage ist auch ein persönliches Sicherheits-Briefing als Zoom-Termin möglich. Wir gehen Hosting, Backups, Rollen-System und die DSGVO-Checkliste live mit deiner IT durch.