// KIBERBIZTONSÁGI KISOKOS · 05. MODUL

Legkisebb jogosultság — mindenki csak annyit, amennyi kell

Q: Mi a különbség a legkisebb jogosultság és a zero trust között?

A legkisebb jogosultság (least privilege) egy alapelv: mindenki csak annyi hozzáférést kapjon, amennyi a feladatához feltétlenül kell. A zero trust ennél tágabb biztonsági szemlélet: alapból semmiben és senkiben nem bízunk meg automatikusan, minden hozzáférést újra és újra ellenőrzünk (felhasználó, eszköz, kontextus). A legkisebb jogosultság a zero trust egyik építőköve — a zero trust gyakorlatilag a least privilege folyamatos, dinamikus érvényesítése.

Q: Túl bonyolult ez egy kis cégnek?

Nem. Egy kis cégnél a legtöbb érték néhány lépésből jön: legyen lista arról, kinek van admin-joga; vond vissza a jogokat kilépéskor még aznap; és kapcsold be az MFA-t a kritikus fiókokra. Drága eszköz nélkül, egy egyszerű táblázattal is el lehet kezdeni. A bonyolultabb megoldások (RBAC-rendszer, PAM) később, a növekedéssel jönnek.

Q: Mi az a privilégium-kúszás (privilege creep)?

A privilégium-kúszás az, amikor egy munkatárs az évek során egyre több hozzáférést gyűjt (új projektek, áthelyezések, ideiglenes megbízások miatt), de a régi, már nem szükséges jogait soha nem vonják vissza. Így csendben túl tág hozzáférése lesz — ami egy ellopott fiók esetén nagyobb kárt tesz lehetővé. A rendszeres jogosultság-felülvizsgálat épp ezt akadályozza meg.

C · I kb. 6 perc olvasás

A legkisebb jogosultság (least privilege) elve egyetlen mondatban összefoglalható: mindenki csak annyi hozzáférést kapjon, amennyi a munkájához feltétlenül szükséges — se többet. A felesleges jog nem kényelem, hanem nyitva felejtett ajtó. Ez a modul megmutatja, miért ez a hozzáférés-kezelés gerince, és hogyan vezeted be egy kis cégnél is, drága eszközök nélkül.

Hogyan vezesd be? → Gyors önellenőrzés Vissza a Kisokoshoz

1 · Laikusan

Mi a legkisebb jogosultság?

A legkisebb jogosultság (least privilege) azt mondja ki, hogy minden ember és minden program csak annyi hozzáférést kapjon, amennyi a feladatához feltétlenül kell — és semmivel sem többet. A rokon fogalom a need-to-know elv: csak az lássa az adatot, akinek a munkájához tényleg szüksége van rá.

Képzeld el egy irodaház kulcsaival Egy jól vezetett irodaházban mindenki csak azokat a kulcsokat kapja meg, amelyekre a munkájához szüksége van. A takarító bejut az irodákba, hogy kitakarítson — de nem kap kulcsot a páncélteremhez, ahol a pénz és a szerződések állnak. A könyvelő bejut a páncélterembe, de nem kap kulcsot a szerverszobához. Senki nem kap egy „mindenhová nyitó" mesterkulcsot csak azért, mert így kényelmesebb. Ha valakitől ellopnák a kulcscsomóját, az csak annyi ajtót nyitna, amennyi azon a csomón van — nem az egész házat.

A digitális világban a „kulcs" a hozzáférési jogosultság: ki tud belépni a könyvelőprogramba, ki látja a béradatokat, ki telepíthet szoftvert a gépekre. Ennek rendezett kezelésére használják a RBACRBAC (szerepkör-alapú hozzáférés, Role-Based Access Control): nem emberenként, hanem szerepkörönként (pl. „könyvelő", „raktáros") adsz jogokat. Aki abba a szerepkörbe kerül, automatikusan a szerepkörhöz tartozó hozzáféréseket kapja. modellt: nem fejenként osztogatsz jogokat, hanem szerepkörökhöz (könyvelő, raktáros, ügyvezető) rendeled őket. A leggyakoribb buktató pedig a privilégium-kúszás (privilege creep): valaki az évek során egyre több jogot gyűjt, de a régieket soha nem veszik el tőle.

2 · A gyakorlatban

Miért NIS2-szempont?

A hozzáférés-kezelés a kockázatkezelési intézkedések visszatérő, hangsúlyos eleme — szinte minden biztonsági keretrendszer és a NIS2-felkészülés is elvárja valamilyen formában. A legkisebb jogosultság ennek a gyakorlati magja: nem új eszközt jelent, hanem fegyelmezett rendet a meglévő jogosultságokban.

Mi ez?

Az az elv, hogy minden felhasználó, fiók és program a lehető legszűkebb hozzáférést kapja, amivel a feladata még elvégezhető. A jogokat szerepkörhöz kötöd (RBAC), és rendszeresen felülvizsgálod, hogy ne maradjon felesleges hozzáférés.

