Чытанне URL проксі з канфігурацыі трымае пароль па-за файлам зыходнага кода. Гэта карысна, калі файл сумесны або пад кантролем версій. Але гэта не робіць уліковыя даныя нябачнымі для працэсу, які імі карыстаецца.

Зменная асяроддзя, інтэрактыўнае запытанне і кіраванае сховішча сакрэтаў даюць розныя спосабы перадачы значэння. Выберыце той, што адпавядае таму, як запускаецца скрыпт. Запланаваная служба не можа адказаць на запытанне, а ўтыліта, якую запускаюць уручную, можа не мець патрэбы ў пастаянным файле пароля.

Трымайце сакрэт па-за звычайнай дыягностыкай пасля загрузкі. Друк поўнага слоўніка проксі можа звесці нанівец карысць ад выдалення пароля са скрыпта. Замест гэтага запісвайце бяспечны ідэнтыфікатар уліковага запісу або канцавой кропкі.

Калі чалавек, які запускае код, кантралюе працэс, шыфраванне ўбудаванага пароля разам з убудаваннем усяго неабходнага для яго расшыфроўкі не стварае надзейнай мяжы адносна гэтага чалавека. Дазволы ўліковага запісу і жыццёвы цыкл уліковых даных павінны адпавядаць гэтай рэальнасці.

Падзяліце мэту на два пытанні: дзе захоўваюцца ўліковыя даныя і каму дазволена карыстацца ўліковым запісам проксі. Змена канфігурацыі можа вырашыць першае, не змяняючы аўтаматычна другое.

Падобныя артыкулы