En gennemgang af et AWS-miljø begynder med rodkontoen, går videre til brugere og nøgler, så til logningen og til sidst til det, der står åbent. CIS AWS Foundations Benchmark, som AWS gengiver den, giver en tjekliste med numre, som driften kan holde opsætningen op imod.
Situationen er ofte den samme. Udviklerne oprettede kontoen for nogle år siden, byggede det, der skulle bygges, og gik videre. Nu skal driften overtage, og ingen ved helt, hvem der har adgang, eller om noget bliver logget. En tjekliste med kendte numre er et godt sted at starte.
Benchmarken, som AWS gengiver den
CIS udgiver benchmarken, men selve dokumentet ligger bag en formular og er ikke læst her. Det, der er læst, er AWS’ egen gengivelse i dokumentationen til Security Hub CSPM. Den understøtter versionerne 5.0.0, 3.0.0, 1.4.0 og 1.2.0, og AWS anbefaler 5.0.0. Tallene i artiklen er fra AWS’ tabel over version 5.0.0. Siden har ingen opdateringsdato.
Hver række i tabellen har to numre: AWS’ eget kontrolnavn og CIS-kravets nummer. Begge er nyttige. AWS-navnet er det, I ser i værktøjet. CIS-nummeret er det, en anden auditor genkender.
Rodkontoen
Rodbrugeren er det første, en gennemgang ser på. Benchmarken har tre punkter for den:
- IAM.9 · CIS v5.0.0: 1.4 · Indhold: MFA for rodbrugeren
- IAM.6 · CIS v5.0.0: 1.5 · Indhold: Hardware-MFA for rodbrugeren
- IAM.4 · CIS v5.0.0: 1.3 · Indhold: Ingen adgangsnøgle for rodbrugeren
Beviset er kontoens egen oversigt over rodbrugerens MFA og en bekræftelse af, at der ikke findes adgangsnøgler. Et vigtigt spørgsmål ved overtagelse er, hvem der har MFA-enheden og adgangskoden til rodbrugeren. Er det en tidligere udvikler, er det første fund fundet.
Brugere, roller og nøgler
For de almindelige brugere har benchmarken disse punkter. Alle brugere med adgangskode til konsollen har MFA (IAM.5, CIS 1.9). Adgangsnøgler roteres hver 90. dag eller oftere (IAM.3, CIS 1.13). Legitimationsoplysninger, der ikke er brugt i 45 dage, fjernes (IAM.22, CIS 1.11). Politikker sættes ikke direkte på brugere (IAM.2, CIS 1.14). Og IAM Access Analyzer for ekstern adgang er slået til (IAM.28, CIS 1.19).
Punktet om politikker direkte på brugere betyder i praksis, at rettigheder gives gennem grupper eller roller. Så kan en gennemgang læse rettighederne ét sted i stedet for bruger for bruger. Nøglerne og deres alder er uddybet i nøgler og hemmeligheder i skyen.
Ældre versioner af benchmarken havde krav om udløb af adgangskoder inden for 90 dage og om kompleksitet. Ifølge AWS’ gengivelse har CIS fjernet dem i de senere versioner. Ser I dem i en gammel rapport, er det version 1.2.0.
Logning i alle regioner
Uden logning er der intet at efterforske med. Benchmarken kræver mindst én CloudTrail-trail, der dækker alle regioner med både læse- og skrivehændelser (CloudTrail.1, CIS 3.1). Logfilvalidering er slået til (CloudTrail.4, CIS 3.2), og loggen er krypteret (CloudTrail.2, CIS 3.5). AWS Config er slået til (Config.1, CIS 3.3), og VPC flow logs er slået til i alle VPC’er (EC2.6, CIS 3.7).
Kravet om alle regioner betyder, at også de regioner, I ikke selv bruger, er dækket af loggen. Sker der noget dér, kan det ses bagefter.
Det, der står åbent
Den sidste gruppe handler om netværket. Standardsikkerhedsgrupperne tillader hverken ind- eller udgående trafik (EC2.2, CIS 5.5). Ingen sikkerhedsgruppe tillader indgang fra 0.0.0.0/0 eller ::/0 til porte for fjernadministration (EC2.53 og EC2.54, CIS 5.3 og 5.4). Og instanserne bruger IMDSv2 (EC2.8, CIS 5.7).
Lager, som udenforstående kan læse, har sin egen artikel: lager i skyen, der kan læses udefra.
Det, tabellen ikke dækker
Nogle punkter står som “manual check” i AWS’ gengivelse, fx alarmer på brug af rodbrugeren. Teksten til dem står i CIS-dokumentet, som ikke er læst her, så de er ikke gengivet. En gennemgang bør nævne, at de findes, og at de ikke er vurderet automatisk.
Har virksomheden flere AWS-konti, fx én til test og én til drift, er det almindelig praksis at køre tjeklisten i hver konto for sig og samle resultatet i én tabel. Så ses det hurtigt, hvis testkontoen er sat op med en anden og slappere logning end driftskontoen.
Hvad det kræver, og hvad det koster at lade være
Det kræver en læserolle i alle konti, der hører til miljøet, og en person, der ved, hvem der har rodbrugerens adgang. Kontrollerne kan køres automatisk i AWS’ egne værktøjer, og resultatet kan gemmes som udtræk.
Uden gennemgangen arver driften en konto, hvor tidligere udviklere stadig kan have nøgler, og hvor ingen kan se, hvad der er sket. Fejl i opsætningen bliver så opdaget af andre end jer.
Det skal I lade være med
- At lade rodbrugerens MFA ligge hos én person · adgangen skal kunne bruges, når personen er væk.
- At slette gamle nøgler, før ejeren er fundet · deaktivér dem først, så et stoppet job kan spores.
- At slå logning til i én region · benchmarken kræver alle regioner.
Det skal gennemgangen kunne vise
- ☐ MFA på rodbrugeren og ingen rodnøgler.
- ☐ Hvem der har rodbrugerens adgangskode og MFA-enhed.
- ☐ Brugere med konsoladgang uden MFA.
- ☐ Adgangsnøgler ældre end 90 dage og legitimationsoplysninger ubrugt i 45 dage.
- ☐ CloudTrail i alle regioner med validering og kryptering.
- ☐ Sikkerhedsgrupper med indgang fra hele internettet til administrationsporte.
- ☐ Hvilken version af benchmarken resultatet bygger på.
Kilder
- AWS, CIS AWS Foundations Benchmark in Security Hub CSPM, version 5.0.0 og kontroltabellen, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Find ud af, hvem der har rodbrugerens adgangskode og MFA-enhed, og om der findes rodnøgler.
Læs også: Automatisk måling mod benchmark · Servicekonti
→ Kontakt · Tlf. 70 13 63 23 · Teknisk sikkerhedsgennemgang hos Nielco IT
