Секрети, паролі та доступ: мінімальний набір для команди

Три речі, які ламають безпеку найчастіше

1. Секрети в репозиторії — API-ключі в .env, закоміченому «на хвилинку».
2. Один пароль на все — злам одного сервісу відкриває ланцюжок.
3. Занадто широкі права — усі під одним обліковим записом адміна.

Секрети: де їм місце

• У секретних сховищах: CI (GitHub Actions secrets), хмарні Secret Manager, Vault тощо.
• У локальному .env — лише на машині розробника, файл у .gitignore.
• Ротація: після витоку або підозри — ключ замінюється, старий вимикається.

# приклад перевірки, чи не закомічено .env (git)
git ls-files | grep -E '\.env$' && echo "УВАГА: .env у індексі" || echo "OK"

Паролі та облікові записи

• Менеджер паролів для людей; унікальні паролі для критичних сервісів.
• Де можливо — MFA (другий фактор) для хмари, пошти, Git.
• Сервівні акаунти (боти, CI) — окремі ключі, мінімальні права.

Модель доступу

Підхід	Ідея
Least privilege	Лише ті права, які потрібні для задачі
Розділення ролей	Адмін ≠ розробник ≠ лише читання
Аудит	Хто змінював критичні налаштування — має лишатися слід

Безпека — це процес, а не разовий чеклист. Маленькі звички (не шарити паролі в чатах, перевіряти права) економлять години розслідувань.

Почніть з прибирання секретів з git та MFA для адмінки — це дає найбільший ефект при найменших зусиллях.