Nyní pracuji pro společnost zabývající se prodejem softwaru, zejména řešení pro řízení přístupu. A moje zkušenost „z minulého života“ je spojena se zákaznickou stranou – velkým finančním ústavem. V té době se naše skupina kontroly přístupu v oddělení informační bezpečnosti nemohla pochlubit velkými kompetencemi v IdM. Hodně jsme se při tom naučili, museli jsme zaplnit hromadu hrbolků, abychom vybudovali fungující mechanismus pro správu uživatelských práv v informačních systémech ve firmě.
Spojením mých zkušeností získaných u zákazníka se znalostmi a kompetencemi dodavatele se s vámi chci v podstatě podělit o návod krok za krokem: jak vytvořit model řízení přístupu na základě rolí ve velké společnosti a co to přinese v konec. Můj návod se skládá ze dvou částí: první – připravujeme stavbu modelu, druhá – skutečně jej postavíme. Než se pustíte do první části, přípravné.
NB Budování vzoru není bohužel výsledek, ale proces. Nebo spíše dokonce součástí procesu vytváření ekosystému řízení přístupu ve firmě. Nalaďte se tedy na hru na delší dobu.
Nejprve si definujme – co je řízení přístupu založené na rolích? Předpokládejme, že máte velkou banku s desítkami či dokonce stovkami tisíc zaměstnanců (subjektů), z nichž každý má desítky přístupových práv ke stovkám vnitrobankovních informačních systémů (objektů). A nyní vynásobte počet objektů počtem subjektů - to je to, kolik spojení musíte nejprve vybudovat a poté ovládat. Je to opravdu možné udělat ručně? Samozřejmě ne - objevily se role, které tento problém vyřešily.
Role je sada oprávnění, která uživatel nebo skupina uživatelů potřebuje k provádění určitých pracovních úkolů. Každý zaměstnanec může mít jednu nebo více rolí a každá role může obsahovat jedno až mnoho oprávnění, která jsou povolena uživateli v rámci dané role. Role mohou být vázány na určité pozice, oddělení nebo funkční úkoly zaměstnanců.
Role jsou obvykle vytvářeny z jednotlivých oprávnění zaměstnanců v každém informačním systému. Z rolí každého systému se pak formují globální obchodní role. Například obchodní role „úvěrový manažer“ bude zahrnovat několik samostatných rolí v informačních systémech, které se používají v klientské kanceláři banky. Například v hlavním automatizovaném bankovním systému, pokladně, systému elektronické správy dokumentů, manažeru služeb a dalších. Obchodní role jsou zpravidla vázány na organizační strukturu – tedy na soubor firemních oddělení a pozic v nich. Takto se tvoří globální matice rolí (uvádím příklad v tabulce níže).
Stojí za zmínku, že je prostě nemožné vybudovat 100% vzor, který poskytuje všechna potřebná práva pro zaměstnance každé pozice v obchodní struktuře. Ano, to není nutné. Vzor přece nemůže být statický, protože závisí na neustále se měnícím prostředí. A to ze změny podnikatelské činnosti společnosti, která se podle toho dotkne změny organizační struktury a funkčnosti. A z nedostatku plného zajištění zdrojů a z nedodržování popisu práce a z touhy po zisku na úkor bezpečnosti a z mnoha dalších faktorů. Proto je nutné vybudovat vzor, který dokáže pokrýt až 80 % potřeb uživatelů na nezbytná základní práva při jejich jmenování do funkce. A zbývajících 20 % budou moci v případě potřeby vyslechnout později v samostatných aplikacích.
Samozřejmě se můžete zeptat: "Cože, neexistují vůbec žádné 100% vzory?" No proč, to se děje třeba v neziskových strukturách, které nepodléhají častým změnám – v nějakém výzkumném ústavu. Nebo v organizacích vojensko-průmyslového komplexu s vysokou úrovní zabezpečení, kde je bezpečnost na prvním místě. Stává se to v komerční struktuře, ale v rámci jednoho celku, jehož práce je poměrně statický a předvídatelný proces.
Hlavní výhodou správy rolí je zjednodušení udělování práv, protože počet rolí je výrazně 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: zaměstnává tisíce prodejců, kteří však mají v systému N stejnou sadu práv a bude pro ně vytvořena pouze jedna role. Do firmy přišel nový prodejce – byla mu automaticky přidělena potřebná role v systému, který již má všechny potřebné pravomoci. Jedním kliknutím také můžete změnit práva pro tisíce prodejců najednou, například přidat novou možnost generování reportu. Nemusíte dělat tisíc operací, připojovat ke každému účtu nové právo – stačí přidat tuto možnost do role a zobrazí se všem prodejcům zároveň.
Další výhodou správy založené na rolích je vyloučení nekompatibilních oprávnění. To znamená, že zaměstnanec, který má v systému určitou roli, nemůže mít současně jinou roli, jejíž práva by neměla být kombinována s právy v první. Živým příkladem je zákaz kombinace funkcí vstupu a kontroly finanční transakce.
Každý, koho zajímá, jak vůbec došlo k řízení přístupu na základě rolí, může
ponořit se do historie
Pokud se podíváme do historie, pak IT komunita poprvé přemýšlela o metodách řízení přístupu již v 70. letech XNUMX. století. Sice byly aplikace tehdy docela jednoduché, ale stejně jako dnes k nim chtěl opravdu každý pohodlně spravovat přístup. Udělujte, měňte a řiďte uživatelská práva – jen abyste lépe porozuměli tomu, jaký přístup má každý z nich. V té době ale ještě neexistovaly společné standardy, vyvíjely se první systémy kontroly vstupu a každá firma vycházela ze svých představ a pravidel.
Nyní je známo mnoho různých modelů řízení přístupu, ale neobjevily se okamžitě. Pozastavme se u těch, kteří hmatatelně přispěli k rozvoji tohoto směru.
První a asi nejjednodušší model je Volitelná (selektivní) kontrola přístupu (DAC – volitelné řízení přístupu). Tento model předpokládá sdílení práv všemi účastníky procesu přístupu. Každý uživatel získá přístup ke konkrétním objektům nebo operacím. Ve skutečnosti zde množina předmětů práv odpovídá množině předmětů. Ukázalo se, že tento model je příliš flexibilní a příliš náročný na údržbu: přístupové seznamy se postupem času stávají obrovskými a obtížně se ovládají.
Druhý model je Povinná kontrola přístupu (MAC). Podle tohoto modelu získá každý uživatel přístup k objektu v souladu s uděleným přístupem k určité úrovni důvěrnosti dat. Předměty by proto měly být kategorizovány podle úrovně důvěrnosti. Na rozdíl od prvního flexibilního modelu se tento naopak ukázal jako příliš přísný a omezující. Jeho použití se neospravedlňuje, když má společnost mnoho různých informačních zdrojů: abyste vymezili přístup k různým zdrojům, budete muset zavést mnoho kategorií, které se nebudou překrývat.
Kvůli zjevným nedokonalostem těchto dvou metod IT komunita pokračovala ve vývoji modelů, které jsou flexibilnější a zároveň víceméně univerzální pro podporu různých typů organizačních politik řízení přístupu. A tehdy se to objevilo třetí model řízení přístupu na základě rolí! Tento přístup se ukázal jako nejslibnější, protože vyžaduje nejen autorizaci identity uživatele, ale také jeho pracovních funkcí v systémech.
První dobře popsanou modelovou strukturu navrhli američtí vědci David Ferrailo a Richard Kuhn z amerického Národního institutu pro standardy a technologie v roce 1992. Pak se poprvé objevil termín RBAC (Role-based access control). Tyto studie a popisy hlavních komponent a jejich vztahů tvořily základ dodnes platné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 přidruženou sémantikou týkající se oprávnění a odpovědnosti přiřazené uživateli přiřazenému k roli“. Dokument stanovuje základní prvky RBAC – uživatele, relace, role, oprávnění, operace a objekty, jakož i vztahy a vztahy mezi nimi.
Standard poskytuje minimální nezbytnou strukturu pro vybudování vzoru rolí – kombinování práv v rolích a následné vydávání přístupu uživatelům prostřednictvím těchto rolí. Jsou nastíněny mechanismy skládání rolí z objektů a operací, popsána hierarchie rolí a dědičnost pravomocí. Ve skutečnosti v každé společnosti existují role, které kombinují základní pravomoci, které jsou nezbytné pro všechny zaměstnance společnosti. Může se jednat o přístup k e-mailu, k EDMS, k podnikovému portálu atd. Tato oprávnění mohou být zahrnuta do jedné obecné role zvané „zaměstnanec“ a nebude nutné v každé z rolí vyšší úrovně znovu a znovu vypisovat všechna základní práva. Stačí pouze uvést znak dědičnosti role "zaměstnance".
Později byl standard doplněn o nové přístupové atributy související s neustále se měnícím prostředím. Přidána možnost zavádět statická a dynamická omezení. Statické znamenají nemožnost kombinovat role (stejné zadávání a řízení operací jako výše). Dynamické limity lze definovat změnou parametrů, jako je čas (pracovní/nepracovní doba nebo dny), lokalita (kancelář/domov) a podobně.
Samostatně by se mělo říci o Řízení přístupu založené na atributech (ABAC). Tento přístup je založen na udělení přístupu pomocí pravidel sdílení atributů. Tento model lze používat samostatně, ale poměrně často aktivně doplňuje klasický model role: ke konkrétní roli můžete přidat atributy uživatelů, zdrojů a zařízení, ale i čas nebo místo. To vám umožní používat méně rolí, zavést další omezení a učinit přístup minimálně dostatečným, a tím zvýšit zabezpečení.
Účetnímu lze například umožnit přístup k účtům, pokud pracuje v určitém regionu. Poté bude umístění specialisty porovnáno s určitou referenční hodnotou. Nebo můžete udělit přístup k účtům pouze v případě, že se uživatel přihlásí ze zařízení zapsaného v registru povolených. Dobrý doplněk k vzoru rolí, ale jen zřídka se používá samostatně kvůli potřebě vytvořit mnoho pravidel a tabulek oprávnění nebo omezení.
Uvedu příklad použití ABAC z mého "minulého života". Naše banka měla několik poboček. Zaměstnanci klientských kanceláří na těchto pobočkách prováděli úplně stejné operace, ale v hlavním systému museli pracovat pouze s účty ve svém regionu. Nejprve jsme začali vytvářet samostatné role pro každý region – a takových rolí s opakujícími se funkcemi, ale s přístupem k různým účtům, bylo tolik! Potom jsme použitím atributu umístění pro uživatele a jeho propojením s konkrétním rozsahem účtů ke kontrole výrazně snížili počet rolí v systému. V důsledku toho zůstaly role pouze pro jednu pobočku, které byly replikovány na odpovídající pozice ve všech ostatních teritoriálních útvarech banky.
A teď si povíme něco o nezbytných přípravných krocích, bez kterých prostě nejde vybudovat fungující vzor.
Krok 1. Vytvořte funkční model
Vyplatí se začít s vytvořením funkčního modelu – dokumentu nejvyšší úrovně, který podrobně popisuje funkčnost každé jednotky a každé pozice. Zpravidla do něj vstupují informace z různých dokumentů: pracovní náplně a předpisy pro jednotlivé divize - divize, oddělení, oddělení. Funkční model musí být odsouhlasen se všemi zainteresovanými útvary (obchod, vnitřní kontrola, bezpečnost) a schválen vedením společnosti. K čemu je tento dokument? Aby na to vzor mohl odkazovat. Například se chystáte vybudovat model role na základě stávajících práv zaměstnanců – vyřazených ze systému a „redukovaných na společného jmenovatele“. Při domlouvání přijatých rolí s obchodním vlastníkem systému se pak lze odkázat na konkrétní položku funkčního modelu, na základě které je to či ono právo zahrnuto do role.
Krok 2. Provedeme audit IT systémů a vypracujeme plán stanovení priorit
Ve druhé fázi by měl být proveden audit systémů IT, aby bylo možné pochopit, jak je organizován přístup k nim. Moje finanční společnost například provozovala několik stovek informačních systémů. Ve všech systémech existovaly určité základy správy rolí, ve většině - některé role, ale většinou na papíře nebo v systémovém adresáři - jsou dávno zastaralé a přístup k nim byl distribuován na základě skutečných požadavků uživatelů. Přirozeně je prostě nemožné postavit vzor v několika stovkách systémů najednou, někde se začít musí. Provedli jsme hloubkovou analýzu procesu řízení přístupu, abychom určili jeho úroveň vyspělosti. V procesu analýzy byla vypracována kritéria pro upřednostňování informačních systémů - kritičnost, připravenost, plány na vyřazení z provozu atd. S jejich pomocí jsme vybudovali sekvenci pro vývoj / aktualizaci vzorů pro tyto systémy. A pak – zahrnuli vzory rolí do plánu integrace s řešením Identity Management pro automatizaci řízení přístupu.
Jak tedy určit kritičnost systému? Odpovězte si na následující otázky:
- Je systém propojen s provozními procesy, na kterých závisí hlavní byznys společnosti?
- Ovlivní narušení systému integritu majetku společnosti?
- Jaká je maximální přípustná prostoj systému, po jehož dosažení není možné po přerušení obnovit činnost?
- Může narušení integrity informací v systému vést k nevratným důsledkům, finančním i reputačním?
- Kritika vůči podvodům. Přítomnost funkčnosti, s jejíž nedostatečnou kontrolou je možné provádět interní / externí podvodné akce;
- Jaké jsou právní požadavky a také vnitřní pravidla a postupy pro tyto systémy? Budou za nedodržení sankce ze strany regulátorů?
V naší finanční společnosti jsme provedli takový audit. Management vyvinul postup auditu Access Right Review, aby se nejprve vypořádal se stávajícími uživateli a právy v těch informačních systémech, které jsou na seznamu nejvyšších priorit. Vlastníkem tohoto procesu bylo pověřeno bezpečnostní oddělení. Abychom si ale udělali úplný obrázek o přístupových právech ve firmě, bylo nutné do procesu zapojit IT a obchodní oddělení. A tady začaly spory, nedorozumění a někdy i sabotáže: nikdo se nechce odtrhnout od svých dosavadních povinností a zapojit se do nějakých na první pohled nepochopitelných aktivit.
NB Velké společnosti s rozvinutými IT procesy pravděpodobně znají proceduru IT auditu – IT obecné kontroly (ITGC), která umožňuje identifikovat nedostatky v IT procesech a zavést kontrolu tak, aby se procesy zlepšovaly v souladu s nejlepší praxí (ITIL, COBIT, IT Řízení atd.) Takový audit umožňuje IT a byznysu lépe si porozumět a vyvinout společnou strategii rozvoje, analyzovat rizika, optimalizovat náklady a vyvinout efektivnější přístupy k práci.
Jednou z oblastí auditu je zjišťování 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 budování vzoru. Výsledkem takového auditu je registr IT systémů, ve kterém byly stanoveny jejich technické parametry a uvedeny popisy. Navíc byl pro každý systém určen vlastník z obchodního směru, v jehož zájmu byl provozován: byl to on, kdo odpovídal za obchodní procesy, kterým tento systém sloužil. Dále byl jmenován manažer IT služeb odpovědný za technickou implementaci obchodních potřeb v konkrétním IS. Zaznamenávány byly pro společnost nejkritičtější systémy a jejich technické parametry, data zprovoznění a vyřazení z provozu atd. Tyto parametry velmi pomohly v procesu přípravy na budování vzoru.
Krok 3 Vytvořte metodiku
Klíčem k úspěchu každého podnikání je správná metoda. Proto jak k vybudování vzoru, tak k provedení auditu musíme vytvořit metodiku, ve které popíšeme interakci mezi odděleními, zafixujeme odpovědnost v předpisech společnosti atd.
Nejprve musíte prozkoumat všechny dostupné dokumenty, které stanoví postup pro udělení přístupu a práv. Procesy by měly být zdokumentovány na několika úrovních:
- obecné firemní požadavky;
- požadavky na oblasti informační bezpečnosti (závisí na činnosti organizace);
- požadavky na technologické procesy (návody, přístupové matice, směrnice, požadavky na konfiguraci).
V naší finanční společnosti jsme našli spoustu zastaralých dokumentů – museli jsme je uvést do souladu se zaváděnými novými procesy.
Na příkaz vedení byla vytvořena pracovní skupina, ve které byli zástupci z oblasti bezpečnosti, IT, obchodu a vnitřní kontroly. Rozkaz načrtl cíle vytvoření skupiny, směr činnosti, dobu existence a odpovědnosti každé strany. Kromě toho jsme vypracovali metodiku auditu a postup budování vzoru: odsouhlasili je všichni odpovědní zástupci oblastí a schválilo je vedení společnosti.
Dokumenty popisující postup při provádění prací, termíny, odpovědnosti atd. - záruka, že na cestě k vytouženému cíli, který zpočátku není každému zřejmý, nikdo nebude mít otázky „proč to děláme, proč to potřebujeme atd. a nebude zde žádná příležitost „odskočit“ nebo zpomalit proces.
Krok 4. Oprava parametrů stávajícího modelu řízení přístupu
Vypracováváme tzv. „systémový pas“ z hlediska kontroly přístupu. Ve skutečnosti se jedná o dotazník na konkrétní informační systém, ve kterém jsou zaznamenány všechny algoritmy pro řízení přístupu k němu. Společnosti, které již implementovaly řešení třídy IdM, pravděpodobně takový dotazník znají, protože právě u něj začíná studium systémů.
Některé parametry o systému a majitelích přišly do dotazníku z IT registru (viz krok 2, audit), ale byly přidány nové:
- jak jsou účty spravovány (přímo v databázi nebo prostřednictvím rozhraní programu);
- jak se uživatelé přihlašují do systému (pomocí samostatného účtu nebo pomocí účtu AD, LDAP atd.);
- jaké úrovně přístupu do systému se používají (úroveň aplikace, úroveň systému, využití síťových souborových zdrojů systémem);
- popis a parametry serverů, na kterých systém běží;
- jaké operace správy účtu jsou podporovány (blokování, přejmenování atd.);
- jaké algoritmy nebo pravidla se používají k vytvoření identifikátoru uživatele systému;
- jaký atribut lze použít k navázání vazby na záznam o zaměstnanci v personálním systému (celé jméno, osobní číslo atd.);
- všechny možné atributy účtu a pravidla pro jejich vyplňování;
- jaká přístupová práva v systému existují (role, skupiny, atomová práva atd., existují vnořená nebo hierarchická práva);
- mechanismy pro oddělení přístupových práv (podle pozic, divizí, funkčnosti atd.);
- zda má systém pravidla pro segregaci práv (SOD - Segregation of Duties) a jak fungují;
- jak se v systému zpracovávají události nepřítomnosti, přeložení, propuštění, aktualizace údajů o zaměstnancích atd.
Ve výčtu by bylo možné pokračovat a podrobně popisovat různé parametry a další entity, které se účastní procesu řízení přístupu.
Krok 5: Vytvořte Business-Oriented Authorization Description
Dalším dokumentem, který budeme při budování vzoru potřebovat, je průvodce všemi možnými pravomocemi (právy), které lze uživatelům udělit v informačním systému s podrobným popisem obchodní funkce, která za tím stojí. Síly v systému jsou často zašifrovány určitými jmény, skládajícími se z písmen a číslic, a obchodní zaměstnanci nemohou přijít na to, co se za těmito znaky skrývá. Pak jdou do IT služby a tam ... také nedokážou odpovědět na otázku, například o zřídka používaných právech. Pak musíte provést další testování.
Je dobré, pokud již existuje popis podnikání nebo dokonce existuje spojení těchto práv do skupin a rolí. U některých aplikací je osvědčeným postupem vytvořit takového průvodce ve fázi vývoje. To se ale nestává často, takže opět jdeme na IT oddělení shromáždit informace o všech možných právech a popsat je. Náš průvodce bude nakonec obsahovat následující:
- název orgánu, včetně objektu, na který se vztahuje přístupové právo;
- činnost, která je s objektem povolena (prohlížení, změna atd., možnost omezení např. na územním základě nebo na skupině klientů);
- kód oprávnění (kód a název systémové funkce/požadavku, který lze provést pomocí oprávnění);
- popis oprávnění (podrobný popis úkonů v IS při uplatnění oprávnění a jejich důsledky pro proces;
- stav oprávnění: "Aktivní" (pokud je oprávnění přiděleno alespoň jednomu uživateli) nebo "Neaktivní" (pokud oprávnění není použito).
Krok 6 Stáhneme data o uživatelích a právech ze systémů a porovnáme je s personálním zdrojem
V závěrečné fázi přípravy je potřeba nahrát data z informačních systémů o všech uživatelích a právech, která aktuálně mají. Zde jsou možné dva scénáře. Za prvé, bezpečnostní oddělení má přímý přístup do systému a má prostředky ke stažení příslušných zpráv, což je vzácné, ale velmi pohodlné. Za druhé: odešleme požadavek do IT, abychom obdrželi zprávy v požadovaném formátu. Praxe ukazuje, že domluvit se s IT a získat potřebná data není možné hned napoprvé. Je nutné provést několik přístupů, dokud nejsou informace obdrženy v požadované formě a formátu.
Jaká data je třeba nahrát:
- Jméno účtu
- Jméno zaměstnance, kterému je přiděleno
- Stav (aktivní nebo blokovaný)
- Datum vytvoření účtu
- Datum posledního použití
- Seznam dostupných práv/skupin/rolí
Obdrželi jsme tedy uvolnění ze systému se všemi uživateli a se všemi právy, která jsou jim udělena. A okamžitě odložili všechny zablokované účty, protože práce na budování vzoru budou prováděny pouze pro aktivní uživatele.
Pokud pak vaše společnost nemá automatizované prostředky pro uzavření přístupu propuštěným zaměstnancům (to není neobvyklé) nebo existuje patchworková automatizace, která ne vždy funguje správně, musíte všechny „mrtvé duše“ identifikovat. Hovoříme o účtech již propuštěných zaměstnanců, jejichž práva z nějakého důvodu nejsou blokována – je třeba je zablokovat. K tomu porovnáváme nahraná data s personálním zdrojem. Vyložení personálu je také nutné předem zajistit u útvaru vedoucího personální základnu.
Samostatně je nutné vyčlenit účty, jejichž majitelé nebyli nalezeni v personální základně, nikomu nepřiřazeni - tedy bez vlastníka. Pro tento seznam potřebujeme datum posledního použití: pokud je to docela nedávné, pak ještě musíme hledat majitele. To může zahrnovat účty externích dodavatelů nebo servisní účty, které nejsou nikomu přiřazeny, ale jsou spojeny s jakýmikoli procesy. Chcete-li objasnit vlastnictví účtu, můžete poslat dopisy všem oddělením s žádostí o odpověď. Po nalezení vlastníků o nich zadáme údaje do systému: tímto způsobem jsou identifikovány všechny aktivní účty a zbytek je zablokován.
Jakmile budou naše uploady vyčištěny od nepotřebných záznamů a zůstanou pouze aktivní účty, můžeme začít budovat vzor pro konkrétní informační systém. Ale o tom budu mluvit v příštím článku.
Autor: Lyudmila Sevastyanova, manažerka propagace Solar inRights
Zdroj: www.habr.com