permission

| Olvasási idő: 4 perc |

A felhőalapú technológiák rohamos terjedésével egyre nagyobb hangsúlyt kap az erőforrásokhoz való hozzáférés kezelése. Az elmúlt hónapokban már több cikkben is körbejártuk, hogyan épülnek fel a modern felhőarchitektúrák, és milyen eszközökkel tarthatók átláthatóan karban. Most azonban elérkeztünk egy olyan témához, ami nélkül minden korábbi tudás bizonytalan lábakon állna: a hozzáférés-kezeléshez. Ennek egyik legfontosabb pillére az RBAC, vagyis a Role-Based Access Control – magyarul szerepkör-alapú hozzáférés-vezérlés.

Képzeljünk el egy nagyvállalatot, ahol több száz vagy több ezer ember dolgozik különböző projekteken. Nem mindenki férhet hozzá mindenhez – a fejlesztők nem módosíthatják a pénzügyi adatokat, az adminisztrátor viszont nem feltétlenül lát bele az alkalmazás kódjába. Az RBAC éppen ezt a problémát oldja meg: egyértelműen meghatározza, ki mit tehet és mit nem.

Mi az RBAC lényege?

Az RBAC alapelve, hogy a hozzáférési jogokat nem közvetlenül a felhasználókhoz, hanem szerepkörökhöz rendeljük. Ezek a szerepkörök előre definiált engedélyeket tartalmaznak, amelyek meghatározzák, milyen műveletek hajthatók végre adott erőforrásokon.
A felhasználók ezután egy vagy több szerepkört kaphatnak – így az engedélyezés egyszerre lesz átlátható, rugalmas és könnyen kezelhető.

A koncepció három alapeleme:

1. Felhasználók (Users) – azok a személyek vagy szolgáltatások, akik hozzáférnek az erőforrásokhoz.
2. Szerepkörök (Roles) – engedélyek gyűjteménye, például „Reader”, „Contributor” vagy „Owner”.
3. Hozzárendelések (Role Assignments) – ezek kapcsolják össze a felhasználót, a szerepkört és az adott erőforrást.

Hogyan működik az RBAC az Azure-ban?

Az Azure RBAC az Azure Resource Manager (ARM) modellre épül, és segítségével szabályozható, hogy ki milyen műveleteket végezhet el Azure-erőforrásokon – például virtuális gépeken, tárfiókokon, adatbázisokon vagy hálózati elemekben.

Az Azure-ban minden erőforrás hierarchikus struktúrában helyezkedik el:

• Management Group (Felügyeleti csoport) – a legfelső szint, amely több előfizetést is összefoghat.
• Subscription (Előfizetés) – az erőforrások logikai egysége, ahol a számlázás és az erőforrás-kvóták kezelése történik.
• Resource Group (Erőforráscsoport) – az erőforrások rendezésére szolgáló konténer, például egy adott projekt vagy alkalmazás elemei számára.
• Resource (Erőforrás) – az egyes Azure-szolgáltatások, például virtuális gépek, tárfiókok, adatbázisok vagy hálózati elemek.

Egy szerepkör-hozzárendelés bármelyik szinten megadható, és öröklődik a hierarchia alatti szintekre.
Ha például valaki Reader jogot kap egy teljes előfizetés szinten, akkor automatikusan olvashatja az összes erőforráscsoport és erőforrás tartalmát abban az előfizetésben.

RBAC a gyakorlatban (példa)

Képzeljük el, hogy egy fejlesztőcsapat három szereplőből áll:

• Attila, a vezető fejlesztő
• Péter, az infrastruktúra adminisztrátor
• Zoli, a tesztelő

Az IT biztonsági elv szerint mindenkinek csak a munkájához szükséges jogokat adjuk meg.

