Last updated
Ucz się i ćwicz Hacking AWS:
HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: 
HackTricks Training GCP Red Team Expert (GRTE)
W AWS istnieje konto główne, które jest rodzicem dla wszystkich kont w twojej organizacji. Jednak nie musisz używać tego konta do wdrażania zasobów, możesz stworzyć inne konta, aby oddzielić różne infrastruktury AWS między sobą.
Jest to bardzo interesujące z punktu widzenia bezpieczeństwa, ponieważ jedno konto nie będzie mogło uzyskać dostępu do zasobów innego konta (chyba że specjalnie utworzone są mosty), dzięki czemu możesz stworzyć granice między wdrożeniami.
Dlatego w organizacji istnieją dwa typy kont (mówimy o kontach AWS, a nie kontach użytkowników): jedno konto, które jest wyznaczone jako konto zarządzające, oraz jedno lub więcej kont członkowskich.
Konto zarządzające (konto główne) to konto, którego używasz do tworzenia organizacji. Z konta zarządzającego organizacją możesz zrobić następujące rzeczy:
Tworzyć konta w organizacji
Zapraszać inne istniejące konta do organizacji
Usuwać konta z organizacji
Zarządzać zaproszeniami
Stosować polityki do podmiotów (korzeni, OU lub kont) w organizacji
Włączyć integrację z obsługiwanymi usługami AWS, aby zapewnić funkcjonalność usług we wszystkich kontach w organizacji.
Możliwe jest zalogowanie się jako użytkownik główny, używając adresu e-mail i hasła użytego do utworzenia tego konta głównego/organizacji.
Konto zarządzające ma odpowiedzialność konta płatnika i jest odpowiedzialne za opłacanie wszystkich opłat, które są naliczane przez konta członkowskie. Nie możesz zmienić konta zarządzającego organizacją.
Konta członkowskie składają się z pozostałych kont w organizacji. Konto może być członkiem tylko jednej organizacji w danym czasie. Możesz przypisać politykę do konta, aby zastosować kontrole tylko do tego jednego konta.
Konta członkowskie muszą używać ważnego adresu e-mail i mogą mieć nazwę, generalnie nie będą mogły zarządzać rozliczeniami (ale mogą otrzymać do nich dostęp).
Konta mogą być grupowane w Jednostki Organizacyjne (OU). W ten sposób możesz tworzyć polityki dla Jednostki Organizacyjnej, które będą stosowane do wszystkich kont podrzędnych. Zauważ, że OU może mieć inne OU jako dzieci.
Polityka kontroli usług (SCP) to polityka, która określa usługi i działania, które użytkownicy i role mogą wykorzystywać w kontach, na które wpływa SCP. SCP są podobne do polityk uprawnień IAM, z tą różnicą, że nie przyznają żadnych uprawnień. Zamiast tego SCP określają maksymalne uprawnienia dla organizacji, jednostki organizacyjnej (OU) lub konta. Gdy dołączysz SCP do korzenia swojej organizacji lub OU, SCP ogranicza uprawnienia dla podmiotów w kontach członkowskich.
To jest JEDYNY sposób, aby nawet użytkownik root mógł być powstrzymany przed wykonaniem czegoś. Na przykład, może być użyty do powstrzymania użytkowników przed wyłączaniem CloudTrail lub usuwaniem kopii zapasowych. Jedynym sposobem na obejście tego jest również skompromitowanie konta głównego, które konfiguruje SCP (konto główne nie może być zablokowane).
Zauważ, że SCP ograniczają tylko podmioty w koncie, więc inne konta nie są dotknięte. Oznacza to, że posiadanie SCP, które odmawia s3:GetObject, nie powstrzyma ludzi przed uzyskiwaniem dostępu do publicznego koszyka S3 w twoim koncie.
Przykłady SCP:
Całkowicie odmówić kontu root
Zezwolić tylko na określone regiony
Zezwolić tylko na usługi z białej listy
Odmówić wyłączania GuardDuty, CloudTrail i S3 Public Block Access
Odmówić usuwania lub modyfikowania ról odpowiedzialnych za bezpieczeństwo/reakcję na incydenty.
Odmówić usuwania kopii zapasowych.
Odmówić tworzenia użytkowników IAM i kluczy dostępu
Znajdź przykłady JSON w https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html
Amazon Resource Name to unikalna nazwa, którą ma każdy zasób w AWS, składa się z tego:
Zauważ, że w AWS są 4 partycje, ale tylko 3 sposoby ich nazywania:
AWS Standard: aws
AWS China: aws-cn
AWS US public Internet (GovCloud): aws-us-gov
AWS Secret (US Classified): aws
IAM to usługa, która pozwala zarządzać uwierzytelnianiem, autoryzacją i kontrolą dostępu w Twoim koncie AWS.
Uwierzytelnianie - Proces definiowania tożsamości i weryfikacji tej tożsamości. Proces ten można podzielić na: Identyfikację i weryfikację.
Autoryzacja - Określa, do czego tożsamość ma dostęp w systemie po jej uwierzytelnieniu.
Kontrola dostępu - Metoda i proces, w jaki sposób przyznawany jest dostęp do zabezpieczonego zasobu.
IAM można zdefiniować przez jego zdolność do zarządzania, kontrolowania i regulowania mechanizmów uwierzytelniania, autoryzacji i kontroli dostępu tożsamości do Twoich zasobów w Twoim koncie AWS.
Kiedy po raz pierwszy tworzysz konto Amazon Web Services (AWS), zaczynasz od pojedynczej tożsamości logowania, która ma pełny dostęp do wszystkich usług i zasobów AWS w koncie. To jest główny użytkownik konta AWS i uzyskuje się do niego dostęp, logując się za pomocą adresu e-mail i hasła, które użyłeś do utworzenia konta.
Zauważ, że nowy użytkownik admina będzie miał mniej uprawnień niż użytkownik główny.
Z punktu widzenia bezpieczeństwa zaleca się tworzenie innych użytkowników i unikanie korzystania z tego.
Użytkownik IAM to podmiot, który tworzysz w AWS, aby reprezentować osobę lub aplikację, która go używa do interakcji z AWS. Użytkownik w AWS składa się z nazwy i poświadczeń (hasło i do dwóch kluczy dostępu).
Kiedy tworzysz użytkownika IAM, przyznajesz mu uprawnienia, czyniąc go członkiem grupy użytkowników, która ma odpowiednie polityki uprawnień (zalecane), lub bezpośrednio przypisując polityki do użytkownika.
Użytkownicy mogą mieć włączone MFA do logowania przez konsolę. Tokeny API użytkowników z włączonym MFA nie są chronione przez MFA. Jeśli chcesz ograniczyć dostęp kluczy API użytkowników za pomocą MFA, musisz wskazać w polityce, że aby wykonać określone działania, MFA musi być obecne (przykład tutaj).
ID klucza dostępu: 20 losowych wielkich liter alfanumerycznych, takich jak AKHDNAPO86BSHKDIRYT
ID tajnego klucza dostępu: 40 losowych wielkich i małych liter: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Nie ma możliwości odzyskania utraconych ID tajnych kluczy dostępu).
Kiedy musisz zmienić klucz dostępu, powinieneś postępować według tego procesu: Utwórz nowy klucz dostępu -> Zastosuj nowy klucz do systemu/aplikacji -> oznacz oryginalny jako nieaktywny -> Przetestuj i zweryfikuj, że nowy klucz dostępu działa -> Usuń stary klucz dostępu
Jest używane do tworzenia dodatkowego czynnika uwierzytelniania oprócz istniejących metod, takich jak hasło, tworząc w ten sposób wieloskładnikowy poziom uwierzytelniania. Możesz użyć darmowej aplikacji wirtualnej lub fizycznego urządzenia. Możesz użyć aplikacji takich jak Google Authenticator za darmo, aby aktywować MFA w AWS.
Polityki z warunkami MFA mogą być przypisane do następujących:
Użytkownika lub grupy IAM
Zasobu, takiego jak koszyk Amazon S3, kolejka Amazon SQS lub temat Amazon SNS
Polityki zaufania roli IAM, która może być przyjęta przez użytkownika
Jeśli chcesz uzyskać dostęp przez CLI do zasobu, który sprawdza MFA, musisz wywołać GetSessionToken. To da ci token z informacjami o MFA.
Zauważ, że AssumeRole credentials nie zawierają tych informacji.
As stated here, istnieje wiele różnych przypadków, w których MFA nie może być używane.
Grupa użytkowników IAM to sposób na przypisanie polityk do wielu użytkowników jednocześnie, co może ułatwić zarządzanie uprawnieniami tych użytkowników. Role i grupy nie mogą być częścią grupy.
Możesz przypisać politykę opartą na tożsamości do grupy użytkowników, aby wszyscy użytkownicy w grupie użytkowników otrzymali uprawnienia polityki. Nie możesz zidentyfikować grupy użytkowników jako Principal w polityce (takiej jak polityka oparta na zasobach), ponieważ grupy odnoszą się do uprawnień, a nie do uwierzytelniania, a podmioty są uwierzytelnionymi jednostkami IAM.
Oto kilka ważnych cech grup użytkowników:
Grupa użytkowników może zawierać wielu użytkowników, a użytkownik może należeć do wielu grup.
Grupy użytkowników nie mogą być zagnieżdżane; mogą zawierać tylko użytkowników, a nie inne grupy użytkowników.
Nie ma domyślnej grupy użytkowników, która automatycznie obejmuje wszystkich użytkowników w koncie AWS. Jeśli chcesz mieć taką grupę użytkowników, musisz ją utworzyć i przypisać do niej każdego nowego użytkownika.
Liczba i rozmiar zasobów IAM w koncie AWS, takich jak liczba grup oraz liczba grup, do których użytkownik może należeć, są ograniczone. Aby uzyskać więcej informacji, zobacz kwoty IAM i AWS STS.
Rola IAM jest bardzo podobna do użytkownika, ponieważ jest to tożsamość z politykami uprawnień, które określają, co może i czego nie może robić w AWS. Jednak rola nie ma żadnych poświadczeń (hasła ani kluczy dostępu) związanych z nią. Zamiast być unikalnie przypisana do jednej osoby, rola ma być przyjmowana przez każdego, kto jej potrzebuje (i ma wystarczające uprawnienia). Użytkownik IAM może przyjąć rolę, aby tymczasowo uzyskać różne uprawnienia do konkretnego zadania. Rola może być przypisana do użytkownika federacyjnego, który loguje się za pomocą zewnętrznego dostawcy tożsamości zamiast IAM.
Rola IAM składa się z dwóch typów polityk: polityki zaufania, która nie może być pusta, definiującej kto może przyjąć rolę, oraz polityki uprawnień, która nie może być pusta, definiującej co może uzyskać dostęp.
Usługa AWS Security Token Service (STS) to usługa internetowa, która ułatwia wydawanie tymczasowych, ograniczonych poświadczeń. Jest specjalnie dostosowana do:
Tymczasowe poświadczenia są głównie używane z rolami IAM, ale istnieją również inne zastosowania. Możesz zażądać tymczasowych poświadczeń, które mają bardziej ograniczony zestaw uprawnień niż standardowy użytkownik IAM. To zapobiega przypadkowemu wykonywaniu zadań, które nie są dozwolone przez bardziej ograniczone poświadczenia. Korzyścią tymczasowych poświadczeń jest to, że wygasają automatycznie po określonym czasie. Masz kontrolę nad czasem, przez jaki poświadczenia są ważne.
Służą do przypisywania uprawnień. Istnieją 2 typy:
Polityki zarządzane przez AWS (wstępnie skonfigurowane przez AWS)
Polityki zarządzane przez klienta: skonfigurowane przez Ciebie. Możesz tworzyć polityki na podstawie polityk zarządzanych przez AWS (modyfikując jedną z nich i tworząc własną), korzystając z generatora polityk (widok GUI, który pomaga w przyznawaniu i odmawianiu uprawnień) lub pisząc własne.
Zgodnie z domyślnym dostępem jest odmowa, dostęp zostanie przyznany, jeśli określono wyraźną rolę. Jeśli istnieje pojedyncza "Odmowa", nadpisze "Zezwolenie", z wyjątkiem żądań, które używają poświadczeń bezpieczeństwa głównego konta AWS (które są domyślnie dozwolone).
The global fields that can be used for conditions in any service are documented here. The specific fields that can be used for conditions per service are documented here.
Ten rodzaj polityk jest bezpośrednio przypisany do użytkownika, grupy lub roli. Wtedy nie pojawiają się one na liście Polityk, ponieważ nikt inny nie może ich używać. Polityki inline są przydatne, jeśli chcesz utrzymać ścisły związek jeden do jednego między polityką a tożsamością, do której są stosowane. Na przykład, chcesz mieć pewność, że uprawnienia w polityce nie są przypadkowo przypisane do tożsamości innej niż ta, dla której są przeznaczone. Kiedy używasz polityki inline, uprawnienia w polityce nie mogą być przypadkowo przypisane do niewłaściwej tożsamości. Dodatkowo, gdy używasz konsoli zarządzania AWS do usunięcia tej tożsamości, polityki osadzone w tożsamości są również usuwane. To dlatego, że są częścią głównego podmiotu.
To są polityki, które mogą być definiowane w zasobach. Nie wszystkie zasoby AWS je wspierają.
Jeśli główny podmiot nie ma wyraźnego odmowy dostępu do nich, a polityka zasobów przyznaje im dostęp, to są one dozwolone.
Granice IAM mogą być używane do ograniczenia uprawnień, do których użytkownik lub rola powinny mieć dostęp. W ten sposób, nawet jeśli inny zestaw uprawnień jest przyznawany użytkownikowi przez inną politykę, operacja nie powiedzie się, jeśli spróbuje ich użyć.
Granica to po prostu polityka przypisana do użytkownika, która wskazuje maksymalny poziom uprawnień, jakie użytkownik lub rola mogą mieć. Tak więc, nawet jeśli użytkownik ma dostęp administratora, jeśli granica wskazuje, że może tylko czytać koszyki S·, to jest to maksymalne, co może zrobić.
To, SCP i przestrzeganie zasady najmniejszych uprawnień to sposoby kontrolowania, aby użytkownicy nie mieli więcej uprawnień niż te, których potrzebują.
Polityka sesji to polityka ustawiana, gdy rola jest przyjmowana w jakiś sposób. Będzie to jak granica IAM dla tej sesji: Oznacza to, że polityka sesji nie przyznaje uprawnień, ale ogranicza je do tych wskazanych w polityce (maksymalne uprawnienia to te, które ma rola).
To jest przydatne dla środków bezpieczeństwa: Gdy administrator ma przyjąć bardzo uprzywilejowaną rolę, może ograniczyć uprawnienia tylko do tych wskazanych w polityce sesji, w przypadku gdy sesja zostanie skompromitowana.
Note that by default AWS może dodać polityki sesji do sesji, które będą generowane z powodu innych przyczyn. Na przykład, w nieautoryzowanych rolach przyjętych przez cognito domyślnie (korzystając z ulepszonej autoryzacji), AWS wygeneruje poświadczenia sesji z polityką sesji, która ogranicza usługi, do których sesja ma dostęp do następującej listy.
Dlatego, jeśli w pewnym momencie napotkasz błąd "... ponieważ żadna polityka sesji nie zezwala na ...", a rola ma dostęp do wykonania akcji, to dlatego, że istnieje polityka sesji, która to uniemożliwia.
Federacja tożsamości pozwala użytkownikom z dostawców tożsamości, którzy są zewnętrzni dla AWS, na bezpieczny dostęp do zasobów AWS bez konieczności podawania poświadczeń użytkownika AWS z ważnego konta IAM. Przykładem dostawcy tożsamości może być twoje własne korporacyjne Microsoft Active Directory (poprzez SAML) lub usługi OpenID (jak Google). Dostęp federacyjny pozwoli użytkownikom w nim na dostęp do AWS.
Aby skonfigurować to zaufanie, generowany jest dostawca tożsamości IAM (SAML lub OAuth), który ufa innej platformie. Następnie, przynajmniej jedna rola IAM jest przypisana (ufająca) do dostawcy tożsamości. Jeśli użytkownik z zaufanej platformy uzyskuje dostęp do AWS, uzyskuje dostęp jako wspomniana rola.
Jednak zazwyczaj będziesz chciał nadać inną rolę w zależności od grupy użytkownika na zewnętrznej platformie. Wtedy kilka ról IAM może ufać zewnętrznemu dostawcy tożsamości, a zewnętrzna platforma będzie tą, która pozwoli użytkownikom na przyjęcie jednej roli lub innej.
AWS IAM Identity Center (następca AWS Single Sign-On) rozszerza możliwości AWS Identity and Access Management (IAM), aby zapewnić centralne miejsce, które łączy administrację użytkownikami i ich dostępem do kont AWS oraz aplikacji w chmurze.
Domena logowania będzie wyglądać jak <user_input>.awsapps.com.
Aby zalogować użytkowników, można użyć 3 źródeł tożsamości:
Katalog Centrum Tożsamości: Zwykli użytkownicy AWS
Active Directory: Obsługuje różne konektory
Zewnętrzny dostawca tożsamości: Wszyscy użytkownicy i grupy pochodzą z zewnętrznego dostawcy tożsamości (IdP)
W najprostszym przypadku katalogu Centrum Tożsamości, Centrum Tożsamości będzie miało listę użytkowników i grup i będzie mogło przypisywać polityki do nich do dowolnych kont organizacji.
Aby nadać dostęp użytkownikowi/grupie Centrum Tożsamości do konta, zostanie utworzony zaufany dostawca tożsamości SAML, a rola ufająca dostawcy tożsamości z określonymi politykami zostanie utworzona w docelowym koncie.
Możliwe jest nadawanie uprawnień za pomocą polityk inline do ról utworzonych za pomocą IAM Identity Center. Role utworzone w kontach, którym nadawane są polityki inline w AWS Identity Center, będą miały te uprawnienia w polityce inline o nazwie AwsSSOInlinePolicy.
Dlatego, nawet jeśli zobaczysz 2 role z polityką inline o nazwie AwsSSOInlinePolicy, to nie oznacza, że mają te same uprawnienia.
Użytkownik (ufający) może utworzyć rolę międzykontową z pewnymi politykami, a następnie zezwolić innemu użytkownikowi (zaufanemu) na dostęp do swojego konta, ale tylko mając dostęp wskazany w nowych politykach roli. Aby to utworzyć, wystarczy utworzyć nową rolę i wybrać rolę międzykontową. Role do dostępu międzykontowego oferują dwie opcje. Zapewnienie dostępu między kontami AWS, które posiadasz, oraz zapewnienie dostępu między kontem, które posiadasz, a zewnętrznym kontem AWS. Zaleca się określenie użytkownika, który jest zaufany, a nie podawanie czegoś ogólnego, ponieważ w przeciwnym razie inni uwierzytelnieni użytkownicy, tacy jak użytkownicy federacyjni, będą mogli również nadużywać tego zaufania.
Nieobsługiwane:
Relacje zaufania
Centrum administracyjne AD
Pełne wsparcie PS API
Kosz na śmieci AD
Zarządzane konta usług grupowych
Rozszerzenia schematu
Brak bezpośredniego dostępu do OS lub instancji
Aplikacja używa AssumeRoleWithWebIdentity do tworzenia tymczasowych poświadczeń. Jednak nie daje to dostępu do konsoli AWS, tylko dostęp do zasobów w AWS.
Możesz ustawić politykę haseł, opcje takie jak minimalna długość i wymagania dotyczące haseł.
Możesz pobrać "Raport poświadczeń" z informacjami o bieżących poświadczeniach (takimi jak czas utworzenia użytkownika, czy hasło jest włączone...). Możesz generować raport poświadczeń tak często, jak co cztery godziny.
AWS Identity and Access Management (IAM) zapewnia szczegółową kontrolę dostępu w całym AWS. Dzięki IAM możesz określić, kto może uzyskać dostęp do jakich usług i zasobów, oraz na jakich warunkach. Dzięki politykom IAM zarządzasz uprawnieniami dla swojej siły roboczej i systemów, aby zapewnić minimalne uprawnienia.
Na tej stronie możesz znaleźć prefiksy ID IAM kluczy w zależności od ich natury:
Następujące uprawnienia przyznają różny dostęp do metadanych:
arn:aws:iam::aws:policy/SecurityAudit
arn:aws:iam::aws:policy/job-function/ViewOnlyAccess
codebuild:ListProjects
config:Describe*
cloudformation:ListStacks
logs:DescribeMetricFilters
directconnect:DescribeConnections
dynamodb:ListTables
Aby zwykły użytkownik mógł uwierzytelnić się w AWS za pomocą CLI, musisz mieć lokalne poświadczenia. Domyślnie możesz je skonfigurować ręcznie w ~/.aws/credentials lub uruchamiając aws configure.
W tym pliku możesz mieć więcej niż jeden profil, jeśli żaden profil nie jest określony przy użyciu aws cli, używany będzie ten o nazwie [default] w tym pliku.
Przykład pliku poświadczeń z więcej niż 1 profilem:
Jeśli musisz uzyskać dostęp do różnych kont AWS i twój profil otrzymał dostęp do przyjęcia roli w tych kontach, nie musisz ręcznie wywoływać STS za każdym razem (aws sts assume-role --role-arn <role-arn> --role-session-name sessname) i konfigurować poświadczeń.
Możesz użyć pliku ~/.aws/config, aby wskazać, które role przyjąć, a następnie użyć parametru --profile jak zwykle (operacja assume-role zostanie wykonana w sposób przezroczysty dla użytkownika).
Przykład pliku konfiguracyjnego:
Z tym plikiem konfiguracyjnym możesz następnie używać aws cli jak:
Jeśli szukasz czegoś podobnego do tego, ale dla przeglądarki, możesz sprawdzić rozszerzenie AWS Extend Switch Roles.
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
ABIA
ACCA
Poświadczenie specyficzne dla kontekstu
AGPA
Grupa użytkowników
AIDA
Użytkownik IAM
AIPA
Profil instancji Amazon EC2
AKIA
Klucz dostępu
ANPA
Polityka zarządzana
ANVA
Wersja w polityce zarządzanej
APKA
Klucz publiczny
AROA
Rola
ASCA
Certyfikat
ASIA
Tymczasowe identyfikatory kluczy dostępu (AWS STS) używają tego prefiksu, ale są unikalne tylko w połączeniu z tajnym kluczem dostępu i tokenem sesji.
