DNS-hallinnointi vuonna 2026: auditointivalmiit rekisteröijäkontrollit

Maanantaiaamuna klo 07.42 fintech-kasvuyrityksen tietoturvajohtaja saa viestin, jota kukaan ei halua nähdä. Asiakkaat eivät pääse maksuliikenneportaaliin, tukipalvelu ruuhkautuu, sähköposti ei toimi, eikä SOC löydä haittaohjelmia, palomuurikatkoa tai pilvipalveluntarjoajan poikkeamaa.

Juurisyy on hiljaisempi ja kiusallisempi. Rekisteröijätilille kirjauduttiin vanhentuneilla ylläpitotunnuksilla, joita useat entiset IT-työntekijät olivat jakaneet. Hyökkääjä vaihtoi autoritatiiviset nimipalvelimet, muutti MX-tietueita, poisti DNSSEC:n käytöstä ja ohjasi liikennettä uudelleen riittävän kauan tunnistetietojen keräämiseksi ja kumppanien ohjelmointirajapintojen häiritsemiseksi. Maksuliikenneportaalia ei murrettu perinteisessä merkityksessä. Yrityksen luottamusankkuri, sen verkkotunnus, murrettiin.

Klo 09.30 operatiivinen kriisi on muuttunut vaatimustenmukaisuuskriisiksi. Hallitus kysyy, oliko registry lock käytössä. Lakiasiat kysyy, altistuivatko henkilötiedot. Tietosuojavastaava kysyy, onko kyseessä GDPR:n mukainen henkilötietojen tietoturvaloukkaus. Valvova viranomainen haluaa tietää, vaikuttiko poikkeama kriittiseen tai tärkeään toimintoon. Asiakkaan auditoija pyytää muutostikettiä, jolla DNS-muutos hyväksyttiin.

Liian monessa organisaatiossa vastaus on laskentataulukko, jaettu sähköpostilaatikko ja rekisteröijän hallintakonsoli, jota kukaan ei ole katselmoinut kuuteen kuukauteen.

DNS:n ja verkkotunnusrekisteröijien hallinnointi vuonna 2026 ei ole enää kapea infrastruktuuriaihe. Se on osa kiristyshaittaohjelmien sietokykyä, tietojenkalastelun torjuntaa, pilvipalvelujen saatavuutta, toimittajariskien hallintaa, tietoturvapoikkeamiin reagointia, liiketoiminnan jatkuvuutta ja näyttöön perustuvaa vaatimustenmukaisuutta. Jos verkkotunnuksesi voidaan kaapata, SaaS-alustasi voi kadota. Jos DNS-tietueitasi voidaan muuttaa ilman hyväksyntää, sähköpostin tietoturva, SSO, TLS-varmenteet, ohjelmointirajapintojen päätepisteet ja asiakkaiden luottamus voidaan horjuttaa minuuteissa.

Miksi DNS:n ja rekisteröijien hallinnointi kuuluu ISMS:ään

Verkkotunnus ei ole pelkkä brändiin liittyvä omaisuuserä. Se on looginen omaisuuserä, todennusriippuvuus, reititysriippuvuus ja usein toimittajan hallinnoima palvelu. Se yhdistää identiteetintarjoajat, sähköpostitodennuksen, TLS-varmenteiden validoinnin, pilvipalvelujen päätepisteet, asiakasportaalit, ohjelmointirajapinnat, CDN-palvelut, seurantaluotaimet ja poikkeamaviestinnän.

Clarysecin Omaisuuden hallintapolitiikka - SME Omaisuuden hallintapolitiikka - SME tekee tämän soveltamisalassaan selväksi:

Digitaaliset tunnistetiedot ja palvelut: verkkotunnukset, digitaaliset varmenteet, API-avaimet, sähköpostitilit, pilvikirjautumiset

Kohdasta “Soveltamisala”, politiikan lauseke 2.2.4.

Sama politiikka edellyttää muutakin kuin verkkotunnuksen listaamista:

Omistajuus, käyttötarkoitus, käyttöoikeudet ja uusimisaikataulut on dokumentoitava.

Kohdasta “Politiikan toteutusvaatimukset”, politiikan lauseke 6.6.2.

