У більшості компаній процедура звільнення вважається завершеною, щойно запис зникає з HR-системи — хоча насправді акаунт у хмарі, токен на GitHub чи роль у продакшн-підписці продовжують існувати. Людина вже не працює в компанії, а її API-ключі, доступи й оплачені ліцензії живуть своїм життям. В українському ІТ ця проблема відчувається особливо гостро: мобілізація, релокація і постійна плинність команд перетворюють офбординг на аварійну ситуацію, а не на планову процедуру.

Що показує кожен аудит доступів

Команда Gart Solutions понад 15 років займається побудовою та аудитом хмарної інфраструктури і за цей час пройшла через понад 50 клієнтських середовищ. Практично кожна перевірка розпочинається однаково: фахівці вивантажують список користувачів із хмари, GitHub та Google Workspace і зіставляють його з актуальними даними від HR-відділу.

Результат зазвичай однаковий:

  • діють облікові записи людей, які звільнилися багато місяців тому, інколи навіть з правами адміністратора
  • IAM-користувачі зі статичними ключами доступу, якими ніхто не користувався роками, хоча права на продакшн у них залишаються
  • спільний акаунт на кшталт admin@ чи devops@, пароль від якого знають п'ятеро людей, троє з яких давно працюють в іншому місці
  • оплачені ліцензії в SaaS-сервісах, куди востаннє заходили ще до звільнення конкретного працівника

Жодна з цих знахідок не свідчить про недбалість чи зловмисність — просто кожен доступ колись видавали з конкретною метою. Проблема в тому, що в момент звільнення ніхто конкретно не відповідає за долю цих доступів: HR закриває свою частину процесу, ІТ-відділ свою, а хмара, GitHub і решта SaaS-сервісів залишаються поза увагою.

Чому звичний офбординг в Україні не працює

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

Перший сценарій — мобілізація. Людина може отримати повістку й зникнути з робочих каналів буквально за добу, не встигнувши передати жодних справ. Юридично вона при цьому не звільняється: згідно з частиною 3 статті 119 КЗпП, за мобілізованим працівником зберігається місце роботи та посада. Для HR-системи такий співробітник лишається активним, тому автоматичний офбординг, прив'язаний до факту звільнення, просто не спрацьовує — а видаляти акаунт теж не можна, адже людина має право повернутися.

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

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

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

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

Заблокований акаунт — не те саме, що закритий доступ

Найпоширеніша хибна думка звучить так: «ми заблокували людину в Google Workspace чи Entra ID, отже всі доступи закрито». Насправді корпоративний акаунт — лише одні з багатьох дверей. За кілька років роботи типовий інженер накопичує значно більше точок входу:

  • статичні ключі в хмарі: IAM-користувач в AWS з access key, service principal із секретом в Azure, JSON-ключ сервісного акаунта в GCP — усі вони не залежать від SSO і діють, доки їх явно не видалять
  • токени та SSH-ключі на GitHub, прив'язані до особистого акаунта, а не до корпоративного; документація GitHub прямо попереджає, що без SCIM автоматичного депровізіонингу при SAML SSO немає, а видані токени продовжують давати доступ до організації навіть після закінчення сесії
  • локальні копії коду: форки приватних репозиторіїв видаляються разом з обліковим записом, але локальні клони лишаються на пристрої людини, тому будь-які секрети, що колись потрапили в репозиторій, варто вважати скомпрометованими
  • SaaS із власним логіном — сервіси моніторингу, CI, домен-реєстратори чи рекламні кабінети, куди людина реєструвалась корпоративною поштою в обхід SSO
  • спільні адмінакаунти на кшталт root, admin@ чи доступу до панелі хостингу або реєстратора доменів, де заблокувати конкретну людину неможливо — можна лише змінити пароль і MFA, про що часто забувають

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

Сервісні акаунти, про які всі забувають

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

