Налаштування AWS IAM (Identity and Access Management)

IAM AWS: чому доступи перетворюються на вузьке місце

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

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

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

Так IAM AWS з інструменту контролю перетворюється на джерело невизначеності: формально доступи є в усіх, у кого мають бути, але фактично — в усіх, хто колись просив.

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

Аудит упирається в записи, де під одним ідентифікатором діють п'ять людей і три автоматизовані процеси. Ротація при цьому не проводиться роками, бо незрозуміло, які системи зламаються після зміни ключа.

Третій шар проблеми — невідстежувані зміни прав. Політики правляться напряму в консолі, минаючи рев'ю, і через місяць ніхто не відновить, хто і навіщо розширив доступ до сховища з даними.

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

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

Що дає вибудувана модель доступу

Видача доступів за хвилини замість днів

Поки права оформлюються листуванням і ручними правками в консолі, новий інженер чекає на доступ до середовища, а команда — на реліз.

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

Помилки прав перестають валити прод

Клас відмов, коли сервіс отримує зайві права й пише туди, куди не повинен, або навпаки втрачає доступ до бакета під час ротації ключів, зникає разом із принципом найменших привілеїв.

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

Поверхня атаки звужується, аудит прискорюється

Довгоживучі ключі та надлишкові дозволи — головне джерело ризику в хмарі. Перехід на тимчасові облікові дані та ролі з обмеженим терміном життя скорочує кількість точок входу, які можна скомпрометувати.

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

Управління ризиками стає вимірюваним

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

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

Підходи до організації доступу: порівняння

Коли в акаунті десятки сервісів і команд, питання «як надати доступ» швидко перетворюється на питання «як його потім відкликати».

Нижче — чотири робочі моделі, між якими реально обирають під час налаштування IAM в AWS, з їхніми сильними сторонами та тим, де вони починають заважати.

Як обирати між ними

Статичні ключі варто залишати лише там, де федерація технічно неможлива, і одразу заводити їм термін життя та власника.

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

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

Етапи впровадження управління доступами

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

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

1. Аудит доступів. Зводимо облікові записи, групи, ролі та політики в один реєстр, зіставляємо з журналами звернень. Позначаємо невикористовувані права, надлишкові дозволи та сервісні ключі без власника.
2. Проєктування ролей. Розкладаємо обов'язки за ролями: окремо читання, окремо зміна, окремо адміністрування. Визначаємо, де потрібен тимчасовий доступ, а де постійний, і хто виступає власником кожної ролі.
3. Налаштування політик. Пишемо політики з явною забороною за замовчуванням і точковим дозволом на конкретні дії та ресурси. Умови обмежують доступ за джерелом запиту, мітками ресурсів і вимогою багатофакторної автентифікації.
4. Тестування доступу. Проганяємо сценарії від імені кожної ролі: що має працювати і що обов'язково має бути відхилено. Перевіряємо граничні випадки — доступ до чужих ресурсів, спроби ескалації прав, роботу з недовіреної мережі.
5. Переведення робочих навантажень. Перемикаємо сервіси та команди на нові ролі невеликими групами, старі права тримаємо в резерві до підтвердження, що нічого не відвалилося.
6. Документування. Фіксуємо модель ролей, призначення кожної політики, власників і порядок видачі тимчасового доступу. Описуємо, як додати нового співробітника і як відкликати права при звільненні.
7. Передача та регламент. Віддаємо команді схему доступу та правила перегляду прав, домовляємося про періодичну ревізію, щоб модель не заростала винятками.

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

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

Політики доступу та ролі: що налаштовуємо

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

Кожен пункт закриває конкретний клас ризиків: надлишкові права, «вічні» ключі, невідстежувані зміни.

