Datasikkerhed under Business Central cloud-migration

Når Business Central flytter fra jeres egen server til BC online, overtager Microsoft en stor del af sikkerhedsarbejdet: servere, patches, kryptering af databasen og backup. Men ikke det hele. Hvem der må se lønkonti, hvem der kan rette bankoplysninger på en kreditor, og hvordan data kommer sikkert fra det gamle system til det nye — det er stadig jeres ansvar.

Her er det, vi gennemgår med kunderne, før vi flytter dem fra C5, NAV eller on-prem BC.

Forstå sikkerhedslandskabet

En cloud-migration har fem sikkerhedsflader. De to første klarer Microsoft langt hen ad vejen. De sidste tre er jeres:

• Data under overførsel: Microsofts migreringsværktøj flytter data krypteret. Ved filbaseret migrering, fx fra C5, er det eksportfilen på nogens skrivebord, der er risikoen
• Lagrede data: BC online krypterer databasen og tager backup. Det skal I ikke selv sætte op
• Adgangskontrol: Brugere og rettigheder flyttes ikke med i cloud-migreringen. Det er en opgave — og en god anledning til at rydde op
• Compliance: GDPR, bogføringsloven og revisors krav gælder stadig, uanset hvor serveren står
• Overgangsperioden: To systemer kører parallelt, og data ligger i testmiljøer og eksportfiler

Vigtige sikkerhedsforanstaltninger

1. Kortlæg, før I flytter

Start med at vide, hvad I har. I et NAV-system, der har kørt i 15 år, ligger der typisk mere, end nogen husker:

• Hvilke tabeller indeholder persondata — debitorer, kontakter, medarbejdere, og måske CPR-numre i egne felter
• Hvem har SUPER i dag, og hvorfor
• Integrationer med gemte brugernavne og adgangskoder: FTP, webservices, NAS-jobs
• Egne tabeller og felter i tilpasningerne, der skal med — eller bevidst efterlades

En grundig sikkerhedsvurdering før migrationen reducerer risikoen for uventede sikkerhedsproblemer med op til 70% under migrationsprocessen.

2. Sikker dataoverførsel

Selve flytningen er sjældent problemet, hvis I bruger Microsofts værktøjer. Det er alt det rundt om:

• Fra on-prem BC: brug Cloud Migration-værktøjet. Data går krypteret via en self-hosted integration runtime, ikke via filer
• Fra C5 og ældre NAV: hold eksportfiler et kontrolleret sted, og slet dem efter go-live
• Del ikke en sandbox med produktionsdata med eksterne uden at anonymisere persondata
• Afstem efter overførslen: balance, åbne poster og lagerværdi pr. skæringsdato

3. Adgangskontrol fra bunden

BC online logger ind via Microsoft Entra ID. Det giver værktøjer, I ikke havde på jeres egen server:

• Kræv MFA for alle brugere — også bogholderen, der kun logger ind fra kontoret
• Tildel rettigheder via sikkerhedsgrupper i Entra ID i stedet for bruger for bruger
• Byg egne tilladelsessæt ud fra Microsofts standardsæt i stedet for at give SUPER
• Adskil, hvem der opretter kreditorer og bankkonti, fra hvem der godkender betalinger
• Giv partneren adgang via GDAP med tidsbegrænsning — det gælder også os

4. Kryptering og data, der forlader BC

I BC online er databasen krypteret, og al trafik går over TLS. Det er Microsofts ansvar. Jeres del handler om de data, der forlader systemet:

• Integrationer logger ind med OAuth via en app-registrering i Entra ID — ikke med en brugers adgangskode
• Hemmeligheder i egne apps hører hjemme i Isolated Storage eller Azure Key Vault, ikke i en opsætningstabel
• Betalinger går via en direkte bankintegration som Continia Banking frem for betalingsfiler i en delt mappe
• Excel-udtræk med persondata sendes ikke rundt på mail

5. Overvågning efter go-live

Sikkerhed stopper ikke ved go-live:

• Slå ændringsloggen til på de felter, der betyder noget: bankkonti på kreditorer, betalingsbetingelser, kreditmaksimum
• Send telemetri til Application Insights, så fejlede integrationer og usædvanlig aktivitet bliver synlig
• Hold øje med login-loggen i Entra ID
• Gennemgå brugere og rettigheder hvert kvartal — fratrådte medarbejdere bliver hængende oftere, end man tror

Håndtering af compliance-krav

Microsoft har certificeringerne. Det er stadig jer, der skal bruge systemet, så det lever op til kravene:

• GDPR: Kend jeres persondata i BC, klassificér felterne, og brug opbevaringspolitikker til at slette det, I ikke må gemme
• Bogføringsloven: Regnskabsmateriale skal opbevares i fem år. Beslut, hvad der sker med historikken fra det gamle system
• ISO 27001 og branchekrav: Er I selv certificeret, skal BC-rettigheder og leverandøraftaler passe ind i jeres ISMS

Microsoft leverer det sikre fundament. Opsætningen er jeres — eller jeres partners.

Risikostyring under migration

Det meste, der går galt, går galt i overgangen:

• Lav en kort risikoliste: Hvad gør vi, hvis bankintegrationen ikke virker mandag morgen?
• Test i sandbox med brugernes rigtige rettigheder — ikke kun som SUPER, ellers finder brugerne fejlene på dag ét
• Hav en tilbagerulningsplan: Hvornår beslutter vi at fortsætte i det gamle system?
• Luk det gamle system for bogføring, men behold læseadgang, til første momsafregning er afstemt

Sikkerhed efter migration — bedste praksis

Når I er i drift, handler det om faste rutiner:

• Kvartalsvis gennemgang af brugere, licenser og tilladelsessæt
• Microsoft opdaterer BC online, men egne apps og tredjepartsapps skal følge med — test i sandbox før de store udgivelser i april og oktober
• Lær brugerne at genkende phishing og falske ændringer af bankoplysninger fra "leverandører"
• En plan for hændelser: Hvem ringer I til, og hvem kan lukke en kompromitteret konto
• Microsoft kan gendanne miljøet til et tidligere tidspunkt. Kræver jeres politik mere, så lav egne eksporter af kritiske data

Konklusion

En flytning til BC online gør de fleste virksomheder mere sikre, ikke mindre: ingen server i kælderen, ingen glemte patches og MFA på alle logins. Men gevinsten kommer kun, hvis rettigheder, integrationer og selve overgangen bliver håndteret ordentligt.

Det er et delt ansvar. Microsoft sikrer platformen. Hvem der må hvad, og hvordan data kommer ind og ud af systemet, er jeres. Den del hjælper vi gerne med.