mi a szerep-alapú hozzáférés-vezérlés (RBAC)?

A szerep-alapú hozzáférés-vezérlés (RBAC) egy olyan biztonsági paradigma, amely szerint a felhasználók a társaságban betöltött szerepük alapján hozzáférést kapnak az erőforrásokhoz. Az RBAC, ha helyesen hajtják végre, hatékony módja lehet A legkisebb kiváltság elvének érvényesítésére.

a szerep-alapú hozzáférés-vezérlés alapelve egyszerű: a pénzügyi osztály nem látja a HR-adatokat, és fordítva.,

ha helyesen hajtják végre, az RBAC átlátható lesz a felhasználók számára. A szereposztás a színfalak mögött történik, és minden felhasználó hozzáférhet a munkájához szükséges alkalmazásokhoz és adatokhoz.

ebben az útmutatóban részletesebben elmagyarázzuk, mi az RBAC, és megmutatjuk, mikor és hogyan használhatja ezt a paradigmát.,

• az RBAC előnyei
• 5 lépés az RBAC implementációhoz
• RBAC példák
• Azure RBAC
• alternatívák az RBAC

szerep alapú hozzáférés-vezérlés: az alapok

legtöbb RBAC a rendszerek három alapelv alkalmazásán alapulnak. Az egyes szervezetekben alkalmazott módszerek eltérőek lehetnek, de ezek az elvek változatlanok maradnak:

1. Szerepkiosztás: az alany csak akkor gyakorolhat engedélyt, ha a téma kiválasztott vagy hozzárendelt szerepet.,
2. Szerepengedélyezés: az alany aktív szerepét engedélyezni kell. Ez azt jelenti, hogy nem tudok csak hozzárendelni magam egy szerephez. Engedély kell.
3. engedélyezési engedély: az alany csak akkor gyakorolhat engedélyt, ha az engedélyt az alany aktív szerepére engedélyezték. Az 1. és 2. szabályokkal ez a szabály biztosítja, hogy a felhasználók csak azokat az engedélyeket gyakorolhassák, amelyekre jogosultak.

az RBAC fontos a kiberbiztonság szempontjából, mivel az adatok megsértésével kapcsolatos statisztikák azt mutatják, hogy az alkalmazottak számára nem megfelelő szintű hozzáférés biztosítása az adatvesztés és az adatlopás egyik fő oka., Rendszer nélkül annak eldöntésére, hogy ki férhet hozzá az adatokhoz, bizonyos adatokat ki lehet téve.

2019 októberében a kiberbiztonsági kutatók Diachenko és Troia egy olyan adatbarlangot találtak, amely egy nem biztonságos szerveren, amely 4 terabájt PII-t tartalmazott, vagy körülbelül 4 milliárd rekordot. Az összes adatkészletben egyedülálló emberek száma több mint 1, 2 milliárd embert ért el, így ez az egyik legnagyobb adatszivárgás a történelem egyetlen forrásszervezetéből.

a kiszivárgott adatok neveket, e-mail címeket, telefonszámokat, LinkedIn-t és Facebook-profiladatokat tartalmaztak., A felfedezett ElasticSearch szerver, amely tartalmazza az összes információt, nem volt védett, elérhető egy webböngészőn keresztül. Nem volt szükség semmilyen jelszóra vagy hitelesítésre az összes adat eléréséhez vagy letöltéséhez, mert az adatokat tároló szervezetek (két különálló, névtelen adatdúsító cég) nem tettek lépéseket az adatokhoz való hozzáférés korlátozására.

Ez egy szélsőséges példa: a szóban forgó adatoknak egyáltalán nem volt hozzáférési ellenőrzése. Úgy tűnhet, hogy a szervezet soha nem követne el ilyen hibát., A gyakorlatban azonban könnyű hibázni-különösen akkor, ha a kritikus információkat sok helyen tárolják különböző hozzáférés-vezérlési rendszerekkel és egyszerű végfelhasználói megosztási funkciókkal.

az RBAC paradigma végrehajtása nehéz lehet, nagyrészt azért, mert megköveteli, hogy részletesen meghatározza a szervezet összes szerepét, és eldöntse, hogy mely erőforrásokat kell biztosítani az ebben a szerepben dolgozó alkalmazottaknak. A nagy szervezetek sok mozgó alkatrészek, összekapcsolt csapatok, még vázlat egy szervezeti térkép ilyen lehet egy nagy vállalkozás.,

