| Název: | Správa uživatelů a přidělování prostředků |
| Autor: | David Čečelský |
| Publikováno: | Professional Computing 3/2006 |
V listopadovém čísle jsme se věnovali problematice technologií pro správu identit - Identity Management (dále IdM), konkrétně jsme popisovali špičkové produkty. Nyní se budeme věnovat spíše implementaci takové technologie, ať už si zvolíme libovolného výrobce.
Přidělování prostředků (neboli provisioning) byl předmětem činnosti IT oddělení od pradávna. Jednodušeji se prostředky přidělovali ve světě operačních systémů UNIX, později se začalo využívat přidělování prostředků pomocí adresářových služeb. Průkopníkem v této oblasti byl Novell, později se přidal Microsoft a další.
Proč stále váznou implementace správy uživatelů a přidělování prostředků, když jde o historicky známou problematiku. Proč řada společností z kategorie Enterprise vůbec nemá implementovánu technologii, zajišťující tak významné procesy. Příčinou nejsou chybějící technologie, nýbrž záležitosti, které můžeme nazvat brzdou procesu. Jde např. o boje platforem, různé politické důvody, svou roli sehrává i fakt, že technologie pro Identity Management a Provisioning nejsou tak populární, jako jsou třeba technologie pro CRM, ERP, nebo Web Services.
Souboj platforem lze chápat jako přesvědčení zodpovědných osob za to, že právě jimi vybraná platforma je tou nejsprávnější volbou. Obvykle mezi sebou soupeří platformy výrobců operačního systému, jako např. Linux versus Windows apod. Tím samozřejmě nechceme zlehčovat problematiku výběru operačního systému. Ten může mít zcela rozhodující vliv i na volbu adresářové služby, která je v drtivé většině základním stavebním kamenem technologie IdM a Provisioningu.
Proč vlastně IdM
Pouštíme-li se do diskuzí s vrcholovým manažerem na téma mít, či nemít ve společnosti IdM, je potřeba mít po ruce pádné argumenty. Obvykle je dobré si připomenout oblíbené zkratky Total Cost of Ownership (TCO), Return on Investment (ROI) apod., na kterých lze argumentaci založit.
Chceme-li mluvit srozumitelně, pak je vhodné připomenout, že zmiňovaná technologie rozhodně nepředstavuje luxus, nýbrž z hlediska bezpečnosti naprostou nezbytnost. Uveďme některé aspekty z pohledu IT oddělení.
- Zvyšuje se počet spravovaných účtů a hesel. Koncept "single-sign on", jak byl původně definován, je obtížně implementovatelný. Dobře se nasazuje u nových aplikací s třívrstvou architekturou, které se např. integrují do portálů. Většina aplikací je však platformě nezávislá a řeší si autentizaci a autorizaci sama. Starší tzv. "legacy" aplikace vyžadují redesign, což je mnohdy obtížné nebo neproveditelné (dodavatelská firma neexistuje, produkt nahradila jiným).
- Narůstají náklady na administraci - zvyšuje se počet administrátorů, pro každou aplikaci nebo systém je nutné mít jednoho. Neexistuje autoritativní zdroj informací, který by zakládal a rušil účty ve všech systémech. Tato činnost se deleguje na správce a celkový proces se prodlužuje, vznikají bezpečnostní chyby při rušení účtů a výsledkem jsou nekonzistentní procesy.
- Problematika hesel - nároky na helpdesk (řešet hesel). Pro běžného uživatele je složité spravovat si množství různých hesel (obvykle ještě s různou periodou exspirace a požadavku na jeho komplexnost). Běžný uživatel většinou udržuje jen jedno heslo, které si pak mění na všech systémech, což je rovněž bezpečnostní problém.
- Problém auditu - je obtížné sledovat chování uživatele v celém prostředí. Je nutný centrální přehled o pravomocech uživatele v rámci aplikací a systémů, možnost využívat nastavení oprávnění moderními mechanizmy (role/ skupiny v centrální adresářové službě, legování událostí atd.).
Takže další argumenty nám vyplynuly. Jde zjevně o významné šetření provozních nákladů IT, ale také zajištění bezpečnosti. Z hlediska úspory nákladů jde o zlepšení správy uživatelských účtů, kdy se automatizují rutinní postupy jako např. zakládání a rušení uživatelských účtů. Některé činnosti, které dříve spadaly do kompetencí administrátorů, lze delegovat na pověřené osoby, něco si dokážou udělat i samotní uživatelé - "self" administrace.
Bezpečnostní hledisko představuje sledování a porovnávání reálného stavu systému se stavem, který byl definován. Máme pod kontrolou bezpečnostní politiku a přístupová práva uživatelů, můžeme zjistit neoprávněné nebo potenciálně nebezpečné zásahy do částí systému atd. Generování bezpečnostních reportů pro audit není problematické. Další argumenty lze opřít o legislativní nařízení - např. zákony typu Sarbanes-Oxley, HIPAA apod.
Neposledním argumentem je pak lepší možnost komunikace s dalšími organizacemi, partnery, zákazníky, dodavateli. Máme samozřejmě na mysli možnost bezpečného sdílení informací o identitě, což se v odborné literatuře označuje pojmem "federovaná identita".
Globálnost projektu a rizika
Správa uživatelů a přidělování prostředků zasahuje téměř do celého prostředí informačních systémů společnosti. Posuzujeme-li projekt pro malou společnost s celorepublikovou působností, není problematika zdaleka tak náročná, jako např. pro globální nadnárodní firmu. Ve USA budeme muset akceptovat nařízení HIPAA, v rámci EU třeba nařízení Č. 95/46, v Japonsku HPB 517 apod. To zcela jistě a podstatně ovlivní celý projekt. Co se týče dalších rizik, odkázal bych na zajímavou stránku , kde se nachází článek Seven Identity Management Implementation Risks Marka Dixona ze společnosti SUN. Autor v něm definoval sedm hlavních rizik při nasazování IdM technologie, kterým se chce postupně věnovat. Je tedy nač se těšit.
Rozhodující aspekty
Volba platformy a adresářové služby
Jde o první zásadní rozhodnutí, ke kterému nelze podat jednoznačné doporučení. Adresářová služba je základní stavební kámen a hlavní úložiště informací, které IdM technologie využívá. Data s identitou uživatelů jsou obvykle uložena různým způsobem, ať jsou to relační databáze, registry Windows serverů, textové soubory atd. Dále jsou tyto informace rozmístěny v různých místech sítě (servery, aktivní prvky, lokálních disky pracovních stanic).
Adresářová služba v projektu IdM představuje primární datové úložiště pro data s identitou a obsahuje nástroje k pořizování, správě a mazání těchto dat. Součástí adresářových služeb jsou rovněž nástroje pro vlastní monitorování a správu adresáře a samozřejmě i nástroje pro reportování.
Při výběru dnešních technologií se obvykle zastavíme před otázkou, jestli použít SQL nebo LDAP. Jsou jistě zastánci RDBMS, kteří si budou stát za tvrzením, že tento přístup je nejlepší možný. Podobné příznivce najdeme i na straně LDAP. Každý z přístupů má své silné a slabé stránky. RDBMS bude rychlejší pro operace zápisu, pro čtení však rychlostí oplývat nebude. Zato řešení může být robustní. U LDAP systémů je výhodou možnost budování hierarchie stromu, logického členění na dílčí části a jejich replikace napříč prostředím. Tím se zvyšuje jak bezpečnost, tak dostupnost uložených dat.
Dilema lze rozřešit jedině zhodnocením výhod a nevýhod v závislosti na skutečných potřebách projektu a samozřejmě s ohledem na stávající systémy, aplikace a další subjekty.
Konsolidace dat
Důležitým aspektem IdM projektu je zachovat takové prostředí, aby veškeré stávající služby a aplikace měly jasně definovanou cestu k informacím tak, aby s nimi uživatelé dále mohli pracovat. Ne každá aplikace je naprogramována tak, že se např. pomocí vlastního LDAP rozhraní dotáže centrální adresářové služby na autentizační informace uživatele, případně další specifické atributy.
Může nastat i situace, že aplikace již LDAP rozhraní obsahují, ale posléze zjistíme, že jinak je to s LDAP službami v prostředí MS Active Directory a jinak v novelovské eDirectory.
Cesta ven se jmenuje konsolidace dat. K tomu abychom data mohli konsolidovat, můžeme použít různé přístupy:
- Využití Enterprise systémů
Máte-li veškerá data s identitou uložena v jednom adresáři, dostupném kdykoli a odkudkoliv, pak máme problém vyřešen. Správa uživatelů řeší enterprise adresářová služba a přidělování prostředků se děje z jednoho místa. Jde ale o ideální stav, kterého nedosáhneme a vždy pracujeme s více úložišti informací a ještě v heterogenním prostředí. Můžeme mít jednu opravdu enterprise adresářovou službu, ale nikdy ne pouze jediné místo, kde budou uložena data. - Využití technologie metaadresáře
Metaadresář je služba, která sdružuje informace z různých datových zdrojů a umožňuje jednotný pohled a přístup k těmto datům podle definovaného oprávnění. Základem metaadresáře je adresářová služba a další technologické nadstavby (konektory) umožňující napojení na ostatní datové subsystémy. Konektory pomocí synchronizačních mechanizmů zabezpečují agregaci a synchronizaci dat v metaadresáři. Napojené systémy jsou přirozeně vlastníky dat a kontrolují, jak se data pořizují a modifikují. Typickým příkladem metaadresářového řešení jsou např. produkty MIIS (MS Identity Integration Server). Nevýhodou takového řešení je, že dedikujete další adresářovou službu v systému k tomuto účelu a k tomu samozřejmě potřebujete další HW vybavení. - Využití virtuálních adresářových služeb
Virtuální adresářová služba je vlastně metaadresář, ovšem bez nadřazené adresářové služby ve funkci datového úložiště. Virtuální adresářová služba používá databázi, kde má uloženy pouze odkazy na vlastní datové zdroje. Potřebuje-li služba nebo aplikace číst informaci o identitě, kontaktuje virtuální adresářovou službu, která zajistí dotaz na příslušný datový zdroj a vrátí odpověď. Jde o vlastně o jakousi službu identity proxy. Výborné produkty z této oblasti vyvíjela společnost OctetString, akvizicí Oracle patří tato technologie již Oracle. Jako další zástupce uveďme ještě Radiant Logic RadiantOne Virtual Directory Server. Problematickým místem tohoto přístupu může být rychlost čtení v porovnání s metaadresářem, což je pochopitelné. Tento přístup však na druhé straně zajišťuje získání stoprocentně aktuální informace. U tohoto místa je nezbytné zajistit bezpečnost a dostupnost databáze, kde se ukládají odkazy na datové zdroje. Jinými slovy je nutné systém udělat robustní a redundantní, aby nebyl tzv. Single Point of Failure. Je nutné opět zvážit všechna pro a proti a rozhodnout se podle aktuálních potřeb. Zaměřit se na výhody a nevýhody a důkladně posoudit, které funkce jsou prioritní a kde lze případně něco "ošidit". Jakou technologii zvolit jsme řešili v čísle 11/2005 Professional Computingu.
Fáze projektu
Naše společnost se již delší dobu zabývá návrhem a implementací systému IdM a máme k dispozici podrobnou metodiku, kterou uplatňujeme u našich zákazníků. Pokud bychom chtěli souhrnně a obecně popsat základní kroky projektu, pak lze projekt fázovat do šesti dílčích částí.
- Analýza
Jde o důležitou fázi projektu. Je nutné zmapovat stávající prostředí systémů a aplikací a připravit prostředí pro vlastní projekt. Tato etapa rozhodne o kvalitě budoucího návrhu řešení a bez úzké součinnosti s dodavateli aplikací by bylo nemožné budoucí integrační řešení vůbec implementovat. Součástí analýzy je např. stanovení typových pozic a rolí pro koncové uživatele, práce s účty, analýza procesů přidělování zdrojů, určení autoritativních zdrojů a toků dat, definice schvalovacích a eskalačních procesů, správa hesel, definice oprávnění a rolí pro práci s IdM atd.
Budujeme-li adresářovou službu pro centrální úložiště, je nezbytnou součástí také návrh struktury adresářové stromu apod. - Implementace v testovacím prostředí
Tato fáze představuje pro řešitele vybudování laboratorního prostředí, kde budou zastoupeny modelové systémy s testovacími daty a v němž se ladí celkový koncept řešení. Po doladění se řešení testuje, je-li vhodné k nasazení do produkčního prostředí. - Projektování
Množství projektů samozřejmě závisí na potřebách a dohodách řešitelské společnosti se zákazníkem. V každém případě je téměř nezbytné, aby implementace řešení byla vyprojektována na technické úrovni, tj. aby měl zákazník přehled o tom, jaké technologie byly použity, jak jsou implementovány, jaká je integrace se stávajícím prostředím, jaká je konfigurace konektorů do stávajících systémů, jaké jsou bezpečnostní aspekty řešení atd. - Zaškolení obsluhy a uživatelů
Obvykle se zákazník neobejde bez zaškolení administrátorů systému IdM, dále obsluhy a také koncových uživatelů. - Převedení do produkčního prostředí
Téměř kritickou fází projektu je jeho uvedení do provozu v produkčním prostředí. V této fázi je nezbytné zajistit bezproblémový přechod z hlediska uživatelů a stávajících aplikací, aby nedošlo k výraznému omezení provozu, narušení konzistence stávajících dat, nebo k havárii aplikací. - Dokumentace projektu
Zdokumentování celého procesu implementace je samozřejmostí i u jiných projektů třeba i menšího rozsahu. Technická dokumentace by měla dát zákazníkovi možnost získat přehled o přesném nastavení, konfiguraci a dalších parametrech celého IdM systému.
SHRNUTÍ
Implementace IdM technologií není procházkou růžovým sadem. Přináší jistá rizika, vyplývající z komplexnosti projektu, který ovlivňuje řadu IT subsystémů a je spojen s dalšími bezpečnostními, legislativními a jinými aspekty. Pro řadu společností se však nasazení IdM stává již naprostou nutností, a to nejen jako hrozba možného auditu či nedodržení zákona, ale i jako nástroj pro efektivní obchodování a spolupráci. V každém případě však musíme podotknout, že u nás je problematika IdM u společností teprve v plenkách a také technologie, které se v poslední době derou na trh, mají své dětské nemoci.
