A Mézga család Autó tortúra részében hangzik el Paula szájából, a rendőri intézkedés során a klasszikus:

„Ne vitatkozz Gáza! Az csak emeli az árfolyamot! Add oda szépen a jogosulást.”

A rendező valószínűleg nem gondolt arra, hogy évtizedekkel később mekkora szerepe is lesz a „jogosulásnak”.

Itt és most nem a biztonsági belépésekkel kapcsolatos jogosultságokról lesz szó, hanem a felhasználók tevékenységét meghatározó szintekről, arról, hogy mivel, mikor és mit tehetnek meg egy adott rendszeren belül. Kapcsolódunk majd a metaadatokhoz és a biztonsági problémákhoz is, a könnyebb érthetőség miatt egy hétköznapi dokumentumtáron keresztül világítunk rá a problémakörre.

Esetünkben gondoljunk egy átlagos vállalkozásra, webes kereskedelemmel, korszerű informatikai rendszerrel, integrált dokumentumkezelő megoldással. Ez alap lehetne napjainkban, de az utolsó láncszem, a dokumentumkezelés sajnos még sok helyen hiányzik, de mi most mégis tekintsük egyben az egészet. Az integrált dokumentumkezelő egyben dokumentumtár is, kiszolgálja a netes érdeklődőket, az ügyfeleket, a vállalkozás munkatársait és a menedzsmentet egyaránt. Erre szükség is van, mivel a felsorolt rétegek valójában egymásnak szolgáltatnak adatokat vagy biztosítanak információkat. Az egész mögé tegyünk egy szabványos SQL motort. (Ez a következő részben még fontos lesz, mint kockázat). Természetesen a biztonságért is a napi technológiák – jelszavak, router, tűzfal stb. – felelnek. Most ennek sincs jelentősége, tételezzük fel, hogy minden szereplő rendelkezik a leírtakhoz szükséges hálózati és felhasználói jogosítványokkal.

Kinek a pap, kinek a papné…

A jellemző dokumentumkezelési modellt, az alapjogosultságokat az alábbi ábra mutatja:

Szándékosan csak négy fő felhasználói csoportot és ugyanennyi funkciót ábrázoltunk - ez elég lesz most. Az érdeklődők szabadon férnek hozzá a reklámjainkhoz, ismertetőinkhöz, a regisztrált ügyfelek, megrendelők már a szolgáltatáshoz járó kínálatot is „látják”, a munkatársak hozzáférnek a munkájukhoz szükséges összes adathoz, információhoz, míg a menedzsment mindent lát, és az általuk rögzítettek viszont „nem léteznek” a többiek számára.

Egyszerű és átlátható.

Lenne…

Ha a munkatársak csoport homogén volna, és számukra nem lenne további kerítéskészlet egymás funkciói között! De van és ez nem hanyagolható el! Hiszen a jogi osztály részéhez nem szabad, hogy hozzáférjenek a fejlesztők, a pénzügyhöz az ügyfelesek és így tovább. Aztán mi van a banki utalásokkal? Egy pici vállalkozásnál ezt megoldja maga a vezető, a tulajdonos, de más esetben ez már a pénzügy/könyvelés csoport feladata. De nem mindenkié, csak azoké, akiknek ez engedélyezett. Miközben a „bank” már a védett zónában van, így mégis be kell engedni oda egyes „kívülállókat” is.

Ez alapvetően bizalmi kérdés, de a mind összetettebb jogosultsági szabályokra megfelelő példát szolgáltat. Csak halkan jegyezzük meg a rendszergazda felelősségét, aki mindenhez hozzáfér… De erről is majd a következő írásunkban elmélkedünk.

Pontosítsuk az ábránkat:

