Управление учетными записями для аварийного доступа в Microsoft Entra ID

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

Учетные записи пользователей с ролью глобального администратора имеют высокие привилегии в системе, и эта роль включает учетные записи аварийного доступа с ролью глобального администратора. Используйте учетные записи экстренного доступа только в экстренных ситуациях или в сценариях «break glass», когда обычные административные учетные записи использовать невозможно. Ограничьте использование аварийной учетной записи только теми случаями, когда это абсолютно необходимо.

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

Зачем использовать учетную запись для аварийного доступа?

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

• Учетные записи пользователей объединяются в федерацию, которая в настоящее время недоступна из-за перебоев в работе сотовой сети или поставщика удостоверений. Например, если узел поставщика удостоверений в вашей среде становится недоступен, пользователи могут не иметь возможности войти, когда Microsoft Entra ID перенаправляет их к поставщику удостоверений.
• Администраторы проходят регистрацию с использованием многофакторной аутентификации Microsoft Entra, и все их личные устройства недоступны либо недоступна сама служба. Пользователи могут не выполнить многофакторную проверку подлинности для активации роли. Например, из-за сбоя сотовой сети они не могут отвечать на телефонные звонки или получать текстовые сообщения (два механизма аутентификации, зарегистрированные для устройства).
• Пользователь с самым последним доступом глобального администратора покидает организацию. Идентификатор Microsoft Entra запрещает удаление последней учетной записи глобального администратора, но не предотвращает удаление или отключение учетной записи локальной среды. В этих случаях сбой может привести к тому, что организация не сможет восстановить учетную запись.
• Может возникнуть непредвиденное обстоятельство, такое как чрезвычайная ситуация в случае стихийного бедствия, при котором мобильный телефон или другие сети могут быть недоступны.
• Все назначения на роли глобального администратора и администратора привилегированных ролей доступны для активации (не активны), для активации требуется утверждение, и не выбраны утверждающие лица (или все выбранные утверждающие лица были удалены из каталога). Активные глобальные администраторы и администраторы привилегированных ролей являются утверждающими лицами по умолчанию, если явным образом никто не выбран, но, поскольку ни один из них не активен, никто не может утвердить активацию, и администрирование арендатора фактически заблокировано.

Создание учетных записей для аварийного доступа

Создайте две или больше учетных записей для аварийного доступа. Такие учетные записи должны быть исключительно облачными и использовать домен *.onmicrosoft.com. Они не должны быть федеративными или синхронизированными из локальной среды. На высоком уровне выполните следующие действия.

1. Найдите существующие учетные записи аварийного доступа или создайте новых пользователей только в облаке и назначьте им роль глобального администратора.

2. Выберите один из этих методов проверки подлинности без пароля для учетных записей аварийного доступа. Эти методы удовлетворяют обязательным требованиям многофакторной проверки подлинности.

   • Passkey (FIDO2) ( рекомендуется)
   • Проверка подлинности на основе сертификатов, если в вашей организации уже настроена инфраструктура открытых ключей (PKI)

3. Зарегистрируйте учетные данные для метода проверки подлинности, выбранного на предыдущем шаге.

   • Секретный ключ (FIDO2): включение секретных ключей (FIDO2) для вашей организации, а затем регистрация ключа доступа (FIDO2)
   • Проверка подлинности на основе сертификатов: настройка проверки подлинности на основе сертификатов

4. Убедитесь, что учетные записи аварийного доступа исключены из любой политики условного доступа, которая блокирует или ограничивает вход. Метод проверки подлинности, устойчивый к фишингу, зарегистрированный на предыдущем шаге, защищает учетную запись; Примененная политика условного доступа может предотвратить вход во время точной аварийной ситуации, для которой предназначена учетная запись. Политики в режиме «Только отчет» не блокируют доступ и не требуют исключения. Дополнительные сведения см. в рекомендациях по условному доступу.

5. Безопасно храните данные учетной записи.

6. Отслеживайте журналы входа и аудита.

7. Регулярно проверяйте учетные записи.

Требования к конфигурации

При настройке этих учетных записей убедитесь, что выполнены следующие требования:

