Dolgozók és szerepkörök biztonságos kezelése

Válaszd szét a felhasználót, szerepet és jogosultságot

A felhasználó egy személyhez tartozik névvel és e-maillel. A szerep munkakört ír le, például recepciót vagy housekeepinget. A jogosultság határozza meg az olvasást, írást vagy kezelést.

A Hotel Nordlicht vezetési, recepciós, housekeeping és pénzügyi profillal indul. Egy személy több feladatot is elláthat, de saját fiókot és a legkisebb megfelelő szerepet kapja.

Tarts külön három fogalmat. A felhasználó egy azonosítható személy saját belépéssel, nyelvvel és aktív állapottal. A szerep jóváhagyott munkakört csoportosít. A jogosultság konkrét műveletet enged, például foglalás olvasását, pénzügyi beállítás változtatását vagy felhasználókezelést. Ne hozz létre közös „recepció” felhasználót, mert a művelet, hiba és későbbi audit nem kötődne személyhez. Minden dolgozót a helyes hotelhez rendelj, és kényelemből ne vigyél tovább korábbi felelősségből származó jogot. A rendszerszerepek karbantartott alapot adnak; egyedi szerep csak stabil működési igénnyel indokolt. Rögzítsd a szerep felelősét és jóváhagyási dátumát. Beállítás előtt írd le a kívánt feladatkört és érzékeny kizárásokat. A modell akkor kész, ha a vezetés el tudja magyarázni, ki a személy, miért létezik a szerep, és mely pontos műveletet engedi vagy tiltja informális munkaköri cím nélkül.

Feladat tervezése jogosultság előtt

Sorolj fel öt-tíz gyakori feladatot munkakörönként. A recepció foglalással, vendéggel és üzenettel, a housekeeping napi tervvel, a pénzügy dokumentummal és fizetéssel, a vezetés riporttal és beállítással dolgozik.

Jelöld, hogy a feladathoz olvasás vagy módosítás kell. A szobák megtekintése nem jelent elérhetőségkezelést; a számla megtekintése nem jelent fizetési korrekciót. Ne engedélyezz modult „biztos ami biztos” alapon.

A hozzáférést feladatból és kockázatból tervezd. Listázd, mit kell a recepciónak, housekeepingnek, pénzügynek, vezetésnek és ideiglenes helyettesnek normál műszakban elvégeznie, majd határozd meg a legkisebb szükséges adat- és műveletkört. Ahol a termék támogatja, különítsd el az olvasást, létrehozást, szerkesztést, jóváhagyást, exportot és adminisztrációt. Külön figyelj a vendégadatra, dokumentumra, fizetésre, rátára, hotelbeállításra és felhasználó-adminisztrációra. Aki riportot igényel, nem automatikusan jogosult konfigurációra; aki szobamunkát frissít, nem igényel vendégpénzügyet. Állandó adminjog helyett határozz meg vészhelyzeti eszkalációt. Jegyezd fel a második jóváhagyást vagy későbbi felülvizsgálatot igénylő műveletet. Vesd össze a tervet a valós helyettesítéssel és munkaidőn kívüli támogatással. A feladatterv akkor sikeres, ha minden jog megnevezett folyamatot támogat, minden érzékeny kizárásnak van működési alternatívája, és nincs jog csak azért, mert „egyszer hasznos lehet”.

Rendszerszerepek ellenőrzése és tudatos egyedi szerepek

Nyisd meg a Beállítások → Felhasználók és szerepkörök részt. A STRYK Inhaber, Admin, Recepció és Housekeeping kiinduló profilt ad. Ellenőrizd a leírást, aktivitást, hozzárendelt felhasználót és moduljogot.

Egyedi szerepet csak tartósan eltérő munkakörhöz hozz létre, például pénzügyhöz hotelkonfiguráció nélkül. Adj világos nevet és leírást, válaszd a szükséges modulokat, majd ellenőrizd a mentést.

