Az AI/MI jelenlegi állapota – dióhéjban

A mesterséges intelligencia minden munkahelyet elvesz, mindenkit levált, minden munkát ellát. Vagy mégsem. Mint a „jereváni rádió”…

A mesterséges intelligencia ma már nem egyetlen technológia, hanem egymásra épülő rendszerek ökoszisztémája. A legfontosabb irányok: nagy nyelvi modellek (LLM-ek), képgeneráló modellek, beszédfelismerés és -szintézis, prediktív analitika, valamint ipari gépi látás. Ezek többsége érett, stabil technológia, amelyet világszerte napi szinten használnak – nem kísérleti státuszban, hanem termelésben.

A megvalósított projektek globálisan már a teljes vállalati működést lefedik: automatizált ügyfélszolgálat, dokumentumfeldolgozás, minőségellenőrzés, logisztikai optimalizálás, kódgenerálás, marketingautomatizáció, HR‑szűrés, pénzügyi előrejelzés. Magyarországon a nagyvállalatok (bankok, telekom, energetika, gyártás) már alkalmazzák ezeket, míg a KKV‑szektor lassabban, főként költségérzékenység miatt.

A jelenlegi MI-ökoszisztéma fő irányai és alkalmazási területei 2026-ban az MI már nem különálló eszköz, hanem a rendszerek, folyamatok és eszközök alaprétege. A legfontosabb irányok:

• Generatív AI és specializált alapmodellek: Az általános nagy nyelvi modellek (LLM) mellett egyre inkább teret nyernek az iparágakra, üzleti területekre szabott, specializált AI-megoldások. Ezek nemcsak szöveget generálnak, hanem konkrét üzleti feladatokat (pl. dokumentumfeldolgozás, döntéstámogatás, kockázatelemzés) is elvégzenek, és természetes nyelven kommunikálnak a felhasználókkal.
• Automatizáció és AI-ügynökök: Az AI-ügynökök (autonóm, önállóan működő rendszerek) már nem csak egyszerű feladatokat automatizálnak, hanem teljes folyamatláncokat kezelnek – például HR, pénzügy, beszerzés területén. Ezek a „digitális kollégák” képesek dokumentumokat feldolgozni, döntéseket előkészíteni, vagy akár utazásokat szervezni, így jelentősen csökkentik az adminisztratív terheket és költségeket.
• Prediktív és döntéstámogató rendszerek: Az MI segít előrejelezni a piaci trendeket, optimalizálni a gyártási folyamatokat, vagy akár a klímaváltozáshoz való alkalmazkodást. Magyarországon is kiemelt területek a precíziós gazdálkodás, a logisztika és az ellátási láncok hatékonyabbá tétele, valamint az egészségügyi döntéstámogatás.
• Digitális ikrek és szimulációk: Az ipari szektorban egyre elterjedtebb a digitális iker technológia, amely valós idejű adatokon alapuló szimulációkkal segíti a gyártás, energia és élettudományok területén a döntéseket, csökkenti a hibák számát és a költségeket.

MI-megoldások átlagos gazdasági társaságok számára Magyarországon a költségtudatos kisvállalatok számára is elérhetőek és hasznosíthatóak az alábbi technológiák:

• Automatizált adminisztráció és dokumentumkezelés: RPA (Robotic Process Automation) és NLP (Natural Language Processing) alapú rendszerek képesek az ismétlődő, szabályalapú feladatok (adatbevitel, számlázás, időpont-egyeztetés, egyszerű ügyfélszolgálati lekérdezések) automatizálására. Ez 15–40%-os költségcsökkenést és hatékonyságnövekedést eredményezhet, minimális technikai előfeltétellel.
• Ügyfélszolgálat és marketing: AI-alapú chatbotok és ügynökök képesek az ügyfélkapcsolatok kezelésére (azért itt még kevés az igazán jó példa…), személyre szabott ajánlatok készítésére, vagy akár marketingkampányok optimalizálására. Ezek a megoldások már nem csak nagyvállalatoknak, hanem kisvállalkozásoknak is elérhetőek, pl. felhőalapon, előfizetési modellben.
• Adatelemzés és döntéstámogatás: Az MI segít a vállalatoknak a saját adataik elemzésében, például az eladásokat, költségeket, vagy a termékek profitabilitását illetően. Ez lehetővé teszi, hogy másodpercek alatt kapjanak válaszokat olyan kérdésekre, mint „Melyik termék hozza a legtöbb profitot télen?”.
• Felhőalapú és nyílt forráskódú megoldások: Olyan eszközök, mint az n8n (automatizáció), vagy a Gamma (prezentációk generálása), lehetővé teszik, hogy kisvállalatok is saját szerveren, vagy felhőben futtassanak AI-alapú workflow-okat, anélkül, hogy drága infrastruktúrába kellene beruháznia.

Kisvállalati alkalmazások

• Átlagos cégnél a chatbotok (pl. ügyfélszolgálat), a tartalomgenerálás (marketing szövegek) és adatanalízis (értékesítési előrejelzés) működik stabilan, felhős alapokon (pl. Google Cloud, Azure). Kisvállalatnál (költségfókusz) ingyenes/open-source eszközök: ChatGPT Enterprise, Hugging Face modellek riportokhoz, automatizációhoz (Zapier+MI) hozhatnak némi időmegtakarítást.

Adatbiztonság

• Az adatbiztonság az MI-rendszerekben kulcsfontosságú, különösen a GDPR és az EU AI Act előírásai miatt, amelyek kockázat alapú megközelítést írnak elő. Kisvállalatoknál az érzékeny adatok (pl. ügyféladatok) védelme érdekében titkosítás, hozzáférés-vezérlés és audit logok elengedhetetlenek.
• Felhős rendszerek
• A felhős megoldások skálázhatók és automatikusan frissülnek biztonsági patch-ekkel, központi védelemmel (pl. zero-trust modell). Hátrányuk: adatok tárolása harmadik félnél kockázatot jelent, bár a szolgáltatók SLA-kkal garantálnak magas biztonságú elérhetőséget és megfelelőséget.
• Helyi telepítésű rendszerek
• Helyi (on-premise/edge) rendszerek teljes adatvezérlést adnak, nincs külső adatátvitel, ideális érzékeny iparágakban (pl. gyártás, jog, egészségügy,…). Előny: alacsony latency, offline működés; hátrány: magas kezdeti költség, manuális frissítések és szakértői karbantartás szükséges. Kisvállalatoknál hibrid modell ajánlott: kritikus adatok helyben, rutin feladatok felhőben.

Előfeltételek és költségek Az MI-bevezetés fő előfeltételei:

• Adatminőség és infrastruktúra: Az MI csak akkor működik hatékonyan, ha minőségi, strukturált adatok állnak rendelkezésre, és a vállalat rendelkezik megfelelő IT-alapokkal (pl. felhőszolgáltatások, biztonságos adatkezelés).
• Szaktudás és képzés: Nem feltétlenül szükséges mély MI-szakértelem, de a dolgozóknak ismerniük kell az eszközök lehetőségeit és korlátait. Sok esetben elegendő az alapvető digitális kompetenciák fejlesztése, vagy akár külső tanácsadás igénybevétele.
• Költségek: A legtöbb felhőalapú vagy előfizetési modellű megoldás már alacsony havi költségekkel (néhány tízezer forinttól) elérhető, és a befektetés általában 6–12 hónap alatt megtérül a hatékonyságnövekedés és költségcsökkenés révén.

