Облачное логирование и журналы аудита

Что на самом деле записывает журнал аудита

В любом облаке два слоя логов, и их постоянно путают. Логи слоя данных фиксируют трафик через твои сервисы: HTTP-запросы к балансировщику, чтения объекта, запросы к базе. Логи управляющего слоя — AWS CloudTrail, GCP Cloud Audit Logs, Azure Activity Log — фиксируют управляющие действия против самого облачного API: кто вызвал CreateUser, кто привязал политику, кто изменил security group, кто проротировал ключ, кто удалил бакет. Когда ты восстанавливаешь взлом, важен именно журнал управляющего слоя, потому что любое повышение привилегий и любой акт закрепления — это под капотом последовательность аутентифицированных API-вызовов.

Одно событие CloudTrail — это структурированная запись с полями, которые реально нужны расследователю: eventTime, eventName (вызванный API), userIdentity (IAM-принципал, включая сессию принятой роли и исходный аккаунт), sourceIPAddress, userAgent, параметры запроса и ответ. Прочитай эти пять полей по нескольким тысячам событий — и ты ответишь на единственный важный в 02:00 вопрос: какая личность это сделала, когда, откуда и чего коснулась. Поэтому журнал и называют источником истины — это единственное место, где само облако, а не твоё приложение, свидетельствует о том, что произошло.

Подвох — в покрытии по умолчанию. Из коробки журнал обычно логирует управляющие события, но не события данных: атакующий, вычитывающий каждый объект из S3-бакета, не порождает ни одной записи управляющего слоя, пока ты явно не включишь логирование событий данных — а оно отключено по умолчанию отчасти потому, что объёмно и тарифицируется поштучно. Зрелый рефлекс: точно знать, что твой журнал захватывает, а что — нет, до инцидента, потому что «мы предполагали, что S3 GetObject логируется» — открытие, которое не хочется делать, когда эксфильтрация уже идёт.

Почему журнал — первая цель атакующего

Подумай как противник один абзац. Ты скомпрометировал учётку. Твои цели — повысить привилегии, закрепиться и действовать: майнить крипту, выкачивать данные, шантажировать аккаунт. Каждое из этих действий оставляет в журнале следы API-вызовов. Поэтому ход с наибольшим рычагом, который можно сделать перед всем шумным, — ослепить защитника: остановить журнал, удалить его или прервать доставку в место назначения. Это не теория — «уклонение от защиты через подрыв логирования» — поименованная, каталогизированная техника в облачной матрице MITRE ATT&CK именно потому, что это стандартный дебютный ход. Журнал, который атакующий может выключить, — это датчик дыма с доступным выключателем: он защищает ровно до момента, когда становится нужен.

Защита от подделки: превращаем лог в доказательство

Разница между логом и доказательством — в том, мог ли записываемый его изменить. До цели доводят четыре меры, наложенные слоями.

Доставляй в неизменяемое append-only хранилище. Журнал должен писать в объектное хранилище с политикой object-lock / удержания в режиме compliance, чтобы даже администратор аккаунта не мог удалить или перезаписать объект до истечения срока удержания. Append-only — то свойство, что бьёт «правку истории»: можно добавлять записи, но никогда не переписывать.

Размести сток в отдельном аккаунте. Это единственный архитектурный ход с наибольшей ценностью. У скомпрометированного принципала в рабочем аккаунте вообще не должно быть IAM-прав над архивом логов. Централизуй журналы со всех аккаунтов в один выделенный, наглухо запертый логирующий аккаунт, единственная работа которого — принимать и хранить. Теперь, чтобы ослепить журнал, нужно скомпрометировать второй, куда меньший и куда строже контролируемый аккаунт — ты поднял стоимость уклонения на порядок.

Проверяй целостность криптографически. Включи валидацию целостности файлов журнала (CloudTrail подписывает каждый доставленный файл и выпускает дайджест, связанный хеш-цепочкой). На этапе расследования ты сможешь доказать, что файл не изменялся после доставки, — превращая «мы думаем, что это полно» в «мы можем продемонстрировать, что это полно», а это и делает журнал пригодным в форензном или юридическом контексте.

Алертируй на сам акт подделки. API-вызовы, отключающие логирование — StopLogging, DeleteTrail, сужающий охват PutEventSelectors, удаление стока логов, — сами являются логируемыми событиями. Повесь на них алерт в реальном времени. Первый ход атакующего становится его самым громким. Это же и ответ на премису непрерывного мониторинга из NIST SP 800-137: мера, которую выставили один раз и никогда не наблюдают, имеет неизвестный статус; состояние безопасности нужно наблюдать на постоянной основе, и «логирование всё ещё включено?» — самое базовое, что стоит наблюдать.

Читать журнал хорошо, а не только хранить

Защита от подделки держит запись честной; полезной саму по себе она её не делает. Журнал, к которому ты никогда не делаешь запросов, — это просто дорогое хранилище. Две зрелые привычки закрывают разрыв. Первая — централизуй и нормализуй: сливай журнал каждого аккаунта в одно запросопригодное хранилище, чтобы расследователь делал один запрос по всей организации, а не двенадцать. Вторая — выстрой базовую линию нормы, чтобы аномалия бросалась в глаза: новый IAM-пользователь, созданный в 03:00, console login из страны, где вы не работаете, внезапный всплеск RunInstances в неиспользуемом регионе — это сигнал только тогда, когда ты знаешь, как выглядит скучное. Это ровно тот цикл, что NIST SP 800-137 называет непрерывным мониторингом: собрать, сравнить с известной базовой линией, отреагировать, повторить — статус безопасности это то, что ты продолжаешь измерять, а не галочка, поставленная на старте.