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

У нас есть сервер разработки и живой сервер с различными сведениями о соединении с базой данных (имя пользователя, пароль и т.д.).

В настоящее время мы храним BOTH данные о соединении с базой данных в файле initial.php, и один выбирается, если присутствует оператор DEFINE. Мы вручную добавляем этот оператор DEFINE на наш живой сервер.

Это безопасный подход? Каковы наилучшие/альтернативные подходы для управления безопасностью соединений с БД?

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

Ответ 1

Я использую .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-константы.

Ответ 2

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

Ответ 5

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

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

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

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

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