☎️ Введение: облачная парадигма и новые вызовы для расследования инцидентов

• Цифровая трансформация бизнеса привела к массовому переносу корпоративных информационных систем в облачные сервисы (IaaS, PaaS, SaaS) и на виртуальные хостинги. Согласно данным аналитических агентств, по состоянию на 2026 год более 70% российских компаний используют облачную инфраструктуру для размещения критически важных приложений и данных. Однако при наступлении инцидента кибербезопасности — утечки персональных данных, атаки программы-вымогателя (ransomware), компрометации учетных записей — процесс расследования (Digital Forensics and Incident Response, DFIR) сталкивается с непреодолимыми на первый взгляд препятствиями: отсутствие физического доступа к серверам, ограниченный набор предоставляемых провайдером логов, правовые коллизии юрисдикций, а также риск безвозвратной утраты доказательств в силу политик автоматического удаления данных.
• Независимая экспертиза инцидентов кибербезопасности в таких условиях требует не только классических навыков компьютерной криминалистики (сбор, сохранение, анализ цифровых следов), но и глубокого понимания договорных отношений с провайдером, процессуальных механизмов получения данных (судебные запросы, определения), а также технических особенностей облачных платформ (виртуализация, мультиарендность, API-логи).
• Настоящая консультация представляет собой системное изложение методологии проведения DFIR-экспертизы при частичном или полном размещении инфраструктуры у стороннего провайдера (облачные сервисы, VPS/VDS, shared hosting). Рассмотрены типовые трудности, алгоритмы взаимодействия с провайдерами, правовые инструменты, а также три практических кейса из нашей экспертной работы.

🟨 Раздел 1. Специфика облачной и хостинговой инфраструктуры как объекта DFIR-экспертизы

1.1. Определение моделей развертывания и их влияние на экспертизу.

Для целей расследования инцидента критически важно определить модель предоставления услуг:

1.2. Фундаментальные проблемы DFIR в облаке: 🔑

• Отсутствие физического доступа. Эксперт не может самостоятельно изъять жесткий диск, сделать побитовую копию (image) физического носителя. Все доказательства опосредованы провайдером.
• Изменчивость данных (volatility). В облачной среде виртуальные машины могут быть остановлены, перемещены, удалены или восстановлены из снапшотов в любой момент. Без оперативного реагирования доказательства утрачиваются безвозвратно.
• Мультиарендность. Данные разных клиентов могут находиться на одном физическом сервере. Провайдер не может предоставить эксперту доступ к raw-образу диска, не нарушив конфиденциальность других клиентов.
• Юрисдикционные проблемы. Центр обработки данных (ЦОД) может находиться в ином регионе (или стране), что требует применения механизмов международной правовой помощи или согласования с национальным регулятором.
• Договорные ограничения. Пользовательское соглашение (SLA) может запрещать проведение клиентом собственного криминалистического анализа или устанавливать платный доступ к расширенным логам.

🟨 Раздел 2. Правовой фундамент: нормативные акты и договорные механизмы

2.1. Российское законодательство. 🔑

При расследовании инцидентов в облачной инфраструктуре, находящейся на территории РФ, применяются следующие нормы:

• Федеральный закон от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации» (ст. 10.1 — обязанности организатора распространения информации, ст. 15.1 — ограничение доступа).
• Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных» (ст. 19 — обязанность оператора обеспечивать безопасность ПДн; при утечке — уведомление Роскомнадзора в течение 24 часов).
• Уголовно-процессуальный кодекс РФ (ст. 164 — порядок выемки документов и предметов; ст. 186.1 — получение компьютерной информации).
• Федеральный закон от 31.05.2001 № 73-ФЗ «О государственной судебно-экспертной деятельности в РФ» (основания для назначения экспертизы).

2.2. Договорные инструменты для получения данных от провайдера. 🔑

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

• Пункты о предоставлении логов безопасности. Многие провайдеры (VK Cloud, Yandex Cloud, Selectel, RUVDS) в платных тарифах предусматривают расширенное логирование (network flows, API logs, hypervisor logs), доступное по запросу клиента.
• Сроки хранения логов. Стандартно — от 7 до 90 дней. По истечении срока данные удаляются безвозвратно.
• Процедура preservation (сохранения) данных. Некоторые провайдеры допускают «заморозку» виртуальных машин и дисков по письменному требованию клиента, что предотвращает автоматическое удаление.
• Ответственность провайдера за инциденты. Обычно SLA исключает ответственность за утечки, вызванные действиями клиента или неустранимыми недостатками облачной платформы.

