Криминалистика в облаке

В облаке исчезает привычный «жёсткий диск под подушкой»: главным свидетелем становится управляющий журнал API-вызовов, а сам сервер может испариться за секунды.

Облачный аудит-журнал (CloudTrail в AWS, Activity Log в Azure, Audit Logs в GCP) — это запись управляющих действий: кто, когда, из какого источника и через какой API создал, изменил или удалил ресурс. В облаке именно он, а не образ диска, чаще всего отвечает на вопрос «что произошло».

Этот урок — про то, как меняется криминалистика, когда инфраструктура живёт в чужом дата-центре и управляется через API. Мы смотрим на облако глазами расследователя инцидента в своей организации: где лежат доказательства, почему их легко потерять и как собрать улики так, чтобы им можно было доверять. Расследовать можно только свои облачные аккаунты или те, на которые у вас есть полномочия; доступ к чужим аккаунтам — это ст. 272 УК РФ.

Зачем это знать защитнику

Классическая форензика предполагает, что у вас есть физический носитель: вы снимаете его побитовый образ и анализируете офлайн. В облаке этой опоры нет. Виртуальная машина — это не «железо», а запись в системе провайдера; контейнер живёт минуты; функция (serverless) выполняется доли секунды и не оставляет диска вовсе. Зато каждое действие в аккаунте проходит через плоскость управления (control plane) и может быть записано в журнал. Поэтому центр тяжести расследования смещается: вместо «что лежит на диске» — «какие API-вызовы были сделаны и кем». Понимание этой модели отличает того, кто восстановит картину атаки, от того, кто разведёт руками над удалённым инстансом.

Где живут доказательства в облаке

Плоскость управления: аудит-журналы

Главный источник — журнал управляющих вызовов. Каждая запись описывает одно событие: какой API вызван (например, создание ВМ, выдача прав, удаление бакета), от чьего имени (пользователь, роль, ключ доступа), с какого IP, в какое время, успешно или с отказом. По этой ленте восстанавливается последовательность действий атакующего: вход → повышение прав → создание ресурсов → удаление следов. Так выглядит одна запись (схематично, поля упрощены):

{
  "eventTime": "2026-03-14T09:21:07Z",
  "eventName": "CreateAccessKey",
  "userIdentity": { "type": "IAMUser", "userName": "deploy-bot" },
  "sourceIPAddress": "203.0.113.45",
  "requestParameters": { "userName": "admin" },
  "responseElements": { "accessKey": { "status": "Active" } }
}

Здесь видно тревожный паттерн: сервисная учётка deploy-bot с нового IP создаёт ключ доступа для admin — типичный шаг закрепления. Аудит-журнал отвечает на вопросы «кто» и «что сделал» даже тогда, когда сам ресурс уже удалён.

Плоскость данных и снимки дисков

Иногда нужно содержимое — файлы на диске ВМ, объекты в хранилище. Здесь работает снимок диска (snapshot): облако умеет за секунды сделать консистентную копию тома, не выключая машину. Снимок — это и есть облачный аналог образа диска: его можно скопировать в изолированный криминалистический аккаунт и спокойно анализировать, не трогая работающий сервис. Журналы доступа к данным (например, к объектному хранилищу) показывают, какие именно объекты читались и скачивались, — это прямая улика эксфильтрации.

Идентичность вместо периметра

В облаке нет «сетевого периметра» в привычном смысле — есть идентичности и права (IAM). Поэтому ключевой вопрос инцидента: «чьи учётные данные скомпрометированы и какие права у них были». Утёкший ключ доступа здесь опаснее открытого порта: с ним атакующий действует «легально» от имени жертвы, и отличить его можно только по аномалиям — новый IP, необычное время, нетипичные вызовы.

Эфемерность: почему улики исчезают

Эфемерность — ключевое свойство облака: ресурсы создаются и уничтожаются на лету, автоматически масштабируются и пересоздаются. Для разработки это удобно, для расследования — ловушка. Инстанс, на котором работал злоумышленник, может быть удалён автоскейлингом через минуту; локальный диск контейнера исчезает вместе с ним; serverless-функция вообще не оставляет файловой системы. Если телеметрия не настроена заранее, восстанавливать будет нечего. Отсюда железное правило облачной форензики: доказательства собираются логированием до инцидента, а не образами после. Включённый и выгружаемый в защищённое хранилище аудит-журнал — это и есть ваша «чёрная коробка».

Как это работает под капотом

Управляющий журнал — побочный продукт самой архитектуры облака. Любое действие (через консоль, CLI или SDK) превращается в вызов REST-API плоскости управления. Провайдер ставит этот вызов на запись: фиксирует вызывающую идентичность (по токену/ключу), параметры, IP и результат, после чего складывает событие в журнал и опционально доставляет его в хранилище или SIEM. Поскольку запись делает сама платформа, а не агент на машине, журнал переживает удаление ресурса — событие «инстанс удалён» останется, даже когда инстанса уже нет. Снимки дисков работают на уровне системы хранения: провайдер фиксирует состояние блоков тома (copy-on-write), поэтому копия консистентна и не требует остановки сервиса. У этой модели есть оборотная сторона доверия: вы полагаетесь на корректность журналов провайдера и на то, что у атакующего не было прав их отключить или почистить, — поэтому защита самих логов критична.

Как защититься

1. Включите аудит во всех аккаунтах и регионах. CloudTrail/Activity Log/Audit Logs должны покрывать весь периметр, а не один регион. Без сплошного логирования слепые зоны становятся местом, где «ничего не было».

2. Защитите сами журналы от подделки. Выгружайте логи в отдельный, изолированный аккаунт-приёмник с неизменяемым (WORM/object-lock) хранилищем. Атакующий с правами в основном аккаунте не должен иметь возможности их стереть или отредактировать.

3. Логируйте плоскость данных там, где это важно. Включайте журналы доступа к объектному хранилищу для чувствительных бакетов — иначе факт скачивания данных останется невидимым.

4. Реагируйте снимками, а не удалением. При инциденте первым делом сделайте снимок диска подозрительной ВМ и сохраните её метаданные, прежде чем что-то останавливать или удалять. Изолируйте ресурс (отдельная сеть/правила), но не уничтожайте улики.

5. Считайте идентичности активами. Минимальные права, короткоживущие токены, обязательная многофакторная аутентификация и алерты на аномальные вызовы (новый IP, создание ключей, изменение прав) ловят компрометацию учётных данных раньше, чем она перерастёт в захват аккаунта.

Итоги

В облаке главное доказательство — управляющий аудит-журнал (кто/что/откуда/когда сделал по API), а не образ диска.
Ресурсы эфемерны: ВМ, контейнеры и функции исчезают, поэтому улики собираются логированием заранее, а не после инцидента.
Снимок диска — облачный аналог образа: консистентная копия тома для офлайн-анализа без остановки сервиса.
Периметр заменён идентичностями: утёкший ключ доступа опаснее открытого порта, а компрометация видна по аномалиям.
Журналы нужно защищать (изолированный аккаунт, неизменяемое хранилище), иначе атакующий сотрёт собственные следы; расследуем только свои аккаунты — чужие это ст. 272 УК РФ.