AWS CloudTrail: kto, co i kiedy zrobił na Twoim koncie

Wyobraź sobie, że rano przychodzisz do pracy i ktoś usunął produkcyjną bazę danych. Kto to zrobił? Kiedy? Z jakiego IP? Jeśli masz włączony AWS CloudTrail, masz odpowiedzi na wszystkie te pytania.

CloudTrail to usługa audytu, która rejestruje każde wywołanie API na Twoim koncie AWS. Ktoś uruchomił instancję EC2? Zapisane. Ktoś zmienił uprawnienia IAM? Zapisane. Ktoś usunął bucket S3? Zapisane. CloudTrail to czarna skrzynka Twojego konta AWS.

⚠️ Na egzaminie
CloudTrail = „kto zrobił co i kiedy" (API auditing). CloudWatch = „jak działają Twoje zasoby" (monitoring metryk i logów). To rozróżnienie pojawia się w wielu pytaniach.

Jak działa CloudTrail?

CloudTrail jest domyślnie włączony na każdym koncie AWS. Bez żadnej konfiguracji rejestruje management events z ostatnich 90 dni (Event History). Możesz przeglądać je w konsoli AWS.

Każdy event zawiera kluczowe informacje:

  • Who - kto wykonał akcję (IAM user, role, root account)
  • What - jaka akcja (np. RunInstances, DeleteBucket, CreateUser)
  • When - kiedy (timestamp)
  • Where - z jakiego IP, jaki region
  • How - czy przez konsolę, CLI, SDK

Typy eventów

Management Events (Control Plane)

Operacje zarządzania zasobami AWS. To domyślny typ, rejestrowany zawsze.

  • Tworzenie/usuwanie instancji EC2
  • Zmiany w IAM (tworzenie users, ról, policies)
  • Konfiguracja VPC, security groups
  • Tworzenie/usuwanie bucketów S3

Data Events

Operacje na danych wewnątrz zasobów. Domyślnie NIE są rejestrowane (bo generują ogromną ilość logów).

  • GetObject / PutObject na S3 (każdy upload/download)
  • Invoke na Lambda (każde wywołanie funkcji)
  • Operacje DynamoDB (GetItem, PutItem)
💡 Dlaczego data events są wyłączone?
Wyobraź sobie aplikację, która robi 10,000 odczytów S3 na sekundę. Logowanie każdego z nich generowałoby terabajty logów i ogromne koszty. Dlatego data events włączasz selektywnie, dla konkretnych bucketów czy funkcji.

Insights Events

CloudTrail Insights automatycznie analizuje management events i wykrywa nietypową aktywność. Na przykład:

  • Nagły wzrost tworzenia instancji EC2 (może to atak?)
  • Nietypowa liczba błędów autoryzacji (ktoś próbuje się włamać?)
  • Niespotykane wzorce wywołań API

Trail (ścieżka audytu)

Domyślny Event History przechowuje eventy tylko 90 dni i nie pozwala na zaawansowaną konfigurację. Żeby mieć pełną kontrolę, tworzysz Trail.

Trail to konfiguracja, która mówi CloudTrail: „zapisuj logi do tego konkretnego bucketu S3".

⚖️ Typy Trail
CechaSingle-region TrailMulti-region Trail (all-regions)
ZasięgJeden wybrany regionWszystkie regiony na koncie
Nowe regionyNie obejmuje automatycznieNowe regiony dodawane automatycznie
Rekomendacja AWSRzadko stosowanyBest practice, zalecany
Organization TrailNie dotyczyTak, dla AWS Organizations
⚠️ Na egzaminie
AWS zaleca tworzenie multi-region Trail jako best practice. Organization Trail pozwala centralnie zbierać logi ze wszystkich kont w organizacji do jednego bucketu S3.

Gdzie lądują logi?

CloudTrail zapisuje logi jako pliki JSON w buckecie S3. Opcjonalnie możesz:

  • Szyfrować logi za pomocą KMS
  • Włączyć Log File Validation (integrity checking; sprawdzanie, czy ktoś nie zmodyfikował logów)
  • Wysyłać logi równocześnie do CloudWatch Logs

