Zacznij od wymagań operacyjnych
Przed porównaniem konfiguracji zbierz dla każdego projektu stos aplikacji, bazę danych, pliki przesyłane, zadania zaplanowane, integracje i oczekiwane zmiany. Wskaż, kto potrzebuje dostępu do treści, dostępu wdrożeniowego i administracji hostem. To różne zadania. Klient edytujący stronę może potrzebować tylko konta aplikacji; wykonawca utrzymujący system operacyjny potrzebuje znacznie szerszych uprawnień.
Zapisz także akceptowalne okno konserwacyjne, kto zatwierdza przestój, gdzie przechowywane są kopie odzyskiwania i kto płaci za prace operacyjne. Zanotuj wszelkie wymagania klienta dotyczące osobnego serwera lub konta jako ograniczenie decyzyjne. Arkusz zasobów nie rozstrzygnie wymagania dotyczącego własności lub dostępu.
- Wskaż głównego operatora i zastępcę dla każdego projektu.
- Wymień wspólne zależności: dostęp DNS, poświadczenia wdrożeniowe, usługi bazodanowe i miejsca docelowe kopii zapasowych.
- Przed podjęciem zobowiązania oznacz nieznane wymagania do decyzji klienta.
Wybierz granicę dostępu przed rozmiarem serwera
OWASP zaleca przyznawanie wyłącznie uprawnień niezbędnych do wykonywania pracy danej osoby oraz weryfikację, czy zamierzone ograniczenia są zachowane. Zastosuj tę zasadę do planu hostingowego: używaj indywidualnych tożsamości, danych uwierzytelniających aplikacji właściwych dla projektu i udokumentowanej ścieżki wdrożenia. Katalog nazwany imieniem klienta jest ułatwieniem organizacyjnym, a nie polityką dostępu.
W przypadku korzystania z Docker traktuj dostęp do jego demona jako odpowiedzialność na poziomie hosta. Dokumentacja bezpieczeństwa Docker wyjaśnia, że zaufany operator demona może montować i modyfikować pliki hosta. Powierzenie zewnętrznemu wykonawcy nieograniczonej kontroli nad Docker jest zatem słabo dopasowane do hosta zawierającego dane niezwiązanego klienta.
Oddzielne instancje VPS pozwalają na odrębną administrację systemem operacyjnym i odrębne decyzje o wydaniach. Nadal wymagają starannych uprawnień w ramach każdego projektu. Wspólne dane uwierzytelniające agencji lub współdzielone konto wdrożeniowe mogą ponownie połączyć ryzyka, które zamierzałeś rozdzielić.
Przejdź przez dwa fikcyjne briefy klientów
Poniżsi klienci są fikcyjnymi przykładami, a nie historiami klientów. Agencja prowadzi obecnie oba projekty, ale ich wymagania dotyczące dostępu i harmonogramu się różnią.
Połączenie tych dwóch projektów uczyniłoby dostęp wykonawcy Morrowa i harmonogram uruchomienia częścią ryzyka operacyjnego Aster. Decyzja o oddzielnych serwerach wynika z tych ograniczeń; nie twierdzi, że Morrow potrzebuje określonej liczby procesorów ani że Aster jest wolny od ryzyka.
Przewiń w poziomie, aby zobaczyć wszystkie kolumny tabeli.
| Czynnik decyzyjny | Aster Furniture: strona wizytówkowa | Morrow Workshops: strona rejestracyjna |
|---|---|---|
| Obciążenie | Strony publiczne i okazjonalne aktualizacje treści | Formularze, baza danych i zaplanowane eksporty rejestracji |
| Dostęp | Klient edytuje treść; agencja wdraża | Zewnętrzny deweloper potrzebuje administracji hostem |
| Utrzymanie | Uzgodnione okno wieczorne | Brak planowanych zmian podczas uruchomienia rezerwacji |
| Wpływ incydentu | Tymczasowa niedostępność strony może być przedmiotem dyskusji | Utracone lub zduplikowane zgłoszenia wymagają zbadania |
| Wymóg wyjścia | Wyeksportuj treść i przenieś aplikację | Przenieś niezależnie eksploatowane środowisko |
| Decyzja wstępna | Rozważ współdzielenie z kompatybilnymi stronami prowadzonymi przez agencję | Użyj oddzielnego VPS i oddzielnych danych uwierzytelniających projektu |
Porównaj pełny koszt obu rozwiązań
Zbuduj dwie wersje budżetu przy użyciu obecnego konfiguratora: jedną ze wspólną konfiguracją i jedną z konfiguracją dla każdego projektu. W każdej z nich wyszczególnij osobno całkowity koszt hostingu za wybrany okres, opcje cykliczne, usługi zewnętrzne i czas utrzymania przez agencję. Nie kopiuj starej ceny do briefu klienta. Zapisz, kiedy konfiguracja została przygotowana i kto zatwierdził alokację.
W przypadku współdzielonego hosta ustal, jak klienci dzielą koszty stałe i co się dzieje, gdy jeden z nich odchodzi lub wymaga aktualizacji. Równe udziały są proste, ale mogą być nieodpowiednie, gdy jeden projekt powoduje większość wzrostu pamięci masowej lub pracy operacyjnej. Oddzielne serwery czynią przypisanie bardziej przejrzystym, dodając jednak odrębne zadania związane z łataniem, monitorowaniem i odzyskiwaniem.
Zostaw zapas zasobów na wydania, kopie zapasowe i prace tymczasowe. Kontenery Docker domyślnie nie mają ograniczeń procesora ani pamięci; skonfiguruj odpowiednie limity i oceń łączne obciążenie. Sama lista kontenerów nie dowodzi realnego budżetu zasobów.
Uczyń konserwację i odzyskiwanie specyficznymi dla projektu
Na współdzielonym hoście restart systemu operacyjnego wpływa na każdy obecny projekt. Umieść utrzymanie hosta we wspólnym kalendarzu i wskaż, kto kontaktuje się z każdym klientem. W miarę możliwości utrzymuj wydania aplikacji osobno i unikaj planowania eksportu danych jednego projektu podczas ważnego uruchomienia innego.
Notatki dotyczące odzyskiwania powinny wskazywać bazę danych projektu, pliki, konfigurację i wymagane dane uwierzytelniające, bez kopiowania sekretów do notatek. Zaplanuj przywracanie do oddzielnego celu testowego. Przywrócenie całego współdzielonego hosta jako pierwsza reakcja mogłoby zastąpić zdrowe zmiany należące do drugiego klienta.
W przypadku oddzielnych instancji VPS zapisz usługi współdzielone, które pozostają. Wspólne konto DNS, miejsce docelowe kopii zapasowych lub operator nadal mogą wpływać na oba projekty. Rozdzielenie serwerów nie jest dowodem niezależnej infrastruktury fizycznej ani gwarantowanej dostępności.
Zwaliduj rozwiązanie i ustaw wyzwalacze przeglądu
Przed zaakceptowaniem tego rozwiązania poproś drugiego operatora o sprawdzenie, czy tożsamość projektu może wykonywać przydzielone jej zadania i nie może odczytywać plików, kopii zapasowych ani sekretów drugiego projektu. Sprawdź uprawnienia do bazy danych i wdrożone dane uwierzytelniające, a także ekrany aplikacji. Używaj nieszkodliwych danych testowych w uzgodnionym środowisku; nie sonduj danych produkcyjnych innego klienta.
Zapisz wynik jako zaakceptowany, odrzucony lub oczekujący na wskazaną korektę. Jeśli izolacji nie można wykazać, zawęź dostęp lub przenieś projekt przed przyznaniem szerszych uprawnień. Skuteczna odpowiedź strony głównej nie jest kontrolą dostępu ani odzyskiwania.
- Prowadź rejestr decyzji z wybranym układem, zatwierdzonym podziałem kosztów, właścicielami i nierozstrzygniętymi kwestiami.
- Zweryfikuj wybór, gdy dołączy zewnętrzny administrator, zmieni się okno uruchomienia, wzrośnie pamięć masowa lub klient przygotuje się do odejścia.
- Użyj przewodnika po odpowiedzialnościach, aby przełożyć wybór techniczny na umowę operacyjną.
Źródła i przegląd
Odniesienia techniczne sprawdzono we wrześniu 12, 2026. Przykłady to ćwiczenia planistyczne; przywołana dokumentacja oprogramowania nie ustala możliwości usługi PrivateHostLab.