Roller på tværs af konti og ressourcepolitikker

Virkelige arkitekturer omfatter mange konti: en produktionskonto, en logningskonto og en konto til delte tjenester. Arbejdsbelastninger og personer har ofte brug for at nå ressourcer på tværs af disse grænser.

Den sikre metode er aldrig at kopiere legitimationsoplysninger mellem konti. I stedet giver du adgang med begrænset omfang ved hjælp af roller på tværs af konti eller ressourcebaserede politikker.

Det mest almindelige mønster er en rolle i målkontoen, som en principal i kildekontoen antager.

• Rollens tillidspolitik angiver kildekontoen eller principalen.
• Kildeprincipal'en kalder AssumeRole og modtager midlertidige legitimationsoplysninger.
• Den handler derefter i målkontoen inden for rollens tilladelser.

Det kræver, at begge sider tillader det, at en rolle antages på tværs af konti:

• Målrollens tillidspolitik tillader kildeprincipal'en.
• Kildeprincipalens identitetspolitik tillader sts:AssumeRole på den pågældende rolle.

Hvis en af dem mangler, mislykkes antagelsen. Dette dobbelttjek er et hyppigt eksamenspunkt.

Nogle tjenester understøtter ressourcebaserede politikker, der er knyttet direkte til ressourcen, såsom en S3-bucketpolitik, KMS-nøglepolitik eller SQS-køpolitik.

De kan give adgang til en principal i en anden konto uden at principalen antager en rolle. Den eksterne konto bruger sin egen identitet, og ressourcepolitikken godkender den.

Vælg mekanismen ud fra tjenesten:

• Til tjenester uden ressourcepolitik (EC2, de fleste API'er) skal du bruge en rolle på tværs af konti.
• Til S3, KMS, SNS, SQS, Lambda og andre tjenester kan en ressourcepolitik give direkte adgang på tværs af konti.

Ressourcepolitikker undgår et ekstra AssumeRole-hop.

Når du giver en tredjepart (for eksempel en SaaS-leverandør) adgang på tværs af konti, skal du tilføje en betingelse med et eksternt ID i tillidspolitikken.

Leverandøren skal sende en unik hemmelig værdi, når den antager rollen. Det blokerer problemet med den forvirrede stedfortræder, hvor en angriber narrer leverandøren til at få adgang til den forkerte kundes konto.

Roller på tværs af konti bør kun give det nødvendige minimum med begrænsning til bestemte ressourcer og handlinger.

En almindelig fejl er bred tillid til en hel ekstern konto kombineret med administratorrettigheder. Begræns tilliden til en bestemt rolle eller bruger og tilladelserne til den præcise opgave.

Et hyppigt design centraliserer en funktion i én konto, som andre konti får adgang til via roller, for eksempel en sikkerhedskonto, der antager skrivebeskyttede roller i alle arbejdsbelastningskonti.

Hver arbejdsbelastningskonto har en rolle med samme navn, som har tillid til sikkerhedskontoen, så værktøjer kan scanne alle konti ensartet.

AWS Resource Access Manager (RAM) deler bestemte ressourcer, såsom undernet eller Transit Gateways, på tværs af konti i en organisation.

RAM bruges til at dele selve ressourcen i stedet for at give API-tilladelser til at handle på den. Det supplerer roller og ressourcepolitikker ved deling af netværk og infrastruktur.

Adgang på tværs af konti udvider dit tillidsområde, så du bør revidere den regelmæssigt.

• CloudTrail registrerer alle AssumeRole- og API-kald på tværs af konti.
• IAM Access Analyzer markerer ressourcepolitikker, der giver adgang uden for din konto.

Gennemgå disse for tidligt at opdage utilsigtet deling.

For at forbinde konti sikkert skal du foretrække roller til beregning og API'er, ressourcepolitikker til lager- og meddelelsestjenester og altid anvende mindste privilegium med et eksternt ID til tredjep parter.

Del aldrig langtidsholdbare nøgler mellem konti.

Du lærte, hvordan du forbinder konti sikkert.

• Roller på tværs af konti kræver både en tillidspolitik og en identitetspolitik i kildekontoen.
• Ressourcebaserede politikker giver direkte adgang til tjenester som S3 og KMS.
• Brug et eksternt ID til tredjep parter, og revider med Access Analyzer og CloudTrail.