Egyedi szerep előtt vizsgáld meg a meglévő rendszerszerepeket. Hasonlítsd össze a tényleges jogosultságukat a feladatmátrixszal, és teszteld a megnyitott termékterületeket. A legközelebbi, legkisebb jogosultságú alapot válaszd, egyedi szerepet csak visszatérő, másként biztonságosan nem ábrázolható munkához készíts. Az egyedi szerep neve felelősséget írjon le, legyen felelőse, és ne személynévből álljon, amely létszámváltozáskor értelmetlenné válik. Ne másolj adminszerepet néhány látható elem eltávolításával rejtett műveletek tesztje nélkül. Nyisd újra a mentett szerepet, és hasonlíts össze minden jogot. Ugyanahhoz a munkához egy kanonikus szerepet tarts, ne több majdnem azonos változatot. Új funkció új jogánál széles kiosztás előtt vizsgáld a hatást. A szerepterv akkor sikeres, ha minden szükséges feladatot enged, idegen érzékeny műveletet tilt, és a létrehozótól független vezető számára is érthető.

Személyes felhasználók biztonságos létrehozása

A felhasználói területen válaszd a létrehozást, add meg a teljes nevet, elérhető saját e-mailt és előkészített szerepet. A kezdőjelszót biztonságosan add át, és mentés előtt ellenőrizd az e-mailt.

A Hotel Nordlicht külön felhasználót hoz létre vezetéshez, recepciós műszakhoz, housekeepinghez és pénzügyhöz. A műszak szerepet megoszthat, fiókot nem.

A megnevezett dolgozóhoz ellenőrzött munkahelyi e-maillel és helyes hotellel hozz létre egy fiókot. Állítsd be a kívánt nyelvet, aktív állapotot és jóváhagyott szerepet; képernyőkép kedvéért ne tölts ki kitalált személyes adatot. A beléptetést a jóváhagyott fiókfolyamatban add át, és követeld meg a hitelesítő adatok titokban tartását. Közös adminjelszót ne küldj chatben és ne tárolj recepciós jegyzetben. Erősítsd meg, hogy a személy be tud lépni, a helyes hotelfiókba és nyelvre érkezik. Mentés után vizsgáld a felhasználói rekordot, nehogy nem kívánt szerepet örökölt. Emelt hozzáférésnél rögzíts jóváhagyót és felülvizsgálati dátumot. A kioskazonosító hotelfiók-specifikus technikai felhasználó, amely a kioskélményt nyitja meg, nem normál admint; nem helyettesíti a dolgozói fiókot. A létrehozás akkor sikeres, ha egy valós személy egy követhető fiókot kezel, és műszakhoz sem belépést, sem szerepet nem kell megosztani.

Minden szerep tesztelése pozitív és negatív esettel

Lépj be szereptesztelő felhasználóval, és ellenőrizd a pozitív esetet: recepció eléri a foglalást és vendéget, housekeeping a napi tervet, pénzügy a dokumentumot. Jelölt tesztadatot használj.

Ezután ellenőrizd a tudatos tiltást. Ha feladat hiányzik, a központi szerepet módosítsd a legkisebb szükséges joggal, lépj be újra, és teszteld az engedélyezett és tiltott esetet.

Minden szerepet pozitív és negatív esettel tesztelj a tesztfelhasználóval bejelentkezve. A pozitív eset bizonyítja a szükséges munkát: recepciós jóváhagyott foglalást nyit és frissít, housekeeper a közös napi tervet használja, pénzügyes eléri a kívánt dokumentumot, vezető engedélyezett konfigurációt végez. A negatív eset ugyanilyen fontos: ugyanaz a felhasználó láthatóan hibázzon idegen pénzügy, felhasználó-adminisztráció, érzékeny vendégexport vagy hotelbeállítás próbáján. Teszteld a közvetlen navigációt is, ne csak a hiányzó menüt; a biztonság nem támaszkodhat rejtett linkre. Rögzítsd a szerepet, műveletet, várt és tényleges eredményt, bizonyítékot. Kritikus hiba, ha STRYK-hiba mellett mégis változik adat, a helyileg szimulált siker pedig érvénytelen. Szerepszerkesztés és lényeges termékváltozás után tesztelj újra. A szerep csak akkor jóváhagyott, ha a szükséges művelet sikeres, a tiltott STRYKoldalon hibázik, és az eredmény kijelentkezés és friss belépés után is megmarad.

