Kontrola i ostrzeganie o awaryjnym dostępie w Organizacji AWS

Organizacje budujące systemy na skalę korporacyjną wymagają skonfigurowania bezpiecznej i zarządzanej strefy docelowej (landing zone) w celu wdrażania i obsługi swoich systemów.

Strefa docelowa to punkt wyjścia, z którego organizacja może szybko uruchamiać i wdrażać obciążenia i aplikacje, mając pewność co do bezpieczeństwa i środowiska infrastruktury, zgodnie z opisem w sekcji Czym jest strefa docelowa? Nationwide Building Society (Nationwide) jest największym na świecie towarzystwem budowlanym. Jest własnością 16 milionów członków i istnieje, aby służyć ich potrzebom. Towarzystwo jest jednym z największych dostawców kredytów hipotecznych, oszczędnościowych i bieżących w Wielkiej Brytanii, a także głównym dostawcą ISA, kart kredytowych, pożyczek osobistych, ubezpieczeń i inwestycji.

W ramach jednej ze swoich inicjatyw biznesowych Nationwide wykorzystuje AWS Control Tower do budowania i obsługi strefy docelowej, która zapewnia dobrze ugruntowany wzorzec do konfigurowania i zarządzania bezpiecznym, wielokontowym środowiskiem AWS. Nationwide działa w branży o wysokim stopniu regulacji, a gwarancja zarządzania wymaga odpowiedniej kontroli nad każdym uprzywilejowanym dostępem do danych z linii produkcyjnej lub do zasobów, które mają do nich dostęp. Twórcy zdecydowali się na tę konkretną inicjatywę biznesową, aby wdrożyć swoją strefę docelową wykorzystując AWS Organizations, korzystać z ciągłego zarządzania kontem i zwierzchnictwa zgodnie z najlepszymi praktykami wdrażania AWS.

Wykorzystano również jednokrotne logowanie AWS (AWS SSO), aby utworzyć tożsamości naszych pracowników w AWS i centralnie zarządzać dostępem w całej organizacji AWS. W tym artykule autorzy opisują integracje wymagane w AWS Control Tower i AWS SSO w celu wdrożenia mechanizmu „break-glass”, który umożliwia publikowanie raportów dostępu dla operatorów systemów, a także dla systemów i procesów audytu wewnętrznego. Dowiesz się, w jaki sposób użyto AWS SSO do konfiguracji, a także trzy rozważane opcje architektury i dlaczego wybrano konkretne rozwiązanie.

Pozyskiwanie danych dostępu AWS SSO do monitorowania w czasie zbliżonym do rzeczywistego

W przypadku omawianej konfiguracji dostępnych jest wiele kont AWS oraz ścieżek na każdym z tych kont. Użytkownicy będą regularnie nawigować po wielu kontach podczas obsługi infrastruktury, a ich „podróże” są oznaczone na wielu ścieżkach. Zazwyczaj AWS CloudTrail jest wybranym zasobem do jasnej i jednoznacznej identyfikacji dostępu do konta lub danych. Kluczowym wyzwaniem w tym scenariuszu było zaprojektowanie wydajnego i opłacalnego rozwiązania do skanowania tych śladów, aby pomóc zidentyfikować i raportować dostęp awaryjny użytkowników do danych księgowych i produkcyjnych. Aby sprostać temu wyzwaniu, opracowano dwie następujące opcje projektowania architektury.

Opcja nr 1: Zdecentralizowane podejście, które wykorzystuje AWS CloudFormation StackSets, Amazon EventBridge i AWS Lambda

Rozwiązanie wymagało zdecentralizowanego podejścia poprzez wdrożenie CloudFormation StackSet do tworzenia, aktualizowania lub usuwania stosów na wielu kontach i regionach AWS za pomocą jednej operacji. Stackset stworzył reguły Amazon EventBridge i docelowe funkcje AWS Lambda. Te funkcje są publikowane w EventBridge na koncie audytu. Wspomniane konto audytowe zawiera zestaw funkcji Lambda uruchamianych z EventBridge w celu inicjowania określonych zdarzeń, formatowania wiadomości o zdarzeniu i wysyłania do Slacka –scentralizowanej platformy komunikacyjnej dla tej implementacji. Rysunek nr 1 przedstawia ogólną architekturę tej opcji.

Rysunek 1: Zdecentralizowane logowanie za pomocą Amazon EventBridge i AWS Lambda

Opcja nr 2: Użyj śladu organizacji na koncie Zarządzania Organizacją

