Защита пароля БД в php

Являюсь новым для веб-разработки. Мне любопытно, как люди это делают.

Я пишу код php, который использует базу данных mysql. На данный момент у меня есть пароль, закодированный в коде. Этот код может быть проверен всеми разработчиками, поэтому каждый имеет доступ к паролю. Мне кажется очень неправым. Кроме того, я могу придумать некоторые осложнения. Я перечисляю вопросы в форме пули –

  1. Пароль, закодированный в коде, неверен. Я не хочу, чтобы все разработчики имели доступ к нему, так как все они могут проверить код.

  2. Как различать серверы / учетные данные для производства и разработки? У меня есть тот же файл, содержащий учетные данные prod и dev DB. Каков наилучший способ справиться с этим?

  3. Я хочу, чтобы предотвратить ленивые / пьяные времена, чтобы разработчики не удаляли / удаляли таблицы и т. Д. У меня, очевидно, есть другой доступ к разным разработчикам. Так это решение всего этого?

Потенциальное решение: не вводите пароль в код. Попросите разработчиков добавить пароль самостоятельно и убедитесь, что его никогда не проверяли.

Проблема с решением: утомительный процесс развертывания. Необходимо добавить пароль для развертывания производства / QA вручную и убедиться, что он способен подключаться к БД каждый раз перед развертыванием. Звучит слишком болезненно и подвержено ошибкам. Что люди обычно делают?

Также на той же ноте (вроде связанного с вышеуказанным вопросом)

  1. Если у вас есть 4 разработчика в команде, как настроить среду разработки? Все ли они используют одну и ту же БД? Если нет, как вы создаете таблицы и заполняете таблицы тестовыми данными? Вам нужно написать код для заполнения тестовых данных?

Большое спасибо за любой вклад.

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

Убедитесь, что вы сохранили файл config.php (или все, что вы хотите назвать) из корневого каталога, также, чтобы он не мог быть случайно отправлен пользователям любого приложения. Кроме того, в качестве дополнительной меры предосторожности убедитесь, что вы предоставили ему расширение .php , так что, если он каким-то образом все-таки будет обслуживаться, он сначала должен быть проанализирован PHP, и любая полезная информация (надеюсь) удалена – обычная практика чтобы назвать его расширением .conf.php или .inc.php по этой причине.

Что касается среды Dev, мы используем единую базу данных, совместно используемую всеми разработчиками. Он был первоначально создан из данных живых клиентов, клонированных в нашу базу данных, с определенной информацией, отредактированной / замененной по соображениям конфиденциальности. Одна и та же база данных используется в нашей сборке разработки, а также в наших сборках localhost.

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

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

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

Производственная версия содержит информацию о подключении для производственного сервера и не читается ненадежными разработчиками. Когда код развертывается на рабочем месте, не развертывайте версию версии файла конфигурации. Тогда версия производственного сервера останется нетронутой.

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