Godkendelse af kritiske handlinger: adskil bestilling og godkendelse

Brug ekstra godkendelse dér, hvor konsekvensen kræver det

To-personers-godkendelse kaldes også fire-øjne-princippet eller maker-checker. Det er ikke en erstatning for almindelige roller og rettigheder. Det er et ekstra værn ved handlinger, hvor misbrug eller en menneskelig fejl kan få stor økonomisk, sikkerheds- eller driftsmæssig konsekvens.

NIST beskriver adskillelse af pligter som en kontrol mod misbrug af legitime privilegier. Det betyder ikke, at alle ændringer skal gennem to personer. Vælg de konkrete handlinger efter appens risiko, eksisterende værn og virksomhedens størrelse.

Beskriv reglen før brugerfladen bygges

Skriv en lille beslutningstabel for hver kritisk handling. Den skal være forståelig for både virksomhedsejeren, brugerne og den, der vedligeholder koden.

Udløser

Hvilken handling, rolle, beløbsgrænse, datatype eller kombination kræver godkendelse?

Bestiller

Hvem må oprette anmodningen, og hvilke data må personen foreslå?

Godkender

Hvem må godkende, og skal personen tilhøre en anden rolle, afdeling eller konkret virksomhed?

Gyldighed

Hvor længe må anmodningen stå åben, og hvilke ændringer gør den ugyldig?

Udførelse

Hvilken serverhandling udføres én gang, og hvad sker der ved konflikt eller ekstern fejl?

Nødvej

Kan driften vente, eller kræves en afgrænset nødprocedure med alarm og efterkontrol?

Gem en præcis anmodning – ikke bare et ja eller nej

Godkenderen skal kunne se, hvad der faktisk bliver udført. Gem derfor den væsentlige forretningsdata sammen med anmodningen: mål, før- og efterværdi, beløb, valuta, virksomhed, bestiller, begrundelse og udløbstid. Et link til en levende redigeringsside er ikke nok, hvis data kan ændres efter godkendelsen.

• Bind godkendelsen til indholdet: Hvis mål, beløb, rolle eller omfang ændres, skal den tidligere godkendelse bortfalde.
• Vis forskellen: Godkenderen skal kunne se de betydende værdier, ikke blot teksten “Godkend ændring”.
• Bevar status: Afventer, godkendt, afvist, udløbet, annulleret, udfører, gennemført og fejlet skal have tydelig betydning.
• Brug én beslutning én gang: En godkendelse må ikke kunne genbruges til en ny eller ændret handling.

Håndhæv adskillelsen på serveren

En skjult godkendelsesknap beskytter kun brugeroplevelsen. Serveren eller datalagets betroede regler skal afvise, hvis bestiller og godkender er samme identitet, hvis godkenderen mangler den aktuelle rolle, eller hvis anmodningen tilhører en anden virksomhed.

1. 1. Opret anmodningen. Serveren udleder bestiller og virksomhed fra den verificerede session og gemmer et uforanderligt beslutningsgrundlag.
2. 2. Find godkendere. Brug appens aktuelle roller og datarelationer – ikke en emailadresse sendt af klienten.
3. 3. Kontrollér beslutningen. Ved godkendelse genkontrolleres identitet, forskellig aktør, rettighed, virksomhed, status og udløb.
4. 4. Luk kapløbet. To godkendere eller dobbeltklik må ikke udføre samme anmodning flere gange. Brug transaktion, versionskontrol eller anden atomisk betingelse.
5. 5. Kontrollér før udførelse. Bekræft at det godkendte mål stadig findes, og at den kritiske førtilstand ikke har ændret sig.
6. 6. Gem udfaldet. Forretningsændring, beslutning og revisionsspor skal enten hænge atomisk sammen eller kunne afstemmes sikkert efter en ekstern handling.

OWASP anbefaler, at transaktionsgodkendelse håndhæves på serveren, bindes til de betydende data, følger en tilladt rækkefølge og kontrolleres igen ved udførelse. Samme princip gælder på tværs af SQL, Firebase, Supabase, Azure og andre stacks; den konkrete atomiske mekanisme afhænger af datalageret.

Gør godkenderen i stand til at træffe en rigtig beslutning

Et flow er ikke sikkert, hvis brugeren lærer at trykke “Godkend” uden at forstå konsekvensen. Vis kort og konkret hvem, hvad og hvorfor – og fremhæv de værdier, der gør handlingen risikabel.

