Управление учетными записями для аварийного доступа в Microsoft Entra ID
Важно предотвратить случайную блокировку организации Microsoft Entra, которая может случиться, если вы не сможете выполнить вход или назначить администратором другую учетную запись пользователя. Уменьшить ущерб от случайного блокирования административного доступа можно, создав в организации две или более учетных записи для аварийного доступа.
Учетные записи для аварийного доступа имеют высокий уровень привилегий и не назначаются конкретным лицам. Учетные записи для аварийного доступа используются только в непредвиденных ситуациях, в которых невозможно использовать обычные учетные записи администратора. Рекомендуется поддерживать цель ограничения использования учетной записи аварийного реагирования только в то время, когда это абсолютно необходимо.
В этой статье приведены рекомендации по управлению учетными записями аварийного доступа в идентификаторе Microsoft Entra.
Зачем использовать учетную запись для аварийного доступа?
Организации может потребоваться использовать учетные записи для аварийного доступа в следующих ситуациях.
- Учетные записи пользователей объединяются в федерацию, которая в настоящее время недоступна из-за перебоев в работе сотовой сети или поставщика удостоверений. Например, если узел поставщика удостоверений в вашей среде снизился, пользователи могут не входить, когда идентификатор Microsoft Entra ID перенаправляется на своего поставщика удостоверений.
- Администраторы зарегистрированы через многофакторную проверку подлинности Microsoft Entra, и все их отдельные устройства недоступны или служба недоступна. Пользователи могут не выполнить многофакторную проверку подлинности для активации роли. Например, из-за сбоя сотовой сети они не могут отвечать на телефонные звонки или получать текстовые сообщения (два механизма аутентификации, зарегистрированные для устройства).
- Пользователь, которому недавно предоставили права глобального административного доступа, покинул организацию. Идентификатор Microsoft Entra запрещает удаление последней учетной записи глобального администратора, но не предотвращает удаление или отключение учетной записи локальной среды. В этих случаях сбой может привести к тому, что организация не сможет восстановить учетную запись.
- Может возникнуть непредвиденное обстоятельство, такое как чрезвычайная ситуация в случае стихийного бедствия, при котором мобильный телефон или другие сети могут быть недоступны.
Создание учетных записей для аварийного доступа
Создайте две или больше учетных записей для аварийного доступа. Такие учетные записи должны использоваться только в облаке, то есть только для домена onmicrosoft.com. Не стоит делать их федеративными или синхронизировать из локальной среды.
Создание учетной записи для аварийного доступа
Войдите в Центр администрирования Microsoft Entra в качестве глобального администратора.
Перейдите в раздел Удостоверение>Пользователи>Все пользователи.
Выберите Новый пользователь.
Щелкните Create user (Создать пользователя).
Присвойте учетной записи Имя пользователя.
Присвойте учетной записи Имя.
Создайте для учетной записи длинный и сложный пароль.
В разделе Роли назначьте роль Глобальный администратор.
В разделе Место использованиявыберите нужное расположение.
Нажмите кнопку создания.
При настройке этих учетных записей должны выполняться приведенные далее требования.
- Учетные записи аварийного доступа не должны быть связаны с конкретным пользователем в организации. Следите за тем, чтобы учетные записи организации не были привязаны к личным мобильным телефонам сотрудников, находящимся в распоряжении сотрудников аппаратным маркерам или другим учетным данным, зависящим от конкретного сотрудника. Эта мера безопасности распространяется на случаи, когда учетные данные нужны, а отдельный сотрудник недоступен. Важно убедиться, что все зарегистрированные устройства хранятся в известном безопасном расположении с несколькими средствами взаимодействия с идентификатором Microsoft Entra.
- Используйте строгую проверку подлинности для учетных записей аварийного доступа и убедитесь, что не используется тот же способ проверки подлинности, что и для других учетных записей администратора. Например, если обычная учетная запись администратора использует для строгой проверки подлинности приложение Microsoft Authenticator, то для учетных записей аварийного доступа следует использовать ключ безопасности FIDO2. Учитывайте зависимости различных способов проверки подлинности, чтобы избежать добавления внешних требований в процесс проверки подлинности.
- Устройство или учетные данные должны быть действительными, либо они не должны входить в планы по автоматической очистке из-за недостаточного использования.
- В microsoft Entra управление привилегированными пользователями необходимо сделать назначение роли глобального администратора постоянным, а не иметь права на доступ к учетным записям аварийного доступа.
Исключить хотя бы одну учетную запись из многофакторной проверки подлинности на основе телефона
Чтобы снизить риск атаки, возникшей из-за скомпрометированного пароля, идентификатор Microsoft Entra рекомендует требовать многофакторную проверку подлинности для всех отдельных пользователей. В эту группу входят администраторы и остальные специалисты (например, финансовые сотрудники), чья скомпрометированная учетная запись окажет значительное влияние.
Однако хотя бы одна из учетных записей аварийного доступа не должна иметь тот же механизм многофакторной проверки подлинности, что и другие учетные записи, не являющиеся экстренными. Сюда входят сторонние решения многофакторной проверки подлинности. Если у вас есть политика условного доступа для необходимости многофакторной проверки подлинности для каждого администратора для идентификатора Microsoft Entra ID и другого подключенного программного обеспечения как службы (SaaS), следует исключить учетные записи аварийного доступа из этого требования и настроить другой механизм. Кроме того, следует убедиться, что учетные записи не имеют политики многофакторной проверки подлинности для каждого пользователя.
Исключение по меньшей мере одной учетной записи из политик условного доступа
Вам не понравится, если во время аварии такая политика заблокирует доступ, необходимый для устранения проблем. При использовании условного доступа необходимо исключить по крайней мере одну учетную запись аварийного доступа из всех политик условного доступа.
Примечание.
Начиная с июля 2024 года команды Azure начнут развертывать дополнительные меры безопасности на уровне клиента, чтобы требовать многофакторную проверку подлинности (MFA) для всех пользователей. Как уже задокументировано, используйте надежную проверку подлинности для учетных записей аварийного доступа. Мы рекомендуем обновить эти учетные записи, чтобы использовать проверку подлинности на основе сертификатов fiDO2 или на основе сертификатов (при настройке в качестве MFA) вместо того, чтобы использовать только длинный пароль. Оба метода удовлетворяют требованиям MFA.
Руководство по объединению в федерацию
Некоторые организации используют доменные службы AD и AD FS или аналогичный поставщик удостоверений для федерации с идентификатором Microsoft Entra. Аварийный доступ к локальным системам и аварийный доступ для облачных служб должны использоваться отдельно, без зависимости друг от друга. Мастеринг и проверка подлинности для учетных записей с привилегиями аварийного доступа из других систем добавляет ненужный риск в случае сбоя этих систем.
Безопасное хранение данных учетной записи
Организации должны обеспечить защиту учетных данных для учетных записей аварийного доступа и предоставить к ним доступ только тем, у кого есть право на их использование. Некоторые клиенты используют смарт-карту для Windows Server AD, ключ безопасности FIDO2 для идентификатора Microsoft Entra и другие используют пароли. Пароль учетной записи для аварийного доступа обычно разделяется на две или три части, написанные на отдельных листах бумаги, хранящихся в безопасных огнестойких сейфах в отдельных безопасных местах.
При использовании паролей убедитесь, что учетные записи имеют надежные пароли, которые не истекают. В идеале пароли должны создаваться случайным образом и состоять как минимум из 16 символов.
Мониторинг журналов входа и аудита
Организации должны отслеживать действия входа и ведения журнала аудита из учетных записей для аварийного доступа и запускать уведомления для других администраторов. При наблюдении за активностью учетных записей для аварийного доступа можно проверить, используются ли эти учетные записи только для тестирования или в реальных непредвиденных ситуациях. Вы можете использовать Azure Log Analytics для мониторинга журналов входа и отправки сообщений электронной почты и оповещений SMS администраторам при каждом входе в учетные записи для аварийного доступа.
Необходимые компоненты
- Отправьте журналы входа Microsoft Entra в Azure Monitor.
Получение идентификаторов объектов учетных записей для аварийного доступа
Войдите в Центр администрирования Microsoft Entra как минимум администратор пользователя.
Перейдите в раздел Удостоверение>Пользователи>Все пользователи.
Найдите учетную запись для аварийного доступа и выберите имя пользователя.
Скопируйте и сохраните атрибут идентификатора объекта, чтобы его можно было использовать позже.
Повторите предыдущие шаги со второй учетной записью для аварийного доступа.
Создать правило генерации оповещений
Войдите в портал Azure как минимум участник мониторинга.
Перейдите к мониторингу >рабочих областей Log Analytics.
Выберите рабочую область.
В рабочей области выберите Оповещения>Новое правило генерации оповещений.
В разделе Ресурсы убедитесь, что подписка является той, с которой необходимо связать правило оповещения.
В разделе Условиевыберите Добавить.
В разделе Название сигнала выберите значение Пользовательский поиск по журналам.
В разделе Поисковый запрос введите следующий запрос, вставив идентификаторы объектов двух учетных записей для аварийного доступа.
Примечание.
Для каждой дополнительной учетной записи аварийного доступа, которую необходимо включить, добавьте в запрос еще один "or UserId = = "ObjectGuid"".
Примеры запросов:
// Search for a single Object ID (UserID) SigninLogs | project UserId | where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee"
// Search for multiple Object IDs (UserIds) SigninLogs | project UserId | where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee" or UserId == "11bb11bb-cc22-dd33-ee44-55ff55ff55ff"
// Search for a single UserPrincipalName SigninLogs | project UserPrincipalName | where UserPrincipalName == "user@yourdomain.onmicrosoft.com"
В разделе Логика оповещений введите следующее:
- Основа: число результатов.
- Оператор: Больше
- Пороговое значение: 0
В разделе Оценка на основе выберите Период (в минутах) для времени выполнения запроса и Частота (в минутах) для периодичности выполнения запроса. Периодичность должна быть меньше или равна периоду.
Нажмите кнопку Готово. Теперь вы можете просмотреть предполагаемые ежемесячные затраты на это оповещение.
Выберите группу действий пользователей, которые будут уведомлены оповещением. Если вы хотите создать такую группу, см. раздел Создание группы действий.
Чтобы настроить уведомление по электронной почте, отправляемое членам группы действий, выберите действия в разделе Настройка действий.
В разделе Сведения об оповещении укажите имя правила генерации оповещений и добавьте необязательное описание.
Установите Уровень серьезности события. Рекомендуется задать для него значение Критический (уровень серьезности 0).
В разделе Включить правило при создании оставьте значение да.
Чтобы отключать оповещения на время, установите флажок Подавить оповещения и введите длительность ожидания до повторного оповещения, а затем выберите Сохранить.
Щелкните элемент Создать правило генерации оповещений.
Создание группы действий
Введите Создать группу действий.
Введите полное и короткое имена для новой группы действий.
Укажите подписку и группу ресурсов.
В разделе тип действия выберите Email/SMS/Push/Voice (электронная почта, SMS, push-уведомление, голосовое сообщение).
Введите имя действия, например уведомление глобального администратора.
Выберите Тип действия из Email/SMS/Push/Voice (электронная почта, SMS, push-уведомление, голосовое сообщение).
Выберите Изменить сведения, чтобы выбрать методы уведомления, которые нужно настроить, и введите необходимые контактные данные, а затем нажмите кнопку ОК, чтобы сохранить сведения.
Добавьте дополнительные действия, которые необходимо активировать.
Нажмите ОК.
Регулярная проверка учетных записей
При обучении сотрудников использованию учетных записей для аварийного доступа и проверке этих учетных записей регулярно выполняйте как минимум приведенные далее действия.
- Убедитесь, что сотрудники службы мониторинга безопасности знают, что действия по проверке учетных записей нужно выполнять регулярно.
- Убедитесь, что процесс предоставления разрешений для использования этих учетных записей документируется и является актуальным.
- Убедитесь, что администраторы и сотрудники службы безопасности, которым может потребоваться выполнить эти действия в случае чрезвычайной ситуации, прошили соответствующее обучение.
- Обновите учетные данные (в частности, все пароли) для учетных записей аварийного доступа и проверьте, что учетные записи для аварийного доступа могут выполнять вход и решать административные задачи.
- Убедитесь, что пользователи не зарегистрировали многофакторную проверку подлинности или самостоятельный сброс пароля (SSPR) на устройство или персональные данные отдельного пользователя.
- Если учетные записи зарегистрированы для многофакторной проверки подлинности на устройстве, для использования во время входа или активации ролей убедитесь, что устройство доступно всем администраторам, которым может потребоваться использовать его во время чрезвычайной ситуации. Также обеспечьте для устройства не менее двух сетевых путей доступа, которые не зависят от работоспособности друг друга. Например, устройство может осуществлять связь с Интернетом через беспроводную сеть объекта и через сеть сотового оператора.
Приведенные далее действия необходимо выполнять в случае внесения важных изменений и через регулярные промежутки времени.
- Каждые 90 дней.
- Когда произошли недавние изменения в составе ИТ-персонала, такие как смена работы, увольнение или наем нового сотрудника.
- Когда подписки Microsoft Entra в организации изменились
Следующие шаги
- Защита привилегированного доступа для гибридных и облачных развертываний в идентификаторе Microsoft Entra
- Добавление пользователей с помощью идентификатора Microsoft Entra и назначение ролей новому пользователю
- Зарегистрируйтесь в Microsoft Entra ID P1 или P2, если вы еще не зарегистрировались
- Включение двухфакторной проверки подлинности пользователя
- Настройте дополнительные средства защиты для привилегированных ролей в Microsoft 365, если вы используете Microsoft 365
- Запустите проверку доступа привилегированных ролей и переключите существующие назначения привилегированных ролей на более конкретные роли администратора.