Analiza i zrozumienie wykorzystania roli IAM z Amazon Detective

W tym poście pokażemy, w jaki sposób można wykorzystać funkcję analizy ról Amazon Detective do badania wyników dotyczących bezpieczeństwa, które są powiązane z wykorzystaniem ról AWS Identity and Access Management (IAM).

Dowiesz się, jak możesz użyć tej funkcji, aby określić, który zasób Amazon Web Services (AWS) przyjął rolę, która wywołała alarm, oraz zrozumieć kontekst działań, które zasób wykonywał, gdy alarm został uruchomiony .

W wyniku tego przewodnika dowiesz się, jak szybko ustalić anomalną tożsamość wzorce zachowań. Chociaż ta demonstracja wykorzystuje wniosek Amazon GuardDuty jako punkt wyjścia, techniki przedstawione w tym poście podkreślają, w jaki sposób można wykorzystać Detective do badania wszelkich wzorców zachowań związanych z korzystaniem z ról IAM.

Role IAM zapewniają cenny mechanizm, którego można użyć do delegowania dostępu użytkowników i usług w celu zarządzania zasobami AWS i uzyskiwania do nich dostępu, ale korzystanie z ról IAM może to skomplikować. Logi AWS CloudTrail śledzą akcje powiązane z rolami IAM, ale przypisywanie aktywności do określonego zasobu, który przyjął rolę, wymaga przechowywania logów CloudTrail i ich analizy. Zrozumienie użycia roli poprzez analizę logów staje się jeszcze bardziej złożone, jeśli w grę wchodzą założenia dotyczące ról dla wielu kont, ponieważ wymaga to zestawiania i analizowania logów z wielu kont. W niektórych przypadkach uprawnienia mogą umożliwić zasobowi sekwencyjne przejmowanie szeregu różnych ról (łączenie ról), co dodatkowo komplikuje przypisanie działania do określonego zasobu.

Dzięki wbudowanej analizie logu dla wielu kont nowa funkcja analizy ról Detective zapewnia wgląd w użycie ról, założenia dotyczące ról między kontami oraz wszelkie czynności związane z łączeniem ról, które mogły zostać wykonane na tych kontach. Dzięki tej funkcji można szybko określić, kto lub co przyjął rolę, niezależnie od tego, czy był to użytkownik oddelegowany, użytkownik IAM, czy inny zasób. Ta funkcja pokazuje, kiedy przyjęto role, na jak długo, i pomaga określić czynności, które zostały wykonane podczas tego założenia. Detective wizualizuje te wyniki na podstawie automatycznej analizy logów CloudTrail i ruchu w VPC flow log, które stale przetwarza dla włączonych kont, niezależnie od tego, czy te źródła logów są włączone na każdym koncie.

Aby zademonstrować tę funkcję, zbadamy alarm „CloudTrail logging disabled”, który jest wywoływany przez Amazon GuardDuty, w wyniku działania wykonywanego przez zasób, który przyjął rolę IAM. Amazon GuardDuty to usługa AWS, która stale monitoruje złośliwe lub nieautoryzowane zachowanie w celu ochrony zasobów AWS, w tym kont AWS, kluczy dostępu i instancji EC2. GuardDuty identyfikuje nietypowe lub nieautoryzowane działania, takie jak wydobywanie kryptowalut, dostęp do danych przechowywanych w S3 z nietypowych lokalizacji lub wdrażanie infrastruktury w regionie, który nigdy nie był używany.

Rozpoczęcie “śledztwa” w GuardDuty

GuardDuty wystawia alert CloudTrailLoggingDisabled, aby ostrzec Cię, że logowanie CloudTrail zostało wyłączone na jednym z Twoich kont. To ważna informacja, ponieważ może oznaczać, że atakujący próbuje ukryć swoje ślady. Ponieważ Detective otrzymuje kopię ruchu CloudTrail bezpośrednio z infrastruktury AWS, będzie nadal odbierać wywołania API, które są wykonywane po wyłączeniu rejestrowania CloudTrail.

Aby właściwie zbadać tego typu ustalenia i określić, czy jest to problem, którego należy się obawiać, należy odpowiedzieć na kilka szczegółowych pytań:

1. Musisz określić, który użytkownik lub zasób wyłączył CloudTrail.
2. Będziesz musiał sprawdzić, jakie inne czynności wykonano po wyłączeniu rejestrowania.
3. Będziesz chciał zrozumieć, czy wzorzec dostępu i zachowania są zgodne z wcześniejszymi wzorcami i zachowaniami.

