AWS IAM: практики проти ескалації привілеїв

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

На практиці політика, прикріплена до нього, часто виглядає як "Action": "*", "Resource": "*", тому що wildcard був “достатньо близьким” до того, що потрібно пайплайну, і ніхто не повернувся, щоб звузити його. Цей обліковий запис тепер є адміністратором під нудною назвою, і той, хто його видав, може про це навіть не знати.

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

Безпека AWS IAM — це практика надання хмарним ідентичностям (користувачам, ролям, сервісам) лише тих дозволів, які реально потрібні для їхньої роботи, і перевірки того, що ця межа тримається навіть після компрометації ролі, ключа чи акаунта. Вона охоплює обсяг політик, життєвий цикл ключів, витік облікових даних через сервіс метаданих, дозволи функцій та довіру, що дозволяє одному акаунту приймати роль в іншому.

CIS AWS Foundations Benchmark виділяє керування ідентичностями та доступом в окремий домен контролю саме тому. Більшість хмарних інцидентів це не новий експлойт проти самого AWS. Це дозвіл, виданий коректно, яким скористався той, кому він ніколи не призначався.

Згруповано за тим, де саме ламається довіра, тому кожен пункт має свого власника й свій фікс.

Політика, що надає всі дії на всіх ресурсах, за визначенням непіддається аудиту. Гірше те, що iam:PassRole дозволяє викликачу передати привілейовану роль сервісу, який виконає її замість нього, тож викликач ескалує права, ніколи не приймаючи цю роль сам. Вправа Over-Permissive IAM дає прочитати політику облікового запису build-агента, передати роль адміністратора аварійного доступу у функцію, яку ви створюєте, а потім переписати політику до названих дій на названих ресурсах із межею дозволів під нею.

Статичний ключ доступу не має терміну дії, тож розрив між витоком і зловживанням обмежений лише тим, коли хтось це помітить. Ключі витікають у логи збірок, клієнтський код і старі коміти, і продовжують автентифікувати місяцями пізніше, бо зі статичним ключем із часом нічого не змінюється. Вправа Long-Lived Access Keys дає повторно використати ключ, узятий із весняного лога збірки, проти осіннього продакшн-акаунта, а потім замінити його федерацією, що видає короткоживучі облікові дані на кожен запуск замість свіжішого статичного ключа.

Будь-який процес на хмарному інстансі може запитати в сервісу метаданих облікові дані цього інстансу, і за замовчуванням сервіс не перевіряє, хто саме запитує. Вада, що дозволяє серверу робити запит за посиланням користувача, яка інакше була б незначною, перетворюється на спосіб украсти весь набір облікових даних ролі. Вправа Instance Metadata Abuse веде функцію завантаження за URL прямо до такої крадіжки, а потім закриває її вимогою токена сесії та лімітом переходів в одиницю.

Функція це не скрипт. Це ідентичність, і все, що дозволяє її роль виконання, може зробити будь-хто, хто здатен її викликати.

Обробник зображень із доступом до сховища на рівні всього акаунта це набагато ширший радіус ураження, ніж бакет мініатюр, до якого він насправді звертається. Вправа Serverless Over-Privilege дає дістатися неавтентифікованого URL функції, витягнути обліковий запис бази даних зі змінних середовища, а потім звузити роль до одного бакета, який потрібен функції, і перенести секрет у кероване сховище.

Акаунт це найсильніша межа радіуса ураження, яку дає хмара, але вона тримається лише тоді, коли довіра, спрямована в нього, звужена. Обліковий запис пісочниці без жодних цінних даних стає небезпечним у ту мить, коли може прийняти продакшн-роль, бо за пісочницями стежать значно рідше, ніж за продакшном. Вправа Multi-Account Boundaries дає пройти саме цим шляхом, а потім поставити над акаунтом сервісну контрольну політику, щоб межа тримала навіть проти продакшн-адміністратора, який намагається її розширити назад.

У порядку того, скільки ризику ескалації знімає кожен пункт, а не того, як він виглядає в чеклісті комплаєнсу.

1. Пишіть політики через перелічені дії й ресурси, ніколи не wildcard з обох боків. Список, який можна прочитати повністю, це список, який можна перевірити. Wildcard це обіцянка, яку неможливо перевірити.
2. Додайте межу дозволів поверх кожної переліченої політики. Вона ловить wildcard, до якого хтось сягне під тиском дедлайну, а саме тоді початкова помилка зазвичай і повторюється.
3. Замініть статичні ключі федерованими короткоживучими обліковими даними, де це можливо для навантаження. Ключ, що сам спливає, неможливо відтворити через місяці після витоку.
4. Вимагайте IMDSv2 і встановіть ліміт переходів в одиницю. Обмін токеном сесії зупиняє один підроблений запит від досягнення сервісу метаданих узагалі.
5. Звужуйте кожну роль виконання serverless до конкретного ресурсу, з яким працює функція. Доступ до всього сховища чи бази даних майже ніколи не потрібен самій функції.
6. Виносьте секрети зі змінних середовища в кероване сховище секретів, яке функція читає під час виконання. Це фіксує кожен доступ у журналі аудиту й робить ротацію можливою без повторного деплою.
7. Називайте конкретну роль у кожній політиці довіри між акаунтами й вимагайте зовнішній ідентифікатор. Політика довіри, що називає весь акаунт, віддає продакшн будь-чому, що цей акаунт коли-небудь запустить.
8. Поставте сервісну контрольну політику над акаунтом для всього, що скомпрометований адміністратор ніколи не повинен мати змогу скасувати. Фікси всередині акаунта можна скасувати зсередини акаунта. SCP, що діє над акаунтом, скасувати не можна.

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

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

Саме так побудовані наші вправи Cloud Infrastructure Security — девʼять, які ми випустили поряд з наявним курсом про контейнери в тій самій категорії Cloud Security. Кожна ставить вас на бік атакуючого першим, а потім дає задеплоїти фікс і довести, що той самий шлях більше не працює.

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

Чи буває прийнятною політика IAM із wildcard?

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

Чому ротація витеклого ключа доступу має значення, якщо його вже відкликано?

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

Чи повністю закриває вимога IMDSv2 зловживання сервісом метаданих?

Вона закриває варіант з одним запитом, а це більшість того, до чого дотягуються вади підробки запитів на сервері. Ліміт переходів в одиницю це друга половина, бо він не дає відповіді на ланцюжок запитів вийти за межі інстансу. Жодна із цих змін не потребує чіпати код застосунку, у якому була початкова вада.

Чим роль виконання serverless відрізняється від звичайної ролі IAM?

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

Чому довіра між акаунтами потребує сервісної контрольної політики поверх звуженої політики довіри?

Тому що звужена політика довіри це правило всередині акаунта, а правило всередині акаунта можна змінити зсередини акаунта, включно з адміністратором, який сам був скомпрометований. Сервісна контрольна політика діє над акаунтом, тож та сама зміна відхиляється незалежно від того, хто всередині акаунта її намагається зробити.

Витягніть політику, прикріплену до облікового запису вашого CI чи build-агента, і прочитайте кожну дію та ресурс у ній. Якщо хоч одна сторона це wildcard, ви знайшли ту саму помилку, з якої починається ця стаття, і вона, ймовірно, прикріплена не лише до одного облікового запису.

Наші вправи Cloud Infrastructure Security безкоштовні для тестування, а щоб розгорнути їх на всю інженерну команду, звʼяжіться з нами.