Support og administration

Sikker supportadgang: hjælp brugeren uden en skjult superbruger

Når medarbejdere eller kunder bruger appen, skal support kunne undersøge fejl uden at få permanent adgang til alle virksomheder, alle data og alle handlinger. En sikker løsning starter med mindst mulig indsigt og åbner kun en navngiven, afgrænset og tidsbegrænset adgang, når sagen faktisk kræver det.

Brug det mindst indgribende supportniveau

Support behøver sjældent fuld brugeradgang som udgangspunkt. Opdel hjælpen i niveauer, og vælg det laveste niveau, der kan besvare den konkrete sag. Det begrænser både persondata, fejlhåndtering og konsekvensen af en kompromitteret supportkonto.

Supportniveau	Hvad support kan se eller gøre	Brug det når
Vejledning	Ingen adgang til kundens data	Et skærmbillede, en fejlkode eller skærmdeling er nok
Diagnostik	Driftsstatus, versionsdata og dataminimerede logs	Fejlen kan findes uden at åbne selve indholdet
Læsende support	Udvalgte data i én virksomhed eller sag	Support skal se den konkrete tilstand, men ikke ændre den
Handling på vegne af bruger	Få navngivne handlinger i en kort periode	Problemet ikke kan løses sikkert på et lavere niveau

En supportrolle er ikke det samme som en systemadministrator. Support kan eksempelvis få adgang til ordrestatus og genafsendelse af en kvittering uden samtidig at kunne ændre roller, eksportere alle kunder eller læse betalingsoplysninger.

Adskil den virkelige aktør fra den berørte bruger

Systemet skal altid bevare identiteten på den supportmedarbejder, der er logget ind. Hvis personen ser appen i en kundes eller brugers kontekst, er det en ekstra kontekst – ikke en ny identitet. Ellers kommer revisionssporet til at ligne en almindelig brugerhandling, og kunden kan ikke se, hvem der reelt gjorde hvad.

Aktør: Den navngivne supportmedarbejder med egen konto og stærkt login.
Mål: Den virksomhed, bruger, sag eller datapost, supporten må arbejde med.
Omfang: Læsning eller udtrykkeligt tilladte handlinger – aldrig bare “alt admin”.
Gyldighed: Start, udløb, sagshenvisning og mulighed for at stoppe adgangen straks.

Bed aldrig om brugerens adgangskode. Nulstil heller ikke brugerens login for at overtage kontoen. Det ødelægger både ansvarsspor, brugerens kontrol og muligheden for at tilbagekalde supportadgangen særskilt.

Opret adgang fra en konkret supportsag

En supportanmodning bør starte med et sagsnummer, et formål og en beskrivelse af den nødvendige adgang. Hvis support skal læse kundedata eller handle på kundens vegne, skal kunden eller en navngiven intern ansvarlig kunne se, hvad der åbnes, hvorfor og hvor længe. Godkendelse skal passe til risikoen; en harmløs statuskontrol og en ændring af fakturadata behøver ikke samme proces.

Beskriv problemet: Knyt anmodningen til en konkret sag og et forventet resultat.
Vælg mål og omfang: Én virksomhed, eventuelt én bruger eller sag, og de nødvendige handlinger.
Få passende godkendelse: Registrér hvem der bad om eller godkendte adgangen, når det er relevant.
Sæt et udløb: Adgangen skal lukke automatisk; tid vælges efter opgaven, ikke efter en bekvem standard.
Luk sagen: Stop adgangen, kontrollér ændringerne, og skriv et kort resultat uden at kopiere følsomme data ind i supportsystemet.

Håndhæv supportsessionen på serveren

En knap eller et skjult menupunkt i frontend er ikke adgangskontrol. Serveren, databasens politikker eller platformens Security Rules skal kontrollere den almindelige supportrolle og den aktive supportsessions mål, omfang og udløb ved hver request. Regler uden et udtrykkeligt match skal afvise adgangen.

Genbekræft før elevation: Kræv et friskt, stærkt login før en privilegeret supportsession åbnes.
Udsted en kortlivet reference: Gem aktør, mål, omfang, udløb og sag server-side; lad ikke browseren vælge dem frit.
Kontrollér hver handling: Match både supportmedarbejder, virksomhed, datapost, operation og sessionens aktuelle gyldighed.
Stop centralt: En lukket sag, fratrådt medarbejder eller mistænkelig aktivitet skal kunne tilbagekalde adgangen straks.
Begræns data i svaret: Returnér kun de felter, som supportvisningen faktisk skal bruge, og maskér følsomme værdier.

I Firebase kan custom claims bruges til stabile adgangsroller, men ændringer ses først, når brugerens ID-token bliver fornyet eller tvangsopdateret. En kort, sagsspecifik supporttilladelse passer derfor ofte bedre som en serverkontrolleret post med udløb, mens den grundlæggende ret til at anmode om supportadgang kan ligge i rollen.

Gør brugerrepræsentation tydelig og svær at glemme

Hvis appen har en “se som bruger”-funktion, skal tilstanden være synlig på alle sider. Et vedvarende banner bør vise supporttilstand, målvirksomhed eller bruger og en tydelig afslutningsknap. Den normale supportnavigation må ikke ligne kundens egen session så meget, at medarbejderen glemmer, hvem handlingen rammer.

Start læsende, og deaktivér sletning, rolleændringer, masseeksport og andre højrisikohandlinger.
Hvis en ændring er nødvendig, vis mål og konsekvens og kræv en særskilt, afgrænset tilladelse.
Skeln mellem forhåndsvisning og virkning: undgå at sende mails, webhooks eller notifikationer blot ved at åbne supportvisningen.
Vis udløb og resterende gyldighed, og afslut tilstanden automatisk ved udløb eller tilbagekaldelse.
Lad supportmedarbejderen vende tilbage til sin egen kontekst med én tydelig handling.

