Når virksomheden har systemer i AWS, er det ikke nødvendigvis ét system. Der er konti til drift og udvikling, roller til mennesker og programmer, lagerplads, databaser, servere og netværk, og alt sammen er sat op af nogen på et tidspunkt. En test af AWS afprøver den del, I selv har valgt og konfigureret, ikke AWS’ egen platform. Den hviler på AWS’ egen ansvarsfordeling og politik for kunders test, og den giver IT-afdelingen et billede af, hvem og hvad der kan nå jeres data, og om det svarer til hensigten.
Jeres del af AWS
AWS beskriver ansvaret som sikkerhed af skyen, som er AWS’ del, og sikkerhed i skyen, som er kundens. Jo mere I selv konfigurerer, jo større er jeres del. På en lejet server står I for styresystemet, programmerne og firewallreglerne. På en færdig tjeneste står I stadig for, hvem der har adgang, og hvordan den er sat op.
For en test betyder det, at spørgsmålene ikke handler om AWS’ datacentre, men om jeres valg. Køberens overvejelser om ansvarsfordeling i cloud er forklaret på penetrationtest.dk. Her handler det om, hvad driften skal have klar, og hvad testen kan finde.
Hvad testen afprøver
En AWS-test dækker typisk fem områder:
- Konti og struktur · hvor mange AWS-konti der findes, hvordan de hænger sammen, og hvem der ejer hver af dem.
- Rettigheder · hvilke brugere, roller og programmer der har hvilke tilladelser, og om de er bredere end nødvendigt. → Rettigheder i AWS
- Data · om lagerplads og databaser kan nås af flere end tilsigtet, også fra internettet. → Lagerspande i AWS
- Netværk og servere · hvad der er åbent udadtil, og hvad en kompromitteret server kan nå. → Virtuelle maskiner i Azure og AWS
- Overvågning · om handlinger i kontoen registreres, så testens spor kan genfindes.
Det kan være samspillet mellem områderne, der giver de alvorlige fund. En server med en rolle, der må læse alt lager, gør en almindelig svaghed på serveren til et spørgsmål om data.
Gennemgang og afprøvning
En del af testen er en gennemgang af opsætningen med en konto, der kan læse, men ikke ændre. Den giver bredde: alle konti, alle roller, alle lagerområder. AWS har selv værktøjer, der kan pege på offentlig adgang og ubrugte rettigheder, og resultaterne fra dem kan være et godt udgangspunkt.
Den anden del er afprøvning. Her er spørgsmålet, hvad en bestemt identitet faktisk kan nå, når den bruges. En rolle kan se snæver ud og alligevel give adgang videre, fordi den må overtage en anden rolle. Det er afprøvningen, der viser, om reglerne holder i praksis. → Konfigurationsgennemgang eller penetrationstest af cloud
Rammen for begge dele er AWS’ egne regler. AWS tillader kunder at teste en række navngivne tjenester uden at spørge først, men forbyder blandt andet test, der kan lamme tjenester, og kræver forhåndsgodkendelse til visse andre aktiviteter. Listen ændres, og den gældende udgave skal læses før start. Det er jeres ansvar som kunde, også når testeren er en ekstern part. → AWS’ politik for penetrationstest
Det, IT-afdelingen forbereder
- Kontooversigt · alle AWS-konti med ejer og formål, også dem til udvikling og forsøg.
- Testadgang · en rolle med læseadgang til opsætningen og eventuelt en rolle med samme rettigheder som en typisk medarbejder eller et typisk program.
- Kendte undtagelser · lagerområder eller tjenester, der bevidst er offentlige, med begrundelse.
- Login-sammenhæng · om medarbejdere logger ind gennem en central identitetstjeneste, fx Entra ID, eller med egne brugere i AWS.
- Logning · at registrering af handlinger er slået til i alle konti, og hvor længe den gemmes. → Logning i Microsoft 365, Azure og AWS
- Leverandører · partnere med adgang til kontiene, og hvem af dem der skal orienteres.
Fjern testrollerne, når testen er slut. De er rigtige adgange til jeres konti.
Fundene, der går igen
Fund i AWS kan samle sig om de samme temaer:
- Rodkontoen bruges · den konto, der blev oprettet med AWS-kontoen, har fuld adgang til alt. AWS anbefaler, at den kun bruges til de få opgaver, der kræver den, og at den har tofaktor.
- Langvarige nøgler · adgangsnøgler, der aldrig udløber, i stedet for midlertidige legitimationer, som AWS anbefaler.
- Brede tilladelser · roller med adgang til hele tjenester eller alle ressourcer, hvor en snævrere tilladelse ville række.
- Offentlig adgang til data · lagerområder eller øjebliksbilleder, der kan nås udefra.
- Konti uden ejer · gamle forsøgskonti, som stadig kører og stadig har adgang.
Prioriter efter, hvad fundet giver adgang til. Fund, der giver kontrol over en hel konto eller adgang til følsomme data, kommer først. Derefter fund, der kræver en forudgående adgang. Rettelser i tilladelser bør afprøves, før de gælder i produktion, for en for stram regel kan stoppe et program.
Når en partner driver kontiene
Har en partner sat AWS op for jer, eller videresælger partneren AWS sammen med driften, skal partneren med fra begyndelsen. AWS skriver i sin politik, at videreforhandlere har ansvaret for deres kunders test, og at kunden har ansvaret for de eksterne parter, kunden selv bruger. Det gør det vigtigt at aftale skriftligt, hvem der giver lov til testen, og hvem AWS skal kontakte, hvis der kommer en henvendelse.
Partneren kan selv have roller med høje rettigheder i jeres konti, og de roller hører med i testen. Aftal også, hvem der retter bagefter. Ligger en ændring af rettigheder uden for driftsaftalen, er det bedre at vide det, før fundene skal fordeles. → MSP og penetrationstest
Det skal I lade være med
- At teste med en administratorrolle. Testen viser så, hvad en administrator kan.
- At glemme udviklingskontiene. De kan have bredere rettigheder og forbindelse til produktion.
- At springe AWS’ politik over. Aktiviteter uden for den kan føre til henvendelser fra AWS undervejs.
- At skjule bevidst offentlige data. Testeren kan ikke vurdere fundet uden begrundelsen.
- At rette alle tilladelser på én gang. Et program, der mister sin adgang, er også et nedbrud.
Hvad kan og ikke kan konkluderes
Testen viser, hvordan de aftalte konti og tjenester holdt på testtidspunktet. Den kan ikke dokumentere AWS’ egen sikkerhed, og konti eller tjenester uden for aftalen er ikke dækket. Opsætningen i AWS ændres ofte og af mange, så et godt resultat holder kun, hvis ændringer af rettigheder og offentlig adgang også styres og følges bagefter.
Tjekliste før AWS-testen
- ☐ Er alle AWS-konti listet med ejer og formål?
- ☐ Er testroller oprettet og afgrænset?
- ☐ Er AWS’ gældende politik for test læst og aftalt med testeren?
- ☐ Er bevidst offentlige data beskrevet med begrundelse?
- ☐ Er logning slået til i alle konti?
- ☐ Er partnere med adgang orienteret?
Kilder
- AWS: Shared Responsibility Model: sikkerhed af skyen og i skyen, og kundens ansvar for styresystem, programmer og firewallregler.
- AWS: Penetration Testing: navngivne tjenester, der kan testes uden forudgående godkendelse, forbudte aktiviteter og kundens ansvar for eksterne testere.
- AWS IAM: Security best practices: midlertidige legitimationer, tofaktor, mindst mulig adgang og oprydning i ubrugte rettigheder.
- AWS IAM: Root user best practices: rodkontoen bruges kun til opgaver, der kræver den, med tofaktor og uden adgangsnøgler.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Lagerspande i AWS · Flere cloudmiljøer i samme test
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
