Scott Tiger Tech Blog

Blog technologiczny firmy Scott Tiger S.A.

AWS CloudTrail

Autor: Piotr Karpiuk o piątek 21. Kwiecień 2017


CloudTrail to usługa logowania wywłań API chmury Amazonu, a więc akcji podejmowanych przez użytkowników, role i usługi AWS. Nie ma znaczenia czy użytkownik zainicjował akcję z wiersza poleceń, przez API z jakiegoś języka programowania czy z konsoli przeglądarki. Krótko mówiąc, możesz użyć CloudTrail aby obserwować aktywność na swoim koncie AWS, taką jak zalogowanie się użytkownika w konsoli, utworzenie maszyny wirtualnej EC2, zmiana uprawnień użytkownika itp. Usługa jest domyślnie włączona.

Historia zdarzeń

Ze swojej konsoli w przeglądarce masz dostęp do najważniejszych logów z ostatnich 7 dni (patrz rysunek) i nie wiąże się to z żadnymi kosztami.


Logi możesz tu przeglądać, przeszukiwać lub ściągnąć (JSON/CSV).

Rodzaje logów

Logi dzielimy ze względu na typ:

  • management events – są to operacje takie jak utworzenie/usunięcie instancji EC2, kolejki SQS, bazy danych itp., ale także operacje odczytu stanu (np. stanu maszyny wirtualnej z poziomu CLI), czy zalogowania się użytkownika do konsoli webowej AWS
  • data events, obecnie dotyczą tylko usługi S3 i operacji GetObject, DeleteObject i PutObject. Można logować tylko operacje na obiektach, których klucze mają wskazany prefiks. Logowanie tego typu zdarzeń kosztuje.

…a także ze względu na rodzaj wykonywanej operacji: Create/Read/Update/Delete (CRUD).

W historii zdarzeń widać logi management CUD (bez odczytu).

Struktura zdarzenia

Przykład typowego zdarzenia:

{
    "eventVersion": "1.01",
    "userIdentity": {
	"type": "IAMUser",
	"principalId": "AIDAJDPLRKLG7UEXAMPLE",
	"arn": "arn:aws:iam::123456789012:user/Alice",
	"accountId": "123456789012",
	"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
	"userName": "Alice",
	"sessionContext": {
	    "attributes": {
		"mfaAuthenticated": "false",
		"creationDate": "2014-03-18T14:29:23Z"
	    }
	}
    },
    "eventTime": "2014-03-18T14:30:07Z",
    "eventSource": "cloudtrail.amazonaws.com",
    "eventName": "StartLogging",
    "awsRegion": "us-west-2",
    "sourceIPAddress": "72.21.198.64",
    "userAgent": "signin.amazonaws.com",
    "requestParameters": {
	"name": "Default"
    },
    "responseElements": null,
    "requestID": "cdc73f9d-aea9-11e3-9d5a-835b769c0d9c",
    "eventID": "3074414d-c626-42aa-984b-68ff152d6ab7"
}

Co ciekawsze pola:

Pole Opis
eventID Unikalny element zdarzenia
eventTime Czas wygenerowania żądania API, w UTC
userIdentity Użytkownik, który zlecił żądanie
eventSource Usługa, której dotyczyło żądanie
awsRegion Region do którego trafiło żądanie
sourceIPAddress IP z którego przyszło żądanie
userAgent Tu się dowiemy czy żądanie przyszło z konsoli webowej, wiersza poleceń, SDK konkretnego języka programowania, czy innej usługi AWS
errorCode Kod błędu jeśli żądanie zakończyło się błędem
errorMessage Ewentualny komunikat błędu

Uwagi:

  • Zdarzenie logów nie zawiera informacji o priorytecie (DEBUG/INFO/WARNING/ERROR itp.). O tym że realizacja żądania zakończyła się błędem, dowiadujemy się z pól errorCode i errorMessages, w przypadku niektórych usług z pola responseElements.
  • Nie wszystkie usługi generują logi: patrz CloudTrail Unsupported Services.
  • Aby zabronić użytkownikowi IAM dostępu do logów, usuń z jego polityki akcję cloudtrail:LookupEvents.

Traile

