AWS Solutions Architect · Lektion

Scenarier for sikre arkitekturer

Arbejd med scenariebaserede spørgsmål om IAM med mindst mulige privilegier, kryptering, VPC-isolering og WAF/Shield for at styrke din viden om sikkerhedsdomænet

Lektion 1 af 413 trin

Scenarier for sikre arkitekturer er en gratis AWS Solutions Architect-lektion på CoddyKit. Dette er lektion 1 af 4. Du kan læse alle 3 lektioner i dette læringsspor gratis i deres fulde længde — derefter låser CoddyKit PRO alle lektioner op samt praktiske øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. Den er en del af læringsforløbet i AWS Solutions Architect, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. AWS Solutions Architect-kurset indeholder 4 lektioner i alt.

Scenarie 1: EC2-adgang til S3 med mindst mulige privilegier

Scenarie: En EC2-instans kører en webapplikation, der skal læse objekter fra en bestemt S3-bucket. Sikkerhedsteamet kræver, at der ikke gemmes legitimationsoplysninger med lang levetid på instansen, og at adgangen følger princippet om mindst mulige privilegier. Løsning: Opret en IAM-rolle med en politik, der kun tillader s3:GetObject på den specifikke bucket-ARN. Tilknyt rollen til EC2-instansen som en instansprofil. Applikationen bruger instansens metadatatjeneste (IMDS) til automatisk at hente midlertidige legitimationsoplysninger — der er ikke behov for gemte nøgler.

# IAM policy for least-privilege EC2 -> S3 read
{
  'Version': '2012-10-17',
  'Statement': [{
    'Effect': 'Allow',
    'Action': ['s3:GetObject'],
    'Resource': 'arn:aws:s3:::my-app-bucket/*'
  }]
}

# Attach role to EC2 instance
aws ec2 associate-iam-instance-profile \
  --instance-id i-1234567890abcdef0 \
  --iam-instance-profile Name=EC2S3ReadRole

Scenarie 2: Kryptering af data i en RDS-database

Scenarie: En virksomhed gemmer personligt identificerbare oplysninger om kunder i en RDS PostgreSQL-database. Compliance-teamet kræver kryptering af data i hvile samt mulighed for at revidere brugen af nøglen. Løsning: Aktivér RDS-kryptering ved hjælp af AWS KMS med en Customer Managed Key (CMK). CMK'en giver sikkerhedsteamet mulighed for at styre nøgle-rotation, se nøglebrug i CloudTrail og tilbagekalde adgang efter behov. Bemærk: kryptering skal aktiveres, når RDS-instansen oprettes — du kan ikke kryptere en eksisterende ukrypteret RDS-instans på stedet. Hvis du vil kryptere en eksisterende database, skal du tage et snapshot, kopiere det med kryptering aktiveret og gendanne fra det krypterede snapshot.

# Create an encrypted RDS instance
aws rds create-db-instance \
  --db-instance-identifier prod-postgres \
  --db-instance-class db.t3.medium \
  --engine postgres \
  --master-username admin \
  --master-user-password SecurePass123! \
  --storage-encrypted \
  --kms-key-id arn:aws:kms:us-east-1:123456789012:key/mrk-abc123 \
  --allocated-storage 100

Scenarie 3: S3-bucket — blokering af offentlig adgang

Scenarie: En udvikler gjorde ved en fejl en S3-bucket offentlig, så kundedata blev eksponeret. Sikkerhedsteamet vil sikre, at ingen S3-bucket på kontoen nogensinde kan gøres offentlig, heller ikke hvis en udvikler forsøger. Løsning: Aktivér S3 Block Public Access på kontoniveau. Det tilsidesætter enhver politik eller ACL på bucket-niveau, der giver offentlig adgang, uanset hvad de enkelte teams konfigurerer. Kombinér dette med en AWS Config-regel (s3-bucket-public-read-prohibited) for løbende at registrere og advare om buckets, der ikke overholder kravene.

# Block all public access at account level
aws s3control put-public-access-block \
  --account-id 123456789012 \
  --public-access-block-configuration \
    'BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true'

