Skip to main content

Forfatter: Svein tore

En ansatt ser fem sikkerhetsvarsler på en bærbar PC på kontoret.

5 tegn på at bedriftens IT-sikkerhet er for dårlig

Skrevet av Svein tore den . Publisert i Nyheter.

IT-sikkerheten kan være svakere enn dere tror, selv om alt fungerer i hverdagen. Mistenkelige innlogginger, uklare rutiner, utdatert sikkerhetsprogramvare, mangelfull sikkerhetskopiering og for mange administratorrettigheter er varsellamper dere bør ta på alvor. Her er fem tegn på at bedriften bør ta grep.

Tegn 1 – Hyppige datainntrengninger

Den første indikasjonen på at IT-sikkerheten for småbedrifter kanskje ikke er tilstrekkelig, er hyppige datainntrengninger. Dette kan inkludere tvilsomme innlogginger, uventet nettverkstrafikk eller uautoriserte endringer i systemene dine.

Tegn 2 – Mangler en klar IT-sikkerhetspolicy

En godt definert IT-sikkerhetspolicy er sentral i beskyttelsen av bedriftens data. Denne policyen bør dekke alt fra bruk av sikkerhetsprogramvare, til opplæring av ansatte og prosedyrer ved mistanke om datainnbrudd.

Tegn 3 – Uoppdatert sikkerhetsprogramvare

Oppdatering av antivirusprogramvare og andre sikkerhetsverktøy er avgjørende for å beskytte bedriften mot nye trusler. Hvis dette overses, kan det være en indikasjon på at bedriftens IT-sikkerhet er for svak.

Tegn 4 – Ingen rutiner for sikkerhetskopiering

Sikkerhetskopiering av data er et av de viktigste tiltakene en bedrift kan ta for å sikre seg mot tap av kritisk data. Uten rutiner for sikkerhetskopiering kan data være i fare.

Tegn 5 – Brukere har for høye privilegier

Hvis de fleste brukere har administratorrettigheter, kan dette være et tegn på dårlig IT-sikkerhet. Brukere bør bare ha tilgang til de dataene og systemene de trenger for å utføre jobben sin.

For å bedre bedriftens IT-sikkerhet kan løsningen være endepunktsikring. Dette er en omfattende løsning som beskytter bedriften mot en rekke trusler og gir bedre IT-sikkerhet for småbedrifter. Vil dere utforske dette videre, kan dere lese mer om endepunktsikring.

Laptop med kontaktskjema, sjekkliste og mobil som viser kontroll av e-postlevering.

Kontaktskjemaet virker ikke? Slik unngår dere å miste henvendelser

Skrevet av Svein tore den . Publisert i Nettside, Wordpress.

Et kontaktskjema kan se helt riktig ut på nettsiden, men likevel ikke gi dere henvendelsene dere tror dere får.

For små bedrifter er dette en ubehagelig feiltype. Kunden får kanskje en bekreftelse på skjermen, mens meldingen aldri havner hos riktig person. Ingen alarmer går. Ingen vet at noe er galt før en kunde ringer og spør hvorfor ingen svarte.

Her er en praktisk sjekkliste for bedrifter som bruker WordPress, webhotell, Microsoft 365, Plesk-mail eller andre e-postløsninger sammen med kontaktskjema på nettsiden.

Tegn på at kontaktskjemaet ikke er til å stole på

Et kontaktskjema trenger ikke være helt ødelagt for å skape problemer. Ofte er feilen delvis, periodisk eller avhengig av hvem som sender inn skjemaet.

Typiske tegn er:

  • skjemaet sier at meldingen er sendt, men ingen mottar den
  • meldinger havner i spam eller karantene
  • skjemaet virker bare til enkelte mottakere
  • svaradressen blir feil eller tom
  • kunden får ingen kvittering
  • dere får mye spam og strammer inn for hardt
  • skjemaet slutter å virke etter flytting av nettside eller e-post
  • henvendelser lagres i WordPress uten at noen følger dem opp

Hvis nettsiden brukes til tilbud, booking, support, befaring eller rekruttering, bør ikke kontaktskjemaet være noe dere bare antar at fungerer.

Start med en ekte test

Den enkleste kontrollen er fortsatt den viktigste: send en testmelding slik en kunde ville gjort det.

Testen bør dekke mer enn bare at det kommer en grønn bekreftelse på nettsiden:

  • send inn skjemaet fra vanlig mobilnett, ikke bare fra kontoret
  • bruk en ekstern e-postkonto som avsender
  • sjekk at riktig mottaker får meldingen
  • sjekk spam, karantene og eventuelle regler i innboksen
  • svar på meldingen og kontroller at svaret går til kunden
  • se om innholdet er lesbart på mobil
  • noter tidspunktet testen ble sendt og mottatt

Hvis dere har flere skjema, må hvert skjema testes. Et kontaktskjema, et rekrutteringsskjema og et supports skjema kan ha ulike mottakere, ulike innstillinger og ulike spamregler.

Skill mellom skjema, WordPress og e-postlevering

Når et kontaktskjema feiler, er det fristende å si at «nettsiden sender ikke e-post». Det kan stemme, men det kan også være mer presist å dele problemet i tre deler:

  • Skjemaet: tar imot feltene, validerer dem og prøver å sende en melding.
  • WordPress: behandler meldingen gjennom nettsidens e-postfunksjon eller en SMTP-plugin.
  • E-postsystemet: avgjør om meldingen faktisk leveres, avvises, havner i spam eller stoppes av sikkerhetsregler.

Dette skillet er viktig. WordPress sin egen dokumentasjon for wp_mail() beskriver at en teknisk «sendt»-respons ikke i seg selv garanterer at mottakeren faktisk fikk e-posten. Derfor bør man teste hele veien fra skjema til innboks.

Bruk en avsender som hører til domenet

Et vanlig feiloppsett er at skjemaet prøver å sende e-post med kundens adresse som teknisk avsender. Det kan se praktisk ut, men det kan gjøre meldingen mindre troverdig for spamfilteret.

En bedre praksis er ofte:

  • bruk en fast avsenderadresse som hører til bedriftens eget domene
  • sett kundens adresse som svaradresse, ikke nødvendigvis som teknisk avsender
  • bruk et navn som gjør at mottaker forstår hvilket skjema meldingen kommer fra
  • unngå at skjemaet sender fra et domene nettsiden ikke har lov til å sende på vegne av

Dette er ikke bare ryddighet. Moderne e-postmottakere vurderer avsender, domene, IP, SPF, DKIM og DMARC før de slipper meldinger gjennom. Kunnskapsrom har en nøytral forklaring av SPF, DKIM og DMARC hvis dere vil forstå begrepene bedre.

SMTP er ofte bedre enn standard webserver-mail

Mange WordPress-sider forsøker å sende e-post direkte fra webserveren. Det kan fungere, men det er ofte mer sårbart enn å sende gjennom en riktig konfigurert SMTP-konto eller e-posttjeneste.

Med et godt SMTP-oppsett får dere vanligvis:

  • autentisert sending
  • tydeligere avsender
  • bedre logging av feil
  • mindre risiko for at webserveren blir vurdert som ukjent avsender
  • enklere feilsøking når leveringen stopper

Google sine veiledninger for avsenderautentisering peker også på at SPF eller DKIM bør være satt opp for avsendere som sender til Gmail-mottakere, og at DMARC bør bygges på riktig grunnlag når SPF og DKIM fungerer. Poenget for små bedrifter er enkelt: e-post fra nettsiden bør behandles som e-postdrift, ikke som en tilfeldig WordPress-innstilling.

Sjekk mottaker og ansvar

Et teknisk riktig skjema kan fortsatt feile organisatorisk.

Still disse spørsmålene:

  • hvem mottar skjemaet i dag?
  • er mottakeren en person, en felles innboks eller et system?
  • hva skjer når mottaker har ferie eller slutter?
  • er det noen som følger med på spammappe eller karantene?
  • skal flere personer få kopi?
  • skal henvendelser også lagres i WordPress eller CRM?
  • hvem har ansvar for å teste skjemaet jevnlig?

Dette er spesielt viktig for små virksomheter der nettsiden kanskje ble laget for flere år siden, mens ansatte, e-postløsning og arbeidsrutiner har endret seg etterpå.

Ikke samle mer informasjon enn dere trenger

Kontaktskjema behandler ofte personopplysninger. Navn, telefonnummer, e-post, fritekstfelt og vedlegg kan være nok til at bedriften må tenke gjennom formål, tilgang og lagring.

En praktisk regel er å spørre: trenger vi egentlig dette feltet for å svare på henvendelsen?

For de fleste enkle kontaktskjema holder det med få felt. Fritekstfelt bør ikke invitere til at kunder legger inn sensitive opplysninger. Hvis skjemaet gjelder support, rekruttering, helse, økonomi eller andre mer følsomme forhold, bør løsningen vurderes strengere.

Sjekk også om skjema-pluginen lagrer innsendelser i WordPress. Det kan være nyttig som reserve hvis e-postlevering feiler, men det betyr også at dataene ligger i nettsidens database. Da bør dere vite hvem som har tilgang, hvor lenge data lagres og hvordan de slettes.

Spamvern må ikke stoppe ekte kunder

Spam fra kontaktskjema kan bli et stort irritasjonsmoment. Samtidig kan et for aggressivt spamvern gjøre det vanskelig for ekte kunder å sende inn henvendelser.

Gode tiltak kan være:

  • honeypot-felt som vanlige brukere ikke ser
  • moderat bruk av CAPTCHA eller tilsvarende kontroll
  • spamfilter som kan læres opp over tid
  • begrensning av gjentatte innsendinger
  • logging som gjør det mulig å se hva som stoppes

Ikke vurder spamvern bare etter hvor mye det stopper. Vurder også om det stopper riktige meldinger, om mobilbrukere kommer gjennom, og om tilgjengeligheten fortsatt er god.

Test etter endringer

Kontaktskjema bør testes hver gang noe rundt nettsiden eller e-posten endres.

Det gjelder særlig etter:

  • flytting til nytt webhotell
  • endring av DNS
  • bytte til Microsoft 365 eller annen e-postløsning
  • oppdatering av skjema-plugin
  • bytte av tema eller sidebygger
  • aktivering av ny cache- eller sikkerhetsplugin
  • endring av spamfilter, PMG eller e-postgateway
  • lansering av ny nettside

Dette er en av grunnene til at kontaktskjema bør være med i vanlig WordPress-vedlikehold, ikke bare testes ved lansering.

Ha en enkel reserveplan

Selv med godt oppsett kan feil oppstå. Derfor bør bedriften ha en enkel reserveplan.

Det kan være:

  • at skjemaet lagrer kopi i WordPress i en begrenset periode
  • at kritiske skjema sender kopi til en felles innboks
  • at det finnes en alternativ kontaktmetode på siden
  • at noen tester skjemaet månedlig
  • at feilvarsler fra SMTP-plugin eller webhotell faktisk leses

