Autoriseringsmodeller: RBAC, MAC og DAC

Adgangskontrolmodeller definerer de regler og politikker, der bestemmer, hvilke subjekter (brugere, processer) der kan få adgang til hvilke objekter (filer, systemer, data). Den valgte model bestemmer, hvem der kan give adgang, hvordan tilladelser tildeles, og hvordan håndhævelsen fungerer. Security+-eksamen dækker fire primære modeller: Discretionary Access Control (DAC), Mandatory Access Control (MAC), Role-Based Access Control (RBAC) og Rule-Based Access Control. Det er afgørende at forstå hver models styrker og egnede anvendelsestilfælde for at kunne designe effektive autoriseringssystemer.

I Discretionary Access Control (DAC) bestemmer ressourceejeren selv, hvem der må få adgang til vedkommendes ressourcer, og kan give eller tilbagekalde adgang for andre brugere. Det »discretionary« aspekt er, at ejerne træffer beslutningerne — systemet håndhæver deres beslutninger, men dikterer dem ikke. Dette er den model, der bruges i de fleste personlige computermiljøer (Windows NTFS-filtilladelser, Linux/Unix-filtilladelser). DAC's sikkerhedsbegrænsning er, at den kræver, at alle ressourceejere træffer korrekte adgangsbeslutninger — en bruger, der får adgang til en fil, kan give andre adgang uden administratorens medvirken og dermed potentielt sprede følsomme data ud over den tilsigtede målgruppe.

DAC har to iboende sikkerhedsrisici. Transitiv adgang: bruger A giver bruger B adgang, og bruger B giver bruger C adgang — den oprindelige ejer ved måske ikke engang, at C har adgang til vedkommendes ressource. Problemet med den forvirrede stedfortræder: et privilegeret program, der handler på vegne af en bruger med færre privilegier, kan utilsigtet bruge sine privilegier på en måde, som brugeren ikke selv kunne. I DAC-miljøer kan en enkelt kompromitteret konto potentielt få adgang til alle ressourcer, som brugeren har fået adgang til, og kan give andre adgang, før kompromitteringen opdages. DAC er praktisk, men skaber udfordringer for streng informationsindeslutning.

I Mandatory Access Control (MAC) håndhæver operativsystemet adgangspolitikker baseret på sikkerhedsmærkater, der er tildelt både subjekter (brugere) og objekter (data). Brugere kan ikke tilsidesætte eller ændre disse politikker — kun systemadministratoren eller sikkerhedspolitikken kan ændre dem. MAC bruges i klassificerede offentlige og militære miljøer, hvor data skal opdeles strengt. En bruger med sikkerhedsgodkendelsen »Secret« kan ikke få adgang til data mærket »Top Secret«, selv hvis dataejeren gerne ville give adgang. Bell-LaPadula-modellen (ingen læsning opad, ingen skrivning nedad) og Biba-modellen (ingen skrivning opad, ingen læsning nedad) er formelle MAC-implementeringer.

To formelle MAC-modeller omsætter sikkerhedsmål til matematiske regler. Bell-LaPadula fokuserer på fortrolighed: subjekter kan ikke læse data over deres klassifikationsniveau (ingen læsning opad) og kan ikke skrive data til et lavere klassifikationsniveau (ingen skrivning nedad). Dette forhindrer, at følsomme oplysninger flyder til uautoriserede brugere. Biba fokuserer på integritet: subjekter kan ikke skrive til et højere integritetsniveau (ingen skrivning opad) og kan ikke læse fra et lavere integritetsniveau (ingen læsning nedad). Biba forhindrer, at data med høj integritet forurenes af input med lav integritet. Virkelige MAC-systemer (som SELinux) kombinerer aspekter fra begge modeller.

Role-Based Access Control (RBAC) tildeler tilladelser til roller i stedet for direkte til individuelle brugere og tildeler derefter brugere til roller. Dette løser udfordringen med at tildele individuelle tilladelser i stor skala. Almindelige roller i virksomhedsmiljøer er: admin, auditor, developer, HR_manager, finance_analyst. Når en ny medarbejder begynder, føjes vedkommende til den relevante rolle og arver straks alle de tilladelser, som rollen kræver. Når en medarbejder skifter stilling, ændres rollen, og tilladelserne tilpasses automatisk. RBAC er den dominerende model i virksomheders IAM-systemer.

