Behatolastesztes UK - Mire Szamithat 2026-Ban

Az Egyesult Kiralyságban a behatolastesztes szolgáltatások iránti keresések több mint 35%-kal nőttek 2023 és 2025 között, amelyet zsarolóvírusos incidensek, szigorodó szabályozási kötelezettségek és a biztosítók egy hulláma hajtott, akik aktív biztonsági tesztelés igazolását követelik meg a kiberpolitikák kibocsátása előtt. E kereslet ellenére még mindig széles körű a zavar azzal kapcsolatban, hogy valójában mi is a behatolásteszt, miben tér el a sebezhetőségi szkenneléstől, és mennyibe kerül egy jó.

Ez az útmutató teljes képet nyújt: mi a behatolásteszt és mi nem az, a főbb típusok, hogyan zajlik a folyamat, mit kell tartalmaznia az eredménynek, melyek a fontos minősítések az Egyesult Királyságban, és reális koltségtartományok 2026-ra.

Rövid összefoglaló

• A behatolásteszt egy felhatalmazott tesztelő által végrehajtott szimulált támadás, aki ugyanazokat a technikákat alkalmazza, mint a valódi támadók. Nem ugyanaz, mint a sebezhetőségi szkennelés, amely automatizált, és nem képes sebezhetőségeket láncolni vagy valós hatást felmérni.
• A tesztelők több sebezhetőséget láncolnak össze a tényleges hatás demonstrálása érdekében, nem csupán felsorolják az egyes problémákat. Ez teszi a módszertant különlegessé és értékessé.
• Az Egyesult Királyságban a PCI DSS éves behatolástesztelést ír elő, és az UK GDPR 32. cikke, az ISO 27001 és az NCSC iránymutatásai mind a rendszeres behatolástesztelést jelölik meg a megfelelő műszaki ellenőrzések bizonyítékaként.
• CREST akkreditált szolgáltatók esetén keresse a CRT (webalkalmazás), CCT App (webalkalmazás) vagy CCT Inf (infrastruktúra) minősítéseket. A közszféra munkáihoz a CHECK rendszer vonatkozik.

Mi a behatolásteszt (és mi nem az)

A behatolásteszt egy meghatározott célpont ellen irányuló strukturált, felhatalmazott támadásszimulációt jelent. A tesztelő ugyanazokat az eszközöket, technikákat és gondolkodási folyamatokat alkalmazza, mint egy rosszindulatú támadó, de megállapodott hatókörön és részvételi szabályokon belül működik. A cél a sebezhetőségek azonosítása és valós kihasználhatóságuk demonstrálása, mielőtt egy valódi támadó megtenné azt.

A sebezhetőségi szkennelés nem behatolásteszt. Egy automatizált szkenner ismert sebezhetőségek adatbázisával szemben vizsgálja a rendszereket, és megállapítások listáját állítja elő. Gyors és megismételhető, de nem képes kontextust értelmezni, megállapításokat láncolni, üzleti logikát értékelni, vagy az általa talált dolgok tényleges hatását demonstrálni. Sok szervezet összekeveri a kettőt, és egyes gyártók szándékosan elmossák a határt. Ha egy szállító “behatolástesztelésre” kínál ajánlatot, és az egész feladat manuális elemzés nélkül, csupán egy eszközből fut, akkor prémium áron vásárolt sebezhetőségi szkennelésen.

A különbség a gyakorlatban fontos. A sebezhetőségi szkennelés jelezheti, hogy az alkalmazásán fiókzár nélküli bejelentkezési űrlap található. A behatolásteszt tovább megy: a tesztelő megpróbálja kihasználni ezt egy felhasználónév-felsorolási gyengeséggel és egy kiszámítható munkamenet-tokennel együtt, hogy teljes fiókhatalombavételi láncot demonstráljon. Ez a különbség egy kockázat fellistázása és annak bizonyítása között.

A behatolástesztek típusai

Tudásszint szerint. A teszteket általában fekete doboz, szürke doboz vagy fehér doboz kategóriákba sorolják, attól függően, mennyi információt kap a tesztelő a kezdetben:

• Fekete doboz: a tesztelő a célpontról semmilyen előzetes ismerettel nem rendelkezik, és egy külső támadót szimulál, aki saját felderítést végzett. A legközelebb áll egy valós támadási forgatókönyvhöz, de időigényes lehet, mivel a tesztelő az engagement idejét olyan feladatokra fordítja (mint az alkalmazás feltérképezése), amelyeket Ön biztosíthatna.
• Szürke doboz: a tesztelő bizonyos információkat kap, jellemzően felhasználói hitelesítő adatokat és dokumentációt, de nem forráskódot vagy teljes architektúradiagramokat. Webalkalmazás-teszteknél a leggyakoribb választás, mivel egyensúlyt teremt a realizmus és a hatékonyság között.
• Fehér doboz: a tesztelőnek teljes hozzáférése van, beleértve a forráskódot, az architektúra-dokumentációt és az infrastruktúra-diagramokat. Átfogó értékelésekhez és megfelelési vezérelt kódellenőrzésekhez használják. A sebezhetőségek legnagyobb arányát találja meg, de a legtöbb felkészülést igényli a csapatától.

Célpont típusa szerint. A általános kategóriák a következők:

• Hálózati behatolásteszt: külső vagy belső infrastruktúra, tűzfalszabályok, VPN-konfiguráció, oldalirányú mozgási lehetőségek
• Webalkalmazás behatolásteszt: az OWASP Top 10 és azon túl, beleértve a hitelesítést, munkamenet-kezelést, bemeneti ellenőrzést és üzleti logikát
• API behatolásteszt: REST és GraphQL végpontok, hitelesítési megkerülés, tömeges hozzárendelés, sebességkorlátozás és adatkitettség
• Mobilalkalmazás behatolásteszt: Android és iOS alkalmazások, nem biztonságos adattárolás, tanúsítvány-rögzítési megkerülés és a mobil rétegen keresztül kitett háttéri API-problémák
• Szociális mérnökség: adathalász szimuláció, pretext és vishing (hangalapú adathalászat) az emberi réteg teszteléséhez
• Fizikai behatolásteszt: tailgating, RFID-klónozás, hozzáférési ellenőrzés megkerülése, fizikai helyszínek célzása

A legtöbb brit vállalkozás webalkalmazás- vagy hálózatteszttel kezdi, és bővíti a hatókört, ahogy biztonsági programjuk érik.

A behatolásteszt folyamata

A szigorú behatolásteszt meghatározott módszertant követ. A CREST és a PTES (Penetration Testing Execution Standard) keretrendszerek hasonló sorrendet írnak le:

Hatókör meghatározása és részvételi szabályok

Mielőtt a tesztelés megkezdődne, Ön és a szolgáltató megállapodnak a célpontban, a teszttípusban, a tesztelési ablakokban (egyes szervezetek munkaidőn kívüli tesztelést igényelnek az éles környezetre gyakorolt hatás elkerülése érdekében), az eszkalációs eljárásokban, ha kritikus megállapítást tesznek a teszt közepén, és abban, hogy mi esik explicit módon a hatókörön kívül. Ezt írásban rögzítse. A felhatalmazási levél mindkét felet védi.

Felderítés

A tesztelő passzív eszközökkel (nyílt forráskódú hírszerzés, tanúsítvány-átláthatósági naplók, a technológiai stacket feltáró álláshirdetések, megsértett adatbázisokban kiszivárgott hitelesítő adatok) és aktív eszközökkel (DNS-felsorolás, portszkenneléss, szolgáltatás-ujjlenyomat) gyűjt információt a célpontról. Fekete doboz tesztnél ez a fázis az engagement idő jelentős részét igénybe veheti.

Kihasználás

A tesztelő megpróbálja kihasználni az azonosított sebezhetőségeket a kezdeti hozzáférés megszerzéséhez vagy a hatás demonstrálásához. Itt tér el a módszertan a szkennelestől: egy képzett tesztelő több útvonalat próbál ki, alkalmazkodik, ha az egyik út le van zárva, és kisebb súlyosságú problémák kombinációit keresi, amelyek együttesen nagy hatású eredményt produkálnak.

Post-exploitation és sebezhetőségláncolás

