Publikujeme

Nacházíte se zde: Úvodní stránka > Publikujeme > Blog > Licence a delegace - seriál o IdM část 3.

Licence a delegace - seriál o IdM část 3.

Licence a delegace - seriál o IdM část 3. 123

V tomto díle se ponoříme hlouběji do řízení rolí a ukážeme si, jak zkrotit nekontrolované bujení oprávnění. Projdeme si řízení licencí, časově omezené role, delegaci privilegovaných úloh, eskalaci jako záchrannou brzdu prokrastinace a vazbu na helpdeskový systém.

Sdílej na sociálních sítích:

V druhém díle seriálu jsme hovořili o řízení rolí. Objasnili jsme si, že role je abstraktní pojmenování pro skupinu oprávnění, která jsou po schválení naráz uživateli přidělena. Seznámili jsme se s pozicí návrháře rolí - metodika, který má na starosti vytváření nových rolí. Dnes pokračujeme dalšími dvěma tématy:

  • Možnosti přidělování oprávnění - je role jediný způsob jak uživateli přidělit oprávnění?
  • Role mining - představení efektivního nástroje na situaci, kdy se role přemnoží.

Možnosti přidělování oprávnění

Způsoby, jak uživateli přidělovat oprávnění, můžeme rozdělit na

  • přímé přidělení - uživatel dostane oprávnění rovnou na koncovém systému,
  • přidělení na základě role - oprávnění uživateli přidělí nepřímo role,
  • a atributu - určitá vlastnost uživatele způsobí, že dostane oprávnění.

 

Obrázek 1 - Způsoby přidělování oprávnění
 

Přímo přidělovaná oprávnění

Přímé přidělení znamená, že uživateli je zdroj (účet na systému, kartička, role v systému) přiřazen napřímo. Je svázán s jeho identitou, a dokud není zažádáno o odebrání oprávnění, má jej přiřazen. To má negativní dopady například při změně pozice uživatele. Na nové pozici dostane nové role, ale o staré nepřijde. Stává se tak z něj sběratel rolí, který za pár let má přístup ke kdejakému firemnímu systému, ať již na něj má na své pozici nárok, nebo ne.

Přístupy na základě rolí

Nedostatek přímého přidělování oprávnění se snaží napravit RBAC přístup (Role-Based Access Control). Jedná se o model, ve kterém jsou uživateli přiřazeny role, které mu teprve dávají určitý stupeň přístupu ke zdroji. Přiřazení role garantuje uživateli určitý nároků na přístup (takzvaný entitlement). Přístup je následně přiřazen buď automaticky, nebo na základě splnění podmínky, nebo na základě schválení odpovědnými osobami. RBAC je v současnosti nejrozšířenější způsob přidělování oprávnění. Při důsledném používání vede však ve větších společnostech k definici desetitisíců rolí, které se liší například různou kombinací atributů uživatele. Pro zlepšení práce s takto definovanými oprávněními byl vymyšlen model ABAC.

Atributy řízená oprávnění

ABAC, čili Attribute-Based Access Control, je atributově řízený přístup ke zdrojům. Například: programátor pracuje na projektu vytěžování dat z firemního Data Warehousu. Z důvodů alokování je proto v interním systému na řízení projektů zařazen do projektu Datamining. Tento atribut je propagován do Identity Manageru. V IdM gestor systému Data Warehouse nastaví, že pokud atribut projekt uživatele obsahuje projekt Datamining, je uživateli povolen účet do systému Data Warehouse. Stejným způsobem může přidat další podmínky, například

  • atribut informačního systému prostředí je roven TEST,
  • aktuální datum je menší než předpokládaný konec projektu.

Role mining

Při přidělování přístupu na základě rolí jsou tyto role buď přímo zadávány do Identity manageru, nebo ukládány do úložiště, ze kterého jsou do systému řízení identit načítány. Těchto úložišť může být víc, Identity manager může například vytvářet role na základě takzvaných autorizačních objektů (skupiny v Active Directory, SAP role, nsrole v LDAP serverech a dalších).

