/ PENETRÁCIÓS TESZTELÉS

Penetrációs tesztelés

A Qyntar penetrációs tesztelése valós támadói szemszögből ellenőrzi webalkalmazásai, hálózata, felhőkörnyezete és API-jai védelmét – és olyan, kockázat szerint rangsorolt javítási tervet ad, amelyet a fejlesztők és a vezetők is azonnal használni tudnak.

Ajánlatot kérek Részletek

támadói szemlélet

manuális, nem csak automata tesztelés

reprodukálható bizonyítékok

javítást segítő jelentés

[ 01 ] / MI EZ

Mi a penetrációs tesztelés, és miben más, mint egy sérülékenységvizsgálat?

Röviden

A penetrációs tesztelés (más néven behatolásteszt vagy pentest) egy engedélyezett, kontrollált támadás-szimuláció, amely során a szakértők ugyanazokkal a módszerekkel keresnek és használnak ki sérülékenységeket, mint egy valódi támadó – de a céljuk nem a kár okozása, hanem az, hogy a hibák a rosszindulatú szereplők előtt kerüljenek elő. Az eredmény egy bizonyítékokkal alátámasztott, priorizált jelentés a javításhoz.

A sérülékenységvizsgálat (vulnerability scan) automatizált eszközökkel keresi az ismert hibákat, és hosszú listát ad vissza – sokszor téves riasztásokkal. A penetrációs teszt ennél továbbmegy: emberi szakértők értelmezik az eredményeket, láncba fűzik a gyengeségeket, és megmutatják, hogy egy támadó a gyakorlatban mit ér el velük: hozzáfér-e ügyféladatokhoz, átveheti-e egy rendszer irányítását, vagy eljuthat-e a belső hálózat kritikus pontjaihoz.

Egy jó penetrációs teszt nem azt mondja meg, hány hibája van a rendszernek, hanem azt, hogy melyik számít igazán. Egy közepes súlyú, de könnyen kihasználható jogosultsági hiba például nagyobb üzleti kockázatot jelenthet, mint egy elméletileg súlyos, de a gyakorlatban elérhetetlen sérülékenység. Ezért a jelentéseinkben a technikai besorolás mellett mindig szerepel a tényleges kihasználhatóság és az üzleti hatás is.

A tesztelés előre egyeztetett hatókörben, szabályok mentén zajlik, így a működés nem sérül. Dolgozunk black-box (előzetes információ nélkül), grey-box (korlátozott hozzáféréssel, például felhasználói fiókkal) és white-box (teljes betekintéssel) módszerrel is – a cél és a költségkeret határozza meg, melyik a leghatékonyabb. A szolgáltatás kiválóan kiegészíthető forráskód-felülvizsgálattal és felhőbiztonsági felméréssel.

Módszertanok és szabványok

OWASP WSTG
OWASP Top 10
OWASP ASVS
PTES
NIST SP 800-115
MITRE ATT&CK
OSSTMM

[ 02 ] / KINEK AJÁNLJUK

Kinek éri meg penetrációs tesztet rendelnie?

Minden szervezetnek, amelynek internetről elérhető rendszerei, érzékeny adatai vagy szabályozói elvárásai vannak. Az alábbi helyzetekben a teszt különösen indokolt.

Új vagy jelentősen módosított alkalmazás indítása előtt

Éles üzembe helyezés előtt a hibák javítása töredékébe kerül annak, mint egy incidens utáni kármentés. A teszt a go-live döntés műszaki alapja lehet.

Webshopok, ügyfélportálok és SaaS termékek üzemeltetői

Ahol ügyféladatok, fizetési folyamatok vagy több bérlős (multi-tenant) architektúra van, ott a jogosultság- és adatelválasztási hibák a legsúlyosabb kockázatok közé tartoznak.

NIS2, ISO 27001, DORA vagy PCI DSS hatálya alá tartozó szervezetek

Több keretrendszer elvárja a technikai kontrollok rendszeres, független ellenőrzését. A penetrációs teszt jelentése auditbizonyítékként is felhasználható.

Nagyvállalati ügyfelek beszállítói

Egyre több partner kér független penetrációs teszt jelentést a szerződéskötés vagy a megújítás feltételeként. Egy naprakész riport versenyelőnyt is jelenthet.

Szervezetek egy komolyabb átalakítás után

Felhőmigráció, cégfelvásárlás, új gyártási vagy irodai hálózat, új beszállítói integráció után a támadási felület megváltozik – érdemes újraellenőrizni.

Akik tudni szeretnék, mennyire állnának ellen egy valódi támadásnak

