Чому ваші облікові записи «svc-» — це бомба із затримкою

By Mirko Peters · 2026-08-11

Automatically translated with AI from the original post. Read the English original

Titelbild: Why Your 'svc-' Accounts Are a Ticking Time Bomb

Ласкаво просимо назад до подкасту та нашого поглибленого розбору архітектури безпеки підприємства. Якщо ваша організація схожа на більшість, швидкий перегляд Active Directory або каталогу Microsoft Entra ID покаже розрослий цвинтар облікових записів, які починаються з «svc-», «app-» або «admin-bot». Ці облікові записи забезпечують роботу сервісів, потік даних і автоматизацій. Але водночас вони є найбільшою сліпою зоною у вашій сучасній моделі безпеки. У цьому блозі ми розвиваємо наш останній випуск, щоб пояснити, чому традиційні облікові записи служби повністю підривають вашу архітектуру Zero Trust і чому перехід на Microsoft Entra Workload Identities є єдиним правильним шляхом.

Повну аудіоверсію цієї теми можна послухати в нашому супутньому епізоді подкасту Replace Service Accounts with Entra Workload Identities. А тепер розберемо механіку ризиків, пов'язаних із не-людськими обліковими записами, і те, як їх остаточно усунути.

TL;DR

Облікові записи служби зі статичними секретами та широкими правами є вашою найбільшою прогалиною в ідентичності. Workload Identities (у Microsoft Entra ID) дають кожному не-людському суб'єкту керовану ідентичність із мінімальними привілеями, життєвим циклом, політиками CA, ротацією та повними журналами аудиту — без порушення ваших автоматизацій.

Чому облікові записи служби не справляються (і ламають Zero Trust)

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

Статичні секрети та відсутність MFA -> їх легко викрасти, важко безпечно ротувати
Надмірні привілеї за замовчуванням -> дозволи типу «просто щоб працювало» стають постійними
Відсутній життєвий цикл -> забуті чи осиротілі облікові записи переживають міграції та реорганізації
Слабка прозорість аудиту -> відповідь на питання «хто і навіщо використовував цей обліковий запис?» — це здогадки та скриншоти
Культура винятків -> виключення з CA/MFA для ботів непомітно розширюють вашу поверхню атаки

Managed Identities: добрий крок, але прив'язаний до Azure

Коли організації усвідомлюють, що статичні облікові записи служби небезпечні, їхнім першим природним кроком часто стають Managed Identities в Azure. Вони є суттєвим проривом, адже повністю прибирають секрети для ресурсів, розміщених в Azure, але мають чіткі обмеження.

✅ Доступ без секретів для нативних ресурсів Azure (Functions, VM, Logic Apps)
❌ Прогалини для гібридних і сторонніх цілей, слабке зіставлення власників, обмежені представлення для керування
❌ Покриття CA та призначених прав неоднорідне для ресурсів поза Azure

Workload Identities: що ви насправді отримуєте

Саме тут на сцену виходять Microsoft Entra Workload Identities. Замість того щоб ставитися до не-людських суб'єктів як до громадян другого сорту або змушувати вас обмежуватися лише Azure, Workload Identities підносять застосунки, скрипти та автоматизовані сервіси до рівня повноцінних суб'єктів безпеки.

Повноцінні не-людські ідентичності (застосунки, скрипти, конектори, RPA, інтеграції)
Обмежені дозволи (ролі Graph і ресурсів, автентифікація лише для застосунків) з мінімальними привілеями
Життєвий цикл (власник, частота перегляду, процес виведення з експлуатації), прив'язаний до бізнес-процесу
Умовний доступ для навантажень (контроль на основі ризику та контексту, керування сесіями там, де це підтримується)
Гігієна облікових даних (короткоживучі секрети, сертифікати, політика ротації ключів)
Єдина видимість (входи, токени, доступ до ресурсів, історія змін) -> готовність до аудиту

Матриця порівняння (на одному погляді)

Характеристика	Обліковий запис служби	Managed Identity	Workload Identity
Секрети	Статичні паролі	Без секретів (Azure)	Без секретів / короткоживучі + ротація
Область дії	Широка, як у користувача	Орієнтовано на Azure	Будь-яке навантаження (застосунки, скрипти, конектори)
CA / ризик	Рідко застосовується	Обмежено	Керується політиками там, де підтримується
Життєвий цикл	Ad hoc (без системи)	Базовий	Власник + перевірки + виведення з експлуатації
Аудит	Фрагментарний	Журнали Azure	Централізований журнал входів і дозволів

Архітектурні патерни (типові сценарії використання)

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

Конектори Power Platform / хмарні потоки -> Призначте робочу ідентичність для кожної інтеграції; надавайте лише потрібні області Graph/Dataverse.
Застосунки для бізнесу (веб-API, демони) -> реєстрація застосунку + сертифікат; використовуйте ролі застосунку та Graph лише для застосунку; застосовуйте CA, де це можливо.
Скрипти автоматизації (Azure Automation, GitHub Actions, DevOps) -> Використовуйте федеративні облікові дані (OIDC) без збережених секретів.
Міжклієнтські завдання / завдання B2B -> Окрема робоча ідентичність для кожної межі клієнта; ізолюйте права та журналювання.

Плейбук міграції (90 днів, без зайвих потрясінь)

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