Reserveplanen trenger ikke være avansert. Den må bare være kjent, trygg og enkel å følge.

Fem minutters månedlig sjekk

For en vanlig firmaside kan en enkel månedlig sjekk være nok til å oppdage mye tidlig:

  1. Send testmelding fra kontaktskjemaet.
  2. Bekreft at riktig innboks mottar meldingen.
  3. Svar på meldingen og kontroller at svaradressen fungerer.
  4. Sjekk spammappe eller karantene.
  5. Se om skjema-plugin eller SMTP-plugin viser feil.
  6. Kontroller at mottakerlisten fortsatt stemmer.
  7. Sjekk om WordPress lagrer skjemadata unødvendig lenge.

Hvis nettsiden er viktig for salg, support eller booking, bør denne testen være like naturlig som å sjekke at telefonen virker.

Når bør dere be om hjelp?

Dere bør vurdere hjelp hvis:

  • skjemaet sier sendt, men meldinger kommer ikke frem
  • meldinger havner i spam selv om innholdet er legitimt
  • dere ikke vet om nettsiden sender via SMTP
  • DNS, SPF, DKIM eller DMARC er uklart
  • skjemaet håndterer sensitive eller viktige henvendelser
  • dere nylig har flyttet nettside eller e-post
  • ingen vet hvem som egentlig har ansvar for nettsiden

Trønder Data kan hjelpe med webhosting, WordPress, e-postoppsett, DNS, SMTP, skjema og teknisk kontroll. For noen bedrifter passer dette som fast del av en serviceavtale. For andre holder det med timebank når noe må sjekkes, flyttes eller ryddes.

Kort oppsummert

Et kontaktskjema er ikke ferdig testet når det viser en grønn «sendt»-melding på nettsiden.

Dere bør vite hvem som mottar henvendelser, hvordan WordPress sender e-post, om SMTP og DNS er riktig satt opp, hvordan spamfilteret oppfører seg, hvilke data skjemaet lagrer, og hvem som tester at alt fungerer etter endringer.

For små bedrifter handler dette ikke om teknisk perfeksjon. Det handler om å ikke miste ekte henvendelser fra kunder som allerede prøver å ta kontakt.

Laptop med nettsideoversikt, sjekkliste og backupdisk for WordPress-vedlikehold.

WordPress-vedlikehold: sjekklisten små bedrifter bør følge

Skrevet av Svein tore den . Publisert i IT-sikkerhet, Nettside, Serviceavtaler, Wordpress.

En WordPress-side er ikke ferdig bare fordi den er publisert.

For mange små bedrifter blir nettsiden liggende i bakgrunnen etter lansering. Den ser kanskje grei ut, men bak fasaden kan det samle seg gamle plugins, utestede skjema, treg lasting, svake passord, utdatert innhold og backup som ingen har prøvd å gjenopprette.

Det betyr ikke at WordPress er en dårlig løsning. WordPress er fleksibelt, kjent og praktisk for mange norske bedrifter. Men det bør behandles som et driftssystem, ikke som en brosjyre som kan glemmes.

Her er en praktisk sjekkliste for WordPress-vedlikehold som små bedrifter kan bruke selv, eller som grunnlag for å avklare ansvar med en IT- eller webpartner.

Start med ansvar, ikke med plugins

Det første spørsmålet er ikke hvilken plugin som bør oppdateres. Det første spørsmålet er hvem som har ansvar.

En liten bedrift bør vite:

  • hvem som eier domenet
  • hvor nettsiden hostes
  • hvem som har WordPress-administrator
  • hvem som følger med på oppdateringer
  • hvem som tester kontaktskjema
  • hvem som kan gjenopprette backup
  • hvem som skal kontaktes hvis siden går ned

Når dette er uklart, blir små feil fort større. En utløpt lisens, en plugin som stopper, et skjema som ikke sender e-post eller et SSL-sertifikat som feiler kan bli liggende lenge fordi alle tror at noen andre følger med.

Har dere nettside hos en leverandør, bør ansvaret stå tydelig i avtalen. Gjelder avtalen bare hosting? Gjelder den også WordPress-oppdateringer? Gjelder den backup, skjema, sikkerhet og feilretting? Dette er akkurat den typen avklaring vi anbefaler også i artikkelen om forskjellen mellom lisens, drift og ansvar.

Sjekk backup før dere oppdaterer

Oppdateringer er viktige, men de bør ikke gjøres i blinde.

Før WordPress, tema eller plugins oppdateres, bør dere vite at det finnes en fersk backup. Ikke bare av filene, men også av databasen. WordPress består av begge deler: filer, tema, plugins, opplastede bilder og en database med sider, innlegg, innstillinger, brukere og skjemadata.

En nyttig backup-sjekk er:

  • når ble siste backup tatt?
  • dekker den både filer og database?
  • lagres backup et annet sted enn samme webhotell?
  • hvor lenge beholdes backup?
  • hvem kan gjenopprette den?
  • er gjenoppretting faktisk testet?

Det siste punktet er ofte det viktigste. En backup som aldri er testet, er mer et håp enn en rutine.

For bedrifter som er avhengige av nettsiden for leads, booking eller salg, bør sikkerhetskopiering være en del av driftsoppsettet, ikke noe som bare sjekkes etter at noe har gått galt.

Oppdater WordPress, tema og plugins kontrollert

Utdaterte WordPress-installasjoner er en vanlig kilde til risiko. Det gjelder særlig plugins og temaer, fordi de ofte utvider WordPress med kode fra mange ulike leverandører.

En enkel og trygg rekkefølge er:

  1. Ta eller bekreft backup.
  2. Sjekk om nettsiden har kjente kritiske funksjoner, som skjema, nettbutikk, booking eller medlemsinnlogging.
  3. Oppdater plugins og temaer.
  4. Oppdater WordPress-kjerne hvis den ikke allerede er oppdatert.
  5. Test de viktigste sidene og funksjonene.
  6. Tøm cache hvis siden bruker cache.
  7. Noter hva som ble gjort.

For en helt enkel firmaside kan dette ofte gjøres raskt. For nettbutikk, booking, medlemsløsning eller spesialtilpasset tema bør oppdateringer gjøres mer forsiktig, gjerne med testmiljø eller ekstra kontroll.

Hvis en plugin ikke har vært oppdatert på lang tid, bør dere vurdere om den fortsatt er trygg å bruke. Det samme gjelder plugins dere ikke lenger vet hvorfor er installert.

Fjern det som ikke brukes

Mange WordPress-sider samler opp rester over tid:

  • gamle plugins som er deaktivert, men fortsatt installert
  • temaer som ikke brukes
  • gamle administratorbrukere
  • test-sider og gamle kampanjesider
  • kontaktpersoner som har sluttet
  • integrasjoner ingen lenger eier
  • bilder og dokumenter med uklare filnavn

Alt dette trenger ikke slettes ukritisk. Men det bør gjennomgås.

Gamle plugins kan gi unødvendig angrepsflate. Gamle brukere kan gi tilgang til personer som ikke lenger skal ha det. Gamle sider kan skape forvirring i Google eller for kunder som finner dem via søk.

En god regel er enkel: hvis dere ikke vet hvorfor noe finnes, finn det ut før dere lar det bli liggende.

Test kontaktskjema og e-post

Kontaktskjema er et av de mest oversette punktene i WordPress-vedlikehold.

Et skjema kan se riktig ut for besøkende, men likevel ikke levere meldinger. Årsaken kan være endret e-postoppsett, spamfilter, manglende SMTP-oppsett, feil mottakeradresse, ødelagt plugin, DNS-endringer eller at meldinger havner i søppelpost.

Test jevnlig:

  • at skjemaet faktisk sender
  • at riktig person mottar meldingen
  • at avsender og svaradresse fungerer
  • at spam-beskyttelse ikke blokkerer ekte henvendelser
  • at personverntekst og samtykke er rimelig for skjemaets bruk
  • at skjemadata ikke lagres lenger enn nødvendig

Dette er spesielt viktig hvis nettsiden brukes til tilbudsforespørsler, booking, support eller rekruttering. Et ødelagt skjema kan koste mer enn selve vedlikeholdsjobben.

For sider som sender e-post fra webhotell eller via WordPress, bør dere også vite hvordan e-posten er satt opp. Se gjerne Trønder Data sin side om webhosting hvis dere trenger drift av nettside, e-post eller webmiljø.

Se over administratorer og innlogging

WordPress-admin bør ikke være en felles nøkkel alle deler.

Gå gjennom brukerne og sjekk:

  • hvem som har administratorrolle
  • om tidligere ansatte eller gamle leverandører fortsatt har tilgang
  • om hver person har egen bruker
  • om passordene er sterke nok
  • om tofaktor bør aktiveres
  • om brukere har høyere rolle enn de trenger

Administratorrollen bør bare gis til personer som faktisk trenger full kontroll. En person som bare skal skrive nyheter eller rette tekst, trenger normalt ikke administrator.

Dette henger sammen med samme prinsipp som i IT-drift ellers: minst mulig tilgang, men nok til å gjøre jobben. Trønder Data har også skrevet om hvorfor adminbrukere krever strengere kontroll.

Sjekk hastighet, bilder og cache

En treg nettside er ikke bare irriterende. Den kan gi færre henvendelser, dårligere brukeropplevelse og svakere synlighet i søk.

Det er lett å gjøre WordPress tregere over tid:

  • store bilder lastes opp rett fra mobil eller kamera
  • flere plugins legger inn scripts på alle sider
  • gamle sider får tunge elementer
  • cache er feil konfigurert
  • webhotellet har for lite ressurser
  • tema eller builder laster mer enn siden trenger

En månedlig sjekk trenger ikke være avansert. Test forsiden og de viktigste landingssidene på mobil. Se om bildene er rimelige i størrelse. Kontroller at cache fungerer. Bruk gjerne Google Search Console eller PageSpeed Insights som støtte, men ikke jag poeng uten å forstå hva som faktisk påvirker brukerne.

Vi har skrevet mer om hvorfor nettsideytelse og sikkerhet er avgjørende. For små bedrifter handler dette ofte om helt praktiske ting: rask lasting, trygg drift og sider som fungerer når kunden trenger dem.

Ikke glem innholdet

Teknisk vedlikehold er bare halve jobben. Innholdet må også holdes levende.

Sjekk jevnlig:

  • om åpningstider, telefonnummer og e-post er riktige
  • om ansatte, tjenester og priser er oppdatert
  • om gamle kampanjer fortsatt ligger ute
  • om lenker peker til sider som finnes
  • om bilder fortsatt er relevante
  • om viktige sider har tydelig neste steg for kunden
  • om sidetitler og beskrivelser fortsatt stemmer

