Секрети в SaaS: зберігання, ротація та план дій при витоку

Більшість невеликих SaaS-продуктів зберігають секрети одним і тим самим способом: API-ключі, пароль від бази й токени лежать у змінних оточення платформи, на якій працює застосунок. Це просто й зручно, і в більшості випадків цього достатньо. Але лише доти, доки зламають не вас, а саму платформу.

У жовтні 2026 року я зіткнувся з цим на практиці. Один з моїх проєктів на Spring Boot працює на Railway, і після інциденту з витоком змінних оточення на Railway OpenRouter превентивно відключив мій ключ. Застосунок почав отримувати 401, а викотити новий ключ я не міг: платформа зупинила всі деплої. У цьому гайді — що я виніс з цієї ситуації і як організувати зберігання секретів так, щоб наступний інцидент коштував вам мінімум нервів і грошей.

📚 Зміст статті

• 📌 Чому секрети на PaaS — спільна точка відмови
• 📌 Які секрети є у типового SaaS і чим ризикує кожен
• 📌 Env-змінні платформи vs секрет-менеджер: де зберігати секрети
• 💼 Принцип мінімальної шкоди: як обмежити наслідки витоку
• 💼 Ротація секретів: як міняти ключі без простою
• 💼 План дій при компрометації: чек-лист на перші 24 години
• 💼 Що робити, коли платформа заморожує деплої
• ✅ Як перевірити безпеку секретів у вашого SaaS-постачальника
• ❓ Часті питання (FAQ)

🎯 Чому секрети на PaaS — спільна точка відмови

Коли ви деплоїте застосунок на PaaS (Railway, Render, Heroku, Fly.io тощо), ви довіряєте платформі не лише код. Ви віддаєте їй усі ключі: від бази даних, платіжної системи, хмарного сховища, AI-провайдерів. Платформа шифрує їх і підставляє в контейнер під час запуску.

Проблема в тому, що для атакувальника таке сховище — дуже вигідна ціль. Зламати один SaaS-продукт — це один набір ключів. Зламати платформу — це ключі тисяч продуктів одночасно. Саме тому атаки на платформи для розробників і CI/CD-сервіси повторюються з року в рік.

Висновок не в тому, що PaaS — це погано. Висновок у тому, що витік секретів через платформу — не гіпотетичний, а реальний сценарій, і архітектура вашого продукту має його враховувати.

Схожі інциденти

• Railway, жовтень 2026. Стороння особа могла отримати доступ до змінних оточення клієнтів і розшифрувати частину з них. Платформа зупинила деплої, AI-провайдери превентивно відкликали ключі. Детальніше в нашій новині
• CircleCI, січень 2023. Після компрометації компанія закликала всіх клієнтів ротувати всі секрети, що зберігалися в CircleCI. Офіційне повідомлення.
• Heroku і Travis CI, квітень 2022. Викрадені OAuth-токени GitHub, видані цим інтеграціям, використали для доступу до приватних репозиторіїв клієнтів. Повідомлення GitHub.
• Codecov, 2021. Атакувальники змінили скрипт завантаження звітів у CI, і він відправляв змінні оточення клієнтів на сторонній сервер. Офіційне оновлення Codecov.

Спільне в усіх випадках одне: клієнти не робили нічого неправильно. Секрети витікали з інфраструктури, якій вони довіряли.

🎯 Розділ 2. Які секрети є у типового SaaS і чим ризикує кожен

Не всі секрети однаково цінні. Щоб правильно розставити пріоритети захисту й ротації, корисно спершу скласти інвентар і оцінити, що ви втрачаєте при витоку кожного.

Зверніть увагу на JWT-секрет: його часто недооцінюють, бо це «просто рядок у конфігу». Але з ним атакувальник може згенерувати валідний токен для будь-якого користувача, включно з адміністратором, і жоден пароль його не зупинить.

🎯 Розділ 3. Env-змінні платформи vs секрет-менеджер: де зберігати секрети

Є два основні підходи: тримати секрети у змінних оточення платформи або винести їх в окремий секрет-менеджер, з якого застосунок їх читає.

Важливий нюанс: секрет-менеджер не робить секрети невразливими. Застосунку все одно потрібен «перший ключ», щоб дістатися до менеджера, і він теж десь зберігається. Але ви отримуєте три важливі речі: секрети не лежать разом з кодом на одній платформі, є аудит, хто й коли їх читав, і секрет можна змінити без перезбирання застосунку.

Моя рекомендація: для MVP змінних оточення достатньо, якщо ви виконуєте правила з наступного розділу. Коли з'являються платні клієнти й дані, які шкода втратити, варто перейти на Doppler чи Infisical: це день роботи, а не тиждень.

🎯 Розділ 4. Принцип мінімальної шкоди: як обмежити наслідки витоку

Повністю виключити витік неможливо. Зате можна зробити так, щоб вкрадений ключ коштував якомога менше. Ось правила, які дають найбільший ефект за найменших зусиль.

Окремий ключ на кожен сервіс і задачу

Не використовуйте один ключ OpenRouter для чат-бота, перекладу й генерації контенту. Окремі ключі дозволяють відкликати лише скомпрометований і одразу бачити, який сервіс поводиться дивно.

