Budujeme model řízení přístupu. První část, přípravná

Nyní pracuji ve společnosti, která vyrábí software, konkrétně v oblasti řešení pro správu přístupu. Můj zkušenost "z minulé éry" je spojena se zákaznickou stranou - velkou finanční institucí. V té době naše skupina pro kontrolu přístupu v oddělení IT bezpečnosti nemohla pochlubit velkými kompetencemi v IdM. Mnoho jsme se naučili během procesu, museli jsme si nabít hodně šrámů, abychom ve společnosti vytvořili funkční mechanismus pro správu uživatelských práv v informačních systémech.

Své těžce vybojované zkušenosti ze zákaznické strany kombinuji s vendorovskými znalostmi a kompetencemi a chci se s vámi podělit o jakousi krok za krokem instrukci: jak vytvořit v velké společnosti model řízení přístupu na základě rolí, a co to přinese. Moje instrukce se skládá ze dvou částí: první – připravujeme se na stavbu modelu, druhá – vlastně budujeme. Před vámi je první část, přípravná.

N.B. Vytváření modelu na základě rolí bohužel není výstup, ale proces. A přesněji řečeno, je to část procesu budování ve společnosti ekosystému správy přístupu. Tak se připravte na dlouhou hru.

Nejprve si ujasněme – co vlastně znamená správa přístupu na základě rolí? Představte si, že máte velkou banku s desítkami nebo dokonce stovkami tisíc zaměstnanců (subjektů), z nichž každý má desítky přístupových práv do stovek vnitřních informačních systémů (objektů). A nyní vynásobte počet objektů počtem subjektů – přesně tolik vztahů minimum potřebujete nejprve vytvořit a poté kontrolovat. Je to možné udělat ručně? Samozřejmě že ne – proto byly vytvořeny role.

Role je soubor oprávnění, který je potřebný uživateli nebo skupině uživatelů k vykonávání konkrétních pracovních úkolů. Každý zaměstnanec může mít jednu nebo více rolí, přičemž každá role může obsahovat od jednoho do mnoha oprávnění, která jsou uživateli povolena v rámci této role. Role mohou být spojeny s určitými pracovními pozicemi, odděleními nebo funkčními úkoly zaměstnanců.

Role se obvykle vytvářejí na základě jednotlivých oprávnění zaměstnance v každém informačním systému. Z rolí každého systému se poté formují globální obchodní role. Například obchodní role „úvěrový manažer“ bude zahrnovat několik jednotlivých rolí v informačních systémech, které jsou využívány v klientském kanceláři banky. Řekněme, v takových jako je hlavní automatizovaný bankovní systém, pokladní modul, systém elektronického oběhu dokumentů, servisní manažer a jiné. Obchodní role se obvykle vážou na organizační a pracovní strukturu – jednoduše řečeno, na soubor oddělení společnosti a pozic v nich. Tak se vytváří globální rolová matice (příklad uvádím v tabulce níže).

Je třeba poznamenat, že vytvořit 100% rolový model, zajišťující všechny potřebné pravomoci zaměstnanců na každé pozici v obchodní struktuře, je prostě nemožné. A to ani není potřeba. Vždyť rolový model nemůže být statický, protože závisí na neustále se měnícím prostředí. A na změně obchodní činnosti společnosti, která odpovídajícím způsobem ovlivňuje změnu organizační struktury a funkcionality. A na nedostatku úplného zajištění zdrojům, a na nedodržování pracovních instrukcí, a na snaze o zisk na úkor bezpečnosti, a na mnoha dalších faktorech. Proto je třeba budovat rolový model, který dokáže pokrýt až 80% potřeb uživatelů v potřebných základních právech při jmenování na pozici. A těch zbývajících 20% si budou moci, pokud bude potřeba, dodatečně zažádat později podle jednotlivých žádostí.

Samozřejmě se můžete zeptat: „A co, vůbec neexistují 100% rolové modely?“ Proč by ne, to se občas vyskytuje například v neziskových strukturách, které nejsou náchylné k častým změnám – v nějakém výzkumném institutu. Nebo v organizacích obranného průmyslu s vysokou úrovní zabezpečení, kde bezpečnost je na prvním místě. Někdy i v komerční struktuře, ale v rámci samostatně vybraného oddělení, jehož činnost je dostatečně statická a předvídatelný proces.

