Penetrációs teszt: együttműködés és architektúra-szemlélet

A kép, amit egy hagyományos penetrációs teszt ad a szervezet védelmi képességeiről, valójában egy pillanatkép, hiszen a körülmények és az infrastruktúra is folyamatos változásban lehetnek. Aki még úgy gondol a pentestre, mint egy évente egyszer lefutó ellenőrző listára, valószínűleg lemarad azokról a kockázatokról, amelyek a két audit között keletkeznek.

Miről olvashat?

• Miért veszélyes, ha a biztonsági tesztelés egyetlen pillanatfelvételre korlátozódik

• Hogyan dolgozik együtt a szakértő és az AI-asszisztens egy modern pentest során

• Mit jelent az architektúra-szemlélet a felhő, az azonosságkezelés és a mesterséges intelligencia korában

• Hogyan oldja fel a Naunet-módszer a folyamatos tesztelés és a belső hozzáférési szabályok közötti feszültséget

A pontszerű biztonsági tesztelés szerepe átértékelődik

A hagyományos tesztelés logikája: egy meghatározott időszakban egy külső csapat átvizsgálja a rendszert, majd jelentést ad a talált hibákról.

A pontszerű biztonsági tesztelést gyakran megfelelési, audit- vagy ügyfélelvárások indokolják. A NIS2, az ISO 27001 és a SOC 2 eltérő módon kezelik a biztonsági intézkedések ellenőrzését, ezért a szükséges vizsgálat típusát és gyakoriságát mindig az alkalmazandó követelmények és a szervezet kockázatai alapján kell meghatározni.

A probléma nem magával a hagyományos módszerrel van, inkább azzal, ha ez az egyetlen biztonsági visszacsatolási pont egy egész éven át.

Egy statikus, point-in-time (adott pillanatra vonatkozó) vizsgálat azt a képet rögzíti, ami a tesztelés hetében fennállt. Ha a fejlesztői csapat másnap egy új szolgáltatást élesít, vagy megváltoztat egy hozzáférési szabályt, arról már nincs friss visszaigazolás a következő auditig. A modern penetrációs teszt ezért egyre kevésbé egyszeri projekt, inkább egy folyamat, amely valós támadási útvonalakat és technikákat szimulálva térképezi fel, mi történhet egy éles incidens esetén.

Hogyan dolgozik együtt az ember és a mesterséges intelligencia egy penetrációs teszt során?

Miben erős ma egy AI-asszisztens a pentest folyamatában?

A HackerOne 2025-ös Hacker-Powered Security jelentése szerint a biztonsági kutatók 70 százaléka használ valamilyen AI-eszközt a munkafolyamatában. Ugyanakkor csupán 12 százalékuk gondolja úgy, hogy a mesterséges intelligencia teljes mértékben helyettesíthetné az emberi tesztelőt. Ugyanez a forrás azt is jelzi, hogy egy év alatt 270 százalékkal nőtt azoknak a bug bounty programoknak a száma, amelyek scope-jában már kifejezetten AI-komponens is szerepel vagy érkezett érvényes AI-vonatkozású jelentés.

Ez a két szám együtt jól leírja a jelenlegi helyzetet. Az AI-asszisztensek, például a Burp Suite-ba integrált ágensalapú (agentic) megoldások, közvetlenül a tesztelő mellett dolgozva automatizálják a rutinfeladatokat: átfésülik a minifikált JavaScript kódot, mintázatokat keresnek ismert sérülékenységi családokban, és rövid idő alatt generálnak működő koncepcióigazolást (PoC, proof of concept) egy-egy talált hibára.

Mit nem tud átvenni az AI az emberi tesztelőtől?

