⚡ LIMITED TIME Get our FREE €500+ Compliance Starter Kit
Get It Now →

Revízia pravidiel firewallu pre ISO 27001, NIS2, DORA a GDPR

Igor Petreski
14 min read
Diagram mapovania súladu pre segmentáciu siete a revíziu pravidiel firewallu

Je pondelok 07:42 ráno. CISO rastúceho poskytovateľa SaaS a FinTech služieb sleduje tri samostatné správy.

Prvá je zo SOC. Kompromitovaná vývojárska pracovná stanica sa v noci pokúsila pripojiť k internej databázovej podsieti. Sieťová prevádzka bola zablokovaná, ale analytik potrebuje potvrdiť, že pravidlo firewallu je zámerné, aktuálne a schválené.

Druhá je od veľkého podnikového zákazníka. Požaduje dôkazy, že produkčné, vývojové, podnikové a podporné prostredia sú segmentované, pravidlá firewallu sa pravidelne preskúmavajú a výnimky majú ukončenú platnosť.

Tretia je od manažéra súladu. Organizácia spadá pod NIS2 ako dôležitý subjekt poskytujúci digitálne služby, má povinnosti podľa GDPR ako sprostredkovateľ a obsluhuje zákazníkov z finančného sektora, ktorí požadujú dôkazy o riadení rizík IKT v štýle DORA. Predstavenstvo chce vedieť, či rovnaké dôkazy podľa ISO/IEC 27001:2022 dokážu odpovedať na všetky tri požiadavky.

Potom príde revízia po incidente. Vývojový server bol počas nočnej zmeny takmer vystavený internetu. Údaje zákazníkov sa nestratili, ale forenzný tím zistil niečo horšie než pôvodnú chybu: päť rokov staré pravidlo firewallu označené ako „dočasný test“ stále umožňovalo široký pohyb medzi vývojovým a produkčným prostredím. Ak by útočník získal prístup, sieť by kládla len minimálny odpor.

To je moment, keď mnohé organizácie narazia na bolestivú skutočnosť. Môžu mať firewally, VLAN, cloudové bezpečnostné skupiny a diagramy, ale nemajú zavedenú správu a riadenie segmentačných zón, vlastníctva pravidiel, dočasných prístupov, schvaľovania zmien, opätovnej certifikácie a auditných dôkazov.

V roku 2026 už tvrdenie „máme firewall“ nie je obhájiteľnou odpoveďou. Audítori, regulátori, zákazníci aj poisťovne požadujú dôkaz, že siete sú zámerne oddelené, sieťová prevádzka je riadená podľa obchodnej potreby, rizikové výnimky sú pod kontrolou a logy preukazujú účinnosť kontrol.

Prečo je správa a riadenie firewallov už témou pre predstavenstvo

Segmentácia siete sa kedysi vnímala ako technická inžinierska téma. Tímy infraštruktúry vlastnili VLAN, administrátori firewallov udržiavali súbory pravidiel, cloudové tímy spravovali bezpečnostné skupiny a útvar súladu videl počas auditov iba diagram.

Tento prevádzkový model už nefunguje.

Smernica NIS2 vyžaduje, aby základné a dôležité subjekty zaviedli primerané a proporcionálne technické, prevádzkové a organizačné opatrenia na riadenie rizík pre sieťové a informačné systémy. Article 21 zahŕňa politiky analýzy rizík, riešenie incidentov, kontinuitu činností, bezpečnosť dodávateľského reťazca, bezpečnosť pri obstarávaní a údržbe, posudzovanie účinnosti, základnú kybernetickú hygienu, riadenie prístupu a správu aktív. Riadiace orgány musia tieto opatrenia riadenia kybernetických rizík schvaľovať a dohliadať na ne.

DORA sa od 17. januára 2025 uplatňuje na mnohé finančné subjekty a mení riadenie rizík IKT na riadenú, zdokumentovanú disciplínu. Articles 5, 6 a 8 vyžadujú správu a riadenie, rámec riadenia rizík IKT a identifikáciu obchodných funkcií podporovaných IKT, informačných aktív, aktív IKT, závislostí, kritických aktív a prepojení. Articles 9, 10 a 11 sa zaoberajú ochranou, prevenciou, detekciou, reakciou a obnovou. Articles 24 až 27 vyžadujú testovanie digitálnej prevádzkovej odolnosti vrátane pokročilého testovania pre určité subjekty. Segmentácia je preto otázkou odolnosti, nie iba otázkou firewallu.