• Не свяжите учетные записи аварийного доступа с отдельным пользователем в организации. Сохраните учетные данные в известном безопасном расположении, доступном нескольким членам группы администрирования. Не подключайте эти учетные записи с устройствами, предоставленными сотрудниками, например телефонами. Такой подход объединяет управление учетными записями аварийного доступа. Большинство организаций нуждаются в учетных записях аварийного доступа не только для инфраструктуры Microsoft Cloud, но и для локальных сред, федеративных приложений SaaS и других критически важных систем.

  Кроме того, можно создать отдельные учетные записи аварийного доступа для администраторов. Это решение способствует подотчетности и позволяет администраторам использовать учетные записи аварийного доступа из удаленных расположений.

• Используйте надежную проверку подлинности для учетных записей аварийного доступа и убедитесь, что они не используют те же методы проверки подлинности, что и другие учетные записи администратора. Например, если обычная учетная запись администратора использует для строгой проверки подлинности приложение Microsoft Authenticator, то для учетных записей аварийного доступа следует использовать ключ безопасности FIDO2. Чтобы избежать добавления внешних требований в процесс проверки подлинности, рассмотрите зависимости различных методов проверки подлинности.

• Устройство или учетные данные не должны истекать или попадать под автоматическую очистку из-за отсутствия использования.

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

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

Руководство по объединению в федерацию

Некоторые организации используют доменные службы Active Directory и службу федерации Active Directory (AD FS) или аналогичного поставщика удостоверений для федерации с Microsoft Entra ID. Разделяйте экстренный доступ к локальным системам и экстренный доступ к облачным службам так, чтобы одно не зависело от другого. Управление аутентификацией для учетных записей с привилегиями экстренного доступа или её получение из других систем создает ненужный риск в случае сбоя в этих системах.

Безопасное хранение данных учетной записи

Убедитесь, что учетные данные для учетных записей аварийного доступа защищены и известны только лицам, которым разрешено использовать их. Например, можно использовать ключи безопасности FIDO2 для идентификатора Microsoft Entra или смарт-карт для Windows Server Active Directory. Храните учетные данные в безопасных, пожаробезопасных устройствах, которые находятся в безопасных, отдельных расположениях.

Рекомендации по условному доступу

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

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

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

Дополнительные сведения о планировании исключений условного доступа см. в разделе Планирование развертывания условного доступа.

Сводка по мерам безопасности

Следующий контрольный список содержит общие сведения о требованиях безопасности для учетных записей аварийного доступа:

• Сохраняйте по крайней мере две учетные записи аварийного доступа для избыточности.
• Используйте облачные учетные записи (.onmicrosoft.com домен) без зависимости от федеративных поставщиков удостоверений.
• Используйте методы проверки подлинности, устойчивые к фишингу (ключи безопасности FIDO2 или проверка подлинности на основе сертификатов), отличные от обычных учетных записей администратора.
• Убедитесь, что срок действия учетных данных и устройств не истекает и не подлежит автоматической очистке.
• В управление привилегированными пользователями назначьте роль «Глобальный администратор» как постоянную активную (а не допустимую для активации) для аварийных учетных записей.
• Требуется использовать назначенную безопасную рабочую станцию или рабочую станцию привилегированного доступа при использовании учетных записей аварийного доступа.
• Храните учётные данные в отдельных, безопасных, защищённых от огня местах, доступных уполномоченным лицам.
• Исключите учетные записи аварийного доступа из политик условного доступа, которые блокируют или ограничивают вход. Политики режима «только отчет» не требуют исключения.
• Отслеживайте все действия журнала входа и аудита для учетных записей аварийного доступа с оповещениями об обнаружении ненужных или неавторизованных операций.
• Проверка функциональности учетной записи по крайней мере каждые 90 дней.

Доступность аудита и соответствие требованиям

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

• Мониторинг журнала входа и аудита. Настройка оповещений для каждого использования учетной записи аварийного доступа. Собирайте журналы входа в систему и журналы аудита для последующей проверки. Дополнительные сведения см. в разделе "Мониторинг журналов входа и аудита " в этой статье.
• Проверка по итогам инцидента: после любого использования учетной записи для аварийного доступа проведите проверку, чтобы определить, было ли такое использование санкционировано и были ли предпринятые действия надлежащими. Подробнее см. в разделе Подготовка команды для посмертного анализа в этой статье.
• Регулярная проверка: проводите проверочные процедуры для учетной записи не реже одного раза в 90 дней, включая проверку списка авторизованных пользователей и тестирование возможностей входа и выполнения административных задач. Подробнее см. раздел Регулярно проверяйте учетные записи в этой статье.
• Сопоставление требований соответствия: Если ваша организация обязана соблюдать требования HIPAA, Microsoft предоставляет рекомендации о том, как учетные записи для экстренного доступа соотносятся с требованиями HIPAA к процедурам экстренного доступа. Дополнительные сведения см. в разделе "Элементы управления доступом HIPAA".

