Måste mitt AWS-konto-ID hållas hemligt? Kan något alls göras med bara AWS-konto-ID?
Från AWS-dokumentation :
AWS-konto-ID: t är ett 12-siffrigt nummer, till exempel 123456789012, som du använder för att konstruera Amazon Resource Names (ARNs). När du hänvisar till resurser, till exempel en IAM-användare eller ett Amazon Glacier-valv, skiljer konto-ID dina resurser från resurser i andra AWS-konton.
Svar
Ett AWS-konto-ID kan delas vid behov.
Som dokumentationen säger, det viktigaste vem som helst kan använda din AWS Kontonummer för är att konstruera ARN ”s. Om jag till exempel hade ett AWS-konto som innehöll en AWS Lambda-funktion, och någon på ett annat konto, som jag uttryckligen hade gett tillstånd till, ville manipulera det, skulle de använda för konto nummer i ARN.
arn:aws:lambda:us-east-1:123456789012:function:ProcessKinesisRecords Återigen är detta helt begränsat av behörigheterna som tillämpas på ditt konto. Även om jag hade en fullständig ARN, såvida du inte ger min AWS-kontoåtkomst, jag kan inte göra någonting med det.
API-nycklar är de saker som ger fjärrkontroll av saker och är farliga.
Kommentarer
- Det stämmer. AWS tillåter dig nu att dela offentligt tillgängliga lambdaskikt, som delas via ARN som innehåller ditt konto-id. Det är alltid bättre att inte dela någonting om du inte måste – något du bara måste dela ditt konto-id i form av ett ARN.
Svara
Att känna till ett AWS-konto-ID utsätter dig inte för någon attack i sig, men det kan göra det lättare för en angripare att få annan kompromissinformation.
Rhino Security Labs visar en potentiell kompromissvektor via felkonfigurerade IAM-roller i ett blogginlägg här :
AWS-konto-ID: n identifierar alla AWS-konton unikt och är känsligare än du kanske tror. Medan ID-meddelandet inte utsätter ett konto direkt för kompromisser kan en angripare utnyttja denna information i andra attacker. En rimlig ansträngning bör göras för att behålla AWS konto-ID: n privata, men i praktiken exponeras de ofta för allmänheten oavsiktligt.
[…]
Detta inlägg – och det medföljande skriptet vi har släppt – adresserar usi ng ett AWS-konto-ID för att identifiera befintliga roller. Som en förlängning av detta koncept kan angripare gå ett steg längre och anta felkonfigurerade IAM-roller för att få obehörig åtkomst.
Detta kommer bara att vara effektivt i fallet där en användare tillåter rollantagande från * eller från ett alltför stort utbud av resurser, men enligt mina erfarenheter är IAM-behörigheter komplexa och ganska svåra att granska bra, och attacker som detta är svåra att upptäcka:
Denna brutförstärkningsteknik och skript genererar en stor mängd ”iam: AssumeRole” CloudTrail-loggar i kontot du använder för uppräkning. Alla konton du riktar dig mot kommer inte att se någonting i deras CloudTrail-loggar förrän du lyckats ta en felkonfigurerad roll, så det betyder att uppräkning är helt loggfritt på målkontot.
Med andra ord – det är inte i sig en risk, men det minskar angreppsytan på ditt konto på ett meningsfullt sätt för att hålla ID borta från allmänheten.
Kommentarer
- Jag ' har också läst den artikeln, det inlägget förskönar saker lite, de behövde ha en riktig IAM-kredit + AWS-tillämpligheten. Jag ' d säg om någon har en inloggning till kontot är det ' redan i spel över typ av situation. Läcker av AWS-acc-ID är knappast det som utlöste attacken.