Enligt AWS delade ansvarsmodell (Shared Responsibility Model), medan AWS hanterar "säkerhet AV molnet" (fysiska datacenter, värdmaskinvara, hypervisorer), behåller kunden det fulla ansvaret för "säkerhet I molnet" – särskilt identitetsstyrning, god hantering av inloggningsuppgifter och åtkomstkontroll. En kompromettering av ett obegränsat AWS-rotkonto eller privilegierade IAM-uppgifter tillåter hotaktörer att provisionera otillåtna GPU-kryptominningsinstanser för tusentals dollar, exfiltrera privata S3-datasjöar eller genomföra katastrofala utpressningsraderingar.
MFA är obligatoriskt för alla administratörsanvändare i konsolen och absolut icke förhandlingsbart för AWS-rotkontot.
AWS tillåter registrering av upp till 8 separata FIDO2- och virtuella TOTP-tokens per konto, vilket eliminerar enstaka felpunkter.
En global villkorad IAM-neka-policy blockerar alla obehöriga API-anrop tills en aktiv MFA-validering har uppnåtts.
Molnefterlevnadsgrundlinjer: CIS Benchmark och regelverk
Oavsett om din tekniska organisation siktar på SOC 2 Type II-attestering, ISO 27001-certifiering, PCI DSS 4.0-validering eller anpassning till AWS Well-Architected säkerhetspelare, är implementering av MFA över alla IAM-identiteter ett grundläggande behörighetskrav:
| Standard / Efterlevnadsstandard | Kontrollspecifikation | Allvarlighetsgrad / Krav | Mekanism för granskningsvalidering |
|---|---|---|---|
| CIS AWS Foundations Benchmark v3.0 | 1.5 / 1.6 / 1.10 | Nivå 1 (Obligatorisk) | Automatiserad bedömning via AWS Security Hub / Prowler |
| PCI DSS 4.0 | Krav 8.4.2 | Obligatoriskt | Konsol- och API-granskning av kortinnehavardatamiljön (CDE) |
| SOC 2 Type II (Trust Criteria) | CC6.1 / CC6.2 | Nyckelkontroll | Oberoende CPA-inspektion av IAM-behörighetsrapporter (Credential Reports) |
| Obligatorisk MFA-utrullning i AWS | AWS 2024–2026 Policy | Plattformstillämpning | Blockerad rotinloggningsgateway tills MFA-registrering har slutförts |
Det absoluta kravet på att säkra AWS-rotkontot
Inom ett AWS-kontos gränser representerar rotkontot den allsmäktiga identitet som skapades vid kontots start. Till skillnad från IAM-roller eller IAM-användare kan rotkontots åtgärder inte begränsas av IAM-identitetsbaserade policyer eller Service Control Policies (SCP) i fristående konton.
Katastrofal skaderadie vid ett komprometterat rotkonto:
- Irreversibel kontostängning: Hotaktörer kan klicka på "Close Account", vilket schemalägger permanent förstörelse av infrastrukturen.
- Kapning av fakturering och ekonomi: Omdirigera fakturor, byta ut företagets betalkort och driftsätta hundratals GPU-spotinstanser över fler än 30 AWS-regioner för olaglig brytning av kryptovaluta.
- Splittring av AWS Organizations-strukturen: Ta bort medlemskonton från hanteringsträd, vilket slår ut organisationens efterlevnadsövervakning.
- Modifiering av primära säkerhetskontakter: Att ändra rotens e-post och telefonnummer bryter permanent de officiella kontaktvägarna för AWS-supportintervention.
- Inga åtkomstnycklar för rot: Granska IAM-behörighetsrapporter för att bekräfta att åtkomstnycklar (Access Keys) för rotkontot inte existerar. Om de finns, radera dem omedelbart.
- Lösenordsförvaring med delad vårdnad (Dual-Custody): Generera ett slumpmässigt lösenord på 32+ tecken, dela lösenordsfrasen mellan CISO och chefsjurist, och lås in delarna i separata fysiska brandsäkra kassaskåp.
- Redundans med flera enheter (upp till 8 enheter): Registrera minst två fysiska FIDO2-hårdvarunycklar (YubiKeys) plus en offline, kallförvarad virtuell TOTP-reservenhet.
MFA-urvalsmatris: Virtuell TOTP vs hårdvaru-FIDO2 (YubiKey)
AWS stöder tre primära klasser av MFA-enheter. Molnarkitekter bör anpassa valet utifrån hotmodeller och administrativa behörighetsnivåer:
Virtuella TOTP-applikationer
Standard RFC 6238-tokens (Google Authenticator, 1Password, 2FA-Tool). Snabb introduktion, noll upphandlingsfriktion. Perfekt för standardutvecklare.
YubiKey 5-serien
Nätfiske-resistent kryptografi. Ursprungsbundna public key-verifieringar motverkar nätfiskeverktyg med omvänd proxy. Obligatoriskt för rot och administratörer.
Gemalto- / Thales-kort
Självdrivet, frånkopplat (air-gapped) TOTP-kort med LCD-skärm. Oumbärligt för säkra faciliteter (SCIF) där smarttelefoner och USB-nycklar är förbjudna.
FIPS 140-2 nivå 3 hårdvaru-MFA och säkra protokoll med dubbel vårdnad för storföretag:
För Fortune 500-företag och försvarsleverantörer kräver rotkontosäkerhet dedikerade hårdvarunyckelbrickor (t.ex. SafeNet/Gemalto IDPrime fobs) certifierade enligt FIPS 140-2 Level 3. Till skillnad från smartphone-appar har dessa fysiska brickor inga trådlösa gränssnitt, inga Bluetooth-antenner och kan inte kapas via spionprogramvara i mobilen.
Fysisk styrning med delad vårdnad (Dual-Custody): I datacenterprotokoll för storföretag kräver rotåtkomst två olika personer: en förvaltare innehar huvudinloggningsuppgifterna för e-post, medan en oberoende säkerhetsansvarig har den fysiska nyckeln till ett säkert kassaskåp som innehåller hårdvarutokenen för rot. Ingen part kan självständigt få åtkomst till AWS-rotkontot.
Framtvinga MFA via IAM-policyer (JSON-implementering)
Säkerhetsgrundlinjer kan inte förlita sig på anställdas frivilliga agerande. Molnstyrning kräver tillämpning på policynivå: användare utan aktiv MFA-autentisering måste systematiskt nekas alla AWS API- och konsolåtgärder, förutom möjligheten att själva registrera sin egen MFA-enhet.
{
"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"
}
}
}
]
}
Statement 4 utvärderar den globala villkorsnyckeln "aws:MultiFactorAuthPresent": "false" med en explicit Deny. Eftersom en explicit Deny åsidosätter alla Allow-satser, blockeras icke-MFA-sessioner omedelbart i alla AWS-API:er, vilket slussar användaren direkt till självregistreringsskärmen.
AWS CLI- och SDK-autentisering med MFA: Tillfälliga STS-sessionstokens
När IAM-policyer tillämpar MFA kommer utvecklare som kör kommandon som aws s3 ls eller kör Terraform-kod att få AccessDenied-fel. Långlivade åtkomstnycklar kan inte interaktivt fråga efter engångskoder.
Ingenjörer måste använda AWS STS (Security Token Service) för att byta långlivade nycklar + en 6-siffrig TOTP mot tillfälliga inloggningsuppgifter:
Automatiseringsskript (aws-mfa-session.sh):
Placera detta hjälpskript i din lokala miljö (~/.aws/aws-mfa-session.sh) för att automatisera inhämtningen av tokens:
# Exchange AWS Long-Term Keys + MFA Code for STS Session Token
MFA_ARN="arn:aws:iam::123456789012:mfa/alex-dev"
echo -n "Enter 6-digit 2FA OTP Code: "
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 "✅ Authenticated! Temporary session exported (Valid for 12 hours)."
echo "❌ Authentication failed. Check token code or device time drift."
fi
Cross-Account AssumeRole med MFA-villkor
I företagsarkitekturer med flera konton autentiserar privilegierade ingenjörer vanligtvis mot ett centraliserat identitetskonto (Identity account) och byter till målkonton (Production, Staging) via sts:AssumeRole. För att säkerställa att förhöjda produktionsbehörigheter inte kan kapas via läckta uppgifter måste produktionsrollens förtroenderelation (trust policy) kräva ett MFA-villkor:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
Detta arkitektoniska mönster säkerställer att även om en angripare komprometterar inloggningsuppgifter i det centrala identitetskontot, utlöser varje försök att anta målrollen utan godkänd MFA ett omedelbart AccessDenied-fel vid säkerhetstokengränsen.
CloudTrail-granskning och EventBridge-aviseringar i realtid
Automatiserad validering av efterlevnad kräver omedelbar upptäckt när en användare loggar in i AWS Management Console utan flerfaktorsautentisering. Genom att samla in AWS CloudTrail-händelser och dirigera dem via Amazon EventBridge uppnår SecOps-team aviseringar i realtid:
{
"source": ["aws.signin"],
"detail-type": ["AWS Console Sign In via CloudTrail"],
"detail": {
"eventName": ["ConsoleLogin"],
"additionalEventData": {
"MFAUsed": ["No"]
}
}
}
När händelsen tas emot utlöser EventBridge en Amazon SNS-avisering till jourhavande person i Security Operations Center (SOC) eller anropar en AWS Lambda-funktion som omedelbart återkallar den aktiva IAM-användarsessionen.
Styrning av flera konton: AWS Organizations och IAM Identity Center
I företagsmiljöer som hanterar dussintals eller hundratals AWS-konton över Landing Zones är tilldelning av individuella IAM-användare i varje konto ett antimönster.
Centraliserad identitetsfederation:
Distribuera AWS IAM Identity Center (tidigare AWS SSO) i ditt utsedda hanteringskonto (Management Account). Federera identiteter mot företagets IdP:er (Okta, Microsoft Entra ID, PingFederate). Tillämpa företagets MFA på IdP-nivån, samtidigt som Service Control Policies (SCP) kopplas till organisationens rot för att neka åtgärder från medlemsrotkonton:
"Condition": { "StringLike": { "aws:PrincipalArn": ["arn:aws:iam::*:root"] } }
Produktionsklar SCP: Tillämpa MFA-begränsningar över alla medlemskonton
I stora organisationer kan enskilda kontoadministratörer oavsiktligt bevilja alltför omfattande behörigheter. Genom att koppla en Service Control Policy (SCP) på organisationsrotens eller organisationsenhetens (OU) nivå upprättar molnstyrningsteamet ett oföränderligt skyddsräcke: destruktiva och kritiska API-anrop nekas villkorslöst om de inte godkänts av 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"
}
}
}
]
}
Rollkedjning och begränsningar för STS-tokens livslängd:
När IAM-identiteter antar mellanliggande roller som i sin tur antar sekundära roller ("rollkedjning" eller role chaining), tar AWS STS bort det ursprungliga aws:MultiFactorAuthPresent-sammanhanget från den nedströms sessionstokenen! För att upprätthålla strikt efterlevnad från ände till ände i pipelines mellan konton bör rollantagandegrafen utformas direkt från den autentiserade IAM Identity Center-sessionen snarare än genom kedjekoppling av flera mellanliggande IAM-roller.
Katastrofåterställning: Protokoll för förlorad rot-MFA
Vad händer om alla registrerade hårdvarutokens och virtuella enheter för rot-MFA förstörs i en katastrof?
Officiell återställningssekvens (Out-of-Band):
- Initiera rotinloggning: Ange rotkontots e-postadress och huvudlösenord i AWS-konsolen.
- Felsök MFA: Klicka på "Troubleshoot MFA" vid MFA-inloggningsrutan.
- Verifiering av primär e-post: AWS skickar en tidsbegränsad verifieringslänk till den primära rot-e-postadressen. Validera länken i e-postmeddelandet.
- Automatiserat röstsamtal: Klicka på "Call me now". AWS automatiserade verifieringssystem ringer det registrerade primära telefonnumret och läser upp en 6-siffrig bekräftelsekod.
Om din organisation bytt telefonnummer eller om kontaktpersonen slutat utan att uppdatera AWS-kontoinställningarna misslyckas den automatiserade återställningen. Manuell lösning kräver att notariserade företagsregistreringsbevis skickas till AWS Trust & Safety, med en handläggningstid på 3–7 arbetsdagar.
FAQ för molnarkitekter
Kan AWS-rot-MFA-tokens delas inom ett DevOps-team? ▼
Strängt förbjudet. Att dela inloggningsuppgifter och MFA för rot strider mot alla efterlevnadsgranskningar (SOC 2, ISO 27001). Rutinmässig administration måste ske via IAM Identity Center-roller med individuellt ansvar. Rotuppgifterna måste förbli inlåsta i fysiska kassaskåp med dubbel vårdnad för katastrofala nödåtkomster (break-glass) enbart.
Hur förbättrar villkorsnyckeln aws:MultiFactorAuthAge säkerheten? ▼
Denna nyckel säkerställer sessionens aktualitet. Genom att konfigurera "NumericLessThan": {"aws:MultiFactorAuthAge": "3600"} krävs att MFA-tokenen presenterades inom de senaste 3 600 sekunderna (1 timme). Högriskåtgärder (t.ex. att radera RDS-kluster) blockeras om sessionen är äldre, vilket skyddar mot kapning av långlivade sessioner.
Kan jag använda 2FA-Tools online-autentiserare för att provisionera AWS virtuell MFA? ▼
Ja. AWS virtuell MFA följer RFC 6238 TOTP-specifikationerna strikt (HMAC-SHA1, 30-sekundersintervall, 6 siffror). Du kan ange den hemliga Base32-strängen på 2FA-Tool.com för att generera de två på varandra följande autentiseringskoder som krävs för registreringen, 100 % lokalt i din webbläsare.
Testa företagstokens för TOTP på ett säkert sätt
Generera vanliga RFC 6238 TOTP-verifieringskoder omedelbart med W3C Web Crypto API. Inga serveranrop, fullständig minnesisolering, noll läckage.