Hosting-Benutzer unter Linux sicher isolieren

Veröffentlicht am 12. November 2026

Ein gemeinsam genutzter Server kann monatelang einwandfrei laufen – bis eine kompromittierte Website eine Datei liest, die sie niemals sehen dürfte. Deshalb müssen Teams Hosting-Benutzer sicher voneinander isolieren: nicht als Luxus für große Hosting-Unternehmen, sondern als Grundregel für jeden Server, auf dem mehr als eine Website, ein Kunde oder ein Projekt gehostet wird.

Die Benutzerisolation begrenzt den Schaden, wenn eine Anwendung ein verwundbares Plugin, ein schwaches Passwort oder eine hochgeladene Datei enthält, die sich als schädlich herausstellt. Außerdem verhindert sie, dass ein stark ausgelastetes Konto die Websites aller anderen verlangsamt. Das Ziel ist einfach: Jeder Kunde sollte genug Kontrolle haben, um seine eigenen Websites zu verwalten, während der Server klare Grenzen zu allem anderen zieht.

Was die Isolation von Hosting-Benutzern tatsächlich bedeutet

Isolation ist keine einzelne Einstellung. Sie besteht aus mehreren Ebenen, die zusammenwirken. Mindestens benötigt ein Hosting-Konto einen eigenen Linux-Benutzer, ein eigenes Home-Verzeichnis, eigene Dateiberechtigungen, Datenbankzugangsdaten, einen eigenen PHP-Prozess und eigene Zugriffsregeln. Ein Sicherheitsvorfall auf einer Website sollte nicht automatisch Zugriff auf alle Websites des Servers ermöglichen.

Stellen Sie sich einen gemeinsam genutzten Server wie ein Mehrfamilienhaus vor. Ein eigener Linux-Benutzer ist die Wohnungstür. Korrekte Dateiberechtigungen sind das Schloss. Separate PHP-FPM-Pools, Datenbankbenutzer und Ressourcenlimits sind die Wände, Versorgungsleitungen und Sicherungsautomaten. Eine einzelne Schutzebene hilft, aber sich nur auf eine zu verlassen, ist der Grund dafür, dass aus kleinen Vorfällen lange Abende werden.

Der passende Isolationsgrad hängt davon ab, was Sie hosten. Einige interne Websites mit einem vertrauenswürdigen Administrator haben andere Anforderungen als ein Agenturserver mit 80 Kundenkonten. Bei voneinander unabhängigen Kunden lohnt sich eine stärkere Trennung trotz des zusätzlichen Konfigurationsaufwands und des etwas höheren Speicherverbrauchs.

Verwenden Sie einen Linux-Benutzer pro Hosting-Konto

Führen Sie niemals alle Websites unter demselben Systemkonto aus. Wenn alle Webdateien einem allgemeinen Webbenutzer gehören, etwa `www-data`, kann jedes verwundbare Skript, das Dateien schreiben darf, möglicherweise auch die Website eines anderen Kunden ändern.

Erstellen Sie für jedes Hosting-Konto einen eigenen Linux-Benutzer und machen Sie diesen Benutzer zum Eigentümer seines eigenen Dokumentenstammverzeichnisses, seiner Protokolle, temporären Dateien und Anwendungsdateien. Vermeiden Sie gemeinsam beschreibbare Verzeichnisse, wo immer möglich. Ein Verzeichnis, in das jedes Konto schreiben darf, wird früher oder später zum Ort, an dem Probleme entstehen.

Legen Sie standardmäßig restriktive Berechtigungen fest. Website-Verzeichnisse benötigen üblicherweise `755`, während für gewöhnliche Dateien `644` verwendet werden kann. Konfigurationsdateien mit Geheimnissen sollten restriktiver geschützt werden, häufig mit `600` oder `640`, je nachdem, welches Dienstkonto sie lesen muss. Greifen Sie nicht zu `777`, nur weil ein Upload-Ordner nicht funktioniert. Damit beheben Sie das Symptom, indem Sie das Schloss von der Tür entfernen.

