Polish - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

AWS - Basic Information

Zacznij naukę hakowania AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

Hierarchia Organizacyjna

Konta

W AWS istnieje konto główne, które jest kontenerem nadrzędnym dla wszystkich kont twojej organizacji. Jednak nie musisz używać tego konta do wdrażania zasobów, możesz tworzyć inne konta do separacji różnych infrastruktur AWS między nimi.

Jest to bardzo interesujące z punktu widzenia bezpieczeństwa, ponieważ jedno konto nie będzie mogło uzyskać dostępu do zasobów z innego konta (chyba że zostaną specjalnie utworzone mosty), dzięki czemu można tworzyć granice między wdrożeniami.

Dlatego istnieją dwa rodzaje kont w organizacji (mówimy tutaj 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óre używasz do tworzenia organizacji. Z konta zarządzającego organizacją możesz:

  • Tworzyć konta w organizacji

  • Zapraszać inne istniejące konta do organizacji

  • Usuwać konta z organizacji

  • Zarządzać zaproszeniami

  • Stosować zasady do jednostek (korzenie, OU lub konta) w ramach organizacji

  • Włączać integrację z obsługiwanymi usługami AWS, aby zapewnić funkcjonalność usługi 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żytych do utworzenia tego konta głównego/organizacji.

Konto zarządzające ma obowiązki konta płatnika i odpowiada za opłacanie wszystkich opłat naliczanych przez konta członkowskie. Nie można zmienić konta zarządzającego organizacją.

  • Konta członkowskie stanowią wszystkie pozostałe konta w organizacji. Konto może być członkiem tylko jednej organizacji w danym czasie. Możesz dołączyć zasadę do konta, aby zastosować kontrole tylko do tego jednego konta.

  • Konta członkowskie muszą używać prawidłowego adresu e-mail i mogą mieć nazwę, zazwyczaj nie będą mogły zarządzać rozliczeniami (ale mogą otrzymać do nich dostęp).

aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com

Jednostki Organizacyjne

Konta można grupować w Jednostki Organizacyjne (OU). W ten sposób można tworzyć polityki dla Jednostki Organizacyjnej, które zostaną zastosowane do wszystkich kont potomnych. Zauważ, że OU może mieć inne OU jako dzieci.

# You can get the root id from aws organizations list-roots
aws organizations create-organizational-unit --parent-id r-lalala --name TestOU

Polityka kontroli usług (SCP)

Polityka kontroli usług (SCP) to polityka określająca usługi i działania, których użytkownicy i role mogą używać w kontach, na które wpływa SCP. SCP są podobne do polityk uprawnień IAM, z tym ż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 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ł zostać zatrzymany przed zrobieniem czegoś. Na przykład, może być użyty do zatrzymania użytkowników przed wyłączeniem CloudTrail lub usuwaniem kopii zapasowych. Jedynym sposobem obejścia tego jest skompromitowanie również konta głównego, które konfiguruje SCP (konto główne nie może być zablokowane).

Zauważ, że SCPy ograniczają tylko podmioty w koncie, więc inne konta nie są dotknięte. Oznacza to, że odmowa SCP dla s3:GetObject nie zatrzyma ludzi przed dostępem do publicznego kubełka S3 w twoim koncie.

Przykłady SCP:

  • Zablokuj konto root w całości

  • Pozwól tylko na określone regiony

  • Pozwól tylko na usługi z białej listy

  • Zablokuj możliwość wyłączenia GuardDuty, CloudTrail i dostępu do publicznego kubełka S3

  • Zablokuj możliwość usuwania lub modyfikowania ról bezpieczeństwa/reagowania na incydenty

  • Zablokuj usuwanie kopii zapasowych

  • Zablokuj tworzenie użytkowników IAM i kluczy dostępu

Znajdź przykłady JSON pod adresem https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html

ARN

Amazon Resource Name to unikalna nazwa, którą ma każdy zasób w AWS, jest ona skonstruowana w ten sposób:

arn:partition:service:region:account-id:resource-type/resource-id
arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env

Zauważ, że w AWS są 4 partycje, ale tylko 3 sposoby, aby się do nich odwołać:

  • AWS Standard: aws

  • AWS China: aws-cn

  • AWS US public Internet (GovCloud): aws-us-gov

  • AWS Secret (US Classified): aws

IAM - Identity and Access Management

IAM to usługa, która umożliwia zarządzanie Autoryzacją, Uwierzytelnianiem i Kontrolą Dostępu wewnątrz Twojego konta 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 dana tożsamość może uzyskać dostęp w systemie po uwierzytelnieniu.

  • Kontrola Dostępu - Metoda i proces przyznawania dostępu do zasobu zabezpieczonego

IAM można zdefiniować poprzez zdolność do zarządzania, kontrolowania i regulowania mechanizmów uwierzytelniania, autoryzacji i kontroli dostępu tożsamości do zasobów w Twoim koncie AWS.

Konto główne użytkownika AWS

Gdy 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. Jest to użytkownik root konta AWS i uzyskuje się do niego, logując się za pomocą adresu e-mail i hasła, których użyłeś do utworzenia konta.

Nowy użytkownik admina będzie miał mniej uprawnień niż użytkownik root.

Z punktu widzenia bezpieczeństwa zaleca się tworzenie innych użytkowników i unikanie korzystania z tego.

Użytkownicy IAM

Użytkownik IAM to jednostka, którą tworzysz w AWS, aby reprezentować osobę lub aplikację, która z niej korzysta do interakcji z AWS. Użytkownik w AWS składa się z nazwy i poświadczeń (hasła i maksymalnie dwóch kluczy dostępu).

Tworząc użytkownika IAM, nadajesz mu uprawnienia, uczyniając go członkiem grupy użytkowników z odpowiednimi polisami uprawnień (zalecane), lub bezpośrednio dołączając polisy 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 polisie, że do wykonania określonych działań wymagane jest MFA (przykład tutaj).

CLI

  • ID klucza dostępu: 20 losowych wielkich liter i cyfr, np. AKHDNAPO86BSHKDIRYT

  • Tajny klucz dostępu: 40 losowych dużych i małych liter: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Nie można odzyskać utraconego tajnego klucza dostępu).

