Det tager kun én “lille” ændring i Business Central at skabe en stor forretningsrisiko: et nyt felt i en tabel, en hurtigt skrevet API-integration eller en rettelse, der går direkte i produktion fredag eftermiddag.
I denne artikel får du et praktisk overblik over, hvorfor sikker udvikling i Business Central og lignende ERP-miljøer bør være styret af klare kontroller og processer — ikke mavefornemmelser og helteindsats. Du får konkrete eksempler fra ERP-hverdagen, typiske faldgruber og en række kontroller, du kan implementere uden at kvæle tempoet.
Du får også svar på de spørgsmål, jeg oftest møder: Hvad er “sikker udvikling” i ERP-kontekst? Hvorfor er det vigtigt? Hvordan gør man i praksis? Hvad koster det? Og hvilke fejl ser man igen og igen — især i Business Central/AL-udvikling og integrationer?
Hvad betyder “sikker udvikling” i et ERP-miljø?
En kort definition: Sikker udvikling i ERP handler om at designe, bygge, teste og udrulle ændringer, så fortrolighed, integritet og tilgængelighed bevares — også når systemet ændrer sig. I praksis betyder det kontroller for kode, dataadgang, ændringsstyring, test, logning og godkendelser.
Hvorfor betyder det noget? Fordi ERP-systemet typisk er “system of record” for økonomi, lager, kunder, priser, rabatter, betalingsbetingelser og ofte også persondata. En fejl i et ERP-system kan derfor være mere alvorlig end en fejl i en isoleret webapp: den kan ændre regnskabsgrundlag, skabe svindelmuligheder eller stoppe driften.
Mini-konklusion: Sikkerhed i ERP er ikke et ekstra lag ovenpå — det er et sæt arbejdsgange, der sikrer, at ændringer ikke skaber nye svagheder.
Hvorfor kontroller og processer er vigtigere i ERP end mange tror
Jeg ser ofte, at teams undervurderer ERP-ændringer, fordi de “bare” er interne. Men i moderne ERP er integrationsfladen ofte større end brugerfladen: API’er, EDI, Power Platform, datalakes, rapportering og tredjepartsapps. Hver ny forbindelse udvider angrebsfladen.
Klare processer er ikke bureaukrati for bureaukratiets skyld. De fungerer som “sikkerhedsseler”: De forhindrer, at enkeltpersoner (eller tidspres) kan omgå nødvendige checks.
ERP-data er højværdi — også for interne trusler
En klassiker: en udvikler eller konsulent får brede rettigheder “midlertidigt” for at løse en opgave. Tre måneder senere er rettighederne stadig åbne, og ændringer kan foretages uden sporbarhed. I ERP er adgange ofte binære: enten kan du se/postere, eller også kan du ikke. Derfor gør små lempelser stor skade.
Ændringer kan have regnskabs- og compliance-effekt
Et eksempel fra praksis: En “uskyldig” automatisering af bogføringsdatoer kan medføre, at posteringer ryger i forkert periode. Det er ikke bare en bug — det kan blive en revisionsfinding. Tilsvarende kan ændringer i godkendelsesflows, rabatlogik eller kreditlimit skabe direkte tab.
Mini-konklusion: I ERP er konsekvensen af fejl ofte forretningskritisk, og derfor skal ændringer styres som kontrollerede risici.
De mest almindelige faldgruber i Business Central-udvikling (og hvordan du undgår dem)
Business Central og AL-udvikling har deres egne “klassiske” sikkerhedsfælder. Mange handler ikke om avanceret hacking, men om manglende styring og uklare roller.
- Direkte ændringer i produktion (hotfix uden spor): Undgå ved at kræve pull requests, release-godkendelse og emergency-procedure med efterfølgende review.
- Overprivilegerede servicekonti til integrationer: Giv mindst mulige rettigheder, adskil læse/skriv, og roter credentials.
- Manglende miljøadskillelse (dev/test/prod flyder sammen): Etablér separate miljøer og dataset-strategi (maskering eller anonymisering).
- Utestede permission sets: Test roller som “lavest privilegeret bruger” og brug negative tests (hvad må de ikke?).
- For svag logning og sporbarhed: Aktivér relevant audit/logning, og sørg for at hændelser kan knyttes til person/systemkonto.
- Skjulte afhængigheder i extensions: Hold styr på versioner, dependencies og breaking changes via release notes og automatiske checks.
En praktisk tommelfingerregel: Hvis du ikke kan svare hurtigt på “hvem ændrede hvad, hvornår, og hvorfor”, så mangler du en kontrol.
Mini-konklusion: De største ERP-sikkerhedsproblemer kommer ofte fra procesbrud — ikke fra exotiske zero-days.
Fra “best effort” til styret Secure SDLC: Kontroller der virker i praksis
“Secure SDLC” lyder tungt, men i ERP-kontekst kan det implementeres som en række få, konsekvente gates: krav → design → udvikling → test → release → drift. Pointen er, at sikkerhedskrav og kvalitet ikke er valgfrit fra sprint til sprint.
Hvis du vil have en ramme målrettet netop ERP og Business Central, kan du dykke ned i Secure SDLC i Business Central som inspiration til, hvordan krav og kontroller kan mappes til en praktisk udviklingsmodel.
Minimumskontroller (startpakke) som de fleste kan implementere
- Ændringsstyring: Alle ændringer har ticket/krav, risikovurdering og acceptkriterier.
- Code review: Ingen merge uden review fra en anden end forfatteren (to-personers princip).
- Automatiseret build og baseline-tests: CI, der blokerer ved fejl og manglende standardchecks.
- Release-godkendelse: Formelt go/no-go, inkl. plan for rollback.
- Adskilte miljøer: Dev/test/prod + klare dataregler.
- Logging og overvågning: Definér hændelser, alarmer og ansvar for opfølgning.
Sådan undgår du at processen bliver en flaskehals
Den største misforståelse er, at flere kontroller altid betyder langsommere levering. I praksis skaber forudsigelighed fart: Når teamet ved præcis, hvad der kræves for at få en ændring ud, reduceres frem-og-tilbage og “brandøvelser”. Automatisér alt det gentagne (build, tests, linting, deploy), og hold de manuelle kontroller på det, der kræver faglig vurdering (risiko, godkendelse, review).
Mini-konklusion: En styret SDLC handler ikke om at gøre alt tungt — men om at gøre det ens hver gang.
Kontroller i AL/Business Central: Hvad skal du konkret kigge efter?
I Business Central er der en række tekniske og funktionelle områder, hvor kontroller typisk giver høj sikkerhedseffekt pr. investeret time. Her er de steder, jeg vil starte i de fleste miljøer.
Rettigheder, roller og “least privilege”
Permission sets er din første forsvarslinje, men de bliver ofte “udjævnet” over tid: flere og flere får samme brede rolle, fordi det er nemmest. Indfør en praksis hvor nye rettigheder kræver begrundelse, og hvor roller gennemgås kvartalsvist for de mest følsomme områder (betalinger, kreditnotaer, leverandørbankkonti, pris-/rabatstyring).
Tip: Test kritiske processer med en “minimalt privilegeret” testbruger. Det afslører hurtigt, om jeres roller er designet eller bare vokset tilfældigt.
Integrationer og API’er: Den stille risikofaktor
Mange ERP-hændelser starter ikke i UI, men i integrationen: en servicekonto der kan oprette leverandører, ændre bankoplysninger eller poste kladder. Kontrollér især:
- Hvilke endpoints og operationer servicekonti må bruge
- Om kald logges med korrelations-id og payload-referencer (ikke nødvendigvis fuld payload)
- Rate limiting og fejlhåndtering (så fejl ikke skaber dubletter)
- Adskillelse mellem test- og produktionsnøgler
Mini-konklusion: Hvis integrationer ikke er styret, kan de omgå jeres manuelle kontroller og godkendelser.
Test og kvalitetssikring: Hvad er “god nok” sikkerhedstest i ERP?
Et typisk spørgsmål er: “Hvordan tester vi sikkerhed uden at lave et helt sikkerhedsteam?” Svaret er at kombinere tre niveauer: automatiske checks, målrettede manuelle tests og periodiske dybere gennemgange.
For ERP er det sjældent realistisk at “penteste” hver sprint. Til gengæld kan man opnå meget med konsekvente regressionstests på kritiske flows og simple sikkerhedstests, der gentages ved hver release.
Praktiske tests, der ofte finder rigtige fejl
- Negative tests på godkendelsesflows: Kan man poste uden godkendelse via alternativ vej?
- Rettighedstests: Kan en bruger uden rolle X stadig læse/ændre data via side, rapport eller API?
- Datavalidering: Kan integrationen skrive ugyldige værdier (fx momsgrupper, dimensionskoder) uden at fejle?
- Transaktions- og dubletkontrol: Hvad sker der ved timeouts og retries?
Bedste praksis: Gør tests til en release-gate
Et konkret greb er at definere en “kritisk testpakke” (fx 20–50 tests) som altid skal være grøn før release. Den pakke bør dække de 5–10 vigtigste forretningsprocesser: indkøb, salg, postering, betaling, lagerregulering, masterdataændringer. Når den pakke fejler, er det et stop-signal.
Mini-konklusion: “God nok” sikkerhedstest i ERP er gentagelig, fokuseret og koblet direkte til release-beslutningen.
Hvad koster det at indføre kontroller — og hvad koster det at lade være?
Omkostningen afhænger af modenhed. Hvis I i dag kører med manuelle deploys, uklare rettigheder og sporadiske tests, vil de første forbedringer give stor effekt hurtigt. Mange bliver overraskede over, at en stor del af arbejdet handler om afklaring og standardisering, ikke dyre værktøjer.
Som grov sammenligning fra projekter jeg har været tæt på: At etablere en basismodel med miljøadskillelse, simple CI-checks, PR-review og release-godkendelse kan ofte gøres på få uger, hvis der er ejerskab og adgang til de rigtige kompetencer. Den løbende “driftsudgift” ligger typisk i disciplinen: review-tid, vedligehold af tests og kvartalsvise adgangsgennemgange.
Hvad koster det at lade være? Det viser sig ofte som:
- Flere incidents og dyrere fejlretning (fordi fejl opdages sent)
- Uforudsigelige releases og nedetid
- Revisionsbemærkninger og compliance-arbejde “baglæns”
- Tab ved svindel eller fejlagtige udbetalinger
Mini-konklusion: Kontroller koster tid; manglende kontroller koster typisk tid plus krisehåndtering — og ofte med højere forretningsrisiko.
Sådan kommer du i gang: En realistisk 30-60-90 dages plan
Hvis du sidder med ansvaret for Business Central (IT, finance systems, ERP lead, product owner eller sikkerhedsansvarlig), er den bedste start at vælge få kontroller og gøre dem urokkelige. Her er en plan, der kan gennemføres uden at “genopfinde” alt på én gang.
0–30 dage: Skab overblik og stop de værste lækager
- Dokumentér miljøer, integrationskonti og hvem der kan deploye
- Indfør obligatorisk ticket-id på ændringer og en enkel release-log
- Luk for direkte ændringer i produktion (eller indfør emergency-procedure)
- Identificér 5 mest kritiske roller og gennemgå rettigheder
30–60 dage: Gør kvalitet målelig
- Indfør PR-review som standard og definér review-checkliste (fx rettigheder, logning, fejlscenarier)
- Byg en kritisk testpakke og gør den til release-gate
- Etabler minimum logging/monitorering for integrationer og kritiske transaktioner
60–90 dage: Modenhed og gentagelighed
- Formaliser risikovurdering pr. ændring (lav/medium/høj) med passende krav
- Planlæg kvartalsvis access review og halvårlig gennemgang af integrationer
- Træn teamet i de top-10 fejlmønstre, I faktisk ser (ikke generiske slides)
Vigtig pointe: Start med det, der reducerer risiko mest pr. indsats: adgangsstyring, ændringssporbarhed og release-disciplin. Resten kan bygges ovenpå.
Mini-konklusion: Du behøver ikke en perfekt model fra dag 1 — du behøver en model, der bliver fulgt konsekvent.
De fejl, der typisk får selv gode initiativer til at fejle
Selv stærke teams kan falde i fælder, når de indfører kontroller. Her er dem, jeg ser oftest — og den praktiske modgift.
- Kontroller uden ejerskab: Hvis ingen “ejer” release-processen, bliver den omgået. Løsning: tydelige roller (release manager, systemejer, sikkerhedsansvarlig).
- For mange regler på én gang: Teamet mister overblik og finder smutveje. Løsning: indfør 3–5 ufravigelige gates først.
- Manuelle checks, der burde være automatiske: Det skaber træthed og fejl. Løsning: automatisér standardkontroller i CI/CD.
- Manglende læringsloop: Incidents gentager sig. Løsning: post-mortems med konkrete ændringer i processer og tests.
Det vigtigste tegn på modenhed er ikke, at I aldrig laver fejl — men at den samme type fejl ikke overlever mere end én eller to releases.
Mini-konklusion: Kontroller virker kun, hvis de er få nok til at blive fulgt, og skarpe nok til at gøre en forskel.
