Golang. Хранение паролей для доступа к базе данных безопасно

Интересные обсуждения по теме на других ресурсах:

• Reddit - Best practices for storing API keys and passwords securely in Golang?
• Reddit - passwords, secrets, keys - best practice
• Stackoverflow - Is it secure to store passwords as environment variables

Почему стоит хранить в формате переменных окружения

Есть довольно интересная методология от разработчиков облачной платформы Heroku, под названием Twelve-Factor App. Лучшие практики относительно хранения паролей, ключей API описаны здесь, раздел config. Так же есть два перевода на хабре выжимка и полный.

Конфигурация — это все параметры, которые меняются в зависимости от того где запущено приложение: логины, пароли, адреса баз данных, ключи api и т.д.

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

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

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

Приложение двенадцати факторов хранит конфигурацию в переменных окружения (часто сокращается до env vars или env). Переменные окружения легко изменить между развертываниями, не изменяя код. В отличие от файлов конфигурации, менее вероятно случайно сохранить их в репозиторий кода. Так же в отличие от пользовательских конфигурационных файлов или других механизмов конфигурации, таких как Java System Properties, они являются независимыми от языка и операционной системы стандартом.

В приложении двенадцати факторов переменные окружения являются не связанными между собой. Каждая переменная окружения полностью независима от других. Они никогда не группируются вместе в “окружения”, а вместо этого управляются независимо для каждого развертывания.

Защищённость переменной окружения.

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

Библиотеки Golang для шифрования/хранения секретов

Для шифрования/хранения секретных можно использовать следующие библиотеки:

• keyring - работает с хранилищами учётных данных встроенных в систему, такими как Windows Credential Manager, KWallet и другие. Но при компрометации системы это опять же не особо поможет.
• sops - библиотека для работы с Mozilla Sops. Позволяет шифровать/дешифровать данные. В данном случае основная проблема это хранение приватного ключа. Он не должен храниться на машине где запущено приложение, иначе возвращаемся к утечке учётных данных. Соответственно необходима реализация стороннего провайдера для дешифровки в момент, когда это нужно на другой машине. Но для моих целей это уже будет излишнее усложнение.

Поэтому как и предполагал буду хранить переменные окружения в CD/CI GitLab.

Буду рад, если кто-нибудь более компетентный напишет другой ответ.