Kiberbiztonsági audit: mit kér az auditor, és mi legyen készen

A kiberbiztonsági audit nem azt méri, be lehet-e törni a rendszerbe. Azt méri, bizonyítható-e, hogy a védelmi intézkedések a helyükön vannak, és hogy valaki rendszeresen ellenőrzi is őket. Szabályzatokkal teli iratrendező erre nem bizonyíték. Bizonyíték az a vizsgálati jelentés, amely megnevezi, mit teszteltek, mikor, mit találtak, és mi lett a megtalált hibák sorsa. Alább összeszedtük, mit mond a magyar jog az auditról, mit vizsgálhat az auditor, mit fogad el technikai bizonyítékként, és mit érdemes már az audit előtt előkészíteni. Informatikai és biztonsági vezetőknek írtuk, szakzsargon nélkül ott, ahol elkerülhető.

Mit vizsgál a kiberbiztonsági audit?

Az audit szisztematikus összevetés: az auditor a jogszabályban előírt védelmi intézkedéseket veti össze a szervezet tényleges állapotával, leírja az eltéréseket, és megmondja, mit kell rendbe tenni. A cél nem a hibátlan bizonyítvány, hanem az, hogy a gyenge pontokat előbb találja meg valaki, aki ezért kapja a fizetését.

Magyarországon ehhez egyetlen kiberbiztonsági törvény van hatályban: a Magyarország kiberbiztonságáról szóló 2024. évi LXIX. törvény (a továbbiakban: Kiberbiztonsági tv.), amely 2025. január 1-jén lépett hatályba, és amely a NIS2 irányelvet ülteti át a magyar jogba. Ugyanezzel a nappal hatályát vesztette a 2023. évi XXIII. törvény (128. §) és a 2013. évi L. törvény (116. §) is. Ha egy tanácsadói összefoglaló még ezekre hivatkozik, elavult forrásból dolgozik.

A megfelelés mércéjét a 7/2024. (VI. 24.) MK rendelet 2. melléklete adja. Ez biztonsági osztályonként – alap, jelentős, magas – sorolja fel a védelmi intézkedéseket, és a szervezet vezetője dönt arról, melyik rendszer melyik osztályba kerül. Az auditor ezt a katalógust veti össze a valósággal, tehát a felkészülés is innen indul: előbb a besorolás, utána a bizonyíték. Aki már ISO 27001 tanúsítvánnyal a kezében kérdezi, mennyi maradt hátra, annak külön cikkben szedtük össze a különbséget.

Kire vonatkozik, és milyen gyakran

A 16. § (1) bekezdése szerint kétévente kell kiberbiztonsági auditot végeztetnie annak az 1. § (1) bekezdés b) pontja szerinti szervezetnek, amely egyúttal a 2. vagy a 3. melléklet szerinti szervezet is, továbbá a d) pont szerinti szervezetnek, valamint – a mikrovállalkozás kivételével – az e) pont szerinti szervezetnek. Ezen felül a hatáskörrel rendelkező kiberbiztonsági hatóság külön is elrendelheti.

A ciklus tehát kétéves, nem éves. Ez a piacon a leggyakrabban elrontott részlet, és egy megfelelési vezető azonnal észreveszi, ha egy szolgáltató éves auditról beszél.

A határidők a nyilvántartásba vételhez igazodnak: a 16. § (2) bekezdés a) pontja szerint a szerződést a nyilvántartásba vételtől számított 120 napon belül kell megkötni, az első auditot pedig a b) pont szerint két éven belül elvégeztetni. A már 2025. január 1. előtt is működő szervezeteknek a 89. § (2) bekezdése – a 2025. évi XXXII. törvény 70. § (2) bekezdésével megállapított szöveg szerint – 2026. június 30-ig adott időt.

Ez a kör lezárult, és az eredménye ismert. Az SZTFH 2026. augusztus 26-i közleménye szerint 2194 szervezet végezte el az első kiberbiztonsági auditot, mintegy 90% megfelelt, és mintegy 10% kapta meg a legjobb minősítést, az „Elhanyagolható kockázattal megfelelt” besorolást. A hatóság egy visszatérő hiányosságot is megnevezett: a távoli hozzáférés megoldásait a szervezetek komolyan vették, a rendszerdokumentáció viszont sok helyen hiányos volt. Aki most készül a következő ciklusra, ott nyeri a legtöbbet, ha ezt a dokumentációs hiányt pótolja először.

