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

  • 16 мин

Анализ риска.

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

Все три отчета позволяют скачивать события в формате CSV для дальнейшего анализа за пределами портала Azure. В отчете о пользователях, совершающих рискованные действия, и рискованных входах можно загружать последние 2500 записей, а в отчете об обнаружении рисков — последние 5000 записей.

Организации могут воспользоваться преимуществами интеграции API Microsoft Graph для агрегирования данных с другими источниками, к которым у них есть доступ к организации.

Вы можете найти три отчета в Центре администрирования Microsoft Entra, а затем identity, а затем Protection — Identity Protection.

Каждый отчет содержит список всех обнаружений за период, показанный в верхней части отчета. Каждый отчет допускает добавление или удаление столбцов в зависимости от предпочтений администратора. Администраторы могут выбрать загрузку данных в формате CSV или JSON. С помощью фильтров в верхней части отчета можно фильтровать данные в отчете.

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

Выбор отдельных записей расширяет окно сведений под обнаружением. Детальный вид позволяет администраторам исследовать и выполнять действия при каждом обнаружении.

Снимок экрана: отчет по защите идентификации, где отображаются рискованные входы и сведения о них.

Пользователи, выполняющие рискованные действия

Информация, доступная в отчете о пользователях, выполняющих рискованные действия, поможет администратору найти следующие сведения:

  • какие пользователи являются рискованными, были ли риски исправлены или отклонены?
  • детальные сведения об обнаружении;
  • все рискованные входы;
  • журнал рисков.

Затем администраторы могут предпринять действия с этими событиями. Учащиеся могут по выбору:

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

Вход, представляющий риск

Отчет о рискованных входах содержит фильтруемые данные за последние 30 дней (1 месяц).

Информация, доступная в отчете о пользователях, выполняющих рискованные входы в систему, поможет администратору найти следующие сведения:

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

Затем администраторы могут предпринять действия с этими событиями. Администраторы могут:

  • подтвердить компрометацию входа;
  • подтвердить безопасный вход.

Обнаружения рисков

Отчет об обнаружении потенциальных рисков содержит фильтруемые данные за последние 90 дней (3 месяца).

Информация, доступная в отчете об обнаружении рисков, поможет администратору найти следующие сведения:

  • сведения о каждом обнаружении рисков, включая тип.
  • другие риски, активированные в то же время;
  • расположение попытки входа.

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

Отчет об обнаружении рисков также содержит активную ссылку на обнаружение на портале Microsoft Defender для облачных приложений (MDCA), где можно просмотреть дополнительные журналы и оповещения.

Примечание.

Наша система обнаруживает, что событие риска, которое способствовало оценке риска пользователя, было ложным положительным или что риск пользователя был исправлен с применением политики, например завершение запроса MFA или безопасного изменения пароля. Таким образом, наша система закроет состояние риска, а сведения о риске "ИИ подтвердил безопасный вход" станут известны и больше не будут вноситься в риск пользователя.

Устранение рисков и разблокирование пользователей

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

Серверы

Все активные обнаружения рисков участвуют в вычислении значения, называемого уровнем риска для пользователя. Уровень риска для пользователя является индикатором (низким, средним, высоким) вероятности того, что учетная запись была скомпрометирована. Администраторам нужно закрывать все обнаружения рисков, чтобы затронутые пользователи больше не подвергались риску.

Некоторые обнаружения рисков помечаются защитой идентификации как "Закрытая (система)", так как события больше не были определены как рискованные.

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

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

Самостоятельное исправление с политикой рисков

Если вы разрешаете пользователям самостоятельно устранять неполадки с многофакторной проверкой подлинности (MFA) и самостоятельным сбросом пароля (SSPR) в политиках риска, они могут разблокировать себя при обнаружении риска. В таком случае эти обнаружения считаются закрытыми. Пользователи должны ранее зарегистрированы для MFA и SSPR, чтобы использовать при обнаружении риска.

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

Сброс паролей вручную

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

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

