Настройка делегирования с помощью административных единиц

  • 7 мин

Административные единицы — это ресурсы идентификатора Microsoft Entra, которые могут быть контейнерами для других ресурсов Microsoft Entra. Административная единица может содержать только пользователей, групп и устройств.

Административные единицы ограничивают разрешения в роли для любой части организации, которую вы определяете. Вы можете, например, использовать административные единицы для делегирования роли администратора службы поддержки региональным специалистам службы поддержки, чтобы они могли управлять пользователями только в том регионе, который они поддерживают. Административными единицами можно управлять с помощью портала Azure, командлетов и скриптов PowerShell или Microsoft Graph.

Что такое административная единица?

В идентификаторе Microsoft Entra, используя один клиент, если вы назначаете пользователю любую роль администратора, теперь они администраторы над каждым пользователем в клиенте. Всегда думайте о принципе минимальных привилегий при назначении административных обязанностей. Административные единицы — это контейнеры, созданные для решения этой проблемы в идентификаторе Microsoft Entra. Если вы хотите, чтобы администратор пользователей управлял только ограниченной группой пользователей, например только пользователями из исследовательского отдела больницы, вы можете настроить административную единицу. Тогда в этой административной единице вы добавите пользователей и группы для команды исследователей, а затем добавите определенного пользователя в роль администратора пользователей в административной единице, назвав его "Администратор исследователей". Администратор может управлять пользователями в административной единице, но не во всем клиенте, что помогает достичь принципа минимальных привилегий.

Какие роли администратора доступны для административной единицы?

Пользователи могут управлять административной единицей с помощью следующих ролей:

  • Администратор проверки подлинности
  • Администратор групп
  • Администратор службы поддержки
  • Администратор лицензий
  • Администратор паролей
  • Администратор пользователей

Примечание.

Если вы знакомы с локальной службой Active Directory, эта возможность обрабатывалась путем настройки подразделений в каталоге и добавления пользователей в подразделение.

Планирование административных единиц

Административные единицы можно использовать для логического группирования ресурсов Microsoft Entra. Организация с ИТ-отделом международного масштаба, возможно, может создать административные единицы, определяющие географические границы соответствующих регионов. Еще один сценарий — глобальная организация с подчиненными структурами, являющимися в определенной степени полуавтономными, в которой каждая такая структура может быть представлена административной единицей.

Критерии, по которым создаются административные единицы, определяются уникальными требованиями организации. Административные единицы — это распространенный способ определения структуры в службах Microsoft 365. При подготовке административных единиц рекомендуется учитывать их использование в службах Microsoft 365. Вы можете реализовать максимальную эффективность административных единиц, если свяжете общие ресурсы из Microsoft 365 в административной единице.

Создание административных единиц в организации можно условно разделить на следующие этапы:

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

Делегирование администрирования в идентификаторе Microsoft Entra

По мере роста организации возрастает и сложность ее структуры. Одним из распространенных ответов является сокращение рабочей нагрузки управления доступом с ролями администратора Microsoft Entra. Можно предоставить пользователям минимально необходимый уровень для доступа к конкретным приложениям и выполнения задач. Даже если вы не назначаете роль глобального администратора всем владельцам приложения, вы возлагаете обязанности по управлению приложением на имеющихся глобальных администраторов. Существует множество причин, по которым организациям стоит перейти на децентрализованное администрирование.

В идентификаторе Microsoft Entra можно делегировать разрешения на создание и управление приложениями следующими способами:

  • Ограничение круга пользователей, которые могут создавать приложения и управлять ими. По умолчанию в идентификаторе Microsoft Entra все пользователи могут регистрировать регистрации приложений и управлять всеми аспектами создаваемых приложений. Это разрешение можно предоставить только избранным пользователям.
  • Назначение приложению одного или нескольких владельцев. Простой способ предоставить пользователю возможность управлять всеми аспектами конфигурации идентификатора Microsoft Entra для конкретного приложения.
  • Назначение встроенной административной роли, которая предоставляет доступ к управлению конфигурацией в идентификаторе Microsoft Entra для всех приложений. Рекомендуемый способ предоставить ИТ-специалистам доступ к управлению широкими разрешениями конфигурации приложений без предоставления доступа к другим частям идентификатора Microsoft Entra, не связанным с конфигурацией приложения.
  • Создайте пользовательскую роль для определения конкретных разрешений. Затем назначьте роль пользователю, чтобы настроить ограниченного владельца. Вы также можете назначить ограниченного администратора на уровне каталога.

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

Планирование делегирования

Непросто разработать модель делегирования, которая соответствует вашим потребностям. Разработку модели делегирования следует выполнять поэтапно. Мы рекомендуем разбить процесс на следующие этапы:

  • определение необходимых ролей;
  • Делегирование прав на администрирование приложений
  • предоставление прав на регистрацию приложений;
  • Делегирование прав владения приложениями
  • разработка плана безопасности;
  • создание учетных записей для экстренных ситуаций;
  • защита ролей администраторов;
  • применение схемы временного повышения привилегий.

