Přejít na obsah

Jak probíhá penetrační test krok za krokem

30.07.2026 | Roman Jonas

30. července 2026 od
Jak probíhá penetrační test krok za krokem
Roman Jonas

Penetrační test zní jako něco pro velké korporace s vlastním bezpečnostním oddělením. Není to pravda. Nejčastěji ho potřebuje běžná firma, která má e-shop, interní systém nebo aplikaci, na které stojí její provoz. Cílem testu je jednoduchý: najít slabá místa dřív, než je najde útočník.

Tenhle článek vás provede celým průběhem penetračního testu, fázi po fázi. Bez žargonu. Na konci budete přesně vědět, co si objednáváte, co dostanete a jak poznat dobře odvedený test od povrchního skenu.

Co je penetrační test a co jím není

Penetrační test je řízený pokus o průnik do vašeho systému. Testér se chová jako útočník, ale s vaším svolením a v předem dohodnutých mezích. Hledá zranitelnosti a snaží se je skutečně zneužít, aby ukázal reálný dopad, ne jen teoretické riziko.

Důležitý rozdíl: automatický sken zranitelností není penetrační test. Sken vám vyplivne seznam možných problémů, často s řadou falešných poplachů. Penetrační test dělá člověk, který ty nálezy ověří, zřetězí je a ukáže, kam až se dá skutečně dostat. Sken řekne „port je otevřený". Pentest řekne „tímhle portem se dostanu k vaší zákaznické databázi, tady je důkaz".

Fáze penetračního testu krok za krokem

Poctivý penetrační test má jasnou strukturu. Většina testérů vychází z uznávaných metodik jako OWASP Testing Guide pro webové aplikace nebo PTES. V praxi to znamená sedm fází.

1. Dohoda o rozsahu a pravidlech

Nejdřív se domluví, co se testuje a co ne. Které IP adresy, domény a aplikace jsou v rozsahu. Kdy se testuje, aby se neshodil provoz. Co je zakázané, třeba útoky na dostupnost. Tahle fáze je nudná, ale rozhoduje o tom, jestli test dá smysl. Špatně nastavený rozsah znamená, že se otestuje něco jiného, než na čem vám záleží.

2. Sběr informací

Testér mapuje, co je o vašem systému veřejně dostupné. Domény, subdomény, technologie, verze softwaru, e-maily zaměstnanců, které mohly uniknout. Útočník začíná stejně. Čím víc toho o vás ví, tím snáz najde vstupní bod.

3. Skenování a mapování

Teď přichází technická analýza. Otevřené porty, běžící služby, struktura aplikace, přihlašovací formuláře, API. Tady se používají i automatické nástroje, ale jen jako výchozí bod. Výsledkem je mapa útočné plochy, tedy všech míst, kudy se dá zkusit dostat dovnitř.

4. Pokus o průnik

Jádro celého testu. Testér se pokouší zranitelnosti skutečně zneužít. Zkouší obejít přihlášení, podstrčit škodlivý vstup, dostat se k datům jiného uživatele, zvýšit si oprávnění. Každý úspěšný krok dokládá, aby se dal později zopakovat a opravit. Tady se pozná zkušenost. Automat najde známou chybu, člověk najde chybu v logice, kterou nikdo nečekal.

5. Post-exploitace

Když se testér dostane dovnitř, zjišťuje, jak daleko se dá jít. Dá se z jednoho účtu dostat k dalším? K databázi? K serveru? Tahle fáze ukazuje skutečný dopad. Jedna zranitelnost sama o sobě může vypadat neškodně. Zřetězená s dalšími dvěma vede k úplnému převzetí systému.

6. Zpráva s nálezy a prioritami

Výstup, za který platíte. Dobrá zpráva není seznam 200 varování. Je to přehledný dokument, který u každého nálezu říká, jak vážný je, jak se zneužije, jaký má dopad a jak ho opravit. Nálezy jsou seřazené podle priority, takže víte, co řešit první. Součástí bývá i shrnutí pro vedení, kterému rozumí i netechnický člověk.

7. Retest

Po opravě přichází ověření. Testér zkontroluje, jestli opravy skutečně fungují a jestli náhodou nevznikla nová díra. Bez retestu nevíte, jestli jste problém opravdu vyřešili, nebo jen zamaskovali. Poctivý dodavatel retest nabízí jako součást služby.

Black box, grey box, white box: kolik toho testér ví předem

Testy se liší podle toho, kolik informací testér dostane na začátku.

  • Black box: testér nemá nic, jen jméno cíle. Simuluje útočníka zvenku. Realistické, ale pomalejší a některé chyby nemusí najít.
  • Grey box: testér dostane běžný uživatelský účet a základní informace. Nejčastější volba, protože simuluje útočníka, který získal přístup jednoho uživatele. Dobrý poměr hloubky a ceny.
  • White box: testér má přístup ke zdrojovému kódu a dokumentaci. Najde nejvíc, protože vidí do vnitřku. Vhodné pro kritické aplikace.

Jak dlouho test trvá a co ovlivňuje cenu

Krátká odpověď: záleží na rozsahu. Test jednoduché webové aplikace zabere pár dní. Rozsáhlá infrastruktura s desítkami serverů týdny. Cenu určuje počet cílů, hloubka testu a typ (black, grey, white box). Podrobněji se cenou zabýváme v samostatném článku o tom, kolik penetrační test stojí.

Kdy penetrační test potřebujete

Nejde jen o „když se něco stane". Firmy si penetrační test objednávají, když spouští novou aplikaci nebo e-shop, když je k tomu tlačí zákazník nebo pojišťovna, když se připravují na certifikaci jako ISO 27001, nebo když se na ně vztahuje nová legislativa typu NIS2. A pak ty, které to prostě myslí s bezpečností vážně a chtějí vědět, jak na tom reálně jsou.

Časté dotazy

Neshodí penetrační test náš provoz?

Při správně dohodnutém rozsahu ne. Rizikové testy se domlouvají předem a běží mimo špičku. Proto je fáze dohody o pravidlech tak důležitá.

Jak často se má pentest dělat?

Obecně jednou ročně a vždy po větší změně systému. Nová funkce nebo migrace může otevřít díru, která tam předtím nebyla.

Dostaneme něco, čemu budeme rozumět?

Ano. Kvalitní zpráva má technickou část pro vývojáře i srozumitelné shrnutí pro vedení. Pokud dodavatel dodá jen strojový výstup ze skeneru, není to penetrační test.

Co si z toho odnést

Penetrační test není razítko ani formalita. Je to řízený pokus prolomit vaši ochranu, který skončí konkrétním seznamem toho, co opravit a v jakém pořadí. Pokud provozujete web, aplikaci nebo systém, na kterém závisí vaše tržby, je otázka spíš „kdy", ne „jestli".

Nabízíme penetrační testy webů, aplikací i interní sítě s přehlednou zprávou a retestem v ceně. Pokud si nejste jistí, jestli test potřebujete nebo v jakém rozsahu, rezervujte si nezávaznou konzultaci. Řekneme vám na rovinu, jestli a jak dokážeme pomoct.

Vlastní hosting firemního softwaru: Hetzner vs AWS vs spravovaný cloud