Секреты и .env в разработке: как не слить ключи в git

Прямой ответ

Секреты (API-ключи, пароли БД, токены) не должны попадать в код и в git — точка. Рабочий стандарт: значения живут в переменных окружения, локально — в файле .env, который в .gitignore с первого коммита; в репозитории хранится только .env.example с пустыми значениями. Утечка в истории git не лечится удалением файла в новом коммите — нужна немедленная ротация ключа, и только потом чистка истории. Автоматическая страховка — сканеры секретов (gitleaks) в pre-commit-хуке.

Базовая схема проекта

project/
  .env            # реальные значения — никогда в git
  .env.example    # те же ключи, пустые значения — в git
  .gitignore      # содержит .env

.env:

DB_PASSWORD=...
OPENAI_API_KEY=...

Приложение читает переменные окружения (python-dotenv, dotenv-flow, docker env_file). Методология «конфигурация через окружение» описана в 12-factor — это отраслевой стандарт, а не изобретение команды. В Docker Compose файл подключается как env_file: .env — примеры в статье про локальный Compose-стек.

Три частые ошибки новичков: .env добавлен в git до .gitignore (файл уже в истории); .env закоммичен «временно»; значения продублированы хардкодом в коде «для отладки» и забыты.

Если ключ всё-таки попал в git

Порядок действий, где первый шаг обязателен:

Немедленно отзовите/перевыпустите ключ в сервисе (GitHub, OpenAI, облако, БД). Удаление из git не спасает: историю клонировали, боты сканируют публичные репозитории за минуты.
Оцените ущерб: что успел сделать злоумышленник (логи сервиса, биллинг, доступы).
Вычистите историю: git filter-repo --path .env --invert-paths (официально рекомендуемый инструмент) и force-push; у публичных репозиториев считайте историю скомпрометированной навсегда — спасает только ротация.
Добавьте защиту от повторения (следующий раздел).

Проверка истории на уже забытые утечки: gitleaks detect сканирует все коммиты и находит ключи по сотням сигнатур — стоит прогнать на старых личных репозиториях, там регулярно находятся «учебные» токены.

Автоматическая страховка: сканеры в pre-commit

Локальный хук блокирует коммит с секретом до пуша:

# через pre-commit framework (.pre-commit-config.yaml)
repos:
  - repo: 
    rev: v8.x
    hooks: [{id: gitleaks}]

Ложные срабатывания (тестовые строки, примеры) допускаются через allowlist — но каждый allowlist-элемент должен быть осмысленным. На стороне сервера включите штатное: GitHub push protection / secret scanning для организации — второй эшелон.

Хранение на самом ноутбуке

Менеджер паролей (Bitwarden/KeePassXC/1Password) для человеческих доступов; копипаст ключа из менеджера лучше, чем «секретный notes.txt на рабочем столе».
SSH-ключи: ~/.ssh с правами 600/700, passphrase на приватном ключе; агент ключей (ssh-agent, на macOS — Keychain) вместо пароля на каждое подключение. Настройка подключений — в статье про remote-разработку по SSH.
Шифрование диска (BitLocker/FileVault/LUKS) включено: при краже ноутбука .env и ~/.ssh не читаются с вынутого SSD.
Бэкапы: .env и SSH-ключи входят в зашифрованный бэкап, но никогда — в публичное облако в открытом виде.
Личные и рабочие секреты раздельно: разные профили менеджера/файлы; увольнение/смена проекта не должны оставлять «хвостов» доступов на личном устройстве.

Гигиена командной работы

Ротация по расписанию и по событиям (ушёл сотрудник, засветился лог).
Минимальные права: ключ только под нужную операцию (read-only токен вместо admin).
CI/CD: секреты в хранилище раннера (GitHub Actions secrets), никогда — в YAML и артефактах сборки; логи с секретами маскируются штатно, но проверяйте кастомные скрипты.
.gitignore с .env — в шаблоне нового проекта/скелете репозитория, чтобы правило действовало с первого коммита; при работе с монорепозиториями шаблон особенно важен — см. Git-монорепозитории.

Чек-лист самопроверки за 15 минут

Пройдите список по своим активным проектам — он закрывает типовые дыры личного ноутбука:

Инвентаризация: выпишите, где у вас вообще есть секреты: .env проектов, ~/.ssh, облачные CLI (~/.aws/credentials, gcloud), токены пакетных менеджеров (~/.npmrc), конфиги БД-клиентов.
Git-чистота: в каждом репозитории git log --all -- .env | head — пусто? Затем gitleaks detect по всей истории. Найденное — немедленно ротировать (шаги выше).
Права файлов: chmod 600 .env ~/.ssh/id_* (Linux/macOS); на Windows — свойства файла → безопасность, убрать «Все».
Шифрование диска: BitLocker/FileVault включены — при выключенном диске кража ноутбука равна утечке всех секретов.
Облачные CLI: профили с минимальными правами; админ-ключи облака на личном ноутбуке не хранят в принципе.
Резервная копия: .env и SSH-ключи входят в зашифрованный бэкап (например, архив с паролем из менеджера), но не в синхронизируемую папку в открытом виде.
План инцидента: вы знаете, где отзывать каждый ключ (панель GitHub, консоль облака, админка БД)? Проверьте, что доступ к этим панелям есть с телефона — при краже ноутбука действовать нужно быстро.

Пункт 7 недооценён: скорость ротации при инциденте важнее всех профилактических мер вместе. Держите ссылку на страницы отзыва ключей ваших сервисов в заметке менеджера паролей.

FAQ

Можно ли хранить секреты в зашифрованном виде в git (SOPS, git-crypt)? Да, это рабочая практика для инфраструктурного кода: в репозитории лежит шифртекст, ключ расшифровки — у команды. Для типовых приложений переменные окружения проще и достаточно безопасны.

Чем .env плох в продакшене? Файл на диске — лишний вектор и риск рассинхрона. В проде секреты поступают из хранилища (Vault, облачные Secrets Manager) напрямую в окружение процесса; .env — инструмент локальной разработки.

Помогает ли «захардкодить и удалить в следующем коммите»? Нет: секрет остаётся в истории навсегда. Только переменные окружения с первого коммита и немедленная ротация при утечке.

Что проверить на личном ноутбуке прямо сейчас? Три пункта: .env в .gitignore всех активных проектов; gitleaks detect по старым репозиториям; шифрование диска включено.

Как безопасно делиться .env с напарником по проекту? Не через мессенджеры и не файлом в репозитории: передайте значения через менеджер паролей (общий доступ к элементу) или одноразовым зашифрованным каналом (age/gpg-файл с паролем в другом канале). После завершения совместной работы ключи, которые были общими, разумно ротировать.

Источники: рекомендации GitHub по защите секретов, проект gitleaks, 12-factor (ссылки в шапке).

Секреты разработчика на ноутбуке: .env, ключи API и пароли — хранение без утечек