Mit ad egy valódi behatolásteszt — és hogyan ismersz fel egy olcsót
A legtöbb cég úgy vesz behatolástesztet, hogy nem tudja, mit ad egy jó. Itt van, mi legyen hatókörben, hogy néz ki a leadandó, és mely vészjelek jelzik, hogy egy automata szkennelést vettél szebb borítóval.
Szakmai ellenőrzés:Dezső Mező· Alapító · Mérnök, DField Solutions· 2026. máj. 14.
A legtöbb cég úgy vesz behatolástesztet, ahogy biztosítást kötne — mert egy ügyfél biztonsági kérdőíve, egy befektető vagy egy NIS2-kötelezettség azt mondta, kell egy. Ez rendben van mint kiindulás, de azt jelenti, hogy a vásárló gyakran nem tudja megkülönböztetni a valódi tesztet egy automata szkenneléstől, aminek szebb a borítója. A kettő gyökeresen mást ér, és gyökeresen mást is kerül. Ez a vásárlói oldal bontása: mit fed le valójában egy igazi behatolásteszt, hogy néz ki a leadandó, és mely vészjelek jelzik, hogy az előtted lévő ajánlat az olcsó fajta.
Mi a behatolásteszt — és mi nem
A behatolásteszt egy ellenőrzött, engedélyezett támadás a rendszered ellen, amit egy ember végez, hogy megtalálja a gyengeségeket, amelyeket egy valódi támadó kihasználna, és bebizonyítsa, milyen messzire jutna. A kulcsszó: egy ember végzi. Az automata eszközök minden modern pentest részei — gyorsan lefednek sok terepet —, de az eszköz jelölteket talál, nem következtetéseket. Egy szkenner ezer „lehetséges" problémát jelez; a tesztelő kidolgozza, melyik három láncolódik valódi betörésbe, és be is bizonyítja.
Ami a pentest nem: nem sebezhetőség-szkennelés (az automata, folyamatos és olcsó), és nem megfelelőségi audit (az egy papírmunka egy kontroll-keretrendszerhez mérve). Mindhárom hasznos. Nem felcserélhetők, és az a cég, amelyik az ajánlatban összemossa őket, vagy össze van zavarodva, vagy abban reménykedik, hogy te.
Mi van valójában hatókörben
Egy valódi feladat körül van határolva, mielőtt elkezdődik, írásban. A „teszteld a biztonságunkat" nem hatókör. Egy rendes hatókör megnevezi a célokat, a határokat és a szabályokat.
Célok · mely rendszerek vannak benne — a webalkalmazás, a publikus API, a felhőkonfiguráció, a belső hálózat, a mobilapp, és egyre inkább az LLM / AI-réteg, ha szállítasz ilyet.
Hatókörön kívül · mit nem érinthet a tesztelő — harmadik felek szolgáltatásai, amelyek nem a tieid, éles adat törlése, szolgáltatásmegtagadás. Kifejezetten kimondva, hogy semmi ne legyen kétértelmű.
A szabályok · tesztelési ablakok, kit kell hívni, ha valami eltörik, és hogy fekete-doboz (nincs belső tudás), szürke-doboz (van valamennyi) vagy fehér-doboz (teljes forráshozzáférés).
Szabványok · mihez mérik a tesztet — az OWASP Top 10 a webre, az OWASP API- és LLM-listák, ahol relevánsak, és egy elismert módszertan, hogy a lefedettség ne legyen esetleges.
A szürke- vagy fehér-doboz teszt jellemzően ugyanannyi pénzből többet talál — a forráshozzáférés átadásával a tesztelő órákat tölthet valódi kihasználással felderítés helyett. A fekete-doboz csak akkor indokolt, ha a cél kifejezetten egy nulla tudással induló külső támadó szimulálása.
A módszertan, érthetően
Egy strukturált pentest felismerhető fázisokon halad át. Neked nem kell futtatnod őket — de fel kell ismerned őket egy ajánlatban, mert az az ajánlat, amelyik nem tudja leírni a saját módszerét, valami másra szól.
Felderítés · a támadási felület feltérképezése — mi van kitéve, milyen technológiák futnak, hol vannak a belépési pontok.
Szkennelés · automata és kézi vizsgálat a jelölt gyengeségek számbavételére a körülhatárolt felületen.
Kihasználás · maga a teszt — annak bizonyítása, hogy mely jelöltek valódiak, ellenőrzött kihasználással, a hatás megmutatásával.
Kihasználás utáni szakasz · meddig jut egy megszerzett láb — jogosultság-emelés, oldalirányú mozgás, milyen adat válik elérhetővé. Ez választja el a „hibát" a „betöréstől".
Jelentés · minden megerősített találat úgy leírva, hogy reprodukálni tudd, súlyozva (jellemzően CVSS-szel), konkrét javítással.
Újrateszt · miután javítasz, a tesztelő újrafuttatja a találatokat, és ellenőrzi, hogy a javítások valóban tartottak. Az újrateszt nélküli teszt fél teszt.
A leadandó: mit kell kapnod
A jelentésnél válik el legláthatóbban az olcsó és a valódi. Egy igazi leadandó arra épül, hogy cselekedj belőle, nem hogy lefűzd.
Reprodukálható találatok · mindegyik a pontos lépésekkel, amelyek kiváltják. Ha a mérnököd nem tudja reprodukálni a jelentésből, nem lehet magabiztosan javítani.
Súlyozás, ami jelent valamit · következetesen pontozva (CVSS vagy azzal egyenértékű), hogy a kritikus utat javítsd először, és ne fulladj bele az alacsony kockázatú zajba.
Javítás, amivel cselekedni tudsz · nem „javítsd a bemenet-ellenőrzést", hanem egy konkrét javítás — ideális esetben egy pull request a saját repódba nyitva.
Egy vezetői összefoglaló · egy oldal, amit egy nem műszaki döntéshozó is elolvas: mit teszteltek, mit találtak, mi a valódi kockázat.
Egy ellenőrzött újrateszt · dokumentált megerősítés, hogy a javítások lezárták a találatokat. Ezt az anyagot kéri valójában egy ügyfél biztonsági csapata vagy egy auditor.
A 80 oldalas jelentés nem az alaposság jele — általában annak a jele, hogy egy automata szkenner nyers kimenetét bemásolták. Egy valódi jelentés rövidebb, mert minden találat benne megerősített. A hossz hiúsági mutató; a reprodukálhatóság a valódi.
Vészjelek: hogyan ismersz fel egy olcsó tesztet
Ha egy ajánlatban több is megjelenik ezek közül, egy automata szkennelést veszel behatolástesztnek álcázva.
Néhány ezer eurónál jóval olcsóbb ár · a valódi kézi tesztelés senior mérnöki idő; egy komoly webalkalmazás-teszt több tíz óra.
Megnevezett tesztelő nélkül · tudnod kell, ki végzi a munkát, és látnod a hátterét. A „csapatunk" nevek nélkül azt jelenti, hogy egy eszköz futtatta.
Kihasználás nélkül · a találatok úgy fogalmazva, hogy „ez sebezhetőnek tűnik", nem hogy „kihasználtuk, itt a bizonyíték". A „tűnik" szkenner-nyelv.
Újrateszt nélkül · ha a javításaid ellenőrzése külön kerül pénzbe, a feladatot úgy határolták, hogy az érték előtt érjen véget.
A 80 oldalas PDF mint fő érv · a mennyiség helyettesíti a megerősítést.
Hatóköri beszélgetés nélkül · egy valódi teszt egy beszélgetéssel kezdődik arról, mi van hatókörben és miért; egy sima megrendelőlap nem.
Teszt, szkennelés, audit — melyikre van valójában szükséged
Valószínűleg egynél többre van szükséged. Egy sebezhetőség-szkennelésnek folyamatosan futnia kell a pipeline-odban. Egy behatolásteszt egy nagyobb élesítés előtt, egy jelentős architektúra-változás után, és rendszeres ütemben való — az évente egyszer gyakori minimum. Megfelelőségi audit akkor történik, amikor egy keret vagy egy ügyfél megköveteli. Ha egy ügyfél kérdőíve azt mondja, „behatolásteszt", és te egy szkennelési jelentést adsz át, megbuktál a kérdésen — és fordítva.
Hogyan futtatjuk a tesztet a DField Solutionsnél
A behatolástesztet ugyanúgy futtatjuk, ahogy a többi munkánkat: előre körülhatárolva, fix árral, kézi teszteléssel az OWASP web-, API- és LLM-listái ellen, és egy leadandóval, ami arra épül, hogy cselekedj belőle. A találatok javító PR-ekként érkeznek a repódba — nem egy 80 oldalas PDF-ként —, mindegyik reprodukálható, súlyozott, és a hatása bizonyított. Egy újrateszt, miután bemerged a javításokat, a feladat része, nem felárazott extra. A sztenderd audit nagyjából két hét; a jelentés és a javító PR-ek a második hét végére megérkeznek.
Ha tesztet tervezel — egy élesítéshez, egy ügyfél biztonsági átvizsgálásához vagy egy NIS2-kötelezettséghez —, a kiberbiztonsági szolgáltatás oldal bemutatja, hogyan dolgozunk, és egy 30 perces hívás a leggyorsabb mód a hatókör meghatározására. Ha előbb az ársávok érdekelnek, az árlapon megtalálod őket.
Olyan rendszereket építettem és üzemeltettem, amiket nap mint nap valódi cégek használnak — pénzügytől a blockchain-ig, kezdő startuptól nagyobb cégig.
