Чеклист деплойменту на AWS, частина 1: секрети та облікові дані
На початку тижня Vercel підтвердив, що зловмисники дістались до їхніх внутрішніх систем. Хтось, хто називає себе ShinyHunters, виставив на продаж вихідний код, API-ключі, NPM-токени та GitHub-токени. Порада Vercel клієнтам: перегляньте змінні середовища.
Порада правильна. Тільки для компаній, які тримали там credentials до продакшн-бази, ключі Stripe та OAuth-секрети — запізніла. Ці дані потенційно вже в чужих руках.
Але злом Vercel увиразнив патерн, який ми бачимо майже в кожному AWS-середовищі, яке аудитуємо: секрети порозкидані по платформах, credentials з надлишковими правами, ніякого плану ротації, ніякого чіткого розуміння, що полетить, якщо будь-яка ланка в ланцюгу ламається.
Це перша частина нашого чеклиста деплойменту на AWS. Починаємо з секретів, бо саме вони найчастіше визначають різницю між «ми чули про злом» і «це нас зламали».
1. Припини тримати продакшн-секрети у змінних середовища платформи
Змінні середовища в платформі для деплойменту — Vercel, Netlify, GitHub Actions, що завгодно — зручні. Вони ж — одна точка компрометації. Коли платформу зламають, кожен секрет у кожній змінній потенційно розкритий.
Для всього, що має значення, використовуй AWS Secrets Manager або Systems Manager Parameter Store. Credentials до бази, API-ключі, ключі шифрування, сервісні токени — це має жити в менеджері секретів із логуванням доступу, а не в текстовому полі панелі платформи.
Накладні витрати мінімальні. Додаток читає з Secrets Manager при старті замість process.env. Різниця в безпеці — колосальна.
2. Розділи credentials по середовищах — по-справжньому
Більшість команд мають окремі змінні для dev, staging і продакшну. Чимало з цих команд використовують ті самі credentials до бази на staging і продакшні, той самий ключ Stripe, той самий GitHub-токен із тими самими правами.
Якщо preview-деплоймент має credential, що дістає до продакшн-даних — preview-середовище є поверхнею атаки на продакшн. Злом, неправильно налаштований бранч, supply chain атака на залежність preview-білда — будь-що з цього стає продакшн-інцидентом.
Різні credentials на кожне середовище. Різні користувачі бази. Різні API-ключі. Без винятків.
3. MFA на root. IAM users для щоденної роботи. Жодних спільних акаунтів.
Це мало б бути очевидним, але ми досі це бачимо: команди працюють під root, діляться одним IAM-юзером на кількох людей, IAM-юзери без MFA.
Root: MFA увімкнено, credentials заховані, використовується виключно для білінгу та операцій рівня акаунта. Щоденна робота: індивідуальні IAM-юзери, кожен із MFA, кожен із правами, обмеженими до того, що реально потрібно. Спільний юзер «deploy», пароль від якого знають троє — видали.
Якщо дію в CloudTrail не можна прив'язати до конкретної людини — контроль доступу зламаний.
4. Обмеж кожен credential до мінімуму
GitHub-токен, підключений до CI/CD — має права на запис у кожне репо в організації? IAM-юзер, що обслуговує деплойменти — має AdministratorAccess? Connection string до бази — під юзером root?
Відповідь на всі три зазвичай «так». А має бути «ні».
Кожен credential повинен мати мінімальні права для свого конкретного завдання. Деплоймент-пайплайну потрібні права оновлювати конкретні сервіси, а не admin на весь AWS-акаунт. З'єднанню з базою для веб-додатку потрібен read/write на своїх таблицях, а не GRANT ALL.
Виправлення цього — одне робоче після обіду. Зменшення радіуса ураження при компрометації credentialа — драматичне.
5. Увімкни CloudTrail і реально в нього дивись
CloudTrail логує кожен API-виклик на твоєму AWS-акаунті. Це різниця між «нас зламали і ми не знаємо, що сталося» та «нас зламали і ми точно знаємо, які credentials використали, до чого дістались і коли».
Увімкни. Логи в S3. Trail, що покриває всі регіони, а не лише той, який використовуєш. CloudTrail Insights, якщо хочеш детекцію аномалій без побудови її з нуля.
І — тут більшість команд відвалюється — реально переглядай. Налаштуй CloudWatch-алерти на підозрілі патерни: використання root-акаунта, логіни з консолі з неочікуваних локацій, API-виклики з невідомих IP-діапазонів. Ці алерти безкоштовні в налаштуванні й безцінні, коли спрацьовують.
6. Автоматизуй ротацію credentials
Ручна ротація credentials означає ротацію, яка не відбувається. Пароль до бази, встановлений два роки тому, який сидить у чотирьох конфігах у трьох середовищах — це той credential, який буде скомпрометований.
Secrets Manager підтримує автоматичну ротацію RDS-credentials із коробки. Для інших секретів — збудуй ротаційну Lambda або використай запланований пайплайн. Ціль: жоден credential не живе довше 90 днів, а його ротація не вимагає деплойменту чи рестарту.
Якщо автоматична ротація — поки що забагато, почни з нагадування в календарі та задокументованої процедури. Це не ідеально, але нескінченно краще за «колись до цього дійдемо».
7. Знай свій радіус ураження
Якщо хтось прямо зараз дістане credentials з твоєї платформи для деплойменту — до чого він має доступ? Якщо хтось перехопить секрети з CI/CD-пайплайну — до чого дотягнеться? Якщо ноутбук розробника скомпрометують — які credentials зберігаються локально?
Намалюй діаграму. Для кожного секрету, яким керуєш, дай відповідь: де зберігається, хто має доступ, до чого дає доступ, коли був останній раз зротований.
Якщо відповідь на «що отримає зловмисник?» — «все», у тебе ризик концентрації, яким треба зайнятись до наступного Vercel, наступного SolarWinds, наступного CodeCov.
8. Май план реагування на компрометацію credentials
Не загальний план реагування на інциденти. Конкретна, задокументована відповідь на питання: «Платформу, яку ми використовуємо, зламали, і наші credentials можуть бути розкриті. Що ми робимо в наступну годину?»
План має включати: список кожного credentialа в кожній платформі, спосіб ротації кожного з них, відповідальну особу за кожну ротацію, сервіси, що потребують рестарту, та людей для сповіщення.
Коли цього тижня з'явилась новина про Vercel, підготовлені команди відкрили документ, пройшлися по списку і мали все зротоване за годину. Решта досі розбирається.
Це перша частина нашої серії чеклистів деплойменту на AWS. Далі: контроль витрат і гігієна білінгу — як зробити так, щоб AWS не здивував рахунком утричі більшим за очікуваний.
В Otocolobus ми аудитуємо AWS-середовища саме на такі проблеми — розкидані секрети, надлишкові права, відсутність політик ротації. Хочеш дізнатись, де твої прогалини, до того як їх знайде хтось інший — напиши.