Identity Access Management (IAM)
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.
Jezik IAM Policy-a
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 / DeniedPrincipal -
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 racuna123456789012
- ID AWS racuna bez-
znakova U oba ova slucaja principal je AWS account sa ID-em123456789012
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 confused deputy problem 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 logickoOR
. 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 jeservice prefix
s3
aime akcije
jePutObject
.*
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 logickoNOR
.Resource -
The Where
- Oznacava jedan ili vise AWS resursa na koje se odnosi / primjenjuje Policy Statement. Resursi se specificiraju koristeci ARN (Amazon Resource Name). ARN se pise u formatuarn: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 bucketaarn: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 logickoOR
unutar jednog Statement-a.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 radiregion
- kod regiona u kojem se nalazi resurs. Npr.us-east-1
za US East (N. Virginia) Regionaccount-id
- ID AWS racuna bez-
znakovaresource-type
- govori nam o tipu resursa, npr.s3
za S3 servis,ec2
za EC2 servis itd.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 putanja.
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) jednakatrue
, 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
Operator - Definise koje poredjenje IAM treba napraviti prije nego pokusa da poredi vrijednosti u vasem polisiju sa vrijednostima unutar authorisation-context. Postoji vise razlicitih condition operatora, koji operator cete koristiti zavisi od tipa koju vrijednost operatora ima unutar authorisation-context-a. Mozete koristiti razlicite sufixe sa operatorima
Equals
iliNotEquals
iliLike
da bi dobili tacno podudaranje ili wildcard podudaranje. Kako bi znali kojicondition-key
mozemo koristiti sa kojim IAM pristupom i resursom pogledajte Service Authorization Reference. Unutar Service Authorization Reference dokumentacije za svaki AWS servis mozete pogledati kojicondition-key
mozete koristiti sa kojim tipom. Npr. za EC2 servis u koloni Type vidite koji tip mozete da koristite da biste radili poredjenje. Condition keys koji pocinju saaws:
mogu se koristiti sa svim AWS servisima.
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.
Kategorije / Vrste IAM Policy-a
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.
IAM Policy Statements
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.
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 sljedecm linku. Kako se nas polisiji sastoji od vise Statement dijelova, onda poslije elementa "Version": "2012-10-17"
dolazi element "Statement": []
koji sadrzi niz Statement dijelova.
IAM Policy Evaluation
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:
Authorization context
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
Important Actions - iam:PassRole
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.
Zahvaljujuci tome, iam:PassRole
akcija se koristi za sprijecavanje sigurnosnog propusta koji je poznat pod nazivom confused deputy problem.
API Actions vs IAM Actions
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.
IAM Policy Evaluation: Policy Evaluation Chains
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.
Security best practices with AWS IAM
IAM Tips and Tricks
Resources
AWS Documentation
Last updated