Security v praxi: Od penetračného testu až po realitu kontajnerov

#1 Prečo? Ako? Čo? Penetračné testovanie

Lukáš Naď, CODECON #Bratislava 2025

Penetračné testovanie je jedna z tých vecí, o ktorých sa v IT veľa hovorí, ale často si pod tým každý predstaví niečo iné. Niekto napríklad „hackovanie“, iný zas jednorázový audit…

Táto prednáška rieši penetračné testovanie v širšom kontexte. Ukazuje, čo reálne je, prečo vzniklo a čo od neho (ne)očakávať. Nie teoreticky, ale cez konkrétne situácie a reálny priebeh testovania.

Ale poďme si to najskôr ujasniť a uviesť na pravú mieru. Čo je vlastne penetračné testovanie? Je to riadené testovanie bezpečnosti, kde sa simuluje reálny útok na systém, aby sa odhalili zraniteľnosti skôr, než ich zneužije útočník.

Čo si z prednášky odnesieš

• aké typy penetračného testovania existujú (a čo všetko sa dá testovať)
• ako vyzerá reálny priebeh testu krok za krokom
• čo sú najčastejšie mýty, ktoré o pentestoch kolujú
• čo presne znamená „etické a kontrolované“ testovanie
• prečo dnes nestačia klasické bezpečnostné opatrenia

Prednáška je dnes dostupná online TU 👇👇:

V tomto článku ti medzitým prinášame ochutnávku toho, o čom prednáška je, bez všetkých detailov a ukážok.

Praktické veci, ktoré vieš aplikovať hneď:

Najčastejšie mýty o penetračnom testovaní

• Penetračné testovanie je len o hackovaní
  V skutočnosti ide o systematický proces, ktorý zahŕňa plánovanie, analýzu aj odporúčania.
• Penetračné testovanie je nelegálne
  Ak prebieha so súhlasom a v dohodnutom rozsahu, ide o legálnu a etickú aktivitu.
• Výsledky testu sú úplné a konečné
  Test vždy odráža len aktuálny stav a nedokáže odhaliť všetky zraniteľnosti.
• Penetračné testovanie je jednorazová aktivita
  Testovanie je potrebné opakovať, pretože systémy aj hrozby sa neustále menia.
• Penetračné testovanie je to isté ako vulnerability scan
  Scan je automatizovaný a povrchový, zatiaľ čo pentest ide do hĺbky a overuje reálnu zneužiteľnosť.

Prečo je testovanie dôležité v praxi

Keď tieto mýty odložíme bokom, realita vyzerá trochu inak. Bezpečnostné problémy často nevznikajú preto, že by boli neznáme. Ale preto, že sa neriešia včas.

Dobrý príklad je incident firmy Equifax. Zraniteľnosť bola známa, existoval na ňu patch a bola verejne dostupná niekoľko mesiacov. Napriek tomu nebola aplikovaná.

Výsledok:

• unikli osobné dáta miliónov ľudí
• obrovská finančná pokuta
• strata dôvery a reputácie

Na opačnej strane máme Microsoft a zraniteľnosti v Exchange serveri. Zraniteľnosť bola odhalená výskumníkmi a komunikovaná ďalej.

• zverejnil problém
• rýchlo vydal patch
• spolupracoval s komunitou
• poskytol odporúčania, ako znížiť riziko, kým sa systém aktualizuje

Výsledok bol úplne iný. Mnohé organizácie stihli reagovať a dopad sa výrazne znížil.

Útok nezačína exploitom, ale informáciami

Zaujímavé je, ako vyzerá samotný priebeh testovania. Nezačína to exploitom. Začína to zberom informácií.

Najprv si poskladáš obraz systému:

• aké služby bežia
• aké porty sú otvorené
• čo je dostupné zvonku

A potom narazíš napríklad na login. Tester neskúša len očakávané vstupy, ale aj tie, ktoré bežný používateľ nezadá. Napríklad jednoduchý znak v inpute. Aj takáto drobnosť môže odhaliť správanie aplikácie a naznačiť problém v databáze.

Všetky ďalšie insighty nájdeš v prednáške na našom YouTube.

---

#2 Bezpečnosť kontajnerov od tvorby až po prevádzku

