Beginnen Sie mit den Betriebsanforderungen
Sammeln Sie vor dem Vergleich von Konfigurationen den Anwendungsstack, die Datenbank, Uploads, geplante Aufgaben, Integrationen und erwartete Änderungen jedes Projekts. Identifizieren Sie, wer Inhaltszugriff, Deployment-Zugriff und Host-Administration benötigt. Dies sind unterschiedliche Aufgaben. Ein Kunde, der eine Seite bearbeitet, benötigt möglicherweise nur ein Anwendungskonto; ein Auftragnehmer, der das Betriebssystem wartet, benötigt wesentlich umfassendere Berechtigungen.
Notieren Sie außerdem das akzeptable Wartungsfenster, wer Ausfallzeiten genehmigt, wo Wiederherstellungskopien aufbewahrt werden und wer betriebliche Arbeit bezahlt. Vermerken Sie jede Kundenanforderung nach einem separaten Server oder Konto als Entscheidungsbedingung. Eine Ressourcentabelle kann keine Inhaberschafts- oder Zugriffsanforderung klären.
- Benennen Sie den Hauptbetreiber und einen Ersatz für jedes Projekt.
- Listen Sie gemeinsame Abhängigkeiten auf: DNS-Zugriff, Deployment-Anmeldedaten, Datenbankdienste und Backup-Ziele.
- Unbekannte Anforderungen vor der Entscheidung des Kunden markieren, bevor die Vereinbarung eingegangen wird.
Wählen Sie die Zugriffsgrenze vor der Servergröße
OWASP empfiehlt, nur die Berechtigungen zu erteilen, die für die Tätigkeit einer Person erforderlich sind, und zu überprüfen, dass die beabsichtigten Einschränkungen greifen. Wenden Sie dieses Prinzip auf den Hosting-Plan an: Verwenden Sie individuelle Identitäten, projektspezifische Anwendungsanmeldedaten und einen dokumentierten Deployment-Pfad. Ein nach einem Kunden benanntes Verzeichnis ist eine organisatorische Hilfe, keine Zugriffsrichtlinie.
Bei Verwendung von Docker ist der Zugriff auf den Daemon als Host-Aufgabe zu behandeln. In der Docker-Sicherheitsdokumentation wird erläutert, dass ein vertrauenswürdiger Daemon-Betreiber Host-Dateien einhängen und ändern kann. Einem externen Auftragnehmer uneingeschränkte Docker-Kontrolle zu geben, passt daher schlecht zu einem Host, der Daten eines unabhängigen Kunden enthält.
Getrennte VPS-Instanzen ermöglichen getrennte Betriebssystem-Administration und Release-Entscheidungen. Sie erfordern weiterhin sorgfältige Berechtigungen innerhalb jedes Projekts. Gemeinsame Agentur-Anmeldedaten oder ein geteiltes Deployment-Konto können die Risiken, die Sie trennen wollten, wieder verbinden.
Arbeiten Sie zwei fiktive Kunden-Briefings durch
Die folgenden Kunden sind fiktive Beispiele, keine Kundenhistorien. Die Agentur betreibt derzeit beide Projekte, aber ihre Zugriffs- und Zeitplananforderungen unterscheiden sich.
Diese beiden Projekte zusammenzulegen würde den Contractor-Zugang und den Launch-Zeitplan von Morrow zu einem Teil des Betriebsrisikos von Aster machen. Die Entscheidung für getrennte Server folgt aus diesen Einschränkungen; sie behauptet nicht, dass Morrow eine bestimmte Anzahl von CPUs benötigt oder dass Aster risikofrei ist.
Horizontal scrollen für alle Tabellenspalten.
| Entscheidungsfaktor | Aster Furniture: Broschüren-Website | Morrow Workshops: Registrierungs-Website |
|---|---|---|
| Arbeitslast | Öffentliche Seiten und gelegentliche Inhaltsaktualisierungen | Formulare, eine Datenbank und geplante Registrierungsexporte |
| Zugriff | Kunde bearbeitet Inhalte; Agentur deployt | Externer Entwickler benötigt Host-Administration |
| Wartung | Ein vereinbartes Abendfenster | Keine geplanten Änderungen während eines Buchungsstarts |
| Auswirkung von Vorfällen | Ein vorübergehender Seitenausfall kann besprochen werden | Verlorene oder doppelte Einsendungen erfordern Untersuchung |
| Exit-Anforderung | Inhalte exportieren und die Anwendung verschieben | Eine eigenständig betriebene Umgebung übertragen |
| Vorläufige Entscheidung | Erwägen, mit kompatiblen agenturbetriebenen Sites zu teilen | Einen separaten VPS und separate Projektanmeldedaten verwenden |
Vergleichen Sie die vollen Kosten beider Arrangements
Erstellen Sie zwei Budgetversionen mit dem aktuellen Konfigurator: eine gemeinsame Konfiguration und eine Konfiguration pro Projekt. Listen Sie für jede die Hosting-Gesamtkosten für den ausgewählten Zeitraum, wiederkehrende Optionen, externe Dienste und den Wartungsaufwand der Agentur separat auf. Vermeiden Sie es, einen alten Preis in das Kundenbriefing zu übernehmen. Dokumentieren Sie, wann die Konfiguration erstellt wurde und wer die Zuweisung genehmigt hat.
Bei einem gemeinsamen Host vereinbaren Sie, wie Kunden Fixkosten aufteilen und was passiert, wenn einer ausscheidet oder ein Upgrade benötigt. Gleiche Anteile sind einfach, können aber ungeeignet sein, wenn ein Projekt den größten Teil des Speicherwachstums oder des operativen Aufwands verursacht. Getrennte Server machen die Zuordnung klarer, fügen jedoch separate Patch-, Monitoring- und Wiederherstellungsaufgaben hinzu.
Lassen Sie Ressourcenpuffer für Releases, Backups und temporäre Arbeiten. Docker-Container haben standardmäßig keine CPU- oder Speicherbeschränkungen; konfigurieren Sie angemessene Limits und bewerten Sie die kombinierte Arbeitslast. Eine bloße Containerliste belegt kein tragfähiges Ressourcenbudget.
Machen Sie Wartung und Wiederherstellung projektspezifisch
Bei einem gemeinsamen Host betrifft ein Neustart des Betriebssystems jedes dort ansässige Projekt. Legen Sie die Host-Wartung auf einen gemeinsamen Kalender und bestimmen Sie, wer jeden Kunden kontaktiert. Halten Sie Anwendungs-Releases nach Möglichkeit getrennt und planen Sie den Datenexport eines Projekts nicht während des wichtigen Launches eines anderen.
Wiederherstellungshinweise sollten die Datenbank, Dateien, Konfiguration und erforderlichen Anmeldedaten eines Projekts benennen, ohne Geheimnisse in die Hinweise zu kopieren. Planen Sie die Wiederherstellung an ein separates Testziel. Einen gesamten gemeinsamen Host als erste Reaktion wiederherzustellen könnte gesunde Änderungen des anderen Kunden ersetzen.
Bei getrennten VPS-Instanzen dokumentieren Sie die gemeinsamen Dienste, die bestehen bleiben. Ein gemeinsames DNS-Konto, Backup-Ziel oder ein Betreiber kann weiterhin beide Projekte beeinflussen. Servertrennung ist kein Beweis für unabhängige physische Infrastruktur oder garantierte Verfügbarkeit.
Validieren Sie das Arrangement und legen Sie Überprüfungsauslöser fest
Bevor Sie die Vereinbarung annehmen, lassen Sie einen zweiten Betreiber prüfen, dass eine Projektidentität ihre zugewiesene Arbeit ausführen kann und nicht auf die Dateien, Backups oder Geheimnisse des anderen Projekts zugreifen kann. Prüfen Sie Datenbankberechtigungen und deployte Anmeldedaten ebenso wie Anwendungsoberflächen. Verwenden Sie harmlose Testdaten in einer vereinbarten Umgebung; untersuchen Sie keine Produktionsdaten eines anderen Kunden.
Dokumentieren Sie das Ergebnis als akzeptiert, abgelehnt oder wartend auf eine benannte Korrektur. Wenn die Isolation nicht nachgewiesen werden kann, verengen Sie den Zugriff oder verschieben Sie das Projekt, bevor Sie umfassendere Berechtigungen erteilen. Eine erfolgreiche Antwort der Startseite ist keine Zugriffs- oder Wiederherstellungsprüfung.
- Führen Sie ein Entscheidungsprotokoll mit der gewählten Aufteilung, der genehmigten Kostenverteilung, den Verantwortlichen und ungelösten Punkten.
- Überprüfen Sie die Wahl, wenn ein externer Administrator hinzukommt, sich ein Launch-Fenster ändert, der Speicher wächst oder ein Kunde sich auf das Ausscheiden vorbereitet.
- Nutzen Sie den Verantwortlichkeitsleitfaden, um die technische Wahl in eine Betriebsvereinbarung zu überführen.
Quellen & Prüfung
Technische Referenzen wurden am 12. September 2026 geprüft. Beispiele sind Planungsübungen; referenzierte Softwaredokumentation belegt keine PrivateHostLab Servicefähigkeiten.