Az AI az üzleti logikai és több lépésből felépülő hibáknál még gyakran igényel emberi kontextust és ellenőrzést. A jogosultsági szinteken átnyúló hibák, mint az IDOR (Insecure Direct Object Reference, amikor egy felhasználó jogosultság nélkül fér hozzá más felhasználók adataihoz egy azonosító egyszerű módosításával), vagy az egymásba láncolt sérülékenységek (vulnerability chaining, amikor több önmagában alacsony súlyosságú hiba összekapcsolva komoly kockázatot jelent) jellemzően kreatív, kontextusfüggő emberi gondolkodást igényelnek.

A senior tesztelők ugyanakkor egyre gyakrabban kódolják be saját szaktudásukat egyedi szkennelési sablonokba, amivel a belső kompetencia egy része skálázhatóvá válik a csapat többi tagja számára is.

A technikai pontosság mellett könnyen háttérbe szorul egy másik szempont. A penetrációs teszt eredménye csak akkor ér valamit a döntéshozók számára, ha azt üzleti kockázati nyelvre is le lehet fordítani.

Miért nem elég egyszer évente lezárni a scope-ot?

Milyen gyorsan nő a vállalati támadási felület?

A Palo Alto Networks Unit 42 kutatócsapatának 2024-es Attack Surface Threat Reportja 265 nemzetközi vállalat adatait vizsgálta egy éven át, és azt találta, hogy egy átlagos szervezet támadási felülete havonta több mint 300 új szolgáltatással bővül. Ugyanez a kutatás azt is kimutatta, hogy a feltárt kitettségek több mint 23 százaléka kritikus IT- és biztonsági infrastruktúrát, tehát routerek, tűzfalak, VPN-ek és egyéb hálózati eszközök admin felületeit érinti.

Ha a vizsgálat scope-ja egy adott pillanatban rögzül, minden utána élesített szolgáltatás, aldomain vagy API-végpont a következő tesztelési ciklusig kimarad a validációból.

A GreyNoise kutatói arról írnak, hogy amint egy új eszköz kapcsolatba kerül az internettel, az azt folyamatosan pásztázó, jórészt jogszerű célú szolgáltatások (attack surface management, ASM) jellemzően perceken belül, a lassabb szereplők esetében legfeljebb néhány óra alatt feltérképezik. A kutatás jóindulatú szkennereket vizsgált, ezért közvetlenül nem mutatja meg a támadók reakcióidejét. Azt azonban jól érzékelteti, milyen gyorsan felderíthetővé válhat egy új internetes eszköz.

Ez a felismerés vezetett el a folyamatos penetrációs teszteléshez (continuous penetration testing) mint szemlélethez.

Mit jelent a folyamatos penetrációs tesztelés a gyakorlatban?

A koncepció lényege, hogy a külső támadásifelület-kezelés (EASM, external attack surface management) és a klasszikus pentest tevékenység ne két különálló folyamatként éljen egymás mellett. Egy folyamatos tesztelési modellben a szervezet a kockázat alapján határozhatja meg, mely jelentősebb változások után indokolt automatizált vagy manuális biztonsági ellenőrzést indítani.

Ez nem jelenti azt, hogy minden vállalatnak napi szintű, teljes körű tesztelésre lenne szüksége, inkább azt, hogy a kockázatosabb változásokat célszerű gyorsabban visszaellenőrizni, mint egy éves ciklus engedné.

Miért fontos az architektúra-szemlélet?

A támadók ritkán korlátozódnak egyetlen elszigetelt belépési pontra. Egy támadási lánc gyakran a hálózati és a felhőréteg között mozog, és pont ezek metszeténél válik élessé. A klasszikus portszkennelés önmagában egyre kevesebbet mond el egy felhő-natív környezetről: a fókusz sokkal inkább a felhőbeli azonosságkezelés (IAM, identity and access management), a platform API-k és a rendszerek közötti bizalmi kapcsolatok elemzésére tevődik át.

Ehhez társul egy viszonylag új réteg is. A vállalati rendszerekbe egyre több helyen épülnek be nagy nyelvi modellek (LLM, large language model), és ezeknek megvannak a saját sérülékenységi kategóriái, mint a prompt injection (amikor a bemeneti szöveg manipulálásával a modellt a tervezettől eltérő működésre lehet rábírni) vagy a jailbreak (a beépített korlátozások megkerülése).

