Was sind die unbedachten Risiken beim Selfhosting und On-Premise Software?

Ein selbst betriebener Server wirkt auf den ersten Blick nach voller Kontrolle. Die Daten liegen im eigenen Haus, niemand von außen hat Zugriff, man ist unabhängig von einem Cloud-Anbieter. Genau diese Wahrnehmung ist trügerisch, denn hinter jedem selbst gehosteten System steht eine Liste an Aufgaben, die kontinuierlich erledigt werden müssen, und Lücken in dieser Liste sind es, die regelmäßig zu realen Vorfällen führen.

Wartung ist keine einmalige Aufgabe, sondern eine Daueraufgabe

Software, die im eigenen Haus läuft, verlangt fortlaufende Pflege: Sicherheitsupdates einspielen, Backups prüfen, Firewallregeln aktuell halten, TLS-Konfigurationen erneuern, Logging und Monitoring einrichten und auswerten. In kleinen und mittleren Unternehmen landet diese Verantwortung häufig beim Geschäftsführer selbst oder bei einem IT-Verantwortlichen, der das nebenbei erledigt, oft abends oder am Wochenende, weil im Tagesgeschäft keine Zeit dafür bleibt. Das Problem dabei ist nicht die einzelne Aufgabe, sondern die Summe: Ein vergessenes Update, eine offene Portfreigabe oder eine fehlende Zwei-Faktor-Authentifizierung bei einem exponierten Dienst reichen aus, damit ein System angreifbar wird.

Wie real dieses Risiko ist, zeigt der Fall der self-hosted Git-Software Gogs. Golem.de berichtete, dass Angreifer über eine bisher ungepatchte Lücke Schadcode einschleusen können und schätzungsweise jeder zweite öffentlich erreichbare Gogs-Server im Netz bereits kompromittiert sein dürfte, auch in Deutschland. Die zugrunde liegende Analyse identifizierte mehr als 1.400 im Internet exponierte Instanzen, von denen über 700 eindeutige Spuren einer Kompromittierung aufwiesen. Die US-Sicherheitsbehörde CISA bestätigte später, dass Angriffe bereits seit Monaten liefen, ohne dass ein offizieller Patch zur Verfügung stand. Heise berichtete dazu in der Vergangenheit ebenfalls.

Hier eine strukturierte Übersicht der Daueraufgaben, die im Selfhosting-/On-Premise-Betrieb regelmäßig anfallen. Ziel ist genau das, was du beschreibst: sichtbar machen, wie viele Baustellen parallel laufen und welche davon im Alltag leicht untergehen.

Sicherheit und Zugriffsschutz

• Sicherheitsupdates und Patch-Management für Betriebssystem, Anwendungen und Firmware
• Firewallkonfiguration und regelmäßige Regelwerk-Reviews
• TLS-/SSL-Zertifikate erneuern, bevor sie ablaufen
• Zwei-Faktor-Authentifizierung für alle exponierten Services durchsetzen
• Schutz gegen Brute-Force-Angriffe bei öffentlichen Logins (z. B. NAS-Systeme, Admin-Panels)
• Intrusion Detection und Intrusion Prevention (IDS/IPS) konfigurieren und Alerts auswerten
• Patch-Management für Drittanbieter-Plugins und Abhängigkeiten (Dependency Management)
• Härtung des Systems (Hardening) nach Best-Practice-Standards wie CIS Benchmarks
• Rechteverwaltung und Prinzip der geringsten Rechte (Least Privilege) pflegen
• Regelmäßige Penetrationstests oder zumindest Vulnerability Scans

Backup und Notfallvorsorge

• Backup-Strategie mit klarer Rotation (z. B. 3-2-1-Regel: drei Kopien, zwei Medientypen, eine extern)
• Georedundanz beziehungsweise physisch getrennte Sicherungsorte
• Regelmäßige Restore-Tests, denn ein Backup zählt nur, wenn die Wiederherstellung nachweislich funktioniert
• Disaster-Recovery-Plan inklusive RTO (Recovery Time Objective) und RPO (Recovery Point Objective)
• Incident-Response-Plan mit dokumentierten Abläufen und regelmäßigen Übungen
• Business-Continuity-Planung für den Fall eines Totalausfalls

Monitoring und Betrieb

• Logging und zentrales Log-Management (SIEM wäre hier das Buzzword für größere Setups)
• Monitoring von Systemressourcen (CPU, RAM, Storage, Netzwerklast)
• Uptime-Monitoring und Alerting bei Ausfällen
• Kapazitätsplanung, damit Storage oder Rechenleistung nicht plötzlich knapp werden
• Zertifikats- und Lizenz-Ablaufüberwachung (Certificate Lifecycle Management)
• Dokumentation der Systemlandschaft aktuell halten (Configuration Management)

Netzwerk und Infrastruktur