Hlavní výhodou rolového řízení je zjednodušení udělování oprávnění, protože počet rolí je zásadně menší než počet uživatelů informačního systému. A to platí pro jakékoli odvětví.

Vezměme si maloobchodní společnost: pracují zde tisíce prodavačů, ale soubor práv v systému N je pro ně stejný, a bude pro ně vytvořena pouze jedna role. Když do společnosti přijde nový prodavač, automaticky mu je přidělena potřebná role v systému, který již obsahuje všechny potřebné pravomoci. Také jedním kliknutím lze změnit práva pro tisíce prodavačů najednou, například přidat novou možnost pro generování zprávy. Není třeba provádět tisíc operací a přidělovat nové právo každému účtu – stačí přidat tuto možnost k roli a ta se objeví u všech prodavačů současně.

Další výhodou rolového řízení je vyloučení udělování neslučitelných pravomocí. To znamená, že zaměstnanec, který má určitou roli v systému, nemůže mít současně jinou roli, jejíž práva by neměla být v souladu s právy v první. Výrazným příkladem je zákaz kombinace funkcí zadávání a kontroly finanční operace.

Všichni, kdo mají zájem o to, jak vlastně vzniklo rolové řízení přístupu, mohou
se ponořit do exkurze do historie
Pokud se podíváme do historie, poprvé se IT společenství zamyslelo nad metodami řízení přístupu již v 70. letech 20. století. Ačkoli aplikace byly tehdy dost jednoduché, avšak, stejně jako dnes, všichni chtěli pohodlně řídit přístup k nim. Poskytování, měnění a kontrolování práv uživatelů – prostě proto, aby bylo jednodušší pochopit, jaký přístup má každý z nich. Ale v té době neexistovaly žádné obecné standardy, vyvíjely se první systémy pro řízení přístupu a každá společnost se zakládala na svých vlastních představách a pravidlech.

Dnes je známo mnoho různých modelů řízení přístupu, ale ty se neobjevily hned. Zaměříme se na ty, které měly významný přínos k rozvoji této oblasti.

První a pravděpodobně nejjednodušší model – Diskreční (vybíravé) řízení přístupu (DAC – Discretionary access control). Tento model předpokládá sdílené využívání práv všemi účastníky přístupového procesu. Každý uživatel má přístup k konkrétním objektům nebo operacím. V podstatě zde odpovídá množství subjektů práv množství objektů. Tento model byl uznán za příliš flexibilní a příliš složitý pro údržbu: přístupové seznamy se časem stávají obrovskými a těžko kontrolovatelnými.

Druhý model je Mandatorní řízení přístupu (MAC — Mandatory access control). Podle tohoto modelu má každý uživatel přístup k objektu na základě stanoveného přístupu k určitému stupni důvěrnosti dat. Odpovídajícím způsobem musí být objekty kategorizovány podle stupně důvěrnosti. Na rozdíl od prvního flexibilního modelu se tento model naopak ukázal jako příliš přísný a omezující. Jeho aplikace se neospravedlňuje, když má společnost mnoho různých informačních zdrojů: pro oddělení přístupu k různým zdrojům bude nutné zavést mnoho kategorií, které se nebudou překrývat.

Vzhledem k zřejmým nedostatkům těchto dvou metod pokračovalo IT společenství ve vývoji modelů, které byly flexibilnější a přitom více či méně univerzální pro podporu různých typů organizačních politik řízení přístupu. A právě tehdy se objevila třetí model řízení přístupu na základě rolí! Tento přístup se ukázal jako nejperspektivnější, protože vyžaduje nejen autorizaci identity uživatele, ale i jeho pracovní funkce v systémech.

První jasně popsanou strukturu rolového modelu navrhli američtí vědci David Ferraiolo a Richard Kuhn z Národního institutu standardů a technologií USA v roce 1992. Tehdy se poprvé objevil termín RBAC (Role-based access control). Tyto výzkumy a popisy základních komponentů, jakož i jejich vzájemné vztahy se staly základem aktuálního standardu INCITS 359-2012, schváleného Mezinárodním výborem pro standardy informačních technologií (INCITS).

