Новый веб-сервер: какие учетные записи пользователей мне следует создать и какие разрешения предоставить

Новый веб-сервер: какие учетные записи пользователей мне следует создать и какие разрешения предоставить

Это продолжение моего вопросаздесь.

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

Для 2 разработчиков у меня есть 2 аккаунта (и они добавлены в дополнительную группу devs), и только им разрешено подключаться к серверу по ssh. Для веб-приложения (на основе Django) я создал 1 обычного пользователя app(не настроил его как --systemпользователя и принадлежит к группе app) с доступом к оболочке. 2 разработчика после подключения по ssh к серверу будут использовать su appдля любых обновлений и запуска/остановки приложения. Пользователю appне разрешено выполнять действия su(заблокировано не добавлением в настройку группы в /etc/pam.d/suusing pam_wheel.so). У меня также есть 3-й аккаунт без suвозможностей для задач, связанных с резервным копированием, где задание cron будет подключаться по ssh и извлекать файлы журналов, статус и т. д.

Дайте мне знать, если необходимо улучшить аспекты безопасности. (P.S.: Я здесь новичок)

решение1

suтребует совместного использования пароля. Я предпочитаю sudo. Поэтому разработчики будут запускать либо sudo -u app commandrun commandas app, либо run sudo -u app -i, чтобы запустить интерактивную оболочку как app. Возможно, sudo -u app -i /bin/bashесли вы установили appоболочку 's на что-то вроде /bin/false или /bin/true.

Если им не нужна полная оболочка как приложение, а нужно только перезапустить приложение, вы можете ограничить команды, которые они могут запустить как приложение. Используйте ACL по умолчанию для каталогов, к которым им нужен доступ, который предоставляет доступ разработчикам и приложению, чтобы у вас не было проблем с разрешениями файловой системы. Принцип наименьших привилегий — это то, чему вам нужно следовать, IMHO. Если им это не нужно, не давайте им доступа для этого.

Обычно я предпочитаю использовать ключи только для ssh. Если вы можете это сделать, отключите пароли для разработчиков и установите правила sudo так, чтобы они не требовали пароль. Тогда пароли никому не понадобятся, и, следовательно, не будет паролей, которые можно раскрыть/потерять/сбросить.

Задание по чтению на этот вечер, потому что для этого поста это немного перебор: "как работают ACL файловой системы" и "как настроить sudo". Возможно, после этого последует управление ключами ssh.

Связанный контент