postgres, django и общая аутентификация веб-сервера (pg_hba.conf и т. д.)

Question

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

На моем сервере запущены nginx & uwsgi, оба из которых были настроены для работы в качестве своих соответствующих пользователей 'nginx' и 'uwsgi' - оба пользователя были настроены как no-login, no-password.

Все папки моего приложения / проекта созданы под моим собственным (не-root) именем пользователя и группой 'developers'. Они chmod'ы доступны только для чтения всем.

1-й вопрос)

Насколько я понимаю, это хорошая практика, поскольку серверы (uwsgi / nginx) не имеют доступа для записи в эти файлы?

2-й вопрос)

Мой postgres pg_hba.conf is:

local    all    postgres    ident sameuser
local    appdb  appusername      password

где appdb & appusername были настроены через pgsql для конкретного приложения

Означает ли это, что (unix) пользователь 'postgres' может входить в систему только локально, если авторизовано id / unix?

Кроме того, это означает, что единственный доступ к базе данных 'dbname' осуществляется через (psql) пользователя 'dbuser' с правильным паролем

** Заключительная часть **

Если мой сервер (uwsgi) технически имеет доступ для чтения к моему файлу настроек django (в котором есть данные моей базы данных, включая пароль и имя пользователя psql), это не угроза безопасности?

Любые разъяснения приветствуются!

Answer 1

1. Да, это хорошая (хотя и редко встречающаяся для веб-приложений) практика для серверов не иметь доступа для записи или чтения к файлам, которые ему не нужны.

2. Да, это означает, что любой процесс, который запускается пользователем ОС postgres, может обращаться к любой базе данных как пользователь базы данных postgres.И это обеспечивается с помощью Ident, но не небезопасного и ненадежного сетевого идентификатора, а локального, безопасного и надежного SO_PEERCRED.
   
   Я также рекомендовал бы, чтобы службы подключались не по паролю, а по локальному Ident - если злоумышленник каким-то образом получает право на чтениев файл настроек (например, из резервных копий, небезопасной передачи и т. д.) с сохраненным паролем, тогда он может делать что угодно с базой данных.С id он должен иметь возможность запускать код от имени конкретного пользователя, что намного сложнее.

3. Все представляет собой угрозу безопасности.Безопасность - это искусство управления этим риском - управление балансом между безопасным и удобным.Если вы можете настроить свой сервер так, чтобы он не нуждался в доступе к этим файлам, и это не было бы чрезмерно непрактично (например, требуется ручное вмешательство при перезагрузке), тогда сделайте это.Может быть, эта «идентификационная» аутентификация была бы лучше.

Answer 2

1. Как правило, хорошей идеей быть как можно более параноидально в отношении разрешений - так что да.:)
2. Да, да и да.
3. Все, что разрешено, является «угрозой безопасности», но иногда это просто не работает иначе.uWSGI - ваш сервер приложений, как он должен выполнять ваш код, если он не может его прочитать?