SQL-доступ для веб-приложений

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

Лично я, если я понимаю то, что вы говорите выше, я делаю больше того, о чем думает ИТ-команда (я использую Postgres). Другими словами, мое приложение развертывается через SSH с использованием данной учетной записи (скажем, это учетная запись AppName). Это означает, что мне нужно, чтобы мои SSH-ключи были настроены для безопасного развертывания (используя PEM, known_keys или что-то еще).

В домашнем корне для AppName у меня есть файл с именем .pgpass который имеет довольно специфическую защиту (0600). Это означает, что моя учетная запись AppName будет использовать для входа локальную безопасность, а не имя пользователя/пароль.

Я делаю это, потому что в противном случае мне нужно было бы хранить эту информацию где-то в файле, а эти вещи плохо обрабатываются отправил, например, на github.

В конце концов, подумайте через 5 лет о том, как будут выглядеть ваш проект и команда. Будьте оптимистичны – возможно, это будет ошеломительный успех! Как будет выглядеть техническое обслуживание? Какие ошибки будет совершать ваша команда? Гибкость сейчас — это хорошо, но убедитесь, что решение будет принимать тот, кто попадет в беду, если в вашей базе данных возникнут проблемы с безопасностью.

Лучше всего иметь индивидуальные учетные записи. Это позволяет вам использовать средства базы данных для определения того, кто обращается к базе данных.

Это особенно важно, если данные изменяются. Вы можете регистрировать, кто и какие данные изменяет — обычно это жесткое требование в любой системе, где у пользователей есть такая возможность.

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

Наконец, если вы создаете собственное приложение с несколькими пользователями, имеющими доступ только для чтения к базе данных, может быть проще иметь только одну учетную запись для входа. Обычно вам все равно хотелось бы знать, кто что делает, но для простоты вы можете отказаться от этой функции. Однако знание того, кто что делает, обычно очень полезно для поддержки и улучшения приложения.