Een bedrijf gebruikt AWS Organizations en is van plan om ongeveer 1.000 extra accounts toe te voegen. Momenteel kan alleen het centrale beveiligingsteam IAM-rollen aanmaken. Om knelpunten te verminderen, moeten applicatieteams hun eigen IAM-rollen kunnen provisioneren, maar de rollen moeten beperkt zijn in scope en mogen geen privilege-escalatie toestaan. Wat is de oplossing met de minste operationele overhead?

De correcte optie is om een Service Control Policy (SCP) en een IAM permissions boundary te gebruiken. Een SCP, gekoppeld aan de root OU, kan afdwingen dat alleen IAM-rollen die een specifieke permissions boundary bevatten, nieuwe IAM-rollen mogen aanmaken. De permissions boundary definieert de maximale permissies die een IAM-entiteit kan hebben, waardoor privilege-escalatie wordt voorkomen en de scope van de rollen wordt beperkt. Dit is de oplossing met de minste operationele overhead omdat het een geautomatiseerd en schaalbaar controlemechanisme biedt dat centraal wordt beheerd en consistent wordt toegepast over alle accounts. De andere opties zijn minder efficiënt: IAM-groepen en RBAC zijn voor gebruikers, niet voor het provisioneren van rollen door teams. Het delegeren aan teamleiders met handmatige controles is arbeidsintensief en schaalt slecht. Het plaatsen van elk account in een eigen OU met SCP's per OU is complex en beperkt de services, maar adresseert niet direct het gecontroleerd aanmaken van IAM-rollen binnen die accounts.