Yritysympäristöissä Clarysecin Omaisuuden hallintapolitiikka Omaisuuden hallintapolitiikka sisällyttää soveltamisalaan myös loogiset omaisuuserät:

Loogiset omaisuuserät: verkkotunnukset, lisenssit, käyttäjätilit, peruskonfiguraatiot

Kohdasta “Soveltamisala”, politiikan lauseke 2.2.5.

Tästä hallinnointi alkaa. DNS- ja rekisteröijäluettelon tulee dokumentoida:

• Verkkotunnus, rekisteri, rekisteröijä, DNS-palveluntarjoaja ja autoritatiiviset nimipalvelimet
• Liiketoimintavastaava, tekninen omistaja, tietoturvaomistaja ja hätätilanteen hyväksyjä
• Käyttötarkoitus, kuten tuotantoportaali, API, sähköposti, SSO, markkinointi, testiympäristö tai suojaava rekisteröinti
• Kriittisyysluokitus ja riippuvuuskartoitus liiketoimintapalveluihin
• DNSSEC:n tila, DS-tietueen tila, avainten omistajuus ja avainten kiertoprosessi
• Registry lock- ja registrar lock -suojauksen tila
• MFA ja etuoikeutetun pääsyn malli rekisteröijän ja DNS-palveluntarjoajan tileille
• Uusimispäivä, automaattisen uusimisen tila, maksamisesta vastaava omistaja ja vanhenemishälytykset
• Muutoksenhallintavaatimukset vyöhykemuokkauksille ja delegointimuutoksille
• Lokitus, hälyttäminen, seuranta ja näytön säilytys

Siksi verkkotunnusten hallinnoinnin tulee näkyä ISO/IEC 27001:2022 -standardin mukaisessa ISMS:n soveltamisalassa ja riskien arvioinnissa. ISO/IEC 27001:2022 edellyttää, että organisaatiot määrittävät toimintaympäristönsä, sidosryhmien vaatimukset, lakisääteiset ja sopimusvelvoitteet sekä rajapinnat ja riippuvuudet ulkoisiin organisaatioihin. DNS riippuu rekisteröijistä, rekistereistä, DNS-palveluntarjoajista, pilvipalveluntarjoajista, varmentajista, MSP-palveluntarjoajista ja joskus markkinointitoimistoista. Jos nämä rajapinnat rajataan ISMS:n ulkopuolelle, auditointijälki jää puutteelliseksi.

Vuoden 2026 DNS-uhkamalli

Vakavimmat DNS-häiriöt ovat usein yksinkertaisia:

1. Verkkotunnus vanhenee, koska uusimisen omistajuus oli epäselvä.
2. Entisellä toimistolla on edelleen pääsy rekisteröijätilille.
3. DNSSEC on käytössä, mutta DS-tietueet ovat virheellisiä DNS-palveluntarjoajan migraation jälkeen.
4. Wildcard-tietue ohjaa liikenteen hylättyyn pilvipalveluun.
5. TXT-tietuetta muutetaan hyökkääjän hallitseman SaaS-ympäristön tai varmennepyynnön validoimiseksi.
6. MX-tietueita muutetaan tietojenkalastelu- tai sähköpostin sieppauskampanjan aikana.
7. Kolmannen osapuolen alustaan osoittavasta CNAME-tietueesta tulee haltuunotolle altis.
8. Registry lock on käytössä ensisijaiselle verkkotunnukselle, mutta ei asiakasrajapinnan maakooditunnuksille.
9. SOC valvoo päätelaitteita, mutta kukaan ei seuraa vyöhyketiedoston muutoksia.

Tekniset suojatoimet tunnetaan hyvin. DNSSEC auttaa suojaamaan DNS-tietojen eheyttä ja alkuperän todennusta. Registry lock edellyttää lisävarmennusta erillisessä kanavassa korkean riskin rekisteritason muutoksille. Registrar lock vähentää luvattomien siirtojen riskiä. MFA ja etuoikeutettujen käyttöoikeuksien katselmoinnit pienentävät tilin haltuunoton todennäköisyyttä. Muutoksenhallinta ehkäisee tahattomia häiriöitä. Seuranta havaitsee luvattomat tai odottamattomat muutokset.