Определение ролей

Оцените, какие задачи выполняются администраторами в Active Directory и как эти задачи можно распределить по ролям. Оцените частоту выполнения, значимость и сложность каждой задачи. Именно эти важные аспекты оценки задачи определяют, какие разрешения можно или нужно делегировать.

  • Для делегирования лучше всего подходят те задачи, которые выполняются регулярно, не сопряжены со значительными рисками и просты в выполнении.
  • Редко выполняемые задачи с потенциальным риском во всей организации и высокими требованиями к навыкам исполнителей можно делегировать только после тщательного анализа. Для таких задач лучше использовать временное повышение прав учетной записи до необходимой роли или переназначение.

Делегирование прав на администрирование приложений

Распространение приложений в организации усложняет модель делегирования. Если задача управления приложениями создает большую нагрузку на глобального администратора, такая модель со временем потребует все больше сил на ее реализацию. Если вы предоставляете пользователям роль глобального администратора для таких задач, как настройка корпоративных приложений, постарайтесь передать эти функции другим ролям с меньшими правами доступа. Такое ограничение повысит уровень безопасности и снизит вероятность проблем из-за возможных ошибок. Ниже перечислены роли администраторов с наивысшим уровнем привилегий.

  • Роль администратора приложений, которая дает права на управление приложениями в каталоге: регистрация, настройка единого входа, назначение пользователей и групп, лицензирование, настройка прокси приложений, управление согласием. Она не предоставляет прав на управление условным доступом.
  • Роль администратора облачных приложений, которая предоставляет все возможности администратора приложений, за исключением доступа к параметрам прокси приложения (так как не включает разрешения на действия в локальной среде).

Делегирование прав на регистрацию приложений

По умолчанию регистрацию приложений могут создавать все пользователи. Чтобы выборочно предоставить возможность создания регистраций приложения, сделайте следующее.

  • В разделе Параметры пользователя для параметра Пользователи могут регистрировать приложения задайте значение "Нет".
  • Назначение пользователю роли разработчика приложения

Чтобы выборочно предоставить возможность давать согласие на доступ приложения к данным, сделайте следующее.

  • В разделе User settings (Параметры пользователя) для корпоративных приложений задайте для параметра Пользователи могут давать согласие на доступ приложений к данным компании от их имени. (Пользователи могут предоставлять согласие на доступ приложений к данным компании от их имени) значение No (Нет).
  • Назначение пользователю роли разработчика приложения

Когда разработчик регистрирует новое приложение, он автоматически становится первым владельцем этого приложения.

Делегирование прав владения приложениями

Вы можете еще глубже детализировать доступ к приложениям, назначая права владения для определенных корпоративных приложений. Вы улучшаете поддержку назначения владельцев для регистрации приложений. Владение назначается отдельно для каждого приложения в организации с помощью экрана "Корпоративные приложения". Это удобно, так как владельцы могут управлять только теми корпоративными приложениями, которыми они владеют. Например, можно назначить владельца для приложения Salesforce, и тогда он сможет управлять доступом и настройками только для Salesforce, но не для других приложений. Каждое корпоративное приложение может иметь много владельцев, и каждый пользователь может быть владельцем многих корпоративных приложений. Различают две роли владельца приложения.

  • Роль владельца корпоративного приложения дает возможность управлять корпоративными приложениями, владельцами которых является этот пользователь, в том числе настраивать единый вход, назначать пользователей и группы, добавлять новых владельцев. Она не предоставляет прав на управление параметрами прокси приложений или условного доступа.
  • Роль владельца регистрации приложения дает возможность управлять регистрациями для тех приложений, владельцами которых является этот пользователь, в том числе изменять манифест приложения и добавлять новых владельцев.

разработка плана безопасности;

Идентификатор Microsoft Entra id предоставляет подробное руководство по планированию и выполнению плана безопасности для ролей администратора Microsoft Entra, защиты привилегированного доступа для гибридных и облачных развертываний.

создание учетных записей для экстренных ситуаций;

Чтобы сохранить доступ к хранилищу управления удостоверениями при возникновении проблем, подготовьте учетные записи для аварийного доступа по инструкциям из статьи Управление учетными записями администратора для аварийного доступа в Azure AD.

защита ролей администраторов;

Получив доступ к привилегированным учетным записям, злоумышленники могут нанести серьезный вред. Всегда обеспечивайте защиту этих учетных записей. Используйте функцию по умолчанию безопасности, доступную всем организациям Microsoft Entra. По умолчанию безопасность применяет многофакторную проверку подлинности для привилегированных учетных записей Microsoft Entra.