Ta opcja korzysta ze scentralizowanej ścieżki organizacyjnej na koncie zarządzania organizacją do źródła danych audytu. Szczegóły dotyczące tworzenia śladu organizacji można znaleźć w AWS CloudTrail User Guide. CloudTrail został skonfigurowany do wysyłania rejestru zdarzeń do CloudWatch Logs. Zdarzenia te są następnie wysyłane za pomocą funkcji Lambda do Slacka za pomocą webhooków. Użyto publicznego modułu terraform w wybranym repozytorium GitHub, aby zbudować tę integrację Lambda – Slack. Rysunek nr 2 przedstawia ogólną architekturę tej opcji.

Rysunek 2: Scentralizowany wzorzec logowania za pomocą Amazon CloudWatch

To była opcja preferowana przez autorów i w końcu została przez nich wdrożona.

Twórcy ocenili również trzecią opcję, która polegała na użyciu funkcji scentralizowanego rejestrowania i audytu dostępnej w Control Tower. Użytkownicy uwierzytelniają i federalizują z kontami docelowymi z centralnej lokalizacji, więc wydawało się, że można uzyskać te informacje ze scentralizowanych rejestrów. Te zdarzenia rejestrów są jednak dostarczane jako skompresowane obiekty json .gz, co oznaczało konieczność wielokrotnego rozszerzania tych archiwów w celu sprawdzenia. Dlatego też autorzy zrezygnowali z tej opcji.

Scentralizowane, ekonomiczne, rozszerzalne rozwiązanie ostrzegające o awaryjnym SSO

Wymaganiem twórców było zidentyfikowanie dostępu typu „break-glass” we wszystkich mechanizmach dostępu obsługiwanych przez AWS, w tym dostęp do CLI i User Portal. Aby zapewnić kompleksową ochronę we wszystkich mechanizmach dostępu, zidentyfikowano wszystkie zdarzenia zainicjowane dla każdego mechanizmu dostępu:

1. Zdarzenia dostępu do portalu użytkownika/konsoli AWS

• Authenticate
• ListApplications
• ListApplicationProfiles
• Federate — to zdarzenie zawiera rolę, z którą użytkownik się utożsamia

2. Zdarzenia dostępu do CLI

• CreateToken
• ListAccounts
• ListAccountRoles
• GetRoleCredentials – to zdarzenie zawiera rolę, z którą użytkownik się utożsamia.

EventBridge jest w stanie inicjować akcje po zdarzeniach tylko wtedy, gdy zdarzenie próbuje dokonać zmian (gdy atrybut „readOnly” w treści rekordu zdarzenia ma wartość „false”).

Zespół wsparcia AWS był świadomy tego atrybutu i zalecił autorom zmianę przepływu danych, którego używano, na taki, który jest w stanie inicjować akcje po dowolnym zdarzeniu, niezależnie od wartości atrybutu readOnly. Rozwiązaniem w tym przypadku okazało się przesłanie logów CloudTrail do CloudWatch Logs. To następnie inicjuje funkcję Lambda poprzez subskrypcję filtra, która wykrywa żądane nazwy zdarzeń w treści dziennika.

Ze względu na rozmiar pytania w zapytaniach CloudWatch Log konieczne było usunięcie filtrów subskrypcji i wykonanie analizy zawartości linii logu wewnątrz funkcji lambda. Aby określić, które konta będą inicjować powiadomienia, wysłano do niego listę kont i ról jako zmienną środowiskową w czasie wykonywania programu.

Rozważania dotyczące dostępu jednokrotnego do wielu kont

Dzięki bezpośredniej federacji użytkownicy otrzymują token dostępu. Jest to najbardziej oczywiste w przypadku pojedynczego logowania AWS na stronie chiclet jako „Wiersz poleceń lub dostęp programowy”. Tokeny SSO mają ograniczony czas życia (domyślnie używa się 1 godziny). Użytkownik nie musi uzyskiwać nowego tokena, aby uzyskać dostęp do zasobu docelowego, dopóki ten, którego używa, nie wygaśnie. Oznacza to, że użytkownik może wielokrotnie uzyskiwać dostęp do konta docelowego przy użyciu tego samego tokena w trakcie jego życia. Chociaż token jest udostępniany na stronie chiclet, zdarzenie GetRoleCredentials nie występuje, dopóki nie zostanie użyte do uwierzytelnienia wywołania interfejsu API na docelowym koncie AWS.

Wnioski

W tym artykule autorzy omówili, w jaki sposób AWS Control Tower i AWS Single Sign-on umożliwiły Nationwide zbudowanie i zarządzanie bezpiecznym, wielokontowym środowiskiem AWS dla jednej z ich inicjatyw biznesowych oraz scentralizowanie zarządzania dostępem w całej implementacji. Integracja była ważna dla twórców dla dokładnej i kompleksowej identyfikacji i audytu dostępu awaryjnego dla wdrożenia. W rezultacie autorzy byli w stanie spełnić wymagania dotyczące audytu bezpieczeństwa i zgodności w zakresie uprzywilejowanego dostępu do kont AWS.

źródło: AWS