Vaatimustenmukaisuuden haaste on toinen: pystytkö osoittamaan, että nämä suojatoimet ovat olemassa, niille on nimetty omistajat, niitä katselmoidaan ja ne toimivat poikkeaman aikana?

Tässä näyttökysymyksessä moni organisaatio epäonnistuu.

DNS-hallinnoinnin kytkeminen ISO/IEC 27001:2022- ja ISO/IEC 27002:2022 -standardeihin

ISO/IEC 27001:2022 tarjoaa hallintajärjestelmän rakenteen, jolla DNS-kontrollit muutetaan toistettaviksi ja auditoitaviksi prosesseiksi. ISO/IEC 27001:2022 Annex A ja ISO/IEC 27002:2022 -standardin kontrolliohjeistus antavat kontrollikielen, jota auditoijat odottavat.

Clarysecin Zenith Blueprint: auditoijan 30 askeleen tiekartta Zenith Blueprint käsittelee verkkopalveluja nimenomaisina auditointikohteina. Controls in Action -vaiheen vaiheessa 20 se ohjeistaa tiimejä validoimaan verkkopalvelujen tietoturvan:

Listaa kaikki sisäiset ja ulkoiset verkkopalvelut (DNS, VPN, SMTP, DHCP, API-yhdyskäytävät, jne.).

✓ Varmista kunkin osalta, että ne käyttävät turvallisia protokollia (esim. DNSSEC, TLS 1.2+, SSH Telnetin sijaan). ✓ Katselmoi, miten kunkin palvelun pääsyä hallitaan (esim. IP-sallittujen luettelot, todennus, varmenteet). ✓ Jos kolmannet osapuolet hallinnoivat palveluja (esim. DNS, SD-WAN, ylläpidetty VPN), katselmoi SLA:n tai toimittajasopimuksen tietoturvalausekkeet. Päivitä palvelurekisteri ja merkitse, missä tietoturva- vastuut sijaitsevat, sisäisesti vai ulkoisesti.

Controls in Action -vaiheesta, vaihe 20: kontrollit 8.18–8.26.

Tämä antaa käytännöllisen auditointipolun: käsittele DNS:ää ulkoisena verkkopalveluna, dokumentoi, miten se on suojattu, ja kirjaa, onko vastuu organisaation sisällä, rekisteröijällä, DNS-palveluntarjoajalla vai MSP-palveluntarjoajalla.

Clarysecin Zenith Controls: viitekehysten välinen vaatimustenmukaisuusopas Zenith Controls on hyödyllinen, koska DNS-hallinnointi ei yleensä kohdistu vain yhteen viitekehykseen. Sama DNSSEC- tai registry lock -päätös tukee ISO/IEC 27001:2022-, NIS2-, DORA-, GDPR-, NIST CSF 2.0- ja COBIT 2019 -näyttöä.

Toimittajien seurannan osalta Zenith Controls kytkee ISO/IEC 27002:2022 -kontrollin 5.22, toimittajapalvelujen seuranta, katselmointi ja muutoksenhallinta, ennaltaehkäiseväksi kontrolliksi, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta. DNS:n osalta tämä tarkoittaa, että rekisteröijä ja DNS-palveluntarjoaja eivät ole “aseta ja unohda” -toimittajia. Niiden tietoturvan tila, palvelumuutokset, katkokset, alikäsittelijät ja ilmoituskäytännöt on katselmoitava.

DNSSEC:n ja kryptografisen eheyden osalta Zenith Controls kytkee ISO/IEC 27002:2022 -kontrollin 8.24, kryptografian käyttö, ennaltaehkäiseväksi kontrolliksi, joka on linjassa turvallisen konfiguroinnin kanssa. DNSSEC ei salaa DNS-liikennettä, mutta se tarjoaa kryptografisen varmuuden DNS-tietojen eheydestä ja alkuperän todennuksesta.