GDPR pridáva vrstvu zodpovednosti za ochranu osobných údajov. Article 32 vyžaduje primerané technické a organizačné opatrenia na zaistenie úrovne bezpečnosti primeranej riziku vrátane dôvernosti, integrity, dostupnosti a odolnosti. Article 5(1)(f) vyžaduje integritu a dôvernosť a Article 5(2) vyžaduje preukázateľnú zodpovednosť. Ak sú systémy s osobnými údajmi dostupné z kompromitovaných koncových bodov, hosťovských sietí alebo nespravovaných ciest tretích strán, dozorný orgán sa môže pýtať, prečo takéto cesty existovali.

ISO/IEC 27001:2022 poskytuje základ systému riadenia, ktorý tieto povinnosti prepája. Vyžaduje rozsah, požiadavky zainteresovaných strán, posúdenie rizík, ošetrenie rizík, vyhlásenie o aplikovateľnosti (SoA), prevádzkové plánovanie a riadenie, zodpovednosť vedenia, merateľné ciele, zdokumentované informácie a neustále zlepšovanie. Príloha A, podporená usmerneniami ISO/IEC 27002:2022, zahŕňa oblasti kontrol potrebné pre dodávateľské riziko, cloudové služby, logovanie, monitorovanie, bezpečnú architektúru, oddelenie prostredí a riadenie zmien.

Pointa je jednoduchá: segmentácia siete a revízia pravidiel firewallu sú dnes dôkazom správy a riadenia.

Prevádzkový vzor Clarysec: 8.20, 8.22 a 8.32

Clarysec pristupuje k segmentácii a revízii firewallov ako k jednému prevádzkovému vzoru naprieč kontrolami ISO/IEC 27002:2022, nie ako k izolovaným technickým úlohám.

Tri primárne kontroly sú:

Oblasť ISO/IEC 27002:2022Otázka správy a riadeniaDôkazy očakávané audítormi
8.20 Bezpečnosť sietíSú siete navrhnuté, spravované, monitorované a chránené podľa rizika?Architektonické diagramy, štandardy firewallov, postupy bezpečnej prevádzky siete, monitorovacie logy, dôkazy IDS/IPS, vzorky konfigurácie VPN a cloudovej siete
8.22 Oddelenie sietíSú zóny oddelené podľa citlivosti, funkcie a úrovne dôvery?Model zónovania, matica dátových tokov, návrh VLAN a podsietí, hranice DMZ, pravidlá firewallu medzi zónami, výsledky testov segmentácie
8.32 Riadenie zmienSú zmeny pravidiel vyhodnocované, schvaľované, testované, logované a preskúmavané?Tickety zmien, posúdenia rizík, schválenia, plány návratu do pôvodného stavu, preskúmania po implementácii, záznamy núdzových zmien

V Zenith Blueprint: An Auditor’s 30-Step Roadmap [ZB] Clarysec zaraďuje bezpečnosť sietí do fázy „Kontroly v praxi“, krok 20: kontroly 8.18 až 8.26. Príručka jasne formuluje základnú auditnú otázku:

„Vo svojej podstate táto kontrola vyžaduje, aby organizácie zabezpečili, že siete sú bezpečné už architektúrou, nielen dodatočným pridaním firewallov alebo antivírusového softvéru. Znamená to strategicky uvažovať o segmentácii siete, riadení prístupu, šifrovaní pri prenose, monitorovaní a obrane do hĺbky. Začína sa jednoduchou otázkou: Kto a čo komunikuje a malo by to komunikovať?“

Táto otázka, „kto a čo komunikuje a malo by to komunikovať?“, je najlepší praktický východiskový bod pre revíziu pravidiel firewallu. Presúva diskusiu od tisícov neprehľadných položiek ACL k obchodne odôvodneným tokom.

Rovnaký Zenith Blueprint vedie tímy k posúdeniu sieťovej architektúry overením, že pravidlá firewallu, konfigurácie IPS/IDS a vzdialeného prístupu sú aktuálne a hardenované, a potvrdením, že cloudové bezpečnostné skupiny, smerovanie a pravidlá VPC alebo podsietí zodpovedajú zamýšľanej architektúre. Audítorom tiež odporúča očakávať diagram bezpečnostnej architektúry siete, ktorý zobrazuje firewally, VPN brány, zóny DMZ, oddelenie VLAN a hranice dôvery.

Pri riadení zmien Zenith Blueprint zaraďuje kontrolu ISO/IEC 27002:2022 8.32 do fázy „Kontroly v praxi“, krok 21: kontroly 8.27 až 8.34, a zdôrazňuje, prečo správa a riadenie firewallov zlyháva, keď je riadenie zmien slabé:

„Táto kontrola uznáva tvrdú realitu v IT: mnohé incidenty nespôsobujú útoky, ale nesprávne riadené zmeny. Príliš široko otvorené pravidlo firewallu. Ponechané zapnuté ladenie. Zabudnutá závislosť po migrácii.“

Presne tak sa z dočasných otvorení firewallu stávajú trvalé cesty útoku.

