Sikkerhetssjekkliste for domene, DNS, e-post og nettsted

Et sikkert nettsted hjelper lite hvis en gammel konsulent kan endre DNS, hvis domenet står på feil virksomhet, eller hvis gjenopprettingsadressen forsvinner sammen med e-posten. En god sikkerhetskontroll følger hele kjeden fra domeneabonnement til nettsted og beredskap.

Denne sjekklisten passer som kvartalskontroll for små og mellomstore virksomheter. Den kan også brukes før leverandørbytte, etter personalendringer og når en ny nettside eller e-posttjeneste settes i drift.

Slik bruker dere sjekklisten

Ikke sett bare et kryss. Registrer fem ting for hvert punkt:

Ukjent er et funn. Hvis ingen kan vise hvem som står som abonnent, hvor DNS-sonen ligger eller om backup kan gjenopprettes, skal punktet ikke markeres som godkjent.

Unngå en samlet «sikkerhetsscore». Ett kritisk avvik, som feil abonnent eller en usikret administratorkonto, kan være viktigere enn ti godkjente lavrisikopunkter.

1. Kartlegg tjenester og avhengigheter

NSMs grunnprinsipper begynner med å identifisere og kartlegge. Det er nødvendig fordi domenet ofte er en avhengighet for flere tjenester som ikke ser ut til å høre sammen.

• Alle domener er registrert. Ta med hoveddomene, kampanjedomener, gamle videresendinger og domener som bare brukes til e-post.
• Kritikalitet er vurdert. Marker hvilke domener som påvirker e-post, innlogging, betaling, kundeservice og andre viktige leveranser.
• Leverandørkjeden er kjent. Registrer registrar, DNS, hosting, e-post, sertifikater, analyse og andre tjenester per domene.
• Tekniske avhengigheter er dokumentert. Noter viktige underdomener, MX-poster, videresendinger og tjenester som bruker DNS til bekreftelse.
• Krav er identifisert. Avklar avtaler, personvern, oppbevaring, bransjekrav og intern aksept for nedetid og datatap.

For hvert kritisk domene bør dere kunne svare på hva som stopper hvis domenet er utilgjengelig i én time, ett døgn og én uke. Norids veileder om domenenavn og risiko er et godt grunnlag for denne vurderingen.

2. Kontroller abonnent, registrar og fornyelse

• Riktig virksomhet står som abonnent. Kontroller juridisk navn og organisasjonsnummer i Norids oppslag.
• Registraren er kjent. Fakturamottaker, DNS-leverandør og registrar er ikke nødvendigvis samme selskap.
• Kontaktopplysningene virker. Test adressen som mottar viktige varsler, og sørg for at den ikke bare kontrolleres av en tidligere ansatt eller et byrå.
• Fullmaktene er tydelige. Minst to riktige personer vet hvem som kan bestille endringer på vegne av virksomheten.
• Fornyelsen har eier og frist. Registrer hvem som følger opp, hvordan betaling skjer og hvordan gjennomført fornyelse bekreftes.
• Flytteprosessen er forstått. Behandle flyttekode og engangskode som hemmeligheter, og lagre dem ikke i åpne saker eller chatter.

Et betalt webhotell eller en faktura for domene er ikke i seg selv bevis på at riktig virksomhet står som abonnent. Les hvordan dere kontrollerer abonnent og praktisk domenekontroll .

Vymo bruker manuell domenefornyelse og trekker ikke kort automatisk. Vymo-kunder må derfor kontrollere at fornyelsen er bekreftet, ikke bare at fristen ligger i kalenderen.

3. Revider administratortilganger

Lag en egen liste over personer og maskinkontoer med tilgang til registrar, DNS, hosting, publisering og e-postadministrasjon.

• Alle brukere er gjenkjennelige. Fjern ukjente kontoer, generiske delte brukere og tilganger som ikke lenger trengs.
• Hver person har egen konto. Da kan tilgang fjernes uten å bytte et delt passord for alle, og hendelser kan knyttes til riktig bruker der logg finnes.
• Rettigheter er begrenset. En innholdsredaktør trenger normalt ikke kunne endre DNS eller e-postdomene.
• Sterk innlogging er aktivert. Bruk unikt passord og passnøkkel, sikkerhetsnøkkel eller flerfaktor når leverandøren tilbyr det.
• Reserveveien er testet. Minst én annen autorisert person kan starte gjenoppretting uten hovedadministratoren.
• Avslutning er dokumentert. Tilgang fjernes ved fratredelse og leverandørbytte, inkludert API-nøkler, personlige passnøkler og gjenopprettingsmetoder.

