Настройка AWS CloudTrail для аудита и безопасности под ключ

Настройка CloudTrail: что ломается без аудита действий в аккаунте

CloudTrail включён по умолчанию почти в каждом аккаунте, и именно поэтому аудит действий в аккаунте часто считают решённой задачей. На деле «Журнал событий» в консоли хранит только события управления за последние 90 дней и только по текущему региону. Без выгрузки в защищённое хранилище эта история исчезает безвозвратно — разбирать происшествие через месяц будет не по чему.

Пробелы в аудите копятся незаметно. События уровня данных по S3 и DynamoDB, обращения к KMS, работа с секретами и часть сервисных вызовов в журнал не попадают, пока их не включат отдельно. Аккаунт живёт в нескольких регионах, а маршрут аудита настроен на один — периферийные регионы остаются без наблюдения. Целостность доставленных записей CloudTrail сам не проверяет, поэтому подменить фрагмент журнала в хранилище можно, не оставив следов.

Дороже всего обходится потеря следов изменения прав. Без записей о правках ролевых политик, создании ключей доступа и выдачах временных сессий несанкционированный доступ невозможно ни доказать, ни ограничить по времени: непонятно, кто получил доступ, когда и что успел сделать. Записи CloudTrail нужно связывать с сетевыми журналами и журналами балансировщика, иначе картина происшествия рассыпается на несвязанные фрагменты.

Разбираем, как настройка CloudTrail закрывает эти слепые зоны: единый мультирегиональный маршрут с проверкой целостности, отдельный архивный аккаунт для журналов, события уровня данных и оповещения на чувствительные операции.

Что даёт выстроенный аудит: время разбора, простой, классы отказов

Журнал, собранный корректно, отвечает на четыре вопроса по каждому действию: кто, что, когда и откуда. Пока этого нет, разбор происшествия идёт по логам приложений — а они не знают, что кто-то поменял права доступа, и сбой выглядит необъяснимым.

Когда AWS CloudTrail сведён в единый контур, разбор начинается не с «кто виноват», а с выборки по событию. Проверка, кто и когда выдал избыточную роль или открыл доступ наружу, занимает минуты вместо часов реконструкции по переписке и заявкам. Простой сокращается не потому, что отказы исчезли, а потому что причина находится до того, как её начнут искать вслепую.

Уходит и целый класс спорных ситуаций: «это не наши изменения», расхождение конфигураций между средами, теневые правки политик доступа. События складываются в отдельное хранилище, где срок хранения задан политикой, — окно ретроспективы перекрывает интервал между проверками, поэтому следы остаются, даже если происшествие всплыло позже.

Готовность к внешней проверке здесь следствие, а не отдельная работа: отчёт по доступам и изменениям собирается из того же журнала, без ручной сверки. Наблюдаемость инфраструктуры растёт побочно — аномальные вызовы видно на общем фоне, и они попадают в оповещения раньше, чем в разбор.

Режимы сбора событий: единый журнал, мультиаккаунт, регионы

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

В мультиаккаунтной схеме выбор сводится к трём компромиссам. Единый журнал организации даёт сквозную картину и одну точку подключения оповещений, но превращает центральный аккаунт в узкое место по правам и квотам. Раздельные журналы по подразделениям снимают это ограничение, зато сквозной разбор инцидента превращается в ручную сверку нескольких хранилищ. Глобальные сервисы пишут события лишь в один регион — это учитывают до выбора регионов хранения.

Проверку целостности журнальных файлов включаем сразу — отключить её позже можно, но гарантии подлинности записи журнал уже не даст.

Порядок внедрения: от разбора текущих журналов до передачи регламентов

Собирать события раньше, чем продумана маршрутизация, бессмысленно: дописать журнал задним числом нельзя, а лишние ветки сбора потом дорого чистить. Поэтому идём от инвентаризации к регламенту — с проверяемым результатом на каждом шаге.

1. Разбор текущего состояния. Фиксируем, какие трейлы уже есть, какие регионы и аккаунты покрывают, куда пишут события и сколько хранят. Выписываем слепые зоны: регионы без сбора, выключенные типы событий, бакеты без защиты и версионирования.

2. Схема маршрутизации событий. Определяем, что собираем централизованно, а что точечно: управляющие события — по всем регионам, события уровня данных — только по критичным хранилищам. Два потока: оперативный приёмник для разбора и архив с длительным сроком хранения.

3. Включение сбора и защита хранилища. Шифруем журналы управляемым ключом, включаем проверку целостности файлов и жизненный цикл перевода старых записей в холодный класс. Публичный доступ к бакету закрыт, удаление — только из-под отдельной роли.

4. Проверка полноты. Прогоняем контрольные действия и сверяем, что они дошли целиком: без пропусков по регионам, с корректными метками времени. Проверяем и обратный сценарий — запись нельзя незаметно удалить или подменить.

5. Регламент доступа. Разделяем роли: администратор сбора, аналитик с правом чтения, дежурный. Права на удаление архива не выдаём повседневным ролям, вход — через многофакторную аутентификацию.

6. Передача документации. Отдаём схему потоков, матрицу доступа, инструкции по типовым разборам и порядок действий при сбое доставки — чтобы команда вела систему без нас.

На выходе — целостный журнал и команда, которая умеет с ним работать.

Настройка CloudTrail: артефакты и политики доступа на выходе

Заказчик получает не отчёт о работах, а рабочий комплект: конфигурации сбора, политики доступа и регламенты, по которым дежурная смена действует без нас. Ниже — что именно фиксируется в передаваемых документах.

