Adgangskontrol forklaret: godkendelse, autorisation og ressourceadministration

Adgangskontrol er et af de emner, der virker indlysende, indtil du kigger nærmere efter. Det er også, år efter år, kategori nummer et i OWASP Top 10 (Broken Access Control) og langt den mest udbredte svaghed, vi ser, både i branchen og i vores egne analyser. Den gode nyhed er, at emnet bliver meget enklere, når du har de rigtige spørgsmål for øje.

Hvad er adgangskontrol helt præcist?

Adgangskontrol afgør, hvem der må gøre hvad med hvilken ressource. Når en applikation modtager en anmodning, skal den besvare tre spørgsmål, og alle tre betyder noget.

1. Ved jeg, hvem brugeren er? (godkendelse)

Det er identitetstrinnet: er brugeren virkelig den, vedkommende påstår at være? Adgangskoder, MFA og SSO besvarer alle det første spørgsmål.

2. Har brugeren lov til at udføre handlingen? (autorisation)

At vide, hvem brugeren er, siger ingenting om, hvad vedkommende må. En godkendt bruger er ikke nødvendigvis en bruger, der har lov til at slette, redigere eller administrere.

3. Har vedkommende ret til denne konkrete ressource? (autorisation på objektniveau)

Det er det spørgsmål, der oftest bliver glemt. Retten til at se „én“ post betyder ikke retten til at se „alle“ poster. Når den kontrol mangler, kalder vi det IDOR (Insecure Direct Object Reference): det eneste, der skal til, er at ændre en identifikator i anmodningen for at nå en andens data.

Værd at huske: det er nok at glemme et eneste af de tre spørgsmål for at skabe en sårbarhed. De tre udgør en helhed.

Spørgsmålet, folk glemmer: hvor sker kontrollen?

Det er ikke nok at besvare de tre spørgsmål korrekt. Du skal også spørge, hvor kontrollerne håndhæves. Og det er præcis her, forskellen ligger mellem en reel sikkerhedsforanstaltning og en simpel grænsefladekonvention.

Klientsiden

Kontroller på klientsiden håndhæves af grænsefladen: en „Slet“-knap, der er skjult, en mulighed, der er nedtonet, en menu, der ikke vises. Det er nyttigt og helt normalt. Det er det, der gør en applikation behagelig at bruge, og det styrer brugerne væk fra valg, som alligevel bare ville blive afvist. Det er ikke det, der forhindrer handlingen: når adgangskontrollen er gjort rigtigt, afviser serveren handlingen, uanset hvad grænsefladen viser.

Kontrollerne lever på brugerens side, og enhver, der manipulerer anmodningerne direkte, kan omgå dem, fordi grænsefladen kun er én dør blandt andre til dataene.

Serversiden

Kontroller på serversiden håndhæves af selve applikationen, der hvor dataene ligger. De afhænger ikke af den grænseflade, der bruges, og de kan ikke omgås ved at sammensætte en anmodning.

Det lag, og kun det lag, er det, der reelt beskytter følsomme data: visning, redigering, sletning, afsløring af en adgangskode, adgang til vedhæftede filer og så videre.

En kontrol på klientsiden er en konvention for brugeroplevelsen, ikke en sikkerhedsforanstaltning. Reglen er enkel: enhver tilladelse, der beskytter følsomme data eller et kritisk forløb, skal håndhæves på serversiden. En kontrol på klientsiden kan ledsage den, men aldrig erstatte den.

Hvad det betyder i praksis for dine data

Tag eksemplet med Remote Desktop Manager (RDM), vores desktopapplikation til administration af fjernforbindelser og legitimationsoplysninger. RDM tilbyder en rig oplevelse: tilladelser, roller og valg, der vises eller skjules alt efter brugeren. Men hvor håndhæves de tilladelser faktisk? Svaret afhænger helt af arkitekturen i det arbejdsområde, den forbinder til.

• Et SQL Server-arbejdsområde (en direkte databaseforbindelse). I det tilfælde er der ingen applikationsserver mellem RDM og databasen. RDM taler direkte med SQL Server. Tilladelserne findes, men de håndhæves af klienten. Med andre ord lever de alle på klientsiden. Laget på serversiden, det der står imod direkte manipulation, er simpelthen ikke til stede.
• Et anbefalet arbejdsområde, der hviler på en applikationsserver. Det findes i to varianter: Devolutions Server (DVLS), det selvhostede arbejdsområde, du udruller på din egen infrastruktur, og Devolutions Cloud, det fuldt administrerede, cloudhostede arbejdsområde. I begge tilfælde er RDM stadig klienten, men det er serveren, der validerer hver adgang: hvem du er, hvad du må, og på hvilken konkret ressource. De tre spørgsmål finder deres svar der, hvor det virkelig tæller, på serversiden.

Det er ikke et spørgsmål om gode intentioner eller omhyggelig konfiguration. Det er et spørgsmål om arkitektur. Uden en applikationsserver er der ikke et fysisk sted at håndhæve kontroller på serversiden. Det er den centrale grund til, at vi anbefaler at parre RDM med en Devolutions Password Manager, ikke som en produktpræference, men fordi arkitekturen kræver det.

Kort fortalt

• God adgangskontrol besvarer tre spørgsmål: hvem (godkendelse), hvad (autorisation) og på hvilken ressource (autorisation på objektniveau).
• En kontrol på klientsiden forbedrer oplevelsen, men beskytter ingenting i sig selv, fordi den kan omgås.
• Kun en kontrol på serversiden beskytter reelt følsomme data.
• For at laget på serversiden overhovedet findes, skal du have en Devolutions Password Manager bag RDM: Devolutions Server (DVLS), hvis du vil selvhoste, eller Devolutions Cloud, hvis du foretrækker en fuldt administreret tjeneste.

Hvis RDM i øjeblikket forbinder direkte til en SQL Server-database, er det værd at spørge dig selv: hvor håndhæves mine adgangskontroller faktisk? Arkitekturen, ikke konfigurationen, giver dig det ærlige svar. Du kan udforske de tilgængelige arbejdsområder for at se, hvilket der passer til dit miljø.

Og prisen er sjældent den forhindring, folk forventer: både Devolutions Server og Devolutions Cloud tilbyder en gratis mulighed til at komme i gang. At bruge Devolutions Server som backend kræver blot en aktiv Remote Desktop Manager Enterprise-licens, og da det allerede kræver den samme Enterprise-licens at forbinde RDM til en SQL Server-database, har du højst sandsynligt allerede alt, hvad du skal bruge for at skifte. (At nå arbejdsområdet fra en webbrowser uden RDM bruger en separat Client Access License.)