Перш чым змясціць наладу проксі ў публічны рэпазітар
Аддзяліце канчатковы пункт проксі ад уліковых даных проксі і патлумачце, чаму публікацыя першага не забяспечвае кантроль доступу.
Імя хоста проксі ў файле канфігурацыі не тое самае, што пароль проксі. Публікацыя любога з іх патрабуе свядомага рашэння, але наступствы розныя.
Канчатковы пункт паведамляе чытачам, дзе паслуга можа быць даступная. URL накшталт http://name:[email protected]:8080 таксама дае ім прыдатныя ўліковыя даныя. Ніколі не варта лічыць яго бясшкодным толькі таму, што ён выглядае як адрас.
Схаваны адрас не з'яўляецца палітыкай доступу
Прыватнаму проксі патрэбны кантроль, адпаведны яго карыстальнікам: аўтэнтыфікацыя, дазволеныя сеткі кліентаў і абмежаванні прызначэння. Захаванне адраса па-за рэпазітарам іх не замяняе. Публічна даступную паслугу можна выявіць, нават калі ніхто не чытае вашу канфігурацыю.
Наадварот, публікацыя адраса паслугі не даказвае, што яна адкрытая. Канчатковы пункт можа па-ранейшаму патрабаваць уліковыя даныя або быць даступным толькі з меркаванай сеткі. Праверце фактычную мяжу доступу, а не мяркуйце, што сакрэтнасць і аўтэнтыфікацыя азначаюць адно і тое ж.
Для агульных прыкладаў выкарыстоўвайце дакументацыйныя імёны хостаў і апускайце сакрэты. Захоўвайце прыватныя налады ў усталяваным механізме сакрэтаў або лакальнай канфігурацыі праекта. Будзьце ўважлівыя да створаных файлаў і скапіяваных дыягнастычных журналаў, якія могуць змяшчаць поўны URL з уліковымі данымі.
Калі ўліковыя даныя былі выкрытыя, спачатку пазбаўце іх карыснасці, адклікаўшы або змяніўшы. Рэдагаванне апошняга файла не выдаляе копіі, папярэднія каміты ці змесціва ў кэшы. Кіраўніцтва GitHub па адчувальных даных тлумачыць, чаму ачыстка гісторыі — асобная задача.
Карысны агляд правярае абодва бакі: які доступ дае апублікаваная інфармацыя і ці застаецца проксі абмежаваным, нават калі яго адрас вядомы.