Før et særskilt revisionsspor for support

Almindelige serverlogs er ikke nok til at forklare en supportsag. Registrér åbning, godkendelse, brug, ændringer, afvisninger, tilbagekaldelse og afslutning som forretningshændelser. OWASP anbefaler, at en log kan forklare hvornår, hvor, hvem og hvad; for support bør den også knytte hændelsen til mål, resultat og begrundelse.

Identitet: Den virkelige aktør og eventuel godkender – aldrig kun den repræsenterede bruger.
Adgang: Sag, målvirksomhed, omfang, start, udløb og årsag til ophør.
Handling: Funktion, berørt objektreference, resultat og relevant ændring uden unødigt indhold.
Kontrol: Afviste forsøg, overskredet omfang og brug efter udløb skal være søgbare og kunne udløse alarm.

Gem ikke passwords, tokens, hele dokumenter, komplette formularer eller følsomme beskeder i loggen. Revisionssporet skal kunne bevise hændelsen uden selv at blive en unødvendig kopi af kundens data.

Hold nødadgang adskilt fra daglig support

Nødadgang kan være nødvendig, hvis normal identitetsstyring eller supportflow er nede, men den må ikke blive den praktiske genvej i hverdagen. Brug navngivne konti, stærk autentifikation, kort gyldighed, begrundelse, alarm til en anden ansvarlig og en fast efterkontrol. Delte “admin”-konti gør det umuligt at placere ansvar og bør ikke bruges.

Microsoft Entra PIM og Google Cloud Privileged Access Manager er eksempler på platformfunktioner til just-in-time, tidsbegrænset adgang med mulighed for begrundelse, godkendelse og efterfølgende audit. Den præcise funktion og tilgængelighed afhænger af jeres cloudmiljø og abonnement; princippet kan også bygges afgrænset i selve appen.

Test både adgang, udløb og sideeffekter

Afprøv supportflowet i et isoleret miljø med realistiske testvirksomheder. En test er først bestået, når det tilladte virker, det forbudte afvises, og ingen skjult mail, webhook eller dataændring er sluppet igennem.

En almindelig bruger og en supportmedarbejder uden aktiv sag får afslag.
En læsende supportsession kan ikke skrive, eksportere bredt eller skifte virksomhed.
Et ændret virksomheds-, bruger- eller objekt-id i requesten bliver afvist på serveren.
Sessionen stopper ved udløb, manuel tilbagekaldelse, lukket sag og deaktiveret supportkonto.
Genindlæsning, ny fane og direkte API-kald kan ikke omgå banner, omfang eller udløb.
Revisionssporet viser aktør, mål, handling og resultat, mens følsomme felter er udeladt.
En supportvisning udløser ikke kundemails, notifikationer eller integrationer ved et uheld.

Typiske fejl

Én permanent superbrugerrolle: Enhver supportsag åbner hele produktionen uden mål, udløb eller begrundelse.
Skjult menu som kontrol: Direkte API-kald virker stadig, fordi serveren ikke kontrollerer supportsessionen.
Support logger ind som kunden: Adgangskoder deles eller nulstilles, og revisionssporet peger på den forkerte aktør.
Kun læsning i brugerfladen: Backend tillader stadig ændrende endpoints eller brede eksportkald.
Adgangen udløber kun i browseren: Et gammelt token eller direkte kald fortsætter efter banneret er væk.
Hele payloaden logges: Supportsporet bliver en ny samling af kundedata, tokens eller følsomme dokumenter.
Nødadgang bruges til hverdag: Den kontrollerede supportvej bliver aldrig gjort færdig eller afprøvet.

Tjekliste før support får adgang til produktion

☐ Supportniveauerne er beskrevet fra vejledning til sjælden handling på vegne af bruger.
☐ Hver supportmedarbejder bruger sin egen konto med stærkt login; ingen deler en adminbruger.
☐ En adgang knyttes til sag, formål, målvirksomhed, omfang, godkender og automatisk udløb efter behov.
☐ Den virkelige aktør bevares separat fra den bruger eller virksomhed, som vises.
☐ Server, database eller Security Rules kontrollerer rolle, mål, handling og udløb ved hver request.
☐ Brugerrepræsentation har vedvarende banner, tydeligt mål, udløb og en sikker afslutningsknap.
☐ Læseadgang er standard, og højrisikohandlinger kræver et særskilt, snævert omfang.
☐ Supportvisningen udløser ikke utilsigtede mails, webhooks, betalinger eller notifikationer.
☐ Adgang kan tilbagekaldes straks ved lukket sag, fratrædelse eller mistanke om misbrug.
☐ Revisionssporet viser start, aktør, mål, handling, resultat og afslutning uden secrets eller unødige persondata.
☐ Nødadgang er adskilt, alarmeret, tidsbegrænset og efterprøves efter brug.
☐ Negative tests beviser, at andre virksomheder, udløbne sessioner og forbudte handlinger afvises.

Relaterede guides

Roller og rettigheder for funktioner, virksomheder og dataposter Revisionslog over kritiske forretningshandlinger Sikkert login, MFA, sessioner og kontogendannelse Driftsberedskab ved nedbrud og sikkerhedshændelser GDPR, dataminimering og ansvar for persondata Se hele guidebiblioteket

Officielle kilder

Den konkrete implementering afhænger af appens identitetsløsning, database og cloud. Kilderne beskriver principperne og udvalgte platformfunktioner; kontrollér altid den aktuelle dokumentation for jeres egen stack, og afprøv den faktiske adgang.