Ez az a fázis, amelyet a legtöbb szállítói marketing figyelmen kívül hagy. A kezdeti hozzáférés megszerzése után mit tehet ténylegesen egy támadó? Egy webalkalmazást értékelő tesztelő láncolhat XSS sebezhetőséget egy CSRF gyengeséggel és egy kiszámítható munkamenet-azonosítóval, hogy teljes fiókhatalombavételt demonstráljon. Az infrastruktúránál a post-exploitation magában foglalja a jogosultsági szint emelését, az oldalirányú mozgást és annak meghatározását, hogy milyen adatokhoz vagy rendszerekhez lehet hozzáférni a kezdeti támaszkodópontból.

A láncolás kritikus fontosságú, mert átkeretezi a kockázatot. Egy CVSS 5.5 (Közepes) egyedi megállapítás egészen más beszélgetéssé válik, ha be tudja mutatni, hogy két másikkal kombinálva kihasználható az ügyféladatbázis kiszűrésére.

Jelentéskészítés

A tesztelő dokumentálja az összes megállapítást, megírja a jelentést, és az egyeztetett határidőn belül leszállítja azt (jellemzően öt-tíz munkanappal a tesztelés befejezése után). A következő szakasz részletezi, mit kell tartalmaznia a jelentésnek.

Amit egy minőségi behatolásteszt-jelentésnek tartalmaznia kell

A professzionális behatolásteszt-jelentés az Ön csapatának munkaanyaga, nem a szolgáltató értékesítési eszköze. A következőket kell tartalmaznia:

Vezetői összefoglaló. A feladat nem technikai áttekintése, az általános kockázati állapot, a megállapítások száma és súlyossága, valamint a legkritikusabb problémák. Igazgatósági szintű olvasónak szánva, akinek döntéseket kell hoznia, nem fejlesztőnek, akinek kódot kell javítania.

Hatókör és módszertan. Mi lett tesztelve, hogyan lett tesztelve, és minden korlátozás (például ha bizonyos URL-eket kizártak, vagy a tesztelés munkaidőre korlátozódott).

Kockázat szerint rangsorolt megállapítások. Minden sebezhetőség felsorolva súlyossági besorolással. A legtöbb brit professzionális szolgáltató CVSS 3.1 pontszámokat használ az Ön konkrét környezetét figyelembe vevő kontextuális kockázati besorolással együtt. Önálló CVSS-pontszám félrevezető lehet; a 7.5-ös megállapítás külső hozzáférési vektor nélkül más kockázatot jelent, mint ugyanez a pontszám egy nyilvánosan elérhető végponton.

Technikai részletek és reprodukciós lépések. Elegendő információ a fejlesztők számára a megállapítás reprodukálásához, annak megértéséhez, miért kihasználható, és a javítás ellenőrzéséhez. Ez a következőket jelenti: pontos kérések és válaszok, használt payloadok, képernyőképek ahol hasznos.

Helyreállítási útmutató. Konkrét, megvalósítható tanácsok minden egyes megállapításhoz. Nem “frissítse a függőségeit”, hanem “frissítse az X könyvtárat a 2.3.1-es verzióról a 2.4.0-ra, és távolítsa el az elavult sorosítási hívást a UserController.php 247. sorából.”

Újratesztelési nyilatkozat. Megerősítés arról, hogy az újratesztelés szerepel-e a csomagban, és ha igen, hogyan zárják le a megállapításokat. Egy megállapítás nem tekinthető megoldottnak, amíg egy tesztelő ezt meg nem erősíti.

Az Egyesult Királyság megfelelési kötelezettségei a behatolástesztelésben

PCI DSS. Minden vállalkozásnak, amely bankkártyaadatokat dolgoz fel, tárol vagy továbbít, legalább évente behatolástesztet kell végrehajtania, és minden jelentős infrastruktúra- vagy alkalmazásváltoztatás után is. A PCI DSS v4.0, amely 2024 márciusában vált az egyetlen aktív verzióvá, frissített követelményeket tartalmaz a behatolásteszt hatókörére és módszertanára vonatkozóan. Ez kötelező követelmény, nem ajánlás.

UK GDPR 32. cikk. Szervezetektől megköveteli a megfelelő technikai intézkedések bevezetését a kockázatnak megfelelő biztonság biztosítása érdekében. A behatolásteszt a legközvetlenebb módja annak igazolására, hogy aktívan felmérte, működnek-e a műszaki ellenőrzések. Az ICO hivatkozott a biztonsági tesztelésre végrehajtási határozatokban.

