Pokud má uživatel ve společnosti přístup k více informačním systémům, má zpravidla i více přístupových účtů. Tento stav je dán přirozenou heterogenitou podnikových aplikací a stále rostoucími požadavky byznysu. Ve velké organizaci s mnoha zaměstnanci pak hrozí zmatek s možnými vážnými důsledky. Počet aplikací a systémů stále narůstá a schopnost uřídit velké množství účtů v dostatečném čase může být pro organizaci problém. Aby organizace měla jasný přehled o tom, kdo a kdy má k jaké informaci přístup, je třeba uživatelské účty spravovat z jednoho místa. Odpovědi na tyto potřeby nabízí software pro centralizovanou správu uživatelů, zvaný identity management.
Životní cyklus uživatele
Základním procesem identity managementu je životní cyklus identity uživatele. Cyklus zpravidla začíná nástupem zaměstnance do organizace, kdy jsou uživateli zřízeny základní přístupy, například na koncovou stanici, do firemní pošty a intranetu. V průběhu času uživatel získává další nové účty a oprávnění, nebo o oprávnění naopak přichází. Pokud dojde k přerušení pracovního poměru, jsou obvykle účty zaměstnance zneplatněny tak, aby se na ně nemohl přihlásit, přičemž účty fakticky dál existují. Při obnovení pracovního poměru je možné účty jednoduše znovu aktivovat a pokračovat v práci. Při definitivním odchodu zaměstnance jsou účty vymazány. Organizace také poměrně často zažívají změnu uživatelského jména uživatele (uživatelky) či změnu organizačního zařazení pracovníka a s ní související změny v oprávněních.
Identity management (IdM) je informační systém, který dokáže z jednoho místa ovládat životní cyklus všech uživatelských účtů v organizaci a zároveň sledovat jejich změny díky auditu. Pokud přijde nový pracovník, je zařazen do personálního systému (Human resources systém, HR) a pomocí centralizované správy založen do systémů společnosti – tzv. provisioning účtů. Veškerá získaná oprávnění jsou monitorována, zpětně dohledatelná a zaznamenána takovým způsobem, že pokud pracovník ukončí pracovní poměr je možné všechny jeho nabyté účty vymazat. Navíc je možné kdykoli zjistit, jakými účty uživatel v organizaci disponuje a jaká má aktuálně přidělená oprávnění. Stávající procesy v organizaci, které zahrnují správu účtů, je možné podpořit workflow IdM. Workflow obsluhují řadu automatických akcí, jako například synchronizaci identit ze systému HR nebo schvalovací procesy provisioningu. Automatizace procesů přinášejí další přidanou hodnotu v podobě snížení nákladů na lidskou obsluhu a díky automatické synchronizaci identit také vyšší konzistenci dat mezi heterogenními systémy. Samozřejmě je možné řízení účtů zajistit i organizačně bez dodatečné podpory IT, např. vytvořit oddělení pracovníků, kteří tyto aktivity včetně spolehlivé evidence zajistí. Nikdy však nebude možné vyloučit lidskou chybu a personální náklady zřejmě převýší investiční a provozní náklady softwaru, který toto zajistí.
Architektura
Typická architektura IdM je centrálně orientovaná, přičemž jednotlivé koncové systémy jsou k centrálnímu uzlu (IdM) napojeny pomocí tzv. konektorů, nebo též adaptérů či agentů. Koncové systémy jsou všechny aplikace či systémy, které obsahují vlastní úložiště uživatelských účtů. Konektor je pak komponenta IdM, která abstrahuje spojení k úložišti uživatelů v koncovém systému, případně pak obstarává další operace jako je například řízení domovských adresářů nebo poštovních schránek. Implementace konektorů se liší podle výrobce IdM, avšak v dnešní době převažuje tzv. neinvazivní způsob komunikace, který využívá standardní protokoly a vrstvy jako např. JDBC, SSH, LDAP atd. Tento přístup má výhodu v tom, že ve vlastním koncovém systému není třeba realizovat žádnou adaptaci pro IdM na rozdíl od klasického způsobu, kdy se musí ovládaný systém pro identity management uzpůsobovat. Většina produktů IdM nabízí celou škálu předpřipravených konektorů pro řízení uživatelských účtů ve většině nejběžnějších koncových systémů, čímž jsou sníženy náklady na vývoj vlastních řešení.
Modelová architektura identity managementu
Identity management tedy funguje na principu dodání potřebných dat do koncových systémů na základě autoritativní informace. Koncové systémy si pak již vlastními prostředky řídí autentizaci a autorizaci uživatele proti svému úložišti. Opačnou filozofií je access management, kdy si jednotlivé aplikace aktivně ověřují přístup uživatele proti centrální autoritě. V praxi se mohou obě architektury kombinovat, a proto se často hovoří o řešení identity a access managementu.
Nasazení
Ambicí nasazení IdM v organizaci není většinou vytvářet nové procesy, ale převzít maximum stávajících IT procesů do své správy. K tomu aby IdM mohl efektivně vykonávat svoji práci, je nutné jej integrovat do stávající infrastruktury, což samo o sobě není jednoduchý krok a vyžaduje značnou míru koordinace. Jak tedy v praxi probíhá zavedení IdM do provozu? Nejprve je nutné IdM napojit na existující koncové systémy a jejich účty tzv. napárovat na identity uložené v IdM. Toto napárování probíhá v procesu rekonciliace. Rekonciliace v původním významu znamená usmíření se s církví či přijetí hříšníka zpět do společnosti. Ve světě identity managementu jde o uvedení účtů do souladu s IdM. Tedy účtům v koncových systémech se přidělují vlastníci (identity IdM) na základě logických podmínek např. korelace uživatelského jména, emailu apod. Účty bez vlastníka jsou reportovány, nebo rovnou mazány z koncového systému. Procesem rekonciliace je vynucen soulad a řád v koncových systémech.
Dalším úkonem při integraci IdM do stávající infrastruktury je napojení na autoritativní zdroj identit, to znamená obvykle HR systém organizace, který poskytne vstupní data o nových či změněných identitách pro IdM. Autoritativní zdroj může být zpracováván v reálném čase, nebo v pravidelných intervalech synchronizován na koncové systémy, kde se změny provedou. Zde je nutné dobře řízenou koordinací se správci koncových systémů domluvit seznam povolených operací, které může IdM v systému vykonávat, jaké účty IdM řídí a jak provádět reporting o změnách v účtech. Ve většině systémů se totiž vyskytují například i technické či systémové účty, které není možné jednoduše přiřadit k identitě uživatele. V některých případech není vhodné provádět na koncových systémech některé automatické akce jako je mazaní účtu, místo toho stačí účet jen zneplatnit. Správce koncových systémů je možné zahrnout do schvalovacích procesů v IdM tak, aby i nadále měli vliv na životní cyklus účtů ve svých systémech. Většina produktů IdM nabízí základní procesy pro řízení životního cyklu uživatele již v základní instalaci, funkcionalitu je však nezbytné vlastním vývojem upravit tak, aby odpovídala potřebám organizace.
Samoobsluha uživatelů
Co poskytuje IdM běžným uživatelům? Kromě toho, že jejich účty budou založeny rychleji než manuálním procesem, je to možnost samoobsluhy některých úkonů, které dosud musely být zdlouhavě řešeny přes help desk či IT oddělení. Jednou z nejčastěji prováděných aktivit je změna hesla v koncovém systému ať z důvodu toho, že jej uživatel zapomněl nebo v případě, že to vyžaduje firemní politika. Řešení IdM obvykle nabízí předpřipravené webové uživatelské rozhraní, které se dá dalšími úpravami rozšířit pro potřeby zákazníka. Mezi základní funkčnosti patří již zmíněná změna hesla nebo žádosti o zřízení přístupu do koncového systému. IdM je také možné přímo integrovat se stávajícím řešením help desku. Uživatelé nadále podávají své požadavky do známého rozraní firemního help desku, přičemž obsluhu svého požadavku si buď mohou vyřídit sami ve webovém rozhraní IdM, nebo toto mohou ponechat stejně jako dříve na obsluze help desku. Ta ke své práci využije s výhodou IdM, kdy uživateli například založí účet, nebo centrálně změní heslo z jednoho rozhraní. Pokud se uživatel rozhodne vyřídit svůj požadavek v IdM, je výhodou zkrácená doba řešení, protože odpadá manuální práce řešitele požadavku. IdM pak může zpětně informovat help desk o výsledku zpracování požadavku uživatele například přes rozhraní webových služeb.
Řízení oprávnění
Uživatelé zpravidla v podnikových systémech či aplikacích vykonávají různé činnosti, mají přístup k určitému obsahu či funkcím na základě svého systémového oprávnění, tedy autorizace. Autorizační data jsou obvykle uložena v uživatelském účtu na koncovém systému a proto je možné s výhodou k jejich řízení využít IdM. Oprávnění se dle typu koncového systému mohou nazývat různě, např. skupiny, role či profily. Praxe nasazení identity managementu ve velkých organizací ukazuje, že správa oprávnění v koncových systémech je nedílnou součástí správy identit. Zvláště podniky, které disponují ERP systémy nebo dalšími aplikacemi, kde existuje velké množství rolí, řeší otázku jak efektivně tato oprávnění řídit. Jistě je možné tato oprávnění řídit ručně, pomineme-li nákladnost takového řešení, hraje zde velkou roli i bezpečností aspekt. Uživatelé mají tendenci během svého působení v organizaci oprávnění spíše akumulovat než naopak. Nová oprávnění nabývají v situacích, kdy je zaváděn nový systém, mění organizační zařazení nebo se účastní projektu. Proto je výhodné oprávnění pevně svázat s organizačním zařazením pracovníka nebo oprávnění časově omezit pouze na dobu trvání jejich potřeby (např. po dobu projektu).
Dnes již rozšířeným principem v řízení oprávnění je Role-Based Access Control (RBAC), který využívá opakovaně přidělitelné objekty – role. Uživatel mající roli pak získá oprávnění nepřímo přes tuto přidělenou roli. Role samotná pak může obsahovat další atributy, kromě názvu například i schvalovatele či vlastníka role nebo popis. Dále je možné na úrovni rolí řídit pravidla exkluzivity tzv. Segregation of Duties (SoD), kdy uživatel nemůže mít například roli, která jej opravňuje k vydávání faktur společně s rolí, která faktury kontroluje. IdM reprezentuje dílčí oprávnění v koncovém systému pomocí aplikační role.
Uživatelé mohou často mít i stovky až tisíce různých aplikačních rolí. Je jasné, že efektivní správa takového množství rolí je možná jen pokud aplikační role sdružíme do skupin. Tyto skupiny aplikačních rolí se nazývají business role a mohou odkazovat na více oprávnění v různých koncových systémech organizace. Uživatelé tak místo velkého množství aplikačních rolí mají přiřazeno jen několik málo business rolí. Business role zpravidla reprezentuje skupinu zaměstnanců, kteří vykonávají podobné činnosti v rámci organizace. Business role může být odvozena od organizační struktury, kdy zahrnuje všechna oprávnění, která zaměstnanec potřebuje pro zastávání pozice na příslušném organizačním místě. Dalším typem mohou být business role vázané na proces v organizaci nebo na projekt a zahrnují tak oprávnění, která jsou nutná pro vykonávání určité činnosti.
Model správy rolí
Úplná verze tohoto článku vyjde v tištěném SecurityWorldu.
Autor je softwarový specialista
email: martin.lizner@ami.cz
PŘEDPLATNÉ
ČLÁNKY DO MAILU