В облачной среде исчезли ресурсы, изменились права или обнаружены неизвестные запросы к ключам. На сервере может не остаться привычных локальных следов, поэтому первые часы расследования зависят от сохранности облачных журналов. Ниже — порядок сбора материалов на примере Microsoft Azure.
Поводом для разбора стала публикация Microsoft от 25 сентября 2026 года об атаке через служебные учётные записи приложений. Это пример, а не описание инцидента «Бизнес-Эксперт» или каждого облачного взлома.
Сначала зафиксируйте границы события
Запишите идентификаторы tenant и подписок, группы ресурсов, имена затронутых сервисов и время первого обнаруженного отклонения. Ведите одну временную шкалу в UTC с указанием источника каждой отметки. Отдельно сохраните список пользователей и приложений, у которых был доступ на момент инцидента, их роли и изменения назначений. Рабочие действия по восстановлению тоже документируйте: они создают новые события и могут смешаться со следами атаки.
Какие журналы нужны
| Источник | Зачем сохранять |
|---|---|
| Azure Activity Log | Операции управления ресурсами: создание, изменение, удаление, попытки и результаты действий, идентификаторы корреляции. |
| Microsoft Entra sign-in logs | Входы служебных учётных записей, приложений и управляемых удостоверений; проверяйте тип учётной записи, статус, IP, время и ресурс. |
| Azure Resource Graph Change Analysis | История изменений свойств ресурсов и сведения об инициаторе там, где они доступны. |
| Журналы конкретных сервисов | Доступ к объектам Storage, Key Vault, базам данных и приложениям — если соответствующая диагностика была включена заранее. |
| Резервные копии и настройки защиты | Состояние точек восстановления, блокировок удаления и изменения политик. |
По документации Microsoft, Activity Log собирает операции управления автоматически, но обычно не содержит чтение данных. Его стандартный срок хранения — 90 дней; для более долгого хранения требуется отдельная настройка экспорта. Отсутствие записи о скачивании в Activity Log поэтому не доказывает, что данные никто не читал. Наличие и срок хранения других журналов нужно проверять в конкретной подписке.
Как сохранить материалы без потери контекста
- Экспортируйте исходные события. Для каждого набора укажите сервис, фильтры, диапазон времени, часовой пояс, учётную запись экспортировавшего и дату выгрузки. Сохраняйте полный набор рядом с рабочей выборкой.
- Сделайте неизменяемую копию. По возможности храните её вне затронутой подписки с ограниченным доступом. Рассчитайте SHA-256 файлов после выгрузки и повторно при передаче; хеш помогает контролировать целостность конкретной копии, но не доказывает истинность самих записей.
- Сопоставьте события. Свяжите идентификаторы служебной учётной записи, входы Entra, операции управления и изменения ресурсов по времени и correlation ID. Microsoft поясняет, что записи входов service principal относятся к приложению, а не к интерактивному входу человека.
- Отмечайте пробелы. Укажите, какие диагностические журналы не были включены, какие сроки хранения истекли и какие сведения доступны только провайдеру. Не подменяйте отсутствующие данные предположениями.
Защита и исследование должны идти вместе
При подтверждённом раскрытии секрета его нужно отозвать или заменить; удаление строки из публичной задачи не делает старый секрет недействительным. Одновременно важно зафиксировать прежние назначения ролей, состояние ресурсов и журналы до изменений. Очерёдность действий определяет команда реагирования с учётом риска продолжающегося доступа.
По вопросам последовательности операций и объёма затронутых данных может потребоваться анализ цифровых данных и расследование инцидента информационной безопасности. Задачу и доступные источники лучше согласовать до истечения сроков хранения облачных журналов.
Сообщите платформу, время обнаружения, затронутые подписки и какие журналы уже сохранены. Поможем определить вопросы и состав материалов для исследования.