Összefoglaló 2026-ban az MI már nem luxus, hanem szükségszerűség a versenyképesség fenntartásához. A kisvállalatok is beépíthetik a mindennapi működésükbe az automatizációt, az ügyfélszolgálatot, az adatelemzést és a döntéstámogatást segítő rendszereket, költséghatékonyan és skálázhatóan. A siker kulcsa a megfelelő adatbázis, a stabil IT-infrastruktúra és a dolgozók képzése. Azok a cégek, amelyek időben felkészülnek, nemcsak technológiai, hanem üzleti előnyt is szerezhetnek a versenytársaikkal szemben.

Szóval, akkor elvesz minden munkát?

Igen, kivéve, ha például a gyümölcsfáimat kell metszeni, az autón téli gumit cserélni, ablakot mosni, … DE! Jó hír is van: alvállalkozhatunk a mesterséges intelligenciának ilyen munkákra!

A RentAHuman.ai egy kísérleti online platform, ahol mesterséges intelligencia‑ügynökök „bérelhetnek” valódi embereket fizikai, valós világban elvégzendő feladatokra. A szolgáltatás célja, hogy az AI‑rendszerek olyan tevékenységeket is végrehajthassanak, amelyekhez emberi jelenlét szükséges.

Röviden, miről szól a RentAHuman.ai?

• AI‑ügynökök valós embereket fogadhatnak fel különféle fizikai feladatokra – például helyszíni ellenőrzésre, vásárlásra, fotózásra vagy bármilyen olyan tevékenységre, amit egy AI önmagában nem tud elvégezni.
• A platformon emberek regisztrálhatnak „bérelhetőként”, óradíjjal, profilképpel és rövid bemutatkozással.
• A projektet Alexander Liteplo fejlesztő indította, és induláskor már több száz – később tízezres nagyságrendű – regisztrált felhasználót jelentettek.
• A koncepció lényege: „a robotok nem tudnak kimenni a valóságba – de te igen”, így az AI‑ügynökök egyetlen technikai hívással delegálhatnak feladatot egy embernek.

Miért érdekes?

A RentAHuman.ai egy új, határfeszegető modell: nem az emberek bérelnek AI‑t, hanem az AI bérel embereket. Ez a megközelítés a jövőben új típusú ember–AI együttműködést alapozhat meg, különösen ott, ahol a fizikai jelenlét továbbra is nélkülözhetetlen.

Azaz: változatlanul én metszem a gyümölcsfáimat, nekem kell megoldanom a téli gumi cserét és az ablakmosását is.

Az MI rendszer meg közben majd ír verset, zenét és fest képeket… ??

nuce.hu

A NIS2-re való felkészülés egyik sarkalatos kérdése a szervezeten belül az elektronikus információs rendszerek (EIR) pontos azonosítása. Elég fontos kérdés önmagában is, de az 1/2025. SZTFH rendelet (a kiberbiztonsági audit lefolytatásának rendjéről és a kiberbiztonsági audit legmagasabb díjáról) óta, ez már konkrétan zsebre is megy.

A kötelezett szervezetek audit díjának meghatározásában egyik igen fontos paraméter a szervezet elektronikus információs rendszereinek darabszáma. Öt darab EIR-ig az SZTFH-képlet vonatkozó szorzószáma egyes, hat EIR-nél már 2.5-es. Minden más paraméter (szorzószám) azonossága mellett ez az egy döntés, az audit -egyébként sem olcsó- díját akár 2.5-szeresére is emelheti!

Azaz, érdemes alaposan átgondolni a szervezet elektronikus információs rendszereinek kérdését.

Sajnos ez a cikk sem fogja tudni megmondani a pontos választ minden kérdésre, ez nem is lehet a célunk, hiszen az EIR-ek azonosítása tekintetében is igaz az „attól függ”.

Az elmúlt néhány évtized auditálásai során láttuk is, és el is mondtuk, mondjuk azóta is a legfontosabbat: minden szervezet más! Mindenhol egyedi sajátosságok, paraméterek alapján lehet és kell eldönteni nagyon sok ilyen kérdést. Ezeknek a kérdéseknek a feltevésében próbálunk meg most segítséget nyújtani.

Csak dióhéjban. In nuce…

Definíciók

Először is a jogszabály (2024. évi LXIX. törvény Magyarország kiberbiztonságáról) szerint az elektronikus információs rendszer:

1. az elektronikus hírközlésről szóló törvény szerinti elektronikus hírközlési hálózat,
2. minden olyan eszköz vagy egymással összekapcsolt vagy kapcsolatban álló eszközök csoportja, amelyek közül egy vagy több valamely program alapján digitális adatok automatizált kezelését végzi, ideértve a kiber-fizikai rendszereket, vagy
3. az a) és b) alpontban szereplő elemek által működésük, használatuk, védelmük és karbantartásuk céljából tárolt, kezelt, visszakeresett vagy továbbított digitális adatok.

Csak megjegyzés: az EU 2022/2555-ös (NIS 2) irányelve a „hálózati és információs rendszer” fogalmat használja, többé-kevésbé a fenti hármas definícióval.

Egy igen komoly segítség található Az információbiztonság alapjai kiadvány 1.2. fejezetében, Dr. Muha Lajostól:

„Fontos, hogy összhangban a rendszerelmélettel, valóban rendszerről és ne berendezések, eszközök valamiféle halmazáról beszéljünk. Ludwig von Bertalanffy szerint: „A rendszer egymással kölcsönhatásban álló elemek olyan együttese, amelyre bizonyos rendszertörvények alkalmazhatók. Az elem a rendszer olyan része, összetevője, amelyet az egész vizsgálata érdekében célszerű megkülönböztetni.” Ezek az elemek:

Információs rendszer az adatok, információk kezelésére használt eszközök (környezeti infrastruktúra, hardver, hálózat és adathordozók), eljárások (szabályozás, szoftver és kapcsolódó folyamatok), valamint az ezeket kezelő személyek együttese.

Az információs rendszerekhez tartoznak:

1. a számítástechnikai rendszerek és hálózatok, ideértve az internet szolgáltatást is;
2. a helyhez kötött, mobil és egyéb rádiófrekvenciás, valamint műholdas elektronikus hírközlési hálózatok, szolgáltatások;
3. a vezetékes, a rádiófrekvenciás és műholdas műsorszórás;
4. a rádiós vagy műholdas navigációs rendszerek;
5. az automatizálási, vezérlési és ellenőrzési rendszerek (vezérlő és adatgyűjtő, távmérő, távérzékelő és telemetriai rendszerek stb.);
6. a fentiek felderítéséhez, lehallgatásához vagy zavarásához használható rendszerek.”

Önállóság

Az önálló elektronikus információs rendszer tehát olyan informatikai rendszer, amely önállóan képes bizonyos funkciók ellátására, és amely különáll más rendszerektől biztonsági, szervezeti vagy funkcionális szempontból. Az önállóságot több tényező határozza meg, például a rendeltetés, a tulajdonviszony, a felügyeleti struktúra vagy a technológiai függetlenség, tehát az önálló elektronikus információs rendszer fogalma nem technikai, hanem üzleti-funkcionális és biztonsági szempontból értelmezhető.

Az önálló rendszer jellemzői:

1. Célhoz kötött: Egy meghatározott üzleti célhoz, szolgáltatáshoz, folyamathoz kötődik.
2. Technológiai integráció: A rendszer technikailag összefüggő, közös működési logikát vagy platformot használ.
3. Kockázati szempontból különálló: Ha a rendszer biztonsági kockázatai, fenyegetettségei és sérülékenységei külön kezelendők.
4. Üzemeltetési szempontból elhatárolható: Ha a rendszer önállóan fejleszthető, frissíthető, auditálható, akkor külön veendő.