За рік-два такий акаунт зазвичай виглядає так:

  • має права read/write до продакшн-бази або повний доступ Contributor на всю підписку
  • його секрет зберігається в змінних CI, у файлі .env на чиємусь ноутбуці, а можливо, і в історії Git
  • людина, яка його створила, уже не працює в компанії
  • ніхто не береться його видаляти, бо невідомо, чи він ще комусь потрібен

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

У 2026 році до цього переліку додалися ще й AI-агенти та інтеграції з LLM-інструментами — їм так само видають токени доступу до GitHub, хмари та SaaS, і про них так само забувають. Кількість нелюдських ідентичностей у компаніях зростає швидше, ніж кількість людей.

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

Ліцензії, за які платять навіть після звільнення

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

  • у Google Workspace призупинений (suspended) користувач втрачає можливість заходити в систему, але оплата за ліцензію триває; видаляти акаунт одразу теж не варто, бо без попередньої передачі файлів компанія втратить документи з Drive — правильний шлях передбачає передачу даних і перехід на ліцензію Archived User або видалення вже після передачі
  • на GitHub після видалення зовнішнього співробітника з приватного репозиторію кількість оплачених місць автоматично не зменшується — план потрібно знижувати вручну
  • в інших SaaS-сервісах із входом через Google чи Microsoft блокування в IdP закриває доступ лише через SSO, а оплачене місце в Slack, Jira, Figma чи Notion лишається активним, доки його хтось не прибере вручну

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

У компанії на 200–500 людей із нормальним рівнем плинності персоналу таких «фантомних» місць накопичуються десятки. Кожне окремо коштує небагато, але разом вони утворюють помітну статтю витрат, яку ніхто не бачить, бо вона розкидана по різних рахунках.

Справжня причина — відсутність власника у доступу

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

HR знає, хто працює в компанії. Хмара знає, які існують ресурси та ролі. GitHub знає, хто має доступ до репозиторіїв. Бухгалтерія знає, за що саме платить. Але жодна з цих систем не може відповісти на питання, що саме тримала конкретна людина і хто тепер за це відповідає.

Звідси й типова схема офбордингу «за списком»: ІТ-відділ проходить чекліст із 15 пунктів, складений ще два роки тому. Нові SaaS-сервіси, хмарні акаунти та сервісні ключі до нього просто не потрапили. Такий чекліст створює відчуття контролю, але не сам контроль.

Принцип living ownership

У Gart Solutions прийшли до простого принципу, який назвали living ownership: у кожного цифрового активу — акаунта, ролі, ключа, ліцензії, хмарного ресурсу чи сервісного акаунта — має бути конкретний власник, людина або команда, яка за нього відповідає. А коли власник звільняється, усі пов'язані з ним активи мають підсвітитися того ж дня, а не тихо залишитися нічиїми.

  1. Інвентар доступів формується автоматично з первинних джерел — хмари, IdP, GitHub, SaaS, — а не з таблиці, яку хтось оновлює раз на квартал.
  2. Власник — це поле в моделі даних, а не просто тег. У ресурсу може бути бізнес-власник, що відповідає за потребу й бюджет, і технічний, що відповідає за конфігурацію. У сервісного акаунта завжди є конкретна людина-власник.
  3. Зміна статусу співробітника стає тригером: звільнення, мобілізація чи переведення автоматично формують список активів, які треба передати, призупинити або видалити, із конкретним відповідальним за кожен пункт.

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

Як на цій основі виникла Eigna

Після десятків аудитів команда помітила, що щоразу виконує одну й ту саму ручну роботу: вивантажує списки з хмари, IdP, GitHub і SaaS, зводить їх у таблицю, звіряє з HR і запитує в команд, чий це доступ. Через півроку таблиця знову застаріває. Тому підхід вирішили перетворити на окремий продукт.