• Netzwerksegmentierung, damit sich ein kompromittiertes System nicht frei im Netz ausbreitet
• VPN-Konfiguration und -Wartung für externen Zugriff
• DNS-Konfiguration und -Sicherheit (z. B. DNSSEC)
• Portfreigaben regelmäßig prüfen und unnötige schließen
• Container- und Virtualisierungs-Sicherheit (z. B. Docker-Hardening, Image-Scanning)
• Verwaltung und Rotation von API-Schlüsseln und Zugangsdaten (Secrets Management)

Compliance und Governance

• DSGVO-konforme Verschlüsselung im Ruhezustand und bei der Übertragung (Encryption at Rest / in Transit)
• Löschkonzepte und Aufbewahrungsfristen dokumentieren
• Audit-Trails führen, um Zugriffe nachvollziehbar zu machen
• Regelmäßige Datenschutz-Folgenabschätzungen bei neuen Systemen
• Verträge und Auftragsverarbeitung bei eingebundenen Drittsystemen prüfen

Was oft komplett übersehen wird

• Wer vertritt die Aufgabe, wenn die verantwortliche Person krank oder im Urlaub ist (Bus-Factor)
• End-of-Life-Software identifizieren, die keine Sicherheitsupdates mehr erhält
• Abhängigkeit von einzelnen Drittanbieter-Plugins, die selbst nicht mehr gepflegt werden
• Stromversorgung und unterbrechungsfreie Stromversorgung (USV) für den Serverraum
• Physische Zugangskontrolle zum Serverstandort selbst
• Klimatisierung und Brandschutz am Serverstandort

Backups sind kein Häkchen, sondern eine Strategie

Backups im Selfhosting-Umfeld werden oft als abgehakte Aufgabe behandelt, dabei ist die eigentliche Frage, wo diese Sicherungen physisch liegen. Eine externe Festplatte, die wöchentlich mit nach Hause genommen wird, schützt zwar vor einem Festplattendefekt, aber nicht vor einem Brand im Serverraum, einem Wasserschaden oder einem Diebstahl, bei dem Produktivsystem und Backup am selben Ort stehen. Ohne eine durchdachte Redundanzstrategie mit räumlich getrennter Sicherung ist ein Totalverlust der Daten keine theoretische Möglichkeit, sondern ein realistisches Szenario, das in der Praxis regelmäßig vorkommt.

Malware kompromittiert nicht nur ein System, sondern das ganze Netzwerk

Gelangt Schadsoftware ins interne Netzwerk, kann sie sich von einem kompromittierten Server aus lateral ausbreiten und weitere Systeme infizieren, gerade wenn Netzwerksegmentierung fehlt. Auch Container-Technologien wie Docker schützen hier nur bedingt: Sie isolieren einzelne Anwendungen, verhindern aber keinen kompletten Ausfall der zugrunde liegenden Infrastruktur, wenn etwa der Host-Server selbst betroffen ist. Das Open Web Application Security Project empfiehlt in seinem Docker Security Cheat Sheet unter anderem strikte Nutzerrechte-Trennung, den Verzicht auf Root-Rechte innerhalb von Containern und konsequente Netzwerksegmentierung als Mindeststandard, Maßnahmen, die in vielen KMU-Umgebungen aus Zeit- oder Kostengründen nicht konsequent umgesetzt werden.

Auch aktuelle Software ist nicht automatisch sicher

Ollama, ein beliebtes Tool zum lokalen Betrieb von KI-Sprachmodellen, wies eine kritische Schwachstelle namens „Bleeding Llama“ auf. Über nur drei unauthentifizierte API-Aufrufe konnten Angreifer den kompletten Prozessspeicher des Servers auslesen, einschließlich API-Schlüsseln, Zugangsdaten und Gesprächsdaten anderer Nutzer. Schätzungen zufolge waren mehr als 300.000 Ollama-Server weltweit über das Internet erreichbar, die API war dabei standardmäßig ohne Authentifizierung aktiv.

Open Source ist kein Sicherheitsgarant

Open-Source-Projekte auf Plattformen wie GitHub werden zunehmend gezielt unterwandert, indem Schadcode in scheinbar harmlose Beiträge eingeschleust wird. Wer sich auf Drittanbieter-Plugins oder Bibliotheken verlässt, übernimmt automatisch auch deren Schwachstellen, ohne diese selbst vollständig prüfen zu können. Diese Abhängigkeit ist einer der am meisten unterschätzten Risikofaktoren im Selfhosting-Umfeld, weil sie sich der direkten Kontrolle des Betreibers entzieht.

Warum das Thema gerade jetzt an Dringlichkeit gewinnt

Politisch motivierte Angriffe auf Unternehmensnetzwerke nehmen zu, und Phishing-Kampagnen werden durch KI-Werkzeuge zunehmend überzeugender. Gleichzeitig sinkt die technische Hürde, um Sicherheitslücken zu finden und auszunutzen. Für ein Unternehmen ohne dediziertes IT-Sicherheitsteam bedeutet das: Die Wahrscheinlichkeit, dass eine ungepatchte Lücke gefunden wird, steigt, während die Zeit, sie rechtzeitig zu schließen, kaum wächst.