Mit lehet egyben kezelni?

Több informatikai rendszert egy rendszerként lehet kezelni, ha:

• Ugyanazt a szolgáltatást támogatják (pl. egy webáruház frontendje + backend + adatbázis)
• Együttesen működnek (pl. mikroszolgáltatásos architektúrában több komponens, de ugyanazt a szolgáltatást nyújtják)
• Funkcionálisan összetartozó egységet alkotnak (pl. egy vállalat belső HR rendszere, amely több alrendszerből áll, de együttműködik)
• Ugyanaz a kockázati profiljuk, és egyetlen eseménykezelési rendszer alá esnek (pl. egy e-kereskedelmi platform fizetési rendszere és raktárkezelője, ha ugyanaz a csapat felügyeli)
• Közös biztonsági irányítás alatt állnak (pl. egy felhőalapú ERP rendszer különböző moduljai, egy egészségügyi intézmény betegregisztrációs és receptíró rendszere, ha egy adatvédelmi szabályzat vonatkozik rájuk)
• Ugyanaz a jogi entitás felelős érte (pl. egy bank online banking rendszere és mobilalkalmazása).

Mit kell külön venni?

Külön rendszerként kell kezelni azokat, amelyek:

• Más célú szolgáltatásokat, különálló feladatokat támogatnak (pl. HR rendszer vs. ERP vs. webshop, egy logisztikai nyomkövető rendszer vs. egy termelési tervező szoftver)
• Más felelősségi körhöz tartoznak (pl. külön üzletág vagy szolgáltató kezeli)
• Más biztonsági osztályba tartoznak (pl. egyik nyilvános, másik szigorúan védett)
• Különböző célú, nem összekapcsolt rendszerek, más infrastruktúrán futnak, nincs közvetlen adatcsere (pl. egy kórház betegadat-kezelő rendszere és a pénzügyi szoftvere, két különálló adatbázis, amelyek nem kommunikálnak egymással)
• Függetlenül működnek és külön biztonsági szabályzat vonatkozik rájuk (pl. egy önkormányzat közúti kamerarendszere és a közigazgatási dokumentumkezelője)
• Különböző jogi felelősség alá tartoznak (pl. egy leányvállalat informatikai rendszere és anyavállalaté, egy egyetem hallgatói portálja vs. kutatói adattárháza).

Fontos a NIS2 szempontjából

A NIS2 kiemelt hangsúlyt fektet a kritikus fontosságú rendszerek azonosítására. Ha egy rendszer önállóan kritikus funkciót lát el (pl. energiaszolgáltató SCADA rendszere), akkor külön kockázatértékelés és biztonsági intézkedések szükségesek, még ha más rendszerekkel együtt is üzemel.

Mindenképpen kiemelendő még, hogy nem csak az EIR-ek szempontjából, de nagyon sok egyéb szempontból is (például GDPR) minden ilyen döntés alapja a kockázatelemzés és az üzleti hatáselemzés. Csak ezek alapján tudunk megalapozott döntéseket hozni (és azt a döntést adott esetben hatékonyan megvédeni!) az elektronikus információs rendszerek besorolásáról (is).

Néhány kérdés az elektronikus információs rendszerek önállóságának értékeléséhez (NIS2 szerint)

Az alábbi kérdések segítenek eldönteni, hogy egy rendszer önálló-e, vagy integráltnak tekinthető más rendszerekkel: 

1. Szervezeti és irányítási szempontok

• Ugyanaz a jogi entitás (pl. vállalat, intézmény) felelős a rendszer üzemeltetéséért? Ha nem, valószínűleg külön rendszer (pl. külső beszállító rendszere).
• Ugyanaz a belső csapat vagy osztály felügyeli a rendszert? Ha külön csapatok kezelik (pl. IT és termelés), inkább önálló.
• Más információbiztonsági osztályba vagy kockázati kategóriába tartozik, mint a többi rendszer? Igen esetén önálló rendszerként kell kezelni.
• Külön biztonsági szabályzat és kockázatkezelési terv vonatkozik rá? Ha igen, önálló rendszernek minősül.

2. Funkcionális és technikai összefüggések

• A rendszer különálló feladatot lát el, vagy szorosan kapcsolódik más rendszerek működéséhez? Pl. egy logisztikai nyomkövető vs. pénzügyi számlázó – eltérő cél = önálló.
• Önállóan is működőképes a rendszer, vagy csak egy másik rendszerrel együtt működik? Ha csak egy másik rendszerrel együtt működőképes, nem biztos, hogy önálló.
• Közvetlen adatcsere történik más rendszerekkel? Ha igen, milyen gyakran és mennyire automatizált? Minél kevésbé integrált, annál inkább önálló (pl. kézi adatátvitel vs. valós időben szinkronizált API).
• Független infrastruktúrán (szerver, hálózat, felhő) fut, vagy megosztott erőforrásokat használ? Pl. két rendszer ugyanazon az AWS-fiókban vs. fizikailag elkülönített adatközpontokban.
• A felhős szolgáltatásunk milyen konstrukcióban van? Pl. IaaS, Paas, SaaS? Mi mennyire lehetünk hatással a konfigurálásokra, hozzáférésekre, mentésekre, üzleti folyamatok beállítására stb.

3. Biztonsági és jogi megfontolások

• A rendszer kockázatai függetlenek más rendszerektől? Pl. egy kórház betegadat-rendszerének megszegése nem érinti a lámpákat vezérlő IoT eszközöket.
• Külön adatvédelmi vagy szabályozási követelmények vonatkoznak rá? Pl. GDPR-ra kötelezett CRM vs. ipari vezérlőrendszer, amelyre más szabványok érvényesek.
• Ha egy rendszer meghibásodik, az hatással van más rendszerekre? A rendszer kiesése önállóan is kockázatot jelent az üzletmenetre? Ha nincs láncreakció (pl. egy e-mail szerver leállása nem befolyásolja a gyártási robotokat), önálló. Ha igen, önállónak értelmezhető.

4. Üzleti folyamatok és tulajdonviszony

• Külön üzleti folyamat része? Ha eltérő üzleti célt szolgál, valószínűleg önálló.Pl. egy webshop rendeléskezelője vs. szállítói beszerzési rendszer – más folyamatok = önálló.
• Külső partner vagy saját fejlesztésű rendszerről van szó? Külső SaaS megoldások (pl. Salesforce) gyakran függetlenek a belső rendszerektől.
• Más-más szolgáltatási szintet (SLA-t) biztosítanak a rendszerekre? Eltérő SLA különállóságra utal.
• Elkülönített frissítési/fenntartási időszakokkal rendelkezik? Ha a karbantartás nem érint más rendszereket (pl. külön karbantartási ablakok), önálló.

Kérdéses

A végére csak néhány kérdés:

• Ha a szervezet alkalmazottja a szervezet elektromos autójával (ami „digitális adatok automatizált kezelését végzi”) szervezeti dokumentumokat szállít, akkor az elektromos autót, azt a szervezet elektronikus információs rendszerei közé kell sorolnunk?
• A céges kamerarendszer a szervezet EIR-jei közé tartozik, akkor is, ha ugyan a szervezet épületében van felszerelve, a szervezet látogatóit, munkatársait rögzíti, de nem a szervezet üzemelteti?
• A Microsoft 365 rendszerei szervezeti EIR-nek minősülnek-e, hiszen igen korlátozottak a beállításaikkal/adatkezeléseikkel kapcsolatos lehetőségei a felhasználó szervezeteknek?

A válasz mindegyikre azonos: attól függ…

nuce.hu

