Etikus hacker: kit bízzon meg, és mit kérjen tőle írásban

„Bérelnék egy hackert” – ez addig hangzik viccnek, amíg tényleg meg nem kell venni: kiválasztani a vállalkozót, szerződést aláírni és idegeneket beengedni oda, ahol az ügyféladat van. Ekkor derül ki, hogy a kereskedelmi piacnak nincs belépési küszöbe. „Pentesztet végzünk” mondatot bárki kiírhat a honlapjára, a különbség pedig a jelentésben látszik – vagyis a számla után.

Alább szétszedjük ezt a beszerzést: kit bíz meg valójában, miből derül ki, hogy a vállalkozó tudja is, amit ígér, mi kerüljön a szerződésbe, és milyen az a jelentés, amiért érdemes fizetni. Magát a szolgáltatást külön írtuk le: mi az a penetrációs teszt.

Kit bízna meg valójában?

A napi munkának kevés köze van a kapucnis alakhoz a stockfotókról. Nagyrészt olvasás, próbálkozás és dokumentálás.

• A támadási felület feltérképezése. Mi látszik egyáltalán az internet felől, milyen aldomének élnek, milyen technológia fut alattuk. Rendszeresen kijön belőle egy tesztrendszer, amelyről a cégen belül már senki nem tudott.
• Hitelesítés és jogosultságok. Ki lehet-e adni magunkat másik felhasználónak? Lát-e egy átlagos fiók olyan adatot, amihez semmi köze? Itt születnek a legsúlyosabb megállapítások, és ezeket egyetlen szkenner sem hozza ki.
• Üzleti logika. Kétszer beváltott kupon, kihagyott lépés a megrendelésben, negatív összegű utalás. A kód szempontjából semmi nem romlik el, a pénz mégis kifolyik.
• A hibák láncba fűzése. Két apróság, amelyből külön-külön semmi nem következik, együtt rendszergazdai hozzáférést ad. Épp ezt a láncot kell megmutatnia a jelentésnek.
• Bizonyíték. A megállapítás bizonyíték nélkül vélemény. A bizonyíték választja el a tesztet a szkenner exportjától.

A megnevezés változó, a munka ugyanaz. Honlapon és álláshirdetésben egyaránt szerepel az „etikus hacker”, a „penteszter” és a „biztonsági tesztelő”. Megrendelni viszont penetrációs tesztet érdemes: csak ennek a névnek van hatóköre, ütemezése és terméke a végén. Az „etikus hackelés” címszó alatt adott ajánlatot semmivel nem lehet összehasonlítani, mert a munka méretéről nem mond semmit.

A magyar jog is a szűkebb szót használja. A Kiberbiztonsági tv. 4. § 11. pontja szerint a behatolásvizsgálat a sérülékenységvizsgálat egyik módszere: 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. Ha tehát a szerződés vagy a pályázati kiírás behatolásvizsgálatot ír, ugyanerről a munkáról beszél.

Mi különbözteti meg az etikus hackert a támadótól?

Nem a technika: az ugyanaz. A különbség három dokumentumban van.

• Írásos engedély. A jogosult hozzájárulása, még a munka megkezdése előtt. Attól kell megkapni, aki a rendszert ténylegesen üzemelteti – idegen felhőben futó alkalmazásnál vagy SaaS-szolgáltatásnál ez nem automatikusan a megrendelő cége, a szolgáltató szerződési feltételei pedig korlátozhatják a tesztet vagy előzetes bejelentéshez köthetik.
• Hatókör. Pontos lista arról, mi tartozik a vizsgálatba, és mi nem. A hatókörön kívüli rendszert a tesztelő békén hagyja, akkor is, ha hibát lát benne.
• Tesztelési szabályok. Időablak, engedélyezett technikák, eszkalációs elérhetőségek és azok a lépések, amelyekhez külön hozzájárulás kell. Ide tartozik jellemzően a rendelkezésre állás elleni támadás, a tömeges levélküldés és az éles adatok módosítása.

E három nélkül ugyanaz a tevékenység már nem szolgáltatás. Paragrafusszámot itt nem idézünk: a jogi minősítés a körülményeken múlik – azon, kinek a rendszeréről és kinek az adatairól van szó –, és ez ügyvédi kérdés, nem a tesztelőé. A vállalkozónak ezen a ponton egyetlen dolga van: írásos engedély nélkül nem kezd hozzá.