Norma definuje roli jako „pracovní funkci v kontextu organizace s určitou související sémantikou týkající se pravomocí a odpovědnosti, které jsou uloženy uživateli přiřazenému k roli“. Dokument stanovuje základní prvky RBAC – uživatelé, relace, role, oprávnění, operace a objekty, stejně jako vztahy a vzájemné vztahy mezi nimi.

Ve standardu je uvedena minimálně potřebná struktura pro vytvoření modelu rolí – sloučení oprávnění do rolí a poté poskytování přístupu uživatelům prostřednictvím těchto rolí. Jsou definovány mechanismy pro sestavení rolí z objektů a operací, popsána hierarchie rolí a dědění pravomocí. Každá společnost má role, které spojují základní pravomoci, které jsou potřebné všem zaměstnancům společnosti. Může to být přístup k e-mailu, k informačnímu systému, k firemnímu portálu atd. Tato oprávnění lze zahrnout do jedné společné role nazvané „zaměstnanec“, a nebude nutné v každé z rolí na vyšší úrovni opakovaně uvádět všechna základní práva. Stačí jen uvést znak dědění role „zaměstnanec“.

Později byl standard doplněn o nové přístupové atributy související s neustále se měnícím prostředím. Byla přidána možnost zavádění statických a dynamických omezení. Statická znamenají nemožnost slučování rolí (ten samý vstup a kontrola operací, zmíněná výše). Dynamická omezení mohou být určena měnícími se parametry, například časem (pracovní/nepracovní hodiny nebo dny), umístěním (kancelář/domů) atd.

Samostatně stojí za zmínku řízení přístupu založené na atributech (ABAC — řízení přístupu založené na atributech). Přístup je postaven na poskytování přístupu pomocí pravidel sdílení atributů. Tento model může být používán samostatně, ale velmi často aktivně doplňuje klasický rolový: k určité roli je možné přidávat atributy uživatelů, zdrojů a zařízení, stejně jako vymezení času nebo místa. To umožňuje použít méně rolí, zavádět další omezení a učinit přístup minimálně dostačujícím, čímž se zvyšuje bezpečnost.

Například účetní může mít přístup k účtům, pokud pracuje v určitém regionu. Poté bude umístění specialisty porovnáváno s konkrétní referenční hodnotou. Nebo může mít přístup k účtům pouze v případě, že se uživatel autorizuje z zařízení, které je zapsáno v registru povolených. Dobré doplnění k rolové modelu, ale samostatně se používá málo kvůli nutnosti vytvářet mnoho pravidel a tabulek oprávnění nebo omezení.

Uvedu příklad použití ABAC z mé "minulé kariéry". V naší bance bylo několik poboček. Zaměstnanci klientských kanceláří v těchto pobočkách prováděli naprosto shodné operace, ale měli pracovat v hlavním systému pouze s účty své regionu. Nejprve jsme začali vytvářet samostatné role pro každý region – a takových rolí s opakující se funkcionalitou, ale s přístupem k různým účtům, vzniklo opravdu velké množství! Poté, co jsme použili atribut umístění pro uživatele a spojili ho s konkrétním rozsahem účtů pro kontrolu, jsme výrazně snížili počet rolí v systému. V důsledku toho zbyly role pouze pro jednu pobočku, které se duplikovaly na odpovídající pozice ve všech ostatních teritoriálních podřízeních banky.

A nyní si povězme o nezbytných přípravných krocích, bez kterých není možné vytvořit funkční rolový model.

Krok 1. Vytváříme funkční model

Začněte vytvořením funkčního modelu – vysoce úrovňového dokumentu, který podrobně popisuje funkčnost každého oddělení a každé pozice. Informace do něj obvykle přicházejí z různých dokumentů: popisů pracovních povinností a předpisů pro jednotlivá oddělení – oddělení, správy, úřady. Funkční model musí být schválen všemi zainteresovanými odděleními (byznys, interní kontrola, bezpečnost) a schválen vedením společnosti. K čemu je tento dokument potřeba? Aby se na něj mohla odkazovat rolová model. Například plánujete vytvořit rolový model na základě již existujících práv zaměstnanců – exportovaných ze systému a „přivedených k jednotnému jmenovateli“. Pak, při schvalování získaných rolí s byznys vlastníkem systému, můžete odkázat na konkrétní bod funkčního modelu, na jehož základě je do role zahrnuto konkrétní právo.

