Identita uživatelů v síti

Začněme u té nejprostší otázky – proč. Nejčastější a nejdůležitější argumenty pro IdM jsou úspora času a eliminace chyb. Sjednocením identit do jednoho managementu a integrací dalších aplikací či systémů lze docílit výrazné automatizace. Místo definice uživatele na několika různých místech máme jednotnou databázi identit a časová efektivita je jasným argumentem. Ve společnostech postrádajících centrální IdM se naopak často stane, že existují nestandardní účty, nezruší se účty uživatele při jeho odchodu, případně se takové přístupy předávají lidovou slovesností dále. IdM má za úkol popsat celý životní cyklus identity včetně postupů při jejím vzniku, změně či zániku.

Zda je vaše společnost zralá na implementaci IdM se obvykle primárně odvíjí od počtu uživatelů, ale závisí samozřejmě i na dalších integracích s aplikacemi a systémy. Kritická hranice pro nasazení se obvykle pohybuje kolem 500 uživatelů. Start projektu u menších společností doporučujeme důkladně zvážit, zejména s ohledem na rizika, která popisujeme níže. 

Jak vypadá projekt v praxi? Samotná konfigurace IdM je technicky nejjednodušší krok, kterému ale předchází několik komplexních a časově náročných fází.

V první řadě je nutné (re)definovat firemní procesy. Veškerá správa identit musí být propojena s primárním zdrojem identit – což je obvykle personální oddělení. Tam vznikají a zanikají pracovní vztahy a definuje se role pracovníka/uživatele.

Bez důkladné revize dat na obou stranách (IT a HR) je projekt odsouzen k neúspěchu. Každá výjimka z nastaveného standardu pak bude do budoucna komplikací a velký počet výjimek celý projekt paralyzuje. K tomu je potřeba také definovat způsob práce s identitami externích subjektů a oprávnění uživatelů v rámci společnosti – což je zodpovědnost managementu. 

Na procesní definici navazuje definice samotného IdM, což je obvykle otázka hierarchie LDAP systému. Je třeba určit počet vrstev (obvykle maximálně 7) a mnohdy plochou uživatelskou databázi do nich logicky transformovat. Pokud jste si doteď mysleli, že znáte svou vlastní společnost, tak budete při tvorbě nové struktury vyvedeni z omylu. Navazuje jednotná jmenná konvence pro všechny záznamy – skupiny i uživatele. Dnes už je jméno a příjmení uživatele v podstatě pouze sociologický pozůstatek. Nejefektivněji se bude pracovat s jiným jednoznačným identifikátorem. Ve velkých společnostech je často několik uživatelů se shodným jménem a příjmením, některé kombinace jsou zase pro systémy příliš dlouhé a můžete narazit na limit znaků v uživatelském jménu.

Limity pro uživatelská jména jsou zároveň jedním z úskalí při integracích návazných systémů a aplikací. Proto je potřeba již do úvodní analýzy a definice konvencí zahrnout požadavky integrovaných systémů. Obvyklý optimismus ohledně počtu integrovaných aplikací při startu projektu dozná trhliny, jakmile narazíte na nestandardní chování některých aplikací, zastaralé systémy, proprietární protokoly a s tím související časovou a finanční náročnost integrace. Ne vždy je nutné mít integrovaný systém, který je využíván okrajově pouze několika uživateli. Samostatnou kapitolou je pak požadavek na Single Sign On (SSO), který je uživatelsky přívětivější, ale může být extrémně náročný na implementaci. 

Ačkoliv je technickým základem celého projektu IT technologie, z výše popsaného už vyplývá, že samotný projekt zdaleka není pouze záležitostí IT oddělení. Naopak bez součinnosti ostatních organizačních jednotek je projekt odsouzen k nezdaru.

Proto je nutné připravit se na fakt, že celý projekt musí interně řídit jedna osoba schopná koordinovat interní zdroje a komunikovat s externím analytikem/dodavatelem IdM. Tým vyžaduje také člověka, který bude rozhodovat, protože se budou řešit střety kompetencí různých oddělení. Navíc zkušenosti ukazují, že stěžejní je účast někoho, kdo „ví, jak to chodí”. Obvykle služebně staršího zaměstnance, který ví, proč jsou procesy historicky nastaveny tak, jak jsou, a který by mohl do několik let staré proprietární aplikace ještě trochu vidět. V neposlední řadě se bude projekt týkat správců různých aplikací a systémů, pro které je prioritou jejich rutinní práce a původní stav jim může z několika důvodů vyhovovat vice.

Kromě samotných integrací IdM služeb pak s projektem souvisí další technologie, stavěné obvykle nad funkčním IdM – zejména úzce provázaná správa privilegovaných účtů (PIM), která definuje také autorizaci uživatelů. Dále návaznosti na síťové prostředí, jako je 802.1x, případně cloudové aplikace. V neposlední řadě vám IdM může pomoct zpřehlednit výstupy ze SIEM a analytických nástrojů, kam propíše přímo identitu uživatele namísto IP adres a jiných nepřímých identifikátorů. Pro auditní účely je IdM zásadní při tvorbě časových řezů různými událostmi. 

Na závěr shrnutí největších rizik, zejména z pohledu IT, které vás čekají:

• Minimálně 50 % práce je papírování – analýzy, postupy, směrnice, standardy.
• Možná budete za dodání projektu formálně zodpovědní, ale v tom případě potřebujete pro jeho dokončení také odpovídající kompetence. Zejména pro zajištění součinnosti dalších organizačních jednotek.
• I pesimistický odhad pracnosti může být překročen – zejména při definici hierarchie a rolí v IdM a integracích s aplikacemi – obvykle vinou nedostatečně pružné komunikace uvnitř společnosti a směrem k implementátorovi.
• Nový IdM pořizujete, protože je původní systém časově neefektivní – přitom jeho implementaci řešíte v situaci, kdy vám většinu času zabere rutinní provoz.
• Až se vám podaří celý proces úspěšně dokončit, bude potřeba udržet vše konzistentní a dodržovat nastavená pravidla. Aby vám veškerou snahu nezhatila třeba akvizice další společnosti, je potřeba počítat s dalšími požadavky už ve fázi analýzy

Spoluautoři článku:

Maroš Barabas, Lukáš Solil	Tomáš Jurák	Petr Česal	Tomáš Baier	Martin Fruhauf