flexideo

Přístupové úrovně


Princip úrovní

Vedle této definice v datové struktuře dokumentů je dán seznam rolí a jejich případné nastavení oddělení, kde každá z těchto rolí má dánu svou přístupovou úroveň (vlastnost secrecy-lev), která je u role, na rozdíl od datového segmentu, dána právě jedním číslem a má určen seznam oddělení, ve kterých uživatelé použivající danou roli pracují (nemusí byt zařazena v žádném oddělení, nebo může být zařazena zároveň v několika odděleních).

Pro každou roli jsou pak dle jejího přístupového práva připraveny vzory dokumentů (jejich XDS a DAD) s určením přístupu pro danou roli formou vlastnosti přístupu, která může obsahovat buď editable nebo read-only. Pokud nemá být daný dokument či jeho segment přístupný vůbec, pak se ze vzorů a map odstraní úplně. Z takto připravených vzorů a map pro jednotlivé dokumenty a role vznikají formuláře, tiskové šablony, dotazy do databáze, seznamy oblastí a prvků pro vyhledávání atd.

V aplikaci flexideo má každý uživatel přidělenu jednu či více rolí, každý úkon nakonec ale provádí pod jednou optimálně zvolenou rolí. Každá role má definovánu určitou úroveň přístupu, což je číslo od jedné do například deseti. Jednička je vždy nejnižší úroveň. Pozor, nejde o číslo role, role 1 je naopak vždy ta s nejvyššími právy, tj. nejvyšší úrovní. Má-li tedy uživatel skrze aktuálně použitou roli přidělenu úroveň jedna, pak má nejnižší možná přístupová práva a naopak.

Například pan Novák využívá roli 5 a role má definovánu bezpečnostní úroveň 3. Dále máme například dva dokumenty klient a smlouva. Řekněme, že zatímco u klienti budou poměrně snadno přístupní, jejich smlouvy s choulostivějšími informacemi chceme lépe zabezpečit. Určíme tedy pro klienty úroveň 2 a pro smlouvy úroveň 4. Pan Novák potom bude mít možnost nahlédnout do klientů a upravovat je, ale do jejich smluv nahlédnout nemůže.

Jiná role zase může prohlížet smlouvy a nemít možnost editace, tedy read-only. V jiném oddělení zase mohou se smlouvami běžně pracovat a mít plný přístup pro editaci (editable).

Vedle přístupu jen pro čtení a plného přístupu editace je tu ještě jedna možnost. Jeto jakýsi mezistupeň mezi oběma jmenovanými přístupy. Jde o variantu, kdy například oblast klient v dokumentu smlouva je propojena na dokument osoba pomocí vlastnosti source. Zde vzniká tzv. výběrový uzel - tedy segment jehož obsah je možné nastavit výběrem dat z jiného dokumentu. Řekněme, že u smlouvy chceme zamezit úpravě údajů osoby klienta, ale zároveň chceme mít možnost tato data z vybrané osoby použít. Kdybychom na oblast klient uplatnili pro některé úrovně přístup jen pro čtení read-only, tak by uživatelé této úrovně nemohli údaje ani vybrat - je jen pro čtení. Kdyby naopak byla oblast klient nastavená i pro nižší úrovně jako editable, pak by mohli nejen vybírat, ale i měnit. Navíc editable bychom nemohli uplatnit pro úrovně, pro které je osoba nastavena jako readonly (replikátor automaticky zvyší zabezpečení údajů klienta dle osoby - pravidlo výběru většího zabezpečení v konfliktní situaci).

Pro tyto případy je tu k dispozici varianta selectable. Ta umožní, aby u výběrového uzlu (jinde nemá tato úroveň význam a chová se jako read-only) bylo možné data vybrat, ale nebylo již možné je danou skupinou uživatelů upravovat.


Úrovně pro oddělení

Přísněji definované zabezpeční obecných úrovní secrecy-lev pro segment je možné uvolnit pro určitá oddělení vlastností section. Nastavení pro sekce jsou prioritní. Je dodržována konvence spolehlivější definice zabezpečení, která říká, že obecnější úrovně se definují přísněji a sekce tvoří explicitní výjimky pro určité skupiny uživatelů (role).

Pro příklad uvažujme dokument "výplatní páska zaměstnance", ktery eviduje vyši mzdy každého zaměstnance každý měsíc. Jedná se tedy o data, ke kterým asi nechceme umožnit přístup většině lidí. Běžně by se tato situace dala vyřešit tím, že do úrovně zabezpečdní dokumentu uvedeme nejvyšší používanou úroveň - 7, která v našem příkladu patří managementu firmy. Jenže management firmy mzdy nezpracovává, na to existuje personální oddělení (nebo personální asistentka). Personální pracovník však nemůže dostat oprávnění 7, jelikož by tak získal nežádoucí přístup i k dalším informacím, které má management k dispozici.

Tuto situaci řeší definice sekcí. V definici dokumentu "vyplatní páska zaměstnance" bychom mohli použít například následující kombinaci:

úroveň = 7

sekce = personalni: 4r,5;

Nyní budou mít k dokumentům výplat přístup všichni pracovníci personálního oddělení s úrovní 4 (pouze pro čtení), 5 a větší (plný přístup). U všech ostatních (tj. nespecifikovaných) oddělení se přístup řídí definováním obecnější úrovně, tedy je zapotřebí úroveň 7. Ale ani všichni z personálního oddělení nemusí mít k tomuto dokumentu přístup. Například asistentka personálního oddělení s přístupovými právy na úrovni 3 nesplňuje požadavky pro zobrazení dokumentu.

