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

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

Мой вопрос: как лучше всего защитить файлы конфигурации, в которых есть строки подключения?

Достаточно ли другого пользователя с [4+] 00 прав доступа к файлу? Стоит ли зашифровать их? Похоже, это просто переносит проблему в другое место, и я беспокоюсь о том, где хранить ключ шифрования. Я понимаю, что разработчикам Perl потребуется собственная строка подключения, поскольку у них будут только разрешения на выполнение базы данных.


linux php database security connection-string
person Chris Kloberdanz    schedule 02.12.2008    source источник
comment
это приложение командной строки или веб-приложение?   -  person Gary Richardson    schedule 02.12.2008
comment
Я думаю, можно с уверенностью предположить, что PHP == веб-приложениям более чем в 99% случаев.   -  person Bill Karwin    schedule 02.12.2008
comment
Это законный вопрос. Некоторые части системы фактически используют интерфейс командной строки.   -  person Chris Kloberdanz    schedule 02.12.2008

Ответы (3)


arrow_upward
8
arrow_downward

Если машина действительно администрируется традиционным способом Unix, где пользователь J. Random не постоянно исключает права root, я бы сказал, что разрешения файловой системы - ваш лучший выбор. Если кто-то получит неавторизованный root-доступ, никакие глупости шифрования не смогут «обезопасить» строку подключения.

Я бы пометил файлы со строкой подключения как принадлежащие «пользователю сценария» и предоставил бы им доступ, как вы описываете.

(Браво за понимание того, что шифрование строки подключения в этом примере ничего вам не дает. Безопасность через неясность контрпродуктивна.)

person Evan Anderson    schedule 02.12.2008
comment
Хорошее подтверждение того, о чем я думал. Я вообще не собираюсь использовать sudo. Иногда безопасность сводит меня с ума, потому что она не может быть идеальной. - person Chris Kloberdanz; 03.12.2008

arrow_upward
2
arrow_downward

Вот ссылка на бесплатный модуль Apache, который помогает управлять доступом к хранилищу паролей:

http://uranus.it.swin.edu.au/~jn/linux/php/passwords.htm

Мне это кажется немного сложным и требует, чтобы вы запускали PHP под mod_php. И все же он не учитывает возможность того, что неавторизованные люди, имеющие доступ к серверу, могут просто прочитать ваш файл паролей.

Я думаю, вы должны полагаться на права доступа к файлам и верить, что неавторизованные люди не имеют возможности sudo использовать UID вашего PHP-приложения или получить root-доступ.

person Bill Karwin    schedule 02.12.2008

arrow_upward
0
arrow_downward

Моим лучшим решением до сих пор было хранить файлы конфигурации в зашифрованном разделе, чтобы люди с прямым доступом к машине не могли снимать пароли, подключив диск к другому ПК, и с разрешениями файловой системы, чтобы люди не могли читать файл изнутри самой ОС.

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

person Community    schedule 02.12.2008