Hvordan fungerer IAM-roller og -politikker i dybden?

Question

Accepted Answer

Ud over basis-IAM er forståelse af **roller** (antagne identiteter), **politiktyper og evaluering** (hvordan tilladelser bestemmes) og mønstre som **tværkonto-adgang** og **serviceroller** vigtig for sikker, velbygget AWS-adgangsstyring.

## Roller i dybden — hvem antager hvad

```text
A ROLE has TWO key policies:
  TRUST POLICY → WHO can assume the role (which principals: a service, account, user)
  PERMISSION POLICIES → WHAT the role can do once assumed
Use cases:
  → SERVICE roles — an EC2/Lambda assumes a role to access AWS (no embedded keys)
  → CROSS-ACCOUNT — account B's role trusts account A → A's users assume it (controlled access)
  → FEDERATION/SSO — external identities assume roles (temporary credentials)
→ Roles give TEMPORARY credentials (auto-rotated) — far safer than long-lived keys.
```

## Politiktyper

```text
IDENTITY-BASED → attached to users/groups/roles (what THEY can do)
RESOURCE-BASED → attached to a resource (e.g. an S3 bucket policy: who can access IT)
PERMISSION BOUNDARIES → a max-permissions limit on an identity (cap delegated permissions)
SCPs (Service Control Policies) → org-wide guardrails (limit what accounts can do)
→ Effective permissions = the combination, with rules for how they interact.
```

## Politikevaluering (hvordan adgang bestemmes)

```text
1. Explicit DENY anywhere → DENIED (deny always wins)
2. Else, an explicit ALLOW (from identity/resource policy) within bounds → ALLOWED
3. Else (no allow) → DENIED (default deny)
→ Default deny; explicit deny overrides any allow; you need an allow + no deny + within
  any boundaries/SCPs.
```

## Hvorfor det betyder noget

At forstå IAM-roller og -politikker i dybden er vigtig for **sikker, velbygget AWS-adgangsstyring**, så det er værdifuld viden ud over IAM-grundlæggende.

At forstå **roller i dybden** — deres **trust policy** (hvem der kan antage rollen) og **permission policies** (hvad den kan gøre) — er nøglen til de vigtigste sikre adgangsmønstre: **serviceroller** (som giver EC2-instanser og Lambda-funktioner adgang til AWS-ressourcer via midlertidige, automatisk-roterede legitimationsoplysninger i stedet for indlejrede langlivede nøgler — en kritisk sikkerhedspraksis), **tværkonto-adgang** (kontrolleret adgang mellem AWS-konti via rolantagen) og **federation/SSO** (eksterne identiteter antager roller til midlertidig adgang).

Roller, der giver midlertidige legitimationsoplysninger i stedet for langlivede nøgler, er en grundlæggende sikkerhedsforbedring.

At forstå **politiktyperne** — identitetsbaseret (hvad brugere/roller kan gøre), ressourcebaseret (som S3-bucket-politikker, der kontrollerer hvem der kan få adgang til en ressource), permission boundaries (som sætter loft over delegerede tilladelser) og SCP'er (organisationsomfattende sikkerhedsgranser) — er nødvendigt for sofistikeret adgangskontrol i rigtige organisationer.

At forstå **politikevalueringlogik** (standard-nægt; en eksplicit nægt overalt vinder altid; du har brug for en eksplicit tilladelse inden for eventuelle grænser og ingen nægt) er essentiel for korrekt at kunne tænke over, hvilke tilladelser der faktisk gælder — en almindelig kilde til forvirring, hvor manglende forståelse fører til enten for bred adgang (sikkerhedsrisiko) eller uventede nægtelser (operationel friktion).

Da sikker adgangsstyring er kritisk for AWS-sikkerhed (og IAM-fejlkonfigurationer er en ledende årsag til brud), og da forståelse af roller i dybden (for sikre legitimationsoplysninger-fri adgangsmønstre), politiktyper (for lagdelt kontrol) og politikevaluering (for korrekt ræsonnering om tilladelser) er nødvendig for velbygget, sikker adgang, er forståelse af IAM-roller og -politikker i dybden værdifuld, praktisk vigtig AWS-viden for sikkerhed — som bygger på IAM-grundlæggende for at muliggøre de sikre adgangsmønstre og korrekte tilladelsesræsonneringer, som professionel AWS-sikkerhed kræver, et vigtig område hvor dybde af forståelse direkte påvirker sikkerhedsstilling.