# Deploy Config rule to detect violations
aws configservice put-config-rule \
  --config-rule '{"ConfigRuleName": "s3-bucket-public-read-prohibited", "Source": {"Owner": "AWS", "SourceIdentifier": "S3_BUCKET_PUBLIC_READ_PROHIBITED"}}'

Scenarie 4: VPC-isolering af databaselaget

Scenarie: En virksomhed vil sikre, at dens RDS-database kun er tilgængelig fra applikationsserverne og ikke fra internettet. Løsning: Placér RDS i et privat subnet uden en rute til en internetgateway. Opret en sikkerhedsgruppe til RDS, der kun tillader indgående trafik på port 5432 (PostgreSQL) fra applikationsservernes sikkerhedsgruppe — ikke fra noget IP-adresseområde. Det sikrer, at en angriber ikke kan få adgang til databasen udefra VPC'en, selv hvis en applikationsserver kompromitteres, og at lateral bevægelse begrænses af reglerne for sikkerhedsgrupper.

# Create RDS security group allowing only the app tier SG as source
aws ec2 create-security-group \
  --group-name rds-sg \
  --description 'RDS security group' \
  --vpc-id vpc-abc123

aws ec2 authorize-security-group-ingress \
  --group-id sg-rds \
  --protocol tcp \
  --port 5432 \
  --source-group sg-app  # app tier security group ID only

Scenarie 5: Rotation af databaselegitimationsoplysninger

Scenarie: Applikationskoden har i øjeblikket databaselegitimationsoplysninger indlejret i konfigurationsfiler. Sikkerhedsrevisionen markerer dette som en kritisk risiko. Løsning: Gem legitimationsoplysningerne i AWS Secrets Manager, og konfigurér automatisk rotation (Secrets Manager har indbyggede Lambda-rotationsfunktioner til RDS). Opdatér applikationen, så den henter legitimationsoplysninger fra Secrets Manager under kørsel ved hjælp af SDK'et. Applikationen får automatisk friske legitimationsoplysninger uden en udrulning ved hver rotation. Aktivér skabelonen til rotation af RDS-hemmeligheder for fuldt administreret rotation uden nedetid.

# Store RDS credentials in Secrets Manager
aws secretsmanager create-secret \
  --name prod/myapp/rds \
  --secret-string '{"username":"admin","password":"OldPass123!","host":"rds-endpoint.amazonaws.com","port":5432}'

# Enable automatic rotation every 30 days
aws secretsmanager rotate-secret \
  --secret-id prod/myapp/rds \
  --rotation-lambda-arn arn:aws:lambda:us-east-1:123:function:SecretsManagerRDSPostgreSQLRotationSingleUser \
  --rotation-rules AutomaticallyAfterDays=30

Scenarie 6: Registrering af usædvanlig API-aktivitet

Scenarie: En virksomhed vil registrere, om AWS-kontoens legitimationsoplysninger er blevet kompromitteret og bruges fra uventede placeringer. Løsning: Aktivér Amazon GuardDuty i alle Regioner. GuardDuty analyserer CloudTrail-hændelser, VPC Flow Logs og DNS-logfiler ved hjælp af maskinlæring for at registrere afvigelser: API-kald fra usædvanlige geografiske områder, mønstre for Bitcoin-mining på EC2, kommunikation med Tor-exitnoder eller mønstre for eksfiltrering af legitimationsoplysninger. GuardDuty genererer fund, der kan udløse EventBridge-regler, som automatisk underretter sikkerhedsteamet via SNS eller opretter en supportsag.

# Enable GuardDuty in a Region
aws guardduty create-detector \
  --enable \
  --finding-publishing-frequency FIFTEEN_MINUTES

# EventBridge rule to react to GuardDuty HIGH severity findings
aws events put-rule \
  --name guardduty-high-severity \
  --event-pattern '{
    "source": ["aws.guardduty"],
    "detail-type": ["GuardDuty Finding"],
    "detail": {"severity": [{"numeric": [">=", 7]}]}
  }'

Scenarie 7: WAF til blokering af ondsindede forespørgsler