Ha a meglévő védelmi intézkedések hatékonyságáról nincs bizonyíték, a teszt objektív képet ad, és megmutatja, hova érdemes a következő biztonsági forintot fordítani.

[ 03 ] / MIT TARTALMAZ

A penetrációs tesztelési szolgáltatás elemei

A hatókört mindig a konkrét környezethez igazítjuk. Az alábbi területek jellemzően a szolgáltatás részei lehetnek, külön vagy egymással kombinálva.

Webalkalmazás-tesztelés

Az OWASP Top 10 és az ASVS szerinti ellenőrzés: hitelesítési és munkamenet-kezelési hibák, jogosultsági problémák (IDOR, privilege escalation), injekciós támadások, üzleti logikai hibák, fájlfeltöltés, kliensoldali sérülékenységek és konfigurációs hiányosságok.

API- és mikroszolgáltatás-tesztelés

REST, GraphQL és SOAP interfészek vizsgálata: objektum- és funkciószintű jogosultságok, tömeges értékadás, sebességkorlátozás hiánya, adatszivárgás és hibás hitelesítés.

Külső hálózati (external) teszt

Az internetről elérhető rendszerek felderítése és tesztelése: nyitott szolgáltatások, elavult szoftverek, hibás TLS-beállítások, elfelejtett (shadow IT) eszközök.

Belső hálózati (internal) teszt és Active Directory

Mi történik, ha egy támadó belép a hálózatba? Oldalirányú mozgás, jogosultságemelés, Active Directory-hibák, gyenge jelszavak, hibás szegmentálás és a tartományi rendszergazdai jogosultságig vezető útvonalak vizsgálata.

Felhőkörnyezetek tesztelése

AWS, Azure és Google Cloud környezetek támadói szemszögű vizsgálata: túlzott jogosultságok, hibás tárolókonfiguráció, kitett titkok, hibásan védett konténerek és Kubernetes-fürtök.

Mobilalkalmazás-tesztelés

Android és iOS alkalmazások vizsgálata az OWASP MASVS alapján: adattárolás, hálózati kommunikáció, visszafejtés elleni védelem és szerveroldali integráció.

Social engineering és fizikai tesztek

Megegyezés szerint phishing-szimuláció, telefonos manipuláció vagy fizikai behatolási kísérlet, amely az emberi és szervezeti oldal ellenállóképességét méri.

Red teaming és célzott támadás-szimuláció

Érett szervezeteknek: egy konkrét célra (például egy üzleti folyamat vagy adatbázis elérése) irányuló, több hétig tartó, valós támadást utánzó gyakorlat, amely a felderítő és védekező képességet is méri.

[ 04 ] / HOGYAN ZAJLIK

A penetrációs teszt lépései az ajánlatkéréstől az újratesztig

Átlátható folyamatban dolgozunk: a megrendelő mindig tudja, mi történik, mikor és milyen hatással lehet a rendszerre.

Hatókör és szabályok egyeztetése

Tisztázzuk a célokat, a tesztelendő rendszereket, az időablakot, a tiltott műveleteket és a kapcsolattartási rendet. Ekkor születik meg a megbízási és titoktartási keret.

Felderítés és információgyűjtés

Feltérképezzük a támadási felületet: nyilvános információk, szolgáltatások, technológiák, felhasználók és integrációk alapján.

Sérülékenységek azonosítása

Automatizált eszközökkel és kézi vizsgálattal feltárjuk a gyengeségeket, majd kiszűrjük a téves riasztásokat.

Kihasználás és hatásmérés

Ellenőrzött módon, a működés veszélyeztetése nélkül kihasználjuk a hibákat, és megmutatjuk, mi a valós üzleti hatás. Kritikus hiba esetén azonnal jelzünk.

Jelentés és vezetői összefoglaló

Technikai részletes jelentést és vezetők számára érthető összegzést adunk, minden hibához reprodukciós lépésekkel és konkrét javítási javaslattal.

Javítási támogatás és újrateszt

Átbeszéljük az eredményeket a fejlesztőkkel és az üzemeltetéssel, majd a javítások után újratesztelünk, és igazoljuk, hogy a hibák valóban megszűntek.

[ 05 ] / MIT OLD MEG

Mit old meg a penetrációs teszt, és miért éri meg?

A szolgáltatás legfontosabb értéke a bizonyosság: nem feltételezések, hanem tesztelt tények alapján dönthet arról, hová fektessen biztonsági erőforrásokat. A feltárt hibákat a támadók előtt ismeri meg, és a javítás a saját ütemezése szerint, nem egy incidens kényszerében történik.