En nettside som aldri oppdateres, kan gi feil inntrykk selv om teknikken fungerer. Det gjelder særlig små bedrifter der nettsiden ofte er første møte med kunden.

Artikkelen Publisert nettside blir glemt handler nettopp om dette: lansering er starten på nettsidens liv, ikke slutten.

Sjekk webhotell, PHP og SSL

Noen vedlikeholdspunkter ligger utenfor WordPress, men påvirker WordPress direkte.

Minst noen ganger i året bør dere vite:

  • om PHP-versjonen fortsatt er støttet
  • om SSL-sertifikatet fornyes automatisk
  • om domenet er registrert på riktig eier
  • om DNS og e-postoppsett er dokumentert
  • om webhotellet har nok kapasitet
  • om serverbackup og WordPress-backup dekker ulike behov

Dette blir ekstra viktig ved flytting av nettside, bytte av leverandør eller endring i e-post. Ikke avslutt et gammelt webhotell før dere vet om e-post, DNS, skjema eller gamle filer fortsatt er avhengige av det.

Hvis dere planlegger ny side eller ønsker mer kontroll på drift, kan Trønder Data hjelpe med nettside, hosting, WordPress og teknisk oppfølging.

Lag en enkel vedlikeholdsrytme

WordPress-vedlikehold trenger ikke være tungt. Det viktigste er at det skjer jevnlig.

En praktisk månedlig rytme kan være:

  • bekreft at backup finnes
  • oppdater WordPress, tema og plugins kontrollert
  • test kontaktskjema
  • sjekk administratorbrukere
  • test forsiden og viktige sider på mobil
  • se etter åpenbare hastighetsproblemer
  • kontroller at viktig kontaktinformasjon stemmer
  • noter eventuelle feil eller restpunkter

Hver tredje eller sjette måned kan dere ta en grundigere gjennomgang av innhold, SEO, bilder, gamle sider, teknisk oppsett og sikkerhet.

For noen bedrifter passer dette som en fast del av en serviceavtale. For andre holder det med en timebank der små endringer, feilsøking og kontroller kan tas når behovet dukker opp.

Når bør dere be om hjelp?

Det er fullt mulig å gjøre mye WordPress-vedlikehold selv. Men det finnes noen tegn på at det er lurt å få hjelp:

  • dere vet ikke om backup kan gjenopprettes
  • oppdateringer feiler eller gir hvit side
  • kontaktskjema leverer ikke stabilt
  • siden er treg uten åpenbar årsak
  • det finnes mange gamle plugins eller administratorer
  • nettbutikken, booking eller skjema er forretningskritisk
  • ingen vet hvem som eier domene, DNS eller hosting
  • dere skal bytte leverandør eller flytte siden

Da er målet ikke bare å «fikse WordPress». Målet er å få kontroll på nettsiden som en del av bedriftens digitale drift.

Kort oppsummert

WordPress-vedlikehold handler om mer enn å trykke på oppdater-knappen.

Små bedrifter bør ha kontroll på ansvar, backup, oppdateringer, plugins, skjema, administratorer, sikkerhet, hastighet, innhold, webhotell og domenet. Det trenger ikke være komplisert, men det må være regelmessig.

Den beste rutinen er enkel nok til at den faktisk blir gjort, og tydelig nok til at alle vet hvem som har ansvar når noe slutter å virke.

Videre lesing

Arbeidsplass med sikkerhetsinnstillinger, mobil for flerfaktorautentisering, ruter og sjekkliste

Sju IT-sikkerhetstiltak for småbedrifter

Skrevet av Svein tore den . Publisert i Nyheter.

God IT-sikkerhet handler ikke om å kjøpe ett produkt som «stopper alt». For en småbedrift handler det først om å vite hvilke systemer som er viktige, redusere unødvendige tilganger og sørge for at virksomheten kan oppdage og håndtere hendelser. Her er sju tiltak som gir et praktisk utgangspunkt.

1. Lag en enkel oversikt over det dere er avhengige av

Start med å skrive ned hvilke enheter, programmer og skytjenester virksomheten bruker. Ta med datamaskiner, mobiltelefoner, e-post, økonomisystem, filområder, nettside og utstyr som styrer nettverket. Noter også hvem som eier hvert system, og hvem som kan hjelpe hvis det slutter å virke.

Oversikten trenger ikke være avansert. Den må bare være oppdatert nok til at dere vet hva som skal beskyttes og prioriteres. NSM anbefaler å kartlegge enheter og programvare som grunnlag for videre sikkerhetsarbeid.

2. Beskytt kontoene med flerfaktorautentisering

Aktiver flerfaktorautentisering for e-post, skylagring, økonomisystemer, fjernstyring og andre tjenester som inneholder viktige data. Begynn med administratorer og brukere som har tilgang til mye informasjon.

Velg helst løsninger som er motstandsdyktige mot sosial manipulering, for eksempel passnøkler eller sikkerhetsnøkler der tjenesten støtter det. En engangskode eller et pushvarsel gir et ekstra lag, men en bruker kan fortsatt bli lurt til å dele eller godkjenne det. NSM har en egen veiledning om flerfaktorautentisering.

3. Skill daglig bruk fra administratorarbeid

En konto med administratorrettigheter kan gjøre store endringer. Den bør derfor ikke brukes til vanlig e-post, nettsurfing eller dokumentarbeid. Gi ansatte bare tilgangen de trenger, og fjern tilganger når roller endres eller arbeidsforhold avsluttes.

Lag en fast rutine for å kontrollere hvem som har administratorrettigheter. Les også vår gjennomgang av hvorfor administratorbrukere krever strengere kontroll.

4. Oppdater enheter og programmer systematisk

Sikkerhetsoppdateringer må ikke være avhengige av at en tilfeldig medarbeider husker dem. Bestem hvilke enheter og programmer som skal oppdateres automatisk, hvem som følger opp feil, og hvor raskt kritiske oppdateringer skal håndteres.

Husk også rutere, svitsjer, skrivere og andre enheter som ofte blir stående urørt. Utstyr og programvare som ikke lenger mottar sikkerhetsoppdateringer, bør erstattes eller isoleres etter en risikovurdering.

5. Gjør e-postsvindel vanskeligere å lykkes med

Tekniske filtre er viktige, men rutiner rundt betaling og endring av opplysninger er minst like viktige. Avtal at endringer i kontonummer, hastebetalinger og uventede forespørsler fra ledelsen skal bekreftes i en annen kanal. Ring et kjent nummer i stedet for nummeret i meldingen.

Ansatte bør vite hvor de skal melde fra om mistenkelige meldinger. Målet er rask varsling, ikke å finne en skyldig. Jo tidligere en feil oppdages, desto større er muligheten for å begrense konsekvensene.

6. Ha sikkerhetskopi som faktisk kan gjenopprettes

Finn ut hvilke data virksomheten ikke kan klare seg uten, hvor de sikkerhetskopieres og hvor lenge kopiene beholdes. En synkronisert mappe er ikke nødvendigvis en separat sikkerhetskopi: sletting eller kryptering kan også bli synkronisert.

Test gjenoppretting med jevne mellomrom. En vellykket statusmelding fra sikkerhetskopieringen beviser ikke alene at riktige data kan hentes tilbake innen tiden virksomheten tåler. Vi har forklart dette nærmere i guiden om sikkerhetskopiering og datatap.

7. Avklar hva som skal skje når noe går galt

Skriv ned hvem som skal kontaktes ved mistenkelig pålogging, tapt utstyr, feilbetaling eller utilgjengelige systemer. Planen bør finnes et sted dere får tilgang til selv om e-post eller skylagring er nede. Ta med kontaktpunkter hos IT-leverandør, forsikring og andre relevante samarbeidspartnere.

En kort øvelse avdekker ofte mangler som ikke er synlige på papiret. Velg én situasjon, for eksempel at e-posten er kompromittert, og gå gjennom hvem som gjør hva den første timen. Se vår praktiske guide til IT-beredskap for småbedrifter for et enkelt oppsett.

Begynn med ansvar, ikke med en lang handleliste

NSMs grunnprinsipper deler sikkerhetsarbeidet i å identifisere og kartlegge, beskytte og opprettholde, oppdage, samt håndtere og gjenopprette. Anbefalingene må tilpasses den enkelte virksomheten; de er et fundament, ikke en garanti mot hendelser.

Velg først de to eller tre største manglene, sett en ansvarlig og en dato, og kontroller deretter at tiltakene fungerer. Dersom dere mangler kapasitet til løpende oppfølging, kan en fast IT-serviceavtale gjøre ansvar, oppdateringer og kontroll mer forutsigbart.

Kilde: NSMs grunnprinsipper for IKT-sikkerhet.

Laptop, adgangskort, nøkkel og mobil kontrolleres mot en sjekkliste når en ansatt slutter

Når en ansatt slutter: IT-sjekklisten små bedrifter bør ha klar

Skrevet av Svein tore den . Publisert i IT-sikkerhet, Microsoft 365, Serviceavtaler.

Når en ansatt slutter, blir IT ofte tatt litt på sparket. Noen husker å få tilbake PC-en. Noen ber IT-leverandøren sperre e-postkontoen. Noen lar kontoen stå åpen en stund «for sikkerhets skyld».

Det kan fungere i en rolig situasjon. Men det er ikke en god rutine.

En ryddig avslutning handler om tre ting samtidig:

  • tidligere ansatte skal ikke ha tilgang lenger enn nødvendig
  • bedriften skal ikke miste viktige filer, e-post eller dokumentasjon
  • e-post og private filer skal håndteres innenfor norske personvernregler

For små bedrifter trenger ikke dette være komplisert. Men det bør være planlagt før siste arbeidsdag.

Start med dato og ansvar

Det viktigste spørsmålet er enkelt: når skal tilgangen stoppe?

Noter:

  • siste arbeidsdag
  • klokkeslett for sperring av kontoer
  • hvem som bestiller endringen
  • hvem som godkjenner tilgang til filer eller felles systemer
  • hvem som skal overta praktiske oppgaver
  • om fratreden er planlagt, brå eller sensitiv

Ved vanlig fratreden kan mye gjøres kontrollert over flere dager. Ved konflikt, mistanke om misbruk eller annen sensitiv situasjon bør tilgangene sperres raskt, og videre håndtering bør avklares med ledelse, HR eller juridisk rådgiver.

IT-leverandøren bør ikke måtte gjette. En kort bestilling med dato, navn på intern godkjenner og hva som skal bevares gjør jobben tryggere.

Sperr innlogging før dere rydder

Mange starter med å slette brukeren. Det er ofte feil rekkefølge.