Ako vyzerá dobrá segmentácia siete

Zrelý program segmentácie má štyri vrstvy.

Po prvé, má model zónovania. Zóny nie sú náhodné podsiete. Sú to hranice dôvery zosúladené s obchodnou funkciou a citlivosťou údajov, napríklad DMZ dostupná z internetu, produkčná aplikačná vrstva, produkčná databázová vrstva, podniková používateľská sieť, sieť privilegovanej správy, vývojové prostredie, testovacie prostredie, zálohovacia sieť, hosťovská Wi‑Fi, zóna OT alebo IoT a zóna prístupu tretích strán.

Po druhé, má maticu tokov. Pre každú dvojicu zón organizácia dokumentuje povolený zdroj, cieľ, protokol, port, aplikáciu, vlastníka obchodného procesu, vlastníka systému, typ údajov, odôvodnenie a požiadavku na logovanie.

Po tretie, má vlastníctvo pravidiel. Každé pravidlo firewallu, pravidlo cloudovej bezpečnostnej skupiny alebo politika softvérovo definovaného perimetra má vlastníka, dátum skončenia platnosti alebo opätovnej certifikácie, prepojený ticket zmeny a obchodné odôvodnenie. „Any to any“ sa musí považovať za auditné zistenie, pokiaľ nejde o formálne akceptované riziko, ktoré je časovo obmedzené a podporené kompenzačnými kontrolami.

Po štvrté, má opakovanú revíziu. Revízia znamená viac než raz ročne exportovať bázu pravidiel firewallu. Zahŕňa opätovnú certifikáciu vlastníkmi, porovnanie s pozorovanou prevádzkou, detekciu nepoužívaných pravidiel, overenie dočasných výnimiek, preskúmanie expozície voči internetu, testovanie segmentácie a zosúladenie s inventarizáciou aktív.

Clarysec Politika bezpečnosti sietí [P-NS] jasne stanovuje podnikové očakávanie:

„Všetka prevádzka medzi zónami musí byť riadená firewallmi alebo riešeniami softvérovo definovaného perimetra s explicitnými konfiguráciami zásady predvoleného zamietnutia.“

Z podnikovej politiky, Politika bezpečnosti sietí, časť „Požiadavky na správu a riadenie“, bod 5.2.

Rovnaká politika priamo prepája zmeny firewallu s riadením zmien:

„Každá zmena súborov pravidiel firewallu, smerovacích tabuliek alebo konfigurácií bezpečnostných skupín musí postupovať podľa Politiky riadenia zmien (P5) organizácie vrátane plánov návratu do pôvodného stavu a auditného logovania.“

Z podnikovej politiky, Politika bezpečnosti sietí, časť „Požiadavky na správu a riadenie“, bod 5.4.

Pre MSP poskytuje Clarysec Politika bezpečnosti sietí pre MSP [P-NS-SME] rovnaký princíp v prevádzkovom znení:

„Pravidlá predvoleného zamietnutia sa musia presadzovať pre všetky prichádzajúce pripojenia, pokiaľ nie sú výslovne požadované a schválené.“

Z politiky pre MSP, Politika bezpečnosti sietí pre MSP, časť „Požiadavky na implementáciu politiky“, bod 6.1.2.

A konkrétne pre segmentáciu:

„Prevádzka medzi segmentmi sa musí filtrovať a prístup medzi segmentmi sa musí riadiť zásadou minimálnych oprávnení.“

Z politiky pre MSP, Politika bezpečnosti sietí pre MSP, časť „Požiadavky na implementáciu politiky“, bod 6.2.3.

Tieto ustanovenia politík umožňujú audítorovi sledovať cestu od rizika ku kontrole, od kontroly k pravidlu, od pravidla k schváleniu a od schválenia k logom.

Jeden dôkazový balík pre ISO 27001, NIS2, DORA a GDPR

Chybou mnohých tímov je budovanie samostatných dôkazových balíkov: jeden pre ISO/IEC 27001:2022, jeden pre NIS2, jeden pre GDPR, jeden pre zákazníkov s požiadavkami DORA a jeden pre kybernetické poistenie.

Lepším prístupom je vybudovať jeden dôkazový balík pre segmentáciu a správu firewallov, ktorý sa mapuje naprieč rámcami.

Zenith Controls: The Cross-Compliance Guide [ZC] mapuje kontrolu ISO/IEC 27002:2022 8.22 Oddelenie sietí ako preventívnu kontrolu podporujúcu dôvernosť, integritu a dostupnosť, zosúladenú s konceptom kybernetickej bezpečnosti Protect a prevádzkovou schopnosťou systémovej a sieťovej bezpečnosti. Prepája 8.22 s 8.20 Bezpečnosť sietí, 8.21 Bezpečnosť sieťových služieb, 8.7 Ochrana pred malvérom, 8.27 Bezpečná systémová architektúra a inžinierske princípy a 8.31 Oddelenie vývojového, testovacieho a produkčného prostredia.