Мониторинг журналов входа и аудита

Отслеживайте активность в журналах входа и аудита для аварийных учетных записей и отправляйте уведомления другим администраторам. При мониторинге активности учетных записей экстренного доступа, можно удостовериться, что они используются только для тестирования или в реальных чрезвычайных ситуациях. Вы можете использовать Azure Monitor, Microsoft Sentinel или другие средства для отслеживания журналов входа и активации оповещений электронной почты и SMS для администраторов при входе учетных записей аварийного доступа. В этом разделе показано использование Azure Monitor.

Предварительные условия

• Отправьте журналы входа Microsoft Entra в Azure Monitor.

Получение идентификаторов объектов учетных записей аварийного доступа

1. Войдите в центр администрирования Microsoft Entra как минимум в качестве Администратора пользователя.

2. Перейдите к Entra ID>Пользователи.

3. Найдите учетную запись аварийного доступа и выберите имя пользователя.

4. Скопируйте и сохраните атрибут идентификатора объекта, чтобы его можно было использовать позже.

5. Повторите предыдущие шаги для второй учетной записи аварийного доступа.

Создать правило генерации оповещений

1. Войдите на портал Azure как минимум помощник по мониторингу.

2. Найдите и откройте монитор.

3. В меню слева выберите "Оповещения".

4. Выберите + Создать>Правило оповещения. Откроется страница создания правила генерации оповещений.

5. На вкладке "Область ":

   1. На панели Select a resource найдите и выберите рабочую область Log Analytics.
   2. Убедитесь, что подписка соответствует рабочей области, настроенной в предварительных требованиях.
   3. Нажмите кнопку "Применить".

6. На вкладке "Условие ":

   1. В раскрывающемся списке Имя сигнала выберите пункт Пользовательский поиск в журналах.

   2. Задайте тип запросадля агрегированных журналов.

   3. В разделе "Поиск" введите один из следующих запросов, вставив идентификаторы объектов двух учетных записей аварийного доступа.

      Примечание.

      Для каждой дополнительной учетной записи аварийного доступа, которую вы хотите включить, добавьте еще один or UserId == "ObjectGuid" в запрос.

      Примеры запросов:

      // Search for a single Object ID (UserID)
      SigninLogs
      | where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee"
      | project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription
      

      // Search for multiple Object IDs (UserIds)
      SigninLogs
      | where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee" or UserId == "11bb11bb-cc22-dd33-ee44-55ff55ff55ff"
      | project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription
      

      // Search for a single UserPrincipalName
      SigninLogs
      | where UserPrincipalName == "user@yourdomain.onmicrosoft.com"
      | project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription
      

   4. В разделе "Измерение" задайте, как суммировать результаты запроса:

      1. Выберите меру.
      2. Выберите тип агрегирования.
      3. Выберите степень детализации агрегирования.

   5. В разделе Разделение по измерениям выберите столбец "Идентификатор ресурса".

   6. В разделе логики оповещений:

      1. Установите для типа порога значение Статический.
      2. Задайте для оператора значение «Больше чем».
      3. Установите для параметра Пороговое значение значение 0.
      4. Задайте частоту оценки на частоту выполнения запроса.

      

   7. Чтобы продолжить, выберите Далее.

7. На вкладке "Действия" выберите группу действий, которую будет уведомлять оповещение. Если вы хотите создать его, см. статью "Создание группы действий".

8. На вкладке Подробные сведения выполните следующие действия.

   1. Выберите серьезность события. Используйте 0 — критическое значение.
   2. Введите имя правила генерации оповещений и добавьте необязательное описание.
   3. Выберите Регион.
   4. Выберите, какой Identity использовать при выполнении запроса к журналу.
   5. В разделе "Дополнительные параметры" выберите "Включить при создании".
   6. Чтобы продолжить, выберите Далее.