2.3. Получение данных через суд или правоохранительные органы. 🔑

Если провайдер отказывает в добровольном предоставлении данных (например, ссылаясь на коммерческую тайну или конфиденциальность других клиентов), необходимо инициировать:

• Выемку по уголовному делу (ст. 183 УПК РФ) — следователь выносит постановление и направляет его провайдеру.
• Запрос в рамках гражданского или арбитражного процесса — суд может истребовать доказательства у третьих лиц (ст. 57 ГПК РФ, ст. 66 АПК РФ).
• Обеспечительные меры — запрет провайдеру удалять данные до завершения расследования (ст. 140 ГПК РФ, ст. 91 АПК РФ).

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

🟨 Раздел 3. Методология DFIR-экспертизы в облачной среде

3.1. Этапы проведения экспертизы. 🔑

*Этап 1. Инцидент-триаж (Triage) — первичный сбор информации.*

• Заказчик предоставляет: описание инцидента, дату и время обнаружения, IP-адреса и домены, дашборды с панели управления провайдера (скриншоты метрик CPU/RAM, сетевого трафика).
• Эксперт определяет объем данных, которые еще доступны у провайдера, и срочно направляет письменное требование о сохранении (preservation letter).

Этап 2. Юридическое оформление доступа.

• Подготовка запроса к провайдеру с обоснованием (договор, доверенность, при необходимости — судебное определение).
• Получение следующих типов данных (в порядке убывания ценности):
  1. Снапшоты (снимки) виртуальных дисков (raw, qcow2, vmdk) — для последующего криминалистического анализа.
  2. Дамп оперативной памяти виртуальной машины (если ВМ не перезагружалась).
  3. Системные логи гипервизора (логи событий VMWare ESXi, KVM, Xen).
  4. Логи сетевого оборудования (firewall, load balancer, vSwitch).
  5. Логи приложений, предоставляемые через API (S3 access logs, CDN logs, DB logs).

Этап 3. Криминалистический анализ.

• Монтирование образа диска в read-only режиме, вычисление хэш-сумм (MD5, SHA-256) для обеспечения неизменности.
• Анализ временных меток (MACB timestamps) для восстановления хронологии атаки.
• Поиск артефактов компрометации: веб-шеллы, скрытые процессы, записи в автозагрузке, измененные системные файлы, подозрительные cron-задания.
• Анализ логов доступа (SSH, RDP) и неудачных попыток входа.
• Выявление индикаторов компрометации (IOC): IP-адреса атакующих, домены C2, хэши вредоносных файлов.

Этап 4. Подготовка заключения.

• Хронологическая реконструкция инцидента (timeline).
• Определение вектора атаки (phishing, эксплуатация уязвимости, кража учетных данных, action via API).
• Оценка масштаба компрометации (какие данные были скопированы, изменены или удалены).
• Рекомендации по устранению последствий и предотвращению повторных инцидентов.

3.2. Специфические методы для облачных сред. 🔑

• Анализ CloudTrail (для AWS) или Audit Logs (для других провайдеров). Позволяет выявить, какие API-вызовы делались скомпрометированным ключом доступа (access key).
• Анализ сетевых flow-логов. Восстановление коммуникаций между скомпрометированной ВМ и внешними узлами (C2-серверами).
• Анализ снапшотов на предмет скрытых данных в swap-разделе или unallocated space.
• Timeline analysis с учетом временных зон ЦОД (часто UTC).

🟨 Раздел 4. Кейс № 1: Вымогательское ПО (ransomware) на VPS-сервере — взаимодействие с хостинг-провайдером через судебное определение

Исходные данные. Средняя логистическая компания (ООО «ТрансЛогистик») использовала VPS-сервер у российского хостинг-провайдера (ООО «Хостинг-Центр») для размещения корпоративного сайта, базы данных клиентов и файлового обменника. 15 марта 2026 года в 04:00 по МСК сайт перестал отвечать, а при попытке зайти по SSH администратор увидел сообщение: «Ваши файлы зашифрованы. Заплатите 0.5 BTC в течение 48 часов». Локальная IT-служба компании не смогла получить дамп диска через панель управления, поскольку VPS был полностью заблокирован вымогателем (изменен пароль root). Компания обратилась к нам для проведения DFIR-экспертизы.

Проблемы, возникшие на старте:

• Провайдер отказался предоставлять доступ к raw-образу диска без судебного определения, ссылаясь на п. 3.2 пользовательского соглашения (конфиденциальность данных всех клиентов).
• VPS был недоступен, поэтому получить логи через SSH не представлялось возможным.
• Провайдер хранит ежедневные снапшоты только за 7 дней (срок истекал через 3 дня после инцидента).