Создание временного пароля — создав временный пароль, можно немедленно вернуть удостоверение в безопасное состояние. Этот способ требует обращения к затронутым пользователям, так как им нужно знать временный пароль. Так как пароль является временным, при следующем входе пользователю предлагается сменить пароль на новый.

Требование от пользователя сбросить пароль — требование сброса пароля от пользователей позволяет включить самостоятельное восстановление без обращения в службу технической поддержки или к администратору. Этот метод применяется только к пользователям, зарегистрированным для MFA и SSPR. Незарегистрированным пользователям этот параметр недоступен.

Закрыть уведомление о риске для пользователя

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

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

Закрытие отдельных обнаружений рисков вручную

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

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

  • подтвердить компрометацию пользователя;
  • Отклонение риска пользователей.
  • подтвердить безопасный вход.
  • подтвердить компрометацию входа.

Разблокировка пользователей

Администратор выбирает блокировку входа на основе политики риска или расследований. Блок возникает на основе риска входа или пользователя.

Разблокировка на основании риска пользователя

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

  • Смена пароля. Вы можете сбросить пароль пользователя.
  • Закрытие уведомления о риске для пользователя. Политика рисков пользователей блокирует пользователя при достижении заданного уровня риска для пользователя. Чтобы снизить уровень риска для пользователя, можно закрыть уведомление о риске для пользователя или вручную закрыть переданные обнаружения рисков.
  • Исключение пользователя из политики. Если вы считаете, что текущая конфигурация политики входа вызывает проблемы у конкретных пользователей, можно исключить из нее пользователей.
  • Отключение политики. Если вы считаете, что конфигурация политики является причиной проблем всех пользователей, то ее можно отключить.

Разблокировка на основании риска при входе

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

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

Предварительная версия PowerShell

Используя модуль предварительной версии пакета SDK для Microsoft Graph PowerShell, организации могут управлять рисками с помощью PowerShell. Модули предварительной версии и пример кода находятся в репозитории Azure GitHub.

Использование API Microsoft Graph

Microsoft Graph — это конечная точка единого API Майкрософт и домашняя страница API защиты идентификации Microsoft Entra. Существует три API, которые предоставляют информацию о совершающих рискованные действия пользователях и рискованных входах: riskDetection, riskyUsers, and signIn.

riskDetectionпозволяет запрашивать Microsoft Graph для списка связанных обнаружения рисков пользователя и входа в систему и связанных сведений об обнаружении.

riskyUsersпозволяет запрашивать Microsoft Graph сведения о пользователях, которые защита удостоверений обнаружена как рискоемая.

signIn позволяет запрашивать Microsoft Graph сведения о входе в систему Идентификатора Microsoft Entra с определенными свойствами, связанными с состоянием риска, подробными сведениями и уровнем.

