Gå til indhold
atlas

Adgangskontrol

De regler og mekanismer, der afgør, hvem der må bruge hvilke systemer, data eller lokaler, og på hvilken måde.

Kladde - dette opslag er endnu ikke gennemgået.

Formelt

Håndhævelsen af en politik ved hver anmodning om at bruge en ressource, hvor autentificering (hvem spørger) og autorisation (hvad må vedkommende) tilsammen afgør, om den tillades eller afvises. Det gælder både digitale ressourcer og fysiske som døre og serverrum.

Forklaret enkelt

Som hele dørsystemet i en kontorbygning - kortlæserne, listen over, hvem der må komme på hvilken etage, og låsen, der faktisk holder døren lukket.

I praksis

På et regionshospital kan sygeplejersker kun åbne journaler for patienter på deres eget afsnit; journalsystemet tjekker hvert opslag mod den regel og logger alle afviste forsøg.

Hvorfor det betyder noget

Det er her, dataenes fortrolighed og integritet rent faktisk håndhæves; uden den er enhver sikkerhedspolitik blot ord på papir.

Sådan kommer du i gang

De typiske trin i rækkefølge. Tilpas dem til jeres organisation.

  1. Lad systemejeren skrive adgangsreglerne ned i klart sprog for hvert system - hvilke roller eller attributter der må læse, ændre eller slette hvilke data - og få dem godkendt, før der bygges noget.
  2. Vælg den model, der passer til reglerne, fx roller til simpel jobbaseret adgang og attributter eller relationer til regler som "kun patienter på mit eget afsnit", og skriv valget ind i designet.
  3. Placér kontrollen i ét centralt håndhævelsespunkt på serveren, fx en middleware, en API-gateway eller en policy engine, i stedet for at sprede if-sætninger ud i koden eller nøjes med at skjule knapper i brugerfladen.
  4. Afvis som udgangspunkt, så enhver anmodning, side, fil eller API-kald uden en udtrykkelig regel bliver afvist, og lad systemet nægte adgang, hvis policy engine eller katalog ikke kan nås.
  5. Tjek rettighederne ved hver anmodning og for hver enkelt post, ikke kun ved login, så en bruger ikke kan åbne en andens sag ved at ændre et ID i URL'en.
  6. Log både afviste og tilladte opslag i følsomme data med bruger, objekt og tidspunkt, og alarmér ved gentagne afvisninger fra samme konto.
  7. Skriv automatiske tests af adgangsreglerne, også forsøg på at nå andre brugeres data og administratorfunktioner, og kør dem i build-pipelinen ved hver ændring.
  8. Test adgangskontrollen ved hver penetrationstest eller kodegennemgang, og gennemgå reglerne med systemejeren mindst en gang om året og hver gang systemet ændres.

Typiske faldgruber

  • At skjule et menupunkt eller en knap i brugerfladen, men lade API'et bag den stå åbent for alle, der kalder det direkte.
  • At tjekke, at brugeren er logget ind, uden at tjekke, at den post, der bedes om, er en, brugeren må se, hvilket giver insecure direct object references.
  • At fejle åbent, så alle bliver lukket ind, når policy engine, katalog eller rettighedsopslag ikke svarer.

Gode vejledninger

Teknisk uddybning

Det teoretiske udgangspunkt er Lampsons adgangsmatrix (1971): subjekter som rækker, objekter som kolonner og et sæt rettigheder i hver celle. Ingen systemer gemmer selve matricen; de skærer den enten pr. kolonne, så man får adgangskontrollister knyttet til objekterne (Unix-tilladelsesbits, POSIX-ACL'er, NTFS-DACL'er, S3-bucketpolitikker), eller pr. række, så man får capabilities, som subjekterne holder (filbeskrivere, objekt-capabilities, bearer-tokens). Anderson-rapporten fra 1972 tilføjede begrebet reference monitor: Den håndhævende komponent skal kaldes ved hver eneste adgang (complete mediation), være beskyttet mod manipulation og være lille nok til at kunne verificeres. De tre egenskaber er stadig den rette målestok for ethvert håndhævelsespunkt.

Oven på det ligger politikmodellerne. Ved skønsmæssig adgangskontrol (DAC) kan ejeren af et objekt selv tildele rettigheder, som med chmod. Ved obligatorisk adgangskontrol (MAC) håndhæver systemet klassifikationsmærker, som ejeren ikke kan tilsidesætte; Bell-LaPadula ("ingen læsning opad, ingen skrivning nedad") beskytter fortrolighed, Biba beskytter integritet, og SELinux og AppArmor bringer MAC til Linux. Rollebaseret adgangskontrol (ANSI INCITS 359-2004) sender rettighederne gennem roller, attributbaseret adgangskontrol (NIST SP 800-162) evaluerer regler over attributter for subjekt, objekt, handling og omgivelser, og relationsbaseret adgangskontrol, kendt fra Googles Zanzibar-artikel (2019), udleder rettigheder fra en graf af relationer som ejer, medlem og overordnet mappe. Systemer i drift kombinerer som regel flere modeller.

Arkitekturen beskrives typisk med XACML's begreber: Et policy enforcement point (PEP) opfanger forespørgslen, et policy decision point (PDP) træffer afgørelsen, et policy information point (PIP) leverer attributter, og et policy administration point (PAP) forvalter reglerne. NIST SP 800-207 genbruger opdelingen i PEP og PDP til Zero Trust. Eksterne regelmotorer som Open Policy Agent (Rego) eller Cedar holder politikken ude af applikationskoden. Fornuftige standardvalg er afvisning som udgangspunkt, kontrol på serveren ved hver forespørgsel og for hvert objekt, afvisning hvis PDP'en ikke kan nås (fail closed), og logning af både tilladte og afviste afgørelser.

Fejlene er udbredte: Broken Access Control er A01 i både OWASP Top 10:2021 og Top 10:2025 og dækker usikre direkte objektreferencer (IDOR), manglende kontrol på funktionsniveau, forced browsing, manipulerede tokens og fra 2025 også SSRF. Confused deputy-problemet (Hardy, 1988) viser, hvordan et privilegeret program kan narres til at bruge sin egen myndighed på en kalders vegne; huller mellem kontrol og brug (TOCTOU) og cachede afgørelser, der overlever en tilbagekaldelse, er andre klassiske fejl. Adgangskontrol er mekanismen ved hver forespørgsel; adgangsstyring er livscyklussen med at tildele, recertificere og fjerne rettigheder. ISO/IEC 27001:2022 dækker begge i bilag A 5.15-5.18, med 7.2 for fysisk adgang og 8.3 for begrænsning af adgang til information.

Hvad du bør lære først

Alt det, dette bygger på - grundlaget først.

  1. Digital identitet
  2. →Loginoplysning (credential)
  3. →Autentificering
  4. →Adgangskontrol

Relationer

Forudsætter
Autentificering
Implementeres af
Adgangsstyring
Forveksl ikke med
Adgangsstyring

Kilder og videre læsning

Standarder og officielle tekster

Hvor dataene kommer fra

Dette opslag er skrevet af en AI ud fra kilderne ovenfor og er endnu ikke gennemgået af et menneske. Brug det som udgangspunkt, og tjek alt vigtigt mod kilderne.

Se gennemgangskøenForeslå en rettelse på GitHubDette begreb som JSON

Nævnt i

SystempromptHåndtering af hemmeligheder (secrets management)ISO 27002OWASP Top 10

Test dig selv

Indlæser…

Atlas er i beta.