Ответ
Защита репозиториев — критичная часть DevOps-практик. Вот что я настраивал в GitLab и GitHub:
1. Branch Protection Rules (Правила защиты веток)
- Запрет прямых пушей (force push) в главные ветки (
main,master,production). - Обязательный код-ревью: Требование одного или нескольких апрувов от коллег, не являющихся авторами MR/PR.
- Обязательные успешные пайплайны: Мерж-реквест может быть смержен только после успешного прохождения всех стадий CI.
- Требование линейной истории (linear history): Запрет мержей с коммитами, отличными от fast-forward.
2. RBAC (Role-Based Access Control) Четкое разделение прав. В GitLab:
- Guest/Reporter — только чтение.
- Developer — может создавать ветки и MR, но не мержить в защищенные ветки.
- Maintainer/Owner — полные права, включая мерж в защищенные ветки.
3. Сканирование на утечки секретов (Secrets Scanning)
- Интеграция GitGuardian или TruffleHog в пайплайн CI для сканирования каждого коммита на наличие токенов, паролей, приватных ключей.
- Использование HashiCorp Vault или AWS Secrets Manager для хранения секретов, а не в коде.
4. Двухфакторная аутентификация (2FA) Обязательное требование для всех разработчиков с доступом к репозиториям.
5. Подпись коммитов (GPG/SSH Signing) Верификация авторства коммитов и тегов через цифровые подписи. Настраивается на уровне репозитория и клиента Git.
6. Webhooks для аудита и интеграции
- Отправка событий (пуши, мержи, создание веток) в SIEM-систему (например, Splunk) или канал Slack для аудита.
- Интеграция с Jira для автоматического обновления статуса задач.
7. Политики для зависимостей (Dependency Scanning)
- Регулярное сканирование
package.json,requirements.txt,go.modна уязвимости (GitLab SAST, Snyk, Dependabot). - Автоматическое создание MR для обновления уязвимых зависимостей.
Комбинация этих мер создает многоуровневую защиту, где человеческая ошибка (пуш секрета) или злой умысел блокируются автоматическими проверками.