Az Európai Unió Általános Adatvédelmi Rendeletének (GDPR) 32. cikke az adatkezelés biztonságára vonatkozó követelményeket határozza meg. Ez a cikk kulcsfontosságú az adatvédelmi megfelelés szempontjából, mivel előírja, hogy az adatkezelőknek és adatfeldolgozóknak megfelelő technikai és szervezési intézkedéseket kell bevezetniük a személyes adatok védelme érdekében. A GDPR hazai bevezetésében közreműködő jogászok ennek a megvalósításáig általában nem jutnak el, és nem véletlenül.

Kockázatalapú megközelítés

A GDPR 32. cikke kockázatalapú megközelítést alkalmaz. Ez azt jelenti, hogy az adatkezelőknek és adatfeldolgozóknak figyelembe kell venniük többek között:

• a technológia aktuális állását,
• a megvalósítás költségeit,
• az adatkezelés jellegét, hatókörét, körülményeit és céljait,
• valamint a természetes személyek jogaira és szabadságaira jelentett kockázat valószínűségét és súlyosságát.

Ezek alapján kell meghatározniuk és megvalósítaniuk a megfelelő biztonsági intézkedéseket.

Ajánlott technikai és szervezési intézkedések

A 32. cikk példákat is felsorol az alkalmazható intézkedésekre:

• a személyes adatok álnevesítése és titkosítása,
• a feldolgozási rendszerek és szolgáltatások folyamatos bizalmasságának, integritásának, rendelkezésre állásának és ellenálló képességének biztosítása,
• a személyes adatokhoz való hozzáférés és rendelkezésre állás gyors helyreállításának képessége fizikai vagy technikai incidens esetén,
• a biztonsági intézkedések hatékonyságának rendszeres tesztelése, értékelése és felülvizsgálata.

Felelősségi körök

Az adatkezelőnek és az adatfeldolgozónak biztosítania kell, hogy minden olyan természetes személy, aki az ő irányításuk alatt jár el és hozzáfér a személyes adatokhoz, csak az adatkezelő utasításai alapján kezelheti azokat, kivéve, ha az uniós vagy tagállami jog másként írja elő.

Gyakorlati tanácsok a megfeleléshez

A GDPR 32. cikkének való megfelelés érdekében az alábbi lépések ajánlottak:

1. Kockázatértékelés elvégzése: Azonosítsa és értékelje a személyes adatok kezelésével kapcsolatos kockázatokat.
2. Megfelelő intézkedések bevezetése: Alkalmazzon technikai és szervezési intézkedéseket, mint például titkosítás, hozzáférés-szabályozás és rendszeres biztonsági tesztelés.
3. Dokumentáció: Rögzítse az összes biztonsági intézkedést és azok hatékonyságának értékelését.
4. Munkavállalók képzése: Biztosítsa, hogy minden érintett munkatárs tisztában legyen az adatvédelmi kötelezettségekkel és a biztonsági protokollokkal.
5. Rendszeres felülvizsgálat: Évente vagy jelentős változások esetén vizsgálja felül és frissítse a biztonsági intézkedéseket.

A 32. cikk betartása nemcsak jogi kötelezettség, hanem alapvető lépés a személyes adatok védelme és az adatkezelés biztonságának biztosítása érdekében.

nuce.hu

Az Európai Unió 2025 tavaszán nagyszabású felülvizsgálatot indított az Általános Adatvédelmi Rendelet (GDPR) kapcsán, különös tekintettel a kis- és középvállalkozások (KKV-k) adminisztratív terheinek csökkentésére. A változások célja, hogy egyszerűsítsék a jelenlegi szabályokat, amelyek sok vállalkozás szerint túl bonyolultak és költségesek.

A Bizottság javaslata szerint a kevesebb mint 750 alkalmazottat foglalkoztató szervezetek számára enyhítenék a dokumentációs és nyilvántartási kötelezettségeket. Az ígéretek szerint ez csökkentené a vállalkozásokra nehezedő adminisztratív terheket, és javítaná versenyképességüket a globális piacon.

Ugyanakkor a felülvizsgálattal kapcsolatban több aggály is felmerült. Adatvédelmi szakértők és civil szervezetek attól tartanak, hogy a szabályok lazítása gyengítheti a magánszemélyek adatainak védelmét. Felhívják a figyelmet arra, hogy a GDPR épp azért vált nemzetközi szinten is mércévé, mert szigorúan védi az egyének jogait – ennek felvizezése hosszú távon visszaüthet.

További aggodalomra ad okot, hogy az egységes adatvédelmi elveket a tagállamok eltérően értelmezhetik, ami gyengítheti a rendelet egységét. Az Európai Adatvédelmi Testület (EDPB) ezért javasolta, hogy a tagállami adatvédelmi hatóságok gyakorlatát rendszeresen értékeljék, hogy elkerülhetők legyenek a jelentős eltérések.

A változtatással kapcsolatos aggályokat 108 szervezet közös nyílt levélben jelezte. Ezek szerint a javasolt változtatások azzal a kockázattal járnak, hogy nem érik el a valódi egyszerűsítés célját, és ehelyett a kulcsfontosságú elszámoltathatósági biztosítékokat, és velük együtt magát az elszámoltathatósági elvet is visszavonhatják.

Az újratárgyalás után a GDPR sebezhetővé válhat a szélesebb körű deregulációs igényekkel szemben. Számos ilyen nyomás már látható, beleértve a hozzájárulásra vonatkozó szabályok gyengítésére irányuló felhívásokat a felhasználók számára hatékony biztosítékok nélkül, vagy a személyes adatok mesterséges intelligencia-képzéshez való erőszakos felhasználásának legitimálását.

A nyílt levélben a geopolitikai kontextust is megemlítik. Az elmúlt években a külföldi kereskedelmi és politikai szereplők az EU digitális védelmének lazítására irányuló felhívásai következetesen a GDPR gyengítésére irányuló kísérletekkel kezdődtek, amely stratégia mára kiterjedt az egész EU technológiai szabálykönyvére, beleértve a digitális szolgáltatásokról szóló törvényt (DSA), a digitális piacról szóló törvényt (DMA) és a mesterséges intelligencia törvényt (AI Act) – és már folyamatban van a vállalati elszámoltathatóság és a környezeti igazságosság terén.

A GDPR hivatalos újraértékelésére 2027-ben kerül sor, de a 2025-ös reformcsomag már most is jelentős hatással lehet az adatkezelés európai jövőjére. A kihívás az, hogy megtaláljuk az egyensúlyt a vállalkozások adminisztratív terheinek csökkentése és a személyes adatok védelmének szavatolása között.

A változások végleges formája még kérdéses, de az biztos: a GDPR korszakának következő fejezete már elkezdődött.

nuce.hu

Az előttünk álló időszakban a NIS 2 hazai bevezetésével kapcsolatban a legfontosabb kihívások és legsürgősebb feladatok az alábbiak lehetnek:

1. Auditokra való felkészülés

• Határidő: Az első kötelező auditok határideje sok szervezetnél 2025. december 31., így a nyár kulcsidőszak a felkészüléshez.

• Szakemberhiány: Kevés az auditor és a felkészült, hozzáértő tanácsadó, ezért már most nehéz időpontokat foglalni. Akik késlekednek, azok nem biztos, hogy teljesíteni tudják a törvényi határidőt.

2. Rendszer- és folyamatfejlesztés

• Hiányos IT-biztonsági rendszerek: Számos érintett szervezetnél nincsenek megfelelő kockázatkezelési és incidens-reakciós mechanizmusok.

