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

В общем, когда следует создавать новую учетную запись пользователя для запуска на сервере части интернет-программного обеспечения?

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

На серверах Dreamhost и многих других аналогично настроенных серверах все это можно сделать под одной учетной записью пользователя , но я вижу некоторые недостатки этого подхода:

• Более длинный .bashrc
• Если эта одна учетная запись становится скомпрометированной, то же самое делают все сайты, работающие под ней.

С другой стороны, наличие большого количества учетных записей пользователей может стать проблемой для отслеживания, особенно если некоторые из них имеют идентичные требования в отношении установленного программного обеспечения. Например, иметь одну учетную запись для каждого сайта, на котором работает WordPress, может быть излишним.

Какая лучшая практика? Является ли это просто вопросом уменьшения количества размещенных сайтов (или размещенных репозиториев и т. Д.) На учетную запись пользователя пропорционально уровню паранойи?

Пожалуйста, оставьте свое мнение по этому поводу, указав свои причины.

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

Я, как правило, фанат «Один пользователь для всего, что открывает слушающий сокет в сети» - один для Apache, один для почты, один для DNS и т. Д.

Это (как я слышал в последний раз) по-прежнему лучшая текущая практика, и причина этого заключается в простой и простой паранойе: эти сервисы подвергаются большому плохому Интернету, если кто-то обнаруживает уязвимость и использует ее, прежде чем у меня есть возможность исправить По крайней мере, программное обеспечение я ограничиваю их одной учетной записью пользователя, обладающей только правами, необходимыми для запуска единственного сервиса, за который он отвечает.
Вообще говоря, я считаю этот уровень изоляции достаточным для защиты системы, хотя каждое приложение представляет собой островок уязвимости (например, если кто-то устанавливает уязвимый плагин WordPress, все вещи, к которым у Apache есть доступ (т.е. все веб-сайты), эффективно уязвимы. в случае компромисса.

Таким образом, можно создать расширенную версию этого аргумента для песочницы веб-сайтов клиентов Shared Hosting с его собственной конфигурацией Apache и пользователем (необязательно устанавливать полный веб-стек для каждого сайта, просто отдельная конфигурация apache, указывающая другого пользователя ), недостатком является то, что на каждом сайте в настоящее время выполняется несколько процессов Apache, поэтому использование вашей оперативной памяти существенно возросло, а вещи, доступные для чтения во всем мире, по-прежнему уязвимы, если какой-либо отдельный экземпляр / пользователь Apache подвергается риску.

Расширение аргумента для помещения каждого Apache в chroot (или тюрьму, если вы в системах BSD) может быть сделано для еще большей безопасности, но теперь вы говорите о дополнительном дисковом пространстве, так как для каждой chroot / jail потребуется все программное обеспечение, необходимое для запустите сайт, который он содержит (и нужно обновлять это программное обеспечение для каждого сайта, а не только одну основную копию на сервере при выходе исправлений), плюс требование к оперативной памяти, как если бы у вас были отдельные экземпляры user / apache.
Это смягчает все, кроме ошибки ОС / ядра, которая позволяет пользователям выйти из chroot (что становится аргументом для запуска каждого сайта на отдельном физическом сервере - который затем становится аргументом для разделения сайтов на разные сети / подсети и т. Д.)

Как и в случае со всеми рисками, вы не можете устранить его: вы можете уменьшить его только до приемлемого уровня, основываясь на потенциальном вреде / стоимости компромисса, вероятности компромисса и стоимости каждого уровня смягчения.
За мои деньги, для некритической среды общего хостинга, не относящейся к электронной коммерции, базовый «Один пользователь для Apache, один для DNS, один для почты и т. Д.» Защитная сеть достаточно. Если существует потребность в безопасности выше этого уровня, ваши пользователи должны серьезно подумать о собственном оборудовании.

Как правило, у меня есть один пользователь для внешних служб, которым запрещен вход (например, «никто»), и одна учетная запись, которой разрешен вход в систему и su или sudo. Естественно, убедитесь, что ваши имена пользователей отличаются и не легко угадываются.

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