A Naunet blogján bemutatott OpenClaw-eset jó illusztrációja annak, hogyan válhat egy önmagában hasznos AI-asszisztens is támadási felületté, ha az üzenetfogadás, a webes hozzáférés és a tárolt jogosultságok egyetlen futásidejű környezetben találkoznak. Ha a szervezet éles folyamataiban AI-komponens is működik, a scoping során annak biztonsági vizsgálatát is érdemes mérlegelni.

A képből gyakran hiányzik egy alábecsült elem is: az elméleti és a gyakorlati kockázat közötti különbség, amit validation gapnek szokás nevezni. Egy sérülékenységvizsgáló szkenner (vulnerability scanner) képes listázni, hogy egy komponens elméletileg érintett lehet egy ismert hibában, de nem mutatja meg, hogy az adott kontrollkörnyezetben ez valóban kihasználható-e.

A penetrációs teszt ott kezd értéket teremteni, ahol bizonyítja, hogy a hiba nemcsak papíron létezik, hanem tényleges hozzáférést vagy adatszivárgást eredményezhet.

Hogyan néz ki ez a gyakorlatban a Naunet-módszernél?

A Naunet megközelítése abból indul ki, hogy egy elszigetelt vizsgálat önmagában ritkán ad teljes képet egy szervezet kockázati profiljáról. A csapatunk szoros, partneri együttműködésben térképezi fel az ügyfél infrastruktúráját és architekturális megoldásait.

Igyekszik felszínre hozni azokat a kockázatokat is, amelyek nem egy komponensből, hanem a komponensek egymással való egyedi interakciójából adódnak.

A folyamatos penetrációs teszt dilemmájának feloldása

A folyamatosság dilemmájára, amiről az előző szekcióban volt szó, nem mindenki tud egyformán jó választ adni. A klasszikus Pentest-as-a-Service (PTaaS) platformok sokszor pontosan a fejlesztési (DEV) és az UAT (user acceptance testing) környezeteknél ütköznek korlátba, mert a belső biztonsági szabályzatok sok esetben nem engedik meg egy külső fél állandó VPN-kapcsolatát ezekhez a rendszerekhez.

A Naunet ezt a feszültséget folyamatos elköteleződéssel (continuous engagement) próbálja feloldani. A hosszabb távú partnerségek során az ügyféllel közösen, lépésről lépésre emelünk ki más-más modulokat és rendszerelemeket tesztelésre. Ez azt jelenti, hogy a fejlesztői csapat rendszeresen kap friss biztonsági visszacsatolást anélkül, hogy a hozzáférési szabályokat sérteni kellene.

A visszacsatolás riportok formájában érkezik: a web app pentest esetén például ilyen riportot készítünk.

Mit jelent a proaktív scoping a gyakorlatban?

A scoping fázisban a csapat nem passzív végrehajtóként vesz részt. Aktívan segít eldönteni, mely komponensek priorizálása indokolt, mit érdemes kizárni a vizsgálatból egy adott ciklusban, és hol van szükség a scope kiterjesztésére, hogy az erőforrások a valós kockázatokhoz igazodjanak.

Azoknak, akik korábban csak egy szűkebb terület, például egy alkalmazás egyszeri vizsgálatát fedték le, ez a fajta rugalmas, folyamatosan bővíthető megközelítés jelenti a legnagyobb elmozdulást a korábbi gyakorlathoz képest.

Az alábbi összehasonlítás tipikus működési modelleket mutat be. Az egyes szolgáltatások tartalma, hozzáférési megoldása és retest-feltételei szolgáltatónként eltérhetnek.

Ez a modell egy középvállalattól egy nemzetközi vállalatcsoportig hasonló logika szerint alkalmazható, mert a lényege nem a cégméret, inkább az architektúra összetettsége és a változás sebessége.

Mit jelent ez a döntéshozók számára?

