Jak korzystać z AWS Config i CloudTrail, aby dowiedzieć się, kto dokonał zmian w zasobie?

AWS Config to usługa, która stale śledzi i ocenia zmiany konfiguracji Twoich zasobów AWS. Zapewnia Resource Timeline, która pomaga badać i kontrolować, w jaki sposób zasoby i ich relacje zmieniają się w czasie. AWS Config rejestruje konfigurację obsługiwanych zasobów w strukturze JSON znanej jako element konfiguracji (CI).

Podczas korzystania z konsoli AWS Config, jeśli przejdziesz do Resource Timeline niektórych zasobów, możesz zobaczyć skorelowany link do zdarzenia Amazon CloudTrail, jeśli zdarzenie miało miejsce w ciągu ostatnich 90 dni. AWS Config osiąga to, wywołując CloudTrail LookupEvents API. Wybierając link, AWS Config przekieruje Cię do historii zdarzeń CloudTrail. Z wydarzenia Amazon CloudTrail możesz uzyskać dodatkowe informacje, w tym między innymi, kto dokonał zmian w zasobach i kiedy.

W tym artykule zostanie omówione rozwiązanie umożliwiające zautomatyzowanie tego procesu i otrzymywanie powiadomień Amazon Simple Notification Service (Amazon SNS) dotyczących tego, który główny użytkownik dokonał zmian w zasobach AWS oraz w jakim czasie.

Omówienie rozwiązania

W tym rozwiązaniu wykorzystasz kombinację usług AWS:

1. Rozwiązanie jest samowystarczalne i wdrażane przy użyciu stosu AWS CloudFormation. Domyślnie stos utworzy następujące zasoby:

• AWS EventBridge Rules
• Amazon SQS Queue and Queue Policy
• AWS Lambda Function and Event Source Mapping
• AWS IAM Role (AWS Lambda Function Execution Role)
• Amazon SNS Topic
• AWS Key Management Service (AWS KMS) Customer-managed Key
• Amazon CloudWatch Log Group

1. Po wdrożeniu wszystkich zasobów możesz przejść do konsoli Amazon SNS i utworzyć subskrypcję, taką jak powiadomienie e-mail dla tematu SNS.
2. Gdy wszystko będzie gotowe, możesz włączyć regułę AWS EventBridge. Gdy tylko reguła zostanie włączona, rozpocznie przechwytywanie ConfigurationChangeNotification.
3. Możesz dalej modyfikować ten szablon i funkcję AWS Lambda, aby wykonać inną automatyzację. Szablon w tym poście pokazuje, jak na przykład używać Amazon SNS do publikowania powiadomień.

Jak działa rozwiązanie

Poniższy diagram ilustruje architekturę rozwiązania:

1. Za każdym razem, gdy wystąpi zdarzenie tworzenia, aktualizacji lub usuwania dla zasobu obsługiwanego przez AWS Config, AWS Config Recorder zarejestruje zmianę konfiguracji jako CI dla tego zasobu w celu śledzenia zmian. Pamiętaj, że AWS Config jest usługą regionalną. Dlatego rozwiązanie należy wdrażać regionalnie.
2. Reguła EventBridge może przechwytywać powiadomienia o zdarzeniach Config CI Change dla rejestrowanych typów zasobów. Szablon CloudFormation zawiera parametr do ustawienia filtru wzorców zdarzeń dla określonych typów zasobów. Domyślnie wzorzec zdarzeń przechwyci wszystkie typy zasobów, które aktualnie rejestruje rejestrator konfiguracji. Rejestrator konfiguracji nie ma na to wpływu.
3. Po przechwyceniu reguła EventBridge przekazuje komunikat do kolejki SQS.
4. Kolejka SQS ma 10-minutowe opóźnienie w dostarczeniu, po czym wywołuje funkcję Lambda, która sprawdza wiadomość z kolejki SQS. 10-minutowe opóźnienie zapewnia wystarczający czas na propagację zdarzenia zmiany konfiguracji zasobów w CloudTrail.
5. Następnie funkcja Lambda wyodrębnia szczegóły zasobu z odpytanego komunikatu i wywołuje API CloudTrail LookupEvents na podstawie nazwy zasobu lub identyfikatora zasobu na 15 minut przed utworzeniem CI. Interfejs API LookupEvents zwraca skorelowane zdarzenia interfejsu API. Ponieważ rejestracja zasobów AWS Config Recorder zajmuje krótką chwilę, czas zdarzenia API będzie miał wcześniejszy znacznik czasu niż czas przechwytywania CI.
6. Na koniec funkcja Lambda wyodrębnia szczegóły zdarzenia, takie jak nazwa użytkownika, nazwa zdarzenia, czas zdarzenia itp. z pobranego zdarzenia API w celu dalszej automatyzacji. W tej wersji demo funkcja Lambda przeanalizuje szczegóły zdarzenia w postaci zwykłego tekstu, doda adresy URL konsoli Config i CloudTrail, które prowadzą do zdarzeń, i opublikuje je w temacie Amazon SNS.

