Må min AWS-konto-ID holdes hemmelig? Kan noe i det hele tatt gjøres med bare AWS-konto-ID?
Fra AWS-dokumentasjon :
AWS-konto-ID er et 12-sifret nummer, for eksempel 123456789012, som du bruker til å konstruere Amazon Resource Names (ARNs). Når du refererer til ressurser, for eksempel en IAM-bruker eller et Amazon Glacier-hvelv, skiller konto-ID-en dine ressurser fra ressurser i andre AWS-kontoer.
Svar
En AWS-konto-ID kan deles når det er nødvendig.
Som dokumentasjonen sier, er det viktigste alle som kan bruke AWS Kontonummer for er å konstruere ARN «s. Hvis jeg for eksempel hadde en AWS-konto som hadde en AWS Lambda-funksjon, og noen på en annen konto, som jeg eksplisitt hadde gitt tillatelse til, ønsket å manipulere den, ville de bruke for konto nummer i ARN.
arn:aws:lambda:us-east-1:123456789012:function:ProcessKinesisRecords Igjen, dette er helt begrenset av tillatelsene som brukes på kontoen din. Selv om jeg hadde full ARN, med mindre du gir min AWS-kontotilgang, jeg kan ikke gjøre noe med det.
API-nøkler er de tingene som gir fjernkontroll av ting, og er farlige.
Kommentarer
- Det stemmer. AWS lar deg nå dele offentlig tilgjengelige lambda-lag, som deles via ARN-er som inneholder konto-ID-en din. Selv om det alltid er bedre å ikke dele noe med mindre du må – noe må du bare dele konto-ID-en din i form av et ARN.
Svar
Å vite en AWS-konto-ID utsetter deg ikke for noe angrep i seg selv, men det kan gjøre det lettere for en angriper å skaffe seg annen kompromitterende informasjon.
Rhino Security Labs demonstrerer en potensiell kompromissvektor via feilkonfigurerte IAM-roller i et blogginnlegg her :
AWS-konto-IDer identifiserer alle AWS-kontoer unikt og er mer følsomme enn du kanskje tror. Mens røpe ID ikke direkte utsetter en konto for kompromisser, kan en angriper utnytte denne informasjonen i andre angrep. Det bør gjøres en rimelig innsats for å beholde AWS konto-ID-er private, men i praksis blir de ofte utilsiktet eksponert for publikum.
[…]
Dette innlegget – og det medfølgende skriptet vi har gitt ut – adresserer usi en AWS-konto-ID for å identifisere eksisterende roller. Som en utvidelse av dette konseptet kan angripere gå et skritt videre og anta feilkonfigurerte IAM-roller for å få uautorisert tilgang.
Dette vil bare være effektivt i tilfelle der en bruker tillater rolletak fra * eller fra et for bredt spekter av ressurser, men i mine erfaringer er IAM-tillatelser kompliserte og rimelig vanskelig å revidere godt, og angrep som dette er vanskelig å oppdage:
Denne bruteforceringsteknikken og skriptet vil generere en stor mengde “iam: AssumeRole” CloudTrail-logger i kontoen du bruker til oppregning. Enhver konto du målretter mot, vil ikke se noe i CloudTrail-loggene før du har antatt en feilkonfigurert rolle, så det betyr at oppregning er helt loggfri på målkontoen.
Med andre ord – det er ikke iboende en risiko, men det reduserer angrepsoverflaten på kontoen din meningsfullt for å holde ID-en utenfor offentligheten.
Kommentarer
- Jeg ' har også lest den artikkelen, det innlegget pynter litt på ting, de trengte å ha en ekte IAM-kreditt + AWS-kontoen. Jeg ' hvis noen har innlogging til kontoen, er det ' som allerede kommer i spill på grunn av type situasjon. Lekker av AWS-acc-ID er neppe det som utløste angrepet.