A látható identitás a modern identitásbiztonság kiindulópontja, mert a kutatások szerint – köztük a Verizon éves Data Breach Investigations Report jelentései alapján – az ellopott és visszaélésre használt hitelesítő adatok a kezdeti hozzáférés leggyakrabban jelentett módjai közé tartoznak. A cikk bemutatja, mit jelent a látható identitás az IAM-ben, miért nehezíti meg ezt a felhő és a többfelhős környezet, milyen képességek számítanak az identity visibility eszközökben, és hogyan lehet rá gyakorlati programot építeni.

Mi az a látható identitás?

A látható identitás azt jelenti, hogy a szervezet teljes környezetében minden identitást látunk, tudjuk, mihez fér hozzá, és azt is, hogy ezeket a hozzáféréseket a futásidőben valójában hogyan használják. Az eszközleltárt, a jogosultságok feltérképezését és a viselkedési telemetriát egyetlen folyamatos képpé fűzi össze, nem csak időszakos pillanatfelvételeket készít.

A lényeges különbség a szándék és a végrehajtás között van. Az identity and access management (IAM) platformok a házirend szándékát fejezik ki: ki férhet hozzá, milyen feltételekkel és mennyi ideig. Az alkalmazások és az infrastruktúra mutatják meg a végrehajtást: mely hitelesítő adatokkal léptek be, milyen jogosultságokat használtak, és milyen útvonalakon haladtak végig.

A két réteg közötti térben él az identitás „sötét anyaga”: a helyi alkalmazásfiókok, a beágyazott szolgáltatás-hitelesítési adatok, az örökölt hitelesítési folyamatok és azok az integrációk, amelyeket soha nem csatoltak be egy központi identity providerhez (IdP). Ez a rejtett felület teszi a láthatóság hiányát puszta adminisztratív gond helyett biztonsági problémává.

Miért vált kritikus IAM kihívássá a látható identitás?

Az identitás sötét anyaga ritkán elszigetelt, marginális jelenség. Sokkal inkább a SaaS elterjedésének, a felhőbe költözésnek és az automatizálásnak az általános mellékterméke az elmúlt évtizedből. Amikor a szervezetek gyorsabban vesznek fel új rendszereket, mint ahogy az identitásprogramjuk ezeket fel tudja dolgozni, egyre jobban szétnyílik az olló a dokumentált és a tényleges hozzáférések között.

Az identitás támadási felületének tágulása

A támadók ehhez a réshez igazították a módszereiket. Ahelyett, hogy olyan kártevőket telepítenének, amelyeket a végpontvédelmi eszközök eleve kiszűrnek, egyre több betörés indul úgy, hogy jogos, de kompromittált hitelesítő adatokat használnak a már meglévő jogosultságok keretein belül. Az így keletkező tevékenység könnyen hasonlíthat a normál üzemeltetési működésre.

Az identitás alapú támadási felület növekedésének okai

• Hitelesítő adatokra épülő betörés: Adathalászat, tokenlopás és munkamenet-eltérítés olyan hitelesítési eseményeket eredményez, amelyek az IdP naplóiban a normál felhasználói viselkedésre emlékeztetnek.
• Gépi és nem emberi identitások: A szolgáltatásfiókok, API-kulcsok és workload hitelesítő adatok gyakran számban is felülmúlják az alkalmazotti fiókokat a felhőre támaszkodó környezetekben, és sokszor nincs lejárati idejük.
• Alkalmazáson belüli helyi fiókok: Azok a rendszerek, amelyek az egypontos bejelentkezéstől (SSO) függetlenül hitelesítenek, gyakran soha nem jelennek meg a központi hozzáférés-felülvizsgálatokban.

Agentikus AI workloadok: Az autonóm agentek delegált jogosultságokkal működnek több rendszeren át, gyakran olyan sebességgel és mennyiségben, amit kézi ellenőrzéssel lehetetlen követni.

