Penetration-test

AWS’ politik for penetrationstest: det, I tjekker inden start

AWS' politik for penetrationstest: det, I tjekker inden start

Før en test af jeres miljø i AWS går i gang, skal nogen have læst AWS’ politik for kunders sikkerhedstest. Politikken afgør, hvilke tjenester der må testes uden at spørge først, hvilke aktiviteter der er forbudt, og hvad der kræver en særskilt godkendelse. Svaret hviler på den udgave af politikken, der gælder på testtidspunktet, for AWS ændrer den løbende. For IT-afdelingen er det en praktisk opgave: at sikre, at testens plan passer til politikken, og at der er en kontaktperson, hvis AWS henvender sig.

Hvem politikken gælder for

Politikken gælder AWS’ kunder, når de tester deres egne ressourcer. AWS skriver tydeligt, at kunder ikke må teste AWS’ egen infrastruktur eller selve tjenesterne. Testen skal altså holde sig til det, I har oprettet og råder over.

Politikken lægger også ansvaret fast. Bruger I en ekstern tester, er det jer som kunde, der har ansvaret for, at testeren overholder politikken. Har I købt AWS gennem en videreforhandler, er det ifølge AWS videreforhandleren, der har ansvaret for kundernes test. Det sidste er vigtigt for MSP’er og partnere, der leverer AWS som en del af driften. → MSP og penetrationstest

Tjenester, der kan testes uden forhåndsgodkendelse

AWS har en liste over tjenester, hvor kunder kan teste egne ressourcer uden at spørge først. Da teksten blev gennemgået, omfattede listen blandt andet virtuelle servere, databasetjenesterne, funktioner uden fast server, indholdsnettet, API-tjenesten, load balancere og containertjenester. Listen er længere, og den ændres.

Står en tjeneste ikke på listen, skal I kontakte AWS, før den testes. Det gælder også, selv om tjenesten er en del af den løsning, testen handler om. Gå derfor jeres oversigt over tjenester igennem og sammenlign med listen. Tjenester, der ikke er dækket, enten kommer ud af testen, eller også søges der om lov. → AWS-test

Aktiviteter, der ikke er tilladt

Politikken nævner en række aktiviteter, som ikke må indgå. De vigtigste for en almindelig test er:

  • Overbelastning · test, der skal lamme en tjeneste, er forbudt, også når den kun er simuleret. Det samme gælder test, der oversvømmer en tjeneste med trafik eller forespørgsler, fx på login.
  • Navnetjenesten · visse aktiviteter mod AWS’ egen DNS-tjeneste er forbudt.
  • Overtagelse · forsøg på at overtage lagerområder eller subdomæner er nævnt som forbudt.

AWS har en separat politik for simulering af overbelastningsangreb. Det hører ikke med i en almindelig penetrationstest, og hvis I vil have overbelastning afprøvet, er det en anden opgave med egne regler. → Ekstern test og DDoS

Det, der kræver godkendelse på forhånd

Nogle aktiviteter er ikke forbudt, men kræver, at AWS får besked og godkender dem. AWS nævner blandt andet red, blue og purple team-øvelser, test, hvor testeren opretter en fjernstyring af systemer, simuleret phishing og andre simulerede hændelser. Anmodningen skal ifølge politikken indsendes mindst to uger før.

For en IT-afdeling betyder det, at en almindelig penetrationstest af egne servere og tjenester ikke kræver anmeldelse, mens en længere angrebssimulering gør. Spørg testeren, hvilke aktiviteter planen indeholder, og om nogle af dem falder ind under kravet om anmeldelse. Skriv svaret ind i aftalen, så der ikke opstår tvivl undervejs. Husk, at anmeldelsen tager tid hos AWS. En test, der først planlægges en uge før start, kan derfor ikke nå at få godkendt de aktiviteter, der kræver det, og må enten udskydes eller gøres mindre.

Gennemgangen før start, trin for trin

