Что и главное от кого защищаешься? от этого зависит ответ и он будет сильно разный.
Если реально нужно как то защитить данные от провайдера, их администраторов, сканирующих машины своих клиентов на предмет 'чем бы поживиться', то критичные строки нужно в принципе не хранить в файлах а только в оперативной памяти, запрашивая его 'на стороне'.
Этот вариант подходит только для запущенных служб/приложений а не http rest на основе cgi или модулей веб сервера (для них понадобится запустить свою службу, запросы к которой уже будут уязвимы). Метод не даст абсолютной гарантии, так как имея доступ к файлам кода бакэнда провайдер может их проанализировать и вычислить и подменить методику на менее защищенную, в особо запущенных случаях провайдер может и в оперативной памяти машины покопаться, но это особо сложный и дорогой способ, а значит маловероятен.
В момент запуска приложение запрашивает у стороннего сервиса пароль, сторонний сервис его передает, например после ручного подтверждения оператором/владельцем.
Советы
- не использовать типовые технологии и предлагаемые провайдером инструменты, иначе встает вопрос от кого тогда защищаешься то?
- обязательно реализовать ручное подтверждение оператором, администратор знает когда перезапускается веб сервер и если к нему приедет запрос на отсылку пароля в другое время - повод забеспокоиться
- не делать это вопрос ответной системой (типа бакэнд по rpc обращается к удаленному сервису и тот сразу возвращает пароль), так как ее легко вычислить в коде и симулировать вызов, бакэнд запрашивает, но работа сервиса начнется только после того как к нему приедет соответствующий запрос
p.s. пример простой реализации если нужно защитить данные от приглашенного администратора (вариант с заражением им трояном пока опустим, то другими способами фиксится) - все конфиги в открытом виде хранятся в определенном каталоге, по умолчанию там тестовые данные, для проверки работоспособности проекта, а на боевом сервисе или в режиме 'in production' в этот каталог складываются правильные конфиги, например монтированием из encfs, эту операцию делает специальный человек в момент перезапуска сервера вручную.
Само собой правильно - администратор должен не настройкой заниматься, а создавать и настраивать инструменты автоматического развертывания (например образ docker или конфиги ansible), т.е. минимум два человека - один делает всю работу но не имеет доступа к паролям, только тестовые данные, другой только проверяет работу и запускает в бой.
Разделяй и властвуй - не держи все в одном месте, разделяй сервис на несколько, чтобы критичная информация могла быть размещена отдельно от основной логики в виде простого и дубового модуля, требующего минимального и редкого обслуживания