DNS-vyöhykemuokkausten osalta Zenith Controls kytkee ISO/IEC 27002:2022 -kontrollin 8.32, muutoksenhallinta, ennaltaehkäiseväksi kontrolliksi, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta. DNS-muutos on konfiguraatiomuutos. DS-tietueen päivityksellä, MX-tietueen muutoksella, CNAME-migraatiolla, SPF- tai DMARC-päivityksellä, CDN-siirtymällä tai nimipalvelindelegoinnin muutoksella tulee olla tiketti, riskien arviointi, hyväksyntä, testitulos ja palautussuunnitelma.

DNSSEC, registry lock ja avaintenhallinta kriittisille verkkotunnuksille

Kaikilla verkkotunnuksilla ei ole sama riskitaso. Pelkästään toisena esiintymisen ehkäisemiseen käytettävä suojaava verkkotunnus voi tarvita seurantaa ja uusimiskuria. Ensisijainen asiakasportaaliin liittyvä verkkotunnus edellyttää vahvimpia käytettävissä olevia kontrolleja.

Kriittisille verkkotunnuksille Clarysec suosittelee tyypillisesti seuraavaa perustasoa:

• DNSSEC on käytössä ja validoitu siellä, missä rekisteri, rekisteröijä ja DNS-palveluntarjoaja tukevat sitä
• DS-tietueet katselmoidaan jokaisen DNS-palveluntarjoajan migraation jälkeen
• Dokumentoitu KSK- ja ZSK-avainten kiertoprosessi, jos avaimet ovat asiakkaan hallinnoimia
• Registry lock on käytössä ensisijaisille tuotanto-, identiteetti-, API-, maksu- ja sähköpostiverkkotunnuksille
• Registrar lock on käytössä kaikille verkkotunnuksille, ellei tilapäistä poikkeusta ole dokumentoitu
• MFA on pakotettu kaikille rekisteröijän ja DNS-palveluntarjoajan käyttäjille
• Etuoikeutetut käyttäjät on rajattu, nimetty, hyväksytty ja katselmoitu
• Break-glass-pääsy on dokumentoitu ja testattu
• Vyöhyketiedoston seuranta hälyttää NS-, DS-, DNSKEY-, MX-, TXT-, A-, AAAA-, CNAME-, CAA- ja wildcard-muutoksista
• Ulkoinen seuranta useista resolvereista ja alueilta
• Näyttö säilytetään ISMS-tietovarastossa

Clarysecin yritystason Kryptografisten hallintakeinojen politiikka Kryptografisten hallintakeinojen politiikka tarjoaa hallinnointikytkennän DNSSEC-avaimille:

Keskitettyä avaintenhallintarekisteriä on ylläpidettävä kaikkien kryptografisten avainten, niiden elinkaaritilan, nimettyjen vastuuhenkilöiden ja käyttökontekstien kirjaamiseksi.

Kohdasta “Hallinnointivaatimukset”, politiikan lauseke 5.2.

Jos organisaatiosi hallinnoi DNSSEC-avaimia suoraan tai kontrolloi DS-tietueiden julkaisua rekisteröijällä, avaintenhallintarekisterin tulee dokumentoida avainten hallinta, elinkaaritila, kiertopäivät ja hyväksyntävaltuus. Jos DNS-palveluntarjoaja hallinnoi DNSSEC-avaimia, toimittajatietueen tulee selittää tämä vastuu ja sisältää varmentava näyttö.

Rekisteröijän käyttöoikeuksien hallinnointi: MFA, vähimmät oikeudet ja hätätilanteen hallinta

Rekisteröijätilit luodaan usein yrityksen alkuvaiheessa ja unohdetaan yrityksen kypsyessä. Perustajilla, toimistoilla, kehittäjillä, taloushallinnon käyttäjillä ja MSP-palveluntarjoajilla voi kaikilla olla historiallinen pääsy. Tämä on vakava kontrolliheikkous.

Clarysecin Käyttäjätilien ja käyttöoikeuksien hallintapolitiikka - SME Käyttäjätilien ja käyttöoikeuksien hallintapolitiikka - SME toteaa:

Korotetut tai hallinnolliset oikeudet edellyttävät toimitusjohtajan tai IT-vastaavan lisähyväksyntää, ja ne on dokumentoitava, rajattava ajallisesti ja saatettava säännöllisen katselmoinnin piiriin.

Kohdasta “Politiikan toteutusvaatimukset”, politiikan lauseke 6.2.2.