Auch Cloud-Anbieter sind nicht unfehlbar, der Unterschied liegt im Umgang mit Fehlern

Ehrlicherweise gehört zu diesem Thema auch, dass große Cloud-Plattformen selbst schon erhebliche Sicherheitsvorfälle hatten. Microsoft musste sich 2024 von der US-Cybersicherheitsbehörde CISA scharfe Kritik gefallen lassen, nachdem ein gestohlener Signaturschlüssel der Hackergruppe Storm-0558 monatelangen Zugriff auf Exchange-Online-Konten mehrerer Regierungsbehörden ermöglicht hatte, die Behörde sprach von einer „Kaskade vermeidbarer Fehler“. Auch eine Schwachstelle in Azure Active Directory blieb 2023 über ein halbes Jahr ungepatcht, obwohl Sicherheitsforscher Microsoft frühzeitig gewarnt hatten. Der entscheidende Unterschied zu einem selbst betriebenen Server liegt aber nicht darin, dass bei einem Cloud-Anbieter nie etwas passiert, sondern darin, dass ein Konzern wie Microsoft über dedizierte Sicherheitsteams, Monitoring rund um die Uhr und die Ressourcen verfügt, um solche Vorfälle überhaupt zu erkennen und in der Regel innerhalb weniger Tage zu schließen, während eine unentdeckte Lücke auf einem selbst gehosteten KMU-Server oft monatelang unbemerkt bleibt.

Warum humbee auf eine andere Art Kontrolle setzt

Die Cloud-Frage ist bei humbee ohnehin nur die halbe Antwort, die eigentliche Idee dahinter ist eine andere: Statt zehn verschiedene Tools für Dokumente, E-Mails, Aufgaben und Kommunikation zu betreiben, von denen jedes einzeln gewartet, gepatcht und abgesichert werden müsste, bündelt humbee diese Funktionen in einer einzigen Plattform. Jedes zusätzliche Tool in einer Landschaft ist ein zusätzlicher Angriffsvektor, eine zusätzliche Update-Pflicht und eine zusätzliche Stelle, an der Zugriffsrechte falsch konfiguriert sein können, weniger Systeme bedeuten also nicht nur weniger Aufwand, sondern auch weniger Fläche, die überhaupt abgesichert werden muss. Wo bestehende Systeme trotzdem weiterlaufen sollen, werden sie über definierte Schnittstellen angebunden, statt parallel eigene, ungeprüfte Lösungen zu betreiben.

Wer zusätzlich Wert auf eine physische Kopie der eigenen Daten legt, ist damit bei humbee nicht komplett von der Cloud abhängig: Ein Backup lässt sich auch auf ein lokales System im eigenen Haus spiegeln, sodass die Kontrolle über eine zusätzliche Kopie erhalten bleibt, ohne dass der komplette Betrieb wieder auf den eigenen Schultern lastet. Die Infrastruktur selbst läuft dabei auf Microsoft Azure mit Rechenzentren in den Niederlanden und Irland als Ausweichstandort, wodurch Daten vollständig im EU-Raum bleiben und der DSGVO unterliegen. Dokumente werden sechsfach redundant gespeichert, alle vier Stunden erfolgt ein automatisches Backup, und im Katastrophenfall schwenkt das System automatisch auf das zweite Rechenzentrum, ergänzt durch AES-256-Verschlüsselung, granulare Rechteverwaltung und 2-Faktor-Authentifizierung.

Wo Selfhosting trotzdem seine Berechtigung hat

Selbst gehostete Software hat nachvollziehbare Vorteile: keine sich ändernden AGB eines Drittanbieters, volle Kontrolle über die eigene Infrastruktur und für manche Anwendungsfälle eine höhere Datenintegrität. Diese Vorteile gelten aber nur, wenn das nötige Fachwissen, die Zeit und die Prozesse vorhanden sind, um die oben beschriebenen Aufgaben dauerhaft und konsequent umzusetzen. Für die meisten kleinen und mittleren Unternehmen ist genau das der Punkt, an dem die Theorie an der betrieblichen Realität scheitert.

Am Ende bleibt eine einfache Beobachtung aus der IT-Sicherheitspraxis: Die wahre Sicherheitslücke sitzt oft zwischen Bildschirm und Tastatur, nicht im Code selbst. Ein System ist nur so sicher wie die Konsequenz, mit der es gepflegt wird, egal ob im eigenen Serverschrank oder in der Cloud, und genau diese Konsequenz lässt sich leichter aufrechterhalten, wenn Verantwortung und Werkzeuge nicht auf zehn verschiedene Systeme verteilt sind.