Start heller med å hindre ny innlogging:

  • blokker innlogging i Microsoft 365, Google Workspace, Nextcloud eller annet hovedsystem
  • reset passord hvis kontoen skal bevares midlertidig
  • logg ut aktive økter der systemet støtter det
  • fjern eller deaktiver tofaktormetoder som tilhører den ansatte
  • vurder om mobil, nettbrett eller private enheter må fjernes fra kontoen

I Microsoft 365 har Microsoft egne trinn for å blokkere tidligere ansatte, håndtere e-post og fjerne lisens. De tekniske mulighetene må likevel brukes med norske regler og bedriftens rutiner i bakhodet.

Poenget er at kontoen kan bevares teknisk mens tilgangen stoppes. Det gir tid til å vurdere e-post, filer, lisenser og dokumentasjon uten at den tidligere ansatte fortsatt kan logge inn.

Ikke sett automatisk videresending ukritisk

E-post er et av de vanligste stedene små bedrifter gjør feil.

Det kan virke fristende å videresende all e-post fra den tidligere ansattes konto til daglig leder eller en kollega. Teknisk er det ofte enkelt. Juridisk og personvernmessig er det langt mer krevende.

Datatilsynet er tydelig på at en personlig e-postkasse hos arbeidsgiver også har et personvern. Automatisk videresending av all e-post kan bli vurdert som løpende overvåking. Innsyn i e-post bør derfor bare skje når vilkårene er oppfylt, og med riktig prosess.

I praksis bør små bedrifter heller vurdere:

  • automatisk svar som forteller at personen har sluttet og hvem som kan kontaktes
  • overgang til rolleadresse, for eksempel post, salg eller support
  • avgrenset innsyn i konkrete arbeidsrelaterte meldinger når det er nødvendig
  • overføring av kunderelaterte saker til felles system før siste arbeidsdag
  • sletting eller arkivering etter avtalt rutine når behovet er avklart

Hvis bedriften ofte er avhengig av enkeltpersoners personlige e-postkasser, er det et tegn på at rutinene bør endres. Viktige henvendelser bør helst gå til fellesadresser eller saksystem, ikke bare til én person.

Avklar hva som skal skje med filer

Filer kan være like viktige som e-post.

Når en ansatt slutter, må dere vite hvor arbeidsfiler ligger:

  • lokalt på PC
  • i OneDrive
  • i SharePoint
  • i Nextcloud
  • på filserver
  • i fagsystem
  • i regnskapssystem
  • i prosjektverktøy

Ikke anta at alt ligger «i skyen». Mange bedrifter har en blanding av lokale mapper, skrivebord, nedlastinger, synkroniserte mapper og fellesområder.

Gå gjennom:

  • hvilke mapper som tilhører bedriften
  • hvem som skal eie eller overta filene
  • om private filer skal skilles ut
  • om delte lenker bør fjernes
  • om eksterne delinger skal stenges
  • om filer er inkludert i backup

Hvis bedriften bruker Nextcloud, OneDrive eller SharePoint, bør eierskap og delinger kontrolleres før brukeren slettes. Det er enklere å rydde mens kontoen fortsatt finnes, men er sperret for den tidligere ansatte.

Få tilbake utstyr og sjekk enhetene

PC, mobil, nettbrett, adgangsbrikke, sikkerhetsnøkkel, headset, lader og annet utstyr bør registreres ved innlevering.

En enkel sjekkliste er nok:

  • hvilket utstyr er levert inn
  • serienummer eller maskinnavn
  • fysisk tilstand
  • om lader og tilbehør følger med
  • om PC-en skal gjenbrukes, slettes eller lagres
  • om lokale filer må tas vare på før reinstallasjon
  • om enheten har fjernhjelp, RMM eller sikkerhetsprogramvare

Ikke gi PC-en direkte videre til neste person uten rydding. En tidligere brukers profil, nettleserdata, lokale filer, passord og synkronisering kan skape både sikkerhets- og personvernproblemer.

Ved gjenbruk bør PC-en normalt gjennomgås, oppdateres og settes opp på nytt etter bedriftens standard.

Fjern tilgang i systemene rundt hovedkontoen

Microsoft 365 eller e-postkontoen er bare én del av bildet. Mange ansatte har tilgang til flere systemer enn bedriften husker.

Typiske steder å sjekke:

  • regnskap og faktura
  • nettbank og betaling
  • lønn og HR
  • CRM eller kundesystem
  • WordPress og nettside
  • nettbutikk
  • domene, DNS og webhotell
  • sosiale medier
  • annonsekontoer
  • fjernhjelp og RMM
  • VPN
  • WiFi og nettverksutstyr
  • passordhvelv
  • fagsystemer

Dette er grunnen til at tilgangsstyring bør dokumenteres mens folk starter, ikke først når de slutter. Hvis bedriften ikke vet hva en person har tilgang til, blir offboarding en manuell letejobb.

NSM anbefaler å kartlegge brukere og behov for tilgang. Det er et godt prinsipp også for små bedrifter: gi nok tilgang til jobben, fjern den når behovet forsvinner.

Bytt delte passord og rydd gamle snarveier

Personlige brukerkontoer er best. Likevel har mange små bedrifter noen delte passord i praksis.

Når en ansatt slutter, bør dere vurdere om personen kjente passord til:

  • felles e-postkontoer
  • domene- eller webhotelltilgang
  • sosiale medier
  • leverandørportaler
  • nettbutikk
  • WiFi
  • lokale administratorpassord
  • skannere, skrivere eller nettverksutstyr

Delte passord bør byttes når noen som kjente dem slutter, spesielt hvis tilgangen kan brukes utenfor kontoret. Enda bedre er det å fase ut delte passord og bruke personlige kontoer med riktige roller.

Hvis bedriften bruker passordhåndtering, fjern brukeren der også. Husk at eksporterte eller kopierte passord ikke nødvendigvis forsvinner selv om kontoen stenges.

Fjern administratorrettigheter først

Administratorrettigheter bør behandles særskilt. En vanlig brukerkonto som blir stående åpen er uheldig. En administratorkonto som blir stående åpen er verre.

Sjekk om personen hadde administratorrolle i:

  • Microsoft 365 eller Entra
  • lokal Windows-PC
  • servere
  • WordPress
  • webhotell eller Plesk
  • domene/DNS
  • Nextcloud
  • backup
  • regnskapssystem
  • sikkerhetsverktøy

Hvis dere er usikre, prioriter først kontoer med høyest risiko: administrasjon, økonomi, e-post, backup, nettside, domene og systemer med kundedata.

Trønder Data har tidligere skrevet om hvorfor adminbrukere krever strengere kontroll. Det prinsippet gjelder ekstra godt når noen slutter.

Sjekk backup før noe slettes

Sletting føles ryddig, men kan være farlig hvis dere ikke vet hva som finnes av backup og gjenoppretting.

Før kontoer eller data slettes permanent, avklar:

  • hvor lenge e-post skal bevares
  • om filer må arkiveres
  • om kunden eller prosjektet trenger historikk
  • om data er dekket av backup
  • hvem som kan bestille gjenoppretting
  • om lisens kan fjernes uten at data forsvinner for tidlig

I Microsoft 365 kan dataoppbevaring, lisenser og sletting ha konkrete tekniske konsekvenser. Dette bør sjekkes før lisensen fjernes eller brukeren slettes. Det samme gjelder Nextcloud, Google Workspace og andre skytjenester.

Synkronisering er heller ikke det samme som backup. Hvis en fil slettes eller overskrives og endringen synkroniseres, trenger dere en reell gjenopprettingsmulighet.

Lag en praktisk offboarding-mal

Små bedrifter trenger ikke et tungt HR-system for å gjøre dette riktig. En enkel mal holder lenge.

Malen bør ha felter for:

  • ansattnavn
  • siste arbeidsdag
  • ansvarlig leder
  • tidspunkt for sperring
  • e-posthåndtering
  • filhåndtering
  • utstyr som skal leveres inn
  • systemer som må stenges
  • delte passord som må byttes
  • administratorroller
  • backup/arkiv
  • dato for kontroll etter avslutning

Det viktigste er ikke at malen er lang. Det viktigste er at den blir brukt hver gang.

Sjekk igjen etter noen dager

Offboarding bør ha en etterkontroll. Noen tilganger dukker først opp når en kollega prøver å finne en fil, når en kunde sender e-post, eller når en leverandørportal fortsatt viser tidligere ansatt som kontakt.

Etter noen dager eller uker bør dere sjekke:

  • kommer e-post til riktig sted
  • er filer overtatt av riktig person
  • er lisensene ryddet
  • er utstyr registrert
  • er gamle delinger fjernet
  • er brukeren fjernet fra grupper og eksterne systemer
  • er dokumentasjonen oppdatert

Hvis samme type feil går igjen hver gang noen slutter, er det rutinen som må forbedres.

Når bør dere bruke IT-partner?

En liten bedrift kan gjøre mye selv, men offboarding blir fort mer krevende når dere har flere systemer, ansatte som jobber eksternt, Microsoft 365, Nextcloud, nettside, regnskapssystem, felles e-post, sikkerhetskrav og backup.

Fast IT-hjelp eller en serviceavtale kan være nyttig når dere vil ha:

  • fast sjekkliste for nye og avsluttede brukere
  • ryddig dokumentasjon på kontoer og utstyr
  • kontroll på Microsoft 365, e-post, Nextcloud og PC-er
  • rask sperring ved hastebehov
  • mindre risiko for glemte administratorroller
  • tryggere håndtering av backup og filer

For bedrifter som ikke trenger fast avtale, kan timebank være en praktisk mellomløsning. Da kan brukerendringer, PC-rydding, tilgangskontroll og små supportoppgaver håndteres uten at alt må bli en egen hastejobb.

Kort oppsummert

Når en ansatt slutter, bør IT-rutinen dekke mer enn PC og e-post.

Start med å sperre innlogging, ikke slette alt. Håndter e-post og filer med respekt for personvernreglene. Fjern tilganger i alle systemer, bytt delte passord, sjekk administratorroller, og kontroller backup før data slettes.

Den beste rutinen er den som er enkel nok til at bedriften faktisk bruker den, hver gang noen slutter.

To datamaskiner med e-postsystemer, ekstern sikkerhetskopi og sjekkliste for migrering

Flytte e-post til Microsoft 365: sjekk dette før migrering

Skrevet av Svein tore den . Publisert i Guider, Microsoft 365, Serviceavtaler. Ingen kommentarer til Flytte e-post til Microsoft 365: sjekk dette før migrering

Å flytte e-post til Microsoft 365 høres ofte ut som én DNS-endring. I praksis er det sjelden så enkelt. For en liten bedrift kan e-post være knyttet til postbokser, aliaser, gamle webhotell, skannere, kontaktskjema, regnskapssystem og mobiltelefoner som har vært satt opp litt forskjellig over flere år.