1. Attila (Contributor) – létrehozhat, módosíthat és törölhet erőforrásokat a fejlesztői Resource Group-ban, de nem kezelheti a hozzáféréseket.
2. Péter (Owner) – teljes körű hozzáféréssel rendelkezik, így módosíthatja a szerepköröket és erőforrásokat is.
3. Zoli (Reader) – csak megtekintheti a fejlesztési környezetben található erőforrásokat, de nem módosíthat semmit.

Ez a megközelítés egyszerre biztonságos és hatékony, hiszen mindenki csak azt látja és azt kezeli, ami a feladata ellátásához szükséges.

RBAC szerepkörök az Azure-ban

Az Azure több mint 120 beépített szerepkört kínál, de a leggyakoribbak közé tartozik:

• Owner – teljes hozzáférés mindenhez, beleértve a hozzáférés-kezelést is.
• Contributor – minden erőforrást módosíthat, de nem kezelheti a jogosultságokat.
• Reader – csak olvasási hozzáféréssel rendelkezik.
• User Access Administrator – mások jogosultságait kezelheti, de magukat az erőforrásokat nem módosíthatja.

Ezen felül lehetőség van egyedi szerepkörök létrehozására is, ha a beépített szerepkörök nem fedik le pontosan a szervezet igényeit.
Egyedi szerepkörök JSON formátumban definiálhatók, és pontosan meghatározható bennük, milyen műveletek engedélyezettek vagy tiltottak.

Az RBAC előnyei

1. Biztonság – Csökkenti a túlzott jogosultságok kockázatát, így kevesebb az emberi hiba vagy jogosulatlan hozzáférés.
2. Átláthatóság – Könnyen ellenőrizhető, ki milyen jogokkal rendelkezik.
3. Skálázhatóság – Nagyvállalati környezetben is egyszerűen kezelhető a jogosultságok bővülése.
4. Automatizálhatóság – A szerepkörök hozzárendelhetők automatizált szkriptekkel vagy Terraform kódokkal is.

Az RBAC korlátai

Bár az RBAC rendkívül hasznos, nem minden esetben elégséges.

• Nem tudja kezelni az adatszintű hozzáféréseket (például egy SQL tábla soraira vonatkozó jogosultságokat).
• A komplex szervezeti hierarchiákban a szerepkörök öröklődése nehezen átláthatóvá válhat.
• Túl sok egyedi szerepkör esetén nő az adminisztrációs teher és a hibalehetőség.

Ezek miatt sok vállalat az RBAC-et kombinálja más megoldásokkal, például Azure AD (EntraID) Conditional Access vagy Privileged Identity Management (PIM) funkciókkal, amelyek ideiglenes vagy feltételes jogosultságkezelést biztosítanak.

Miért hasznos a cégek és felhasználók számára?

A cégek számára az RBAC legnagyobb előnye a kontroll és a biztonság egyensúlya.
Ahelyett, hogy mindenki korlátlanul hozzáférne mindenhez, az RBAC lehetővé teszi, hogy a hozzáférés csak a szükséges mértékben legyen biztosítva.

A felhasználók számára ez azt jelenti, hogy egyértelműen látják, mire jogosultak, és nem kell aggódniuk a véletlen hibák miatt.
Egy fejlesztő például nyugodtan dolgozhat a saját projektjén anélkül, hogy kockáztatná más rendszerek működését.
A rendszergazdák pedig gyorsabban és pontosabban tudják kiosztani az engedélyeket, akár automatizált folyamatokon keresztül is.

Összegzés

A Role-Based Access Control az egyik legfontosabb biztonsági és hatékonysági alapelv a felhőben. Az Azure RBAC egy kifinomult, de logikusan felépített rendszer, amely segít abban, hogy a szervezetek biztonságosan, mégis rugalmasan kezeljék a hozzáféréseket.

Az alapelve egyszerű: mindenkinek csak annyi jogot adjunk, amennyire valóban szüksége van.

Ez a szemlélet nemcsak az Azure-ban, hanem bármely modern informatikai környezetben elengedhetetlen, ahol a bizalom és az ellenőrzés kéz a kézben jár.