cloudservices

Minden informatikai rendszerben kiemelkedő szerepet tölt be a jogosultságkezelés, hiszen ez határozza meg, hogy a rendszer mely részéhez ki és hogyan férhet hozzá. Ezzel egyidőben a jogosultságkezelési megoldások bonyolulttá tehetik ezt a területet, amelybe sokszor belezavarodhatunk. Ez sajnos egy valós probléma a mindennapokban.

A felhőben sincs ez másképp. Minden felhőszolgáltató, kicsit másképp oldja meg ezt a feladatot, annak ellenére, hogy az alapelv emögött ugyanaz: mindenki a számára kijelölt szerepkörök szerint férjen hozzá a felhő szolgáltatásaihoz.

AWS-ben az IAM (Identity and Access Management) rendszeren keresztül tudjuk kezelni a jogosultságokat. Itt azonban nem csupán a jól ismert felhasználók, felhasználói csoportok szerepelnek, hanem szerepkörök (role) és jogosultságpolitika (policy) is. Ezek használata azonban habár jól körülhatárolható, mégis sok fejfájást okoz a kezdőknek.

AWS-ben gyakran találkozom én is azzal a kérdéssel, hogy mi az a IAM szerepkör (IAM Role), és miben különbözik a jogosultságpolitika (IAM Policy). Sokan nehezen értik meg ezt a két fogalmat, pedig az IAM (Identity and Access Management) az egyik legfontosabb biztonsági pillére a felhőalapú rendszereknek.

Ebben a cikkben ehhez szeretnénk egy kis segítséget adni, bemutatva a különbségeket, használati eseteket, és gyakorlati példákat is, hogy értsd, ne csak használd az AWS jogosultságkezelését.

Mi az IAM (Identity and Access Management)?

Az IAM lehetővé teszi, hogy meghatározd:

• Ki léphet be az AWS-be
• Milyen műveleteket hajthat végre
• Mely erőforrásokon

Az IAM az alábbi fő elemekkel dolgozik:

IAM Policy – Mit lehet csinálni?

Egy IAM Policy (jogosultságpolitika) egy JSON formátumú dokumentum, amely pontosan meghatározza, hogy egy adott felhasználó, csoport vagy szerepkör milyen műveleteket hajthat végre, milyen AWS-erőforrásokon, és milyen feltételek mellett.

Ez a dokumentum a következőket tartalmazza:

• Effect: A művelet engedélyezése ("Allow") vagy tiltása ("Deny").
• Action: Az engedélyezett vagy tiltott AWS műveletek (pl. s3:PutObject, ec2:StartInstances).
• Resource: Az érintett AWS-erőforrások, például egy konkrét S3 bucket vagy EC2 instance.
• Condition (opcionális): További megszorítások, pl. csak bizonyos IP-címről vagy csak többfaktoros hitelesítés esetén érvényes a policy.

Miért fontos?

Az IAM Policy határozza meg, hogy valaki mit tehet meg az AWS-ben és mit nem. Ezáltal kulcsszerepe van az AWS-fiók biztonságos és kontrollált használatában.

Előre adott, vagy nekem kell kitalálni?

Amikor a policy-k szóba kerülnek az alábbi kérdés is felvetődik:

A policy-ket nekem kell megírnom, vagy vannak előre elkészített sablonok is?

A válasz pedig: mindkettő lehetséges, az AWS kétféle policy-típust támogat:

A. Managed Policies – előre definiált, újrahasznosítható

• Ezeket az AWS hozta létre, és sok tipikus szerepkört lefednek (pl. olvasás S3-ból, teljes hozzáférés DynamoDB-hez).
• Például: AmazonS3ReadOnlyAccess, AmazonEC2FullAccess, AWSLambdaExecute
• Ezeket készen hozzá tudod rendelni felhasználókhoz vagy szerepkörökhöz.
• Előnyük, hogy gyorsan használhatók, és AWS által karbantartottak, de kevésbé testreszabhatók.

B. Customer Managed Policies – saját szabályzatok, egyedi igényekre

• Ezeket te magad írod meg, ha pontosan szabályozni akarod, hogy mi történhet.
• Teljes rugalmasságot adnak, de több figyelmet és tesztelést igényelnek.

Mikor melyiket használd?

Példa – Csak olvasási jogosultság egy S3 bucketre

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": ["s3:GetObject"],
 "Resource": ["arn:aws:s3:::egy-pelda-bucket/*"]
 }
 ]
}

Ez a policy lehetővé teszi, hogy a megcélzott szereplő olvasni tudjon a egy-pelda-bucket nevű S3 tárolóból, de nem tud írni vagy törölni.

IAM Role – Ki és mikor kaphat jogosultságokat?

Egy IAM Role, vagyis szerepkör, egy olyan AWS-identitás, amely nem egy adott felhasználóhoz van kötve, hanem ideiglenesen felvehető jogosultságokat biztosít különböző szolgáltatásoknak, más felhasználóknak, vagy akár külső AWS-fiókoknak.

