DNS pārvaldība 2026. gadā: auditam gatavi reģistratora kontroles pasākumi
Pirmdienas rītā plkst. 07:42 strauji augoša finanšu tehnoloģiju uzņēmuma informācijas drošības vadītājs saņem ziņu, ko neviens nevēlas redzēt. Klienti nevar piekļūt maksājumu portālam, palīdzības dienests ir pārslogots, e-pasts nedarbojas, un SOC nav konstatējis ne ļaunatūru, ne ugunsmūra atteici, ne mākoņpakalpojumu sniedzēja incidentu.
Pamatcēlonis ir klusāks un nepatīkamāks. Reģistratora kontam piekļuva, izmantojot novecojušus administratora autentifikācijas datus, kurus koplietoja vairāki bijušie IT darbinieki. Uzbrucējs nomainīja autoritatīvos vārdu serverus, mainīja MX ierakstus, atspējoja DNSSEC un pietiekami ilgi novirzīja datplūsmu, lai iegūtu autentifikācijas datus un traucētu partneru API darbību. Maksājumu portāls netika uzlauzts tradicionālā nozīmē. Tika kompromitēts uzņēmuma uzticības enkurs — tā domēns.
Līdz plkst. 09:30 darbības krīze ir kļuvusi par atbilstības krīzi. Valde jautā, vai bija iespējota reģistra bloķēšana. Juridiskais dienests jautā, vai tika izpausti personas dati. Datu aizsardzības speciālists jautā, vai tas ir GDPR personas datu aizsardzības pārkāpums. Regulators vēlas zināt, vai tika ietekmēta kritiska vai svarīga funkcija. Klienta auditors pieprasa izmaiņu pieteikumu, ar kuru tika apstiprināta DNS izmaiņa.
Pārāk daudzās organizācijās atbilde ir izklājlapa, koplietota pastkaste un reģistratora konsole, kuru neviens nav pārskatījis sešus mēnešus.
DNS un domēnu reģistratora pārvaldība 2026. gadā vairs nav šaurs infrastruktūras jautājums. Tā ir daļa no noturības pret izspiedējprogrammatūru, pikšķerēšanas novēršanas, mākoņpakalpojumu pieejamības, piegādātāju risku pārvaldības, reaģēšanas uz incidentiem, darbības nepārtrauktības un pierādījumos balstītas atbilstības. Ja jūsu domēnu var pārņemt, jūsu SaaS platforma var pazust. Ja DNS ierakstus var mainīt bez apstiprinājuma, jūsu e-pasta drošību, SSO, TLS sertifikātus, API galapunktus un klientu uzticēšanos var apdraudēt dažu minūšu laikā.
Kāpēc DNS un reģistratora pārvaldībai jābūt IDPS daļai
Domēna vārds nav tikai zīmola aktīvs. Tas ir loģisks aktīvs, autentifikācijas atkarība, maršrutēšanas atkarība un bieži vien piegādātāja pārvaldīts pakalpojums. Tas sasaista identitātes nodrošinātājus, e-pasta autentifikāciju, TLS sertifikātu validāciju, mākoņa galapunktus, klientu portālus, API, CDN pakalpojumus, uzraudzības zondes un incidentu komunikāciju.
Clarysec Aktīvu pārvaldības politika - SME Aktīvu pārvaldības politika - SME to skaidri nosaka savā piemērošanas jomā:
Digitālie autentifikācijas dati un pakalpojumi: domēna vārdi, digitālie sertifikāti, API atslēgas, e-pasta konti, mākoņpakalpojumu pieteikšanās dati
No sadaļas “Piemērošanas joma”, politikas punkts 2.2.4.
Tā pati politika prasa vairāk nekā tikai domēna vārda uzskaitīšanu:
Īpašumtiesībām, mērķim, piekļuves privilēģijām un atjaunošanas termiņiem jābūt dokumentētiem.
No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.6.2.
Uzņēmuma vidēm Clarysec Aktīvu pārvaldības politika Aktīvu pārvaldības politika piemērošanas jomā ietver arī loģiskos aktīvus:
Loģiskie aktīvi: domēna vārdi, licences, lietotāju konti, pamatkonfigurācijas
No sadaļas “Piemērošanas joma”, politikas punkts 2.2.5.
Tas ir pārvaldības sākumpunkts. DNS un reģistratora uzskaitei jādokumentē:
- Domēna vārds, reģistrs, reģistrators, DNS mitināšanas pakalpojumu sniedzējs un autoritatīvie vārdu serveri
- Biznesa īpašnieks, tehniskais īpašnieks, drošības īpašnieks un ārkārtas apstiprinātājs
- Mērķis, piemēram, ražošanas portāls, API, e-pasts, SSO, mārketings, testa vide vai aizsargreģistrācija
- Kritiskuma vērtējums un atkarību kartēšana ar biznesa pakalpojumiem
- DNSSEC statuss, DS ieraksta statuss, atslēgu īpašumtiesības un atslēgu rotācijas process
- Reģistra bloķēšanas un reģistratora bloķēšanas statuss
- MFA un privileģētās piekļuves modelis reģistratora un DNS pakalpojumu sniedzēja kontiem
- Atjaunošanas datums, automātiskās atjaunošanas statuss, maksājuma īpašnieks un brīdinājumi par termiņa beigām
- Izmaiņu kontroles prasības zonas ierakstu labojumiem un deleģēšanas izmaiņām
- Žurnālfiksēšana, brīdināšana, uzraudzība un pierādījumu glabāšana
Tāpēc domēnu pārvaldībai jābūt iekļautai ISO/IEC 27001:2022 IDPS darbības jomā un risku izvērtēšanā. ISO/IEC 27001:2022 prasa organizācijām noteikt kontekstu, ieinteresēto pušu prasības, juridiskos un līgumiskos pienākumus, saskarnes un atkarības ar ārējām organizācijām. DNS ir atkarīgs no reģistratoriem, reģistriem, DNS mitināšanas pakalpojumu sniedzējiem, mākoņpakalpojumu sniedzējiem, sertifikācijas iestādēm, MSP un dažkārt arī mārketinga aģentūrām. Ja šīs saskarnes tiek izslēgtas no IDPS, audita pēda būs nepilnīga.
2026. gada DNS apdraudējumu modelis
Bieži vien viskaitīgākās DNS kļūmes ir vienkāršas:
- Domēna termiņš beidzas, jo atbildība par atjaunošanu nav skaidra.
- Bijušai aģentūrai joprojām ir piekļuve reģistratora kontam.
- DNSSEC ir iespējots, bet pēc migrācijas uz citu DNS pakalpojumu sniedzēju DS ieraksti ir nepareizi.
- Aizstājējzīmes ieraksts novirza datplūsmu uz pamestu mākoņpakalpojumu.
- TXT ieraksts tiek mainīts, lai validētu uzbrucēja kontrolētu SaaS nomnieku vai sertifikāta pieprasījumu.
- MX ieraksti tiek mainīti pikšķerēšanas vai e-pasta pārtveršanas kampaņas laikā.
- CNAME ieraksts uz trešās puses platformu kļūst uzņēmīgs pret pārņemšanu.
- Reģistra bloķēšana pastāv primārajam domēnam, bet ne klientiem pieejamiem valsts koda domēniem.
- SOC uzrauga galapunktus, bet neviens neuzrauga zonas datņu izmaiņas.
Tehniskie drošības pasākumi ir labi zināmi. DNSSEC palīdz aizsargāt DNS datu integritāti un izcelsmes autentiskumu. Reģistra bloķēšana nosaka, ka augsta riska reģistra līmeņa izmaiņām nepieciešama papildu ārpuskanāla verifikācija. Reģistratora bloķēšana samazina nesankcionētas pārcelšanas risku. MFA un privileģētās piekļuves tiesību pārskatīšana samazina konta pārņemšanas iespējamību. Izmaiņu kontrole novērš nejaušus darbības traucējumus. Uzraudzība atklāj nesankcionētas vai neparedzētas izmaiņas.
Atbilstības izaicinājums ir cits: vai varat pierādīt, ka šie drošības pasākumi pastāv, tiem ir īpašnieki, tie tiek pārskatīti un incidenta laikā darbojas?
Tieši šajā pierādījumu jautājumā daudzas organizācijas cieš neveiksmi.
DNS pārvaldības kartēšana uz ISO/IEC 27001:2022 un ISO/IEC 27002:2022
ISO/IEC 27001:2022 nodrošina pārvaldības sistēmas struktūru, lai DNS kontroles pasākumus pārvērstu atkārtojamos, auditējamos procesos. ISO/IEC 27001:2022 Annex A un ISO/IEC 27002:2022 kontroles vadlīnijas sniedz kontroles valodu, ko sagaida auditori.
| DNS pārvaldības joma | ISO/IEC 27001:2022 Annex A un ISO/IEC 27002:2022 pierādījumu tēma | Ko auditori sagaida redzēt |
|---|---|---|
| Domēnu uzskaite | 5.9 Informācijas un citu saistīto aktīvu uzskaite | Domēnu reģistrs ar īpašniekiem, kritiskumu, atjaunošanas datumiem, DNS pakalpojumu sniedzēju, reģistratoru un atkarībām |
| Reģistratora piekļuve | 5.15 Piekļuves kontrole, 5.16 Identitātes pārvaldība, 5.18 Piekļuves tiesības, 8.5 Droša autentifikācija | Vārdiski lietotāji, MFA pierādījumi, apstiprinājumu ieraksti, periodiska piekļuves tiesību pārskatīšana un ārkārtas piekļuves process |
| DNSSEC | 8.24 Kriptogrāfijas izmantošana | DNSSEC statuss, DS ieraksti, atslēgu glabāšana, rotācijas plāns un validācijas uzraudzība |
| Reģistra un reģistratora bloķēšana | 5.15 Piekļuves kontrole, 8.20 Tīkla drošība, 8.21 Tīkla pakalpojumu drošība, 8.32 Izmaiņu pārvaldība | Bloķēšanas statuss, atbloķēšanas procedūra, autorizētās kontaktpersonas un ārpuskanāla verifikācijas process |
| Zonas izmaiņu kontrole | 8.9 Konfigurācijas pārvaldība, 8.32 Izmaiņu pārvaldība | Izmaiņu pieteikumi, risku izvērtēšana, apstiprinājumi, ieviešanas pierādījumi un atcelšanas plāns |
| DNS pakalpojumu sniedzēja pārvaldība | 5.19 Informācijas drošība piegādātāju attiecībās, 5.20 Informācijas drošības noteikšana piegādātāju līgumos, 5.22 Piegādātāju pakalpojumu uzraudzība, pārskatīšana un izmaiņu pārvaldība | Līguma klauzulas, SLA, drošības pienākumi, pakalpojumu pārskatīšana un incidentu paziņošanas prasības |
| DNS žurnālfiksēšana un uzraudzība | 8.15 Žurnālfiksēšana, 8.16 Uzraudzības darbības | Žurnāli, brīdinājumi, SIEM ievade, glabāšana un brīdinājumu testu pierādījumi |
| Reaģēšana uz DNS nepieejamību | 5.24 Informācijas drošības incidentu pārvaldības plānošana un sagatavošana, 5.29 Informācijas drošība traucējumu laikā, 5.30 IKT gatavība darbības nepārtrauktībai | Reaģēšanas instrukcijas, eskalācijas saraksts, atjaunošanas procedūras un pēcincidenta gūtās mācības |
Clarysec Zenith Blueprint: auditora 30 soļu ceļvedis Zenith Blueprint tīkla pakalpojumus aplūko kā skaidrus audita objektus. Fāzē “Kontroles praksē”, 20. solī, tas norāda komandām validēt tīkla pakalpojumu drošību:
Uzskaitiet visus iekšējos un ārējos tīkla pakalpojumus (DNS, VPN, SMTP, DHCP, API vārtejas, u. c.).
✓ Katram pakalpojumam apstipriniet, ka tas izmanto drošus protokolus (piem., DNSSEC, TLS 1.2+, SSH, nevis Telnet). ✓ Pārskatiet, kā tiek kontrolēta piekļuve katram pakalpojumam (piem., IP atļauto saraksti, autentifikācija, sertifikāti). ✓ Ja tos pārvalda trešās puses (piem., DNS, SD-WAN, mitināts VPN), pārskatiet drošības klauzulas SLA vai piegādātāja līgumā. Atjauniniet pakalpojumu reģistru un norādiet, kur atrodas drošības atbildība — iekšēji vai ārēji.
No fāzes “Kontroles praksē”, 20. solis: kontroles 8.18 līdz 8.26.
Tas sniedz praktisku audita ceļu: uzskatiet DNS par ārēju tīkla pakalpojumu, dokumentējiet, kā tas ir aizsargāts, un reģistrējiet, vai atbildība ir iekšēji, pie reģistratora, pie DNS pakalpojumu sniedzēja vai pie MSP.
Clarysec Zenith Controls: pārrobežu atbilstības ceļvedis Zenith Controls ir noderīgs, jo DNS pārvaldība reti kartējas tikai uz vienu ietvaru. Tas pats DNSSEC vai reģistra bloķēšanas lēmums atbalsta ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 un COBIT 2019 pierādījumus.
Piegādātāju uzraudzībai Zenith Controls kartē ISO/IEC 27002:2022 kontroli 5.22, Piegādātāju pakalpojumu uzraudzība, pārskatīšana un izmaiņu pārvaldība, kā preventīvu kontroles pasākumu, kas atbalsta konfidencialitāti, integritāti un pieejamību. DNS gadījumā tas nozīmē, ka jūsu reģistrators un DNS pakalpojumu sniedzējs nav piegādātāji, kurus var iestatīt un aizmirst. To drošības stāvoklis, pakalpojumu izmaiņas, nepieejamība, apakšapstrādātāji un paziņošanas prakse ir jāpārskata.
DNSSEC un kriptogrāfiskās integritātes vajadzībām Zenith Controls kartē ISO/IEC 27002:2022 kontroli 8.24, Kriptogrāfijas izmantošana, kā preventīvu kontroles pasākumu, kas saskaņots ar drošu konfigurāciju. DNSSEC nav DNS datplūsmas šifrēšana, bet tas ir kriptogrāfisks apliecinājums DNS datu integritātei un izcelsmes autentiskumam.
DNS zonas ierakstu labojumiem Zenith Controls kartē ISO/IEC 27002:2022 kontroli 8.32, Izmaiņu pārvaldība, kā preventīvu kontroles pasākumu, kas atbalsta konfidencialitāti, integritāti un pieejamību. DNS izmaiņa ir konfigurācijas izmaiņa. DS ieraksta atjauninājumam, MX ieraksta izmaiņai, CNAME migrācijai, SPF vai DMARC atjauninājumam, CDN pārslēgšanai vai vārdu servera deleģēšanas izmaiņai jābūt pieteikumam, risku izvērtēšanai, apstiprinājumam, testa rezultātam un atcelšanas plānam.
DNSSEC, reģistra bloķēšana un atslēgu pārvaldība kritiskiem domēniem
Ne visiem domēniem ir vienāds risks. Aizsargdomēnam, kas tiek izmantots tikai, lai novērstu uzdošanos par organizāciju, var būt nepieciešama uzraudzība un disciplinēta atjaunošana. Primāram klientu portāla domēnam nepieciešami spēcīgākie pieejamie kontroles pasākumi.
Kritiskiem domēniem Clarysec parasti iesaka šādu pamatlīmeni:
- DNSSEC iespējots un validēts, ja to atbalsta reģistrs, reģistrators un DNS pakalpojumu sniedzējs
- DS ieraksti pārskatīti pēc jebkuras DNS pakalpojumu sniedzēja migrācijas
- Dokumentēts KSK un ZSK rotācijas process, ja atslēgas pārvalda klients
- Reģistra bloķēšana iespējota primārajiem ražošanas, identitātes, API, maksājumu un e-pasta domēniem
- Reģistratora bloķēšana iespējota visiem domēniem, ja vien nav dokumentēts pagaidu izņēmums
- MFA piemērota visiem reģistratora un DNS pakalpojumu sniedzēja lietotājiem
- Privileģētie lietotāji ierobežoti, vārdiski identificēti, apstiprināti un pārskatīti
- Ārkārtas piekļuve dokumentēta un testēta
- Zonas datņu uzraudzība ar brīdinājumiem par NS, DS, DNSKEY, MX, TXT, A, AAAA, CNAME, CAA un aizstājējzīmju izmaiņām
- Ārējā uzraudzība no vairākiem atrisinātājiem un reģioniem
- Pierādījumi glabāti IDPS repozitorijā
Clarysec uzņēmuma Kriptogrāfisko kontroles pasākumu politika Kriptogrāfisko kontroles pasākumu politika nodrošina DNSSEC atslēgu pārvaldības piesaisti:
Jāuztur centralizēts Atslēgu pārvaldības reģistrs, kurā reģistrē visas kriptogrāfiskās atslēgas, to dzīves cikla statusu, piešķirtos glabātājus un lietošanas kontekstus.
No sadaļas “Pārvaldības prasības”, politikas punkts 5.2.
Ja jūsu organizācija tieši pārvalda DNSSEC atslēgas vai kontrolē DS publicēšanu pie reģistratora, Atslēgu pārvaldības reģistrā jādokumentē glabāšana, dzīves cikla statuss, rotācijas datumi un apstiprināšanas pilnvaras. Ja DNS pakalpojumu sniedzējs pārvalda DNSSEC atslēgas, piegādātāja ierakstā šī atbildība jāpaskaidro un jāiekļauj apliecinājuma pierādījumi.
Reģistratora piekļuves pārvaldība: MFA, minimāli nepieciešamās tiesības un ārkārtas kontrole
Reģistratora konti bieži tiek izveidoti uzņēmuma darbības sākumā un pēc tam aizmirsti, uzņēmumam nobriestot. Dibinātājiem, aģentūrām, izstrādātājiem, finanšu lietotājiem un MSP var būt vēsturiska piekļuve. Tā ir nopietna kontroles vājā vieta.
Clarysec Lietotāju kontu un privilēģiju pārvaldības politika - SME Lietotāju kontu un privilēģiju pārvaldības politika - SME nosaka:
Paaugstinātām vai administratīvām privilēģijām nepieciešams papildu apstiprinājums no ģenerāldirektora vai IT vadītāja, un tām jābūt dokumentētām, laikierobežotām un pakļautām periodiskai pārskatīšanai.
No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.2.2.
Piemērojiet to tieši reģistratora un DNS pakalpojumu sniedzēja piekļuvei:
- Nav koplietotu reģistratora administratora kontu
- MFA katram lietotājam, vēlams noturīga pret pikšķerēšanu, ja tas tiek atbalstīts
- Vārdiskas ārkārtas kontaktpersonas ar dokumentētām pilnvarām
- Norēķinu lietotāju nošķiršana no tehniskajiem administratoriem, ja iespējams
- Tūlītēja bijušo darbinieku, aģentūru un piegādātāju piekļuves atņemšana
- Ceturkšņa privileģētās piekļuves pārskatīšana kritiskiem domēniem
- Izņēmumi reģistrēti ar termiņa beigu datumiem
- Testētas ārkārtas atbloķēšanas un atjaunošanas procedūras, kas nerada nedrošas izmaiņas ražošanas vidē
Reģistra bloķēšanas pierādījumos jāiekļauj ekrānuzņēmumi vai reģistratora apliecinājumi, kas parāda iespējotu statusu, autorizētās kontaktpersonas, atbloķēšanas procesu un pēdējās pārskatīšanas datumu.
Zonas izmaiņu kontrole: mazi DNS labojumi, liela ietekme uz darbību
DNS izmaiņas ir mānīgi mazas. TXT ieraksts var validēt SaaS platformas īpašumtiesības. CNAME var novirzīt klientus uz jaunu vidi. MX ieraksts var pārmaršrutēt e-pastu. CAA ieraksts var ietekmēt sertifikātu izsniegšanu. Nepareizs DS ieraksts var izraisīt parakstīta domēna validācijas atteici.
Clarysec Izmaiņu pārvaldības politika - SME Izmaiņu pārvaldības politika - SME nosaka:
Visas izmaiņas jāiesniedz kā izmaiņu pieprasījums (e-pastā, veidlapā vai palīdzības dienesta pieteikumā).
No sadaļas “Pārvaldības prasības”, politikas punkts 5.1.1.
Uzņēmuma klientiem Clarysec Izmaiņu pārvaldības politika Izmaiņu pārvaldības politika paaugstina pierādījumu prasību:
Visi izmaiņu pieprasījumi, pārskatīšanas, apstiprinājumi un atbalsta pierādījumi jāreģistrē centralizētajā Izmaiņu pārvaldības sistēmā.
No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.1.1.
Zenith Blueprint to pastiprina fāzē “Kontroles praksē”, 21. solī:
Izvēlieties 2–3 nesenas sistēmas vai konfigurācijas izmaiņas un pārbaudiet, vai tās tika apstrādātas, izmantojot jūsu formālo izmaiņu pārvaldības darbplūsmu.
✓ Vai riski tika izvērtēti? ✓ Vai apstiprinājumi tika dokumentēti? ✓ Vai bija iekļauts atcelšanas plāns?
Validējiet, ka izmaiņas tika ieviestas, kā plānots, un ka visi incidenti vai neparedzētā ietekme tika reģistrēta. Pārskatiet žurnālus, versiju kontroles atšķirības vai audita pēdas no tādiem rīkiem kā ServiceNow, Jira vai Git. Fiksējiet šo procesu Izmaiņu ierakstu kopsavilkuma žurnālā audita atsaucei.
No fāzes “Kontroles praksē”, 21. solis: kontroles 8.27 līdz 8.34.
DNS specifiskā izmaiņu pieteikumā jāiekļauj ietekmētais domēns un zona, ieraksta tips, vērtības pirms un pēc izmaiņām, biznesa pamatojums, risku izvērtēšana, ieviešanas logs, apstiprinātājs, ieviesējs, pārbaudītājs, DNS izplatīšanās pārbaudes, DNSSEC validācija, atcelšanas plāns, uzraudzība pēc izmaiņām un eksportēti pierādījumi.
Audita princips ir vienkāršs: DNS izmaiņām jābūt izsekojamām no pieprasījuma līdz apstiprinājumam, ieviešanai un verifikācijai.
Uzraudzība un žurnālfiksēšana: atklājiet DNS izmaiņas pirms klientiem
Spēcīga DNS pārvaldības programma pieņem, ka preventīvie pasākumi var neizdoties. Uzraudzībai jāatklāj neparedzētas izmaiņas pietiekami ātri, lai atbalstītu reaģēšanu uz incidentiem.
Clarysec Tīkla drošības politika - SME Tīkla drošības politika - SME to nosaka skaidri:
DNS žurnālfiksēšanai jābūt iespējotai, lai atbalstītu draudu medības un reaģēšanu uz incidentiem
No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.6.3.
Uzņēmuma Žurnālfiksēšanas un uzraudzības politika Žurnālfiksēšanas un uzraudzības politika sākas ar tādu pašu operacionālo prasību:
Visām aptvertajām sistēmām jāģenerē žurnāli, kuros fiksē:
No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.1.1.
DNS un reģistratora pārvaldībai aptvertajās sistēmās jāiekļauj reģistratora portāli, DNS mitināšanas konsoles, uz API balstīta DNS pārvaldība, CI/CD konveijeri, kas izvieto DNS kā kodu, SIEM brīdinājumi un ārējie uzraudzības rīki.
| Notikums | Kāpēc tas ir svarīgi | Minimālie pierādījumi |
|---|---|---|
| NS ieraksta izmaiņa | Var novirzīt visu domēnu uz uzbrucēja kontrolētu DNS | Brīdinājums, pieteikums, apstiprinātājs un vērtības pirms/pēc izmaiņām |
| DS vai DNSKEY izmaiņa | Var pārtraukt DNSSEC validāciju vai ļaut veikt integritātes uzbrukumus | DNSSEC validācijas pārskats un izmaiņu ieraksts |
| MX izmaiņa | Var pārmaršrutēt e-pastu un atbalstīt pikšķerēšanu vai datu pārtveršanu | Brīdinājums, e-pasta plūsmas tests un apstiprinājums |
| TXT izmaiņa | Var validēt SaaS īpašumtiesības, e-pasta autentifikāciju vai sertifikāta izsniegšanu | Izmaiņu pieteikums, pieprasītājs un biznesa pamatojums |
| CAA izmaiņa | Var ietekmēt sertifikātu izsniegšanas kontroles pasākumus | Sertifikātu pārvaldības pārskatīšana |
| Aizstājējzīmes ieraksta pievienošana | Var radīt plašu maršrutēšanas vai pārņemšanas risku | Risku izvērtēšana un apstiprinājums |
| Reģistratora pieteikšanās no neparastas atrašanās vietas | Norāda uz konta kompromitēšanas risku | SIEM brīdinājums un izmeklēšanas piezīme |
| Reģistra bloķēšanas atbloķēšanas pieprasījums | Augsta riska izmaiņa, kam nepieciešama eskalācija | Ārkārtas apstiprinājums un pēc darbības veikta pārskatīšana |
Uzraudzība jāintegrē reaģēšanā uz incidentiem. DNS brīdinājums bez īpašnieka, smaguma pakāpes vērtējuma vai reaģēšanas instrukcijas ir tikai troksnis.
NIS2, DORA un GDPR: DNS pārvaldība kā regulatīvie pierādījumi
NIS2 Article 21 prasa atbilstošus un samērīgus tehniskus, operacionālus un organizatoriskus pasākumus, lai pārvaldītu riskus tīklu un informācijas sistēmām un mazinātu incidentu ietekmi. DNS pārvaldība dabiski kartējas uz aktīvu pārvaldību, piekļuves kontroli, kriptogrāfiju, piegādes ķēdes drošību, incidentu apstrādi, darbības nepārtrauktību un efektivitātes izvērtēšanu.
NIS2 Article 20 arī nosaka kiberdrošību kā pārvaldības institūcijas atbildību. Valdēm nav jāapstiprina katrs TXT ieraksts, bet tām jāizprot, vai kritiskie domēni ir aizsargāti ar DNSSEC, reģistra bloķēšanu, MFA, uzraudzību un testētu atjaunošanu. Nozīmīgiem incidentiem NIS2 Article 23 ievieš pakāpenisku ziņošanu, tostarp agrīnu brīdinājumu 24 stundu laikā, incidenta paziņojumu 72 stundu laikā un gala ziņojumu ne vēlāk kā vienu mēnesi pēc incidenta paziņojuma.
Regulētām finanšu iestādēm DORA ir piemērojams no 2025. gada 17. janvāra un darbojas kā nozares specifiskais IKT noturības ietvars jomās, kur tas pārklājas ar NIS2. DNS bieži atbalsta kritiskas vai svarīgas funkcijas, piemēram, maksājumu lietotnes, mobilo banku, tirdzniecības portālus, klientu identitāti, krāpšanas sistēmas, API vārtejas un trešo pušu integrācijas. DORA pierādījumiem jāparāda IKT aktīvu atkarību kartēšana, incidentu klasifikācija, noturības testēšana, trešo pušu risku pārvaldība un atjaunošanas plānošana DNS un reģistratora kļūmju scenārijiem.
DNS incidents automātiski nav GDPR personas datu aizsardzības pārkāpums. Par tādu tas var kļūt, ja lietotāji tiek novirzīti uz pikšķerēšanas vietni, tiek iegūti autentifikācijas dati, tiek pārmaršrutēts e-pasts, kas satur personas datus, tiek pārtverta datplūsma uz personas datu apstrādes sistēmām vai būtiski ietekmēta personas datu pieejamība. GDPR Article 5 prasa integritāti, konfidencialitāti un pārskatatbildību. Article 32 prasa apstrādei piemērotus drošības pasākumus. DNS pārvaldība nodrošina pierādījumus, ka domēna maršrutēšana un no DNS atkarīgie pakalpojumi ir aizsargāti ar samērīgiem tehniskiem un organizatoriskiem pasākumiem.
| Kontroles pasākums | ISO/IEC 27001:2022 Annex A un ISO/IEC 27002:2022 | NIS2 | DORA | GDPR |
|---|---|---|---|---|
| Domēnu aktīvu uzskaite | 5.9 Informācijas un citu saistīto aktīvu uzskaite | Article 21(2)(i) | Article 8 | Articles 5 and 32 |
| Reģistrators kā piegādātājs | 5.19, 5.20, 5.22 | Article 21(2)(d) | Chapter V | Article 28 and Article 32 |
| Reģistratora piekļuves kontrole un MFA | 5.15, 5.16, 5.18, 8.5 | Article 21(2)(i) and 21(2)(j) | Article 9 | Article 32 |
| Reģistra un reģistratora bloķēšana | 5.15, 8.20, 8.21, 8.32 | Article 21(2)(a) and 21(2)(e) | Articles 9, 10 and 11 | Article 32 |
| DNS zonas izmaiņu kontrole | 8.9, 8.32 | Article 21(2)(a) and 21(2)(e) | Articles 9, 10 and 11 | Articles 5 and 32 |
| DNSSEC ieviešana | 8.24 Kriptogrāfijas izmantošana | Article 21(2)(h) | Articles 9 and 10 | Article 32 |
| DNS žurnālfiksēšana un uzraudzība | 8.15 Žurnālfiksēšana, 8.16 Uzraudzības darbības | Article 21(2)(a), 21(2)(b) and 21(2)(f) | Articles 10 and 17 | Articles 5, 32 and 33 |
Izveidojiet DNS pierādījumu pakotni vienas nedēļas laikā
Praktisku DNS pārvaldības trūkumu novēršanas plānu var īstenot ātri, ja tas ir balstīts pierādījumos.
1. diena: izveidojiet domēnu un DNS pakalpojumu reģistru
Sāciet ar Aktīvu pārvaldības politika - SME prasību dokumentēt īpašumtiesības, mērķi, piekļuves privilēģijas un atjaunošanas termiņus.
| Lauks | Piemērs |
|---|---|
| Domēns | example.com |
| Biznesa mērķis | Klientu portāls, API, e-pasts |
| Kritiskums | Kritisks |
| Reģistrators | Reģistrators A |
| Reģistra bloķēšana | Iespējota |
| Reģistratora bloķēšana | Iespējota |
| DNS pakalpojumu sniedzējs | Pārvaldīts DNS pakalpojumu sniedzējs B |
| DNSSEC | Iespējots, DS publicēts |
| Īpašnieks | Platformas vadītājs |
| Drošības īpašnieks | Informācijas drošības vadītājs |
| Atjaunošanas datums | 2027-04-12 |
| Uzraudzība | SIEM brīdinājums un ārējais DNS monitors |
| Izmaiņu darbplūsma | Jira DNS izmaiņu tips |
| Piegādātāja pārskatīšanas datums | 2026-03-15 |
2. diena: pārskatiet piekļuvi un privilēģijas
Eksportējiet reģistratora un DNS pakalpojumu sniedzēja lietotājus. Noņemiet novecojušos kontus. Piemērojiet MFA. Identificējiet administratorus. Reģistrējiet apstiprinājumu pierādījumus privileģētiem lietotājiem un dokumentējiet ārkārtas piekļuvi.
3. diena: validējiet DNSSEC un bloķēšanu
Katram kritiskajam domēnam pārbaudiet DNSSEC ķēdes validāciju, DS ierakstu precizitāti, DNSKEY redzamību, reģistratora bloķēšanu un reģistra bloķēšanu. Ja DNSSEC pārvalda pakalpojumu sniedzējs, dokumentējiet pakalpojumu sniedzēja atbildību. Ja to pārvalda klients, pievienojiet DNSSEC atslēgas un glabātājus Atslēgu pārvaldības reģistram.
4. diena: pārvērtiet DNS izmaiņas formālos izmaiņu ierakstos
Atlasiet pēdējās trīs DNS izmaiņas un pārbaudiet tās pret Zenith Blueprint 21. soļa kritērijiem: risks izvērtēts, apstiprinājums dokumentēts, atcelšanas plāns iekļauts, ieviests kā plānots un neparedzētā ietekme reģistrēta. Izveidojiet Izmaiņu ierakstu kopsavilkuma žurnālu.
5. diena: sasaistiet uzraudzību ar reaģēšanu uz incidentiem
Apstipriniet žurnālus un brīdinājumus par reģistratora pieteikšanos, zonas izmaiņām, DNSSEC izmaiņām, NS izmaiņām, MX izmaiņām, TXT izmaiņām, CAA izmaiņām un pakalpojumu sniedzēja paziņojumiem. Nosūtiet testa brīdinājumus SOC vai IT īpašniekam. Pievienojiet pierādījumus IDPS repozitorijam.
6. diena: pārskatiet piegādātāju pienākumus
Izmantojiet Zenith Blueprint 23. soļa norādījumus piegādātāju izmaiņu un uzraudzības procedūrām:
Izveidojiet vienkāršu, mērogojamu procedūru piegādātāju pakalpojumu izmaiņu (5.21) izvērtēšanai, piemēram, migrācijai uz mākoņvidi, jauniem apakšapstrādātājiem vai infrastruktūras pārprojektēšanai. Definējiet trigerus, kas prasa drošības atkārtotu izvērtēšanu. Pēc tam ieviesiet atkārtotu piegādātāju uzraudzības ritmu (5.22), piešķirot īpašniekus kritiskiem piegādātājiem un nodrošinot, ka veiktspēja, atbilstība un riski tiek pārskatīti vismaz reizi gadā.
No fāzes “Kontroles praksē”, 23. solis: organizatoriskās kontroles 5.19 līdz 5.37.
Clarysec uzņēmuma Trešo pušu un piegādātāju drošības politika Trešo pušu un piegādātāju drošības politika nodrošina līgumisko pamatu:
Līgumos ar piegādātājiem jāiekļauj:
No sadaļas “Pārvaldības prasības”, politikas punkts 5.3.
| Līguma tēma | DNS specifiskā prasība |
|---|---|
| Drošības pienākumi | Kas pārvalda DNSSEC, bloķēšanu, žurnālus, piekļuvi, rezerves kopijas un izmaiņu apstiprinājumus |
| Incidenta paziņošana | Termiņi un kanāli reģistratora kompromitēšanai, DNS nepieejamībai vai nesankcionētai izmaiņai |
| Atbalsta eskalācija | 24/7 ārkārtas kanāls kritiskiem domēniem |
| Paziņošana par izmaiņām | Iepriekšējs paziņojums par platformas migrācijām, API izmaiņām un apakšapstrādātāju izmaiņām |
| Pierādījumi | Piekļuves žurnāli, izmaiņu vēsture, bloķēšanas statuss, DNSSEC statuss un darbspējas laika pārskati |
| Iziešana | Domēna pārcelšana, zonas eksports, DNSSEC migrācija un bloķēšanas noņemšanas procedūra |
7. diena: veiciet galda mācības
Simulējiet nesankcionētu NS ieraksta izmaiņu. Komandai tā jāatklāj, jāklasificē, jāeskalē, jāsazinās ar reģistratoru, vajadzības gadījumā jāiedarbina reģistra bloķēšanas procedūras, jāatjauno pareizā deleģēšana, jāvalidē DNSSEC, jāinformē iesaistītās puses, jāizvērtē GDPR ietekme un jālemj, vai ir sasniegti NIS2 vai DORA ziņošanas sliekšņi. Fiksējiet gūtās mācības un atjauniniet procedūras.
Audita jautājumi, biežākie konstatējumi un valdes rādītāji
DNS pārvaldības audits reti tiek veikts tikai no viena skatpunkta.
| Auditora skatpunkts | Iespējamais audita jautājums | Spēcīgi pierādījumi |
|---|---|---|
| ISO/IEC 27001:2022 auditors | Vai domēni ir piemērošanas jomā, tiem ir veikta risku izvērtēšana, tiem ir īpašnieki, tie tiek kontrolēti, uzraudzīti un iekļauti piegādātāju pārvaldībā? | IDPS darbības joma, Riska reģistrs, aktīvu reģistrs, piemērojamības deklarācija (SoA), izmaiņu pieteikumi, piegādātāju pārskatīšana un žurnāli |
| NIST CSF 2.0 izvērtētājs | Vai DNS riski tiek pārvaldīti, identificēti, aizsargāti, atklāti, uz tiem tiek reaģēts un no tiem tiek atjaunota darbība? | Pašreizējais un mērķa profils, trūkumu novēršanas plāns, aktīvu uzskaite, piekļuves kontroles pasākumi, uzraudzības brīdinājumi un atjaunošanas ieraksti |
| DORA pārskatītājs | Vai DNS atbalsta kritiskas vai svarīgas funkcijas, un vai atkarība tiek pārvaldīta, testēta un ir atjaunojama? | IKT aktīvu atkarību karte, noturības testu plāns, incidentu klasifikācijas process, trešo pušu reģistrs un atjaunošanas pierādījumi |
| GDPR pārskatītājs | Vai DNS incidents varētu ietekmēt personas datus, un vai organizācija var pierādīt atbilstošu drošību? | Article 32 pierādījumi, incidenta izvērtēšana, apstrādātāja pārraudzība, piekļuves kontrole, izmaiņu un uzraudzības ieraksti |
| COBIT 2019 vai ISACA auditors | Vai ar domēniem saistītie pārvaldības mērķi ir pārvērsti pārvaldītos procesos ar īpašumtiesībām, metrikām un apliecinājumu? | RACI, procesu mērķi, KPI, KRI, piegādātāju veiktspējas pārskatīšana, vadības ziņošana un trūkumu novēršanas izsekošana |
Biežākie konstatējumi ir paredzami.
| Konstatējums | Risks | Clarysec risinājums |
|---|---|---|
| Domēni nav iekļauti aktīvu reģistrā | Termiņa beigas, īpašumtiesību neskaidrība un nepilnīga risku izvērtēšana | Pievienojiet domēnus aktīvu reģistram ar īpašnieku, mērķi, kritiskumu, atjaunošanu un atkarībām |
| Koplietots reģistratora administratora konts | Nav pārskatatbildības un vāja incidentu kriminālistika | Pārejiet uz vārdiskiem lietotājiem, MFA, minimāli nepieciešamajām tiesībām un ceturkšņa pārskatīšanu |
| Kritiskam domēnam nav reģistra bloķēšanas | Augstas ietekmes nesankcionēta deleģēšana vai pārcelšana | Iespējojiet reģistra bloķēšanu un dokumentējiet ārkārtas atbloķēšanas procedūru |
| DNSSEC daļēji iespējots | Validācijas atteices vai maldīgs apliecinājums | Validējiet ķēdi, DS ierakstus, atslēgu īpašumtiesības un rotācijas plānu |
| DNS izmaiņas veiktas ārpus pieteikumiem | Nepieejamība, nepareiza maršrutēšana un audita neizpilde | Pieprasiet formālu DNS izmaiņu tipu ar apstiprinājumu un atcelšanas plānu |
| Nav brīdināšanas par NS vai MX izmaiņām | Lēna pārņemšanas vai e-pasta pārmaršrutēšanas atklāšana | Integrējiet DNS uzraudzību ar SIEM un eskalācijas instrukciju |
| Reģistrators nav pārskatīts kā piegādātājs | Līguma un reaģēšanas uz incidentiem trūkumi | Iekļaujiet reģistratoru un DNS pakalpojumu sniedzēju piegādātāju uzraudzības ritmā |
| Nav incidentu reaģēšanas instrukcijas | Aizkavēta atjaunošana un nenoteiktība ziņošanā | Izveidojiet DNS pārņemšanas un DNS nepieejamības reaģēšanas instrukcijas, pēc tam veiciet galda testu |
Valdēm un vadības komandām DNS metrikas jāsaņem noturības valodā. Noderīgi rādītāji ietver kritisko domēnu procentuālo daļu ar iespējotu un validētu DNSSEC, procentuālo daļu ar reģistra bloķēšanu, reģistratora administratoru skaitu, privileģēto lietotāju procentuālo daļu, kas pārskatīta pēdējā ceturksnī, DNS izmaiņu skaitu, kas ieviestas bez formāliem pieteikumiem, vidējo laiku līdz nesankcionētas DNS izmaiņas atklāšanai, vidējo laiku līdz pareizas DNS konfigurācijas atjaunošanai, domēnus, kuru termiņš beidzas 90 dienu laikā, pabeigtās piegādātāju pārskatīšanas un neatrisinātos DNS uzraudzības brīdinājumus.
Pārvērtiet DNS no slēpta riska auditam gatavos pierādījumos
Ja jūsu organizācija pēdējo sešu mēnešu laikā nav pārskatījusi domēnu un DNS pārvaldību, pieņemiet, ka pastāv novirze. Sāciet ar kritiskiem ražošanas domēniem, pēc tam paplašiniet uz reģionālajiem domēniem, aizsargdomēniem, testa domēniem, iegāžu domēniem un domēniem, kurus pārvalda aģentūras vai meitasuzņēmumi.
Clarysec var palīdzēt pāriet no izkaisītiem reģistratora ekrānuzņēmumiem uz strukturētu pierādījumu pakotni, izmantojot:
- Zenith Blueprint: auditora 30 soļu ceļvedis Zenith Blueprint soli pa solim veiktai tīkla pakalpojumu, izmaiņu pārvaldības, žurnālfiksēšanas, uzraudzības un piegādātāju kontroles pasākumu validācijai
- Zenith Controls: pārrobežu atbilstības ceļvedis Zenith Controls DNSSEC, reģistra bloķēšanas, piegādātāju uzraudzības un zonas izmaiņu pārvaldības kartēšanai ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST un COBIT 2019 skatījumos
- Clarysec politiku veidnes, tostarp Aktīvu pārvaldības politika - SME, Izmaiņu pārvaldības politika - SME, Lietotāju kontu un privilēģiju pārvaldības politika - SME, Tīkla drošības politika - SME, Aktīvu pārvaldības politika, Izmaiņu pārvaldības politika, Žurnālfiksēšanas un uzraudzības politika, Kriptogrāfisko kontroles pasākumu politika un Trešo pušu un piegādātāju drošības politika
Jūsu domēns ir jūsu digitālā biznesa priekšdurvis. 2026. gadā auditori, regulatori, klienti un valdes sagaidīs, ka spēsiet pierādīt: priekšdurvis ir aizslēgtas, uzraudzītas, atjaunojamas un pārvaldītas.
Lejupielādējiet Clarysec rīkkopu, veiciet vienas nedēļas DNS pierādījumu pakotnes vingrinājumu vai rezervējiet Clarysec izvērtējumu, lai DNS un reģistratora pārvaldību pārvērstu auditam gatavos pierādījumos pirms jūsu pašu pirmdienas rīta krīzes.
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
