I henhold til AWS' Shared Responsibility Model håndterer AWS "sikkerheden AF skyen" (fysiske datacentre, serverhardware, virtualiseringslag), mens kunden har det fulde ansvar for "sikkerheden I skyen" – herunder identitetsstyring, nøglehygiejne og adgangskontrol. Hvis en ubeskyttet AWS Root-konto eller priviligerede IAM-legitimationsoplysninger kompromitteres, kan trusselsaktører oprette tusindvis af GPU-instanser til ulovlig kryptomining, lække private data fra S3-buckets eller slette hele virksomhedens cloud-infrastruktur.
MFA er obligatorisk for alle administrative konsolbrugere og ufravigelig for AWS Root-kontoen.
AWS tillader registrering af op til 8 separate FIDO2- og virtuelle TOTP-tokens pr. konto, hvilket eliminerer single points of failure.
Global IAM-politik blokerer alle uautoriserede API-kald, indtil aktiv MFA-validering er gennemført.
Cloud Compliance-grundlag: CIS Benchmark & regulatoriske rammer
Uanset om din organisation arbejder mod SOC 2 Type II-godkendelse, ISO 27001-certificering, PCI DSS 4.0-validering eller følger AWS Well-Architected Security Pillar, er implementering af MFA på tværs af IAM-identiteter et ufravigeligt grundkrav:
| Standard / Compliance-ramme | Kontrolspecifikation | Kravniveau | Revisionsvalidering |
|---|---|---|---|
| CIS AWS Foundations Benchmark v3.0 | 1.5 / 1.6 / 1.10 | Level 1 (Obligatorisk) | Automatiseret kontrol via AWS Security Hub / Prowler |
| PCI DSS 4.0 | Krav 8.4.2 | Obligatorisk | Revision af konsol- og API-adgang til kortdatabackend (CDE) |
| SOC 2 Type II (Trust Criteria) | CC6.1 / CC6.2 | Nøglekontrol | Revisoreftersyn af IAM Credential Reports |
| AWS obligatorisk MFA-udrulning | AWS 2024–2026 Politik | Platformsblokeret | Root-login blokeres ved gateway, indtil MFA er tilknyttet |
Den afgørende nødvendighed af at sikre AWS Root-kontoen
I en AWS-konto er Root-brugeren den almægtige identitet, der skabes ved kontooprettelsen. I modsætning til IAM-roller eller brugere kan Root-kontoens handlinger ikke begrænses af IAM-politikker eller Service Control Policies inden for enkeltstående konti.
Katastrofale konsekvenser ved en kompromitteret Root-konto:
- Uigenkaldelig kontolukning: Angribere kan klikke på "Close Account" og igangsætte permanent sletning af hele infrastrukturen.
- Økonomisk kapring & regningssvindel: Ændre faktureringsoplysninger, udskifte betalingskort og igangsætte hundredvis af dyre GPU spot-instanser på tværs af mere end 30 AWS-regioner til kryptomining.
- Destruktion af AWS Organizations-strukturen: Fjerne medlemskonti fra organisationen og ødelægge den centrale overvågning.
- Ændring af primære sikkerhedskontakter: Ved at ændre rod-e-mail og telefonnumre afskæres AWS Support fra at assistere i en krisesituation.
- Ingen faste adgangsnøgler til Root (Zero Access Keys): Inspicer IAM Credential Reports og bekræft, at der ikke findes statiske access keys til Root. Hvis de findes, skal de slettes straks.
- Delt kontrol over adgangskoden (Dual-Custody): Generer en vilkårlig adgangskode på mindst 32 tegn, del den mellem CISO og juridisk chef, og opbevar delene i adskilte fysiske brandskabe.
- Flere enheder til redundans (op til 8 enheder): Tilknyt mindst to fysiske FIDO2-hardwarenøgler (f.eks. YubiKey) samt en offline, koldopbevaret virtuel TOTP-nødenhed.
Valg af MFA: Virtuel TOTP vs. hardware FIDO2 (YubiKey)
AWS understøtter tre primære typer af MFA-enheder. Valget bør træffes ud fra organisationens trusselsmodel og de pågældende brugeres privilegieniveau:
Virtuelle TOTP-apps
Standard RFC 6238-koder (Google Authenticator, 1Password, 2FA-Tool). Hurtig udrulning uden hardwareanskaffelse. Velegnet til almindelige udviklere.
YubiKey 5-serien
Phishing-resistent kryptografi. Domænebundne offentlige nøgleattesteringer modstår reverse-proxy phishing-angreb. Obligatorisk for Root & administratorer.
Gemalto / Thales-kort
Fritstående, batteridrevne TOTP-kort med LCD-skærm. Uundværlige i sikrede faciliteter (SCIFs), hvor smartphones og USB-enheder er forbudt.
Enterprise Hardware MFA FIPS 140-2 Level 3 & to-personers kontrol:
For store koncerner og forsvarsleverandører kræver sikring af Root-kontoen dedikerede hardwarenøgler (f.eks. SafeNet/Gemalto IDPrime) certificeret efter FIPS 140-2 Level 3. I modsætning til smartphones har disse enheder ingen trådløse grænseflader eller Bluetooth og kan ikke overvåges af spyware.
Fysisk to-personers godkendelse: I enterprise-procedurer kræver Root-adgang to personer: Den ene medarbejder kender e-mail og adgangskode, mens en uafhængig sikkerhedsansvarlig har nøglen til det fysiske pengeskab med hardwaretokenet. Ingen af parterne kan få adgang til Root-kontoen på egen hånd.
Håndhævelse af MFA via IAM-politikker (JSON-implementering)
Sikkerhedskrav kan ikke baseres på medarbejdernes frivillighed. Cloudstyring kræver automatisk håndhævelse: brugere uden aktiv MFA-godkendelse skal nægtes samtlige handlinger i AWS API og konsol, bortset fra muligheden for selv at konfigurere deres egen MFA-enhed.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowViewAccountInfo",
"Effect": "Allow",
"Action": [
"iam:GetAccountPasswordPolicy",
"iam:ListVirtualMFADevices"
],
"Resource": "*"
},
{
"Sid": "AllowManageOwnVirtualMFADevice",
"Effect": "Allow",
"Action": [
"iam:CreateVirtualMFADevice",
"iam:DeleteVirtualMFADevice"
],
"Resource": "arn:aws:iam::*:mfa/${aws:username}"
},
{
"Sid": "AllowManageOwnUserMFA",
"Effect": "Allow",
"Action": [
"iam:DeactivateMFADevice",
"iam:EnableMFADevice",
"iam:ListMFADevices",
"iam:ResyncMFADevice"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "BlockAllAccessUnlessMFAAuthenticated",
"Effect": "Deny",
"NotAction": [
"iam:CreateVirtualMFADevice",
"iam:EnableMFADevice",
"iam:ListMFADevices",
"iam:ListVirtualMFADevices",
"iam:ResyncMFADevice",
"iam:GetUser"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}
Regel 4 evaluerer den globale betingelsesnøgle "aws:MultiFactorAuthPresent": "false" med et eksplicit Deny. Da et eksplicit Deny altid tilsidesætter eventuelle Allow-tilladelser, blokeres sessioner uden MFA øjeblikkeligt for alle AWS API'er og henviser brugeren direkte til MFA-registreringsskærmen.
MFA-godkendelse i AWS CLI & SDK: Midlertidige STS-sessionstokens
Når IAM-politikker kræver MFA, vil udviklere, der udfører kommandoer som aws s3 ls eller kører Terraform, modtage en fejlmeddelelse om AccessDenied. Statiske adgangsnøgler kan nemlig ikke interaktivt efterspørge engangskoder.
Udviklere skal derfor anvende AWS STS (Security Token Service) til at omveksle statiske nøgler + en 6-cifret TOTP-kode til midlertidige legitimationsoplysninger:
Automatiseringsscript (aws-mfa-session.sh):
Placer dette hjælpescript i dit lokale miljø (~/.aws/aws-mfa-session.sh) for at automatisere sessionshåndteringen:
# Ombyt statiske AWS-nøgler + MFA-kode til et midlertidigt STS-sessionstoken
MFA_ARN="arn:aws:iam::123456789012:mfa/alex-dev"
echo -n "Indtast 6-cifret 2FA-kode: "
read -r TOKEN_CODE
SESSION_JSON=$(aws sts get-session-token \
--serial-number "$MFA_ARN" \
--token-code "$TOKEN_CODE" \
--duration-seconds 43200 \
--output json)
if [ $? -eq 0 ]; then
export AWS_ACCESS_KEY_ID=$(echo "$SESSION_JSON" | jq -r '.Credentials.AccessKeyId')
export AWS_SECRET_ACCESS_KEY=$(echo "$SESSION_JSON" | jq -r '.Credentials.SecretAccessKey')
export AWS_SESSION_TOKEN=$(echo "$SESSION_JSON" | jq -r '.Credentials.SessionToken')
echo "✅ Godkendt! Midlertidig session eksporteret (Gyldig i 12 timer)."
else
echo "❌ Godkendelse mislykkedes. Kontroller koden eller telefonens tidsindstilling."
fi
Tværgående AssumeRole med MFA-betingelser
I multi-konto enterprise-miljøer logger priviligerede udviklere typisk ind på en central identitetskonto og overtager derefter roller i målkonti (f.eks. Produktion, Staging) via sts:AssumeRole. For at forhindre, at produktionsadgang misbruges via lækkede nøgler, skal produktionsrollens tillidspolitik (trust policy) kræve aktiv MFA:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
Dette arkitekturmønster sikrer, at selv hvis en angriber får fat i legitimationsoplysninger i den centrale konto, vil et forsøg på at overtage produktionsrollen uden aktiv MFA øjeblikkeligt udløse en AccessDenied-fejl.
CloudTrail-overvågning & EventBridge-alarmer i realtid
Automatiseret sikkerhedsovervågning kræver omgående besked, hvis en bruger tilgår AWS Management Console uden totrinsgodkendelse. Ved at opsnappe AWS CloudTrail-hændelser og dirigere dem gennem Amazon EventBridge kan SecOps-teams opsætte øjeblikkelige alarmer:
{
"source": ["aws.signin"],
"detail-type": ["AWS Console Sign In via CloudTrail"],
"detail": {
"eventName": ["ConsoleLogin"],
"additionalEventData": {
"MFAUsed": ["No"]
}
}
}
Når hændelsen modtages, kan EventBridge sende en notifikation via Amazon SNS til vagtholdet eller kalde en AWS Lambda-funktion, der straks afbryder den pågældende brugersession.
Styring på tværs af konti: AWS Organizations & IAM Identity Center
I virksomhedsmiljøer med snesevis eller hundredvis af AWS-konti er manuel oprettelse af lokale IAM-brugere i hver enkelt konto et uhensigtsmæssigt anti-mønster.
Centraliseret identitetsføderation:
Implementer AWS IAM Identity Center (tidligere AWS SSO) i din primære administrationskonto. Forbind identiteter til virksomhedens IdP (Okta, Microsoft Entra ID, PingFederate). Håndhæv MFA centralt i virksomhedens IdP, og tilknyt Service Control Policies (SCPs) i roden af din AWS Organization for at blokere utilsigtede handlinger på medlemskontis Root-brugere:
"Condition": { "StringLike": { "aws:PrincipalArn": ["arn:aws:iam::*:root"] } }
Produktionsklar SCP: Håndhæv MFA på tværs af alle medlemskonti
I større organisationer kan lokale administratorer ved et uheld tildele for brede rettigheder. Ved at tilknytte en Service Control Policy (SCP) på organisations- eller OU-niveau etableres et ufravigeligt sikkerhedsværn: Kritiske API-handlinger blokeres betingelsesløst, medmindre de godkendes af en aktiv MFA-session:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyCriticalActionsWithoutMFA",
"Effect": "Deny",
"Action": [
"iam:CreateAccessKey",
"iam:CreateLoginProfile",
"s3:DeleteBucket",
"kms:ScheduleKeyDeletion",
"ec2:TerminateInstances"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}
Rolle-kædning og levetid for STS-tokens:
Når IAM-identiteter overtager en mellemliggende rolle, der derefter overtager en efterfølgende rolle ("role chaining"), fjerner AWS STS den oprindelige aws:MultiFactorAuthPresent-kontekst fra det nye sessionstoken! For at opretholde ubrudt compliance på tværs af konti bør du overtage roller direkte fra den MFA-godkendte IAM Identity Center-session frem for at kæde flere IAM-roller sammen.
Nødgenopretning: Procedure ved mistet Root MFA-enhed
Hvad gør man, hvis samtlige registrerede hardwarenøgler og virtuelle MFA-enheder til Root-kontoen går tabt eller ødelægges?
Officiel nødprocedure (Out-of-Band Recovery):
- Start Root-login: Indtast Root-kontoens e-mailadresse og adgangskode på AWS-konsollen.
- Vælg fejlfinding: På MFA-skærmen klikkes på "Troubleshoot MFA".
- Verifikation via primær e-mail: AWS fremsender et tidsbegrænset bekræftelseslink til den primære Root-e-mailadresse. Følg linket for at bekræfte.
- Automatisk telefonopkald: Klik på "Call me now". Det automatiserede AWS-system ringer til det registrerede primære telefonnummer og oplyser en 6-cifret bekræftelses-PIN.
Hvis din organisation har skiftet telefonnummer, eller kontaktpersonen er fratrådt uden opdatering i AWS-kontoindstillingerne, vil den automatiske gendannelse mislykkes. Manuel genskabelse kræver indsendelse af notarbekræftede virksomhedsdokumenter til AWS Trust & Safety, hvilket typisk tager 3–7 arbejdsdage.
Ofte stillede spørgsmål fra cloudarkitekter (FAQ)
Må AWS Root MFA-tokens deles internt i et DevOps-team? ▼
Strengt forbudt. Deling af Root MFA-oplysninger dumper samtlige compliance-revisioner (SOC 2, ISO 27001). Rutinemæssig administration skal foregå via IAM Identity Center med individuel sporbarhed. Root-oplysningerne skal forblive låst inde i fysiske pengeskabe med to-personers kontrol og må kun benyttes ved absolutte nødsituationer (break-glass).
Hvordan styrker betingelsesnøglen aws:MultiFactorAuthAge sikkerheden? ▼
Denne nøgle sikrer, at MFA-godkendelsen er frisk. Ved at konfigurere "NumericLessThan": {"aws:MultiFactorAuthAge": "3600"} kræves det, at MFA-koden er indtastet inden for de seneste 3.600 sekunder (1 time). Kritiske handlinger (såsom sletning af en RDS-database) blokeres, hvis sessionen er ældre, hvilket beskytter mod kapring af langvarige sessioner.
Kan jeg bruge 2FA-Tool online godkenderen til at konfigurere virtuel AWS MFA? ▼
Ja. Virtuel AWS MFA overholder nøje RFC 6238 TOTP-specifikationen (HMAC-SHA1, 30-sekunders interval, 6 cifre). Du kan indtaste den hemmelige Base32-streng på 2FA-Tool.com for at generere de to på hinanden følgende bekræftelseskoder, der kræves ved registrering – 100 % lokalt i din browser.
Test enterprise TOTP-koder sikkert
Generer standardmæssige RFC 6238 TOTP-bekræftelseskoder øjeblikkeligt med W3C Web Crypto API. Ingen serverkald, fuld hukommelsesisolering, nul datalækage.