AWS - Basic Information
Last updated
Last updated
Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
U AWS postoji root račun, koji je glavni kontejner za sve račune vaše organizacije. Međutim, ne morate koristiti taj račun za implementaciju resursa, možete kreirati druge račune kako biste odvojili različite AWS infrastrukture između njih.
Ovo je veoma zanimljivo sa bezbednosnog stanovišta, jer jedan račun neće moći da pristupi resursima drugog računa (osim ako su mostovi posebno kreirani), tako da na ovaj način možete postaviti granice između implementacija.
Stoga, postoje dva tipa računa u organizaciji (govorimo o AWS računima, a ne o korisničkim računima): jedan račun koji je označen kao račun za upravljanje, i jedan ili više članova računa.
Račun za upravljanje (root račun) je račun koji koristite za kreiranje organizacije. Iz računa za upravljanje organizacijom, možete uraditi sledeće:
Kreirati račune u organizaciji
Pozvati druge postojeće račune u organizaciju
Ukloniti račune iz organizacije
Upravljati pozivnicama
Primeni politike na entitete (root, OU ili račune) unutar organizacije
Omogućiti integraciju sa podržanim AWS uslugama kako bi se obezbedila funkcionalnost usluga širom svih računa u organizaciji.
Moguće je prijaviti se kao root korisnik koristeći email i lozinku korišćene za kreiranje ovog root računa/organizacije.
Račun za upravljanje ima odgovornosti računa za plaćanje i odgovoran je za plaćanje svih troškova koje generišu članovi računi. Ne možete promeniti račun za upravljanje organizacijom.
Članovi računi čine sve ostale račune u organizaciji. Račun može biti član samo jedne organizacije u isto vreme. Možete prikačiti politiku na račun kako biste primenili kontrole samo na taj jedan račun.
Članovi računi moraju koristiti važeću email adresu i mogu imati ime, generalno neće moći da upravljaju naplatom (ali im može biti dat pristup).
Računi se mogu grupisati u Organizacione jedinice (OU). Na ovaj način, možete kreirati politike za Organizacionu jedinicu koje će biti primenjene na sve podračune. Imajte na umu da OU može imati druge OU kao decu.
Politika kontrole usluga (SCP) je politika koja specificira usluge i akcije koje korisnici i uloge mogu koristiti u nalozima na koje SCP utiče. SCP-ovi su slični IAM politikama dozvola osim što ne dodeljuju nikakve dozvole. Umesto toga, SCP-ovi specificiraju maksimalne dozvole za organizaciju, organizacionu jedinicu (OU) ili nalog. Kada prikačite SCP na koren vaše organizacije ili na OU, SCP ograničava dozvole za entitete u članicama naloga.
Ovo je JEDINI način na koji čak i korisnik sa root privilegijama može biti sprečen da nešto uradi. Na primer, može se koristiti da se spreči korisnike da onemoguće CloudTrail ili obrišu rezervne kopije. Jedini način da se to zaobiđe je da se kompromituje i glavni nalog koji konfiguriše SCP-ove (glavni nalog ne može biti blokiran).
Napomena da SCP-ovi samo ograničavaju principe u nalogu, tako da drugi nalozi nisu pogođeni. To znači da imati SCP koji odbija s3:GetObject neće sprečiti ljude da pristupaju javnom S3 bucket-u u vašem nalogu.
Primeri SCP-a:
Odbijanje glavnog naloga u potpunosti
Dozvoliti samo specifične regione
Dozvoliti samo usluge sa bele liste
Odbijanje GuardDuty, CloudTrail i S3 javnog blokiranja pristupa
da budu onemogućeni
Odbijanje uloga za bezbednost/odgovor na incidente da budu obrisane ili
modifikovane.
Odbijanje brisanja rezervnih kopija.
Odbijanje kreiranja IAM korisnika i pristupnih ključeva
Pronađite JSON primere u https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html
Amazon Resource Name je jedinstveno ime koje svaki resurs unutar AWS-a ima, sastoji se ovako:
Napomena da postoje 4 particije u AWS-u, ali samo 3 načina da ih nazovete:
AWS Standard: aws
AWS China: aws-cn
AWS US javni Internet (GovCloud): aws-us-gov
AWS Secret (US Classified): aws
IAM je usluga koja će vam omogućiti da upravljate autentifikacijom, autorizacijom i kontrolom pristupa unutar vašeg AWS naloga.
Autentifikacija - Proces definisanja identiteta i verifikacije tog identiteta. Ovaj proces se može podeliti na: Identifikaciju i verifikaciju.
Autorizacija - Određuje šta identitet može da pristupi unutar sistema nakon što je autentifikovan.
Kontrola pristupa - Metod i proces kako se pristup dodeljuje sigurnom resursu.
IAM se može definisati po svojoj sposobnosti da upravlja, kontroliše i reguliše mehanizme autentifikacije, autorizacije i kontrole pristupa identiteta vašim resursima unutar vašeg AWS naloga.
Kada prvi put kreirate Amazon Web Services (AWS) nalog, počinjete sa jednim identitetom za prijavu koji ima potpun pristup svim AWS uslugama i resursima u nalogu. Ovo je root korisnik AWS naloga i pristupa mu se prijavom sa email adresom i lozinkom koje ste koristili za kreiranje naloga.
Napomena da novi admin korisnik ima manje dozvole od root korisnika.
Sa bezbednosnog stanovišta, preporučuje se kreiranje drugih korisnika i izbegavanje korišćenja ovog.
IAM korisnik je entitet koji kreirate u AWS-u da predstavlja osobu ili aplikaciju koja ga koristi za interakciju sa AWS-om. Korisnik u AWS-u se sastoji od imena i akreditiva (lozinka i do dve pristupne ključeve).
Kada kreirate IAM korisnika, dodeljujete mu dozvole tako što ga činite članom korisničke grupe koja ima odgovarajuće politike dozvola (preporučeno), ili direktno povezivanjem politika sa korisnikom.
Korisnici mogu imati omogućen MFA za prijavu putem konzole. API tokeni korisnika sa omogućenim MFA nisu zaštićeni MFA. Ako želite da ograničite pristup API ključevima korisnika koristeći MFA, morate naznačiti u politici da je za izvršavanje određenih radnji MFA potrebno (primer ovde).
ID pristupnog ključa: 20 nasumičnih velikih alfanumeričkih karaktera kao što su AKHDNAPO86BSHKDIRYT
ID tajnog pristupnog ključa: 40 nasumičnih velikih i malih karaktera: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Nije moguće povratiti izgubljene ID-ove tajnog pristupnog ključa).
Kad god trebate da promenite pristupni ključ, ovo je proces koji treba da pratite: &#xNAN;Create a new access key -> Apply the new key to system/application -> mark original one as inactive -> Test and verify new access key is working -> Delete old access key
Koristi se za kreiranje dodatnog faktora za autentifikaciju pored vaših postojećih metoda, kao što je lozinka, čime se stvara višefaktorski nivo autentifikacije. Možete koristiti besplatnu virtuelnu aplikaciju ili fizički uređaj. Možete koristiti aplikacije poput Google autentifikacije besplatno za aktivaciju MFA u AWS-u.
Politike sa MFA uslovima mogu se povezati sa sledećim:
IAM korisnikom ili grupom
Resursom kao što je Amazon S3 bucket, Amazon SQS queue ili Amazon SNS topic
Politika poverenja IAM uloge koju može preuzeti korisnik
Ako želite da pristupite putem CLI resursu koji proverava MFA, morate pozvati GetSessionToken. To će vam dati token sa informacijama o MFA.
Napomena da AssumeRole akreditivi ne sadrže ove informacije.
As stated here, postoje mnogi različiti slučajevi gde MFA ne može biti korišćen.
IAM korisnička grupa je način da se prikače politike više korisnika u isto vreme, što može olakšati upravljanje dozvolama za te korisnike. Uloge i grupe ne mogu biti deo grupe.
Možete prikačiti politiku zasnovanu na identitetu korisničkoj grupi tako da svi korisnici u korisničkoj grupi dobiju dozvole politike. Ne možete identifikovati korisničku grupu kao Principal u politici (kao što je politika zasnovana na resursima) jer se grupe odnose na dozvole, a ne na autentifikaciju, a principi su autentifikovani IAM entiteti.
Evo nekoliko važnih karakteristika korisničkih grupa:
Korisnička grupa može sadržati mnogo korisnika, a korisnik može pripadati više grupa.
Korisničke grupe ne mogu biti ugnježdene; mogu sadržati samo korisnike, ne i druge korisničke grupe.
Ne postoji podrazumevana korisnička grupa koja automatski uključuje sve korisnike u AWS nalogu. Ako želite da imate takvu korisničku grupu, morate je kreirati i dodeliti svakom novom korisniku.
Broj i veličina IAM resursa u AWS nalogu, kao što su broj grupa i broj grupa kojima korisnik može pripadati, su ograničeni. Za više informacija, pogledajte IAM i AWS STS kvote.
IAM uloga je veoma slična korisniku, jer je to identitet sa politikama dozvola koje određuju šta može i ne može da radi u AWS-u. Međutim, uloga nema nikakve kredencijale (lozinku ili pristupne ključeve) povezane sa njom. Umesto da bude jedinstveno povezana sa jednom osobom, uloga je namenjena da bude preuzeta od strane bilo koga ko je treba (i ima dovoljno dozvola). IAM korisnik može preuzeti ulogu da privremeno preuzme različite dozvole za određeni zadatak. Uloga može biti dodeljena federisanom korisniku koji se prijavljuje koristeći eksternog provajdera identiteta umesto IAM-a.
IAM uloga se sastoji od dvaju tipova politika: politika poverenja, koja ne može biti prazna, definišući ko može preuzeti ulogu, i politika dozvola, koja ne može biti prazna, definišući šta može pristupiti.
AWS Security Token Service (STS) je veb servis koji olakšava izdavanje privremenih, ograničenih privilegija kredencijala. Specijalno je prilagođen za:
Privremeni kredencijali se prvenstveno koriste sa IAM ulogama, ali postoje i druge upotrebe. Možete zatražiti privremene kredencijale koji imaju ograničeniji skup dozvola od vašeg standardnog IAM korisnika. Ovo sprečava vas da slučajno izvršavate zadatke koji nisu dozvoljeni sa ograničenim kredencijalima. Prednost privremenih kredencijala je ta što automatski ističu nakon određenog vremenskog perioda. Imate kontrolu nad trajanjem za koje su kredencijali validni.
Koriste se za dodeljivanje dozvola. Postoje 2 tipa:
AWS upravljane politike (prekonfigurisane od strane AWS-a)
Politike koje upravlja korisnik: Konfigurišete ih vi. Možete kreirati politike zasnovane na AWS upravljanim politikama (modifikujući jednu od njih i kreirajući svoju), koristeći generator politika (GUI prikaz koji vam pomaže u dodeljivanju i odbijanju dozvola) ili pišući svoje.
Po podrazumevanju, pristup je odbijen, pristup će biti odobren ako je eksplicitna uloga navedena. Ako jedna "Odbij" postoji, ona će nadjačati "Dozvoli", osim za zahteve koji koriste korenske sigurnosne kredencijale AWS naloga (koji su podrazumevano dozvoljeni).
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.
Ova vrsta politika je direktno dodeljena korisniku, grupi ili ulozi. Tada se ne pojavljuju na listi politika kao što to može biti slučaj sa drugim. Inline politike su korisne ako želite da održite strogu jedan-na-jedan vezu između politike i identiteta na koji se primenjuju. Na primer, želite da budete sigurni da dozvole u politici nisu nenamerno dodeljene identitetu osim onog za koji su namenjene. Kada koristite inline politiku, dozvole u politici ne mogu biti nenamerno povezane sa pogrešnim identitetom. Pored toga, kada koristite AWS Management Console za brisanje tog identiteta, politike ugrađene u identitet se takođe brišu. To je zato što su deo glavne entiteta.
Ovo su politike koje se mogu definisati u resursima. Nisu svi resursi AWS-a podržavaju njih.
Ako glavni entitet nema eksplicitnu zabranu na njih, a politika resursa im daje pristup, tada su dozvoljeni.
IAM granice se mogu koristiti za ograničavanje dozvola kojima korisnik ili uloga treba da imaju pristup. Na ovaj način, čak i ako se korisniku dodeli drugačiji skup dozvola putem druge politike, operacija će neuspeti ako pokuša da ih koristi.
Granica je samo politika koja je povezana sa korisnikom i ukazuje na maksimalni nivo dozvola koje korisnik ili uloga mogu imati. Dakle, čak i ako korisnik ima Administrator pristup, ako granica ukazuje da može samo da čita S· kante, to je maksimum što može da uradi.
Ovo, SCPs i pridržavanje principa minimalnih privilegija su načini da se kontroliše da korisnici nemaju više dozvola nego što im je potrebno.
Politika sesije je politika postavljena kada se uloga preuzima na neki način. Ovo će biti kao IAM granica za tu sesiju: To znači da politika sesije ne dodeljuje dozvole, već ograničava ih na one koje su navedene u politici (maksimalne dozvole su one koje uloga ima).
Ovo je korisno za bezbednosne mere: Kada administrator preuzima veoma privilegovanu ulogu, mogao bi da ograniči dozvolu samo na one koje su navedene u politici sesije u slučaju da sesija bude kompromitovana.
Napomena da po defaultu AWS može dodati politike sesije sesijama koje će biti generisane zbog trećih razloga. Na primer, u neautentifikovanim cognito pretpostavljenim rolama po defaultu (koristeći poboljšanu autentifikaciju), AWS će generisati akreditiv sesije sa politikom sesije koja ograničava usluge kojima sesija može pristupiti na sledeću listu.
Dakle, ako se u nekom trenutku suočite sa greškom "... jer nijedna politika sesije ne dozvoljava ...", a uloga ima pristup za izvršenje akcije, to je zato što postoji politika sesije koja to sprečava.
Identitetna federacija omogućava korisnicima iz identitetskih provajdera koji su eksterni za AWS da sigurno pristupaju AWS resursima bez potrebe da dostavljaju AWS korisničke akreditive iz važećeg IAM korisničkog naloga. Primer identitetskog provajdera može biti vaša vlastita korporativna Microsoft Active Directory (putem SAML) ili OpenID usluga (kao što je Google). Federisani pristup će tada omogućiti korisnicima unutar njega da pristupaju AWS-u.
Da biste konfigurisali ovo poverenje, generiše se IAM identitetski provajder (SAML ili OAuth) koji će verovati drugoj platformi. Zatim, najmanje jedna IAM uloga se dodeljuje (verujuća) identitetskom provajderu. Ako korisnik iz poverene platforme pristupi AWS-u, pristupaće kao pomenuta uloga.
Međutim, obično ćete želeti da dodelite različitu ulogu u zavisnosti od grupe korisnika na platformi treće strane. Tada, nekoliko IAM uloga može verovati identitetskom provajderu treće strane, a platforma treće strane će biti ta koja omogućava korisnicima da preuzmu jednu ili drugu ulogu.
AWS IAM Identitetni Centar (naslednik AWS Single Sign-On) proširuje mogućnosti AWS Identiteta i Upravljanja Pristupom (IAM) kako bi pružio centralno mesto koje okuplja administraciju korisnika i njihov pristup AWS nalozima i cloud aplikacijama.
Domen za prijavu će biti nešto poput <user_input>.awsapps.com.
Da biste prijavili korisnike, postoje 3 izvora identiteta koji se mogu koristiti:
Identitetni Centar Direktorijum: Redovni AWS korisnici
Active Directory: Podržava različite konektore
Eksterni Identitetni Provajder: Svi korisnici i grupe dolaze iz eksternog identitetnog provajdera (IdP)
U najjednostavnijem slučaju direktorijuma Identitetnog Centra, Identitetni Centar će imati listu korisnika i grupa i moći će da dodeli politike njima za bilo koji od naloga organizacije.
Da biste dali pristup korisniku/grupi Identitetnog Centra nalogu, biće kreiran SAML identitetni provajder koji veruje Identitetnom Centru, a uloga koja veruje identitetnom provajderu sa navedenim politikama biće kreirana u odredišnom nalogu.
Moguće je dati dozvole putem inline politika rolama kreiranim putem IAM Identitetnog Centra. Uloge kreirane u nalozima koje dobijaju inline politike u AWS Identitetnom Centru će imati ove dozvole u inline politici pod nazivom AwsSSOInlinePolicy.
Dakle, čak i ako vidite 2 uloge sa inline politikom pod nazivom AwsSSOInlinePolicy, to ne znači da imaju iste dozvole.
Korisnik (verujući) može kreirati Cross Account ulogu sa nekim politikama i zatim dozvoliti drugom korisniku (pouzdani) da pristupi njegovom nalogu ali samo imajući pristup naznačen u novim politikama uloge. Da biste to kreirali, jednostavno kreirajte novu ulogu i izaberite Cross Account ulogu. Uloge za pristup između naloga nude dve opcije. Pružanje pristupa između AWS naloga koje posedujete, i pružanje pristupa između naloga koji posedujete i naloga treće strane. Preporučuje se da precizirate korisnika koji je poveren i ne stavljate neku generičku stvar jer u suprotnom, drugi autentifikovani korisnici poput federisanih korisnika će takođe moći da zloupotrebe ovo poverenje.
Nije podržano:
Odnos poverenja
AD Admin Centar
Puna PS API podrška
AD Kanta za reciklažu
Grupa upravljanih servisnih naloga
Proširenja šeme
Nema direktan pristup OS-u ili instancama
Aplikacija koristi AssumeRoleWithWebIdentity za kreiranje privremenih akreditiva. Međutim, ovo ne omogućava pristup AWS konzoli, samo pristup resursima unutar AWS-a.
Možete postaviti podešavanje politike lozinke kao što su minimalna dužina i zahtevi za lozinkom.
Možete preuzeti "Izveštaj o akreditivima" sa informacijama o trenutnim akreditivima (kao što su vreme kreiranja korisnika, da li je lozinka omogućena...). Možete generisati izveštaj o akreditivima koliko često želite, čak i jednom svaka četiri sata.
AWS Identitet i Upravljanje Pristupom (IAM) pruža fino podešavanje kontrole pristupa širom celog AWS-a. Sa IAM-om, možete precizirati ko može pristupiti kojim uslugama i resursima, i pod kojim uslovima. Sa IAM politikama, upravljate dozvolama za vašu radnu snagu i sisteme kako biste osigurali dozvole sa najmanjim privilegijama.
Na ovoj stranici možete pronaći IAM ID prefikse ključeva u zavisnosti od njihove prirode:
ACCA
Kontekstualni akreditiv
AGPA
Korisnička grupa
AIDA
IAM korisnik
AIPA
Amazon EC2 profil instance
AKIA
Ključ pristupa
ANPA
Upravljana politika
ANVA
Verzija u upravljanoj politici
APKA
Javni ključ
AROA
Uloga
ASCA
Sertifikat
ASIA
Privremeni (AWS STS) ID-ovi ključeva za pristup koriste ovaj prefiks, ali su jedinstveni samo u kombinaciji sa tajnim pristupnim ključem i tokenom sesije.
Sledeće privilegije daju različit pristup metapodacima:
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
Da bi regularni korisnik autentifikovao AWS putem CLI, potrebno je imati lokalne akreditive. Po defaultu, možete ih konfigurisati ručno u ~/.aws/credentials ili pokretanjem aws configure.
U toj datoteci možete imati više od jednog profila, ako nije specificiran profil koristeći aws cli, koristiće se onaj pod nazivom [default] u toj datoteci.
Primer datoteke akreditiva sa više od 1 profila:
Ako treba da pristupite različitim AWS nalozima i vašem profilu je dato pravo da pretpostavi ulogu unutar tih naloga, ne morate ručno pozivati STS svaki put (aws sts assume-role --role-arn <role-arn> --role-session-name sessname) i konfigurisati akreditive.
Možete koristiti ~/.aws/config datoteku da naznačite koje uloge da pretpostavite i zatim koristiti --profile parametar kao i obično (pretpostavljanje uloge će se izvršiti na transparentan način za korisnika).
Primer konfiguracione datoteke:
Sa ovom konfiguracionom datotekom možete koristiti aws cli kao:
Ako tražite nešto slično ovome, ali za pregledač, možete proveriti ekstenziju AWS Extend Switch Roles.
Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
