AWS IAM Access Control: Politikker, roller og best practices

AWS Identity and Access Management (IAM) er den tjeneste, der styrer autentificering og autorisation for hvert eneste API-kald til dit AWS-miljø. Den afgør, hvem der kan logge ind, hvilke handlinger de kan udføre, og på hvilke ressourcer — på tværs af alle AWS-tjenester, i alle regioner, for hver konto. At få IAM korrekt konfigureret er ikke valgfrit; ifølge AWS' egne analyser efter hændelser er fejlkonfigurerede IAM-politikker involveret i størstedelen af de cloud-sikkerhedsbrud, der når offentligheden. Denne artikel dækker IAM's arkitektur, dens policy-evalueringslogik, praktiske mønstre til skalering af adgangskontrol og de operationelle fejl, Opsios SOC gentagne gange støder på i hundredvis af AWS-konti.

Vigtigste pointer

• AWS IAM er den grundlæggende tjeneste til at styre, hvem der kan gøre hvad på tværs af alle AWS-ressourcer — og fejlkonfiguration er den hyppigste årsag til sikkerhedshændelser i cloud.
• Effektiv IAM kræver lagdeling af identity policies, resource policies, permission boundaries og Service Control Policies — ikke blot at vedhæfte managed policies til brugere.
• Organisationer underlagt NIS2, GDPR eller DPDPA 2023 skal behandle IAM-konfiguration som en compliancekontrol, ikke blot en operationel bekvemmelighed.
• ABAC (attribute-based access control) med tags er nu det anbefalede skaleringsmønster for organisationer med mere end en håndfuld konti, men de fleste teams benytter stadig RBAC som standard.
• De største IAM-fejl, Opsios SOC efterforsker, er ikke privilege escalations — det er forældede credentials og over-permitterede serviceroller, som ingen gennemgår.

Sådan fungerer AWS IAM: Kernemodellen

IAM opererer efter en default-deny-model. Hvert AWS API-request evalueres mod et sæt politikker, og medmindre evalueringen producerer et eksplicit Allow — uden at et Deny tilsidesætter det — afvises forespørgslen. At forstå denne evalueringskæde er det absolut vigtigste koncept inden for AWS-adgangskontrol.

Principals, Actions, Resources og Conditions

Hvert IAM-policystatement har fire komponenter:

• Principal — den entitet, der foretager forespørgslen (IAM-bruger, IAM-rolle, federeret identitet, AWS-tjeneste)
• Action — den specifikke API-operation (s3:GetObject, ec2:RunInstances, iam:CreateUser)
• Resource — den eller de ARN'er, handlingen vedrører
• Condition — valgfri begrænsninger (kilde-IP, MFA-status, tidspunkt, resource tags)

En politikker et JSON-dokument, der indeholder et eller flere statements, hver med en Effect på Allow eller Deny. Styrken — og kompleksiteten — opstår, når flere politikker interagerer under evaluering.

Policy-evalueringskæden

Når en principal foretager en forespørgsel inden for en AWS Organization, følger evalueringen denne rækkefølge:

1. Service Control Policies (SCP'er) — organisationsniveauets guardrails, der sætter de maksimale tilladelser for medlemskonti

2. Resource-based policies — knyttet til selve ressourcen (f.eks. S3 bucket policies, KMS key policies)

3. IAM permission boundaries — de maksimale tilladelser, en IAM-entitet kan have, uanset dens identity policies

4. Session policies — overført ved role assumption, som yderligere afgrænser sessionen

5. Identity-based policies — de politikker, der er knyttet til IAM-brugeren, gruppen eller rollen

Et eksplicit Deny på et hvilket som helst niveau tilsidesætter alle Allow-statements. Denne lagdelte model betyder, at man kan håndhæve organisationsdækkende guardrails (via SCP'er), selv hvis individuelle kontoadministratorer forsøger at tildele bredere adgang.

At forstå denne kæde er ikke akademisk — Opsios NOC sporer regelmæssigt access-denied-fejl til SCP-begrænsninger, som kontoadministratorer ikke kendte til. Hvis du fejlsøger en 403 på et API-kald, hvor identity policy tydeligt siger Allow, så tjek SCP'erne først.

IAM-byggesten i praksis

IAM Users vs. IAM Roles vs. Federated Identities

IAM users er langlivede identiteter med permanente credentials. De eksisterer stadig og virker stadig, men for menneskelige operatører bør de betragtes som legacy. AWS' nuværende vejledning — og Opsios operationelle holdning — er at federere menneskelig adgang gennem IAM Identity Center (tidligere AWS SSO), som udsteder midlertidige credentials via SAML 2.0 eller OIDC.

IAM roles er arbejdshestene i moderne AWS IAM. En rolle har ingen permanente credentials; i stedet antager principals rollen og modtager midlertidige sikkerhedstokens (via AWS STS). Roller bruges til:

• Adgang på tværs af konti (Account A's workload antager en rolle i Account B)
• Service-til-service-adgang (en EC2 instance profile, en Lambda execution role)
• Menneskelig adgang via federation (antag en rolle efter autentificering gennem din IdP)

Federated identities autentificerer mod en ekstern identity provider (Okta, Azure AD / Entra ID, Google Workspace) og antager IAM-roller. Dette er det mønster, enhver organisation med mere end ti udviklere bør bruge til konsol- og CLI-adgang.

IAM Policies: Managed, Inline og Custom

AWS managed policies (f.eks. ReadOnlyAccess, PowerUserAccess) vedligeholdes af AWS og dækker gængse mønstre. De er bekvemme, men ofte for brede til produktionsbrug. AdministratorAccess er den hyppigst vedhæftede managed policy, Opsios SOC finder i revisionsresultater — og den er næsten aldrig berettiget til daglig drift.

Customer managed policies er det rigtige standardvalg. Skriv dem selv, afgræns dem til dine faktiske workloads, versionsstyr dem i Git, og deploy dem via Infrastructure as Code (Terraform, CloudFormation eller CDK).

Inline policies er indlejret direkte i en bruger, gruppe eller rolle. De har et strengt 1:1-forhold. Brug dem kun, når en politikker ikke ved et uheld må knyttes til en anden entitet — hvilket er sjældent.

Service Control Policies (SCP'er)

SCP'er er det mest kraftfulde — og mest misforståede — lag i IAM-stakken. De tildeler ikke tilladelser; de definerer den maksimale grænse for, hvad en principal i en medlemskonto kan gøre. En SCP, der nægter s3:DeleteBucket, betyder, at ingen i den konto kan slette en bucket, selv med AdministratorAccess.

Praktiske SCP-mønstre, Opsio deployerer for kunder:

• Regionsbegrænsning — afvis alle handlinger uden for eu-north-1, eu-west-1 og eu-central-1 (håndhævelse af datasuverænitet under GDPR og dansk lovgivning, herunder Datatilsynets vejledninger)
• Guardrail-SCP'er — forhindre deaktivering af CloudTrail, sletning af VPC flow logs eller ændring af audit-IAM-rollen
• Service deny-list — bloker tjenester, organisationen ikke anvender (f.eks. Lightsail, GameLift) for at reducere angrebsfladen

AWS-sikkerhedsguardrails

RBAC vs. ABAC: Valg af den rigtige model

RBAC (Role-Based Access Control)

RBAC i AWS betyder at oprette distinkte IAM-roller for hver jobfunktion — DevOps-Engineer, Data-Analyst, Security-Auditor — og knytte politikker til disse roller. Det er intuitivt og fungerer godt, når:

• Du har færre end ca. 20 distinkte roller
• Teams er klart adskilte
• Kontoudbredelsen er begrænset

Ulempen er kombinatorisk eksplosion. Har du 5 jobfunktioner, 4 miljøer (dev/staging/prod/sandbox) og 3 projekter, kan du have brug for 60 rolledefinitioner — hver med separate politikker.

ABAC (Attribute-Based Access Control)

ABAC bruger tags på både principals og ressourcer til at træffe autorisationsbeslutninger. I stedet for 60 roller skriver du et mindre sæt politikker med betingelser som:

```json

"Condition": {

"StringEquals": {

"aws:ResourceTag/Project": "${aws:PrincipalTag/Project}",

"aws:ResourceTag/Environment": "${aws:PrincipalTag/Environment}"

}

}

```

Dette lader en udvikler tagget Project=payments, Environment=dev kun tilgå ressourcer tagget på samme måde — uden at oprette projekt- eller miljøspecifikke roller.

AWS' IAM-dokumentation anbefaler eksplicit ABAC som den foretrukne model til skalering. I praksis bruger de fleste organisationer, Opsio administrerer, en hybrid: RBAC til bred jobfunktionsadskillelse, ABAC til finkornet ressourceafgrænsning inden for disse roller.

Den operationelle faldgrube: ABAC fungerer kun, hvis din tagging er disciplineret. Tagger teams ikke konsekvent deres ressourcer, fejler betingelserne åbent eller lukket på uforudsigelige måder. Håndhæv tagging med SCP'er og AWS Config-regler, før du satser på ABAC.

Tag governance og FinOps

IAM Best Practices: Hvad der reelt har betydning

AWS Well-Architected Frameworks Security Pillar definerer IAM best practices på tværs af fem områder. Her er, hvad vi ser betyde mest i produktion — ikke teori:

1. Eliminer langlivede access keys

Hver access key er et credential, der kan eksfiltreres. Opsios SOC har efterforsket hændelser, hvor access keys committet til offentlige GitHub-repos blev udnyttet inden for minutter af automatiserede scannere. Løsningen:

• Brug IAM-roller med midlertidige credentials til alle workloads (EC2 instance profiles, ECS task roles, Lambda execution roles)
• Federer menneskelig adgang via IAM Identity Center
• For de sjældne tilfælde, hvor access keys er uundgåelige (legacy-integrationer), håndhæv rotation via AWS Config-reglen access-keys-rotated med en maksimal alder på 90 dage

2. Håndhæv MFA — overalt hvor det betyder noget

MFA på root-kontoen er et minimumskrav. Men håndhæv også MFA for:

• Alle menneskelige IAM-brugere (hvis du stadig har dem)
• Role assumption for følsomme roller (iam:AssumeRole med Condition: { "Bool": { "aws:MultiFactorAuthPresent": "true" }})
• IAM Identity Center-autentificeringsflowet (push notification MFA, ikke SMS)

3. Anvend least privilege iterativt

Ingen rammer least privilege rigtigt i første forsøg. Den praktiske tilgang:

1. Start med AWS managed policies, der er lidt bredere end nødvendigt

2. Aktiver IAM Access Analyzer for at overvåge, hvilke tilladelser der faktisk bruges

3. Generer efter 30-90 dage en least-privilege-politikker baseret på CloudTrail-adgangsaktivitet

4. Erstat den brede politikker med den genererede

5. Gentag kvartalsvis

IAM Access Analyzers politikgenereringsfunktion er oprigtigt nyttig og underudnyttet. Den læser CloudTrail-logs og producerer en afgrænset politikker, der kun matcher de handlinger og ressourcer, der faktisk er blevet kaldt.

4. Brug permission boundaries til delegeret administration

Hvis du tillader udviklere eller teamledere at oprette IAM-roller (f.eks. til Lambda-funktioner), sæt en permission boundary, der begrænser, hvad disse oprettede roller kan gøre. Uden dette kan en udvikler oprette en rolle med AdministratorAccess — hvilket er en privilege escalation-sti.

5. Auditér løbende, ikke årligt

En årlig IAM-gennemgang er en afkrydsningsøvelse. I stedet:

• Kør IAM Access Analyzer løbende for at opdage ekstern og ubenyttet adgang
• Overvåg for anomale IAM API-kald via CloudTrail + Amazon GuardDuty
• Brug AWS Config-regler til automatisk at flagge ikke-compliant IAM-konfigurationer
• Led resultater ind i en centraliseret SIEM eller din SOC's alarmpipeline

24/7 SOC-overvågning

IAM i en multi-account AWS Organization

Enkelt-konto AWS-miljøer er stadig sjældnere i produktion. AWS Organizations, kombineret med IAM Identity Center, er standardmønstret til at styre adgang på tværs af ti eller hundredvis af konti.

IAM Identity Center (tidligere AWS SSO)

IAM Identity Center giver ét centralt sted til at styre menneskelig adgang på tværs af alle konti i din organisation. Brugere autentificerer sig én gang (via din virksomheds IdP eller det indbyggede directory) og modtager midlertidige credentials for den konto og det tilladelsessæt, de vælger.

Permission sets i IAM Identity Center er abstraktioner, der opretter IAM-roller i hver målkonto. Du definerer dem centralt én gang og tildeler dem til brugere eller grupper per konto. Det er drastisk enklere end at administrere IAM-roller uafhængigt i hver konto.

Cross-Account Role Assumption

Til service-til-service-adgang på tværs af konti (f.eks. en CI/CD-pipeline i tooling-kontoen, der deployer til produktion) er mønstret:

1. Opret en rolle i målkontoen med en trust policy, der tillader kildekontorollen

2. Kilde-workloaden kalder sts:AssumeRole for at få midlertidige credentials

3. Brug external IDs til at forhindre confused-deputy-angreb, når tredjeparter er involveret

Opsio konfigurerer cross-account-adgang efter en hub-and-spoke-model: en central sikkerhedskonto har audit-roller, der kan læse (men ikke skrive) i alle medlemskonti. Dette design understøtter både SOC-drift og indsamling af complianceevidens.

Multi-account-strategi

Compliancedimensioner: NIS2, GDPR og DPDPA 2023

IAM-konfiguration refereres direkte i alle større complianceframeworks, Opsio møder:

NIS2-direktivet (EU) — Artikel 21 kræver "politikker for adgangskontrol", herunder privileged access management. Organisationer klassificeret som væsentlige eller vigtige enheder skal dokumentere, at IAM-kontroller er proportionale med risikoen, at privilegeret adgang overvåges, og at adgangsgennemgange foretages regelmæssigt. I danske sammenhænge melder Datatilsynet og Center for Cybersikkerhed (CFCS) klare forventninger til implementeringen af NIS2. For AWS betyder det SCP'er, CloudTrail, IAM Access Analyzer og dokumenterede procedurer for adgangsgennemgang.

GDPR — Artikel 32 kræver "evnen til at sikre vedvarende fortrolighed, integritet, tilgængelighed og robusthed af behandlingssystemer og -tjenester," hvilket Datatilsynet fortolker til at omfatte identitets- og adgangsstyring. Dataansvarlige skal dokumentere, at adgang til personoplysninger er begrænset til de medarbejdere, der har behov — hvilket betyder IAM-politikker afgrænset til specifikke DynamoDB-tabeller, S3-præfikser eller RDS-instanser, der indeholder personhenførbare oplysninger.

DPDPA 2023 (Indien) — Sektion 8-forpligtelser for data fiduciaries omfatter implementering af "rimelige sikkerhedsforanstaltninger." For indiske virksomheder med workloads i ap-south-1 (Mumbai) eller ap-south-2 (Hyderabad) betyder det dokumenterede IAM-kontroller, audit trails og evidens for periodisk gennemgang — i ånd lig GDPR's Artikel 32-krav.

Den røde tråd: alle tre frameworks kræver ikke blot, at kontroller eksisterer, men at de overvåges og gennemgås. IAM-konfiguration uden CloudTrail-logning og periodisk adgangsgennemgang opfylder ingen af dem.

Typiske IAM-fejl, Opsios SOC møder

Baseret på faktiske hændelser og revisionsresultater på tværs af vores administrerede konti:

1. Wildcard resource ARN'er i produktionspolitikker — "Resource": "*" er acceptabelt under prototyping. I produktion betyder det, at en kompromitteret principal kan tilgå enhver ressource af den type i kontoen.

2. Serviceroller med AdministratorAccess — Lambda-funktioner og ECS-tasks bør have snævert afgrænsede execution roles. At vedhæfte admin-adgang "fordi det er nemmere" gør enhver applikationssårbarhed til et fuldt kontokompromittering.

3. Ingen SCP-guardrails på medlemskonti — Uden SCP'er kan enhver kontoadministrator tildele sig selv hvad som helst. SCP'er er den eneste mekanisme, der begrænser selv kontoens root-bruger (i medlemskonti).

4. Forældede IAM-brugere og access keys — Vi finder regelmæssigt IAM-brugere for medarbejdere, der forlod organisationen for måneder eller år siden. Brug AWS Configs iam-user-unused-credentials-check-regel og sæt den til at flagge credentials, der ikke er brugt i 45 dage.

5. Ignorering af resource-based policies — S3 bucket policies, KMS key policies og SQS queue policies kan tildele adgang uafhængigt af identity policies. En S3-bucket med "Principal": "*" i sin bucket policy er offentligt tilgængelig, uanset hvor stramme dine IAM-roller er.

Kom godt i gang: En praktisk rækkefølge

For organisationer, der ikke har formaliseret IAM-governance, er her den rækkefølge, der hurtigst giver resultater:

1. Aktiver CloudTrail i alle konti, alle regioner, med logning til en centraliseret S3-bucket i en log archive-konto

2. Aktiver IAM Access Analyzer i hver konto (den er gratis)

3. Migrer menneskelig adgang fra IAM-brugere til IAM Identity Center med MFA

4. Deploy baseline-SCP'er — afvis ubrugte regioner, beskyt audit-infrastruktur, kræv kryptering

5. Auditér eksisterende IAM-roller og politikker — brug Access Analyzers resultater til at identificere ubrugte roller og over-permitterede politikker

6. Implementer Infrastructure as Code for alle IAM-ressourcer — slut med ClickOps i IAM-konsollen

Cloud-migrering og modernisering

Denne rækkefølge fungerer, uanset om du har 2 konti eller 200. Forskellen er, hvor lang tid trin 5 tager.

Ofte stillede spørgsmål

Hvad er IAM access controls?

IAM access controls er de politikker, roller og mekanismer inden for AWS Identity and Access Management, der bestemmer, hvilke principals (brugere, roller, tjenester) der kan udføre hvilke handlinger på hvilke ressourcer. De opererer efter en default-deny-model: medmindre en politikeksplicit tillader en handling, afvises den. Kontrollerne omfatter identity-based policies, resource-based policies, permission boundaries, session policies og Service Control Policies på organisationsniveau.

Er IAM RBAC eller ABAC?

AWS IAM understøtter begge dele. Role-based access control (RBAC) opnås ved at oprette IAM-roller med specifikke tilladelsessæt og tildele dem til brugere eller grupper. Attribute-based access control (ABAC) bruger tags på principals og ressourcer til at træffe dynamiske autorisationsbeslutninger. AWS anbefaler ABAC til skalering på tværs af mange konti, fordi det reducerer antallet af distinkte politikker, der skal administreres. De fleste produktionsmiljøer bruger en hybrid af begge.

Hvad er IAM access i AWS?

IAM access i AWS refererer til den autentificerede og autoriserede adgang, som en principal — en IAM-bruger, federeret identitet eller IAM-rolle — har til at interagere med AWS-tjenester og -ressourcer. Hvert API-kald til AWS evalueres mod IAM-politikker. Adgang bevilges kun, når de relevante politikker producerer et eksplicit Allow, og ingen relevant politikproducerer et eksplicit Deny.

Hvad er de 4 søjler i IAM?

De fire søjler, der almindeligvis refereres til inden for identitetsstyring, er: autentificering (bevise hvem du er), autorisation (hvad du har tilladelse til at gøre), administration (styring af identiteter og politikker i stor skala) og revision (logning og gennemgang af adgangsaktivitet). I AWS-termer svarer disse til IAM-autentificeringsmekanismer, IAM-politikker, AWS Organizations/IAM Identity Center og AWS CloudTrail.

Hvordan relaterer AWS IAM sig til NIS2-compliance?

NIS2 kræver, at væsentlige og vigtige enheder implementerer adgangskontrolpolitikker, der er proportionale med risikoen, opretholder incident response-kapaciteter og dokumenterer ansvarlighed for privilegeret adgang. AWS IAM leverer de tekniske kontroller — MFA, least-privilege-politikker, SCP'er, CloudTrail-logning — men compliance kræver dokumenterede processer, periodiske adgangsgennemgange og evidens for, at disse kontroller aktivt overvåges. En managed SOC kan bygge bro mellem at have kontrollerne og at bevise, at de virker.