Przyjrzymy się wynikowi CloudTrailLoggingDisabled w GuardDuty, gdy zaczniemy próbować odpowiedzieć na te pytania. Po uzyskaniu dostępu do konsoli GuardDuty wyświetlana jest lista ostatnich „znalezisk”. Na rysunku 1 zastosowano filtr w celu wyświetlenia wyniku CloudTrailLoggingDisabled.

Rysunek 1: Wniosek GuardDuty pokazujący, że funkcja CloudTrail została wyłączona

Po wybraniu wniosku GuardDuty można wyświetlić szczegóły, w tym niektóre informacje o użytkowniku związanego z alertem. Rysunek 2 przedstawia sekcję wniosku dotyczącą Resources affected.

Rysunek 2: Przeglądanie danych użytkownika związanych z wynikami GuardDuty

Pole Affected resources, wskazuje, że ścieżka demo-trail-2 znajdowała się w miejscu, w którym rejestrowanie zostało wyłączone. Możesz również zobaczyć, że User type jest ustawiony na AssumedRole, a User name zawiera rolę AWSReservedSSO_AdministratorAccess_598c5f73f8b2b4e5. To była rola, którą przyjęto i przy użyciu której logowanie CloudTrail zostało wyłączone. Te informacje mogą pomóc w zrozumieniu zasobów, do których ta rola deleguje dostęp, oraz uprawnień, które zapewnia. Nadal musisz określić, kto konkretnie przejął tę rolę, aby wyłączyć rejestrowanie CloudTrail i czynności, które wykonano później. Możesz użyć Amazon Detective, aby odpowiedzieć na te pytania.

Zbadanie odkrycia w Detective

Aby zbadać odkrycie GuardDuty w usłudze Detective, należy wybrać wynik, a następnie wybrać opcję Investigate w menu Actions, jak pokazano na rysunku 3.

Rysunek 3: Wybierz ‘Investigate with Detective’ i wybierz identyfikator wyniku GuardDuty w wyskakującym okienku, aby zbadać wynik

Wyświetlenie strony profilu wyniku

Wybranie akcji Investigate dla wyniku CloudTrailLoggingDisabled w GuardDuty otwiera stronę profilu wyniku w konsoli Detective, jak pokazano na rysunku 4. Detective ma formę strony profilu, która wyświetla podsumowania i analizy zebrane z logów CloudTrail, logów VPC oraz wyniki GuardDuty dotyczące zasobów AWS, adresów IP i użytkowników.

Każda strona profilu może wyświetlać (do 12 miesięcy) informacje dotyczące wybranego zasobu i ma na celu pomóc badaczowi w przejrzeniu i zrozumieniu zachowania zasobu lub w szybkim segregowaniu i zagłębianiu się w potencjalne problemy. Detective nie wymaga, aby klient włączył logowanie CloudTrail lub VPC Flow w celu pobrania tych danych i zapewnia widoczność przez te 12 miesięcy niezależnie od zasad przechowywania lub archiwizacji logów.

Rysunek 4: Wyświetlanie wyniku GuardDuty w usłudze Detective

Zakres czasu

Aby pomóc skupić się na dochodzeniu, Detective domyślnie ustawia zakres czasu, a tym samym informacje wyświetlane w profilu wyszukiwania, tak aby obejmowały okres od utworzenia znaleziska do ostatniej aktualizacji. W przypadku tych wyników, zakres czasowy obejmuje 1-godzinny okres. Możesz zmienić zakres czasu, wybierając ikonę kalendarza w prawym górnym rogu strony, jeśli chcesz sprawdzić dodatkowe informacje przed lub po utworzeniu wyniku. Domyślny zakres czasu jest wystarczający do tego badania, więc możemy go pozostawić bez zmian.

Przegląd sesji roli

Detective używa zakładek do grupowania informacji na stronach profilów i dla tych wyników domyślnie wyświetla zakładkę przeglądu sesji roli. Sesja ról przedstawia działania i zachowanie zasobu, który przyjął rolę związaną z naszym odkryciem. W tym przypadku rolę przejął ktoś o nazwie użytkownika sara, jak pokazano w polu Assumed. (Zakładamy, że imię użytkownika to Sara). Analizując informacje o sesji ról w logach CloudTrail, Detective był w stanie natychmiast zidentyfikować, że sara była użytkownikiem, który wyłączył rejestrowanie CloudTrail i spowodował wywołanie alarmu.

