Sådan strømliner du brugerkonti i AWS

Oprydning i IAM-enheder

Det er yderst vigtigt at få styr på IAM. En enkelt bruger eller rolle med omfattende tilladelser kan potentielt kompromittere hele miljøet. Målet er at rydde op i brugerne ved at fjerne brugere, der ikke er blevet benyttet i nogen tid, slette adgangsnøgler, hvor det er muligt, og begynde som minimum at gennemgå politikkerne, der er knyttet til hver bruger.

Indledende oprydning

IAM Credential-rapporten sparer dig tid, fordi du ikke skal klikke ind på hver enkelt bruger. 

For at foretage den indledende oprydning, skal du igennem de følgende fire steps:

1. Download en IAM Credential Report for din konto. Denne indeholder en række meget vigtige oplysninger om hver IAM-bruger.
2. Start med at isolere de brugere, der er lettest at slette: Dem, der hverken har et password (dvs. non-console brugere), adgangsnøgler eller vedhæftede certificeringer. Disse brugere har ikke nogen værdi (i hvert fald ikke for os; deres forældre elsker dem formentlig stadigvæk). Hold øje med følgende felter og værdier:

   • password_enabled: false

   • access_key_1_active: false

   • access_key_2_active: false

   • cert_1_active: false

   • cert_2_active: false

3. Når du har slettet disse brugere, skal du gå videre til dem, der ikke har et password, men muligvis har adgangsnøgler, der er blevet brugt for tilstrækkelig længe siden. ”Tilstrækkelig” i denne sammenhæng defineres som “den tidsramme du vil risikere dit job for en service, som ikke bliver brugt.”
   
4. Herefter kommer de brugere, som ikke har adgangsnøgler, men som har passwords, der er blevet brugt for tilstrækkelig længe siden. Hvis Peter ikke har logget ind siden Anders Fogh var statsminister, så er der stor sandsynlighed for, at han ikke har brug for sin konto. Tjek feltet: password_last_used for at fjerne disse brugere.

Opsporing af brugere

På nuværende tidspunkt har du forhåbentlig ryddet godt ud i de brugere, der har adgang til kontoen. For at få et overblik over de resterende brugere skal du i gang med at opspore dem.

Deaktivering af brugernes konsoladgang vil tvinge dem til at finde dig.

1. Start med brugere, der har både passwords og adgangsnøgler. Hvis du genkender dem så send en mail og spørg, hvad nøglerne bruges til, og om hvorvidt de kan deaktiveres. Måske de har ladet et script køre et sted.
2. Hvis brugernavnet ligner et IAM-skærmnavn tilbage fra dine dage på skolebænken, og du ikke kan genkende brugeren, så bliver vi nødt til at være kreative. Vi anbefaler ikke nødvendigvis at låse kontoen med det samme, men hvis brugeren har omfattende rettigheder, er det måske nødvendigt. Du skal bare være opmærksom på ikke at deaktivere de adgangsnøgler, der er i brug, når du gør det. Dog ved de pågældende brugere forhåbentlig, hvor de kan finde dig, i tilfælde af at deres konto bliver inddraget – så sørg for at vise dit ansigt udenfor serverrummet af og til. Hvis ikke du hører noget i løbet af 90 dage, så har brugeren formentlig ikke brug for adgangen, og den kan således inddrages permanent.
3. Gentag denne proces for de brugere, der kun har passwords. Disse brugere vil være nemmere, da de er mere sikre at slette efter at have været låst en periode.

Vi har nu en mere overkommelig gruppe af brugere, som har enten passwords eller adgangsnøgler til AWS (ideelt set ikke begge på samme tid). Vi anbefaler, at de placeres i en af følgende tre kategorier:

1. Mennesker, som har brug for konsoladgang til legitime forretningsformål
2. Maskiner, der bruger adgangsnøgler udenfor AWS (eksempelvis Jenkins, der kører i et skab)
3. Maskiner, der bruger adgangsnøgler i AWS (eksempelvis EC2-servere, Lambda etc.)

Forberedelse af kontopolitikker

Det gør ikke rigtig nogen forskel at få brugere i den første kategori til at nulstille deres passwords, hvis de bare kan ændre det til noget simpelt. Sørg for først at afkrydse IAM Password Policy for kontoen og kryds herefter alle relevante bokse af for din virksomheds passwordpolitik.

Kontakt brugere

Du bør have kontakt til brugerne i kategori 1 for at sikre, at:

• Passwords, som ikke er blevet nulstillet indenfor den angivne tidsperiode, bliver nulstillet.
• MFA er aktiveret for deres konti.
• Deres tilknyttede IAM-politikker er nødvendige for deres jobfunktion. Brug grupperne til at styre denne adgang, hvor det er nødvendigt.

Opsporing af adgangsnøgler

For brugerne i kategori 2 ligger den svære del i at opspore, hvor scripts kører. Heldigvis indeholder CloudTrail et væld af information, inklusive IP-adressers oprindelse, user agent headers og andre detaljer, som kan bruges til at lokalisere brugeren. Når alt andet fejler, kan du altid foretage en søgning i din virksomheds GitHub-installation, for det kan jo være at nøglen er blevet lagt derind.

For brugerne i kategori 3 er målet at overføre dem til IAM-roller, deprecate adgangsnøglerne og slette brugerne. Det kan være nemmere sagt end gjort, specielt hvis disse er overtagede applikationer uden en automatiseret deployment proces.

Når alt andet fejler, er den bedste mulighed – hvis nøglerne altså ikke kan slettes – at gennemgå deres politikker, således at de kun har adgang til de ydelser, de har brug for. Endnu en gang, det er ikke en nem opgave, men der er værktøjer, der kan hjælpe:

1. Brug ”Access Advisor”-værktøjet i IAM til at undersøge, om de tildelte politikker bliver benyttet.
2. Brug CloudTrail til at se specifikke API-opkald, fremskaffe data og andre detaljer for at beslutte, om alle rettigheder er nødvendige.

På nuværende tidspunkt bør du have et mere organiseret IAM-miljø, sikrere IAM-politikker og en nøje konfigureret account password politik, således at mennesker kan logge ind (med passwords og MFA) og maskiner kan tilgå de nødvendige APIer (med adgangsnøgler).

NB. Mange virksomheder bruger Single Sign On internt, hvilket af flere grunde er den mest ideelle metode til at konfigurere AWS-adgang sammenlignet med password-baseret login. Disse grunde er blandt andet provisionering og deprecation. Hvis SSO kan bruges, så anbefaler vi, at du etablerer det og overflytter dine IAM-brugere, hvis det er muligt.