Miért nem elég a hagyományos IAM riportolás

A legtöbb IAM riport a konfigurációt írja le: csoporttagságokat, szerepkör-hozzárendeléseket és jogosultságkatalógusokat. Ezek az adatok arra válaszolnak, hogy milyen hozzáférést adtak meg, de nem derül ki belőlük, hogy az alkalmazás valóban érvényesítette-e ezt, hogy a fióknak van-e még emberi tulajdonosa, vagy hogy használták-e a jogosultságot az elmúlt évben.

A governance platformok jellemzően azokról az alkalmazásokról készítenek riportot, amelyekhez ténylegesen csatlakoznak, a lefedettséget viszont nem ellenőrzik függetlenül. Ha egy alkalmazást soha nem integráltak, nem jelenik meg a riportban, és a hiányt könnyen összetéveszthetik a megfeleléssel.

Az identitás láthatóságának megértése az IAM-ben: alapfogalmak

Az IAM-ben az identitás láthatóságának alapelve a feltételezés helyett az ellenőrzés. Három kulcsfogalom teszi lehetővé ezt az ellenőrzést: a pontos leltár, a feltérképezett hozzáférési kapcsolatok és a folyamatos, kontextusfüggő elemzés.

Identitások, jogosultságok és hozzáférési kapcsolatok

Az identitásleltár felsorolja a szereplőket. A jogosultságtérkép megmutatja, hogy az egyes szereplők mit tehetnek. A hozzáférési kapcsolatok a kettőt kötik össze a rendszerek között, és a tényleges, nem csak névleges jogosultságokat tárják fel.

A tényleges hozzáférés gyakran jóval szélesebb a tervezettnél. Egy felhasználó, akinek csak szerény alkalmazásszerepet adtak, örökölhet adminisztrátori képességeket egy beágyazott csoporton, egy megosztott szolgáltatásfiókon vagy felhőfiókok közötti trust kapcsolaton keresztül. A kapcsolatok feltérképezése láthatóvá teszi ezeket a láncolt útvonalakat, és a támadók ezeken haladnak végig az oldalsó mozgás során.

Folyamatos felderítés és kontextusfüggő kockázatelemzés

A felderítés nehezebb kérdésre válaszol, mint a leltár: mi létezik azok közül, amit senki sem regisztrált? A folyamatos felderítés közvetlenül az alkalmazásokból és az infrastruktúrából gyűjt identitásadatokat, és felszínre hozza a helyi fiókokat, beágyazott hitelesítő adatokat és hitelesítési módszereket, amelyeket a központi IAM platformok soha nem rögzítettek.

A kontextus ezután rangsorrá alakítja a talált tételeket. Egy tétlen fiók, amely csak olvasási hozzáféréssel rendelkezik egy tesztrendszerhez, alacsony következményű zaj. Egy nem lejáró automatizálási hitelesítő adat, amely írási hozzáférést kapott az éles környezethez, nincs hozzárendelt tulajdonosa, és nem használ többtényezős hitelesítést (MFA), lényegesen nagyobb kockázatot jelent.

Felhős identitásláthatóság és a multicloud identitásláthatóság kihívása

A kontextus abban a pillanatban széttöredezik, hogy az identitásadatok átlépik a szolgáltatói határokat. A felhős identitásláthatóság nem azért nehéz, mert a felhőplatformokból hiányzik a naplózás, hanem mert mindegyik másként modellezi az identitást, és egyik sem írja le, mi történik a többiben.

Identitásszigetek a felhőszolgáltatók és SaaS alkalmazások között

Minden platform a saját szókészletével fejezi ki a jogosultságokat. A multicloud identitásláthatóság lényege, hogy ezeket a szókészleteket egységesítik, így egyetlen identitás útja végigkövethető minden környezetben, amelyet érint.

Normalizálást igénylő identitásmodellek