Eigentumsverhältnisse sind genauso wichtig wie numerische Berechtigungen. Eine WordPress-Website benötigt beispielsweise möglicherweise Schreibzugriff auf `wp-content/uploads`, aber der Webdienst sollte nicht die gesamte Anwendung überschreiben dürfen. Erteilen Sie Schreibzugriff nur für Verzeichnisse, die ihn tatsächlich benötigen.

Halten Sie Kontogrenzen aus gemeinsam genutzten Pfaden heraus

Es ist verlockend, Sicherungen, Sitzungen, Caches oder Bereitstellungsdateien an einem gemeinsamen Speicherort abzulegen. Das kann praktisch sein – bis Berechtigungen schleichend geändert werden oder ein Bereinigungsjob die falschen Dateien löscht. Speichern Sie anwendungsbezogene Daten pro Benutzer im Home-Verzeichnis des jeweiligen Kontos oder an einem anderen Speicherort, der ausdrücklich diesem Konto gehört.

Wenn ein gemeinsam genutzter Dienst unvermeidbar ist, legen Sie den Zugriff ausdrücklich fest. Verwenden Sie eine eigene Gruppe mit den kleinstmöglichen erforderlichen Berechtigungen, dokumentieren Sie ihren Zweck und überprüfen Sie sie nach Änderungen. „Vorübergehender“ gemeinsam genutzter Zugriff wird erfahrungsgemäß dauerhaft.

Führen Sie PHP für jedes Konto separat aus

Bei PHP-Websites ist das Ausführungsmodell eine der wichtigsten Entscheidungen, die Sie treffen müssen. Wird PHP über einen gemeinsam genutzten Prozess ausgeführt, kann eine verwundbare Website Zugriff erhalten, der weit über ihre eigenen Dateien hinausgeht. Ein separater PHP-FPM-Pool für jeden Hosting-Benutzer schafft eine klarere Grenze: Der PHP-Worker läuft als Linux-Benutzer des jeweiligen Kontos und hat eigene Prozesseinstellungen und Limits.

Ein PHP-FPM-Pool pro Benutzer erleichtert auch die Fehlerbehebung. Wenn die Anwendung eines Kunden beginnt, Worker oder Speicher zu verbrauchen, können Sie den verantwortlichen Pool identifizieren, statt den Server als ein großes Rätsel zu betrachten. Legen Sie Limits auf Pool-Ebene fest, etwa für die maximale Anzahl von Kindprozessen und die Zeitüberschreitung von Anfragen, und richten Sie sie nach dem Tarif des Kontos und den tatsächlichen Anforderungen der Anwendung aus.

Dabei gibt es einen Zielkonflikt. Mehr PHP-FPM-Pools verbrauchen mehr Speicher als ein einzelner gemeinsam genutzter Pool, besonders auf einem kleinen virtuellen Server. Bei einem Server mit nur wenigen Websites mit geringem Datenverkehr sollten Sie sinnvolle Limits festlegen, statt überdimensionierte Pools einzurichten. Opfern Sie die Trennung der Konten jedoch nicht, nur um eine überschaubare Menge RAM einzusparen. Erweitern Sie die Kapazität, bevor Sie alle Mandanten zu einer einzigen Sicherheitszone machen.

Wenden Sie bei Anwendungen außerhalb von PHP dasselbe Prinzip an. Führen Sie Node.js-, Python-, Ruby- oder benutzerdefinierte Dienste unter eigenen Benutzern aus. Verwenden Sie separate Systemdienste und Umgebungsdateien statt eines gemeinsamen Anwendungskontos mit Zugriff auf jedes Projekt.

Trennen Sie Datenbanken, Zugangsdaten und Geheimnisse

Ein Datenbankserver ist oft der Ort, an dem die Isolation unbemerkt versagt. Allen Anwendungen dieselbe Datenbankadministrator-Anmeldung zu geben, ist bei der Einrichtung praktisch und danach dauerhaft riskant. Jede Website sollte eine eigene Datenbank und einen eigenen Datenbankbenutzer haben, dessen Berechtigungen auf diese Datenbank beschränkt sind.