Zawsze gdy chcesz zmienić klucz dostępu, powinieneś postępować zgodnie z tym procesem: Utwórz nowy klucz dostępu -> Zastosuj nowy klucz do systemu/aplikacji -> oznacz oryginalny jako nieaktywny -> Przetestuj i zweryfikuj, czy nowy klucz dostępu działa -> Usuń stary klucz dostępu

MFA - Multi Factor Authentication

Służy do utworzenia dodatkowego czynnika uwierzytelniania oprócz istniejących metod, takich jak hasło, tworząc tym samym wieloczynnikowy poziom uwierzytelniania. Możesz użyć darmowej aplikacji wirtualnej lub urządzenia fizycznego. Możesz użyć aplikacji, takiej jak uwierzytelnianie Google za darmo, aby aktywować MFA w AWS.

Polisy z warunkami MFA mogą być dołączone do:

  • Użytkownika IAM lub grupy

  • Zasobu, takiego jak kubełek Amazon S3, kolejka Amazon SQS lub temat Amazon SNS

  • Polityki zaufania roli IAM, którą może przyjąć użytkownik

Jeśli chcesz uzyskać dostęp za pomocą CLI do zasobu, który sprawdza MFA, musisz wywołać GetSessionToken. To dostarczy Ci token z informacją o MFA. Zauważ, że poświadczenia z AssumeRole nie zawierają tej informacji.

aws sts get-session-token --serial-number <arn_device> --token-code <code>

Jak stwierdzono tutaj, istnieje wiele różnych przypadków, w których MFA nie może być używane.

Grupy użytkowników IAM

Grupa użytkowników IAM to sposób dołączania zasad do wielu użytkowników jednocześnie, co ułatwia zarządzanie uprawnieniami dla tych użytkowników. Role i grupy nie mogą być częścią grupy.

Możesz dołączyć zasadę opartą na tożsamości do grupy użytkowników, dzięki czemu wszyscy użytkownicy w grupie użytkowników otrzymują uprawnienia z zasad. Nie możesz zidentyfikować grupy użytkowników jako Principal w zasadzie (takiej jak zasada oparta na zasobach), ponieważ grupy odnoszą się do uprawnień, a nie uwierzytelniania, a podmioty są uwierzytelnionymi jednostkami IAM.

Oto kilka ważnych cech grup użytkowników:

  • Grupa 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 zawierałaby 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 i liczba grup, do których użytkownik może należeć, są ograniczone. Aby uzyskać więcej informacji, zobacz limity IAM i AWS STS.