• AWS: Szerepkörök, identitás- és erőforrásalapú policyk, valamint a fiókok közötti szerepkör-átvétel határozza meg, mit érhet el egy principal.
• Azure/Entra ID: Könyvtárbeli principalek, Azure RBAC szerepkiosztások és jóváhagyott alkalmazásjogosultságok (delegált és alkalmazás scope-ok).
• Google Cloud: Service accountok és IAM bindingek, amelyek az organization–folder–project hierarchián keresztül öröklik a scope-ot.
• SaaS alkalmazások: Saját adminisztrátori szintek, egyedi szerepkörök és helyi fiókok, amelyek soha nem jutnak el az identity providerig.

Normalizálás nélkül a biztonsági csapatok külön-külön vizsgálják az egyes platformokat, és könnyen elsiklik a szemük a kapcsolódási pontok felett: a federált bizalmi viszonyok, a fiókok közötti szerepkör-átvétel és a megosztott hitelesítő adatok felett, amelyek lehetővé teszik, hogy egy felhőben lévő identitás egy másikban is működjön. A felhőn belüli oldalirányú mozgás gyakran ezeket az IAM bizalmi kapcsolatokat követi, nem pedig a hálózati útvonalakat.

Emberi, gépi és nem emberi identitások a felhőben

A gépi identitások a nem emberi identitások egy részhalmazát alkotják, és felhős környezetben gyakran ők adják a principalek többségét. Az infrastruktúra-automatizálás hozza létre őket – pipeline-ok, Terraform futások, orchestration eszközök –, nem pedig a HR által vezérelt belépő–áthelyezett–kilépő folyamatok, ezért általában megkerülik az alkalmazottakra kialakított életciklus-felügyeletet.

A control-plane identitások külön figyelmet érdemelnek. Mivel magát az infrastruktúrát konfigurálják, egy kompromittálódott automatizálási hitelesítő adat új hozzáféréseket hozhat létre, módosíthatja a naplózási beállításokat, vagy letilthatja azokat a kontrollokat, amelyek épp a támadás észlelésére szolgálnának. Minden nem emberi identitásnak ugyanazokból a governance attribútumokból származik előnye, mint egy emberi fióknak: megnevezett tulajdonos, egyértelmű cél, lejárati vagy rotációs ütemezés, valamint aktív monitorozás.

Identitásláthatósági eszközök (IVIP): a legfontosabb képességek

A gépi és emberi identitások nagyléptékű monitorozása az identity visibility and intelligence platformok (IVIP) feladata. Ez a kategória azért jelent meg, mert a governance, a cloud posture és az észlelő eszközök csak a probléma egy-egy részét fedték le. Az alábbi gyártók eltérő architekturális kiindulópontokból közelítik meg a területet.

Identitásláthatósági platformok és elsődleges megközelítéseik

A lista szemléltető jellegű, nem teljes, és nem a teljesítmény alapján rendezett. A képességkészletek átfednek és gyorsan változnak, ezért mindig a saját környezeted és igényeid alapján értékelj. Fontos, hogy ezt az oldalt az Orchid Security teszi közzé, amely maga is szerepel a listában.