• Матриця прав — таблиця відповідності «роль → сервіси → дії → ресурси», узгоджена з власниками систем. З неї виводяться політики, а не навпаки: спочатку фіксуємо, кому що потрібно для роботи, потім пишемо JSON.
• Політики доступу — керовані політики з явним розділенням на дозвільні та заборонні, з умовами за джерелом запиту, тегами ресурсів і вимогою MFA для чутливих операцій. Окремо — межі прав, щоб навіть адміністратор ролі не міг вийти за окреслений контур.
• Ролі для сервісів і людей — окремі ролі для застосунків, складальних процесів та інженерів, з довірчими відносинами лише до потрібних джерел. Постійні ключі доступу замінюємо на тимчасові облікові дані.
• Схема потоків доступу — діаграма: хто автентифікується, через яку точку входу, в який обліковий запис і з якими правами потрапляє. Допомагає побачити зайві зв'язки до того, як ними скористаються.
• Регламент ротації — правила та строки зміни облікових даних і сертифікатів, порядок відкликання при звільненні або компрометації, відповідальні за кожну дію.
• Журналювання та оповіщення — увімкнений запис подій доступу, вивантаження в захищене сховище та сигнали на підозрілі сценарії: вхід з нової геолокації, відмова в доступі, зміна політик.
• Документація та передача — опис моделі доступу, інструкції для інженерів щодо додавання нових ролей і чек-ліст перевірки перед випуском змін.

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

Кейс: скорочення часу видачі доступу в 4 рази

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

Аудит у такій моделі перетворювався на археологію: за логами доводилося відновлювати, хто і коли отримав зайві права.

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

Amazon Web Services IAM тут дав основу: ролі, політики та умови доступу описуються декларативно, а отже, піддаються автоматизації. Ми підключили видачу до корпоративного каталогу — новий співробітник потрапляє в потрібну групу, і права з'являються самі, без ручних операцій. Відкликання при звільненні або зміні ролі спрацьовує так само автоматично.

Що змінилося в цифрах

Час видачі доступу скоротився приблизно в 4 рази, а головне — пішов клас помилок, коли права залишаються в людини після зміни задач. Аудит тепер зводиться до вивантаження звіту про те, у кого які ролі, замість ручного зіставлення логів.

Окремо налаштували регулярну перевірку: система сама підсвічує облікові записи з надлишковими правами та неактивні акаунти.

Чим відрізняються ролі від політик у IAM AWS?

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

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

Політики бувають керовані (багаторазово використовувані, з версіонуванням) і вбудовані (живуть лише всередині однієї сутності).

Усередині політики є блоки Effect, Action, Resource і Condition — останній і дозволяє звузити доступ за умовами: лише з довіреної мережі, лише з обов'язковою багатофакторною автентифікацією, лише до ресурсів із певним тегом. Саме Condition найчастіше перетворює формально робочу політику на реально безпечну.

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

Звідси типове застосування: сервіс на сервері звертається до сховища або бази не через «прошиті» ключі, а через роль — витекти з коду нічому, бо в коді ключів немає.

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

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

Часто їх застосовують разом: одна керована політика прив'язується до кількох ролей із різними умовами довіри, і права змінюються в одному місці, а не в десяти.

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

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

Часті технічні сумніви

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

У нас кілька акаунтів. Ролі доведеться налаштовувати в кожному окремо?

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

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

Як забезпечити аудит і довести, хто і коли отримав доступ?

Кожна дія під роллю потрапляє в журнал із зазначенням, хто саме запросив сесію, на який термін і з якими правами. Тимчасові elevated-права видаються на години, а не назавжди, і автоматично відкликаються — у журналі видно і видачу, і закінчення.

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

Що буде, якщо роль налаштована з помилкою і доступ виявиться ширшим за потрібний?

Тому права видаються за принципом мінімально необхідних і перевіряються на тестовому контурі до продакшену. Політики версіонуються, зміни проходять рев'ю, а відкат до попередньої версії займає хвилини.

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

Опишіть вашу поточну схему доступу та кількість акаунтів — повернемося з оцінкою та планом міграції.

Обговоримо ваше завдання щодо доступів

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

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

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

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

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