Kiedy powinienem utworzyć nowe konto użytkownika, aby uruchomić oprogramowanie na serwerze?

Zasadniczo, kiedy należy utworzyć nowe konto użytkownika, aby uruchomić na serwerze oprogramowanie internetowe?

Załóżmy na przykład, że korzystam ze wspólnego serwera Debian (np. Za pośrednictwem Dreamhost) i chcę uruchomić niektóre strony internetowe przy użyciu WordPress, niektóre przy użyciu Redmine, niektóre przy użyciu Ruby on Rails, może niektóre przy użyciu Django i chciałbym obsługiwać Mercurial repozytoria też.

Na serwerach Dreamhost i wielu innych podobnie skonfigurowanych serwerach można to wszystko zrobić na jednym koncie użytkownika , ale widzę pewne wady tego podejścia:

• Dłuższy .bashrc
• Jeśli to jedno konto zostanie naruszone, podobnie jak wszystkie witryny działające pod nim.

Z drugiej strony, posiadanie dużej liczby kont użytkowników może być trochę trudnym do kontrolowania, szczególnie jeśli niektóre z nich mają identyczne wymagania pod względem zainstalowanego oprogramowania. Na przykład posiadanie jednego konta dla każdej strony internetowej z WordPressem może być przesadą.

Jaka jest najlepsza praktyka? Czy to po prostu kwestia zmniejszenia liczby hostowanych witryn (lub hostowanych repozytoriów itp.) Na konto użytkownika proporcjonalnie do poziomu paranoi?

Prześlij swoje opinie na ten temat, podając uzasadnienie.

Ponadto, jeśli masz jakiekolwiek powody, by sądzić, że podejście zastosowane na serwerze prywatnym lub VPS powinno różnić się od podejścia zastosowanego na serwerze współużytkowanym, proszę opisz, jakie są, i ponownie, powody ich zastosowania.

Zasadniczo jestem fanem „jednego użytkownika do wszystkiego, co otwiera gniazdo nasłuchiwania w sieci” - jednego dla Apache, jednego dla Maila, jednego dla DNS itp.

Jest to (jak ostatnio słyszałem) najlepsza bieżąca praktyka, a przyczyną tego jest prosta i prosta paranoja: te usługi są narażone na wielki zły internet, jeśli ktoś odkryje lukę i wykorzysta ją, zanim będę miał szansę załatać oprogramowanie przynajmniej ograniczam je do jednego konta użytkownika, z jedynie uprawnieniami wymaganymi do uruchomienia pojedynczej usługi, za którą jest odpowiedzialny.
Ogólnie rzecz biorąc, uważam ten poziom izolacji za wystarczający do ochrony systemu, chociaż każda aplikacja jest wyspą podatną na zagrożenia (na przykład, jeśli ktoś zainstaluje podatną wtyczkę WordPress, wszystkie rzeczy, do których Apache ma dostęp (tj. Wszystkie strony internetowe), są skutecznie wrażliwe w przypadku kompromisu.

Można zatem utworzyć rozszerzoną wersję tego argumentu dla piaskownicowania witryn klientów Shared Hosting z własną konfiguracją Apache i użytkownikiem (niekoniecznie trzeba instalować pełny stos sieciowy dla każdej witryny, wystarczy osobna konfiguracja Apache określająca innego użytkownika ), wadą jest to, że w każdej witrynie jest teraz uruchomionych kilka procesów Apache, więc użycie pamięci RAM znacznie wzrosło, a rzeczy, które można odczytać na całym świecie, są nadal narażone na atak, jeśli zostanie naruszona jakakolwiek pojedyncza instancja / użytkownik Apache.

Można rozszerzyć argument za umieszczeniem każdego Apache'a w chroocie (lub więzieniu, jeśli masz system BSD), aby uzyskać jeszcze większe bezpieczeństwo, ale teraz mówisz o dodatkowej przestrzeni dyskowej, ponieważ każdy chroot / więzienie będzie potrzebował całego oprogramowania wymaganego do uruchom stronę w nim zawartą (i musisz zaktualizować to oprogramowanie dla każdej strony zamiast jednej kopii głównej na serwerze, gdy pojawią się łaty), a także wymagania dotyczące pamięci RAM, tak jak w przypadku oddzielnych instancji użytkowników / apache.
Łagodzi to wszystko oprócz błędu OS / Kernel, który pozwala użytkownikom wyjść z chroota (co staje się argumentem do uruchomienia każdej witryny na osobnym serwerze fizycznym - który następnie staje się argumentem do rozdzielenia stron na różne sieci vlans / podsieci itp.)

Podobnie jak w przypadku wszystkich rodzajów ryzyka, nie można go wyeliminować: można go ograniczyć tylko do akceptowalnego poziomu na podstawie potencjalnej szkody / kosztu kompromisu, prawdopodobieństwa kompromisu i kosztu każdego poziomu ograniczenia.
Za moje pieniądze, w przypadku niekrytycznego, współdzielonego środowiska hostingu e-commerce podstawowy „Jeden użytkownik dla Apache, jeden dla DNS, jeden dla poczty itp.” wystarczy siatka bezpieczeństwa. Jeśli istnieje potrzeba bezpieczeństwa powyżej tego poziomu, użytkownicy powinni poważnie rozważyć własny sprzęt.

Zasadniczo to, co robię, to mieć jednego użytkownika dla zewnętrznych usług komunikacyjnych, który nie może się zalogować (na przykład „nikt”) i jedno konto, które może się zalogować i su lub sudo. Oczywiście upewnij się, że twoje nazwy użytkownika są różne i nie są łatwe do odgadnięcia.

Nie widzę potrzeby posiadania jednego użytkownika na usługę, chyba że prowadzisz wspólne środowisko hostingowe, w którym każdy klient ma login. Jeśli realistycznie postrzegasz siebie jako bardzo atrakcyjny cel hakowania, równie dobrze możesz izolować jak najwięcej. Jednakże, chyba że robisz coś bardzo kontrowersyjnego lub przechowujesz dane finansowe, nie jesteś tak atrakcyjny dla celu.