A penetrációs teszt annál sokkal fontosabb, minthogy egyszerű pipa legyen egy megfelelőségi listán. A szervezetek rezilienciáját ma inkább a folyamatos visszacsatolás és a kontextusalapú vizsgálat határozza meg, mint egy-egy éves audit eredménye.

A szoros szakmai együttműködés, a rugalmasan bővíthető scope és az architektúra-szemlélet egymásra épülő rétegek egy kiforrott biztonsági programban, ez az irány, amelyre a Naunet-módszer is épül.

Ha szervezete most keres partnert egy sérülékenységvizsgálathoz, red team gyakorlathoz vagy compliance felkészüléshez, akár NIS2, ISO 27001 vagy SOC 2 vonatkozásban kérjen ingyenes konzultációt, ahol segítünk feltérképezni a lehetőségeket!

Díjmentes konzultációt kérek

Gyakran ismételt kérdések a penetrációs tesztelés témában

Kiválthatja-e az ágensalapú penetrációs tesztelés a hagyományos sérülékenységvizsgáló szkennereket?

A kiberbiztonsági csapatoknak (a jelenleg fennálló helyzet szerint) jellemzően mindkét megközelítésre szükségük van, mert eltérő kérdésekre adnak választ. A sérülékenységvizsgálat (vulnerability scanning) egy széles, de viszonylag sekély hálót dob ki az IT-infrastruktúrára. Jelzi, mi lehet hibás ismert sérülékenységi minták, konfigurációs hibák és elavult szoftverek alapján. Ugyanakkor sok téves riasztást is generálhat, és nem bizonyítja, hogy a hiba valóban kihasználható. Az ágensalapú (agentic) penetrációs tesztelés célzottabban, jellemzően a külső webalkalmazásokra és API-kra fókuszál. Nemcsak jelzi a hibákat, hanem megtervezi, végrehajtja és bizonyítja azok gyakorlati kihasználhatóságát, reprodukálható PoC-vel alátámasztva.

Kiválthatja-e a mesterséges intelligencia a szakértőket?

A jelenlegi adatok alapján ez nem tűnik valószínűnek belátható időn belül. Az AI jól automatizálja a repetitív feladatokat, például a kódátfésülést vagy az exploit-sablonok generálását, de a komplex üzleti logika hibái és a több lépésből álló támadási láncolatok továbbra is emberi kontextuális gondolkodást igényelnek.

Milyen gyakran érdemes penetrációs tesztet végezni?

Ez a szervezet kockázati profiljától és fejlesztési ütemétől függ, ezért nincs rá egyetlen univerzális válasz. Az évente egyszeri tesztelés önmagában egyre kevésbé tűnik elégségesnek a gyorsan változó környezetekben.

Mi a különbség a PTaaS és a hagyományos pentest között?

A fő különbség az eredmények kézbesítésében, a kollaborációban és az integrációban rejlik. A hagyományos pentest projektalapú, zárt időablakos vizsgálat, statikus jelentéssel a végén. A PTaaS (Penetration Testing as a Service) platformalapú megközelítés, folyamatosan frissülő dashboarddal és gyors retesting lehetőséggel.

Mit kell tartalmaznia egy jó penetrációs teszt jelentésnek?

Egy jól felépített pentest report nemcsak technikai leírás, inkább olyan üzleti és szakmai dokumentum, amely alapján a belső csapatok azonnal el tudják kezdeni a javítást. Ide tartozik a vizsgálati terjedelem, az alkalmazott módszertan és a tesztelési időablak bemutatása, egy vezetői összefoglaló, amely üzleti nyelven vázolja fel a kockázatokat, a validált eredmények súlyosság szerinti rangsorolása, gyakran a CVSS (Common Vulnerability Scoring System, a sérülékenységek súlyosságát számszerűsítő ipari szabvány) alapján, a reprodukciós lépések konkrét bizonyítékokkal, valamint egy gyakorlati javítási útmutató.