Hvordan fungerer tilgangskontroll (RBAC, minste rettighet)?

Question

Accepted Answer

**Tilgangskontroll** styrer hva autentiserte brukere kan gjøre — gjennom modeller som **RBAC** (Role-Based Access Control) og prinsipper som **minste rettighet**. Riktig tilgangskontroll er kritisk, siden brutt tilgangskontroll er OWASPs #1 sårbarhet.

## Tilgangskontrollmodeller

```text
RBAC (Role-Based Access Control) → assign users to ROLES; roles have PERMISSIONS:
  → user → role(s) (admin, editor, viewer) → permissions → access decisions
  → manageable, common; change a role's permissions, all its users update
ABAC (Attribute-Based) → decisions based on ATTRIBUTES (user, resource, context) → flexible,
  fine-grained (e.g. "editors can edit docs in their department during business hours")
ACLs → per-resource lists of who can do what
```

## Prinsippet om minste rettighet

```text
LEAST PRIVILEGE → grant the MINIMUM access needed to do the job, nothing more:
  → limits the BLAST RADIUS if an account/component is compromised
  → applies to users, services, processes, database accounts, API keys, etc.
→ a foundational security principle (default to LESS access; grant more only as needed)
```

## Implementering av tilgangskontroll på en sikker måte

```text
⚠️ BROKEN ACCESS CONTROL is OWASP #1 — common and serious:
✓ ENFORCE authorization on the SERVER for EVERY protected action/resource (never trust
  the client; don't rely on hiding UI elements)
✓ Check the user is authorized for the SPECIFIC resource (prevent IDOR — accessing
  others' data by changing an ID)
✓ DENY by default; verify on each request; centralize authorization logic
✓ Test access control (a common gap — easy to miss authorization checks)
```

## Hvorfor det er viktig

Å forstå tilgangskontroll er viktig fordi det **styrer hva brukere kan gjøre og er kritisk for sikkerhet** — brutt tilgangskontroll er OWASPs #1 sårbarhet — så det er verdifull, praktisk-kritisk sikkerhetskunnskap.

Tilgangskontroll bestemmer hva autentiserte brukere har tillatelse til å gjøre, og det er avgjørende å få det riktig.

Å forstå **modellene** — **RBAC** (tildele brukere til roller som har tillatelser — håndterlig og vanlig), **ABAC** (attributtbaserte beslutninger for fleksibel, detaljert kontroll), og ACLs (tillatelseslister per ressurs) — gir rammeverket for å strukturere tillatelser, med RBAC som den vanligste å forstå.

Å forstå **prinsippet om minste rettighet** — tildele **minimum tilgang som trengs**, som **begrenser skadepotensial hvis en konto eller komponent blir kompromittert** — er et grunnleggende sikkerhetsprinsipp som gjelder bredt (brukere, tjenester, databasekontoer, API-nøkler), og et av de viktigste sikkerkonseptene.

Kritisk er det å forstå hvordan man **implementerer tilgangskontroll på en sikker måte** som adresserer #1 sårbarheten: **håndheve autorisasjon på serveren for hver beskyttet handling** (aldri stole på klienten eller basere seg på skjult UI — en vanlig feil), **sjekke autorisasjon for den spesifikke ressursen** (forhindre IDOR, der brukere får tilgang til andres data ved å endre en ID — en vanlig brutt-tilgangskontroll-feil), **nekte som standard**, verifisere på hver forespørsel, og **teste tilgangskontroll** (et vanlig gap, siden manglende autorisasjonsjekker er lett å overse).

Siden tilgangskontroll styrer hva brukere kan gjøre og brutt tilgangskontroll er den øverste sårbarheten (vanlig og alvorlig), og siden å forstå modellene (RBAC), prinsippet om minste rettighet, og sikker implementering (server-side håndhevelse, ressurs-spesifikke sjekker, nekt som standard) er kritisk for sikkerhet, er å forstå tilgangskontroll verdifull, praktisk-kritisk sikkerhetskunnskap — som adresserer #1 sikkerhetrisikoen, er fundamental for å kontrollere hva brukere kan gjøre, og er essensielt for å unngå brutt-tilgangskontroll-feilene (som IDOR og manglende autorisasjonsjekker) som er blant de vanligste og alvorligste sårbarhetene.