Historia zdarzeń to niewątpliwie przydatna rzecz, ale ma swoje niedociągnięcia:

  • przydałaby się możliwość podglądu historii z okresu dłuższego niż tydzień,
  • nie ma tam wszystkich zdarzeń (np. operacji odczytu dla zdarzeń typu management).
  • przydałaby się możliwość reagowania na pewne sytuacje wynikające z logów.

Można oczywiście systematycznie zaciągać logi z historii zdarzeń co najmniej raz na tydzień i samodzielnie zbudować system do ich obsługi (w szczególności archiwizowania), ale możesz też utworzyć tzw. trail, który automatycznie zrzuca (zaszyfrowane i spakowane) logi do wskazanego kubła w S3 i ewentualnie do innych usług (np. CloudWatch Logs, CloudWatch Events) w celu analizy, monitorowania i reagowania na wykryte problemy, np. rozszczelnienie zapory sieciowej, nieudane próby zalogowania się do konsoli webowej, próby wykonania operacji bez posiadanych uprawnień, sprawdzenie zgodności z najlepszymi praktykami itp. Od momentu wystąpienia logowanego zdarzenia do jego zapisu w S3 mija zwykle nie więcej niż 15 minut, a kolejne pliki z logami są dodawane średnio co 5 minut.

Formatka definiowania nowego traila

Za pierwszego traila nie płacisz nic (więcej traili ma sens tylko w naprawdę dużych organizacjach), ale kosztować będzie miejsce zajęte przez zrzucane logi na S3 – Amazon twierdzi że średnio klienci wydają na to $3 miesięcznie. Zawsze też możesz skorzystać z możliwości jakie daje S3 i poprosić aby pliki nie używane dłuższy czas były archiwizowane w usłudze Glacier, albo po prostu automatycznie usuwane. Domyślne ustawienia tworzą traila we wszystkich regionach naraz, i automatycznie we wszystkich nowopowstałych regionach w przyszłości.

Przy definiowaniu traila możesz zażyczyć sobie aby nadejście każdego pliku z logami było anonsowane we wskazanym topicu usługi SNS. Dzięki temu możesz skonstruować sobie maszynerię do przetwarzania logów (najczęściej przy użyciu gotowej biblioteki w Javie: The AWS CloudTrail Processing Library), która nasłuchuje na SNS komunikatów o nadejściu nowych plików, po czym dobiera się do pliku – taka architektura pozwala uniknąć pollingu.

Nazwa pliku logów w S3 ma postać:

AccountID_CloudTrail_RegionName_YYYYMMDDTHHmmZ_UniqueString.json.gz

Uwagi:

  • Utworzenie traila nie ma wpływu na wydajność wywołań API chmury Amazonu.
  • W trailu nie można zdefiniować filtra jak w Event history.
  • Domyślnie logi mają włączoną opcję walidacji integralności. To znaczy że oprócz samych plików logów generowane są pliki skrótów (ang. digest files), a każdy kolejny plik skrótów zawiera skrót poprzedniego pliku skrótów. Pozwala to sprawdzić, czy ktoś nie próbował manipulować przy logach (zmieniać, usuwać).
  • Za pomocą usługi IAM możesz określić którzy użytkownicy mogą tworzyć, konfigurować i usuwać traile, zatrzymywać i wznawiać logowanie i prawa dostępu do kubła S3 z logami. W szczególności przy nadawaniu uprawnień użytkownikom można posłużyć się politykami: AWSCloudTrailFullAccess (pełny dostęp) i AWSCloudTrailReadOnlyAccess (tylko odczyt logów, bez prawa tworzenia, modyfikacji i kasowania traili).
  • Nie da się przesyłać logów do CloudWatch Logs/Events z pominięciem S3.
  • Aby do traila trafiały zdarzenia usługi Route 53, musisz wybrać region US East (N.Virginia) gdy tworzysz traila.

Literatura

AWS CloudTrail User Guide

Share and Enjoy:
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Śledzik
  • Blip
  • Blogger.com
  • Gadu-Gadu Live
  • LinkedIn
  • MySpace
  • Wykop

Zostaw komentarz

XHTML: Możesz użyć następujących tagów: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>