Derfor bør en e-postmigrering planlegges som en liten driftsendring, ikke som en rask knapp i adminpanelet. Målet er ikke å gjøre prosjektet større enn nødvendig. Målet er å unngå at viktig e-post stopper, havner feil sted eller blir liggende igjen i en gammel postkasse ingen følger med på.

Start med å finne ut hvor e-posten faktisk går i dag

Før dere endrer noe, bør dere vite hvilken løsning som mottar e-post i dag. Det er ikke alltid det samme som der nettsiden ligger, eller der domenet er kjøpt.

Sjekk særlig:

  • hvem som styrer DNS for domenet
  • hvilken MX-post som mottar e-post
  • om det finnes gamle postbokser på webhotell eller mailserver
  • om noen bruker webmail, Outlook, Thunderbird eller mobil direkte mot gammel server
  • om domenet har aliaser, videresendinger eller delte postbokser
  • om kontaktskjema, skrivere, skannere eller fagsystemer sender e-post via gammel løsning
  • om det finnes spamfilter, gateway eller connector mellom flere systemer

Dette er ofte der små feil oppstår. En bedrift kan ha Microsoft 365 for noen brukere, men fortsatt ha en gammel postboks, videresending eller SMTP-oppsett et annet sted. Da kan en tilsynelatende enkel MX-endring få uventede følger.

Ikke begynn med MX-posten

MX-posten bestemmer hvor ny innkommende e-post for domenet sendes. Når den endres til Microsoft 365, begynner ny e-post å gå dit. Eksisterende e-post hos tidligere leverandør flytter seg ikke automatisk.

Microsoft beskriver dette tydelig i domenedokumentasjonen sin: brukere og postbokser bør være opprettet før MX endres, slik at e-post ikke stopper under overgangen. Det betyr at MX-endringen bør komme etter kartlegging, oppretting av brukere, test og plan for migrering.

En god tommelfingerregel er: ikke pek domenet til Microsoft 365 før dere vet at riktig postboks finnes for alle adresser som skal motta e-post.

Avklar hva som faktisk skal flyttes

En migrering handler ikke bare om “all e-post”. Dere bør vite hva som skal tas med, hva som kan arkiveres, og hva som ikke skal flyttes.

Ikke velg «tre år» bare fordi det høres passe ut

Et mønster vi møter i migreringsarbeid, er at virksomheten først ber om å få med e-post fra de siste tre årene. Det kan virke som en enkel avgrensning. Senere kommer spørsmålet om hvor eldre korrespondanse ble av, fordi ingen undersøkte hva postboksene faktisk ble brukt til før grensen ble satt.

Det betyr ikke at all historikk alltid skal flyttes. Det betyr at beslutningen bør bygge på innhold og behov, ikke på hukommelse alene. Før dere velger en dato, bør hver postbokseier kontrollere noen konkrete eksempler:

  • Hvor gammel er den eldste e-posten de fortsatt søker etter i arbeidshverdagen?
  • Finnes det eldre dialog om avtaler, leveranser, reklamasjoner eller andre saker som fortsatt kan bli aktuelle?
  • Ligger viktig historikk i Sendt, egne undermapper, lokale arkivfiler eller en tidligere ansatts postboks?
  • Er det krav i avtaler, interne rutiner eller regelverk som påvirker hvor lenge bestemte opplysninger skal bevares eller slettes?

Velg deretter en bevisst løsning: flytt hele den nødvendige historikken, flytt et dokumentert utvalg, eller etabler et separat arkiv med avklart tilgang og levetid. Å la gammel e-post bli stående på en server som snart skal stenges, er ikke en arkivplan.

Kontroller historikken før gammel løsning stenges

Etter migreringen bør dere søke etter kjente meldinger fra både nyere og eldre perioder. Kontroller innboks, Sendt og egne mapper, åpne noen vedlegg, og sjekk eventuelle lokale arkivfiler. Utpek én person som bekrefter at den avtalte historikken er tilgjengelig før gammel løsning slettes eller abonnementet avsluttes.

Migreringsmetoden påvirker også hva som følger med. Microsoft opplyser at en vanlig IMAP-migrering flytter e-post i postmappene, men ikke kontakter, kalenderoppføringer eller oppgaver. Målpostboksene må dessuten opprettes i Microsoft 365 før IMAP-migreringen gjennomføres. Slike avgrensninger må stå i migreringsplanen, slik at manglende innhold ikke først oppdages etterpå.

Avklar dette før migreringen:

  • hvilke brukere som skal ha Microsoft 365-postboks
  • hvilke delte adresser som skal være shared mailbox, distribusjonsliste eller alias
  • om gamle videresendinger fortsatt trengs
  • hvor langt tilbake historisk e-post skal flyttes
  • om kalender, kontakter og regler må håndteres separat
  • hvem som kan godkjenne rydding eller sletting
  • hvilke kontoer som må testes ekstra fordi de brukes av ledelse, økonomi eller kundemottak

Ved IMAP-migrering er det spesielt viktig å være presis. IMAP egner seg til å flytte e-post fra mange eldre eller enklere e-postløsninger, men det løser ikke alt rundt kalender, kontakter, klientprofiler, regler og gammel lokal data. Slike ting må vurderes ved siden av.

Rydd i adresser før de flyttes

Mange små virksomheter har adresser som er laget over tid: en info-adresse, gamle ansatte, midlertidige aliaser, leverandøradresser, prosjektadresser og videresendinger som ingen helt husker hvorfor finnes.

Før migrering bør dere gå gjennom listen og merke:

  • skal beholdes som egen bruker
  • skal være delt postboks
  • skal være alias
  • skal videresendes
  • skal stenges eller arkiveres

Dette sparer lisenser, reduserer rot og gjør det enklere å dokumentere hvem som har tilgang til hva. Det er også et godt tidspunkt å slå på tofaktor og rydde i administratorrettigheter.

DNS må behandles som drift, ikke pynt

For Microsoft 365-e-post er de viktigste DNS-postene normalt MX, Autodiscover og SPF. I tillegg bør DKIM og DMARC vurderes for bedre e-postautentisering og mindre risiko for misbruk av domenet.

Det viktigste er ikke å kopiere et eksempel fra nettet. Verdiene må hentes fra riktig Microsoft 365-tenant og riktig domene. Feil MX-verdi, gammel SPF-post eller manglende autodiscover kan gi problemer som først oppdages når brukerne skal sende, motta eller sette opp Outlook.

Hvis DNS styres hos en annen leverandør enn webhotellet, må dere vite hvor endringen faktisk skal gjøres. Ikke anta at Plesk, Domeneshop, Cloudflare, Microsoft og nettsideleverandøren styrer samme del av domenet.

Se etter gamle systemer som fortsatt sender e-post

Et vanlig migreringsproblem er at brukerpostboksene flyttes, men gamle systemer fortsatt prøver å sende via tidligere mailserver. Det kan gjelde:

  • kontaktskjema på nettsiden
  • kopimaskin eller skanner
  • regnskapssystem
  • alarmsystem eller overvåking
  • nettbutikk
  • eldre applikasjoner med SMTP-oppsett

Noen systemer kan bruke Microsoft 365 direkte. Andre bør bruke en godkjent SMTP-løsning eller connector, avhengig av behov og sikkerhetskrav. Microsoft har egen dokumentasjon for connectors og scenarier der e-post skal rutes mellom Microsoft 365 og andre systemer.

Lag en enkel testplan

En praktisk testplan trenger ikke være lang. Den bør bare dekke det som faktisk kan gå galt.

Test minst dette:

  • mottak fra ekstern e-postadresse
  • sending til ekstern e-postadresse
  • sending internt mellom brukere
  • Outlook-oppsett på PC
  • mobiloppsett for minst én bruker
  • webmail i Microsoft 365
  • deling eller tilgang til felles postboks
  • kontaktskjema eller system som sender e-post
  • at gamle postbokser ikke lenger mottar ny e-post etter kuttet

Dokumenter hva som er testet. Når en bruker senere sier at “e-posten ikke virker”, er det stor forskjell på å vite at domenet fungerer, og å måtte gjette om feilen ligger i DNS, Outlook-profilen, passord, mobil eller en gammel konto.

Planlegg opprydding etterpå

Migreringen er ikke ferdig idet e-post begynner å komme inn i Microsoft 365. Etterpå bør dere rydde kontrollert.

Typiske etterarbeidspunkter:

  • bekreft at alle viktige adresser mottar e-post i ny løsning
  • kontroller at gamle videresendinger ikke sender e-post feil vei
  • oppdater dokumentasjon for DNS, postbokser og ansvar
  • fjern gamle kontoer først når data og tilgang er avklart
  • sett opp eller bekreft backup der det trengs
  • slå på sikkerhetsinnstillinger som tofaktor og betinget tilgang der det passer
  • avtal hvem som hjelper brukere med mobil og Outlook-profiler

Ikke slett gamle postbokser eller serveroppsett for tidlig. Det kan ligge historikk, systemkontoer eller avklaringer der som først bør verifiseres.

Backup og gjenoppretting må avklares separat

Microsoft 365 gir en robust skytjeneste, men en migrering bør likevel ha en tydelig plan for backup og gjenoppretting. Det gjelder både data som ligger igjen i gammel løsning, data som flyttes, og data som skal beskyttes etterpå.

Spør konkret:

  • finnes det en eksport eller backup før migreringen starter?
  • hvor lenge beholdes gammel løsning etter kuttet?
  • hvem kan be om gjenoppretting?
  • dekker backup e-post, OneDrive, SharePoint og Teams, eller bare deler av miljøet?
  • hvordan testes restore hvis noe mangler?

Vi har skrevet mer om dette i Hva dekker Microsoft 365-backup? og Hvordan fungerer backup og gjenoppretting hos Trønder Data?.

Når bør dere få hjelp?

En liten bedrift kan fint gjøre en enkel e-postflytting selv hvis miljøet er ryddig, få brukere er involvert og ingen gamle systemer er koblet på. Men få hjelp hvis dere har:

  • flere domener eller flere e-postleverandører
  • gamle postbokser på webhotell
  • mange aliaser, delte adresser eller videresendinger
  • skannere, regnskapssystem eller nettsider som sender e-post
  • behov for å bevare historikk
  • usikkerhet rundt DNS, SPF, DKIM eller DMARC
  • krav til minst mulig nedetid

Da er det ofte billigere å bruke litt tid på kartlegging enn å feilsøke i hast etter at e-posten har stoppet.

Kort sjekkliste før dere flytter

  • Kartlegg nåværende e-postleverandør og DNS-ansvar.
  • Lag liste over brukere, aliaser, videresendinger og delte postbokser.
  • Opprett nødvendige brukere og postbokser i Microsoft 365 før MX endres.
  • Bestem migreringsmetode og test med en konto først.
  • Sjekk gamle systemer som sender e-post.
  • Planlegg DNS-endring og tidspunkt.
  • Test sending, mottak, mobil, Outlook og webmail.
  • Avklar backup, arkiv og opprydding.
  • Dokumenter hva som er gjort.

