Mielőtt megvizsgálnánk a lehetséges válaszokat a bevezetőben megfogalmazott kérdésekre, előtte tisztázzuk a vállalati architektúra fogalmát. Ezt minden core rendszer bevezetéséhez pontosan ismernünk kell.

A vállalati architektúra (Enterprise Architecture, a továbbiakban: EA) egy olyan koncepcionális modell, amely leírja a vállalat üzleti folyamatait, szervezetét, céljait, termékeit / szolgáltatásait, és ezeknek az összetevőknek a támogató informatikai szolgáltatásokkal és infrastruktúrával való kapcsolatát. Az EA segít abban, hogy a vállalatot egységesen és hatékonyan működtessük, és hogy az informatikai fejlesztések összhangban legyenek az üzleti stratégiával, célokkal és igényekkel.

Az EA különböző rétegekre tagolódik, amely rétegeknek más és más a célközönsége, úgy, mint: üzleti elemzők, IT (megoldás) tervezők, fejlesztők, üzemeltetők stb. A rétegek funkciójának ismerete nélkülözhetetlen minden új (core) rendszer bevezetéséhez, annak érdekében, hogy megértsük a vállalat működésének logikáját, az informatikai rendszerek felépítését és kapcsolódását, valamint a változások hatásait a vállalat egészére.

Az EA-t többféle szempont szerint is feloszthatjuk. Most azonban lássunk egy alapvető és gyakran előforduló felosztást, ami négy réteget különböztet meg:

1. üzleti réteg;

2. adatréteg;

3. alkalmazásréteg és

4. technológiai réteg.

Az üzleti elemző érintettsége az üzleti- és adatrétegekre teljed ki leginkább, az üzleti követelmények és folyamatmodellek specifikálásával. Azonban a további rétegekre is rálátással kell rendelkezzen, támogatva ezzel a tervezési, fejlesztési, tesztelési és bevezetési szakaszokat, illetve végső soron az elvárt üzleti eredmény megvalósulását. Ha az üzleti elemző nem ismeri az általa létrehozott üzleti specifikációra épülő technikai megoldást, akkor nincs teljes rálátása az üzleti- és a technikai rétegek összefüggéseire. Amiből következően, gyakran veszélybe kerül az elvárt üzleti eredmény visszamérhetősége is.

Egy (core) rendszer bevezetése során nem elegendő kizárólag annak az üzleti adataira, folyamataira, követelményeire koncentrálni! A sikeres bevezetés záloga az, ha az üzleti elemző munkája során megvizsgálja a bevezetendő rendszer kapcsolatát a vállalati üzleti stratégiával, a jelenlegi üzleti működési környezettel és az alkalmazott technológiai megoldásokkal. A felsorolt területek jelentik az üzleti architektúra három dimenzióját. Amennyiben ezen dimenziók közül bármelyikre nem fordít kellő hangsúlyt az üzleti elemző, akkor a szállított megoldás beillesztése (integrálása) az EA-ba részben vagy egészben sikertelenné válhat.

Fontos megemlíteni, hogy a fenti ábrán látható háromszög (BA fókuszterület) nem kizárólag a három dimenziót érinti, hanem azok metszeteit is. Amit úgy is értelmezhetünk, hogy az üzleti elemző nem kizárólag azért felel, hogy a három dimenzió mindegyikéhez illeszkedjen az üzleti megoldás. Hanem azért is, hogy a dimenziók kapcsolatait és együttműködését is támogassa a (core) rendszer üzleti specifikációja.

Az ábrán a vállalat külső környezete is megjelenik, amit szintén nem szabad elfejtenünk! Hiszen a kizárólag a belső vállalati környezettel együttműködni képes üzleti megoldás még nem lesz teljes értékű. Hacsak nem tekintünk ki a vállalati környezeten túlra is. És biztosítjuk, hogy a szükséges megfelelési szint teljesül a külső környezet irányába is (pl.: törvényi szabályozási környezet).

Az IAM rendszer egy olyan keretrendszer, amely lehetővé teszi a szervezetek számára, hogy kezeljék és ellenőrizzék az erőforrásaikhoz, illetve az adataikhoz való hozzáférést. Az IAM mindezt négy fő logikai komponens együttes működésével valósítja meg.

Az authentikációs komponens felel a rendszer munkamenetek biztonságáért, azok többszintű titkosításával.

