Trennung von Mandanten #

Diese Seite ist für die Produktmanager, Architekten und Sicherheitsverantwortlichen eines Hosters, die entscheiden, wie Kunden sich Maschinen teilen. Die Frage, die sie beantwortet: Wenn die Website eines Kunden kompromittiert wird oder einfach schlecht geschrieben ist, was kann sie sonst noch erreichen? Die kurze Antwort aus dem README des Projekts: Ein einziger Serverprozess, der mehrere Websites ausliefert, ist eine Bequemlichkeit beim Routing, keine Sicherheitsgrenze. Die Grenze kommt vom Betriebssystem: getrennte Benutzer, getrennte Prozesse, getrennte Datenbanken.

Inhalt #

1. Was Exponential trennt und was nicht
2. Die Einrichtungen und ihre Grenzen
3. Mehrere Websites auf einer Installation
4. Geteilte Pfade, auf die Sie achten müssen
5. Datenbanken
6. Caches, Sitzungen und Logs
7. Wählen
8. Checkliste

Was Exponential trennt und was nicht #

Innerhalb einer Installation trennt Exponential Benutzer durch Rollen und Richtlinien, Siteaccesses durch eigene Einstellungen, und es kann jedem Siteaccess ein eigenes Sitzungscookie geben (SessionNameHandler=custom). Das sind Grenzen der Anwendung: Sie halten, solange der PHP-Code nicht kompromittiert ist.

Zwischen Installationen bietet Exponential nichts Eigenes und braucht nichts Besonderes: Jede Installation ist ein Verzeichnis, eine Datenbank und eine Gruppe von Prozessen. Ob ein Kunde die Dateien eines anderen lesen kann, hängt nur davon ab, wie der Hoster diese Prozesse betreibt. Das README sagt es deutlich: Wenn mehrere Kunden die Daten der anderen nicht lesen dürfen, betreiben Sie eine Velocity-Instanz pro Website hinter einem Proxy, jede als eigener Benutzer des Betriebssystems, denn der Prozess, der eine Website ausliefert, kann jede Datei lesen, die die anderen halten.

Und aus Kapitel 8: wenn mehrere Kunden auf einer Maschine voneinander auf Ebene des Betriebssystems getrennt sein müssen (ein Velocity-Server pro Website, jeder als eigener Benutzer, oder ein klassischer Server mit einem PHP-FPM-Pool pro Website).

Die Einrichtungen und ihre Grenzen #

Das eigene Prozessmodell von Velocity innerhalb einer Website: Der Elternprozess darf root bleiben, um Ports zu binden und Zertifikate zu lesen, und jeder Worker gibt root auf, bevor Code der Anwendung läuft; [ServerSettings] User und Group entscheiden, wer er wird, und Worker als root werden verweigert, es sei denn AllowRootWorkers=enabled (8.3.5). Persistente Worker bedienen viele Anfragen derselben Website; ForkPerRequest=enabled gibt eine Anfrage pro Worker, also dieselbe Trennung wie bei PHP-FPM (8.3.7). Keine der beiden Einstellungen trennt Kunden; getrennte Instanzen tun es.

Mehrere Websites auf einer Installation #

Exponential kann viele Websites aus einer Installation ausliefern: jede Website ein Siteaccess oder eine Website-Erweiterung mit eigenem VarDir, eigenen Logs (UseGlobalLogDir=disabled, LogVarDir), Caches (CacheVarDir) und INI-Cache (INICacheDir=site) (Logs, INI-Cache und Ablaufzeitstempel pro Website). Das hält die Daten der Websites für den Betrieb auseinander, nicht für die Sicherheit: Ein PHP-Benutzer schreibt sie alle, und ein Administrator mit Richtlinien setup/* auf einem Siteaccess arbeitet an der geteilten Installation. Nutzen Sie es für die Websites eines Kunden oder einer Organisation, nicht, um Kunden ohne Bezug zueinander zu trennen. Einrichtung: Mehrere Websites auf einer Installation.

Geteilte Pfade, auf die Sie achten müssen #

Selbst mit einem Benutzer pro Website zeigen einige Standards auf Orte, die jeder Benutzer der Maschine teilt:

Panels setzen oft auch open_basedir pro Konto. Der Setup-Assistent warnt nur davor (die Einstellung kann wegen Fehlern in einigen PHP-Versionen Probleme beim Betrieb von Exponential verursachen); testen Sie eine Website unter der Einstellung Ihres Panels, bevor Sie sich darauf verlassen (Shared Hosting).

Datenbanken #

Geben Sie jeder Installation eine eigene Datenbank und einen eigenen Datenbankbenutzer mit Rechten nur auf diese Datenbank. Die Verbindung, einschließlich des Passworts, steht in settings/override/site.ini.append.php der Installation; halten Sie diese Datei auf 0640 oder strenger, damit andere Benutzer sie nicht lesen können (Datenbanken und Benutzer). Die unterstützten Datenbanken in der offiziellen Reihenfolge: 1. SQLite 3 (der Standard) · 2. PostgreSQL · 3. MongoDB · 4. MariaDB · 5. Oracle · 6. MySQL; Microsoft SQL Server ist derzeit bekanntermaßen mit zusätzlicher Arbeit möglich (Datenbankunterstützung). Mit SQLite 3 ist die Datenbank eine Datei unterhalb der Installation (standardmäßig var/storage/sqlite3/), sodass die Dateiberechtigungen die ganze Grenze sind.

Caches, Sitzungen und Logs #

• Caches gibt es pro Installation (var/); mit einem geteilten Reverse Proxy oder CDN davor stellen Sie sicher, dass die Schlüssel den Hostnamen enthalten und angemeldete Seiten nie gespeichert werden (13.10, „Zwischenspeichernde Proxys“).
• Sitzungen: ein Cookie pro Siteaccess mit SessionNameHandler=custom; verschiedene Installationen auf verschiedenen Hostnamen teilen nie Cookies, es sei denn, eine Cookie-Domain ist weiter als der Host gesetzt.
• Logs nennen Besucher. Halten Sie die Logs jeder Website in ihrem eigenen Baum und nur für ihren Benutzer lesbar; eine zentrale Log-Plattform, die sie sammelt, braucht eigene Zugriffsregeln pro Kunde.

Wählen #

Das sind Möglichkeiten; der Hoster wählt und nennt das Modell in seinen Tarifen (Ein Hosting-Modell wählen).

Checkliste #

• To do: Die Installation jedes Kunden läuft als eigener Benutzer des Betriebssystems, nie als geteilter PHP-Benutzer oder geteilte Velocity.
• To do: Code für diesen Benutzer nur lesbar; var/ und settings/ nur für ihn und seine Gruppe beschreibbar.
• To do: Keine für alle beschreibbaren Berechtigungen; TemporaryDir, Sitzungen und Uploads in Verzeichnissen pro Website.
• To do: Eine Datenbank und ein Datenbankbenutzer pro Installation; settings/override mit Modus 0640 oder strenger.
• To do: Installationen mit mehreren Websites nur innerhalb einer Organisation genutzt.
• To do: Geteilte Proxys und CDNs speichern nie angemeldete Seiten.
• To do: Das Modell der Trennung in der Tarifbeschreibung festgehalten.

Verwandte Seiten #

• Sicherheit für Hoster: Überblick
• Benutzer und Pools pro Kunde
• Ein Hosting-Modell wählen
• Shared Hosting
• Kapitel 8: Dateiberechtigungen und Eigentum
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.