Röviden: Az IAM-incidens ritkán látványos. Egy csillag a policy-ben, egy régi trust, egy role, ami közben S3-ra is ráérett. 2026-ban a szerepkörök karbantartása üzemeltetés, nem projekt.
A legtöbb IAM-hiba nem zero-day. Egy * a Resource mezőben, mert „ideiglenes”. Egy trust policy, ami 2023-ban egy másik fiókra szólt, és azóta senki nem olvasta. Egy Lambda-role, ami PutObject mellé közben s3:*-ot is kapott, mert a demó nem ment. 2026-ban az Identity Center, a permission set és a role manager eszközök adottak. A fegyelem nem. A least privilege nem architektúra-diagram, hanem heti karbantartás.
A hét hiba, ami nem unalmas, csak drága
Az első a wildcard a production policy-ben. Kényelmes, amíg a credential egy CI-jobban marad. A második a túl széles trust: bármelyik service principal, bármelyik fiók, feltétel nélkül. A harmadik a hosszú életű access key emberi useren — 2026-ban ez már nem „régi szokás”, hanem nyitott ajtó. A negyedik az inline policy, ami nem review-zható pull requestben. Az ötödik a role-chaining, amit senki nem tud fejből elismételni. A hatodik: a permission boundary hiánya a fejlesztői sandboxban, ahonnan a kísérleti erőforrások nőnek. A hetedik: a log, ami nem mondja el, melyik role mit csinált, csak azt, hogy „AccessDenied” vagy „Allowed”.
Ezek nem elmélet. Magyar SaaS-nél a tipikus lánc: egy staging role production bucketre is lát, mert a környezet neve tagben van, a policy-ben nincs. A tag nem IAM. A feltétel lehet, ha ki van írva. Ha nincs, a tag csak dísz.
Identity Center, ne root, ne örök kulcs
Az emberi belépés 2026-ban Identity Center (vagy azzal egyenértékű IdP-federation). A root user a páncélszekrény, nem a hétfő reggel. Az access key emberi lényen: tilos, kivéve a ritka, rövid, rotált kivételt, ami ticketen él. A gépnek role kell, assume-olva, feltétellel. A CI-nek OpenID Connect a GitHub Actionsből, nem lemezen tárolt titok.
Az augusztus közepi heti AWS-körképben felbukkant IAM role manager nem csodaszer, de jel: a szerepkörök karbantartása külön termékfelületet kap, mert a nyers policy-JSON-t emberek rontják el. Használd, ha rövidíti a review-t. Ne használd ürügynek arra, hogy a policy-t ne verziózd. Ami nincs gitben, az nincs.
A csillag a policy-ben nem gyorsaság. Az a döntés, hogy a review-t az incidens utánra toltad.
Hogyan szűkíts anélkül, hogy összedőljön
A least privilege bevezetése nem „cseréljük le holnap az összes *”. Először Access Analyzer és a tényleges hívások. Aztán egy dry-run: a szűk policy stagingben, egy hétig, riasztással a Denied-re. Aztán productionben ugyanaz, feature flaggel vagy dual policy-val, rollbackkel. A szűkítés, ami pénteken megy élesbe review nélkül, hétfőn az a ticket, hogy „ki vette el a jogot”.
A permission set-eket munkakörre szabd, nem emberekre. Ha Anna és Béla ugyanazt csinálja, egy set. Ha Béla egyszer debugolt productionben, az ne maradjon a setben. Az emelt jogosultság legyen időzített, naplózott, külön approval. A „csak gyorsan ránézek” a felhőben ugyanaz, mint a production SSH root — csak a nyomtáv nagyobb.
Magyar csapatnál a compliance-nyomás (GDPR, ügyfél-audit) gyakran megelőzi a mérnöki higiéniát. Ez visszafelé ül. Az auditor a szerepkört, a naplót és a rotációt kéri. Ha ezek megvannak, a papír gyors. Ha nincsenek, a papír sem ment meg. Az IAM a compliance olcsóbb fele — olcsóbb, mint egy adatszivárgás utáni forensics.
Break-glass, Analyzer, és ami a gitben nincs
A break-glass role a tűzoltófejsze az üveg mögött: léteznie kell, időzítettnek, riasztottnak, és unalmasnak kell lennie, amíg nincs tűz. Ha a break-glass a hétköznapi belépésed, nincs üveg. Állíts rá CloudTrail-riasztást, kötelező indoklást, és maximum néhány órás sessiont. Utána a fejsze visszamegy a keretbe, és a változtatás PR-be.
Az IAM Access Analyzer a barátod, ha hagyod unalmasnak lenni. Nem „security tool, amit majd az audit előtt megnyitunk”, hanem heti lista: külső megosztás, nem használt jogosultság, váratlan principal. A unused permission a szűkítés nyersanyaga. A külső megosztás a „ki látja a bucketet” kérdés, amit magyar ügyfél-auditon előbb kérdeznek, mint a titkosítási algoritmust.
A policy-t mint kódot kezeld. Ugyanaz a linter, ugyanaz a PR, ugyanaz a reviewer, mint a Terraformnál. A JSON, ami csak a konzolon él, az a drift rokona. SCP-vel (ha van szervezeted) a sandboxot zárd: ne lehessen production-accountba kézzel usert gyártani, ne lehessen a root kulcsot hétköznap elővenni. Kettes csapatnál az SCP túlzásnak hangzik, amíg valaki a saját gépéről nem hoz létre egy admin usert „csak a demóhoz”. Utána már nem túlzás.
A session tag és a feltétel (aws:RequestedRegion, aws:ResourceTag/env) a least privilege olcsóbb fele, mint a végtelenül szétvágott role-család. Egy role, ami csak eu-central-1-ben és csak env=prod tagen dolgozik, kevesebb review, mint tizenkét majdnem azonos role. A feltétel nem dísz. Ha nincs tesztelve Denied-del, nincs. A teszt pedig legyen automatikus: egy staging-job, ami szándékosan tiltott műveletet hív, és elbukik, ha az mégis átmegy. A policy, amit soha nem próbáltál elutasítani, csak egy kívánságlista. A magyar audit ezt a kívánságlistát nem pecsételi le — a Denied-logot igen, ha van, és ha a region plusz tag feltétel tényleg a production útvonalon él, nem csak a wiki oldalán. A CloudTrail-t pedig ne 90 napnál rövidebben tartsd, ha az audit évente jön: a policy-szűkítés utólagos bizonyítéka a napló. Ami nincs meg, az a „bíztunk benne” mondat a jegyzőkönyvben.
Mit jelent ez neked?
Ezen a héten három role elég. A legszélesebb production role, a CI role, és az, amivel emberek lépnek be. Vedd ki a wildcardot, ahol a Access Analyzer szerint nincs rá szükség. Tedd Identity Centerre az embereket, role-ra a gépeket, gitbe a policy-t. A least privilege nem projektvége. Heti tizenöt perc, amíg unalmas nem lesz — és az unalom itt a siker. Ha a tizenöt percben csak egy csillag tűnik el, a hét már jobb, mint az előző. A policy-k nem konferencián szűkülnek. Hétfőn, naptárban, Denied-teszttel.