Jak připravit projekt Identity Managementu (aktualizace 2026)

Stojíte před rozhodnutím, jak připravit projekt Identity Managementu (IdM), a potřebujete poradit? Tento článek popisuje, jak projekt Identity Managementu připravit. Motivací článku je srozumitelnost a jednoduchost, nikoli detailní popis analýzy konkrétního nasazení. K tomu jsou určeny jiné naše články. Součástí článku je i praktická ukázka dat na straně připojovaných systémů.

Článek jsme v roce 2026 zásadně aktualizovali. Největší změny oproti původní verzi: implementace s pomocí AI, bezpečnostní požadavky vycházející z NIS2, kombinace IdM + PAM, nasazení ve skupinách firem a hybridní prostředí Active Directory + Entra ID.

Jaké jsou cíle projektu?

Určete cíle projekt konkrétně, srozumitelně a měřitelně. Co vás pálí? Co chcete IdM projektem vyřešit? Přesně vydefinované cíle jsou zásadní pro úspěšnost projektu. Při tvorbě zadání se na ně s klientem vždy soustředíme.

Příklady správných cílů:

• rychlost zakládání účtů pro nové zaměstnance (nástup v řádu hodin, ne dnů),
• delegace rozhodování o přístupech na vlastníky dat a aplikací,
• bezpečnost: zamezení osiřelým a zapomenutým účtům (tzv. mrtvým duším),
• samoobsluha uživatelů: reset hesel, žádosti o práva,
• compliance: schopnost auditorovi doložit, kdo má k čemu přístup a proč; typicky to dnes žene NIS2 a zákon o kybernetické bezpečnosti.

Existují různé potřeby, různé cíle. Zamezte očekávání: „IdM jako magický nástroj nám vyřeší vše„. IdM magickým nástrojem je, ale je třeba jej namířit na konkrétní problémy.

Jak AI mění projekt IdM

Největší posun od prvního vydání tohoto článku přinesla AI. Nejdřív jedno vyjasnění: AI nesmí rozhodovat o přidělování přístupů. Rozhodnutí, kdo dostane jaký účet a oprávnění, musí zůstat v rukou lidí a deterministických, auditovatelných pravidel. Role schvaluje vedoucí nebo garant role, automaticky přiděluje politika a každé rozhodnutí nechává auditní stopu. Žádný regulátor, a upřímně ani žádný bezpečnostní tým, nepřijme odpověď „rozhodl to model“.

Kde AI naopak skutečně září, je rychlé zavedení systému do produkčního provozu. Předpokladem je kvalitní produktová dokumentace, ideálně dostupná online. Z dobré dokumentace vytvoříte kvalitní Skill (znalostní balíček, který si AI asistent načte a pracuje s ním). Od té chvíle vám AI slouží jako konzultant:

• pomáhá napojovat systémy — navrhuje mapování atributů a píše transformační skripty,
• tvoří uživatelské příručky a návody pro administrátory přesně podle vaší konfigurace,
• připravuje testovací scénáře a pomáhá ladit synchronizace,
• odpovídá na otázky typu „jak udělám…“, které by jinak skončily jako ticket u dodavatele.

Praktický důsledek: projekt bude levnější, protože nebudete tolik závislí na implementátorovi. Vaši administrátoři zvládnou podstatně větší část konfigurace sami a konzultanti dodavatele se soustředí na skutečně těžké části.

Co si připravit v projektovém řízení?

Musíte mít jasno hlavně v zadání. Zní to samozřejmě, ale velmi často se setkáváme s vágním zadáním.

Vyhněte se fixnímu zadání u velkých projektů. To je historicky ověřený postup vedoucí k neúspěchu. Nepotkali jsme projekt IdM, který by se obešel bez změnového řízení. Projekty Identity Managementu jsou integračními projekty, u kterých je extrémně náročné až nemožné předem vše analyzovat a navrhnout. Čím větší projekt a delší realizace, tím víc změn v systémech, organizaci i v projektu samotném vznikne. Vytvořte si prostor na změny. I se státním výběrovým řízením to jde.

