Under AWS Shared Responsibility Model (modellen for delt ansvar) administrerer AWS "Security OF the Cloud" (fysiske datasentre, vertshardware, hypervisorer), mens kunden har det fulle ansvaret for "Security IN the Cloud"—spesifikt identitetsstyring, sikker legitimasjonshygiene og tilgangskontroll. Kompromittering av en ubegrenset AWS Root-konto eller en privilegert IAM-legitimasjon gjør det mulig for trusselaktører å opprette GPU-instanser for ulovlig kryptoutvinning for tusenvis av dollar, hente ut sensitive S3-datasjøer eller utføre katastrofal utpressing og sletting.
MFA er obligatorisk for alle administrative konsollbrukere og ufravikelig for AWS Root-kontoen.
AWS tillater registrering av opptil 8 separate FIDO2- og virtuelle TOTP-tokener per konto, noe som eliminerer enkeltpunkter for feil (Single Point of Failure).
Global IAM-policy med betinget avvisning (Deny) blokkerer alle uautoriserte API-kall inntil aktiv MFA-validering er fullført.
Samsvarsgrunnlinjer for skyen: CIS Benchmark og regulatoriske rammeverk
Enten ingeniørorganisasjonen din sikter mot SOC 2 Type II-attestering, ISO 27001-sertifisering, PCI DSS 4.0-validering eller samsvar med AWS Well-Architected Security Pillar, er MFA-implementering på tvers av IAM-identiteter et ufravikelig grunnkrav:
| Standard / Samsvarsrammeverk | Kontrollspesifikasjon | Alvorlighetsgrad / Påbud | Revisjons- og valideringsmekanisme |
|---|---|---|---|
| CIS AWS Foundations Benchmark v3.0 | 1.5 / 1.6 / 1.10 | Nivå 1 (Obligatorisk) | AWS Security Hub / Prowler automatisert vurdering |
| PCI DSS 4.0 | Krav 8.4.2 | Obligatorisk | Kortholderdatamiljø (CDE) konsoll- og API-revisjon |
| SOC 2 Type II (Tillitskriterier) | CC6.1 / CC6.2 | Nøkkelkontroll | Uavhengig revisorinspeksjon av IAM Credential Reports |
| AWS obligatorisk MFA-utrulling | AWS 2024–2026-policy | Plattformhåndheving | Blokkering av Root-pålogging inntil MFA-registrering er fullført |
Den absolutte nødvendigheten av å sikre AWS Root-kontoen
Innenfor et AWS-kontoområde representerer Root-kontoen den allmektige identiteten som opprettes ved kontoens etablering. I motsetning til IAM-roller eller brukere, kan ikke handlingene til Root-kontoen begrenses av IAM-identitetsbaserte policyer eller Service Control Policies i frittstående kontoer.
Katastrofale konsekvenser ved kompromittert Root-konto:
- Uopprettelig kontonedleggelse (Irreversible Account Closure): Angripere kan klikke på "Close Account", noe som iverksetter permanent destruksjon av all infrastruktur.
- Fakturerings- og finansiell kapring (Billing & Financial Hijacking): Omdirigering av fakturaer, utskifting av bedriftsbetalingskort og oppstart av hundrevis av GPU-spotinstanser på tvers av over 30 AWS-regioner for ulovlig kryptoutvinning.
- Oppløsning av AWS Organizations-strukturen: Fjerning av medlemskontoer fra organisasjonstrær, noe som lammer organisasjonens samsvarsovervåking.
- Endring av primære sikkerhetskontakter: Endring av e-post- og telefonnumre for Root kutter offisielle eskaleringskanaler til AWS-kundestøtte permanent.
- Null Root-tilgangsnøkler (Zero Root Access Keys): Gjennomfør revisjon av IAM Credential Reports for å bekrefte at tilgangsnøkler (Access Keys) for Root-kontoen ikke eksisterer. Slett dem umiddelbart hvis de finnes.
- Passordhvelv med delt forvaltning (Dual-Custody): Generer et tilfeldig passord på 32+ tegn, del passordet mellom CISO og juridisk direktør, og lås delene inn i separate, brannsikre safer.
- Flerenhetsredundans (opptil 8 enheter): Registrer minst to fysiske FIDO2-maskinvarenøkler (YubiKeys) pluss en offline, sikkerhetskopiert virtuell TOTP-fallbackenhet.
MFA-valgmatrise: Virtuell TOTP vs. maskinvarebasert FIDO2 (YubiKey)
AWS støtter tre primære MFA-enhetsklasser. Skyarkitekter bør tilpasse valget etter trusselmodeller og administrative privilegienivåer:
Virtuelle TOTP-apper
Standard RFC 6238-tokener (Google Authenticator, 1Password, 2FA-Tool). Rask onboarding, ingen innkjøpskostnader. Ideelt for vanlige utviklere.
YubiKey 5-serien
Phishing-resistent kryptografi. Opprinnelsesbundne offentlige nøkkelsignaturer nøytraliserer reverse-proxy-phishing. Obligatorisk for Root og administratorer.
Gemalto / Thales-kort
Selvdrevet, luftgapet (air-gapped) TOTP-kort med LCD-skjerm. Nødvendig for høysikkerhetsfasiliteter (SCIFs) der smarttelefoner og USB-enheter er forbudt.
Maskinvare-MFA på bedriftsnivå, FIPS 140-2 nivå 3 og protokoller for delt forvaltning:
For Fortune 500-selskaper og forsvarsleverandører krever Root-kontosikkerhet dedikerte maskinvarebrikker (f.eks. SafeNet/Gemalto IDPrime fobs) sertifisert under FIPS 140-2 nivå 3. I motsetning til mobilapper har disse fysiske enhetene ingen trådløse grensesnitt eller Bluetooth-radioer, og kan ikke overvåkes eller manipuleres via spionprogramvare på mobiler.
Fysisk delt forvaltning (Dual-Custody Governance): I bedriftsdatasentre krever tilgang til Root to distinkte personer: én forvalter har hovedinnloggingsdataene for e-post, mens en uavhengig sikkerhetsansvarlig har den fysiske nøkkelen til en sikker safe som inneholder Root-maskinvaretokenet. Ingen av partene kan få tilgang til AWS Root-kontoen på egen hånd.
Håndheving av MFA via IAM-policyer (JSON-implementering)
Sikkerhetsgrunnlinjer kan ikke stole på frivillige tiltak fra ansatte. Styring i skyen krever håndheving på policynivå: brukere uten aktiv MFA-autentisering må systematisk nektes alle AWS API- og konsollhandlinger, med unntak av muligheten til selv å registrere 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"
}
}
}
]
}
Setning 4 evaluerer den globale betingelsesnøkkelen "aws:MultiFactorAuthPresent": "false" ved hjelp av en eksplisitt Deny. Fordi en eksplisitt Deny alltid overstyrer alle Allow-setninger, blir sesjoner uten MFA umiddelbart blokkert på tvers av alle AWS API-er, og leder brukeren rett til skjermen for registrering av egen MFA.
AWS CLI og SDK MFA-autentisering: Midlertidige STS-sesjonstokener
Når IAM-policyer krever MFA, vil utviklere som kjører kommandoer som aws s3 ls eller kjører Terraform-kode, motta feilmeldingen AccessDenied. Langvarige tilgangsnøkler kan ikke be om engangskoder interaktivt.
Ingeniører må bruke AWS STS (Security Token Service) for å bytte langvarige nøkler + en 6-sifret TOTP mot midlertidige sesjonsdata:
Automatiseringsskript (aws-mfa-session.sh):
Plasser dette hjelpeskriptet i det lokale miljøet ditt (~/.aws/aws-mfa-session.sh) for å automatisere henting av sesjonstokener:
# 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)."
else
echo "❌ Authentication failed. Check token code or device time drift."
fi
AssumeRole på tvers av kontoer med MFA-betingelser
I fler-kontos arkitekturer i bedrifter autentiserer privilegerte ingeniører seg vanligvis mot en sentralisert Identity-konto og bytter til målkontoer (Production, Staging) via sts:AssumeRole. For å sikre at opphøyde produksjonstillatelser ikke kan kapres via lekkede legitimasjoner, må målkontoens tillitsforhold håndheve en MFA-betingelse:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
Dette arkitekturmønsteret sikrer at selv om en angriper kompromitterer legitimasjon i den sentrale Identity-kontoen, vil forsøk på å overta målrollen uten å tilfredsstille MFA utløse en umiddelbar AccessDenied-feil ved sikkerhetstokengrensen.
CloudTrail-revisjon og EventBridge-varsler i sanntid
Automatisert samsvarsvalidering krever umiddelbar oppdagelse når en bruker logger seg inn på AWS Management Console uten tofaktorautentisering. Ved å fange opp hendelser fra AWS CloudTrail og rute dem via Amazon EventBridge, oppnår SecOps-team varsling i sanntid:
{
"source": ["aws.signin"],
"detail-type": ["AWS Console Sign In via CloudTrail"],
"detail": {
"eventName": ["ConsoleLogin"],
"additionalEventData": {
"MFAUsed": ["No"]
}
}
}
Når hendelsen mottas, utløser EventBridge et Amazon SNS-varsel til vakthavende i Security Operations Center (SOC) eller kaller en AWS Lambda-funksjon som umiddelbart avslutter den aktive IAM-brukersesjonen.
Fler-kontostyring: AWS Organizations og IAM Identity Center
I bedriftsmiljøer som administrerer titalls eller hundrevis av AWS-kontoer på tvers av Landing Zones, er opprettelse av individuelle IAM-brukere i hver konto et anti-mønster (anti-pattern).
Sentralisert identitetsføderering:
Distribuer AWS IAM Identity Center (tidligere AWS SSO) i den utpekte administrasjonskontoen (Management Account). Føderer identiteter mot bedriftens IdP-er (Okta, Microsoft Entra ID, PingFederate). Håndhev bedrifts-MFA på IdP-nivå, og koble Service Control Policies (SCP-er) til organisasjonens rot for å nekte Root-handlinger i medlemskontoer:
"Condition": { "StringLike": { "aws:PrincipalArn": ["arn:aws:iam::*:root"] } }
Produksjonsklar SCP: Håndheving av MFA-krav på tvers av alle medlemskontoer
I store organisasjoner kan individuelle kontoadministratorer utilsiktet tildele overflødige privilegier. Ved å tilknytte en Service Control Policy (SCP) på Organization Root- eller Organizational Unit (OU)-nivå etablerer sky-styringsteamet et urokkelig vern: kritiske API-kall nektes ubetinget med mindre de godkjennes av en aktiv MFA-sesjon:
{
"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"
}
}
}
]
}
Rollelenking (Role Chaining) og levetidsbegrensninger for STS-tokener:
Når IAM-identiteter påtar seg mellomliggende roller som deretter overtar sekundære roller ("role chaining"), fjerner AWS STS den opprinnelige aws:MultiFactorAuthPresent-konteksten fra det etterfølgende sesjonstokenet! For å opprettholde streng samsvarskontroll på tvers av kontoer bør rolletildelinger arkitekteres direkte fra den autentiserte IAM Identity Center-sesjonen, i stedet for å lenke flere mellomliggende IAM-roller sammen.
Katastrofegjenoppretting: Protokoll for tapt Root-MFA-enhet
Hva skjer dersom alle registrerte Root-MFA-maskinvarebrikker og virtuelle enheter blir ødelagt i en katastrofe?
Offisiell prosedyre for out-of-band-gjenoppretting:
- Start Root-innlogging: Skriv inn e-postadressen og hovedpassordet for Root-kontoen på AWS-konsollen.
- Feilsøk MFA: Klikk på "Troubleshoot MFA" (Feilsøk MFA) i MFA-forespørselen.
- Primær e-postbekreftelse: AWS sender en tidsbegrenset bekreftelseslenke til den primære Root-e-postadressen. Bekreft utfordringen via e-post.
- Automatisert taleutfordring: Klikk på "Call me now". Det automatiserte AWS-verifiseringssystemet ringer det registrerte telefonnummeret til primærkontoen og leser opp en 6-sifret bekreftelses-PIN.
Hvis organisasjonen din har endret telefonnumre eller kontaktpersonen har sluttet uten å oppdatere AWS-kontoinnstillingene, vil den automatiserte gjenopprettingen mislykkes. Manuell løsning krever innsending av tinglyste bedriftsdokumenter til AWS Trust & Safety, og behandlingstiden tar 3–7 virkedager.
Ofte stilte spørsmål (FAQ) for skyarkitekter
Kan AWS Root-MFA-tokener deles på tvers av et DevOps-team? ▼
Strengt forbudt. Deling av Root-MFA-legitimasjon fører til stryk i alle samsvarsrevisjoner (SOC 2, ISO 27001). Rutinemessig administrasjon må foregå via IAM Identity Center-roller med individuelt ansvar. Root-legitimasjon må forbli innelåst i fysiske safer med delt forvaltning (dual-custody) kun for ekstreme nødssituasjoner (break-glass).
Hvordan forbedrer betingelsesnøkkelen aws:MultiFactorAuthAge sikkerheten? ▼
Denne nøkkelen håndhever sesjonsferskhet. Ved å konfigurere "NumericLessThan": {"aws:MultiFactorAuthAge": "3600"} kreves det at MFA-tokenet ble oppgitt i løpet av de siste 3600 sekundene (1 time). Høyrisikohandlinger (f.eks. sletting av RDS-klynger) blir blokkert dersom sesjonen er eldre, noe som beskytter mot kapring av langvarige sesjoner.
Kan jeg bruke 2FA-Tool online-autentisering til å sette opp AWS virtuell MFA? ▼
Ja. AWS virtuell MFA følger standard RFC 6238 TOTP-spesifikasjoner strengt (HMAC-SHA1, 30-sekunders intervall, 6 sifre). Du kan lime inn den hemmelige Base32-nøkkelen i 2FA-Tool.com for å generere de to påfølgende autentiseringskodene som kreves for registrering, 100 % lokalt i nettleseren din.
Test TOTP-tokener for bedriften sikkert
Generer standard RFC 6238 TOTP-verifiseringskoder umiddelbart med W3C Web Crypto API. Ingen serverkall, fullstendig isolert minne, null datalekkasje.