Это мой первый вопрос по ServerFault, и я больше знаком с разработкой программного обеспечения, чем с администрированием, поэтому я не уверен, правильный это вопрос или нет.
Я создаю веб-приложение в качестве учебного упражнения, и я не уверен, правильно ли я использую подход в отношении безопасности. Мой текущий план - создать учетную запись пользователя для приложения в базе данных и удалить все разрешения, кроме тех, которые необходимы для выполнения набора хранимых процедур, которые действуют от имени веб-приложения.
Для справки, приложение будет написано на PHP, и будет использоваться база данных MySQL.
Вообще говоря, лучше всего выполнить аутентификацию / авторизацию через интерфейс, а затем разрешить интерфейсу взаимодействовать с репозиторием с использованием учетной записи приложения. Предоставьте учетной записи приложения минимальный объем доступа, необходимый для работы приложения, чтобы ограничить влияние взломанной учетной записи.
Я также рекомендовал бы избегать использования учетных данных в виде обычного текста в исходном коде или в файлах конфигурации. Рассмотрите возможность шифрования учетных данных или, вполне возможно, запуска приложения под одной учетной записью, чтобы все запросы к базе данных выполнялись в контексте этой учетной записи. Таким образом, администратор сервера несет ответственность за сохранение учетных данных, а не разработчик.
Наконец, я бы посоветовал вам добавить учетную запись приложения к роли в базе данных и предоставить этой роли необходимые разрешения. Это упрощает внесение изменений в учетную запись в будущем (т.е. добавление / удаление роли вместо предоставления / отказа 100 индивидуальных разрешений).
да, это рекомендуемый подход. также возможно одно: когда ваше приложение становится более сложным и у вас есть разные части, которые должны выполнять разную работу с вашей базой данных, вы можете создать больше учетных записей, например один с доступом rw и один с доступом только для чтения.
но не усложняйте его по мере необходимости. это вернет все соображения безопасности, потому что в какой-то момент вы не знаете, какого пользователя для чего использовать, и каждый пользователь получит больше разрешений, чем ему нужно.
Ага, вы все правильно поняли. Даже если пользователи входят в систему, вероятно, лучше всего, чтобы этот вход был аутентификацией для использования программы, в то время как доступ к базе данных осуществляется одним пользователем.
Обратной стороной этого является то, что когда вы проверяете свои журналы SQL, если что-то не так, все изменения будут сделаны одним и тем же пользователем, что затрудняет сужение источника. Хороший дизайн приложения должен предотвращать это по большей части, но помните об этом.
Лучшей практикой, но своего рода «в идеальном мире» было бы иметь те же идентификаторы в базе данных, что и в приложении, а учетные записи пользователей БД имеют только разрешения в БД, которые соответствуют их разрешениям в приложение. Тогда вы можете обойти ситуацию, на которую правильно указал Dynamo - вы можете видеть в БД тех же пользователей, что и в приложении.
Я не знаю, насколько это реально реализовать (я, конечно, не видел, чтобы это было сделано таким образом), но это лучше, чем один пользователь приложения, у которого есть все права на БД приложения, что само по себе много лучше, чем использовать учетную запись sa или аналогичную для подключения приложения.