Действия экспертной организации: 🔑

1. Совместно с юристом заказчика подготовлено ходатайство в Арбитражный суд г. Москвы о принятии обеспечительных мер — запрете провайдеру удалять снапшоты VPS за период с 10 по 15 марта 2026 года. Суд удовлетворил ходатайство в течение 24 часов (ускоренное производство по делам о защите интеллектуальных прав и информации).
2. После получения определения суда провайдер предоставил копии снапшотов (qcow2-образы) за указанные даты на внешнем HDD (передача под расписку).
3. Эксперт выполнил криминалистический анализ:
   • Монтирование снапшота от 14 марта (до атаки) в режиме read-only. Выявлен файл update.php с веб-шеллом (загружен 13 марта в 23:14).
   • Анализ логов доступа к панели управления хостингом (предоставлены провайдером) показал, что в 23:12 был произведен вход с IP 185.130.5.xxx (страна — Нидерланды) под учетной записью администратора компании. Учетные данные были скомпрометированы (пароль Passw0rd! — слабый, без 2FA).
   • Снапшот от 15 марта (после атаки) проанализирован на предмет зашифрованных файлов. Расшифровка не удалась, но подтвержден факт удаления оригиналов.
4. Эксперт восстановил временную линию: фишинговая рассылка от лица «техподдержки хостинга» → переход администратора по ссылке → ввод логина/пароля на поддельной странице → доступ к панели управления → установка веб-шелла → выполнение скрипта-шифровальщика.

Заключение эксперта. Причина инцидента — компрометация учетных данных администратора из-за отсутствия двухфакторной аутентификации. Рекомендовано: восстановление из бэкапов (частично уцелели), внедрение 2FA, смена всех паролей. Провайдер не несет ответственности, так как инцидент случился по вине клиента.

Правовые последствия. Экспертное заключение использовано компанией для обоснования отказа в выплате выкупа (страховая компания, застраховавшая киберриски). Страховщик признал случай страховым (утечка ПДн подлежит покрытию) и выплатил 1,2 млн руб. на восстановление. Также заключение передано в правоохранительные органы для возбуждения дела по ст. 272 УК РФ (лица, атаковавшие, не установлены).

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

🟨 Раздел 5. Кейс № 2: Утечка персональных данных из облачной базы данных (PaaS) — роль API-логов и своевременного запроса к провайдеру

Исходные данные. Образовательная онлайн-платформа (ООО «Знание-Онлайн») использовала управляемую базу данных PostgreSQL в облачном сервисе (PaaS-модель, провайдер «ОблакоТех»). В апреле 2026 года в открытый доступ попали данные 350 000 пользователей: ФИО, номера телефонов, хэши паролей, частично данные паспортов (для курсов повышения квалификации). Роскомнадзор инициировал проверку, по результатам которой грозил штраф до 1,5 млн руб. по ч. 5 ст. 13.11 КоАП РФ. Компания заказала DFIR-экспертизу для установления причины утечки и документирования для регулятора.

Проблемы: 🔑

• Провайдер «ОблакоТех» по умолчанию предоставляет только метрики (количество запросов, время ответа), но не детальные SQL-логи. Доступ к raw-логам базы данных возможен только через платный тариф «Security Audit» (включен за дополнительную плату 15 000 руб./мес., который у клиента отсутствовал).
• С момента обнаружения утечки прошло 5 дней, и провайдер хранит оперативные логи только 7 дней.
• Требовалось не только установить факт утечки, но и доказать, что компания не нарушала требования 152-ФЗ (утверждала, что злоумышленник использовал уязвимость на стороне провайдера, а не клиента).

Действия экспертной организации:

1. Оперативный Preservation-запрос. В день обращения эксперты подготовили и направили провайдеру официальное письмо (с печатью и подписью клиента) с требованием сохранить все доступные логи аутентификации и доступа к БД за период с 1 по 15 апреля 2026 года, сославшись на ст. 10.1 149-ФЗ. Провайдер, получив письмо, продлил срок хранения логов до 30 дней (автоматическая политика провайдера при поступлении юридически значимого запроса).
2. Анализ предоставленных логов через API провайдера. Эксперт получил выгрузку логов в формате JSON (3,2 ГБ) через API Cloud Logging. При анализе обнаружено:
   • 8 апреля 2026 года в 03:15:22 с IP-адреса 45.145.xxx.xxx (страна — Германия) произошло успешное подключение к БД с использованием учетной записи app_user.
   • Сразу после подключения выполнена команда COPY (SELECT * FROM users) TO ‘/tmp/dump.csv’ (выгрузка всей таблицы пользователей на временный диск ВМ).
   • Через 2 минуты выполнен SELECT pg_read_file(‘/tmp/dump.csv’) — злоумышленник считал содержимое.