Ki folytatja le

Az auditot a Kiberbiztonsági tv. 4. § 10. pontja szerinti auditor végzi: független gazdálkodó szervezet, amely szerepel az SZTFH auditori nyilvántartásában. A 21. § (2) bekezdése ezt egy második feltételhez is köti: az auditornak egyben az 57. § (1) bekezdés c) pontja szerinti, sérülékenységvizsgálat lefolytatására jogosult szervezetnek is kell lennie. A nyilvántartás nyilvános; a szerződéskötés előtt érdemes közvetlenül az SZTFH oldalán ellenőrizni, ki szerepel benne és mikori az utolsó módosítás.

Az auditor az eredményt a 22. § (2) bekezdése szerint haladéktalanul megküldi az SZTFH-nak és a szervezetnek is. Ez a mondat önmagában is elég indok arra, hogy a technikai bizonyíték előbb legyen kész, mint az auditor első kérdése.

Mit vizsgálhat az auditor a megfelelés ellenőrzésekor?

A Kiberbiztonsági tv. 22. § (1) bekezdése nem kötelezettséget ír elő, hanem jogosultságot ad. A szöveg kulcsszava a „jogosult”: az auditor eldöntheti, hogy a nyomon követhető módon elvégezhető vizsgálatok közül melyiket használja. A felsorolás három elemből áll:

• a) belső informatikai biztonsági és távoli sérülékenységvizsgálat, valamint „jelentős” vagy „magas” biztonsági osztály esetén behatolásvizsgálat;


• b) kriptográfiai megfelelőségvizsgálat;


• c) „jelentős” vagy „magas” biztonsági osztály esetén a kritikus biztonsági funkciókat ellátó, egyedileg fejlesztett szoftverek biztonsági forráskódvizsgálata.

Egy szót érdemes pontosan idézni. A törvény az a) pontban belső informatikai biztonsági vizsgálatot ír, nem külsőt. A közkézen forgó összefoglalók egy része itt külsőt közöl, és a hibás idézet több szolgáltatói oldalra is átkerült. A 4. § 12. pontja meg is határozza a fogalmat: belső informatikai biztonsági vizsgálatról akkor van szó, ha a sérülékenységvizsgálat a belső hálózati végpontról közvetlenül történik, vagy ha a belső hálózatban használt eszköz, illetve rendszerelem vizsgálata zajlik. Ugyanezt erősíti meg az 1/2025. (I. 31.) SZTFH rendelet 2. § (2) bekezdése, amely szerint ezek a módszerek alkalmazhatóak.

A behatolásvizsgálat a magyar jogban egyébként sem önálló tevékenység. A 4. § 11. pontja sérülékenységvizsgálati módszerként határozza meg, amely a rendszer „gyenge pontjainak feltárására és kihasználhatóságának ellenőrzésére” irányul, rosszindulatú támadások szimulációjával. Aki tehát behatolásvizsgálatot rendel, a törvény szerint a sérülékenységvizsgálat egyik módszerét rendeli meg. Hogy melyik szervezetre melyik eljárás vonatkozik, arról a ki végezhet sérülékenységvizsgálatot című cikkünkben írtunk részletesen.

Mit ír elő a védelmi intézkedések katalógusa?

Az önálló, kötelező behatolásvizsgálat kérdését nem a törvény, hanem a 7/2024. (VI. 24.) MK rendelet 2. melléklete dönti el, cellánként. Az alábbi táblázat a rendelet saját jelöléseit adja vissza: az X kötelező elemi követelményt jelöl, a vízszintes vonás azt, hogy az adott osztályban nem az.

Ebből három dolog következik. Az önálló behatolásvizsgálat (5.21) egyetlen biztonsági osztályban sem kötelező elemi követelmény. Független szakértő vagy csapat bevonása (5.22) kizárólag a magas osztályban az. A sérülékenységek ellenőrzése (15.9) viszont mindhárom osztályban kötelező, a sérülékenységmenedzsment (15.10) pedig a jelentős osztálytól felfelé – vagyis a rendszeres, dokumentált vizsgálat az a pont, ahol szinte mindenki érintett. A cellákat és a következményeiket külön cikkben bontottuk ki.