Milyen megbízást nem vállalunk el?

A „bérelnék egy hackert” kérés két teljesen különböző szándékot takar, ezért egyértelműen: kizárólag olyan rendszert vizsgálunk, amelyre a jogosulttól írásos engedélyt kaptunk.

Nem vállaljuk – az indoktól és a díjtól függetlenül:

• hozzáférés szerzését más fiókjához, postaládájához, üzeneteihez vagy eszközéhez, akkor sem, ha hozzátartozóról, üzlettársról vagy munkatársról van szó;
• olyan fiók visszaszerzését, amelynél a tulajdonlás nem igazolható;
• versenytárs, beszállító vagy ügyfél rendszerének vizsgálatát a saját megrendelésük nélkül;
• személyek megfigyelését.

Ez nem formaság és nem alkuképes. Az a vállalkozó, aki ezt a határt alkura bocsátja, a megrendelő adatainál is alkura fogja bocsátani.

Tanúsítványok: melyik mit igazol?

A tanúsítvány az egyetlen széles körben elérhető mérce, csak épp nagyon különböző dolgokat mér. A választóvonal a működő rendszeren letett gyakorlati vizsga és a biztonságirányításról szóló feleletválasztós teszt között húzódik.

Két dolgot negyedóra alatt ellenőrizhet. Az egyik: a tanúsítvány emberhez tartozik, nem céghez – ezért a ténylegesen dolgozó szakemberek nevét kérdezze, ne a honlap összesített listáját. A másik: az OffSec és az ISC2 nyilvánosan ellenőrizhető nyilvántartást vezet, tehát kérjen azonosítót vagy hivatkozást, ne képernyőképet.

Nálunk négy etikus hacker végzi a tesztelést, OSCP-szintű tanúsítvánnyal; a nevek, a szerepek és a tanúsítványok a Rólunk oldalon nyilvánosak. Az információbiztonsági irányítási rendszerünket ezen felül a TÜV SÜD tanúsította az ISO/IEC 27001 szabvány szerint – ez a saját működésünkről szól, nem a vizsgált rendszerről.

Amit a magyar szabályozás vár el a szakembertől

Egy dolgot érdemes szétválasztani, mert a piacon rendre összecsúszik. A Kiberbiztonsági tv. 57. §-a szerinti sérülékenységvizsgálat szabályozott eljárás: azt az NBSZ, a honvédelmi kiberbiztonsági incidenskezelő központ (KNBSZ), illetve telephely biztonsági tanúsítvánnyal rendelkező, az SZTFH nyilvántartásában szereplő gazdálkodó szervezet folytathatja le (57. § (1) bekezdés). A vizsgálatot végző személytől a törvény szakértelmet, kétéves gyakorlatot és nyilvántartásba vételt kíván meg (57. § (2) bekezdés b)–d) pont). Ez a rend viszont az 1. § (1) bekezdés a)–c) és f) pontja szerinti szervezetekre terjed ki (1. § (9) bekezdés), a d)–e) pont alá tartozó cégek kereskedelmi megrendelését pedig a 60. § (1) bekezdése kiveszi alóla. Egy magáncég piaci penetrációs tesztjét tehát nem köti az SZTFH-nyilvántartás. Ezt a félreértést – mert a magyar találati listákon ez a leggyakoribb – külön cikkben vezettük végig.

Ha a hatókörbe emberek is beletartoznak, a jogszabály szóhasználatát érdemes átvenni a kiírásba: az 5/2025. (VI. 20.) SZTFH rendelet 3. § (2) bekezdés bd) alpontja szakértői kompetenciaként nevesíti a „pszichológiai manipulációs (social engineering) támadások tervezése és kivitelezése” tevékenységet. A social engineering vizsgálat tehát nem egzotikus kiegészítő, hanem olyan munka, amelyet a hazai szabályozás is néven nevez.

Mit tartalmazzon a szerződés?

A penetrációs teszt szerződése nem egyetlen mondat „biztonsági tesztek elvégzéséről”. Alább az a minimum, amelynek a hiányát a megrendelő általában akkor veszi észre, amikor már baj van.