• Orchid Security: Az identitásokat, jogosultságokat és hitelesítési folyamatokat közvetlenül az alkalmazásokból és az infrastruktúrából deríti fel, nem csak az IAM konfigurációs adataira támaszkodik, és ezt a telemetriát auditálásra kész megfelelőségi bizonyítékká alakítja. Az alkalmazásréteg vakfoltjaira összpontosít.
• Veza: Megfigyelhetőség-központú access graph, amely a tényleges jogosultságokat térképezi fel az adatplatformok, felhőszolgáltatók és SaaS rendszerek között, külön hangsúlyt fektetve a jogosultságok közötti kapcsolatok elemzésére.
• SailPoint: Governance-központú identitásbiztonsági platform, amely az életciklus-kezelésre, a tanúsítási kampányokra és a szabályok érvényesítésére összpontosít nagyvállalati léptékben.
• Saviynt: Egységesített governance és felhőjogosultság-kezelés, amely az identity governance and administration (IGA) munkafolyamatokat a cloud infrastructure entitlement management (CIEM) elemzéssel ötvözi.
• Silverfort: Futásidejű hitelesítési láthatóságot és érvényesítést biztosít, beleértve a régi és nem menedzselt rendszereket is, amelyeket nem lehet egyszerűen bekötni modern SSO-megoldásokba.
• Semperis: Posture-központú védelem Active Directoryhoz és Entra ID-hez, a konfigurációs higiénére, a támadási útvonalak elemzésére és a helyreállításra helyezve a hangsúlyt.
• CrowdStrike Falcon Identity Protection: Felderítés-központú identity threat detection and response (ITDR), szorosan összekapcsolva az endpoint- és workload-telemetriával.

Egységes identitásleltár és hozzáférési térkép

Akárhonnan indul az architektúra, az alapvető képesség ugyanaz: egy hiteles leltár, amely egyezteti az identitásokat az IdP-k, a felhőplatformok, az alkalmazások és az infrastruktúra között, majd feltérképezi a tényleges hozzáféréseket.

Hasznos próba, hogy a leltár tartalmaz-e olyan identitásokat is, amelyeket senki sem regisztrált. Ha egy platform csak az IAM konfigurációs adatait olvassa, az IAM-ben meglévő vakfoltokat fogja újrateremteni. Az alkalmazásrétegben végzett felderítés különbözteti meg a jelentést a valódi leltártól.

Kockázatészlelés, analitika és elhárítási munkafolyamatok

Az elemzés nélküli leltár csak hosszabb listát ad, nem biztonságosabb környezetet. A felderítés minősége a viselkedési alapvonalon múlik: előbb tudni kell, hogyan néz ki a normál használat egy adott identitásnál, csak utána lehet megítélni az eltérést.

Elemző képességek, amelyeket érdemes értékelni

• Viselkedési alapvonal: Megkülönbözteti a rutinszerű automatizálást ugyanazon hitelesítő adatok szokatlan jogosultság-használatától.
• Támadási útvonalak elemzése: Felméri, hogy egy hibás konfiguráció kihasználható-e a jogosultságok, az elérhetőség és a futásidejű környezet alapján.
• Technikákhoz rendelés: A megállapításokat a MITRE ATT&CK identitáshoz kapcsolódó technikáihoz, például a Valid Accounts (T1078) tételhez igazítja, így az elemzők nem elszigetelt riasztásokról, hanem ellenfél-viselkedésről gondolkodhatnak.
• Elhárítási útvonal: A megállapításokat a felelős csapathoz irányítja, a szükséges bizonyítékokkal együtt, nem egy közös várólistára.

Hogyan illeszkedik az identitásláthatóság és -intelligencia az identity fabric modellbe

Az identitásláthatóság és -intelligencia nem egy újabb helyettesítő réteg. Megfigyelési rétegként működik, amely ellenőrizhetővé teszi a meglévő identitásmegoldásokba fektetett erőforrásokat.

IAM, IGA, PAM és biztonsági üzemeltetés összekapcsolása

Az IAM platformok jellemzően két dimenzióban működnek: tervezési időben, amely az életciklust, a szabályokat és a kiépítést fedi le, illetve futásidőben, amely a hitelesítés és jogosultság-érvényesítés folyamatait jelenti. A láthatósági platformok mindkettőt figyelik, és a kettő közötti eltérésről adnak visszajelzést.