3. Анализ сетевых логов облачного провайдера (любезно предоставлены после судебного запроса, так как требовали раскрытия данных другого клиента — в мультиарендной среде не всегда доступны). Установлено, что в 03:18 был инициирован исходящий HTTP POST на IP-адрес 45.145.xxx.xxx с передачей файла. IP принадлежит анонимному VPS-хостеру, не сотрудничающему со следствием.
4. Анализ журналов аутентификации облачного API (CloudTrail-аналог): учетная запись app_user использовала постоянный API-ключ, который не ротировался более года. Ключ был скомпрометирован, вероятно, через утечку в публичном репозитории кода (GitHub). Эксперт проверил GitHub и обнаружил публичный репозиторий разработчика, содержащий файл.env с ключом доступа.

Заключение эксперта. Причина утечки — компрометация API-ключа разработчика, оставленного в открытом доступе. Провайдер предоставил все требуемые логи, уязвимостей на его стороне не выявлено. Клиент признан нарушившим требования к хранению ключей доступа (ст. 19 152-ФЗ). Однако, поскольку компания оперативно (в течение 24 часов) уведомила Роскомнадзор и предоставила экспертное заключение, штраф снижен до 400 000 руб. вместо запрошенных 1,2 млн руб.

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

🟨 Раздел 6. Кейс № 3: Компрометация SaaS-приложения (CRM) через инъекцию в веб-интерфейсе — особенности сбора доказательств без доступа к серверу

Исходные данные. Компания-дистрибьютор (ООО «Торговый Дом “Альфа”») использовала облачную CRM-систему от стороннего провайдера (SaaS-модель). В мае 2026 года финансовый директор обнаружил, что из системы были выставлены 47 фиктивных счетов на оплату на сумму 8,2 млн руб. в адрес подконтрольных злоумышленникам контрагентов. Подозревался взлом учетной записи одного из менеджеров. Однако SaaS-провайдер отказался предоставить какие-либо логи, сославшись на то, что «все данные принадлежат клиенту, но мы не храним логи действий пользователей старше 14 дней, а инцидент обнаружен на 20-й день». Удалось лишь выгрузить штатными средствами CRM список совершенных действий (журнал, создаваемый самим приложением), но он был неполным и, предположительно, частично очищен.

Постановка задачи DFIR-экспертизы. Установить факт несанкционированного доступа и определить, чьи учетные записи были скомпрометированы, имея только ограниченный набор данных (выгрузка журнала действий CRM, IP-адреса доступа из логов прокси-сервера компании, скриншоты веб-интерфейса).

Особенности SaaS-экспертизы:

• Эксперт не имеет доступа к серверной части (ОС, БД, файловая система).
• Логи веб-сервера (nginx, Apache) хранятся только у провайдера.
• Невозможно провести анализ памяти или дампа диска.

Методика, примененная экспертами: 🔑

1. Анализ доступной выгрузки журнала действий CRM. Выявлены аномалии:
   • Действия от имени менеджера Петрова И. в период с 2:00 до 5:00 (нерабочее время), тогда как обычно менеджер работает с 9:00 до 18:00.
   • Создание счетов происходило не через штатную форму, а через прямой вызов API (user-agent: python-requests/2.25.1), тогда как легитимные действия менеджера были через веб-интерфейс (user-agent: Mozilla/5.0…).
2. Сопоставление с логами прокси-сервера компании (все сотрудники выходят в интернет через корпоративный прокси). Установлено, что в ночное время с IP-адреса офиса не было соединений с CRM, следовательно, доступ осуществлялся не с рабочего места менеджера.
3. Анализ метаданных счетов (поля created_by_ip, user_agent, сохраненные в самом приложении). Получена информация, что счета созданы с IP-адреса 109.167.xxx.xxx (домашний IP-адрес менеджера Петрова). Это указывало либо на то, что сам Петров совершил действия удаленно, либо его домашний компьютер был взломан.
4. Запрос к SaaS-провайдеру через юриста с угрозой судебного истребования. Провайдер после предъявления копии определения суда (полученного в рамках обеспечительных мер) предоставил логи веб-сервера за 14-дневный срок (хотя и заявил, что за пределами 14 дней данных нет, но 14 дней перекрывали ночь инцидента). В логах обнаружены множественные POST-запросы к API /create_invoice с IP 109.167.xxx.xxx, с User-Agent python-requests, без сессионной cookie (то есть использовался API-ключ специалиста интеграции).
5. Анализ API-ключей. Установлено, что API-ключ, использованный для действий, принадлежал сервису интеграции «1С-Коннект», который был отключен за 2 месяца до инцидента, но ключ формально не был деактивирован. Злоумышленник, вероятно, нашел старый ключ в коде или документации.