Sovella tätä suoraan rekisteröijän ja DNS-palveluntarjoajan käyttöoikeuksiin:

• Ei jaettuja rekisteröijän ylläpitäjätilejä
• MFA jokaiselle käyttäjälle, mieluiten tietojenkalastelua kestävä ratkaisu, jos sitä tuetaan
• Nimetyt hätäyhteyshenkilöt dokumentoidulla toimivallalla
• Laskutuskäyttäjien erottaminen teknisistä ylläpitäjistä mahdollisuuksien mukaan
• Entisten työntekijöiden, toimistojen ja toimittajien välitön poistaminen
• Kriittisten verkkotunnusten etuoikeutettujen käyttöoikeuksien neljännesvuosittainen katselmointi
• Poikkeukset kirjataan vanhenemispäivineen
• Testatut hätätilanteen lukituksenpoisto- ja palautusmenettelyt, jotka eivät aiheuta turvattomia tuotantomuutoksia

Registry lock -näytön tulee sisältää kuvakaappaukset tai rekisteröijän vaatimustenmukaisuusvakuutukset, joista ilmenevät käyttöönotettu tila, valtuutetut yhteyshenkilöt, lukituksen poistoprosessi ja viimeisin katselmointipäivä.

Vyöhykemuutosten hallinta: pienet DNS-muokkaukset, suuri liiketoimintavaikutus

DNS-muutokset näyttävät petollisen pieniltä. TXT-tietue voi validoida SaaS-alustan omistajuuden. CNAME voi ohjata asiakkaat uuteen ympäristöön. MX-tietue voi uudelleenreitittää sähköpostin. CAA-tietue voi vaikuttaa varmenteiden myöntämiseen. Väärä DS-tietue voi estää allekirjoitetun verkkotunnuksen validoinnin.

Clarysecin Muutoksenhallintapolitiikka - SME Muutoksenhallintapolitiikka - SME toteaa:

Kaikki muutokset on jätettävä muutospyyntönä (sähköposti, lomake tai tukipalvelun tiketti).

Kohdasta “Hallinnointivaatimukset”, politiikan lauseke 5.1.1.

Yritysasiakkaille Clarysecin Muutoksenhallintapolitiikka Muutoksenhallintapolitiikka nostaa näyttöodotusta:

Kaikki muutospyynnöt, katselmoinnit, hyväksynnät ja niitä tukeva näyttö on kirjattava keskitettyyn muutoksenhallintajärjestelmään.

Kohdasta “Politiikan toteutusvaatimukset”, politiikan lauseke 6.1.1.

Zenith Blueprint vahvistaa tämän Controls in Action -vaiheen vaiheessa 21:

Valitse 2–3 viimeaikaista järjestelmä- tai konfiguraatiomuutosta ja tarkista, käsiteltiinkö ne muodollisen muutoksenhallintatyönkulun kautta.

✓ Arvioitiinko riskit? ✓ Dokumentoitiinko hyväksynnät? ✓ Sisältyikö mukaan palautussuunnitelma?

Validoi, että muutokset toteutettiin suunnitellusti ja että mahdolliset poikkeamat tai odottamattomat vaikutukset kirjattiin. Katselmoi lokit, versionhallinnan erot tai auditointijäljet työkaluista, kuten ServiceNow, Jira tai Git. Tallenna tämä prosessi muutostallenteiden yhteenvetolokiin auditointia varten.

Controls in Action -vaiheesta, vaihe 21: kontrollit 8.27–8.34.

DNS-kohtaisen muutostiketin tulee sisältää vaikutettu verkkotunnus ja vyöhyke, tietuetyyppi, arvot ennen ja jälkeen muutoksen, liiketoimintaperuste, riskien arviointi, toteutusikkuna, hyväksyjä, toteuttaja, varmentaja, DNS-propagoinnin tarkastukset, DNSSEC-validointi, palautussuunnitelma, muutoksen jälkeinen seuranta ja viety näyttö.

Auditointiperiaate on yksinkertainen: DNS-muutosten on oltava jäljitettävissä pyynnöstä hyväksyntään, toteutukseen ja varmennukseen.