Mivel most csak a dokumentumkezelésről van szó, folytassuk azzal. Az ábrán látható „mátrix” beállítása önmagában is hatalmas tervezési feladat, egyedi és csoportos jogosultságok tervezésére van szükség, és ez önmagában csak a dokumentumkezelőhöz, az abban tároltakhoz történő hozzáférés szabályozza. Nem árt tehát megoldani annak tartalmának a szabályozását is, összhangban a rendszerszintű jogosultságokkal. Ahány szint, ahány felhasználói csoport, annyiféle tartalom rögzíthető és annyiféle eredmény nyerhető vissza!

Az nem jó, ha mindenki ugyanazt látja és használja. Nemcsak az adatbiztonság miatt, hanem mert csak egy kezelhetetlen kotyvasz lesz az egészből. Régen még azt tanít tanították, hogy minden felhasználó elé csak a számára szükséges információ kerüljön és az ergonómia – kezelőfelület - is ennek megfelelő legyen.

Mivel nem jó a sok különálló adatállomány, egy közös kell és a hozzáférést és a kezelést kell eszerint létrehozni, megtervezni. Ennek egyik eszköze a korábbi írásunkban már említett metaadat. A metaadatokkal határozzuk meg többek között a rögzített tételek jellemzőit, kinek szólnak azok és azt is, hogy kik férhet hozzájuk.

Aszimmetria

A metaadatok tervezése – mint másik posztunkban már írtuk – összetett feladat. A bemutatott esetben kötött metaadat struktúrát feltételezünk, tehát minden felhasználói csoportnak más és más metaadat-halmazt kell meghatározni, de ezek egységesen részesei az adatbázisnak, azaz a felhasználói csoportok kezelőfelületeit is ennek megfelelően kell kialakítani. Hogy ne legyen nagyon egyszerű a dolgunk, nem csak a bevitelnél van szükség más és más felületekre, hanem a lekérdezéseknél, a jelentéseknél is!

Ez nagyon pontos és előrelátó tervezést igényel, későbbi módosítások nem csak az adatbázist, hanem az összes érintett képernyőt, programrészt is érinthet.

A gondjainkat növeli, hogy egy ilyen általánosságban is használt megoldás, programrendszer jellemzően aszimmetrikus kezelést, működést jelent, azaz

• a bevitelnél sok egyedi részinformáció kerül az adatbázisba
• a tárolás egységes
• a lekérdezés, felhasználás pedig ismét többféle részhalmazt igényel, ráadásul nem is a bevitellel szinkronban (más a rögzítési tartalom és más a keresési)

Hétköznapi nyelvre lefordítva a fentieket mindez azt jelenti, hogy az érdeklődők, az ügyfelek, a munkatársak sok és rájuk vonatkozó, számukra fontos adatot rögzítenek és látnak el rájuk jellemző metaadatokkal, ezek belekerülnek a nagy „üstbe”, majd ebből a résztvevők a saját „merőkanalaikkal” keresik a nekik szükséges elemeket, tételeket.

Ezt pedig szabályozni kell!

Egy alap dokumentumtárnál, például egy könyvtárban egyszerű a feladat, mivel adott a rögzítési művelet és a tartalmat a regisztráció és az esteleges fizetett szolgáltatások alapján találjuk meg. Egy vállalkozásnál alkalmazott ügyviteli, számviteli rendszernél azonban mind a rögzítés, mind a felhasználás egy komplex mátrix, rengeteg átfedéssel fűszerezve.

Persze nem a külső érdeklődőkkel vagy a már fizető partnerekkel, ügyfelekkel van a gond, az ő kiszolgálásuk egy szigorú szabályrendszer alapján történik, gond a belső használat! Hogy egy területen belül is számtalan felhasználási jog van. A pénzügynél van, aki csak rögzíthet, van, aki módosíthat, kiegészíthet, mások igazolhatnak számlákat vagy teljesítéseket, megint mások lekérdezésekkel elemzéseket, vezetői információkat hozhatnak létre. Ugyanakkor másik területen dolgozóknak is lehet beavatkozásra joguk, a már említett teljesítésigazolásoknál a végrehajtóknak kell az elvégzetteket jelezniük, a kereskedőknek is rá kell látniuk a raktárkészletre és így tovább.