Miért NIS2-kötelező elem?

A NIS2-t átültető szabályozás kockázatarányos intézkedéseket vár el, és ezek között a hozzáférés-kezelés rendre kiemelt helyen szerepel. A pontos elvárás a szervezet érintettségétől függ — itt szándékosan nem idézünk konkrét paragrafust; az értelmezés mindig egyedi.

Hogyan segít?

Ha mindenki csak a szükséges jogokat kapja, egy ellopott jelszó vagy egy megfertőzött gép sokkal kevesebb kárt tud okozni — nem terjed tovább az egész rendszerre. A legkisebb jogosultság így egyszerre csökkenti a támadási felületet és a hiba „robbanási sugarát".

Mi felkészítünk, nem mi auditálunk. Ez az oldal általános tájékoztatás, nem jogi tanácsadás és nem hatósági állásfoglalás. A kötelező, független megfelelőségi auditot a Szabályozott Tevékenységek Felügyeleti Hatósága (SZTFH) által nyilvántartásba vett auditor végzi, külön díjért — ezt nem helyettesítjük. A jogszabályi adatok a tájékoztatás időpontjában (2026. június) hatályos állapotot tükrözik.

2 · A gyakorlatban

Hogyan vezesd be? — hat lépés

Nem kell hozzá drága rendszer; egy táblázattal és némi fegyelemmel el lehet kezdeni. A lényeg, hogy a hozzáférés-kezelés ne ad-hoc döntés legyen, hanem ismételhető folyamat.

Szerepkörök leltára

Vedd számba, milyen munkakörök vannak a cégben, és mihez kell ténylegesen hozzáférniük. Pl. „könyvelő", „raktáros", „ügyvezető", „külsős fejlesztő".

„Ki mihez fér hozzá" mátrix

Készíts egy egyszerű táblázatot: soronként emberek vagy szerepkörök, oszloponként rendszerek és adatok. Töltsd ki, ki mihez fér hozzá ma — gyakran ez maga a leleplező pillanat.

Felesleges jogok visszavonása

Nézd meg, hol fér valaki hozzá olyasmihez, ami a munkájához nem indokolt — és vond vissza. Itt számolod fel a felgyűlt privilégium-kúszást.

MFA a kritikus hozzáférésekre

Az admin- és érzékeny hozzáférésekre tedd kötelezővé a MFA-tMFA (többfaktoros hitelesítés): a jelszó mellett egy második bizonyíték (pl. telefonos kód vagy alkalmazás) kell a belépéshez. Önmagában a jelszó ellopása így nem elég a támadónak.. A szűk jogosultság és az erős hitelesítés együtt sokkal többet ér, mint külön-külön.

Belépés–áthelyezés–kilépés folyamat

Rögzítsd, mi történik a hozzáférésekkel, amikor valaki belép, más szerepkörbe kerül vagy kilép (joiner-mover-leaver). A kilépő munkatárs jogait még aznap vissza kell vonni.

Rendszeres jogosultság-felülvizsgálat

Időközönként (pl. negyedévente vagy félévente) nézd át újra a mátrixot, és vond vissza, ami már nem indokolt. Ez tartja kordában a csendben szivárgó jogokat.

3 · Technikai mélység

Ha mélyebbre ásnál

Az alábbiak az IT-felelősnek szólnak — a laikus olvasó nyugodtan átugorhatja, az elv megértéséhez nem szükséges.

PoLP vs. zero standing privilege

A klasszikus PoLP (Principle of Least Privilege) azt mondja: legyen mindenkinek minimális, de állandó jogosultsága. A modernebb cél a zero standing privilege: alaphelyzetben senkinek ne legyen állandó emelt jogosultsága. Vagyis az admin-jog ne „ott üljön" folyamatosan egy fiókon, hanem csak akkor és annyi időre keletkezzen, amikor egy konkrét feladathoz tényleg kell. Így egy ellopott fiók a támadás pillanatában jellemzően nem rendelkezik emelt joggal — nincs mit kihasználnia.

Just-in-time (JIT) hozzáférés

A just-in-time hozzáférés a zero standing privilege gyakorlati megvalósítása: az emelt jogot a felhasználó csak akkor és csak addig kapja meg, amíg az adott feladathoz szükséges — jóváhagyás vagy automatikus szabály alapján, majd a jog magától lejár. Ennek a jegyzőkönyve (ki, mikor, mire kért emelt jogot) egyúttal kiváló audit-nyomot is ad. A JIT különösen az adminisztrátori és a kritikus rendszer-hozzáféréseknél hoz nagy kockázatcsökkenést.

Privilegizált fiókok (PAM) és service account-ok