Príručka vysvetľuje význam segmentácie pre NIS2 takto:

„Oddelenie sietí je priamou odpoveďou na tieto povinnosti, pretože znižuje útočnú plochu a zabraňuje laterálnemu pohybu naprieč sieťovými systémami.“

Táto veta vysvetľuje, prečo by programy kybernetickej hygieny podľa NIS2 nemali segmentáciu považovať za voliteľnú. Zamedzenie šírenia ransomvéru nie je iba o ochrane koncových bodov. Ide o obmedzenie laterálneho pohybu, keď prevencia zlyhá.

Pre GDPR Zenith Controls mapuje 8.22 na Article 32 a Recital 49 a uvádza, že sieťové diagramy a politiky zónovania sa stávajú kľúčovými dôkazmi súladu. Pre DORA Zenith Controls mapuje bezpečnosť sietí a oddelenie sietí na riadenie rizík IKT a zamedzenie šírenia incidentov. Testy segmentácie môžu podporiť dôkazy odolnosti IKT, najmä keď preukazujú, že kompromitácia v jednej zóne sa nemôže voľne presunúť do kritických finančných služieb, repozitárov osobných údajov alebo systémov privilegovanej správy.

Dôkazový artefaktPoužitie pre ISO/IEC 27001:2022 a ISO/IEC 27002:2022Použitie pre NIS2Použitie pre DORAPoužitie pre GDPR
Diagram bezpečnostnej architektúry sietePodporuje rozsah ISMS, prevádzkové riadenie, 8.20 a 8.22Preukazuje technické opatrenia na bezpečnosť sieťových a informačných systémovPreukazuje prepojenia IKT a závislosti kritických služiebPreukazuje ochranné hranice okolo systémov s osobnými údajmi
Matica zón a tokovPreukazuje oddelenie založené na riziku a zásadu minimálnych oprávneníPodporuje kybernetickú hygienu a posudzovanie účinnostiPodporuje klasifikáciu aktív IKT a závislostíPodporuje technické opatrenia a preukázateľnú zodpovednosť podľa Article 32
Záznamy z revízie pravidiel firewalluDôkaz o monitorovaní kontrol a neustálom zlepšovaníPreukazuje, že opatrenia sa preskúmavajú a nie sú statickéPodporuje preskúmanie rizík IKT a testovanie odolnostiPreukazuje priebežnú bezpečnosť spracúvania
Tickety zmien pre pravidlá firewalluPodporujú 8.32 Riadenie zmienPodporujú bezpečnú údržbu a sledovateľnosťPodporujú riadenú zmenu IKT a odolnosťPreukazujú, že zmeny ovplyvňujúce systémy s osobnými údajmi sú posúdené z hľadiska rizika
Register výnimiekPodporuje ošetrenie rizík a akceptáciu zvyškového rizikaPreukazuje dohľad manažmentu nad odchýlkamiPodporuje toleranciu rizika a správu a riadeniePreukazuje zodpovednosť za dočasnú expozíciu
Logy zablokovanej a povolenej prevádzky medzi zónamiPodporujú logovanie, monitorovanie a účinnosť kontrolPodporujú detekciu a reakciu na incidentyPodporujú klasifikáciu incidentov a oznamovaniePodporujú posúdenie porušenia ochrany údajov a uchovanie dôkazov

Táto tabuľka nie je iba mapovaním súladu. Je to plán zberu dôkazov.

Revízia pravidiel firewallu, ktorá skutočne funguje

Revízia pravidiel firewallu zlyháva, keď sa pýta iba: „Je toto pravidlo ešte potrebné?“ Vlastníci pravidiel často odpovedia áno, pretože sa obávajú, že niečo prestane fungovať.

Lepšia revízia kladie šesť otázok:

  1. Akú obchodnú službu toto pravidlo podporuje?
  2. Ktorý vlastník aktíva a vlastník údajov schválil tok?
  3. Je cieľ v správnej zóne vzhľadom na údaje a funkciu?
  4. Je pravidlo širšie, než vyžaduje pozorovaná prevádzka?
  5. Je pri vysoko rizikových tokoch zapnuté logovanie?
  6. Má pravidlo dátum preskúmania, dátum skončenia platnosti alebo záznam o výnimke?

Politika bezpečnosti sietí pre MSP vyžaduje pravidelnú revíziu:

„Poskytovateľ IT podpory musí vykonať ročnú revíziu pravidiel firewallu, sieťovej architektúry a bezdrôtových konfigurácií.“

Z politiky pre MSP, Politika bezpečnosti sietí pre MSP, časť „Požiadavky na správu a riadenie“, bod 5.6.1.

