Роли администраторов Microsoft 365: кто что может в компании

Коротко для руководителя

Роли администраторов 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), но с ограничением: для них доступна лишь часть разрешений из списка встроенных ролей. Поэтому не стоит строить схему на предположении, что можно собрать роль под любую потребность. Сначала проверьте, не закрывает ли задачу встроенная роль, и только потом думайте о собственной.

Как выбрать

Ориентируйтесь на три вопроса. Какое действие человек выполняет каждую неделю, а какое раз в год? Может ли он навредить другим пользователям или всей организации? Нужен ли ему доступ постоянно или на период проекта? Ответы помогут подобрать более узкую роль, чем та, которую хочется выдать «на всякий случай».

Шаги для администратора

1. Составьте список всех, у кого есть административные роли, включая подрядчиков. Проверка: каждое имя вы можете соотнести с живым человеком, его должностью и задачей.
2. Для каждого человека запишите, какие именно действия он выполняет: сбрасывает пароли, управляет лицензиями, настраивает приложения, оплачивает сервисы. Проверка: напротив каждого действия стоит роль из справочника Microsoft или пометка, что встроенной роли под него не найдено.
3. Замените широкие роли более узкими там, где это возможно. Проверка: после замены человек выполняет свою ежедневную задачу и подтверждает, что доступ к остальным настройкам ему не нужен.
4. Отделите административную учётную запись от повседневной: админские действия выполняйте только под ней, а почту и браузер открывайте под обычной. Проверка: у обычной учётной записи нет админских ролей, а для административной включена MFA.
5. Для внешних специалистов определите срок доступа и ответственного со своей стороны. Проверка: в списке напротив каждого подрядчика есть дата следующего пересмотра.
6. Назначьте регулярный пересмотр, например раз в квартал, и фиксируйте результат. Проверка: в календаре есть повторяющаяся задача, а после первого пересмотра остался короткий протокол изменений.

Приоритет

Сегодня: если на первом шаге вы нашли бывшего сотрудника или подрядчика с админской ролью, уберите её сразу. На этой неделе: завершите инвентаризацию и замените самые широкие роли более узкими. При плановом обновлении настроек: введите квартальный пересмотр и рассмотрите собственные роли, если встроенные действительно не подходят.

Если администратора нет

В небольших компаниях админские права часто оказываются у того, кто когда-то настраивал систему, и никто не отвечает за их пересмотр. Если в вашей компании нет человека, который следит за правами администраторов Microsoft 365, этот контроль можно передать команде TakeIT. Для начала можно заказать IT-аудит компании, где список ролей и доступов будет одним из вопросов.

Частые вопросы

Можно ли выдать роль не администратору?

Да. В справочнике прямо сказано, что роль могут получить и другие администраторы, и неадминистраторы, которым нужно управлять ресурсами Entra. Например, сотруднику бухгалтерии можно дать только платёжную роль, не делая его IT-администратором.

Действуют ли эти роли для ресурсов Azure?

Эти роли предназначены для управления ресурсами Microsoft Entra. Для ресурсов Azure Microsoft ведёт отдельный перечень Azure built-in roles. Не смешивайте их: нужную роль ищите в том перечне, который соответствует ресурсу, которым вы управляете.

Зачем отдельные роли для AI?

Потому что у Copilot и связанных сервисов есть собственные настройки. AI Administrator управляет ими, а AI Reader может только смотреть. Если вы только пробуете AI-функции, обычно достаточно дать чтение тому, кто готовит решение, а управление оставить одному ответственному человеку.

Сколько должно быть администраторов?

Фиксированного числа источник не называет, и мы не будем его выдумывать. Ориентир практический: достаточно, чтобы отпуск или болезнь одного человека не останавливали работу, но не больше, чем вы способны перечислить по памяти.

Вывод

Админские роли похожи на ключи от кабинетов: мастер-ключ нужен редко, а потерянный стоит дорого. Встроенные роли Microsoft уже разделяют ответственность, остаётся применить это к вашей команде и раз в квартал сверять список с реальностью.