Erteilen Sie Anwendungsbenutzern keine globalen Berechtigungen, keine Berechtigung zum Anlegen neuer Benutzer und keinen Zugriff auf jedes Schema, sofern es dafür keinen konkreten betrieblichen Grund gibt. Wird eine CMS-Anmeldeinformation kompromittiert, sollten die Daten einer Anwendung offengelegt werden, nicht Kundendaten auf dem gesamten Server.

Gehen Sie mit Geheimnissen ebenso sorgfältig um. Speichern Sie Datenbankpasswörter, API-Schlüssel und E-Mail-Zugangsdaten in Konfigurationsdateien, die dem jeweiligen Konto gehören. Bewahren Sie sie außerhalb öffentlicher Webverzeichnisse, Versionskontrollordner und gemeinsam genutzter Sicherungsspeicherorte auf. Wenn ein Mitarbeiter, Auftragnehmer oder Kunde keinen Zugriff mehr benötigt, entziehen Sie ihn, statt anzunehmen, dass alte Zugangsdaten harmlos bleiben.

Steuern Sie den Zugriff auf Shell, SSH und geplante Aufgaben

Nicht jeder Hosting-Benutzer benötigt SSH. Für einen Kunden, der nur eine einfache Website verwaltet, reicht möglicherweise die Dateiverwaltung über das Panel oder SFTP aus. Für Entwickler und Agenturen kann SSH für Bereitstellungen, Composer, WP-CLI und die Prüfung von Protokollen sehr nützlich sein. Die praktische Antwort besteht nicht darin, den Zugriff überall zu blockieren, sondern ihn gezielt zu gewähren.

Verwenden Sie nach Möglichkeit SSH-Schlüssel statt Passwörtern. Deaktivieren Sie die direkte Root-Anmeldung, vermeiden Sie gemeinsam genutzte Administratorkonten und geben Sie Mitarbeitern separate, namentlich zugeordnete Konten, damit Aktionen nachvollziehbar sind. Wenn ein Benutzer nur Dateien übertragen muss, sollten Sie das Konto auf SFTP beschränken. Wenn der Benutzer eine Shell benötigt, stellen Sie sicher, dass er weder die Home-Verzeichnisse anderer Benutzer lesen noch riskante Wege zur Rechteausweitung nutzen kann.

Cron-Jobs verdienen dieselbe Aufmerksamkeit. Führen Sie jede geplante Aufgabe als ihr Besitzerkonto aus, nicht als Root und nicht unter einem gemeinsam genutzten Webkonto. Ein fehlerhafter Cron-Job kann eine Festplatte füllen, Tausende E-Mails versenden oder wiederholt ein ressourcenintensives Skript ausführen. Legen Sie klare Limits fest und überprüfen Sie Jobs, die lange nicht mehr angefasst wurden.

Begrenzen Sie die Ressourcen jedes Kontos

Sicherheit und Stabilität treffen bei der Ressourcensteuerung aufeinander. Ein Konto kann alle anderen Konten beeinträchtigen, ohne in deren Dateien einzudringen – indem es einfach CPU, Speicher, Prozesse, Festplattenspeicher oder Inode-Anzahl ausschöpft. Ressourcenlimits sorgen dafür, dass eine Verkehrsspitze, eine fehlerhafte Abfrage oder eine versehentliche Schleife auf das verursachende Konto beschränkt bleibt.

Nutzen Sie die von Ihrer Linux-Umgebung unterstützten Steuerungsmöglichkeiten, etwa Prozesslimits, PHP-FPM-Pool-Einstellungen, Festplattenkontingente und systemweite cgroups. Überwachen Sie die tatsächliche Nutzung, bevor Sie Grenzwerte festlegen. Ein zu niedriges Limit kann legitimen E-Commerce-Datenverkehr, Hintergrundimporte oder Sicherungen beeinträchtigen. Ein zu hohes Limit ist kaum ein Limit.