Trønder Data kan hjelpe med kartlegging, migrering, DNS, Microsoft 365-oppsett og etterkontroll for små og mellomstore bedrifter. Se også siden vår om Microsoft 365 og artikkelen Når passer Microsoft 365, og når bør dere velge Nextcloud?.

Videre lesing

IT-tekniker overvåker sikkerhetsstatus for PC-er i en liten bedrift.

Antivirus er ikke nok: 5 krav til endepunktsikring

Skrevet av Svein tore den . Publisert i IT-sikkerhet.

Antivirus er fortsatt en viktig del av beskyttelsen på en PC, men det er ikke det samme som komplett endepunktsikring. En liten bedrift trenger også oversikt over enhetene, riktig konfigurasjon, sentral varsling og en avklart plan for hva som skal skje når noe blir oppdaget.

Det er nettopp forskjellen mellom et installert produkt og en fulgt opp sikkerhetstjeneste som avgjør om beskyttelsen virker i praksis. Her er fem krav småbedriften bør stille til endepunktsikringen.

Hva er et endepunkt?

Et endepunkt er en enhet som brukes mot bedriftens data og tjenester. Det kan være en stasjonær PC, bærbar PC, server eller annen administrert enhet. Hjemmekontor og arbeid på reise gjør at enhetene ikke alltid befinner seg bak kontorets brannmur.

Endepunktsikring skal redusere risikoen på disse enhetene og gi virksomheten mulighet til å oppdage og håndtere uønsket aktivitet. Løsningen må derfor omfatte mer enn skanning av kjente skadevarefiler.

1. Alle enheter må være kjent og registrert

En sikkerhetsløsning beskytter ikke en PC som ingen vet om, eller en agent som sluttet å rapportere for flere uker siden. Første krav er derfor en oppdatert oversikt over hvilke enheter som skal være med, hvem som bruker dem og om de faktisk kommuniserer med sikkerhetstjenesten.

En praktisk kontroll bør vise:

  • hvilke enheter som er aktive
  • hvilken bruker eller funksjon de tilhører
  • når hver enhet sist rapporterte
  • om beskyttelsen er aktiv og oppdatert
  • hvilke enheter som mangler eller har falt ut

Dette samsvarer med det første hovedområdet i NSMs grunnprinsipper: identifisere og kartlegge. Uten oversikt er det vanskelig å vite om sikkerhetstiltakene dekker hele miljøet.

2. Forebyggende beskyttelse må være riktig konfigurert

Antivirus kan oppdage og stoppe mye kjent skadevare. Moderne endepunktsikring kan i tillegg bruke atferdsanalyse, skybasert beskyttelse, angrepsflatereduksjon, brannmurregler og beskyttelse mot at sikkerhetsinnstillinger manipuleres.

Funksjonene har bare verdi når de er slått på, oppdatert og tilpasset miljøet. Standardinnstillinger kan være et godt utgangspunkt, men unntak, gamle policyer og programvare som ikke lenger støttes kan svekke beskyttelsen. Derfor bør noen ha ansvar for å følge med på konfigurasjonen over tid.

Microsofts dokumentasjon for Defender for Endpoint skiller blant annet mellom forebyggende beskyttelse, endepunktdeteksjon og respons, sårbarhetsstyring og automatisert undersøkelse. Det illustrerer hvorfor «vi har antivirus» ikke beskriver hele sikkerhetsnivået.

3. Hendelser må oppdages sentralt

Noen angrep ser ikke ut som en kjent virusfil. En kompromittert konto kan brukes til å starte legitime verktøy, endre innstillinger eller bevege seg videre til andre systemer. Da er det nødvendig å se aktivitet og varsler i sammenheng.

EDR, eller endpoint detection and response, samler sikkerhetsrelevant informasjon fra enhetene og kan varsle om mistenkelig atferd. Det gir et bedre grunnlag for å undersøke hva som har skjedd og hvilke enheter eller kontoer som er berørt.

Sentral varsling betyr likevel ikke at alle varsler er alvorlige, eller at løsningen løser alle hendelser automatisk. Noen må vurdere dem, prioritere riktig og dokumentere utfallet. Les også hvordan dere kan kontrollere at endepunktsikringen faktisk virker.

4. Det må finnes en plan for respons

Et varsel uten en ansvarlig mottaker er bare informasjon. Før en hendelse oppstår, bør virksomheten vite hvem som undersøker varselet, hvem som kan isolere en enhet, og hvem som tar beslutninger dersom arbeidet må stoppes.

En enkel responsplan bør svare på:

  • Hvem mottar og vurderer sikkerhetsvarsler?
  • Hvor raskt skal kritiske varsler behandles?
  • Kan en mistenkt enhet isoleres fra nettverket?
  • Hvordan sikres logger og annet beslutningsgrunnlag?
  • Hvem informerer ledelsen og berørte brukere?
  • Hvordan settes enheten trygt tilbake i drift?

NSM deler sikkerhetsarbeidet inn i å identifisere, beskytte, oppdage og håndtere/gjenopprette. Grunnprinsippene er ikke en garanti mot hendelser, men de viser hvorfor forebygging må kobles til styring, kompetanse og beredskap.

5. Beskyttelsen må kontrolleres over tid

En installasjon som var riktig i fjor, er ikke nødvendigvis riktig i dag. Bedriften får nye PC-er og ansatte, programvare endres, og enheter kan falle ut av administrasjonen. Endepunktsikring er derfor en løpende oppgave.

Be om en periodisk kontroll som minst viser dekningsgrad, enheter som ikke rapporterer, aktive varsler, status på oppdateringer og eventuelle unntak. Kontrollen bør føre til konkrete oppgaver når noe avviker. En rapport uten oppfølging gir liten sikkerhetsverdi.

Dette er også grunnen til at vi skiller mellom å levere en lisens og å ha et avtalt ansvar for oppfølging. Produktet leverer funksjoner; avtalen avgjør hvem som følger med og reagerer.

Endepunktsikring erstatter ikke resten av sikkerhetsarbeidet

Selv en godt administrert endepunktløsning kan ikke alene beskytte hele virksomheten. Den må inngå i et lagdelt oppsett med blant annet:

  • flerfaktorautentisering og kontroll med brukerkontoer
  • sikkerhetsoppdateringer for operativsystem og programmer
  • begrensede administratorrettigheter
  • e-postsikkerhet og opplæring av ansatte
  • separate, testede sikkerhetskopier
  • beredskap for driftsstans og sikkerhetshendelser

Endepunktsikring og backup løser dessuten forskjellige oppgaver. Sikkerhetsløsningen skal forebygge, oppdage og bidra til respons. Backup skal gjøre det mulig å gjenopprette data når forebyggingen ikke var nok. Se vår guide til sikkerhetskopiering for småbedrifter.

Sju spørsmål til IT-leverandøren

  1. Har vi en oppdatert liste over alle enheter som skal være beskyttet?
  2. Kan vi se hvilke enheter som ikke rapporterer eller har feil?
  3. Hvilke forebyggende funksjoner er faktisk aktivert?
  4. Hvem mottar varsler, og når blir de vurdert?
  5. Kan en kompromittert enhet isoleres raskt?
  6. Hvordan følges unntak og konfigurasjonsendringer opp?
  7. Hvordan dokumenteres status og utførte tiltak?

Hvis svarene bare handler om at et program er installert, mangler dere sannsynligvis viktige deler av tjenesten.

Kort oppsummert

God endepunktsikring for en småbedrift består av fem ting: oversikt over enhetene, riktig forebyggende beskyttelse, sentral deteksjon, en avklart responsplan og løpende kontroll. Antivirus er en del av dette, men ikke hele løsningen.

Trønder Data kan hjelpe med å kartlegge enhetene, sette opp beskyttelsen og avtale hvem som følger opp varsler og avvik. Les mer om vår tjeneste for endepunktsikring.

Illustrasjon av kontrollert overtakelse av IT-drift med PC-er, brannmur, kalender og sikkerhet

Slik bytter dere IT-leverandør uten unødvendig nedetid

Skrevet av Svein tore den . Publisert i Serviceavtaler. Ingen kommentarer til Slik bytter dere IT-leverandør uten unødvendig nedetid

Et bytte av IT-leverandør bør behandles som en kontrollert overtakelse, ikke som en rask bestilling. Dere trenger datoer, tydelig ansvar og en dokumentert oversikt over tjenester, tilganger og tekniske avhengigheter før den gamle leveransen avsluttes.

Å bytte IT-leverandør trenger ikke være dramatisk. Det blir først krevende når overgangen skjer uten oversikt, uten datoer og uten tydelig ansvar.

For oss handler et leverandørbytte ikke bare om å legge inn nye lisenser. Vi må vite når tidligere avtale avsluttes, hva dere har fått levert fra før, hvilke systemer som er kritiske, og hva vi faktisk skal ta ansvar for etterpå.

Kortversjonen er denne: Jo bedre vi får planlagt før overtakelsen, desto mindre merker ansatte og drift når byttet skjer.

Start med oppsigelsesdatoen

Det første vi trenger, er oppsigelsesdatoen hos eksisterende leverandør. Den datoen styrer resten av planen.

Lisenser må flyttes eller bestilles før fristen. Tilganger må være klare før gammel leverandør mister ansvar. Overvåking, supportverktøy og sikkerhetssystemer må overtas uten at PC-er, e-post, backup eller nettverk havner i et tomrom.

Hvis oppsigelsen skjer først og planleggingen kommer etterpå, må oppgavene ofte løses i feil rekkefølge. Det skaper unødvendig hastverk og øker risikoen for avbrudd.

En praktisk overtakelsesplan bør minst vise:

  • når dagens leveranse og tilganger slutter
  • hvilke tjenester som må overføres før denne datoen
  • hva tidligere leverandør skal levere eller bidra med
  • hvem som godkjenner endringer og nye kostnader
  • hvilke systemer virksomheten ikke tåler nedetid på
  • hva den nye leverandøren skal ha ansvar for etter overtakelsen

Vi må vite hva dere faktisk har

Det vi oftest savner ved en overtakelse, er ikke én bestemt innlogging. Det er den samlede oversikten over hvilke tjenester og oppsett kunden faktisk har. Hullene blir gjerne synlige først når vi begynner å rydde i nettverket eller følger en tjeneste tilbake til den som administrerer den.

En «IT-avtale» kan i praksis omfatte Microsoft 365, backup, domene, DNS, brannmur, WiFi, antivirus, fjernsupport, overvåking, webhotell, e-postsignaturer, skrivere, passordhvelv, servere, nettverksutstyr og administratorbrukere.

