Jelenleg egy szoftverszállítónál dolgozom, különösen a beléptető megoldásoknál. És az „elmúlt életből származó” tapasztalatom az ügyfél oldalához kapcsolódik - egy nagy pénzügyi szervezethez. Akkoriban az információbiztonsági osztály beléptető csoportja nem büszkélkedhetett nagy kompetenciákkal az IdM területén. Sokat tanultunk a folyamat során, sok zökkenőt kellett eltalálnunk ahhoz, hogy működőképes mechanizmust építsünk ki az információs rendszerek felhasználói jogainak kezelésére a vállalatnál.
A nehezen megszerzett vevői tapasztalatomat a szállítói tudással és kompetenciákkal ötvözve, lényegében lépésről lépésre szóló instrukciókat szeretnék megosztani Önökkel: hogyan készítsünk szerepalapú hozzáférés-vezérlési modellt egy nagyvállalatnál, és ez mit ad ennek eredményeként. . Az utasításaim két részből állnak: az első a modell megépítésére készül, a második a tényleges építés. Íme az első rész, az előkészítő rész.
NB A példakép építése sajnos nem eredmény, hanem folyamat. Illetve még a beléptető ökoszisztéma létrehozásának folyamatának egy része a vállalatban. Így hát készülj a játékra sokáig.
Először is definiáljuk – mi az a szerepalapú hozzáférés-vezérlés? Tegyük fel, hogy van egy nagy bankja, ahol több tíz, vagy akár több százezer alkalmazott (entitás) van, és mindegyikük több tucat hozzáférési joggal rendelkezik több száz belső banki információs rendszerhez (objektumhoz). Most szorozza meg az objektumok számát az alanyok számával - ez a kapcsolatok minimális száma, amelyet először létre kell hoznia, majd ellenőriznie kell. Tényleg lehetséges ezt manuálisan megcsinálni? Természetesen nem – szerepek jöttek létre ennek a problémának a megoldására.
A szerepkör olyan engedélyek halmaza, amelyekre egy felhasználónak vagy felhasználói csoportnak szüksége van bizonyos munkafeladatok végrehajtásához. Minden alkalmazottnak egy vagy több szerepköre lehet, és minden szerepkör egytől több engedélyt tartalmazhat, amelyek a felhasználó számára engedélyezettek az adott szerepkörön belül. A szerepek az alkalmazottak meghatározott pozícióihoz, osztályaihoz vagy funkcionális feladataihoz köthetők.
A szerepkörök általában az egyes információs rendszerekben lévő egyéni alkalmazotti jogosultságokból jönnek létre. Ezután az egyes rendszerek szerepköreiből globális üzleti szerepkörök alakulnak ki. Például a „hitelmenedzser” üzleti szerepkör több különálló szerepet fog tartalmazni a bank ügyfélirodájában használt információs rendszerekben. Például a fő automatizált banki rendszerben, készpénzmodulban, elektronikus dokumentumkezelő rendszerben, szolgáltatásmenedzserben és másokban. Az üzleti szerepkörök általában a szervezeti struktúrához – más szóval a vállalati részlegek és az azokban betöltött pozíciók halmazához – kötődnek. Így jön létre a globális szerepmátrix (az alábbi táblázatban adok egy példát).
Érdemes megjegyezni, hogy egyszerűen lehetetlen 100% -os példaképet felépíteni, amely minden szükséges jogot biztosít az egyes pozíciók alkalmazottai számára egy kereskedelmi struktúrában. Igen, ez nem szükséges. Hiszen a példakép nem lehet statikus, mert az állandóan változó környezettől függ. És a vállalat üzleti tevékenységében bekövetkezett változásoktól, amelyek ennek megfelelően befolyásolják a szervezeti struktúra és a funkcionalitás változásait. És a források teljes körű biztosításának hiányából, és a munkaköri leírások be nem tartásából, valamint a biztonság rovására menő haszonszerzési vágyból és sok egyéb tényezőből. Ezért szükséges egy olyan példakép felépítése, amely a felhasználói igények 80%-át képes lefedni a szükséges alapjogokra egy pozícióhoz rendelve. És szükség esetén a fennmaradó 20%-ot később, külön kérvényeken kérhetik.
Természetesen felteheti a kérdést: „Nincsenek 100%-os példaképek?” Nos, miért, ez megtörténik például a nem gyakori változásoknak kitett nonprofit struktúrákban - egyes kutatóintézetekben. Vagy katonai-ipari komplexumokban, magas szintű biztonsággal, ahol a biztonság az első. Kereskedelmi struktúrában, de külön divízió keretein belül történik, melynek munkája meglehetősen statikus és kiszámítható folyamat.
A szerep alapú menedzsment legfőbb előnye a jogok kiadásának egyszerűsítése, mert a szerepek száma lényegesen kevesebb, mint az információs rendszer felhasználóinak száma. És ez minden iparágra igaz.
Vegyünk egy kiskereskedelmi céget: több ezer értékesítőt foglalkoztat, de az N rendszerben azonos jogokkal rendelkeznek, és csak egy szerepkör jön létre. Amikor új értékesítő érkezik a céghez, automatikusan hozzárendeli a szükséges szerepkört a rendszerben, amely már rendelkezik minden szükséges jogosultsággal. Ezenkívül egyetlen kattintással módosíthatja egyszerre több ezer eladó jogait, például hozzáadhat egy új lehetőséget a jelentéskészítéshez. Nem kell ezer műveletet végrehajtani, minden fiókhoz új jogosultságot kapcsolni – csak adja hozzá ezt a lehetőséget a szerepkörhöz, és az összes eladónál egyszerre fog megjelenni.
A szerepalapú menedzsment másik előnye, hogy kiküszöböli az inkompatibilis jogosultságok kiadását. Vagyis a rendszerben meghatározott szerepkörrel rendelkező munkavállalónak nem lehet egyidejűleg más szerepköre, amelynek jogait nem szabad összevonni az elsőben szereplő jogokkal. Feltűnő példa a pénzügyi tranzakciók beviteli és ellenőrzési funkcióinak kombinálásának tilalma.
Akit érdekel, hogyan jött létre a szerepalapú hozzáférés-vezérlés, az megteheti
merüljön el a történelemben
Ha a történelmet nézzük, az informatikai közösség először a 70. század XNUMX-es éveiben gondolt a hozzáférés-szabályozási módszerekre. Bár az alkalmazások akkoriban is meglehetősen egyszerűek voltak, csakúgy, mint most, de mindenki szerette volna kényelmesen kezelni a hozzáférésüket. Felhasználói jogok megadása, módosítása és ellenőrzése – csak azért, hogy könnyebb legyen megérteni, milyen hozzáféréssel rendelkeznek mindegyikük. De akkoriban még nem voltak közös szabványok, az első beléptetőrendszerek fejlesztése zajlott, és minden cég a saját elképzeléseire és szabályaira épült.
Ma már számos különböző beléptetési modell ismert, de nem jelentek meg azonnal. Maradjunk azoknál, akik jelentős mértékben hozzájárultak e terület fejlődéséhez.
Az első és valószínűleg a legegyszerűbb modell Diszkrecionális (szelektív) hozzáférés-szabályozás (DAC – diszkrecionális hozzáférés-vezérlés). Ez a modell magában foglalja a jogok megosztását a hozzáférési folyamat minden résztvevője között. Minden felhasználó hozzáfér bizonyos objektumokhoz vagy műveletekhez. Lényegében itt a jogalanyok halmaza megfelel a tárgyak halmazának. Ezt a modellt túlságosan rugalmasnak találták, és túlságosan nehéz fenntartani: a hozzáférési listák végül hatalmassá és nehezen ellenőrizhetővé válnak.
A második modell az Kötelező hozzáférés-vezérlés (MAC – Kötelező hozzáférés-vezérlés). E modell szerint minden felhasználó hozzáférést kap egy objektumhoz, a kiadott hozzáférésnek megfelelően egy adott adatbizalmassági szinthez. Ennek megfelelően az objektumokat titkossági szintjük szerint kell kategorizálni. Az első rugalmas modelltől eltérően ez éppen ellenkezőleg, túl szigorúnak és korlátozónak bizonyult. Használata nem indokolt, ha a vállalat sok különböző információforrással rendelkezik: a különböző erőforrásokhoz való hozzáférés megkülönböztetéséhez sok kategóriát kell bevezetni, amelyek nem fedik egymást.
E két módszer nyilvánvaló tökéletlenségei miatt az informatikai közösség folytatta a rugalmasabb, ugyanakkor többé-kevésbé univerzális modellek kidolgozását a különböző típusú szervezeti hozzáférés-szabályozási szabályzatok támogatására. És akkor megjelent a harmadik szerep alapú hozzáférés-vezérlési modell! Ez a megközelítés bizonyult a legígéretesebbnek, mert nemcsak a felhasználó személyazonosságának engedélyezését igényli, hanem a rendszerekben végzett működési funkcióit is.
Az első egyértelműen leírt példakép-struktúrát David Ferrailo és Richard Kuhn amerikai tudósok javasolták az Egyesült Államok Nemzeti Szabványügyi és Technológiai Intézetétől 1992-ben. Ekkor jelent meg először a kifejezés RBAC (Szerep alapú hozzáférés-vezérlés). Ezek a tanulmányok és a fő komponensek leírása, valamint azok összefüggései képezték az alapját a ma is érvényben lévő INCITS 359-2012 szabványnak, amelyet a Nemzetközi Informatikai Szabványok Bizottsága (INCITS) hagyott jóvá.
A szabvány a szerepkört a következőképpen definiálja: "egy szervezet kontextusában egy munkaköri funkció, amelyhez a szerepkörhöz rendelt felhasználóhoz rendelt jogosultságra és felelősségre vonatkozó szemantika kapcsolódik." A dokumentum meghatározza az RBAC alapvető elemeit - felhasználókat, munkameneteket, szerepköröket, engedélyeket, műveleteket és objektumokat, valamint a köztük lévő kapcsolatokat és kapcsolatokat.
A szabvány biztosítja a minimálisan szükséges struktúrát a példakép felépítéséhez – a jogok szerepkörökbe való egyesítése, majd hozzáférés biztosítása a felhasználók számára ezeken a szerepeken keresztül. Felvázoljuk a szerepek objektumokból és műveletekből történő összeállításának mechanizmusait, ismertetjük a szerepek hierarchiáját és a hatáskörök öröklődését. Végtére is, minden vállalatban vannak olyan szerepek, amelyek egyesítik az alapvető jogköröket, amelyek a vállalat összes alkalmazottja számára szükségesek. Ez lehet hozzáférés az e-mailekhez, EDMS-hez, vállalati portálhoz stb. Ezeket az engedélyeket egy általános, „alkalmazotti” szerepkörbe lehet foglalni, és nem kell minden egyes magasabb szintű szerepkörben újra és újra felsorolni az összes alapvető jogot. Elég, ha egyszerűen megjelöljük az „alkalmazotti” szerepre jellemző öröklődést.
Később a szabvány kiegészült a folyamatosan változó környezethez kapcsolódó új hozzáférési attribútumokkal. Statikus és dinamikus korlátozások bevezetésére is lehetőség nyílik. A statikusak a szerepek kombinálásának lehetetlenségét jelentik (a műveletek fent említett bevitele és vezérlése). A dinamikus korlátozások paraméterek megváltoztatásával határozhatók meg, például az idő (munkaidő/munkaszüneti idő vagy napok), hely (iroda/otthon) stb.
Külön kell szólni róla attribútum-alapú hozzáférés-vezérlés (ABAC - Attribútum-alapú hozzáférés-vezérlés). A megközelítés az attribútum-megosztási szabályokkal való hozzáférés megadásán alapul. Ez a modell külön is használható, de gyakran aktívan kiegészíti a klasszikus példaképet: a felhasználók, az erőforrások és az eszközök attribútumai, valamint az idő vagy a hely hozzáadhatók egy bizonyos szerepkörhöz. Ez lehetővé teszi, hogy kevesebb szerepkört használjon, további korlátozásokat vezessen be, és a lehető legminimálisabbra tegye a hozzáférést, ezáltal javítja a biztonságot.
Például egy könyvelő számára engedélyezhető a fiókokhoz való hozzáférés, ha egy bizonyos régióban dolgozik. Ezután a szakember helyét egy bizonyos referenciaértékkel hasonlítják össze. Vagy csak akkor adhat hozzáférést a fiókokhoz, ha a felhasználó az engedélyezettek listáján szereplő eszközről jelentkezik be. Jó kiegészítés egy példaképhez, de önmagában ritkán használják, mivel sok szabályt és engedélyeket vagy korlátozásokat kell létrehozni.
Hadd mondjak egy példát az ABAC használatára a „múlt életemből”. Bankunknak több fiókja volt. Az ügyfélirodák alkalmazottai ezekben a fiókokban pontosan ugyanazokat a műveleteket hajtották végre, de a fő rendszerben csak a régiójukban lévő számlákkal kellett dolgozniuk. Először is elkezdtünk külön szerepköröket létrehozni minden régióhoz – és nagyon sok ilyen szerepkör volt ismétlődő funkcióval, de különböző fiókokhoz való hozzáféréssel! Ezután a hely attribútumot használva a felhasználóhoz, és azt az áttekintendő fiókokhoz rendelve jelentősen csökkentettük a szerepek számát a rendszerben. Ennek eredményeként csak egy fiókban maradtak meg a szerepek, amelyeket a bank összes többi területi részlegében megismételtek a megfelelő pozíciókra.
Most 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ő példaképet építeni.
1. lépés: Hozzon létre egy funkcionális modellt
Kezdje egy funkcionális modell létrehozásával – egy legfelső szintű dokumentummal, amely részletesen leírja az egyes részlegek és pozíciók működését. Az információk általában különféle dokumentumokból kerülnek be: munkaköri leírások és az egyes egységek - osztályok, osztályok, osztályok - szabályzatai. A funkcionális modellt minden érdekelt részleggel (üzleti, belső ellenőrzés, biztonság) meg kell állapodni, és a vállalat vezetőségének jóvá kell hagynia. Mire való ez a dokumentum? Hogy a példakép hivatkozhasson rá. Például egy példaképet fog építeni a munkavállalók meglévő jogai alapján - kirakodva a rendszerből és „közös nevezőre redukálva”. Ezután a kapott szerepkörök egyeztetésekor a rendszer cégtulajdonosával lehet hivatkozni a funkcionális modell egy adott pontjára, ami alapján ez vagy az a jog szerepel a szerepkörben.
2. lépés: Ellenőrizzük az informatikai rendszereket, és prioritási tervet készítünk
A második szakaszban el kell végeznie az IT-rendszerek auditját, hogy megértse, hogyan szerveződik a hozzáférésük. Például a pénzügyi cégem több száz információs rendszert üzemeltetett. Minden rendszer rendelkezett a szerepkör alapú menedzsment bizonyos alapjaival, a legtöbbnek volt néhány szerepköre, de többnyire papíron vagy a rendszerkönyvtárban - ezek már rég elavultak, és a hozzáférést tényleges felhasználói kérések alapján biztosították. Egyszerre több száz rendszerben természetesen lehetetlen példaképet építeni, valahol el kell kezdeni. Elvégeztük a hozzáférés-szabályozási folyamat mélyreható elemzését, hogy meghatározzuk annak érettségi szintjét. Az elemzési folyamat során kidolgozásra kerültek az információs rendszerek rangsorolásának kritériumai - kritikusság, felkészültség, leszerelési tervek stb. Segítségükkel sorra állítottuk e rendszerek példaképeinek fejlesztését/frissítését. Ezután példaképeket vettünk fel az Identity Management megoldással való integráció tervébe a hozzáférés-vezérlés automatizálása érdekében.
Tehát hogyan lehet meghatározni egy rendszer kritikusságát? Válaszoljon magának a következő kérdésekre:
- Kapcsolódik-e a rendszer azokhoz a működési folyamatokhoz, amelyektől a vállalat alaptevékenysége függ?
- Befolyásolja-e a rendszer zavara a vállalat eszközeinek integritását?
- Mekkora a rendszer maximálisan megengedhető állásideje, amelyet elérve nem lehet visszaállítani a tevékenységet megszakítás után?
- A rendszerben lévő információk integritásának megsértése vezethet visszafordíthatatlan pénzügyi és hírnévi következményekhez?
- A csalással szembeni kritika. A funkcionalitás jelenléte, ha nem megfelelően ellenőrzik, belső/külső csaló tevékenységekhez vezethet;
- Milyen jogszabályi követelmények és belső szabályok és eljárások vonatkoznak ezekre a rendszerekre? Kiszabnak-e bírságot a szabályozó hatóságok az előírások be nem tartása miatt?
Pénzügyi társaságunkban ilyen ellenőrzést végeztünk. A menedzsment kidolgozta a hozzáférési jogok felülvizsgálatának ellenőrzési eljárását, hogy először a meglévő felhasználókat és jogokat vizsgálja meg azokban az információs rendszerekben, amelyek a legmagasabb prioritású listán szerepeltek. A biztonsági osztályt jelölték ki ennek a folyamatnak a tulajdonosaként. De ahhoz, hogy teljes képet kapjunk a vállalat hozzáférési jogairól, szükség volt az informatikai és üzleti osztályok bevonására a folyamatba. És itt elkezdődtek a viták, a félreértések, sőt olykor a szabotázsok is: senki sem akar elszakadni jelenlegi feladataitól és belekeveredni néhány, első ránézésre érthetetlen tevékenységbe.
NB A fejlett informatikai folyamatokkal rendelkező nagyvállalatok valószínűleg ismerik az IT audit eljárást – az IT általános kontrollokat (ITGC), amely lehetővé teszi az informatikai folyamatok hiányosságainak azonosítását és az ellenőrzés kialakítását a folyamatok fejlesztése érdekében a legjobb gyakorlatnak megfelelően (ITIL, COBIT, IT). Irányítás stb.) Egy ilyen audit lehetővé teszi az informatika és a vállalkozások számára, hogy jobban megértsék egymást, és közös fejlesztési stratégiát dolgozzanak ki, elemezzék a kockázatokat, optimalizálják a költségeket, és hatékonyabb munkamódszereket dolgozzanak ki.
Az audit egyik területe az információs rendszerekhez való logikai és fizikai hozzáférés paramétereinek meghatározása. A kapott adatokat alapul vettük a további példakép-építéshez. Az ellenőrzés eredményeként rendelkeztünk az informatikai rendszerek nyilvántartásával, amelyben meghatároztuk azok műszaki paramétereit és leírását. Emellett minden rendszerhez azonosítottak egy tulajdonost abból az üzleti irányból, akinek az érdekei szerint üzemeltették: ő volt az, aki felelős a rendszer által kiszolgált üzleti folyamatokért. Kineveztek egy informatikai szolgáltatásvezetőt is, aki egy adott IS üzleti igényeinek műszaki megvalósításáért felel. Rögzítésre kerültek a vállalat számára legkritikusabb rendszerek és azok műszaki paraméterei, üzembe helyezési és leszerelési feltételei, stb. Ezek a paraméterek nagy segítséget nyújtottak a példakép megalkotására való felkészülés során.
3. lépés Hozzon létre egy módszertant
Minden vállalkozás sikerének kulcsa a megfelelő módszer. Ezért mind a példakép felépítéséhez, mind az audit lefolytatásához meg kell alkotnunk egy olyan módszertant, amelyben leírjuk a részlegek közötti interakciót, meghatározzuk a felelősséget a vállalat szabályzatában stb.
Először meg kell vizsgálnia az összes rendelkezésre álló dokumentumot, amely meghatározza a hozzáférés és a jogok megadásának eljárását. Jó értelemben a folyamatokat több szinten kell dokumentálni:
- általános vállalati követelmények;
- az információbiztonsági területekre vonatkozó követelmények (a szervezet tevékenységi területeitől függően);
- technológiai folyamatokra vonatkozó követelmények (utasítások, hozzáférési mátrixok, útmutatók, konfigurációs követelmények).
Pénzügyi társaságunknál sok elavult dokumentumot találtunk, ezeket az új folyamatoknak megfelelően kellett hozni.
A vezetőség megbízásából munkacsoportot hoztak létre, amelyben a biztonsági, informatikai, üzleti és belső kontroll képviselői is helyet kaptak. A megrendelés felvázolta a csoport létrehozásának céljait, a tevékenység irányát, a fennállás időszakát és a felelősöket mindkét oldalról. Ezen túlmenően kidolgoztunk egy ellenőrzési módszertant és a példakép felépítésének eljárását: ezeket a területek összes felelős képviselője egyetértett, és a cég vezetése jóváhagyta.
A munkavégzés menetét, a határidőket, a felelősséget stb. leíró dokumentumokat. - garancia arra, hogy a dédelgetett cél felé vezető úton, ami eleinte nem mindenki számára nyilvánvaló, senkinek nem lesz kérdése, hogy „miért csináljuk ezt, miért van szükségünk rá, stb.” és nem lesz lehetőség „leugrani” vagy lelassítani a folyamatot.
4. lépés: Javítsa ki a meglévő hozzáférés-vezérlési modell paramétereit
A beléptetés szempontjából úgynevezett „rendszerútlevelet” készítünk. Lényegében ez egy kérdőív egy adott információs rendszeren, amely rögzíti az összes hozzáférést szabályozó algoritmust. Az IdM-osztályú megoldásokat már megvalósító cégek valószínűleg ismerik ezt a kérdőívet, hiszen itt kezdődik a rendszerek tanulmányozása.
A kérdőívbe az informatikai nyilvántartásból befolyt néhány paraméter a rendszerről és a tulajdonosokról (lásd 2. lépés, audit), de újak is bekerültek:
- a fiókok kezelésének módja (közvetlenül az adatbázisban vagy szoftveres felületeken keresztül);
- hogyan jelentkeznek be a felhasználók a rendszerbe (külön fiók használatával vagy AD-fiók, LDAP stb. használatával);
- milyen szintű hozzáférést használnak a rendszerhez (alkalmazásszint, rendszerszint, hálózati fájlerőforrások rendszerhasználata);
- azon szerverek leírása és paraméterei, amelyeken a rendszer fut;
- milyen fiókkezelési műveletek támogatottak (blokkolás, átnevezés stb.);
- milyen algoritmusokat vagy szabályokat használnak a rendszer felhasználói azonosítójának generálásához;
- milyen attribútum segítségével lehet kapcsolatot létesíteni a személyzeti rendszerben lévő alkalmazott nyilvántartásával (teljes név, személyi szám stb.);
- minden lehetséges fiókattribútum és a kitöltési szabály;
- milyen hozzáférési jogok léteznek a rendszerben (szerepek, csoportok, atomjogok stb., vannak-e beágyazott vagy hierarchikus jogok);
- a hozzáférési jogok felosztásának mechanizmusai (beosztás, osztály, funkcionalitás stb. szerint);
- Vannak-e a rendszerben szabályok a jogok elkülönítésére (SOD – Segregation of Duties), és ezek hogyan működnek;
- hogyan történik a rendszerben a távollét, áthelyezés, elbocsátás, munkavállalói adatok frissítése stb.
Ez a lista folytatható, részletezve a különböző paramétereket és egyéb objektumokat, amelyek részt vesznek a hozzáférés-vezérlési folyamatban.
5. lépés: Hozzon létre egy üzleti célú engedély leírást
Egy másik dokumentum, amelyre szükségünk lesz a példakép felépítésénél, egy referenciakönyv az információs rendszerben a felhasználók számára biztosítható összes lehetséges jogkörről (jog), a mögötte álló üzleti funkció részletes leírásával. A rendszerben a hatóságok gyakran bizonyos betűkből és számokból álló nevekkel vannak titkosítva, és az üzleti alkalmazottak nem tudják kitalálni, mi rejlik e szimbólumok mögött. Aztán bemennek az informatikai szervizbe, és ott... szintén nem tudnak válaszolni a kérdésre, például a ritkán használt jogokról. Ezután további vizsgálatokat kell végezni.
Jó, ha már van egy vállalkozásleírás, vagy még akkor is, ha ezek a jogok csoportokba és szerepkörökbe kombinálódnak. Egyes alkalmazások esetében a legjobb gyakorlat egy ilyen hivatkozás létrehozása a fejlesztési szakaszban. De ez nem gyakran fordul elő, ezért ismét felkeressük az IT-részleget, hogy információkat gyűjtsünk az összes lehetséges jogról és leírjuk azokat. Útmutatónk végül a következőket tartalmazza:
- a hatóság neve, beleértve azt az objektumot is, amelyre a hozzáférési jog vonatkozik;
- egy tárggyal végrehajtható művelet (megtekintés, változtatás stb., korlátozás lehetősége például területi alapon vagy ügyfélcsoportonként);
- engedélyezési kód (az engedélyezéssel végrehajtható rendszerfunkció/kérés kódja és neve);
- a hatóság leírása (az IS-ben a felhatalmazás alkalmazása során végrehajtott intézkedések és azok folyamatra gyakorolt következményeinek részletes leírása;
- engedély állapota: „Aktív” (ha az engedély legalább egy felhasználóhoz hozzá van rendelve) vagy „Nem aktív” (ha az engedélyt nem használják fel).
6. lépés Letöltjük a felhasználókra és jogokra vonatkozó adatokat a rendszerekből, és összehasonlítjuk azokat a személyzeti forrással
Az előkészítés utolsó szakaszában adatokat kell letöltenie az információs rendszerekből az összes felhasználóról és a jelenleg meglévő jogokról. Itt két lehetséges forgatókönyv lehetséges. Először is: a biztonsági osztály közvetlen hozzáféréssel rendelkezik a rendszerhez, és rendelkezik a vonatkozó jelentések letöltésével, ami nem gyakran történik meg, de nagyon kényelmes. Másodszor: kérést küldünk az IT-nek, hogy megkapja a jelentéseket a kívánt formátumban. A tapasztalatok azt mutatják, hogy az IT-vel nem lehet elsőre megállapodni és megszerezni a szükséges adatokat. Több megközelítést kell végrehajtani, amíg az információ a kívánt formában és formátumban megérkezik.
Milyen adatokat kell letölteni:
- Felhasználónév
- Annak az alkalmazottnak a teljes neve, akihez hozzárendelték
- Állapot (aktív vagy blokkolt)
- Fiók létrehozásának dátuma
- Az utolsó használat dátuma
- Az elérhető jogok/csoportok/szerepek listája
Tehát megkaptuk a letöltéseket a rendszertől az összes felhasználóval és a számukra biztosított jogokkal. És azonnal félreteszik az összes blokkolt fiókot, mivel a példakép felépítésén csak az aktív felhasználók fognak dolgozni.
Ezután, ha a vállalata nem rendelkezik automatizált eszközökkel az elbocsátott alkalmazottak hozzáférésének blokkolására (ez gyakran előfordul), vagy olyan patchwork automatizálással rendelkezik, amely nem mindig működik megfelelően, azonosítania kell az összes „halott lelket”. A már elbocsátott alkalmazottak számláiról beszélünk, akiknek jogai valamilyen okból nincsenek zárolva - zárolni kell őket. Ehhez összehasonlítjuk a feltöltött adatokat a személyi forrással. A személyi kirakodást is előzetesen a személyi adatbázist vezető osztálytól kell beszerezni.
Külön kell félretenni azokat a fiókokat, amelyek tulajdonosai nem találhatók meg a személyzeti adatbázisban, nem voltak hozzárendelve senkihez - vagyis gazdátlanok. Ezt a listát használva szükségünk lesz az utolsó használat dátumára: ha egészen friss, akkor is meg kell keresnünk a tulajdonosokat. Ez magában foglalhatja külső vállalkozók fiókjait vagy szolgáltatási fiókjait, amelyek nincsenek hozzárendelve senkihez, de bármilyen folyamathoz kapcsolódnak. Ahhoz, hogy megtudja, kihez tartoznak a fiókok, levelet küldhet az összes osztálynak, amelyben kéri őket, hogy válaszoljanak. A tulajdonosok megtalálásakor adatokat viszünk be róluk a rendszerbe: így minden aktív fiókot azonosítunk, a többit pedig blokkoljuk.
Amint a feltöltéseink megtisztulnak a felesleges rekordoktól, és csak az aktív fiókok maradnak, elkezdhetjük egy adott információs rendszer példaképének felépítését. De erről a következő cikkben fogok mesélni.
Szerző: Ljudmila Sevastyanova, a Solar inRights promóciós menedzsere
Forrás: will.com