Seuranta ja lokitus: havaitse DNS-muutos ennen asiakkaita

Vahva DNS-hallinnointiohjelma olettaa, että ennaltaehkäisy voi epäonnistua. Seurannan on havaittava odottamaton muutos riittävän nopeasti tietoturvapoikkeamiin reagoinnin tueksi.

Clarysecin Verkkoturvallisuuspolitiikka - SME Verkkoturvallisuuspolitiikka - SME on täsmällinen:

DNS-lokitus on otettava käyttöön uhkien metsästyksen ja tietoturvapoikkeamiin reagoinnin tukemiseksi

Kohdasta “Politiikan toteutusvaatimukset”, politiikan lauseke 6.6.3.

Yritystason Lokitus- ja valvontapolitiikka Lokitus- ja valvontapolitiikka lähtee samasta operatiivisesta odotuksesta:

Kaikkien katettujen järjestelmien on tuotettava lokit, jotka tallentavat:

Kohdasta “Politiikan toteutusvaatimukset”, politiikan lauseke 6.1.1.

DNS:n ja rekisteröijien hallinnoinnissa katettuihin järjestelmiin tulee sisällyttää rekisteröijäportaalit, DNS-hallintakonsolit, API-pohjainen DNS-hallinta, koodina hallitun DNS:n käyttöönottoja suorittavat CI/CD-putket, SIEM-hälytykset ja ulkoiset seurantatyökalut.

Seuranta tulee integroida tietoturvapoikkeamiin reagointiin. DNS-hälytys, jolla ei ole omistajaa, vakavuusluokitusta tai palautusohjetta, on pelkkää hälyä.

NIS2, DORA ja GDPR: DNS-hallinnointi sääntelynäyttönä

NIS2 Article 21 edellyttää asianmukaisia ja oikeasuhtaisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä verkko- ja tietojärjestelmiin kohdistuvien riskien hallitsemiseksi ja poikkeamien vaikutusten minimoimiseksi. DNS-hallinnointi kytkeytyy luonnollisesti omaisuudenhallintaan, pääsynhallintaan, kryptografiaan, toimitusketjun turvallisuuteen, poikkeamien käsittelyyn, liiketoiminnan jatkuvuuteen ja vaikuttavuuden arviointiin.

NIS2 Article 20 tekee kyberturvallisuudesta myös johtamisesta vastaavan elimen vastuun. Hallituksen ei tarvitse hyväksyä jokaista TXT-tietuetta, mutta sen tulee ymmärtää, suojataanko kriittiset verkkotunnukset DNSSEC:llä, registry lockilla, MFA:lla, seurannalla ja testatulla palautumisella. Merkittävissä poikkeamissa NIS2 Article 23 tuo vaiheistetun raportoinnin, johon sisältyvät varhaisvaroitus 24 tunnin kuluessa, poikkeamailmoitus 72 tunnin kuluessa ja loppuraportti viimeistään kuukauden kuluttua poikkeamailmoituksesta.

Säännellyille finanssialan toimijoille DORA soveltuu 17. tammikuuta 2025 alkaen ja toimii toimialakohtaisena ICT-häiriönsietokyvyn viitekehyksenä niiltä osin kuin se limittyy NIS2:n kanssa. DNS tukee usein kriittisiä tai tärkeitä toimintoja, kuten maksusovelluksia, mobiilipankkia, kaupankäyntiportaaleja, asiakasidentiteettiä, petostentorjuntajärjestelmiä, API-yhdyskäytäviä ja kolmansien osapuolten integraatioita. DORA-näytön tulee osoittaa ICT-omaisuuserien riippuvuuskartoitus, poikkeamaluokittelu, häiriönsietokyvyn testaus, kolmannen osapuolen riskienhallinta sekä palautussuunnittelu DNS- ja rekisteröijävian skenaarioihin.