• Dokumentáció hiány: A szabályozás részletes IT-biztonsági dokumentációt vár el, amit sok szervezetnek most kell kialakítania, kiegészítenie.

3. Tudatosság és vezetői felelősség

• Menedzsment felkészítése: A vezetői felelősség hangsúlyosabb lett, így a felsővezetők oktatása, bevonása sürgető feladat.

• Belső oktatás: A munkavállalók kiberbiztonsági tudatossága még mindig alacsony – a nyár ideális időszak lehet belső képzésekre.

4. Kapcsolattartás a hatóságokkal

• SZTFH iránymutatások követése: A Szabályozott Tevékenységek Felügyeleti Hatósága (SZTFH) folyamatosan ad ki új tájékoztatókat – ezek nyomon követése és beépítése a gyakorlatba kulcsfontosságú.

• Nyilvántartásba vétel és megfelelés igazolása: Akik még nem regisztráltak, haladéktalanul pótolniuk kell.

Összegzés:

A nyár döntő időszak lesz a megfelelés szempontjából. Aki most nem kezd bele komolyan a felkészülésbe – különösen az audit lebonyolításához szükséges feltételek megteremtésébe – komoly bírságokat és működési kockázatokat vállal.

nuce.hu

Az Európai Unió jelenleg fontolgatja a 2018-ban életbe lépett Általános Adatvédelmi Rendelet (GDPR) jelentős módosítását. Ursula von der Leyen, az Európai Bizottság elnöke vezetésével a Bizottság a GDPR egyszerűsítését célzó javaslat benyújtását tervezi a következő hetekben. Ennek célja az adminisztratív terhek csökkentése és az európai vállalkozások, különösen a kis- és középvállalkozások versenyképességének növelése.

A GDPR-t Európa egyik legösszetettebb jogszabályának tekinti a technológiai szektor, amely a 2018-as bevezetése óta igen komoly felfordulást okozott. Most, hét évvel később Brüsszel előveszi az ollót, hogy finomítsa a híres-hírhedt adatvédelmi törvényét.

Michael McGrath ír EU-biztos megerősítette, hogy a GDPR módosítása szerepel egy közelgő omnibusz jogalkotási csomagban, amelynek célja a szabályozási terhek enyhítése. Kiemelte, hogy különösen a kis- és középvállalkozásokra vonatkozó nyilvántartási kötelezettségek felülvizsgálata van napirenden.

Az elmúlt időszakban egyes kritikusok, mint például Caroline Stage Olsen dán digitális miniszter és Mario Draghi volt olasz miniszterelnök, aggodalmukat fejezték ki a GDPR összetettsége miatt, amely szerintük akadályozza az üzleti hatékonyságot és a gazdasági növekedést. Fontos azonban megjegyezni, hogy a GDPR a személyes adatok védelmének globális mércéjévé vált, így bármilyen gyengítésére irányuló kísérlet erős ellenállásba ütközhet.

"Sok jó dolog van a GDPR-ban, és az adatvédelem teljes mértékben szükséges. De nem kell ostoba módon szabályoznunk. Meg kell könnyítenünk a vállalkozások és a vállalatok számára, hogy megfeleljenek" - mondta Caroline Stage Olsen dán digitális miniszter a múlt héten újságíróknak. 2025 második felében Dánia elnököl az EU Tanácsában, soros elnöksége részeként.

A Bizottság korábban közölte, hogy az egyszerűsítési terv az 500 főnél kevesebbet foglalkoztató szervezetek jelentéstételi követelményeire fog összpontosítani, de nem érinti „a GDPR-rendszer alapvető célkitűzését”.

McGrath a múlt héten megerősítette, hogy a GDPR egyszerűsítésére vonatkozó javaslat az elkövetkező hetekben esedékes. A Bizottság azt tervezte, hogy a Bizottság ütemterve szerint április 16-ra állapodik meg a kis- és középvállalkozások úgynevezett egyszerűsítési csomagjáról, de ezt a dátumot azóta május 21-re tolták.

A módosítások részletei és azok véglegesítése még kidolgozás alatt állnak, és a következő hetekben várhatóak további információk a tervezett változtatásokról.

nuce.hu

A BlackLock ransomware-csoport, más néven "El Dorado" vagy "Eldorado", 2024 márciusában jelent meg a kiberbűnözés színterén. Azóta tevékenységük drámai növekedést mutatott: 2024 utolsó negyedévében 1425%-os emelkedést regisztráltak az adatközlési bejegyzéseik számában az előző negyedévhez képest. Ez a gyors terjeszkedés aggodalmat keltett a kiberbiztonsági szakértők körében, akik attól tartottak, hogy a BlackLock 2025-ben a legdominánsabb ransomware-szolgáltatóvá válhat.

A BlackLock sajátosságai és működési módszerei

A BlackLock egyik fő megkülönböztető jegye, hogy saját fejlesztésű malware-t használ, szemben más csoportokkal, amelyek kiszivárgott ransomware-készítőket alkalmaznak. Ez a megközelítés megnehezíti a biztonsági kutatók számára a kártevő elemzését és az ellene való védekezést. A csoport Windows, VMware ESXi és Linux rendszereket céloz meg, bár a Linux változat kevésbé fejlett.

A BlackLock kettős zsarolási taktikát alkalmaz: nemcsak titkosítja az áldozatok adatait, hanem ellopja azokat, majd a nyilvánosságra hozatallal fenyegetőzik, ha nem teljesítik a váltságdíj követeléseit. Adatközlő oldaluk (Data Leak Site - DLS) fejlett funkciókkal rendelkezik, amelyek megnehezítik a kutatók és az áldozatok számára a kiszivárgott adatokhoz való hozzáférést és azok elemzését. Ez a stratégia fokozza a nyomást az áldozatokon, hogy gyorsan fizessenek, mielőtt teljes mértékben felmérhetnék a károkat.

A Resecurity beavatkozása és eredményei

A Resecurity kiberbiztonsági vállalat szakértői felfedeztek egy sebezhetőséget a BlackLock DLS oldalán a TOR hálózaton. Ezt kihasználva hozzáfértek a csoport belső infrastruktúrájához, és értékes információkat gyűjtöttek tevékenységükről, beleértve a hálózati infrastruktúrát, a bejelentkezési időpontokat, valamint a MEGA fájlmegosztó fiókokat, amelyeket az ellopott adatok tárolására használtak. Ez az áttörés lehetővé tette a szakértők számára, hogy előre jelezzék és megelőzzék a csoport által tervezett támadásokat, valamint figyelmeztessék a potenciális áldozatokat.

2025 február 10-ig a Resecurity 46 áldozatot azonosított, akik különböző szektorokban tevékenykedtek, beleértve az elektronikát, az akadémiai intézményeket, vallási szervezeteket, védelmi ipart, egészségügyet, technológiát, IT/MSP szolgáltatókat és kormányzati ügynökségeket. Az érintett szervezetek olyan országokban működtek, mint Argentína, Aruba, Brazília, Kanada, Kongó, Horvátország, Peru, Franciaország, Olaszország, Spanyolország, Hollandia, Egyesült Államok, Egyesült Királyság és az Egyesült Arab Emírségek.

A BlackLock működési stratégiája és toborzási módszerei

A BlackLock aktívan jelen van a RAMP nevű orosz nyelvű kiberbűnözői fórumon, ahol "traffereket" toboroznak a támadások korai szakaszában való részvételre, beleértve a rosszindulatú forgalom irányítását és a kezdeti hozzáférés megszerzését. A fejlesztői és programozói pozíciók betöltése diszkrétebben történik, ami nagyobb bizalmat és hosszú távú elköteleződést igényel. Érdekes módon az affiliate toborzás gyakran megelőzi a jelentősebb támadási hullámokat, ami tudatos stratégiára utal.