RBAC's primære fordel er administrativ skalerbarhed. Ændring af en roles tilladelser påvirker straks alle brugere i rollen — det er ikke nødvendigt at opdatere individuelle brugerposter på tværs af hundredvis af systemer. RBAC understøtter naturligt funktionsadskillelse ved at sikre, at ingen enkelt rolle har modstridende tilladelser (f.eks. en rolle, der både kan oprette og godkende finansielle transaktioner). RBAC forenkler også compliance: revisorer kan gennemgå roller og deres tilladelser i stedet for at revidere tusindvis af individuelle brugertildelinger. Begrænsningen er rolleeksplosion — organisationer opretter sommetider for mange detaljerede roller, hvilket skaber en administrationskompleksitet, der undergraver fordelen ved skalerbarhed.

Rule-Based Access Control (må ikke forveksles med RBAC) giver eller nægter adgang baseret på et sæt betingede regler i stedet for udelukkende identitet eller rolle. Firewallregler er det klassiske eksempel: »Tillad TCP fra 192.168.1.0/24 til alle på port 443. Afvis al anden trafik.« Adgangen evalueres mod reglerne i rækkefølge, indtil der findes et match. Regelbaseret kontrol kombineres ofte med andre modeller: MAC bruger sikkerhedsmærkater som regler, og Attribute-Based Access Control (ABAC) udvider den regelbaserede logik til samtidig at evaluere flere attributter (brugerens afdeling, enhedstype, tidspunkt på dagen, ressourceklassifikation) for at træffe detaljerede beslutninger.

ABAC (Attribute-Based Access Control) er den mest fleksible og detaljerede adgangskontrolmodel. Adgangsbeslutninger evaluerer flere attributter samtidigt: subjekters attributter (brugerens afdeling, sikkerhedsgodkendelsesniveau, placering), objekters attributter (dataklassifikation, ejerens afdeling, opbevaringsmærkat), miljøattributter (tidspunkt på dagen, enhedstype, netværksplacering) og handlingsattributter (læs, skriv, slet). En politik kan sige: »Tillad adgang, hvis user.department = Finance OG resource.classification = Internal OG device.type = corporate OG time.hour BETWEEN 8 AND 18.« ABAC muliggør beslutninger i henhold til zero-trust-politikker og implementeres af produkter som XACML og cloud-IAM-politikmotorer.

Den rette adgangskontrolmodel afhænger af sikkerhedskravene og den organisatoriske kontekst. DAC: egnet til personlig databehandling og små teams, hvor bekvemmelighed prioriteres over streng kontrol. MAC: påkrævet i klassificerede offentlige og militære miljøer med streng informationsopdeling. RBAC: ideel til virksomheder, hvor administrativ skalerbarhed er afgørende, og rollerne passer tydeligt til jobfunktionerne. ABAC: egnet til cloudmiljøer og zero-trust-arkitekturer, hvor der er behov for kontekstbevidste, detaljerede politikker. I praksis bruger de fleste organisationer en kombination: RBAC som fundament med ABAC til kontekstafhængige adgangsbeslutninger.

Uanset modellen for adgangskontrol er adgangskontrollister (ACL'er) den mest almindelige tekniske implementeringsmekanisme. En ACL, der er knyttet til en ressource, angiver, hvilke subjekter der kan udføre hvilke handlinger. Filsystemets ACL'er (Windows NTFS, Linux POSIX-ACL'er) styrer adgangen til filer og mapper. Netværks-ACL'er styrer trafikflowet på router- eller cloud-netværksniveau. Database-ACL'er styrer adgangen på tabel- og rækkeniveau. ACL'er kan implementere alle de modeller, der er gennemgået: En fils ACL implementerer DAC, når ejeren styrer den; en sikkerhedsplatforms ACL implementerer MAC, når mærkater bestemmer posterne; og en applikations ACL implementerer RBAC, når posterne henviser til roller.

I denne lektion har du lært, at DAC lader ressourceejere styre adgangen (fleksibelt, men risikabelt); MAC bruger systemhåndhævede sikkerhedsmærkater (strengt og anvendt i klassificerede miljøer); RBAC tildeler tilladelser til roller, så løsningen kan skaleres i virksomheder; og ABAC evaluerer flere attributter for detaljerede beslutninger baseret på zero trust. Dernæst ser vi på fødereret identitet: SAML, OAuth og OpenID Connect.