Nogle virksomheder har ikke ét cloudmiljø, men flere: Microsoft 365 til mail og dokumenter, Azure til nogle servere og AWS til et system, der kom med en leverandør eller et opkøb. Spørgsmålet er, om de skal testes hver for sig eller samlet. Svaret hviler på, hvor meget de hænger sammen. Deler de login, netværk eller data, er forbindelserne mellem dem en del af risikoen, og så giver det mening at se dem i samme test eller i tæt koordinerede test. Er de reelt adskilt, kan de testes hver for sig uden at miste noget.
Hvor miljøerne hænger sammen
Det første arbejde for IT-afdelingen er at tegne forbindelserne. De kan findes fire steder:
- Login · medarbejdere logger ind i AWS med deres konto fra Entra ID, eller administratorer bruger samme konto begge steder. AWS anbefaler selv, at mennesker logger ind gennem en central identitetstjeneste med midlertidige legitimationer.
- Netværk · der er en fast forbindelse mellem et virtuelt net i Azure og et i AWS, eller begge er forbundet til kontornettet.
- Data · et system i det ene miljø henter eller sender data til det andet.
- Administration · samme driftsleverandør, samme administrationsværktøj eller samme nøgler bruges på tværs.
Hver forbindelse er en vej, som en svaghed i det ene miljø kan bruge til at nå det andet. Det er dem, en samlet test skal se på.
Identiteten først
Når login er fælles, bliver identitetsplatformen det vigtigste enkeltområde. En administrator i Entra ID, der kan ændre, hvem der får adgang til AWS, har reelt også adgang til AWS. En regel for betinget adgang, der har huller, gælder også for login til de andre miljøer.
Begynd derfor med identiteten, hvis testen skal deles op i etaper. Det er her, en svaghed rammer bredest. Forbindelsen mellem et lokalt katalog og cloud hører med, hvis den findes. → Hybrid identitet
Derefter kan de enkelte miljøer tages i den rækkefølge, der passer til, hvor data og forretningskritiske systemer ligger. → Microsoft 365-test for IT-afdelingen · → Azure-test · → AWS-test
Afgrænsning, der kan holde
En test, der omfatter alt, bliver let så bred, at den ikke går i dybden nogen steder. Det hjælper at skrive afgrænsningen som spørgsmål frem for som en liste over tjenester:
- Hvad kan en almindelig medarbejder nå på tværs? · fx fra sin konto i Microsoft 365 til data i AWS.
- Hvad kan en administrator i ét miljø gøre i et andet? · fx via fælles roller eller føderation.
- Hvad kan en kompromitteret server nå? · fx gennem en fast netværksforbindelse eller en nøgle til det andet miljø.
- Hvilke data ligger, hvor, og hvem kan se dem? · på tværs af lagerområder og delinger.
Spørgsmålene gør det tydeligt, hvad der skal med, og hvad der kan vente. De gør det også lettere at vurdere, om en gennemgang af opsætningen er nok, eller om der skal afprøves. → Konfigurationsgennemgang eller penetrationstest af cloud
Hver udbyder har sine regler
En samlet test skal holde sig inden for alle udbyderes regler på én gang. Microsoft kræver ikke forhåndsgodkendelse til test af egne ressourcer i Azure, men henviser til fælles regler, der blandt andet forbyder overbelastning. AWS har sin egen liste over tjenester, der kan testes uden at spørge, og kræver anmeldelse af visse aktiviteter. → AWS’ politik for penetrationstest
Planen skal passe til de regler, der gælder for hver tjeneste. Bed testeren skrive i planen, hvilke regler de enkelte dele er planlagt efter.
Det, IT-afdelingen forbereder
- ☐ Oversigt over miljøerne med ejer, formål og driftsleverandør.
- ☐ Tegning eller beskrivelse af forbindelserne: login, netværk, data og administration.
- ☐ Testkonti i hvert miljø, helst knyttet til samme identitet, hvis login er fælles.
- ☐ Læseadgang til opsætningen i hvert miljø.
- ☐ Oplysning om logning i alle miljøer, så testens spor kan samles bagefter. → Logning i Microsoft 365, Azure og AWS
- ☐ Kontaktpersoner hos hver leverandør, der passer et af miljøerne.
Fund, der går på tværs
En samlet test giver nogle fund, som ingen enkeltstående test ville have givet. De typiske er:
- Fælles administratorer · samme personer eller konti har høje rettigheder i flere miljøer, uden at det er nødvendigt.
- Nøgler i det forkerte miljø · en adgangsnøgle til AWS ligger i en opsætning i Azure eller i et script på en server.
- For brede forbindelser · en netværksforbindelse mellem miljøerne tillader mere trafik end den ene integration, den blev lavet til.
- Uens regler · tofaktor eller betinget adgang gælder i ét miljø, men ikke for login til det andet.
Fund på tværs kan have to ejere. Skriv begge ved fundet, og aftal, hvem der driver rettelsen. Ellers venter de to parter på hinanden. Prioriter dem efter, hvor langt fundet rækker: et fund, der fører fra en almindelig medarbejderkonto til data i et andet miljø, vejer tungere end et fund, der kræver administratoradgang i forvejen.
Når hvert miljø har sin egen leverandør
Det er almindeligt, at Microsoft 365 passes af én partner, mens AWS-miljøet kom med en softwareleverandør, og Azure drives af IT-afdelingen selv. Så kender ingen enkelt part hele billedet, og forbindelserne mellem miljøerne kan være dem, der er dårligst beskrevet. Ingen har haft ansvaret for at tegne dem.
Saml leverandørerne til et kort møde før testen. Formålet er ikke at gennemgå alt, men at få bekræftet forbindelserne, aftalt hvem der svarer på spørgsmål om hvert miljø, og afklaret, hvem der retter hvad bagefter. Bed også hver leverandør oplyse, hvilke konti med høje rettigheder de selv har. Det giver testeren et bedre udgangspunkt, og det giver jer et overblik, I kan bruge, også når testen er overstået. Har en leverandør regler for varsel eller godkendelse i sin aftale, skal de også med i planen.
Det skal I lade være med
- At teste miljøerne hver for sig, når de deler login. Så bliver den vigtigste vej ikke set.
- At lade afgrænsningen være en liste over alle tjenester. Den bliver for bred til at gå i dybden.
- At glemme miljøer fra opkøb og leverandører. De kan have forbindelser, ingen har tegnet.
- At følge kun én udbyders regler. Hver tjeneste har sine egne.
- At fordele fund på tværs til én part. Rettelsen kan kræve begge sider.
Hvad kan og ikke kan konkluderes
En samlet test viser, hvordan forbindelserne mellem de aftalte miljøer holdt på testtidspunktet, og hvor en svaghed i ét miljø kunne række ind i et andet. Den dækker ikke miljøer eller forbindelser, der ikke var kendt eller med i aftalen. Udbydernes egne platforme er ikke testet. Når nye forbindelser oprettes, ændres billedet, og tegningen over forbindelserne bør derfor holdes ved lige efter testen.
Kilder
- Microsoft Learn: Penetration testing: test af egne Azure-ressourcer uden forhåndsgodkendelse og henvisning til fælles regler.
- AWS: Penetration Testing: tjenester, der kan testes uden forhåndsgodkendelse, og aktiviteter, der kræver anmeldelse.
- AWS IAM: Security best practices: anbefaling om, at mennesker logger ind gennem en central identitetstjeneste med midlertidige legitimationer.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Azure-test · Logning i Microsoft 365, Azure og AWS · Google Workspace som testområde
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