Helyettesítés, szerepváltás és kilépés tiszta kezelése

Helyettesítésnél határozd meg az időszakot és konkrét többletfeladatot. Különítsd el a dokumentum olvasását a fizetés kezelésétől, és rögzítsd a visszaállítás dátumát.

Tartós szerepváltásnál a személyes felhasználó szerepét módosítsd, ne hozz létre második fiókot. Kilépéskor az utolsó napig deaktiváld, de őrizd az előzményt. A STRYK-deaktiválás nem helyettesíti a teljes hoteli offboarding listát.

A helyettesítést, szerepváltást és kilépést dátumozott hozzáférési eseményként kezeld. Ideiglenes helyettesnél a meghatározott időre a legkisebb kiegészítő szerepet add, rögzítsd a jóváhagyót és eltávolítási dátumot, belépést ne ossz meg. Részlegváltásnál hasonlítsd össze a régi és új feladatmátrixot, előbb töröld a már nem szükséges jogot, majd add az újat. Kilépésnél gyorsan deaktiváld a személyes felhasználót, őrizd meg az auditnyomot, és rendeld újra a nyitott működési felelősséget, például housekeeping szobát vagy jóváhagyást. Előzmény eltüntetéséhez ne töröld a fiókot, és „hátha kell” alapon ne hagyd aktívan. Ahol lehet, vizsgáld az aktív munkamenetet és kapcsolt hozzáférést, a jogszerűen ismert közös külső jelszót pedig cseréld. Az utódot külön teszteld. Az esemény akkor kész, ha a korábbi felhasználó nem fér hozzá, az előzmény követhető, a nyitott munkának új felelőse van, az utód csak jóváhagyott aktuális jogot kap.

Hozzáférés rendszeres felülvizsgálata és jóváhagyása

Havonta rövid csapategyeztetést, negyedévente teljes szerepfelülvizsgálatot végezz. Ellenőrizd az aktív felhasználót, munkakört, szezonális dolgozót, helyettesítést, duplikációt és nem használt szerepet.

Rögzítsd a dátumot, ellenőrt, változást és következő felülvizsgálatot. A Hotel Nordlicht hat személyes fiókot, négy működési szerepet és nulla közös belépést igazol.

Rendszeresen vizsgáld a hozzáférést az aktív felhasználók, szerepdefiníciók és közelmúltbeli működési felelősség alapján. Minden felhasználónál erősítsd meg az azonosságot, munkaviszonyt vagy szerződést, hotelt, szerepet, emelt jogot, utolsó jóváhagyást és fennálló üzleti igényt. Az egyedi szerepeknél keresd a duplikációt és új funkció által hozzáadott jogot. Mintavétellel ellenőrizd az érzékeny pénzügyi, vendég-, árazási és adminművelet auditbizonyítékát. A vezető kifejezetten hagyja jóvá vagy távolítsa el a hozzáférést; a hallgatás nem jóváhagyás. Kövesd a lejárt ideiglenes jogot és továbbra is engedélyezett inaktív fiókot. Rögzítsd a felülvizsgálati dátumot, ellenőrzőt, javítást és lezárási bizonyítékot fölösleges személyes adat második táblázatba másolása nélkül. Ismételd nagy létszám- vagy termékváltozás után és meghatározott rendszerességgel. A felülvizsgálat akkor kész, ha minden aktív fióknak aktuális felelőse és oka van, minden szerep tesztelt, a többletjog eltávolított, a vezetés a központi rendszerből követni tudja a döntést.

A felülvizsgálat végén végezz külön hotelfiók-ellenőrzést is: minden aktív felhasználó csak ahhoz a hotelhez férjen hozzá, amelyhez jóváhagyták, és egy másik hotelfiók azonosítójával végzett közvetlen kérés STRYKoldalon bukjon el. A tesztbizonyíték ne tartalmazzon vendégadatot vagy jelszót; elegendő a felhasználó, szerep, hotel, művelet, várt tiltás és időpont. Ezzel a jogosultsági ellenőrzés nemcsak menüszintű, hanem a többhoteles adatelkülönítést is ténylegesen igazolja.