DNS-poikkeama ei automaattisesti ole GDPR:n mukainen henkilötietojen tietoturvaloukkaus. Siitä voi tulla sellainen, jos käyttäjät ohjataan tietojenkalastelusivustolle, tunnistetietoja kerätään, henkilötietoja sisältävä sähköposti reititetään uudelleen, liikenne henkilötietoja käsitteleviin järjestelmiin siepataan tai henkilötietojen saatavuuteen vaikutetaan olennaisesti. GDPR Article 5 edellyttää eheyttä, luottamuksellisuutta ja osoitusvelvollisuutta. Article 32 edellyttää käsittelylle asianmukaisia turvatoimia. DNS-hallinnointi tuottaa näyttöä siitä, että verkkotunnusreititys ja DNS-riippuvaiset palvelut on suojattu oikeasuhtaisilla teknisillä ja organisatorisilla toimenpiteillä.

Rakenna DNS-näyttöpaketti yhdessä viikossa

Käytännöllinen DNS-hallinnoinnin korjaussuunnitelma voidaan toteuttaa nopeasti, jos sitä ohjaa näyttö.

Päivä 1: Luo verkkotunnus- ja DNS-palvelurekisteri

Aloita Omaisuuden hallintapolitiikka - SME -vaatimuksesta dokumentoida omistajuus, käyttötarkoitus, käyttöoikeudet ja uusimisaikataulut.

Päivä 2: Katselmoi pääsy ja etuoikeudet

Vie rekisteröijän ja DNS-palveluntarjoajan käyttäjät. Poista vanhentuneet tilit. Pakota MFA käyttöön. Tunnista ylläpitäjät. Tallenna hyväksyntänäyttö etuoikeutetuille käyttäjille ja dokumentoi hätäkäyttö.

Päivä 3: Validoi DNSSEC ja lukitukset

Varmenna jokaiselle kriittiselle verkkotunnukselle DNSSEC-ketjun validointi, DS-tietueen oikeellisuus, DNSKEY-näkyvyys, registrar lock ja registry lock. Jos DNSSEC on palveluntarjoajan hallinnoima, dokumentoi palveluntarjoajan vastuu. Jos se on asiakkaan hallinnoima, lisää DNSSEC-avaimet ja niiden vastuuhenkilöt avaintenhallintarekisteriin.

Päivä 4: Muunna DNS-muutokset muodollisiksi muutostallenteiksi

Valitse kolme viimeisintä DNS-muutosta ja testaa ne Zenith Blueprint -vaiheen 21 kriteereillä: riski arvioitu, hyväksyntä dokumentoitu, palautussuunnitelma mukana, toteutettu suunnitellusti ja odottamaton vaikutus kirjattu. Luo muutostallenteiden yhteenvetoloki.

Päivä 5: Kytke seuranta tietoturvapoikkeamiin reagointiin

Varmista lokit ja hälytykset rekisteröijäkirjautumisille, vyöhykemuutoksille, DNSSEC-muutoksille, NS-muutoksille, MX-muutoksille, TXT-muutoksille, CAA-muutoksille ja palveluntarjoajan ilmoituksille. Lähetä testihälytykset SOC:lle tai IT-omistajalle. Liitä näyttö ISMS-tietovarastoon.

Päivä 6: Katselmoi toimittajavelvoitteet

Käytä Zenith Blueprint -vaiheen 23 ohjeistusta toimittajamuutosten ja seurantamenettelyjen osalta:

Laadi yksinkertainen ja skaalautuva menettely toimittajapalvelujen muutosten (5.21) arviointiin, kuten pilveen siirtymiseen, uusiin alikäsittelijöihin tai infrastruktuurin uudelleensuunnitteluun. Määritä herätteet, jotka edellyttävät tietoturvan uudelleenarviointia. Toteuta sen jälkeen toistuva toimittajien seurantarytmi (5.22), nimeä omistajat kriittisille toimittajille ja varmista, että suorituskyky, vaatimustenmukaisuus ja riskit katselmoidaan vähintään vuosittain.

Controls in Action -vaiheesta, vaihe 23: organisatoriset kontrollit 5.19–5.37.

Clarysecin yritystason Kolmansien osapuolten ja toimittajien turvallisuuspolitiikka Kolmansien osapuolten ja toimittajien turvallisuuspolitiikka tarjoaa sopimuksellisen ankkurin:

Toimittajien kanssa tehtävien sopimusten on sisällettävä:

Kohdasta “Hallinnointivaatimukset”, politiikan lauseke 5.3.

