Коли я повинен створити новий обліковий запис користувача для запуску програмного забезпечення на сервері?

Загалом, коли слід створити новий обліковий запис користувача, щоб запустити на сервері частину програмного забезпечення, що стоять перед Інтернетом?

Наприклад, припустимо, що я використовую спільний сервер Debian (наприклад, через Dreamhost), і я хочу запустити деякі веб-сайти за допомогою WordPress, деякі з Redmine, деякі з Ruby on Rails, можливо, з використанням Django, і я хотів би обслуговувати Mercurial сховища теж.

На серверах Dreamhost та багатьох інших серверах з подібним налаштуванням все це можна зробити за допомогою одного облікового запису користувача , але я бачу деякі недоліки цього підходу:

• Більш довгий .bashrc
• Якщо цей обліковий запис стає порушеним, це роблять усі сайти, що працюють під ним.

З іншого боку, наявність великої кількості облікових записів користувачів може неприємно відслідковувати, особливо якщо деякі з них мають однакові вимоги щодо встановленого програмного забезпечення. Наприклад, мати один обліковий запис для кожного веб-сайту, на якому працює WordPress, може бути зайвим.

Яка найкраща практика? Це просто питання зменшення кількості розміщених сайтів (або розміщених сховищ тощо) на обліковий запис користувача пропорційно рівню параної?

Будь ласка, опублікуйте свої думки з цього приводу, виклавши свої причини для них.

Крім того, якщо у вас є якісь причини вважати, що підхід, прийнятий на приватному сервері або VPS, повинен відрізнятися від підходу, який використовується на спільному сервері, будь ласка, охарактеризуйте, що вони є, і, знову ж таки, свої причини для них.

Я, як правило, шанувальник "Один користувач на все, що відкриває прослуховувальний сокет у мережі" - один для Apache, один для пошти, один для DNS тощо.

Це (як я останній раз чув), як і раніше найкраща поточна практика, і причиною цього є звичайна і проста параноїя: ці сервіси піддаються великому поганому Інтернету, якщо хтось виявить вразливість і використовує його, перш ніж у мене є можливість виправити програмне забезпечення, принаймні, я обмежую їх одним обліковим записом користувача, маючи лише ті пільги, які необхідні для запуску єдиної послуги, за яку він відповідає.
Взагалі кажучи, я вважаю, що цей рівень ізоляції є достатнім для захисту системи, хоча кожен додаток є островом вразливості (наприклад, якщо хтось встановлює вразливий плагін WordPress, всі речі, до яких Apache має доступ (тобто всі веб-сайти), є вразливими у випадку компромісу.

Таким чином, розширена версія цього аргументу може бути зроблена для веб-сайтів клієнтів спільного хостингу з пісочницею з його власною конфігурацією Apache та користувачем (вам не обов'язково встановлювати повний стек веб-сторінок для кожного сайту, а лише окрему конфігурацію апаша із зазначенням іншого користувача ), що недоліком є ​​те, що зараз на кожному веб-сайті працює безліч процесів Apache, тому використання вашої оперативної пам’яті просто значно зросло, і речі, які читаються у всьому світі, залишаються вразливими, якщо порушується будь-який екземпляр / користувач Apache.

Подальше розширення аргументу для того, щоб помістити кожного Apache в chroot (або в'язницю, якщо ви на BSD-системах), можна зробити ще більшою безпекою, але тепер ви говорите про додатковий дисковий простір, оскільки для кожного chroot / jail буде потрібно все програмне забезпечення, необхідне для запустіть сайт, який він містить (і потрібно оновлювати це програмне забезпечення для кожного сайту, а не лише одну головну копію на сервері, коли виходять патчі), плюс вимогу оперативної пам’яті, як і коли були окремі екземпляри користувачів / апаш.
Це пом'якшує все, крім помилки ОС / ядра, що дозволяє користувачам вириватися з хротону (що стає аргументом для запуску кожного сайту на окремому фізичному сервері - який потім стає аргументом для розділення сайтів на різні vlans / subnet тощо).

Як і всі ризики, ви не можете його усунути: ви можете лише зменшити його до прийнятного рівня, виходячи з потенційної шкоди / вартості компромісу, ймовірності компромісу та вартості кожного рівня пом'якшення.
На мої гроші, для некритичного, неелектричного комерційного середовища для спільного хостингу, основне "Один користувач для Apache, один для DNS, один для пошти тощо". сітки безпеки достатньо. Якщо є потреба в безпеці поза цим рівнем, ваші користувачі повинні серйозно розглянути питання про власне обладнання.

Як правило, у мене є один користувач для зовнішніх служб, на яких заборонено входити (наприклад, "ніхто"), і один обліковий запис, на який дозволено входити в систему і su або sudo. Звичайно, переконайтеся, що ваші імена користувачів відрізняються і їх легко легко довідатися.

Я не вважаю необхідним одного користувача на послугу, якщо ви не використовуєте спільне середовище хостингу, де кожен клієнт має вхід. Якщо ви реалістично вважаєте себе дуже привабливою ціллю для злому, ви можете максимально ізолювати їх. Однак, якщо ви робите щось дуже суперечливе або розміщуєте фінансові дані, ви насправді не такі привабливі для цілі.