Se vzrůstajícím počtem rolí a komplexností infrastruktury se nevyhnutelně blíží okamžik, kdy je snazší vytvořit v systému novou roli, než dohledávat, zda nějaká role se stejným záběrem oprávnění existuje. Tímto způsobem mohou postupně v databázi rolí vzniknout tisíce až statisíce rolí, jejichž údržba je nesnadná až nemožná. Z toho následně vychází statisíce až miliony přidělených oprávnění, tj. vazeb uživatel-role. A zde nastupují praktiky vytěžování rolí (role mining), které se snaží tento stav zlepšit.

 

Obrázek 2 - Stav před a po role miningu: Uživatelé, role a účty v systémech

Pokud si chceme udělat představu, jak efektivně jsou role navrženy, je jednou z možností použít specializovaný nástroj na "dolování" informací z databáze rolí a oprávnění. Ten umožňuje nad načtenými daty provádět analýzy s využitím pokročilých algoritmů. Tyto analýzy zahrnují:

  • Přehledné pohledy na data, kdy lze efektivně zobrazit vzájemné vazby mezi oprávněními - včetně hierarchie, a vazbou na uživatele, včetně časového přiřazení rolí.
  • Nalezení uživatelů se stejnou či podobnou sadou oprávnění.
  • Nalezení uživatelů, kteří hromadí příliš mnoho oprávnění.
  • Nalezení nepoužívaných oprávnění.
  • Modelování nových rolí pomocí takzvaného "refactoringu" (přepracování) existujících rolí.
  • Vzájemné porovnání rolí s cílem zjistit duplicity ve složení (z pohledu autorizačních objektů, viz výše).

Následující obrázek demonstruje pohled na analyzovaná data v prostředí SAPu.

 

Obrázek 3 - Pohled na data, zleva: Uživatelé, Role, Autor, Objekty a Transakce

Zabudované auditní kontroly umožňují například nalezení rolí, které mají z pohledu obsažených autorizačních objektů stejné či podobné složení. Na příkladu uvedeném níže je nalezena 100% podobnost mezi rolemi pro sekretářku a asistentku. Pravděpodobně se tedy jedná o duplicitní role. Na tomto příkladu je dobře vidět úloha návrháře rolí v procesu role miningu. Role sekretářky se také kryje s rolí vedoucího oddělení autoservisu a specialisty servisů. Výstup z auditní sestavy proto slouží pouze jako podklad pro další práci tohoto specialisty.

 

Obrázek 4 - Nalezení duplicitních rolí

Poznámka: Sloupec „Score“ ukazuje míru podobnosti v %. Podobnost se měří dle vazby role na autorizační objekty.

Po role managementu přejdeme na druhé téma článku, kterým jsou další funkcionality, jež může identity management nabídnout.

Pokročilé funkce identity managementu

Mezi specializovanější funkcionality identity managementu, které jsme dosud v našem seriálu neprobrali, patří:

  • Řízení licencí - co když je přístup do informačního systému navázán na licenci?
  • Časové omezení rolí - pokud nechceme zapomenout někomu odebrat roli.
  • Delegace - aneb jak vyřešit lokálního administrátora.
  • Eskalace - když uživatelé zapomínají na své úkoly.
  • Integrace s Helpdeskem - pro komfortní práci s Identity managerem.

Řízení licencí

V některých informačních systémech je uživatelský přístup podmíněn vydáním licence pro příslušného uživatele. Tato licence může být jmenná na uživatele, nebo přenosná. Přenosná licence zpravidla pouze určuje omezení na současný počet současně evidovaných uživatelů (účtů) v systému nebo službě. Zde jde tedy o to mít aktuální přehled o počtu uživatelů a případné nadlimitní žádosti o přístup odmítnout do navýšení počtu licencí. Tohoto lze dosáhnout zapojením rozhodovací logiky pro řízení licencí do schvalování žádostí o oprávnění.

