Hvis en enkelt stjålet adgangskode kan åbne døren til hele jeres virksomhed, er fjernadgang ikke bare et IT-emne — det er et forretningskritisk risikospørgsmål.
I denne artikel får du en praktisk og sikker måde at tænke fjernadgang på: hvem skal have adgang til hvad, hvordan du bruger princippet om mindst mulige rettigheder, hvorfor MFA og logning er fundamentet, og hvordan netværksadskillelse begrænser skaden, når (ikke hvis) noget går galt. Du får også en enkel proces, du kan bruge til at designe adgange fra bunden: roller → ressourcer → adgang → kontrol.
Du kan bruge indholdet som tjekliste til en eksisterende løsning eller som blueprint, hvis du skal standardisere fjernarbejde, eksterne leverandører eller supportadgang.
Hvad er sikker fjernadgang — og hvorfor betyder det så meget?
Sikker fjernadgang er en kontrolleret måde at give brugere adgang til virksomhedens systemer og data fra et andet netværk (hjemme, på farten eller hos en leverandør) med tydelig identitet, mindst mulige rettigheder, kryptering og sporbarhed. Det betyder noget, fordi fjernadgang ofte bliver genvejen ind i miljøet: den forbinder “udenfor” med “indenfor”, og den bliver derfor et yndet mål for phishing, credential stuffing og misbrug af for brede rettigheder.
Fra praksis ser jeg typisk to scenarier: Enten er fjernadgang sat op “for at få det til at virke” (hurtigt), eller også er den designet som et kontrolleret adgangslag, hvor man forventer fejl og derfor begrænser konsekvensen. Forskellen kan måles i både driftsstop og oprydningstid: Når adgang er for bred og uden logning, kan en hændelse udvikle sig i dage; når adgang er snæver og sporbar, kan den ofte isoleres på timer.
Mini-konklusion: Sikker fjernadgang handler ikke om én teknologi, men om at styre identitet, rettigheder og kontrolpunkter, så kompromittering bliver dyrt for angriberen og håndterbart for jer.
Hvem skal have adgang til hvad? Start med roller og forretningsbehov
Det første spørgsmål er ikke “skal vi have VPN?”, men “hvilke opgaver skal løses udefra — og af hvem?”. Når man starter i roller og opgaver, undgår man at give generel netværksadgang, hvor brugeren selv kan “finde rundt” til det nødvendige. Den tilgang skaber utilsigtet eksponering.
Typiske roller og deres behov
Her er et realistisk udgangspunkt, som du kan tilpasse. Pointen er at omsætte jobfunktion til konkrete ressourcer og protokoller:
- Kontormedarbejder: mail, CRM/ERP, filadgang til afgrænsede mapper, intranet.
- Udvikler/IT: adgang til administrationsværktøjer, kode-repos, CI/CD, testmiljøer; sjældent direkte til produktion.
- Support/Helpdesk: fjernstyring af klienter via godkendte værktøjer, adgang til logs og ticket-system, begrænset admin.
- Ekstern leverandør: adgang til ét system eller én management-konsol, tidsbegrænset, ofte kun fra kendte IP’er.
- Ledelse: adgang til rapportering, økonomisystem og dokumenter; ikke til administrative netværk.
Oversæt behov til “ressource-sæt”
En fejl, jeg ofte ser, er at man giver adgang til “netværket” i stedet for til “ressourcen”. Prøv i stedet at definere ressource-sæt: “ERP-web”, “Filserver-projektX”, “RDP til jump host”, “Admin til firewall”. Det gør det muligt at styre adgang præcist og at dokumentere, hvorfor adgangen findes.
Mini-konklusion: Når du beskriver adgang som roller → ressourcer, bliver resten (rettigheder, MFA, logning) langt lettere at implementere konsekvent.
Princippet om mindst mulige rettigheder (Least Privilege) i praksis
Least Privilege betyder, at brugeren kun får de rettigheder, der er nødvendige for opgaven — og kun så længe opgaven kræver det. Det lyder enkelt, men praksis kræver disciplin, fordi “midlertidige” undtagelser har det med at blive permanente.
Sådan undgår du “alt-eller-intet”-adgang
Tre greb virker næsten altid:
- Giv adgang til applikationer frem for hele subnets (fx via reverse proxy, app gateways eller ZTNA-lignende adgang).
- Brug separate administrative konti til admin-opgaver, og almindelige konti til daglig brug.
- Indfør tidsbegrænset forhøjelse af rettigheder (Just-in-Time), så admin-adgang udløber automatisk.
Måder mindst mulige rettigheder ofte går galt
De klassiske faldgruber er: delte konti (“support/support”), brede AD-grupper (“VPN_Users” med adgang til alt), og “nødadgang” som ingen ejer. Undgå dem ved at kræve navngivne konti, dokumenteret formål og en fast owner pr. adgangsgruppe.
Mini-konklusion: Least Privilege er ikke et projekt, men en driftstandard: nye adgange skal være små, udløbe når de kan, og kunne forklares på én linje.
MFA: det vigtigste kontrolpunkt ved fjernadgang
MFA (Multi-Factor Authentication) er i praksis den mest effektive barriere mod misbrug af stjålne credentials ved fjernadgang. En adgangskode alene er ofte kompromitteret via phishing eller password reuse. MFA tilføjer en ekstra faktor (typisk app-bekræftelse eller hardware key), så en lækket kode sjældent er nok.
Hvilken MFA giver mening?
Mit erfaringsbaserede hierarki, når man kigger på modstandsdygtighed mod phishing, er typisk:
- Hardware security keys (FIDO2/WebAuthn) til admin og højrisiko-roller.
- Authenticator-app med nummer-match/push, hvor det er muligt.
- TOTP-koder (engangskoder) som minimum.
- SMS som sidste udvej, fordi det kan omgås via SIM-swap og viderestilling.
MFA uden blindgyder
To ting bliver ofte overset: kontogendannelse og nødprocedure. Hvis en medarbejder mister sin telefon, skal processen være sikker, men ikke så tung, at folk omgår den. Brug fx kontrolleret identitetsvalidering via IT, registrer backup-metoder, og log alle MFA-reset. Overvej også separate krav: strengere MFA for admin, mildere for lavrisiko-apps.
Mini-konklusion: MFA er ikke “nice to have” ved fjernadgang; det er basis, især for admin-adgang og leverandører.
Logning og sporbarhed: hvis du ikke kan se det, kan du ikke styre det
Logning er din mulighed for at opdage misbrug og dokumentere, hvad der skete. Ved fjernadgang bør du som minimum kunne svare på: Hvem loggede ind? Hvornår? Fra hvor? Til hvilken ressource? Og hvad blev der gjort bagefter?
Minimumslogning, der faktisk hjælper
- Autentificeringslogs: succes/fejl, MFA-status, IP/geografi, enhedstype.
- Adgangslogs: hvilke systemer/portaler/jump hosts der blev tilgået.
- Admin-aktiviteter: ændringer i grupper, politikker, firewall-regler, brugere.
- Session-data: varighed, samtidige sessioner, afbrudte forbindelser.
Et praktisk tip: Sørg for tids-synkronisering (NTP) på alle relevante systemer. Uden ens tidspunkter bliver incident-håndtering hurtigt gætteri.
Hvad med GDPR og opbevaring?
Logning skal være proportionel og have et formål (sikkerhed og drift). Definér derfor retention: Mange organisationer vælger 90–180 dage til “standardlogs” og længere til kritiske admin-logs, afhængigt af risiko og compliance. Husk at begrænse, hvem der kan se logs, og at log-adgang også skal logges.
Mini-konklusion: God logning er ikke “mere data”, men de rigtige hændelser, samlet ét sted, så I kan reagere hurtigt og sikkert.
Adskillelse af netværk: begræns skaden, når noget kompromitteres
Netværksadskillelse (segmentering) handler om at forhindre lateral bevægelse: at en angriber, der får fodfæste ét sted, kan hoppe videre til alt andet. Ved fjernadgang er segmentering især vigtig, fordi fjernforbindelsen ellers kan blive en direkte bro ind i hele infrastrukturen.
Praktiske niveauer af segmentering
Du behøver ikke starte med et komplekst “zero trust”-projekt for at få effekt. Her er tre niveauer, som ofte giver hurtig risikoreduktion:
- Separér bruger-netværk fra server-netværk (VLAN/subnets + firewall-regler).
- Lav et særskilt admin-netværk og en jump host til RDP/SSH, i stedet for direkte adgang.
- Isolér kritiske systemer (økonomi, produktion, OT/IoT) bag ekstra kontrolpunkter.
VPN, gateway eller applikationsadgang?
Der findes flere veje til fjernadgang, og valget afhænger af risikoprofil og drift. Klassisk VPN giver netværksadgang, mens applikationsgateways og ZTNA-lignende løsninger kan give mere snæver adgang til udvalgte apps. Hvis du vurderer VPN som den rigtige del af din løsning, kan du orientere dig i mulighederne for VPN til erhverv som et sted at starte din research og sammenligne udstyr og funktioner.
Mini-konklusion: Segmentering er den mest oversete “forsikring”: Den gør, at fejl i adgangsstyring ikke automatisk bliver til fuld kompromittering.
Design en sikker adgang: roller → ressourcer → adgang → kontrol (en enkel proces)
Her er en enkel proces, jeg bruger som redaktionel og teknisk ramme, når fjernadgang skal designes eller ryddes op. Den virker, fordi den tvinger jer til at dokumentere beslutninger og bygge kontroller ind fra start.
- Roller: List roller, inklusive eksterne leverandører. Angiv risikoniveau (lav/medium/høj) og om rollen kræver admin.
- Ressourcer: Opdel i systemer og data-sæt. For hver ressource: ejer, kritikalitet, og “hvad er den korrekte adgangsvej?”
- Adgang: Vælg metode (VPN, app gateway, jump host), definér protokoller/porte, og opret grupper. Brug default deny hvor muligt.
- Kontrol: Sæt MFA-krav, logging, alarmer, og review-frekvens. Definér break-glass og hvordan det bruges.
- Test: Validér med en “lavprivilegeret” bruger. Kan man tilgå mere end nødvendigt? Kan man bevæge sig sideværts?
- Drift: Sæt en proces for onboarding/offboarding, samt kvartalsvis adgangsreview for højrisiko-roller.
En hurtig tommelfingerregel: Hvis en rolle ikke kan beskrives i én sætning (“Support kan kun fjernstyre klienter og se logs”), er adgangen ofte for kompleks eller for bred.
Mini-konklusion: Processen gør adgang til et designvalg, ikke en ad hoc-undtagelse — og den skaber dokumentation, som både sikkerhed og drift kan leve med.
Hvad koster sikker fjernadgang, og hvor får du mest effekt for pengene?
Omkostningen afhænger af størrelse, kompleksitet og om I allerede har identitetsplatform, firewall og log-platform. Men du kan tænke i tre lag: (1) identitet/MFA, (2) adgangsvej (VPN/gateway/jump host), (3) logning/overvågning. For mange SMV’er er den største udgift ikke licenser, men tid til design, oprydning i grupper og dokumentation.
Hvis du skal prioritere, giver følgende ofte mest risikoreduktion pr. krone:
- MFA overalt, især for admin og eksterne parter.
- Fjern delte konti og indfør navngivne brugere.
- Segmentér mindst bruger- og servernet samt lav en jump host til admin.
- Saml logs ét sted og lav alarmer på anomali (fx mange login-fejl, login fra nye lande, privilegieændringer).
Til gengæld er “dyrt men uden effekt” ofte kendetegnet ved komplekse regler uden ejer, eller et SIEM-setup uden bemanding til at reagere.
Mini-konklusion: Den bedste investering er sjældent den mest avancerede teknologi, men de kontroller, I faktisk kan drive: MFA, segmentering, oprydning i rettigheder og brugbar logning.
Typiske fejl og bedste praksis (så du undgår de klassiske huller)
Selv velmenende fjernadgang ender ofte med “sikkerhedsgæld”. Her er de fejl, jeg oftest støder på — og hvordan du lukker dem:
Faldgruber, der skaber unødvendig risiko
- For brede VPN-profiler med adgang til hele interne netværk.
- Manglende offboarding: brugere og leverandører beholder adgang efter endt behov.
- Ingen separation mellem bruger- og admin-konti.
- MFA kun på “nogle” systemer, eller undtagelser uden tidsbegrænsning.
- Logning findes, men ingen ser på den, og der er ingen alarmer.
Bedste praksis, der holder i drift
- Gør adgang til en del af onboarding: rolle vælges, ressourcer mappes, og adgangen dokumenteres.
- Indfør faste review-cyklusser: højrisiko hver 30–90 dage, øvrige mindst kvartalsvis eller halvårligt.
- Brug break-glass-konti med stærk beskyttelse, begrænset brug og ekstra logning.
- Test regelmæssigt: “Kan en standardbruger nå admin-nettet?” og “kan en leverandør nå andet end sit system?”
Mini-konklusion: De største huller skyldes sjældent sofistikerede angreb — men ukontrollerede undtagelser og manglende driftprocesser.
