Identity Access Management (IAM)
Last updated
Was this helpful?
Last updated
Was this helpful?
Identinty Access Management (IAM) je AWS servis koji vam omogucava autentifikaciju i autorizaciju za rad sa AWS servisima unutar vaseg AWS racuna.
Kada posaljete zahtjev prema AWS API-iju, bilo da radite sa servisima koristeci AWS konzolu,SDKs (Software Development Kit) ili AWS Command Line Interface (AWS CLI), IAM servis je taj koji verifikuje vas identitet i provjerava da li vam je dozvoljeno izvrsavanje zeljene akcije.
IAM dakle kontrolise KO (autentifikacija) moze pristupiti vasem AWS racunu i KOJE AKCIJE (autorizacija) moze napraviti unutar AWS racuna.
IAM Policy je napisan u JSON formatu. Svaki IAM Policy se sastoji od jednog ili vise Statements. Unutar Statement dijela mozemo imati sljedece elemente:
Effect - The Why - Oznacava da li ce request biti Allow / Allowed ili Deny / Denied
Principal - The Who - Ovaj element oznacava entitet / Entity kojem je pristup dozvoljen ili odbijen, primjetiti cete da ponekad Principa element nije sadrzan unutar Policy Statement-a. Ovaj element je jedino dostupan unutar resource based i vpc-endpoint polisija. Postoje cetiri moguca tipa Principa elementa:
AWS - Koristite AWS tip Principal Elementa da referencirate druge AWS racune, role, korisnike kao i Session Principals. AWS racun unutar principal elementa moze biti napisan na dva nacina:
arn:aws:iam::123456789012:root - ARN koji sadrzi ID AWS racuna
123456789012 - ID AWS racuna bez - znakova U oba ova slucaja principal je AWS account sa ID-em 123456789012
Service - Service Principal se koristi na nivou resursa da dozvoli pristup AWS servisu. Kada napisete AWS policy koji koristi Service Principal type obicno bi trebali ukljuciti Condition key element koji specificira source ARN ili source Account odakle request dolazi. Npr:
To se koristi iz razloga da se izbjegne o cemu smo vise pisali u nastavku u dijelu Important Actions - iam:PassRole
Federated - Koristi se samo unutar IAM Trust Policies kako bi se dodijelio pristup za Web Idenity Session Principles od strane Web Idenity provajdera ili SAML Session Principle od strane SAML provajdera.
Canonical User (ne bi trebao da se koristi jer samo nekoliko slucajeva zahtijeva upotrebu ovog tipa Principal elementa)
NotPrincipal - Postoji i obrnuta varijanta Principal elementa. Medjutim nije ga preporuceno koristiti jer danas ne postoji use-case unutar AWS-a gdje bi ovaj element bio potreban. Umjesto toga mozete imati policy koji izgleda kao na primjeru ispod:
Action - The What - Oznacava jednu ili vise Akcija koje su dozvoljene / Allowed ili odbijene / Denied. Set akcija koje su navedene unautar Action dijela se evaluira kao logicko OR. Postoje razlicite reprezentacije Action elementa, npr. s3:PutObject, s3:*, s3:Put*, s3:*Object, s3:*Bucket, *. Vrijednost Action elementa je podjeljena u dva dijela, service prefix na lijevoj strani : ime akcije na desnoj strani. Npr. s3:PutObject oznacava da je service prefix s3 a ime akcije je PutObject. * oznacava wildcard za sve akcije. NotAction - Obrnuta varijanta Action elementa. Oznacava da je akcija koja je navedena u NotAction elementu zabranjena / Denied. Vise akcija unutar Not Action elementa se evaluiraju kao logicko NOR.
ARN Fromat pojasnjenje:
partition - odnosi se na to gdje se AWS resurs nalazi, npr. aws za AWS Region, aws-cn za AWS resurse u Kini, aws-us-gov za AWS Goverment resurse.
service - govori nam o kojem AWS servisu se radi
region - kod regiona u kojem se nalazi resurs. Npr. us-east-1 za US East (N. Virginia) Region
account-id - ID AWS racuna bez - znakova
resource-type - govori nam o tipu resursa, npr. s3 za S3 servis, ec2 za EC2 servis itd.
NotResource - Predstavlja inverzni element Resource elementa. Oznacava da je resurs koji je naveden u NotResource elementu zabranjen / Denied. Vise resursa unutar NotResource elementa se evaluiraju kao logicko NOR. Na njega mozete gledati i kao na Exception element. Ako pogledamo primjer:
Budite pazljivi sa koristenjem NotResource sa Allow Effect jer na taj nacin dodjeljuju pristup svim resursima osim onih koji su navedeni u NotResource elementu.
Condition - The When - Condition element oznacava konektekst unutar kojeg ce pristup biti razmotren odnosno kada ili pod kojim uslovom ce policy biti primjenjen. Npr. Statement u primjeru ispod se primjenjuje samo ukoliko je vrijednost za AWS sigurni prenos podataka (AWS Secure Transport) jednaka true, odnosno ako je request poslan preko HTTPS/TLS protokola. Polisije koji imaju Condition element mozete citati i na nacin da kazete: "Izvrsi sljedece akcije ali samo ako..."
Condition element moze da se sastoji od nekoliko elemenata. Npr:
ili
ili
ili
Key - Definise koja vrijednost iz authorisation-context treba da se poredi sa vrijednostima u vasem polisiju.
Value - Definise vrijednost koja se poredi sa vrijednostima u vasem polisiju. Da bi se polisiji mogao izvrsiti, vrijednosti u polisiju moraju biti jednake vrijednostima u authorisation-context-u.
Postoji nekoliko kategorija / vrsta IAM Policy-a, npr. policy koji je pridruzen IAM User-u, IAM Role ili IAM Group te policy koji su pridruzeni AWS resursima, npr. S3 Bucket, SQS...
Identity Based Policy - Za polisije koji su pridruzeni korisniku, roli ili grupi kazemo da se zovu Identity Based Policy, jer se radi o polisijima koji su direktno zakaceni za identitet korisnika, role ili grupe i sadrze dozvole o akcijama koje korisnik, rola ili grupa korisnika moze da napravi.
Resource Based Policy - Za polisije koji su pridruzeni AWS resursima kazemo da se zovu Resource Based Policy, jer se radi o polisijima koji su zakaceni na AWS resurs.
VPC endpoint policies - predstavljaju polisije koji kontrolisu ko i moze pristupiti i koristiti odredjeni VPC endpoint.
Service Control Policies (SPCs) - Postoje i Service Control Policies (SPCs) koje se primjenjuju na nivou AWS organizacije i predstavljaju siru sigurnosnu politiku te se zahvaljujuci tome sto se dodjeljuju na nivou za AWS Organisation servisa primjenjuju se na vise AWS racuna unutar iste organizacije.
Permission Boundaries - predstavljaju napredna mogucnost polisija koja se obicno koristi za delegiranje prava za kreiranje IAM entiteta
Session policies - predstavljaju polisije koji se primjenjuju na pojedinacnu sesiju kada dolazi do Assume IAM Role.
Svaki tip polisija koji je nabrojan iznad moze da sadrzi jedan ili vise Statement-a. Unutar Statementa se osim iznad nabrojanih primarnih elemenata mogu nalaziti i sljedeci opcionalni elementi:
Sid - Oznacava jedinstveni identifikator za Statement.
Primjer idenity-based policy statement-a:
Primjetite da ovaj polisi Statement ne sadrzi Principal element, to je zato sto se u ovom slucaju pricipal implicitan jer je sam polisiji pridruzen principal-u.
Primjer resource-based policy statement-a:
Za razliku od idenity-based polisija, resource-based polisi mora da sadrzi Principal element. To je zato sto bilo koji Principa moze pokusati da napravi poziv prema resursu i onda je na nama da koristimo principal element da definisemo ko MOZE ili NE MOZE da pristupi resursu.
U nastavku je dat primjer kompletnog IAM polisija koji se sastoji od vise Statement dijelova.
Postoje dva pravila evaluacije IAM polisija:
Najmanje jedan Statement sa Effect-om Allow mora da se podudari da bi se se akcija koju pokusavamo da napravimo kroz nas request dozvolila.
Podudarajuci Statement sa Effect-om Deny ima prednost u odnosu na Statement sa Effect-om Allow.
Nije bitno u kojem poretku sa napisani Statement-i, ako se Effect Deny podudara sa nasim requestom, onda ce se request odbiti.
Kada Principal napravi request prema AWS-u, AWS skuplja informacije o tom requestu i stavlja te informacije o requestu u ono sto nazivamo authorisation context. Authorisation context ukljucuje informacije o Akciji ili operaciji koju principa zeli da napravi, to moze biti akcija unutar AWS konzole ili kroz AWS CLI ili AWS API. Dalje sadrzi informacije o resursu nad kojim ce akcije biti napravljene. Sadrzi informacije o principalu, odnsosno osobi ili aplikaciji, koja zeli da napravit tu akciju. Informacije o principalu ukljucuju i polisiji koji je pridruzen entitetu kojeg je principal koristio za sign in. Pored navedenog authorisation context sadrzi informacije o IP adresi. Ispod je dat jedan ilustrativni primjer authorisation context-a:
IAM radi poredjenje authorization context-a sa IAM polisijem da bi saznao koji se Statement iz IAM polisija podudara i na kraju da bi odlucio da li je request Allowed ili Denied.
Request 1: Korsnik Dzenan koristi svoju IAM rolu da bi dohvatio objekat file.txt iz S3 bucket-a pod naziovom DZENAN-S3-BUCKET. Korisnik Dzenan ima identity-policy sa sljedecim statement dijelovima zakacen za svoju IAM Rolu:
Da bi utvrdio da li je request Allow ili Deny IAM ce raditi poredjenje ovog authrisation context-a sa svakim statement-om iz identity-policy-ja. IAM ce takodjer raditi poredjenje authrisation context-a i sa ostalim polisijama koje su spomenuti iznad ako oni postoje.
Rezultati evaluacije requesta korisnika odnosno poredjenja authrisation context-a sa identity-policy-jem je sljedeci:
Statement1
Allow
Yes
Statement2
Deny
No
Statement3
Allow
Ignored
Statement4
Allow
Ignored
Vidimo da se samo Statement1 poklapa sa authorization context-om i kako je Effect Allow, onda ce request biti Allowed. Ako uporedimo sljedeci authorization context sa istim identity-policy-jem vidimo da se u Statement1 dijelu Resource iz authorization context-a ne poklapa sa Resource iz identity-policy-ja.
Ukoliko ne postoji bar jedna podudarnost izmedju authorization context-a i identity-policy-ja za Allow statement, onda ce request biti Denied (Implicit Denied). Kada dodje do podudarnosti za Deny Statement, svi ostali Statement se mogu ignorisati. Ukoliko vidimo da imamo dva matching statments, jedan Allow i jedan Deny, onda ce request biti Denied (Explicit Denied).
Moguci rezultati evaluacije requesta korisnika odnosno poredjenja authrisation context-a sa identity-policy-jem su sljedeci:
Emplicit allow - Najanje jedan Allow Statement, nema podudarajucih Denuy Statements
Implicit Deny - Nema podudarajucih Allow ili Deny Statements
Emplicit Deny - Najmanje jedan podudarajuci Deny Statement, ne postoji Explicit Allow Statement
Akcija iam:PassRole je specijalna akcija koja se koristi za delegiranje / dodjelu prava, ili kako se to naziva u AWS dokumentaciji radi se o permission only akciji. Ova akcija podrzava opciju specificiranja role koju korisnik moze da delegira / dodijeli drugom korisniku. Ova akcija se koristi u kombinaciji sa resource-based policy-jima. Npr. zamislite da imate scenario u gdje postoji IAM Rola Administrators koja ima administratorske privilegije nad vasim AWS racunom. Dalje zamislite da imate korisnika A koji ima permisije da kreira EC2 instancu i da toj instanci dodijeli IAM Rolu. Prilikom kreiranja EC2 instance, korisnik A ima opciju da odabere IAM Rolu koja ce biti pridruzena toj EC2 instanci. U tom slucaju se moze dogoditi da korisnik A, koji nije Administrator, moze da dodijeli IAM Rolu Administrators EC2 instanci. Tada bi korisnik koji nema administratorske privilegije, mogao da se spoji na tu EC2 instancu i sa nje izvrsi akcije koje mu orginalno nisu bile dozvoljene kroz njegovu rolu. Da bi sprijecili ovaj scenario, IAM zahtijeva da korisniku A, kroz iam:PassRole akciju bude dozvoljeno da EC2 instanci dodijeli navedenu rolu. Ako korisnik A nema dodjeljenu iam:PassRole akciju gdje je navedena Administratorska IAM Rola, on tu role nece moci dodijeliti EC2 instanci koju je kreirao. Dakle iam:PassRole akcija daje permisije korisnicima da proslijede rolu drugom servisu ili resursu.
Za bilo koju akciju / komnadu koju korisnik zeli da izvrsi nad AWS servisima koristi se API akcija. Kada napravite poziv prema AWS API-u, AWS API ce autorizovati jednu ili vise IAM akcija Npr. za kreiranje EC2 instance koristi se API akcija ec2:RunInstances. Obicno su nazivi API akcija jednaki nazivu IAM akcija uz sljedece izuzetke.
S3 CopyObject
s3:ListBucket, s3:GetObject, s3:PutObject
S3 ListBuckets
s3:ListAllMyBuckets
Lambda Invoke
lambda:InvokeFunction
Npr: API akcija S3 CopyObject zahtijeva s3:GetObject permisije nad S3 bucketom iz kojeg kopirate objekat / podatke, s3:PutObject nad S3 bucketom u koji kopirate objekat / podatke kao i s3:ListBucket privilegije. Postoje IAM akcije koje imaju nesto drugacije ime nego njihov API action ekvivalent. Jedan od primjera je Lambda Invoke API akcija koja zahtijeva lambda:InvokeFunction IAM akciju. Preporuka je da provjerite AWS Dokumentaciju kako bi vidjeli koje tacno IAM akcije trebate kako bi korisnik mogao da izvrsi API akciju koju zelite.
Prvi principal koji pravi request je Role session. IAM Role uvijek ima odgovarajucu sesiju koja je ustvari principal koji pravi request. IAM Rola sama po sebi ne pravi request bez sesije. Sljedeci principal koji pravi request je IAM User. IAM Users nemaju sesije i oni prave requestove. Federated user (using sts:GetFederationToken) je principal koji je dobio pristupne podatke koristeci sts:GetFederationToken API. Ovo nije korisnik koji je federated od strane idenity provajdera. Vecina AWS korisnika ne koristi cesto ovaj tip Federated korisnika. Anonymous principal predstavlja korisnika koji pravi ne-autorizovani request prema AWS-u. Root korisnik je specijalni tip principala i ne bi trebao biti koristen za svakodnevnu upotrebu jer se radi o korisniku koji ima sve privilegije nad AWS racunom.
Resource - The Where - Oznacava jedan ili vise AWS resursa na koje se odnosi / primjenjuje Policy Statement. Resursi se specificiraju koristeci . ARN se pise u formatu arn:partition:service:region:account-id:resource-type/resource-id. Kada pogledate ARN razlicitih AWS Servisa vidjeti cete da nemaju svi servisi sve dijelove ARN-a. Npr: ARN S3 bucketa arn:aws:s3:::MOJ-S3-BUCKET ne ukljucuje account-id ili region. Umjesto kompletnog arn koda mozete korisiti i * wildcard da zamijenite dio ili citav ARN. Resource element se evaluira kao logicko OR unutar jednog Statement-a.
resource-id - govori nam o ID-u resursa, npr. MOJ-S3-BUCKET za S3 Bucket, i-1234567890abcdef0 za EC2 Instance itd. resurce-id moze biti Ime resursa, ID resursa ili .
Operator - Definise koje poredjenje IAM treba napraviti prije nego pokusa da poredi vrijednosti u vasem polisiju sa vrijednostima unutar authorisation-context. Postoji vise razlicitih , koji operator cete koristiti zavisi od tipa koju vrijednost operatora ima unutar authorisation-context-a. Mozete koristiti razlicite sufixe sa operatorima Equals ili NotEquals ili Like da bi dobili tacno podudaranje ili wildcard podudaranje. Kako bi znali koji condition-key mozemo koristiti sa kojim IAM pristupom i resursom pogledajte . Unutar Service Authorization Reference dokumentacije za svaki AWS servis mozete pogledati koji condition-key mozete koristiti sa kojim tipom. Npr. za u koloni Type vidite koji tip mozete da koristite da biste radili poredjenje. Condition keys koji pocinju sa aws: mogu se koristiti sa svim AWS servisima.
Za razliku od dijelova polisija koje ste vidjeli iznad, u ovom kompletnom polisiju se nalazi i dio "Version": "2012-10-17" koji oznacava sintaksu i pravila jezika kojim je napisan polisij. Vise o tome mozete vidjeti u AWS dokumentaciji na . Kako se nas polisiji sastoji od vise Statement dijelova, onda poslije elementa "Version": "2012-10-17" dolazi element "Statement": [] koji sadrzi niz Statement dijelova.
Zahvaljujuci tome, iam:PassRole akcija se koristi za sprijecavanje sigurnosnog propusta koji je poznat pod nazivom .