A PAMPAM (Privileged Access Management): a kiemelt jogú — jellemzően admin — fiókok kezelésére szolgáló megközelítés és eszközkör: jelszó-széf, hozzáférés-jóváhagyás, munkamenet-naplózás. (Privileged Access Management) a kiemelt jogú fiókok rendezett kezelése: a jelszavak széfben állnak, az emelt hozzáférést jóvá kell hagyni, és a munkamenetek naplózódnak. Külön figyelmet érdemelnek a service account-ok (gép–gép kapcsolatokhoz, automatikus folyamatokhoz tartozó technikai fiókok): ezek gyakran túl tág jogot kapnak, soha nem cserélik a jelszavukat, és senki nem érzi a sajátjának — ezért kedvelt célpontok. Ugyanúgy vonatkozik rájuk a legkisebb jogosultság elve: szűk hatókör, dokumentált tulajdonos, rendszeres felülvizsgálat.

2 · A gyakorlatban

Gyors önellenőrzés

Három kérdés, amit ma fel tudsz tenni magadnak — nincs eszköz, nincs regisztráció. Ha bármelyikre „nem" vagy „nem tudom" a válasz, ott van a következő lépésed.

1 · Admin-lista

Van-e naprakész listátok arról, kinek van admin- (rendszergazdai) joga a céges rendszerekben? Ha fejből nem tudod megmondani, valószínűleg többen vannak, mint kellene.

2 · Kilépés még aznap

Egy kilépő munkatárs hozzáféréseit visszavonjátok-e még aznap (e-mail, fájlok, rendszerek, VPN)? A „majd a jövő héten" hozzáférés a leggyakoribb néma rés.

3 · Felesleges jogok

Mikor néztétek át utoljára, hogy ki mihez fér hozzá, és van-e olyan, akinek a munkájához már nem indokolt a hozzáférése? Ha „még soha", ott gyűlik a privilégium-kúszás.

1 · Laikusan

Gyakori tévhit

Tévhit

„Kényelmesebb, ha mindenki admin — kevesebb a vesződség."

Rövid távon kényelmesebb, hosszú távon veszélyes. A zsarolóvírusok és a betörések kárának nagy része épp a túl tág jogokon terjed tovább: ha egy fertőzött gépnek vagy ellopott fióknak mindenhez hozzáférése van, a támadó egyetlen rést kihasználva az egész rendszert el tudja érni. A szűk jogosultság olyan, mint a tűzgátló fal: nem akadályozza meg a kezdeti hibát, de megállítja a továbbterjedését.

Gyakori kérdések

GYIK a legkisebb jogosultságról

Mi a különbség a least privilege és a zero trust között?

A legkisebb jogosultság egy alapelv: mindenki csak annyi hozzáférést kapjon, amennyi a feladatához kell. A zero trust ennél tágabb szemlélet: alapból semmiben és senkiben nem bízunk meg automatikusan, minden hozzáférést újra ellenőrzünk (felhasználó, eszköz, kontextus). A least privilege a zero trust egyik építőköve — a zero trust gyakorlatilag a legkisebb jogosultság folyamatos, dinamikus érvényesítése.

Túl bonyolult ez egy kis cégnek?

Nem. A legtöbb érték néhány egyszerű lépésből jön: legyen lista arról, kinek van admin-joga; vond vissza a hozzáféréseket kilépéskor még aznap; és kapcsold be az MFA-t a kritikus fiókokra. Mindez drága eszköz nélkül, egy táblázattal is elindítható. A bonyolultabb megoldások (RBAC-rendszer, PAM) később, a növekedéssel jönnek.

Mi az a privilégium-kúszás (privilege creep)?

Az, amikor valaki az évek során egyre több hozzáférést gyűjt (új projektek, áthelyezések, ideiglenes megbízások miatt), de a régi, már nem szükséges jogait soha nem vonják vissza. Így csendben túl tág hozzáférése lesz — ami egy ellopott fiók esetén nagyobb kárt tesz lehetővé. A rendszeres jogosultság-felülvizsgálat épp ezt akadályozza meg.

Miért épp az admin-jogokra kell a legjobban figyelni?

Az adminisztrátori (rendszergazdai) hozzáférés szinte mindenhez hozzáfér: telepíthet, törölhet, jogosultságot oszthat, kikapcsolhat védelmet. Ha egy ilyen fiók támadó kezébe kerül, a kár jóval nagyobb, mint egy átlagos felhasználói fióknál. Ezért érdemes az admin-jogokat a lehető legkevesebb emberre szűkíteni, MFA-val védeni, és csak akkor használni, amikor tényleg szükség van rá.

← Előző modul A CIA triász Következő modul → Hálózati zónák, szegmentáció, tűzfalak

Következő lépés

Megvan az elv — hol szivárog a hozzáférésetek?

A jogosultságok rendbetétele szervezeti munka, amit magadnak kell elvégezned — de a technikai réseket (kitett bejelentkező felületek, hiányzó biztonsági fejlécek, gyenge konfiguráció) egy ingyenes szivárgás-audit pár perc alatt megmutatja, konkrétan a saját domained alapján. Jó kiindulópont, mielőtt belevágsz.

Indíts ingyenes auditot → NIS2 felkészülés-csomagok Vissza a Kisokoshoz