Überwachen Sie mindestens CPU-Auslastung, Speicherauslastung, Festplattennutzung, Inode-Nutzung, Prozessanzahl, fehlgeschlagene Anmeldungen und ausgehendes E-Mail-Aufkommen – sofern möglich pro Konto. Echtzeitüberwachung macht aus „der Server ist langsam“ eine hilfreiche Antwort: welcher Benutzer, welcher Prozess und seit wann.

Fügen Sie weitere Abschottung hinzu, aber verwechseln Sie sie nicht mit einer Lösung

Chroot-Umgebungen, Container und Virtualisierung können die Grenzen zwischen Benutzern verstärken. Container sind besonders nützlich, wenn Kunden benutzerdefinierte Laufzeitumgebungen, Abhängigkeiten oder Diensteinstellungen benötigen, die andernfalls auf einem Betriebssystem miteinander in Konflikt geraten würden. Virtuelle Maschinen bieten eine noch stärkere Trennung, verursachen jedoch höhere Betriebskosten.

Diese Werkzeuge sind hilfreich, ersetzen aber weder Berechtigungen noch Patch-Management oder sichere Zugangsdaten. Ein als Root ausgeführter Container mit einem beschreibbaren Host-Mount bildet keine sichere Grenze zwischen Mandanten. Ebenso kann ein Chroot-Jail den sichtbaren Dateisystemzugriff einschränken, aber möglicherweise nicht jedes Problem auf Anwendungsebene eindämmen. Wählen Sie die Ebene passend zum Risiko und konfigurieren Sie sie sorgfältig.

Eine praktische Checkliste zur Isolation

Prüfen Sie vor dem Hinzufügen eines neuen Hosting-Kontos die folgenden grundlegenden Punkte:

• Das Konto hat einen eigenen Linux-Benutzer, ein eigenes Home-Verzeichnis, eigene Website-Dateien, Protokolle und temporäre Pfade.
• PHP oder eine andere Anwendungs-Laufzeitumgebung wird unter diesem Benutzer ausgeführt und nicht unter einer gemeinsamen Dienstidentität.
• Das Konto verfügt über separate Datenbankzugangsdaten mit Zugriff nur auf die eigene Datenbank.
• Dateieigentümer und Berechtigungen verhindern Lese- und Schreibzugriffe zwischen Konten.
• SSH, SFTP, Cron-Jobs, Sicherungen und Ressourcenlimits werden für dieses spezifische Konto gewährt und konfiguriert.

Ein Control Panel sollte diese Grenzen sichtbar machen, statt sie hinter Server-Fachjargon zu verbergen. Mit FASTPANEL können Administratoren separate Konten, Domains, Datenbanken und Serveraktivitäten über eine übersichtliche Arbeitsoberfläche verwalten. Dadurch lässt sich eine gute Isolation leichter aufrechterhalten, wenn der Server wächst.

Prüfen Sie die Einstellungen auch nach der Einrichtung weiterhin

Isolation ist keine Aufgabe, die Sie einmal erledigen und dann vergessen können. Neue Plugins, Migrationsskripte, manuelle Berechtigungsänderungen und unter Zeitdruck vorgenommene Supportkorrekturen können sie mit der Zeit schwächen. Überprüfen Sie nach Website-Migrationen die Kontoinhaberschaft, suchen Sie nach weltweit beschreibbaren Dateien, entfernen Sie inaktive Benutzer, installieren Sie Sicherheitsupdates und testen Sie Sicherungen, ohne Sicherungsprozessen unnötigen Zugriff auf jedes Konto zu gewähren.

Die beste Einrichtung ist diejenige, die Ihr Team auch unter Druck verstehen und pflegen kann. Ziehen Sie für jeden Benutzer eine klare Grenze, halten Sie Ausnahmen selten und dokumentieren Sie sie, und überlassen Sie dem Server die stille Arbeit, zu verhindern, dass der schlechte Tag einer Website zum Problem für alle wird.