Conformance Packs och organisationsspår

AWS Config Conformance Packs är samlingar av Config-regler och åtgärder som paketeras tillsammans som en enda distribuerbar enhet med hjälp av en YAML-mall som liknar en CloudFormation-mall. De representerar en uppsättning efterlevnadskontroller för en specifik standard eller ett specifikt ramverk – till exempel CIS AWS Foundations Benchmark, PCI-DSS, HIPAA eller NIST 800-53. I stället för att distribuera dussintals enskilda Config-regler manuellt distribuerar Ni ett conformance pack och får heltäckande täckning på några minuter.

AWS tillhandahåller dussintals sample conformance pack templates på GitHub och i AWS-konsolen. Exempel är: Operational-Best-Practices-for-CIS-AWS-v1.4-Level1 (grundläggande säkerhetskontroller), Operational-Best-Practices-for-PCI-DSS (kontroller för betalkortsbranschen) och Operational-Best-Practices-for-HIPAA-Security (kontroller för hälsovårdsdata). Ni kan använda mallarna som de är eller anpassa dem genom att lägga till, ta bort eller ändra enskilda regler före distributionen.

En conformance pack-mall är ett YAML-dokument som innehåller avsnitten Parameters och Resources. Varje resurs i mallen är en Config-regeldefinition som använder CloudFormation-resurstypen AWS::Config::ConfigRule. Ni kan även inkludera resurser av typen AWS::Config::RemediationConfiguration för att koppla automatiska åtgärder. Parametrar gör mallen återanvändbar – Ni kan till exempel ange vilken S3-bucket som lagrar resultat eller vilken IAM-roll åtgärden antar.

När ett conformance pack har distribuerats kan Ni visa en compliance summary för det – med information om hur många regler som godkänns, hur många som underkänns och hur många resurser som inte uppfyller kraven för varje regel. Ni kan gå från packnivå till regelnivå och vidare till den enskilda resursnivån. Efterlevnadsdata kan exporteras till S3 i en resultatbucket som Ni anger, så att Ni kan läsa in den i ett SIEM-system eller en instrumentpanel för efterlevnadsrapportering.

Ett Organisation Conformance Pack distribuerar samtidigt ett conformance pack till alla konton i en AWS-organisation från hanteringskontot (eller ett delegerat administratörskonto). Medlemskonton kan inte ta bort eller ändra de distribuerade reglerna. Nya konton som ansluter till organisationen får automatiskt conformance packet. Detta är det effektivaste sättet att tillämpa grundläggande efterlevnadskrav i hundratals konton utan att besöka varje konto individuellt.

I en AWS-organisation kan Ni utse ett delegated administrator account för AWS Config, så att hanteringskontot inte behöver användas för det dagliga Config-arbetet. Den delegerade administratören kan distribuera organisationsomfattande Config-regler, conformance packs och aggregatorer samt visa efterlevnadsdata från alla medlemskonton. Detta följer bästa praxis genom att hålla hanteringskontot så lite involverat som möjligt i operativa uppgifter.

En organisation trail i AWS CloudTrail samlar in API-aktivitet från alla konton i AWS-organisationen – både nuvarande och framtida medlemskonton – och levererar loggarna till en centraliserad S3-bucket i hanteringskontot. Till skillnad från trails på kontonivå, som varje konto måste underhålla, skapas en organisation trail en gång och tillämpas automatiskt överallt. Medlemskonton kan se organisation trail i sin CloudTrail-konsol men kan inte ändra eller ta bort den.

S3-bucketen för organisation trail använder ett strukturerat nyckelprefix: AWSLogs/ORGANIZATION_ID/ACCOUNT_ID/CloudTrail/REGION/YYYY/MM/DD/. Denna hierarki gör att Ni kan fråga efter loggar från alla konton med en enda Athena-tabell som är partitionerad efter organisations-ID och konto-ID, eller använda S3-objektprefix för att ge specifika konton läsåtkomst endast till deras egna loggar. Bucket-principen måste uttryckligen tillåta cloudtrail.amazonaws.com att skriva från alla konton i organisationen.

Service Control Policies (SCPs) i AWS Organisations är en kompletterande förebyggande kontroll som begränsar vad medlemskonton får göra. Genom att kombinera SCP:er med Config-regler skapas ett försvar i flera lager: SCP:er förhindrar att åtgärder som inte uppfyller kraven genomförs över huvud taget (till exempel genom att neka skapande av okrypterade EBS-volymer), medan Config-regler identifierar tillstånd som inte uppfyller kraven och utlöser åtgärder. SAA-C03-provet testar Er förmåga att välja mellan förebyggande kontroller (SCP:er) och detekterande kontroller (Config) i olika scenarier.

AWS Security Hub hämtar in fynd från Config (resultat från efterlevnadskontroller), GuardDuty (hotidentifieringar), Inspector (sårbarhetsfynd), Macie (datakänslighet) och partnerverktyg till en enda normaliserad vy. Fynden mappas mot säkerhetsstandarder som CIS Foundations, PCI-DSS och AWS Foundational Security Best Practices. Config fokuserar på konfigurationstillstånd, medan Security Hub är platsen där Ni får en övergripande security score och en prioriterad lista över fynd från alla tjänster.

En komplett arkitektur för styrning i företagsskala använder flera tjänster tillsammans: SCPs förhindrar överträdelser innan de inträffar, AWS Config + Organisation Conformance Packs identifierar och åtgärdar överträdelser automatiskt, Organisation CloudTrail registrerar all API-aktivitet centralt, Security Hub sammanställer fynd till ett prioriterat säkerhetspoäng och EventBridge + Lambda tillhandahåller automatiska svar på fynd med hög allvarlighetsgrad. Detta lagerindelade tillvägagångssätt är vad AWS kallar modellen defence-in-depth för molnstyrning.

I den här lektionen har Ni lärt Er att Conformance Packs samlar flera Config-regler i en enda distribuerbar YAML-mall för efterlevnad av ramverk, att Organisation Conformance Packs automatiskt tillämpas på alla AWS Organisations konton och inte kan ändras av medlemskonton, samt att Organisation Trails centraliserar API-granskningsloggar från alla konton utan kontospecifik konfiguration. Härnäst utforskar vi EBS-volymtyper i Storage Deep Dive.