• Конфигурация сбора. Какие категории событий включены — управляющие действия, доступ к данным на критичных ресурсах, вход в консоль, — в каких регионах, и почему набор именно такой, а не «пишем всё подряд».
• Схемы хранения. Где лежит журнал, как разделены быстрый поиск за последние недели и архив с длинным сроком, какие правила жизненного цикла и защита от удаления применены.
• Политики доступа. Кто читает журналы и через какие роли, почему администрирование и чтение разведены, как исключено изменение и удаление следов.
• Роли для чтения журналов. Отдельные роли для дежурного, разборщика инцидентов и аудитора — с минимально необходимым набором прав.
• Регламенты реагирования. Какие события считаются инцидентом, кому уходит уведомление, что делают в первые минуты и кто подтверждает закрытие.
• Сроки хранения. Сколько хранится каждая категория событий и чем обоснован срок.
• Документация по аудиту. Карта потоков событий, перечень контрольных проверок, порядок выгрузки доказательств по запросу.

Комплект собран так, чтобы проверку можно было пройти без нас: по документации видно, где лежит нужное событие, кто имеет к нему доступ и что уже делалось по похожему инциденту.

Кейс: аудит аккаунта с неотслеживаемыми ролями и доступами

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

На старте зафиксировали три факта: полнота собираемых событий ниже половины, отсутствие контроля целостности журналов и невозможность восстановить цепочку «кто — когда — что изменил». Любой разбор подозрительной активности превращался в ручной перебор логов по аккаунтам и заканчивался выводом «данных нет».

Что сделали

Развернули AWS CloudTrail единым трейлом уровня организации: запись со всех аккаунтов и регионов, доставка журналов в изолированный аккаунт аудита, куда у операционных команд доступа нет. Политику хранения задали на уровне хранилища — переход в холодный класс и удаление по сроку, защита от изменения и удаления самих журналов. Отключение записи, правки сроков хранения и изменения политик доступа связали с оповещениями дежурной смене, а проверку целостности файлов журнала вынесли в отдельную регулярную проверку.

Отдельно собрали реестр ролей: сопоставили записи в журналах с фактически используемыми правами, отметили неиспользуемые и избыточные. Аудит ролей перестал быть разовым проектом — появился регулярный отчёт: новые роли, расширение прав, обращения к чувствительным данным.

Метрики до и после

Полнота событий по операциям управления выросла с 58% до 100%. Время разбора инцидента сократилось с двух-трёх суток до 40 минут: цепочка по всем аккаунтам собирается одним запросом. Аудит ролей дал 470 записей, из них 70 неиспользуемых и 34 с избыточными правами — лишние отозвали. Изменился и класс отказов: вместо «логи не найдены» разбор упирается в конкретное событие и его контекст.

Что делать, если часть действий уже пишется в старый журнал?

Старую схему сбора не выключают одним переключением. Штатный путь — параллельная запись: прежний поток продолжает складывать события в старое хранилище, новый пишет те же действия в целевое. Сам CloudTrail допускает несколько записей одновременно, поэтому оба сбора живут рядом несколько недель, пока не наберётся статистика по всем источникам и регионам.

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

Дальше — сверка полноты. Раз в сутки сравниваем наборы по типам событий: какие действия управления и обращения к данным видит новый сбор, а какие пока пишет только старый. Нулевое расхождение по всем типам — единственный критерий, что слепых зон на переходе не осталось.

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

Отключаем старый сбор только после сверки, обычно по одному источнику за раз, сохраняя архив на срок, который задаёт политика хранения. Так переход не оставляет разрывов в истории и не превращается в день, когда непонятно, где искать событие.

Технические сомнения: полнота событий, объёмы, задержки доставки

Перед стартом звучит один набор вопросов: попадут ли в аудит все сервисы, во что превратится хранилище через год, сколько ждать события до разбора. Ниже — ответы на уровне конфигурации: AWS CloudTrail настраиваем как систему аудита, а не как галочку.

Что будет с объёмом хранения через год?

Схема проектируется со сроком хранения по типам событий, сжатием и переводом старых записей в холодное хранилище. Однотипные события сводятся в агрегаты, горячими остаются нужные для разбора — реестр растёт вместе с нагрузкой, но предсказуемо.

Как быстро события пригодны для разбора?

Для регулярного аудита хватает нескольких минут. Там, где важна реакция на удаление данных или смену прав, поток отдаётся почти сразу и уходит в оповещения, минуя пакетную запись. Задержку замеряем на стенде до ввода в работу.

Что если приёмник недоступен?

Доставка повторяется, недоставленное удерживается и уходит после восстановления связи; контролируем отставание, чтобы пробел был виден заранее. Запись идёт в защищённое хранилище с ограниченными правами на изменение и проверкой целостности — для требований аудита этого достаточно.

Обсудим задачу: план работ и оценка сроков по вашему аккаунту

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

• Инвентаризация аккаунтов и регионов: где нужен общий трейл, где достаточно локального, а где логи уже сводятся в один архив.
• Схема доставки: отдельное хранилище под след, срок хранения, защита от удаления и правки, разделение по аккаунтам и подразделениям.
• Набор событий: события управления включаем везде, события доступа к данным — точечно по сервисам, чтобы объём оставался управляемым.
• Правила отбора: инцидентные события уходят в поток для разбора, полный след остаётся в архиве для проверок.
• Доступы: отдельная учётная роль только на чтение для аудита, ограничение по внешнему идентификатору, свои права у автоматизации и дежурной смены.
• Проверка и передача: тестовые операции с подтверждением, что событие дошло до архива, плюс схемы и инструкции для тех, кто разбирает инциденты.

Начинаем с пилотного этапа на одном аккаунте или группе: включаем след, убеждаемся, что нужные события доходят до хранилища целиком и без задержек, и только потом раскатываем схему на всю организацию. Опишите задачу и дайте доступ к конфигурации — вернёмся с планом работ и оценкой сроков по вашему аккаунту.