Мониторинг работоспособности входа в приложения для обеспечения устойчивости

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

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

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

Во время события влияния может произойти две вещи:

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

Необходимые компоненты

• Клиент Microsoft Entra.
• Пользователь назначил по крайней мере роль администратора безопасности.
• Рабочая область Log Analytics в подписке Azure для отправки журналов в журналы Azure Monitor. Узнайте, как создать рабочую область Log Analytics.
• Журналы Microsoft Entra, интегрированные с журналами Azure Monitor. Узнайте, как интегрировать журналы входа Microsoft Entra с Azure Monitor Stream.

Настройка книги работоспособности входа в приложение

Чтобы получить доступ к книгам в портал Azure, выберите идентификатор Microsoft Entra, выберите книги.

Книги отображаются в разделе "Использование", "Условный доступ" и "Устранение неполадок". Книга о работоспособности входа в приложение отображается в разделе "Работоспособное состояние ". После использования книги она может появиться в разделе "Недавно измененные книги ".

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

На предыдущем снимке экрана два графика:

• Почасовое использование (число успешных пользователей). Сравнение текущего числа успешных пользователей с типичным периодом использования помогает обнаружить падение использования, которое может потребовать исследования. Скорость успешного использования может помочь обнаружить проблемы производительности и использования, которые не удается обнаружить. Например, когда пользователи не могут связаться с приложением, чтобы попытаться войти, возникает падение использования, но нет сбоев. См. пример запроса для этих данных в следующем разделе этой статьи.
• Почасовая частота сбоев. Всплеск частоты сбоев может указывать на проблему с механизмами проверки подлинности. Меры частоты сбоев отображаются только в том случае, если пользователи могут пытаться пройти проверку подлинности. Когда пользователи не могут получить доступ к попытке, отсутствуют сбои.

Настройка запроса и оповещений

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

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

• Успешное использование снижается на 90 % с того же часа два дня назад, как показано в предыдущем примере диаграммы использования почасового использования.
• Частота сбоев увеличивается на 90% от того же часа два дня назад, как показано в предыдущем примере диаграммы частоты сбоев.

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

1. В книге выберите "Изменить ", как показано на следующем снимке экрана. Щелкните значок запроса в правом верхнем углу графа.

   

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

   

3. Скопируйте один из следующих примеров скриптов для нового запроса Kusto.

   • Запрос Azure Data Explorer для увеличения числа неудачных попыток
   • Запрос Azure Data Explorer для уменьшения числа успешных попыток

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

   

5. Выделите запрос. Выберите + Новое правило генерации оповещений.

   

6. Настройте условия оповещения. Как показано на следующем снимке экрана, в разделе "Условие" в разделе "Измерение" выберите строки таблицы для меры. Выберите count for Aggregation type. Выберите 2 дня для детализации агрегирования.

   

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

7. В логике генерации оповещений настройте параметры, как показано на снимке экрана.

   

   • Пороговое значение: 0 Это значение оповещает о любых результатах.
   • Частота оценки: 1 час. Это значение устанавливает частоту оценки: один раз в час за предыдущий час.

8. В разделе "Действия" настройте параметры, как показано на снимке экрана.

   

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

9. В разделе "Сведения" настройте параметры, как показано на снимке экрана примера.

   

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

10. В разделе "Просмотр и создание" настройте параметры, как показано на снимке экрана.

    

11. Выберите Сохранить. Введите имя для запроса. В поле "Сохранить как" выберите "Запрос". Для категории выберите "Оповещение". Снова нажмите кнопку "Сохранить".

    

Уточнение запросов и оповещений

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

• Всегда тестировать оповещения.
• Измените чувствительность и частоту оповещений, чтобы получать важные уведомления. Администраторы могут стать десенсибилизированными для оповещений и пропустить что-то важное, если они получают слишком много.
• В клиентах электронной почты администратора добавьте сообщение электронной почты, из которого оповещения приходят в список разрешенных отправителей. Этот подход предотвращает пропущенные уведомления из-за фильтра нежелательной почты на своих клиентах электронной почты.
• По проектированию запросы оповещений в Azure Monitor могут включать только результаты за последние 48 часов.

Примеры сценариев

Запрос Azure Data Explorer для увеличения числа неудачных попыток

В следующем запросе мы обнаруживаем увеличение частоты сбоев. По мере необходимости можно настроить соотношение в нижней части. Он представляет собой процентное изменение трафика в последний час по сравнению с вчерашним трафиком одновременно. Результат 0,5 указывает на разницу в трафике на 50 %.