Miért hasznos?

• Nem kell hozzá felhasználónév vagy jelszó, sem hozzáférési kulcs.
• A szerepkört fel lehet venni egy adott helyzetben — például amikor egy Lambda függvény elindul, vagy amikor egy EC2 példány hozzáfér egy S3 buckethez.
• A role-hoz tartozó policy-k határozzák meg, hogy az adott szerepet viselő milyen AWS-műveleteket hajthat végre.

Példák szerepkör használatra:

Fontos: A Role csak addig érvényes, amíg „fel van véve” – ezáltal sokkal biztonságosabb hosszú távon, mint ha kulcsokat vagy jelszót adnál ki egy szolgáltatásnak.

Hogyan „veszi fel” egy AWS-identitás az IAM Role-t?

Attól függően, hogy ki vagy mi szeretné használni a szerepkört, a felvétel módja eltér. Alapvetően három fő helyzetvan:

A. AWS szolgáltatás (pl. EC2, Lambda) automatikusan felveszi a szerepkört

Amikor egy AWS-erőforráshoz (pl. EC2 példányhoz vagy Lambda függvényhez) hozzárendelsz egy IAM role-t, akkor az AWS rendszer automatikusan „felveszi” azt a szerepet a szolgáltatás nevében futásidőben.

Példa:

• Létrehozol egy role-t, ami engedélyezi PutObject műveletet egy S3 bucketre.
• Ezt a role-t hozzárendeled egy EC2 példányhoz.
• Amikor a példány fut, és az alkalmazás próbál írni az S3 bucketbe, az AWS automatikusan „aláírja” a kérést a role jogosultságaival.

Tehát nem kell semmit kézzel csinálni – a role automatikusan aktiválódik.

B. Egy emberi felhasználó (IAM User vagy Federated User) kézzel veszi fel a szerepkört

Ez történik például akkor, amikor:

• Belépsz az AWS Management Console-ba, és ott manuálisan „Assume Role”-t (szerepváltás, szerep felvétel) végzel.
• CLI-ból vagy SDK-ból használsz sts:AssumeRole hívást egy másik szerepkör felvételére.

Amikor egy AWS-identitás (pl. ember vagy szolgáltatás) ideiglenesen magára ölt egy másik jogosultságkészletet, azt nevezzük „Assume Role”-nak, azaz szerepkör felvételének.

Példa CLI-ból:

aws sts assume-role \
 --role-arn arn:aws:iam::123456789012:role/AdminAccessRole \
 --role-session-name admin-session \
 --profile felhasznalo1

Ez a parancs egy másik szerepkört aktivál a felhasznalo1, majd visszaad egy ideiglenes hozzáférési kulcsot, amelyet a CLI vagy SDK automatikusan használ a következő hívásokhoz. Ez hasznos például akkor, ha egy fejlesztő csak ideiglenesen akar admin jogosultságot — a role 1 órára „felvehető”, utána lejár.

C. Egy külső AWS-fiókból vagy identitásszolgáltatóból (pl. Azure EntraID, Google Workspace) történik a role felvétel

Ez akkor történik, ha van egy cross-account access (amikor egy AWS-fiók felhasználója vagy szolgáltatása hozzáférést kap egy másik AWS-fiók erőforrásaihoz, jellemzően IAM szerepkörön keresztül.) vagy federált hitelesítés (amikor egy külső identitásszolgáltató – pl. Google, Azure EntraID, vállalati SSO – felhasználói AWS-hozzáférést kapnak anélkül, hogy külön IAM felhasználót hoznánk létre nekik.):

• A külső felhasználó azonosítja magát (pl. SAML vagy OIDC segítségével).
• Az AWS STS (Security Token Service) engedélyezi, hogy felvegyen egy role-t, amit előre engedélyeztél neki.
• Ekkor is ideiglenes tokeneket kap, amelyeket aztán használhat.

Ez a technika például Single Sign-On (SSO) esetén működik így.

IAM Role vs Policy – A teljes kép

Mikor lehet összekeverni?

Sok kezdő azon akad fenn, hogy a policy-k önmagukban nem „élnek”. Csak akkor működnek, ha:

• Hozzá vannak rendelve egy user-hez, group-hoz vagy role-hoz.
• A role-t valaki vagy valami ténylegesen „felveszi”.

Tippek a biztonságos használathoz

1. Használj role-t szolgáltatásokhoz, ne kulcsokat.
2. Csak annyi jogosultságot adj, amennyi szükséges – ez a „least privilege principle”.
3. Kerüld az Action: "*" és Resource: "*" használatát, kivéve teszteléskor.
4. Használj IAM policy simulator-t, hogy kipróbáld, mit engedélyez a policy.
5. Auditáld a role használatot a CloudTrail segítségével.

Összegzés

A szerepkör olyan, mint egy színes sapka, amit ideiglenesen felvehetsz – ez mutatja, milyen szerepben vagy. A policy pedig az a szabálykönyv, ami meghatározza, hogy az adott sapka viselője mit tehet meg.