Секреты, .env и утечки в логах и коммитах

Файлы .env и облачные учётные данные — самый быстрый путь превратить демо в инцидент. Утечки редко бывают в одном месте: они расползаются по истории shell, логам CI, дампам и форкам. Храните секреты в менеджерах и короткоживущих токенах, а не в вечных строках в дереве проекта.

Структура урока: кольца — уровни, где живёт секрет; code-explorer — разбор опасного фрагмента; timeline — типичная утечка; таблица — куда класть конфиг; карточки — меры.

Где на самом деле лежит секрет
Внешнее кольцо — то, что видно первым; внутрь — тем сложнее зачистить следы.
Слои
Рабочая копияИстория GitАвтоматизация
Внешнее кольцо — то, что видно первым; внутрь — тем сложнее зачистить следы.
Опасный фрагмент .env
Построчно: что вращать в первую очередь после утечки?
bash
1
DATABASE_URL=postgres:// svc:SuperSecret@db.internal:5432/приложение
▼
2
AWS_ACCESS_KEY_ID=AKIA...
▼
3
SLACK_WEBHOOK=https:// крючки.slack.com/...
▼
4
# committed by mistake — rotate everything below
▼
Как развивается утечка
Точки — ориентир для постмортемов.
Куда класть конфигурацию?
Часто комбинируют: удобство разработки vs радиус поражения.
ПодходТипичное применение
.env (в .gitignore)Только локальная разработка — не как единственный источник для прода.
Secret managerVault, AWS SM, GCP SM — аудит и ротация.
Секреты CI / OIDCВ пайплайнах — федерация вместо статических ключей.
Усиление защиты
Одно улучшение за спринт — накопительный эффект важнее разового «пожара».
Если секрет попал в публичную ветку — считайте его скомпрометированным: ротация и аудит логов, а не только удаление файла в HEAD.