ISO 27001. Az A. melléklet 8.8-as vezérlője a technikai sebezhetőségek kezelését tárgyalja, és a behatolásteszt szabványos módszer ennek a vezérlőnek a teljesítéséhez. Ha ISO 27001 tanúsítás felé törekszik, a könyvvizsgálója tesztelési bizonyítékot vár.

Cyber Essentials Plus. Az egyesult királysági kormány Cyber Essentials programjának magasabb szintje helyszíni értékelést és sebezhetőségi szkennelést tartalmaz. Bár a Cyber Essentials Plus nem behatolásteszt, ennek megszerzése és az általa megállapított alapvonal fenntartása ésszerű előfeltétel.

NCSC útmutatás. A Nemzeti Kiberbiztonsági Központ a “10 lépés a kiberbiztonsághoz” keretrendszer részeként ajánlja a behatolástesztelést, különösen a “Sebezhetőségkezelés” és a “Hálózatbiztonság” lépések alatt.

CREST minősítések és miért fontosak

A CREST az Egyesult Királyság elsődleges akkreditációs szervezete a behatolástesztelő cégek és az egyéni tesztelők számára. A CREST-regisztrált szolgáltatókat folyamataik, módszertanuk és az érzékeny adatok megfelelő kezelésére való képességük alapján értékelik. Az egyéni tesztelők a következő minősítéseket szerezhetik:

• CREST Registered Tester (CRT): belépő szintű tanúsítvány, amely webalkalmazás- vagy infrastruktúra-tesztelési technikai kompetenciát igazol.
• CREST Certified Tester - Application (CCT App): fejlett tanúsítvány webalkalmazás-behatolásteszteléshez. Gyakorlati vizsga sikeres teljesítését igényli.
• CREST Certified Tester - Infrastructure (CCT Inf): egyenértékű tanúsítvány hálózati és infrastruktúra-teszteléshez.

Az Egyesult Királyság közszféra-szervei számára a CHECK rendszer vonatkozik. A CHECK az NCSC által kezelt rendszer, amely megköveteli, hogy a behatolástesztelők CHECK Team Member vagy CHECK Team Leader státusszal rendelkezzenek. Ha Ön kormányzati szerv, NHS testület vagy helyi hatóság, a szolgáltatójának CHECK státusszal kell rendelkeznie.

A szolgáltatók értékelésénél kérje a feladatán dolgozó tesztelők által tartott konkrét minősítések megtekintését, nem a cég legmagasabb rangú munkatársainak minősítéseit. Az Ön jelentését megíró és a tesztet elvégző személy az a minősítés, amely számít.

Milyen gyakran érdemes tesztelni?

A helyes válasz az Ön kockázati profiljától függ, de a gyakorlati minimumok a következők:

• Évente legalább egyszer minden internetnek kitett, személyes adatokat vagy fizetési adatokat kezelő alkalmazás esetén
• Főbb kiadások után, amelyek új funkcionalitást, új hitelesítési folyamatokat vagy új integrációkat vezet be
• Élesítés előtt olyan új termékkel, alkalmazással vagy szolgáltatással, amely először fog személyes vagy fizetési adatokat feldolgozni
• Biztonsági incidens után, hogy megértse, hagyott-e hátra a támadó perzisztenciamechanizmusokat, vagy kihasznált-e olyan sebezhetőségeket, amelyeket még nem zártak le
• Amikor a kockázati profil változik, például fúzió, felvásárlás vagy a felhasználói bázis jelentős bővítése után

Behatolástesztelés költségei az Egyesult Királyságban

Az árak a 2026-os brit piaci árakat tükrözik. A tartományoknál lényegesen alacsonyabb ajánlatok általában minimális manuális elemzéssel rendelkező automatizált szkennelésre utalnak.

A Mecanik behatolástesztelési szolgáltatás webalkalmazás-, API- és infrastruktúra-tesztelést fed le brit vállalkozások számára, PTES és OWASP módszertant alkalmazva, proof-of-concept exploitokkal és priorizált helyreállítási jelentéssel.

Főbb tanulságok