Gennemgangen af politikken behøver ikke tage lang tid, men den skal gøres af nogen, der kender jeres miljø. Testeren kender reglerne, men ikke nødvendigvis alle jeres tjenester. Et forløb, der fungerer for mange IT-afdelinger, ser sådan ud:

  1. Hent den gældende udgave · læs politikken på AWS’ egen side samme uge, som testen planlægges, og notér datoen.
  2. Sammenlign med jeres tjenester · gå oversigten over tjenester i testens konti igennem, og markér dem, der ikke står på listen.
  3. Gennemgå testens plan · bed testeren beskrive, hvilke typer aktiviteter planen indeholder, og om nogle kræver anmeldelse.
  4. Beslut og dokumentér · skriv ned, hvad der er med, hvad der er taget ud, og hvad der er søgt om, og læg det ved aftalen.

Dokumentationen har værdi bagefter. Hvis der opstår spørgsmål, fra AWS eller internt, kan I vise, hvilken udgave af reglerne testen blev planlagt efter, og hvem der godkendte planen.

Når AWS henvender sig

Aktivitet fra en test kan ligne et angreb udefra, og AWS kan få klager over den. Ifølge politikken videresender AWS sådanne klager til kunden. I skal kunne svare med en forklaring på testen og en kontaktperson, som AWS kan give videre til den, der klagede.

Det kræver, at nogen i IT-afdelingen ved, at testen kører, og kan svare hurtigt. Aftal det før start:

  • ☐ Hvem modtager henvendelser fra AWS i testperioden?
  • ☐ Er testens tidsrum og kildeadresser skrevet ned, så de kan oplyses?
  • ☐ Er der en kort beskrivelse af testen klar til at sende?
  • ☐ Ved driftsleverandøren, at testen kører, hvis den overvåger kontiene?
  • ☐ Er der aftalt, hvem testeren kontakter, hvis noget går galt? → Kontaktpersonen i IT under testen

Jeres egen overvågning kan også reagere. Hvis I har alarmer på kontiene, så beslut på forhånd, om de skal være aktive, og hvem der skal vurdere dem. → Alarmer under testen

Flere udbydere i samme test

Indgår både AWS, Azure og Microsoft 365 i testen, har hver udbyder sine egne regler. Microsoft kræver ikke forhåndsgodkendelse til test af egne Azure-ressourcer, men har fælles regler, der blandt andet forbyder overbelastning og test af andres lejere. Planen skal passe til den strengeste af reglerne for de tjenester, der berøres. → Flere cloudmiljøer i samme test

Det skal I lade være med

  • At læse en gammel udgave af politikken. Listen over tjenester ændres, og det er den gældende, der tæller.
  • At antage, at testeren har styr på det. Som kunde har I ansvaret for, at jeres tester følger reglerne.
  • At glemme tjenester uden for listen. De skal enten ud af testen eller godkendes af AWS.
  • At blande overbelastning ind i testen. Det er forbudt under den almindelige politik.
  • At lade henvendelser fra AWS lande i en ubemandet postkasse. Nogen skal kunne svare, mens testen kører.

Hvad kan og ikke kan konkluderes

At testen følger AWS’ politik, betyder, at den er planlagt inden for udbyderens regler for de tjenester, der indgik. Det siger intet om, hvor grundig testen var, eller om alle relevante tjenester kom med. Politikken er en ramme, ikke et scope, og den fritager ikke jer for at have tilladelse fra den, der ejer kontiene, hvis det ikke er jer selv. Teksten her er ikke juridisk rådgivning, og ved tvivl om fortolkningen er det AWS’ egen tekst, der gælder.

Kilder

  • AWS: Penetration Testing: kunders test af egne ressourcer, listen over tjenester uden forhåndsgodkendelse, forbudte aktiviteter, krav om anmeldelse af simulerede hændelser mindst to uger før, kundens og videreforhandlerens ansvar og videresendelse af klager.
  • Microsoft Learn: Penetration testing: test af egne Azure-ressourcer uden forhåndsgodkendelse og henvisning til Microsofts fælles regler.

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Artikler til IT-afdelingen

Læs også: Flere cloudmiljøer i samme test · Rettigheder i AWS

→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Skal jeres miljø testes?

Fortæl kort, hvilke dele af jeres miljø der skal testes, og hvornår I skal bruge resultatet. Så vender jeg tilbage. Testen og rådgivningen er uvildige og uafhængige, og Nielco IT har ikke indgået forhandleraftaler med leverandører.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.