Browserbaseret fjernadgang til servere med Syteca PAM i stedet for VPN: En ekstern leverandør har akut brug for adminadgang. Skal vi virkelig først pakke en VPN-klient, gennemføre onboarding, åbne firewall-regler og håbe på, at intet går galt? Det kan gøres smartere. Med PAM-modulet fra Syteca sker den privilegerede adgang til RDP, SSH, databaser og web-konsoller direkte i browseren, uden fat client, uden VPN-klient og uden direkte netværkskobling mellem slutenheden og det interne net. Dette indlæg placerer tilgangen i en Zero Trust-ramme, viser DMZ- og HAProxy-arkitekturer og forklarer, hvorfor modellen både er sikrere og driftsmæssigt slankere end klassisk VPN. Desuden reducerer browserbaseret fjernadgang eksponeringen markant i den daglige drift.
📑 Indholdsoversigt
Introduktion og mål · Udfordringen: VPN-risici og driftsbyrde · Kilder · Konklusion og handlingsfelter
Introduktion og mål: browserbaseret fjernadgang med Syteca PAM i stedet for VPN
Privilegerede adgange er følsomme, fordi de kan ændre systemer, data og sikkerhedsparametre. Klassiske VPN-modeller kobler desuden slutenheden bredt til det interne net og flytter derved en del af forsvarsbyrden over på klientsiden. NIST anbefaler, at arkitekturer for fjernadgang modelleres bevidst, og at portal- og webadgang klart adskilles fra netdækkende tunneller. NIST SP 800-46 Rev. 2 beskriver desuden, hvordan portal- og terminalserveradgang kan sikres, især i konteksten af telearbejde og BYOD med højere eksponering og tilsvarende beskyttelsesbehov (NIST SP 800-46, SP 800-46 Rev. 2). Netop her sætter Syteca PAM ind: Adgangen sker på applikationsniveau over HTTPS og ikke på netværksniveau via en VPN-tunnel, hvilket styrker browserbaseret fjernadgang.
Adminadgang direkte i browseren, uden VPN-klient og uden lokale agenter på slutenheden.
Udfordringen forstået: hvorfor klassisk VPN bliver en risiko ved privilegeret browserbaseret fjernadgang
En VPN-tunnel forbinder slutenheden netværksmæssigt med virksomhedsnettet og åbner derved angrebsveje: lateral movement inden for subnet, credential harvesting langs tunnelen samt en vanskelig adskillelse mellem privilegeret og regulær adgang. Dertil kommer risici ved split tunneling, høj byrde ved klientforvaltning og udfordringerne omkring BYOD og eksterne leverandører. NIST positionerer derfor portal- og webadgang som et mere kontrollerbart alternativ og understreger, at teknologier til fjernadgang er udsat for øget trusselsniveau og derfor kræver stærk autentisering samt en minimeret angrebsflade (SP 800-46 Rev. 2). For privilegerede sessioner er mindst mulige rettigheder afgørende, og NIST-kontrolmålet AC-6 adresserer netop den konsekvente begrænsning af administrative privilegier (NIST SP 800-53 AC-6). Browserbaseret fjernadgang understøtter i praksis denne skarpe afgrænsning.
Browserbaseret adgang med Syteca PAM: funktion og sikkerhedsanker
Syteca PAM stiller en HTTPS-portal til rådighed, hvorfra administratorer og eksterne leverandører kan starte RDP-, SSH- eller webkonsol-sessioner, uden at slutenheden opretter en direkte netværksforbindelse til målsystemet. Gatewayen formidler protokollerne, terminerer TLS, verificerer identitet og kontekst, håndhæver just-in-time-godkendelser og varetager desuden sessionoptagelse samt revisionssikre audit-logs. Credential vaulting sikrer, at administratorer ikke kender måladgangskoderne. Autentisering og autorisation gennemføres, før selve ressourcesessionen etableres, helt i tråd med princippet never trust, always verify. NIST anbefaler netop at orientere fjernadgang mod ressourcer frem for netsegmenter og at gennemføre autorisation før sessionen (NIST SP 800-46). Denne arkitektur styrker browserbaseret fjernadgang uden at øge netværkseksponeringen.
Zero Trust-ramme og politikker
Browserbaseret PAM er i praksis et ZTNA-mønster: adgang på applikationsniveau, identitets- og kontekstbaseret, med minimal netværkseksponering. Mindst mulige rettigheder og just-in-time er dermed de styrende principper. NIST SP 800-53 AC-6 leverer kontrolniveauet til at håndhæve minimerede privilegier (NIST SP 800-53 AC-6). For fjernadgang kan man desuden inddrage NIST SP 800-171 3.1.12, som kræver overvågning og kontrol af fjernadgang (NIST SP 800-171 3.1.12), mens CMMC AC.L2-3.1.12 sammenfatter de tilsvarende krav for leverandører til den amerikanske forsvarsindustri (CMMC AC.L2-3.1.12). I alle tilfælde muliggør browserbaseret fjernadgang en mere stringent håndhævelse.
DMZ-variant: Syteca-gateway som bastion i afkoblingszonen
– Placering: Syteca-gateway eller jump-komponent i DMZ.
– Indgående fra internettet udelukkende port 443/TCP (HTTPS) til gatewayen.
– Firewall-regler DMZ→internt begrænses strengt til de nødvendige målprotokoller (fx RDP 3389/TCP, SSH 22/TCP) og initieres kun fra gatewayen.
– Interne servere forbliver uden interneteksponering. RDP og SSH er rent interne og derfor ikke tilgængelige fra internettet.
– Identitetsintegration (Active Directory, Entra ID), MFA og godkendelses-workflows håndhæves centralt i gatewayen. Sessionoptagelse og audit-trail opfylder desuden revisionskravene. Samlet reducerer denne arkitektur angrebsfladen markant sammenlignet med bredt koblede VPN-tunneller og styrker browserbaseret fjernadgang.
HAProxy-variant: reverse proxy foran Syteca for hærdning og høj tilgængelighed
HAProxy i DMZ terminerer valgfrit TLS (eller videresender det som passthrough), håndhæver moderne cipher suites (mindst TLS 1.2), sætter HSTS og rate limiting og overvåger backends via health checks. To HAProxy-noder kan desuden drives højtilgængeligt med Keepalived/VRRP, og mod backend kan der re-encryptes. Kraftigt forkortet eksempel:
global …
defaults …
frontend https_in
bind :443 ssl crt /etc/ssl/certs/site.pem ssl-min-ver TLSv1.2
http-response set-header Strict-Transport-Security “max-age=31536000; includeSubDomains; preload”
acl is_api path_beg /api
use_backend syteca_api if is_api
default_backend syteca_portal
backend syteca_portal
option httpchk GET /healthz
server portal1 10.10.10.11:443 ssl check
backend syteca_api
server api1 10.10.10.12:443 ssl check
Bemærk: I produktionsmiljøer er struktureret logning, forbindelsesgrænser og DoS-beskyttelse uomgængelige. Indgående tilladelser forbliver desuden begrænset til port 443. RDP og SSH er kun interne og udelukkende tilgængelige fra gatewayen. Denne opstilling beskytter desuden browserbaseret fjernadgang mod volumetriske angreb.
Operationelle fordele i hverdagen Ærlig vurdering: hvornår VPN fortsat giver mening
– Mindre angrebsflade: Ingen bred netværkskobling på klienten. Adgang til ressourcen i stedet for til et helt subnet.
– Revisionssikker logning: Sessionoptagelse med billed- og tastaturoptagelse samt uforanderlige logs i stedet for sparsomme VPN-metadata.
– Leverandøradgang uden VPN-onboarding: Browserlogin, MFA, tidsbegrænset godkendelse og øjeblikkelig offboarding.
– Credential-hygiejne: Centralt vaulting, automatisk rotation, ingen klartekst-adgangskode hos administratoren.
– BYOD-egnet: Ingen VPN- eller RDP-klienter på fremmede enheder. Risikoen kanaliseres i stedet ved gatewayen. NIST anbefaler desuden at beskytte BYOD- og fjernteknologier særskilt og styre risici eksplicit (NIST SP 800-46
VPN er ikke forældet. Til fuld netadgang, lift-and-shift-legacy eller overgangsfaser forbliver det et legitimt værktøj, helst segmenteret, med stærk autentisering og aktiv overvågning. Til privilegeret adgang til klart definerede målsystemer er browserbaseret PAM dog som regel sikrere, driftsmæssigt enklere og lettere at auditere, særligt når mindst mulige rettigheder håndhæves konsekvent i henhold til NIST AC-6 (NIST SP 800-53 AC-6). I praksis vil browserbaseret fjernadgang derfor ofte være førstevalget.
Konklusion og handlingsfelter
Browserbaseret fjernadgang med Syteca PAM flytter kontrollen fra nettet til ressourcen. Autentisering, autorisation, godkendelse og optagelse foregår i gatewayen, før en session overhovedet når frem til målsystemet. Det svarer til Zero Trust-princippet never trust, always verify og reducerer risikoen markant i forhold til netdækkende VPN-tunneller. For SMV’er betyder det følgelig mindre driftsfriktion, bedre sporbarhed og en ren adskillelse for leverandøradgange.
Vi anbefaler beslutningstagere følgende næste skridt som en pragmatisk start. Dermed accelererer I indførelsen af browserbaseret fjernadgang uden at gå på kompromis med styringen.
✓ Fastlæg mandat og scope: Kortlæg privilegerede målsystemer (Windows- og Linux-servere, databaser, appliances, web-konsoller) og definer adgangskanaler (HTTPS via portal, ingen direkte RDP/SSH-eksponeringer). Dermed sikrer I konsekvent browserbaseret fjernadgang.
✓ Operationaliser mindst mulige rettigheder: Rollemodel, godkendelses-workflows, just-in-time-adgang og sessionoptagelse defineres bindende, med reference til NIST SP 800-53 AC-6 (Link) og kontrollerne for fjernadgang i NIST SP 800-171 3.1.12 (Link). Denne governance udgør fundamentet for sikker browserbaseret fjernadgang.
✓ Vælg arkitektur: DMZ-gateway med port 443 indgående og stramme DMZ→internt-regler, eventuelt suppleret med HAProxy foran for TLS-hærdning og høj tilgængelighed. Vurder desuden telearbejds- og fjernrisici i henhold til NIST SP 800-46 og formaliser driftsprocesserne for overvågning, patching og backup (SP 800-46 Rev. 2, NIST-oversigt). Dermed bevares robust browserbaseret fjernadgang også under belastning.
Videre information og rådgivning
Vil I etablere privilegeret fjernadgang uden VPN-klienter, med DMZ-gateway, HAProxy-hærdning, MFA, just-in-time-godkendelser, sessionoptagelse og credential vaulting? Vi følger jer fra arkitekturreview til pilotering, konsekvent med reference til NIST-anbefalingerne for fjernadgang og mindst mulige rettigheder. Dermed bevares styrbarheden i browserbaseret fjernadgang.
🎯 Vigtigste pointer – handl nu
Nogle umiddelbare konklusioner for ledelse og IT-ansvarlige:
✓ Løsriv privilegeret adgang fra VPN: Sats på browserbaseret adgang via et PAM-gateway med MFA, JIT-godkendelser, sessionoptagelse og vaulting i stedet for netdækkende tunneller. Det følger desuden NIST-anbefalingerne for fjernadgang og mindst mulige rettigheder (SP 800-46 Rev. 2, AC-6). Denne prioritering styrker samtidig browserbaseret fjernadgang.
✓ Hærd arkitekturen konsekvent: DMZ-gateway med udelukkende port 443 udefra, strenge firewall-regler DMZ→internt, RDP og SSH kun internt. Eventuelt suppleres med HAProxy for TLS-hærdning, health checks og høj tilgængelighed via VRRP. Dermed opnår I robust browserbaseret fjernadgang uden overflødige åbninger.
✓ Forenkl og auditér leverandøradgange: Intet VPN-onboarding, men i stedet browserlogin, tidsbegrænset godkendelse, sessionoptagelse og fuld audit-trail. Offboarding sker desuden på minutter i stedet for dage. Det forbedrer governance for browserbaseret fjernadgang.
✓ Forankr politikker: Definer kontroller for fjernadgang i henhold til NIST SP 800-171 3.1.12 og CMMC AC.L2-3.1.12, inklusive stærk autentisering, rolleprincip og revisionssikker logning (NIST SP 800-171 3.1.12, CMMC AC.L2-3.1.12
Ofte stillede spørgsmål: FAQ om browserbaseret fjernadgang med Syteca PAM
Hvad omfatter de næste skridt?
Vi demonstrerer gerne den browserbaserede adminadgang live, inklusive MFA, just-in-time-godkendelse, sessionoptagelse og vaulting. I et kort arkitekturreview skitserer vi desuden DMZ- eller HAProxy-varianten til jeres miljø og prioriterer de første målsystemer. Som tekstlig skitse af arkitekturbilledet: Internet → ydre firewall → DMZ med HAProxy og Syteca-gateway → indre firewall → interne målsystemer. Denne køreplan giver en effektiv og sporbar indførelse af browserbaseret fjernadgang.