Ročná revízia je základ, nie horná hranica. Vysoko rizikové pravidlá potrebujú častejšiu opätovnú certifikáciu.

Kategória pravidlaPríkladFrekvencia revízieOčakávané schválenie
Prichádzajúca internetová prevádzka do produkcieVerejné API smerujúce na aplikačnú bránuŠtvrťročne alebo po významnom vydaníVlastník služby, bezpečnosť, schvaľovateľ zmeny
Prístup k produkčnej databáze medzi zónamiAplikačná vrstva do databázovej vrstvyŠtvrťročneVlastník aplikácie a vlastník údajov
Administrátorský prístupBastion host na porty správy serverovMesačne alebo štvrťročneVlastník infraštruktúry a delegát CISO
Prístup tretích stránVPN dodávateľa do podpornej podsieteMesačne alebo pri zmluvnom míľnikuVlastník dodávateľa a bezpečnostný tím
Dočasná výnimkaNúdzový prístup počas migráciePred skončením platnosti, maximálne 90 dníManažér ISMS alebo CISO
Štandardné interné pravidlo s nízkym rizikomMonitorovací server na spravované koncové bodyRočneVlastník služby

Politika bezpečnosti sietí je pri výnimkách explicitná:

„Žiadosť musí preskúmať a schváliť manažér ISMS alebo CISO a musí byť zaznamenaná v Registri výnimiek ISMS s maximálnou dobou schválenia 90 dní, obnoviteľnou po prehodnotení.“

Z podnikovej politiky, Politika bezpečnosti sietí, časť „Ošetrenie rizík a výnimky“, bod 7.3.

Pre MSP Politika bezpečnosti sietí pre MSP vyžaduje, aby žiadosti o výnimku obsahovali správne minimálne údaje:

„Žiadosť musí obsahovať odôvodnenie, rozsah, trvanie a kompenzačné kontroly (napr. povolenie konkrétnych IP adries, logovanie).“

Z politiky pre MSP, Politika bezpečnosti sietí pre MSP, časť „Ošetrenie rizík a výnimky“, bod 7.3.3.

Toto ustanovenie mení ošetrenie výnimiek z neformálnej komunikácie na auditovateľné ošetrenie rizík.

Praktický príklad: odstránenie rizikového pravidla produkčnej databázy

Predpokladajme, že spoločnosť počas revízie nájde toto pravidlo:

PoleAktuálna hodnota
ZdrojPodniková používateľská VLAN
CieľProdukčná databázová podsieť
PortTCP 5432
AkciaPovoliť
PoznámkaDočasný prístup pre migráciu reportingu
VytvorenéPred 14 mesiacmi
VlastníkNeznámy
LogovanieVypnuté

Ide o klasické auditné zistenie. Porušuje zásadu minimálnych oprávnení, nemá jasného vlastníka, dátum skončenia platnosti, aktuálne odôvodnenie ani logovanie. Zároveň vytvára expozíciu podľa GDPR Article 32, ak produkčná databáza obsahuje osobné údaje zákazníkov.

Proces nápravy má vytvoriť dôkazy, nielen odstrániť chybné pravidlo.

KrokAkciaReferencia ClarysecVytvorený auditný dôkaz
1. Namapovať pravidlo na model zónPotvrdiť, či podnikoví používatelia vôbec majú mať prístup do produkčnej databázovej podsieteZenith Blueprint, „Kontroly v praxi“, krok 20Aktualizované poznámky z preskúmania architektúry a klasifikácia zóny
2. Vytvoriť alebo aktualizovať záznam tokuZdokumentovať zdroj, cieľ, port, typ údajov, vlastníka, odôvodnenie a rizikoZenith Controls, mapovanie 8.22Položka v matici zón a tokov
3. Otvoriť ticket zmenyNavrhnúť odstránenie alebo nahradenie riadenou cestou reportovacej službyPolitika bezpečnosti sietí, bod 5.4Záznam zmeny s analýzou rizík, plánom testovania a plánom návratu do pôvodného stavu
4. Rozhodnúť o ošetreníOdstrániť široké pravidlo alebo ho nahradiť replikou iba na čítanie, bastion hostom, povolením konkrétnych IP adries a logovanímPolitika bezpečnosti sietí, bod 7.3Rozhodnutie o ošetrení rizika alebo časovo obmedzená výnimka
5. Zapnúť logovanie schválených tokovOdosielať vysoko rizikové udalosti firewallu medzi zónami do monitorovaniaPolitika logovania a monitorovania, bod 6.1.1.6Záznamy SIEM, pravidlá upozornení a snímky obrazovky z monitorovania
6. Overiť segmentáciuOtestovať, že databázová podsieť je nedostupná okrem schválených ciestZenith Blueprint, krok 20Výsledok testu segmentácie a uzavretie nápravy