Mit fogad el az auditor technikai bizonyítékként?

Az auditor egyetlen szempontból nézi a technikai anyagot: visszakereshető-e, és ellenőrizhető-e. A „megcsináltuk” önmagában nem az. Három elvárás ismétlődik.

1. Független és friss vizsgálat. A saját üzemeltetői csapat rendszeres ellenőrzése napi szinten hasznos, formális bizonyítékként viszont gyenge, mert a saját munkáját minősíti. Külső szakértő jelentését fogadja el a legkönnyebben. Számít a dátum is: egy évnél régebbi jelentés olyan rendszert ír le, amely ebben a formájában sokszor már nem létezik. A magas osztályban ez nem is ízlés kérdése, hanem az 5.22 kontroll szövege.


2. Ellenőrzött megállapítás, nem nyers eszközkimenet. Egy automatizált felderítés exportja kontextus nélkül, több száz tétellel inkább kérdéseket szül, mint bizalmat. A használható jelentésben minden megállapítás mellett ott a bizonyíték, a kihasználás feltétele és a következmény. A hamis riasztásokat a tesztelő már kiszűrte, tehát az auditor nem a szűrésre fog rákérdezni.


3. Javítás és bizonyíték a javításról. A hibalista önmagában nem eredmény. Minden megállapításhoz tartozzon javítási lépés, felelős és határidő, a lezárt tételekhez pedig írásos igazolás arról, hogy az újratesztelés után a hiba már nem használható ki. Ez az a dokumentum, amely a kockázat tudomásulvételét intézkedéssé változtatja – és az SZTFH visszajelzése alapján éppen a dokumentáció az, ami a leggyakrabban hiányzik.

Röviden: az auditor hiteles bizonyítékot keres arra, hogy a szervezet rendszeresen méri a saját ellenálló képességét, és rendbe teszi, amit talál. Egy tisztességesen megírt vizsgálati jelentés ezt az elvárást nagyrészt egyetlen dokumentummal lefedi.

Mit adunk át az audithoz?

A 16. § szerinti kiberbiztonsági auditot az SZTFH nyilvántartásában szereplő, független auditor folytatja le. Az a technikai bizonyíték viszont, amelyet bekér, a szervezetnél áll elő – és ezt a részt készítjük el. Egyetlen tesztprojektből kijön az a csomag, amelyet az auditor kérni fog:

• Hatókör és időpont. Pontosan melyik rendszert, melyik felületet és melyik jogosultsági szintet vizsgáltuk, mikortól meddig, milyen modellben.


• Megállapítások bizonyítékkal. Minden tétel mellett ott vannak a reprodukció lépései és a bizonyíték arra, hogy a hiba a gyakorlatban is kihasználható.


• Kockázati besorolás a saját környezetére vetítve. A CVSS-pontszám mellett leírjuk, mit jelent a hiba ebben a szervezetben: ügyféladat, leállás, pénzügyi veszteség.


• Javítási lépések sorrendben. Nem „frissítse a rendszert”, hanem melyik komponenst, melyik verzióra, melyik beállítást hogyan – és mit érdemes elsőként megcsinálni.


• Írásos igazolás az újratesztelésről. A javítások után újra megnézzük a megállapításokat, és leírjuk, melyik zárult le. Ezt fogadja el az auditor a leggyorsabban.

A vizsgálatot elismert módszertanok szerint végezzük – webalkalmazásoknál az OWASP ASVS és a WSTG szerint –, és a jelentés megnevezi, mi alapján dolgoztunk. A tesztelőink OSCP-tanúsítvánnyal rendelkeznek, a Haxoris ISO/IEC 27001 tanúsítványát pedig a TÜV SÜD adta ki, tehát saját bevezetésből tudjuk, hogyan néz ki egy auditor számára használható bizonyíték. A megfelelési oldalról ugyanezt a munkát az IT-biztonsági audit és a NIS2 penetrációs teszt oldalán írtuk le, a rendszeres, eszközzel támogatott felderítést pedig a sérülékenységvizsgálat oldalán.

Miért erősíti a penetrációs teszt az audit eredményét?