Korszerű dokumentumkezelőnek biztosítania kell, hogy adatbevitel, a tárolás és a felhasználás bármilyen kombinációban, de szabályozottan megtörténhessen!

Lássuk mindezt elméletben is.

Az ábrákon bemutatott modellnél a bemeneti csoportokat nevezzük el A (érdeklődők), B (partnerek), C (munkatársak) és D (vezetők) részhalmaznak, ebből azonnal az is látszik, hogy az A és B részhalmaz kötött, előre szabályozható egységes rendszert alkotnak, a D részhalmaznak pedig adjuk meg a jogot arra, hogy a saját „kertjükben” bármit megtehessenek

A kritikus rész az alkalmazotti terület.

Az alkalmazottak egy munkafolyamaton belül is eltérő jogosultsággal rendelkeznek, akár a bevitel, akár a beavatkozás és akár az eredményekhez történő hozzáférések esetében. Ezért a C részhalmazt is fel kell bontani további részhalmazokká, így az egyébként ideális metaadatos kezelést még egy összetett jogosultsági rendszerrel is ki kell egészíteni, ez pedig a programozók, rendszertervezők vállára pakol súlyos terheket.

A bevitelt és az adatmódosítást a felhasználói jogokkal vezérelt dinamikus képernyőkkel - ahol az aktuális tartalom és tevékenységi lehetőségek a belépők jogosultságaihoz alkalmazkodva jelennek meg-  beállítható, a lekérdezések területén azonban már szinte filozófiai problémákkal szembesülhetünk:

• a munkatárs csak a számára engedélyezett tartalmakat lássa?
• a munkatárs minden láthasson?
• az eredmény egy kombinált lista legyen, ahol a jogosultságnak megfelelő tételek elérhetők, a tiltottak meg csak jelezve legyenek?

Természetesen a keresésnél a mataadatoknak azon tartalma is részt vesz a folyamatban, melyek nem tartoznak az adott munkatárs hatáskörébe, de csak a full text keresési résznél, hiszen az ő képernyőjén a nem engedélyezettek nem is jelenek meg.

Az első esetben az eredmény hiányos lesz, egy adóhatósági adatszolgáltatásnál nem megengedhető, hogy például bizonyos számlák ne kerüljenek elő! A második esetben meg értelmetlenné válik az egész biztosági vonal.

A harmadikat tekithetjük a megfelelő megoldásnak, azaz jelzéssel ellátott tartalmak esetén a munkatárs jelezheti azokat annak, aki rendelkezik megfelelő jogosultsággal. Erre való a dokumentumkezelő rendszer… Viszont megint az a fránya biztonsági kérdés… Szinte felhívjuk a figyelmet a bizalmas adatokra.

A „végső” megoldás a régi programozási korszakban már ismert volt, csak alkalmazni kell azt napjainkban is: A felhasználók egy jogosultsági táblába kerülnek, ebben írjuk le az egyedi jogokat (írás, olvasás, módosítás, tiltás) értelemszerűen az egész rendszerre, képernyőnként, funkciónként és a szerverek felhasználói jogosultságainál ismert módszerrel állítjuk be - rendszergazdai szinten - a „zászlókat”. Egy új munkatárs alapból semmihez nem fér hozzá, majd feloldjuk a tiltásokat a megfelelő területeken. Erre találták ki többek között a felhasználói csoportokat…

A leírtak tehát a fejlesztők számára az alapokat jelentik, ma azonban sokszor tapasztaljuk a legyintést, a problémák gyors átlépést, ami később a tesztfázisnál is gyakran érvényesül, majd az éles üzem során, már a megrendelő tapasztalatai alapján merülnek fel további gondok, akadályok, rések. Ezek kijavítása egy nagy rendszernél, főleg ha hibás szemlélettel lett az létrehozva, hatalmas idő és erőforrás veszteséget jelent.

A következő részben egy súlyos biztonsági problémát fogunk boncolgatni.