Our S.O.S. line:
+49 89 262 025954
Our team of experts is ready to assist your organization in the event of a cyberattack.
details
Mi történik azokkal a közös mappákkal és csoporttagságokkal, amelyekhez korábban hozzáadták? Maradt-e aktív hozzáférése valamelyik SaaS-szolgáltatásban? Ismer-e olyan közös jelszót, amelyet a kilépése után sem változtattak meg? Volt-e olyan ügyfél- vagy partneroldali hozzáférése, amelynek visszavonásáról nem a saját IT gondoskodik?
Egyetlen bent maradt jogosultság is felesleges kitettséget jelenthet.
A jogosultságkezelés ezért nem egyszerűen arról szól, hogy a belépő munkavállaló hozzáférést kap, a kilépőtől pedig mindent elveszünk. A hozzáféréseket a teljes munkavállalói életciklus során kezelni kell.
Ezt foglalja össze a Joiner–Mover–Leaver, vagyis JML megközelítés.
Új belépő esetén az első kérdés az, hogy milyen rendszerekhez, adatokhoz és funkciókhoz van szüksége a munkaköre ellátásához.
Nem az a cél, hogy „biztos, ami biztos” alapon minél több hozzáférést kapjon, hanem éppen az ellenkezője: csak azt, amelyre valóban szüksége van. Ez a least privilege és a need to know elvek gyakorlati megvalósítása.
Egy pénzügyi munkatársnak például szüksége lehet az ERP pénzügyi moduljához való hozzáférésre, de ettől még nem indokolt, hogy HR-adatokat vagy technikai adminisztrációs felületeket is elérjen.
Ezt nagyban megkönnyítheti az RBAC, vagyis a szerepkör-alapú hozzáférés-kezelés. Ha a szervezet előre meghatározza, hogy egy adott munkakörhöz milyen alapjogosultságok tartoznak, az új belépők hozzáférése gyorsabban, következetesebben és auditálhatóbb módon alakítható ki.
A jogosultságkezelés egyik leggyakoribb gyenge pontja nem a belépés vagy a kilépés, hanem a kettő közötti időszak.
Tegyük fel, hogy egy munkatárs projektkoordinátorból vezetői pozícióba kerül. Új feladataihoz további rendszerekhez kap hozzáférést, vezetői riportokat lát, jóváhagyási jogokat kap.
De mi történik a korábbi jogosultságaival?
Ha a szervezet csak hozzáadja az új hozzáféréseket, de nem vizsgálja felül a régieket, idővel kialakul az úgynevezett privilege creep, vagyis a jogosultságok fokozatos felhalmozódása.
Ugyanez történhet projektek lezárásakor is. Egy munkatárs fél évre hozzáférést kap egy érzékeny ügyfélprojekthez, közös mappákhoz vagy akár külső rendszerekhez. A projekt véget ér, a hozzáférések azonban változatlanul megmaradnak.
Ez akkor is kockázat, ha a munkatárs teljesen megbízható. Ha ugyanis a felhasználói fiókját kompromittálják, a támadó ugyanazokat a hozzáféréseket kapja meg, amelyekkel ő rendelkezik.
Minél több felesleges jogosultság marad aktív, annál nagyobb lehet egy incidens hatása.
Kilépő munkatárs esetén a hozzáférések visszavonásának gyorsnak, teljes körűnek és igazolhatónak kell lennie.
A fő vállalati fiók letiltása fontos, de önmagában nem feltétlenül elegendő.
Érdemes felülvizsgálni:
Különösen fontos ez a privilegizált felhasználóknál. Egy rendszergazda nemcsak a saját fiókjával rendelkezhet magas szintű hozzáféréssel, hanem ismerhet szolgáltatásfiókokhoz, hálózati eszközökhöz vagy közös adminisztratív hozzáférésekhez tartozó hitelesítő adatokat is. Ilyenkor a kilépési folyamatnak azt is vizsgálnia kell, szükséges-e jelszavak vagy kulcsok cseréje.
A jogosultsági életciklus nemcsak munkavállalókra vonatkozik.
Beszállítók, tanácsadók és külső fejlesztők gyakran időszakos hozzáférést kapnak belső rendszerekhez. Tipikus példa, amikor egy külső fejlesztő egy projekthez adminisztratív hozzáférést kap, de a projekt lezárása után a fiókja aktív marad.
Éppen ezért a külsős hozzáféréseknél különösen hasznos az időkorlátos jogosultság, a kijelölt belső felelős és a projekt lezárásához kötött kötelező felülvizsgálat.
A hozzáférések rendszeres ellenőrzése nem a munkavállalókkal szembeni bizalmatlanságról szól.
A legkisebb jogosultság elvének célja, hogy minden felhasználó csak ahhoz férjen hozzá, ami a feladataihoz szükséges, és csak addig, amíg erre valóban szükség van.
A jogosultságokat ezért rendszeresen felül kell vizsgálni. Ez történhet évente, magasabb kockázatú rendszerek vagy privilegizált felhasználók esetében akár gyakrabban is.
Érdemes külön vizsgálni:
A felülvizsgálat eredménye legyen dokumentált: ki ellenőrizte, milyen eltérés merült fel, milyen hozzáférést vontak vissza, és ki hagyta jóvá a módosítást.
Ez nemcsak a biztonságot növeli, hanem audit során is bizonyíthatóvá teszi a kontroll működését.
A jogosultságmódosítások naplózása emellett detektálási kontrollként is használható. Ha például egy átlagos felhasználó váratlanul adminisztrátori jogot kap, vagy érzékeny adatokhoz hozzáférést biztosító csoportba kerül, az már önmagában vizsgálatra érdemes esemény lehet.
A jól működő jogosultságkezeléshez nem feltétlenül bonyolult rendszerre van szükség. A lényeg az, hogy a teljes életciklus követhető és visszaellenőrizhető legyen.
Ehhez érdemes kialakítani:
A jó jogosultságkezelés végső soron három egyszerű kérdésre ad választ:
Ha a harmadik kérdésre nincs egyértelmű válasz, akkor valószínűleg ideje felülvizsgálni a jogosultságot.
A White Hat IT Security a jogosultsági életciklushoz kapcsolódó folyamatok kialakításában és felülvizsgálatában is támogatást nyújt. Segítünk többek között a hozzáférési megállapodások, a belépési és kilépési jogosultságkezelési folyamatok, a munkakörváltáshoz kapcsolódó felülvizsgálatok, valamint az éves jogosultság-felülvizsgálati nyilvántartások kialakításában.
A cél nem több adminisztráció, hanem az, hogy minden jogosultságnak legyen oka, felelőse és kontrollált életciklusa – és ezt a szervezet bármikor bizonyítani is tudja.
Jogosultságkezelési kérdésekben is számíthat GRC csapatunkra! Irányítási, kockázatkezelési és megfelelőségi szolgáltatások | White Hat IT Security
Az Ügyészség nevében érkezik a levél, de ransomware van mögötte. Elemeztük az országot körbejáró legújabb zsarlóvírus támadást és elkészítettük a visszafejtő programot, aminek segítségével bárki fizetés nélkül visszaállíthatja fájljait. Űrlap a visszafejtő program letöltéséhez Frissítés: Azonosítottuk, hogy a kampány során [...]
