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

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

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

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

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

19
connections database php security

5 ответов

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

пример .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-константы.

12

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

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

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

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

2

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

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

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

1

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

0

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

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

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

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

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

0