Этот раздел знакомит вас с подключением к Microsoft Graph и запросами к этим программным интерфейсам. Дополнительные сведения, полную документацию и доступ к Graph Explorer можно получить на сайте Microsoft Graph (https://graph.microsoft.io/) или по ссылкам на документацию по API-интерфейсам riskDetection, riskyUsers, and signIn.

Подключение к Microsoft Graph

Доступ к данным службы "Защита идентификации" с помощью Microsoft Graph состоит из четырех этапов: получение имени домена, создание регистрации приложения, настройка разрешений API и настройка допустимых учетных данных.

Получение имени домена

  1. Войдите в центр администрирования Microsoft Entra.
  2. Перейдите к удостоверению, а затем откройте параметры и выберите доменные имена.
  3. Запишите домен .onmicrosoft.com. Они понадобятся на последующем шаге.

Создание регистрации приложения

  1. В Центре администрирования Microsoft Entra перейдите к identity and Applications, а затем Регистрация приложений.

  2. Выберите Создать регистрацию.

  3. На странице Создание выполните следующие действия.

    1. В текстовом поле "Имя" введите имя приложения (например, API обнаружения рисков Microsoft Entra).
    2. В разделе Поддерживаемые типы учетных записей выберите тип учетных записей, которые будут использовать API.
    3. Выберите Зарегистрировать.

  4. Скопируйте идентификатор приложения.

Конфигурация разрешений API

  1. В созданном приложении выберите Разрешения API.

  2. На странице Настроенные разрешения на панели инструментов вверху выберите Добавить разрешение.

  3. На странице Добавить доступ через API выберите Выбрать API.

  4. На странице Выбор API выберите Microsoft Graph, а затем нажмите кнопку Выбрать.

  5. Выполните следующие действия на странице Запрос разрешений API.

    1. Выберите Разрешения приложения.
    2. Установите флажки IdentityRiskEvent.Read.All и IdentityRiskyUser.Read.All.
    3. Выберите Добавить разрешения.

  6. Выберите Предоставить согласие администратора для домена.

Настройка допустимых учетных данных

  1. В созданном приложении выберите Сертификаты и секреты.

  2. В разделе Секреты клиента выберите Новый секрет клиента.

    1. Задайте описание для секрета клиента, а также время истечения срока действия согласно политикам организации.

    2. Выберите Добавить.

      Примечание.

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

Проверка подлинности в Microsoft Graph и выполнение запросов с помощью API обнаружения рисков службы "Защита идентификации"

На этом этапе вам понадобятся:

  • имя домена клиента.
  • идентификатор приложения (клиента);
  • секрет клиента или сертификат.

Чтобы выполнить проверку подлинности, отправьте запрос POST по адресу https://login.microsoft.com со следующими параметрами в тексте:

  • grant_type: client_credentials
  • resource: https://graph.microsoft.com
  • client_id:
  • client_secret:

В случае успешного выполнения этот запрос возвращает маркер аутентификации. Для вызова API создайте заголовок со следующим параметром:

Authorization`="<token_type> <access_token>"

При проверке подлинности тип маркера и маркер доступа можно найти в возвращаемом маркере.

Отправьте этот заголовок как запрос по следующему URL-адресу API: https://graph.microsoft.com/v1.0/identityProtection/riskDetections.

В случае успеха ответ представляет собой коллекцию обнаружений рисков идентификации и связанных данных в формате OData JSON, которые можно анализировать и обрабатывать по своему усмотрению.

Пример

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

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

    $ClientID      = "<your client ID here>"        # Should be a ~36 hex character string; insert your info here

    $ClientSecret  = "<your client secret here>"    # Should be a ~44 character string; insert your info here

    $tenantdomain  = "<your tenant domain here>"    # For example, contoso.onmicrosoft.com

    $loginURL      = "https://login.microsoft.com"

    $resource      = "https://graph.microsoft.com"

    $body          = @{grant_type="client_credentials";resource=$resource;client_id=$ClientID;client_secret=$ClientSecret}

    $oauth        = Invoke-RestMethod -Method Post -Uri $loginURL/$tenantdomain/oauth2/token?api-version=1.0 -Body $body

    Write-Output $oauth

    if ($oauth.access_token -ne $null) {

        $headerParams = @{'Authorization'="$($oauth.token_type) $($oauth.access_token)"}

        $url = "https://graph.microsoft.com/v1.0/identityProtection/riskDetections"

        Write-Output $url

        $myReport = (Invoke-WebRequest -UseBasicParsing -Headers $headerParams -Uri $url)

        foreach ($event in ($myReport.Content | ConvertFrom-Json).value) {

            Write-Output $event

        }

    } else {

        Write-Host "ERROR: No Access Token"

    }

Получение всех автономных обнаружений рисков (API riskDetection)

Политики рисков при входе службы "Защита идентификации" позволяют применять условия при обнаружении риска в режиме реального времени. Но что же делать с автономными обнаружениями? Чтобы понять, какие обнаружения являются автономными и, следовательно, не могли активировать политику рискованных входов, можно запросить API riskDetection.

GET https://graph.microsoft.com/v1.0/identityProtection/riskDetections?$filter=detectionTimingType eq 'offline'

Получение списка всех пользователей, успешно прошедших многофакторную проверку подлинности, активированную политикой рискованных входов (API riskyUsers)

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

GET https://graph.microsoft.com/v1.0/identityProtection/riskyUsers?$filter=riskDetail eq 'userPassedMFADrivenByRiskBasedPolicy'