Налаштування CloudTrail: що ламається без аудиту дій в акаунті
CloudTrail увімкнено за замовчуванням майже в кожному акаунті, і саме тому аудит дій в акаунті часто вважають розв'язаною задачею. Насправді «Журнал подій» у консолі зберігає лише керуючі події за останні 90 днів і лише за поточним регіоном.
Без вивантаження в захищене сховище ця історія зникає безповоротно — розбирати інцидент через місяць не буде за чим.
Прогалини в аудиті накопичуються непомітно. Події рівня даних за S3 і DynamoDB, звернення до KMS, робота із секретами та частина сервісних викликів до журналу не потрапляють, поки їх не увімкнуть окремо.
Акаунт живе в кількох регіонах, а маршрут аудиту налаштовано на один — периферійні регіони залишаються без нагляду. Цілісність доставлених записів CloudTrail сам не перевіряє, тому підмінити фрагмент журналу у сховищі можна, не залишивши слідів.
Найдорожче обходиться втрата слідів змінення прав. Без записів про правки рольових політик, створення ключів доступу та видачі тимчасових сесій несанкціонований доступ неможливо ні довести, ні обмежити в часі: незрозуміло, хто отримав доступ, коли і що встиг зробити.
Записи CloudTrail потрібно пов'язувати з мережевими журналами та журналами балансувальника, інакше картина інциденту розсипається на незв'язані фрагменти.
Розбираємо, як налаштування CloudTrail закриває ці сліпі зони: єдиний мультирегіональний маршрут із перевіркою цілісності, окремий архівний акаунт для журналів, події рівня даних і сповіщення на чутливі операції.
Що дає вибудуваний аудит: час розбору, простій, класи відмов
Журнал, зібраний коректно, відповідає на чотири питання щодо кожної дії: хто, що, коли та звідки. Поки цього немає, розбір інциденту йде за логами застосунків — а вони не знають, що хтось змінив права доступу, і збій виглядає незрозумілим.
Коли AWS CloudTrail зведено в єдиний контур, розбір починається не з «хто винен», а з вибірки за подією. Перевірка, хто і коли видав надлишкову роль або відкрив доступ назовні, займає хвилини замість годин реконструкції за листуванням і заявками.
Простій скорочується не тому, що відмови зникли, а тому що причина знаходиться до того, як її почнуть шукати наосліп.
Зникає й цілий клас спірних ситуацій: «це не наші зміни», розбіжність конфігурацій між середовищами, тіньові правки політик доступу.
Події складаються в окреме сховище, де строк зберігання заданий політикою, — вікно ретроспективи перекриває інтервал між перевірками, тому сліди залишаються, навіть якщо інцидент сплив пізніше.
Готовність до зовнішньої перевірки тут є наслідком, а не окремою роботою: звіт щодо доступів і змін збирається з того самого журналу, без ручної звірки.
Спостережуваність інфраструктури зростає побічно — аномальні виклики видно на загальному тлі, і вони потрапляють у сповіщення раніше, ніж у розбір.
Режими збору подій: єдиний журнал, мультиакаунт, регіони
Організація збору подій визначає, куди пишуться журнали, хто має до них доступ і наскільки просто довести їхню цілісність під час розбору інциденту.
Схема задається під час створення журналу: пізніше її змінюють лише з перезбиранням політик доступу до сховища, ключів шифрування та правил життєвого циклу об'єктів, а події за минулий період до нового журналу вже не потраплять.
У мультиакаунтній схемі вибір зводиться до трьох компромісів. Єдиний журнал організації дає наскрізну картину й одну точку підключення сповіщень, але перетворює центральний акаунт на вузьке місце за правами та квотами.
Окремі журнали за підрозділами знімають це обмеження, зате наскрізний розбір інциденту перетворюється на ручну звірку кількох сховищ. Глобальні сервіси пишуть події лише в один регіон — це враховують до вибору регіонів зберігання.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Централізований журнал організації | Потрібна наскрізна картина за всіма акаунтами, єдина точка реагування | Спільний приймач і ключ шифрування — єдина точка відмови |
| Окремі журнали за підрозділами | Команди володіють своїми сховищами та зоною відповідальності | Наскрізний пошук подій між командами виконується вручну |
| Гібрид: приймання в регіоні, агрегація вище | Дані мають зберігатися в конкретному регіоні, потрібна загальна аналітика | Подвійна доставка подій: стежити за дублями та порядком записів |
Перевірку цілісності журнальних файлів вмикаємо відразу — вимкнути її пізніше можна, але гарантії автентичності запису журнал уже не дасть.
Порядок упровадження: від розбору поточних журналів до передавання регламентів
Збирати події раніше, ніж продумано маршрутизацію, безглуздо: дописати журнал заднім числом не можна, а зайві гілки збору потім дорого чистити. Тому йдемо від інвентаризації до регламенту — з перевірюваним результатом на кожному кроці.
-
Розбір поточного стану. Фіксуємо, які трейли вже є, які регіони та акаунти покривають, куди пишуть події та скільки зберігають. Виписуємо сліпі зони: регіони без збору, вимкнені типи подій, бакети без захисту й версіонування.
-
Схема маршрутизації подій. Визначаємо, що збираємо централізовано, а що точково: керуючі події — за всіма регіонами, події рівня даних — лише за критичними сховищами. Два потоки: оперативний приймач для розбору й архів із тривалим строком зберігання.
-
Увімкнення збору та захист сховища. Шифруємо журнали керованим ключем, вмикаємо перевірку цілісності файлів і життєвий цикл переведення старих записів у холодний клас. Публічний доступ до бакета закритий, видалення — лише з-під окремої ролі.
-
Перевірка повноти. Проганяємо контрольні дії та звіряємо, що вони дійшли цілком: без пропусків за регіонами, з коректними мітками часу. Перевіряємо і зворотний сценарій — запис не можна непомітно видалити або підмінити.
-
Регламент доступу. Розділяємо ролі: адміністратор збору, аналітик із правом читання, черговий. Права на видалення архіву не видаємо повсякденним ролям, вхід — через багатофакторну автентифікацію.
-
Передавання документації. Віддаємо схему потоків, матрицю доступу, інструкції з типових розборів і порядок дій у разі збою доставки — щоб команда вела систему без нас.
На виході — цілісний журнал і команда, яка вміє з ним працювати.
Налаштування CloudTrail: артефакти та політики доступу на виході
Замовник отримує не звіт про роботи, а робочий комплект: конфігурації збору, політики доступу та регламенти, за якими чергова зміна діє без нас. Нижче — що саме фіксується в документах, які передаються.
- Конфігурація збору. Які категорії подій увімкнено — керуючі дії, доступ до даних на критичних ресурсах, вхід у консоль, — у яких регіонах, і чому набір саме такий, а не «пишемо все підряд».
- Схеми зберігання. Де лежить журнал, як розділено швидкий пошук за останні тижні й архів із тривалим строком, які правила життєвого циклу та захист від видалення застосовано.
- Політики доступу. Хто читає журнали й через які ролі, чому адміністрування та читання розведено, як унеможливлено змінення й видалення слідів.
- Ролі для читання журналів. Окремі ролі для чергового, розбирача інцидентів і аудитора — з мінімально необхідним набором прав.
- Регламенти реагування. Які події вважаються інцидентом, кому надходить повідомлення, що роблять у перші хвилини й хто підтверджує закриття.
- Строки зберігання. Скільки зберігається кожна категорія подій і чим обґрунтовано строк.
- Документація з аудиту. Карта потоків подій, перелік контрольних перевірок, порядок вивантаження доказів на запит.
Комплект зібрано так, щоб перевірку можна було пройти без нас: з документації видно, де лежить потрібна подія, хто має до неї доступ і що вже робилося за схожим інцидентом.
Кейс: аудит акаунта з невідстежуваними ролями та доступами
Замовник прийшов із картиною, типовою для розрослої інфраструктури: кількість акаунтів за кілька років зросла в рази, права ролям видавали вручну й без регламенту.
Перевірити, хто й коли розширив доступ, було неможливо — частина журналів велася лише в окремих акаунтах, строки зберігання ніхто не контролював, а вимкнути запис міг будь-який адміністратор, і слідів від цього не залишалося.
На старті зафіксували три факти: повнота зібраних подій нижче половини, відсутність контролю цілісності журналів і неможливість відновити ланцюжок «хто — коли — що змінив».
Будь-який розбір підозрілої активності перетворювався на ручний перебір логів за акаунтами й закінчувався висновком «даних немає».
Що зробили
Розгорнули AWS CloudTrail єдиним трейлом рівня організації: запис з усіх акаунтів і регіонів, доставка журналів в ізольований акаунт аудиту, куди в операційних команд доступу немає.
Політику зберігання задали на рівні сховища — перехід у холодний клас і видалення за строком, захист від змінення й видалення самих журналів.
Вимкнення запису, правки строків зберігання та зміни політик доступу пов'язали зі сповіщеннями черговій зміні, а перевірку цілісності файлів журналу винесли в окрему регулярну перевірку.
Окремо зібрали реєстр ролей: зіставили записи в журналах із фактично використовуваними правами, позначили невикористовувані та надлишкові. Аудит ролей перестав бути разовим проєктом — з'явився регулярний звіт: нові ролі, розширення прав, звернення до чутливих даних.
Метрики до і після
Повнота подій за операціями управління зросла з 58% до 100%. Час розбору інциденту скоротився з двох-трьох діб до 40 хвилин: ланцюжок за всіма акаунтами збирається одним запитом.
Аудит ролей дав 470 записів, з них 70 невикористовуваних і 34 з надлишковими правами — зайві відкликали. Змінився й клас відмов: замість «логи не знайдено» розбір упирається в конкретну подію та її контекст.
Що робити, якщо частина дій уже пишеться в старий журнал?
Стару схему збору не вимикають одним перемиканням. Штатний шлях — паралельний запис: колишній потік продовжує складати події в старе сховище, новий пише ті самі дії в цільове.
Сам CloudTrail допускає кілька записів одночасно, тому обидва збори живуть поруч кілька тижнів, поки не набереться статистика за всіма джерелами й регіонами.
Головна складність цього періоду — дублювання подій. Одна й та сама дія потрапляє в обидва журнали, але з різними ідентифікаторами запису, і просте об'єднання дає подвійний рахунок під час розбору інциденту.
Тому нормалізуємо поля на прийманні: час події, ідентифікатор запиту, обліковий запис і джерело приводяться до єдиного вигляду, а збіги згортаються під час завантаження, а не у звіті.
Далі — звірка повноти. Раз на добу порівнюємо набори за типами подій: які керуючі дії та звернення до даних бачить новий збір, а які поки пише лише старий. Нульова розбіжність за всіма типами — єдиний критерій, що сліпих зон на переході не залишилося.
Історію переносимо окремим потоком: старий архів розбирається й довантажується в цільове сховище з міткою періоду, щоб не змішувати його з новими подіями та не роздувати робочий індекс.
Поки триває міграція журналу, пошук за інцидентом ведеться за двома сховищами — це заздалегідь описано в схемі розслідування, щоб черговий не витрачав час на здогади.
Вимикаємо старий збір лише після звірки, зазвичай по одному джерелу за раз, зберігаючи архів на строк, який задає політика зберігання. Так перехід не залишає розривів в історії й не перетворюється на день, коли незрозуміло, де шукати подію.
Технічні сумніви: повнота подій, обсяги, затримки доставки
Перед стартом лунає один набір питань: чи потраплять в аудит усі сервіси, на що перетвориться сховище через рік, скільки чекати події до розбору. Нижче — відповіді на рівні конфігурації: AWS CloudTrail налаштовуємо як систему аудиту, а не як галочку.
Чи потраплять в аудит усі сервіси та дії?
Керуючі події пишуться за замовчуванням: створення, змінення й видалення ресурсів, робота з правами доступу. Звернення до даних вмикають адресно — за конкретними сховищами й операціями, інакше обсяг зростає на порядок без користі для розбору.
Що буде з обсягом зберігання через рік?
Схема проєктується зі строком зберігання за типами подій, стисненням і переведенням старих записів у холодне сховище. Однотипні події зводяться в агрегати, гарячими залишаються потрібні для розбору — реєстр зростає разом із навантаженням, але передбачувано.
Як швидко події придатні для розбору?
Для регулярного аудиту достатньо кількох хвилин. Там, де важлива реакція на видалення даних або зміну прав, потік віддається майже одразу й надходить у сповіщення, минаючи пакетний запис. Затримку заміряємо на стенді до введення в роботу.
Що якщо приймач недоступний?
Доставка повторюється, недоставлене утримується й надходить після відновлення зв'язку; контролюємо відставання, щоб прогалину було видно заздалегідь. Запис іде в захищене сховище з обмеженими правами на змінення та перевіркою цілісності — для вимог аудиту цього достатньо.
Обговоримо задачу: план робіт та оцінка строків за вашим акаунтом
Для оцінки достатньо доступу до акаунта в режимі читання, переліку регіонів і сервісів, які мають потрапляти у слід, і вимог комплаєнсу.
Дивимося, як зараз влаштовано запис подій, де зберігаються архіви та які організаційні обмеження заважають їх об'єднати — із цього складається план робіт та оцінка строків.
- Інвентаризація акаунтів і регіонів: де потрібен загальний трейл, де достатньо локального, а де логи вже зводяться в один архів.
- Схема доставки: окреме сховище під слід, строк зберігання, захист від видалення й правки, розділення за акаунтами та підрозділами.
- Набір подій: керуючі події вмикаємо всюди, події доступу до даних — точково за сервісами, щоб обсяг залишався керованим.
- Правила відбору: інцидентні події надходять у потік для розбору, повний слід залишається в архіві для перевірок.
- Доступи: окрема облікова роль лише на читання для аудиту, обмеження за зовнішнім ідентифікатором, свої права в автоматизації та чергової зміни.
- Перевірка та передавання: тестові операції з підтвердженням, що подія дійшла до архіву, плюс схеми й інструкції для тих, хто розбирає інциденти.
Починаємо з пілотного етапу на одному акаунті або групі: вмикаємо слід, переконуємося, що потрібні події доходять до сховища цілком і без затримок, і лише потім розгортаємо схему на всю організацію.
Опишіть задачу та дайте доступ до конфігурації — повернемося з планом робіт та оцінкою строків за вашим акаунтом.