Příklad řešení: "Běžná firma s.r.o." si pořídila ERP systém pro řízení core businessu, součástí jehož licenčního ujednání je maximální počet 10 uživatelů v systému. Protože tato firma již má IdM řešení zavedeno, ustanovila jednoho pracovníka z nákupu Správcem licencí, a přidala jej jako další krok do procesu schvalování žádostí. Kdykoli odteď někdo požádá o roli, která má atribut "Je třeba schválení Správcem licencí", obdrží zmíněný pracovník úkol v IdM systému posoudit žádost z licenčního hlediska.

 

Obrázek 5 - Řízení licencí v kontextu schvalování žádostí o roli

Časově omezené role

Přesněji řečeno se jedná o časově omezená oprávnění realizovaná formou rolí. Tato funkcionalita se hodí v těch případech, kdy je zapotřebí z jedné nebo druhé strany omezit platnost přidělených oprávnění uživateli. Ať už to je přístup pro externistu, pracujícím na projektu od-do, nástup nového zaměstnance od určitého data, nebo komplexnější příklad změny zařazení pracovníka s omezením platnosti starých rolí do určitého data a přiřazením nových rolí s platností od data změny.

Delegace

Princip delegace spočívá přiřazení definované sady administrativních úkonů privilegovanému uživateli. Tím se z něj stává administrátor pro danou oblast. Tyto administrativní úkony mohou být vydefinovány jak co do funkčnosti - například právo resetovat hesla, právo zakládat uživatele, právo přiřadit uživateli roli, tak i do záběru - právo spravovat uživatele nad určitou organizací.

Eskalace

Pokud v procesu schvalování uživatelských žádostí jde vše podle připravených pravidel, je zřejmé, kdo má za co odpovědnost a kdy bude úkon hotov. Co když ale nastane situace, kdy je schvalovatel neplánovaně indisponován, pracovně přetížen, či informační e-mail o tom, že má posoudit žádost prostě přehlédne? V takovém případě je třeba zapojit eskalační mechanismy. Ty umožňují definovat pravidla co se má stát, pokud v určeném časovém období nedojde k rozhodnutí žádosti. Možnosti jsou například: připomenutí emailem, postoupení na nadřízeného pracovníka, či automatické schválení/zamítnutí žádosti.

Integrace s Helpdeskem

Oblastí, kterou již trochu zasahujeme do integrace IdM řešení s podnikovými systémy, je propojení s helpdeskovým systémem. Helpdeskový systém je rozhraní, které korporátní uživatelé potkávají nejčastěji, pokud něco po někom potřebují. Obsahuje připravené šablony pro všední úkony, jako je žádost o kancelářské vybavení, žádanka o dovolenou, žádost o IT podporu. Integrovat tedy žádosti o oprávnění do tohoto systému je logický krok, který přináší uživatelům jednotnou zkušenost při zadávání žádostí.

Závěrem

Ve třetím díle jsme se seznámili v rámci role managementu s možnostmi, jak lze uživateli přidělovat oprávnění, a ukázali si, jak zkrotit nekontrolované kumulování oprávnění. V druhé části jsme se pak věnovali pokročilým funkcím identity managementu. Prošli jsme řízení licencí, časově omezené role, delegaci privilegovaných úloh, eskalaci v řízení oprávnění a vazbu na helpdeskový systém.

V příštím díle na toto navážeme oblastmi, které s řízením identit souvisí: access management jako aktivní prvek vyhodnocování žádostí o přístup k systémům, a řízení správy SSH klíčů pro lepší management uživatelů linuxových systémů.

 

Autor: Petr Gašparík pracuje posledních 5 let jako solution architect pro oblast řízení identit. Ve společnosti AMI Praha působí 18. rokem a má za sebou řadu významných IT projektů pro zákazníky z komerční i veřejné správy např. ČEZ ICT Services, Česká pošta, či Unicredit Bank Czech Republic and Slovakia.

Článek byl publikován v časopise Computerworld 10/2015.



Přejít na začátek stránky

Mapa stránek

© Copyright 1998-2014 AMI Praha a.s., powered by AMIGO CMS