Zanim przejdziemy do odpowiedzi na resztę pytań dotyczących tego, co zrobiła Sara po wyłączeniu rejestrowania i czy zmieniło się jej zachowanie, omówmy bardziej szczegółowo sesje ról. Każda sesja roli ma nazwę sesji roli, w tym przypadku sara, i unikalny identyfikator sesji roli. Identyfikator sesji roli to identyfikator przyjmowanej roli oraz nazwa sesji roli, połączone razem. Dobre praktyki nakazują, aby w przypadku określonej roli przyjmowanej przez określony zasób nazwa sesji roli reprezentowała nazwę użytkownika IAM lub użytkownika federacyjnego albo zawierała inne przydatne informacje o zasobie, który przejął tę rolę (więcej informacji zawiera sekcja Naming of individual IAM role sessions). W tym przypadku, ponieważ przestrzegane są najlepsze praktyki, Detective może śledzić działania i zachowanie użytkownika Sara za każdym razem, gdy przyjmuje rolę AWSReservedSSO_AdministratorAccess_598c5f73f8b2b4e5.

Detective śledzi statystyki, na przykład kiedy po raz pierwszy zaobserwowano sesję roli (październik w przypadku Sary, dla tej roli), a także wykonywane czynności i spostrzeżenia behawioralne, takie jak geolokalizacje, w których Sara przyjęła rolę. Świadomość, że Sara przyjęła tę rolę wcześniej, jest przydatna, ponieważ możesz teraz ocenić, czy jej użycie roli zmieniło się w 1-godzinnym oknie zakresu, na który patrzysz teraz, w porównaniu ze wszystkimi jej wcześniejszymi przyjęciami tej roli.

Przeglądanie zmian we wzorcach dostępu i czynnościach użytkownika Sara

Detective śledzi zmiany w dostępie geograficznym i operacjach na karcie New behavior. Wybierzmy kartę New behavior dla sesji roli, aby wyświetlić te informacje, jak pokazano na rysunku 5.

Rysunek 5: Przeglądanie nowego zachowania sesji roli

Podczas śledztwa ustalenie, że wzorce dostępu uległy zmianie, może być pomocne w wyróżnieniu złośliwej aktywności. Ponieważ Detective śledzi przyjęcie roli AWSReservedSSO_AdministratorAccess_598c5f73f8b2b4e5 przez Sarę, jest w stanie pokazać lokalizację, w której przyjęła Ona tę rolę i czy miało to miejsce z tego samego miejsca co poprzednie.

Na rysunku nr 5 widać, że Sara w przeszłości przyjmowała rolę AWSReservedSSO_AdministratorAccess_598c5f73f8b2b4e5 z Bellevue w stanie Waszyngton i Ashburn w stanie Wirginia, ponieważ te obszary geograficzne są pokazane na niebiesko. Gdyby przyjęła tę rolę z nowej lokalizacji, byłaby ona oznaczona na mapie kolorem pomarańczowym. Ponieważ wywołania interfejsu API wykonywane przez tego użytkownika pochodzą z wcześniej zaobserwowanej lokalizacji, jest bardzo mało prawdopodobne, że dane logowania użytkownika zostały naruszone. Dokonanie tego ustalenia poprzez ręczną analizę logów CloudTrail byłoby znacznie bardziej czasochłonne.

Inne informacje, które można zebrać na karcie sesji New behawior, obejmują nowo obserwowane wywołania API, wywołania API o zwiększonej objętości, nowo obserwowane organizacje systemów autonomicznych i nowo obserwowanych user-agent’ów. Warto mieć możliwość sprawdzenia, czy operacje wykonywane przez użytkownika Sara w bieżącym okresie czasu są względnie zgodne z operacjami, które wykonywała w przeszłości. To pomaga nam być bardziej pewnym, że to rzeczywiście Sara prowadziła tę działalność.

Zbadanie aktywności użytkownika Sara w interfejsie API

Po ustaleniu, że wzorzec dostępu i działania użytkownika Sara są zgodne z poprzednim zachowaniem, użyjmy funkcji Detective, aby dokładniej przyjrzeć się aktywności Sary, co pozwoli określić, czy przypadkowo wyłączyła logowanie CloudTrail, czy też za jej działaniem stoi złośliwy zamiar.

Jak zbadać działania użytkownik:

1. Na stronie profilu wyszukiwania, z listy rozwijanej u góry ekranu wybierz opcję Overview: Role Session, aby wrócić do karty Overview sesji roli.

Rysunek 6: Przejście na stronę ‘Overview: Role Session’

2. Po otwarciu karty Przegląd przejdź do panelu Overall API call volume.

Rysunek 7: Przechodzenie do panelu ‘Overall API call volume’