Agilní způsob vývoje a implementace softwaru je správnou cestou. Organizace se dnes rychle mění a projekt potřebuje prostor na ně reagovat. Agilní vedení projektu je výrazně vhodnější.

Každý projekt musí mít:

1. Zadání rozsahu — alespoň prvního produktu (prototypu, MVP). Zadání musí vycházet z problémů, které má projekt a následné řešení pomoci vyřešit. Jaké systémy chcete Identity Managementem spravovat? Zařaďte tyto systémy do zadání jako orientační, ať je lze změnit bez zásahu do smlouvy! Potkali jsme mnoho případů, kdy firma vypsala výběrové řízení na správu konkrétních systémů a pak bylo potřeba jeden z nich v průběhu vyměnit. Dejte projektovému týmu smluvní pravomoc zadání upravovat.
2. Rozpočet — kolik celkem chcete investovat? Dejte rozpočet jako strop, ze kterého se bude agilně čerpat.

Dále je třeba vydefinovat:

1. projektový výbor — kdo na projektu bude pracovat. Ano, jsou potřeba i zástupci odběratele: projektový vedoucí, IdM administrátor nebo produktový vedoucí, volitelně administrátoři napojovaných systémů,
2. projektové schůzky — 1× týdně nebo 1× za dva týdny,
3. risk log,
4. harmonogram.

Dva až tři systémy pro základní projekt

Dříve zněla standardní rada jednoduše: „vyberte si 2–3 systémy k prvnímu napojení.“ To pro první fázi platí pořád, ale dnes doporučujeme začít o krok dřív: zmapujte všechny systémy ve vaší organizaci. Udělejte si inventuru a roztřiďte ji:

• které systémy obsahují osobní účty (vázané na konkrétního člověka) a které technické a servisní účty (patřící aplikacím, skriptům a integracím),
• které z nich obsahují privilegovaný přístup — administrátorské účty, infrastrukturu, databáze,
• kdo je vlastníkem každého systému a jeho dat.

V projektovém plánu pak myslete na pokrytí všech typů systémů v jednotlivých fázích — ne jen viditelných systémů s osobními účty, zatímco zapomenuté servisní účty s vysokými právy žijí dál bez správy. V první fázi napojte 2–3 nezbytné systémy. Další postupně vykrystalizují do navazujících fází.

Nenechte se dotlačit k připojování co nejvíce systémů najednou v jediném projektu. Velké zadání zpravidla výrazně zvyšuje riziko neúspěchu. Připojujte a automatizujte to, co má skutečně smysl. Očekávejte, že se budete postupně učit — vy i vaše organizace — co je IdM a jak jej nejlépe využít. Právě to vám umožní agilní vedení projektu; fixní zadání naopak situaci komplikuje především vám.

Vydefinujte si systémy, které chcete spravovat (integrovat) přímo, a které nepřímo (nazýváme virtuálně). Přímá integrace stojí úsilí, proto má smysl tam, kde se účty a práva mění často. Pokud v systému zakládáte účet dvakrát do roka, stačí nepřímé napojení virtuálním systémem — vytvoříte ho do minuty a slouží jako evidenční nástroj (kdo má jaký účet na systému) a k úkolování odpovědných adminů.

Studium konektorů předem nepřeceňujte

Jedna věc, kterou dnes můžete řešit mnohem méně než před pár lety: konektory. Oblast IGA a její nástroje jsou dnes tak pokročilé, že obsahují konektory prakticky na všechna rozhraní, která potkáte — REST a SOAP webové služby, databáze přes JDBC, LDAP, PowerShell, Microsoft Graph API a další. Ve většině případů lze použít existující konektor tak, jak je, nebo ho upravit podle konkrétního systému.

A i tady pomáhá AI: pokud výrobce staví na standardizovaném konektorovém frameworku, jako je ConnID, dokáže AI upravit existující REST konektor podle API vašeho systému — nebo napsat zcela nový — za zlomek času, který dřív zabral vývoj konektoru na míru.

Jaká data v systémech spravovat?