A riportolás minden szomszédos rendszert másképp szolgál ki. Az IGA bizonyítékot kap arról, hogy a jóváhagyások a tényleges hozzáféréseket tükrözik. A privileged access management (PAM) rátalál azokra a privilegizált fiókokra, amelyek a vaultoláson kívül működnek. A biztonsági üzemeltetés pedig olyan identitás-kontekstről kap képet, amely lerövidíti egy vizsgálat során az események időbeli rekonstruálását, ahelyett hogy az elemzőknek több konzol eseményeit kellene kézzel összefűzniük.

Az identity intelligence szerepe a zero trust modellben

A zero trust, ahogy a NIST SP 800-207 leírja, folyamatos ellenőrzésre épül, a folyamatos ellenőrzéshez pedig folyamatos megfigyelés kell. A hozzáférési döntések csak annyira jók, amennyire a mögöttük álló jel: a munkamenet kontextusa, a hitelesítő adatok típusa, a korábbi viselkedés és a célrendszer érzékenysége.

Az identity intelligence adja ezt a jelet. Emellett ellensúlyt is nyújt: bizonyítékot arról, hol nem érvényesül ténylegesen a szabályozás, például ha alkalmazások még mindig régi hitelesítési protokollokat fogadnak el, vagy ha adminisztrátori fiókok MFA nélkül működnek.

Valós használati esetek és bevált megvalósítási gyakorlatok

A priorizálásnál dől el, hogy sok program előrehalad vagy elakad. Az érettebb szervezetek az identitásláthatóságot fejlődési útként kezelik: a kézi, statikus irányítástól az automatizált és folyamatos kontrollon át az alkalmazásokra és infrastruktúrára kiterjedő viselkedésalapú megfigyelésig.

A magas kockázatú identitások és a túlzott jogosultságok előtérbe helyezése

A jogosultságok burjánzása gyakori jelenség felhős környezetekben, sokszor azért, mert a IAM szabályokat a bevezetéskor túl tágra szabták, és utána soha nem igazították a valós igényekhez. Érdemes ott kezdeni, ahol a túlzott jogosultság találkozik a kitettséggel.

Jó első célpontok az olyan gazdátlan service accountok, amelyek éles rendszerekben írhatnak, az MFA nélkül hitelesítő adminisztrátori fiókok, a soha nem forgatott hitelesítő adatok, illetve a már távozott dolgozókhoz tartozó, de még aktív fiókok. Mindegyik kézzelfogható, javítható megállapítás, egyértelmű felelőssel, ami hitelességet ad a teljes programnak.

Lépésenként felépített identitásláthatósági program

A sorrend meghatározása kulcsfontosságú, mert a feltérképezés nagy mennyiségű adatot termel, a mennyiség pedig javítási útvonal nélkül riasztásfáradtsághoz vezet.

A program bevezetésének lépései

• Hatókör meghatározása: Azonosítsd azokat a kiemelten fontos alkalmazásokat és felhős fiókokat, ahol egy identitáskompromittálás okozná a legnagyobb kárt.
• Közvetlen feltérképezés: Az identitás- és jogosultsági adatokat közvetlenül ezekből az alkalmazásokból és infrastruktúra-rétegekből gyűjtsd, ne csak az IdP-ből.
• Tényleges hozzáférés feltérképezése: A beágyazott csoportokat, trust kapcsolatokat és örökölt jogosultságokat fordítsd le tényleges képességekre.
• Felelős kijelölése: Minden fióknak – a nem emberi fiókoknak is – legyen név szerint megjelölt emberi felelőse, valamint felülvizsgálati vagy lejárati dátuma.
• Viselkedésfigyelés: Alapozd meg, mi számít normális használatnak, és jelezd az eltéréseket a jogosultságok használatában és a hitelesítési mintákban.
• Bizonyítékok automatizálása: Készíts megfelelőségi dokumentumokat élő telemetria alapján, ahelyett hogy minden auditciklusban táblázatokat kellene újra összerakni.

A megvalósítás időtartama erősen függ a környezet összetettségétől, az alkalmazások számától és attól, mennyire könnyen elérhetők az alkalmazástulajdonosok.