Ліміти витрат на рівні ключа

Більшість AI-провайдерів дозволяють обмежити бюджет конкретного ключа. Вкрадений ключ з лімітом $5 — неприємність. Ключ без ліміту — потенційно весь баланс акаунта.

Мінімальні права

Користувач БД для застосунку не повинен мати прав на DROP чи на інші бази. Ключ для хмарного сховища — лише на потрібний бакет. Токен для CI — лише на потрібний репозиторій.

Розділення prod і dev

Різні ключі для продакшну, стейджингу й локальної розробки. Ключ з ноутбука розробника не повинен давати доступ до продакшн-бази.

IP allowlist там, де це можливо

Якщо сервіс дозволяє обмежити доступ за IP-адресами (бази даних, деякі API), використовуйте це. Тоді вкрадений пароль без доступу до вашої мережі марний.

Жодних секретів у репозиторії

Додайте сканер секретів (наприклад, вбудований у GitHub secret scanning або gitleaks у pre-commit). Ключ, що потрапив у публічний репозиторій, знаходять за хвилини — і провайдери часто відкликають його автоматично.

🎯 Розділ 5. Ротація секретів: як міняти ключі без простою

Ротація буває двох видів: планова (за розкладом, наприклад раз на квартал) і екстрена (після інциденту). Обидві мають проходити без простою, і це питання архітектури, а не дисципліни.

Схема з двома ключами

Основний прийом ротації без простою — короткий період, коли валідні обидва ключі:

1. Створіть новий ключ у провайдера, старий поки не відкликайте.
2. Оновіть значення в сховищі секретів.
3. Задеплойте або перезапустіть застосунок, щоб він почав використовувати новий ключ.
4. Переконайтеся, що запити з новим ключем проходять, а старий більше не використовується (у більшості провайдерів видно час останнього використання ключа).
5. Відкличте старий ключ.

Секрети, які «ламають» користувачів

Деякі секрети не можна просто замінити. Якщо змінити JWT-секрет, усі видані токени стануть невалідними, і всіх користувачів розлогінить. Для планової ротації застосовують підтримку кількох ключів одночасно: нові токени підписуються новим ключем, а старі ще певний час перевіряються обома. При екстреній ротації після витоку розлогінити всіх — свідоме й правильне рішення.

Документуйте процедуру

Для кожного секрету запишіть: де він створюється, де зберігається, які сервіси його використовують і як його замінити. У момент інциденту ця сторінка заощадить години.

🎯 Розділ 6. План дій при компрометації: чек-лист на перші 24 години

Коли ви дізнаєтеся про можливий витік (від платформи, провайдера чи з власного моніторингу), діяти треба за планом, а не імпровізувати.

Перші години

1. Підтвердьте інформацію з першоджерела. Заходьте в дашборди напряму, а не за посиланнями з листів: на хвилі інцидентів завжди з'являється фішинг.
2. Ротуйте критичні секрети: база даних, платіжні системи, AI-провайдери.
3. Ротуйте секрети високого пріоритету: сховища, JWT і сесійні ключі.
4. Решта: пошта, OAuth, ключі сторонніх інтеграцій, облікові дані registry.

Перевірка логів

• AI-провайдери: незнайомі моделі, нетипові обсяги, запити в неробочий час.
• База даних: підключення з невідомих IP, масові вибірки, зміни схеми.
• Платіжні системи: повернення коштів, зміни налаштувань виплат.
• Сховища: несподівані завантаження, видалення, зміна прав доступу.
• Акаунти: нові учасники команди, нові API-ключі, які ви не створювали.

Комунікація з клієнтами

Якщо є ознаки доступу до даних клієнтів, повідомте їх швидко й чесно: що сталося, що вже зроблено, що мають зробити вони. Залежно від юрисдикції й типу даних (наприклад, GDPR), повідомлення може бути юридичним обов'язком із чіткими строками. Мовчання чи розмиті формулювання шкодять репутації більше, ніж сам інцидент.

Після інциденту

Коротко задокументуйте: що сталося, скільки часу зайняла реакція, що пішло не так. Найцінніший результат — список того, що треба змінити в архітектурі, щоб наступного разу реагувати швидше.

🎯 Розділ 7. Що робити, коли платформа заморожує деплої

Цей сценарій рідко описують у гайдах, але я пережив його сам. Під час інциденту з Railway ситуація виглядала так:

• OpenRouter превентивно відключив ключ, і застосунок почав отримувати 401 Unauthorized;
• я створив новий ключ, локально все запрацювало одразу;
• я оновив змінну в Railway, але вона не застосувалася: змінні читаються лише при старті контейнера;
• перезапустити контейнер чи задеплоїти не вдалося: платформа показувала «Limited Access — Deploys have been paused temporarily».

Сайт працював, але частина функцій, залежна від AI, лежала, і зробити з цим нічого було не можна. Платформа зупинила деплої з правильних міркувань: поки вразливість не закрита, кожен деплой — це ризик витоку нових ключів. Але для вашого продукту результат однаковий: ви заблоковані.