Clarysec Politika logovania a monitorovania [P-LM] zahŕňa externú komunikáciu a spúšťače pravidiel firewallu medzi udalosti relevantné na logovanie:

„Externá komunikácia a spúšťače pravidiel firewallu.“

Z podnikovej politiky, Politika logovania a monitorovania, časť „Požiadavky na implementáciu politiky“, bod 6.1.1.6.

Pri vysoko rizikových pravidlách medzi zónami majú spúšťače firewallu smerovať do SIEM alebo monitorovacej platformy s upozorneniami na nezvyčajné zdrojové hosty, objemy alebo časové okná.

Politika pre MSP vyžaduje aj disciplínu pri zmenách:

„Všetky zmeny sieťových konfigurácií (pravidlá firewallu, ACL prepínačov, smerovacie tabuľky) musia postupovať podľa zdokumentovaného procesu riadenia zmien.“

Z politiky pre MSP, Politika bezpečnosti sietí pre MSP, časť „Požiadavky na implementáciu politiky“, bod 6.9.1.

Jedno vyčistenie tohto pravidla vytvára dôkazy pre prevádzkové riadenie podľa ISO/IEC 27001:2022, ISO/IEC 27002:2022 8.20, 8.22 a 8.32, kybernetickú hygienu podľa NIS2, GDPR Article 32 a riadenie rizík IKT v štýle DORA.

Cloud, SaaS a hybridné siete musia byť zahrnuté

Moderná segmentácia nie je len o VLAN a fyzických firewalloch. Zahŕňa bezpečnostné skupiny AWS, sieťové bezpečnostné skupiny Azure, sieťové politiky Kubernetes, cloudové smerovacie tabuľky, zoznamy povolených administrátorských prístupov v SaaS, privátne koncové body, VPN, SD-WAN, proxy zohľadňujúce identitu a kontroly softvérovo definovaného perimetra.

Pre poskytovateľa SaaS alebo regulovanú digitálnu službu má revízia pravidiel firewallu zahŕňať minimálne:

  • Vyvažovače záťaže a aplikačné brány dostupné z internetu
  • Cloudové bezpečnostné skupiny a sieťové ACL
  • Smerovacie tabuľky privátnych podsietí
  • Peeringové prepojenia a cesty cez transit gateway
  • VPN a cesty vzdialenej administrácie
  • Administrátorské rozhrania a roviny správy
  • Kubernetes ingress a sieťové politiky
  • Prístup CI/CD runnerov do produkcie
  • Pokrytie logovaním pre zamietnuté a povolené vysoko rizikové toky
  • Podporný prístup tretích strán a núdzové účty typu „break-glass“

Ak cloudová bezpečnostná skupina povoľuje prichádzajúcu databázovú prevádzku zo širokého podnikového rozsahu IP adries, zaobchádzajte s ňou ako s pravidlom firewallu. Potrebuje vlastníctvo, odôvodnenie, schválenie, revíziu, logovanie a skončenie platnosti.

Práve tu podporné normy ISO posilňujú celkový príbeh. ISO/IEC 27017 podporuje jasnosť zodpovedností za cloudovú bezpečnosť. ISO/IEC 27033 poskytuje hlbšie usmernenie k architektúre bezpečnosti sietí, DMZ, segmentačným zónam, filtrovaniu prevádzky a bezpečnej komunikácii medzi sieťami. ISO/IEC 27701 posilňuje správu ochrany osobných údajov tam, kde sa osobne identifikovateľné informácie pohybujú naprieč sieťami. ISO/IEC 27035 podporuje zamedzenie šírenia incidentov a ISO/IEC 27005 podporuje výber segmentácie ako ošetrenia rizík pri neoprávnenom prístupe, šírení malvéru a laterálnom pohybe.

Ako audítori testujú rovnakú kontrolu odlišne

Jednou zo silných stránok Zenith Controls je, že vysvetľuje, ako rôzne auditné metodiky skúmajú rovnakú kontrolu. Dôkazy možno opätovne použiť, ale otázky sa líšia.

