Ответ 1
Некоторые вещи сначала...
Вопрос здесь не в том, как скрыть пароль, а как защитить базу данных. Помните, что пароли часто являются очень слабой защитой и не должны считаться единственным механизмом защиты БД. Вы используете SSL? Нет? Ну, тогда даже если вам удастся скрыть пароль в коде приложения, все равно легко нюхать его в сети!
У вас есть несколько вариантов. Все с различной степенью безопасности:
"Роль приложения"
Создайте одного пользователя базы данных для приложения. Примените авторизацию для этой роли. Очень распространенная настройка - разрешить только операции CRUD.
Pros
- очень простая настройка
- Предотвращает
DROP
запросы (f.ex. в SQL-инъекциях?)
Против
- Каждый, кто видит пароль, имеет доступ ко всем данным в базе данных. Даже если эти данные обычно скрыты в приложении.
- Если пароль взломан, пользователь может запускать запросы
UPDATE
иDELETE
без критериев (т.е.: удалить/обновить всю таблицу сразу).
Atomic auth & auth
Создайте одного пользователя базы данных для каждого приложения/конечного пользователя. Это позволяет вам определять права доступа атома даже на основе столбцов. Например: Пользователь X может выбирать только столбцы far и baz из таблицы foo. И ничего больше. Но пользователь Y может SELECT
все, но никаких обновлений, в то время как пользователь Z имеет полный доступ CRUD (выбор, вставка, обновление, удаление).
Pros
- Довольно легко настроить.
- Схема атомной авторизации
Против
- Может быть утомительным
- Пользователи с правами
UPDATE
иDELETE
могут случайно (или намеренно?) удалять/обновлять без критериев. Вы рискуете потерять все данные в таблице.
Сохраненные процедуры с атомным auth & auth
Не записывайте SQL-запросы в приложение. Запустите все через SPROC. Затем создайте db-учетные записи для каждого пользователя и назначьте привилегии только для SPROC.
Pros
- Самый эффективный механизм защиты.
- SPROC могут заставить пользователей передавать критерии каждому запросу (включая
DELETE
иUPDATE
)
Против
- Не уверен, что это работает с MySQL (мои знания в этой области непроницаемы).
- сложный цикл разработки: все, что вы хотите сделать, должно быть сначала определено в SPROC.
Заключительные мысли
Вы не должны разрешать приложениям администрирования базы данных. В большинстве случаев единственными операциями, которые требуются приложения, являются SELECT
, INSERT
, DELETE
и UPDATE
. Если вы следуете этому руководству, вряд ли существует риск того, что пользователи обнаружат пароль. Кроме упомянутых выше пунктов.
В любом случае сохраните резервные копии. Я предполагаю, что вы хотите спроектировать свою базу данных от случайных удалений или обновлений. Но случаются несчастные случаи... помните об этом;)