Фаза 1 — виявлення та сортування (тижні 0–3)

Складіть інвентаризацію входів і об'єктів без участі людини: svc-*, app-*, спільні поштові скриньки, реєстрації застосунків, секрети, що спливають через <90 днів.
Для кожного визначте власника, бізнес-призначення, цілі, дозволи, залежність від аварійного облікового запису.
Ранжуйте за ризиком: статичні паролі, глобальні ролі, відсутній власник, відсутнє нещодавнє оновлення.

Фаза 2 — спочатку переведіть найризикованіші (тижні 4–8)

Створіть робочу ідентичність для кожної інтеграції (не повторно використовуйте існуючі).
Замініть автентифікацію за паролем на сертифікати або федеративні облікові дані; налаштуйте ротацію.
Перейдіть на дозволи лише для застосунку; видаліть делеговані користувачем там, де вони не потрібні.
Застосуйте політики умовного доступу для входів робочих ідентичностей (де це підтримується).
Запровадьте перегляди доступу (щокварталу) та закріплення власників у CMDB/ITSM.

Фаза 3 — виведення з експлуатації та управління (тижні 9–12)

Вимкніть старі службові облікові записи, проживіть 14 днів у режимі моніторингу, потім видаліть.
Запровадьте стандарти створення: іменування, власник, класифікація даних, частота перегляду.
Додайте сповіщення: аномальні входи, неактивні ідентичності понад 30/60/90 днів, секрети, що спливають.
Вбудуйте перевірки ідентичностей у CI/CD (policy-as-code).

Умовний доступ і дозволи (практичні запобіжники)

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

Окремі політики для людських і робочих ідентичностей; блокуйте інтерактивний вхід для робочих навантажень.
Іменовані місця / мережеві обмеження для доступу лише для застосунку там, де це можливо.
Обмежені в часі права (PIM для ролей застосунку, де доступно; заплановані перегляди доступу).
Області дії: надавайте перевагу ролям застосунку або ролям конкретних ресурсів замість загальнокаталожних прав.

Журналювання та аудит (що показати аудитору)

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

Власник застосунку або робочого навантаження, призначення, чутливість даних
Журнали входів (входи об'єкта служби), аудиторія токена, IP-адреса, клієнтський застосунок
Призначення ролей (хто схвалив, коли перевірено)
Історія облікових даних (тип, остання ротація, термін дії)
Життєвий цикл: створено/змінено/вимкнено/видалено з вказанням особи, що вчинила дію

Панель KPI (доведіть покращення)

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

% нелюдських ідентичностей із власником і частотою перегляду (ціль ≥ 95%)
Осиротілі службові облікові записи (ціль -> 0)
Секрети старші за 90 днів (ціль -> 0; краще сертифікати/федеративні облікові дані)
Широта ролей застосунку (кількість „Directory.ReadWrite.All” -> має тенденцію до зниження)
Зауваження аудиту щодо доступу нелюдських ідентичностей (квартал до кварталу ↓)

Антишаблони, які слід усунути

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

Повторне використання одного загального службового облікового запису для багатьох систем
Вбудовані в скрипти, web.config або Key Vault паролі без жодної політики ротації
Надання ролі Global Admin / Owner «про всяк випадок», щоб завдання не зупинилися
«Тимчасові» винятки з CA, які ніколи не спливають

Швидкі перемоги (цього тижня)

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

Позначте кожну не людську ідентичність тегами Owner, System і Data Class.
Перевfigure одне високоризикове завдання на federated credentials (GitHub OIDC -> Entra).
Замініть спільний сервісний обліковий запис у Power Automate на workload identity.
Створіть звіт про service principals з секретами, що спливають або вже спливли, і налаштуйте сповіщення за розкладом.

Поширені запитання (швидкі відповіді)

Чи порушують workload identities старі локальні завдання?
Ні, їх можна поєднати через автентифікацію лише для застосунків, сертифікати або посередницькі сервіси; паролі відмовляйте поступово.

Чи можна примусово застосувати Conditional Access до входів без участі людини?
Так, для підтримуваних сценаріїв (входи service principal). Де це доречно, використовуйте сигнали мережі, розташування чи пристрою, а інтерактивні входи блокуйте.

Як уникнути розростання?
Одна workload identity на інтеграцію, а не на команду. Одразу під час створення вимагайте назву, власника та перегляди, а очищення неактивних обліків автоматизуйте.

А як щодо Power Platform?
Використовуйте Service Principals / Workload Identities для конекторів і Dataverse, а спільні облікові записи користувачів більше не застосовуйте.

Висновок

Ротацією паролів ризики сервісних облікових записів не закрити. Entra Workload Identities переносять доступ без участі людей у ту саму модель Zero Trust, життєвого циклу та аудиту, яку ви вже вимагаєте для людей, і роблять це без простоїв та героїчних зусиль. Почніть з найризикованіших облікових записів із префіксом «svc-», перетворіть їх на керовані workload identities і знову зробіть винятки винятками.

Якщо вам сподобався цей матеріал, обов’язково перегляньте повне обговорення в нашому епізоді подкасту Replace Service Accounts with Entra Workload Identities. Підписуйтеся на шоу, щоб отримувати більше глибоких оглядів стратегій безпеки корпоративних Microsoft 365 та Azure!