Emellett a teszt hiteles bizonyíték az ügyfelek, a partnerek, az auditorok és a hatóságok felé, és objektív alapot ad a fejlesztők, az üzemeltetők és a vezetők közötti biztonsági egyeztetéshez is.

a valós kockázatok feltárása a támadók előtt
kockázat szerint priorizált javítási lista a fejlesztők számára
auditbizonyíték NIS2, ISO 27001, DORA és ügyfélaudit esetén
költséghatékony megelőzés az incidens utáni kármentéssel szemben
mérhető javulás az újratesztekkel

Amit kézhez kap

vezetői összefoglaló üzleti nyelven
részletes technikai jelentés reprodukciós lépésekkel
kockázat szerint besorolt hibalista (CVSS és üzleti hatás)
konkrét, megvalósítható javítási javaslatok
záró megbeszélés a fejlesztőkkel és a vezetőkkel
újrateszt és igazoló jelentés a javítások után

[ 06 ] / MIÉRT A QYNTAR

Miért a Qyntar végezze a penetrációs tesztet?

Mert a tesztet olyanok végzik, akik valóban támadtak már rendszereket, és értik, hogyan születnek döntések egy szabályozott szervezetben.

Támadói tapasztalat

A szakértőink korábban maguk is penetrációs tesztelők voltak, így nem eszközök kimenetét adják át, hanem a támadó fejével gondolkodnak.

Vezetői megértés

Az eredményt üzleti nyelvre fordítjuk, mert a csapatunkban olyan szakember is dolgozik, aki CISO-ként felelt a biztonsági döntésekért egy szabályozott szektorban.

Gyakorlati képesítések

Nálunk a tudás hands-on bizonyított: olyan képesítések alapján dolgozunk, amelyek a technikai képességet éles feladatokon, nem tesztkérdéseken mérik.

Fejlesztőbarát jelentés

A jelentés a javításra optimalizált: egyértelmű reprodukció, konkrét megoldási javaslat és újrateszt – hogy a hibák valóban megszűnjenek.

[ 07 ] / GYAKORI KÉRDÉSEK

Gyakran ismételt kérdések – penetrációs tesztelés

Mennyibe kerül a penetrációs tesztelés?

Az ár a hatókörtől függ: a tesztelt rendszerek vagy alkalmazások számától, a funkciók összetettségétől, a teszt mélységétől (black/grey/white-box) és az időigénytől. Egy egyszerűbb webalkalmazás néhány napos munka, egy összetett belső hálózat vagy red team gyakorlat több hetes. Rövid egyeztetés után fix árú ajánlatot adunk.

Mennyi ideig tart egy penetrációs teszt?

A hatókörtől függően jellemzően 1–4 hét, amelybe a tesztelés, a jelentés elkészítése és a záró megbeszélés is beletartozik. Sürgős igény esetén egyeztetünk a lehetséges ütemezésről.

Veszélyeztetheti a teszt az éles rendszerek működését?

A tesztet kontrolláltan végezzük: előre egyeztetett szabályok szerint, a kockázatos műveleteket külön jóváhagyáshoz kötve. Kritikus hiba esetén azonnal jelzünk, és kérésre a tesztet külön teszt- vagy staging-környezetben is elvégezzük.

Mi a különbség a penetrációs teszt és a sérülékenységvizsgálat között?

A sérülékenységvizsgálat automatizált eszközzel keresi az ismert hibákat. A penetrációs teszt emberi szakértelemmel értelmezi, kihasználja és láncba fűzi a gyengeségeket, így megmutatja a valós kockázatot és a támadási útvonalakat.

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

Általános ajánlás szerint legalább évente, valamint minden jelentős változás (új alkalmazás, nagyobb fejlesztés, infrastruktúra-átalakítás) után. Szabályozott szervezeteknél a keretrendszer (például NIS2, DORA, PCI DSS) is előírhat gyakoriságot.

Kapunk jelentést, amit az auditorok és az ügyfeleink is elfogadnak?

Igen. A jelentés vezetői összefoglalót, módszertani leírást, hibalistát és javítási javaslatokat tartalmaz, és auditbizonyítékként, valamint ügyfelek vagy partnerek felé is bemutatható. A javítás után kiadott újrateszt-igazolás is része a szolgáltatásnak.

Szükséges hozzáférést adnunk a teszthez?

Ez a választott módszertől függ. Black-box teszthez nincs szükség előzetes információra, grey-box esetén tesztfiókokat kérünk, white-box esetén dokumentációt vagy forráskód-hozzáférést. A hozzáférések kezelését a megbízási keretben rögzítjük.

[ 08 ] / TÍPUSOK ÉS IPARÁGAK