Инциденты Microsoft Defender XDR в Jira Service Management
Разбираем источники Microsoft Defender XDR, очередь Jira, приоритеты, обязательные поля и ответственных. Выбираем понятный маршрут инцидента. Регистрируем приложение Microsoft Entra ID, согласуем SecurityIncident.Read.All и проверяем получение incidents через Microsoft Graph v1.0.
Когда стоит обратиться
Обычно к нам обращаются в таких ситуациях:
- ИБ-команда отслеживает Defender Portal, а задачи для системных администраторов и владельцев сервисов вручную создаёт в Jira Service Management.
- Приоритет киберинцидента в Jira зависит от того, кто переносил карточку, поэтому критичные события получают разный маршрут и срок реакции.
- Скрипт использует устаревающий legacy alerts API Microsoft Graph, хотя Microsoft переводит интеграции на alerts_v2 и incidents.
Что именно мы сделаем
Разбираем источники Microsoft Defender XDR, очередь Jira, приоритеты, обязательные поля и ответственных. Выбираем понятный маршрут инцидента.
Регистрируем приложение Microsoft Entra ID, согласуем SecurityIncident.Read.All и проверяем получение incidents через Microsoft Graph v1.0.
Подключаем Jira Service Management REST API, сопоставляем severity, status, displayName, summary, incidentWebUrl и нужные данные связанных alerts.
Настраиваем создание и обновление одной карточки по идентификатору Defender, хранение отметки времени, пагинацию, журнал и повтор после сбоя.
Проверяем новый инцидент, изменение severity и status, повторное получение, временную ошибку API и переход по ссылке между системами.
Что входит в стоимость
44 900 ₽ за всю работу
Подключаем актуальный Microsoft Graph security API и Jira Service Management REST API. Получаем incidents Microsoft Defender XDR по расписанию, сохраняем идентификатор, severity, status, summary, ссылку и доступные связанные alerts. Сопоставляем уровни с приоритетами Jira, выбираем проект и тип запроса, настраиваем создание и обновление карточки. Добавляем защиту от дублей, постраничное получение, контроль последнего обновления, журнал, повторы и удобную ссылку между системами.
Что будет готово
Передадим вам
- Рабочая передача incidents Microsoft Defender XDR в Jira Service Management.
- Карта полей, приоритетов, статусов и правил обновления связанной заявки.
- Журнал обмена, протокол контрольных сценариев и инструкция для ИБ- и ИТ-команды.
Перед сдачей проверим
- Контрольный incident Microsoft Defender создаёт заявку Jira с правильным приоритетом, описанием и ссылкой на Defender Portal.
- Изменение severity, summary или status обновляет связанную карточку по внешнему идентификатору.
- Повторное получение того же incident сохраняет одну заявку, а обработанные изменения и ошибки отражаются в журнале.
Как это выглядит на практике
Defender передаёт критичный инцидент дежурной команде
Типичная ситуация: ИБ-команда отслеживает Defender Portal, а задачи для системных администраторов и владельцев сервисов вручную создаёт в Jira Service Management. Сначала Microsoft Defender XDR объединяет связанные срабатывания в инцидент высокой важности, затем интеграция получает incident через Microsoft Graph и создаёт заявку в очереди безопасности Jira, а в финале Jira назначает SLA и ответственного по действующим правилам проекта.
- 01
Microsoft Defender XDR объединяет связанные срабатывания в инцидент высокой важности.
- 02
Интеграция получает incident через Microsoft Graph и создаёт заявку в очереди безопасности Jira.
- 03
Jira назначает SLA и ответственного по действующим правилам проекта.
- 04
После обновления расследования карточка получает новый статус, краткое описание и ссылку на актуальный контекст Defender.
Что понадобится для работы
От вас
- Тенант Microsoft с активными источниками Defender XDR и incidents для контрольной проверки.
- Приложение Microsoft Entra ID с application permission SecurityIncident.Read.All и административным согласием.
- Проект Jira Service Management, сервисная учётная запись, тип заявки, приоритеты, статусы и обязательные поля.
Если у вас немного другая ситуация
Небольшие уточнения, которые помогают довести согласованный результат до рабочего состояния, уже учитываем в цене. Если по ходу работы появится отдельный крупный блок или понадобится платная лицензия, сначала обсудим варианты и стоимость. Расскажите о своей ситуации — подстроим план под неё.
- 3 000 ₽после подписания договора через Диадок
- 41 900 ₽после выполнения, демонстрации и приёмки результата
Предоплата входит в общую стоимость. Оставшуюся сумму оплачиваете после демонстрации и приёмки готовой работы.
Часто спрашивают
Об этой услуге
Какие продукты Microsoft попадают в incidents API?
Microsoft Graph объединяет инциденты из Microsoft 365 Defender, включая Defender for Endpoint, Identity, Office 365, Cloud Apps и другие поддерживаемые источники безопасности.
Почему используется incidents API вместо старого alerts API?
Microsoft объявила завершение legacy alerts API 31 августа 2026 года и рекомендует актуальные alerts_v2 и incidents. Инцидент уже объединяет связанные срабатывания и удобнее для сервисной заявки.
Можно передавать затронутые устройства и пользователей?
Да. Получим доступные связанные alerts через expand и вынесем полезные объекты в описание или структурированные поля Jira с учётом разрешений тенанта.
Какие права нужны в Jira?
Сервисной учётной записи нужны доступ к нужному проекту, создание и изменение заявок, комментариев и согласованных полей. Подготавливаем точный перечень под вашу схему.
Цена и изменения по ходу работы
Цена на странице окончательная?
Да. Перед началом мы сверяем исходные данные и фиксируем результат в договоре. Указанная на странице сумма покрывает согласованную работу целиком, даже если её техническая реализация потребует больше времени, чем ожидалось при оценке.
Что означает резерв незапланированных работ?
Это уже включённый в цену запас времени на небольшие связанные уточнения заказчика, которые появляются после старта: например, добавить поле, изменить формат уведомления или учесть ещё одно условие обработки.
Резерв рассчитывается по формуле: стоимость услуги × 30% ÷ 1 500 ₽. Для услуги за 30 000 ₽ это 6 часов. Эти часы относятся только к дополнительным, заранее незапланированным уточнениям. Они не являются сроком проекта и не ограничивают время на основную работу: согласованный результат мы выполняем полностью.
Можно уточнять детали уже во время работы?
Да. Небольшие связанные изменения обычно помещаются во включённый резерв и не требуют доплаты. Если новая идея заметно меняет результат или превращается в самостоятельную задачу, сначала обсудим подход и стоимость. Любое решение согласуем до выполнения.
Начало работы и оплата
Как оформляются договор и оплата?
Подписываем договор через Диадок. Предоплата составляет 3 000 ₽ и входит в общую стоимость услуги. Остаток оплачивается после демонстрации и приёмки готового результата.
Когда начинается срок выполнения?
Срок отсчитывается после согласования задачи, получения необходимых доступов и материалов, подписания договора и поступления предоплаты. Конкретную дату старта и плановый день готовности подтверждаем перед началом.
Как учитываются платные лицензии и внешние сервисы?
До старта проверяем, нужны ли тарифы, лицензии, сертификаты или дополнительные ресурсы внешних систем. Если они потребуются, заранее покажем варианты и стоимость. По возможности аккаунты и лицензии оформляются сразу на заказчика.
Проверка результата и гарантия
Как принимается готовая работа?
Вместе проверяем согласованные сценарии на контрольных данных или тестовой копии, а затем демонстрируем результат. Для интеграций сверяем передачу данных и обработку ошибок, для сайта — работу нужных страниц и действий пользователя, для отчёта — расчёты и обновление данных.
Какая гарантия действует после сдачи?
На выполненные изменения действует гарантия 3 месяца. Если в изменённой нами части обнаружится ошибка нашей реализации, проверим и исправим её без дополнительной оплаты. Переданные материалы, настройки и код остаются у заказчика.