EMZETT.
Увійти

Emzett Wiki

Керування секретами: безпечне зберігання паролів і ключів у проєктах

Properties1
tagsglossar, devops, sicherheit

2 хв читання

Керування секретами: безпечне зберігання паролів і ключів у проєктах

Коротко: API-ключі, паролі й сертифікати не мають бути в репозиторії Git; зберігайте їх у змінних середовища або менеджерах секретів і регулярно ротуйте.

Докладніше: Секрет (secret) — будь-яка інформація, що дає доступ: пароль бази даних, API-ключ, токен, закритий ключ. Майже щодня ключі збираються з публічних репозиторіїв (боти сканують GitHub за секунди) і використовуються для зловживань (рахунки за хмару, виведення даних).

Подробиці

Що не працює

  • Секрети у вихідному коді або у файлах конфігурації в репозиторії.
  • В образах Docker чи фронтенд-коді (бачить кожен користувач).
  • У чаті, електронній пошті, тікетах, скриншотах.
  • Одні й ті самі ключі для розробки та production, для всіх сервісів.
  • Безстроково чинні, надто потужні ключі.

Як зробити краще

  1. Змінні середовища (файл .env локально, у .gitignore), секрети CI (GitHub Actions secrets), налаштування хостингу (Vercel, Netlify).
  2. Менеджери секретів: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager, 1Password/Bitwarden Secrets, Doppler, SOPS (зашифровані файли в репозиторії).
  3. Найменші привілеї: ключі з мінімальними правами, окремі для середовищ і сервісів.
  4. Ротація: регулярне оновлення, короткоживучі токени, негайне відкликання у разі підозри.
  5. Журналюйте та відстежуйте доступ.
  6. Два рівні доступу (не один ключ на все).

Захист від витоків

  • Хуки pre-commit і сканери: gitleaks, trufflehog, secret scanning GitHub та захист push.
  • У разі випадкового коміту: негайно відкликати/оновити ключ (видалення з історії недостатньо, дані вже скопійовано); подальше очищення історії (git filter-repo) — лише як додатковий захід.
  • Перевіряйте журнали, щоб у них не виводилися секрети; не робіть повідомлення про помилки надто докладними.
  • Надавайте файли-приклади (.env.example) без реальних значень.

Практика для невеликих проєктів

Використовуйте .env локально та налаштування платформи хостингу для production. Створюйте окремі ключі на кожен сервіс, записуйте їх у менеджер паролів (не у файли), задавайте сповіщення про бюджет у хмарних сервісах і за можливості обмеження за IP чи прив’язку до домену для API-ключів. Публічний ключ браузера (наприклад, для карт) має бути обмежений вашим доменом.

Див. також: Файли env, Найменші привілеї, Менеджер паролів

Зворотні посилання