Shared Hosting Security entscheidet, ob ein kompromittiertes Konto andere Sites berührt oder sauber isoliert bleibt – ich zeige, wie Tenant Isolation in allen Schichten greift. Ich skizziere konkrete Maßnahmen von Prozess‑Jails über VLAN/VXLAN bis zu RLS in Datenbanken, damit Shared Hosting Security im Alltag trägt.
Zentrale Punkte
Die folgenden Kernaspekte strukturieren die Umsetzung von Tenant Isolation im geteilten Hosting.
- Isolationsschichten: Trennung auf Prozess-, Datei-, Netzwerk- und Datenbankebene.
- Datenbank-Schutz: Tenant‑IDs, RLS, Verschlüsselung at‑rest und in‑transit.
- Ressourcenlimits: cgroups, Quotas und faire Planung gegen „Noisy Neighbors“.
- Monitoring: Metriken, Logs und Alarme je Mieter mit klaren Labels.
- Tenancy-Modelle: Silo, Pool oder Hybrid je Risiko und Budget.
Ich gewichte zuerst die Isolationsschicht mit dem größten Risiko, dann ergänze ich weitere Lagen. So entsteht Verteidigung in Tiefe ohne blinde Flecken. Für Einsteiger beschreibe ich die Bausteine knapp, für Profis nenne ich konkrete Mechanismen. Jede Maßnahme zahlt auf Segmentierung ein und reduziert mögliche Ausbreitung. Am Ende steht eine klar geprüfte Trennung je Konto.
Was Tenant Isolation im Shared Hosting bedeutet
Ich kapsle jeden Mieter in eigenen Prozessen, eigenen Namespaces und einem begrenzten Ressourcenrahmen, damit keine fremden Dateien oder Umgebungen erreichbar sind. Container wie LXC oder systemd‑nspawn trennen PIDs, Netzwerke und Mounts, während cgroups harte Limits setzen. Für einfache Workloads reichen leichte Jails, für dynamische Stacks nutze ich Container‑Profile mit AppArmor oder SELinux. Zusätzlich definiere ich per UID/GID-Sets klare Grenzen, damit Dateizugriffe sauber scheitern. Einen tieferen Einstieg liefern die Isolationskonzepte im Hosting, die konkrete Schutzpfade zeigen. So halte ich die Angriffsfläche je Tenant klein und nachvollziehbar.
Netzwerkgrenzen und Traffic-Segmentierung
Auf der Netzwerkschicht trenne ich Traffic per VLAN oder VXLAN und verknüpfe Ports mit Security-Policies. Eine Edge‑Firewall filtert eingehende Verbindungen, lokale Firewalls drosseln laterale Bewegungen. IDS/IPS erkennen anomale Muster je Tenant‑Segment, WAF‑Regeln stoppen gängige Webangriffe früh. Ich definiere Default‑Deny, erlaube nur nötige Protokolle, und logge Drop‑Events pro Mieter. Rate‑Limits und SYN‑Cookies verhindern, dass einzelne Sites den Stack überlasten. So bleibt die Seitentrennung selbst bei Fehlern in Apps wirksam.
Host-Härtung und Minimal‑OS
Ich reduziere die Basis‑Angriffsfläche, bevor ein Tenant überhaupt startet. Das Host‑OS bleibt schlank, unnötige Pakete und Compiler fehlen standardmäßig. Systemdienste laufen mit harten Defaults, Mount‑Punkte sind mit noexec,nosuid,nodev und ro‑Binds abgesichert. sysctl‑Schalter drosseln riskante Funktionen (ptrace‑Scope, unprivileged user namespaces, core‑dumps, spoof‑Schutz). LSM‑Profile erzwingen Mandatory Access Control, Audit‑Regeln protokollieren sensitive Syscalls. Ich halte Kernel und Userland aktuell, nutze falls möglich Live‑Patching und sichere Boot‑Ketten. So verhindert bereits die Basis, dass ein Fehler in höherer Schicht zum Volltreffer wird.
- Readonly‑Systembereiche und unveränderliche Configs per Integrity‑Schutz
- Strikte Device‑Zugriffe: nur notwendige /dev‑Nodes werden in Jails sichtbar
- Standard‑seccomp‑Filter, die gefährliche Syscalls pauschal ausschließen
Datenbank-Isolation mit RLS und Tenant-IDs
Ich erzwinge in jeder Tabelle einen tenant_id-Bezug und prüfe ihn in allen Abfragen. In PostgreSQL setze ich Row‑Level Security ein und lade den Kontext per Parameter, damit selbst vergessene WHERE‑Klauseln ins Leere laufen. In MySQL sichere ich über Views, Stored Procedures und Trigger, die nur Zeilen des aktiven Mieters freigeben. Zusätzlich verschlüssele ich Daten at‑rest mit starken Algorithmen und setze TLS 1.3 für alle Verbindungen. Backup‑Jobs trenne ich logisch, damit Wiederherstellungen keine fremden Daten berühren. So hindere ich Lecks auf der SQL-Ebene zuverlässig.
Queues, E‑Mail und andere Nebenkanäle schützen
Neben DB und HTTP isoliere ich Nachrichtenpfade: Message‑Broker nutzen vhosts/Namespaces je Tenant mit eindeutigen Credentials und ACLs. Für Redis ergänze ich ACLs zu den bereits genannten Key‑Namespaces, Memcached binde ich pro Mieter an eigene Sockets/Ports. MTAs trennen Spools und DKIM‑Schlüssel je Domain, Rate‑Limits und Greylisting greifen pro Konto, nicht global. Outbound‑SMTP geht durch Egress‑Filter mit Volumen‑Schwellen je Tenant, um Reputationsschäden zu vermeiden. DNS‑Zonen verwalte ich getrennt, Signaturen (DNSSEC) und Zertifikate (separate Keys) folgen klaren Eigentumsgrenzen. So schließen auch Nebenkanäle keine Lücken in die Isolation.
Prozess-Isolation in der Praxis
Für PHP, Node.js oder Python versiegele ich Laufzeitumgebungen mit eigenen UIDs, separaten Sockets und restriktiven Dateirechten. Webserver wie nginx oder Apache sprechen jede App über isolierte Upstreams an, nicht über globale Sockel. Syscalls grenze ich mit seccomp‑Profiles ein, damit gefährliche Aufrufe gar nicht erst möglich sind. Start‑Skripte setzen Minimal‑Capabilities statt vollständiger Root‑Rechte. Wer Varianten vergleichen will, findet Details unter Prozess-Isolation vergleichen. So lässt sich der Scope jeder App eng halten.
Dateisystem, Speicher und Caches trennen
Ich sperre jeden Mieter in ein eigenes Chroot– oder CageFS‑Jail und verschlüssele Home‑Verzeichnisse je Konto. AppArmor/SELinux‑Profile definieren, welche Pfade eine App sehen darf, und verweigern Traversal in Nachbarhomes. Für Objekt‑Speicher nutze ich tenant‑spezifische Präfixe und IAM‑Policies, die ausschließlich auf diese Pfade zielen. In Caches wie Redis versioniere ich Keys mit Namensräumen wie tenant:{id}:key, damit keine Kollisionen entstehen. Risiken durch geteilte Speicherbereiche adressiere ich gezielt; ein Überblick zu Shared-Memory Risiken zeigt praktische Leitplanken. So bleiben flüchtige Daten strikt getrennt.
Provisioning, Deprovisioning und sichere Löschung
Ich automatisiere den Lebenszyklus je Tenant: Beim Onboarding erzeuge ich eigene UID/GID‑Ranges, Home‑Skeletons und isolierte Service‑Units. Secrets entstehen erst bei Erststart, wandern verschlüsselt in das Ziel (z. B. per KMS) und werden nie in Images gebacken. Namensräume, Quotas und Policies werden idempotent angewendet, damit Wiederholungen keine Lücken reißen. Beim Offboarding lösche ich Daten deterministisch: kryptografische Schlüssel werden zerstört (Crypto‑Erase), Volumes überschrieben oder sicher verworfen, Logs in Archiv‑Buckets überführt. Domains, IPs und Zertifikate gehen durch eine Quarantäne, bevor sie neu zugewiesen werden. So verhindere ich Datenremanenz und Geister‑Berechtigungen.
Ressourcenlimits: cgroups, Quotas und Fairness
Ich setze pro Tenant harte Limits für CPU‑Zeit, RAM, I/O und Prozesse. cgroups v2 und I/O‑Controller verhindern, dass exzessive Jobs den Host verlangsamen. PHP‑FPM Pools oder Node‑Worker dimensioniere ich mit maximalen Kindern und Memory‑Ceilings. Storage‑Quotas begrenzen belegten Platz, Inodes verhindern Millionen winziger Dateien. Scheduler‑Klassen prorisieren kritische Dienste, damit Admin‑Zugänge auch unter Last erreichbar bleiben. So bleibt der Host für alle Mieter performant.
DoS‑, Abuse‑ und Egress‑Kontrollen pro Tenant
Ich kapsle auch Auslastung pro Konto: Verbindungstabellen, HTTP‑Kontexte und Rate‑Limiter zählen immer je Tenant. Auf dem Host begrenze ich gleichzeitige Sockets, Verbindungsaufbauten und Bandbreite per Traffic‑Shaping, zugeordnet zu NetNS/UID. Ausgehender Traffic folgt Allow‑Listen, damit kompromittierte Sites nicht zu Command‑&‑Control‑Relays werden. Für Upload‑/Download‑Spitzen definiere ich Burst‑Fenster und sanfte Rückstau‑Strategien, statt globaler Hartabbrüche. So bleiben Missbrauch und DDoS‑Effekte lokal, ohne andere Mieter zu treffen.
Sitzungs- und Identitätskontext mit JWT und IAM
Ich verankere den Tenant‑Kontext im Token und prüfe ihn an jedem Hop. Gateways validieren Signaturen, setzen Header und verhindern Überschreiben dieser Claims durch die App. Serverseitig erzwinge ich Least‑Privilege‑Rollen, die nur tenant‑spezifische Ressourcen sehen. Temporäre Credentials laufen kurz und binden sich an IP und Zeitfenster. So entfällt Lateralmovement über kompromittierte Schlüssel. Identität wird zur stärksten Grenze im Stack.
Supply‑Chain, Build‑Prozess und Deployment absichern
Ich sperre den Lieferweg ab: Artefakte werden reproduzierbar gebaut, signiert und mit SBOMs versehen. Build‑Runner sind kurzlebig, arbeiten ohne Root und mit minimalem Netz‑Egress nur zu vertrauenswürdigen Registern/Repos. Abhängigkeiten pinne ich und scanne sie vor Freigabe; Promotion in „production“ erfordert Attestierungen aus Build und Tests. Deployments validieren Policies vor dem Ausrollen (Konfig‑Drift, offene Ports, fehlende Quotas). Secrets injiziere ich erst im Zielumfeld, getrennt je Tenant. So verhindert die Supply‑Chain, dass manipulierte Pakete Isolationen unterwandern.
Tenancy-Modelle: Silo, Pool oder Hybrid
Ich wähle das Tenancy‑Modell nach Risiko, Compliance und Budget. Silo trennt streng pro Kunde, kostet aber mehr und benötigt dedizierte Betriebsabläufe. Pool teilt Ressourcen effizient, erfordert dafür feinkörnige Policies und lückenlose Tests. Hybrid kombiniert dedizierte Datenebenen mit geteilten Edges oder umgekehrt. Die folgende Tabelle ordnet Nutzen und Tauschgeschäfte klar ein, damit Entscheidungen belastbar bleiben.
| Isolationsebene | Vorteile | Nachteile | Typisches Beispiel |
|---|---|---|---|
| Silo (dediziert) | Maximale Trennung, klare Compliance-Zonen | Höhere Kosten, separater Betrieb | Eigenes Stack je Großkunde |
| Pool (Shared) | Hohe Auslastung, geringe Kosten | Komplexere Policies, strenge Tests nötig | Standard Shared Hosting |
| Hybrid | Flexible Balance, gezielte Härtung | Mehr Managementaufwand, Risiko der Fehlkonfiguration | Geteilte Edges, dedizierte DBs |
Ich entscheide modellweise je Anwendung: sensible Daten in Silo‑Komponenten, Traffic‑Handling im Pool. Wichtig bleibt, dass ich Übergänge mit Policies sichere und das Monitoring je Grenze verankere. So entsteht ein Setup, das Risiken eindämmt und Kosten kalkulierbar hält. Test‑Suiten mit Mandanten‑Fixtures decken Fehler früh auf. Deployment‑Pipelines prüfen Isolationsregeln automatisiert.
Compliance, Verschlüsselung und Backups je Tenant
Ich trenne Audit‑Logs je Mieter, damit Prüfungen revisionssicher bleiben. Schlüsselmaterial liegt in HSMs oder KMS‑Diensten, Zugriffe folgen strengen Rollen. TLS‑Profile erzwinge ich hostweit, veraltete Cipher fliegen aus der Konfiguration. Backups verschlüssele ich vor dem Transport und prüfe Wiederherstellungen isoliert pro Tenant. Retention‑Pläne stimmen auf Geschäftsanforderungen und rechtliche Vorgaben ab. So bleibt der Datenschutz greifbar und prüfbar.
Forensik, Übungen und Wiederanlauf
Ich plane die Reaktion mit: Immutable‑Logs, saubere Zeitquellen und Snapshot‑Strategien erlauben belastbare Timelines. Kommt es zum Vorfall, setze ich den betroffenen Tenant in einen Quarantäne‑Modus (Readonly‑Mounts, gesperrte Egress‑Pfade, härtere Limits), ohne andere Mieter zu stören. Break‑Glass‑Zugänge sind kurzlebig und protokolliert. Wiederherstellungen erfolgen aus tenant‑spezifischen, geprüften Backups in separaten Umgebungen, bevor der Switch zurück live geht. Table‑Top‑Übungen und Red‑Team‑Szenarien wiederholen diese Schritte regelmäßig; Erkenntnisse fließen als Härtungen in Policies und Tests zurück.
Monitoring, Audits und Störungsreaktion pro Tenant
Ich label jede Metrik mit tenant_id, damit Dashboards Auswirkungen sofort trennen. Fehler‑Budgets berechne ich separat, so priorisiere ich Eingriffe fair. Alarme feuern auf Quotenbrüche, Latenzspitzen und Auth‑Fehler, jeweils im Kontext des Mieters. Playbooks beschreiben Schritte vom Isolieren bis zum sauberen Restore betroffener Ressourcen. Incident‑Berichte fließen in Härtungsmaßnahmen und Testfälle zurück. So lernt die Plattform sichtbar und messbar.
Häufige Angriffswege und direkte Gegenmaßnahmen
Gelingt der Einstieg über eine schwache App, stoppt Prozess‑Isolation die Seitwärtsbewegung. SQL‑Lecks fange ich mit strikter Tenant‑Filterung und RLS auf Tabellenebene ab. Missbrauch durch „Noisy Neighbors“ dämpfe ich mit cgroups, Quotas und skalierenden Limits. Schwache Admin‑Credentials entschärfe ich mit MFA, FIDO2 und kurzen Session‑Zeiten. Gefährliche Shared‑Memory‑Pfade eliminiere ich durch strikte Namespaces und getrennte Sockets. Jede Maßnahme baut eine Hürde gegen Ausbreitung ein.
Kurz zusammengefasst
Shared Hosting bleibt sicher, wenn ich Tenant Isolation als rotes Leitmotiv auf jeder Schicht anwende. Prozesse, Dateien, Netzwerke und Datenbanken trenne ich konsequent, messe Effekte je Mieter und ziehe harte Grenzen. Ressourcenlimits sichern Fairness, RLS und Verschlüsselung schützen Daten, und segmentierte Edges dämpfen Angriffe früh. Audits, Metriken und Alarme machen jede Entscheidung nachvollziehbar und steuerbar. Wer so denkt, hält geteilte Umgebungen zuverlässig dicht und bewahrt Performance für alle.