Ikke anta at alle leverandører har rollebasert tilgang, flerfaktor, øktoversikt eller revisjonslogg. Registrer hvilke kontroller produktet faktisk tilbyr, og vurder en annen leverandør eller en kompenserende rutine når et kritisk behov mangler.

4. Kontroller DNS og DNSSEC

DNS-endringer kan flytte både nettsted og e-post uten å endre innholdet hos hostingleverandøren.

• Autoritative navnetjenere er riktige. Sammenlign Norid-oppslaget med dokumentert leverandør.
• DNS-sonen har en kjent normaltilstand. Eksporter eller dokumenter alle poster etter godkjente endringer.
• Gamle poster er vurdert. Fjern forlatte CNAME-, A- og bekreftelsesposter når tjenesten er avsluttet.
• Kritiske endringer godkjennes. Navnetjenere, MX, DS og administrativ kontakt bør ha en tydelig bestiller og kontrollør.
• DNSSEC er validert der det brukes. Kontroller både signering og riktig DS-kobling, ikke bare et grønt symbol i ett panel.
• Flytteplanen bevarer DNS. Ny sone må være komplett før navnetjenere endres, og DNSSEC må håndteres i riktig rekkefølge.

DNSSEC gjør forfalskede DNS-svar mulig å oppdage for validerende oppslag. Det stopper ikke en angriper som allerede kan gjøre legitime endringer i den autoritative sonen. Les hva DNSSEC beskytter og ikke beskytter .

Kontroller NS, DS, A, AAAA, CNAME, MX og sentrale TXT-poster fra minst én kilde utenfor eget nettverk. Hvis resultatene avviker, vurder TTL og vanlig DNS-propagering før dere konkluderer med et angrep.

5. Kontroller e-postdomenet

E-postsikkerhet handler både om at legitime meldinger kommer frem, at forfalskning blir vanskeligere, og at en kompromittert postkasse ikke gir adgang til resten av virksomheten.

• MX-postene peker til riktig leverandør. Ukjente eller gamle MX-poster skal undersøkes.
• SPF har én gyldig policy. Kontroller at bare nødvendige avsendere er inkludert, og tell hele den rekursive kjeden mot grensen på ti DNS-oppslag .
• DKIM signerer reelle meldinger. Test minst én melding fra hver godkjent avsendertjeneste og dokumenter selector og nøkkelansvar.
• DMARC er syntaktisk gyldig. Rapportadresse, policy og justering mot From-domenet må være forstått før policy strammes inn.
• Administrator- og gjenopprettingskontoer er sikret. De skal ikke være delte postkasser uten navngitt ansvar.
• Videresending og regler er gjennomgått. Fjern ukjente regler som kan sende kopier ut av virksomheten.
• Testen dekker begge retninger. Send til og fra eksterne mottakere, og kontroller autentiseringsresultater i meldingshodet.

SPF, DKIM og DMARC beskytter ikke en angriper som sender fra en faktisk kompromittert postkasse. Kontosikkerhet, betalingskontroll og rutiner mot direktørsvindel er fortsatt nødvendig. Bruk veiledningen for SPF, DKIM og DMARC som teknisk kontrollgrunnlag.

6. Kontroller nettsted og webhotell

Kontrollen må tilpasses hvordan nettstedet er bygget. En statisk informasjonsside har andre angrepsflater enn en nettbutikk med innlogging og betaling.

• Publisert programvare er støttet. Operativsystem, CMS, utvidelser, tema og kjøretidsmiljø har sikkerhetsoppdateringer der kunden har ansvar for dem.
• Unødvendige funksjoner er fjernet. Steng gamle testmiljøer, administrasjonssider, filopplastinger og integrasjoner som ikke brukes.
• Hemmeligheter ligger ikke i kildekode eller offentlig webområde. Roter nøkler som har vært eksponert.
• HTTPS virker på alle offentlige vertsnavn. Kontroller sertifikatkjede, navn og utløp, samt viderekobling fra HTTP der det er riktig.
• Skjemaer leverer til riktig mottaker. Test faktisk innsending uten å lagre sensitiv informasjon i testfelt, og kontroller feilhåndtering og spamvern.
• Sikkerhetsheadere er valgt med hensikt. Test Content-Security-Policy og andre headere mot løsningens funksjoner før de håndheves.
• Logger og varsler har eier. Avklar hva leverandøren logger, hvor lenge, hvem som ser avvik, og hva som ikke er tilgjengelig i produktet.

