
A hozzáférések módosítása nemcsak műszaki, hanem koordinációs probléma is. Egy identitásplatform nem tudja megszüntetni egy alvállalkozó fiókját, ha senki sem szól a gazdájának, hogy a szerződés lejárt. Ugyanígy egy időben érkező HR-értesítés sem bizonyítja, hogy minden alkalmazás valóban nem fogadja el többé az adott személy hitelesítő adatait.
A belépőknek, áthelyezetteknek és kilépőknek olyan folyamatra van szükségük, amely egy üzleti eseményt egy jóváhagyott hozzáférési állapothoz kapcsol, végrehajtja a szükséges módosításokat, és ellenőrzi az eredményt. A műszaki vezetés szemszögéből nem az a fontos kérdés, hogy létezik-e kiléptetési ellenőrzőlista. Hanem az, hogy a folyamat lefedi-e az emberek által ténylegesen használt rendszereket, kezeli-e a hibákat, és hagy-e bizonyítékot arról, mi és mikor változott.
Minden életciklus-eseményt egy személy engedélyezett hozzáférésének módosításaként kezeljen, ne pusztán egy fiók létrehozására vagy letiltására szolgáló jegyként. Az eseményrekordnak azonosítania kell a személyt, a foglalkoztatási vagy megbízási státuszt, a vezetőt vagy szponzort, a hatálybalépés dátumát és időpontját, valamint az érintett szerepkört. Használjon stabil azonosítót, ahelyett hogy kizárólag nevekre vagy e-mail-címekre hagyatkozna.
A munkavállalói eseményeket gyakran a HR kezdeményezi. Az alvállalkozói eseményeket kezdeményezheti egy beszerzési felelős, egy projektvezető vagy egy belső szponzor. Minden populációhoz válasszon hiteles forrást, és határozza meg, hogyan jutnak el az informatikához a javítások, a meghiúsult belépések, a szerződéshosszabbítások és a sürgős távozások.
Válasszon szét négy felelősségi kört, még akkor is, ha egy kis csapatban többet ugyanaz a személy lát el:
| Felelősségi kör | Elszámoltatható tevékenység | Elvárt rekord |
|---|---|---|
| Kezdeményezés | Pontos esemény és hatálybalépési időpont megadása | Eseményrekord és forrás |
| Jóváhagyás | A szándékolt hozzáférés és a kivételek megerősítése | Megnevezett jóváhagyás és indoklás |
| Végrehajtás | A módosítások alkalmazása az érintett rendszerekben | Rendszerenkénti eredmények és időbélyegek |
| Ellenőrzés | Az eredményül kapott állapot ellenőrzése és az eltérések rendezése | A felülvizsgálat eredménye és a nyitott kivételek |
Nevezzen meg helyetteseket és eszkalációs útvonalat. Egy ütemezett távozás nem függhet attól, hogy egyetlen rendszergazda elérhető-e. Érzékeny módosításoknál egy független felülvizsgáló hasznos ellenőrzést jelent; ahol a létszám ezt nem teszi lehetővé, dokumentálja a megoldást, és alkalmazzon utólagos felülvizsgálatot.
Minden eseményhez határozzon meg befejezési kritériumokat. Egy belépő akkor kész, amikor a jóváhagyott hozzáférést és a szükséges eszközkontrollokat ellenőrizték. Egy áthelyezés akkor zárul, amikor a hozzáadásokat és a visszavonásokat is ellenőrizték. Egy kilépés akkor zárul, amikor a hozzáférési útvonalakat visszavonták, a nyitott eszköz-, adat- vagy hitelesítőadat-kérdéseknek pedig kifejezett felelősük van.
Ezek gyakorlati kontrolltervezési ajánlások, nem általános törvényi határidők. Egy ISO 27001 szerinti IBIR-en belül a hozzáférési kontrolloknak a szervezet hatókörét és kockázatkezelését kell tükrözniük. A tágabb kontrollkontextushoz lásd: Az ISO 27001 A melléklete a gyakorlatban.
Kezdje az alkalmazásleltárral. Minden rendszerhez rögzítse a gazdáját, az identitásforrást, a jogosultságkiosztás módszerét, a hitelesítés módját, a támogatott visszavonási műveleteket és az ellenőrzés módszerét. Vegye fel a központilag kezelt alkalmazásokat és a helyi fiókokkal rendelkezőket is.
Az egyszeri bejelentkezés nem feltétlenül jelent teljes életciklus-kezelést. Egy alkalmazás az identitásszolgáltatón keresztül is hitelesíthet, miközben helyi rendszergazdákat, API-kulcsokat, aktív munkameneteket vagy helyreállítási lehetőségeket tart fenn. Egy jogosultságkiosztási csatoló letilthat egy felhasználót anélkül, hogy minden jogosultságát eltávolítaná. Dokumentálja, mit csinálnak ténylegesen az egyes mechanizmusok.
Vegye fel ezeket a kevésbé látható hozzáférési útvonalakat is:
Ne tiltson le automatikusan minden, egy távozó munkavállalóhoz kapcsolódó szolgáltatásidentitást: lehet, hogy éles munkaterhelést futtat. Ehelyett adja át a tulajdonjogot, vizsgálja felül a jogosultságokat, és szükség szerint cserélje le a kitett hitelesítő adatokat. A cél a személy hozzáférésének megszüntetése elkerülhető kiesés okozása nélkül.
A leltárt rendszeresen vesse össze identitásexportokkal, eszköznyilvántartásokkal, beszerzési nyilvántartásokkal és a csapatok bejelentéseivel. Egyetlen forrás sem fog feltétlenül minden alkalmazást feltárni. A nem kezelt rendszerek felfedezésének az életciklus-folyamatba kell kerülnie, nem informális kivételként maradnia.
A hozzáférési csomagokat a felelősségi körök köré határozza meg, ne csak a munkakörök megnevezése köré. Egy ügyfélszolgálati elemzőnek szüksége lehet az ügyfélkérések elérésére, de a számlázási exportokra nem. Egy szoftvermérnöknek szüksége lehet a forráskód-tárolókra és a fejlesztői környezetekre anélkül, hogy alapértelmezés szerint éles adminisztratív jogosultságot kapna.
Minden alapcsomagnak legyen gazdája, verziója, a benne foglalt csoportok vagy jogosultságok listája és egy felülvizsgálati dátuma. Rögzítse, melyik verziót alkalmazták egy belépőnél. Ellenkező esetben egy későbbi szerepkör-frissítés megnehezíti a korábbi hozzáférési döntések rekonstruálását.
A további hozzáféréseket külön kérelmezzék. A kérelemben szerepeljen az üzleti cél, a jóváhagyó rendszer- vagy adatgazda, a jogosultsági szint és – ahol indokolt – a lejárat. Kerülje egy meglévő munkavállaló teljes jogosultságkészletének lemásolását: ez a korábbi szerepkörökből felhalmozódott kivételeket és jogosultságokat is átviheti.
Ahol hasznos, készítse elő a fiókokat a belépés napja előtt, de az aktiválást ellenőrizze. Egy meghiúsult felvétel esetén takarítsa el az előkészített fiókokat, a kiszállított eszközöket és a meghívókat. Az alvállalkozóknak legyen belső szponzoruk és egy lejárati vagy felülvizsgálati dátumuk; a hosszabbítás kifejezett döntést igényeljen, ne váljon csendben állandó hozzáféréssé.
Rögzítse az eszközazonosítót, a hozzárendelt személyt, az átadás dátumát és a felügyeleti rendszerbe való regisztrációt. Érzékeny hozzáférés megadása előtt ellenőrizze a vonatkozó alapszintet: támogatott operációs rendszer, javítócsomagok állapota, lemeztitkosítás, képernyőzár, végpontvédelem és jóváhagyott hitelesítési beállítás.
Ezek kockázatalapú megvalósítási döntések, nem annak állítása, hogy minden szervezetnek azonos beállításokat kell használnia. A személyes eszközöknél kifejezetten határozza meg a megengedett hozzáférést és adatkezelést, ahelyett hogy a felügyelt laptopokkal egyenértékűként kezelné őket.
Ahol elérhetők, használja az eszközfelügyeleti rendszerek dátummal ellátott megfigyeléseit. Egy manuális leltár is hasznos lehet, ha egyeztetik és bizonyítékokkal támasztják alá; egy élő leltárt is kritikusan kell vizsgálni, ha egy eszköz már nem küld jelentést. Őrizze meg a megfigyelések időpontját, hogy egy régi, megfelelő állapotot ne tévesszenek össze az aktuális bizonyossággal.
Ellenőrizze a hitelesítési regisztrációt és a kezdeti hitelesítő adatok átadását. Ahol a szabályzat többtényezős hitelesítést ír elő, erősítse meg, hogy az aktív, mielőtt a hozzáférés megkezdődik, ahelyett hogy csak azt rögzítené, hogy a regisztrációs meghívót elküldték. A hitelesítő adatokat és a helyreállítási kódokat ne tárolja az életciklus-jegyekben.
Az áthelyezések gyakran a legnehezebb életciklus-események, mert a személy továbbra is a szervezetnél dolgozik, és meglévő fiókja továbbra is működik. Az új hozzáférések figyelmet kapnak, mert a hiányzó jogosultságok megakasztják a munkát. A régi hozzáférések viszont látható tünet nélkül fennmaradhatnak.
Az áthelyezést három állapot összehasonlításaként kezelje: a jelenlegi hozzáférés, a jóváhagyott új alapcsomag és a jóváhagyott, továbbra is fennálló kivételek. Határozza meg, mely jogosultságokat kell hozzáadni, megtartani, csökkenteni vagy eltávolítani. A csoportok mellett ellenőrizze a közvetlen hozzárendeléseket, a beágyazott tagságokat, az adminisztratív szerepköröket és a helyi alkalmazásjogosultságokat is.
A korábbi vezetőnek segítenie kell azonosítani a megszűnt felelősségi köröket. A fogadó vezető megerősíti az új feladatokat, míg a rendszer- vagy adatgazdák jóváhagyják az érzékeny hozzáféréseket. Ez megakadályozza, hogy egy új vezető hallgatólagosan engedélyezze egy másik részleg információihoz való hozzáférés megtartását.
Egy átmeneti időszak jogos lehet. Aki a pénzügyről távozik, annak korlátozott hozzáférésre lehet szüksége egy átadás befejezéséhez. Rögzítse a konkrét jogosultságot, az indoklást, a jóváhagyó gazdát és a lejáratot. Ahol lehetséges, a széles körű írási hozzáférést cserélje szűkebbre vagy csak olvasási hozzáférésre. A lejáratot végrehajtható feladatban vagy rendszerbeállításban rögzítse, ne csak egy megjegyzésben.
A módosítások az eszközöket, a megosztott postafiókokat, az adatgazdaságot és a kiemelt jogosultságú feladatokat is érinthetik. Egy adminisztratív szerepkörbe való áthelyezés nem alakíthatja automatikusan kiemelt jogosultságú identitássá a mindennapi fiókot.
A végrehajtás után vesse össze a tényleges hozzáférési készletet a szándékolt eredménnyel. Egy részlegek közötti áthelyezésnél az új szerepkör megadása könnyű lehet. A fontos ellenőrzés az, hogy megmaradt-e a korábbi pénzügyi, ügyfél- vagy adminisztratív hozzáférés. Egy áthelyezési minta, amely csak az új jogosultságkiosztást ellenőrzi, nem veszi észre ezt a kockázatot.
Rögzítse a visszavonás hatálybalépésének időpontját, az időzónával együtt. Az „utolsó nap” túl kétértelmű az elosztott csapatok és az ütemezett automatizálás számára. Különböztesse meg a tervezett távozást a sürgős felmondástól, a feltételezett kompromittálódástól vagy az ideiglenes felfüggesztést igénylő váratlan távolléttől.
Az időzítést egyeztesse a HR-rel és az érintett vezetéssel. Az érzékeny felmondási részleteket korlátozza azokra, akiknek szükségük van rájuk, ugyanakkor biztosítsa, hogy a végrehajtók elegendő információt kapjanak a cselekvéshez. A magas kockázatú távozások összehangolt, azonnali intézkedést igényelhetnek; a rutinszerű távozások lehetővé tehetnek egy tervezett átadást a hozzáférés megszűnése előtt.
Ne hagyja, hogy az adatátadás vagy az eszköz visszaküldése késleltesse a visszavonást. Ezeknek a tevékenységeknek külön befejezési dátumuk és felelősük lehet. Ha egy kiváltó esemény későn érkezik, rögzítse a tervezett határidőt, a tényleges végrehajtást és a kitettségi időszakot, ahelyett hogy a dokumentációt úgy módosítaná, hogy az esemény időben történtnek tűnjön.
Tiltsa le az elsődleges identitást, és hajtsa végre a leltár szerinti alkalmazásspecifikus műveleteket. Szükség szerint kezelje az aktív munkameneteket, a frissítő tokeneket, a helyi fiókokat, a kiemelt jogosultságú fiókokat, a távoli hozzáférést, a tanúsítványokat és a személyes hitelesítő adatokat. Egy központi fiók letiltása nem bizonyítja, hogy minden meglévő munkamenet vagy egymástól függetlenül kiadott hitelesítő adat használhatatlanná vált.
A személy által elérhető megosztott titkokat a kockázatnak megfelelően cserélje le, és ellenőrizze, hogy a csere nem zavarja-e meg a függő rendszereket. Távolítsa el azokat a helyreállítási módszereket vagy delegált jogosultságokat, amelyekkel a hozzáférés visszaállítható lenne. Ha ügyfél- vagy beszállítói környezetek is érintettek, kérje a visszavonást azok gazdájától, és őrizze meg a megerősítést.
Rögzítse az egyes eredményeket. Egy csatoló időtúllépése nem sikeres lezárás pusztán azért, mert a teljes feladat lefutott. A hibákat irányítsa egy megnevezett reagálóhoz, alkalmazzon jóváhagyott tartalékmegoldást, és ellenőrizze a végső állapotot. A sürgős, nem rendezett hozzáféréseknek a biztonsági eszkalációs folyamatba kell kerülniük.
Kövesse nyomon minden kiadott eszköz visszaszolgáltatását, átvizsgálását és jóváhagyott visszaállítását vagy selejtezését. Távmunkában dolgozóknál rögzítse a szállítási megoldásokat és a nem rendezett őrzési helyzeteket. Szüntesse meg a fizikai hozzáférést, és szükség esetén szerezze vissza a tokeneket vagy kulcsokat.
Ha a visszaszolgáltatás késik, a szabályzatnak és a kockázatnak megfelelően használja a rendelkezésre álló zárolási vagy törlési kontrollokat. Különböztesse meg a parancs kiadását attól, hogy az eszköz nyugtázta és végrehajtotta azt. Egy offline laptop nem feltétlenül kapja meg a parancsot. A fennmaradó kitettséget a titkosítási állapot, a helyi hitelesítő adatok, a gyorsítótárazott adatok és a rendelkezésre álló hálózati korlátozások alapján értékelje, ahelyett hogy a „törlés sorba állítva” állapotot a törlés bizonyítékaként kezelné.
Jelöljön ki utódot az üzleti dokumentumokhoz, a tárolókhoz, a megosztott munkafolyamatokhoz és a szolgáltatások gazdaságához. Használjon engedélyezett adminisztratív átadási mechanizmusokat, ahelyett hogy valakit arra kérne, hogy a korábbi munkavállaló nevében lépjen fel. A postafiókhoz vagy fájlokhoz való hozzáférést határolja be, rögzítse a célját, és korlátozza a hozzáférést kapó személyek körét.
Válassza szét a hozzáférés visszavonását, a licencek visszaszerzését, a megőrzést és a törlést. Egy licenc eltávolítása alkalmazásonként eltérően befolyásolhatja az adatok elérhetőségét. A visszafordíthatatlan takarítás előtt ellenőrizze a megőrzési követelményeket és az esetleges jogi zárolást.
Személyes adatok esetében a GDPR 5. cikke rögzíti a korlátozott tárolhatóság elvét; nem határoz meg egyetlen általános határidőt a munkavállalói fiókok törlésére. Határozzon meg indokolt megőrzési időket és takarítási felelősségeket. A 32. cikk a kockázatnak megfelelő biztonsági intézkedéseket ír elő, ezért dokumentálja a kiléptetési kontrollok mögötti indoklást, ahelyett hogy egy ellenőrzőlistát önmagában jogi megfelelésként kezelne.
A hasznos rekord összekapcsolja az engedélyezett döntést a megfigyelt eredménnyel. Őrizze meg az eseményt, a jóváhagyást, az érintett rendszereket, a végrehajtási időpontokat, az ellenőrzési eredményeket és a kivételkezelést. Vegye fel a szándékolt hatálybalépési időpontot is, hogy a felülvizsgálók értékelni tudják az időszerűséget.
Egy gyakorlati bizonyítékcsomag tartalmazza:
Egy szabályzat a szándékot mutatja. Egy jegy a koordinációt. Egy alkalmazásbeli eredmény vagy hozzáférési export a megvalósítás igazolását segíti. Egyik sem helyettesítheti a másikat. A képernyőképek hasznosak lehetnek, ha erősebb exportok nem állnak rendelkezésre, de tartalmazzanak elegendő kontextust a rendszer, az alany és a megfigyelés időpontjának azonosításához.
Védje ezeket a rekordokat: foglalkoztatási információkat és biztonsági szempontból érzékeny részleteket tartalmaznak. Alkalmazzon hozzáférési korlátozásokat és megőrzési ütemtervet, és kerülje a jelszavak, a felesleges felmondási leírások vagy teljes postafiókok bizonyítékként való gyűjtését. A korábbi rekordoknak az operatív fiókok törlése után is érthetőnek kell maradniuk.
Vegyünk egy szemléltető vállalatot központi identitásszolgáltatóval, felügyelt laptopokkal és egy helyi jogosultságokat kezelő pénzügyi alkalmazással. Tegyük fel, hogy egy munkavállaló június 1-jén a pénzügyi műveletektől az ügyfélsikerhez kerül át, öt munkanapos átadásra van szüksége, majd szeptember 30-án távozik. Ezek a dátumok és megoldások példaként szolgáló feltételezések, nem előírt időzítések.
Az áthelyezésnél az informatika rögzíti a jelenlegi jogosultságokat. Az ügyfélsiker-hozzáférést jóváhagyják, a pénzügyi írási hozzáférést a hatálybalépés időpontjában visszavonják, a korlátozott pénzügyi olvasási hozzáférést pedig az átadás lejártáig megtartják. A pénzügyi gazda jóváhagyja ezt a kivételt. Mivel a pénzügyi alkalmazás helyi jogosultságokat kezel, rendszergazdája az identitásszolgáltatói csoportfrissítéstől külön hajtja végre és ellenőrzi a módosítást.
A lejáratkor az ellenőrzés azt állapítja meg, hogy egy helyi exportjogosultság megmaradt. Az áthelyezési rekord nyitva marad, a rendszergazda eltávolítja a jogosultságot, a felülvizsgáló pedig rögzíti a végső állapotot. A tanulság konkrét: a szerepkörváltás központilag sikeres volt, de az alkalmazás jogosultsági modellje további műveletet igényelt.
A későbbi távozásnál a folyamat pontos határidőt rögzít, az üzleti fájlokat egy jóváhagyott utódnak adja át, letiltja az identitásokat, visszavonja az érintett munkameneteket és tokeneket, és közvetlenül ellenőrzi a pénzügyi fiókot. A laptop futárral még nem érkezett meg. Visszaszolgáltatása eszközkivételként nyitva marad, a megfékezési intézkedéseket és az eszközmegfigyeléseket pedig a fiókvisszavonástól külön rögzítik.
Az eredményül kapott bizonyítékok a sikeres módosításokat és az eredeti visszavonási hibát is mutatják. A hiba elrejtése éppen azt az információt veszítené el, amely a munkafolyamat javításához szükséges.
Vegyen mintát valós életciklus-eseményekből, és vesse össze őket az alkalmazásleltárral. Vegyen fel alvállalkozókat, kiemelt jogosultságú felhasználókat, távmunkásokat, ideiglenes átfedéssel rendelkező áthelyezetteket és az identitásszolgáltatón kívüli alkalmazásokat. A hozzáférés-felülvizsgálatoknak azt is vizsgálniuk kell, hogy a jelenlegi jogosultságok továbbra is megfelelnek-e az egyes személyek felelősségi köreinek; ezek kiegészítik az eseményvezérelt módosításokat, nem helyettesítik őket.
A szokásos végrehajtás mellett a hibautakat is tesztelje: egy elmaradt HR-eseményt, egy hibás csatolót, egy elérhetetlen rendszergazdát, egy késedelmes eszköz-visszaszolgáltatást vagy egy meghiúsult belépést. Ellenőrizze, hogy a riasztások eljutnak-e egy reagálóhoz, és hogy az újrapróbálkozások vagy manuális műveletek ellenőrizhető eredményeket hoznak-e.
Hasznos mérőszámok a visszavonás késedelme az egyeztetett határidőhöz képest, a rendezésre váró sikertelen műveletek, a lejárt ideiglenes hozzáférések és az ellenőrzés nélkül lezárt események. Határozza meg, mit számolnak az egyes mérőszámok. Egy jó átlag elrejthet egyetlen hosszú ideje fennálló kiemelt jogosultsági kivételt. A megállapítások alapján frissítse a szerepköralapú alapcsomagokat, a csatolók működését, a felelősségi köröket és az eszkalációs szabályokat.
A Secani a felülvizsgálható kontrollrekordot azzal támogathatja, hogy a követelményeket rendszerekhez, felelősökhöz, bizonyítékokhoz és döntésekhez kapcsolja. A fiókmódosításokat tartsa az operatív identitás- és eszközkezelő rendszerekben; a megfelelőségi munkaterületet a hatókör, a feltöltött eredmények, a kivételek és a felülvizsgálati döntések megőrzésére használja. Az MI által támogatott bizonyítéki következtetéseket emberi felülvizsgálóknak kell validálniuk, mielőtt támaszkodnának rájuk.
Kezdjen egy reprezentatív csapattal és egy nemrégiben történt belépéssel, áthelyezéssel és kilépéssel. Kövesse végig az egyes eseményeket az értesítéstől a tényleges rendszerállapotig. Javítsa ki az első feltárt átadási pontot vagy hozzáférési útvonalat, jelölje ki a felelősét, és tesztelje újra, mielőtt kiterjesztené a folyamatot.
A Secani egyetlen közös munkaterületen köti össze a hatóköröket, a bizonyítékokat, a feladatokat és az MI-ügynököket.
Kapcsolja össze a kritikus szolgáltatásokat a helyreállítási célokkal, függőségekkel, gyakorlatokkal és korrekciós intézkedésekkel, hogy a folytonossági tervek a tényleges képességet tükrözzék.
Vizsgálja felül a felhőbeli identitásokat, a kitettséget, a titkosítást, a helyreállítást és a naplózást a tényleges fiókokhoz, szolgáltatásokhoz és adatokhoz kötött bizonyítékokkal.
Ötvözze az ismétlődő műszaki ellenőrzéseket és az időszakos szakmai mérlegelést, egyértelmű lefedettséggel, egészséges adatgyűjtéssel, küszöbértékekkel és a nyomon követés felelőseivel.