Technikai részletek és támadási módszerek

A BlackLock támadásai több szakaszból állnak:

1. Kezdeti kompromittálás: Adathalász e-mailek, rosszindulatú mellékletek vagy kompromittált RDP hitelesítő adatok segítségével jutnak be a hálózatba.
2. Oldalirányú mozgás: Legális adminisztrációs eszközöket, például PowerShellt és PsExec-et használnak a hálózaton belüli mozgáshoz.
3. Jogosultság kiterjesztése: Hitelesítő adatok ellopásával magasabb szintű hozzáférést szereznek a kritikus rendszerekhez.
4. Adatexfiltráció: Az érzékeny adatok ellopása a titkosítás előtt, hogy növeljék a zsarolás hatékonyságát.

A BlackLock az El Dorado Ransomware márkaváltásaként ismert. A Resecurity szerint ugyanazok a szereplők több más prominens projekthez is köthetők, köztük a Mamona Ransomware-hez. Az utolsó projekt sem tartott sokáig. Karol Paciorek, a CSIRT KNF munkatársa azonosította a Mamona DLS lehetséges clearnet IP-jét, ami pánikot keltett a leányvállalatok körében.

A BlackLock és a Mamona Ransomware is offline állapotba került, és jelenleg nem érhetők el. Nevezetesen egy másik prominens zsarolóvírus-csoport, a DragonForce vette át a vezetést, kihasználva ezeket az eseményeket. A Resecurity kiemelte, hogy lehetséges, hogy a DragonForce átveszi a BlackLock affiliate bázisát, és a csoport sikeresen átáll az új irányítókra.

nuce.hu

NIS2 esettanulmány: Fiktív Gépgyártó Kft.

1. Cég bemutatása A Fiktív Gépgyártó Kft. egy közepes méretű vállalat, amely ipari gépek és alkatrészek gyártásával foglalkozik. A cég ISO 9001 és ISO 27001 tanúsítvánnyal rendelkezik, mely biztosítja a minőségi gyártást és az információbiztonságot. 200 alkalmazottja közül többen az informatikai és biztonsági rendszerek fenntartásért felelősek. A vállalat rendelkezik egy webshoppal is, ahol pótalkatrészeket és kisebb berendezéseket értékesít.
2. GAP elemzés eredményei A NIS2 irányelvnek való megfelelés érdekében a Fiktív Gépgyártó Kft. GAP elemzést végzett, amely során az alábbi fő hiányosságok derültek ki:

• Szabályzatok hiánya: Az információbiztonsági szabályzatok elavultak, és nem fedik le teljes mértékben a kiberbiztonsági fenyegetéseket.
• Oktatás hiánya: Az alkalmazottak nem kapnak rendszeres kiberbiztonsági képzést, ami növeli a belső fenyegetések kockázatát.
• Biztonsági szoftverek frissítésének hiánya: A meglévő végpontvédelmi rendszerek nem mindig naprakészek, ami sebezhetővé teszi a céget.
• Titkosítás gyengeségei: Az adatok titkosítása nem teljeskörű, és nem felel meg a mai biztonsági előírásoknak.

3. Javasolt lépések a megfelelés érdekében A cég vezetése az alábbi cselekvési tervet fogadta el:

• Szabályzatok frissítése: Egy NIS2-kompatibilis információbiztonsági szabályzat-rendszer kidolgozása, amely kiterjed a kockázatelemzésre, incidenskezelésre és adatvédelemre.
• Oktatási program bevezetése: Rendszeres és többrétegű (vezetői/alkalmazotti/informatikai személyzeti) kiberbiztonsági oktatások szervezése minden alkalmazott számára, beleértve a phishing-tesztek és tudatosító kampányok indítását.
• Biztonsági szoftverek frissítése: Naprakész tűzfalak, behatolásvédelmi rendszerek és végpontvédelmi szoftverek beszerzése és telepítése.
• Titkosítás erősítése: Minden érzékeny adat titkosítása erős és hatékony technológiákkal, és a titkosított kommunikáció bevezetése az online tranzakciókhoz.

4. Várt eredmények A fent említett lépések végrehajtásával a Fiktív Gépgyártó Kft.:

• Javítja a kiberbiztonsági megfelelését a NIS2 irányelv szerint.
• Csökkenti az adatszivárgások és kibertámadások kockázatát.
• Erősíti az alkalmazottak tudatosságát a biztonsági kockázatokkal kapcsolatban.
• Biztonságosabb online és belső informatikai rendszert hoz létre.

A fejlesztések és végrehajtott módosítások lehetővé teszik a cég számára, hogy megfeleljen az európai úniós szabályozásoknak, miközben védi üzleti adatait és informatikai rendszereit a mai és jövőbeni fenyegetésekkel szemben.

 nuce.hu

A 2024. évi LXIX. törvény Magyarország kiberbiztonságáról, jogszabályba emelte többek között az adatosztályozás kötelezettségét is.

Most az ehhez kapcsolódó fontosabb feladatokat és folyamatokat próbáljuk meg az alábbiakban dióhéjban (in nuce) áttekinteni.

Először is fontos tisztázni, hogy az adatosztályozás fogalma nem új keletű, de annak jogszabályba emelése nagyon fontos lépés. Adatosztályozás természetesen nagyon sok szempont szerint és metodikával történhet, de amit a hazai jogszabályok megfogalmaznak, azok közül a legfontosabbak az alábbiak:

1. 2024. évi LXIX. törvény Magyarország kiberbiztonságáról,

• „adatosztályozás: a szervezet által az elektronikus információs rendszerben kezelt adatok és információk biztonsági besorolása azok bizalmasságának, sértetlenségének és rendelkezésre állásának szempontjából;”
• „Az adatosztályozás során figyelembe kell venni a logikailag együtt, egységben kezelt elektronikus adatok – ideértve az adatbázist, adattárat, egyedi dokumentumot és egyéb adatállományt – együttes biztonsági igényét.”

2. 418/2024. (XII. 23.) Korm. rendelet Magyarország kiberbiztonságáról szóló törvény végrehajtásáról

• melléklet „Az adatosztályozás végrehajtásához irányadó szempontok”: célok meghatározása, szempontok az adatok bizalmasság szerinti besorolására, az adatok sértetlenség és rendelkezésre állás szerinti értékelésére, és a besorolás utáni legfontosabb teendőkre.

Fontos: „A nemzeti kiberbiztonsági hatóság az adatosztályozást és a biztonsági osztályba sorolást felülbírálhatja, és indokolt esetben magasabb vagy alacsonyabb szintű besorolást is megállapíthat.”

Itt is ki kell emelnünk: minden szervezet más, mindenhol más típusú adatokat kezelnek, rengeteg különböző struktúrában mind technikailag (adatbázisok, nem strukturált adatok, célrendszerek, OT, felhő, stb.), mind szervezetileg (felelősségek, adatgazdák, stb.). Ennek figyelembevételével az alábbiakban megpróbáljuk összefoglalni, hogy nézhet ki az adatosztályozás folyamata, és mik lehetnek a legfontosabb szempontok.

1. Azonosítás és leltárkészítés

• Az összes szervezeti adat azonosítása.
• Adatforrások, rendszerek és adatfolyamok feltérképezése.

2. Osztályozási kritériumok meghatározása

Az adatok osztályozása általában a következő tényezők alapján történik:

• Bizalmasság: Az adatok nyilvánosságra kerülése milyen hatással lehet a szervezetre vagy érintettekre?
• Integritás: Milyen hatással lenne az adatok módosítása vagy megváltoztatása?
• Rendelkezésre állás: Milyen következményei lennének az adatok elvesztésének vagy elérhetetlenné válásának?
• Jogszabályi megfelelés: Milyen jogi vagy szabályozási követelmények vonatkoznak az adatra (pl. GDPR, iparági szabályok)?
• Érzékenység: Az adat tartalmaz-e bizalmas vagy személyes információt?

3. Adatok kategorizálása

A szervezetek gyakran a következő kategóriákat használják az adatok védelmi szintjének meghatározására:

• Nyilvános adatok: Bárki számára elérhető adatok (pl. weboldalak, sajtóközlemények).
• Belső használatra szánt adatok: Csak a szervezet belső munkatársai számára elérhetők (pl. üzleti tervekre vonatkozó információk).
• Bizalmas adatok: Korlátozott hozzáféréssel rendelkező, érzékeny adatok (pl. ügyféladatok, pénzügyi adatok).
• Kritikus/erősen bizalmas adatok: Olyan adatok, amelyek nyilvánosságra kerülése súlyos károkat okozhat (pl. egészségügyi adatok, szerződések, belső fejlesztési dokumentáció, kutatási adatok).

4. Védelmi intézkedések hozzárendelése

Az osztályozás után minden adatkategóriához megfelelő védelmi intézkedéseket kell hozzárendelni:

• Hozzáférés-szabályozás: Ki férhet hozzá az adatokhoz?
• Titkosítás: Adatok tárolása és továbbítása során alkalmazott védelem.
• Biztonsági mentések: Adatok helyreállíthatóságának biztosítása.
• Monitorozás és naplózás: Gyanús tevékenységek észlelése.

5. Folyamatos ellenőrzés és frissítés

Az osztályozást rendszeresen felül kell vizsgálni, és frissíteni kell a változó üzleti és szabályozási környezethez igazodva.

2. Szempontok az adatosztályozás során

Az adatosztályozás során érdemes a következő szempontokat is figyelembe venni:

• Szabályozási megfelelés: Az adatkezelési szabályzatnak összhangban kell lennie a kibertörvény, a NIS2 előírásaival és egyéb vonatkozó jogszabályokkal.
• Kockázatalapú megközelítés: Az adatok értéke és a kockázatok alapján kell meghatározni a védelmi szinteket.
• Incidenskezelés: Az adatvesztési vagy támadási forgatókönyvek elemzése és az ehhez szükséges védelem kialakítása.
• Hozzáférés-kezelés: Biztosítani kell, hogy csak a megfelelő személyek férhessenek hozzá az adatokhoz.
• Adathozzáférési naplózás: A felhasználói tevékenységek nyomon követése, hogy az esetleges incidenseket vissza lehessen vezetni.

Összegzés

Az adatosztályozás egy strukturált folyamat, amely segít az adatok biztonsági védelmének megfelelő kialakításában. Az adatok osztályozását az üzleti kockázatok, a jogszabályi követelmények és az adat érzékenysége alapján kell elvégezni, majd ehhez megfelelő védelmi intézkedéseket rendelni. A folyamatos felülvizsgálat és aktualizálás pedig biztosítja, hogy az adatosztályozási rendszer hatékonyan működjön, a változó környezetben is.

 www.nuce.hu

A NIS2 és főleg a kibertörvény megjelenése óta elég sok beszélgetésen találkozunk, elég sok „észrevétellel”. Az alábbiakban a leggyakoribb kérdések, érvek közül nézünk végig néhányat. Csak dióhéjban (in nuce).

„Biztos, hogy a kibertörvény ránk is vonatkozik?”

Ez talán a leggyakrabb felvetés, és sok helyen felmerül. Minden (hatósági) segítség ellenére, nem mindig egyszerű eldönteni a kérdést. Ráadásul a felkészüléssel járó ráfordítások mind az erőforrások mind a költségek tekintetében, valamint az auditok várható költségei nagyon alapos megfontolást igényelnek.

Azt azért el lehet mondani, hogy ha már egyáltalán felmerült ez a kérdés, akkor könnyen lehet, hogy valóban a törvény hatálya alá tartozunk…

Természetesen az is opció, hogy a NIS2 keretrendszerét, kontrolljait mindenképpen érdemes használni a szervezetek informatikai fejlesztéseiben, akkor is, ha a jogszabály nem vonatkozik valakire. Legfeljebb nem annyira szűkös határidővel kell mindent megvalósítani, és főleg nem kötelező auditáltatni…

„Van ISO minősítésünk, mi rendben vagyunk, felkészültünk.”

Ez így ebben a formában nem teljesen igaz. Az természetesen igen sokat segít, ha valakinek van ISO minősítése, akár például az információbiztonságra vonatkozó ISO 27001-es. Egyrészt ez azt jelenti, hogy a szervezet gondolkodásába, folyamataiba már beivódott a szabálykövetés, a pontos dokumentálás, a megfelelések/auditok rendszere. Ráadásul ilyenkor az informatika is feltehetően jól szabályozott keretek között működik. Ugyanakkor a NIS2 irányelv (EU 2022/2555 irányelve az Unió egész területén egységesen magas szintű kiberbiztonságot biztosító intézkedésekről,…) 21. cikkében („A kiberbiztonsági kockázatkezelési intézkedések”) jelzi ezek használhatóságát: „Figyelembe véve a legkorszerűbb és adott esetben a vonatkozó európai és nemzetközi szabványokat, valamint a végrehajtás költségeit,…”. Ráadásul az irányelv preambulumának 79. pontja nevesíti is az ISO 27000-et.

Az ISO önkéntes, és a NIS2 kötelezően alkalmazandó jellege mellett vannak természetesen egyéb különbségek, eltérések, nem is kevés. Csak néhány példa erejéig: az ISO rendszerhez képest a NIS2, illetve a hazai kibertörvény rendelkezései jóval konkrétabbak, pontosabb feladatokat, kontrollokat írnak elő, konkrét szektorokat, iparágakat neveznek meg kötelezettként, pontos incidens-bejelentési határidőket határoznak meg, hangsúlyosan kitérnek a beszállítókra is, hatósági ellenőrzéseket és szankciókat tesznek lehetővé, vagy például rendszeres kockázatértékelést írnak elő.

Mindenesetre az ISO, vagy más szabvány igen jó alapot jelent a felkészülés indításához, feltehetően jóval kevesebb munkát igényel majd a NIS2-re való felkészülés, mint egy ilyen meglévő rendszer nélkül.

„Nincs még hatósági metodika az elektronikus információs rendszerek biztonsági osztályba sorolására. Addig nem tudunk semmit sem elkezdeni…”

Egyrészt azért elég sok mindent el lehet kezdeni a biztonsági osztályba sorolás nélkül is, hogy mást ne mondjunk egy kockázatelemzést is el lehetne végezni. Az sem kis feladat… Másrészt a biztonsági osztályba sorolás hatósági metodikájáról a jogszabály (7/2024. MK rendelet, 1. melléklet, 2.1.2. pont) azt mondja, hogy „Az elektronikus információs rendszerek biztonsági osztályba sorolását az elektronikus információs rendszerben kezelt adatok és az adott elektronikus információs rendszer funkciói határozzák meg. A besorolást, amelyet a szervezet vezetője hagy jóvá, hatáselemzés alapján kell elvégezni. Az elektronikus információs rendszerek biztonságának felügyeletét ellátó hatóság ajánlásként hatáselemzési módszertanokat ad ki. Ha a szervezet saját hatáselemzési módszertannal nem rendelkezik, az így kiadott ajánlást köteles használni.” Tehát: HA a szervezet rendelkezik saját hatáselemzési módszertannal, akkor nyugodtan elkezdheti a biztonsági osztályba sorolást.