Chcete jen zakládat účty, nebo i do detailu spravovat práva? Vydefinujte si, jaká data chcete v každém systému spravovat. To je čistě práce zákazníka — dodavatel může pokládat dobré otázky, ale vaše data nezná.

Jaký je zdroj dat o zaměstnancích? Často personalistika. Pozor — pro různé skupiny identit mohou existovat různé zdroje. Pro ne-zaměstnance bývá zdrojem tabulka externistů, nebo vznikají přímo ve webovém rozhraní IdStory, například samoregistrací se schválením.

Bezpečnostní funkce: nové kritérium výběru

Tady je posun důrazu, který považujeme za zásadní. Důležitější než délka seznamu konektorů, nebo dokonalá příprava synchronizovaných atributů předem, je dnes to, zda systém nabízí funkce odpovídající moderním požadavkům na bezpečnost, především těm vycházejícím z NIS2 a navazující národní legislativy (u nás nový zákon o kybernetické bezpečnosti).

Při výběru IdM/IGA systému si ověřte, že umí:

• Správu technických a servisních účtů — účtů, které nepatří lidem, ale aplikacím, skriptům a integracím. Na tyto účty se ve správě identit nejčastěji zapomíná, přitom bývají vysoce privilegované a s heslem, které se nikdy nemění. Každý musí mít odpovědného garanta, evidovanou platnost a auditní stopu.
• Privilegované účty — přehled, kdo drží zvýšená oprávnění, včetně možnosti předat privilegované účty do PAM systému k trezorování a kontrole relací.
• Pravidelné přeschválení práv (recertifikaci) — kampaně, ve kterých vedoucí a garanti rolí pravidelně potvrzují nebo zamítají přidělená oprávnění, s automatickým odebráním nepotvrzeného a kompletním záznamem pro auditora.
• Auditní reporting — hotové odpovědi na otázky „kdo má k čemu přístup“ a „co a kdy se změnilo“, exportovatelné pro auditora bez toho, aby vývojář psal SQL.
• Retenci dat a GDPR — automatickou anonymizaci nebo archivaci osobních údajů odešlých lidí podle vaší retenční politiky, při zachování auditní stopy.

Pokud vybíraný systém tyto věci neumí, narazíte během pár let — regulace se pohybuje jen jedním směrem. Zjednodušeně: systém tyto funkce podporovat musí, aby garantoval dlouhodobou udržitelnost vaší investice. (IdStory IdM všechny uvedené oblasti pokrývá dedikovanými moduly — správou technických účtů, recertifikací, reporty, PAM integrací a GDPR modulem — takže tento seznam je zároveň náš vlastní checklist.)

IdM a PAM: co nasadit dřív?

Nejčastější dnes nasazovanou kombinací řešení pro IGA je IdM + PAM (Privileged Access Management). Každé z nich řeší jinou vrstvu téhož problému: IdM řídí procesy okolo identit a účtů, t.j. kdo má mít jaký účet a roli, schvalování, životní cyklus, doložitelnost. PAM řídí privilegované účty na nízké úrovni, neboli trezorování a rotaci hesel, zprostředkování a nahrávání relací.

Zaměřte se na kompatibilitu vašeho IdM s PAM systémem (stávajícím i tím, který plánujete). A pokud se chystáte nasadit PAM dřív než IdM, zvažte, zda tu cestu neotočit. IdM totiž nejdřív udělá pořádek v účtech, protože každý účet dostane vlastníka, účel a životní cyklus, a tím připraví půdu pro PAM, který si následně převezme nízkoúrovňové řízení těch privilegovaných. Nasazovat PAM na nezmapovanou krajinu účtů bez vlastníků znamená dělat inventuru dvakrát. V IdStory IdM je toto předání přímé: technické účty označené jako privilegované se předávají do PAM systému (např. CyberArk) k trezorovanému, auditovanému přístupu.

Organizace složené z více firem: myslete na multitenanci

Pokud jste organizace složená z více firem, naplánujte onboarding společností postupně. Firmu po firmě, ne všechny najednou.