Rastislav Pečík, CODECON #Bratislava 2025

Kontajnery sa veľmi rýchlo začnú brať ako niečo, čo vyriešilo problém nasadenia. A do veľkej miery to tak naozaj je. Človek si vie pripraviť prostredie vopred, zabaliť aplikáciu spolu so závislosťami a odstrániť veľkú časť problémov, ktoré vznikali pri deploymente. Zrazu má konzistentné prostredie a nemusí riešiť, prečo to funguje lokálne a nefunguje inde.

Práve preto je ľahké prehliadnuť druhú stránku celej veci. Že kontajner síce pomáha s prenositeľnosťou a prevádzkou, ale sám o sebe ešte neznamená bezpečnosť.

Táto prednáška sa pozerá na bezpečnosť kontajnerov pohľadom developera. Nie človeka, ktorý robí security full-time, ale človeka, ktorý potrebuje rozumieť, kde vzniká problém, ako sa vie z jednej zraniteľnosti stať reálny incident a čo sa s tým dá prakticky robiť.

Čo si z prednášky odnesieš

• prečo kontajner nie je automaticky bezpečný len preto, že je „izolovaný“
• ako sa vie z bežného Dockerfile stať vstupný bod do celého prostredia
• čo všetko sa dá pokaziť od imageu až po runtime v Kubernetese
• prečo má zmysel riešiť security už pri buildovaní a nie až v produkcii
• aké nástroje a princípy vedia developerovi reálne pomôcť

Prednáška je dnes dostupná online TU 👇👇:

V tomto článku ti medzitým prinášame ochutnávku toho, o čom prednáška je, bez všetkých detailov a ukážok.

Praktické veci, ktoré vieš aplikovať hneď:

Kontajner nie je bezpečný len preto, že je izolovaný

Kontajner sa často berie ako prirodzená bezpečnostná hranica. V praxi to tak ale nefunguje vždy.

Ak sa útočník dostane do zraniteľnej aplikácie, nekončí to na úrovni jedného kontajnera. V tej chvíli začnú rozhodovať oprávnenia podu, dostupný service account a to, čo má aplikácia k dispozícii v rámci prostredia. Pri nesprávnom nastavení sa dá z kontajnera pokračovať ďalej, napríklad pracovať s Kubernetes API alebo získať širší prístup v clustri. Izolácia pomáha pri nasadení.

Pri incidente rozhoduje konfigurácia a rozsah oprávnení.

Problém sa často začína oveľa skôr, než v produkcii

Zraniteľnosť sa do prostredia väčšinou nedostane až v runtime. Dostane sa tam skôr — cez image, Dockerfile, deployment alebo pipeline. Preto dáva zmysel riešiť security už v týchto fázach:

• skenovať image ešte pred nasadením
• kontrolovať konfiguráciu a deployment
• nepustiť do prostredia veci, ktoré už v tej chvíli porušujú základné pravidlá

Runtime je už len moment, keď sa problém prejaví.

Least privilege rozhoduje o tom, čo sa stane po kompromise

Veľa problémov nevzniká len kvôli zraniteľnosti samotnej, ale kvôli tomu, čo všetko kontajner ešte navyše môže robiť. Ak beží ako root, má zbytočné capabilities alebo príliš široké oprávnenia, útočník sa dostane výrazne ďalej.

Preto majú zmysel aj veci, ktoré sa často berú ako „detail“:

• pod akým používateľom kontajner beží
• aké capabilities naozaj potrebuje
• čo všetko má image navyše

Práve tieto detaily rozhodujú, či riešiš lokálny problém alebo problém celého clusteru.

Network policy určuje, kam sa útok vie dostať

Nestačí vedieť, čo aplikácia robí. Dôležité je vedieť, kam sa vie pripojiť. Ak komunikáciu neobmedzíš, kompromitovaný kontajner si vie otvoriť cestu tam, kam by sa normálne nikdy nedostal.

Network policies preto nie sú „nice to have“. Sú to hranice, ktoré určujú, či útok ostane lokálny alebo sa začne šíriť ďalej.

Chceš vidieť, ako sa z jednej zraniteľnosti stane reálny incident? Celú prednášku nájdeš na našom YouTube.