Krok 2. Provádíme audit IT systémů a sestavujeme plán prioritizace

Ve druhé fázi je nutné provést audit IT systémů, abychom pochopili, jak je organizován přístup do nich. Například v mé finanční společnosti se provozovalo několik stovek informačních systémů. Ve všech systémech byly určité základy rolového řízení, v většině – nějaké role, ale většinou na papíře nebo v odkazu systému – tyto byly již dlouho zastaralé a přístup k nim byl udělován na základě skutečných požadavků uživatelů. Samozřejmě, vybudovat rolový model najednou ve stovkách systémů je prostě nemožné, je třeba začít něčím. Provedli jsme hloubkovou analýzu procesu řízení přístupu, abychom určili úroveň jeho zralosti. V průběhu analýzy jsme vypracovali kritéria prioritizace informačních systémů – kritičnost, připravenost, plány na vyřazení z provozu atd. Pomocí těchto jsme stanovili pořadí vývoje/aktualizace rolových modelů pro tyto systémy. A poté – zařadili jsme rolové modely do plánu integrace s řešením pro řízení identity, abychom automatizovali řízení přístupu.

Jak tedy určit kritičnost systému? Odpovězte si na následující otázky:

• Je systém spojen s operačními procesy, od kterých závisí hlavní činnost společnosti?
• Bude mít narušení fungování systému vliv na integritu aktiv společnosti?
• Jaká je maximálně povolená doba nečinnosti systému, po které již není možné obnovit činnost po přerušení?
• Může narušení integrity informací v systému vést k nevratným následkům, a to jak finančním, tak reputačním?
• Kritičnost k podvodům. Přítomnost funkcionality, která při nedostatečné kontrole umožňuje provádění vnitřních/vnějších podvodných činů;
• Jaké jsou požadavky legislativy a také vnitřní pravidla a postupy těchto systémů? Budou za nedodržení uloženy pokuty ze strany regulátorů?

V naší finanční společnosti jsme provedli audit následujícím způsobem. Vedení vypracovalo proceduru auditu Access Right Review, aby se zabývalo existujícími uživateli a právy nejprve v těch informačních systémech, které se dostaly na seznam nejprioritnějších. Majitelem tohoto procesu bylo určeno oddělení bezpečnosti. Abychom však získali úplný obraz o právech přístupu ve společnosti, bylo nutné zapojit do procesu oddělení IT a byznysu. A právě zde začaly spory, nedorozumění a někdy dokonce sabotáž: nikdo se nechce odtrhnout od svých aktuálních povinností a zapojit se do nějakých, na první pohled, nejasných aktivit.

N.B. Velké společnosti s rozvinutými IT procesy jsou určitě obeznámeny s procedurou IT auditu – IT general controls (ITGC), která umožňuje odhalit nedostatky v IT procesech a zřídit kontrolu tak, aby se zlepšily procesy v souladu s best practice (ITIL, COBIT, IT Governance a dalšími). Takový audit umožňuje IT a byznysu lépe se vzájemně pochopit a vypracovat společnou strategii rozvoje, analyzovat rizika, optimalizovat náklady a vyvinout efektivnější přístupy v práci.



Jedním z cílů auditu je určení parametrů logického a fyzického přístupu k informačním systémům. Získaná data jsme vzali jako základ pro další využití při vytváření rolového modelu. V důsledku takového auditu jsme vytvořili registr IT systémů, ve kterém byly určeny jejich technické parametry a uvedeny popisy. Kromě toho byl pro každý systém určen vlastník z obchodního oddělení, v jehož zájmu byl systém provozován: ten byl zodpovědný za obchodní procesy, které tento systém podporoval. Byl také určen manažer IT služby, který byl zodpovědný za technickou realizaci potřeb podnikání v konkrétním informačním systému. Byly zaznamenány nejkritičtější systémy pro společnost a jejich technické parametry, doba uvedení a vyřazení z provozu atd. Tyto parametry nám velmi pomohly v procesu přípravy na vytvoření rolového modelu.

