Эта статья содержит ответы на часто задаваемые вопросы о защите идентификаторов Microsoft Entra. Разделы часто задаваемых вопросов: обнаружение, утечка учетных данных, исправление, лицензирование и пользователи B2B.
Дополнительные сведения см. в обзоре защиты идентификаторов Microsoft Entra.
Detections
Как имитировать риск, чтобы понять, почему пользователь получает флаг?
У нас есть руководство по имитации риска. В этом руководстве представлено несколько вариантов имитации различных типов рисков. Вы также можете использовать средство WhatIf условного доступа , чтобы узнать, как применяются определенные политики. We also recommend turning on Conditional Access policies in Report-Only mode to understand how policies work in the tenant without affecting your users' ability to access the resources they need.
Я только что получил оповещение с высоким риском, но они не отображаются в книге "Анализ влияния политик на основе рисков". Why?
Если пользователю назначен высокий риск, но вы еще не вошли в систему, вы не увидите их в этом отчете. В отчете используются только журналы входа для заполнения этих данных.
Что делать, если неверные учетные данные использовались для попытки входа?
Защита идентификаторов создает обнаружение рисков только в том случае, если используются правильные учетные данные. Если неверные учетные данные используются при входе, он не представляет риска компрометации учетных данных.
Требуется ли синхронизация хэша паролей?
Для обнаружения рисков, таких как утечки учетных данных, требуется наличие хэшей паролей. Дополнительные сведения о синхронизации хэша паролей см. в статье "Реализация синхронизации хэша паролей с помощью Службы синхронизации Microsoft Entra Connect".
Почему обнаружения рисков создаются для отключенных учетных записей?
Во-первых, важно знать, что учетные записи пользователей в отключенном состоянии можно повторно изменить. Если учетные данные отключенной учетной записи были скомпрометированы и учетная запись снова включена, злоумышленники смогут использовать эти учетные данные для получения доступа. Защита идентификаторов создает обнаружение рисков подозрительных действий для этих отключенных учетных записей, чтобы предупредить клиентов о потенциальном взломе учетной записи.
Если учетная запись больше не используется и не будет повторно использоваться, клиенты должны рассмотреть возможность удаления учетной записи, чтобы предотвратить компрометацию. Для удаленных учетных записей сигналы риска не создаются.
Я пытался отсортировать отчет об обнаружении рисков с помощью столбца "Время обнаружения", но он не работает.
Sorting by Detection time in the Risk detections report might not always give the correct result because of a known technical constraint. To sort by Detection time, open the report in the Microsoft Entra admin center and select Download to export the data as a CSV file and sort accordingly.
Где Майкрософт находит утечки учетных данных? Как часто они обрабатываются?
Майкрософт находит утечки учетных данных в различных местах, в том числе:
- Общедоступные сайты размещения, где злоумышленники обычно публикуют подобные материалы.
- Правоохранительные органы.
- другие группы в Microsoft, которые занимаются исследованием даркнета.
Утечка учетных данных обрабатывается сразу после их обнаружения, обычно в нескольких пакетах в день.
Почему я не вижу утечки учетных данных?
Утечки учетных данных обрабатываются всякий раз, когда корпорация Майкрософт находит новый пакет в общественном доступе. Поскольку эти сведения конфиденциальны, утерянные учетные данные удаляются вскоре после обработки. Only new leaked credentials found after you enable password hash synchronization (PHS) are processed against your tenant. Проверка по ранее найденным парам учетных данных не выполняется.
Чтобы узнать, как утечка учетных данных может отображаться в защите идентификаторов клиента, попробуйте симитировать утечку учетных данных в GitHub для удостоверений рабочей нагрузки. Дополнительные сведения см. в разделе "Имитация обнаружения рисков" в Службе защиты идентификаторов Microsoft Entra.
Если вы не видите никаких событий риска утечки учетных данных, это связано со следующими причинами:
- Синхронизация хэша паролей для клиента не включена.
- Корпорация Майкрософт не обнаружила утечки пар учетных данных, соответствующих вашим пользователям.
Remediation
Когда функция автоматического входа в систему защиты идентификаторов рискует без политики на основе рисков?
Защита идентификаторов автоматически выполняет вход, когда пользователь сразу же предоставляет второй фактор, например многофакторную проверку подлинности (MFA) после их рискованного входа. Предоставление этого второго фактора состоит из строгой проверки подлинности.
Защита идентификаторов также работает с двумя моделями для оценки рисков при входе. Первым является модель реального времени, которая использует ограниченную информацию для быстрого определения во время входа. Второй — это автономная модель, которая использует другие данные входа после завершения входа. Автономная модель может закрыть риск, когда она повторно оценивает оценку риска как безопасную. Эта оценка применяется к обнаружению рисков в режиме реального времени и автономном режиме.
Когда функция автоматической защиты идентификаторов рискует пользователем без политики на основе рисков?
Защита идентификаторов автоматически отвечает пользователям с низким риском пользователей после шести месяцев без повышения риска пользователей. Рискованные пользователи с средним или высоким риском не решаются автоматически без политики риска или увольнения администратора.
Что делать, если не использовать Microsoft Entra для многофакторной проверки подлинности?
Если вы не используете многофакторную проверку подлинности Microsoft Entra, в вашей среде может по-прежнему появиться риск входа, если вы используете поставщик MFA, отличный от Майкрософт. Внешние методы проверки подлинности позволяют устранить риск при использовании поставщика MFA, отличного от Майкрософт.
Каковы лучшие элементы управления условным доступом для учетных записей без пароля?
Ознакомьтесь с нашим руководством по развертыванию фишинговой проверки подлинности без пароля: начало работы с фишинговым развертыванием без пароля
Следует ли добавить "Принудительное применение частоты входа — каждый раз" в наши политики условного доступа для высокого риска?
Этот параметр зависит от допустимости риска вашей организации. Некоторые организации могут заблокировать высокий риск. Принудительное выполнение входа при каждом входе может привести к усталости входа или MFA, что может увеличить вероятность фишинговой атаки.
We also recommend turning on Conditional Access policies in Report-Only mode to understand how policies work in the tenant without affecting your users' ability to access the resources they need. Вы также можете проверить анализ влияния книги политик на основе рисков в службе защиты идентификаторов.
Что делать, если я в гибридной среде?
Риск пользователя может быть самостоятельно устранен с помощью безопасного изменения пароля, если самостоятельный сброс пароля включен с помощью обратной записи паролей. Если включена только синхронизация хэша паролей, рекомендуется разрешить локальный сброс пароля для устранения риска пользователей.
Дополнительные сведения см. в разделе "Устранение рисков и разблокировка пользователей".
Если развернуть политику риска, система автоматически ремедиативирует пользователей по-разному или переделывать прошлые исправления?
Система использует элементы управления предоставлением, указанные в политике условного доступа для всех исправлений. Этот подход, управляемый политикой, позволяет более контролировать доступ к ресурсам. Если для политики риска пользователя требуется блокировка, условный доступ применяет это. Если для политики риска входа требуется многофакторная проверка подлинности, условный доступ применяет новую задачу MFA (если для существующего токена не задано утверждение MFA). Таким образом, если Алиса всегда имела ее рискованные входы автоматически, благодаря другой политике MFA, ничего не изменится при развертывании политики риска, требующей многофакторной проверки подлинности.
Licensing
Какая лицензия необходима для использования защиты идентификаторов Microsoft Entra?
Существует несколько возможностей в защите идентификаторов Microsoft Entra, требующих различных лицензий. Например, можно получить ограниченную информацию в отчете о рискованных входах с помощью бесплатной лицензии Microsoft Entra ID, но вы получаете полный доступ к этим отчетам с помощью лицензии Microsoft Entra ID P2 или microsoft Entra Suite. Дополнительные сведения см. в разделе о требованиях к лицензии защиты идентификаторов Microsoft Entra.
Защита идентификаторов Microsoft Entra также использует сигналы от продуктов Microsoft Defender, лицензированных отдельно. Дополнительные сведения см. в разделе "Что такое Защита идентификации Microsoft Entra?".
B2B users
Почему я не могу исправить пользователей группы риска из службы совместной работы B2B в моем каталоге?
Оценка рисков и исправление для пользователей B2B происходит в домашнем каталоге, поэтому гостевые пользователи не отображаются в отчете о рискованных пользователях в каталоге ресурсов. Администраторы в каталоге ресурсов не могут принудительно выполнить безопасный сброс пароля для этих пользователей.
Что делать, если пользователь службы совместной работы B2B был заблокирован из-за политики на основе рисков в моей организации?
Если рискованный пользователь B2B в вашем каталоге заблокирован политикой на основе рисков, ему необходимо устранить этот риск в своем домашнем каталоге. Пользователи могут устранить свой риск, выполнив безопасный сброс пароля в домашнем каталоге. Если у них нет возможности самостоятельного сброса пароля в домашнем каталоге, необходимо связаться с ИТ-персоналом своей организации, чтобы администратор вручную снял риск или сбросил их пароль. Дополнительные сведения см. в разделе "Исправление риска пользователей".
Как запретить политикам на основе рисков влиять на пользователей совместной работы B2B?
Исключение пользователей B2B из политик условного доступа на основе рисков вашей организации запрещает пользователям B2B влиять на оценку рисков. Чтобы исключить этих пользователей B2B, создайте группу в идентификаторе Microsoft Entra, которая содержит всех гостевых пользователей вашей организации. Затем добавьте эту группу в качестве исключения для встроенных политик риска для пользователей защиты идентификаторов и политик риска входа, а также всех политик условного доступа, использующих риск входа в качестве условия.