Role IAM

Rola IAM jest bardzo podobna do użytkownika, ponieważ jest to tożsamość z zasadami uprawnień określającymi, co może i czego nie może robić w AWS. Jednak rola nie ma przypisanych żadnych poświadczeń (hasła ani kluczy dostępu). Zamiast być unikalnie powiązaną z jedną osobą, rola ma być przyjmowalna przez każdego, kto jej potrzebuje (i ma wystarczające uprawnienia). Użytkownik IAM może przyjąć rolę, aby tymczasowo przyjąć inne uprawnienia do określonego zadania. Rolę można przypisać do użytkownika federacyjnego, który loguje się, korzystając z zewnętrznego dostawcy tożsamości zamiast IAM.

Rola IAM składa się z dwóch rodzajów zasad: zasady zaufania, która nie może być pusta, określająca kto może przyjąć rolę, oraz zasady uprawnień, która nie może być pusta, określająca do czego ma dostęp.

Usługa AWS Security Token Service (STS)

Usługa AWS Security Token Service (STS) to usługa sieciowa ułatwiająca wydawanie tymczasowych, ograniczonych uprawnień. Jest ona specjalnie dostosowana do:

Tymczasowe poświadczenia w IAM

Tymczasowe poświadczenia są głównie używane z rolami IAM, ale istnieją także inne zastosowania. Możesz poprosić o tymczasowe poświadczenia, które mają bardziej ograniczony zestaw uprawnień niż standardowy użytkownik IAM. Zapobiega to przypadkowemu wykonywaniu zadań, które nie są dozwolone przez bardziej ograniczone poświadczenia. Korzyścią z tymczasowych poświadczeń jest automatyczne wygaśnięcie po określonym czasie. Masz kontrolę nad czasem ważności poświadczeń.

Zasady

Uprawnienia zasad

Służą do przypisywania uprawnień. Istnieją 2 rodzaje:

  • Zarządzane przez AWS zasady (prekonfigurowane przez AWS)

  • Zasady zarządzane przez klienta: Skonfigurowane przez Ciebie. Możesz tworzyć zasady oparte na zarządzanych przez AWS zasadach (modyfikując jedną z nich i tworząc swoją własną), korzystając z generatora zasad (widok GUI, który pomaga w przyznawaniu i odmawianiu uprawnień) lub pisząc własne.

Domyślnie dostęp jest zablokowany, dostęp zostanie udzielony, jeśli została określona jasna rola. Jeśli istnieje pojedyncze "Odmów", to zastąpi "Zezwól", z wyjątkiem żądań korzystających z podstawowych poświadczeń bezpieczeństwa konta AWS (które są domyślnie dozwolone).

