Řešení pro centrální správu uživatelských účtů (2)

Pokud uživatel už ví, které zdroje jsou ve firmě důležité a které je nutné do centrální správy integrovat a jakým způsobem, je důležité si uvědomit i to, v jaké struktuře společnosti se tyto zdroje nacházejí.


(pokračování 1. dílu)

Je tedy potřeba specifikovat jednotlivé části společnosti, ať z ohledu fyzických lokací společnosti, samostatných logických oddělení či případně přístupů externích společností. Vše je nutné zvážit a definovat dle vzájemných závislostí a nadřazenosti.

Opět platí pravidlo nespěchat a promyslet si ucelenou stávající strukturu ve společnosti, její jednotlivá oddělení a závislosti. Tato část je důležitá, jelikož k těmto oddělením lze poté přidělovat již připojené zdroje a načítat z nich již existující uživatelské účty a ty spravovat. Definice bezpečnostní politiky uživatelských účtů a jejich hesel v jednotlivých částech struktury společnosti je pak velmi variabilní.

V grafickém rozhraní centrálního řešení lze definovat přehledně jednotlivé části struktury společnosti a kdykoliv je upravovat či nastavovat, jaké části struktury uvidí který administrátor řešení (tj. definice privilegií).

 

Definice organizačních rolí

Jedno z nejdůležitějších a také časově nejnáročnějších nastavení centrálního řešení pro správu uživatelských účtů je definice organizačních rolí. V praxi to znamená, že každý uživatel centrálního řešení získává jednu nebo více rolí v nastavené struktuře společnosti. Taková role vychází z definované pozice ve společnosti, z automaticky nebo na vyžádání vytvořených přístupových účtů k potřebným zdrojům nebo z pozice v rámci oddělení (možnost správy účtů svých podřízených či pozice schvalovatele žádostí). Variabilita je tu vysoká a měla by odrážet skutečnou situaci v rámci společnosti.

 

Organizační role je možné definovat jako statické nebo dynamické. Statické role jsou role v rámci celé organizace a opravňují uživatele registrovaného v centrálním řešení používat stávající účty nebo zažádat o nový přístup k danému zdroji (či skupině zdrojů). Statické role jsou přidávány k registrovaným uživatelům centrálního řešení Identity Management manuálně. Dynamické role jsou takové uživatelské role, které se automaticky přiřazují na základě atributů účtů načtených ze zdroje nebo nově vytvořených uživatelských účtů centrálního řešení. Jedná o atributy LDAP účtu, kde se prohledávají shody s hledanou číselnou nebo znakovou hodnotou.

V řešení může existovat nekonečné množství rolí v kombinaci statické a dynamické. V jednu chvíli může existovat uživatel, který dle statických rolí získal přístup a správu svých účtů k přiděleným zdrojům v rámci organizačního oddělení. Vedle něho existuje další uživatel, který má stejné manuální role, ale získal automaticky dle nalezeného atributu účtu „manager“ dynamickou roli pro schvalování požadavků na změnu účtů a hesel od vedlejšího uživatele či všech uživatelů daného oddělení nebo dané role.

 

Model přidělování uživatelských účtů

V této chvíli jsou již nastavená centrální řešení Identity Management, je vytvořena organizační struktura se všemi jejími komponenty a organizační role jsou vydefinované na statické a dynamické. Dále je potřeba přistoupit k vytvoření uživatelského účtu, který budou používat uživatelé nebo administrátoři pro přístup k centrálním řešení.

Možností vytvoření takového účtu je velké množství. Tento účet se může vytvářet manuálně administrátorem centrálního řešení pro správu uživatelských účtů nebo samotným uživatelem přes registrační grafické/webové rozhraní. Další možností je načtení již existujících uživatelských účtů přímo ze zdroje a použití načtených údajů pro vytvoření centrálního účtu řešení. Metody lze i libovolně kombinovat. Důležité však je, aby každý uživatel centrálního řešení získal připojení s možností spravovat své zdrojové účty či dle rolí spravovat účty svých podřízených.

Dalším krokem je provázanost již existujících zdrojových účtů s uživatelským účtem centrálního řešení. K tomuto účelu je potřeba definovat pravidla/předpisy (tzv. „Provisioning policy“), jež říkají, které centrální účty v rámci přidělené organizační role mohou mít provázány zdrojové účty.

Znovu je zde zdůrazněn vliv organizačních rolí, které jsou přiřazeny v rámci hierarchie společnosti k centrálním uživatelským účtům. Důležitou roli zde hrají i pravidla, která si všímají rolí a na základě toho automaticky nebo dle schvalovacího procesu vytvoří nový nebo použije stávající zdrojový účet. Provázanost mezi centrálními a zdrojovými účty lze provést automaticky nebo selektivně administrátorem.

Jak už bylo uvedeno na začátku, centrální řešení se nasazuje u společnosti, kde již vnitřní infrastruktura existuje a kde již zdroje mají nastavené libovolné množství uživatelských připojení. Také jakýkoliv zdroj a jeho účty lze stále spravovat externě odpovědným administrátorem. Další výhodou implementace centrálního řešení je zpětný pohled na provázanost účtů. Ze zdroje je možné kdykoliv načíst stávající připojení a porovnat je s definovanou provázaností (tzv. proces Ověření / Reconciliation).

Tímto procesem je možné odhalit zdrojové účty, které v rámci politik nemohly být provázány s centrálními účty a tyto „sirotky“ (tzv. účty Orphan) zablokovat či deaktivovat. Samozřejmostí je automatické informování odpovědného administrátora o nalezení takového účtu s tím, že je mu ponechána možnost rozhodnutí o osudu takového účtu.

Také je možné nadefinovat pro jednotlivé zdroje nebo skupinu zdrojů politiku hesel, kdy každý existující zdrojový účet bude automaticky překontrolován a bude zjištěna shoda s politikou stávajícího hesla. Pokud bude zjištěna nesrovnalost, je možné zamezit párovatelnosti takového zdrojového účtu s centrálním, dokud nebude problém vyřešen a nenastane shoda nastavení hesla s politikou.

Oba dva procesy načtení zdrojových účtů za účelem spárování s centrálními účty nebo za účelem porovnání lze spouštět manuálně či naplánovaně. Z důvodu snížení zatížení zdrojů lze takové procesy naplánovat na noční hodiny či rozdělit na několik časově oddělených částí (například dle maximálního počtu načtených účtů ze zdroje).

 

 

---Tento článek vyšel v tištěném SecurityWorldu 4/2008

 

dokončení (3. díl)

 











Komentáře