9. На вкладке "Теги" добавьте все теги, которые необходимо связать с правилом генерации оповещений.

10. Выберите Проверить и создать, а затем выберите Создать.

Создание группы действий

1. Выберите "Создать группу действий".

   

2. На вкладке Основные сведения введите следующие данные:

   • Подписка и группа ресурсов: выберите место для хранения группы действий.
   • Регион: выберите регион для группы действий.
   • Имя группы действий: введите описательное имя.
   • Отображаемое имя: введите короткое имя (максимум 12 символов), которое отображается в уведомлениях.

3. Нажмите «Далее: уведомления».

4. В разделе " Тип уведомления" выберите "Электронная почта", "SMS-сообщение", "Push/Voice".

5. Введите имя уведомления, например уведомление глобального администратора.

6. Выберите "Изменить сведения", настройте методы уведомлений и контактные данные, а затем нажмите кнопку "ОК".

7. Добавьте любые другие уведомления, которые вы хотите активировать.

8. Нажмите кнопку "Далее": действия для настройки любых дополнительных автоматических действий или нажмите кнопку "Проверить и создать ", чтобы завершить работу.

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

Если оповещение активируется, сохраните журналы из Microsoft Entra и других рабочих нагрузок. Провести проверку обстоятельств и результаты использования учетной записи аварийного доступа. Эта проверка определяет, использовалась ли учетная запись:

• Для запланированного учения с целью проверки его пригодности
• В ответ на фактические чрезвычайные ситуации, когда администратор не мог использовать свои обычные учетные записи
• В результате неправильного использования или несанкционированного использования учетной записи

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

Регулярная проверка учетных записей

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

• Убедитесь, что сотрудники по мониторингу безопасности знают, что действие проверки учетных записей продолжается.
• Просмотрите и обновите список лиц, авторизованных для использования учетных данных учетной записи аварийного доступа.
• Убедитесь, что процесс экстренного использования этих учетных записей документирован и актуален.
• Убедитесь, что администраторы и сотрудники службы безопасности, которым может потребоваться выполнить эти действия в случае чрезвычайной ситуации, прошили соответствующее обучение.
• Убедитесь, что учетные записи для аварийного доступа могут входить в систему и выполнять административные задачи.
• Убедитесь, что пользователи не зарегистрировали многофакторную проверку подлинности или самостоятельный сброс пароля (SSPR) на устройство или персональные данные отдельного пользователя.
• Если учетные записи зарегистрированы для многофакторной проверки подлинности на устройстве, для использования во время входа или активации ролей убедитесь, что устройство доступно всем администраторам, которым может потребоваться использовать его во время чрезвычайной ситуации. Также убедитесь, что устройство может передавать данные по крайней мере по двум сетевым путям, которые не имеют общего режима отказа. Например, устройство может осуществлять связь с Интернетом через беспроводную сеть объекта и через сеть сотового оператора.
• Регулярно меняйте кодовые комбинации на всех сейфах, а также после ухода из организации любого сотрудника, имевшего к ним доступ.

Выполните следующие действия с регулярными интервалами и для внесения ключевых изменений:

• По крайней мере каждые 90 дней.
• При недавнем изменении ИТ-персонала, например после прекращения или изменения должности
• При изменении подписок Microsoft Entra в организации

Следующие шаги

• Как убедиться, что пользователи настроены для обязательной многофакторной проверки подлинности
• Требовать фишинговую многофакторную проверку подлинности для администраторов
• Защита привилегированного доступа для гибридных и облачных развертываний в идентификаторе Microsoft Entra
• Настройте дополнительные средства защиты для привилегированных ролей в Microsoft 365, если вы используете Microsoft 365
• Запустите проверку доступа привилегированных ролей и переключите существующие назначения привилегированных ролей на более конкретные роли администратора.

Связанный контент

• Создание устойчивой стратегии управления доступом
• Операции безопасности для привилегированных учетных записей
• Планирование развертывания привилегированного управления удостоверениями
• Планирование развертывания условного доступа
• Элементы управления доступом HIPAA
• Что следует учитывать клиентам Microsoft Entra в рамках DORA