let today = SigninLogs
| where TimeGenerated > ago(1h) // Query failure rate in the last hour
| project TimeGenerated, UserPrincipalName, AppDisplayName, status = case(Status.errorCode == "0", "success", "failure")
// Optionally filter by a specific application
//| where AppDisplayName == **APP NAME**
| summarize success = countif(status == "success"), failure = countif(status == "failure") by bin(TimeGenerated, 1h) // hourly failure rate
| project TimeGenerated, failureRate = (failure * 1.0) / ((failure + success) * 1.0)
| sort by TimeGenerated desc
| serialize rowNumber = row_number();
let yesterday = SigninLogs
| where TimeGenerated between((ago(1h) – totimespan(1d))..(now() – totimespan(1d))) // Query failure rate at the same time yesterday
| project TimeGenerated, UserPrincipalName, AppDisplayName, status = case(Status.errorCode == "0", "success", "failure")
// Optionally filter by a specific application
//| where AppDisplayName == **APP NAME**
| summarize success = countif(status == "success"), failure = countif(status == "failure") by bin(TimeGenerated, 1h) // hourly failure rate at same time yesterday
| project TimeGenerated, failureRateYesterday = (failure * 1.0) / ((failure + success) * 1.0)
| sort by TimeGenerated desc
| serialize rowNumber = row_number();
today
| join (yesterday) on rowNumber // join data from same time today and yesterday
| project TimeGenerated, failureRate, failureRateYesterday
// Set threshold to be the percent difference in failure rate in the last hour as compared to the same time yesterday
// Day variable is the number of days since the previous Sunday. Optionally ignore results on Sat, Sun, and Mon because large variability in traffic is expected.
| extend day = dayofweek(now())
| where day != time(6.00:00:00) // exclude Sat
| where day != time(0.00:00:00) // exclude Sun
| where day != time(1.00:00:00) // exclude Mon
| where abs(failureRate – failureRateYesterday) > 0.5

Запрос Azure Data Explorer для уменьшения числа успешных попыток

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

По мере необходимости можно настроить соотношение в нижней части. Он представляет собой процентное изменение трафика в последний час по сравнению с вчерашним трафиком одновременно. Результат 0,5 указывает на разницу в трафике на 50 %. Настройте эти значения, чтобы соответствовать модели бизнес-операций.

Let today = SigninLogs // Query traffic in the last hour
| where TimeGenerated > ago(1h)
| project TimeGenerated, AppDisplayName, UserPrincipalName
// Optionally filter by AppDisplayName to scope query to a single application
//| where AppDisplayName contains "Office 365 Exchange Online"
| summarize users = dcount(UserPrincipalName) by bin(TimeGenerated, 1hr) // Count distinct users in the last hour
| sort by TimeGenerated desc
| serialize rn = row_number();
let yesterday = SigninLogs // Query traffic at the same hour yesterday
| where TimeGenerated between((ago(1h) – totimespan(1d))..(now() – totimespan(1d))) // Count distinct users in the same hour yesterday
| project TimeGenerated, AppDisplayName, UserPrincipalName
// Optionally filter by AppDisplayName to scope query to a single application
//| where AppDisplayName contains "Office 365 Exchange Online"
| summarize usersYesterday = dcount(UserPrincipalName) by bin(TimeGenerated, 1hr)
| sort by TimeGenerated desc
| serialize rn = row_number();
today
| join // Join data from today and yesterday together
(
yesterday
)
on rn
// Calculate the difference in number of users in the last hour compared to the same time yesterday
| project TimeGenerated, users, usersYesterday, difference = abs(users – usersYesterday), max = max_of(users, usersYesterday)
| extend ratio = (difference * 1.0) / max // Ratio is the percent difference in traffic in the last hour as compared to the same time yesterday
// Day variable is the number of days since the previous Sunday. Optionally ignore results on Sat, Sun, and Mon because large variability in traffic is expected.
| extend day = dayofweek(now())
| where day != time(6.00:00:00) // exclude Sat
| where day != time(0.00:00:00) // exclude Sun
| where day != time(1.00:00:00) // exclude Mon
| where ratio > 0.7 // Threshold percent difference in sign-in traffic as compared to same hour yesterday

Создание процессов для управления оповещениями

После настройки запросов и оповещений создайте бизнес-процессы для управления оповещениями.

• Кто отслеживает книгу и когда?
• Когда возникают оповещения, кто исследует их?
• Каковы потребности в обмене информацией? Кто создает связь и кто их получает?
• Когда происходит сбой, какие бизнес-процессы применяются?

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

Дополнительные сведения о книгах