V definici sekce můžeme zadat samozřejmě více oddělení. Chceme-li vedle personálního oddělení zpřístupnit dokument ještě účtárně, uvedeme ji jako další v pořadí.

Všiměme si jedné důležité skutečnosti. Definice sekce působí jako výjimka pouze směrem ke snížení potřebné bezpečnostní úrovně, nikoli k jejímu zvyšování (tj. nelze ji použít ke zvýšení potřebné bezp. úrovně jen pro určité oddělení - to nezabere). Může se to někdy zdát jako protichůdné či disfunkční, ale je to nejen naprosto logické, ale i vede to i k větší přehlednosti v pravidlech. Navíc to nepůsobí při správném pochopení a pojetí úrovní v aplikaci potíže. Vždy tedy platí že základní úroveň nastavuje "nejvyšší laťku", kterou je možné pro některá oddělení pouze snížit. Tímto pravidlem se totiž, mimo jiné, řeší možný konflikt oddělení v rámci nastavení u jednoho segmentu. Uvažme, že pro určitý segment jsou uvedeny různé úrovně pro dvě různá oddělení a hlavní úroveň je nastavena vysoko. V praxi se může stát, že jeden uživatel je zařazen v obou odděleních. Pokud takový pracovník má přístupovou úroveň, která je mezi objema nastaveními, musí existovat jasné pravidlo, podle kterého se rozhodne, zda daný segment bude takovému uživateli přístupný či nikoli. To pravidlo je právě v tom, že sekce vždy snižuje potřebnou bezpečnostní úroveň. Pro její zvyšování slouží základní úroveň. Zmíněný uživatel tedy bude mít k segmentu přístup - je součástí oddělení, které se segmentem může/potřebuje pracovat.

Ještě je dobré věnovat pozornost přebírání obsahů nastavení přístupu sekcí (section) od rodičovského segmentu. Bude-li existovat např. prvek číslo účtu v oblasti další údaje, kde oblast má definováno pro sekce s obsahem "personalni: 3; uctarna: 3r, 5", můžeme u prvku s číslem účtu definovat obsah "personalni: 4;". Běžně se přístupové úrovně oddělení a obecné definice úrovní přebírají od rodiče. Uvedeme-li ale u segmentu změnu, je v případě definice sekcí aplikována pouze na jmenované oddělení - tj. přístupová práva účtárny zůstanou nedotčena a při fázi kompletace se sekce prvku číslo účtu doplní takto "personalni: 4; uctarna: 3r, 5". Účtárně tedy stačí pro nahlížení na údaj pouze úroveň 3, zatímco v personálním pro přístup k účtu již potřebujete 4-ku. Dále u přebírání přístupových úrovní od rodiče vždy platí, že potomek může mít jedině zvýšené zabezpečení oproti svému rodiči. Pokud byste tedy u potomka nastavili nížžší úroveň, bude se přístupová úroveň pro určitého uživatele řídit úrovní rodiče. Je-li žádoucí, aby se nastavení oddělení nepřebírala od rodiče a potomek tak dostal vyšší zabezpečení, je možné použít klíčové slovo disable-inherit a to buď jako jediný obsah nebo vyjmenovat zmírněná oddělení a na pro zbytek oddělení (uvedných u rodiče) uplatnit disable-inherit - tj. výjimku na tato oddělení potlačit a zabezpečení pro potomka zvýšit dle secrecy-lev.


Vliv propojení vlastností zdroje

V předchozím odstavci jsme se zmínili o jistém vlivu bezpečnostního nastavení zdrojového dokumentu. Jde o pravidlo použití vyššího zabezpečení v konfliktních případech, které zaručí, že pokud je zdroj nastaven na jistou úroveň zabezpeční pro určitý okruh uživatelů, pak tito uživatelé nemhou tuto bezpečnostní úroveň obejít ani prostřednictvím jiného dokumentu, který zdrojový dokument načítá.

Zvláštní případ nastává u propojení pomocí mechanismu initial. Zde dochází k té skutečnosti, že pokud je zdroj pro určitou úroveň přístupný jen jako readonly, pak můžeme (zdánlivě proti zmíněnému pravidlu) nastavit cíl pro danou úroveň jako editable. Je to proto, že u mechanismu initial úpravou načtených údajů neupravujeme údaje ve zdrojovém dokumentu, ale pouze údaje již načtené, které si cílový dokument ukládá odděleně. Proto nedochází ke konfliktní situaci a pravidlo vyššího zabezpečení není použito.

Jiná situace logicky nastává u propojení foreign, kde by změna hodnot v kolonkách cílového dokumentu měla dopad na obsah dokumentu zdrojového a zde je pravidlo vyššího zabezpečení nekompromisně uplatněno.

Nicméně pro oba zdrojové mechanismy platí že pokud v cílovém dokumentu bezpečnostní úroně neuvedeme, pak se nastavení přístupových práv převezme z dokumentu zdrojového, pokud nastavení rodiče výběrového uzlu není přísnější (pak se opět podle pravidla respektuje požadavek na vyšší zabezpečení a převezme se nastavení rodiče).

Pro oba zdrojové mechanismy rovněž platí, že pokud je zdroj readonly, můžeme cílový výběrovy uzel nastavit na úroveň selectable, která respektuje readonly (nemění hodnoty ve zdroji), ale zároveň v cíli umožňuje vybrat požadovanou instanci zdroje.

Viz. též XDS vlastnosti pro práci s přístupy.

Přístupové úrovněPráce s uživateliAutentizace