Управление секретами

Что считается секретом и как он утекает

Секрет это любое значение, которое подтверждает личность или даёт доступ: API-ключи, пароли баз данных, токены, ключи подписи и закрытые ключи. В памятке OWASP по управлению секретами отмечено, что многие организации хардкодят секреты в исходном коде открытым текстом. Памятка советует централизовать их хранение, выдачу, аудит, ротацию и управление, никогда не прописывать их в инструкциях Docker ENV и ARG и не писать в логи.

У вайб-кодеров обычная утечка это ключ, вставленный в файл с кодом, либо файл .env, закоммиченный в git или доступный через веб-сервер. Push protection на GitHub блокирует пуши с поддерживаемыми секретами, но пользователи с правом записи могут её обойти, так что это страховка, а не план. Если ключ уже утёк, действуйте по руководству что делать после утечки API-ключа и проверьте сайт по статье об открытых файлах .env и .git.

Безопасная база на VPS

Начните с файла, который может читать только пользователь приложения, и держите его вне git и вне корня веб-сервера:

cd /srv/myapp
touch .env
chmod 600 .env
chown deploy:deploy .env
echo ".env" >> .gitignore
ls -l .env

Права 600 означают, что читать и писать файл может только владелец. Запускайте приложение от непривилегированного пользователя, например deploy, а не от root, чтобы ошибка в приложении не позволила читать чужие файлы. См. безопасный деплой приложения на VPS и наименьшие привилегии. Убедитесь, что веб-сервер никогда не отдаёт этот файл: поставьте приложение за обратный прокси и держите секреты вне публичной папки.

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

Дальше файла .env

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

На одном сервере это делают секреты Docker Compose. Каждый выданный секрет появляется в контейнере как файл /run/secrets/<имя>:

services:
  app:
    image: myapp:latest
    secrets:
      - db_password

secrets:
  db_password:
    file: ./db_password.txt

Держите db_password.txt с правами 600 и вне git. Полную схему показывает руководство по деплою Docker Compose на VPS. Когда команда растёт, выделенный менеджер секретов добавляет контроль доступа, журнал аудита и автоматическую ротацию. Идея в том, чтобы приложение получало секрет только на время работы и только тот, который ему нужен.

Ротация, область действия и утечки

Хорошее управление секретами это в основном привычки:

• Один ключ на одну задачу. OWASP требует наименьших привилегий для каждого секрета и компонента, чтобы украденный ключ открывал как можно меньше.
• Ротация. Регулярная, лучше автоматическая ротация означает, что украденные данные работают недолго. После любой подозрительной утечки ротируйте сразу.
• Никогда в браузере. В документации Vite сказано, что переменные, доступные клиентскому коду, не должны содержать чувствительные данные вроде API-ключей. Всё, что попало во фронтенд-сборку, публично.
• Сканирование перед коммитом. OWASP советует искать секреты на уровне разработчика, например в pre-commit хуке.

Если секрет всё же утёк, сначала отзовите или ротируйте его, затем расследуйте и наводите порядок. Удаление коммита не делает раскрытый ключ снова безопасным. Следуйте плану реагирования на инциденты и сначала примените сдерживание.

Связанные термины: Переменные окружения, Наименьшие привилегии, Реагирование на инциденты, Вайб-кодинг, Сдерживание (containment).