Lagerområderne i AWS, kaldet buckets eller lagerspande, bruges til alt fra billeder på hjemmesiden til sikkerhedskopier, logfiler og eksport fra forretningssystemer. Når en test melder, at en spand kan læses af flere end tilsigtet, er det et fund om data, ikke om software: nogen kan se noget, de ikke burde. Vurderingen hviler på to spørgsmål, nemlig hvad der ligger i spanden, og hvem der reelt kan nå det. Den gode nyhed for IT-afdelingen er, at AWS har indbyggede indstillinger, der kan spærre for offentlig adgang på tværs af hele kontoen.
Hvorfor fundet opstår
AWS oplyser, at nye spande som udgangspunkt ikke er offentlige. Fundet opstår altså, fordi nogen har ændret noget. Typiske årsager er:
- En hjemmeside eller et download · en spand blev gjort offentlig for at dele filer, og senere kom der andre filer i den.
- Deling med en partner · adgang til en anden konto blev givet bredere end nødvendigt.
- En hurtig løsning · en integration virkede ikke, og adgangen blev åbnet, til den gjorde.
- Gamle indstillinger · spande fra før de nuværende standarder, som aldrig er gennemgået.
- Brede rettigheder indefra · spanden er ikke offentlig, men alt for mange roller i kontoen må læse den. → Rettigheder i AWS
Den sidste årsag er værd at nævne for sig. En spand kan være lukket for internettet og alligevel være et fund, fordi en server, en funktion eller en partnerrolle kan læse den uden at have brug for det.
Hvad testen afprøver
Testen ser på spandene fra flere sider:
- Offentlig adgang · om spanden eller dens indhold kan læses eller skrives uden login.
- Adgang fra andre konti · hvilke eksterne konti der har fået adgang, og om de stadig er aktuelle.
- Adgang indefra · hvilke identiteter i jeres egne konti der kan læse, skrive eller slette.
- Kontoens spærringer · om AWS’ indstillinger mod offentlig adgang er slået til for hele kontoen og for de enkelte spande.
- Indholdet · i det omfang det er aftalt, hvilken type data der ligger i spande med for bred adgang.
Punkt fem kræver en klar aftale. Testeren skal kunne konstatere, at der ligger følsomme data, uden at hente dem ned eller kigge mere end nødvendigt. Hvordan fund af følsomme data håndteres, bør stå i aftalen før start. → Testeren fandt følsomme data
Skrivning er også et fund
Mange tænker kun på, hvem der kan læse. En spand, som andre kan skrive i, kan være mindst lige så alvorlig. Hvis spanden leverer filer til en hjemmeside eller et program, kan den, der kan skrive i den, ændre det, brugerne får. Ligger der sikkerhedskopier i spanden, kan sletning eller overskrivning ramme genopretningen. Rapporten bør skelne mellem læse-, skrive- og sletteadgang, og prioriteringen bør gøre det samme. Spørg testeren, hvis rapporten blot skriver adgang uden at angive hvilken.
Hvad IT-afdelingen forbereder
- ☐ Liste over spande med ejer og formål, også i udviklings- og forsøgskonti.
- ☐ Markering af spande, der bevidst er offentlige, og begrundelsen.
- ☐ Oversigt over partnere og konti, der skal have adgang udefra.
- ☐ Oplysning om, hvilke spande der indeholder persondata, sikkerhedskopier eller logfiler.
- ☐ Aftale om, hvordan testeren må konstatere indhold, og hvem der skal kontaktes ved følsomme fund.
- ☐ Logning af adgang til spande med følsomme data, hvis den er slået til. → Logning i Microsoft 365, Azure og AWS
Prioritering af fundene
Rækkefølgen afgøres af indholdet og af adgangens art. Øverst står spande med persondata, forretningshemmeligheder eller sikkerhedskopier, som kan læses eller ændres uden login. Derefter spande, som andre konti kan skrive i, og som leverer indhold til hjemmesider eller programmer. Derefter spande med for bred adgang indefra.
Spande med indhold, der allerede er offentligt, fx produktbilleder, vejer lettest, men de skal stadig have en ejer og en begrundelse. Et fund, der i dag er harmløst, kan blive alvorligt, den dag nogen lægger en eksport i samme spand. Skriv derfor både vurderingen af indholdet og datoen for vurderingen ved fundet, så den kan tages op igen.
Rettelser: luk det, der ikke skal være åbent
Spærring for hele kontoen. AWS anbefaler at slå alle fire indstillinger mod offentlig adgang til på kontoniveau, så de også gælder fremtidige spande. Indstillingerne tilsidesætter politikker, der ellers ville give offentlig adgang. Før de slås til, skal I sikre jer, at programmer, der bevidst bruger offentlig adgang, ikke holder op med at virke. AWS gør selv opmærksom på dette.
Undtagelser med navn. Spande, der skal være offentlige, fx til en hjemmeside, holdes adskilt fra alt andet, og undtagelsen skrives ned med ejer.
Snævrere adgang indefra. Roller, der kan læse alle spande, får adgang til de spande, de faktisk bruger.
Oprydning. Spande uden ejer eller formål tømmes og fjernes efter aftale, og gamle delinger med eksterne konti lukkes.
Bemærk, at spærringerne ikke ændrer de underliggende politikker. Fjernes spærringen senere, bliver en spand med en offentlig politik offentlig igen. Ret derfor både spærringen og politikken.
Hvem ejer data i spanden?
Et fund om en åben spand ender tit hos IT, fordi IT har adgang til kontoen. Men beslutningen om, hvem der må se data, hører hjemme hos den, der ejer data. Er spanden fyldt med eksport fra økonomisystemet, er det den økonomiansvarlige, der skal svare på, hvem der må læse den. IT står for rettelsen, men ikke for vurderingen af, hvad der er rimeligt. Hvis spanden har været offentlig med persondata i, kan der også være et spørgsmål om brud på persondatasikkerheden, som skal vurderes af den, der har ansvaret for databeskyttelse i virksomheden.
Spande, der indgår i hjemmesider eller domæner, kan også hænge sammen med fund fra den eksterne test. → Glemte subdomæner
Det skal I lade være med
- At slå spærringen til uden at kende konsekvensen. En hjemmeside, der mister sine billeder, er også en hændelse.
- At lade bevidst offentlige spande indeholde andet. Adskil det offentlige fra resten.
- At overse skrive- og sletteadgang. Læseadgang er kun en del af billedet.
- At antage, at en lukket spand er i orden. Adgang indefra kan være lige så bred.
- At lade IT afgøre, hvem der må se data. Det er dataejerens beslutning.
Hvad kan og ikke kan konkluderes
Testen viser, hvilke spande der havde for bred adgang i de aftalte konti på testtidspunktet. Den kan ikke vise, om nogen tidligere har hentet indholdet, medmindre logning var slået til og kan gennemgås. Nye spande og ændrede politikker er ikke dækket, og spærring på kontoniveau kan derfor være den rettelse, der holder længst. Tilsvarende fund i Azure behandles for sig. → Lagerkonti og databaser i Azure
Kilder
- AWS: Blocking public access to your Amazon S3 storage: nye spande er som udgangspunkt ikke offentlige, de fire indstillinger mod offentlig adgang på konto- og spandniveau, anbefaling om at slå dem til for kontoen, kontrol af programmer før ændringen, og at indstillingerne ikke ændrer de underliggende politikker.
- AWS IAM: Security best practices: kontrol af offentlig adgang og adgang på tværs af konti, før den gives.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Lagerkonti og databaser i Azure · Testeren fandt følsomme data
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