Uwaga: W niektórych sytuacjach interfejs API LookupEvents nie będzie w stanie zwrócić zdarzenia związanego z nagranym CI; w ten sposób funkcja Lambda opublikuje tylko bezpośredni adres URL konsoli do CI zasobu bez szczegółów zdarzenia. Dzieje się tak, ponieważ niektóre typy zasobów nie obsługują obecnie interfejsu LookupEvents API według nazwy/identyfikatora zasobu, podczas gdy niektóre elementy CI zasobów mogły zostać zarejestrowane z powodu zmian w efemerycznych obciążeniach lub podczas okresu bazowego rejestratora konfiguracji; te operacje mogą nie mieć żadnego skorelowanego zdarzenia interfejsu API.

Wymagania wstępne

1. Upewnij się, że AWS Config jest włączony w regionie, w którym wdrażasz to rozwiązanie.
2. Upewnij się, że użytkownik tworzący stos ma uprawnienie cloudformation:CreateStack, podczas gdy rola usługi CloudFormation lub jednostka AWS Identity and Access Management (IAM) użyta do wdrożenia stosu posiada następujące uprawnienia:

Kroki, które należy wdrożyć w rozwiązaniu

1. Zapisz szablon YAML dostępny pod tym linkiem GitHub. W razie potrzeby możesz dostosować szablon do swojego przypadku użycia.
2. W konsoli CloudFormation wybierz „Utwórz stos” w regionie, w którym istnieje konfiguracja AWS Config.
3. Wybierz „Z nowymi zasobami” (standard).
4. Wybierz „Prześlij plik szablonu” i wybierz zapisany plik.
5. Wybierz „Dalej”.
6. Nadaj stosowi nazwę i podaj następujące parametry (możesz je zmienić w zależności od przypadku użycia):
7. Wybierz „Dalej”.
8. W następnej sekcji podaj rolę usługi CloudFormation z uprawnieniami do tworzenia zasobów żądanych w stosie. Jeśli nie podano żadnej roli usługi CloudFormation, stos użyje tej samej tożsamości, która tworzy stos do tworzenia zasobów. Rola powinna spełniać uprawnienia wymienione w sekcji wymagań wstępnych.
9. Wybierz „Dalej”.
10. Na ostatniej stronie zaznacz opcję: „Potwierdzam, że AWS CloudFormation może tworzyć zasoby IAM o niestandardowych nazwach.
11. Wybierz „Utwórz stos”.
12. Po utworzeniu stosu powinieneś zobaczyć następujące utworzone zasoby ze statusem stosu CREATE_COMPLETE:

• LookupCIEventsCloudWatchEventRule
• LookupCIEventsCloudWatchEventRuleOversized
• LookupCIEventsKMSCMK
• LookupCIEventsLambdaFunction
• LookupCIEventsLambdaFunctionEventSourceMapping
• LookupCIEventsLambdaFunctionEventSourceMappingDLQ
• LookupCIEventsLambdaFunctionExecutionRole
• LookupCIEventsLambdaFunctionLogGroup
• LookupCIEventsSNSTopic
• LookupCIEventsSQSPolicy
• LookupCIEventsSQSQueue
• LookupCIEventsSQSQueueDLQ

13. Domyślnie reguły zdarzeń EventBridge utworzone przez szablon CloudFormation są wyłączone.Ma to zapobiec przedwczesnemu przechwytywaniu powiadomień.Musisz umożliwić im wysyłanie powiadomień do SQS.Aby włączyć reguły zdarzeń EventBridge, przejdź do zakładki Resources stosu CloudFormation i wybierz łącze do konsoli EventBridge.Wybierz „Włącz”, aby uaktywnić regułę zdarzeń.Możesz wyłączyć reguły zdarzeń, gdy nie chcesz już przechwytywać i otrzymywać powiadomień.