Päivä 7: Toteuta pöytäharjoitus

Simuloi luvaton NS-tietueen muutos. Tiimin on havaittava se, luokiteltava se, eskaloitava se, otettava yhteys rekisteröijään, käynnistettävä tarvittaessa registry lock -menettelyt, palautettava oikea delegointi, validoitava DNSSEC, tiedotettava sidosryhmiä, arvioitava GDPR-vaikutus ja päätettävä, täyttyvätkö NIS2- tai DORA-raportointikynnykset. Kirjaa opit ja päivitä menettelyt.

Auditointikysymykset, yleiset havainnot ja hallituksen mittarit

DNS-hallinnoinnin auditointia tehdään harvoin vain yhdestä näkökulmasta.

Yleisimmät havainnot ovat ennakoitavissa.

Hallitukset ja johtoryhmät tarvitsevat DNS-mittareita häiriönsietokyvyn kielellä. Hyödyllisiä mittareita ovat kriittisten verkkotunnusten osuus, joissa DNSSEC on käytössä ja validoitu; registry lockin kattavuus; rekisteröijän ylläpitäjien määrä; etuoikeutettujen käyttäjien osuus, joka on katselmoitu viimeisen neljänneksen aikana; ilman muodollisia tikettejä toteutettujen DNS-muutosten määrä; keskimääräinen aika luvattoman DNS-muutoksen havaitsemiseen; keskimääräinen aika oikean DNS-konfiguraation palauttamiseen; 90 päivän sisällä vanhenevat verkkotunnukset; valmistuneet toimittajakatselmoinnit; sekä ratkaisemattomat DNS-seurantahälytykset.

Muuta DNS piilevästä riskistä auditointivalmiiksi näytöksi

Jos organisaatiosi ei ole katselmoinut verkkotunnusten ja DNS:n hallinnointia viimeisen kuuden kuukauden aikana, oleta, että poikkeamaa on syntynyt. Aloita kriittisistä tuotantoverkkotunnuksista ja laajenna sitten alueellisiin verkkotunnuksiin, suojaaviin verkkotunnuksiin, testiverkkotunnuksiin, yritysostoihin liittyviin verkkotunnuksiin sekä toimistojen tai tytäryhtiöiden hallinnoimiin verkkotunnuksiin.

Clarysec voi auttaa siirtymään hajanaisista rekisteröijän kuvakaappauksista rakenteiseen näyttöpakettiin käyttämällä:

• Zenith Blueprint: auditoijan 30 askeleen tiekartta Zenith Blueprint verkkopalvelujen, muutoksenhallinnan, lokituksen, seurannan ja toimittajakontrollien vaiheittaiseen validointiin
• Zenith Controls: viitekehysten välinen vaatimustenmukaisuusopas Zenith Controls DNSSEC:n, registry lockin, toimittajien seurannan ja vyöhykemuutosten hallinnoinnin kytkemiseen ISO/IEC 27001:2022-, NIS2-, DORA-, GDPR-, NIST- ja COBIT 2019 -näkökulmiin
• Clarysecin politiikkamallit, mukaan lukien Omaisuuden hallintapolitiikka - SME, Muutoksenhallintapolitiikka - SME, Käyttäjätilien ja käyttöoikeuksien hallintapolitiikka - SME, Verkkoturvallisuuspolitiikka - SME, Omaisuuden hallintapolitiikka, Muutoksenhallintapolitiikka, Lokitus- ja valvontapolitiikka, Kryptografisten hallintakeinojen politiikka ja Kolmansien osapuolten ja toimittajien turvallisuuspolitiikka

Verkkotunnuksesi on digitaalisen liiketoimintasi etuovi. Vuonna 2026 auditoijat, viranomaiset, asiakkaat ja hallitukset odottavat sinun osoittavan, että etuovi on lukittu, valvottu, palautettavissa ja hallinnoitu.

Lataa Clarysec-työkalupaketti, toteuta viikon mittainen DNS-näyttöpakettiharjoitus tai varaa Clarysec-arviointi, jotta voit muuttaa DNS:n ja rekisteröijien hallinnoinnin auditointivalmiiksi näytöksi ennen omaa maanantaiaamun kriisiä.