Ten panel wyświetla wykres udanych i nieudanych wywołań API, które wykonała Sara, gdy przyjęła rolę AWSReservedSSO_AdministratorAccess_598c5f73f8b2b4e5. Wykres przedstawia czarny prostokąt wokół działań, które zostały wykonane w zakresie czasu CloudTrail. Wyświetla również działania historyczne i pokazuje linię bazową na wykresie, dzięki czemu możesz zrozumieć, jak aktywnie wykorzystuje przyznane jej uprawnienia, przyjmując tę rolę.

3. Wybierz przycisk display details for scope time, aby pobrać szczegóły wywołań API, które zostały wywołane przez Sarę, aby można było określić jej działania po wyłączeniu rejestrowania CloudTrail.

Rysunek 8: Wyświetlanie szczegółów w oparciu o zakres czasu

Teraz zobaczysz rozwinięty panel Overall API call volume, pokazujący wszystkie adresy IP, wywołania API i klucze dostępu używane przez Sarę w przedziale czasowym tego wyniku.

4. Wybierz zakładkę API method, aby zobaczyć listę wszystkich wykonanych wywołań API.

Rysunek 9: Przeglądanie wywołań w API method

W tym czasie wykonała tylko dwa wywołania API: StopLogging i AssumeRole. Wiesz już, że Sara wyłączyła logowanie CloudTrail, ale nie wiedziałeś, że przejęła inną rolę. Gdy użytkownik przyjmuje rolę, podczas gdy przyjął już jakąś wcześniej, nazywa się to łączeniem ról. Chociaż można użyć łączenia ról, kiedy użytkownik potrzebuje dodatkowych uprawnień, można go również użyć do ukrycia działań. Ponieważ nie wiemy, jakie inne czynności wykonała Sara po przyjęciu tej drugiej roli, przejdźmy dalej. To może rzucić światło na to, dlaczego zdecydowała się wyłączyć rejestrowanie CloudTrail.

Zbadanie wykorzystania mechanizmu łączenia ról

Aby dowiedzieć się więcej o tym, jak Sara korzysta z łączenia ról, przyjrzyjmy się innej roli, którą przyjęła podczas tej sesji.

Jak wyświetlić inną rolę użytkownika:

1. Przejdź z powrotem na górę strony profilu wyszukiwania. W panelu Role session details wybierz AWSReservedSSO_AdministratorAccess_598c5f73f8b2b4e5.

Rysunek 10: Znajdowanie nazwy ‘Assumed role’

Detective wyświetla stronę profilu AWS Role dla tej roli i możesz teraz zobaczyć aktywność, która miała miejsce we wszystkich zasobach, które przyjęły tę rolę. Aby wyróżnić informacje, które są istotne dla ram czasowych Twojego dochodzenia, Detective utrzymuje Twój zakres czasu podczas przechodzenia ze strony profilu wyszukiwania CloudTrailLoggingDisabled na tę stronę profilu roli.

2. Celem przejścia na tę stronę jest ustalenie, jaką inną rolę przyjęła Sara po przyjęciu roli AWSReservedSSO_AdministratorAccess_598c5f73f8b2b4e5, wybierz więc zakładkę Resource interaction. Na tej karcie zobaczysz następujące trzy panele: Resources that assumed this role, Assumed roles oraz Sessions involved. Na rysunku 11 można zobaczyć panel Resources that assumed this role, który zawiera listę wszystkich zasobów AWS, które przyjęły tę rolę, ich typ (instancja EC2, użytkownik federacyjny lub IAM, rola IAM), konto oraz kiedy przyjęli tę rolę po raz pierwszy i ostatni. Sara jest na tej liście, ale Detective nie pokazuje obok niej konta AWS, ponieważ sfederowani użytkownicy nie są powiązani z konkretnym kontem. Pole konta jest wypełniane dla innych typów zasobów, które są wyświetlane w tym panelu i mogą być przydatne do zrozumienia przyjęć ról typu cross-account.

Rysunek 11: Przeglądanie zasobów, które przyjęły rolę

3. Na tej samej karcie Resource Interaction, przewijając w dół, zobaczysz panel Assumed Roles (Rysunek 12), który pomaga zrozumieć tworzenie łańcuchów ról, wymieniając inne role, które zostały przyjęte przez rolę AWSReservedSSO_AdministratorAccess_598c5f73f8b2b4e5. W tym przypadku rola przyjęła kilka innych ról, w tym DemoRole1 w tym samym oknie czasowym, w którym wystąpiło wykrycie CloudTrailLoggingDisabled.

Rysunek 12: Przeglądanie przyjętych ról

