Svět IAM je plný zkratek. Jak se vyznat v IDM, IGA, AM, PIM a PAM?
7. 10. 2026
Svět IAM je plný zkratek. Jak se vyznat v IDM, IGA, AM, PIM a PAM?
7. 10. 2026
Pod označením IAM se v praxi setkáme s různým pohledem na to, co všechno tato oblast zahrnuje. Někde je těžištěm ověřování uživatelů, jednotné přihlašování (SSO) a vícefaktorová autentizace (MFA). Jinde pod stejnou zkratku organizace zahrnují také životní cyklus identit, účtů a oprávnění. A systém, kterému organizace roky říká IDM, může ve skutečnosti řešit značnou část toho, co se dnes běžně označuje jako IGA.
Nejde nutně o chybu.
Pojmy IAM, IDM, IGA, AM, PIM a PAM mají své definice, jejich hranice ale v praxi nejsou vždy ostré. Dodavatelé i organizace je používají různě, jednotlivé produkty se funkčně překrývají a terminologie se navíc v čase vyvíjí.
Proto je při návrhu architektury, výběru technologie nebo přípravě zadání důležitější než samotná zkratka jiná otázka:
Jakou část řízení identit a přístupů potřebujeme vyřešit a co má konkrétní systém skutečně zajišťovat?
Pro základní orientaci můžeme začít takto – IAM je zastřešující pojem pro řízení identit a přístupů. Zahrnuje několik oblastí:
IDM se stará především o životní cyklus identit a účtů.
IGA řídí a kontroluje oprávnění – kdo je má mít, proč a kdo za ně odpovídá.
AM řeší ověření identity a přístup ve chvíli, kdy chce uživatel nebo systém službu skutečně použít.
PIM řeší privilegovaná oprávnění – kdy a za jakých podmínek identita získá vyšší oprávnění a jak dlouho je může používat.
PAM chrání privilegované účty, přihlašovací údaje a privilegované relace.
Nejlépe ale rozdíly uvidíme na konkrétním příkladu.
Jeden člověk, několik částí IAM
Představme si, že do organizace nastupuje David jako aplikační administrátor.
HR systém už obsahuje informaci o Davidově nástupu. V ostatních systémech ale David zatím neexistuje. Nemá účet, přidělená oprávnění ani administrátorský přístup do produkčního prostředí.
Davidovým nástupem životní cyklus jeho digitální identity začíná. Postupně se do něj zapojí několik různých částí IAM.
IDM: David musí v digitálním prostředí nejprve existovat
Identity Management neboli IDM řeší především správu digitální identity a souvisejících účtů během jejich životního cyklu.
Informace o Davidově nástupu může přijít například z HR systému. IDM na jejím základě vytvoří digitální identitu a zajistí potřebné změny v připojených systémech. Může například:
založit účet v adresářové službě;
vytvořit e-mailovou schránku;
založit účet v interních aplikacích;
synchronizovat jméno, organizační zařazení a další atributy.
Stejný princip platí při změně.
Pokud David přejde do jiného týmu nebo získá novou pracovní pozici, musí se změna promítnout také do jeho digitální identity a souvisejících účtů. Při odchodu je naopak potřeba účty včas zablokovat nebo odstranit.
Typickými pojmy spojenými s IDM jsou proto provisioning, synchronizace a deprovisioning.
IDM: Kdo nebo co má v našem digitálním prostředí existovat a jak se jeho identita v čase mění?
Nemusí přitom jít pouze o zaměstnance. Digitální identity mohou reprezentovat také externisty, zákazníky, technické a servisní účty, aplikace, automatizované procesy nebo další strojové identity.
IGA: Účet existuje. Co v něm ale David smí?
Samotná existence účtu ještě neříká, co může jeho držitel dělat.
David například potřebuje přístup k monitoringu a ticketovacímu systému. Do některých částí produkčního prostředí ale standardně přístup potřebovat nemusí. Některé kombinace oprávnění navíc mohou představovat bezpečnostní riziko.
Tady vstupuje do hry Identity Governance & Administration neboli IGA.
IGA řeší, jaká oprávnění mají identity mít, podle jakých pravidel se přidělují, kdo o nich rozhoduje a jak se jejich oprávněnost průběžně kontroluje.
Typicky sem patří:
definování rolí a pravidel pro přidělování oprávnění,
žádosti o oprávnění a jejich schvalování,
pravidla pro časově omezené přístupy,
pravidelné kontroly a recertifikace oprávnění,
pravidla Segregation of Duties (SoD),
auditní stopa rozhodnutí o přístupech,
pravidla pro změnu nebo odebrání oprávnění při změně role či zániku potřeby.
Rozdíl mezi IDM a IGA je dobře vidět právě ve chvíli, kdy David změní pracovní pozici.
IDM řeší: Které účty a údaje musíme po změně upravit?
IGA řeší: Která oprávnění už David nemá mít, která nově potřebuje a kdo za jejich přidělení odpovídá?
IGA: Co smí identita dělat, proč to smí dělat a kdo za to odpovídá?
Hranice mezi IDM a IGA ale patří k těm nejméně ostrým.
Moderní IGA platformy často samy zajišťují provisioning a deprovisioning. Naopak systémy, které organizace historicky označuje jako IDM, mohou obsahovat role, workflow, schvalování nebo další governance funkce.
Proto při návrhu architektury nestačí říct: „Máme IDM“ nebo „potřebujeme IGA“.
Podstatné je vědět, které konkrétní procesy a funkce systém pokrývá.
AM: David se potřebuje přihlásit
David ráno otevře firemní aplikaci.
V tuto chvíli už není hlavní otázkou, proč mu před několika měsíci vznikl účet nebo kdo schválil jeho oprávnění. Potřebujeme zjistit, kdo se právě přihlašuje a zda jsou splněny podmínky pro přístup.
To řeší Access Management neboli AM.
Typicky sem patří:
autentizace,
vícefaktorová autentizace (MFA),
single sign-on (SSO),
federace identit,
řízení relace,
podmíněný nebo adaptivní přístup,
vyhodnocování přístupových politik.
AM tedy vstupuje do hry především ve chvíli, kdy se identita pokouší získat přístup ke konkrétní aplikaci, službě nebo jinému prostředku.
Systém může ověřit, že se skutečně přihlašuje David, vyžádat další faktor a podle nastavených pravidel rozhodnout, zda jsou splněny podmínky pro vstup.
AM: Je to skutečně David a můžeme mu za daných podmínek umožnit přístup?
PIM: Když David potřebuje administrátorská oprávnění
David je aplikační administrátor a ke své práci občas potřebuje vyšší oprávnění. Neznamená to ale, že je musí mít aktivní neustále.
Právě to řeší Privileged Identity Management neboli PIM. Řídí, kdy a za jakých podmínek může identita získat nebo aktivovat privilegovaná oprávnění. David tak může o potřebná práva požádat ve chvíli, kdy je skutečně potřebuje, případně je získat po schválení a pouze na omezenou dobu.
PIM tím pomáhá naplňovat princip nejnižších potřebných oprávnění a omezuje dobu, po kterou jsou privilegovaná oprávnění aktivní.
PIM: Kdy a za jakých podmínek má identita získat privilegovaná oprávnění?
PAM: Když David vstupuje do produkce s privilegovaným účtem
David je aplikační administrátor a potřebuje zasáhnout přímo v produkčním prostředí. Potřebná oprávnění už má, teď je ale musí bezpečně použít.
Takový přístup představuje výrazně vyšší riziko než běžné používání aplikace. Privilegovaný účet může umožňovat měnit konfiguraci, vytvářet další uživatele, pracovat s citlivými daty nebo zasahovat do bezpečnostních mechanismů.
Proto existuje Privileged Access Management neboli PAM.
PAM chrání privilegované účty, přihlašovací údaje a samotné privilegované relace. Může zajišťovat například:
PAM se přitom netýká jen klasických administrátorských účtů zaměstnanců. Do této oblasti mohou spadat také privilegované servisní účty, technické identity nebo přístupové údaje používané aplikacemi a automatizací.
PAM: Jak chráníme privilegované účty, přihlašovací údaje a relace při jejich používání?
IAM zastřešuje IDM, IGA, AM, PIM i PAM
Identity & Access Management je zastřešující oblast, která řeší digitální identity a jejich přístup k systémům, aplikacím a datům. IDM, IGA, PIM, AM a PAM představují různé části tohoto prostoru.
Oblast
Hlavní otázka
Typické funkce
IDM
Kdo nebo co v prostředí existuje a jak se identita v čase mění?
řízení životního cyklu, provisioning, synchronizace, deprovisioning
IGA
Jaká oprávnění má identita mít, proč je má a kdo za ně odpovídá?
Kdo se přihlašuje a za jakých podmínek získá přístup?
autentizace, SSO, MFA, federace, podmíněný přístup
PIM
Kdy a za jakých podmínek má identita získat privilegovaná oprávnění?
dočasné přidělení privilegovaných rolí, JIT přístup, schvalování, kontrola využití oprávnění
PAM
Jak chráníme nejcitlivější a privilegované přístupy?
bezpečná správa přihlašovacích údajů, jejich rotace, řízení privilegovaných relací, monitoring
Toto rozdělení je záměrně zjednodušené. Neznamená například, že IGA musí být technicky oddělená od IDM, že PIM musí být vždy samostatný systém nebo že konkrétní produkt nemůže pokrývat několik oblastí současně.
Když jednotlivé části IAM nenavazují
Pro základní orientaci můžeme jednotlivé oblasti IAM oddělit. V reálném prostředí ale fungují jako propojený celek.
Problém proto nevzniká ani tak v tom, jak jednotlivé části pojmenujeme, ale ve chvíli, kdy mezi nimi chybí návaznost.
Například:
Máme automatizovaný provisioning, ale chybí governance. Účty vznikají rychle a automaticky. Organizace ale neumí spolehlivě doložit, proč má konkrétní člověk určité oprávnění nebo kdo ho schválil.
Máme propracované schvalování, ale změny se nepropíší všude. Proces rozhodne správně, že uživatel má o oprávnění přijít. Pokud se ale změna neprovede v cílovém systému, riziko zůstává.
Máme MFA, ale účet měl být dávno zrušen. Silná autentizace neřeší problém identity, která už v prostředí nemá existovat.
Máme PAM, ale není jasné, kdo smí privilegovaný přístup získat. Samotná ochrana privilegované relace nestačí, pokud nejsou dobře nastavená pravidla pro přidělení privilegovaného přístupu.
Právě na podobných vazbách se ukazuje, zda organizace identity a přístupy skutečně řídí, nebo pouze provozuje několik samostatných technologií.
V praxi nejde o zkratky
Terminologie pomáhá vytvořit společný jazyk mezi architekty, bezpečností, IT provozem, vlastníky aplikací i dodavateli. Sama o sobě ale neříká, zda organizace řídí identity a přístupy dobře.
Důležité je, aby jednotlivé části na sebe navazovaly a společně pokrývaly celý životní cyklus identit a přístupů.
Dobře navržené IAM je propojené prostředí, ve kterém organizace dokáže spolehlivě odpovědět na základní otázku: Kdo má kam přístup, proč ho má, jak ho získal, za jakých podmínek ho používá a kdy o něj má přijít?
Abychom poskytli co nejlepší služby, používáme k ukládání a/nebo přístupu k informacím o zařízení, technologie jako jsou soubory cookies. Souhlas s těmito technologiemi nám umožní zpracovávat údaje, jako je chování při procházení nebo jedinečná ID na tomto webu. Nesouhlas nebo odvolání souhlasu může nepříznivě ovlivnit určité vlastnosti a funkce.
Funkční
Vždy aktivní
Technické uložení nebo přístup je nezbytně nutný pro legitimní účel umožnění použití konkrétní služby, kterou si odběratel nebo uživatel výslovně vyžádal, nebo pouze za účelem provedení přenosu sdělení prostřednictvím sítě elektronických komunikací.
Předvolby
Technické uložení nebo přístup je nezbytný pro legitimní účel ukládání preferencí, které nejsou požadovány odběratelem nebo uživatelem.
Statistické
Technické uložení nebo přístup, který se používá výhradně pro statistické účely.Technické uložení nebo přístup, který se používá výhradně pro anonymní statistické účely. Bez předvolání, dobrovolného plnění ze strany vašeho Poskytovatele internetových služeb nebo dalších záznamů od třetí strany nelze informace, uložené nebo získané pouze pro tento účel, obvykle použít k vaší identifikaci.
Marketingové
Technické uložení nebo přístup je nutný k vytvoření uživatelských profilů za účelem zasílání reklamy nebo sledování uživatele na webových stránkách nebo několika webových stránkách pro podobné marketingové účely.