Безопасность · Средняя
Как защитить секреты и конфигурацию
Хранить ключи, пароли и токены вне репозитория и логов.
Кратко: за 2 минуты
Хранить ключи, пароли и токены вне репозитория и логов. На выходе: секретов нет в репозитории.
Когда применять
Пункт относится к этапу «Безопасность». Его задача — снижать риски безопасности на каждом этапе разработки. Он нужен до передачи результата разработчикам, QA и команде эксплуатации: иначе команда рискует коммитить .env.
Что это дает
Утечка секретов часто приводит к компрометации данных, инфраструктуры или платежных систем. Это помогает связать работу с общей целью: надежная, безопасная и поддерживаемая система. Практический эффект виден, когда секретов нет в репозитории.
Пошагово: как выполнить
- Используйте env и secret manager.
- Проверяйте, что секреты не логируются.
- Настройте rotation для важных ключей.
Критерии приемки
- Секретов нет в репозитории.
- Production secrets хранятся отдельно.
- Есть процесс замены ключей.
Типичные ошибки
- Коммитить .env.
- Передавать секреты в URL.
- Хранить один ключ для всех сред.
Инструменты
Пример
Плохой пример
Коммитить .env.
Хороший пример
Учебный пример. Ключ платежного провайдера хранится вне репозитория и выдается только сервису оплаты. После ротации новый ключ проверяется на стенде, старый отзывается; журналы не содержат значения ключей.
Шаблон
Реестр секретов и ротации
Скачать рабочий лист этого урока
Выбрать рабочий шаблонРабочий артефакт
Security checklist
Реестр секретов и ротации
Учебный пример. Ключ платежного провайдера хранится вне репозитория и выдается только сервису оплаты. После ротации новый ключ проверяется на стенде, старый отзывается; журналы не содержат значения ключей.
- Auth checks
- Access rules
- Secrets
- Rate limits
Контроль качества
Контроль безопасности backend
Секретов нет в репозитории.
После изменения контрактов, релизов, инцидентов, роста нагрузки и пересмотра архитектурных решений.
Контракт, ограничения, сценарии отказа, метрики, владельца сервиса и критерии готовности.
Перед отметкой выполнено: Секретов нет в репозитории.
Как применять
Начинайте с границ ответственности и пользовательского сценария, который обслуживает система. Затем проверьте контракт, данные, отказоустойчивость, безопасность и наблюдаемость. Хороший backend-пункт фиксирует, что именно меняется, как это проверить и какие метрики покажут стабильность решения.
Короткие ответы
Частые вопросы
Зачем выполнять пункт «Как защитить секреты и конфигурацию»?
Утечка секретов часто приводит к компрометации данных, инфраструктуры или платежных систем. Это помогает связать работу с общей целью: надежная, безопасная и поддерживаемая система. Практический эффект виден, когда секретов нет в репозитории.
С чего начать выполнение?
Используйте env и secret manager.
Как понять, что пункт выполнен?
Секретов нет в репозитории.
Какая ошибка чаще всего мешает результату?
Коммитить .env.
Режим обучения
Тест по теме
Проверка понимания
Ответьте на вопросы по материалу и получите итоговый отчет: что понято хорошо, а что стоит перечитать.
Для углубленного изучения
Редакция Ariol · Версия 2 · Обновлено
Независимая экспертная проверка не заявлена.
Что обновлено
- — Обновлено: Название, Шаблон результата, Пример, Плохой пример, Заголовок поиска, Описание поиска, Поисковые фразы.
Материал предназначен для обучения. Адаптируйте рекомендации к внутренним регламентам компании и условиям проекта.
Предложить исправление через контакты Ariol