Auditný pohľadPravdepodobná otázkaNajlepší dôkaz
Audítor ISO/IEC 27001:2022Je segmentácia vybraná, implementovaná a preskúmavaná na základe rizika?Posúdenie rizík, SoA, sieťová politika, diagramy, záznamy z revízie
Audítor v štýle ISO/IEC 27007Zodpovedajú implementované pravidlá firewallu a schémy VLAN zdokumentovanej politike?Vzorky pravidiel firewallu, ACL smerovačov, návrh VLAN, rozhovory s administrátormi
Prístup certifikačného auditu ISO/IEC 27006-1:2024Sú kritické sieťové hranice auditované s primeranou odbornosťou a plánovaním založeným na riziku?Plán auditov, technické vzorkovanie, dôkazy cloudových bezpečnostných skupín, výsledky testov
Audítor orientovaný na NISTSú hranice a informačné toky vynucované a monitorované?Pravidlá firewallu, ACL, testy segmentácie, záznamy monitorovania
Audítor COBIT 2019Je bezpečnosť sietí riadená, monitorovaná a reportovaná?Matica vlastníctva, KPI, reporting manažmentu, register rizík
Audítor ISACA ITAFFungujú všeobecné IT kontroly konzistentne?Tickety zmien, schválenia výnimiek, logy, vzorky opätovnej certifikácie pravidiel
Dozorný orgán GDPRBoli systémy s osobnými údajmi chránené primeranými technickými opatreniami?Mapy dátových tokov, izolácia zón s PII, prístupové cesty, logy firewallu
Posudzovateľ zameraný na DORAPodporuje segmentácia odolnosť IKT a zamedzenie šírenia incidentov?Mapa závislostí aktív IKT, toky kritických funkcií, playbooky incidentov, záznamy testovania

Posudzovateľ zameraný na DORA sa môže opýtať, či kompromitácia platobnej brány umožní presun do zákazníckych databáz. Príslušný orgán podľa NIS2 sa môže opýtať, či ransomvér na administrátorskej pracovnej stanici dosiahne kľúčové systémy poskytovania služieb. Orgán GDPR sa môže opýtať, aké sieťové obmedzenia chránili systémy spracúvajúce osobné údaje. Audítor ISO sa môže jednoducho opýtať na posúdenie rizík, SoA, politiku, postup a dôkazy, že revízie prebehli.

Najlepšie programy odpovedajú na všetky tieto otázky rovnakými artefaktmi.

Metriky, ktoré zviditeľnia segmentáciu pre vedenie

NIS2 aj DORA posilňujú zodpovednosť manažmentu. ISO/IEC 27001:2022 vyžaduje vedenie, ciele, roly, zdroje, reporting a neustále zlepšovanie. Segmentácia preto potrebuje metriky, ktorým vedenie rozumie.

Užitočné metriky pre manažment zahŕňajú:

  • Percento pravidiel firewallu s priradeným vlastníkom
  • Percento pravidiel so zdokumentovaným obchodným odôvodnením
  • Počet dočasných pravidiel po skončení platnosti
  • Počet pravidiel so zdrojom, cieľom alebo službou „any“
  • Počet služieb vystavených internetu podľa kritickosti
  • Percento vysoko rizikových tokov medzi zónami so zapnutým logovaním
  • Počet núdzových zmien firewallu za štvrťrok
  • Percento vzorkovaných pravidiel priradených k schváleným ticketom zmien
  • Počet zlyhaní testov segmentácie
  • Priemerný čas nápravy rizikových alebo nepoužívaných pravidiel
  • Počet výnimiek starších ako 90 dní
  • Počet pravidiel prístupu tretích strán, ktoré boli preskúmané a opätovne certifikované

Politika bezpečnosti sietí identifikuje „účinnosť pravidiel firewallu“ ako aspekt súladu a uplatňovania politiky v časti „Uplatňovanie politiky a súlad“, bod 8.2.2. Táto formulácia je dôležitá, pretože samotná existencia pravidiel nestačí. Pravidlá musia byť účinné, preskúmavané a zosúladené s aktuálnym rizikom.

Vybudujte dôkazový balík segmentácie pre rok 2026

Praktický dôkazový balík pre segmentáciu a revíziu pravidiel firewallu má byť pripravený skôr, než si ho audítor vyžiada.

Minimálne udržiavajte:

  1. Aktuálny diagram sieťovej architektúry vrátane cloudových a hybridných zón
  2. Štandard klasifikácie zón vrátane citlivosti a úrovne dôvery
  3. Maticu tokov pre kritické služby a systémy s osobnými údajmi
  4. Export pravidiel firewallu a cloudových bezpečnostných skupín
  5. Register vlastníkov pravidiel a opätovnej certifikácie
  6. Postup revízie firewallu a kalendár revízií
  7. Záznamy zmien pre vzorkované úpravy firewallu
  8. Register výnimiek so schváleniami, skončením platnosti a kompenzačnými kontrolami
  9. Výsledky testov segmentácie a záznamy nápravných opatrení
  10. Dôkazy logovania a monitorovania pre vysoko rizikové toky
  11. Playbooky incidentov preukazujúce zamedzenie šírenia podľa zón
  12. Metriky reportovania manažmentu a zápisnice zo stretnutí