Integracja CloudTrail z CloudWatch

To potężna kombinacja. Wysyłasz eventy CloudTrail do CloudWatch Logs, a następnie tworzysz metric filters i alarmy.

🏢 Scenariusz: Alarm na root login
Wysyłasz CloudTrail events do CloudWatch Logs. Tworzysz metric filter, który wykrywa event „ConsoleLogin" gdzie userIdentity.type = „Root". Podpinasz alarm, który wysyła email przez SNS. Teraz za każdym razem, gdy ktoś zaloguje się na konto root, dostajesz natychmiastowe powiadomienie. To absolutny must-have z perspektywy bezpieczeństwa.

CloudTrail Lake

CloudTrail Lake to nowsza usługa, która pozwala przeszukiwać eventy za pomocą SQL. Zamiast ręcznie analizować pliki JSON w S3, możesz napisać zapytanie:

SELECT * FROM events WHERE eventName = 'DeleteBucket' AND eventTime > '2024-01-01'

CloudTrail Lake przechowuje dane w zoptymalizowanym formacie i umożliwia retencję do 7 lat (w planie podstawowym 2555 dni). To idealne rozwiązanie do długoterminowego audytu i compliance.

Początkujący często mylą te dwie usługi. Oto kluczowe różnice:

  • CloudTrail odpowiada na: „kto zmienił security group o 14:32?" (audyt API)
  • CloudWatch Logs odpowiada na: „co moja aplikacja logowała o 14:32?" (logi operacyjne)
  • CloudTrail rejestruje wywołania API AWS
  • CloudWatch Logs przechowuje dowolne logi (aplikacje, systemy, usługi)
  • Mogą (i powinny) ze sobą współpracować: CloudTrail wysyła eventy do CloudWatch Logs
✅ CloudTrail: co musisz zapamiętać na egzamin
CloudTrail = audyt API (kto, co, kiedy); CloudWatch = monitoring metryk i logów
Domyślnie włączony, Event History przechowuje 90 dni management events
Data events (S3 GetObject, Lambda Invoke) domyślnie wyłączone
Multi-region Trail to best practice
Logi idą do S3, opcjonalnie do CloudWatch Logs
CloudTrail Lake pozwala przeszukiwać eventy SQL-em
🧠 Podsumowanie
  • CloudTrail rejestruje każde wywołanie API na koncie AWS (kto, co, kiedy, skąd)
  • Management events logowane domyślnie; data events trzeba włączyć ręcznie
  • Event History = 90 dni bez konfiguracji; Trail = zapis do S3 z pełną kontrolą
  • Multi-region Trail obejmuje wszystkie regiony i jest zalecanym podejściem
  • Integracja z CloudWatch Logs pozwala tworzyć alarmy na konkretne eventy (np. root login)
  • CloudTrail Lake umożliwia zapytania SQL na eventach z retencją do 7 lat
🧪 Sprawdź się

Ktoś usunął produkcyjny bucket S3 w nocy. Gdzie sprawdzisz, kto to zrobił?

A CloudWatch Metrics
B AWS CloudTrail
C AWS Config
CloudTrail rejestruje wywołania API, w tym DeleteBucket. Pokaże kto (IAM user/role), kiedy (timestamp) i skąd (IP) wykonał tę operację. CloudWatch monitoruje metryki, nie audytuje akcje API. AWS Config śledzi stan konfiguracji zasobów, ale nie identyfikuje kto wykonał zmianę.

Firma chce logować każdy download pliku z bucketu S3 zawierającego dane klientów. Co musi włączyć w CloudTrail?

A Management events
B Insights events
C Data events dla S3
GetObject (download z S3) to data event. Management events obejmują operacje zarządzania (tworzenie/usuwanie bucketów), ale nie operacje na danych. Data events dla S3 muszą być włączone ręcznie, bo domyślnie nie są logowane ze względu na potencjalnie ogromną ilość.