Чтение URL прокси из конфигурации держит пароль вне файла исходного кода. Это полезно, когда файл используется совместно или находится под контролем версий. Однако это не делает учётные данные невидимыми для процесса, который их использует.

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

Держите секрет вне рутинной диагностики после загрузки. Печать полного словаря прокси может свести на нет пользу от удаления пароля из скрипта. Вместо этого записывайте в журнал безопасный идентификатор учётной записи или конечной точки.

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

Разделите цель на два вопроса: где хранятся учётные данные и кому разрешено пользоваться учётной записью прокси. Изменение конфигурации может решить первый, автоматически не меняя второй.

Похожие статьи