Krok 3 Vytvoření metodologie

Základem úspěchu jakékoli činnosti je správně zvolená metoda. Proto musíme i pro vytváření rolového modelu a provádění auditu vytvořit metodologii, ve které popíšeme interakci mezi odděleními, stanovíme odpovědnost v regulacích společnosti atd.
Nejprve je třeba prozkoumat všechny dostupné dokumenty, které stanovují pořádek poskytování přístupu a práv. Správně by měly být procesy zdokumentovány na několika úrovních:

• obecné firemní požadavky;
• požadavky na oblast informační bezpečnosti (závisí na směrech činnosti organizace);
• požadavky na technologické procesy (pokyny, přístupové matice, metodické pokyny, požadavky na konfigurace).

Ve své finanční společnosti jsme objevili mnoho zastaralých dokumentů – museli jsme je uvést do souladu s novými procesy, které se zaváděly.

Nařízení vedení zřídilo pracovní skupinu, do které byly zařazeny zástupci oblastí bezpečnosti, IT, podnikání a vnitřní kontroly. V nařízení byly vymezeny cíle zřízení skupiny, směr činnosti, doba existence a odpovědné osoby z každé strany. Dále jsme vyvinuli metodiku provádění auditu a pořadí vytváření rolového modelu: tyto položky schválili všichni zodpovědní zástupci oblastí a schválilo je vedení společnosti.

Dokumenty popisující postup provádění prací, termíny, odpovědnost atd. jsou zárukou, že na cestě k vytouženému cíli, který na začátku není každému zřejmý, nikdo nebude mít otázky „proč to děláme, k čemu nám to je a podobně“ a nebude možné „uklouznout“ nebo zpomalit proces.

Krok 4. Fixujeme parametry stávajícího modelu řízení přístupu

Sestavujeme tzv. "pasport systému" v části řízení přístupu. V podstatě se jedná o dotazník k určité informačnímu systému, ve kterém jsou uvedeny všechny algoritmy řízení přístupu k němu. Společnosti, které již implementovaly řešení typu IdM, jsou s podobným dotazníkem jistě obeznámeny, neboť právě s ním začíná zkoumání systémů.

Část parametrů o systému a vlastnících přetekla do dotazníku z registru IT (viz krok 2, audit), ale přibyly i nové:

• jak se provádí správa uživatelských účtů (přímo v DB nebo přes programové rozhraní);
• jak uživatelé vstupují do systému (pomocí samostatného účtu nebo použitím účtu AD, LDAP nebo jiných);
• jaké úrovně přístupu do systému se používají (úroveň aplikace, systémová úroveň, používání síťových souborových zdrojů systémem);
• popis a parametry servery, na kterých systém pracuje;
• jaké operace správy uživatelských účtů jsou podporovány (blokace, přejmenování atd.);
• na jakých algoritmech nebo pravidlech se vytváří identifikátor uživatele systému;
• podle jakého atributu lze navázat spojení s záznamem o zaměstnanci v personálním systému (jméno, číslo tabulky nebo jiný);
• všechny možné atributy uživatelského účtu a pravidla jejich vyplňování;
• jaká práva přístupu existují v systému (role, skupiny, atomární práva atd., existují-li vložená nebo hierarchická práva);
• mechanismy pro oddělení práv přístupu (podle pozic, oddělení, funkcí atd.);
• existují v systému pravidla pro rozdělení práv (SOD – Segregation of Duties), a jak fungují;
• jak se v systému zpracovávají události absence, převedení, propuštění, aktualizace údajů o zaměstnancích atd.

Tento seznam lze pokračovat s podrobnostmi podle různých parametrů a dalších objektů, které jsou zapojeny do procesu správy přístupu.

Krok 5. Vytváříme obchodně orientovaný popis pravomocí

Další dokument, který budeme potřebovat při vytváření rolové modelu, je příručka ke všem možným pravomocem (právům), které lze poskytnout uživatelům v informačním systému s podrobným popisem obchodní funkce, která za tím stojí. Často jsou pravomoci v systému zašifrovány určitými názvy složenými z písmen a číslic, a zaměstnanci obchodu si nemohou vyjasnit, co se skrývá za těmito symboly. Poté se obracejí na IT službu, kde… také nedostanou odpověď na otázku, například ohledně málo používaných práv. To pak vyžaduje další testování.