Sok védelmi intézkedést el lehet készíteni házon belül: megírni a szabályzatot, betanítani a kollégákat, bekapcsolni az eszközöket. Egy dolgot nem lehet: ellenőrizni, hogy mindez kiállja-e a támadást. Erre való a penetrációs teszt, és az audit szempontjából négy dolgot hoz.

• Megméri, hogy a védelem működik-e. A dokumentumból az derül ki, hogy van tűzfal, végpontvédelem és mentés. Abból, hogy a tesztelő nem jut át, az derül ki, hogy ezek működnek is. A kettő nem ugyanaz, és a különbség rendszerint egy elfelejtett kivételszabály.


• Kihozza a valódi réseket. Az internetről elérhető felügyeleti felület, a jelszócsere nélkül évek óta futó szolgáltatásfiók, a belső hálózaton szabadon elérhető adatbázis. Ezek alapján azonnal lehet lépni, és ha nem a tesztelő találja meg őket, akkor az auditor – vagy valaki más.


• Megelőzi a kellemetlen megállapítást. Sokkal jobb a lezárt hibát megmutatni, mint a nyitottat megmagyarázni. A teszt és az audit közötti néhány hét pontosan erre való.


• Egyszerre több elvárásnak felel meg. Ugyanaz a jelentés használható a magas osztály 5.22 kontrolljához, az [ISO 27001 tanúsító auditra](/hu/szolgaltatasok/iso-27001-penetracios-teszt) készülő bizonyítékként, kártyás környezetben a PCI DSS-hez és beszerzési eljárásban is. Az általános adatvédelmi rendelet 32. cikk (1) bekezdés d) pontja szintén megköveteli „a technikai és szervezési intézkedések hatékonyságának rendszeres tesztelésére, felmérésére és értékelésére szolgáló eljárást”; penetrációs tesztet nevesítve nem ír elő, a hatékonyság mérésére viszont a gyakorlatban ez az egyik használt eszköz.

A penetrációs teszt tehát nem újabb akadály az audit előtt. A legrövidebb út ahhoz, hogy az audit meglepetés nélkül záruljon.

Mit tartalmaz a vizsgálati jelentés?

A jelentés két olvasónak készül egyszerre: a szervezet mérnökeinek és az auditornak. Négy része van, és mindegyik mást ad a két oldalnak.

• Vezetői összefoglaló és technikai rész. Az összefoglaló a legsúlyosabb kockázatokat és az üzleti következményüket írja le olyan nyelven, amelyet a vezetés is használ. A technikai rész ezután megy le a részletekig. Az auditor így percek alatt megtalálja, mit teszteltünk, mi jött ki belőle, és mi történt utána; a csapat pedig feladatlistaként olvassa ugyanezt.


• Megállapítások kockázati besorolással. Minden tétel kap súlyosságot, hogy látszódjon, mi kritikus és mi kozmetikai. A jó jelentés nem áll meg az általános CVSS-pontszámnál, hanem megmondja, mit jelent az adott hiba ebben a környezetben. Az auditornak ez azt mutatja, hogy a szervezet érti a saját kockázatát.


• Javaslatok és javítási sorrend. Konkrét lépések: melyik könyvtárat kell frissíteni és mire, melyik fejlécet kell beállítani, hol kell kétfaktoros hitelesítést bevezetni. Ez a rész rövidíti le az utat a „van egy problémánk” állapottól a „megoldottuk” állapotig.


• Módszertan és hatókör. A jelentés megnevezi, milyen [módszertan](/hu/tesztelesi-modszertanok) szerint dolgoztunk, és pontosan mi tartozott a hatókörbe. Ettől lesz a munka ellenőrizhető: a független auditor néhány lépést maga is megismételhet, és ugyanazt kell kapnia.

Az újratesztelés zárja a kört. Enélkül a jelentés csak azt bizonyítja, hogy a szervezet ismerte a hibáit – azt nem, hogy meg is szüntette őket.

Penetrációs teszt vagy automatizált sérülékenységfelderítés?

A két munkát a kereskedelmi ajánlatokban gyakran összemossák, pedig az audit szempontjából nem egyenértékűek. A különbséget külön is összeszedtük; itt csak az számít, mit kezd velük az auditor.