egyes esetekben ez azt jelenti, hogy az RBAC alapját képező döntések szinte “filozófiai” kérdésekké válhatnak.

• a menedzsereik nevében dolgozó asszisztenseknek ugyanolyan szintű hozzáférésre van szükségük?
• amennyiben egy jogi csapat tagja részévé válik a pénzügyi szerepet annak érdekében, hogy hozzáférjen egy részhalmaza fájlok ideiglenesen?
• a biztonsági személyzetnek hozzáférnie kell az összes adathoz, amelyet megpróbál biztosítani?
• ha egy alkalmazottat előléptetnek, örökölnek-e hozzáférési jogosultságokat egy korábbi szerepkörből?
• vagy a junior személyzetnek több hozzáférésre van szüksége, mint a vezetők, akiknek beszámolnak?,

ezekre a kérdésekre adott válaszok rendkívül bonyolultak lehetnek, mivel a szervezet működésének alapvető módjára vonatkoznak. Biztonsági építészként pedig nem valószínű, hogy képes lenne ilyen pán-szervezeti felügyeletre.

ezért itt, a Varonis – ban javasoljuk, hogy ne próbálja meg végrehajtani a “tiszta” RBAC rendszert. Ehelyett azt javasoljuk, hogy olyan hibrid megközelítést használjon, amely magában foglalja az RBAC elveit, de nem támaszkodik ezekre teljesen.,

A szerepkör-alapú hozzáférés-vezérlés előnyei

a legszélesebb szinten az RBAC segít maximalizálni a működési hatékonyságot, megvédi adatait a kiszivárgástól vagy ellopástól, csökkenti az adminisztrációs és informatikai támogató munkát, és megkönnyíti az ellenőrzési követelmények teljesítését.

bár az RBAC nem tökéletes, sokkal jobb modell, mint önkényesen eldönteni, hogy kinek kell hozzáférnie az erőforrásokhoz. Ha van egy jó RBAC végre, a hackerek kap stonewalled, amint megpróbál kijutni a buborék a feltört felhasználó szerepét., Ez drasztikusan csökkentheti a számla kompromisszumának hatását–különösen a ransomware esetében.

még akkor is, ha az érintett felhasználó a HR-ben tartózkodik, és hozzáfér a személyazonosításra alkalmas információkhoz (PII), a hacker nem tudja titkosítani vagy ellopni a pénzügyi csapat vagy a végrehajtó csapat adatait.

az RBAC csökkenti a szervezet adminisztrációs terhelését és növeli a felhasználók termelékenységét. Nem kell minden felhasználó számára személyre szabott engedélyeket kezelnie, a megfelelő felhasználók számára pedig könnyebb elérni a megfelelő adatokat.,

az új felhasználók vagy vendégfelhasználók kezelése időigényes és nehézkes lehet, de ha van RBAC, amely meghatározza ezeket a szerepeket, mielőtt a felhasználó csatlakozik a hálózathoz, ez egy tűz és elfelejti a helyzetet. A vendégek és az új felhasználók csatlakoznak a hálózathoz, és hozzáférésük előre meghatározott.

az RBAC végrehajtása bizonyítottan sok dollárt takarít meg a vállalat számára. Az RTI 2010-ben közzétett egy jelentést, “a szerepalapú hozzáférés-ellenőrzés gazdasági hatása”, amely azt jelzi, hogy az RBAC-rendszerbe történő beruházások jelentős megtérülést mutatnak., Egy hipotetikus pénzügyi szolgáltató cég 10,000 alkalmazottak, RTI becslése szerint RBAC fogja menteni $24,000 a munkaerő, a munkavállalói állásidő fogja megmenteni a cég $ 300,000 évente. A felhasználói hozzáférési folyamat automatizálása még többet takarít meg, mint önmagában a munkaerő-csökkentés.

Végül a vállalatoknak végre RBAC rendszerek megfelelnek a jogszabályi, valamint a törvényi előírások a bizalmas kezelése mert a vezetők, valamint AZ osztályok is hatékonyabban kezelni, hogy az adatok elérni, valamint használt., Ez különösen fontos azon pénzügyi intézmények és egészségügyi vállalatok számára, amelyek érzékeny adatokat kezelnek, és amelyeknek meg kell felelniük a magánélet tiszteletben tartásának.

a megvalósítás végén a hálózat sokkal biztonságosabb lesz, mint volt, az adatok pedig sokkal biztonságosabbak lesznek a lopástól. A termelékenység növelésének egyéb előnyeit pedig a felhasználók és az informatikai személyzet számára is élvezheti. Ez egy nem-agy, ha megkérdezel minket.,