Dobře, pokud již existuje obchodní popis nebo dokonce konsolidace těchto práv do skupin a rolí. Pro některé aplikace je nejlepší praxí vytvoření takové příručky již v době jejich vývoje. Ale to se vyskytuje zřídkakdy, takže opět jdeme do IT oddělení, abychom shromáždili informace o všech možných právech a popsali je. Naše příručka nakonec bude obsahovat následující:

• název pravomoci, včetně objektu, na který se právo přístupu vztahuje;
• čin, který je povoleno provést s objektem (prohlížení, změna atd., možnost omezení, například podle územního vzoru nebo podle skupiny zákazníků);
• kód pravomoci (kód a název funkce/dotazu systému, které lze provést s použitím pravomoci);
• popis pravomoci (podrobný popis činností v IS při použití pravomoci a jejich důsledků pro proces;
• stav pravomoci: 'Aktivní' (pokud je pravomoc přidělena alespoň jednomu uživateli) nebo 'Neaktivní' (pokud není pravomoc používána).

Krok 6 Vypouštíme z systémů údaje o uživatelích a právech a porovnáváme je s personálním zdrojem

V poslední fázi přípravy je nutné exportovat data z informačních systémů o všech uživatelích a právech, která momentálně mají. Zde jsou možné dvě scénáře. První: bezpečnostní oddělení má přímý přístup do systému a má prostředky pro export příslušných zpráv, což se stává vzácně, ale je to velmi pohodlné. Druhý: posíláme žádost IT oddělení o získání zpráv ve požadovaném formátu. Praxe ukazuje: dohodnout se s IT a získat potřebná data na první pokus se většinou nedaří. Je třeba provést několik pokusů, než budou informace získány ve správném formátu a podobě.

Jaká data je třeba exportovat:

• Název účtu
• Jméno a příjmení pracovníka, na kterého je účet vázán
• Status (aktivní nebo blokovaný)
• Datum vytvoření účtu
• Datum posledního použití
• Seznam dostupných práv/skupin/rolí

Takže jsme získali exporty ze systému se všemi uživateli a se všemi právy, která jsou jim poskytnuta. A hned jsme odložili všechny zablokované účty stranou, protože práce na vytvoření rolového modelu bude probíhat pouze s aktivními uživateli.

Poté, pokud ve vaší společnosti nejsou automatizované prostředky pro uzavření přístupu bývalým zaměstnancům (což se často vyskytuje), nebo pokud existuje kusová automatizace, která ne vždy funguje správně, je třeba identifikovat všechny "mrtvé duše". Hovoříme o účtech již propuštěných zaměstnanců, jejichž práva z nějakého důvodu nejsou blokována – ta je třeba zablokovat. K tomu porovnáváme exportovaná data s personálním zdrojem. Personální export je také třeba nejprve získat od oddělení, které vede personální databázi.

Nejdříve je třeba oddělit účty, jejichž vlastníky jsme nezjistili v personální databázi, které nejsou přiřazeny nikomu – tedy bez majitele. Pro tento seznam budeme potřebovat datum posledního použití: pokud je docela nedávné, budeme muset hledat vlastníky. Může se jednat o účty externích dodavatelů nebo služební účty, které nejsou přiřazeny nikomu, ale jsou spojeny s nějakými procesy. Pro zjištění příslušnosti účtů lze rozeslat e-maily všem oddělením se žádostí o zpětnou vazbu. Jakmile budou vlastníci nalezeni, zadáme jejich údaje do systému: tímto způsobem budou identifikovány všechny aktivní účty a ostatní zablokujeme.

Jakmile jsou naše exporty očištěny od nadbytečných záznamů a zůstaly pouze aktivní účty, můžeme přistoupit k vytváření rolové modelu pro konkrétní informační systém. O tom ale již budu hovořit v dalším článku.

Autor: Ludmila Sevastianova, manažerka propagace Solar inRights

Zdroj: habr.com