Scenarie: En webapplikation, der kører bag en ALB, modtager SQL-injektionsangreb. Applikationen kan ikke ændres med det samme. Løsning: Tilknyt AWS WAF til ALB'en. Udrul regelgruppen AWS Managed Rules for Common Threats (Core Rule Set + SQL Database-regelgruppen), som omfatter forudbyggede funktioner til registrering af SQL-injektioner. WAF inspicerer HTTP-forespørgsler, før de når ALB'en, og blokerer forespørgsler, der matcher angrebsmønstre — der kræves ingen ændring af applikationskoden. Aktivér også WAF-logning til Kinesis Firehose til sikkerhedsanalyse.

# Create WAF Web ACL with SQL injection protection
aws wafv2 create-web-acl \
  --name AppProtection \
  --scope REGIONAL \
  --default-action Allow={} \
  --rules '[{
    "Name": "AWSManagedRulesSQLiRuleSet",
    "Priority": 1,
    "Statement": {
      "ManagedRuleGroupStatement": {
        "VendorName": "AWS",
        "Name": "AWSManagedRulesSQLiRuleSet"
      }
    },
    "OverrideAction": {"None": {}},
    "VisibilityConfig": {"SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "SQLi"}
  }]' \
  --region us-east-1

Scenarie 8: Antagelse af rolle på tværs af konti

Scenarie: En central sikkerhedskonto har brug for skrivebeskyttet adgang til alle workload-konti i en AWS Organisation for at udføre sikkerhedsrevisioner. Løsning: Opret i hver workload-konto en IAM-rolle med en tillidspolitik, der tillader sikkerhedskontoen (via konto-ID) at antage rollen. Tilknyt en skrivebeskyttet politik (for eksempel SecurityAudit AWS managed policy). Sikkerhedsteamet på den centrale konto bruger STS AssumeRole til midlertidigt at antage rollen i hver workload-konto. Det følger princippet om mindst mulige privilegier — der oprettes ingen permanente IAM-brugere i workload-konti.

# Trust policy in workload account (allows security account to assume role)
{
  'Version': '2012-10-17',
  'Statement': [{
    'Effect': 'Allow',
    'Principal': {
      'AWS': 'arn:aws:iam::SECURITY_ACCOUNT_ID:root'
    },
    'Action': 'sts:AssumeRole'
  }]
}

# From security account: assume role in workload account
aws sts assume-role \
  --role-arn arn:aws:iam::WORKLOAD_ACCOUNT_ID:role/SecurityAuditRole \
  --role-session-name audit-2024-01

Scenarie 9: Begrænsning af handlinger med SCP'er

Scenarie: En virksomhed bruger AWS Organizations og vil forhindre enhver konto i en ikke-produktions-OU i at starte dyre GPU-instanser. Løsning: Opret en Service Control Policy (SCP), der nægter ec2:RunInstances for GPU-instansfamilierne (p3, p4, g4, g5), og tilknyt den til ikke-produktions-OU'en. SCP'er gælder også for root-brugere og IAM-brugere på Administrator-niveau i medlemskontiene — de fungerer som sikkerhedsrammer, som ingen identitet på kontoen kan tilsidesætte. Det forhindrer utilsigtede eller ondsindede store udgifter i udviklings- og testkonti.

# SCP to deny GPU instance types in non-prod OU
{
  'Version': '2012-10-17',
  'Statement': [{
    'Sid': 'DenyGPUInstances',
    'Effect': 'Deny',
    'Action': 'ec2:RunInstances',
    'Resource': 'arn:aws:ec2:*:*:instance/*',
    'Condition': {
      'StringLike': {
        'ec2:InstanceType': ['p3.*', 'p4d.*', 'g4.*', 'g5.*']
      }
    }
  }]
}

Scenarie 10: Revisionsspor til compliance

