Autorisasjonsmodeller: RBAC, MAC og DAC
Sammenlign rollebasert, obligatorisk og skjønnsbasert tilgangskontroll, og lær når hver modell egner seg i virksomheter og offentlige organisasjoner.
Autorisasjonsmodeller: RBAC, MAC og DAC er en gratis leksjon i Security+ Academy på CoddyKit. Dette er leksjon 3 av 4. Du kan lese valgfritt 3 leksjoner fra denne læringsstien gratis i sin helhet – deretter låser CoddyKit PRO opp alle leksjoner, samt praktisk øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Security+ Academy, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Security+ Academy inneholder totalt 4 leksjoner.
Oversikt over tilgangskontrollmodeller
Tilgangskontrollmodeller definerer reglene og policyene som styrer hvilke subjekter (brukere, prosesser) som kan få tilgang til hvilke objekter (filer, systemer, data). Valgt modell avgjør hvem som kan gi tilgang, hvordan tillatelser tildeles, og hvordan håndhevingen fungerer. Security+-eksamen dekker fire hovedmodeller: Discretionary Access Control (DAC), Mandatory Access Control (MAC), Role-Based Access Control (RBAC) og Rule-Based Access Control. Det er avgjørende å forstå styrkene til hver modell og når den passer, for å kunne utforme effektive autorisasjonssystemer.
Discretionary Access Control (DAC)
I Discretionary Access Control (DAC) bestemmer ressurseieren selv hvem som får tilgang til ressursene, og kan gi eller tilbakekalle tilgang for andre brukere. Det «discretionary» aspektet er at eierne bestemmer – systemet håndhever beslutningene deres, men dikterer dem ikke. Dette er modellen som brukes i de fleste personlige datamiljøer (Windows NTFS-filtillatelser, Linux/Unix-filtillatelser). Sikkerhetsbegrensningen ved DAC er at hver ressurseier må ta riktige tilgangsbeslutninger. En bruker som får tilgang til en fil, kan gi denne tilgangen videre til andre uten at en administrator involveres, noe som kan spre sensitive data til flere enn de var ment for.
# DAC example: Linux file permissions (owner controls access)
# Create a file and check default permissions
touch confidential_data.txt
ls -la confidential_data.txt
# -rw-rw-r-- 1 alice users (owner=alice, can read/write; group can read/write; others read)
# Owner (Alice) discretionarily removes all access for others
chmod 600 confidential_data.txt
# -rw------- 1 alice users (only Alice can read/write)
# Alice grants read to a specific user via ACL
setfacl -m u:bob:r confidential_data.txtDAC-risikoer: problemet med den forvirrede stedfortrederen
DAC har to iboende sikkerhetsrisikoer. Transitiv tilgang: Bruker A gir bruker B tilgang, og bruker B gir bruker C tilgang – den opprinnelige eieren vet kanskje ikke engang at C har tilgang til ressursen. Problemet med den forvirrede stedfortrederen: Et privilegert program som handler på vegne av en bruker med færre privilegier, kan utilsiktet bruke privilegiene sine på en måte brukeren ikke kunne gjort direkte. I DAC-miljøer kan én kompromittert konto potensielt få tilgang til alle ressursene brukeren har fått tilgang til, og kan gi andre tilgang før kompromitteringen oppdages. DAC er praktisk, men skaper utfordringer når informasjon må holdes strengt avgrenset.
Mandatory Access Control (MAC)
I Mandatory Access Control (MAC) håndhever operativsystemet tilgangspolicyer basert på sikkerhetsetiketter som er tildelt både subjekter (brukere) og objekter (data). Brukere kan ikke overstyre eller endre disse policyene – bare systemadministratoren eller sikkerhetspolicyen kan endre dem. MAC brukes i klassifiserte offentlige og militære miljøer der data må holdes strengt adskilt. En bruker med sikkerhetsklareringen «Secret» får ikke tilgang til data merket «Top Secret», selv om dataeieren ønsker å gi tilgang. Bell-LaPadula-modellen (ingen lesing oppover, ingen skriving nedover) og Biba-modellen (ingen skriving oppover, ingen lesing nedover) er formelle MAC-implementeringer.
# SELinux is a MAC implementation for Linux
# Check SELinux mode and policy
getenforce # Enforcing / Permissive / Disabled
sestatus # Detailed SELinux status
# View SELinux security context labels on files
ls -Z /etc/passwd
# system_u:object_r:passwd_file_t:s0 /etc/passwd
# Security context: user:role:type:level
# A process can only access files where its type has explicit permission
sudo ausearch -m avc -ts recent # View MAC policy denialsBell-LaPadula- og Biba-MAC-modellene
To formelle MAC-modeller uttrykker sikkerhetsmål som matematiske regler. Bell-LaPadula fokuserer på konfidensialitet: Subjekter kan ikke lese data over klassifiseringsnivået sitt (ingen lesing oppover), og de kan ikke skrive data til et lavere klassifiseringsnivå (ingen skriving nedover). Dette hindrer at sensitiv informasjon flyter til uautoriserte brukere. Biba fokuserer på integritet: Subjekter kan ikke skrive til et høyere integritetsnivå (ingen skriving oppover), og de kan ikke lese fra et lavere integritetsnivå (ingen lesing nedover). Biba hindrer at data med høy integritet blir forurenset av inndata med lav integritet. Reelle MAC-systemer (som SELinux) kombinerer aspekter fra begge modellene.
Role-Based Access Control (RBAC)
Role-Based Access Control (RBAC) tildeler tillatelser til roller i stedet for direkte til enkeltbrukere, og tildeler deretter brukere til roller. Dette løser utfordringen med å tildele individuelle tillatelser i stor skala. Vanlige roller i virksomhetsmiljøer er: admin, auditor, developer, HR_manager og finance_analyst. Når en ny ansatt begynner, legges vedkommende til i riktig rolle og arver umiddelbart alle tillatelsene rollen krever. Når en ansatt bytter stilling, endres rollen, og tillatelsene justeres automatisk. RBAC er den dominerende modellen i virksomheters IAM-systemer.
# RBAC example (database permissions)
# Create roles and assign permissions
CREATE ROLE readonly_analyst;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly_analyst;
CREATE ROLE data_engineer;
GRANT SELECT, INSERT, UPDATE ON customer_data TO data_engineer;
# Assign users to roles
GRANT readonly_analyst TO alice;
GRANT data_engineer TO bob;
# When Alice is promoted: revoke old role, grant new one
REVOKE readonly_analyst FROM alice;
GRANT data_engineer TO alice;Fordeler med RBAC: skalerbarhet og separasjon av oppgaver
RBACs viktigste fordel er administrativ skalerbarhet. Når tillatelsene til en rolle endres, påvirker det umiddelbart alle brukerne i rollen – det er ikke nødvendig å oppdatere individuelle brukeroppføringer på tvers av hundrevis av systemer. RBAC støtter naturlig separasjon av oppgaver ved å sikre at ingen enkeltrolle har motstridende tillatelser (for eksempel en rolle som både kan opprette og godkjenne økonomiske transaksjoner). RBAC forenkler også samsvarskontroll: Revisorer kan gjennomgå roller og tillatelsene deres i stedet for å kontrollere tusenvis av individuelle brukertildelinger. Begrensningen er rollekspansjon – organisasjoner oppretter noen ganger for mange finmaskede roller, noe som skaper en administrativ kompleksitet som svekker skaleringsfordelen.
Rule-Based Access Control
Rule-Based Access Control (må ikke forveksles med RBAC) gir eller nekter tilgang basert på et sett med betingede regler, i stedet for utelukkende på identitet eller rolle. Brannmurregler er det klassiske eksempelet: «Allow TCP from 192.168.1.0/24 to any on port 443. Deny all other traffic.» Tilgangen evalueres mot reglene i rekkefølge til et samsvar blir funnet. Regelbasert kontroll kombineres ofte med andre modeller: MAC bruker sikkerhetsetiketter som regler, og Attribute-Based Access Control (ABAC) utvider regelbasert logikk ved å evaluere flere attributter (brukerens avdeling, enhetstype, tidspunkt på dagen, ressursens klassifisering) samtidig for finmaskede beslutninger.
# Rule-based access control: iptables firewall rules
# Rules are evaluated in order; first match wins
# Allow established/related connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow specific source IP to SSH
iptables -A INPUT -s 10.0.0.100 -p tcp --dport 22 -j ACCEPT
# Allow HTTPS from anywhere
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# Default deny all other inbound
iptables -A INPUT -j DROPAttribute-Based Access Control (ABAC)
ABAC (Attribute-Based Access Control) er den mest fleksible og finmaskede tilgangskontrollmodellen. Tilgangsbeslutninger evaluerer flere attributter samtidig: subjektattributter (brukerens avdeling, klareringsnivå, plassering), objektattributter (dataklassifisering, eieravdeling, oppbevaringsetikett), miljøattributter (tidspunkt på dagen, enhetstype, nettverksplassering) og handlingsattributter (lese, skrive, slette). En policy kan si: «Allow access if user.department = Finance AND resource.classification = Internal AND device.type = corporate AND time.hour BETWEEN 8 AND 18.» ABAC muliggjør policybeslutninger basert på nulltillit og implementeres av produkter som XACML og policy-motorer for skybasert IAM.
Velge riktig modell
Valg av tilgangskontrollmodell avhenger av sikkerhetskravene og organisasjonens kontekst. DAC: egner seg for personlig databehandling og små team der brukervennlighet prioriteres fremfor streng kontroll. MAC: kreves i klassifiserte offentlige og militære miljøer med streng informasjonsavgrensning. RBAC: er ideell for virksomheter der administrativ skalerbarhet er avgjørende, og roller samsvarer tydelig med arbeidsfunksjoner. ABAC: passer for skymiljøer og nulltillitsarkitekturer der det er behov for kontekstbevisste og finmaskede policyer. I praksis bruker de fleste organisasjoner en kombinasjon: RBAC som grunnlag, med ABAC for kontekstfølsomme tilgangsbeslutninger.
Tilgangskontrollister (ACL-er)
Uavhengig av tilgangskontrollmodellen er tilgangskontrollister (ACL-er) den vanligste tekniske implementeringsmekanismen. En ACL som er knyttet til en ressurs, angir hvilke subjekter som kan utføre hvilke handlinger. ACL-er for filsystemer (Windows NTFS, Linux POSIX ACL-er) styrer tilgangen til filer og kataloger. Nettverks-ACL-er styrer trafikkflyten på ruter- eller nettsky-nettverksnivå. Database-ACL-er styrer tilgang på tabell- og radnivå. ACL-er kan implementere alle modellene som er omtalt: En fils ACL implementerer DAC når eieren styrer den; en ACL i et sikkerhetssystem implementerer MAC når etiketter bestemmer oppføringene; en ACL i en applikasjon implementerer RBAC når oppføringene refererer til roller.
# Windows NTFS ACL example using icacls
# View current ACL on a folder
icacls 'C:\Sensitive\HR_Data'
# BUILTIN\Administrators:(OI)(CI)(F) <- Full control
# CONTOSO\HR_Team:(OI)(CI)(RX) <- Read and Execute
# Grant specific permissions to HR Managers group
icacls 'C:\Sensitive\HR_Data' /grant 'CONTOSO\HR_Managers:(OI)(CI)(M)'
# (OI)=Object Inherit, (CI)=Container Inherit, (M)=Modify
# Remove access for a former contractor
icacls 'C:\Sensitive\HR_Data' /remove 'CONTOSO\contractors'Hurtigsjekk
Test forståelsen Deres av CompTIA Security+ (SY0-701)-begrepene fra denne leksjonen.
Oppsummering av leksjonen
I denne leksjonen har De lært at DAC lar ressurseiere styre tilgangen (fleksibelt, men risikabelt); MAC bruker sikkerhetsetiketter som håndheves av systemet (strengt og brukt i miljøer med sikkerhetsgradert informasjon); RBAC tildeler tillatelser til roller for skalerbarhet i virksomheter; og ABAC evaluerer flere attributter for finmaskede beslutninger basert på nulltillit. Neste tema er Federated Identity: SAML, OAuth, and OpenID Connect.
Lær deg Security+ Academy med en AI-veileder – gratis
Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.
- Kurs
- 30
- Leksjoner
- 120
Ofte stilte spørsmål
Er leksjonen «Autorisasjonsmodeller: RBAC, MAC og DAC» gratis?
Ja – du kan lese valgfritt 3 av leksjonene i læringsstien Security+ Academy, inkludert «Autorisasjonsmodeller: RBAC, MAC og DAC», gratis i sin helhet her på nettet. Deretter låser CoddyKit PRO opp alle leksjoner, samt interaktiv øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Kurset i Security+ Academy inneholder totalt 4 leksjoner.
Hva lærer jeg i «Autorisasjonsmodeller: RBAC, MAC og DAC»?
Sammenlign rollebasert, obligatorisk og skjønnsbasert tilgangskontroll, og lær når hver modell egner seg i virksomheter og offentlige organisasjoner. Du øver på Security+ Academy med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.
Trenger jeg erfaring for å begynne med Security+ Academy?
Ingen tidligere erfaring er nødvendig. Security+ Academy på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 3 av 4.
Hvor lang tid tar leksjonen «Autorisasjonsmodeller: RBAC, MAC og DAC»?
De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.
Kan jeg skrive og kjøre kode i denne Security+ Academy-leksjonen?
Ja. Alle Security+ Academy-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.
Alle leksjonene i dette kurset
- Passordregler og multifaktorautentisering
- Biometri og tokenbasert autentisering
- Autorisasjonsmodeller: RBAC, MAC og DAC
- Føderert identitet: SAML, OAuth og OpenID Connect