De mest alvorlige fund i en Azure-test handler ikke nødvendigvis om servere, men kan handle om data. En lagerkonto med sikkerhedskopier, en database med kundeoplysninger eller en mappe med eksporterede rapporter kan være tilgængelig for flere end tilsigtet, uden at nogen har lavet en fejl i ond tro. Svaret på, hvorfor det sker, og hvad I gør, hviler på tre spørgsmål, som Microsofts egen dokumentation behandler: kan data læses uden login, kan data nås med en fælles nøgle i stedet for en identitet, og kan tjenesten nås fra hele internettet?
Hvorfor data havner forkert
Lagerkonti og databaser i Azure kan være oprettet af projekter, udviklere eller leverandører, ikke af den, der passer resten af miljøet. De bliver sat op til at virke hurtigt, så en integration kan hente filer, eller en rapport kan læse data. Når projektet er færdigt, flytter folk videre, og opsætningen bliver stående.
Et tænkt eksempel: et projekt flytter en rapportløsning til Azure og lægger de daglige udtræk i en lagerkonto, som et regneark henter fra. For at gøre det nemt får containeren anonym adgang, og nøglen til kontoen kommer i en konfigurationsfil. Et år senere er projektet afsluttet, men udtrækkene lander stadig hver nat.
Testen finder derfor måske ikke én fejl, men en række praktiske valg, der hver for sig gav mening. Det er sammenhængen, der gør dem alvorlige.
Læsning uden login
Azure Blob Storage kan give anonym læseadgang til containere og filer. Microsoft skriver, at anonym adgang er en mulig sikkerhedsrisiko, og anbefaler, at den ikke tillades. Adgangen styres af to indstillinger: én på hele lagerkontoen og én på den enkelte container. Er anonym adgang slået fra på kontoniveau, gælder det for alle containere i kontoen, uanset hvad der er sat på containeren.
Microsoft oplyser også, at nye lagerkonti som standard ikke tillader anonym adgang. Fundene kan derfor opstå i ældre konti eller konti, hvor nogen bevidst har slået det til.
Typiske fund er:
- Kontoen tillader anonym adgang · selvom ingen container i dag bruger det, kan den slås til af enhver med de rette rettigheder.
- Containere med anonym adgang · med indhold, der aldrig var tænkt som offentligt.
- Statiske websteder · Microsoft oplyser, at containeren til et statisk websted altid er offentlig, uanset kontoens indstilling. Filer, der ligger der ved en fejl, er dermed tilgængelige.
Har testeren kunnet åbne følsomme filer uden login, skal fundet behandles efter jeres aftale for den slags. → Testeren fandt følsomme data
Adgang med fælles nøgle
En lagerkonto kan som standard tilgås på to måder: med en identitet fra Entra ID eller med kontoens adgangsnøgle. Microsoft anbefaler identiteter, fordi de giver bedre sikkerhed, og gør det muligt at slå adgang med nøgle fra. Indstillingen er ikke sat som udgangspunkt, og så længe den ikke er sat, er adgang med nøgle tilladt.
Nøglen giver adgang til alle data i kontoen. Microsoft skriver desuden, at roller, der kan administrere lagerkonti, også kan hente nøglerne. En person med en bred rolle på abonnementet kan derfor læse data, selvom ingen har givet personen adgang til selve dataene. → Roller i Azure
Fund om nøgler kan handle om, at adgang med nøgle stadig er slået til, at nøgler ligger i scripts og konfigurationsfiler, og at ingen ved, hvilke systemer der bruger dem. → Nøgler og hemmeligheder i cloud
Databaser, der kan nås udefra
For Azure SQL beskriver Microsoft, at forbindelse over et offentligt endepunkt indebærer en risiko for, at data forlader miljøet, fordi kunden skal åbne for offentlige adresser. Microsoft anbefaler at begrænse adgangen med firewallregler, adgang fra bestemte virtuelle netværk eller private endepunkter, og at bruge Entra ID til login i stedet for databasens egne brugere.
Typiske fund er:
- Brede firewallregler · regler, der åbner for store adresseområder eller for alle tjenester i Azure.
- Databasebrugere med adgangskoder · fælles konti, der bruges af flere systemer og personer.
- For brede rettigheder i databasen · programmer, der kan ændre eller slette, selvom de kun skal læse.
- Testdatabaser med rigtige data · kopier af produktionen med svagere beskyttelse.
Prioritering og rettelse
Start med ejerskabet. Hver lagerkonto og database bør have en ejer, der kan svare på, hvad den bruges til, og hvem der skal have adgang. Uden ejer kan IT hverken prioritere eller rette sikkert, og fundet ender med at blive udskudt fra måned til måned.
Prioritér efter, hvad der rent faktisk kunne nås. Følsomme data, der kunne læses uden login eller fra internettet, står øverst. Derefter adgang med nøgle til konti med følsomme data, og så brede firewallregler og fælles databasebrugere.
Rettelser på begrebsniveau er at slå anonym adgang fra på kontoniveau og flytte det, der skal være offentligt, til en separat konto, at erstatte adgangsnøgler med identiteter, at begrænse databaser til bestemte netværk, og at give programmer præcis de rettigheder, de bruger. → Mindst mulig adgang
Microsoft understreger, at både anonym adgang og adgang med nøgle bør slås fra først, når I ved, hvilke systemer der bruger dem. Ellers stopper integrationer uden varsel. Brug logningen til at finde brugerne, før I strammer. → Rettelser uden nedetid
Det, testen skal have med
- Oversigt over lagerkonti og databaser · med ejer og formål, hvis I har den.
- Markering af følsomme data · hvor persondata, økonomi eller sikkerhedskopier ligger.
- Kendte offentlige konti · lagerkonti, der bevidst deler filer offentligt.
- Adgang til logning · så I bagefter kan se, hvad testen hentede.
Det skal I lade være med
- At slå anonym adgang fra uden at se, hvem der bruger den. Et websted eller en integration kan stoppe.
- At skifte en adgangsnøgle uden at kende afhængighederne. Natlige job fejler.
- At lade testdatabaser beholde rigtige data. De har måske ikke samme beskyttelse.
- At åbne databasens firewall bredt for nemheds skyld. Microsoft anbefaler adgang fra bestemte netværk.
- At stole på, at nye konti er sikre. Ældre konti og ændrede indstillinger er stadig jeres.
Hvad kan og ikke kan konkluderes
Testen viser, hvilke lagerkonti og databaser der var tilgængelige, og hvordan, på testtidspunktet. Den kan ikke vise, om data tidligere er blevet hentet af andre. Det kræver en undersøgelse af logs, hvis de findes. Den dækker kun de abonnementer, der var i scope, og den siger ikke noget om, hvordan data behandles af de systemer, der har lovlig adgang.
Tjekliste til lager og databaser
- ☐ Er anonym adgang slået fra på kontoniveau, hvor den ikke bruges?
- ☐ Er offentlige filer samlet i separate konti?
- ☐ Er adgang med nøgle erstattet af identiteter, hvor det er muligt?
- ☐ Er databaser begrænset til bestemte netværk?
- ☐ Bruger programmer egne identiteter med snævre rettigheder?
- ☐ Er testdatabaser uden rigtige data?
Kilder
- Microsoft Learn: Remediate anonymous read access to blob data: anonym adgang som risiko, anbefaling om at slå den fra, kontoindstilling over containerindstilling, statiske websteder altid offentlige, roller der kan hente adgangsnøgler.
- Microsoft Learn: Prevent authorization with Shared Key: to former for adgang, anbefaling om Entra ID, adgang med nøgle tilladt så længe indstillingen ikke er sat, kortlægning af klienter før ændring.
- Microsoft Learn: Security best practices for Azure SQL: Entra ID til login, firewallregler, private endepunkter og risikoen ved offentlige endepunkter.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Roller i Azure · Lagerspande i AWS
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