Eigna — платформа, яка присвоює конкретного власника кожному хмарному ресурсу, SaaS-акаунту, доступу й AI-агенту. Працює це так:

  • підключення без ризику: read-only конектор через OAuth чи API-ключ до AWS, Azure, Google Cloud, Google Workspace, Entra, GitHub і GitLab, інші системи завантажуються через CSV, а сама Eigna нічого не змінює у підключених хмарах і сервісах
  • єдиний інвентар: акаунти, ролі, ключі, ліцензії та хмарні ресурси зібрані в одному місці, людські й нелюдські доступи — поруч
  • власник на кожному активі: Eigna пропонує кандидата на основі тегів, груп і структури компанії з певним рівнем упевненості, а людина підтверджує або відхиляє цей вибір; бізнес-власник відповідає за потребу й гроші, технічний — за конфігурацію
  • living ownership: коли людина йде з компанії, усі пов'язані з нею активи підсвічуються того ж дня
  • гроші й терміни: оплачені місця та витрати відображаються поряд із реальним використанням, а також дати продовження підписок і завершення дії ключів

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

Що можна зробити вже зараз наявними інструментами

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

Серед доступних варіантів: регулярний перегляд членства в групах, доступу до застосунків і адмінролей силами менеджерів, власників ресурсів або самих користувачів; у Microsoft для цього потрібна ліцензія Entra ID Governance або Entra Suite, причому огляд неактивних користувачів доступний тільки з ID Governance і працює лише в екосистемі Microsoft. У Google Workspace передбачені призупинення акаунта, передача Drive і Calendar новому власнику, ліцензія Archived User та видалення — але призупинений користувач і далі оплачується, а видалення без попередньої передачі даних знищує файли.

У хмарних провайдерах є інструменти, що безперервно знаходять невикористані ролі, access keys і паролі IAM-користувачів, а також зайві права в активних ролях, хоча аналіз невикористаного доступу часто платний і працює лише в межах AWS, не знаючи, хто з людей уже звільнився. На GitHub розділи People, Outside collaborators та Audit log дають змогу видаляти членів і зовнішніх співпрацівників та перевіряти, хто і що робив в організації, — проте особисті токени й SSH-ключі прив'язані до особистого акаунта, а ліцензії автоматично не звільняються.

Деякі платформи пропонують автоматичне видалення з організації одразу після відключення людини в IdP, хоча SAML SSO доступний лише на GitHub Enterprise Cloud, а без SCIM автоматичного депровізіонингу все одно немає. Є й рішення на кшталт одного вимикача в IdP — Entra, Google чи Okta — замість ручних кроків у кожному сервісі окремо, але вони зазвичай доступні лише на дорожчих тарифах SaaS і не звільняють ліцензії всюди автоматично.

Практична порада: почніть із двох речей. Перше — увімкніть аналіз невикористаного доступу в хмарі (Access Analyzer в AWS, аналоги в Azure та GCP) і подивіться, скільки ключів не використовувались понад 90 днів.

Роман Бурдюжа, Gart Solutions

Другий крок — вивантажити список усіх акаунтів із GitHub та Google Workspace і звірити його зі списком від HR. Обидві дії займають один день і практично завжди дають результат у вигляді знахідок. Якщо ж потрібно, щоб таке порівняння виконувалося постійно, а кожен актив мав чіткого власника, саме для цього і створена Eigna.

Пошук дизайн-партнерів серед членів IT Ukraine

Команда шукає перших дизайн-партнерів серед компаній — членів IT Ukraine. Найкраще підійдуть команди чисельністю від 100 до 2000 людей, які працюють із кількома хмарами та SaaS-сервісами одночасно й стикаються з описаними в статті проблемами.

  • безкоштовний доступ до Eigna та підключення ваших систем разом із командою розробників
  • перший звіт про акаунти без власника, доступи колишніх працівників і невикористані ліцензії у вашому середовищі
  • прямий вплив на подальший розвиток продукту — які конектори, сценарії та звіти будуть реалізовані далі

Автор матеріалу — Роман Бурдюжа, співзасновник Gart Solutions (DevOps, Cloud & Digital Transformation) і співзасновник Eigna — платформи, що закріплює власника за кожним хмарним ресурсом, SaaS-акаунтом і доступом.

Джерело: IT Ukraine Association