Hvis ingen har full oversikt, må den bygges før ansvaret kan overtas på en ryddig måte. Dette er ikke papirarbeid for papirarbeidets skyld. Det er forskjellen på å vite hva vi overtar og å oppdage manglene først når noe stopper.

Kunden bør eie en oppdatert overleveringspakke

En IT-leverandør kan administrere løsninger på vegne av kunden, men virksomheten bør selv ha tilgang til oppdatert dokumentasjon og vite hvor den finnes. Det gjør kunden mindre avhengig av enkeltpersoner og reduserer usikkerheten ved leverandørbytte, sykdom eller en alvorlig driftshendelse.

En enkel overleveringspakke bør inneholde:

  • tjenesteoversikt med leverandør, formål, avtaleeier og fornyelsesdato
  • oversikt over domener, DNS, webhotell og e-postmiljø
  • nettverkskart med brannmur, svitsjer, trådløse nett og kritiske forbindelser
  • liste over administratorroller og hvor innloggingene forvaltes
  • oversikt over enheter, servere, backup og sikkerhetsverktøy
  • kontaktpunkter, supportavtaler og rutine for alvorlige hendelser
  • kjente avhengigheter og systemer som må startes eller endres i en bestemt rekkefølge

Dette betyr ikke at passord skal sendes rundt i et dokument eller på e-post. Hemmeligheter bør ligge i en egnet, tilgangsstyrt løsning. Dokumentasjonen skal forklare hva som finnes, hvem som har ansvar, og hvordan en autorisert person får riktig tilgang.

Lisenser må overtas før gammel avtale stopper

Hvis dere bruker Microsoft 365, e-post, sikkerhetsløsninger, backup eller andre abonnementer, må vi vite hva som skal flyttes, hva som skal erstattes og hva som skal avsluttes.

Noen lisenser kan overføres. Andre må bestilles på nytt. Noen har bindingstid eller frister som påvirker antall og kostnad. Dette må avklares før tidligere leverandør slipper taket.

Målet er at ansatte fortsatt har tilgang til e-post, filer og nødvendige systemer når leverandørbyttet skjer.

Fjernstyring og overvåking må byttes i riktig rekkefølge

RMM er systemet en IT-leverandør bruker for å overvåke, fjernstyre og vedlikeholde PC-er og andre enheter.

Når vi overtar, må den gamle leverandørens verktøy fjernes, og avtalte nye systemer må legges inn. Rekkefølgen skal være tydelig. Det bør ikke være to leverandører som kan fjernstyre samme miljø uten en uttrykkelig overgangsavtale. Samtidig bør det ikke oppstå en periode der ingen kan følge opp maskinene.

Før gamle verktøy fjernes, bør den nye leverandøren ha kontrollert at nødvendige enheter er registrert, at varsler kommer fram, og at autorisert fjernhjelp fungerer.

Brannmur, nettverk og administratorroller må sikres

Når ansvaret for nettverk eller sikkerhet flyttes, må den nye leverandøren ha reell og dokumentert kontroll. Det innebærer tilgang til brannmur, nettverksutstyr og nødvendige administratorroller. Gamle tilganger må gjennomgås og fjernes når de ikke lenger er nødvendige.

NSMs grunnprinsipper for IKT-sikkerhet legger vekt på oversikt over systemer, enheter, brukere og tilganger, i tillegg til beskyttelse av konfigurasjoner og sikkerhetskopier. Et leverandørbytte er et naturlig tidspunkt for å kontrollere at denne oversikten faktisk stemmer.

Ansvar følger avtalen

Hvis Trønder Data skal ha ansvar for PC-sikkerhet, backup, nettverk, support, lisenser eller beredskap, må dette være definert i avtalen. Da kan vi sette opp systemene slik at ansvaret kan følges opp i praksis.

Hvis dere bare kjøper én avgrenset tjeneste, overtar vi ikke automatisk alt rundt den. Vi kan fortsatt hjelpe, men det må være tydelig hvem som følger opp det som ligger utenfor leveransen.

Dette er grunnen til at oppstartsmøtet handler om mer enn teknikk. Det skal hindre misforståelser om hvem som passer på hva. Se også hvordan vi beskriver ansvar og innhold på siden om serviceavtaler hos Trønder Data.

Ansatte kjenner de skjulte avhengighetene

Ledelsen vet gjerne når avtalen skal byttes. Ansatte vet ofte hvilke skrivere som skaper problemer, hvilke mapper som brukes hver dag, hvilke programmer som må virke mandag morgen, og hvilke små rutiner som holder arbeidsdagen i gang.

En kort samtale med dem som bruker systemene mest, kan avdekke avhengigheter som ikke finnes i avtalen eller den tekniske dokumentasjonen. Det gir færre overraskelser når overgangen gjennomføres.

Ikke godkjenn overleveringen før resultatet er kontrollert

En mappe med dokumenter er ikke i seg selv bevis på at overleveringen er fullført. Den nye leverandøren bør lese tilbake og kontrollere de viktigste opplysningene før gammel tilgang stenges.

Kontrollen kan blant annet bekrefte at:

  • administratorinnlogginger virker og har riktig omfang
  • domene, DNS og e-post kan administreres av riktig part
  • kritiske enheter og tjenester er med i oversikten
  • backupstatus kan leses og en gjenopprettingsrutine er kjent
  • overvåking og supportkanaler når riktig mottaker
  • gamle fjernstyringsverktøy og unødvendige tilganger er fjernet
  • kunden har fått den oppdaterte dokumentasjonen og vet hvor den ligger

Virksomheter som vil gå bredere gjennom konsekvensene av et avbrudd, kan bruke vår praktiske beredskapsplan for småbedrifter som videre kontroll.

Målet er en rolig overgang

Et godt leverandørbytte skal ikke føles som et stort IT-prosjekt for alle ansatte. Noen vil merke at supportkanalen endres, at et nytt sikkerhetsverktøy kommer på PC-en, eller at passord og tilganger ryddes. Selve arbeidsdagen bør likevel fortsette mest mulig normalt.

Når vi tar over, vil vi vite hva vi overtar, hva vi ikke overtar, hvilke systemer som må virke, og hvilke kontroller som må være bestått før ansvaret faktisk er vårt.

Det er slik dere får et ryddig bytte av IT-leverandør: med en konkret plan, en overleveringspakke kunden selv har tilgang til, og kontroll av at opplysningene virker i praksis.

Kilde

Illustrasjon av to valg: enkel lisens og serviceavtale med ansvar, sikkerhet og support

Serviceavtale eller bare lisens: hva tar Trønder Data ansvar for?

Skrevet av Svein tore den . Publisert i Serviceavtaler. Ingen kommentarer til Serviceavtale eller bare lisens: hva tar Trønder Data ansvar for?

Dere kan kjøpe bare lisenser hos Trønder Data. Det er helt greit for mange bedrifter. Men da er det viktig å forstå forskjellen på å kjøpe en lisens og å ha en avtale der vi faktisk har ansvar for drift, sikkerhet, oppfølging og responstid.

Kortversjonen er enkel: Vi hjelper gjerne også når dere bare har kjøpt lisens, men vi kan ikke ta ansvar for sikkerhet, PC-drift eller beredskap som dere ikke har valgt at vi skal ivareta.

En lisens er ikke det samme som en driftsavtale

En lisens gir dere tilgang til en tjeneste. Det kan være Microsoft 365, Exchange, Nextcloud, backup, sikkerhetsopplæring eller en annen løsning.

En serviceavtale beskriver derimot hva Trønder Data skal ha ansvar for rundt løsningen. Det kan handle om oppsett, sikkerhetsinnstillinger, brukerstyring, backup, dokumentasjon, overvåking, support, responstid og løpende kontroll.

Derfor kan to bedrifter ha samme lisens, men helt ulikt ansvarsbilde.

Den ene bedriften kjøper bare Microsoft 365-lisenser og tar selv ansvar for PC-er, sikkerhet og drift. Den andre har en avtale der vi også følger opp brukere, sikkerhetsoppsett, endepunktsikring, backup og support. Det er to forskjellige leveranser.

Vi kan hjelpe likevel, men ansvar følger avtalen

Hvis dere bare kjøper en lisens av oss og PC-en ikke starter, kan dere fortsatt kontakte oss. Ofte hjelper vi så raskt vi kan. Vi er ikke interessert i å la dere sitte fast hvis vi kan løse problemet.

Men det betyr ikke at PC-drift automatisk var vårt ansvar før feilen oppstod.

Det samme gjelder sikkerhet. Vi kan ta ansvar for PC-sikkerhet, endepunktsikring, backup, tilgangskontroll og dokumentasjon etter at det har oppstått problemer. Avtalen kan oppdateres ved behov. Men dere kan ikke forvente at sikkerheten har vært ivaretatt av oss i perioden før dere valgte den delen av avtalen.

Det er en viktig forskjell.

Vi kan overta ansvar fremover. Vi kan rydde opp. Vi kan dokumentere, sikre og forbedre. Men vi kan ikke være ansvarlige for et område dere tidligere har valgt å håndtere selv.

Når bare lisens kan være riktig

For noen små bedrifter er bare lisens et fornuftig valg.

Hvis dere ikke har vesentlige krav fra myndigheter, kunder eller leverandører, og dere har enkel IT-hverdag, kan det være nok å kjøpe lisenser og betale for litt support utenom ved behov. Det er en ryddig modell, så lenge alle forstår hva den innebærer.

Da kjøper dere tilgang til tjenesten, men ikke full kontroll, beredskap og sikkerhetsansvar.

Dette kan passe hvis:

  • dere har lav risiko
  • dere har få brukere
  • dere gjør mye IT-oppfølging selv
  • dere tåler at support faktureres utenom
  • dere ikke trenger fast responstid på alt
  • dere ikke forventer at Trønder Data overvåker og dokumenterer hele IT-miljøet

Det er ikke feil. Det må bare være bevisst.

Når dere bør ha serviceavtale

Serviceavtale passer bedre når dere ønsker at noen faktisk skal følge med, ta ansvar og hjelpe dere over tid.

Det gjelder særlig hvis bedriften din har krav til personvern, dokumentasjon, oppetid, backup, sikkerhet, tilgangsstyring eller rask respons. Det gjelder også hvis dere ikke har egen IT-kompetanse internt og vil slippe å vurdere hver enkelt IT-beslutning alene.

Med serviceavtale kan vi definere tydelig:

  • hvilke tjenester vi har ansvar for
  • hvilke brukere og enheter som inngår
  • hva som overvåkes
  • hva som dokumenteres
  • hvordan support håndteres
  • hvilken responstid som gjelder
  • hva som trekkes fra timebank
  • hva som faktureres utenom

Da blir det mindre rom for misforståelser når noe skjer.

Les gjerne også forklaringen vår om hva som er inkludert i en serviceavtale.

Sikkerhet må være avtalt før den kan være ivaretatt

IT-sikkerhet handler ikke bare om å installere et produkt.