Namapujte tieto dôkazy na kapitoly ISO/IEC 27001:2022 a oblasti kontrol prílohy A. Potom ich prepojte na NIS2 Article 21, GDPR Article 32, požiadavky DORA na riadenie rizík IKT a testovanie, výsledky NIST CSF 2.0 ako GOVERN, PROTECT, DETECT a RESPOND a praktiky správy a riadenia COBIT.

NIST CSF 2.0 je osobitne užitočný ako komunikačná vrstva pre predstavenstvo. Jeho funkcia GOVERN sa zameriava na právne, regulačné a zmluvné požiadavky, apetít na riziko, roly, politiky a dohľad. Jeho prevádzkové výstupy riešia riadenie konfigurácie, logovanie, monitorovanie, ochranu údajov, reakciu na incidenty a obnovu. Vďaka tomu vedenie rozumie riziku bez čítania ACL firewallu.

Bežné zistenia, ktoré Clarysec vidí pri auditoch segmentácie

Naprieč SaaS, FinTech, poskytovateľmi riadených služieb a regulovanými MSP sa opakovane objavujú rovnaké zistenia:

  • Plochá sieť medzi používateľskými koncovými bodmi a produkčnými službami
  • Produkčné databázy dostupné z vývojových alebo podnikových sietí
  • Široké cloudové bezpečnostné skupiny skopírované zo starých šablón
  • Dočasné pravidlá dodávateľov bez dátumu skončenia platnosti
  • Zmeny firewallu vykonané mimo procesu riadenia zmien
  • Pravidlá bez vlastníka alebo obchodného odôvodnenia
  • Vypnuté logovanie pri vysoko rizikových povoľujúcich pravidlách
  • Hosťovská Wi‑Fi nie je úplne izolovaná
  • Administrátorské rozhrania dostupné zo všeobecných sietí
  • Diagramy nezodpovedajú skutočnému smerovaniu
  • Chýbajú dôkazy, že revízie pravidiel boli dokončené
  • Chýba testovanie segmentácie po významných architektonických zmenách
  • Chýba mapovanie medzi systémami s osobnými údajmi a sieťovými zónami
  • Chýba reporting manažmentu o sieťovej expozícii

Tieto zistenia nie sú iba technickými slabinami. Podkopávajú schopnosť organizácie preukázať kybernetickú hygienu podľa NIS2, prevádzkovú odolnosť podľa DORA a preukázateľnú zodpovednosť podľa GDPR Article 32.

Od reaktívneho čistenia k obhájiteľnej kontrole

Segmentácia siete a revízia pravidiel firewallu sú miestom, kde sa bezpečnostná architektúra stretáva s auditnou realitou. Ak dokážete preukázať model zónovania založený na riziku, riadené toky medzi zónami, schválené zmeny firewallu, časovo obmedzené výnimky, dôkazy logovania a pravidelné overovanie, môžete jedným konzistentným príbehom odpovedať na široký rozsah otázok podľa ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST a COBIT.

Clarysec vám môže pomôcť tento príbeh vybudovať.

Použite Zenith Blueprint: An Auditor’s 30-Step Roadmap na štruktúrovanie implementačnej cesty, najmä „Kontroly v praxi“, krok 20 pre bezpečnosť sietí a segmentáciu a krok 21 pre riadenie zmien. Použite Zenith Controls: The Cross-Compliance Guide na mapovanie kontrol ISO/IEC 27002:2022 8.20, 8.22 a 8.32 naprieč auditnými očakávaniami NIS2, DORA, GDPR, NIST a COBIT. Ukotvite svoje prevádzkové pravidlá v politikách Clarysec Politika bezpečnosti sietí, Politika bezpečnosti sietí pre MSP a Politika logovania a monitorovania.

Váš ďalší krok je jednoduchý a má vysokú hodnotu: vyberte jednu kritickú službu, napríklad zákaznícku produkciu, spracovanie platieb alebo správu identít, a tento týždeň vykonajte vzorkovú revíziu 10 pravidiel. Pri každom pravidle potvrďte vlastníka, odôvodnenie, zdroj, cieľ, port, logovanie, ticket zmeny a skončenie platnosti. Ak týchto sedem skutočností neviete preukázať, máte začiatok svojho plánu zlepšenia segmentácie na rok 2026.

Frequently Asked Questions

About the Author

Igor Petreski

Igor Petreski

Compliance Systems Architect, Clarysec LLC

Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council

Share this article

Related Articles

Ochrana testovacích údajov v roku 2026: od ISO 27001 po DORA

Ochrana testovacích údajov v roku 2026: od ISO 27001 po DORA

Neprodukčné prostredia sú dnes významným predmetom auditu. Tento sprievodca ukazuje, ako chrániť testovacie údaje, stagingové systémy a procesy QA pomocou dôkazov podľa ISO/IEC 27001:2022 mapovaných na GDPR, NIS2, DORA, NIST a COBIT.