Кой е най-добрият начин за защита на низ за връзка с база данни?

Пиша набор от приложения, управлявани от база данни, в 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
Това е легитимен въпрос. Части от системата всъщност използват CLI.   -  person Chris Kloberdanz    schedule 02.12.2008

Отговори (3)


arrow_upward
8
arrow_downward

Ако машината наистина се администрира по традиционния начин на Unix, където J. Random потребител не е изключен от su-ing за 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 приложение или да руутнат.

person Bill Karwin    schedule 02.12.2008

arrow_upward
0
arrow_downward

Най-доброто ми решение досега беше да съхранявам конфигурационните файлове в криптиран дял, така че хората с директен достъп до машината да не могат да изтеглят паролите, като свържат устройството към друг компютър, и с разрешения на файловата система, така че хората да не могат да четат файла от самата операционна система.

Трябва да разберете обаче, че не можете да направите много срещу нападател с директен достъп до машината. Ако работи със самия сървър на базата данни, тогава защитата на конфигурационните файлове няма да има голям ефект, ако той може да модифицира самата база данни. Просто се уверете, че всичко е възможно най-сигурно и вероятно ще бъдете добре.

person Community    schedule 02.12.2008