Пользователи веб-сервера - лучшая практика
SpamAssassin является спам-фильтром для электронной почты. Это полно умных правил, которые смотрят на почтовые заголовки, чтобы видеть, фальсифицируются ли они или содержат подсказки для спамных отправителей.
Сообщения форума (даже когда послано по электронной почте) не ведут себя как электронная почта. Мое предположение - то, что работа SpamAssassin в установке как это будет хуже, чем установка достойного спам-фильтра форума.
Лучшая практика: Имейте трассируемость для всех привилегированных действий. Это не означает логинов как корня при нормальных обстоятельствах; люди входят в систему с их собственными идентификаторами и полномочиями. Меры, которые они принимают, прослеживаемы. Если конкретная учетная запись поставлена под угрозу, она может быть зафиксирована, не влияя на другие учетные записи или систему в целом.
Лучшая практика: Наименьшее количество полномочия. Люди и приложения получают полномочия, они должны выполнить свои авторизованные операции, но не больше.
После тех двух принципов ответ на Ваш вопрос. Точно то, как Вы следуете за ними, ваше дело. Это зависит от того, что Ваша политика сайта рекомендует, сложность Вашего настроенного сервера, планы непрерывности, и т.д. Обратите внимание, что следование за этими принципами идет на компромисс Вашей системы враждебным более трудным нападением, но что еще более важно это ограничивает последствия полной благих намерений ошибки.
Для вещей как обслуживание веб-сервера большинство возможностей может быть включено, не требуя корневого доступа подходящим владением пользователя/группы, и полномочия (обратите внимание, что исходный вопрос имел теги linux/unix). Например, файлы конфигурации веб-сервера могли принадлежать "wserver", группа "wsgroup" и permissioned 664. Это позволит любому пользователю читать конфигурацию и любого в "wsgroup" для редактирования файлов (не обязательно, что Вы хотите). Веб-контент мог быть в другой группе, пока процесс веб-сервера прочитал или возможно выполняет разрешение, содержание может быть подано. Это позволит отличающийся (возможно, накладывающийся) группы поддерживать веб-сервер и содержание.
Можно также настроить sudo чтобы данный пользователей выполнил определенные команды как определенных пользователей. Для лучших практик необходимо ограничить корневой доступ к тем немногим объектам, которые на самом деле требуют полномочий пользователя root (например, запуская процесс, который слушает на привилегированном порте). Настройте остальных, по мере необходимости предоставив так же мало полномочий по мере необходимости - который помогает ограничить последствия ошибок. Например, если Вы хотите позволить группе редактировать файлы конфигурации веб-сервера, позвольте им выполнять {энергию, emacs, gedit} как владелец файлов конфигурации.
Мы - небольшая webdev компания с горсткой серверов.
Каждый администратор имеет их собственную учетную запись на каждом сервере и обычно регистрирует на пути сертификат. Однако они могут также зарегистрировать на пути пароль, так как они, возможно, должны войти в систему от удаленного местоположения, где у них не может быть своего сертификата с ними.
Непосредственно вход в систему как корень только позволяется с помощью сертификата. Мы не полностью запретили удаленный корневой вход в систему, так как это очень полезно для передачи файлов между серверами через rsync и scp, однако только пользующимся наибольшим доверием администраторам добавили их сертификаты к authorized_keys файлу корня.
Администраторы получают права суперпользователя через sudo путем создания их членом группы колеса.
Это не защищает от злонамеренных администраторов, но это действительно обеспечивает некоторый вход и способность отключить отдельные учетные записи, когда администратор уезжает. Это, также не масштабируется хорошо, но хорошо для маленького numer серверов.
Сценарии, для которых нужны полномочия суперпользователя, такие как Capistrano, который мы используем для развертывания наших веб-сайтов с управления версиями на веб-серверы, получают свои собственные учетные записи пользователей и могут использовать sudo для выполнения действий суперпользователя. Но, они ограничены только командами, которых они требуют через Cmnd_Alias sudo.
Я думаю об установке, Аналогично Открываются так, мы можем связать аутентификацию в наш домен Active Directory. Это помогло бы централизовать аутентификацию, управлять паролями и предоставить детализированные полномочия.