У хмарі застосунок отримує права не через ключі в .env, а через роль, прикріплену до сервера чи контейнера (IAM-роль інстансу, workload identity). Облікові дані видає сервіс метаданих за внутрішньою адресою 169.254.169.254.
Чому це зручно: немає статичних ключів, тимчасові облікові дані оновлюються автоматично.
Чому це небезпечно без захисту: будь-яка вразливість, що дозволяє змусити сервер зробити HTTP-запит (SSRF - «завантажити зображення за URL», генерація PDF з HTML, вебхук на адресу користувача), дає зловмиснику доступ до метаданих:
http://169.254.169.254/latest/meta-data/iam/security-credentials/app-role
і облікових даних ролі. Кілька відомих масштабних витоків даних почалися саме так.
Захист сервісу метаданих:
- IMDSv2 обов'язковий (AWS): спершу
PUT-запит за сесійним токеном, потім запити з заголовком токена. Типова SSRF дозволяє лишеGETбез власних заголовків - і токен отримати не може. Для нових інстансів IMDSv2 варто вимагати явно (HttpTokens=required); - hop limit = 1 - відповідь сервісу метаданих не проходить через додатковий мережевий «стрибок»: контейнер без host-мережі не дістане метадані хоста;
- у Kubernetes - IRSA/workload identity замість ролі вузла: кожен под отримує власну роль.
Принцип найменших прав для ролі:
- лише потрібні дії й ресурси:
s3:PutObjectіs3:GetObjectнаarn:aws:s3:::shop-uploads/*, а неs3:*на*; - окремі ролі для веб-застосунку, воркерів черг, задач бекапу - компрометація одного не відкриває решту;
- жодних прав на IAM (створення користувачів і ролей) у застосунку;
- умови: обмеження за VPC, тегами, мережею;
- регулярний аудит невикористаних прав (IAM Access Analyzer та аналоги).
Захист від SSRF у коді лишається обов'язковим: перевірка URL і IP після розв'язання DNS, заборона приватних діапазонів і 169.254.0.0/16, вимкнені редиректи.
Виявлення: журнали хмарного провайдера (CloudTrail) з підозрілими діями від імені ролі застосунку (наприклад, виклики з невідомих IP) - сигнал до негайного реагування.
Докладніше в документації: AWS: налаштування сервісу метаданих (IMDS)
