A penetrációs tesztelés költségének kiszámítása az Egyesült Királyságban létfontosságú megfelelőségi feladat azon vállalatok számára, amelyek 2026-ban kiberbiztonsági auditokat terveznek. Mivel az üzleti tranzakciók egyre inkább online zajlanak, a szigorú alkalmazásbiztonság fenntartása kulcsfontosságú az érzékeny ügyféladatbázisok védelméhez és a költséges szabályozói bírságok elkerüléséhez. Az éves penetrációs teszt megrendelése az általános ajánlásból a helyi keretrendszerek szerinti szabványos követelménnyé vált. Ez az útmutató lebontja a penetrációs tesztelési költségvetések kiszámításához használt árazási modelleket, hatóköri meghatározásokat és megfelelőségi szabványokat.
[!WARNING] Megfelelőségi kockázati figyelmeztetés: A kizárólag automatizált sérülékenységvizsgálókra való hagyatkozás nem minősül penetrációs tesztnek. A szabványos iparági keretrendszerek szerint az automatizált eszközök nem képesek azonosítani az összetett logikai hibákat, így a rendszerei sebezhetők maradnak a kézi behatolásokkal szemben.
Legfontosabb tanulságok:
- A költségek az IP-címek számától, az aktív felhasználói szerepköröktől és a hálózat összetettségétől függően változnak.
- A kisméretű webalkalmazás-penetrációs tesztek £3,500 és £6,500 között mozognak, míg az összetett vállalati hálózatok £8,000-tól indulnak.
- A CREST-akkreditált ügynökségekkel való együttműködés elengedhetetlen az olyan megfelelőségi keretrendszerek teljesítéséhez, mint az ISO 27001 vagy a PCI-DSS.
- A részletes sérülékenységi jelentés megőrzése leegyszerűsíti a strukturális javítást, mérnöki órákat megtakarítva az audit után.
A penetrációs teszt költségét meghatározó változók
A professzionális biztonsági audit tapasztalt etikus hackerek általi kézi validálást igényel. A National Cyber Security Centre (NCSC) iránymutatásai szerint a biztonsági tesztek hatókörének pontos meghatározása az első lépés a költségvetés túllépésének megelőzéséhez. Több paraméter is közvetlenül befolyásolja a munka terjedelmét és a végső árajánlatot. Ezért tisztán kell meghatároznia a célfelületeket a költségvetés elszabadulásának elkerülése érdekében.
1. Hatókör és a célpontok száma
A szerverek, külső IP-címek, belső domainek és aktív API-k száma határozza meg a teszt időtartamát. Ezenkívül egy több felhasználói hozzáférési szinttel rendelkező webalkalmazás megköveteli minden egyes jogosultsági útvonal tesztelését a jogosultságkiterjesztési kockázatok azonosítása érdekében.
2. Tesztelési módszertan: fekete doboz vs. fehér doboz
A biztonsági mérnököknek átadott információk mennyisége határozza meg a tesztelési útvonalat és végső soron a tesztelési stílust.
- Fekete dobozos tesztelés: A mérnökök csak a cél URL-t vagy IP-t kapják meg. Ez a módszer külső támadást szimulál, és több órát igényel az információgyűjtéshez és a végpontok feltérképezéséhez.
- Fehér dobozos tesztelés: A fejlesztők hozzáférést biztosítanak a forráskódhoz, hálózati diagramokhoz és adatbázis-konfigurációkhoz. Ez lehetővé teszi a mélyreható vizsgálatot, de szoros együttműködést igényel.
3. Megfelelőségi és iparági követelmények
Azoknak a brit vállalatoknak, amelyek közszféra-szerződésekre pályáznak vagy a fintech területén tevékenykednek, meghatározott biztonsági alapkövetelményeknek kell megfelelniük (mint például a Cyber Essentials Plus vagy a PCI-DSS). E audit kritériumok teljesítéséhez a tesztelő ügynökségnek speciális teszteket kell futtatnia, és ez a további megfelelőségi réteg növeli a tesztelési órákat és a végső díjat.
A penetrációs tesztelés átlagos költségei az Egyesült Királyságban 2026-ra
Hogy segítsük megfelelőségi csapatának a költségvetés-tervezést, az alábbi táblázat részletezi a biztonsági auditok átlagos költségmutatóit az Egyesült Királyságban:
| Teszt célpontja | Átlagos költségtartomány (GBP) | Ajánlott tesztelési gyakoriság | Teljesített megfelelőségi szabványok |
|---|---|---|---|
| Egyszerű webalkalmazás / API | £3,500 - £6,500 | Évente / Frissítés után | GDPR / OWASP Top 10 |
| Vállalati hálózat (belső és külső) | £8,000 - £15,000+ | Évente | ISO 27001 / PCI-DSS |
| Aktív mobilalkalmazás (iOS és Android) | £5,000 - £10,000 | Évente | OWASP MASVS |
| Felhőinfrastruktúra (AWS/Cloudflare) | £6,000 - £12,000 | Évente / Jelentős változás esetén | CIS Benchmarks |
Ezek a becslések egy olyan tanúsított ügynökség megbízását feltételezik, amely átfogó felelősségbiztosítást, valamint tapasztalt, akkreditált tesztelőket biztosít.
Hogyan épül fel egy penetrációs teszt árajánlata: egy kidolgozott példa
A legtöbb elismert brit tanácsadó cég napidíjas alapon árazza szolgáltatásait. Az árajánlat egyszerűen a becsült tesztelési napok száma megszorozva a tanácsadó napidíjával, plusz a jelentéskészítés és egy újratesztelés. Ez könnyen áttekinthetővé teszi a számítást, amint ismeri a bemeneti adatokat. A CREST-regisztrált tesztelők esetében a napidíjak jellemzően £1,000 és £1,500 között vannak naponta (2026-ra szemléltető jelleggel); a rendkívül speciális munka — egyedi vastag kliens, beágyazott vagy hardveres tesztelés — többe kerül.
Vegyünk egy reális forgatókönyvet: egy közepes méretű SaaS-vállalkozás megrendeli éves értékelését. A hatókörbe tartozó eszközök egy ügyfélorientált webalkalmazás három felhasználói szerepkörrel, a mögötte lévő REST API és egy kisméretű külső hálózati perem. A teljes megbízásra egy vegyes, senior szintű, napi £1,200-os díj vonatkozik.
| Komponens | Hatóköri részletek | Becsült ráfordítás (nap) | Részösszeg £1,200/nap mellett |
|---|---|---|---|
| Webalkalmazás (hitelesített) | 3 felhasználói szerepkör, ~25 dinamikus oldal | 5.0 | £6,000 |
| REST API | ~40 végpont | 2.5 | £3,000 |
| Külső hálózat | 12 aktív IP-cím | 1.5 | £1,800 |
| Jelentéskészítés & minőségbiztosítás | Az eredmények dokumentálása, vezetői összefoglaló, szakértői felülvizsgálat | 1.5 | £1,800 |
| Javítás utáni újratesztelés | A kritikus és magas súlyosságú javítások ellenőrzése | 1.0 | £1,200 |
| Összesen | — | 11.5 nap | £13,800 |
A körülbelül £13,800-as fő összeg tehát nem egy rejtélyes átalánydíj. Ez 11.5 nap ráfordítás egy £1,200-os vegyes díjszabás mellett. Maguk a napszámok egy hatóköri kérdőívből származnak: a tesztelő jogosultsági útvonalanként, végpontklaszterenként és hálózati szegmensenként becsli meg az órákat, majd értelmes fél napokra kerekít. Változtasson meg bármely bemeneti adatot, és az ár kiszámíthatóan mozdul. Adjon hozzá egy natív mobilalkalmazást, és nagyjából 4-6 nappal (£4,800–£7,200) többet ad hozzá. Ragaszkodjon egy teljesen fekete dobozos megbízáshoz, és önmagában a felderítés egy-két napot is hozzáadhat, mert a csapatnak a nulláról kell feltérképeznie azt, amit egy fehér dobozos leírás átadott volna.
A legtöbb ügynökség ezt fix áras árajánlatként mutatja be, nem pedig nyílt napidíjként, miután a napi becslésüket egyetlen összegre alakították. A gyakorlati különbség a szerződéskötéskor számít: a fix ár megvédi Önt, ha a munka elhúzódik, de csak a megállapodott hatókörön belül, így minden, ami az eredeti határokon kívül derül ki, módosítási kérelemmé válik. Aláírás előtt mindig erősítse meg, hogy mit feltételez az árajánlat — a beépített napok számát, azt, hogy egy újratesztelés benne van-e, és hogyan kezelik a hatókörön kívüli megállapításokat. Egy olyan szállító, amely nem tudja fix árát visszabontani napokra és díjakra, megkérdőjelezésre érdemes szállító.
Miből áll össze a fő ár: tételes lebontás
Még egyetlen megbízáson belül is a díj sokkal többet fed le, mint a kézzelfogható, billentyűzet melletti kihasználás. Annak megértése, hogyan oszlik meg a ráfordítás, segít az árajánlatok azonos alapon történő összehasonlításában, és abban, hogy kiszúrja azt a szállítót, amely alultervezte a kevésbé látványos szakaszokat.
| Szakasz | Mit fed le | A ráfordítás jellemző aránya |
|---|---|---|
| Hatókör-meghatározás & előkészítés | Kérdőív, együttműködési szabályok, írásos engedélyezés | 5–10% |
| Felderítés & feltérképezés | A támadási felület felmérése, a végpontok katalogizálása | 10–15% |
| Aktív tesztelés & kihasználás | Kézi tesztelés, megállapítások láncolása, jogosultságkiterjesztés | 45–55% |
| Jelentéskészítés & minőségbiztosítási felülvizsgálat | Dokumentálás, súlyossági besorolások, senior szakértői felülvizsgálat | 20–25% |
| Javítás utáni újratesztelés | A csapata által javított problémák újratesztelése | 5–10% |
A jelentéskészítési szakasz sok első alkalommal vásárlót meglep. Egy olyan teszt, amely komoly problémákat talál, de rosszul dokumentálja azokat, szinte értéktelen: a mérnökei nem tudják reprodukálni vagy rangsorolni azt, amit nem értenek. Amikor két árajánlatot elemez, és az egyik feltűnően olcsóbb, ellenőrizze, hogy nem tömörítette-e csendben a jelentéskészítést és az újratesztelést — általában itt spórolnak.
Folyamatos és rejtett költségek, amelyekre költségvetést kell terveznie
A tesztelő ügynökség számlája ritkán meséli el a teljes történetet. Egy reális éves biztonsági költségvetésnek számolnia kell ezekkel a visszatérő vagy könnyen figyelmen kívül hagyott tételekkel:
- Javítási mérnöki idő. A teszt által feltárt hibák kijavítása gyakran a legnagyobb egyedi költség, és ez a saját csapatára hárul, nem pedig a szállító számlájára. Egy tucatnyi közepes és magas súlyosságú megállapítást tartalmazó jelentés több fejlesztői hetet is felemészthet.
- Éves újratesztelés. Az olyan keretrendszerek, mint az ISO 27001 és a PCI-DSS legalább évente új értékelést várnak el, valamint célzott tesztelést minden jelentős változtatás után.
- Újratesztelési és validációs díjak. A legtöbb megbízás tartalmaz egy újratesztelési időablakot; a javítások ellenőrzése ezen időablak bezárása után általában külön kerül számlázásra.
- Köztes szkennelés és eszközök. Sok szervezet az éves tesztek között hitelesített sérülékenységvizsgálatot futtat, ami saját licencköltséggel jár.
- Belső munkatársi idő. A hatóköri egyeztetések, a környezet előkészítése és a tesztfiókok kiépítése mind olyan órákat emészt fel, amelyek ritkán jelennek meg bármely árajánlatban.
Éves ökölszabályként tervezzen teljes biztonsági tesztelési kiadással, amely nagyjából a fő tesztdíj 1.5-2-szerese, ha a javítási munkát, az újrateszteléseket és a köztes szkennelést is beleszámítjuk (szemléltető jelleggel). Kidolgozott példánkban a £13,800-as megbízás reálisan £20,000–£28,000 összes éves, mindent tartalmazó összeget jelent ehhez a munkaprogramhoz.
Mi mozdítja felfelé vagy lefelé az árat
Mivel a modell napok szorozva egy díjszabással, minden árbeli tényező végső soron a napok számát változtatja meg. Az alábbi tényezők egyik vagy másik irányba mozdítanak egy árajánlatot:
- Felfelé mozdítja: egy teljesen fekete dobozos leírás, sok felhasználói szerepkör vagy jogosultsági határ, olyan megfelelőségi rétegek, mint a PCI-DSS vagy a CBEST, amelyek meghatározott módszertanokat és bizonyítékokat írnak elő, munkaidőn kívüli tesztelés az éles környezet védelme érdekében, valamint bármilyen fizikai vagy social engineering összetevő.
- Lefelé mozdítja: egy szorosan meghatározott és jól dokumentált hatókör, fehér dobozos vagy szürke dobozos hozzáférés, több eszköz egyetlen megrendelésbe való összevonása, egy stabil kódfagyasztás a tesztelési időablakban, valamint egy állandó megbízási (retainer) kapcsolat, amely megszünteti az ismétlődő hatókör-meghatározási terhet.
Bevált gyakorlatok a tesztelési költségek kordában tartására
Ahhoz, hogy megvédje költségvetését a felfutástól, elő kell készítenie rendszereit, mielőtt az audit megkezdődik. A költségek kordában tartása érdekében kövesse ezeket az optimalizálási irányelveket:
- Tisztítsa meg az aktív kódbázisokat: Az egyértelmű OWASP sérülékenységi pontokat automatizált szkennerekkel oldja meg, mielőtt a mérnökök megkezdik a tesztelést.
- Határozzon meg egyértelmű hatóköröket: Zárja ki a célpontlistából a nem kritikus staging aldomaineket vagy a régi statikus szervereket a tesztelési órák korlátozása érdekében.
- Ellenőrizze a harmadik felek jóváhagyásait: Ha rendszerei menedzselt szervereken vannak elhelyezve, gondoskodjon a szolgáltatói engedély megszerzéséről a tesztelés blokkolásának megelőzése érdekében.
- Kösse a javításokat SLA-khoz: Gondoskodjon arról, hogy mérnökcsapata be legyen ütemezve az azonosított sérülékenységek javítására, amint megkapja a jelentéstervezetet.
Működjön együtt egy ellenőrzött brit biztonsági tanácsadóval
A költségvetését alakító elemek megértése biztosítja, hogy megfelelőségi auditjai a tervezett ütemben maradjanak. A Mecanik professzionális penetrációs tesztelési szolgáltatásokat és átfogó biztonsági tesztelést nyújt a webhelybiztonsági audit oldalon keresztül. A webalkalmazások biztonságára, a szerverek megerősítésére és az API-megfelelőségi auditokra specializálódtunk. Vegye fel velünk a kapcsolatot még ma, hogy egyeztessük hatóköri megbeszélését.
Gyakran ismételt kérdések (GYIK)
Mennyi az átlagos penetrációs teszt költsége az Egyesült Királyságban? Egy penetrációs teszt átlagos költsége az Egyesült Királyságban £3,500-tól indul egy egyszerű webalkalmazás vagy API esetén, és összetett vállalati hálózatoknál meghaladhatja a £15,000-ot. A végső árazás az IP-címek számától, az aktív végpontoktól, a felhasználói szerepköröktől és a megfelelőségi követelményektől függ.
Miért van szükségem kézi penetrációs tesztre a szkenner helyett? Az automatizált szkennerek csak ismert szignatúramintázatokat azonosítanak. Ezzel szemben egy kézi penetrációs teszt etikus hackereket alkalmaz az összetett logikai hibák azonosítására, a kisebb problémák kritikus behatolásokká láncolására és az olyan hozzáférés-kiterjesztési hibák ellenőrzésére, amelyeket a szkennerek nem tudnak kiszúrni.
Milyen gyakran végezzen egy brit vállalat penetrációs tesztet? A brit vállalatoknak legalább évente egyszer penetrációs tesztet kell végezniük az olyan megfelelőségi szabványok fenntartásához, mint az ISO 27001. Ezenkívül penetrációs tesztet kell megrendelnie jelentős funkciófrissítések bevezetése, adatbázis-struktúrák módosítása vagy felhőszolgáltató-váltás után.
Mi a CREST-akkreditáció szerepe a penetrációs tesztelésben? A CREST-akkreditáció igazolja, hogy a biztonsági ügynökség és mérnökei szigorú technikai, etikai és jogi irányelveket követnek. Egy CREST-jóváhagyott cég megbízása gyakran követelmény a megfelelőségi auditok teljesítéséhez és biztonsági helyzetének a vállalati ügyfelek felé történő igazolásához.
Mi történik, ha a penetrációs teszt kritikus sérülékenységeket azonosít? Egy professzionális tesztjelentés a sérülékenységeket súlyosság szerint kategorizálja (kritikus, magas, közepes, alacsony). Fejlesztőcsapatának azonnal javítania kell a kritikus és magas kockázatokat, a tesztelő ügynökségnek pedig validációs tesztet kell futtatnia annak megerősítésére, hogy a javítások biztonságosak.
Hozzászólások