{
"Version": "2012-10-17",  //Version of the policy
"Statement": [  //Main element, there can be more than 1 entry in this array
{
"Sid": "Stmt32894y234276923" //Unique identifier (optional)
"Effect": "Allow", //Allow or deny
"Action": [  //Actions that will be allowed or denied
"ec2:AttachVolume",
"ec2:DetachVolume"
],
"Resource": [ //Resource the action and effect will be applied to
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:instance/*"
],
"Condition": { //Optional element that allow to control when the permission will be effective
"ArnEquals": {"ec2:SourceInstanceARN": "arn:aws:ec2:*:*:instance/instance-id"}
}
}
]
}

Globalne pola, które można używać do warunków w dowolnej usłudze są udokumentowane tutaj. Specyficzne pola, które można używać do warunków na poziomie usługi są udokumentowane tutaj.

Polityki osadzone

Ten rodzaj polityk jest bezpośrednio przypisany do użytkownika, grupy lub roli. Wtedy nie pojawiają się one na liście polityk, ponieważ każdy inny może ich używać. Osadzone polityki są przydatne, jeśli chcesz utrzymać ściśły związek jeden do jednego między polityką a tożsamością, do której jest zastosowana. Na przykład chcesz upewnić się, że uprawnienia w polityce nie są przypadkowo przypisane do tożsamości innego niż ta, dla której są przeznaczone. Gdy używasz osadzonej polityki, uprawnienia w polityce nie mogą być przypadkowo przypisane do niewłaściwej tożsamości. Ponadto, gdy używasz AWS Management Console do usunięcia tej tożsamości, osadzone w tożsamości polityki również są usuwane. Dzieje się tak, ponieważ są one częścią podmiotu głównego.

Polityki zasobów kubełka

Są to polityki, które można zdefiniować w zasobach. Nie wszystkie zasoby AWS je obsługują.

Jeśli podmiot nie ma jawnego odmowy dostępu do nich, a polityka zasobu przyznaje im dostęp, to są one dozwolone.

Granice IAM

Granice IAM można użyć 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 przyznany użytkownikowi przez inną politykę, operacja zakończy się niepowodzeniem, jeśli spróbuje ich użyć.

Granica to po prostu polityka dołączona 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ć kubełki S·, to jest to maksimum, jakie może zrobić.

To, SCPs i stosowanie zasady najmniejszych uprawnień są sposobami kontroli, aby użytkownicy nie mieli więcej uprawnień, niż potrzebują.

Polityki sesji

Polityka sesji to polityka ustawiona podczas przejęcia roli 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).

Jest to przydatne dla środków bezpieczeństwa: Gdy administrator ma przejąć bardzo uprzywilejowaną rolę, może ograniczyć uprawnienia tylko do tych wskazanych w polityce sesji w przypadku skompromitowania sesji.

aws sts assume-role \
--role-arn <value> \
--role-session-name <value> \
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
[--policy <file://policy.json>]

Zauważ, że domyślnie AWS może dodać polityki sesji do sesji, które zostaną wygenerowane z powodu innych powodów. Na przykład, w nieuwierzytelnionych rolach przyjętych przez Cognito domyślnie (korzystając z ulepszonej uwierzytelniania), AWS wygeneruje poświadczenia sesji z polityką sesji, która ogranicza usługi, do których sesja może uzyskać 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, oznacza to, że istnieje polityka sesji, która temu zapobiega.

Federacja Tożsamości

Federacja tożsamości pozwala użytkownikom z dostawców tożsamości zewnętrznych do 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ć własne korporacyjne Microsoft Active Directory(za pomocą SAML) lub usługi OpenID (jak Google). Dostęp federacyjny pozwoli użytkownikom w nim zawartym na dostęp do AWS.

Aby skonfigurować to zaufanie, generowany jest Dostawca Tożsamości IAM (SAML lub OAuth), który będzie ufać innemu platformie. Następnie, przynajmniej jedna rola IAM jest przypisana (ufająca) Dostawcy Tożsamości. Jeśli użytkownik z zaufanej platformy uzyska dostęp do AWS, będzie działał jako wspomniana rola.

Jednak zazwyczaj chcesz nadać inną rolę w zależności od grupy użytkownika w platformie zewnętrznej. Następnie, kilka ról IAM może ufać dostawcy tożsamości zewnętrznej, a platforma zewnętrzna będzie decydować, która rola może być przyjęta.

Centrum Tożsamości IAM

Centrum Tożsamości IAM AWS (następca AWS Single Sign-On) rozszerza możliwości Zarządzania Tożsamościami i Dostępem AWS (IAM), zapewniając centralne miejsce, które łączy zarządzanie użytkownikami i ich dostępem do kont AWS oraz aplikacji chmurowych.

Domena logowania będzie miała postać <user_input>.awsapps.com.

Do logowania 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 łączniki

  • 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 oraz będzie mogło przypisywać im polityki do dowolnego z kont organizacji.

Aby dać dostęp użytkownikowi/grupie z Centrum Tożsamości do konta, zostanie utworzony Dostawca Tożsamości SAML ufający Centrum Tożsamości, a rola ufająca Dostawcy Tożsamości z określonymi politykami zostanie utworzona w koncie docelowym.

AwsSSOInlinePolicy

Możliwe jest nadanie uprawnień za pomocą polityk wbudowanych dla ról utworzonych za pomocą Centrum Tożsamości IAM. Role utworzone w kontach, którym nadano polityki wbudowane w Centrum Tożsamości AWS, będą miały te uprawnienia w polityce wbudowanej o nazwie AwsSSOInlinePolicy.

Dlatego nawet jeśli zobaczysz 2 role z polityką wbudowaną o nazwie AwsSSOInlinePolicy, nie oznacza to, że mają takie same uprawnienia.

Zaufanie i Role Międzykontowe

Użytkownik (ufający) może utworzyć Rolę Międzykontową z pewnymi politykami, a następnie umożliwić innemu użytkownikowi (ufanemu) dostęp do swojego konta, ale tylko z dostępem określonym w nowych politykach roli. Aby to zrobić, 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 kontem AWS strony trzeciej. Zaleca się określenie użytkownika, który jest ufały, a nie podawanie ogólnego określenia, ponieważ w przeciwnym razie inni uwierzytelnieni użytkownicy, tak jak użytkownicy federowani, będą również mogli nadużywać tego zaufania.

AWS Simple AD

Nieobsługiwane:

  • Relacje Zaufania

  • Centrum Administracyjne AD

  • Pełne wsparcie dla interfejsu API PS

  • Kosz AD

  • Zarządzane konta usługowe grupy

  • Rozszerzenia schematu

  • Brak bezpośredniego dostępu do systemu operacyjnego lub instancji

Federacja Sieciowa lub Uwierzytelnianie OpenID

Aplikacja korzysta z AssumeRoleWithWebIdentity do tworzenia tymczasowych poświadczeń. Jednak nie zapewnia to dostępu do konsoli AWS, a jedynie dostęp do zasobów w AWS.

Inne opcje IAM

  • Możesz ustawić politykę hasła z opcjami takimi jak minimalna długość i wymagania dotyczące hasła.

  • Możesz pobrać "Raport poświadczeń" z informacjami o bieżących poświadczeniach (jak czas utworzenia użytkownika, czy hasło jest włączone...). Możesz generować raport poświadczeń co najmniej raz co cztery godziny.

Zarządzanie Tożsamościami i Dostępem AWS (IAM) zapewnia dokładną kontrolę dostępu we wszystkich usługach AWS. Dzięki IAM możesz określić kto może uzyskać dostęp do jakich usług i zasobów, oraz pod jakimi warunkami. Dzięki politykom IAM zarządzasz uprawnieniami dla swojej siły roboczej i systemów, aby zapewnić uprawnienia o najmniejszym poziomie.

Prefiksy ID IAM

Na tej stronie znajdziesz prefiksy ID IAM kluczy w zależności od ich charakteru:

ABIA

Token posiadacza usługi AWS STS

ACCA

Poświadczenie określone kontekstowo

AGPA

Grupa użytkowników

AIDA

Użytkownik IAM

AIPA

Profil instancji Amazon EC2

AKIA

Klucz dostępu

ANPA

Zarządzana polityka

ANVA

Wersja w zarządzanej polityce

APKA

Klucz publiczny

AROA

Rola

ASCA

Certyfikat

ASIA

Tymczasowe identyfikatory kluczy dostępu (AWS STS) używają ten prefiks, ale są unikalne tylko w połączeniu z tajnym kluczem dostępu i tokenem sesji.

Rekomendowane uprawnienia do audytowania kont

Następujące uprawnienia umożliwiają różne rodzaje odczytu 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

Różne

Autentykacja CLI

Aby zwykły użytkownik mógł uwierzytelnić się w AWS za pomocą CLI, potrzebujesz lokalnych poświadczeń. 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 nie określono profilu za pomocą aws cli, zostanie użyty ten o nazwie [default] w tym pliku. Przykład pliku z poświadczeniami zawierającym więcej niż 1 profil:

[default]
aws_access_key_id = AKIA5ZDCUJHF83HDTYUT
aws_secret_access_key = uOcdhof683fbOUGFYEQug8fUGIf68greoihef

[Admin]
aws_access_key_id = AKIA8YDCu7TGTR356SHYT
aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7
region = eu-west-2

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 wywoływać ręcznie 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 do wskazania, które role przyjąć, a następnie użyć parametru --profile jak zwykle (operacja assume-role zostanie wykonana w sposób transparentny dla użytkownika). Przykład pliku konfiguracyjnego:

[profile acc2]
region=eu-west-2
role_arn=arn:aws:iam::<account-id>:role/<role-path>
role_session_name = <session_name>
source_profile = <profile_with_assume_role>
sts_regional_endpoints = regional

Z tym plikiem konfiguracyjnym możesz używać aws cli w ten sposób:

aws --profile acc2 ...

Jeśli szukasz czegoś podobnego do tego, ale dla przeglądarki, możesz sprawdzić rozszerzenie AWS Extend Switch Roles.

Odnośniki

Zdobądź wiedzę na temat hakowania AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

PreviousAWS PentestingNextAWS - Federation Abuse

Last updated