Где хранить учетные данные для входа в базу данных для приложения PHP

Я использую .ini-файл, который затем разбирается через parse_ini_file(INI_FILENAME_HERE, true) . Этот файл не находится под управлением версиями (как и файлы php- / template- / whatever-files). Поэтому на каждой машине я создаю этот файл (.database.ini) для соответствующего подключения к базе данных.

Пример .ini-файла для MySQL-соединения с использованием PDO:

 [db_general] driver = "mysql" user = "USERNAME" password = "PASSWORD" ; DSN ; see http://www.php.net/manual/en/pdo.drivers.php [db_data_source_name] host = "localhost" port = 3306 dbname = "DATABASE_NAME" ; specify PDO-options, provide keys without PDO:: ; see http://www.php.net/manual/en/pdo.drivers.php [db_pdo_options] MYSQL_ATTR_INIT_COMMAND = "SET NAMES utf8" ; specify more PDO-attributes, provide keys without PDO:: ; see http://php.net/manual/en/pdo.setattribute.php [db_pdo_attributes] ATTR_CASE = "PDO::CASE_LOWER" ATTR_ERRMODE = "PDO::ERRMODE_EXCEPTION" ATTR_EMULATE_PREPARES = false 

Поскольку невозможно использовать :: внутри .ini-файлов-ключей, используйте constant('PDO::' . $iniKey) в вашем коде, чтобы получить нужные PDO-константы.

Мне недавно пришлось решить эту проблему, и я сделал это, создав двух новых пользователей базы данных. Первый не имел никаких привилегий, кроме чтения привилегий на таблицах в его собственной схеме. У второго были привилегии вставки в таблицу «load», которую я бы заполнил своим кодом.

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

Это были не разработчики, о которых я беспокоился, это были аутсайдеры и опытные пользователи, которые теоретически могли получить доступ к веб-серверу и заглянуть в ini-файлы. Таким образом, только разработчики и администраторы баз данных могут отслеживать (и мы все знаем друг друга). Любой другой должен был бы выяснить, как запросить базу данных, выяснить, какой SQL использовать, выяснить, как запустить код … Невозможно, но, конечно, гигантская многоступенчатая боль в прикладе и не стоит того.

Довольно безопасно – в теории, во всяком случае …

Другим подходом было бы установить переменные среды на машине реального времени и разработки и получить к ним доступ из кода … Я не знаю много php, но в python, который будет:

 import os password = os.environ('DB_PASS') 

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

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

Это безопасный подход?

Это зависит от вашего определения безопасности.

каждый разработчик может видеть детали подключения к базе данных

AFAIK, за исключением использования имени пользователя / пароля / базы данных по умолчанию в файле php.ini, эта проблема в значительной степени неизбежна (и использование значений по умолчанию означает, что они автоматически получили доступ к базе данных в любом случае).

Я предполагаю, что вы можете использовать разные файлы include, зашифрованные с помощью zend-кодера, с функцией, которая возвращает дескрипторы базы данных, и настраивать область и разрешения для разных файлов, но ее сложно изолировать PHP-код базовыми данными. Другим подходом было бы ограничить все веб-сервисы и реализовать расширенную модель разрешений в уровне webservice.