• A behatolásteszt egy manuális, felhatalmazott támadásszimulació. Kategorikusan különbözik az automatizált sebezhetőségi szkenneléstől.
• A tesztelők több sebezhetőséget láncolnak össze a valódi hatás demonstrálásához, nem csupán felsorolják az egyes problémákat izoláltan.
• Az Egyesult Királyság megfelelési kötelezettségei (PCI DSS, UK GDPR 32. cikk, ISO 27001, NCSC iránymutatás) mind a rendszeres behatolástesztelést jelölik meg alap biztonsági gyakorlatként.
• A minőségi jelentés kockázat szerint rangsorolt megállapításokat, technikai reprodukciós lépéseket, kontextuális értékelésekkel ellátott CVSS-pontszámokat és minden egyes problémához konkrét helyreállítási útmutatást tartalmaz.
• A minősítések tekintetében keresse a CREST CRT, CCT App vagy CCT Inf tanúsítványokat az engagement egyéni tesztelőire vonatkozóan. A közszféra munkáihoz a CHECK rendszer státusz szükséges.
• Teszteljen évente legalább egyszer, főbb kiadások után, és minden személyes adatokat vagy fizetési adatokat kezelő új szolgáltatás élesítése előtt.

Gygyakran Ismételt Kérdések (GYIK)

Mi a különbség a behatolásteszt és a sebezhetőségi szkennelés között? A sebezhetőségi szkennelés automatizált eszközöket használ a rendszerek ismert problémák adatbázisával szemben való ellenőrzéséhez. A behatolásteszt emberi tesztelőt foglal magában, aki okoskodik a célpontról, láncolja a sebezhetőségeket, és demonstrálja a tényleges kihasználhatóságot. A szkennelések gyorsak és hasznosak az alapvonal meghatározásához; nem helyettesítik a manuális tesztelést.

Mennyi ideig tart egy behatolásteszt? Egy közepes bonyolultságú oldal webalkalmazás-tesztje jellemzően három-öt nap tesztelési időt vesz igénybe. Nagy alkalmazások, forráskód-áttekintéssel járó fehér doboz megbízások, vagy sok hoston átnyúló infrastruktúra-tesztek tovább tartanak. A hatókör-meghatározás és a jelentéskészítés további időt vesz igénybe, ezért a megbízás megkezdésétől a végső jelentés kézbesítéséig két-négy hetet számítson.

Értesíteni kell a tárhely-szolgáltatót a behatolásteszt előtt? Ellenőrizze a tárhely- vagy felhőszolgáltató szolgáltatási feltételeit. Az AWS, az Azure és a GCP mind engedélyezi saját erőforrásainak behatolástesztelését előzetes értesítés nélkül a legtöbb szolgáltatáshoz, bár néhány korlátozás érvényes. A megosztott tárhely-szolgáltatók gyakran előzetes értesítést igényelnek. A behatolásteszt-szolgáltatónak ezt a hatókör meghatározásakor meg kell erősítenie.

Mi történik, ha a tesztelő kritikus sebezhetőséget talál a teszt során? A részvételi szabályoknak meg kell határozniuk a kritikus megállapítások eszkalációs eljárását. Egy jó hírű tesztelő azonnal felveszi Önnel a kapcsolatot, ahelyett, hogy megvárná a jelentést. Ezután Ön dönt arról, hogy szüneteltetia a tesztelést a helyreállítás alatt, folytatja a dokumentált megállapítással, vagy módosítja a hatókört.

Okozhat-e leállást egy behatolásteszt? A legtöbb tesztelési technika nem romboló, és nem okoz leállást. A denial-of-service teszteléshez kifejezett megállapodás szükséges, és általában munkaidőn kívül végzik. A tesztelőnek meg kell vitatnia bármely potenciálisan zavaró technika kockázatát, mielőtt megpróbálkozna azzal.

Hogyan ellenőrizhetem egy CREST behatolástesztelő minősítéseit? A CREST nyilvános nyilvántartást vezet a regisztrált cégekről és a tanúsított személyekről a crest-approved.org oldalon. Az állapot ellenőrzéséhez keressen cég- vagy tesztelő neve szerint. A CHECK esetén az NCSC közzéteszi a CHECK-jóváhagyott szolgáltatók listáját.