Vybrané IdM řešení musí umět multitenantní přístup: oddělit data a administrátorské přístupy mezi organizacemi, ale zároveň zvládat situaci, kdy jeden člověk má úvazky ve více firmách skupiny. V praxi to znamená, že IdM musí kvalitně řídit kontrakty z různých společností a důsledně přidělovat oprávnění na konkrétní kontrakt. Role získaná přes úvazek ve firmě A nesmí tiše přetéct na úvazek téhož člověka ve firmě B.

Zajistěte si dopředu párovací identifikátor. Jde o atribut, který umožní spárovat více záznamů téže osoby z různých HR zdrojů pod jednu identitu v IdM. Ideálně jde o osobní číslo unikátní napříč celou skupinou. Pokud takové není (nebo není unikátní), poslouží anonymizovaná varianta rodného čísla, například jeho hash. IdM pak citlivý údaj vůbec nedrží, a přesto dokáže jednu osobu spolehlivě spárovat přes více společností.

Hybridní Active Directory + Entra ID

Většina organizací dnes provozuje hybridní prostředí Microsoftu, proto integraci plánujte po fázích:

1. První fáze: spravujte lokální Active Directory a nechte Entra ID Connect synchronizovat identity do cloudu. Vaše IdM by tuto konfiguraci mělo podporovat rovnou.
2. Další fáze: napojte Entra ID přímo přes rozhraní Microsoft Graph API. Právě to umožní spravovat i cloud-only objekty, které v lokálním AD nikdy neexistují, jako jsou cloud-only skupiny, Guest účty, přiřazení licencí.

Jednu hranici je dobré držet jasnou: single sign-on a vícefaktorové ověření jsou doménou access managementu (Entra ID, CAS a podobné). IdM/IGA řídí, kdo má jaký účet a roli a vrstvu access managementu zásobuje čistými, aktuálními daty. Obě vrstvy se doplňují; ani jedna nenahrazuje druhou.

Příklad napojení systémů do IdM

Níže je uveden asi nejjednodušší případ, jak do IdM napojit personální systém a Microsoft Active Directory. Pokud takto připravíte data, napojíte systémy do IdM bez jakékoliv další úpravy na straně IdM.

Personalistika (HR systém) jako autoritativní zdroj o zaměstnancích

Mějme pro ukázku HR systém, který obsahuje data v SQL databázi nebo je umí exportovat do CSV souborů. Názvy sloupců mohou být libovolné. Struktura databázových view nebo CSV odpovídá objektům Identita, Vztah (kontrakt) a Organizační struktura popsaným níže.

1/ Osoby

Tabulka osob slouží jako základní zdroj informací pro založení identity uživatele v IdStory.

2/ Vztahy (kontrakty)

Vztah (kontrakt) si lze představit jako pracovní poměr, DPP či DPČ zaměstnance, kontrakt externího dodavatele, stáž na oddělení, studium na fakultě, účast na neplaceném projektu a další. U vztahu je nejdůležitější vlastník; mají-li běžet automatické procesy jako nástup nebo ukončení zaměstnance, pak i platnosti úvazku od/do.

Identita může mít v identity manageru běžně evidováno více pracovněprávních vztahů — vztahy lze synchronizovat z externího zdroje stejně jako identity. Pokud organizace vztahy nevyužívá, není tato synchronizace nutná: identity manager si „sám“ založí výchozí vztah, na který navazuje veškerá funkčnost.

3/ Organizační struktura

V případě požadavku na synchronizaci organizační struktury do IdM je třeba dodržet strukturu dat. Do takto synchronizované struktury lze přiřazovat úvazky identit. IdM podporuje více organizačních struktur — možných je více synchronizací. Při odstranění prvku ze zdroje dat se odpovídající část struktury v identity manageru smaže pouze tehdy, je-li prázdná.

Příklady spravovaných systémů

• Microsoft Active Directory — jedna doména, provisioning identit a jejich členství ve skupinách,
• Entra ID — v hybridním režimu přes AD + Entra ID Connect, nebo přímo přes Graph API (včetně cloud-only skupin a Guest účtů),
• LDAPv3 — provisioning identit a jejich rolí,
• databáze přes JDBC — např. jedna tabulka uživatelů.

