Jelenleg egy szoftvergyártó cégnél dolgozom, különösen a hozzáférés-irányítási megoldások területén. Korábbi tapasztalataim egy ügyféloldali nagy pénzügyi szervezethez kötődnek. Akkoriban az információbiztonsági osztályunk hozzáférés-ellenőrzési csoportja nem büszkélkedhetett nagy IdM kompetenciákkal. Sok mindent a folyamat során tanultunk meg, és számos hibát elkövettek, hogy működő felhasználói jogkezelési mechanizmust alakítsunk ki a vállalatban.
Összekapcsolva az ügyféloldalon szerzett tapasztalataimat a gyártói tudással és kompetenciákkal, szeretném megosztani veletek a lényegében lépésről lépésre szóló útmutatómat: hogyan lehet egy nagyvállalatban szerep-alapú hozzáférés-irányítási modellt létrehozni, és hogy ez milyen előnyöket hoz a végén. Az útmutatóm két részből áll: az első az előkészületek készítése, a második pedig a tényleges építés. Önök előtt áll az előkészítő első rész.
Figyelem. A szerep-alapú modell felépítése sajnos nem eredmény, hanem egy folyamat. Pontosabban a cégben a hozzáférés-irányítási ökoszisztéma létrehozásának egy része. Tehát készüljetek fel a hosszú távú játékra.
Először nézzük meg, hogy mi is a szerep-alapú hozzáférés-irányítás? Tegyük fel, hogy van egy nagy bankja, amelynek több tízezer, vagy akár százezer alkalmazottja (alany) van, mindegyikük számos hozzáférési joggal rendelkezik a banki információs rendszerek (objektumok) százain. Most pedig szorozzuk meg az objektumok számát az alanyok számával – pontosan ennyi kapcsolatot kell először felépítenünk, majd ellenőriznünk. Lehetséges ezt manuálisan megtenni? Természetesen nem – ezért jöttek létre a szerepek.
A szerep egy olyan jogosultságkészlet, amely szükséges egy felhasználó vagy felhasználói csoport számára bizonyos munkafeladatok elvégzéséhez. Minden alkalmazott rendelkezhet egy vagy több szereppel, és minden szerep tartalmazhat egy vagy több jogosultságot, amelyet a felhasználó a szerep keretein belül gyakorolhat. A szerepek kapcsolódhatnak bizonyos pozíciókhoz, részlegekhez vagy a munkavállalók funkcionális feladataihoz.
A szerepek általában a dolgozók különböző jogosítványaiból jönnek létre minden információs rendszerben. Ezután a minden rendszer szerepeiből globális üzleti szerepek alakulnak. Például az üzleti szerep 'hitelmenedzser' számos különálló szerepet foglal magában az ügyfélszolgálat többségében használt információs rendszerekben. Mondjuk, mint a fő automatizált banki rendszer, a pénztári modul, a elektronikus dokumentumkezelő rendszer, a szolgáltatásmenedzser és egyéb. Az üzleti szerepeket általában a szervezeti felépítéshez kötik - egyszerűbben fogalmazva, a cég részlegeihez és az azokban foglalt pozíciókhoz. Így alakul ki a globális szerepmátrix (példa látható az alábbi táblázatban).
Fontos megjegyezni, hogy lehetetlen 100%-os szerepmintát felépíteni, amely minden szükséges jogosítvánnyal rendelkezik az alkalmazottak minden pozíciójában a kereskedelmi struktúrában. Ez nem is szükséges. Ugyanis a szerepminta nem lehet statikus, mivel az állandóan változó környezettől függ. És a cég üzleti tevékenységének változásától, amely ennek megfelelően befolyásolja a szervezeti struktúrát és a funkciókat. Továbbá a forráshiány és a munkaköri leírások be nem tartása, a biztonság rovására történő nyereségszerzés, valamint sok más tényező is közrejátszik. Ezért olyan szerepmintát kell kialakítani, amely akár a felhasználók alapvető jogainak 80%-át is fedezni tudja, amikor a pozíciójukra kinevezik őket. A fennmaradó 20%-ot pedig, ha szükséges, később különféle kérelmek alapján kérhetik.
Természetesen felmerülhet a kérdés: "Nem létezik egyáltalán 100%-os szerepminta?" De miért ne létezne, ilyen előfordulhat például a nonprofit struktúrákban, amelyek nem szenvednek gyakori változásoktól - például egy kutatóintézetben. Vagy a magas fokú védettséggel rendelkező védelmi ipari szervezetekben, ahol a biztonság elsődleges szempont. Persze létezik ilyen kereskedelmi struktúrákban is, de csak egy adott részlegen belül, amelynek működése viszonylag statikus és előrejelezhető folyamat.
A szerepelvégzés fő előnye a jogosítványok egyszerűsítése, mivel a szerepek száma jelentősen kevesebb, mint az információs rendszer felhasználóinak száma. Ez minden iparágra érvényes.
Vegyük egy kiskereskedelmi cég példáját: több ezer eladó dolgozik benne, de mindannyian ugyanazokkal a jogosultságokkal rendelkeznek a N rendszerben, és számukra csak egyetlen szerepkört hoznak létre. Ha új eladó érkezik a céghez, neki automatikusan kijelölésre kerül a megfelelő szerepkör a rendszerben, amiben már benne vannak az összes szükséges jogosultság. Egy kattintással meg lehet változtatni a jogosultságokat akár ezer eladó esetében is, például új jelentéskészítési lehetőséget hozzáadni. Nem kell ezer műveletet végezni, hogy az új jogosultságot minden egyes felhasználói fiókhoz hozzárendelje – elegendő ezt a lehetőséget a szerepkörbe beilleszteni, és máris mindegyik eladó hozzáférése egyidőben frissül.
A szerepkör-alapú irányítás egy másik előnye a nem összeegyeztethető jogosultságok kiadásának kizárása. Vagyis az a munkavállaló, aki egy bizonyos szerepkörrel rendelkezik a rendszerben, nem lehet egyszerre más szerepkörben, amelynek jogosultságai nem kompatibilisek az első szerepkörével. Egy világos példa – a pénzügyi műveletek bevitelének és ellenőrzésének funkcióinak összevonásának tilalma.
Mindenki, akit érdekel, hogyan alakult meg az szerepkör-alapú hozzáférés-irányítás,
belevághat egy történelmi áttekintésbe
Ha visszatekintünk a múltba, az IT-közösség először az 1970-es években kezdett el gondolkodni a hozzáférés-irányítási módszereken. Bár a programok akkoriban elég egyszerűek voltak, de akárcsak ma, mindenki kényelmesen kívánta kezelni a hozzáféréseket. A felhasználói jogosultságok megadása, módosítása és ellenőrzése – csak hogy könnyebb legyen megérteni, kinek milyen hozzáférése van. De akkoriban nem léteztek általános szabványok, az első hozzáférés-irányítási rendszerek fejlesztése zajlott, és minden cég a saját elképzelésein és szabályain alapult.
Ma már sok különböző hozzáférés-irányítási modell ismert, de ezek nem azonnal jelentek meg. Azokra a modellekre koncentrálunk, amelyek érzékeny hozzájárulást adtak ennek a területnek a fejlődéséhez.
Az első és valószínűleg legegyszerűbb modell – Diszkrecionális (választó) hozzáférés-irányítás (DAC – Diszkretionális hozzáférés-vezérlés). Ez a modell a jogok közös használatát feltételezi a hozzáférési folyamat minden résztvevője között. Minden felhasználó hozzáférést kap konkrét objektumokhoz vagy műveletekhez. Lényegében itt a jogalanyok száma megegyezik az objektumok számával. E modellt túl rugalmasnak és nehezen karbantarthatónak nyilvánították: a hozzáférési listák idővel hatalmasak és nehezen ellenőrizhetők lesznek.
A második modell a Kényszerített hozzáférés-vezérlés (MAC — Mandatory access control). E modell szerint minden felhasználó hozzáférést kap egy objektumhoz az alapján, hogy milyen engedéllyel rendelkezik az adatok adott szintű titkosságára. Ennek megfelelően az objektumokat a titkosság szintje szerint kell kategorizálni. Ahelyett, hogy az első, rugalmas modellhez hasonlítana, ez a modell túl szigorú és korlátozó volt. Alkalmazása nem indokolt, amikor a vállalat számára számos különböző információs erőforrás áll rendelkezésre: a különböző erőforrásokhoz való hozzáférés korlátozásához számos kategóriát kell bevezetni, amelyek nem ütköznek egymással.
A két módszer nyilvánvaló tökéletlensége miatt az IT közösség folytatta a modellek fejlesztését, amelyek rugalmasabbak és mégis viszonylag univerzálisak a különböző típusú szervezeti hozzáférés-ellenőrzési politikák támogatására. Így jelent meg a harmadik szerepkönyvbeli hozzáférés-vezérlés modellen alapuló módszer! Ez a megközelítés a legígéretesebbnek bizonyult, mivel nemcsak a felhasználó személyazonosságának azonosítását, hanem a munkaköreit is megköveteli a rendszerekben.
Az első világosan leírt szerepkönyvbeli modell struktúráját az amerikai tudósok, David Ferraiolo és Richard Kuhn, a Szövetségi Szabványügyi és Technológiai Intézetből javasolták 1992-ben. Ekkor jelent meg először a kifejezés RBAC (Szereken alapuló hozzáférés-vezérlés). E kutatások és a fő összetevők, valamint azok kölcsönhatásának leírása képezte a ma is érvényben lévő INCITS 359-2012 szabvány alapját, amelyet az Informatikai Szabványok Nemzetközi Bizottsága (INCITS) hagyott jóvá.
A szabvány a szerepet úgy határozza meg, mint "a szervezeten belüli munkaköri funkciót, amelynek bizonyos kapcsolódó szemantikája van a felhasználóra ruházott hatáskörökkel és felelősségekkel kapcsolatban, aki a szerepet betölti". A dokumentum meghatározza az RBAC (Role-Based Access Control) alapvető elemeit – felhasználók, munkamenetek, szerepek, engedélyek, műveletek és objektumok, valamint a közöttük lévő kapcsolatok és viszonyok.
A szabvány minimalizált struktúrát ad a szerepkör modelljének felépítéséhez – a jogosultságok szerepekbe való összevonásához, majd pedig ezeknek a szerepeknek a felhasználókhoz való kiosztásához. Megjelöli a szerepek objektumokból és műveletekből való összeállításának mechanizmusait, leírja a szerepek hierarchiáját és a hatáskörök öröklését. Üzleti környezetben minden cégnél vannak olyan szerepek, amelyek összegyűjtik az alapvető hatásköröket, amelyekre a cég összes alkalmazottjának szüksége van. Ilyen lehet például az e-mailhez, az elektronikus dokumentumkezelő rendszerhez (EDMS) vagy a vállalati portálhoz való hozzáférés. Ezeket a hatásköröket egy közös szerepbe, például az "alkalmazott" szerepbe foglalhatjuk, és nem szükséges minden magasabb szintű szerepnél újra és újra felsorolni az összes alapvető jogosultságot. Elég, ha a "munkavállaló" szerep öröklési jelét egyszerűen megadjuk.
Később a szabvány új hozzáférési attribútumokkal bővült, összhangban a folyamatosan változó környezettel. Új statikus és dinamikus korlátozások bevezetésére is lehetőség nyílt. A statikusok azt jelentik, hogy a szerepek nem kombinálhatók (ez az a bemeneti és műveletellenőrzési mechanizmus, amelyet fent említettünk). A dinamikus korlátozások változó paraméterek alapján határozhatók meg, például idő (munkai/nem munkai órák vagy napok), hely (iroda/otthon) stb.
Külön említést érdemel az attribútum alapú hozzáférés-vezérlés (ABAC — Attribute-based Access Control). Ez a megközelítés az attribútumok közös használatára vonatkozó szabályok révén ad hozzáférést. Ez a modell használható önállóan, de gyakran aktívan kiegészíti a klasszikus szerepalapú (RBAC) modellt is: egy adott szerephez felhasználói, erőforrás- és eszközattribútumokat, valamint idő- vagy helyattribútumokat lehet hozzáadni. Ez lehetővé teszi a szerepek számának csökkentését, további korlátozások bevezetését, és a hozzáférés minimálisan elegendővé tételét, ezzel növelve a biztonságot.
Például a könyvelő számára engedélyezhetjük a hozzáférést a számlákhoz, ha egy adott régióban dolgozik. Ekkor a szakember helyzete összehasonlításra kerül egy meghatározott referenciaértékkel. Vagy engedélyezhetjük a hozzáférést a számlákhoz, csak akkor, ha a felhasználó egy engedélyezett eszközről jelentkezik be. Jó kiegészítője a szerepmódellenek, de önállóan ritkán használják, mivel sok szabályt és engedélyezési vagy korlátozási táblázatot kell létrehozni.
Hozzak egy példát az ABAC alkalmazására a „múltbéli” életemből. A bankunkban több fiók működött. Az ügyfélközpontok alkalmazottai ezekben a fiókokban teljesen azonos műveleteket hajtottak végre, de a fő rendszerben csak saját régiójuk számláival dolgozhattak. Először külön szerepeket kezdtünk létrehozni minden régióra – és a számos ismétlődő funkcióval rendelkező szerepből, amely különböző számlákhoz való hozzáféréssel rendelkezett, nagyon sok lett! Ezután a felhasználó tartózkodási helyének attribútumát felhasználva és ezt egy konkrét számtartományhoz kapcsolva a ellenőrzéshez, jelentősen csökkentettük a rendszer szerepeinek számát. Végül csak egy fiók szerepei maradtak, amelyek a bank összes többi területi egységében megfelelő pozíciókra másoltak.
Most pedig beszéljünk a szükséges előkészítő lépésekről, amelyek nélkül egyszerűen lehetetlen működőképes szerepmódelt kialakítani.
1. lépés. Létrehozunk egy funkcionális modellt
Érdemes a funkcionális modell létrehozásával kezdeni – egy magas szintű dokumentummal, amely részletesen leírja minden osztály és munkakör funkcióját. Általában az információ különböző dokumentumokból kerül bele: munkaköri leírásokból és egyes osztályok, mint például részlegek, igazgatóságok, departemenst érintő szabályokból. A funkcionális modellt minden érintett osztállyal (üzlet, belső ellenőrzés, biztonság) egyeztetni kell és a vállalat vezetőségének jóváhagyása szükséges. Miért van szükség erre a dokumentumra? Annak érdekében, hogy a szerepmódell hivatkozhasson rá. Például ha a már meglévő jogosultságok alapján szeretné felépíteni a szerepmódelt – amelyeket a rendszerből exportáltak és „egységesítették”. Akkor a kapott szerepek üzleti tulajdonosával való egyeztetéskor hivatkozhat egy adott pontra a funkcionális modellben, amely alapján a szerephez jogosultságot adnak.
2. lépés. Auditáljuk az IT rendszereket és prioritási tervet készítünk
A második lépés során el kell végezni az IT rendszerek auditját, hogy megértsük, hogyan van megszervezve a hozzáférés ezekhez. Például az én pénzügyi cégemben több száz informatikai rendszer működött. Minden rendszerben volt némi kezdetleges szerepkezelés, a legtöbbben voltak valamilyen szerepek, de főleg papíralapúak vagy a rendszer nyilvántartásában szerepeltek – ezek régóta elavultak, és a hozzáférést a felhasználók tényleges kérései alapján osztották ki. Természetesen lehetetlen egyszerre több száz rendszerben szerepmódelt kialakítani, valahonnan el kell kezdeni. Mélyreható elemzést végeztünk a hozzáférés kezelésének folyamatáról, hogy meghatározzuk annak érettségi szintjét. Az elemzés során kidolgoztuk az informatikai rendszerek prioritási kritériumait – kritikus fontosság, felkészültség, üzemen kívül helyezési tervek stb. Ezek segítségével felállítottuk a szerepmodellek kidolgozásának/számbavételének sorrendjét ezen rendszerek számára. Majd belefoglalva a szerepmodelleket az Identity Management megoldással való integrációs tervbe, hogy automatizáljuk a hozzáférés kezelését.
Tehát hogyan határozzuk meg a rendszer kritikus fontosságát? Válaszoljon a következő kérdésekre:
- A rendszer kapcsolódik-e a vállalat alaptevékenységének végrehajtásához?
- Hatással lesz-e a rendszer működésének megszakadása a vállalat eszközeinek integritására?
- Mi a maximálisan megengedett leállási idő, amelynek elérése után a tevékenység helyreállítása lehetetlen a megszakítást követően?
- Vezethet-e a rendszer információs integritásának megsértése visszafordíthatatlan következményekhez, mind pénzügyi, mind hírnév szempontjából?
- A csalásra gyakorolt kritikus hatás. Az a funkcionalitás, amelynek elégtelen ellenőrzése esetén belső/külső csalásokat lehet elkövetni;
- Mik a jogszabályi követelmények, valamint a belső szabályok és eljárások ezen rendszerekre? Lesznek-e bírságok a hatóságok részéről a megfelelés hiányában?
A pénzügyi cégünknél így végeztük az auditot. A vezetőség kidolgozott egy Access Right Review audit eljárást, hogy tisztába jöjjön a meglévő felhasználókkal és jogaikkal, először azokban az információs rendszerekben, amelyek a legfontosabbak lettek kijelölve. A folyamat tulajdonosává a biztonsági részleg lett kijelölve. De a hozzáférési jogok teljes körű áttekintéséhez a folyamatba be kellett vonni az IT és az üzletek részlegeit is. Itt kezdődtek a viták, a félreértések, sőt, néha a szabotázs: senki sem akar eltávolodni a jelenlegi feladataitól, és belemerülni olyan tevékenységekbe, amelyek első pillantásra érthetetlenek.
Figyelem. A nagyvállalatok, amelyek fejlett IT-folyamatokkal rendelkeznek, biztosan ismerik az IT audit eljárását – az IT general controls (ITGC), amely lehetővé teszi az IT folyamatok hiányosságainak feltárását és a kontroll bevezetését, hogy a folyamatokat a legjobb gyakorlatok (ITIL, COBIT, IT Governance stb.) szerint javítsák. Ez az audit lehetővé teszi az IT és az üzlet számára, hogy jobban megértsék egymást és közös fejlődési stratégiát alakítsanak ki, elemezzék a kockázatokat, optimalizálják a költségeket, és hatékonyabb megközelítéseket dolgozzanak ki a munkában.
Az audit egyik iránya az informatikai rendszerek logikai és fizikai hozzáférésének paramétereinek meghatározása. Az így kapott adatokat alapul vettük a szerepmotor modelljének kidolgozásához. Az audit eredményeként egy IT rendszerregisztert hoztunk létre, amely tartalmazta a technikai paramétereket és a leírásokat. Ezen kívül minden rendszerhez meghatároztuk a business irányból származó tulajdonost, aki felelt a rendszer által támogató üzleti folyamatokért. Elkezdett egy IT szolgáltató menedzsert is, aki a vállalkozás technikai igényeinek megvalósításáért felelt egy adott informatikai rendszerben. Rögzítettük a cég számára legkritikusabb rendszereket és azok technikai paramétereit, a forgalombahozatal és kivonás határidejét stb. Ezek a paraméterek nagyban segítették a szerepmotor modelljének kidolgozását.
3. lépés: Kidolgozzuk a metodológiát
Bármely tevékenység sikerének kulcsa a jól megválasztott módszer. Ezért a szerepmotor modelljének kidolgozása és az audit elvégzése érdekében módszert kínálunk, amely leírja az osztályok közötti interakciót, rögzíti a felelősséget a cég szabályzatában stb.
Először is meg kell vizsgálni az összes rendelkezésre álló dokumentumot, amely rögzíti a hozzáférési és jogosultsági rendet. Jól lenne, ha a folyamatokat több szinten dokumentálnánk:
- általános vállalati követelmények;
- az adatvédelmi területekre vonatkozó követelmények (a szervezet tevékenységeitől függően);
- a technológiai folyamatokra vonatkozó követelmények (utasítások, hozzáférési mátrixok, metodikai útmutatók, konfigurációs követelmények).
A pénzügyi cégünkben sok elavult dokumentumot találtunk - ezeket az új folyamatokkal összhangban kellett hozni.
A vezetőség utasítása alapján munkacsoportot hoztunk létre, amelybe biztonsági, informatikai, üzleti és belső ellenőrzési területek képviselőit választottuk be. Az utasításban megfogalmaztuk a csoport létrehozásának céljait, tevékenységi irányát, működési időtartamát és a felelős személyeket minden oldalról. Ezen kívül kidolgoztuk az auditálás módszertanát és a szerepkör-modellezés rendjét: ezeket minden felelős területi képviselő jóváhagyta, és a vállalat vezetése jóváhagyta.
A munkák elvégzésének rendjét, határidőit, felelősségét stb. leíró dokumentumok a biztosítékai annak, hogy a vágyott cél felé vezető úton, amely kezdetben nem mindenki számára egyértelmű, senkiben ne merüljön fel olyan kérdés, hogy "miért csináljuk ezt, nekünk miért van erre szükségünk stb.", és ne legyen lehetőség arra, hogy valaki "leugorjon" vagy lelassítsa a folyamatot.
4. lépés. Rögzítjük a meglévő hozzáférés-kezelési modell paramétereit.
Összeállítjuk az úgynevezett "rendszer útlevélét" a hozzáférés kezelésére vonatkozóan. Valójában ez egy kérdőív az adott információs rendszerhez, amelyben minden hozzáférésvezérlési algoritmus rögzítve van. Azok a vállalatok, amelyek már bevezették az IdM osztályú megoldásokat, bizonyára ismerik ezt a kérdőívet, mivel éppen ezzel kezdődik a rendszerek kutatása.
A rendszerre és a tulajdonosokra vonatkozó egyes paraméterek az IT nyilvántartásból (lásd 2. lépés, audit) kerültek át a kérdőívbe, de újakkal is kiegészültek:
- hogyan történik a felhasználói fiókok kezelése (közvetlenül az adatbázisban vagy programozási interfészeken keresztül);
- hogyan lépnek be a felhasználók a rendszerbe (különálló fiókkal, vagy AD, LDAP vagy más fiók használatával);
- milyen hozzáférési szintek állnak rendelkezésre a rendszerhez (alkalmazási szint, rendszer szint, hálózati fájlok erőforrásainak használata);
- leírás és paraméterek szerverek, amelyeken a rendszer működik;
- milyen fiók-kezelési műveletek támogatottak (blokkolás, átnevezés stb.);
- milyen algoritmusok vagy szabályok alapján képződik a rendszer felhasználói azonosítója;
- milyen attribútum alapján állítható fel kapcsolat a munkavállaló nyilvántartásával a bérnyilvántartás rendszerében (név, azonosító szám vagy más);
- minden lehetséges fiók attribútum és a kitöltésük szabályai;
- milyen hozzáférési jogok vannak a rendszerben (szerepek, csoportok, atomikus jogok stb., vannak-e beágyazott vagy hierarchikus jogok);
- hozzáférési jogok elosztási mechanizmusai (pozíciók, osztályok, funkciók stb. alapján);
- vannak-e a rendszerben a jogok elkülönítésére vonatkozó szabályok (SOD – Segregation of Duties), és hogyan működnek;
- hogyan kezelik a rendszerben a hiányzási, áthelyezési, elbocsátási, illetve a munkavállalók adataival kapcsolatos frissítési eseményeket stb.
Folytathatjuk ezt a listát különféle paraméterek és egyéb objektumok részletezésével, amelyek részt vesznek a hozzáférés kezelési folyamatában.
5. lépés. Üzletorientált jogi leírás létrehozása
Még egy dokumentum, amelyre szükségünk lesz a szerepkör-modell kiépítésénél, az a jogosultságok (jogok) teljes körű nyilvántartása, amely tartalmazza az informatikai rendszerben a felhasználóknak adható jogok részletes üzleti funkciót ismertető leírását is. Gyakran a rendszerben a jogosultságokat bizonyos betű- és számkombinációkkal titkosítják, és az üzleti munkatársak nem tudják megfejteni, hogy ezek a karakterek mit jelentenek. Ezután az IT-hoz fordulnak, ahol… ott sem tudnak válaszolni például a ritkán használt jogokkal kapcsolatosan. Ilyenkor további tesztelést kell végezni.
Jó, ha már van üzleti leírás, vagy akár ezeknek a jogoknak a csoportokba és szerepekbe történő egyesítése. Néhány alkalmazásnál a legjobb gyakorlat, ha ilyen nyilvántartást még a fejlesztés során létrehoznak. De ez ritkán fordul elő, ezért ismét az IT-osztályhoz fordulunk, hogy összegyűjtsük az összes lehetséges jogot és azokat leírjuk. Végül a nyilvántartásunk a következőket fogja tartalmazni:
- a jogosultság megnevezése, beleértve azt az objektumot, amelyre a hozzáférési jog vonatkozik;
- a művelet, amelyet az objektummal végezni engedélyezett (megtekintés, módosítás stb., területi alapú vagy ügyféllé rendre vonatkozó korlátozás lehetősége);
- a jogosultság kódja (a rendszer azon funkciójának/kérésének kódja és neve, amelyet a jogosultság felhasználásával végre lehet hajtani);
- a jogosultság leírása (a műveletek részletes leírása az IS-ben a jogosultság alkalmazásakor és a folyamatra gyakorolt hatásai;
- a jogosultság státusza: "Aktív" (ha a jogosultságot legalább egy felhasználónak adták) vagy "Inaktív" (ha a jogosultság nem használatos).
6. lépés A felhasználók és jogok adatait exportáljuk a rendszerektől, és összevetjük a személyzeti forrással
A végső előkészítési szakaszban ki kell nyerni az adatokat az információs rendszerekből minden felhasználóról és a jelenlegi jogosultságaikról. Két forgatókönyv lehetséges. Az első: a biztonsági részlegnek közvetlen hozzáférése van a rendszerhez, és van megfelelő eszköze a megfelelő jelentések kinyerésére, ami ritkán fordul elő, de nagyon kényelmes. A második: kérést küldünk az IT-nek, hogy a szükséges formátumban készítsenek jelentéseket. A tapasztalatok azt mutatják, hogy az IT-vel való megállapodás nem mindig sikerül az első próbálkozásra, többször is próbálkozni kell, míg a szükséges információt a kívánt formátumban megkapjuk.
Milyen adatokat kell nyerni:
- A fiók neve
- A foglalkoztatott teljes neve, akire a fiók vonatkozik
- Státusz (aktív vagy letiltott)
- A fiók létrehozásának dátuma
- Az utolsó használat dátuma
- A rendelkezésre álló jogosultságok/csoportok/role-k listája
Tehát megkaptuk a rendszerből a kinyert adatokat minden felhasználóról és a számukra biztosított összes jogosultságról. Azonnal félretettük az összes letiltott fiókot, mivel a szerepkörmodell kiépítése csak az aktív felhasználókra fog vonatkozni.
Ezután, ha a cégnél nincsenek automatizált eszközök a volt dolgozók hozzáférésének letiltására (ez gyakori), vagy ha foszlányos az automatizálás, amely nem mindig működik megfelelően, ki kell azonosítani az összes „halott lelket”. Az olyan fiókokról van szó, amelyek már elbocsátott dolgozókhoz tartoznak, és valamilyen okból nem letiltották a jogosultságaikat – ezeket le kell tiltani. Ehhez a kinyert adatokat össze kell hasonlítani a személyzeti forrással. A személyzeti kinyerést is előzetesen be kell szerezni a személyzeti bázist kezelő részlegtől.
Külön kell tárolni azokat a fiókokat, amelyeknek nem találták meg a tulajdonosait a munkaügyi adatbázisban, vagyis a senki által nem használtakat. Ehhez a listához szükségünk lesz az utolsó használati dátumra: ha az viszonylag friss, akkor mindenképpen keresnünk kell a tulajdonosokat. Ide tartozhatnak külső alvállalkozók fiókjai vagy olyan munkás fiókok, amelyek senkihez sem kötődnek, de valamilyen folyamatokhoz kapcsolódnak. A fiókok tulajdonjogának tisztázásához leveleket küldhetünk az összes részlegnek, kérve az érintetteket, hogy jelentkezzenek. Amikor a tulajdonosokat megtaláltuk, az adatokat rögzítjük a rendszerben: így minden aktív fiók azonosítva van, a többit pedig blokkoljuk.
Amint a kiadásaink megtisztultak a felesleges bejegyzésektől, és csak az aktív fiókok maradtak, elkezdhetjük a szerepmintázat felépítését a konkrét információs rendszerhez. Erről azonban a következő cikkemben fogok beszélni.
Szerző: Lyudmila Sevastyánova, a Solar inRights marketing menedzsere
Forrás: habr.com