Det handler om riktig oppsett, riktige tilganger, oppdateringer, backup, rutiner, dokumentasjon, opplæring, logging, beredskap og kontroll over tid. Hvis dere vil at Trønder Data skal stå ansvarlig for dette, må det være en del av avtalen.

Det betyr ikke at alle må kjøpe den største pakken. Men det betyr at ansvarsnivået må henge sammen med behovet og risikoen.

Hvis dere velger bare lisenser, står dere i praksis selv ansvarlig for sikkerheten rundt resten av miljøet. Vi kan bistå ved behov, men da er arbeidet normalt support eller prosjektarbeid, ikke et ansvar vi allerede har hatt løpende.

Dette er også grunnen til at vi er tydelige på administrative tilganger. Hvis ansatte eller eksterne har adminrettigheter, øker risikoen. Da må avtalen også dekke tilgangskontroll, dokumentasjon og oppfølging. Se gjerne artikkelen om hvorfor adminbrukere krever strengere kontroll.

Avtalen kan oppdateres når behovet endrer seg

Behovet deres kan endre seg. Det er normalt.

En bedrift kan starte med bare e-post og sky, og senere oppdage at den trenger bedre backup, PC-sikkerhet, dokumentasjon eller mer fast support. Da kan vi se på avtalen sammen og oppdatere den der det gir mening.

Noen ganger er det enkelt. Andre ganger finnes det bindinger hos underleverandører, lisensvilkår eller praktiske forhold som påvirker når endringen kan gjøres. Men prinsippet er at avtalen skal kunne utvikle seg sammen med behovet.

Det viktigste er at dere ikke venter til etter en hendelse med å avklare ansvar for det som egentlig er kritisk.

Hva skjer hvis det haster?

Hvis dere ringer fordi noe haster, prøver vi å hjelpe. Men prioritet og ansvar følger avtalen.

En bedrift med serviceavtale og definert ansvar for drift, sikkerhet eller beredskap vil normalt prioriteres foran en bedrift som bare har kjøpt en lisens og trenger hjelp med noe utenfor avtalen. Det handler ikke om vilje. Det handler om at vi må levere på det vi faktisk har forpliktet oss til.

Hvis saken ligger utenfor avtalen, kan vi ofte bistå likevel. Da avtaler vi normalt videre arbeid, timebruk og fakturering.

For kritiske saker innenfor avtalen gjelder avtalt responstid. Se også forklaringen vår om responstid og SLA.

Slik bør dere velge

Hvis dere er usikre, bør spørsmålet ikke være “hvilken lisens trenger vi?”, men “hva ønsker vi at Trønder Data skal ha ansvar for?”.

Start med disse spørsmålene:

  • Skal vi bare levere lisensen, eller skal vi også sikre og følge opp miljøet?
  • Skal PC-er og brukere inngå?
  • Skal backup overvåkes og dokumenteres?
  • Skal sikkerhetshendelser håndteres etter fast prosedyre?
  • Skal dere ha timebank til support og småoppgaver?
  • Har dere krav fra kunder, myndigheter, forsikring eller leverandører?
  • Har dere egen IT-kompetanse som faktisk tar ansvar for resten?

Når dette er avklart, blir det lettere å velge riktig avtale. Da slipper dere også overraskelser når noe stopper.

Kort oppsummert

Bare lisens kan være riktig for bedrifter med enkel IT-hverdag og lavere krav. Da betaler dere for tjenesten og kan kjøpe support ved behov, men Trønder Data står ikke automatisk ansvarlig for PC-sikkerhet, drift, backup, dokumentasjon eller beredskap.

Serviceavtale passer når dere vil at vi skal ta ansvar over tid. Da avtaler vi hva som inngår, hva som overvåkes, hvordan support håndteres, og hvor grensen går mellom vårt ansvar og deres eget.

Vi kan alltid se på avtalen på nytt når behovet endrer seg. Det viktigste er at ansvar for sikkerhet og drift avklares før noe går galt, ikke etterpå.

Referanser

  • EDPB: Sikring av personopplysninger
  • Lovdata: Personvernforordningen artikkel 32 om sikkerhet ved behandlingen
IT-tekniker kontrollerer sikkerhetsstatus på PC, mobil og bærbar datamaskin

Endepunktsikring i praksis: Slik kontrollerer dere at beskyttelsen virker

Skrevet av Svein tore den . Publisert i IT-sikkerhet.

Endepunktsikring er mer enn å installere et antivirusprogram. Bedriften må vite hvilke enheter som er beskyttet, om sikkerhetsfunksjonene faktisk er aktive, hvem som følger opp varsler, og hva som skjer når en PC eller mobil viser tegn til kompromittering.

Den praktiske testen er derfor ikke om dere har kjøpt en sikkerhetslisens. Spørsmålet er om dere kan oppdage en ubeskyttet enhet og håndtere et reelt varsel før hendelsen får spre seg.

Hva er et endepunkt?

Et endepunkt er en enhet som kobles til virksomhetens systemer og data. Det kan være en bærbar PC, stasjonær PC, mobiltelefon, nettbrett eller server. Hjemmekontor og reiser gjør at mange av disse enhetene ofte befinner seg utenfor kontornettverket.

Det betyr at brannmuren på kontoret ikke kan være hele sikkerhetsstrategien. Beskyttelsen må følge enheten, også når medarbeideren bruker hjemmenett, mobildata eller et trådløst nett på reise.

Start med å kontrollere dekningen

Første oppgave er å sammenligne enhetslisten med oversikten i sikkerhetsløsningen. En maskin som ikke er registrert, eller som ikke har rapportert status på lenge, kan falle utenfor oppdateringer, varsling og sentral oppfølging.

Lag en enkel kontroll som svarer på disse spørsmålene:

  • Hvilke PC-er, mobiler og servere har tilgang til bedriftens data?
  • Er alle aktive enheter registrert i den sentrale sikkerhetsløsningen?
  • Finnes det gamle enheter som fortsatt har tilgang, men ikke lenger er i bruk?
  • Hvem har ansvar for å følge opp en enhet som slutter å rapportere?

Kontrollen bør inngå når en ny enhet tas i bruk, når en ansatt slutter, og ved jevnlige gjennomganger. En lisens som er kjøpt, men aldri aktivert på enheten, gir ingen reell beskyttelse.

Oppdateringer må kunne følges opp

Operativsystem, nettleser og vanlige programmer må holdes oppdatert. Automatisk oppdatering er et godt utgangspunkt, men bedriften trenger også en måte å oppdage maskiner der oppdateringen har feilet, er utsatt eller krever omstart.

NSMs grunnprinsipper for IKT-sikkerhet anbefaler blant annet oversikt over enheter og programvare, sikker konfigurasjon og håndtering av sårbarheter. Poenget er praktisk: Det som ikke finnes i oversikten, er vanskelig å beskytte og vedlikeholde.

Vanlig bruker bør være normalen

Daglig arbeid bør som hovedregel skje med en vanlig brukerkonto. Lokale administratorrettigheter gjør det enklere å installere programvare og endre sikkerhetsinnstillinger, men de gir også skadevare og misbrukte kontoer større handlingsrom.

Administratorrettigheter bør derfor gis etter behov, være dokumentert og gjennomgås jevnlig. Vi har forklart dette nærmere i artikkelen hvorfor adminbrukere krever strengere kontroll.

Forebygging alene er ikke nok

Moderne endepunktsikring kombinerer flere funksjoner. Den skal forsøke å stoppe skadelig aktivitet, men også registrere hendelser som må undersøkes. Microsoft beskriver for eksempel Defender for Business som en løsning med forebyggende beskyttelse, reduksjon av angrepsflate, endepunktdeteksjon og respons, samt automatisert undersøkelse og utbedring.

Det betyr ikke at alle bedrifter trenger samme produkt eller oppsett. Det viktige er å avklare hvilke funksjoner løsningen faktisk har, hvilke enheter den dekker, og hvem som reagerer når den melder fra.

Et varsel trenger en eier

Et sikkerhetsvarsel som bare blir liggende i en portal eller sendt til en postkasse ingen følger med på, har begrenset verdi. Bedriften bør vite hvem som mottar varselet, hvor raskt det skal vurderes, og hvem som kan isolere enheten eller sperre en konto.

Avklar minst:

  • hvem som overvåker kritiske varsler
  • hva som regnes som kritisk
  • hvordan berørt bruker og ledelse kontaktes
  • når en enhet skal kobles fra eller isoleres
  • hvordan hendelsen dokumenteres og følges opp

Har dere en ekstern IT-leverandør, må avtalen skille mellom selve lisensen og den løpende oppfølgingen. Artikkelen serviceavtale eller bare lisens viser hvorfor dette skillet er viktig.

Test kontrollkjeden, ikke skadevare

En kontroll av endepunktsikringen trenger ikke innebære at noen laster ned reell skadevare. Bruk leverandørens dokumenterte testfunksjon eller en ufarlig testfil når dette støttes, og avtal testen med den som overvåker løsningen.

Testen bør bekrefte hele kjeden:

  1. Enheten er registrert og rapporterer oppdatert status.
  2. En ufarlig testhendelse blir oppdaget.
  3. Varslet kommer fram til riktig mottaker.
  4. Ansvarlig person kan identifisere enheten og brukeren.
  5. Det finnes en kjent prosedyre for isolering, opprydding og gjenoppretting.

Dette ligner prinsippet for sikkerhetskopiering: En grønn status er nyttig, men en kontrollert test viser om prosessen faktisk virker. Se også vår praktiske veiledning om sikkerhetskopiering for småbedrifter.

En enkel kvartalskontroll

For en liten virksomhet kan en kort, dokumentert gjennomgang hvert kvartal være et fornuftig utgangspunkt. Hyppigheten må tilpasses risiko, endringstakt og kravene virksomheten er underlagt.

  • Sammenlign aktive ansatte og enheter med administrasjonsportalen.
  • Finn enheter som ikke har rapportert på forventet tid.
  • Kontroller status for operativsystem og kritiske programmer.
  • Gjennomgå lokale administratorer og unødvendige unntak.
  • Bekreft at varsler går til en bemannet kanal.
  • Utfør en avtalt og ufarlig varslingstest.
  • Dokumenter avvik, ansvarlig person og frist.

Hva bør bedriften sitte igjen med?

God endepunktsikring skal gi en oppdatert oversikt, ensartet konfigurasjon, tydelig varsling og en gjennomførbar respons. Den skal ikke være avhengig av at én medarbeider husker å åpne riktig portal.

Trenger dere hjelp til å få oversikt over enheter, beskyttelse og oppfølging, kan dere lese mer om endepunktsikring hos Trønder Data. Start med å avklare hva som allerede er aktivt, hvilke enheter som mangler, og hvem som har ansvar når et varsel oppstår.

Kilder