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

Question

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

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

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

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

Answer 1

Я использую INI-файл, который затем анализируется с помощью parse_ini_file(INI_FILENAME_HERE, true).Этот файл не находится под контролем версий (как и php- / template- / what-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-file-keys, используйте constant('PDO::' . $iniKey) в своем коде, чтобы получить нужные PDO-константы.

Answer 2

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

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

Answer 5

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