Microsoft Active Directory (MS AD)

Příklad zadání:

• instalace a konfigurace IdM,
• napojení na doménu MS AD pro správu uživatelských účtů a jejich členství ve skupinách,
• načítání skupin z MS AD a automatické vytváření odpovídajících rolí v identity manageru,
• správa domácích adresářů uživatelů,
• správa e-mailových schránek na MS Exchange,
• správa životního cyklu certifikátů vydávaných externím uživatelům přes certifikační autoritu.

Příklad spravovaných dat — konektor umožňuje spravovat vše, co adresář vystavuje:

Procesy

Identity Management je procesní nástroj. Data se načítají ze zdrojového systému, transformují, schvalují a zapisují do koncových systémů. Doporučujeme využívat standardní procesy připravené vybraným identity managerem — rozsáhlé úpravy na míru zdražují každý budoucí upgrade.

Hlavní typy procesů:

• Řízení životního cyklu identit (joiner–mover–leaver):
  • synchronizace osob a jejich vztahů (úvazků),
  • standardní proces předání hesla — prvotní heslo se uživateli zašle e-mailem (nebo SMSkou) při vytvoření účtu v AD/LDAP/DB,
  • standardní procesy životního cyklu: nástup (joiner), změna pozice či organizačního zařazení (mover), konec úvazku (leaver), vynětí z evidenčního počtu,
  • automatické přidělování a odebírání oprávnění dle zařazení v organizační struktuře.
• Synchronizace organizační struktury a dalších objektů — např. certifikátů nebo atributů typu čísla karet.
• Schvalovací proces žádosti o práva — změny přidělených rolí. Konfigurace standardního schvalovacího procesu: doplnění žádosti helpdeskem, schválení vedoucím uživatele a/nebo garantem role, případně finální schválení bezpečností.
• Manuální procesy — prováděné uživateli a správci v GUI IdM: žádost o změnu oprávnění, její schválení, reset hesla, hromadné akce, práce s rolemi, spuštění synchronizací apod.

Otázky k procesům

1. Jaké procesy chcete automatizovat? Z jakých systémů chcete synchronizovat data a jaká?
2. Jaký je životní cyklus účtů zaměstnanců, externistů, zákazníků a technických účtů? Sepište si jej alespoň rámcově — vznik, změny, zánik.
3. Jak vypadá životní cyklus organizační struktury a jejích jednotek? Pozor, toto bývá skrytá velká pracnost. Organizační strukturu doporučujeme spravovat v personalistice; IdM ji synchronizuje a změny propaguje dál do systémů.
4. Jak vypadá životní cyklus rolí, skupin v AD a certifikátů — vznik, změny, zánik? I zde se může jednat o skrytě velký úkol hodný samostatného projektu.
5. Jak potřebujete schvalovat? Doporučujeme schvalování jednoduché, maximálně tříkrokové. U složitého schvalování v čase narůstá nespokojenost s délkou schvalovacího kolečka. Přesuňte schvalování z administrátorů na vedoucí a vlastníky dat.

Oprávnění v identity manageru

Kdo a jak bude s IdM pracovat? Toto jsou obvyklé role práv:

• Super administrátor — minimálně jeden uživatel na straně zákazníka s nejvyšším oprávněním v identity manageru,
• Helpdesk — změna hesel, přístup k auditním informacím a odeslaným notifikacím,
• Běžný uživatel — změna vlastního hesla, čtení svého profilu, podávání žádostí o změnu oprávnění,
• Vedoucí — práva jako běžný uživatel, navíc vidí své podřízené a může za ně žádat o změny oprávnění,
• Garant role / vlastník dat — schvaluje přístupy k systému či roli, za kterou odpovídá,
• a další — např. auditor s právy pouze pro čtení.

Jaké účty spravovat?