Tworzenie subskrypcji tematu SNS

Po pomyślnym wdrożeniu szablonu CloudFormation, zostanie utworzony dla Ciebie temat SNS, do którego będą dostarczane powiadomienia. Musisz jednak utworzyć i skojarzyć subskrypcję dla tego tematu SNS w następujący sposób:

1. Otwórz konsolę Amazon SNS w tym samym regionie, na przykład „us-east-1”, w którym utworzyłeś stos CloudFormation.
2. Na stronie Tematy wybierz temat LookupCIEventsSNStopic.
3. W zakładce Subskrypcje wybierz „Utwórz subskrypcję”.
4. Z rozwijanej listy w obszarze Protokół wybierz dowolny typ punktu końcowego. W przypadku tego przykładu wybierz „E-mail”, aby otrzymać powiadomienie e-mail o zdarzeniu zmiany CI.
5. W obszarze Punkt końcowy wprowadź adres e-mail.
6. Na koniec wybierz „Utwórz subskrypcję”.

Następnie otrzymasz e-mail z linkiem do potwierdzenia subskrypcji. Wybierz łącze, aby zaakceptować. Zaczniesz otrzymywać powiadomienia SNS po przechwyceniu i przetworzeniu CI przez rozwiązanie. Oto przykładowy komunikat:

Konfigurowanie alarmów rozliczeniowych AWS

Oprócz powyższego rozwiązania możesz monitorować szacunkowe opłaty AWS za pomocą Amazon CloudWatch i tworzyć alarm rozliczeniowy. Alarm rozliczeniowy jest wyzwalany, gdy rozliczenia konta przekroczą określony przez Ciebie próg. Aby uzyskać instrukcje, zobacz Tworzenie alarmu rozliczeniowego, aby monitorować szacunkowe opłaty AWS. Możesz również sprawdzić liczbę elementów CI zarejestrowanych dla zasobu lub typu zasobu. Może to pomóc w zidentyfikowaniu zasobu, który wniósł większość opłat. Aby uzyskać niezbędne instrukcje, sprawdź Identyfikowanie zasobów większość zmian konfiguracji AWS Config.

Porządkowanie zasobów

Zasoby utworzone dla powyższej demonstracji są samowystarczalne w stosie CloudFormation. Usunięcie stosu spowoduje usunięcie wszystkich zasobów utworzonych przez stos. Aby usunąć stos, wykonaj następujące kroki:

1. W regionie, w którym wdrożono ten stos, przejdź do konsoli CloudFormation.
2. Wybierz panel „Stosy” po lewej stronie, a następnie wybierz nazwę stosu.
3. W prawym górnym rogu widoku stosu wybierz „Usuń”, aby rozpocząć usuwanie stosu.
4. Możesz śledzić postęp usuwania w zakładce „Zdarzenia”. Po usunięciu stosu status stosu zmieni się na „DELETE_COMPLETE”.

Wnioski

Za pomocą tego artykułu twórcy zaproponowali przykładowe rozwiązanie, aby wzmocnić wykrywanie i reakcję na główną przyczynę zmiany elementu konfiguracji zasobów AWS Config (CI). Dzięki przykładowemu rozwiązaniu nauczyłeś się programowo wyszukiwać zdarzenia związane ze zmianami CI w AWS CloudTrail, wyodrębniać informacje, takie jak zleceniodawca użytkownika, który dokonał zmiany ze zdarzenia, i wysyłać informacje do tematu AWS SNS jako naprawę. Kod jest dostępny w serwisie GitHub. Możesz dostosować to rozwiązanie i dodać dodatkowe środki zaradcze, takie jak wykonanie dodatkowego wyszukiwania ostatnich wywołań API wykonanych przez podmiot zasadniczy użytkownika lub automatyczne dołączenie restrykcyjnej polityki do podmiotu użytkownika, jeśli zmiana zasobu była nieautoryzowana. Jeśli masz jakiekolwiek pytania dotyczące tego rozwiązania, możesz również skontaktować się z pomocą techniczną AWS.

Źródło: AWS