Модуль 8.4: Крос-акаунт IAM та корпоративна ідентичність

Складність: [COMPLEX] | Час на виконання: 2.5 год | Передумови: Мульти-акаунт архітектура (Модуль 8.1), базове розуміння ролей та політик IAM

Чому цей модуль важливий

Січень 2023 року. Фінансова компанія зі списку Fortune 500.

Інженеру потрібно було терміново виправити баг у кластері Kubernetes, що працював у іншому акаунті AWS. Процес був таким: залогінитися в консоль, переключити ролю на продуктовий акаунт і отримати доступ. “Перемикання” відбувалося через IAM-користувача з правами AdministratorAccess, бо у команди ніяк не доходили руки налаштувати правильну систему крос-акаунт доступу.

Ключі цього користувача лежали в спільному файлі .env у приватному репозиторії GitHub. Коли один зі співробітників звільнився, а його особистий акаунт GitHub згодом зламали, зловмисники знайшли ключі, прийняли ролю адміна і мали повний контроль над продуктовою інфраструктурою протягом 11 годин. Вони викрали 2.3 мільйона записів клієнтів. Штрафи та судові витрати склали $18 мільйонів.

Усе в цій катастрофі було проблемою ідентифікації: постійні ключі замість тимчасових токенів, надмірні права замість мінімальних та відсутність контролю в реальному часі. У мульти-акаунт світі ідентифікація — це ваш новий периметр. Цей модуль навчить вас будувати архітектури ідентичності, які масштабуються на сотні акаунтів і кластерів, залишаючись при цьому безпечними.

Межі довіри: Фундамент крос-акаунтності

Межа довіри (Trust Boundary) — це лінія між “я тобі вірю” та “доведи, хто ти”.

Organization Trust: Усі акаунти вашої компанії (AWS Org / Google Org) довіряють один одному на базовому рівні.
Account Trust: Акаунт А дозволяє конкретним користувачам з Акаунта Б приймати певні ролі.
Workload Trust: Под у Kubernetes має право отримати ключі від хмарної ролі (IRSA / Workload Identity).

IAM Identity Center (AWS SSO)

Більше ніяких IAM-користувачів для людей. IAM Identity Center — це єдиний портал для входу.

Користувач логіниться один раз (напр. через Okta).
Бачить список усіх акаунтів компанії.
Обирає ролю (напр. “ReadOnly” або “Admin”) і потрапляє в потрібний акаунт.
Тимчасові ключі: CLI видає токен, який вмирає через кілька годин.

Workload Identity Federation (GCP / Azure)

Це спосіб дати подику Kubernetes доступ до хмари взагалі без секретів.

Под отримує жетон (token) від Kubernetes.
Хмара (STS) перевіряє цей жетон і видає тимчасовий хмарний ключ.
Cross-project: Под у проєкті “Frontend” може отримати права на читання бази в проєкті “Data”, якщо ви налаштували такий зв’язок.

ABAC: Контроль на основі атрибутів

Традиційний RBAC каже: “Аліса — адмін”. Це важко масштабувати. ABAC (Attribute-Based Access Control) каже: “Аліса може керувати кластером, ТІЛЬКИ ЯКЩО її тег Team співпадає з тегом Team на цьому кластері”. Одна така політика працює для 1000 команд одночасно — вам не треба створювати нові ролі для кожного нового відділу.

JIT (Just-In-Time) Access: Доступ тільки тоді, коли треба

Ніхто не повинен мати прав адміна постійно. Навіть технічний директор. Сценарій JIT:

Інженер створює запит: “Мені потрібен доступ до продакшну на 2 години, ось номер тікета в Jira”.
Менеджер або система (на основі чергування в PagerDuty) схвалює запит.
Система видає права рівно на 2 години.
Через 2 години права зникають автоматично.

Типові помилки

Помилка	Чому це стається	Як виправити
Постійні Access Keys	Спроба уникнути “складної” авторизації	Забороніть створення Access Keys для людей на рівні компанії (SCP)
Права `*` на крос-акаунт ролях	”Потім обмежимо”	Надавайте доступ тільки до конкретних ARN ресурсів з першого дня
Спільні Service Account Keys	Файли JSON передаються в Slack	Використовуйте тільки Workload Identity Federation
Однакові паролі в різних хмарах	Спроба спростити життя	Використовуйте єдиний Identity Provider (Okta/Azure AD) для всіх хмар

Тест

1. Чому тимчасові креденшали (STS) набагато безпечніші за постійні ключі доступу?

Тимчасові креденшали автоматично згорають (зазвичай через 1-12 годин). Навіть якщо хакер вкраде такий ключ — він матиме дуже мале вікно для атаки. Постійний ключ працює роками, поки ви його не видалите вручну.

2. Що таке "Confused Deputy" (заплутаний заступник) в контексті IAM?

Це атака, коли сервіс із високими правами (депутат) виконує дію за запитом зловмисника, не перевіряючи, чи має той право на цю дію. Захист: завжди використовуйте ExternalId або SourceAccount умови в політиках довіри.

Практична вправа: Крос-акаунт доступ

Налаштуйте довіру між двома акаунтами (можна симулювати ролями в одному).
Створіть ролю “Auditor” в акаунті А, яку може приймати користувач з акаунта Б.
Використайте CLI, щоб прийняти цю ролю (aws sts assume-role) та отримати тимчасові ключі.
Перевірте, що тепер ви можете бачити ресурси акаунта А, працюючи під користувачем акаунта Б.
Впровадьте умову MFA: зробіть так, щоб ролю неможливо було прийняти без другого фактора захисту.

Наступний модуль

Ви налаштували безпечний доступ, тепер час підготуватися до гіршого. Переходьте до Модуля 8.5: Аварійне відновлення (DR): RTO/RPO для Kubernetes — ми навчитеся виживати при падінні цілих регіонів та відновлювати дані з попелу.