„Nekünk csak egy elektronikus információs rendszerünk van, és az is „alap” biztonsági osztály…”

Ezek a kérdések ugye az audit díjának megállapításánál elég komoly árkülönbségeket jelenthetnek. 1/2025. SZTFH rendelet, 3. melléklet: „A kiberbiztonsági audit – általános forgalmi adó nélkül számított – legmagasabb díja az 1.1., 1.2. és az 1.3. pont szerinti szorzószámok, valamint 1 750 000 forint szorzataként előálló összeg.”

• 1: A szervezet előző üzleti évi nettó árbevétele
• 2: A szervezet elektronikus információs rendszereinek (EIR) darabszáma
• 3: A szervezet elektronikus információs rendszereinek biztonsági osztálya

Azaz, ha például a szervezet előző üzleti évi nettó árbevétele 11 milliárd Ft, akkor ez adott, mérleg leadva, ezzel nem tud a szervezet mit kezdeni (ez esetben a 11 mlrd Ft-hoz tartozó szorzószám a 2,5).

Amivel próbálkoznak a szervezetek, az az EIR-ek darabszáma. A leggyakoribb az „itt minden egy rendszerben fut”. Ezzel az a gond, hogy ezt esetleg majd az auditor másként látja… Ez mondjuk még a kisebbik probléma, mert öt darab EIR-ig a szorzószám egyes, azaz mindegy, hogy egy vagy akár öt EIR-ünk van, a szorzószám egyes. Hat és tizenöt EIR között már pl. 2,5, 16 EIR felett 4 a szorzószám.

Vagy a biztonsági osztályba sorolás. „Nálunk nincsenek annyira fontos EIR-ek, mi mindent (azt az egyet…) „alap” biztonsági osztályba soroltunk.” Mert hogy az „alap” biztonsági osztály szorzószáma egyes. Ezzel ugyanaz a gond, mint az előbb. Az auditornak esetleg más lesz a véleménye. Ráadásul ezt a besorolást érintett hatóság is vizsgálni fogja! 418/2024. évi Kormányrendelet 30.§ szerint: „Az elektronikus információs rendszerek biztonsági osztályba sorolásának vizsgálata a nemzeti kiberbiztonsági hatóságnak megküldött információk alapján, jogszabályban meghatározott szempontok szerint történik.” „A nemzeti kiberbiztonsági hatóság a szervezet által megállapított biztonsági osztályt felülbírálhatja és indokolással magasabb biztonsági osztályba sorolást is megállapíthat.”

Az SZTFH rendelet szerint: „ha a szervezet valamennyi elektronikus információs rendszerének biztonsági osztálya „alap” biztonsági osztály, a szorzószám 1.Ha a szervezet bármely elektronikus információs rendszerének biztonsági osztálya „jelentős” biztonsági osztály, a szorzószám 3, ha a szervezet bármely elektronikus információs rendszerének biztonsági osztálya „magas” biztonsági osztály, a szorzószám 5.”

Tehát mennyi lehet az SZTFH rendelet szerint a kiberbiztonsági audit legmagasabb díja a fenti példa-árbevétellel számolva?

• A számunkra kedvező matek esetén: 1.750.000 x 2,5 x 1 x 1 = 4.375.000,-Ft+ÁFA
• A valósághoz közelebbi állapot esetén (pl. 6db EIR, amiből egy „jelentős”) 1.750.000 x 2,5 x2,5 x 3 = 32.812.500,-Ft+ÁFA.

Hát… Valóban nem mindegy…

A szervezetek döntéshozóinak mások a prioritásai.

Ez is természetes, és jogos. Akikre a kibertörvény NIS2 része vonatkozik, azok elég nagy szervezetek, a vezetőik abból a pozícióból gondolkodnak már hosszú évek óta. Azaz: „mi nem egy két fős Bt vagyunk, elég nagyok vagyunk, ráérünk, megoldjuk valahogy, a hatóság is „enyhébben kezel””,… Ez igaz, de mind a felkészítők, mind az auditorok is csak ilyen nagy cégekkel dolgoznak, csak ilyenekkel találkoznak, ez a piac csak ilyen nagy szervezetekből áll. Mindenki „nagy”, kiemelt, VIP vezető,…

 Ugyanakkor fontos lenne látni azt is, hogy a kibertörvény elég egyértelműen a „szervezet vezetőjére” ró igen sok feladatot. Ezek egy részét természetesen nem ő fogja elvégezni, de a felelősség az övé. 2024. évi LXIX. törvény 30. § (3): „Ha a szervezet vezetője a jogszabályban előírt kötelezettségének nem tesz eleget, a nemzeti kiberbiztonsági hatóság az eset összes körülményének mérlegelésével kormányrendeletben meghatározott mértékű bírsággal sújthatja, ismételt jogsértés esetén sújtani köteles.” A hivatkozott kormányrendelet a 418/2024. Kormányrendelet, ahol a 42.§ foglalkozik a Kiberbiztonsági bírságokkal. A 3. mellékletben elég részletesen le vannak írva a mulasztások és a kapcsolódó bírságok, de csak egy példa egy kategóriában a legmagasabb összegre: „ha a szervezet alapvető szervezetnek minősül 10 millió eurónak megfelelő forintösszeg vagy, ha ez magasabb a szervezet előző pénzügyi évi globális éves forgalma teljes összege 2%-ának megfelelő összeg”.

Ráadásul a Kormányrendelet 44.§ (4) szerint: „A bírság megfizetése nem mentesít a büntetőjogi, valamint a polgári jogi felelősség, valamint a bírság kiszabására okot adó körülmény megszüntetésének kötelezettsége alól.”

Ide kapcsolódik még egy-két „apróság”: 42.§ (4): „Ha a szervezet vezetője a jogszabályban előírt kötelezettségének nem tesz eleget, a nemzeti kiberbiztonsági hatóság 15 millió forintig terjedő bírsággal sújthatja, illetve ismételt jogsértés esetén sújtja.” Azaz, személy szerint a szervezet vezetője is kaphat pénzbírságot.

ÉS az információbiztonsági felügyelő (2024. évi LXIX. törvény 30. §): „Ha a szervezet a jogszabályokban foglalt biztonsági követelményeket és az ehhez kapcsolódó eljárási szabályokat nem teljesíti vagy nem tartja be, a biztonsági hiányosságokat nem hárítja el, a megfeleléshez szükséges intézkedések meghozatalát elmulasztja, vagy a tevékenységet nem hagyja abba, a kiberbiztonsági hatóság… jogosult … a szervezet költségére információbiztonsági felügyelőt kirendelni.”

Na, ez az, amit senki sem szeretne… Az információbiztonsági felügyelőnek igen komoly jogosultságai vannak, például jogosult „azonnali intézkedést javasolni az érintett szervezet vezetőjének a közvetlen fenyegetés elhárításához (működés korlátozása, leállítása)”.

Még egyszer: a jelenlegi gazdasági körülmények között teljesen jogos a szervezetek vezetőinek az a priorizálása, hogy először a túlélés (árbevétel, piacszerzés, stb.), és minden más csak utána következhet. Ugyanakkor a kibertörvény és „környéke” - bár senki sem a „nulláról indul” - szintén elég sok feladatot ró az érintettekre. És nincs rá sem túl sok idő, sem túl sok erőforrás.

 www.nuce.hu