Scenarier för säker arkitektur

Scenario: En utvecklare gjorde av misstag en S3-bucket offentlig, vilket exponerade kunddata. Säkerhetsteamet vill säkerställa att ingen S3-bucket i kontot någonsin kan göras offentlig, även om en utvecklare försöker. Lösning: Aktivera S3 Block Public Access på kontonivå. Detta åsidosätter alla bucket-policyer eller ACL:er som ger offentlig åtkomst, oavsett vad enskilda team konfigurerar. Kombinera detta med en AWS Config-regel (s3-bucket-public-read-prohibited) för att kontinuerligt upptäcka och varna för buckets som inte följer kraven.

Scenario: Ett företag vill säkerställa att deras RDS-databas endast är åtkomlig från applikationsservrarna och inte från internet. Lösning: Placera RDS i ett privat subnät utan rutt via en internetgateway. Skapa en säkerhetsgrupp för RDS som endast tillåter inkommande trafik på port 5432 (PostgreSQL) från applikationsservrarnas säkerhetsgrupp — inte från något IP-adressintervall. Detta säkerställer att en angripare inte kan nå databasen utifrån VPC:n även om en applikationsserver komprometteras, och begränsar lateral förflyttning genom reglerna för säkerhetsgrupper.

Scenario: Applikationskoden innehåller för närvarande hårdkodade autentiseringsuppgifter till databasen i konfigurationsfiler. Säkerhetsgranskningen flaggar detta som en kritisk risk. Lösning: Lagra autentiseringsuppgifterna i AWS Secrets Manager och konfigurera automatisk rotation (Secrets Manager har inbyggda Lambda-rotationsfunktioner för RDS). Uppdatera applikationen så att den hämtar autentiseringsuppgifterna från Secrets Manager under körning med hjälp av SDK:t. Applikationen får automatiskt nya autentiseringsuppgifter utan att behöva distribueras vid varje rotation. Aktivera mallen för rotation av RDS-hemligheter för helt hanterad rotation av autentiseringsuppgifter utan driftstopp.

Scenario: Ett företag vill upptäcka om autentiseringsuppgifter till AWS-kontot har komprometterats och används från oväntade platser. Lösning: Aktivera Amazon GuardDuty i alla regioner. GuardDuty analyserar CloudTrail-händelser, VPC Flow Logs och DNS-loggar med hjälp av maskininlärning för att upptäcka avvikelser: API-anrop från ovanliga geografiska platser, mönster som tyder på bitcoinbrytning på EC2, kommunikation med Tor-utgångsnoder eller mönster som tyder på exfiltrering av autentiseringsuppgifter. GuardDuty genererar fynd som kan utlösa EventBridge-regler för att automatiskt meddela säkerhetsteamet via SNS eller skapa ett supportärende.

Scenario: En webbapplikation bakom en ALB utsätts för SQL-injektionsattacker. Applikationen kan inte ändras omedelbart. Lösning: Koppla AWS WAF till ALB:n. Distribuera regelgruppen AWS Managed Rules for Common Threats (Core Rule Set + SQL Database rule group), som innehåller färdiga funktioner för att upptäcka SQL-injektioner. WAF inspekterar HTTP-förfrågningar innan de når ALB:n och blockerar förfrågningar som matchar attackmönster — inga ändringar i applikationskoden krävs. Aktivera även WAF-loggning till Kinesis Firehose för säkerhetsanalys.

Scenario: Ett centralt säkerhetskonto behöver skrivskyddad åtkomst till alla arbetsbelastningskonton i en AWS Organisation för att genomföra säkerhetsgranskningar. Lösning: Skapa i varje arbetsbelastningskonto en IAM-roll med en trust policy som tillåter säkerhetskontot (genom konto-ID:t) att anta rollen. Koppla en skrivskyddad policy till rollen (till exempel SecurityAudit AWS managed policy). Säkerhetsteamet i det centrala kontot använder STS AssumeRole för att tillfälligt anta rollen i varje arbetsbelastningskonto. Detta följer principen om minsta möjliga behörighet — inga permanenta IAM-användare skapas i arbetsbelastningskontona.

Scenario: Ett företag använder AWS Organizations och vill förhindra att konton i en icke-produktions-OU startar dyra GPU-instanser. Lösning: Skapa en Service Control Policy (SCP) som nekar ec2:RunInstances för GPU-instansfamiljerna (p3, p4, g4, g5) och koppla den till icke-produktions-OU:n. SCP:er gäller även för rotanvändare och IAM-användare med administratörsbehörighet i medlemskontona — de fungerar som skyddsräcken som ingen identitet i kontot kan kringgå. Detta förhindrar oavsiktliga eller skadliga stora utgifter i utvecklings- och testkonton.

Scenario: Ett företag inom finansiella tjänster måste kunna visa revisorer att alla AWS API-anrop loggas, är manipulationssäkra och sparas i 7 år. Lösning: Skapa ett multi-region AWS CloudTrail-spår som levererar loggar till en dedikerad S3-bucket i ett loggningskonto. Aktivera Log File Integrity Validation (kryptografiska digest-filer som upptäcker manipulation av loggar). Ange en S3-policy för Object Lock i Compliance-läge med en lagringsperiod på 7 år för loggningsbucketen. Detta säkerställer att loggarna inte kan tas bort eller ändras — inte ens av rotanvändaren — under den obligatoriska lagringsperioden.

Scenario: EC2-instanser i en privat VPC behöver komma åt S3 utan att trafiken går via det offentliga internet. En NAT Gateway används för närvarande och kostnaderna är höga på grund av avgifterna för databehandling i NAT Gateway. Lösning: Skapa en S3 Gateway VPC Endpoint. Lägg till en rutt i det privata subnätets routningstabell som pekar S3-prefixlistan till endpointen. Trafiken till S3 stannar nu helt inom AWS-nätverkets stamnät — ingen NAT Gateway eller internetgateway behövs. S3 Gateway Endpoints är kostnadsfria (till skillnad från Interface Endpoints, som kostar per timme och tillgänglighetszon). Detta förbättrar även säkerheten genom att ta bort S3-åtkomst från vägen via det offentliga internet.

I den här lektionen gick ni igenom scenarier som omfattade: IAM-roller och instansprofiler för EC2-åtkomst utan autentiseringsuppgifter, Secrets Manager för automatisk rotation av databasautentiseringsuppgifter, AWS WAF för att blockera injektionsattacker utan kodändringar samt CloudTrail med S3 Object Lock för manipulationssäkra efterlevnadsloggar. Härnäst går vi igenom scenarier för motståndskraftiga arkitekturer med hög tillgänglighet.