Organizations, OUs och SCP-strategi

AWS Organizations låter er centralt hantera många AWS-konton som en gemensam struktur. I den strukturen anger Service Control Policies (SCPs) behörighetstak, och Organizational Units (OUs) grupperar konton för riktad policytillämpning. Att utforma denna hierarki väl är en central färdighet inom styrningsområdet på SCS-C02-provet.

En organisation har högst upp ett management account (tidigare master), en behållare som kallas root samt OU:er som kan kapslas i varandra för att gruppera medlemskonton. Policyer som kopplas på valfri nivå förs vidare till allt som ligger under den nivån. Detta träd gör det möjligt att tillämpa kontroller brett eller snävt med en enda koppling.

En Organizational Unit (OU) grupperar konton med gemensamma styrningsbehov, till exempel en "Production"-OU, en "Sandbox"-OU och en "Security"-OU. När en SCP kopplas till en OU tillämpas den på varje konto i OU:n, så ni organiserar konton utifrån vilka policyer de ska ärva.

SCP:er ärvs nedåt i trädet: ett konto styrs av SCP:erna vid roten, dess överordnade OU:er och kontot självt, i kombination. För att en åtgärd ska tillåtas måste den vara tillåten på varje nivå. Ett deny någonstans i kedjan blockerar den. Denna kumulativa effekt är central vid utformning av SCP:er.

Det finns två strategier. En nekandelista utgår från standardpolicyn FullAWSAccess och lägger till uttryckliga deny för sådant ni aldrig vill tillåta, till exempel att inaktivera CloudTrail. En tillåtelselista tar bort FullAWSAccess och listar uttryckligen endast tillåtna tjänster, vilket ger en betydligt striktare säkerhetsnivå. De flesta organisationer börjar med en nekandelista för att behålla flexibiliteten.

Den här SCP:n nekar alla att stoppa CloudTrail-loggning, ett vanligt skyddsräcke som tillämpas i hela organisationen så att inget medlemskonto kan göra granskningsspåret blint.

En viktig regel: SCP:er beviljar aldrig behörigheter; de anger bara den högsta tillåtna nivån. En åtgärd måste tillåtas av både en SCP och en IAM-policy i kontot. En SCP med allow-list gör helt enkelt tjänster tillgängliga för tilldelning; IAM måste fortfarande bevilja dem.

SCP:er gäller inte för managementkontot, och de påverkar inte service-linked roles. I vissa fall påverkar de inte heller resursbaserade policybeviljanden från organisationer utanför organisationen. Om du känner till dessa undantag undviker du fel svar när ett scenario förutsätter att en SCP ska blockera något som den inte kan blockera.

Två klassiska skyddande SCP:er nekar att organisationen lämnas (organizations:LeaveOrganization) och nekar medlemskonton att inaktivera säkerhetstjänster som GuardDuty, Security Hub, Config och CloudTrail. När de tillämpas på roten säkerställer de att inget medlemskonto kan koppla bort sig från styrningen eller förblinda organisationens detektering. Detta är en starkt rekommenderad baslinje.

En typisk utformning är en baslinje med en deny-list-SCP på roten (skydda CloudTrail, neka att organisationen lämnas och begränsa regioner), striktare SCP:er för OU:n Production och mindre strikta för OU:n Sandbox. Genom att gruppera konton efter riskprofil i OU:er kan du finjustera styrningen med ett minimum av policysprawl.

Organizations strukturerar konton i OU:er under en rot och ett managementkonto. SCP:er ärvs nedåt i trädet, och en åtgärd måste ha ett allow på varje nivå. Välj en strategi med deny-list (flexibel) eller allow-list (strikt), kom ihåg att SCP:er bara sätter en gräns och aldrig beviljar, samt att de inte gäller för managementkontot eller service-linked roles.

AWS Organizations grupperar konton i OU:er under en rot och ett managementkonto. SCP:er ärvs nedåt i trädet och kräver ett allow på varje nivå; varje deny blockerar. Använd en strategi med deny-list (flexibel) eller allow-list (strikt). SCP:er bara sätter en gräns och aldrig beviljar, och gäller inte för managementkontot eller service-linked roles.