A hozzáférés hitelesítést biztosító komponens egy kritikus eleme a rendszer működésének, amely többféle hitelesítési lehetőséget biztosít a jogosultságok kiosztásához, úgy mint: szerepkör-, szabály- vagy attribútum alapú jogosultság-menedzsment.

Például az attribútum alapú jogosultságkezelés (más néven ABAC) egy olyan IAM módszer, amely a felhasználók, erőforrások és környezeti tényezők tulajdonságai (attribútumai) alapján határozza meg a hozzáférési jogokat. Az ABAC jól használható az egészségügyi szektorban is. Ahol a betegadatokhoz való hozzáférés függ a felhasználó szerepétől, a beteg hozzájárulásától, a kezelés helyétől és időpontjától, valamint a jogszabályi előírásoktól.

A felhasználó menedzsment komponens biztosítja, hogy az egyes felhasználói fiókok teljes életciklusát és a hozzájuk rendelt valamennyi jogosultságot ellenőrzés alatt tudjuk tartani, az IAM-mel integrált alkalmazásokban. Betartva az egyes alkalmazások jogosultságkezelési alrendszerének alapvető működési szabályait. Továbbá ezen komponens felel a vállalat munkavállalói számára biztosítandó önkiszolgáló alrendszer működtetésért. Ahol bármely arra jogosult munkavállaló leadhatja és módosíthatja jogosultsági- vagy account igényléseit. Akárcsak amikor egy online vásárlás során hozzáadunk a megrendelési korsarunkhoz egy új árucikket.

A központi user repository komponens tárolja a felhasználók adatait, mint például a nevüket, e-mail címüket, jelszavakat, szerepüket, engedélyeiket és egyéb jellemzőket. A központi user repository lehetővé teszi, hogy a felhasználók egységesen és biztonságosan hitelesíthessék magukat a különböző alkalmazásokhoz és erőforrásokhoz.

Az IAM rendszer bevezetését – sok más IT core rendszerhez hasonlóan – hajlamosak a cégek elsősorban technológiai projektként értelmezni. Ha megvizsgáljuk, hogy az előző fejezetben felsorolt négy logikai komponens milyen fő funkciókkal rendelkezik, és azok kikre vannak hatással a cég életében, akkor könnyen belátható a tévedés. Gondoljunk csak arra, hogy az IAM rendszer minden munkavállaló számára egy self-service platformot biztosít, ahol az account- és jogosultságigényléseit kezelheti. Vagy nézzük az új munkavállalók belépési folyamatát! Ezt jellemzően a HR terület szokta kezelni, és ezen folyamat során számos alapvető jogosultságot és eszközigénylést indítanak el az új belépő számára. Természetesen egy központi account- és jogosultságkezelés hatással van a legtöbb termék- és szolgáltatásfejlesztésre is, az ezek hátterében elhelyezkedő üzleti folyamatok révén. És ne feledkezzünk meg a szabályozási területről sem. Vajon, ha a jelenlegi account- és jogosultságkezelési rendszert egy új központi logika mentén szervezzük újra, akkor az nem igényelne egy igen komplex üzleti szabályozást és oktatást a vállalattól? Nos, természetesen igen.

A következőkben megvizsgáljuk az IAM rendszer alapvető működését az azzal integrált alkalmazások szempontjából is. Alátámasztva ezzel a fentiek alapján már részben kimondható állításunkat, miszerint az IAM core rendszer bevezetésének sikere egyértelműen a megfelelő üzleti alapok megteremtésén múlik, és nem kezelhető kizárólag technológiai projektként, üzleti elemzés nélkül.

Ahhoz, hogy képesek legyünk a központi identitás- és hozzáférésmenedzsment funkciókat biztosítani egy vállalat számára, alapvető elvárás, hogy valamennyi vállalati alkalmazás integrálva legyen az IAM rendszerrel. (Legalábbis azok, amelyekben működik folyamat az identitás- és hozzáférésmenedzsment kezelésére. Egyes alkalmazásokban ezen folyamatok kiszervezett módon történnek.)

Tételezzük fel, hogy bekötöttünk az IAM rendszerbe egy üzleti alkalmazást, amely a napi ügyfélkezelési folyamatban vesz részt. Hogyan tudunk egy új jogosultsági igényt leadni, hogy hozzáférjünk az üzleti alkalmazás riporting funkciójához is a jövőben és kepések legyünk megjeleníteni az ott elkészült riportokat? Lássuk most ezt a folyamatot lépésről lépésre:

1. Az IAM önkiszolgáló (self-service) felületen keresztül kiválasztjuk a számunkra szükséges jogosultságot a riportok megtekintéséhez. Hozzáadjuk azt a „bevásárlókocsinkhoz”, majd elküldjük az igénylést, a kötelező adminisztratív és technikai input adatok megadása mellett.
2. Az IAM önkiszolgáló alrendszer lefordítja az igénylésünket és elindítja az IAM core rendszerben az igénylésünk jóváhagyási folyamatát. Ha megkaptuk a jóváhagyást, akkor az IAM rendszer automatikusan beállítja a jóváhagyott account- és/vagy jogosultság igénylést a szóban forgó (riportokat biztosító) üzleti alkalmazásban.

A fenti folyamat természetesen ennél a gyakorlatban jóval összetettebb, azonban ebből az egyszerűsített leírásból is jól látható az alapvető működési logika.

A hozzáférésvezérlésre három fő megoldást kínál az IAM rendszer. Ezek külön-külön és kombinált módon is alkalmazhatók egy vállalaton belül, amennyiben a kiválasztott IAM termék azt nem korlátozza. Azonban az eltérő módszerek kombinációjának alkalmazását minden esetben javasolt előzetesen elemezni a szükséges ráfordításokat és a várható üzleti előnyöket mérlegelve. Jellemzően a három módszer közül az egyik vagy a másik kerül bevezetésre, amelyik jobban illeszkedik a vállalat hosszútávú üzleti- és technológiai céljaihoz.

Bármelyik megoldást is alkalmazzuk, fontos kihangsúlyozni, hogy csakis akkor működhet megfelelően a választott módszer, ha annak a vállalati szabályozási hátterét is megteremtjük. Gondoljunk csak arra, hogy ha a kezdeti állapotból bármelyik módszer irányába el kívánunk mozdulni, az egy más megközelítést is magával hoz a hozzáférések kezelésében. Így az üzleti folyamatokra, logikára és a vállalati kultúrára is hatással lesz. Természetesen ugyanez igaz arra is, ha az egyes módszerek közötti váltásról beszélünk.

Milyen felelősége van egy üzleti elemzőnek egy sikeres IAM (core) rendszer bevezetésében? Talán az olvasó kapásból rávágja ezen a ponton a választ. „Az üzleti specifikáció kidolgozása, annak minden releváns folyamatával és követelményével együtt.” Ami általánosságban véve igaz is, de nézzük meg egy kicsit közelebbről, hogy mit is kell tartalmazzon egy üzleti specifikáció ebben az esetben.

A követelményeket és üzleti folyamatokat, mint minden core rendszer bevezetése esetén is, három területre oszthatjuk fel:

1: Funkcionális követelmények, amelyek az IAM rendszer belső üzleti működését és folyamatait írják le. (pl.: „webshop” felület működése, az új jogosultsági- vagy account igénylések folyamata, account lifecycle, igénylések jóváhagyási workflow stb.)

2: Nem funkcionális követelmények, amelyek vállalati (üzleti) működési környezetéhez való sikeres integráláshoz szükségesek. (pl.: rendszer-üzemeltetési folyamatok, teljesítmény elvárások, vállalati szabályozási környezetnek való megfelelés, kompatibilitás, skálázhatóság, vállalati oktatás, külső support stb.)

3: Nem funkcionális követelmények másik csoportja, amelyek az IAM rendszerrel integrálni kívánt alkalmazások üzleti- és technikai működéséből fakadnak (pl.: account- és jogosultság adatok szinkronizálás során felmerült eltérések kezelési folyamata és szabályozása, új alkalmazások bekötésének (üzleti) integrációs követelményei, a bekötött alkalmazások közötti felmerülő üzleti szabályok kezelése stb.).

Természetesen a sort egy negyedik ponttal kell lezárnunk a teljeskörű üzleti megoldás specifikálásához. A vállalati külső, de még releváns környezet nem funkcionális követelményeivel. (Pl.: hazai- és nemzetközi jogkörnyezetnek való megfelelés).

A fentiek alapján már láthatjuk, milyen területekre kell kiterjednie az üzleti elemzésnek az IAM (core) rendszer bevezetési projektek során. Továbbá az is megállapítható, hogy tisztán technológiai projektként nem javasolt kezelni az IAM rendszer bevezetéseket.

Szerző:
Egervári Balázs, vezető tanácsadó