Заключение эксперта. Установлены факты НСД. Компрометации учетной записи менеджера Петрова не произошло — действия совершались с его домашнего IP, но через API-ключ, который он (как бывший администратор интеграции) мог сохранить. Таким образом, Петров квалифицируется как лицо, совершившее неправомерные действия (внутренний нарушитель). Представлены доказательства для служебного расследования и (по желанию заказчика) для передачи в правоохранительные органы.

Правовые последствия. Экспертное заключение представлено руководству компании. На его основании проведено внутреннее расследование, Петров уволен по п. 6 ч. 1 ст. 81 ТК РФ (разглашение коммерческой тайны и совершение хищения). Также материалы переданы в полицию, возбуждено уголовное дело по ч. 3 ст. 159 УК РФ (мошенничество в крупном размере). Сумма ущерба частично возмещена за счет страховки (киберполис), компания получила 4 млн руб. компенсации.

Вывод. Даже в SaaS-модели с ограниченным доступом к данным возможна полноценная DFIR-экспертиза при условии анализа косвенных источников (логи прокси, метаданные приложения, запросы к провайдеру через суд). Ключевой фактор — оперативность сохранения логов провайдера (даже частичных).

🟨 Раздел 7. Рекомендации по подготовке к DFIR-экспертизе в облачной среде

7.1. Действия заказчика сразу после обнаружения инцидента:

1. Зафиксировать время и дату обнаружения.
2. Не производить самостоятельных действий по удалению/перезагрузке ВМ, если это не критично. Перезагрузка уничтожает данные оперативной памяти.
3. Сделать скриншоты всех дашбордов провайдера (список ВМ, метрики, активные сессии).
4. Изменить пароли от панели управления облаком (чтобы злоумышленник не удалил улики).
5. Направить провайдеру письменное требование о сохранении (preservation) всех логов и снапшотов за подписью руководителя.
6. Обратиться в экспертную организацию (нашу) для проведения DFIR-экспертизы.

7.2. Пакет документов, который должен предоставить заказчик:

• Договор с провайдером (все приложения и дополнительные соглашения).
• Доступы к панели управления облаком (для эксперта — ограниченные права на чтение логов, либо предоставление выгрузок).
• Логи собственных систем (прокси, шлюзы безопасности, SIEM, антивирус).
• Список учетных записей (администраторы, разработчики, сервисные аккаунты) с указанием уровня доступа.
• Хронология событий по версии заказчика.

7.3. Вопросы, которые следует поставить эксперту: 🔑

• Каков точный вектор проникновения (с указанием CVE, если применимо)?
• Какие действия совершал злоумышленник после получения доступа (какие команды выполнял, какие данные просматривал/копировал)?
• К какому типу нарушителей относится злоумышленник (внешний, внутренний, партнер)?
• Была ли затронута инфраструктура других клиентов провайдера (мультиарендность)?
• Какие меры необходимо принять для предотвращения рецидива?

🟨 Раздел 8. Стоимость и сроки DFIR-экспертизы в облачной среде (ориентировочные)

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

Заключение: DFIR-экспертиза в облаке — сложно, но возможно 🔑

Проведенный анализ и три практических кейса (ransomware на VPS с получением снапшотов через суд; утечка данных из PaaS-БД через скомпрометированный API-ключ; хищение в SaaS-CRM через не деактивированные ключи интеграции) демонстрируют, что даже при полностью внешней инфраструктуре возможно проведение полноценного расследования инцидента кибербезопасности. Однако успех экспертизы зависит от трех ключевых факторов:

1. Оперативность — сохранение логов и снапшотов должно быть инициировано в течение первых 24-48 часов.
2. Правовая поддержка — при отказе провайдера необходимо быстрое обращение в суд за обеспечительными мерами.
3. Квалификация эксперта — знание не только компьютерной криминалистики, но и архитектуры облачных сервисов, API, типовых политик провайдеров.

🟨 Для заказа DFIR-экспертизы в облачной или хостинговой среде (включая взаимодействие с провайдером, судебное истребование данных, анализ и подготовку заключения) перейдите на официальный портал: https://pozex.ru/