5 lépés a szerepkör-alapú hozzáférés-vezérlés végrehajtásához

az RBAC végrehajtásához a következő lépések szükségesek:

1. határozza meg a felhasználók számára biztosított erőforrásokat és szolgáltatásokat (pl. e-mail, CRM, fájlmegosztások, felhőalkalmazások) .
2. hozzon létre egy leképezést a szerepkörök források lépés 1 úgy, hogy minden funkció elérheti szükséges erőforrásokat a feladat elvégzéséhez.
3. hozzon létre olyan biztonsági csoportokat, amelyek minden szerepet képviselnek.
4. hozzárendelje a felhasználókat meghatározott szerepkörökhöz, hozzáadva azokat a megfelelő szerepkör-alapú csoportokhoz.,
5. csoportokat alkalmazhat a

adatokat tartalmazó erőforrások (pl. mappák, postafiókok, webhelyek) vezérlőlistáinak eléréséhez a jó hír az, hogy nagyrészt ki tudja venni a találgatást ebből a folyamatból. Varonis DatAdvantage betekintést nyújt, aki aktívan használja az adatokat rendszeresen, és aki nem, amely segíthet tájékoztatni szerepteremtés, hozzárendelés. Bármely biztonsági csoport (azaz szerep) vagy adatkészlet adattulajdonosát is kijelölheti a rá nehezedő teher csökkentése érdekében.,

Ez az adat tulajdonosa, aki több összefüggésben az adatokat, mint felelős hozzáférést, az adatok hosszú távú, könnyen jóváhagyja vagy tagadja hozzáférési kérelmek a Varonis DataPrivilege felület. A Varonis modellezési képességeket is biztosít a szerepkörök hozzárendelésekor, így láthatja, mi történik, ha visszavonja a mappához való hozzáférést ebből a szerepkörből, mielőtt elkötelezné magát.

a végrehajtás befejezése után elengedhetetlen, hogy a rendszer tiszta legyen. Egyetlen felhasználónak sem szabad jogosultságokat kiosztani a szerepükön kívül., DataPrivilege lehetővé teszi az ideiglenes hozzáférést fájlmegosztások egy kérés alapján, amely nem szegi meg az első szabályt. Szükség lesz azonban egy változási folyamatra a szerepek szükség szerinti beállításához.

és természetesen rendszeres auditálást és monitorozást szeretne az összes kritikus erőforrásról. Tudnia kell, hogy egy felhasználó megpróbál-e hozzáférni az adatokhoz a kijelölt székhelyén kívül, vagy ha az engedélyt hozzáadják a felhasználóhoz a szerepükön kívül.,

példák szerep-alapú hozzáférés-vezérlésre

RBAC rendszer megvalósításakor hasznos, ha van egy alapvető példa az Ön irányítására. Bár RBAC tűnhet, mint egy bonyolult megközelítés, a valóságban, találkozik RBAC sok általánosan használt rendszerek.

talán a legnyilvánvalóbb példa erre a WordPress CMS felhasználói szerepkörök hierarchiája.,adminisztrációs képességek

más szóval, a WordPress rendszer biztosítja, hogy minden felhasználó szerepe van, amely nem ad nekik túlzott jogok, valamint védi az adatokat hajtunk végre azok a felhasználók, akik nem kell ezt a szerepet., Bár a WordPress nem hivatkozik erre a rendszerre “RBAC” rendszerként, pontosan ez az.

Azure RBAC

Azure role-based access control (Azure RBAC) az Azure RBAC implementációja. Az Azure Resource Manager lehetővé teszi az Azure RBAC alapjainak megvalósítását, valamint a rendszer saját igényeinek megfelelő testreszabását.,

Itt van néhány példa, hogy mit lehet csinálni az Azure RBAC (forrás):

• Lehetővé teszi, hogy egy felhasználó kezelése virtuális gépek egy előfizetés egy másik felhasználó kezelni a virtuális hálózatok
• Lehetővé teszi a DBA csoport kezelni SQL adatbázist előfizetés
• a felhasználó kezelheti az összes erőforrás erőforrás csoport, például virtuális gépek, weboldalak, pedig alhálózat
• Lehetővé teszi az alkalmazás számára az összes erőforrás erőforrás-csoport

