Налаштування Yandex IAM: де ламається доступ і чому
Права в хмарі майже ніколи не видають за розрахунком. Зазвичай роль додають «про всяк випадок», щоб завдання не зупинилося: спочатку собі, потім колезі, потім підряднику на час робіт.
Через пару місяців другий і третій контур доступу вже ніхто не пам’ятає, а в списку ролей висить набір, який неможливо пояснити.
Далі нашаровуються сервісні акаунти й ключі. Їх створюють під термінове вивантаження або інтеграцію, ключ кладуть у змінні збірки, репозиторій і листування, ротації немає.
У підсумку живі й мертві ключі виглядають однаково, і незрозуміло, які з них ще щось роблять у хмарі, а які давно час відкликати.
Пік болю — звільнення співробітника. Відкликання доступу перетворюється на тижневий розіграш: частина ресурсів прив’язана до особистого облікового запису, частина — до ролі, виданої на проєкт, частина — до ключа сервісного акаунта, який ніхто не рахував.
Поки триває розбір, колишній співробітник зберігає доступ до сховищ, а нові завдання стоять, бо незрозуміло, що можна відключити без наслідків.
Цього не видно, поки не станеться перевірка або інцидент. І тоді з’ясовується, що не можна відповісти на просте запитання: у кого був доступ до конкретного сховища, хто видав право і що встигли зробити під цим ключем.
Саме тому налаштування доступу в хмарі починається не з консолі, а з інвентаризації: що існує, хто власник, де надлишкові права користувачів і які ключі живуть довше за своє завдання.
Розбираємо, як це закривається: аудит ролей і політик, розділення сервісних акаунтів за завданнями, обмежений термін життя ключів і процедура відкликання, яка займає хвилини, а не тиждень.
Що дає керований доступ: вимірювані ефекти
Права перестають бути властивістю людини і стають властивістю ролі. Принцип мінімальних привілеїв у Yandex Cloud працює через прив’язку ролей до каталогу, хмари або окремого ресурсу: розробник отримує доступ до свого середовища, а не до всього акаунта.
Розбір повноважень на старті зазвичай показує, що у третини облікових записів прав більше, ніж потрібно для роботи; після переведення на ролі частка надлишкових повноважень падає до одиниць відсотків.
Окремий сервісний обліковий запис на кожен сервіс прибирає спільні ключі доступу з конфігів, складальних завдань і робочих машин.
Витік ключа доступу перестає бути тотальною відмовою: інцидент обмежений одним сервісом, ключ відкликається однією операцією, решта продовжують працювати.
Час відкликання доступу вимірюється хвилинами — і для співробітника, і для сервісу, без пошуку всіх місць, де лежав спільний секрет.
Розділення повноважень будується на тому, що адміністративні ролі видаються окремо від робочих і не «про всяк випадок».
Зникає клас ситуацій, коли той самий доступ дозволяє змінити налаштування, підтвердити зміну і не залишити сліду: роли розкладаються за функціями, а дії потрапляють до журналу з прив’язкою до конкретного власника.
Далі доступи живуть за регламентом, а не за пам’яттю: плановий перегляд за журналом показує ролі, не використані місяцями, і їх знімають; під час звільнення або зміни команди права відкликаються за хвилини, бо не висять на спільному акаунті. На виході — керований контур доступу: видно, у кого що є, чим це видано і як швидко закривається.
Варіанти організації доступу: ролі, групи, акаунти
Права в хмарі видають кількома способами, і кожен по-своєму поводиться під час відкликання. Пряма роль на користувача зручна для разової роботи, але через пів року вже ніхто не пам’ятає, навіщо її видано.
Групи збирають однакові права команди в одному місці, успадкування на каталог роздає їх на все вкладене, а сервісний обліковий запис закриває автоматику без участі людини. Вибір схеми — це передусім вибір того, наскільки дешево ви зможете забрати доступ назад.
| Схема | Коли підходить | Обмеження |
|---|---|---|
| Роль напряму користувачу | разова видача на конкретний ресурс, короткі роботи | не успадковується; під час звільнення людини потрібно пам’ятати всі точки видачі |
| Групи користувачів і ролі | команда з однаковим набором завдань і стабільним складом | для індивідуальних винятків не годиться — доведеться плодити групи |
| Права на рівні ресурсу (каталог, хмара) | єдина політика й успадкування прав на все вкладене | легко видати більше, ніж потрібно одному сервісу; звуження потребує окремого каталогу |
| Обліковий запис для сервісу | збірка, інтеграції, фонова автоматика | довгоживучий ключ витікає тихо — ротація й аудит обов’язкові |
| Тимчасовий доступ | аудит, заміни, роботи підрядника | після закінчення терміну відкликається не завжди сам, потрібен контроль |
На практиці схеми комбінують: постійний склад отримує ролі через групи з успадкуванням від каталогу, разові роботи закриваються тимчасовим доступом, автоматика живе на окремому сервісному обліковому записі з мінімальним набором прав.
Тоді відкликання доступу — це одна операція в групі або закінчення терміну, а не пошук прямих видач по десятках ресурсів. Саме ця різниця визначає, скільки часу займе розбір під час перевірки або звільнення співробітника.
Порядок налаштування доступу: від аудиту до передачі
Доступи в хмарі майже завжди виростають стихійно: сервісні акаунти заводяться під конкретне завдання, ключі живуть роками, ролі видаються «щоб запрацювало».
Змінювати це наосліп небезпечніше, ніж залишити як є, — спочатку фіксуємо поточний стан, потім проєктуємо і тільки потім перемикаємо.
- Інвентаризація облікових записів. Збираємо сервісні акаунти, статичні ключі, прив’язки до віртуальних машин і зовнішніх систем. Окремо позначаємо записи без власника — з них найчастіше починається розбір інцидентів.
- Схема доступу. Показуємо, хто до яких ресурсів звертається: сервіс до сервісу, зовнішні інтеграції, люди. На схемі одразу видно зайві зв’язки й ролі, видані «про всяк випадок».
- Матриця повноважень. Зводимо права до мінімально необхідного набору на рівні каталогу, каталогу ресурсів і окремого ресурсу. У кожному рядку — причина, з якої доступ потрібен.
- Налаштування і переведення сервісів. Видаємо нові ролі, ключі робимо короткоживучими, попередні відкликаємо поетапно. План відкату тримаємо готовим: якщо сервіс втрачає доступ, повернення займає хвилини, а не нічні пошуки причини.
- Перевірка на тестовому контурі. Проганяємо типові сценарії — збірку, викладку, читання секретів, звернення до сховища. Контур показує зайві й відсутні права до того, як вони вдарять по робочому середовищу.
- Передача й навчання. Віддаємо документацію, регламент запиту доступу і порядок ротації ключів. Далі команда замовника веде доступи самостійно.
Пакет передачі: конфігурації, схеми й регламенти
За підсумками налаштування Yandex IAM у команди залишається не «доступ, який працює», а пакет артефактів, за яким ви далі живете без нас.
Кожен документ лежить поруч із конфігурацією доступу, оновлюється тією самою зміною і проходить перевірку перед застосуванням — інакше він застаріває на другому тижні.
- Опис ролей — що відкриває кожна роль, де межі між близькими правами і яку брати за замовчуванням для розробника, чергового і складального контуру.
- Матриця повноважень — таблиця «команда / ресурс / роль / область дії / термін»: одразу видно, у кого є доступ до продакшену і на якій підставі.
- Схеми доступу — як пов’язані сервісні акаунти, федерація облікових записів і зовнішні підрядники, через яку точку входу хто заходить.
- Регламент доступу — порядок видачі, продовження і відкликання: хто погоджує, за який термін, що робити під час звільнення співробітника або виходу підрядника.
- Інструкція для чергового — що дивитися в журналах, яку роль зняти негайно, як видати тимчасовий доступ на розбір і повернути конфігурацію в початковий стан.
- Інвентаризація сервісних акаунтів — список ключів із власниками й термінами ротації; безхазяйні й прострочені відключені, а не забуті.
- Передача в експлуатацію — обхід за контрольним списком разом із вашим інженером: доступи відтворюються з конфігурації, а не живуть у листуванні.
Пакет розрахований на зміну складу команди: новий інженер входить у доступи за інструкцією, а не за чужими повідомленнями в чаті. Після передачі залишаємося на зв’язку для розбору спірних випадків, поки ви не почнете вести контур повністю самі.
Кейс: надлишкові права в хмарному середовищі та їх відкликання
До робіт хмарний контур збирався стихійно: у кожної команди — свої сервісні акаунти, ролі видавалися напряму людям «щоб не блокувати реліз», а статичні ключі доступу лежали в репозиторіях і жили до ручного відкликання.
Ніхто не міг відповісти, у кого зараз права адміністратора і які з них реально використовуються — аудит у хмарному середовищі до нас не проводився жодного разу.
Що показав розбір доступу
Ми вивантажили всі прив’язки ролей у Yandex Cloud, зіставили їх із журналами фактичних звернень за зіставний період і зібрали картину по кожному суб’єкту.
З’ясувалося, що більше половини виданих повноважень не використовувалися жодного разу, а третина сервісних акаунтів мала права рівня адміністратора там, де вистачало доступу лише на читання об’єкта.
Окремою знахідкою стали ключі без власника: співробітник звільнився, акаунт залишився активним, підпис продовжував працювати.
Що змінили в схемі
Прямі прив’язки ролей до людей прибрали — доступ видається тільки через групи, а права описуються політиками на рівні каталогу й ресурсу.
Під кожне завдання завели окремий сервісний акаунт із мінімально достатньою роллю замість спільного «на все», а статичні ключі замінили на короткоживучі з автоматичною ротацією.
У кожного ключа з’явився власник і термін дії, продовження — тільки усвідомленою дією, а не за інерцією.
Метрики до і після
Частка надлишкових прав скоротилася з 48% до 7% від виданих повноважень, кількість активних ключів — майже втричі, причому жоден робочий процес при цьому не зупинився.
Час відкликання доступу під час звільнення або зміни ролі знизився з кількох днів ручного листування до однієї операції з групою — хвилини, із записом у журналі.
Розбір інциденту тепер починається не із запитання «а в кого взагалі є доступ», а з готового списку: права описані декларативно, і поточний стан контуру відтворюється з конфігурації, а не з пам’яті адміністратора.
Чим відрізняються ролі рівня організації та ресурсу?
Роль рівня організації видається на всю організацію: доступ діє на всі хмари, каталоги й ресурси всередині, включно з тими, що з’являться пізніше. Права на конкретний ресурс призначаються точкою — каталог, бакет, кластер, віртуальна машина — і за його межами не працюють.
У Yandex Cloud діє успадкування за ієрархією: організація → хмара → каталог → ресурс. Роль, видана на верхньому рівні, успадковується вниз автоматично, а заборонних правил у моделі немає — права тільки додаються.
Тому звузити доступ, виданий на організацію, заднім числом не можна: залишається відкликати роль цілком і перевидати точково.
Звідси практичне правило. Ролі рівня організації доречні для вузького кола: адміністратори білінгу, служба безпеки, аудит — ті, кому за регламентом потрібен огляд усіх каталогів.
Сервісним акаунтам і робочим групам права видаємо на конкретний каталог або ресурс: тоді область дії прав збігається із зоною відповідальності команди.
Ризик широких повноважень проявляється у двох місцях. Компрометація ключа сервісного акаунта з роллю на організацію відкриває доступ до всієї інфраструктури, а відкликання вимагає обійти всі системи, де лежить копія ключа.
У журналі аудиту дію видно, але за одним акаунтом стоять десятки сценаріїв — розбір інциденту перетворюється на ручний пошук.
На аудиті закриваємо це так: збираємо інвентар ролей і прив’язок, звіряємо область дії прав із фактичними завданнями, зайве знімаємо, ключі перевипускаємо під конкретні каталоги. Доступ залишається керованим при зростанні кількості сервісів.
Часті технічні сумніви щодо доступу й ключів
Команда замовника перед стартом ставить ті самі запитання: чи не зупиниться прод під час зміни ролей, що робити з правами, накопиченими за роки, і як бути з підрядниками, у яких зараз спільний доступ. Нижче — як ми відповідаємо на них на практиці.
Окремо запитують про відкат: якщо видача виявиться невірною, скільки часу займає повернення до попереднього стану і чи залишається слід, хто саме видав доступ.
Зміна прав зупинить сервіси, що працюють?
Ні, якщо міняти в правильному порядку. Спочатку знімаємо карту фактичних звернень за журналом аудиту, потім видаємо нові прив’язки ролей і тільки після контрольного періоду спостереження відкликаємо старі.
Відкликання йде партіями з паузами — недоступність можлива лише там, де сервіс тримає довгоживучий ключ, і такі місця ми знаходимо до змін, а не після.
У нас за роки накопичилися зайві права — їх доведеться відкликати наосліп?
Ні. Збираємо карту «сервісний акаунт — роль — ресурс» і зіставляємо з реальними викликами за період спостереження. Ролі, за якими звернень немає, позначаємо як кандидатів на відкликання, але не чіпаємо, поки замовник не підтвердить, що сервіс не використовується сезонно. Відкликання йде із журналом: видно, що було, що стало і що відкотили.
Зовнішнім підрядникам потрібен доступ — як не віддати зайве?
Підрядник отримує власний сервісний акаунт, обмежений потрібним каталогом і терміном дії, а не ключ від спільного. Після завершення робіт доступ відкликається однією дією, без пошуку слідів у чужих конфігураціях.
Ключі підрядника ротуємо за розкладом із перекриттям: новий видається й перевіряється до відкликання старого, щоб не було вікна недоступності.
Як переконатися, що права виставлені коректно?
Проганяємо тестові запити від імені кожного сервісного акаунта — і позитивні, і негативні: доступ до чужих каталогів має бути заборонений. Конфігурації доступу ведемо як код, тому будь-яка зміна версіонується й відкочується до попереднього стану. Перегляд прав ставимо в регулярний цикл, щоб накопичення не почалося заново.
Обговоримо завдання й повернемося з оцінкою та планом
Щоб аудит ролей і сервісних акаунтів у Yandex IAM дав результат, потрібен доступ до реальної картини прав, а не до її переказу.
Перша розмова займає близько години: розбираємо, які команди й зовнішні підрядники працюють із хмарою, де видаються статичні ключі, як влаштований конвеєр збірки й викладки. Окремо проговорюємо, що вже болить: збої викладки, надлишкові ролі, ключі, які ніхто не відкликав.
Що підготувати до старту:
- перелік хмар, каталогів і проєктів, які потрапляють в аудит;
- список сервісних акаунтів та їхнє призначення: збірка, викладка, моніторинг, доступ до сховища;
- як права видаються зараз — через консоль, маніфести інфраструктури як коду, скрипти чи вручну;
- точки інтеграції: конвеєр викладки, оркестрація, зовнішні підрядники з доступом;
- вимоги до розмежування: які середовища й дані не можна змішувати, де потрібен розподіл обов’язків;
- інженер, який відповідає за доступи й підтверджує рішення під час робіт.
Доступи для аудиту просимо мінімальні — читання політик і метаданих акаунтів. Самі ролі й ключі на етапі розбору не чіпаємо: зміни йдуть окремим етапом, після погодження схеми.
За підсумками повертаємося з планом робіт щодо доступу: етапи, порядок переведення сервісних акаунтів, точки відкату, оцінка термінів і цільова модель ролей. Якщо частина даних закрита — фіксуємо це в плані й пропонуємо, чим її замінити.
Опишіть завдання — повернемося з оцінкою та планом.