4. Na rysunku nr 13 można zobaczyć panel Sessions involved, który przedstawia sesje ról dla wszystkich zasobów, które przyjęły tę rolę, oraz sesje ról, w których ta rola przyjęła inne role w bieżącym zakresie czasu. Zobaczysz dwie sesje ról z nazwą sesji sara, jedną, w której Sara przyjęła rolę AWSReservedSSO_AdministratorAccess_598c5f73f8b2b4e5, a drugą, w której AWSReservedSSO_AdministratorAccess_598c5f73f8b2b4e5 przyjęła rolę DemoRole1.

Rysunek 13: Przeglądanie sesji ról, których dotyczyła ta rola

Teraz, gdy wiesz, że Sara również użyła roli DemoRole1 podczas swojej sesji ról, przyjrzyjmy się bliżej, jakie działania wykonała.

Wyświetlanie operacji interfejsu API, które zostały wywołane w ramach połączonej roli

Na tym etapie zobaczymy aktywność Sary w roli DemoRole1, koncentrując się na wywołaniach interfejsu API.

Jak wyświetlić aktywność użytkownika w innej roli:

1. W panelu Sessions involved, w kolumnie Session name, znajdź wiersz, w którym DemoRole1 to wartość Assumed Role. Wybierz nazwę sesji w tym wierszu: sara, aby przejść do strony profilu sesji roli.

2. Najbardziej zainteresują Cię metody API, które zostały wywołane podczas tej sesji roli, które możesz przejrzeć w panelu Overall API call volume. Jak pokazano na Rysunku 14, możesz zobaczyć, że Sara korzystała już wcześniej z DemoRole1 , ponieważ przed wywołaniami w naszym zakresie czasu są obecne inne wywołania.

3.Wybierz display details for scope time w panelu Overall API call volume, a następnie wybierz zakładkę API method.

Rysunek 14: Przeglądanie wywołań roli w API

Na Rysunku nr 14 widać, że wykonano wywołania metod API DescribeInstances i RunInstances. Teraz już wiesz, że Sara określiła typ instancji Amazon Elastic Compute Cloud (Amazon EC2), które działały na Twoim koncie, a następnie pomyślnie utworzyła instancję EC2, wywołując metodę RunInstances. Możesz również zobaczyć, że w ramach sesji wykonano udane i nieudane wywołania metody interfejsu API AttachRolePolicy. Może to być próba podniesienia uprawnień na koncie i uzasadnia dalsze badanie działań użytkownika.

Jako badacz ustaliłeś, że Sara była użytkownikiem, który wyłączył logowanie CloudTrail i że jej wzorzec dostępu był zgodny z jej wcześniejszymi dostępami. Określiłeś również inne czynności, które wykonywała po tym, jak wyłączyła logowanie i przyjęła drugą rolę, ale możesz kontynuować badanie, odpowiadając na dodatkowe pytania, takie jak:

• Co Sara zrobiła z DemoRole1, kiedy przejęła tę rolę w przeszłości? Czy jej obecna działalność jest spójna z wcześniejszą?
• Jakie działania są wykonywane na tym koncie? Czy są one zgodne z działaniami Sary?

Korzystając z funkcji Detective, które zostały zademonstrowane w tym poście, będziesz w stanie odpowiedzieć na pytania, takie jak te wymienione powyżej.

Podsumowanie

Mamy nadzieję, że po przeczytaniu tego posta lepiej zrozumiesz, w jaki sposób Amazon Detective zbiera, organizuje i prezentuje dane logów, aby uprościć dochodzenie w sprawach bezpieczeństwa. Wszystkie subskrypcje usług Detective obejmują nowe możliwości analizy sesji ról. Dzięki tym możliwościom można szybko przypisać działania wykonywane w ramach roli do określonego zasobu w środowisku, namierzyć przyjęcia ról między kontami, określić zachowanie łańcuchów ról i szybko zobaczyć wywołania interfejsów API.

Wszyscy klienci otrzymują 30-dniowy bezpłatny okres próbny po włączeniu usługi Amazon Detective. Zobacz stronę AWS Regional Services aby zobaczyć listę wszystkich regionów, w których dostępna jest usługa Detective. Aby dowiedzieć się więcej, odwiedź stronę produktu Amazon Detective lub zapoznaj się z dodatkowymi zasobami na końcu tego posta, aby jeszcze bardziej poszerzyć swoją wiedzę na temat możliwości i funkcji Detective.

Dodatkowe źródła:

• Amazon Detective features
• Amazon Detective overview and demo
• Amazon Detective FAQs
• Amazon Detective Regions, endpoints, and quotas
• Naming of individual IAM role sessions

źródło: AWS