DNS-irányítás 2026-ban: auditra kész regisztrátori kontrollok

Hétfő reggel 07:42-kor egy növekedési fázisú fintech vállalat információbiztonsági vezetője megkapja azt az üzenetet, amelyet senki sem szeretne látni. Az ügyfelek nem érik el a fizetési portált, a helpdesk túlterhelt, az e-mail-szolgáltatás hibázik, a SOC pedig nem talál malware-t, tűzfalkiesést vagy felhőszolgáltatói incidenst.
A gyökérok csendesebb és kellemetlenebb. Egy regisztrátori fiókhoz olyan elavult adminisztrátori hitelesítő adattal fértek hozzá, amelyet korábban több volt IT-munkatárs is megosztva használt. A támadó módosította az autoritatív névszervereket, átírta az MX rekordokat, letiltotta a DNSSEC-et, és elég ideig irányította át a forgalmat ahhoz, hogy hitelesítő adatokat gyűjtsön és megzavarja a partneri API-kat. A fizetési portált a hagyományos értelemben nem törték fel. A vállalat bizalmi horgonya, a domainje sérült.
09:30-ra az operatív válság megfelelési válsággá válik. Az igazgatóság azt kérdezi, be volt-e kapcsolva a nyilvántartói zárolás. A jogi terület azt kérdezi, kerültek-e ki személyes adatok. Az adatvédelmi tisztviselő azt kérdezi, hogy ez GDPR szerinti személyesadat-sértés-e. A szabályozó hatóság arra kíváncsi, érintett-e kritikus vagy fontos funkciót az eset. Egy ügyfélauditor a DNS-módosítást jóváhagyó változtatási jegyet kéri.
Túl sok szervezetnél a válasz egy táblázat, egy megosztott postafiók és egy olyan regisztrátori konzol, amelyet hat hónapja senki sem vizsgált felül.
A DNS és a domainregisztrátori irányítás 2026-ban már nem háttér-infrastruktúra kérdése. Része a zsarolóvírussal szembeni rezilienciának, az adathalászat-megelőzésnek, a felhő rendelkezésre állásának, a beszállítói kockázatkezelésnek, az incidensreagálásnak, az üzletmenet-folytonosságnak és a bizonyítékalapú megfelelésnek. Ha a domain eltéríthető, a SaaS platform eltűnhet. Ha a DNS-rekordok jóváhagyás nélkül módosíthatók, az e-mail-biztonság, az SSO, az SSL/TLS-tanúsítványok, az API-végpontok és az ügyfélbizalom percek alatt aláásható.
Miért tartozik a DNS- és regisztrátori irányítás az IBIR hatályába
A domainnév nem pusztán márkaeszköz. Logikai eszköz, hitelesítési függőség, útválasztási függőség és gyakran beszállító által kezelt szolgáltatás. Összekapcsolja az identitásszolgáltatókat, az e-mail-hitelesítést, a TLS-tanúsítványok ellenőrzését, a felhővégpontokat, az ügyfélportálokat, az API-kat, a CDN-szolgáltatásokat, a felügyeleti próbaméréseket és az incidenskommunikációt.
A Clarysec Eszközkezelési szabályzat - KKV Eszközkezelési szabályzat - KKV ezt a hatályban kifejezetten rögzíti:
Digitális hitelesítő adatok és szolgáltatások: domainnevek, digitális tanúsítványok, API-kulcsok, e-mail-fiókok, felhőbelépések
A „Hatály” szakasz 2.2.4. szabályzati pontjából.
Ugyanez a szabályzat többet követel meg a domainnév puszta felsorolásánál:
A tulajdonosi felelősséget, a célt, a hozzáférési jogosultságokat és a megújítási határidőket dokumentálni kell.
A „A szabályzat végrehajtásának követelményei” szakasz 6.6.2. szabályzati pontjából.
Vállalati környezetek esetén a Clarysec Eszközkezelési szabályzat Eszközkezelési szabályzat a logikai eszközöket is a hatályba vonja:
Logikai eszközök: domainnevek, licencek, felhasználói fiókok, konfigurációs alapállapotok
A „Hatály” szakasz 2.2.5. szabályzati pontjából.
Ez az irányítás kiindulópontja. A DNS- és regisztrátori nyilvántartásnak dokumentálnia kell:
- Domainnév, nyilvántartó, regisztrátor, DNS-tárhelyszolgáltató és autoritatív névszerverek
- Üzleti tulajdonos, műszaki tulajdonos, biztonsági tulajdonos és vészhelyzeti jóváhagyó
- Cél, például éles portál, API, e-mail, SSO, marketing, tesztkörnyezet vagy védekező célú regisztráció
- Kritikussági besorolás és függőségek hozzárendelése üzleti szolgáltatásokhoz
- DNSSEC-állapot, DS rekord állapota, kulcstulajdonlás és kulcsrotációs folyamat
- Nyilvántartói zárolás és regisztrátori zárolás állapota
- MFA és emelt jogosultságú hozzáférési modell a regisztrátori és DNS-szolgáltatói fiókokhoz
- Megújítási dátum, automatikus megújítás állapota, fizetési felelős és lejárati riasztás
- Változáskezelési követelmények zónaszerkesztésekhez és delegálásmódosításokhoz
- Naplózás, riasztás, felügyelet és bizonyítékmegőrzés
Ezért kell a domainirányításnak megjelennie az ISO/IEC 27001:2022 szerinti IBIR alkalmazási területében és kockázatértékelésében. Az ISO/IEC 27001:2022 előírja, hogy a szervezetek határozzák meg a működési környezetüket, az érdekelt felek követelményeit, a jogi és szerződéses kötelezettségeket, valamint a külső szervezetekkel fennálló interfészeket és függőségeket. A DNS függ a regisztrátoroktól, a nyilvántartóktól, a DNS-tárhelyszolgáltatóktól, a felhőszolgáltatóktól, a hitelesítésszolgáltatóktól, az MSP-ktől és esetenként marketingügynökségektől. Ha ezek az interfészek kimaradnak az IBIR hatályából, az auditnyom hiányos lesz.
A 2026-os DNS-fenyegetésmodell
A legsúlyosabb DNS-hibák gyakran egyszerűek:
- Egy domain lejár, mert nem egyértelmű, ki felel a megújításért.
- Egy korábbi ügynökségnek továbbra is van hozzáférése egy regisztrátori fiókhoz.
- A DNSSEC be van kapcsolva, de a DS rekordok hibásak egy DNS-szolgáltatói migráció után.
- Egy wildcard rekord elhagyott felhőszolgáltatásra irányítja a forgalmat.
- Egy TXT rekordot úgy módosítanak, hogy támadó által kontrollált SaaS-bérlőt vagy tanúsítványkérelmet igazoljon.
- Az MX rekordokat adathalászati vagy e-mail-elfogási kampány során módosítják.
- Egy harmadik fél platformjára mutató CNAME átvételi kockázatnak lesz kitéve.
- A nyilvántartói zárolás létezik az elsődleges domainre, de nem terjed ki az ügyféloldali országkód szerinti domainekre.
- A SOC figyeli a végpontokat, de senki sem felügyeli a zónafájl-módosításokat.
A technikai védelmi intézkedések jól ismertek. A DNSSEC segít védeni a DNS-adatok sértetlenségét és az eredet hitelességét. A nyilvántartói zárolás további, sávon kívüli ellenőrzéshez köti a magas kockázatú nyilvántartói szintű módosításokat. A regisztrátori zárolás csökkenti a jogosulatlan átadás kockázatát. Az MFA és az emelt jogosultságú hozzáférések felülvizsgálata csökkenti a fiókátvétel valószínűségét. A változáskezelés megelőzi a véletlen szolgáltatáskimaradást. A felügyelet észleli a jogosulatlan vagy váratlan módosításokat.
A megfelelési kihívás más: igazolni tudja-e, hogy ezek a védelmi intézkedések léteznek, van gazdájuk, felülvizsgálják őket, és incidens során működnek?
Sok szervezet éppen ennél a bizonyítékkérdésnél bukik el.
A DNS-irányítás megfeleltetése az ISO/IEC 27001:2022 és ISO/IEC 27002:2022 követelményeinek
Az ISO/IEC 27001:2022 adja azt az irányítási rendszerstruktúrát, amellyel a DNS-kontrollok ismételhető, auditálható folyamatokká alakíthatók. Az ISO/IEC 27001:2022 Annex A és az ISO/IEC 27002:2022 kontrollútmutatója biztosítja azt a kontrollnyelvezetet, amelyet az auditorok elvárnak.
| DNS-irányítási terület | ISO/IEC 27001:2022 Annex A és ISO/IEC 27002:2022 bizonyítéktéma | Mit várnak látni az auditorok |
|---|---|---|
| Domainnyilvántartás | 5.9 Információk és kapcsolódó eszközök nyilvántartása | Domainnyilvántartás tulajdonosokkal, kritikussággal, megújítási dátumokkal, DNS-szolgáltatóval, regisztrátorral és függőségekkel |
| Regisztrátori hozzáférés | 5.15 Hozzáférés-szabályozás, 5.16 Identitáskezelés, 5.18 Hozzáférési jogosultságok, 8.5 Biztonságos hitelesítés | Névre szóló felhasználók, MFA-bizonyítékok, jóváhagyási nyilvántartások, időszakos hozzáférés-felülvizsgálatok és vészhelyzeti hozzáférési folyamat |
| DNSSEC | 8.24 Kriptográfia használata | DNSSEC-állapot, DS rekordok, kulcsőrzési felelősség, rotációs terv és ellenőrzési felügyelet |
| Nyilvántartói és regisztrátori zárolás | 5.15 Hozzáférés-szabályozás, 8.20 Hálózatbiztonság, 8.21 Hálózati szolgáltatások biztonsága, 8.32 Változáskezelés | Zárolási állapot, feloldási eljárás, jogosult kapcsolattartók és sávon kívüli ellenőrzési folyamat |
| Zónamódosítások kezelése | 8.9 Konfigurációkezelés, 8.32 Változáskezelés | Változtatási jegyek, kockázatértékelés, jóváhagyások, végrehajtási bizonyítékok és visszaállítási terv |
| DNS-szolgáltatói irányítás | 5.19 Információbiztonság a beszállítói kapcsolatokban, 5.20 Információbiztonság kezelése beszállítói megállapodásokban, 5.22 Beszállítói szolgáltatások felügyelete, felülvizsgálata és változáskezelése | Szerződéses záradékok, SLA, biztonsági felelősségek, szolgáltatás-felülvizsgálatok és incidensbejelentési elvárások |
| DNS-naplózás és -felügyelet | 8.15 Naplózás, 8.16 Megfigyelési tevékenységek | Naplók, riasztások, SIEM-betöltés, megőrzés és riasztásteszt-bizonyítékok |
| DNS-kiesés kezelése | 5.24 Információbiztonsági incidenskezelés tervezése és előkészítése, 5.29 Információbiztonság zavarhelyzetben, 5.30 IKT-felkészültség üzletmenet-folytonosságra | Helyreállítási forgatókönyvek, eszkalációs lista, helyreállítási eljárások és incidens utáni tanulságok |
A Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint a hálózati szolgáltatásokat kifejezett auditobjektumként kezeli. A Controls in Action fázis 20. lépésében arra utasítja a csapatokat, hogy ellenőrizzék a hálózati szolgáltatások biztonságát:
Sorolja fel az összes belső és külső hálózati szolgáltatást (DNS, VPN, SMTP, DHCP, API-átjárók, stb.).
✓ Mindegyiknél erősítse meg, hogy biztonságos protokollokat használnak-e (pl. DNSSEC, TLS 1.2+, SSH a Telnet helyett). ✓ Vizsgálja felül, hogyan szabályozott az egyes szolgáltatásokhoz való hozzáférés (pl. IP-engedélyezési listák, hitelesítés, tanúsítványok). ✓ Ha harmadik felek kezelik őket (pl. DNS, SD-WAN, hosztolt VPN), vizsgálja felül a biztonsági záradékokat az SLA-ban vagy a beszállítói szerződésben. Frissítse a Szolgáltatásnyilvántartást, és rögzítse, hol vannak a biztonsági felelősségek: belső vagy külső oldalon.
A Controls in Action fázis 20. lépéséből: 8.18–8.26. kontrollok.
Ez gyakorlati auditútvonalat ad: a DNS-t külső hálózati szolgáltatásként kell kezelni, dokumentálni kell, hogyan védett, és rögzíteni kell, hogy a felelősség belső oldalon, a regisztrátornál, a DNS-szolgáltatónál vagy egy MSP-nél van-e.
A Clarysec Zenith Controls: The Cross-Compliance Guide Zenith Controls azért hasznos, mert a DNS-irányítás ritkán feleltethető meg egyetlen keretrendszernek. Ugyanaz a DNSSEC- vagy nyilvántartói zárolási döntés támogatja az ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 és COBIT 2019 szerinti bizonyítékokat.
A beszállítói felügyeletnél a Zenith Controls az ISO/IEC 27002:2022 5.22 kontrollját, a beszállítói szolgáltatások felügyeletét, felülvizsgálatát és változáskezelését megelőző kontrollként térképezi fel, amely támogatja a bizalmasságot, a sértetlenséget és a rendelkezésre állást. DNS esetén ez azt jelenti, hogy a regisztrátor és a DNS-szolgáltató nem „beállítjuk és elfelejtjük” típusú beszállító. Biztonsági helyzetüket, szolgáltatásváltozásaikat, kieséseiket, al-adatfeldolgozóikat és bejelentési gyakorlatukat felül kell vizsgálni.
A DNSSEC és a kriptográfiai sértetlenség esetében a Zenith Controls az ISO/IEC 27002:2022 8.24 kontrollját, a kriptográfia használatát megelőző kontrollként térképezi fel, amely összhangban áll a biztonságos konfigurációval. A DNSSEC nem a DNS-forgalom titkosítása, hanem kriptográfiai bizonyosság a DNS-adatok sértetlenségére és eredethitelességére.
A DNS-zónaszerkesztések esetében a Zenith Controls az ISO/IEC 27002:2022 8.32 kontrollját, a változáskezelést megelőző kontrollként térképezi fel, amely támogatja a bizalmasságot, a sértetlenséget és a rendelkezésre állást. A DNS-módosítás konfigurációváltozás. Egy DS rekord frissítéséhez, MX rekord módosításához, CNAME-migrációhoz, SPF- vagy DMARC-frissítéshez, CDN-átálláshoz vagy névszerver-delegálás módosításához jegy, kockázatértékelés, jóváhagyás, teszteredmény és visszaállítási terv szükséges.
DNSSEC, nyilvántartói zárolás és kulcskezelés kritikus domaineknél
Nem minden domain hordoz azonos kockázatot. Egy kizárólag megszemélyesítés megelőzésére használt védekező domainhez elegendő lehet a felügyelet és a megújítási fegyelem. Egy elsődleges ügyfélportál-domainhez a legerősebb elérhető kontrollok szükségesek.
Kritikus domainekre a Clarysec jellemzően az alábbi alapkövetelményeket javasolja:
- DNSSEC bekapcsolva és ellenőrizve ott, ahol a nyilvántartó, a regisztrátor és a DNS-szolgáltató támogatja
- DS rekordok felülvizsgálva minden DNS-szolgáltatói migráció után
- Dokumentált KSK- és ZSK-rotációs folyamat, ahol a kulcsokat az ügyfél kezeli
- Nyilvántartói zárolás bekapcsolva az elsődleges éles, identitás-, API-, fizetési és e-mail-domainekre
- Regisztrátori zárolás bekapcsolva minden domainre, kivéve, ha dokumentált ideiglenes kivétel áll fenn
- MFA kikényszerítve minden regisztrátori és DNS-szolgáltatói felhasználónál
- Emelt jogosultságú felhasználók korlátozva, névre szólóan kijelölve, jóváhagyva és felülvizsgálva
- Break-glass hozzáférés dokumentálva és tesztelve
- Zónafájl-felügyelet riasztásokkal az NS, DS, DNSKEY, MX, TXT, A, AAAA, CNAME, CAA és wildcard módosításokra
- Külső felügyelet több feloldóból és régióból
- Bizonyítékok megőrizve az IBIR dokumentumtárban
A Clarysec vállalati Kriptográfiai kontrollok szabályzata Kriptográfiai kontrollok szabályzata adja a DNSSEC-kulcsok irányítási kapcsolódási pontját:
Központi Kulcskezelési Nyilvántartást kell fenntartani valamennyi kriptográfiai kulcs, azok életciklusállapota, kijelölt gondnokai és használati kontextusai rögzítésére.
Az „Irányítási követelmények” szakasz 5.2. szabályzati pontjából.
Ha a szervezet közvetlenül kezeli a DNSSEC-kulcsokat, vagy a regisztrátornál kontrollálja a DS közzétételt, a Kulcskezelési Nyilvántartásnak dokumentálnia kell a kulcsőrzési felelősséget, az életciklusállapotot, a rotációs dátumokat és a jóváhagyási hatáskört. Ha a DNS-szolgáltató kezeli a DNSSEC-kulcsokat, a beszállítói bejegyzésnek ismertetnie kell ezt a felelősséget, és tartalmaznia kell a bizonyossági bizonyítékokat.
Regisztrátori hozzáférés-irányítás: MFA, legkisebb jogosultság elve és vészhelyzeti kontroll
A regisztrátori fiókok gyakran a vállalat életének korai szakaszában jönnek létre, majd feledésbe merülnek, ahogy a vállalat érettebbé válik. Alapítók, ügynökségek, fejlesztők, pénzügyi felhasználók és MSP-k mind rendelkezhetnek korábbi hozzáféréssel. Ez súlyos kontrollgyengeség.
A Clarysec Felhasználói fiók- és jogosultságkezelési szabályzat - KKV Felhasználói fiók- és jogosultságkezelési szabályzat - KKV kimondja:
Az emelt vagy adminisztratív jogosultságokhoz az ügyvezető vagy az informatikai vezető további jóváhagyása szükséges, és azokat dokumentálni kell, időben korlátozni kell, valamint időszakos felülvizsgálat alá kell vonni.
A „A szabályzat végrehajtásának követelményei” szakasz 6.2.2. szabályzati pontjából.
Ezt szó szerint kell alkalmazni a regisztrátori és DNS-szolgáltatói hozzáférésekre:
- Nincsenek megosztott regisztrátori adminisztrátori fiókok
- MFA minden felhasználónál, lehetőség szerint adathalászattal szemben ellenálló formában
- Névre szóló vészhelyzeti kapcsolattartók dokumentált hatáskörrel
- A számlázási felhasználók és a műszaki adminisztrátorok szétválasztása, ahol lehetséges
- Volt munkavállalók, ügynökségek és beszállítók haladéktalan eltávolítása
- Negyedéves emelt jogosultságú hozzáférés-felülvizsgálat kritikus domaineknél
- Kivételek rögzítése lejárati dátummal
- Tesztelt vészhelyzeti feloldási és helyreállítási eljárások, amelyek nem hoznak létre nem biztonságos éles változtatásokat
A nyilvántartói zárolás bizonyítékainak tartalmazniuk kell képernyőképeket vagy regisztrátori nyilatkozatokat a bekapcsolt állapotról, a jogosult kapcsolattartókról, a feloldási folyamatról és az utolsó felülvizsgálat dátumáról.
Zónamódosítások kezelése: kis DNS-szerkesztések, nagy üzleti hatás
A DNS-módosítások megtévesztően kicsik. Egy TXT rekord igazolhatja egy SaaS platform tulajdonjogát. Egy CNAME átirányíthatja az ügyfeleket egy új környezetbe. Egy MX rekord átirányíthatja a levelezést. Egy CAA rekord befolyásolhatja a tanúsítványkiadást. Egy hibás DS rekord miatt egy aláírt domain ellenőrzése meghiúsulhat.
A Clarysec Változáskezelési szabályzat - KKV Változáskezelési szabályzat - KKV kimondja:
Minden változtatást változtatási kérelemként kell benyújtani (e-mailben, űrlapon vagy helpdesk-jegyen keresztül).
Az „Irányítási követelmények” szakasz 5.1.1. szabályzati pontjából.
Vállalati ügyfelek esetén a Clarysec Változáskezelési szabályzat Változáskezelési szabályzat magasabb bizonyítékelvárást határoz meg:
Minden változáskérelmet, felülvizsgálatot, jóváhagyást és alátámasztó bizonyítékot a központi Változáskezelő Rendszerben kell rögzíteni.
A „A szabályzat végrehajtásának követelményei” szakasz 6.1.1. szabályzati pontjából.
A Zenith Blueprint ezt megerősíti a Controls in Action fázis 21. lépésében:
Válasszon ki 2–3 közelmúltbeli rendszer- vagy konfigurációváltozást, és ellenőrizze, hogy azokat a formális változáskezelési munkafolyamaton keresztül dolgozták-e fel.
✓ Elvégezték a kockázatok értékelését? ✓ Dokumentálták a jóváhagyásokat? ✓ Szerepelt visszaállítási terv?
Ellenőrizze, hogy a változtatásokat a tervek szerint hajtották-e végre, és hogy minden incidenst vagy váratlan hatást rögzítettek-e. Vizsgálja felül a naplókat, a verziókezelési diffeket vagy az auditnyomokat olyan eszközökből, mint a ServiceNow, a Jira vagy a Git. Rögzítse ezt a folyamatot egy Változásbejegyzés-összefoglaló naplóban audit hivatkozás céljára.
A Controls in Action fázis 21. lépéséből: 8.27–8.34. kontrollok.
Egy DNS-specifikus változtatási jegynek tartalmaznia kell az érintett domaint és zónát, a rekordtípust, a módosítás előtti és utáni értékeket, az üzleti indokot, a kockázatértékelést, a végrehajtási ablakot, a jóváhagyót, a végrehajtót, az ellenőrzőt, a DNS-terjedési ellenőrzéseket, a DNSSEC-ellenőrzést, a visszaállítási tervet, a módosítás utáni felügyeletet és az exportált bizonyítékokat.
Az audit alapelve egyszerű: a DNS-módosításoknak a kérelemtől a jóváhagyáson és a végrehajtáson át az ellenőrzésig visszakövethetőnek kell lenniük.
Felügyelet és naplózás: észlelje a DNS-módosítást az ügyfelek előtt
Egy erős DNS-irányítási program abból indul ki, hogy a megelőzés hibázhat. A felügyeletnek elég gyorsan kell észlelnie a váratlan módosítást ahhoz, hogy támogassa az incidensreagálást.
A Clarysec Hálózatbiztonsági szabályzat - KKV Hálózatbiztonsági szabályzat - KKV egyértelműen fogalmaz:
A DNS-naplózást engedélyezni kell a fenyegetésvadászat és az incidensreagálás támogatására
A „A szabályzat végrehajtásának követelményei” szakasz 6.6.3. szabályzati pontjából.
A vállalati Naplózási és felügyeleti szabályzat Naplózási és felügyeleti szabályzat ugyanezt a működési elvárást veszi alapul:
Minden hatály alá tartozó rendszernek olyan naplókat kell előállítania, amelyek rögzítik:
A „A szabályzat végrehajtásának követelményei” szakasz 6.1.1. szabályzati pontjából.
A DNS- és regisztrátori irányításban a hatály alá tartozó rendszerek közé kell sorolni a regisztrátori portálokat, a DNS-tárhelykonzolokat, az API-alapú DNS-kezelést, a DNS-t kódként telepítő CI/CD pipeline-okat, a SIEM-riasztásokat és a külső felügyeleti eszközöket.
| Esemény | Miért fontos | Minimális bizonyíték |
|---|---|---|
| NS rekord módosítása | A teljes domaint támadó által kontrollált DNS-re irányíthatja | Riasztás, jegy, jóváhagyó és módosítás előtti/utáni értékek |
| DS vagy DNSKEY módosítása | Megtörheti a DNSSEC-ellenőrzést, vagy sértetlenség elleni támadásokat tehet lehetővé | DNSSEC-ellenőrzési jelentés és változásbejegyzés |
| MX módosítása | Átirányíthatja az e-mail-forgalmat, és támogathatja az adathalászatot vagy az adatelfogást | Riasztás, levélforgalmi teszt és jóváhagyás |
| TXT módosítása | SaaS-tulajdonjogot, e-mail-hitelesítést vagy tanúsítványkiadást igazolhat | Változtatási jegy, kérelmező és üzleti indoklás |
| CAA módosítása | Befolyásolhatja a tanúsítványkiadási kontrollokat | Tanúsítványirányítási felülvizsgálat |
| Wildcard rekord hozzáadása | Széles körű útválasztási vagy átvételi kockázatot hozhat létre | Kockázatértékelés és jóváhagyás |
| Regisztrátori bejelentkezés szokatlan helyről | Fiókkompromittálódási kockázatra utal | SIEM-riasztás és vizsgálati megjegyzés |
| Nyilvántartói zárolás feloldási kérelme | Magas kockázatú módosítás, amely eszkalációt igényel | Vészhelyzeti jóváhagyás és intézkedés utáni felülvizsgálat |
A felügyeletet integrálni kell az incidensreagálásba. Az olyan DNS-riasztás, amelynek nincs gazdája, súlyossági besorolása vagy forgatókönyve, csak zaj.
NIS2, DORA és GDPR: DNS-irányítás mint szabályozói bizonyíték
A NIS2 Article 21 megfelelő és arányos technikai, operatív és szervezeti intézkedéseket ír elő a hálózati és információs rendszereket érintő kockázatok kezelésére és az incidensek hatásának minimalizálására. A DNS-irányítás természetesen kapcsolódik az eszközkezeléshez, a hozzáférés-szabályozáshoz, a kriptográfiához, az ellátási lánc biztonságához, az incidenskezeléshez, az üzletmenet-folytonossághoz és a hatékonyságértékeléshez.
A NIS2 Article 20 a kiberbiztonságot a vezető testület felelősségévé is teszi. Az igazgatóságoknak nem kell minden TXT rekordot jóváhagyniuk, de érteniük kell, hogy a kritikus domaineket védi-e DNSSEC, nyilvántartói zárolás, MFA, felügyelet és tesztelt helyreállítás. Jelentős incidensek esetén a NIS2 Article 23 szakaszos jelentéstételt vezet be, beleértve a 24 órán belüli korai figyelmeztetést, a 72 órán belüli incidensbejelentést és az incidensbejelentést követő legkésőbb egy hónapon belüli zárójelentést.
Szabályozott pénzügyi szervezeteknél a DORA 2025. január 17-től alkalmazandó, és ágazatspecifikus IKT-reziliencia keretrendszerként működik ott, ahol átfedésben van a NIS2-vel. A DNS gyakran támogat kritikus vagy fontos funkciókat, például fizetési alkalmazásokat, mobilbankot, kereskedési portálokat, ügyfélidentitást, csalásmegelőzési rendszereket, API-átjárókat és harmadik fél integrációkat. A DORA szerinti bizonyítékoknak be kell mutatniuk az IKT-eszközfüggőségek feltérképezését, az incidensbesorolást, a rezilienciatesztelést, a harmadik fél kockázatkezelést és a helyreállítási tervezést DNS- és regisztrátori hibaforgatókönyvekre.
Egy DNS-incidens önmagában nem automatikusan GDPR szerinti személyesadat-sértés. Azzá válhat, ha a felhasználókat adathalász oldalra irányítják, hitelesítő adatokat gyűjtenek, személyes adatokat tartalmazó e-maileket átirányítanak, személyes adatokat kezelő rendszerek felé irányuló forgalmat elfognak, vagy a személyes adatok rendelkezésre állása érdemben sérül. A GDPR Article 5 sértetlenséget, bizalmasságot és elszámoltathatóságot ír elő. Az Article 32 megfelelő adatkezelési biztonsági intézkedéseket követel meg. A DNS-irányítás bizonyítékot ad arra, hogy a domainútválasztás és a DNS-függő szolgáltatások arányos technikai és szervezeti intézkedésekkel védettek.
| Kontrollintézkedés | ISO/IEC 27001:2022 Annex A és ISO/IEC 27002:2022 | NIS2 | DORA | GDPR |
|---|---|---|---|---|
| Domain-eszköznyilvántartás | 5.9 Információk és kapcsolódó eszközök nyilvántartása | Article 21(2)(i) | Article 8 | Articles 5 and 32 |
| Regisztrátor mint beszállító | 5.19, 5.20, 5.22 | Article 21(2)(d) | Chapter V | Article 28 and Article 32 |
| Regisztrátori hozzáférés-szabályozás és MFA | 5.15, 5.16, 5.18, 8.5 | Article 21(2)(i) and 21(2)(j) | Article 9 | Article 32 |
| Nyilvántartói és regisztrátori zárolás | 5.15, 8.20, 8.21, 8.32 | Article 21(2)(a) and 21(2)(e) | Articles 9, 10 and 11 | Article 32 |
| DNS-zónamódosítások kezelése | 8.9, 8.32 | Article 21(2)(a) and 21(2)(e) | Articles 9, 10 and 11 | Articles 5 and 32 |
| DNSSEC bevezetése | 8.24 Kriptográfia használata | Article 21(2)(h) | Articles 9 and 10 | Article 32 |
| DNS-naplózás és -felügyelet | 8.15 Naplózás, 8.16 Megfigyelési tevékenységek | Article 21(2)(a), 21(2)(b) and 21(2)(f) | Articles 10 and 17 | Articles 5, 32 and 33 |
Építsen DNS-bizonyítékcsomagot egy hét alatt
Egy gyakorlati DNS-irányítási korrekciós terv gyorsan végrehajtható, ha bizonyítékalapú.
1. nap: Hozza létre a domain- és DNS-szolgáltatásnyilvántartást
Induljon ki az Eszközkezelési szabályzat - KKV azon követelményéből, amely előírja a tulajdonosi felelősség, a cél, a hozzáférési jogosultságok és a megújítási határidők dokumentálását.
| Mező | Példa |
|---|---|
| Domain | example.com |
| Üzleti cél | Ügyfélportál, API, e-mail |
| Kritikusság | Kritikus |
| Regisztrátor | A regisztrátor |
| Nyilvántartói zárolás | Bekapcsolva |
| Regisztrátori zárolás | Bekapcsolva |
| DNS-szolgáltató | B menedzselt DNS-szolgáltató |
| DNSSEC | Bekapcsolva, DS közzétéve |
| Tulajdonos | Platformvezető |
| Biztonsági tulajdonos | CISO |
| Megújítási dátum | 2027-04-12 |
| Felügyelet | SIEM-riasztás és külső DNS-monitor |
| Változáskezelési munkafolyamat | Jira DNS-változástípus |
| Beszállítói felülvizsgálat dátuma | 2026-03-15 |
2. nap: Vizsgálja felül a hozzáférést és a jogosultságokat
Exportálja a regisztrátori és DNS-szolgáltatói felhasználókat. Távolítsa el az elavult fiókokat. Kényszerítse ki az MFA-t. Azonosítsa az adminisztrátorokat. Rögzítse az emelt jogosultságú felhasználók jóváhagyási bizonyítékait, és dokumentálja a vészhelyzeti hozzáférést.
3. nap: Ellenőrizze a DNSSEC-et és a zárolásokat
Minden kritikus domainnél ellenőrizze a DNSSEC-lánc érvényességét, a DS rekordok pontosságát, a DNSKEY láthatóságát, a regisztrátori zárolást és a nyilvántartói zárolást. Ha a DNSSEC-et a szolgáltató kezeli, dokumentálja a szolgáltató felelősségét. Ha az ügyfél kezeli, adja hozzá a DNSSEC-kulcsokat és a kulcsgondnokokat a Kulcskezelési Nyilvántartáshoz.
4. nap: Alakítsa a DNS-módosításokat formális változásbejegyzésekké
Válassza ki az utolsó három DNS-módosítást, és tesztelje őket a Zenith Blueprint 21. lépésének szempontjai alapján: volt-e kockázatértékelés, dokumentált jóváhagyás, visszaállítási terv, a terv szerinti végrehajtás és váratlan hatás rögzítése. Hozzon létre Változásbejegyzés-összefoglaló naplót.
5. nap: Kapcsolja össze a felügyeletet az incidensreagálással
Erősítse meg a regisztrátori bejelentkezésekre, zónamódosításokra, DNSSEC-módosításokra, NS-módosításokra, MX-módosításokra, TXT-módosításokra, CAA-módosításokra és szolgáltatói értesítésekre vonatkozó naplók és riasztások meglétét. Küldjön tesztriasztásokat a SOC-nak vagy az IT-felelősnek. Csatolja a bizonyítékokat az IBIR dokumentumtárhoz.
6. nap: Vizsgálja felül a beszállítói kötelezettségeket
Használja a Zenith Blueprint 23. lépésének iránymutatását a beszállítói változás- és felügyeleti eljárásokhoz:
Hozzon létre egyszerű, skálázható eljárást a beszállítói szolgáltatások változásainak (5.21) értékelésére, például felhőbe migrálás, új al-adatfeldolgozók vagy infrastruktúra-újratervezés esetén. Határozza meg azokat a kiváltó okokat, amelyek biztonsági újraértékelést igényelnek. Ezután vezessen be ismétlődő beszállítói felügyeleti ütemezést (5.22), rendeljen gazdákat a kritikus beszállítókhoz, és biztosítsa, hogy a teljesítményt, a megfelelést és a kockázatokat legalább évente felülvizsgálják.
A Controls in Action fázis 23. lépéséből: szervezeti kontrollok 5.19–5.37.
A Clarysec vállalati Harmadik fél és beszállítói biztonsági szabályzat Harmadik fél és beszállítói biztonsági szabályzat adja a szerződéses kapcsolódási pontot:
A beszállítókkal kötött szerződéseknek tartalmazniuk kell:
Az „Irányítási követelmények” szakasz 5.3. szabályzati pontjából.
| Szerződéses téma | DNS-specifikus követelmény |
|---|---|
| Biztonsági felelősségek | Ki kezeli a DNSSEC-et, a zárolásokat, a naplókat, a hozzáférést, a biztonsági mentéseket és a változtatás-jóváhagyásokat |
| Incidensbejelentés | Határidők és csatornák regisztrátori kompromittálódás, DNS-kiesés vagy jogosulatlan módosítás esetén |
| Támogatási eszkaláció | 24/7 vészhelyzeti út kritikus domainekhez |
| Változásbejelentés | Előzetes értesítés platformmigrációkról, API-módosításokról és al-adatfeldolgozói változásokról |
| Bizonyíték | Hozzáférési naplók, változáselőzmények, zárolási állapot, DNSSEC-állapot és rendelkezésre állási jelentések |
| Kilépés | Domainátadás, zónaexport, DNSSEC-migráció és zároláseltávolítási eljárás |
7. nap: Futtasson asztali gyakorlatot
Szimuláljon jogosulatlan NS rekord módosítást. A csapatnak észlelnie kell, be kell sorolnia, eszkalálnia kell, kapcsolatba kell lépnie a regisztrátorral, szükség esetén aktiválnia kell a nyilvántartói zárolási eljárásokat, vissza kell állítania a helyes delegálást, ellenőriznie kell a DNSSEC-et, értesítenie kell az érdekelt feleket, értékelnie kell a GDPR-hatást, és el kell döntenie, hogy teljesülnek-e a NIS2 vagy DORA jelentéstételi küszöbértékei. Rögzítse a tanulságokat és frissítse az eljárásokat.
Auditkérdések, gyakori megállapítások és igazgatósági mutatók
A DNS-irányítási auditot ritkán végzik egyetlen nézőpontból.
| Auditori nézőpont | Valószínű auditkérdés | Erős bizonyíték |
|---|---|---|
| ISO/IEC 27001:2022 auditor | A domainek hatályban vannak, kockázatértékeltek, van gazdájuk, kontrolláltak, felügyeltek és szerepelnek a beszállítói irányításban? | IBIR alkalmazási területe, kockázati nyilvántartás, eszköznyilvántartás, alkalmazhatósági nyilatkozat, változtatási jegyek, beszállítói felülvizsgálatok és naplók |
| NIST CSF 2.0 értékelő | A DNS-kockázatok irányítottak, azonosítottak, védettek, észleltek, kezelték őket, és helyreállíthatók? | Current and Target Profile, hiányossági terv, eszköznyilvántartás, hozzáférés-szabályozás, felügyeleti riasztások és helyreállítási nyilvántartások |
| DORA-felülvizsgáló | Támogat-e a DNS kritikus vagy fontos funkciókat, és a függőség irányított, tesztelt és helyreállítható? | IKT-eszközfüggőségi térkép, rezilienciateszt-terv, incidensbesorolási folyamat, harmadik fél nyilvántartás és helyreállítási bizonyítékok |
| GDPR-felülvizsgáló | Érinthet-e egy DNS-incidens személyes adatokat, és a szervezet igazolni tudja-e a megfelelő biztonságot? | Article 32 bizonyíték, incidensértékelés, adatfeldolgozói felügyelet, hozzáférés-szabályozási, változáskezelési és felügyeleti nyilvántartások |
| COBIT 2019 vagy ISACA auditor | A domainhez kapcsolódó irányítási célkitűzések tulajdonosi felelősséggel, mutatókkal és bizonyossággal rendelkező kezelt folyamatokká alakultak? | RACI, folyamatcélok, KPI-k, KRI-k, beszállítói teljesítmény-felülvizsgálatok, vezetői jelentéstétel és helyesbítő intézkedések nyomon követése |
A leggyakoribb megállapítások előre láthatók.
| Megállapítás | Kockázat | Clarysec javítás |
|---|---|---|
| Domainek hiányoznak az eszköznyilvántartásból | Lejárat, tulajdonosi zavar és hiányos kockázatértékelés | Vegye fel a domaineket az eszköznyilvántartásba tulajdonossal, céllal, kritikussággal, megújítással és függőségekkel |
| Megosztott regisztrátori adminisztrátori fiók | Nincs elszámoltathatóság és gyenge incidensforenzika | Átállás névre szóló felhasználókra, MFA-ra, a legkisebb jogosultság elvére és negyedéves felülvizsgálatokra |
| Nincs nyilvántartói zárolás kritikus domainen | Nagy hatású jogosulatlan delegálás vagy átadás | Kapcsolja be a nyilvántartói zárolást, és dokumentálja a vészhelyzeti feloldási eljárást |
| A DNSSEC részlegesen engedélyezett | Ellenőrzési hibák vagy hamis bizonyosság | Ellenőrizze a láncot, a DS rekordokat, a kulcstulajdonlást és a rotációs tervet |
| DNS-módosítások jegy nélkül történnek | Kiesés, hibás útválasztás és audithiba | Követeljen meg formális DNS-változástípust jóváhagyással és visszaállítási tervvel |
| Nincs riasztás NS vagy MX módosításokra | Lassú észlelés eltérítés vagy levélátirányítás esetén | Integrálja a DNS-felügyeletet a SIEM-mel és az eszkalációs forgatókönyvvel |
| A regisztrátort nem vizsgálják felül beszállítóként | Szerződéses és incidensreagálási hiányosságok | Vegye fel a regisztrátort és a DNS-szolgáltatót a beszállítói felügyeleti ütemezésbe |
| Nincs incidens-forgatókönyv | Késedelmes helyreállítás és jelentéstételi bizonytalanság | Hozzon létre DNS-eltérítési és DNS-kiesési helyreállítási forgatókönyveket, majd tesztelje őket asztali gyakorlattal |
Az igazgatóságoknak és a vezetői csapatoknak reziliencianyelven megfogalmazott DNS-mutatókra van szükségük. Hasznos mérőszámok: a DNSSEC-kel ellátott és ellenőrzött kritikus domainek aránya, a nyilvántartói zárolással védett domainek aránya, a regisztrátori adminisztrátorok száma, az előző negyedévben felülvizsgált emelt jogosultságú felhasználók aránya, formális jegy nélkül végrehajtott DNS-módosítások száma, jogosulatlan DNS-módosítás észleléséig eltelt átlagos idő, helyes DNS-konfiguráció visszaállításáig eltelt átlagos idő, 90 napon belül lejáró domainek, elvégzett beszállítói felülvizsgálatok és megoldatlan DNS-felügyeleti riasztások.
Alakítsa a DNS-t rejtett kockázatból auditra kész bizonyítékká
Ha a szervezet az elmúlt hat hónapban nem vizsgálta felül a domain- és DNS-irányítást, feltételezze, hogy sodródás történt. Kezdje a kritikus éles domainekkel, majd terjessze ki a regionális domainekre, a védekező domainekre, a tesztdomainekre, az akvizícióból származó domainekre, valamint az ügynökségek vagy leányvállalatok által kezelt domainekre.
A Clarysec segíthet abban, hogy a szétszórt regisztrátori képernyőképekből strukturált bizonyítékcsomag készüljön az alábbiak használatával:
- Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint a hálózati szolgáltatások, a változáskezelés, a naplózás, a felügyelet és a beszállítói kontrollok lépésről lépésre történő ellenőrzéséhez
- Zenith Controls: The Cross-Compliance Guide Zenith Controls a DNSSEC, a nyilvántartói zárolás, a beszállítói felügyelet és a zónamódosítás-irányítás megfeleltetéséhez ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST és COBIT 2019 nézőpontok között
- Clarysec szabályzatsablonok, beleértve az Eszközkezelési szabályzat - KKV, Változáskezelési szabályzat - KKV, Felhasználói fiók- és jogosultságkezelési szabályzat - KKV, Hálózatbiztonsági szabályzat - KKV, Eszközkezelési szabályzat, Változáskezelési szabályzat, Naplózási és felügyeleti szabályzat, Kriptográfiai kontrollok szabályzata, valamint Harmadik fél és beszállítói biztonsági szabályzat sablonokat
A domain a digitális üzlet első bejárata. 2026-ban az auditorok, a szabályozó hatóságok, az ügyfelek és az igazgatóságok el fogják várni, hogy igazolja: ez a bejárat zárt, felügyelt, helyreállítható és irányított.
Töltse le a Clarysec eszközkészletet, futtassa le az egyhetes DNS-bizonyítékcsomag-gyakorlatot, vagy foglaljon Clarysec-értékelést, hogy a DNS- és regisztrátori irányítást auditra alkalmas bizonyítékká alakítsa, mielőtt bekövetkezne a saját hétfő reggeli válsága.
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