• Hatókör. Címek, doménnevek, alkalmazások, szerepkörök és tesztfiókok listája. A kizárásokat tételesen kell felsorolni, a harmadik felek rendszereivel együtt, amelyekre nincs engedély.
• Időablak. A munka napjai és órái, benne azzal, hogy a terhelő vizsgálat munkaidőn kívülre kerül-e. Enélkül az első riasztásból fölösleges krízisértekezlet lesz.
• Kapcsolattartás és eszkaláció. Ki veszi fel a telefont éjjel mindkét oldalon, ha a teszt megfekteti a szolgáltatást, vagy ha a tesztelő idegen betörés nyomaiba botlik. A második gyakrabban fordul elő, mint amennyire az ajánlatokból következne.
• A tesztadatok kezelése. Hol tárolják a bizonyítékokat és a vizsgálat közben kinyert adatokat, ki fér hozzájuk, meddig őrzik meg, mikor törlik. Ha a hatókörbe személyes adat is beleeshet, tisztázni kell az adatkezelői és adatfeldolgozói szerepeket, valamint a hozzájuk tartozó szerződést.
• Titoktartási megállapodás (NDA). A hatókörről szóló beszélgetés előtt aláírva, nem a vállalkozási szerződés után: már maga az egyeztetés is felfedi az architektúrát.
• Szakmai felelősségbiztosítás. Van-e, mekkora összegre szól, és kiterjed-e az éles környezetben okozott kárra.
• Publikáció és referencia. Megnevezheti-e a vállalkozó a céget ügyfélként, írhat-e róla esettanulmányt, és bejelentheti-e a talált hibát a szoftver gyártójának – ha igen, milyen határidővel és kinek a jóváhagyásával.
• Újratesztelés. A szerződésben, határidővel és árral, vagy a teszt árában. Az újratesztelés nem új vizsgálat: a javítás után a megjelölt helyeket nézi meg, nem az egész alkalmazást elölről.
• Alvállalkozók. Ki végzi el fizikailag a munkát. Megesik, hogy az ajánlatban szereplő nevek és a projektben dolgozó emberek két különböző halmaz.

Milyen a jelentés, amiért érdemes fizetni?

A vizsgálati jelentés a teszt egyetlen tartós terméke. Egy év múlva a beszélgetésekre senki nem fog emlékezni, az auditor pedig dokumentumot kér. Egy használható jelentésben benne van:

• a vezetői összefoglaló, üzleti nyelven;
• a megállapítások száma és megoszlása kockázati szint szerint;
• minden megállapításnál azonosító és cím, kockázati besorolás CVSS szerint, technikai leírás a reprodukáláshoz elég bizonyítékkal, végül konkrét javítási javaslat.

Két dolgot még a döntés előtt érdemes megtenni. Kérjen névtelenített mintajelentést – az aláírás előtt, ne utána; a jelentés maga a termék, és aki nem hajlandó megmutatni, annak megvan rá az oka. És olvassa el a javaslatokat: a „javasoljuk a bevált gyakorlatok bevezetését” mondattal senki nem tud mit kezdeni, a „javasoljuk az X fejléc beállítását Y értékre a Z konfigurációban” viszont egy délután alatt elvégezhető feladat a csapatnak.

A jelentés formája abban a pillanatban már nem ízlés kérdése, amikor bizonyítékká válik. A Kiberbiztonsági tv. 16. § (1) bekezdése szerint az érintett szervezet kétévente köteles kiberbiztonsági auditot végeztetni, a 22. § (1) bekezdés a) pontja szerint pedig az auditor jogosult „belső informatikai biztonsági és távoli sérülékenységvizsgálatot, valamint »jelentős« vagy »magas« biztonsági osztály esetén behatolásvizsgálatot” alkalmazni. Két szó számít itt sokat. Az egyik a jogosult: a törvény felhatalmazza az auditort, nem kötelezi. A másik a belső, amelyet a széles körben másolt kamarai összefoglaló külsőre cserél, és a hiba onnan terjedt tovább. A védelmi intézkedések katalógusában – 7/2024. (VI. 24.) MK rendelet 2. melléklet – az 5.21 behatolásvizsgálat egyik biztonsági osztályban sem kötelező; kizárólag az 5.22, vagyis a független szakértő vagy csapat bevonása az, és csak a magas osztályban. A katalógus sorait külön cikkben jártuk végig, cellánként. A pénzügyi szervezeteknél más a viszonyítási pont: ott a Magyar Nemzeti Bank 1/2025. (I. 13.) számú ajánlása fogalmaz meg gyakoriságot, ez azonban felügyeleti elvárás, nem jogszabály.