Ikke kryss av for «WAF», «DDoS-beskyttelse» eller «backup» bare fordi leverandørens markedsføring bruker ordene. Dokumenter hvilken tjeneste som er aktiv, hva den dekker, og hvem som reagerer på varsler.

Vymos enkle nettside er en administrert én-sides bedriftsnettside. Kunden får ikke et publisert selvbetjeningspanel for CDN-, WAF-, server- eller backupinnstillinger. Sjekklisten må derfor skille mellom det Vymo håndterer og de tilgangene kunden selv har hos domene-, e-post- og tredjepartsleverandører.

7. Test backup og gjenoppretting

En melding om «backup fullført» viser at en jobb kjørte. Den viser ikke at riktige data kan hentes tilbake innen virksomhetens frist.

• Omfanget er kjent. Dokumenter om kopien omfatter filer, database, konfigurasjon, DNS, e-post og nøkler – eller bare deler av dette.
• Kopien er tilstrekkelig adskilt. En angriper med produksjonstilgang bør ikke automatisk kunne slette alle kopier.
• Oppbevaring møter behovet. Kontroller hvor mange versjoner som finnes og hvor langt tilbake dere kan gå.
• Gjenoppretting er testet. Gjør en kontrollert test til et separat område og dokumenter resultat og tidsbruk.
• Ansvar og kostnad er kjent. Avklar hvem som starter restore, forventet responstid og om hjelpen koster ekstra.
• DNS- og kontaktdata kan gjenopprettes. En serverkopi hjelper ikke hvis ingen kan peke domenet tilbake eller nå leverandøren.

Bestem tillatt datatap og nedetid før dere velger løsning. «Daglig backup» kan fortsatt gi nesten ett døgns datatap, og en langsom manuell restore kan bryte virksomhetens tidskrav. Den praktiske restore-testen for backup viser hvordan dere måler begge deler uten å overskrive produksjon.

8. Kontroller overvåking og beredskap

• Det finnes en uavhengig varslingskanal. Varsler og leverandørkontakter må være tilgjengelige når hoveddomenet og e-posten er nede.
• Normaltilstanden er dokumentert. Overvåk navnetjenere, DNSSEC, viktige DNS-poster, sertifikater, HTTP-status og fornyelse mot kjente verdier.
• Varsler havner hos en ansvarlig person. En overfylt fellespostkasse er ikke hendelseshåndtering.
• Scenarier har førstehandling. Skill mellom kontoovertakelse, feil DNS-endring, leverandørutfall, e-poststans og utløpt abonnement.
• Kontaktlisten er verifisert. Bruk kjente opplysninger for registrar, DNS, hosting, e-post og andre kritiske leverandører.
• Planen er øvd. Mål hvor lang tid det tar å finne fullmakt, DNS-kopi, reserveadmin og en fungerende ekstern kanal.

Planen skal si hvem som leder, hvem som kan godkjenne endringer, hva som skal sikres som bevis, og hvordan kunder informeres uten det rammede domenet. Bruk beredskapsplanen for domene, DNS og e-post som neste steg.

Prioriter avvikene

Sorter funn etter mulig konsekvens og hvor lett de kan utnyttes eller utløses:

Et avvik kan aksepteres hvis ledelsen forstår konsekvensen og dokumenterer hvorfor risikoen er akseptabel eller hvilke kompenserende tiltak som brukes. «Leverandøren ordner det» er ikke en risikovurdering uten avtalt ansvar og bekreftet omfang.

Kvartalskontrollen er ferdig når

Kontrollen er ikke ferdig når møtet slutter. Den er ferdig når:

1. alle kritiske tjenester, leverandører og avhengigheter er registrert
2. hvert kontrollpunkt har status og bevis
3. alle avvik har ansvarlig, prioritet og dato
4. kritiske funn er eskalert og midlertidig risiko er håndtert
5. ledelsen vet hvilke vesentlige risikoer som gjenstår
6. dato og omfang for neste kontroll er satt

Oppbevar resultatet et sted som fortsatt er tilgjengelig under et domene- eller e-postutfall. Da blir sjekklisten både en revisjon av dagens sikkerhet og inngangen til en raskere gjenoppretting.