Чому один акаунт AWS ламає управління
Один акаунт AWS зручний рівно до моменту, коли в ньому з'являється друга команда і друге середовище.
Далі починається класичний клубок: продакшн і тестовий контур живуть на одних і тих самих ролях, розробники й підрядники ділять спільний набір прав, а ліміти сервісів і квоти на регіон витрачаються всіма одразу.
Інцидент у тестовому середовищі валить прод не тому, що хтось помилився, а тому що межі між ними фізично немає.
Права в такій схемі розмиваються передбачувано. Поки всі ролі лежать в одному акаунті, будь-яке розширення доступу заради однієї задачі розширює поверхню атаки для всіх інших.
Політики пишуться «на виріст», рев'ю перетворюється на формальність, а зрозуміти, хто і коли отримав зайвий дозвіл, уже неможливо — у журналах усе змішано в одну стрічку.
Білінг при цьому ведеться вручну. Рахунок приходить однією сумою, і розкласти його за командами, продуктами й середовищами можна тільки таблицею, яку хтось веде паралельно.
Щойно хтось забув оновити розмітку тегів, розподіл витрат перестає сходитися, і рішення про те, що оптимізувати, ухвалюються наосліп.
Ізоляція інциденту теж не працює. Коли все в одному акаунті, компрометація одного ключа доступу або помилка в політиці відкриває весь контур цілком — немає технічної межі, за яку можна відкотитися. Відкликати доступ точково не вийде: доведеться зупиняти те, що до цього доступу прив'язане.
Саме тому мультиакаунтна архітектура на AWS Organizations перестала бути «хорошою практикою для великих» і стала базовою гігієною.
Окремі акаунти під середовища, команди й призначення дають жорсткі межі: ізоляція середовищ на рівні акаунта, розділення прав через сервісні політики й ролі, централізований білінг із розміткою за підрозділами. Розбираємо, як це збирається і що дає на практиці.
Що дає мультиакаунтна архітектура AWS
Швидкість видачі акаунта
Новий акаунт в AWS Organizations створюється через централізований шаблон: базова мережа, ролі доступу, політики та прив'язка до білінгу розгортаються автоматично.
Замість днів листування та ручного налаштування команда отримує готове середовище за хвилини — і одразу з потрібними обмеженнями.
Радіус ураження інциденту
Кожне середовище — продуктив, стейджинг, пісочниця розробки — живе в окремому акаунті. Помилка конфігурації, ключ, що витік, або невдалий експеримент залишаються всередині одного акаунта і не зачіпають сусідні. Інцидент локалізується на рівні ізольованого середовища, а не всієї інфраструктури.
Прозорість витрат
Централізований білінг збирає рахунки всіх акаунтів в один звіт із розбивкою за командами, проєктами та середовищами. Видно, який підрозділ скільки споживає, — і рішення про бюджет ухвалюються за фактами, а не за здогадками.
Єдині політики
Service Control Policies задають правила на рівні організації: які сервіси та регіони доступні, що заборонено. Політика застосовується до всіх акаунтів одразу, тому новий проєкт не може випадково обійти вимоги безпеки чи комплаєнсу.
Керованість
Єдина точка входу через SSO, централізований аудит дій і спільний каталог акаунтів. Адміністратор бачить усю картину й керує доступом з одного місця, а не збирає дані за розрізненими обліковими записами.
SCP, SSO та централізований білінг: порівняння підходів
Єдиний акаунт зручний рівно до моменту, коли в ньому з'являються друга команда і другий продукт: права в усіх максимальні, бюджети змішані, а інцидент в одному сервісі валить сусідній.
Далі вибір іде не між «складно і просто», а між чотирма робочими схемами управління — і в кожної є своя ціна у вигляді обмежень.
AWS Organizations тут — не самоціль, а рамка: він задає дерево підрозділів, на яке навішуються політики та ролі. Нижче — порівняння за тим, що реально впливає на експлуатацію: ізоляція відмов, керованість доступів і передбачуваність рахунків.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Єдиний акаунт | Один продукт, одна команда, рання стадія | Немає ізоляції відмов і квот; права роздаються вручну; рахунок не розділити за командами |
| Organizations + SCP | Кілька команд або середовищ, потрібні жорсткі заборони | SCP обмежують, але не видають права; помилка в політиці блокує одразу весь підрозділ; потрібен процес рев'ю змін |
| SSO-федерація | Багато людей і ролей, часті підключення та звільнення | Потребує зовнішнього постачальника посвідчень; ролі все одно описуються в кожному акаунті; без SCP доступи не звузяться |
| Гібрид: Organizations + SSO + зовнішній каталог | Регуляторні вимоги, сотні співробітників, аудит | Найвища вартість впровадження; потрібен власник каталогу та синхронізації; складніше налагоджувати ланцюжок входів |
Практика показує: SCP і SSO вирішують різні завдання і не замінюють одне одного. Політика забороняє небажані дії — наприклад, виведення даних за межі підрозділу або запуск ресурсів поза дозволеними регіонами.
Федерація відповідає за те, хто і на яку роль входить, і прибирає ручні ключі доступу. Централізований білінг поверх Organizations дає розподіл витрат за підрозділами та тегами — без нього рахунок залишається загальною сумою, яку ніхто не може розкласти за командами.
Гібрид із зовнішнім каталогом беруть там, де вхід і звільнення мають відображатися в доступах автоматично. Ціна — синхронізація каталогу та ролей стає окремим сервісом, за яким потрібно стежити.
Як ми впроваджуємо AWS Organizations: етапи робіт
Впровадження AWS Organizations — це не «увімкнути консолідацію рахунків», а перебудувати управління доступом і політиками поверх уже працюючих акаунтів.
Тому починаємо з інвентаризації: які акаунти існують, хто в них ходить, які сервіси та дані живуть, де перетинаються мережі та ролі. Без цієї карти будь-яке перенесення OU або ввімкнення SCP ламає прод.
Далі йдемо ітераціями: спочатку проєктуємо цільову структуру, потім переносимо по одному акаунту, перевіряючи, що нічого не відвалилося. Нижче — типовий порядок робіт, який ми адаптуємо під ваш ландшафт.
- Аудит ландшафту. Збираємо список акаунтів, власників, критичних сервісів, поточних IAM-ролей і мережевих зв'язків. Фіксуємо, що не можна чіпати без вікна обслуговування.
- Проєктування OU. Розкладаємо акаунти за організаційними юнітами: прод, стейджинг, пісочниця, безпека, інфраструктура. Окремо — ізольовані OU для регуляторних або платіжних даних.
- Налаштування SCP. Пишемо політики на рівні OU, а не окремих акаунтів: заборона виходу з організації, обмеження регіонів, блокування вимкнення логування. Спочатку в режимі аудиту, потім — у enforcement.
- Підключення SSO. Налаштовуємо єдиний вхід і мапінг груп на ролі в акаунтах, щоб доступ видавався через каталог, а не через локальні IAM-користувачі. Це знімає ручне управління доступами.
- Міграція акаунтів. Переносимо по одному: прив'язка до OU, застосування SCP, перевірка робочих процесів команди. Відкат можливий на кожному кроці, поки акаунт не закріплений у цільовій структурі.
- Перевірка. Проганяємо сценарії: доступ розробника, деплой, реакція на заборонену дію, робота білінгу та тегів. Дивимося, що політики не блокують легітимні операції.
- Передача. Віддаємо карту OU, набір SCP, схему ролей і регламент додавання нових акаунтів — щоб команда розширювала структуру без нас.
Опишіть поточний ландшафт — повернемося з оцінкою та планом за етапами.
Політики доступу та IAM-ролі в мультиакаунтному середовищі
У мультиакаунтному середовищі доступ описується не разовими налаштуваннями, а набором артефактів, які живуть у репозиторії та проходять рев'ю як код.
Нижче — що замовник отримує на руки після впровадження: кожен пункт можна передати внутрішній команді або підряднику на супровід без усних пояснень.
- SCP-конфігурації — політики на рівні Organizations: заборона виходу з організації, блокування недозволених регіонів, захист від вимкнення аудиту та видалення журналів, обмеження на створення публічних ресурсів. Кожне правило прив'язане до конкретної OU, а не до всього дерева.
- Схеми OU — ієрархія підрозділів із призначенням: sandbox, робочі середовища, продакшн, ізольований контур, інфраструктурний акаунт. Схема фіксує, куди потрапляє новий акаунт і які політики успадковує за замовчуванням.
- Політики доступу — ролі та політики для людей і сервісів: розподіл прав за принципом мінімально необхідних, окремі ролі для читання, розгортання та адміністрування, умови на джерело запиту та обов'язкову багатофакторну автентифікацію.
- IAM-ролі та федерація — вхід через єдиного провайдера ідентифікації, тимчасові облікові дані замість довгоживучих ключів, ролі для автоматизації з обмеженим терміном дії та прив'язкою до конкретного акаунта.
- Регламенти — порядок запиту доступу, терміни перегляду прав, процедура виведення акаунта з організації, правила реагування на спрацювання заборони.
- Документація — карта акаунтів і OU, схема ролей, матриця «хто що може», інструкції для чергової зміни та для аудиту.
Окремо передаємо схему відкату: як зняти політику, якщо вона блокує робочий процес, і в якому порядку це робити, щоб не втратити доступ до керуючого акаунта. Опишіть вашу поточну структуру акаунтів — повернемося з оцінкою та планом впровадження.
Кейс: як скоротили радіус інциденту та час видачі акаунта
Замовник прийшов із класичним болем: акаунти під команди та середовища видавалися вручну, у кожного — свій root-доступ і свої ключі, а білінг розтікався по десятку рахунків.
Інцидент із ключем, що витік, в одному сервісі зачіпав спільні ресурси, і зрозуміти межу ураження можна було лише перебором. Розбирали на базі AWS Organizations — централізоване управління деревом акаунтів, політики та єдиний вхід.
Що було до
Видача нового акаунта під команду займала в середньому 3 робочих дні: заявка, ручне створення, розсилка доступів, окреме налаштування білінгу. Частка ручних операцій у провіжинінгу трималася близько 80% — кожна помилка в правах спливала вже в проді.
Радіус інциденту при компрометації ключа охоплював 6-8 акаунтів через спільні ролі та наскрізні доступи, а на локалізацію йшло до 4 годин.
Що змінили
- Акаунти рознесли по організаційних одиницях (prod, staging, sandbox, shared) з успадкуванням SCP — заборона на вимкнення логування, обмеження регіонів, блокування root-операцій.
- Доступ перевели на федерацію через єдиний вхід: людина отримує роль у конкретному акаунті на час, постійних ключів немає.
- Білінг звели в керуючий акаунт із розміткою по командах — витрати видно по підрозділу, а не по рахунку загалом.
- Видачу акаунта загорнули в шаблон: організаційна одиниця, SCP, базові ролі та бюджет-алерт піднімаються однією операцією.
Що стало
Видача акаунта скоротилася з 3 днів до 15-20 хвилин, частка ручних операцій упала приблизно до 10% — залишилися тільки погодження.
Радіус інциденту звузився до одного акаунта: компрометація ключа більше не дає доступу до сусідніх середовищ, а час локалізації впав з 4 годин до 20-30 хвилин завдяки ізоляції та централізованому аудиту.
Окремий ефект — передбачуваність витрат: розмітка по командах показала, які середовища тягнуть бюджет марно, і частину sandbox-ресурсів згорнули без втрат для розробки.
Чим SCP відрізняється від IAM-політик і коли що застосовувати
SCP та IAM-політики працюють на різних рівнях і відповідають на різні питання. SCP — це політика Organizations, яка задає верхню межу допустимого для цілого акаунта: вона не видає права, а відсікає все, що виходить за її рамки.
IAM-політика діє всередині акаунта і визначає, що конкретний користувач, роль або сервіс може робити з ресурсами. Простіше кажучи: SCP відповідає на питання «що в цьому акаунті заборонено в принципі», IAM — «що дозволено цьому суб'єкту».
Ключова властивість SCP — вона працює як фільтр, а не як джерело дозволів. Навіть якщо IAM-політика дозволяє дію, але SCP його не допускає, дія не пройде. Зворотне невірно: SCP не дає прав сама по собі — без дозвільної IAM-політики доступ все одно закритий.
Тому SCP застосовують для жорстких організаційних меж: заборона виходу за дозволені регіони, блокування відключення журналювання та захисту, заборона створення публічних сховищ, обмеження використовуваних сервісів. Це рамка, яку не можна обійти правами всередині акаунта.
IAM-політики вирішують інше завдання — тонке налаштування доступу. Тут описують, хто і до яких ресурсів звертається, за яких умов, з якими тегами і через які ролі.
Саме на цьому рівні живе повсякденна робота: доступ розробників до потрібних сервісів, права сервісних ролей, обмеження за джерелом запиту. Змінюється команда або процес — змінюється IAM-політика, і це не зачіпає решту акаунтів організації.
Практичне правило застосування просте. Межі, які повинні діяти для всіх акаунтів і не залежать від поточних завдань, виносьте в SCP — вони успадковуються і централізовано керуються. Все, що стосується конкретних людей, ролей і ресурсів усередині одного акаунта, залишайте в IAM.
Змішування рівнів призводить до двох крайнощів: або SCP намагаються використовувати як роздачу прав і отримують неробочий доступ, або в IAM дублюють організаційні заборони, які потім розходяться між акаунтами.
Окремо варто враховувати порядок впровадження. SCP застосовується до акаунта цілком, включаючи кореневого користувача і службові ролі, тому невірно складене правило здатне заблокувати управління.
Безпечніше вводити обмеження поетапно: спочатку на тестовому підрозділі, потім розкочувати на решту, перевіряючи, що штатні сценарії не зачеплені. IAM-політики такої небезпеки не несуть — їхня область обмежена акаунтом, і помилка не виходить за його межі.
Часті технічні сумніви при переході на AWS Organizations
Перехід в AWS Organizations майже ніколи не буває «зеленим полем»: акаунти вже живуть своїм життям, прод обслуговує клієнтів, а користувачі заходять через зовнішній каталог.
Нижче — розбір сумнівів, які найчастіше виникають на етапі планування, і того, як кожен закривається технічно.
Що буде з уже наявними акаунтами — їх доведеться перестворювати?
Ні. Наявні акаунти запрошуються до організації та переносяться до потрібного OU — ресурси, ідентифікатори, ролі та дані залишаються на місці.
Змінюється лише те, що поверх акаунта починає діяти політика організації: SCP обмежують допустимі дії, а централізоване управління доступом підключається до вже працюючих ролей.
Єдине, що варто перевірити заздалегідь, — чи не блокує нова SCP щось із поточних сценаріїв, тому політики спочатку застосовуються в режимі аудиту, а не одразу в блокуючому.
Як не зламати прод при включенні політик?
SCP застосовуються поетапно: спочатку на тестовому OU, де проганяються реальні сценарії деплою та відкату, потім на непроді, і тільки потім на проді.
Політики пишуться так, щоб забороняти конкретні небезпечні дії, а не «все, крім дозволеного» — інакше один пропущений сервіс валить робочий процес.
На кожному кроці залишається точка відкату: політику можна зняти з OU, і акаунти повертаються до попередньої поведінки без перестворення ресурсів.
Користувачі заходять через зовнішній каталог — SSO це зламає?
Ні. Зовнішній каталог підключається як джерело ідентифікації, а централізований доступ роздає ролі в акаунтах на основі наявних груп. Користувачі продовжують входити звичним способом, змінюється лише те, куди їх пускають і з якими правами.
Мапінг груп на ролі налаштовується явно, тому доступи стають прозорішими: видно, хто і в який акаунт потрапляє, а звільнення закриває всі доступи одразу.
Чи можна відкотитися, якщо щось піде не так?
Так. Перенесення оборотне на кожному етапі: акаунт можна вивести з організації, SCP — зняти, а доступ повернути до попередньої схеми. Ми фіксуємо стан до змін і тримаємо план відкату, тому перехід іде без простою проду та без втрати даних.
Обговоримо ваше завдання щодо мультиакаунтної архітектури
Щоб оцінка була точною, а не «плюс-мінус порядок», нам потрібно зрозуміти поточний ландшафт: скільки акаунтів уже живе під AWS Organizations, чи є Control Tower, як влаштовані SSO та ролі, де зараз лежать дані та які вимоги щодо ізоляції середовищ.
Опишіть завдання у вільній формі — далі ми поставимо уточнювальні запитання й повернемося з оцінкою та планом робіт.
Що корисно додати до опису:
- перелік акаунтів та їхнє призначення (прод, стейдж, пісочниці, спільні сервіси, безпека);
- поточна структура підрозділів і як вона має мапитися на організаційні одиниці;
- як сьогодні видаються доступи: через який провайдер ідентифікації, які ролі та групи використовуються;
- які політики вже застосовуються і що заважає — де ручні винятки, де правила обходяться;
- вимоги до ізоляції: що і кому має бути видно, які дані не можна змішувати між акаунтами;
- як зараз збирається білінг і за якими ознаками витрати розкладаються по командах і проєктах;
- обмеження: строки, регламенти, уже ухвалені архітектурні рішення, які не можна ламати.
У відповідь ви отримаєте оцінку трудозатрат із розбивкою за етапами, план впровадження з порядком робіт і точками відкату, схему цільової структури акаунтів і політик, а також перелік ризиків і залежностей, які потрібно закрити до старту. Якщо частина даних поки недоступна — не страшно, почнемо з того, що є, і уточнимо по ходу розбору.
Опишіть завдання — повернемося з оцінкою та планом.
