Konfiguracja AWS CloudTrail jest jednym z najistotniejszych elementów, kiedy zaczynasz pracę z chmurą AWS. Zatem jak skonfigurować AWS CloudTrail i na co warto zwrócić uwagę?
Z jednej strony może Ci się wydawać, że to oczywista oczywistość. Jednak powiem Ci, że nadal często się spotykam z pominięciem ( a raczej nieświadomością) prawidłowej konfiguracji AWS CloudTrail.
Dlatego też w tym artykule przyjrzymy się dokładniej czym jest usługa AWS CloudTrail i dlaczego jest tak istotna. Oraz pokaże Ci jak skonfigurować AWS CloudTrail.
Czym jest AWS CloudTrail?
Zacznijmy od początku, czym jest AWS CloudTrail?
Usługa odpowiedzialna jest za logowanie wszystkich zdarzeń na naszym koncie AWS. Mowa tutaj o tym wszystkim co dzieję się, kiedy pracujesz z konsolą graficzną (AWS Management Console), aws cli, AWS SDK i API.
Czyli każde zdarzenie jak np.:
- użytkownik user1 zalogował się do konsoli,
- usługa X wykonała akcję na usłudze Y,
- SecurityGroup została zmodyfikowana przez …,
- itp.
W skrócie wszystko co dzieje się na Twoim koncie.
Właściwe zadbanie o logi z AWS CloudTrail podnosi poziom bezpieczeństwa i pomaga spełnić wymogi audytowe czy regulacyjne.
Dlatego ważne, jest aby zadbać o tę cześć konfiguracji, dzięki czemu w każdym momencie będziesz w stanie „cofnąć” się w czasie i sprawdzić co i jak działo się na Twoim koncie AWS.
Jak włączyć AWS CloudTrail?
Teraz wyjaśnijmy po krótce dwa bardzo ważne elementy konfiguracji AWS CloudTrail.
Od dłuższego czasu (choć pamiętam czasy kiedy jeszcze tak nie było), dla każdego nowo założonego konta AWS, zbieranie logów w CloudTrail jest automatycznie włączone.
Wujek Google podpowiada, że w Sierpniu 2017 AWS ogłosił, że CloudTrail jest automatycznie włączony dla wszystkich (patrz „New – Amazon Web Services Extends CloudTrail to All AWS Customers„).
Zatem jeśli teraz założysz konto i przejdziesz do CloudTrail w panelu Event history, zobaczysz logi z tego co dzieje się na Twoim koncie (patrz grafika powyżej).
UWAGA! Teraz ten drugi bardzo ważny element… Jak spojrzysz raz jeszcze na zrzut logów powyżej, zobaczysz pod tytułem Event history, bardzo ważne zdanie:
Event history shows you the last 90 days of management events.
Czyli Twoje logi tam są, ale po 90 dniach przepadają. A co w takim razie, gdy przyjdzie nam coś sprawdzać, co wydarzyło się np 180 dni temu? Jak i gdzie można przechowywać te logi dłużej niż 90 dni?
Aby odpowiedzieć na te pytania, postanowiłem napisać ten artykuł. Wciąż i dosyć często spotykam się z sytuacją, w której firmy nie mają wdrożonej konfiguracji bezpiecznego i przede wszystkim dłuższego jak 90 dni przechowywania logów CloudTrail.
Jak bezpiecznie przechowywać logi?
Przechodzimy zatem do meritum tego wpisu, jak bezpiecznie przechowywać logi AWS CloudTrail?
Po pierwsze, nawet jeśli masz tylko jedno konto AWS, to nic nie stoi na przeszkodzie aby zapisywać logi, aby były dostępne dłużej niże 90 dni. Chodzi tu o skonfigurowanie tzw. „Trails” aby logi były zapisywane do bucketu S3.
Ja oczywiście jak zwykle gorąco zachęcam Cię, do stworzenia odrębnego konta AWS, na przechowywanie takich logów. Dlaczego warto mieć więcej kont AWS, dowiesz się o tym z innego mojego artykułu, „Czy jedno konto AWS to nie za mało?„
W dzisiejszym wpisie również skupie się na bezpiecznym przechowywaniu logów w strukturze multi-account. Przejdźmy zatem do szczegółów.
Przechowywanie logów w całej organizacji
W sytuacji, kiedy posiadasz kilka kont AWS, a także planujesz w przyszłości dodawać kolejne, z pomocą przyjdzie usługa AWS Organizations. Dzięki niej możesz nie tylko tworzyć i zarządzać kontami ale również tworzyć współdzielić konfigurację dla niektórych z usług.
W ustawieniach organizacji jest sekcja „Trusted access for AWS services„, w której można „globalnie” w ramach całej organizacji włączać usługi, w tym właśnie AWS CloudTrail.
Aby wdrożyć konfigurację „Trails” w taki sposób aby wszystkie konta automatycznie przesyłały logi do odpowiedniego S3 bucketu, upewnić się, że CloudTrail jest włączony w Twojej organizacji (patrz powyżej).
Gdzie zapisywać logi CloudTrail?
OK, teraz zajmiemy się konfiguracją bezpiecznego miejsca na składowanie logów.
Jeśli udało Ci się już przeczytać mój artykuł o ilości kont to już wiesz, że stworzymy teraz odpowiednie konto, który tylko i wyłącznie będzie dedykowane przechowaniu logów z AWS CloudTrail. Zatem ja w swojej organizacji mam specjalne konto, powiedźmy o id 222222222222 (tak jak na obrazku powyżej).
Teraz kolejny ważny element. Normalnie, gdy na koncie zarządzającym organizacją (powiedzmy koncie o id 111111111111), będziesz tworzył „Trail” to domyślnie dostaniesz propozycje utworzenia bucketu S3 na tym koncie.
Ja jednak chcę aby logi odkładane były na dedykowanym koncie (id 222222222222), z bardzo ograniczonym dostęp. Zatem, zanim skonfigurujemy Trail organizacyjny, to na koncie 222222222222 najpierw utworzymy bucket S3 nałożymy na niego odpowiednie uprawnienia, które pozwolą na zapisywanie logów z całej organizacji.
Przykładowa definicja policy:
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AWSCloudTrailAclCheck20150319",
"Effect":"Allow",
"Principal":{
"Service":[
"cloudtrail.amazonaws.com"
]
},
"Action":"s3:GetBucketAcl",
"Resource":"arn:aws:s3:::gov-my-cloudtrail"
},
{
"Sid":"AWSCloudTrailWrite20150319",
"Effect":"Allow",
"Principal":{
"Service":[
"cloudtrail.amazonaws.com"
]
},
"Action":"s3:PutObject",
"Resource":"arn:aws:s3:::gov-my-cloudtrail/AWSLogs/1111111111/*",
"Condition":{
"StringEquals":{
"s3:x-amz-acl":"bucket-owner-full-control"
}
}
},
{
"Sid":"AWSCloudTrailWrite20150319",
"Effect":"Allow",
"Principal":{
"Service":[
"cloudtrail.amazonaws.com"
]
},
"Action":"s3:PutObject",
"Resource":"arn:aws:s3:::gov-my-cloudtrail/AWSLogs/o-YOUR-ORGANIZATIONS-ID/*",
"Condition":{
"StringEquals":{
"s3:x-amz-acl":"bucket-owner-full-control"
}
}
}
]
}Ważnym elementem, tego aby to działało, musisz dać możliwość Twojej organizacji (podając ID w miejscu zaznaczonym na czerwono) na zapisywanie logów (operacji PutObject) do tego bucketu.
Teraz już jest z górki. Przechodzimy na nasze konto zarządzające 111111111111, a potem do usługi CloudTrail i z lewej strony wybieramy Trails i tworzymy nowy trail.
Następnie podajemy nazwę dla traila, i teraz najważniejsze
- Zaznaczamy „Enable for all accounts in my organization„,
- Zaznaczamy „Use existing S3 bucket” i wpisujemy nazwę naszego bucketu na logi np. gov-my-cloudtrail.
Pozostałe kwestie jak enkrypcja, walidacja logów, zalecam, ale pozostawiam Tobie. Idziemy dalej, Next!
Potem masz jeszcze możliwość określania jakie inne logi poza „Management events” chcesz zapisywać i to tak naprawdę jest już wszystko.
Teraz, na każdym koncie, które posiadasz jak również utworzysz w przyszłości, będzie wdrożona konfiguracja Trails, która będzie odkładała logi do S3 na dedykowanym koncie AWS.
Zaletą tej metody jest też, to że takiego „organizacyjnego” traila nie da się wyłączyć na żadnym przynależnym koncie AWS. Zyskujesz pewność, że nikt nie zatrzyma zapisywania tych logów.
Dodatkowe zabezpieczenia – Service Control Policy
Skoro już korzystamy z AWS Organizations, możemy dodatkowo zabezpieczyć logi, przed skasowaniem, na wypadek, gdyby ktoś dostał się na konto z logami z wyższymi niż byśmy oczekiwali uprawnieniami.
Możemy to osiągnąć, poprzez nałożenie dodatkowo Service Control Policy na konto z logami 222222222222, tak aby zabronić na jakiekolwiek modyfikacje czy skasowanie logów.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Statement1",
"Effect": "Deny",
"Action": [
"s3:RestoreObject",
"s3:PutReplicationConfiguration",
"s3:PutObjectVersionAcl",
"s3:PutObjectTagging",
"s3:PutObjectLegalHold",
"s3:PutObjectAcl",
"s3:PutLifecycleConfiguration",
"s3:PutInventoryConfiguration",
"s3:PutEncryptionConfiguration",
"s3:PutBucketWebsite",
"s3:PutBucketVersioning",
"s3:PutBucketTagging",
"s3:PutBucketPublicAccessBlock",
"s3:PutBucketPolicy",
"s3:PutBucketOwnershipControls",
"s3:PutBucketObjectLockConfiguration",
"s3:PutBucketLogging",
"s3:PutBucketAcl",
"s3:PutAccountPublicAccessBlock",
"s3:ObjectOwnerOverrideToBucketOwner",
"s3:DeleteObjectVersion",
"s3:DeleteObjectTagging",
"s3:DeleteObject",
"s3:DeleteJobTagging",
"s3:DeleteBucketPolicy",
"s3:DeleteBucketOwnershipControls",
"s3:DeleteBucket"
],
"Resource": [
"arn:aws:s3:::YOUR-BUCKET"
]
}
]
}Oczywiście to tylko przykłada polityki, która zabrania pewnych zmian zarówno w konfiguracji jak i przede wszystkim możliwości skasowania logów.
W momencie, w którym nałożymy na konto 222222222222 taką politykę, to bez znaczenia będzie kto i z jakimi uprawnieniami zaloguje się na konto. Nie będzie w stanie skasować logów.
PODSUMOWANIE
Jak widzisz cały proces jest dość prosty i nie powinien zająć więcej niż 10-15 minut Twojego czasu.
Grunt aby zdecydować gdzie i w jaki sposób będą przechowywane logi, ja rekomenduje oddzielnie konto. Zgodnie jednak z zasadą 1 jest lepsze niż 0, to nawet jak pracujesz na jednym koncie, to załóż na nim bucket S3 i skonfiguruj sobie Trails’a.
Dodatkowo zawsze możesz eksportować te logi gdzie „na zewnątrz”.
Jeśli masz więcej konto, wtedy tak jak opisałem w moim scenariuszu, załóż dedykowane konto, na nim bucket S3 i skonfiguruj Trails na poziomie całej organizacji.
Teraz będziesz mieć pewność, że w każdym momencie będzie możliwe sprawdzenia, co kiedy i jak się zadziało w dowolnym momencie w czasie. Cheers!
WPIS TEN ORYGINALNIE POJAWIŁ SIĘ NA ŁAMACH BLOGA WELASTIC.PL
ZNAJDZIESZ TAM POZOSTAŁE WPISY PODSUMOWYWUJĄCE KOLEJNE TYGODNIE KONFERENCJI.
Zbuduje swoje bezpieczne środowisko AWS.
