AWS Identity and Access Management jest nieodłącznym elementem składowym bezpieczeństwa w chmurze AWS. Odpowiada za zarządzanie tym, “kto” może robić “co” na “czym”. Jeżeli nasza konfiguracja IAM jest wadliwa, atakujący może obejść lub zmodyfikować pozostałe zabezpieczenia, takie jak Security Groups, CloudTrail czy MFA użytkowników IAM.
Oznacza to tyle, że brak poprawnej konfiguracji w AWS IAM może prowadzić do eskalacji uprawnień (privilege escalation) i zwiększenia zasięgu ataku (blast radius) w przypadku udanego włamania. Aby zminimalizować to ryzyko, można zastosować wiele różnych metod. W tym artykule skupię się jednak na kilku elementarnych, skutecznych i niezbędnych podejściach pozwalających na wstępne zabezpieczenie i “utwardzenie” (hardening) systemu w chmurze AWS. Natomiast lista tych podejść i dobrych praktyk nie jest wyczerpująca i stanowi tylko wstęp do tematyki bezpieczeństwa chmury publicznej.
“Principle of Least Privilege” i czemu jest często łamana?
Jednym z podstawowych podejść jest PoLP, czyli “Principle of Least Privilege”. Jest to dobra praktyka stosowana powszechnie w systemach informatycznych, nie tylko tych chmurowych. Główną ideą jest nadawanie pryncypałom (użytkownikom, rolom itp.) tylko takich uprawnień, które są im niezbędne do wykonania zadania. W razie potrzeby, uprawnienia te po prostu zwiększamy.
W skrócie można rozumieć to podejście jako “nienadawanie uprawnień na zapas”. O ile brzmi to dość intuicyjnie, to ze względu na wygodę deweloperów i presję czasu na projektach zasada ta jest regularnie naruszana. Wielokrotnie deweloperzy nie wiedzą, jakich dokładnie uprawnień potrzebuje ich aplikacja, a administratorzy nie wiedzą, jakich dostępów wymagają różne zespoły (np. deweloperzy, inżynierowie danych, data scientists). Prowadzi to do sytuacji, w której często nadużywane są wszelkiego rodzaju “wildcardy” (iam:*, s3:* itp.), ponieważ jest to wygodniejsze, szybsze i “po prostu działa”, natomiast jest to mniej bezpieczne.
Właściwym podejściem byłoby ustalenie minimalnych, bazowych uprawnień i utrzymywanie ścisłego kontaktu z użytkownikami, aby je iteracyjnie rozszerzać w miarę potrzeb, co zostało przedstawione na powyższej grafice. Wymaga to jednak nie tylko dobrej woli ze strony inżynierów, ale też zarezerwowania odpowiedniej ilości czasu na zdefiniowanie ról oraz sprawnej komunikacji między administratorem a użytkownikiem.
Przykład eskalacji uprawnień przez zbyt permisywną IAM rolę instancji Jenkinsa
W mojej karierze zawodowej miałem do czynienia z ciekawym przypadkiem eskalacji uprawnień, dokonywanej wewnętrznie w firmie przez deweloperów. Wynikało to z faktu, że nie chciano nadać im uprawnień administratorów do systemu. Po wykryciu, podatność ta została załatana, ale sam mechanizm prezentował się następująco: deweloperzy mieli dostęp do terminala instancji Jenkinsa postawionej na EC2, na wypadek, gdyby potrzebowali w niej coś skonfigurować lub zresetować. W teorii Jenkins odpowiadał jedynie za deployowanie platformy danych i nie wykonywał żadnych bardziej skomplikowanych operacji niż wywoływanie Terraform czy budowanie obrazów Dockera.
W rzeczywistości jednak IAM Rola przypisana do profilu tej instancji EC2 miała pełne uprawnienia do całego konta AWS poprzez umieszczenie wildcardów * w IAM policy. Prawdopodobnie była to pozostałość z wczesnej fazy projektu, kiedy dopiero przygotowywano środowisko CI/CD. Oznaczało to tyle, że o ile deweloperzy nie mieli bezpośrednio wielu uprawnień w AWS (np. do IAM), to i tak mogli je modyfikować, logując się do instancji Jenkinsa i używając AWS CLI. De facto eskalowali swoje uprawnienia ze zwykłych deweloperów do poziomu pełnego administratora.
W konsekwencji uprawnienia dla CI/CD zredukowano i wyznaczono konkretną osobę do zarządzania instancją Jenkinsa, która i tak posiadała już uprawnienia administratorskie. Gdyby taką podatność wykorzystał atakujący z zewnątrz, dostęp do konta zwykłego dewelopera skompromitowałby zabezpieczenia całej platformy danych.
Przykład eskalacji uprawnień wynikający z braku Permission Boundaries i zbyt permisywnego dostępu do IAM
Innym, bardziej podręcznikowym przykładem eskalacji uprawnień i idącego za tym zwiększenia blast radius, jest nieumiejętne przydzielanie polityk, jak np. nadanie iam:* bez nałożenia odpowiedniego Permission Boundary (granicy uprawnień).
Wyobraźmy sobie, że chcemy pozwolić deweloperowi tworzyć role dla jego funkcji Lambda, tasków w ECS czy instancji EC2. Jeżeli nadamy mu po prostu iam:* lub inny podobnie szeroki zakres uprawnień do IAM, będzie mógł stworzyć dla siebie samego rolę IAM z pełnymi uprawnieniami administratora. Będzie więc w stanie w każdej chwili eskalować swoje uprawnienia i uzyskać pełny dostęp do tego konkretnego konta AWS.
Metodą obrony przed czymś takim jest zastosowanie, powyżej przedstawionego, Permission Boundary, czyli mechanizmu ustalającego maksymalny dopuszczalny limit uprawnień. We wspomnianym przypadku można przypisać deweloperowi ograniczenie wymuszające, by każda tworzona przez niego rola również miała przypisane konkretne Permission Boundary, ograniczające jej możliwości maksymalnie do uprawnień samego dewelopera.
Krótkoterminowe poświadczenia i problem wycieku kluczy
Kolejnym problemem, obok privilege escalation i blast radius, jest tzw. powierzchnia ataku (ang. attack surface). Jednym z częstszych uchybień, które ją powiększa, jest używanie długoterminowych poświadczeń (long-lived credentials) użytkowników IAM, zamiast tymczasowych poświadczeń (short-lived credentials) generowanych przez role IAM.
Jeżeli wykorzystujemy długoterminowe poświadczenia, które nie wygasają samoistnie (trzeba je wprost dezaktywować), to w przypadku ich wycieku, np. poprzez zacommitowanie do publicznego repozytorium (co wielokrotnie zdarzało się w branży), stwarzamy atakującemu świetną okazję, gdyż ma on dostęp do naszego konta AWS tak długo, aż sami się zorientujemy i zdezaktywujemy klucze. Pozwala to atakującemu na powolne i dokładne zaplanowanie ataku.
W przypadku poświadczeń krótkoterminowych, aktywnych od 1 do 12 godzin, ich wyciek stwarza zagrożenie tylko przez ten ograniczony czas. Raz wydane poświadczenia po prostu wygasają i nie można ich przedłużać w nieskończoność. Zapobiega temu mechanizm role chainingu, którego omówienie wykracza jednak poza ramy tego artykułu.
Warto zaznaczyć, że ochrona za pomocą tymczasowych poświadczeń nie ogranicza się tylko do chmury AWS. Można ją z powodzeniem stosować w systemach działających poza AWS-em (np. on-premise, na innej chmurze publicznej) wykorzystując usługę AWS IAM Roles Anywhere, która została przedstawiona na powyższej grafice. Pozwala ona systemom spoza chmury AWS korzystać z bezpiecznych, krótkoterminowych poświadczeń do komunikacji z API AWS. Warto rozważyć tę opcję dla systemów hybrydowych lub multi-cloud.
Defense in Depth, czyli chmura nie wybacza błędów
Na koniec chciałbym wspomnieć o generalnym podejściu do architektury bezpieczeństwa, czyli tzw. Defense in Depth (obronie w głąb). To metoda, w której bezpieczeństwo systemu nie opiera się tylko na jednej linii obrony, ale na wielu redundantnych warstwach. Gdy jedna z nich zawiedzie, pozostałe wciąż powinny chronić zasoby w naszym systemie, co zostało przedstawione na powyższej grafice.
Przykładem jest zastosowanie nie tylko warstwy IAM na poziomie pojedynczego konta (omówionej w artykule), ale też warstwy organizacyjnej (polityk SCP, RCP itp.), blokowania publicznego dostępu do S3 (Amazon S3 Block Public Access) oraz stosowania narzędzi takich jak Amazon GuardDuty, AWS Security Hub, AWS Config, AWS KMS itp. Wybrane usługi wspierające implementację podejścia “Defense in Depth” zostały przedstawione na powyższej grafice.
Jak widać, chmura publiczna nie wybacza błędów konfiguracyjnych. Dlatego tak kluczowe jest łączenie różnorodnych metod i dobrych praktyk w celu utwardzania systemu. Począwszy od PoLP i ról IAM, poprzez Defense in Depth, aż po zabezpieczenia na poziomie całej organizacji i wykorzystanie dedykowanych narzędzi bezpieczeństwa.