Ось варіанти, як підготуватися до такої ситуації заздалегідь.

Варіант 1. Зовнішній секрет-менеджер з оновленням у рантаймі

Якщо застосунок читає секрети із зовнішнього менеджера й уміє перечитувати їх без перезапуску, нові ключі можна підхопити без деплою. У Spring Boot це, наприклад, Spring Cloud Vault разом з оновленням конфігурації через @RefreshScope:

spring:
  config:
    import: vault://
  cloud:
    vault:
      uri: https://vault.example.com
      authentication: APPROLE

Застереження: «перший ключ» для доступу до менеджера все одно лежить на платформі. Якщо він теж скомпрометований, доведеться міняти і його. Але це один секрет замість двадцяти, і його можна обмежити за IP та правами.

Варіант 2. Резервна платформа для деплою

Тримайте робочий конфіг для другої платформи (Render, Fly.io чи VPS) і DNS через Cloudflare, щоб перемкнути трафік за хвилини. Це страховка на випадок будь-якої тривалої недоступності основної платформи, не лише інцидентів безпеки. Мінус: якщо база даних живе на тій самій платформі, переносити доведеться й доступ до неї.

Варіант 3. Graceful degradation

Найдешевший варіант: застосунок має коректно поводитися, коли зовнішній API відмовляє. Показувати зрозуміле повідомлення замість помилки 500, ставити задачі в чергу на повтор і не зберігати «порожні» результати. Наприклад, якщо перекладач при помилці повертає оригінальний текст, перевірте, що цей текст не зберігається як переклад: інакше після інциденту доведеться чистити дублікати.

Що обрати: варіант 3 варто зробити в будь-якому продукті, це базова гігієна. Варіант 1 — коли продукт вже приносить гроші й простій AI-функцій коштує дорожче, ніж день налаштування. Варіант 2 — для продуктів, де година недоступності означає втрату клієнтів.

🎯 Розділ 8. Як перевірити безпеку секретів у вашого SaaS-постачальника

Усе вище стосується вашого власного продукту. Але якщо ви B2B-клієнт і передаєте свої ключі чи дані SaaS-сервісу (CI/CD, хостинг, інтеграційну платформу, AI-сервіс), ваша безпека залежить від постачальника. Ось питання, які варто поставити до підписання договору.

Зберігання й доступ

• Як зберігаються ключі та облікові дані клієнтів? Чи шифруються вони і хто керує ключами шифрування?
• Хто зі співробітників має доступ до розшифрованих секретів клієнтів і чи логується цей доступ?
• Чи ізольовані дані різних клієнтів один від одного?

Сертифікації й аудит

• Чи є у постачальника SOC 2 Type II або ISO 27001? Чи можна отримати звіт?
• Чи проводяться регулярні пентести незалежними компаніями?

Інциденти

• Як і в які строки постачальник повідомляє клієнтів про інциденти? Чи є це в договорі?
• Чи були інциденти в минулому і як компанія на них реагувала? Відкриті постмортеми — хороший знак.
• Чи є у постачальника домовленості з upstream-провайдерами про відкликання ключів, як це зробив Railway з AI-провайдерами?

Ваші можливості контролю

• Чи можна використовувати власний секрет-менеджер замість зберігання секретів у постачальника?
• Чи є аудит-лог дій у вашому акаунті й чи можна його експортувати?
• Чи підтримуються SSO, обов'язкова 2FA і ролі з мінімальними правами?

Постачальник, який упевнено й конкретно відповідає на ці питання, найімовірніше, справді займається безпекою. Розмиті відповіді на кшталт «ми використовуємо банківське шифрування» — привід копнути глибше.

❓ Часті питання (FAQ)

Чи безпечно зберігати секрети у змінних оточення?

Для більшості невеликих проєктів — так, якщо секрети не потрапляють у репозиторій і у вас є план ротації. Ризик змінних оточення не в самому механізмі, а в тому, що всі секрети зосереджені на одній платформі разом з кодом.

Як часто треба ротувати секрети?

Жорсткого стандарту немає. Розумний орієнтир для невеликого SaaS — планова ротація критичних секретів раз на 3–6 місяців і обов'язкова екстрена ротація після будь-якого інциденту, звільнення співробітника з доступом чи підозрілої активності.

Чи потрібен секрет-менеджер невеликому SaaS?

На старті не обов'язково. Він стає виправданим, коли з'являються платні клієнти, кілька середовищ і кілька людей з доступом до секретів. Hosted-рішення на кшталт Doppler чи Infisical налаштовуються за день.

Що робити, якщо ключ потрапив у публічний репозиторій?

Негайно відкличте ключ у провайдера й створіть новий. Видалення коміту не допомагає: ключ уже могли скопіювати, а історія Git і форки зберігають його. Потім перевірте логи провайдера на чужі запити.

Чи захищає шифрування секретів на платформі від витоку?

Частково. Шифрування захищає від витоку «сирої» бази, але застосунку секрети потрібні в розшифрованому вигляді, тож платформа вміє їх розшифровувати. Якщо атакувальник отримує доступ до цього механізму, шифрування не допомагає — саме це, за даними Railway, сталося в жовтні 2026 року.