I AWS afgøres næsten alt af tilladelser: hvem der må starte en server, læse en database, ændre en netværksregel eller oprette nye brugere. Når en test melder om for brede tilladelser, betyder det, at en bruger, en rolle eller et program kan mere, end opgaven kræver, og at en fejl eller et misbrug derfor rækker længere. Fundet hviler på AWS’ egen anbefaling om mindst mulig adgang. For IT-afdelingen er det ikke nødvendigvis én fejl, men summen af mange små beslutninger om at give lidt ekstra, så tingene virkede.
Hvordan rettigheder er bygget op i AWS
Tilladelser i AWS skrives i politikker. En politik siger, hvilke handlinger der er tilladt på hvilke ressourcer, og eventuelt under hvilke betingelser. Politikker kan sættes på brugere, grupper og roller, og nogle ressourcer, fx lagerområder, kan have deres egen politik, der bestemmer, hvem der må bruge dem.
En rolle er en identitet, som mennesker eller programmer kan påtage sig for en tid. AWS anbefaler roller med midlertidige legitimationer frem for brugere med faste nøgler. Over flere konti kan organisationen sætte overordnede grænser, som ingen politik i den enkelte konto kan gå ud over.
Det giver mange steder at give adgang, og derfor også mange steder, hvor adgangen kan blive for bred. → AWS-test
Hvad testen ser på
Testen spørger ikke kun, hvilke politikker der findes, men hvad de samlet giver adgang til:
- Hvem der kan administrere · hvilke identiteter der har fuld adgang eller kan give sig selv mere.
- Hvad programmerne må · om roller til servere, funktioner og integrationer har adgang til mere end deres egne data.
- Adgang på tværs · om andre konti, partnere eller hele internettet har fået adgang gennem en ressources egen politik.
- Hvad der ikke bruges · brugere, roller og nøgler, som ikke har været i brug længe, men stadig virker.
- Rodkontoen · om den bruges i dagligdagen, og om den er beskyttet med tofaktor.
Det mest værdifulde ved en test kan være at se kæderne. En rolle med beskeden adgang, der må påtage sig en anden rolle med større adgang, er reelt lige så stærk som den største.
Fundtyperne i rapporten
Stjerne-tilladelser. Politikker, der tillader alle handlinger eller alle ressourcer i en tjeneste. De kan være skrevet for at komme i gang og aldrig strammet. AWS skriver selv, at man kan begynde bredt, mens man finder ud af, hvad der er brug for, men at tilladelserne derefter skal indsnævres.
Færdige politikker brugt som de er. AWS’ egne standardpolitikker passer til mange kunder på én gang. AWS gør opmærksom på, at de derfor ikke nødvendigvis giver mindst mulig adgang til jeres brug.
Faste nøgler. Adgangsnøgler, der ikke udløber, til brugere eller integrationer. Er nøglen kopieret ud et sted, virker den, til nogen fjerner den. → API-nøgler og integrationskonti
Selvforhøjelse. Identiteter, der kan ændre egne eller andres politikker og dermed give sig selv mere.
Ubrugte adgange. Konti og roller fra tidligere projekter, medarbejdere eller leverandører.
Hvem ejer tilladelserne?
Et fund om brede tilladelser er let at skrive og svært at rette, hvis ingen ved, hvem rollen tilhører. I mange AWS-miljøer er roller oprettet af udviklere, af en partner eller af et skabelonværktøj, og navnet siger ikke altid, hvad den bruges til. Før rettelserne starter, skal hver identitet med væsentlig adgang have en ejer, der kan svare på, hvad den skal kunne.
Ejeren er ikke nødvendigvis IT-afdelingen. En rolle, der bruges af et forretningssystem, ejes måske af den, der har ansvaret for systemet, mens IT står for selve ændringen. Skriv fordelingen ind ved fundet, så opgaven ikke bliver liggende mellem to afdelinger. Det gælder også partnerens roller: hvis partneren har oprettet dem, skal partneren være med til at stramme dem.
Prioritering
Prioriter efter, hvad en identitet kan nå, hvis den misbruges, ikke efter, hvor mange fund der er. Det, der giver kontrol over en hel konto eller over andres rettigheder, kommer først. Derefter adgang til følsomme data. Derefter brede tilladelser til ressourcer med begrænset betydning.
Se også på, hvor identiteten bruges. En rolle, der hører til en server på internettet, er mere udsat end en rolle, der kun bruges af en intern administrator med tofaktor. En stor tilladelse på et udsat sted vejer tungere end en stor tilladelse et beskyttet sted. → Virtuelle maskiner i Azure og AWS
Rettelser uden at stoppe driften
At stramme tilladelser er et af de steder, hvor en rettelse kan give nedbrud. Et program, der mister en adgang, det faktisk bruger, holder op med at virke. Rettelserne bør derfor bygge på viden om, hvad der faktisk bruges.
- Find det, der bruges · AWS registrerer, hvornår tilladelser og nøgler sidst er brugt. Det gør det muligt at fjerne det ubrugte med mindre risiko.
- Ryd op først · ubrugte brugere, roller og nøgler fjernes, før de aktive politikker strammes.
- Stram trinvis · brede politikker erstattes af politikker, der er skrevet til opgaven, og afprøves i et testmiljø eller på én tjeneste ad gangen.
- Erstat faste nøgler · hvor det kan lade sig gøre, med roller og midlertidige legitimationer.
- Sæt grænser over kontiene · overordnede regler, der forhindrer de farligste handlinger, uanset hvad den enkelte konto tillader.
Principperne er de samme som i resten af IT-miljøet. → Mindst mulig adgang
Det skal I lade være med
- At fjerne alt, der ser bredt ud, på én dag. Programmer, der stopper, bliver hurtigt rullet tilbage, og så er intet rettet.
- At lade rodkontoen være en almindelig administratorkonto. Den skal kun bruges, når intet andet kan.
- At lade nøgler leve for evigt. En nøgle uden udløb er en adgang uden udløb.
- At glemme ressourcernes egne politikker. Adgang kan gives på lagerområdet selv, ikke kun hos brugeren.
- At rette i hånden uden at opdatere skabelonerne. Hvis kontiene bygges fra kode, kommer den brede tilladelse tilbage ved næste udrulning. → Infrastruktur som kode
Hvad kan og ikke kan konkluderes
Testen viser, hvilke tilladelser der var for brede i de undersøgte konti på testtidspunktet, og hvad de kunne bruges til. Den kan ikke garantere, at der ikke findes flere veje, og nye roller og politikker ændrer billedet hurtigt. Et godt resultat holder kun, hvis nye tilladelser gennemgås, før de tages i brug, og ubrugte adgange fjernes løbende.
Tjekliste til opfølgningen
- ☐ Er identiteter med fuld eller selvforhøjende adgang listet med ejer?
- ☐ Er rodkontoen beskyttet med tofaktor og uden adgangsnøgler?
- ☐ Er ubrugte brugere, roller og nøgler fjernet?
- ☐ Er brede politikker erstattet trinvis og afprøvet?
- ☐ Er skabelonerne rettet, hvis kontiene bygges fra kode?
- ☐ Er der aftalt en løbende gennemgang af tilladelser?
Kilder
- AWS IAM: Security best practices: midlertidige legitimationer, mindst mulig adgang, AWS’ standardpolitikker som udgangspunkt, oplysninger om sidste brug, overordnede grænser over flere konti.
- AWS IAM: Root user best practices: rodkontoen kun til opgaver, der kræver den, tofaktor og ingen adgangsnøgler.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Lagerspande i AWS · Nøgler og hemmeligheder i cloud
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