• Identitet og kontekst: Bestiller, virksomhed, tidspunkt, begrundelse og relevante bilag.
• Før og efter: Eksempelvis gammel og ny bankkonto, nuværende og foreslået rolle eller antal berørte poster.
• Konsekvens: Om handlingen er reversibel, sender noget eksternt, flytter penge eller giver adgang til persondata.
• Klar afvisning: Godkenderen skal kunne afvise med årsag uden at rette anmodningen i stilhed.
• Genbekræftelse efter risiko: Ved særligt følsomme handlinger kan appen kræve en frisk login- eller MFA-kontrol efter den valgte identitetsudbyders model.

Undgå at sikkerheden stopper en lille virksomhed

En virksomhed med få medarbejdere kan ikke altid have to personer til alt. Begræns derfor flowet til de vigtigste risici, udpeg stedfortrædere og beslut på forhånd, hvad der må vente. En nødvej bør være sjælden, smallere end normal adminadgang og gøre brugen synlig med det samme.

Microsoft Entra PIM og GitHub-miljøbeskyttelse er eksempler på platforme, hvor privilegeret aktivering eller deployment kan kræve en anden godkender og forhindre self-review. Appens eget forretningsflow skal stadig designes efter dens data og risiko.

Test både omveje og fastlåste forløb

• Bestilleren forsøger at godkende sin egen anmodning via både brugerflade og direkte API-kald.
• En anden bruger med forkert rolle, forkert virksomhed eller udløbet adgang forsøger at godkende.
• Beløb, mål, rolle eller antal berørte poster ændres efter anmodningen er oprettet.
• To godkendere svarer samtidigt, eller samme request gentages efter timeout.
• Anmodningen udløber, annulleres eller afvises, mens godkendelsessiden står åben.
• Det eksterne system gennemfører handlingen, men appen mister svaret eller genstarter midt i udførelsen.
• Den eneste normale godkender er fraværende, og den dokumenterede stedfortræder eller nødvej afprøves.
• Revisionssporet kan bagefter vise bestiller, beslutningsgrundlag, godkender, tidspunkt, udførelse og endeligt udfald.

Typiske fejl

• Admin kan altid omgå flowet: En bred rolle gør den vigtigste kontrol frivillig.
• Godkendelsen er kun en boolean: Det kan ikke bevises, hvilke værdier eller hvilken konsekvens personen så.
• Self-review skjules kun i UI: Et direkte request accepterer stadig samme bruger som bestiller og godkender.
• Anmodningen kan redigeres: Et ufarligt beløb godkendes og ændres bagefter til et stort.
• Godkendelse udløser et ubeskyttet job: Retry eller to svar gennemfører handlingen flere gange.
• Alt kræver to personer: Køen bliver en vaneøvelse, og medarbejderne leder efter genveje.
• Nødvejen er en fælleskonto: Sporbarhed og individuel adgangskontrol forsvinder netop i den mest risikable situation.

Tjekliste til kritiske godkendelser

• ☐ Handlinger med behov for ekstra godkendelse er valgt efter konkret konsekvens.
• ☐ Bestiller, godkender, beløbsgrænser, dataomfang og stedfortrædere er dokumenteret.
• ☐ Anmodningen gemmer mål, væsentlige før- og efterværdier, begrundelse og udløb.
• ☐ Ændring af betydende data gør en eksisterende godkendelse ugyldig.
• ☐ Serveren afviser self-review, forkert rolle, forkert virksomhed og udløbet anmodning.
• ☐ Godkenderen ser det faktiske beslutningsgrundlag og handlingens konsekvens.
• ☐ Samtidige svar, dobbeltklik og retries kan ikke udføre handlingen flere gange.
• ☐ Rettighed, mål og kritisk førtilstand kontrolleres igen umiddelbart før udførelse.
• ☐ Godkendelse, udførelse og eksternt udfald kan afstemmes og forklares bagefter.
• ☐ Afvisning, udløb, annullering, fejl og fastlåste anmodninger har en tydelig vej.
• ☐ Nødadgang er afgrænset, alarmeret, tidsbegrænset og efterkontrolleret.
• ☐ Hele flowet er testet med mindst to realistiske brugere og negative API-tests.

Relaterede guides

Officielle kilder

Adgangs-, godkendelses- og transaktionsmekanismer varierer mellem identitetsudbydere, databaser og cloudplatforme. Brug de generelle principper her, og kontrollér den aktuelle dokumentation for den stack og de forretningshandlinger, appen faktisk bruger.

• NIST SP 800-53: AC-5 om adskillelse af pligter
• OWASP: Transaction Authorization Cheat Sheet
• OWASP: Authorization Cheat Sheet
• Microsoft Entra PIM: godkend eller afvis privilegerede rolleaktiveringer
• GitHub Docs: miljøbeskyttelse, krævede reviewers og self-review