В общем, когда следует создавать новую учетную запись пользователя для запуска части программного обеспечения с выходом в Интернет на сервере?
Например, предположим, что я использую общий сервер Debian (например, через Dreamhost) и хочу запускать некоторые веб-сайты с использованием WordPress, некоторые с помощью Redmine, некоторые с использованием Ruby on Rails, возможно, некоторые с использованием Django, и я хотел бы обслуживать Mercurial репозитории тоже.
На серверах Dreamhost и многих других подобным образом настроенных серверах все это можно было сделать. под одной учетной записью пользователя, но я вижу некоторые недостатки этого подхода:
С другой стороны, наличие большого количества учетных записей пользователей может стать проблемой для отслеживания, особенно если некоторые из них имеют идентичные требования с точки зрения установленного программного обеспечения. Например, наличие одной учетной записи для каждого веб-сайта, на котором работает WordPress, может быть излишним.
Какая лучшая практика? Это просто вопрос сокращения количества размещенных сайтов (или размещенных репозиториев и т. Д.) На одну учетную запись пользователя пропорционально уровню паранойи человека?
Пожалуйста, опубликуйте свое мнение по этому поводу с указанием причин.
Кроме того, если у вас есть какие-либо основания полагать, что подход, применяемый на частном сервере или VPS, должен отличаться от подхода, применяемого на общем сервере, опишите, что они собой представляют, и, опять же, ваши причины для них.
Я вообще поклонник «Один пользователь для всего, что открывает прослушивающий сокет в сети» - один для Apache, один для почты, один для DNS и т. Д.
Это (как я слышал в последний раз) по-прежнему Лучшая современная практика, и причина этого простая и понятная паранойя: эти службы подвержены воздействию большого плохого Интернета, если кто-то обнаружит уязвимость и воспользуется ею до того, как я смогу исправить ошибку. программного обеспечения, по крайней мере, я ограничиваю их одной учетной записью пользователя, имея только права, необходимые для запуска единственной службы, за которую она отвечает.
Вообще говоря, я считаю этот уровень изоляции достаточным для защиты системы, хотя каждое приложение представляет собой островок уязвимости (например, если кто-то устанавливает уязвимый плагин WordPress все вещи, к которым Apache имеет доступ (то есть все веб-сайты), эффективно уязвимы в случае компрометации.
Таким образом, расширенная версия этого аргумента может быть сделана для изолирования веб-сайтов клиентов Shared Hosting с его собственной конфигурацией Apache и пользователем (вам не обязательно устанавливать полный веб-стек для каждого сайта, просто отдельная конфигурация apache с указанием другого пользователя ). Обратной стороной является то, что на каждом сайте теперь запущено несколько процессов Apache, поэтому использование вашей оперативной памяти существенно возросло, а вещи, доступные для чтения всем, по-прежнему уязвимы, если какой-либо отдельный экземпляр / пользователь Apache будет скомпрометирован.
Расширение аргумента в пользу помещения каждого Apache в chroot (или тюрьму, если вы используете системы BSD) может быть сделано для еще большей безопасности, но теперь вы говорите о дополнительном дисковом пространстве, поскольку для каждого chroot / jail потребуется все программное обеспечение, необходимое для запускать сайт, который он содержит (и необходимость обновлять это программное обеспечение для каждого сайта, а не только одну главную копию на сервере, когда выходят исправления), плюс требования к ОЗУ, как если бы у вас были отдельные экземпляры пользователей / apache.
Это смягчает все, кроме ошибки ОС / ядра, которая позволяет пользователям выйти из chroot (что становится аргументом для запуска каждого сайта на отдельном физическом сервере - который затем становится аргументом для разделения сайтов на разные vlan / подсети и т. Д.)
Как и все риски, вы не можете устранить его: вы можете уменьшить его только до приемлемого уровня, исходя из потенциального вреда / стоимости компрометации, вероятности компрометации и стоимости каждого уровня смягчения.
На мои деньги, для некритичной среды общего хостинга, не связанной с электронной коммерцией, базовый вариант «Один пользователь для Apache, один для DNS, один для почты и т. Д.» подстраховки достаточно. Если существует потребность в безопасности сверх этого уровня, вашим пользователям следует серьезно подумать о собственном оборудовании.
Обычно у меня есть один пользователь для внешних служб, которому не разрешено входить в систему (например, «никто»), и одна учетная запись, для которой разрешен вход и su или sudo. Естественно, убедитесь, что ваши имена пользователей разные и их сложно угадать.
Я не вижу необходимости иметь одного пользователя для каждой службы, если только вы не используете среду общего хостинга, где у каждого клиента есть логин. Если вы реально видите себя очень привлекательной целью для взлома, вы можете максимально изолировать себя. Однако, если вы не делаете что-то очень спорное или хостинг финансовых данных вы на самом деле не что привлекательная мишень.