Bár Azure RBAC egy népszerű módja a hálózati rendszergazdák végrehajtására RBAC belül a szervezet, ez nem az egyetlen lehetőség áll rendelkezésre., Itt a Varonis – nál általában olyan hibrid megközelítést ajánlunk, amely az Azure RBAC egyes elemeit használja, de ezeket egy szélesebb biztonsági stratégiába integrálja.

alternatívák RBAC

RBAC csak egy megközelítés kezelése hozzáférést a hálózatok, és ez nem helyettesíti az alapos és robusztus biztonsági politika. Mindig használhatja a hozzáférés-vezérlési listákat, de ezeket általában nehéz kezelni, és nem méretezik jól a nagy környezetekkel.,

attribútum alapú hozzáférés-vezérlés

a NIST az attribútum alapú hozzáférés-vezérlést az RBAC mellett definiálja, mint potenciális megoldást a hozzáférési jogok megadására. Röviden, az ABAC arra törekszik, hogy megfeleljen a felhasználó jellemzőinek (job funkció, job title) azokkal az erőforrásokkal, amelyekre a felhasználónak szüksége van a munkájához.

eddig ez a rendszer nem szerzett sok tapadást a rendszer széles körű megvalósításához szükséges kihívások és beállítások miatt. Elméletileg jól hangzik,de még mindig a teher nagy részét kezeli.,

megközelítésünk

sok szervezet számára az RBAC nem kínál elegendő részletességet az Adatvédelmi és szabályozási követelmények támogatásához.

például a több üzleti csoportból származó felhasználók egy kis részhalmaza által megosztott Osztályközi adatok csak az egyes felhasználók számára hozzáférhetők. Az RBAC korlátozza az eredmény elérésének képességét, mivel nem adhat hozzáférést csak egy kiválasztott számú emberhez több Üzleti szerepkörből. Egy szerepkör – alapú csoport alkalmazása egy adatkészletre sértené a legkisebb kiváltság elvét.,

számos megközelítést fogadtak el a probléma megoldására, bár kevés sikerrel. A legtöbb esetben az RBAC elégtelen részletességének megkerülésére tett kísérletek az erőforrás engedélyeit túlzott engedékeny hozzáférés állapotában hagyják, lehetetlenné téve a megfelelés fenntartását és helyesbítését.

a szemcsésebb védelmet igénylő adatok esetében filozófiánk az, hogy az engedélykezelésnek az adatok tartalmán kell alapulnia, nem pedig a hozzáférést igénylő felhasználók funkcionális szerepén., Ezekre a mappákra adatspecifikus biztonsági csoportokat kell létrehozni, és kerülni kell a közvetlen engedélyeket.

például egy szolgáltató cég érzékeny ügyféladatokkal rendelkezhet,amelyek csak bizonyos személyek számára hozzáférhetők. Miután azonosították az adatokat tartalmazó mappákat, az engedélyeket csak egy tartalomspecifikus csoport magánszemélyei számára szabad megadni. A megyei csoportoknak nem szabad engedélyeket hozzárendelni a mappához.,

ezt a megközelítést még tovább is alkalmazhatja, és adatspecifikus csoportokat hozhat létre a szükséges hozzáférési szint alapján:

• SOX_ReadOnly
• SOX_Modify

a Sarbanes-Oxley (SOX) adatok fogyasztói lehetnek néhány kiválasztott felhasználó a jogi, pénzügyi és megfelelőségi csoportokból. Még kevesebb felhasználónak van szüksége az adatok módosítására. Erőforrásspecifikus csoportok létrehozásával csökkentheti a komplexitást, megkönnyítheti az újratervezést, és sokkal könnyebben biztosíthatja a legkisebb kiváltságmodellt.,

A végső szó

az RBAC hatékony paradigma a kritikus adatokhoz és erőforrásokhoz való hozzáférés ellenőrzéséhez, és ha helyesen hajtják végre, drámaian megnövelheti a rendszerek biztonságát.

ne feledje azonban, hogy az RBAC nem csodaszer a kiberbiztonság számára. Számos olyan módszer létezik, amelyet a rossz szereplők illetéktelen hozzáféréshez használnak, és nem szabad kizárólag olyan megelőző ellenőrzésekre támaszkodnia, mint például az RBAC az adatok védelme érdekében., A detektív vezérlők, mint például a felhasználói viselkedés elemzési platform, segíthetnek a szokatlan hozzáférési viselkedés figyelmeztetésében–még akkor is, ha szerepkörre van felhatalmazva–, valamint megakadályozzák az adatok megsértését.