• Mélység. Az eszköz ismert mintázatokat keres: hiányzó javítást, nyitott portot, gyenge jelszót. Amit nem ismer, azt nem találja meg. A tesztelő ezzel szemben láncba fűzi az önmagukban jelentéktelen hibákat, és megkeresi az üzleti logika réseit – a hitelesítés megkerülését, a más felhasználó adataira mutató azonosítót.


• Kézi ellenőrzés. Az automatizált kimenet tele van olyan tételekkel, amelyek a gyakorlatban nem használhatók ki. A tesztelő ezeket kiszűri, így a jelentésbe csak ellenőrzött megállapítás kerül. A szervezet nem több száz sort néz át, hanem tíz-tizenöt megállapítást, az auditor pedig nem ballasztot kap.


• Kontextus. Az eszköz általános súlyosságot ad. A jelentés megmondja, hogy egy SQL-injekció ebben az alkalmazásban a teljes ügyféladatbázist nyitja meg – és ezért kritikus itt, akkor is, ha a pontszáma máshol közepes lenne.


• Javítás és újratesztelés. Az eszköz kimenete rendszerint annyit mond, hogy „frissítsen”. A teszt megmondja, mit és mire, majd a javítás után újra megnézi. Ezt a lépést a magyar piacon kevés szolgáltató nevezi meg külön – pedig az auditor éppen ezt keresi.

Ebből nem az következik, hogy az automatizált felderítés felesleges. Az következik, hogy más a dolga: a felderítés a tesztek közötti időszakot fedi le és a 15.9 kontrollhoz ad rendszeres bizonyítékot, a teszt pedig a mélységet adja hozzá.

Hogyan érdemes felkészülni az auditra?

A sorrend számít, mert az egyik lépés kimenete a másik bemenete. A következő ciklusra készülő szervezetnél ez a menet vált be:

• Besorolás először. A biztonsági osztályba sorolás dönti el, mely védelmi intézkedések vonatkoznak a rendszerre – és azt is, kell-e független szakértőt bevonni a behatolásvizsgálathoz. Enélkül a tesztelés hatóköre találgatás.


• Rendszerleltár és dokumentáció. Melyik rendszer hol fut, ki üzemelteti, milyen adatot kezel. Az SZTFH visszajelzése alapján ez az a pont, ahol a legtöbb szervezet elakad, pedig ezt lehet a legolcsóbban rendbe tenni.


• Teszt az audit előtt, nem alatta. Hagyjon időt a javításra és az újratesztelésre. Az a jelentés, amelyben a kritikus tételek már lezártak, egészen más beszélgetést indít.


• Bizonyítékok egy helyen. Jelentés, javítási napló, újratesztelési igazolás, a rendszeres felderítés kimenete. Ha ezt az auditor első kérdésére elő lehet venni, az audit napokkal rövidül.


• Szerződés időben. Az auditorral kötendő szerződésre a 16. § (2) bekezdés a) pontja határidőt szab, és a nyilvántartásban szereplő szervezetek kapacitása véges.

Összefoglalva: a bizonyíték készüljön el előbb

A kiberbiztonsági audit kiszámítható, ha a szervezet felkészülten érkezik rá. A legtöbbet a technikai bizonyíték adja: a hibák előre megtalálhatók és javíthatók, az auditor pedig nem ígéretet kap, hanem dokumentumot. A végén pedig nem az a lényeg, hogy az audit lezárul, hanem hogy a támadás, amelytől a szervezet tart, egyszerűen nem sikerül.

A Haxoris ebben a folyamatban a technikai oldalon dolgozik. Penetrációs tesztet és sérülékenységvizsgálatot végzünk, a jelentést pedig eleve olyan formában adjuk át, amelyet az auditor elfogad: megnevezett módszertannal, ellenőrzött megállapításokkal, kockázati besorolással, javítási sorrenddel és írásos igazolással az újratesztelésről. Ne az auditor vagy egy hívatlan látogató találja meg a réseket. Kérjen ingyenes konzultációt, és nézzük meg, mi hiányzik még a bizonyítékok közül.

Kiberbiztonsági audit – gyakori kérdések

Kapcsolódó Haxoris-szolgáltatások: IT-biztonsági audit és átvilágítás · penetrációs teszt a NIS2-megfeleléshez