A kiberbiztonsági auditot nyilvántartásba vett auditor folytatja le; a technikai bizonyítékot ehhez mi állítjuk elő: reprodukálható megállapításokat, kockázati besorolást, javítási sorrendet és az újratesztelés írásos igazolását. Hogy mit kér be az auditor, és mit érdemes előre elkészíteni, a felkészülésről szóló cikkben írtuk le.

Figyelmeztető jelek

• Szkennelés penetrációs tesztként eladva. Az ilyen ajánlatot arról ismerni fel, hogy minden megállapításnál adatbázisból másolt leírás áll, a kihasználásra viszont egynél sincs bizonyíték. A sérülékenységvizsgálat önálló, olcsóbb és értelmes szolgáltatás – csak épp nem teszt, és nem is annyiba kerül. A kettőt egymás mellé tettük.
• Ár a hatókör megbeszélése előtt. Aki azelőtt mond összeget, hogy tisztázná az alkalmazások, a szerepkörök és az integrációk számát, az vagy tippel, vagy szkennelést fog eladni. Az árat mozgató tényezőket külön cikkben szedtük össze.
• Újratesztelés nélküli ajánlat. A javítások ellenőrzése nélkül a tesztből feladatlista lesz, amelyet soha senki nem vesz át.
• Nevek nélküli „tanúsított szakértői csapat”. Egyetlen név és egyetlen ellenőrizhető azonosító nélkül ez marketing, nem referencia.
• Hibakeresés és javítás ugyanattól a vállalkozótól. Aki felméri a hibát, majd pénzért maga zárja le, pontosan azt a függetlenséget veszíti el, amiért az auditor egyáltalán elfogadja a jelentését.
• Hatályon kívüli jogszabályra hivatkozó ajánlat. A 2023. évi XXIII. törvényt és a 2013. évi L. törvényt (Ibtv.) a Kiberbiztonsági tv. 2025. január 1-jei hatállyal hatályon kívül helyezte (128. §, illetve 116. §). Aki 2026-ban ezekre hivatkozik – vagy azt állítja, hogy a NIS2 miatt évente kötelező a penetrációs teszt –, nem követi azt a szabályozást, amelyből él.

Öt kérdés az aláírás előtt

1. Ki tesztel, név szerint, és milyen tanúsítvánnyal? A működő rendszeren letett gyakorlati vizsgához kötött tanúsítvány számít. A CISSP és a CISA értékes a csapatban, a tesztelői képességet viszont nem igazolja.
2. Kapok-e a döntés előtt névtelenített mintajelentést? Aláírás előtt, ne utána.
3. Milyen módszertan szerint dolgoznak? Az OWASP WSTG, az ASVS és a többi módszertan attól hasznos, hogy a lefedettség ellenőrizhetővé válik, és a különböző évek jelentései összehasonlíthatók.
4. Mi lesz a tesztadatokkal? A tárolás helye és ideje, a törlés időpontja, a hozzáférés köre – és hogy van-e a vállalkozónak szakmai felelősségbiztosítása.
5. Benne van-e az újratesztelés az árban, és ha nincs, mennyibe kerül, meddig hívható le? A „majd megbeszéljük” válasz azt jelenti, hogy nem fogják megbeszélni.

A hatodik kérdés a legkevésbé technikai, és a legtöbbet mondja: megmondja-e a vállalkozó azt is, mikor nincs szükség tesztre? Aki minden megkeresésre ugyanazt az ajánlatot küldi, nem értette meg a hatókört. Néha értelmesebb első lépés a social engineering vizsgálat, ha a kockázat az embereknél ül, vagy a Red Teaming, ha a kérdés nem az, hogy be lehet-e jutni, hanem az, hogy észreveszi-e valaki.

Etikus hacker – gyakori kérdések

Kapcsolódó Haxoris-szolgáltatások: webalkalmazások és infrastruktúra penetrációs tesztelése