Wenn eine Rechnung im Postfach verschwindet: Warum Infrastruktur und Sicherheit zusammengehören
Situationsbeschreibung: Eine Rechnung ist überfällig, niemand hat nachgefasst, Erinnerungen werden zu spät erstellt und Antworten gehen im allgemeinen E‑Mail‑Chaos unter. Für Mittelstandsunternehmen ist das Alltag – und vermeidbar. Ein strukturierter, on‑prem Offene‑Posten‑Workflow reduziert manuellen Aufwand und erhält die Datenhoheit. Damit ein solcher Workflow in Produktion zuverlässig läuft, braucht es abgestimmte Hardware/VM‑Sizing, klare Firewall‑Regeln, verlässliche Backups und regelmäßige Recovery‑Tests.
Übersicht: Kernbausteine der Checklist
- Ressourcenplanung: VM‑ und Hardware‑Sizing nach Edition und Transaktionsvolumen
- Netzwerk & Firewall: Minimalöffnungen, Segmente und Admin‑Zugriff
- Backup‑Strategie: Intervalle, Retention, Offsite‑Kopie
- Verschlüsselung & Schlüsselverwaltung
- Recovery‑Tests & Monitoring
Warum das zu Debentra passt
Debentra läuft als Self‑hosted Lösung auf eigener Infrastruktur. Je nach Edition (BASIS, PRO, PREMIUM) verändert sich der Ressourcenbedarf: PRO automatisiert Teile der Zuordnung und Hintergrundjobs, PREMIUM integriert zusätzliche Buchhaltungsfunktionen. Die folgende Checkliste hilft, die passende Infrastruktur bereitzustellen, ohne Automatisierungskontrolle aufzugeben: Erinnerungsvorlagen und Versand bleiben stets freigabefähig durch Anwender.
1. Hardware / VM‑Sizing (praxisnah je Edition)
Empfehlungen gelten als Ausgangspunkt für typische Mittelstands‑Setups. Passen Sie die Werte anhand Ihrer täglichen Rechnungs‑/Kunden‑Volumina an.
BASIS (kleines Setup, geringer Durchsatz)
- Single VM oder kleiner Server: 2 vCPU, 4 GB RAM
- Speicher: 50–100 GB SSD (prefer NVMe), RAID1 für Redundanz
- DB: lokal in derselben VM möglich; für Performance‑Sicherheit empfiehlt sich später eine separate DB‑VM
- RTO/RPO Zielvorgabe (Empfehlung): RTO ~24 h, RPO ~24 h
PRO (mittleres Setup, Hintergrundjobs & Automatisierung)
- App‑VM: 4 vCPU, 8 GB RAM
- DB‑VM: 2–4 vCPU, 8 GB RAM; separater Storage‑Pool (200 GB SSD)
- Storage: NVMe für DB (IOPS wichtig), RAID10 für Performance + Redundanz
- Worker‑Nodes: Ein zusätzlicher kleiner Worker (2 vCPU, 4 GB RAM) für Background‑Tasks ist empfehlenswert
- RTO/RPO Zielvorgabe: RTO ~8 h, RPO ~1 h
PREMIUM (großere Setups, integrierte Buchhaltung, höhere Verfügbarkeit)
- App‑VMs (clusterfähig): 2× 4–8 vCPU, 16 GB RAM (Load‑Balanced)
- DB‑Cluster: 2–3 Nodes mit je 4 vCPU, 8–16 GB RAM; dedizierter NVMe‑Storage (500 GB+)
- Backup‑Server / Archiv: separate VM oder NAS mit hoher Kapazität und Verschlüsselung
- RTO/RPO Zielvorgabe: RTO ~4 h, RPO ≤15–30 min (WAL‑Shipping / kontinuierliche Replikation)
2. Netzwerk & Firewall‑Regeln
Minimalprinzip: nur notwendige Ports offen, Dienste segmentieren (DMZ, Applikationsnetz, Datenbanknetz), Adminzugänge auf vertrauenswürdige IPs beschränken.
Empfohlene Regeln
- Port 443/tcp (HTTPS): Allow von Internet zu Load‑Balancer / Reverse‑Proxy
- Port 80/tcp: Allow von Internet nur für Redirect auf 443
- SSH (22/tcp): Allow nur von Admin‑IPs oder VPN (keine generelle Öffnung)
- DB‑Ports (z. B. 5432/tcp für PostgreSQL): Allow nur aus Applikationsnetz / spezifischen App‑VMs
- Backup‑Transfer: Beschränken auf TLS/SSH‑basierte Verbindungen (rsync/ssh oder SFTP) und erlaubte Backup‑Server
- Interne Kommunikation: Microsegmentation zwischen App und Worker/DB; nutzen Sie Stateful‑Firewall oder Security Groups
Weitere Hinweise
Setzen Sie ein Management‑VLAN für Admin‑Zugriffe und Überwachung. Deaktivieren Sie unnötige Services auf Produktionsservern und führen Sie regelmäßige Port‑Scans durch.
3. Backup‑Strategie & Intervalle
Backups sind nicht nur Kopien — sie sind ein Prozess. Definieren Sie Schedules, Testläufe und Verantwortlichkeiten.
BASIS
- Vollbackup: täglich (nachts)
- Inkrementelle Snapshots: täglich oder stündlich je nach Belastung
- Retention: 14–30 Tage
- Offsite‑Kopie: mindestens wöchentlich (verschlüsselt)
PRO
- Vollbackup: täglich
- Inkremente: stündlich für DB, tägliche Snapshots für Applikation
- Transaktionelles Backup: WAL‑Backup oder ähnliches zur Wiederherstellung bis auf Minuten
- Retention: 30 Tage + wöchentliche Offsite‑Snapshots
PREMIUM
- Kontinuierliche Replikation (WAL‑Shipping / Streaming Replication)
- Tägliche Vollbackups + stündliche differenzielle Backups
- Retention: 90 Tage für reguläre Backups, Langzeitarchiv nach Bedarf
- Offsite & verschlüsselte Kopien: tägliche Übertragung an externen Standort
4. Verschlüsselung & Schlüsselverwaltung
Verschlüsselung muss Ende‑zu‑Ende gedacht werden: Transit, At‑Rest und Backups.
- TLS: HTTPS mit TLS 1.2+ (besser TLS 1.3), HSTS aktivieren, Certificates automatisch erneuern (z. B. ACME/LetsEncrypt oder interner PKI)
- At‑Rest: Full‑Disk‑Encryption (LUKS) auf VM‑Level oder verschlüsselte LVM‑Volumes; DB‑Speicher zusätzlich auf verschlüsseltem Storage
- Backups: AES‑256‑verschlüsseln; Schlüssel getrennt von Backups verwalten
- Key Management: Verwenden Sie ein zentrales KMS (z. B. HashiCorp Vault oder unternehmensinternes KMS). Vermeiden Sie lokal gespeicherte Klartext‑Keys.
5. Recovery‑Tests, Monitoring & Betrieb
Backups, die nie getestet wurden, sind wertlos. Monitoring löst Probleme, bevor Mahnläufe ins Stocken geraten.
Recovery‑Tests
- BASIS: Quartalsweise vollständiger Restore‑Test (Dokumentation des Ablaufs)
- PRO: Monatliche Restore‑Übung für DB + stichprobenhafte Applikationswiederherstellung
- PREMIUM: Wöchentliche Restore‑Tests auf Staging, Simulation von Last und Failover
Monitoring & Alerts
- Überwachen: Service‑Health, DB‑Latenz, Disk‑IO, Backup‑Jobs, Replikationslag
- Alerts: Backup‑Fehler sofort an Verantwortliche; Warnungen für Disk‑Auslastung ≥75%
- Audit‑Logs: Zugriff und Reminder‑Freigaben protokollieren (für Transparenz im Nachverfolgungsprozess)
Praxisbeispiel: So läuft ein Produktions‑Setup
Ein Mittelstandsunternehmen setzt Debentra PRO ein. Die Architektur: Load‑Balancer → App‑VM (4 vCPU/8 GB) → DB‑VM (2 vCPU/8 GB) → Backup‑Server (offsite verschlüsselte Kopien). Firewall regelt 443 offen, 22 nur vom Admin‑VPN, 5432 nur aus dem Applikationsnetz. Nightly Vollbackup, stündliche DB‑Inkremente, monatlicher Recovery‑Test. Erinnerungsvorlagen werden automatisch vorbereitet, Anwender entscheiden über Freigabe und Versand – so bleibt die Kontrolle beim Team.
Umsetzungstipps und häufige Fehler
- Fehler: DB‑Port öffentlich machen. Konsequenz: unnötiges Angriffsrisiko. Lösung: nur interne Kommunikation erlauben.
- Fehler: Backups vor Ort ohne Offsite‑Kopie. Lösung: tägliche verschlüsselte Offsite‑Kopie einplanen.
- Fehler: Keine Recovery‑Tests. Lösung: Regelmäßige, dokumentierte Restore‑Übungen mit Verantwortlichkeiten.
- Fehler: Automatisierung ohne Freigabeprozess. Lösung: Automatisierte Entwürfe + manuelle Freigabe der Mahnungen einführen.
Fazit und nächste Schritte
Ein stabiler, sicherer Betrieb von Debentra on‑prem benötigt planbare Infrastruktur, begrenzte Netzwerköffnungen, eine durchdachte Backup‑Strategie und regelmäßige Recovery‑Tests. Wählen Sie die Edition passend zu Ihrem Volumen und Ihren Verfügbarkeitsanforderungen: BASIS für einfache Setups, PRO wenn Automatisierung und Hintergrundverarbeitung wichtig sind, PREMIUM für höhere Verfügbarkeit und integrierte Buchhaltungsfunktionen. In allen Fällen bleibt die Kontrolle über Mahn‑Freigaben beim Anwender.
Jetzt handeln: Prüfen Sie Ihre aktuelle Architektur an Hand dieser Checklist und wählen Sie die passende Edition. Edition wählen
Nächster Schritt
Debentra selbst ausprobieren
Zentrale Übersicht und Prozesssteuerung für offene Posten und Zahlungen bei vollständiger Datenhoheit; reduziert manuelle Zuordnungsarbeit (PRO) und ermöglicht integrierte Buchhaltung (PREMIUM); wählbare Installations- und Lizenzmodelle.