СЕКРЕТЫ В КОДЕ: КАК Я ПАЛИЛСЯ И КАК ПЕРЕСТАЛ
Когда-то для меня было нормой держать рабочий пароль к БД прямо в коде. У меня был скрипт на Python, который подключается к базе, и пароль был вписан как обычный текст. Рано или поздно это должно было сыграть против меня.
В то время я регулярно проходил занятия по Python. Мы созванивались с программистом, он показывал мне разные фишки. Все уроки он записывал, чтобы я мог посмотреть и лучше разобраться.
И, конечно, при переключении вкладок пароль попал на запись. Несмотря на моё доверие к преподавателю, рабочий пароль пришлось сменить. И если я это заметил, кто-то другой может не заметить утечку.
Другая частая ошибка - пароль в коде попадает в git. При этом гит-репозиторий может быть как публичным, так и приватным. Каким бы он ни был, пароль туда попадать не должен.
Как по неопытности не слить свой пароль? Давайте разбираться.
Хорошие практики
Хранение пароля в коде у разработчиков считается типичной плохой практикой. А что же считается хорошей? Вариантов много. Всё зависит от того, где вы работаете, с чем, от чего этот пароль и какая у вас среда. Пробежимся по вариантам.
1. HashiCorp Vault - корпоративный стандарт для хранения паролей и кредов в целом. Внутри простой интерфейс: создается переменная, ей указывается значение. У одних сервисов есть права на просмотр или изменение переменной, у других - нет. Еще Vault умеет генерировать пароли "на лету" и выдавать их на ограниченное время. Если злоумышленник украдет такой пароль, через час он уже истечёт.
2. Переменные окружения. Самый простой и популярный способ. Пароль хранится в настройках операционной системы или в CI/CD-платформе (GitHub Actions, GitLab CI, Jenkins). В коде же мы пишем просто:
import os
password = os.getenv('DB_PASSWORD')
Если переменная не задана - скрипт упадет с ошибкой, но пароль точно не засветится в коде или репозитории.
3. Файл .env - удобно для локальной разработки. В корне проекта создается файл .env, куда записываются все секреты. Сам файл .env всегда добавляется в .gitignore, чтобы он точно не попал в коммит. В репозиторий кладется файл-шаблон .env.example. В нём указаны имена переменных без реальных значений (значения пустые или фейковые). Новый разработчик клонирует репозиторий, создаёт .env из .env.example и вписывает свои пароли локально.
4. Шифрование конфигурационных файлов. Для этого есть Ansible Vault, git-crypt или SOPS. Конфиг с паролями лежит в репозитории, но в зашифрованном виде. Расшифровывается только в момент деплоя с помощью мастер-ключа, который хранится отдельно. Это компромисс между удобством и безопасностью.
5. Подмена на этапе сборки. В некоторых фреймворках (Docker BuildKit, Webpack) можно подставлять секреты только во время сборки образа, не зашивая их внутрь контейнера. Пароль используется для установки зависимостей из приватных репозиториев, а после сборки - удаляется.
Это только 5 базовых способов, а ведь есть еще...
Пока писал пост, понял, что материала получается на целую статью, так что ловите ссылочку если заинтересовались: https://directprobi.ru/blogs/sekrety-v-kode-paroli-tokeny-peremennye-okruzheniya-env-vault/
Когда-то для меня было нормой держать рабочий пароль к БД прямо в коде. У меня был скрипт на Python, который подключается к базе, и пароль был вписан как обычный текст. Рано или поздно это должно было сыграть против меня.
В то время я регулярно проходил занятия по Python. Мы созванивались с программистом, он показывал мне разные фишки. Все уроки он записывал, чтобы я мог посмотреть и лучше разобраться.
И, конечно, при переключении вкладок пароль попал на запись. Несмотря на моё доверие к преподавателю, рабочий пароль пришлось сменить. И если я это заметил, кто-то другой может не заметить утечку.
Другая частая ошибка - пароль в коде попадает в git. При этом гит-репозиторий может быть как публичным, так и приватным. Каким бы он ни был, пароль туда попадать не должен.
Как по неопытности не слить свой пароль? Давайте разбираться.
Хорошие практики
Хранение пароля в коде у разработчиков считается типичной плохой практикой. А что же считается хорошей? Вариантов много. Всё зависит от того, где вы работаете, с чем, от чего этот пароль и какая у вас среда. Пробежимся по вариантам.
1. HashiCorp Vault - корпоративный стандарт для хранения паролей и кредов в целом. Внутри простой интерфейс: создается переменная, ей указывается значение. У одних сервисов есть права на просмотр или изменение переменной, у других - нет. Еще Vault умеет генерировать пароли "на лету" и выдавать их на ограниченное время. Если злоумышленник украдет такой пароль, через час он уже истечёт.
2. Переменные окружения. Самый простой и популярный способ. Пароль хранится в настройках операционной системы или в CI/CD-платформе (GitHub Actions, GitLab CI, Jenkins). В коде же мы пишем просто:
import os
password = os.getenv('DB_PASSWORD')
Если переменная не задана - скрипт упадет с ошибкой, но пароль точно не засветится в коде или репозитории.
3. Файл .env - удобно для локальной разработки. В корне проекта создается файл .env, куда записываются все секреты. Сам файл .env всегда добавляется в .gitignore, чтобы он точно не попал в коммит. В репозиторий кладется файл-шаблон .env.example. В нём указаны имена переменных без реальных значений (значения пустые или фейковые). Новый разработчик клонирует репозиторий, создаёт .env из .env.example и вписывает свои пароли локально.
4. Шифрование конфигурационных файлов. Для этого есть Ansible Vault, git-crypt или SOPS. Конфиг с паролями лежит в репозитории, но в зашифрованном виде. Расшифровывается только в момент деплоя с помощью мастер-ключа, который хранится отдельно. Это компромисс между удобством и безопасностью.
5. Подмена на этапе сборки. В некоторых фреймворках (Docker BuildKit, Webpack) можно подставлять секреты только во время сборки образа, не зашивая их внутрь контейнера. Пароль используется для установки зависимостей из приватных репозиториев, а после сборки - удаляется.
Это только 5 базовых способов, а ведь есть еще...
Пока писал пост, понял, что материала получается на целую статью, так что ловите ссылочку если заинтересовались: https://directprobi.ru/blogs/sekrety-v-kode-paroli-tokeny-peremennye-okruzheniya-env-vault/