CzechPAM: Schvalovací úkoly a úprava dat
Náš nový produkt CzechPAM pomáhá při správě privilegovaných účtů. Má mnoho skvělých vlastností. Jednou z nich je možnost, aby vytvořené úkoly, například přidání uživatele do nějaké skupiny, schvalovali určení uživatelé. Tato vlastnost CzechPAM přidává důležitou kostičku do promyšleného bezpečnostního mechanismu našeho produktu. O tom, jak jsme schvalovací úkoly přenesli do CzechPAM, se dozvíte dále v článku.
Součástí bezpečnostního systému musí být možnost, aby změny důležitých atributů byly schvalovány kompetentními osobami. Programátoři to ale vždy neradi slyší, protože to s sebou přináší spoustu komplikací. Tento fakt je ještě ztěžován tím, že v CzechPAMu je možné změnu atributů, například přidělení systému, ještě časově omezit. Obecně je nutné uchovávat informaci o tom, co se má udělat, ale naplánování dané operace odložit až na okamžik, kdy je daný úkol schválen. Jak to udělat tak, aby takový systém byl univerzální a zároveň robustní?
Vytvoření schvalovacího úkolu
Schvalovací úkoly se nevytváří explicitně, vše se děje až interně v CzechPAMu. CzechPAM je bezpečnostní aplikace, při jejím návrhu jsme kladli důraz na to, aby byla i uživatelsky přívětivá. CzechPAM sám určuje, které akce se mají schvalovat. Pro uživatele by nutnost rozhodování byla pouze nadbytečná informace, která by ztěžovala ovládání. Navíc některé schvalování může být podmíněné — například skupina může mít nastaveného schvalovatele. Uživatel tedy provede nějakou akci a po provedení je pouze informován, zda byla akce vykonána či byl vytvořen schvalovací úkol, který čeká na schválení.
Interně tento proces funguje tak, že server přijme upravenou entitu, která obsahuje všechny změny, jež uživatel provedl. CzechPAM prochází atribut po atributu a zjišťuje, které byly upraveny. U atributů, které nepodléhají schvalování, provede změnu ihned. U zbývajících vytvoří schvalovací úkol pro danou úpravu a atribut uloží v nezměněném stavu. CzechPAM pro každý atribut odvodí, jaká role schvaluje jeho změnu. Dokáže tedy rozeznat i konkrétní identity, na které je tento úkol směřován.
Rozpad na jednotlivé operace
Vygenerovaný schvalovací úkol obsahuje množinu dílčích operací, které se mají provést po schválení úkolu. Operace se dělí na několik různých podtypů podle typu operace. Může se jednat o změnu atributu (např. změna hodnoty atributu isGuarantor na true) či přidání reference (např. přidání uživatele jDoe do skupiny superGroup). Operace si ukládá ID všech zainteresovaných entit, které je unikátní napříč celou aplikací. Dále úkol nese informaci o časové platnosti změny, ať už je časově ohraničená nebo nastavena na neurčito. Tím lze například přidat uživatele do skupiny pouze na určitý týden.
V případě, kdy je úkol schválen, je zavolán interní plánovač, jenž na vstupu dostane tyto operace. Ten je na základě časového omezení dále rozdělí na atomické operace, které se liší v tom, že obsahují přesný čas jejich vykonání. V našem modelovém příkladu omezeného přidání skupiny uživateli na jeden týden by to znamenalo vytvořit dvě operace. Nejprve je třeba přidat uživatele do skupiny. Tato operace by byla naplánována na čas T. Dále by byla naplánována reverzní operace, tedy odebrání skupiny, na čas T + týden. Tento způsob ukládání pouze změn je efektivní v řešení problému, kdy je entita změněna od prvotního naplánování úkolu.
Závěr
V tomto článku jsme si ukázali, jak funguje způsob plánování a vykonávání schvalovacích úkolů. Článek může sloužit jako inspirace při řešení podobného problému. Pokud byste měli nějaké dotazy ohledně výše zmíněných postupů či obecně o CzechPAMu, určitě se na mě neváhejte obrátit na info@bcvsolutions.eu.
