Коротко для керівника
Ролі адміністраторів Microsoft 365 визначають, хто в компанії може змінювати користувачів, паролі, ліцензії та налаштування безпеки. Повний перелік вбудованих ролей наведено в довіднику Microsoft Entra built-in roles. Для різних задач там є окремі ролі, тому права краще видавати під конкретну задачу й регулярно переглядати.
Для бізнесу це питання контролю. Власник адміністративної ролі може змінити доступи співробітників, ліцензії, спосіб входу, а залежно від ролі й платіжні дані. Тому список таких людей має бути коротким, відомим і актуальним.
Кого це стосується
Тема стосується компаній, які працюють у Microsoft 365 або мають каталог Microsoft Entra ID. Розмір не міняє логіку: і для 10, і для 250 користувачів питання «хто що може» однаково важливе. Компанії, які користуються лише Google Workspace, ця стаття не стосується. Вона також не описує ролі для ресурсів Azure: для них Microsoft веде окремий перелік Azure built-in roles.
Що це означає на практиці
Реальна ситуація зазвичай буденна: співробітник змінив посаду, підрядник завершив проєкт, а права залишилися. Кадрові зміни й робота із зовнішніми фахівцями роблять це звичайним явищем, а не винятком. Приводу для тривоги тут немає, але раз на квартал на список ролей дивитися варто.
Як це працює
Роль (role) у Microsoft Entra ID це набір дозволів, який отримує обліковий запис. За описом Microsoft, її призначають іншому адміністратору або навіть звичайному користувачу, якому треба керувати ресурсами Entra. Приклади з довідника: додавати й змінювати користувачів, скидати паролі, керувати ліцензіями та доменними іменами. Якщо ваша команда тільки переходить на корпоративну пошту Microsoft 365, питання ролей краще закрити ще на старті.
Принцип найменших привілеїв
У галузі це називають принципом найменших привілеїв (least privilege): людина отримує рівно ті права, які потрібні для її задачі. Довідник Microsoft цьому допомагає: кожна вбудована роль має короткий опис і власний Template ID, тож можна порівняти, що саме дозволяє кожна, і вибрати ту, що відповідає задачі.
Приклади з довідника
Візьмемо дві ролі, які легко сплутати. Authentication Administrator може переглядати, задавати й скидати дані методів автентифікації для будь-якого користувача, який не є адміністратором. Authentication Policy Administrator керує політикою методів автентифікації, загальними налаштуваннями багатофакторної автентифікації (MFA) для всієї організації, політикою захисту паролів і verifiable credentials. Перша роль допомагає окремим людям увійти, друга змінює правила для всіх.
Звернімо увагу на застереження в описі першої ролі: вона працює лише з користувачами без адмінських прав. Тобто співробітник служби підтримки з нею не відновить доступ колезі-адміністратору. Це зручне обмеження, а не недолік: воно не дає ланцюжку «скинув пароль і зайшов як адмін».
Ще одна пара стосується застосунків. Application Administrator може створювати й керувати всіма аспектами реєстрацій застосунків і корпоративних застосунків. Application Developer може створювати реєстрації застосунків незалежно від налаштування «Users can register applications» і змінювати ті застосунки, якими володіє. Якщо розробнику потрібні лише власні реєстрації, вужча друга роль логічніша за першу.
Для фінансів існує Billing Administrator: він виконує типові платіжні задачі, наприклад оновлює платіжну інформацію. Compliance Administrator читає й змінює налаштування та звіти відповідності в Entra і Microsoft 365. Є й ролі для нових сервісів: AI Administrator керує Microsoft Copilot та пов'язаними корпоративними AI-сервісами в Microsoft 365, а AI Reader тільки читає ці налаштування. Усі ці приклади взято з початку списку, повний перелік значно довший.
Варіанти
На практиці компанії розподіляють адмінські права одним із трьох способів. Нижче коротко про кожен і наша оцінка.
Один-два універсальні адміністратори
Це найпростіше: всі права зосереджені в кількох людей, питань «кому писати» немає. Мінус у тому, що кожен такий обліковий запис стає дуже цінним. Помилка, втрачений пристрій чи звільнення однієї людини зачіпають усе середовище одразу. Для невеликої компанії це прийнятна відправна точка, але не місце, де варто зупинятися.
Вузькі вбудовані ролі
Це наш рекомендований варіант для більшості компаній. Помічник підтримки отримує роль для автентифікації, бухгалтер або офіс-менеджер роль для оплат, спеціаліст з безпеки роль для відповідних політик. Кожна задача має власну роль, а перелік зрозумілий і керівнику, і аудитору. Ускладнення невелике: доведеться раз описати, хто що робить.
Власні ролі
Microsoft дозволяє створювати власні ролі (custom roles), але з обмеженням: лише частина дозволів зі списку вбудованих ролей доступна для власних. Тому не варто будувати схему на припущенні, що можна скласти роль під будь-яку потребу. Спершу перевірте, чи не закриває задачу вбудована роль, і лише потім думайте про власну.
Як обрати
Орієнтуйтеся на три питання. Яку дію людина виконує щотижня, а яку раз на рік? Чи може вона зашкодити іншим користувачам або всій організації? Чи потрібен їй доступ постійно, чи на період проєкту? Відповіді допоможуть підібрати вужчу роль, ніж та, яку хочеться видати «про всяк випадок».
Кроки для адміністратора
- Складіть перелік усіх, хто має адміністративні ролі, включно з підрядниками. Перевірка: кожне ім'я ви можете співвіднести з живою людиною, її посадою й завданням.
- Для кожної людини запишіть, які саме дії вона виконує: скидає паролі, керує ліцензіями, налаштовує застосунки, оплачує сервіси. Перевірка: напроти кожної дії стоїть роль з довідника Microsoft або примітка, що вбудованої ролі під неї не знайдено.
- Замініть широкі ролі вужчими там, де це можливо. Перевірка: після зміни людина виконує свою щоденну задачу й підтверджує, що доступ до решти налаштувань їй не потрібен.
- Відокремте адміністративний обліковий запис від щоденного: адмінські дії виконуйте лише під ним, а пошту й браузер відкривайте під звичайним. Перевірка: звичайний обліковий запис не має адмінських ролей, а для адмінського ввімкнено MFA.
- Для зовнішніх фахівців визначте термін доступу й відповідального зі свого боку. Перевірка: у переліку напроти кожного підрядника є дата наступного перегляду.
- Призначте регулярний перегляд, наприклад раз на квартал, і фіксуйте результат. Перевірка: у календарі є повторювана задача, а після першого перегляду залишився короткий запис про зміни.
Пріоритет
Сьогодні: якщо під час першого кроку ви знайшли колишнього співробітника чи підрядника з адмінською роллю, прибирайте її одразу. Цього тижня: завершіть інвентаризацію й замініть найширші ролі на вужчі. При плановому оновленні налаштувань: введіть квартальний перегляд і розгляньте власні ролі, якщо вбудовані справді не підходять.
Якщо адміністратора немає
У невеликих компаніях адмінські права часто опиняються в того, хто колись налаштовував систему, і ніхто не відповідає за їх перегляд. Якщо у вашій компанії немає людини, яка стежить за правами адміністраторів Microsoft 365, цей контроль можна передати команді TakeIT. Для початку можна замовити IT-аудит компанії, де список ролей і доступів буде одним із питань.
Часті питання
Чи можна видати роль не адміністратору?
Так. У довіднику прямо сказано, що роль можуть отримати і інші адміністратори, і неадміністратори, яким потрібно керувати ресурсами Entra. Наприклад, людині з бухгалтерії можна дати лише платіжну роль, не роблячи її IT-адміністратором.
Чи діють ці ролі для ресурсів Azure?
Ці ролі призначені для керування ресурсами Microsoft Entra. Для ресурсів Azure Microsoft веде окремий перелік Azure built-in roles. Не змішуйте їх: потрібну роль шукайте в тому переліку, який відповідає ресурсу, яким ви керуєте.
Навіщо окремі ролі для AI?
Бо Copilot та пов'язані сервіси мають власні налаштування. AI Administrator керує ними, а AI Reader може лише дивитися. Якщо ви тільки пробуєте AI-функції, зазвичай достатньо дати читання тому, хто готує рішення, а керування залишити одній відповідальній людині.
Скільки адміністраторів має бути?
Фіксованого числа джерело не називає, і ми не будемо його вигадувати. Орієнтир практичний: достатньо, щоб відпустка або хвороба однієї людини не зупиняли роботу, але не більше, ніж ви здатні перелічити на пам'ять.
Висновок
Адмінські ролі схожі на ключі від кабінетів: майстер-ключ потрібен рідко, а загублений коштує дорого. Вбудовані ролі Microsoft уже розділяють відповідальність, залишається застосувати це до вашої команди й раз на квартал звіряти список із реальністю.
Джерела
- Microsoft Entra built-in roles · 3 листопада 2026 р.
