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