IdM může spravovat všechny účty a pro každý typ lze nastavit jiné procesy. Jaké účty má smysl spravovat? Integrace a automatizace i s nástrojem IdM stojí nějakou investici — asi nemá smysl automatizovat proces, který se dvakrát do roka aplikuje na hrstku účtů; ten levněji provede administrátor. Typické skupiny účtů:

• Zaměstnanci — identita vzniká začátkem smluvního úvazku, který se do IdM načte z personalistiky.
• Externisté — dodavatelé, zákazníci, studenti apod. Do systémů přistupují často přes VPN, mnohdy s certifikáty. Identity mohou vznikat ve webovém rozhraní IdM, nebo samoregistrací se schválením odpovědnou osobou.
• Technické a servisní účty — účty aplikací a integrací. Nesmí zaniknout s odchodem svého lidského vlastníka; mají vlastní životní cyklus. Každý technický účet by měl mít odpovědného garanta, evidovanou platnost a auditní stopu; IdM může řešit i agendu předávání hesla. Privilegované označte k předání do PAM.
• Privilegované účty — administrátorské účty napříč infrastrukturou a aplikacemi. Veďte jejich přehled s garanty a spravujte je v součinnosti s PAM systémem.

Jaké objekty IdM zpracovává?

Identity, účty, role, skupiny, organizační struktury, úvazky, certifikáty, fotky, katalog rolí, softwarové licence a majetek, VPN přístupy… a akce, které nad nimi uživatelé potřebují provádět v GUI.

Požadavky na HW/SW pro IdM

IdM se obvykle skládá z java aplikace běžící na aplikačním serveru a databáze, kde jsou uložena metadata. Nasazuje se na virtuální server, do kontejnerů, nebo jako připravená appliance. Ve většině případů jde o nenáročný provoz, kdy stačí nízký výkon; víc potřebují jen systémy, které systematicky synchronizují velké objemy dat z mnoha zdrojů.

Příklad HW požadavků našeho IdM: Požadavky na HW/SW serveru.

Součinnost zákazníka

Na co se připravit jako zákazník? Kvalitní dodavatel dokáže formou schůzek a kvalitních otázek získat správné informace. Každopádně je to zákazník, kdo zadává, jaké problémy chce řešit, jaké systémy spravovat, jakými procesy a jaká data.

Níže uvedené úkony se očekávají jako součinnost zákazníka:

• příprava serveru (hardware nebo virtuální server),
• instalace operačního systému, konfigurace firewallu apod.,
• přístup k mailserveru — identity manager vyžaduje SMTP server pro notifikace,
• konfigurace SSL spojení k Active Directory (pokud se spravuje heslo),
• vzdálený přístup pro techniky provádějící implementaci,
• příprava zdroje dat dle formátu výše a jeho zpřístupnění v síti,
• účast na prvotním importu dat, čištění dat a ladění procesů,
• účast na školení a předání prostředí,
• a jedna nová položka: zpřístupněte dokumentaci vašich systémů. Urychlí to práci konzultantů — a je to surovina pro AI Skilly popsané výše.

Závěr

Projekty Identity Managementu bývají rozsáhlé a komplexní integrační projekty a dobrá příprava je základem. Začněte minimálním zadáním, vytvořte minimální produkt a jděte s ním co nejdříve do produkce; následně řešení iterativně vylepšujte a rozšiřujte. Vyvarujete se tak protahování projektu a implementace funkcí, které sice vypadají důležitě, ale nakonec je nevyužijete.

Dvě závěrečná doporučení z pohledu roku 2026. Zaprvé: vybírejte systém podle bezpečnostních funkcí jako správy technických a privilegovaných účtů, recertifikace, auditního reportingu, protože přesně to po vás bude chtít regulace a přesně to garantuje dlouhodobou udržitelnost investice. Zadruhé: využívejte AI, neboť s dobrou dokumentací a kvalitně postaveným Skillem implementaci zrychlí, zlevní a výrazně sníží vaši závislost na implementátorovi. Jen pamatujte na jedinou věc, kterou AI dělat nesmí: rozhodovat o tom, kdo dostane přístup. To zůstává na vašich lidech a vašich pravidlech.