Tűzfalszabályok felülvizsgálata ISO 27001, NIS2, DORA és GDPR szerint
Hétfő reggel 07:42 van. Egy növekvő SaaS- és FinTech-szolgáltató információbiztonsági vezetője (CISO) három külön üzenetet néz.
Az első a SOC-tól érkezett. Egy kompromittálódott fejlesztői munkaállomás az éjszaka megpróbált csatlakozni egy belső adatbázis-alhálózathoz. A forgalmat blokkolták, de az elemző megerősítést kér arról, hogy a tűzfalszabály szándékos, aktuális és jóváhagyott.
A második egy nagyvállalati ügyféltől érkezett. Bizonyítékot kérnek arról, hogy az éles, fejlesztési, vállalati és támogatási környezetek szegmentáltak, a tűzfalszabályokat rendszeresen felülvizsgálják, a kivételek pedig lejárati időhöz kötöttek.
A harmadik a megfelelőségi vezetőtől érkezett. A szervezet fontos digitális szolgáltatóként NIS2 szerinti érintettséggel rendelkezik, adatfeldolgozóként GDPR szerinti felelősségei vannak, pénzügyi szolgáltatási ügyfelei pedig DORA-jellegű IKT-kockázati bizonyítékokat kérnek. Az igazgatóság tudni szeretné, hogy ugyanaz az ISO/IEC 27001:2022 szerinti bizonyítékcsomag képes-e választ adni mindhárom elvárásra.
Ekkor megérkezik az incidens utáni felülvizsgálat. Egy fejlesztői szerver egy késő esti változtatás során majdnem kikerült az internetre. Ügyféladat nem veszett el, de a forenzikus csapat az eredeti hibánál súlyosabb problémát talált: egy ötéves, „ideiglenes teszt” célú tűzfalszabály továbbra is széles körű átjárást engedett a fejlesztési és az éles környezet között. Ha egy támadó hozzáférést szerzett volna, a hálózat alig jelentett volna akadályt.
Sok szervezet ekkor szembesül a kellemetlen ténnyel. Lehetnek tűzfalaik, VLAN-jaik, felhőbiztonsági csoportjaik és diagramjaik, de nincs megfelelő irányításuk a szegmentációs zónák, a szabálytulajdonlás, az ideiglenes hozzáférés, a változtatás-jóváhagyások, az újratanúsítás és az auditbizonyítékok felett.
2026-ban az, hogy „van tűzfalunk”, már nem elfogadható válasz. Az auditorok, szabályozó hatóságok, ügyfelek és biztosítók bizonyítékot várnak arra, hogy a hálózatok szándékosan elkülönítettek, a forgalmat üzleti igény alapján szabályozzák, a kockázatos kivételeket irányított módon kezelik, és a naplók igazolják a kontrollok működését.
Miért igazgatósági szintű kérdés ma a tűzfalszabályok irányítása
A hálózati szegmentálást korábban műszaki mérnöki témaként kezelték. Az infrastruktúra-csapatok feleltek a VLAN-okért, a tűzfaladminisztrátorok tartották karban a szabálykészleteket, a felhőcsapatok kezelték a biztonsági csoportokat, a megfelelőségi funkció pedig auditok során legfeljebb egy diagramot látott.
Ez a működési modell már nem működik.
A NIS2 irányelv előírja, hogy az alapvető és fontos szervezetek megfelelő és arányos technikai, operatív és szervezeti intézkedéseket vezessenek be a hálózati és információs rendszereket érintő kockázatok kezelésére. Article 21 kiterjed a kockázatelemzésre, az incidenskezelésre, az üzletmenet-folytonosságra, az ellátási lánc biztonságára, a beszerzés és karbantartás biztonságára, az eredményesség értékelésére, az alapvető kiberhigiéniára, a hozzáférés-szabályozásra és az eszközkezelésre vonatkozó szabályzatokra. A vezető testületeknek jóvá kell hagyniuk és felügyelniük kell ezeket a kiberbiztonsági kockázatkezelési intézkedéseket.
A DORA 2025. január 17-től számos pénzügyi szervezetre alkalmazandó, és az IKT-kockázatkezelést irányított, dokumentált szakterületté teszi. Articles 5, 6 és 8 irányítást, IKT-kockázatkezelési keretrendszert, valamint az IKT-val támogatott üzleti funkciók, információs vagyon, IKT-eszközök, függőségek, kritikus eszközök és összekapcsolások azonosítását írják elő. Articles 9, 10 és 11 a védelemre, a megelőzésre, az észlelésre, a reagálásra és a helyreállításra vonatkoznak. Articles 24–27 digitális működési reziliencia-tesztelést követelnek meg, bizonyos szervezeteknél fejlett teszteléssel együtt. Ez a szegmentálást reziliencia-kérdéssé teszi, nem pusztán tűzfalproblémává.
A GDPR hozzáadja az adatvédelmi elszámoltathatósági réteget. Article 32 a kockázattal arányos biztonsági szint biztosításához megfelelő technikai és szervezeti intézkedéseket ír elő, ideértve a bizalmasságot, a sértetlenséget, a rendelkezésre állást és a rezilienciát. Article 5(1)(f) sértetlenséget és bizalmasságot, Article 5(2) pedig elszámoltathatóságot követel meg. Ha a személyes adatokat kezelő rendszerek kompromittálódott végpontokról, vendéghálózatokról vagy felügyelet nélküli harmadik fél útvonalakról elérhetők, egy felügyeleti hatóság joggal kérdezheti meg, miért léteztek ezek az útvonalak.
Az ISO/IEC 27001:2022 adja azt az irányítási rendszeri alapot, amely ezeket a kötelezettségeket összekapcsolja. Megköveteli a hatályt, az érdekelt felek követelményeit, a kockázatértékelést, a kockázatkezelést, az alkalmazhatósági nyilatkozatot, a működéstervezést és -szabályozást, a vezetői elszámoltathatóságot, a mérhető célkitűzéseket, a dokumentált információkat és a folyamatos fejlesztést. Az ISO/IEC 27002:2022 útmutatásával támogatott A melléklet tartalmazza a beszállítói kockázathoz, felhőszolgáltatásokhoz, naplózáshoz, felügyelethez, biztonságos architektúrához, környezetek elkülönítéséhez és változáskezeléshez szükséges kontrollterületeket.
A lényeg egyszerű: a hálózati szegmentálás és a tűzfalszabályok felülvizsgálata ma már irányítási bizonyíték.
A Clarysec működési mintája: 8.20, 8.22 és 8.32
A Clarysec a szegmentálást és a tűzfalszabály-felülvizsgálatot egységes működési mintaként kezeli az ISO/IEC 27002:2022 kontrollok között, nem elszigetelt műszaki feladatként.
A három elsődleges kontroll:
| ISO/IEC 27002:2022 terület | Irányítási kérdés | Az auditorok által várt bizonyíték |
|---|---|---|
| 8.20 Hálózatbiztonság | A hálózatokat kockázat alapján tervezik, kezelik, felügyelik és védik? | Architektúra-diagramok, tűzfalszabványok, biztonságos hálózati eljárások, felügyeleti naplók, IDS/IPS-bizonyítékok, VPN- és felhőhálózati konfigurációs minták |
| 8.22 Hálózatok elkülönítése | A zónák érzékenység, funkció és bizalmi szint alapján elkülönülnek? | Zónamodell, adatáramlási mátrix, VLAN- és alhálózati kialakítás, DMZ-határok, zónák közötti tűzfalszabályok, szegmentációs teszteredmények |
| 8.32 Változáskezelés | A szabálymódosításokat értékelik, jóváhagyják, tesztelik, naplózzák és felülvizsgálják? | Változásjegyek, kockázatértékelések, jóváhagyások, visszaállítási tervek, megvalósítás utáni felülvizsgálatok, sürgősségi változások nyilvántartásai |
A Zenith Blueprint: egy auditor 30 lépéses ütemterve [ZB] dokumentumban a Clarysec a hálózatbiztonságot a Kontrollok működésben szakasz 20. lépésébe helyezi: Kontrollok 8.18–8.26. Az útmutató egyértelműen megfogalmazza az alapvető auditkérdést:
„Lényegét tekintve ez a kontroll megköveteli, hogy a szervezetek biztosítsák: a hálózatok már architekturális szinten biztonságosak, nem pedig utólag, tűzfalak vagy vírusirtó hozzáadásával próbáljanak biztonságossá válni. Ez stratégiai gondolkodást igényel a hálózati szegmentálásról, a hozzáférés-szabályozásról, az átvitel közbeni titkosításról, a felügyeletről és a többrétegű védelemről. Egy egyszerű kérdéssel kezdődik: ki és mi kommunikál egymással, és ennek valóban így kell lennie?”
Ez a kérdés — „ki és mi kommunikál egymással, és ennek valóban így kell lennie?” — a tűzfalszabály-felülvizsgálat legjobb gyakorlati kiindulópontja. A beszélgetést elmozdítja a több ezer nehezen értelmezhető ACL-bejegyzéstől az üzletileg indokolt forgalmi útvonalak felé.
Ugyanez a Zenith Blueprint azt írja elő a csapatoknak, hogy a hálózati architektúra értékelésekor ellenőrizzék: a tűzfalszabályok, az IPS/IDS és a távoli hozzáférési konfigurációk aktuálisak és megerősítettek, továbbá erősítsék meg, hogy a felhőbiztonsági csoportok, az útválasztás, valamint a VPC- vagy alhálózati szabályok megfelelnek a szándékolt architektúrának. Az auditorok számára Hálózatbiztonsági architektúra-diagramot is elvár, amely bemutatja a tűzfalakat, VPN-átjárókat, DMZ-zónákat, VLAN-elkülönítést és bizalmi határokat.
A változáskezelés tekintetében a Zenith Blueprint az ISO/IEC 27002:2022 8.32 kontrollt a Kontrollok működésben szakasz 21. lépésébe helyezi: Kontrollok 8.27–8.34, és kiemeli, miért bukik el a tűzfalszabályok irányítása, ha gyenge a változáskezelés:
„Ez a kontroll egy nehéz igazságot ismer el az IT-ben: sok incidenst nem támadások okoznak, hanem rosszul kezelt változtatások. Egy túl szélesre nyitott tűzfalszabály. Egy bekapcsolva hagyott hibakeresési beállítás. Egy migráció után elfelejtett függőség.”
Pontosan így válnak az ideiglenes tűzfalnyitások állandó támadási útvonalakká.
Milyen a jól kialakított hálózati szegmentálás
Egy érett szegmentációs program négy rétegből áll.
Először is rendelkezik zónamodellel. A zónák nem önkényes alhálózatok. Olyan bizalmi határok, amelyek üzleti funkcióhoz és adatérzékenységhez igazodnak, például internet felől elérhető DMZ, éles alkalmazásréteg, éles adatbázisréteg, vállalati felhasználói hálózat, privilegizált felügyeleti hálózat, fejlesztési környezet, tesztkörnyezet, biztonsági mentési hálózat, vendég Wi‑Fi, OT- vagy IoT-zóna és harmadik felek hozzáférési zónája.
Másodszor rendelkezik forgalmi mátrixszal. A szervezet minden zónapárra dokumentálja az engedélyezett forrást, célt, protokollt, portot, alkalmazást, üzleti tulajdonost, rendszerfelelőst, adattípust, indoklást és naplózási követelményt.
Harmadszor rendelkezik szabálytulajdonlással. Minden tűzfalszabálynak, felhőbiztonsági csoportszabálynak vagy szoftveresen meghatározott peremvédelmi szabálynak van tulajdonosa, lejárati vagy újratanúsítási dátuma, kapcsolódó változásjegye és üzleti indoklása. Az „any to any” szabályt auditmegállapításként kell kezelni, kivéve, ha a kockázatot formálisan elfogadták, időkorlátos, és kompenzáló kontrollok támogatják.
Negyedszer rendszeres felülvizsgálatot végez. A felülvizsgálat több annál, mint hogy évente egyszer exportálják a tűzfalszabálybázist. Ide tartozik a tulajdonosi újratanúsítás, a megfigyelt forgalommal való összevetés, a nem használt szabályok azonosítása, az ideiglenes kivételek ellenőrzése, az internetes kitettség felülvizsgálata, a szegmentációs tesztelés és az eszköznyilvántartással való egyeztetés.
A Clarysec Hálózatbiztonsági szabályzata [P-NS] egyértelműen rögzíti a vállalati elvárást:
„Minden zónák közötti forgalmat tűzfalakkal vagy szoftveresen meghatározott peremvédelmi megoldásokkal kell szabályozni, kifejezett alapértelmezett tiltási konfigurációval.”
Vállalati szabályzat, Hálózatbiztonsági szabályzat, „Irányítási követelmények” szakasz, 5.2. pont.
Ugyanez a szabályzat közvetlenül összekapcsolja a tűzfalmódosításokat a változáskezeléssel:
„A tűzfalszabály-készletek, útválasztási táblák vagy biztonsági csoport konfigurációk bármely módosításának a szervezet Változáskezelési szabályzatát (P5) kell követnie, beleértve a visszaállítási terveket és az auditnaplózást.”
Vállalati szabályzat, Hálózatbiztonsági szabályzat, „Irányítási követelmények” szakasz, 5.4. pont.
KKV-k számára a Clarysec Hálózatbiztonsági szabályzat KKV-k számára [P-NS-SME] ugyanezt az elvet operatív megfogalmazásban adja meg:
„Alapértelmezett tiltási szabályokat kell érvényesíteni minden bejövő kapcsolatra, kivéve, ha az kifejezetten szükséges és jóváhagyott.”
KKV-szabályzat, Hálózatbiztonsági szabályzat KKV-k számára, „A szabályzat végrehajtásának követelményei” szakasz, 6.1.2. pont.
Kifejezetten a szegmentálásra:
„A szegmensek közötti forgalmat szűrni kell, és a szegmensek közötti hozzáférésnek a legkisebb jogosultság elvét kell követnie.”
KKV-szabályzat, Hálózatbiztonsági szabályzat KKV-k számára, „A szabályzat végrehajtásának követelményei” szakasz, 6.2.3. pont.
Ezek a szabályzati pontok lehetővé teszik, hogy az auditor a kockázattól a kontrollig, a kontrolltól a szabályig, a szabálytól a jóváhagyásig, a jóváhagyástól pedig a naplókig visszakövesse a folyamatot.
Egy bizonyítékcsomag ISO 27001, NIS2, DORA és GDPR célra
Sok csapat elköveti azt a hibát, hogy külön bizonyítékcsomagokat épít: egyet az ISO/IEC 27001:2022-hez, egyet a NIS2-höz, egyet a GDPR-hoz, egyet a DORA-követelményeket támasztó ügyfeleknek, és egyet a kiberbiztosításhoz.
Jobb megközelítés egyetlen szegmentációs és tűzfalszabály-irányítási bizonyítékcsomag kialakítása, amely több keretrendszerre is leképezhető.
A Zenith Controls: keresztmegfelelőségi útmutató [ZC] az ISO/IEC 27002:2022 8.22 Hálózatok elkülönítése kontrollt olyan megelőző kontrollként képezi le, amely támogatja a bizalmasságot, a sértetlenséget és a rendelkezésre állást, összhangban áll a Protect kiberbiztonsági koncepcióval, valamint a rendszer- és hálózatbiztonság operatív képességével. Az útmutató a 8.22 kontrollt a 8.20 Hálózatbiztonság, a 8.21 Hálózati szolgáltatások biztonsága, a 8.7 Malware elleni védelem, a 8.27 Biztonságos rendszerarchitektúra és mérnöki alapelvek, valamint a 8.31 Fejlesztési, teszt- és éles környezetek elkülönítése kontrollokhoz kapcsolja.
Az útmutató így magyarázza a szegmentálás NIS2-relevanciáját:
„A hálózatok elkülönítése közvetlen válasz ezekre a kötelezettségekre, mivel csökkenti a támadási felületet és megakadályozza a laterális mozgást a hálózatba kapcsolt rendszerek között.”
Ez a mondat leírja, miért nem kezelhetik a NIS2 kiberhigiéniai programok a szegmentálást opcionális elemként. A zsarolóvírusok elszigetelése nem csak végpontvédelem kérdése. Arról is szól, hogy ha a megelőzés sikertelen, korlátozni kell a laterális mozgást.
A GDPR tekintetében a Zenith Controls a 8.22 kontrollt Article 32 és Recital 49 követelményeihez kapcsolja, kiemelve, hogy a hálózati diagramok és zónaszabályzatok a megfelelés kulcsfontosságú bizonyítékaivá válnak. A DORA esetében a Zenith Controls a hálózatbiztonságot és az elkülönítést az IKT-kockázatkezeléshez és az incidensek elszigeteléséhez kapcsolja. A szegmentációs tesztek támogathatják az IKT-rezilienciára vonatkozó bizonyítékokat, különösen akkor, ha igazolják, hogy egy zóna kompromittálódása nem teszi lehetővé a szabad átjárást kritikus pénzügyi szolgáltatások, személyesadat-tárak vagy privilegizált felügyeleti rendszerek felé.
| Bizonyíték | ISO/IEC 27001:2022 és ISO/IEC 27002:2022 szerinti felhasználás | NIS2 szerinti felhasználás | DORA szerinti felhasználás | GDPR szerinti felhasználás |
|---|---|---|---|---|
| Hálózatbiztonsági architektúra-diagram | Támogatja az IBIR alkalmazási területét, az operatív kontrollt, valamint a 8.20 és 8.22 kontrollokat | Bemutatja a hálózati és információs rendszerek biztonságára vonatkozó technikai intézkedéseket | Bemutatja az IKT-összekapcsolásokat és a kritikus szolgáltatási függőségeket | Bemutatja a személyes adatokat kezelő rendszerek körüli védelmi határokat |
| Zóna- és forgalmi mátrix | Igazolja a kockázatalapú elkülönítést és a legkisebb jogosultság elvét | Támogatja a kiberhigiéniát és az eredményesség értékelését | Támogatja az IKT-eszközök és függőségek osztályozását | Támogatja az Article 32 szerinti technikai intézkedéseket és az elszámoltathatóságot |
| Tűzfalszabály-felülvizsgálati nyilvántartások | Bizonyítékot ad a kontrollok felügyeletére és a folyamatos fejlesztésre | Igazolja, hogy az intézkedéseket felülvizsgálják, és nem statikusak | Támogatja az IKT-kockázatok felülvizsgálatát és a rezilienciatesztelést | Igazolja az adatkezelés folyamatos biztonságát |
| Tűzfalszabályokhoz kapcsolódó változásjegyek | Támogatja a 8.32 változáskezelést | Támogatja a biztonságos karbantartást és a visszakövethetőséget | Támogatja a szabályozott IKT-változásokat és a rezilienciát | Igazolja, hogy a személyes adatokat kezelő rendszereket érintő változásokat kockázatértékelték |
| Kivételnyilvántartás | Támogatja a kockázatkezelést és a maradványkockázat elfogadását | Bemutatja az eltérések vezetői felügyeletét | Támogatja a kockázattűrést és az irányítást | Igazolja az ideiglenes kitettséghez kapcsolódó elszámoltathatóságot |
| Blokkolt és engedélyezett zónák közötti forgalom naplói | Támogatja a naplózást, a felügyeletet és a kontrollhatékonyságot | Támogatja az észlelést és az incidensreagálást | Támogatja az incidensbesorolást és a jelentéstételt | Támogatja az adatsértés értékelését és a bizonyítékok megőrzését |
Ez a táblázat nem csupán megfelelőségi leképezés. Ez a bizonyítékgyűjtés ütemterve.
A tűzfalszabály-felülvizsgálat, amely valóban működik
A tűzfalszabály-felülvizsgálat akkor bukik el, ha csak azt kérdezi: „Szükség van még erre a szabályra?” A szabálytulajdonosok gyakran igent mondanak, mert félnek attól, hogy valami leáll.
Egy jobb felülvizsgálat hat kérdést tesz fel:
- Melyik üzleti szolgáltatást támogatja ez a szabály?
- Melyik eszközfelelős és adatgazda hagyta jóvá a forgalmi útvonalat?
- A cél az adat és a funkció szempontjából megfelelő zónában van-e?
- A szabály megengedőbb-e annál, mint amit a megfigyelt forgalom indokol?
- Engedélyezett-e a naplózás a magas kockázatú forgalmakra?
- Van-e a szabálynak felülvizsgálati dátuma, lejárati dátuma vagy kivételbejegyzése?
A Hálózatbiztonsági szabályzat KKV-k számára időszakos felülvizsgálatot ír elő:
„Az IT-támogatási szolgáltatónak évente felül kell vizsgálnia a tűzfalszabályokat, a hálózati architektúrát és a vezeték nélküli konfigurációkat.”
KKV-szabályzat, Hálózatbiztonsági szabályzat KKV-k számára, „Irányítási követelmények” szakasz, 5.6.1. pont.
Az éves felülvizsgálat az alap, nem a felső határ. A magas kockázatú szabályokat gyakrabban kell újratanúsítani.
| Szabálykategória | Példa | Felülvizsgálati gyakoriság | Jóváhagyási elvárás |
|---|---|---|---|
| Internetről bejövő forgalom éles környezetbe | Nyilvános API az alkalmazásátjáró felé | Negyedévente vagy jelentős kiadás után | Szolgáltatásgazda, biztonsági felelős, változás-jóváhagyó |
| Zónák közötti éles adatbázis-hozzáférés | Alkalmazásréteg az adatbázisréteg felé | Negyedévente | Alkalmazástulajdonos és adatgazda |
| Adminisztratív hozzáférés | Ugrószerver szerverfelügyeleti portokhoz | Havonta vagy negyedévente | Infrastruktúra-felelős és CISO-delegált |
| Harmadik felek hozzáférése | Beszállítói VPN támogatási alhálózathoz | Havonta vagy szerződéses mérföldkőnél | Beszállítói kapcsolat tulajdonosa és biztonsági felelős |
| Ideiglenes kivétel | Sürgősségi hozzáférés migráció során | Lejárat előtt, legfeljebb 90 nap | IBIR-vezető vagy CISO |
| Standard alacsony kockázatú belső szabály | Felügyeleti szerver felügyelt végpontokhoz | Évente | Szolgáltatásgazda |
A Hálózatbiztonsági szabályzat egyértelmű a kivételekkel kapcsolatban:
„A kérelmet az IBIR-vezetőnek vagy a CISO-nak kell felülvizsgálnia és jóváhagynia, és azt az IBIR kivételnyilvántartásában kell rögzíteni, legfeljebb 90 napos jóváhagyási időtartammal, amely újraértékelés alapján megújítható.”
Vállalati szabályzat, Hálózatbiztonsági szabályzat, „Kockázatkezelés és kivételek” szakasz, 7.3. pont.
KKV-k esetében a Hálózatbiztonsági szabályzat KKV-k számára előírja, hogy a kivételkérelmek tartalmazzák a szükséges minimális adatokat:
„A kérelemnek tartalmaznia kell az indoklást, a hatályt, az időtartamot és a kompenzáló kontrollokat (pl. IP-engedélyezési lista, naplózás).”
KKV-szabályzat, Hálózatbiztonsági szabályzat KKV-k számára, „Kockázatkezelés és kivételek” szakasz, 7.3.3. pont.
Ez a pont az informális üzenetváltásból auditálható kockázatkezelést hoz létre.
Gyakorlati példa: kockázatos éles adatbázisszabály eltávolítása
Tegyük fel, hogy egy vállalat a felülvizsgálat során az alábbi szabályt találja:
| Mező | Jelenlegi érték |
|---|---|
| Forrás | Vállalati felhasználói VLAN |
| Cél | Éles adatbázis-alhálózat |
| Port | TCP 5432 |
| Művelet | Engedélyezés |
| Megjegyzés | Ideiglenes hozzáférés riporting migrációhoz |
| Létrehozva | 14 hónapja |
| Tulajdonos | Ismeretlen |
| Naplózás | Letiltva |
Ez klasszikus auditmegállapítás. Sérti a legkisebb jogosultság elvét, nincs egyértelmű tulajdonosa, nincs lejárata, nincs aktuális indoklása és nincs naplózása. GDPR Article 32 szerinti kitettséget is teremt, ha az éles adatbázis ügyfelek személyes adatait tartalmazza.
A helyesbítő folyamatnak bizonyítékot kell létrehoznia, nem pusztán el kell távolítania egy rossz szabályt.
| Lépés | Tevékenység | Clarysec-hivatkozás | Létrehozott auditbizonyíték |
|---|---|---|---|
| 1. A szabály leképezése a zónamodellre | Meg kell erősíteni, hogy vállalati felhasználók valaha elérhetik-e az éles adatbázis-alhálózatot | Zenith Blueprint, Kontrollok működésben 20. lépés | Frissített architektúra-felülvizsgálati jegyzetek és zónabesorolás |
| 2. A forgalmi bejegyzés létrehozása vagy frissítése | Dokumentálni kell a forrást, célt, portot, adattípust, tulajdonost, indoklást és kockázatot | Zenith Controls, 8.22 leképezés | Zóna- és forgalmi mátrix bejegyzése |
| 3. Változásjegy megnyitása | Javasolni kell az eltávolítást vagy szabályozott riporting szolgáltatási útvonallal való kiváltást | Hálózatbiztonsági szabályzat, 5.4. pont | Változásbejegyzés kockázatelemzéssel, teszttervvel és visszaállítási tervvel |
| 4. Kezelési döntés meghozatala | A széles szabály eltávolítása vagy kiváltása csak olvasható replikával, bastionnal, IP-engedélyezési listával és naplózással | Hálózatbiztonsági szabályzat, 7.3. pont | Kockázatkezelési döntés vagy időkorlátos kivétel |
| 5. Naplózás engedélyezése jóváhagyott forgalmakra | Magas kockázatú zónák közötti tűzfalesemények továbbítása felügyeletre | Naplózási és felügyeleti szabályzat, 6.1.1.6. pont | SIEM-bejegyzések, riasztási szabályok és felügyeleti képernyőképek |
| 6. A szegmentálás ellenőrzése | Tesztelni kell, hogy az adatbázis-alhálózat kizárólag jóváhagyott útvonalakon érhető el | Zenith Blueprint, 20. lépés | Szegmentációs teszteredmény és helyesbítő intézkedés lezárása |
A Clarysec Naplózási és felügyeleti szabályzata [P-LM] a külső kommunikációt és a tűzfalszabály-kiváltó eseményeket naplózási szempontból releváns eseményként kezeli:
„Külső kommunikációk és tűzfalszabály-kiváltó események”
Vállalati szabályzat, Naplózási és felügyeleti szabályzat, „A szabályzat végrehajtásának követelményei” szakasz, 6.1.1.6. pont.
Magas kockázatú zónák közötti szabályoknál a tűzfaleseményeknek a SIEM-be vagy a felügyeleti platformra kell kerülniük, szokatlan forráshosztokra, forgalmi mennyiségekre vagy időablakokra vonatkozó riasztásokkal.
A KKV-szabályzat a változásfegyelmet is előírja:
„A hálózati konfigurációk minden módosításának (tűzfalszabályok, kapcsoló ACL-ek, útválasztási táblák) dokumentált változáskezelési folyamatot kell követnie.”
KKV-szabályzat, Hálózatbiztonsági szabályzat KKV-k számára, „A szabályzat végrehajtásának követelményei” szakasz, 6.9.1. pont.
E szabály egyszeri megtisztítása bizonyítékot hoz létre az ISO/IEC 27001:2022 szerinti operatív kontrollhoz, az ISO/IEC 27002:2022 8.20, 8.22 és 8.32 kontrollokhoz, a NIS2 kiberhigiéniához, a GDPR Article 32-höz és a DORA-jellegű IKT-kockázatkezeléshez.
A felhőt, a SaaS-t és a hibrid hálózatokat is be kell vonni
A modern szegmentálás nem csak VLAN-okból és fizikai tűzfalakból áll. Ide tartoznak az AWS biztonsági csoportok, az Azure hálózati biztonsági csoportok, a Kubernetes hálózati szabályzatok, a felhőalapú útválasztási táblák, a SaaS adminisztrátori engedélyezési listák, a privát végpontok, a VPN-ek, az SD-WAN, az identitástudatos proxyk és a szoftveresen meghatározott peremvédelmi kontrollok.
Egy SaaS-szolgáltatónál vagy szabályozott digitális szolgáltatásnál a tűzfalszabály-felülvizsgálatnak legalább az alábbiakra ki kell terjednie:
- Internet felől elérhető terheléselosztók és alkalmazásátjárók
- Felhőbiztonsági csoportok és hálózati ACL-ek
- Privát alhálózati útválasztási táblák
- Peering- és tranzitátjáró-útvonalak
- VPN- és távoli adminisztrációs útvonalak
- Adminisztrációs interfészek és felügyeleti síkok
- Kubernetes ingress és hálózati szabályzatok
- CI/CD runner hozzáférés az éles környezethez
- Naplózási lefedettség a tiltott és engedélyezett magas kockázatú forgalmakra
- Harmadik fél támogatói hozzáférés és vészhelyzeti hozzáférési útvonalak
Ha egy felhőbiztonsági csoport széles vállalati IP-tartományból engedélyez bejövő adatbázis-forgalmat, úgy kell kezelni, mint egy tűzfalszabályt. Tulajdonosra, indoklásra, jóváhagyásra, felülvizsgálatra, naplózásra és lejáratra van szüksége.
Itt erősítik a történetet a támogató ISO-szabványok is. Az ISO/IEC 27017 egyértelműséget ad a felhőbiztonsági felelősségekhez. Az ISO/IEC 27033 mélyebb útmutatást nyújt a hálózatbiztonsági architektúráról, a DMZ-kről, a szegmentációs zónákról, a forgalomszűrésről és a biztonságos hálózatközi kommunikációról. Az ISO/IEC 27701 erősíti az adatvédelmi irányítást ott, ahol személyazonosításra alkalmas információk mozognak a hálózatokon. Az ISO/IEC 27035 támogatja az incidensek elszigetelését, az ISO/IEC 27005 pedig támogatja a szegmentálás kockázatkezelési intézkedésként történő kiválasztását jogosulatlan hozzáférés, malware-terjedés és laterális mozgás esetén.
Hogyan tesztelik az auditorok eltérően ugyanazt a kontrollt
A Zenith Controls egyik erőssége, hogy bemutatja, a különböző auditmódszertanok hogyan vizsgálják ugyanazt a kontrollt. A bizonyíték újrahasznosítható, de a kérdések eltérőek.
| Auditnézőpont | Valószínű kérdés | Legjobb bizonyíték |
|---|---|---|
| ISO/IEC 27001:2022 auditor | A szegmentálást kockázat alapján választották ki, vezették be és vizsgálták felül? | Kockázatértékelés, SoA, hálózatbiztonsági szabályzat, diagramok, felülvizsgálati nyilvántartások |
| ISO/IEC 27007-jellegű auditor | A bevezetett tűzfalszabályok és VLAN-sémák megfelelnek a dokumentált szabályzatnak? | Tűzfalszabály-minták, útválasztó ACL-ek, VLAN-kialakítás, rendszergazdai interjúk |
| ISO/IEC 27006-1:2024 tanúsítási auditra jellemző megközelítés | A kritikus hálózati határokat megfelelő kompetenciával és kockázatalapú tervezéssel auditálják? | Auditterv, technikai mintavétel, felhőbiztonsági csoportokra vonatkozó bizonyítékok, teszteredmények |
| NIST-orientált auditor | A határokat és az információáramlásokat kikényszerítik és felügyelik? | Tűzfalszabályok, ACL-ek, szegmentációs tesztek, felügyeleti nyilvántartások |
| COBIT 2019 auditor | A hálózatbiztonság irányított, felügyelt és jelentett? | Tulajdonosi mátrix, KPI-k, vezetői jelentések, kockázati nyilvántartás |
| ISACA ITAF auditor | Az általános IT-kontrollok következetesen működnek? | Változásjegyek, kivétel-jóváhagyások, naplók, szabály-újratanúsítási minták |
| GDPR felügyeleti hatóság | Megfelelő technikai intézkedések védték a személyes adatokat kezelő rendszereket? | Adatáramlási térképek, PII-zóna elkülönítése, hozzáférési útvonalak, tűzfalnaplók |
| DORA-fókuszú értékelő | Támogatja-e a szegmentálás az IKT-rezilienciát és az incidensek elszigetelését? | IKT-eszközfüggőségi térkép, kritikus funkciók forgalmai, incidens-forgatókönyvek, tesztnyilvántartások |
Egy DORA-fókuszú értékelő megkérdezheti, hogy egy fizetési átjáró kompromittálódása esetén lehetséges-e oldalirányú mozgás az ügyféladatbázisok felé. Egy NIS2 illetékes hatóság rákérdezhet, hogy egy adminisztratív munkaállomáson megjelenő zsarolóvírus elérheti-e az alapvető szolgáltatásnyújtási rendszereket. Egy GDPR-hatóság azt kérdezheti, milyen hálózati szintű korlátozások védték a személyes adatokat kezelő rendszereket. Egy ISO-auditor egyszerűen kérheti a kockázatértékelést, az SoA-t, a szabályzatot, az eljárást és annak bizonyítékát, hogy a felülvizsgálatok megtörténtek.
A legjobb programok mindegyikre ugyanazokkal a bizonyítékokkal válaszolnak.
Mutatók, amelyek láthatóvá teszik a szegmentálást a vezetés számára
A NIS2 és a DORA egyaránt erősíti a vezetői elszámoltathatóságot. Az ISO/IEC 27001:2022 vezetést, célkitűzéseket, szerepköröket, erőforrásokat, jelentéstételt és folyamatos fejlesztést követel meg. Ez azt jelenti, hogy a szegmentáláshoz a vezetés számára érthető mutatókra van szükség.
Hasznos vezetői mutatók:
- Tulajdonossal rendelkező tűzfalszabályok aránya
- Dokumentált üzleti indoklással rendelkező szabályok aránya
- Lejárt ideiglenes szabályok száma
- Olyan szabályok száma, amelyekben „any” forrás, cél vagy szolgáltatás szerepel
- Internet felől elérhető szolgáltatások száma kritikusság szerint
- Naplózással rendelkező magas kockázatú zónák közötti forgalmak aránya
- Sürgősségi tűzfalmódosítások száma negyedévente
- Jóváhagyott változásjegyekhez illesztett mintavételezett szabályok aránya
- Szegmentációs teszthibák száma
- Kockázatos vagy nem használt szabályok helyesbítéséig eltelt átlagos idő
- 90 napnál régebbi kivételek száma
- Felülvizsgált és újratanúsított harmadik fél hozzáférési szabályok száma
A Hálózatbiztonsági szabályzat a „tűzfalszabályok hatékonyságát” megfelelési és betartatási szempontként azonosítja a „Betartatás és megfelelés” szakasz 8.2.2. pontjában. Ez a kifejezés azért fontos, mert a szabályok puszta létezése nem elég. A szabályoknak hatékonynak, felülvizsgáltnak és az aktuális kockázattal összhangban állónak kell lenniük.
A 2026-os szegmentációs bizonyítékcsomag felépítése
Egy gyakorlati szegmentációs és tűzfalszabály-felülvizsgálati bizonyítékcsomagnak készen kell állnia, mielőtt az auditor kéri.
Legalább az alábbiakat kell fenntartani:
- Aktuális hálózati architektúra-diagram, beleértve a felhő- és hibrid zónákat
- Zónabesorolási szabvány, beleértve az érzékenységet és a bizalmi szintet
- Forgalmi mátrix a kritikus szolgáltatásokhoz és személyes adatokat kezelő rendszerekhez
- Tűzfal- és felhőbiztonsági csoport szabályexport
- Szabálytulajdonosi és újratanúsítási nyilvántartás
- Tűzfalszabály-felülvizsgálati eljárás és felülvizsgálati naptár
- Változásbejegyzések a mintavételezett tűzfalmódosításokhoz
- Kivételnyilvántartás jóváhagyásokkal, lejárattal és kompenzáló kontrollokkal
- Szegmentációs teszteredmények és helyesbítő intézkedési nyilvántartások
- Naplózási és felügyeleti bizonyítékok magas kockázatú forgalmakra
- Incidens-forgatókönyvek, amelyek bemutatják a zónánkénti elszigetelést
- Vezetői jelentési mutatók és értekezleti jegyzőkönyvek
Ezt a bizonyítékot le kell képezni az ISO/IEC 27001:2022 pontjaira és az A melléklet kontrollterületeire. Ezután kereszthivatkozással kapcsolja a NIS2 Article 21, a GDPR Article 32, a DORA IKT-kockázatkezelési és tesztelési követelményeihez, a NIST CSF 2.0 olyan kimeneteihez, mint GOVERN, PROTECT, DETECT és RESPOND, valamint a COBIT irányítási gyakorlatokhoz.
A NIST CSF 2.0 különösen hasznos vezetői kommunikációs rétegként. GOVERN funkciója a jogi, szabályozási és szerződéses követelményekre, a kockázatvállalási hajlandóságra, a szerepkörökre, szabályzatokra és felügyeletre fókuszál. Operatív kimenetei kiterjednek a konfigurációkezelésre, a naplózásra, a felügyeletre, az adatvédelemre, az incidensreagálásra és a helyreállításra. Ez segít a vezetésnek megérteni a kockázatot anélkül, hogy tűzfal ACL-eket kellene olvasnia.
Gyakori megállapítások, amelyeket a Clarysec szegmentációs auditok során lát
SaaS-szolgáltatóknál, fintech cégeknél, menedzselt szolgáltatóknál és szabályozott KKV-knál ugyanazok a megállapítások ismétlődnek:
- Sík hálózat a felhasználói végpontok és az éles szolgáltatások között
- Fejlesztési vagy vállalati hálózatokból elérhető éles adatbázisok
- Régi sablonokból másolt túl széles felhőbiztonsági csoportok
- Lejárat nélküli ideiglenes beszállítói szabályok
- A változáskezelési folyamaton kívül végrehajtott tűzfalmódosítások
- Tulajdonos vagy üzleti indoklás nélküli szabályok
- Letiltott naplózás magas kockázatú engedélyező szabályokon
- Nem teljesen elkülönített vendég Wi‑Fi
- Általános hálózatokból elérhető adminisztrációs interfészek
- A tényleges útválasztással nem egyező diagramok
- Nincs bizonyíték arra, hogy a szabályfelülvizsgálatok megtörténtek
- Nincs szegmentációs tesztelés jelentős architekturális változások után
- Nincs leképezés a személyes adatokat kezelő rendszerek és a hálózati zónák között
- Nincs vezetői jelentéstétel a hálózati kitettségről
Ezek a megállapítások nem csupán technikai gyengeségek. Aláássák a szervezet képességét arra, hogy igazolja a NIS2 kiberhigiéniát, a DORA működési rezilienciát és a GDPR Article 32 szerinti elszámoltathatóságot.
A reaktív takarítástól az igazolható kontrollig
A hálózati szegmentálás és a tűzfalszabály-felülvizsgálat az a pont, ahol a biztonsági architektúra találkozik az audit valóságával. Ha be tud mutatni kockázatalapú zónamodellt, szabályozott zónák közötti forgalmakat, jóváhagyott tűzfalmódosításokat, időkorlátos kivételeket, naplózási bizonyítékot és időszakos ellenőrzést, akkor az ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST és COBIT kérdések széles körére tud egy koherens történettel válaszolni.
A Clarysec segít felépíteni ezt a történetet.
Használja a Zenith Blueprint: egy auditor 30 lépéses ütemterve útmutatót a bevezetési út strukturálásához, különösen a Kontrollok működésben szakasz 20. lépését a hálózatbiztonságra és szegmentálásra, valamint a 21. lépését a változáskezelésre. Használja a Zenith Controls: keresztmegfelelőségi útmutató dokumentumot az ISO/IEC 27002:2022 8.20, 8.22 és 8.32 kontrollok NIS2, DORA, GDPR, NIST és COBIT audit elvárásokra történő leképezéséhez. A működési szabályokat rögzítse a Clarysec Hálózatbiztonsági szabályzatában, Hálózatbiztonsági szabályzat KKV-k számára dokumentumában és Naplózási és felügyeleti szabályzatában.
A következő lépés egyszerű és nagy értékű: válasszon ki egy kritikus szolgáltatást, például ügyfél-éles környezetet, fizetésfeldolgozást vagy identitáskezelést, és végezzen ezen a héten 10 szabályból álló mintavételes felülvizsgálatot. Minden szabálynál erősítse meg a tulajdonost, az indoklást, a forrást, a célt, a portot, a naplózást, a változásjegyet és a lejáratot. Ha ezt a hét tényt nem tudja igazolni, akkor megvan a 2026-os szegmentációfejlesztési tervének kiindulópontja.
Frequently Asked Questions
About the Author
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