Scenarie: En virksomhed inden for finansielle tjenester skal kunne dokumentere over for revisorer, at alle AWS API-kald logges, ikke kan manipuleres og opbevares i 7 år. Løsning: Opret et multi-region AWS CloudTrail-spor, der leverer logfiler til en dedikeret S3-bucket på en logningskonto. Aktivér validering af logfilers integritet (kryptografiske digest-filer, der registrerer manipulation af logfiler). Angiv en S3-Object Lock-politik i Compliance-tilstand med en opbevaringsperiode på 7 år på logningsbucketen. Det sikrer, at logfilerne ikke kan slettes eller ændres — heller ikke af root-brugeren — i den krævede opbevaringsperiode.

# Create multi-region trail with integrity validation
aws cloudtrail create-trail \
  --name compliance-trail \
  --s3-bucket-name central-audit-logs-123 \
  --is-multi-region-trail \
  --enable-log-file-validation \
  --include-global-service-events

aws cloudtrail start-logging --name compliance-trail

Scenarie 11: VPC-endpoint til privat S3-adgang

Scenarie: EC2-instanser i en privat VPC skal have adgang til S3 uden at trafikken passerer det offentlige internet. Der bruges i øjeblikket en NAT Gateway, og omkostningerne er høje på grund af NAT Gateway-gebyrerne for databehandling. Løsning: Opret et S3 Gateway VPC Endpoint. Tilføj en rute til det private subnets rutetabel, som peger S3-præfikslisten på endpointet. Trafikken til S3 forbliver nu helt inden for AWS-netværkets backbone — der kræves hverken NAT Gateway eller internetgateway. S3 Gateway Endpoints er gratis (i modsætning til Interface Endpoints, som koster pr. time pr. AZ). Det forbedrer også sikkerheden ved at fjerne S3-adgang fra stien via det offentlige internet.

# Create S3 Gateway VPC Endpoint
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-abc123 \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids rtb-private-1a rtb-private-1b

# Result: route table automatically gets a route:
# Destination: pl-63a5400a (S3 prefix list)
# Target: vpce-xyz456 (the Gateway Endpoint)
# EC2 instances now reach S3 privately at no endpoint cost

Hurtig kontrol

Test din forståelse af begreberne i AWS Solutions Architect (SAA-C03) fra denne lektion.

Besvar den i den interaktive lektion

Opsummering af lektionen

I denne lektion arbejdede du med scenarier, der dækkede: IAM-roller og instansprofiler til EC2-adgang uden legitimationsoplysninger, Secrets Manager til automatisk rotation af databaselegitimationsoplysninger, AWS WAF til blokering af injektionsangreb uden kodeændringer og CloudTrail med S3 Object Lock til manipulationssikre overholdelseslogge. Dernæst arbejder du med scenarier for robust og highly available arkitektur.

Gratis at komme i gang

Lær AWS Solutions Architect med en AI-underviser — gratis

Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.

Kurser: 30
Lektioner: 120

Start gratis Se hele kurset

Ofte stillede spørgsmål

Er lektionen “Scenarier for sikre arkitekturer” gratis?

Ja — alle 3 lektioner i læringssporet AWS Solutions Architect, inklusive “Scenarier for sikre arkitekturer”, kan læses gratis i deres fulde længde her på webstedet. Derefter låser CoddyKit PRO alle lektioner op samt interaktive øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. AWS Solutions Architect-kurset indeholder 4 lektioner i alt.

Hvad lærer jeg i “Scenarier for sikre arkitekturer”?

Arbejd med scenariebaserede spørgsmål om IAM med mindst mulige privilegier, kryptering, VPC-isolering og WAF/Shield for at styrke din viden om sikkerhedsdomænet Du øver dig i AWS Solutions Architect med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.

Skal jeg have erfaring for at begynde på AWS Solutions Architect?

Der kræves ingen tidligere erfaring. AWS Solutions Architect på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 1 af 4.

Hvor lang tid tager lektionen “Scenarier for sikre arkitekturer”?

De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.

Kan jeg skrive og køre kode i denne AWS Solutions Architect-lektion?

Ja. Alle AWS Solutions Architect-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.

Alle lektioner i dette kursus

Scenarier for sikre arkitekturer
Scenarier for robuste arkitekturer med høj tilgængelighed
Scenarier med høj ydeevne og omkostningsoptimering
Blandet mini-eksamen i fuld længde

← Tilbage til AWS Solutions Architect