Onder het AWS Shared Responsibility Model beheert AWS de "Beveiliging VAN de Cloud" (fysieke datacenters, host-hardware, hypervisors), maar behoudt de klant de volledige verantwoordelijkheid voor "Beveiliging IN de Cloud" — met name identiteitsbeheer, hygiëne van inloggegevens en toegangscontrole. Het compromitteren van een onbeveiligd AWS Root-account of een bevoorrechte IAM-identiteit stelt aanvallers in staat om voor tienduizenden euro's aan illegale GPU-mining-instances op te starten, gevoelige S3-datalakes te exfilteren of verwoestende ransomware-verwijderingen uit te voeren.
MFA is verplicht voor alle consolegebruikers met beheerdersrechten en ononderhandelbaar voor het AWS Root-account.
AWS staat het registreren van maximaal 8 afzonderlijke FIDO2- en virtuele TOTP-tokens per account toe, waardoor single points of failure worden voorkomen.
Een globaal voorwaardelijk Deny-beleid in IAM blokkeert alle ongeautoriseerde API-aanroepen totdat een actieve MFA-validatie is voltooid.
Baselines voor cloudnaleving: CIS Benchmark & regelgevende kaders
Of uw organisatie nu streeft naar SOC 2 Type II-certificering, ISO 27001-conformiteit, PCI DSS 4.0-validatie of afstemming met de Security Pillar van het AWS Well-Architected Framework: de implementatie van MFA voor alle IAM-identiteiten is een fundamentele voorwaarde:
| Standaard / Nalevingskader | Specificatie van controle | Urgentie / Verplichting | Mechanisme voor auditvalidatie |
|---|---|---|---|
| CIS AWS Foundations Benchmark v3.0 | 1.5 / 1.6 / 1.10 | Niveau 1 (Verplicht) | Geautomatiseerde evaluatie via AWS Security Hub / Prowler |
| PCI DSS 4.0 | Vereiste 8.4.2 | Verplicht | Audit van Cardholder Data Environment (CDE) console & API |
| SOC 2 Type II (Trust Criteria) | CC6.1 / CC6.2 | Kerncontrole | Onafhankelijke accountantscontrole van IAM-inloggegevensrapporten |
| Verplichte AWS MFA-uitrol | AWS 2024–2026 Beleid | Platformafdwinging | Root-inlogpoort geblokkeerd tot registratie van MFA is voltooid |
De absolute noodzaak van het beveiligen van het AWS Root-account
Binnen de grenzen van een AWS-account vertegenwoordigt het Root-account de almachtige identiteit die bij creatie ontstaat. In tegenstelling tot IAM-rollen of -gebruikers kunnen de acties van het Root-account niet worden beperkt door op identiteit gebaseerde IAM-policies of Service Control Policies binnen zelfstandige accounts.
Catastrofale impact van een gecompromitteerd Root-account:
- Onomkeerbare accountsluiting: Kwaadwillenden kunnen op 'Close Account' klikken, waardoor de infrastructuur definitief wordt vernietigd.
- Financiële kaping & facturatie: Facturen omleiden, creditcards vervangen en honderden GPU-spot-instances uitrollen in meer dan 30 AWS-regio's voor het delven van cryptovaluta.
- Loskoppelen van AWS Organizations: Lidaccounts loskoppelen van de organisatiestructuur, waardoor nalevingsmonitoring wegvalt.
- Wijzigen van primaire contactgegevens: Het aanpassen van het e-mailadres en telefoonnummer van het Root-account verbreekt permanente interventiekanalen van AWS Support.
- Geen Root-toegangssleutels (Access Keys): Controleer IAM Credential Reports om te bevestigen dat er geen toegangssleutels bestaan voor het Root-account. Verwijder ze onmiddellijk indien aanwezig.
- Wachtwoordkluis met dubbel toezicht (Dual-Custody): Genereer een willekeurig wachtwoord van 32+ tekens, splits de wachtwoordzin op tussen de CISO en de juridisch adviseur, en bewaar de delen in fysieke brandwerende kluizen.
- Redundantie met meerdere apparaten (tot 8 apparaten): Registreer ten minste twee fysieke FIDO2-hardwaresleutels (YubiKeys) plus een offline, veilig opgeslagen virtueel TOTP-reserveapparaat.
Keuzematrix voor MFA: Virtuele TOTP vs. hardwarematige FIDO2 (YubiKey)
AWS ondersteunt drie primaire categorieën van MFA-apparaten. Cloudarchitecten moeten de keuze afstemmen op dreigingsmodellen en beheerniveaus:
Virtuele TOTP-applicaties
Standaard RFC 6238-tokens (Google Authenticator, 1Password, 2FA-Tool). Snelle ingebruikname, geen aanschafkosten. Ideaal voor reguliere ontwikkelaars.
YubiKey 5-serie
Phishing-resistente cryptografie. Aan de herkomst gekoppelde verificaties blokkeren reverse-proxy phishingkits. Verplicht voor Root en beheerders.
Gemalto / Thales-kaarten
Zelfvoorzienende TOTP-kaart met lcd-scherm. Essentieel voor beveiligde en geïsoleerde faciliteiten (SCIFs) waar smartphones en USB-sticks verboden zijn.
Hardwarematige MFA met FIPS 140-2 Level 3 & protocollen voor dubbel toezicht:
Voor beursgenoteerde ondernemingen en defensiecontractanten vereist de beveiliging van het Root-account toegewijde hardwaretokens (zoals SafeNet/Gemalto IDPrime fobs) die gecertificeerd zijn onder FIPS 140-2 Level 3. In tegenstelling tot smartphone-apps hebben deze fysieke tokens geen draadloze interfaces of bluetooth, waardoor ze immuun zijn voor mobiele spyware.
Fysiek beleid met dubbel toezicht: In enterprise datacenters vereist Root-toegang twee verschillende personen: één beheerder heeft het e-mailadres en hoofdwachtwoord, terwijl een onafhankelijke security officer de fysieke sleutel bezit van de kluis waarin het Root-hardwaretoken ligt. Geen van beiden kan eenzijdig toegang krijgen tot het AWS Root-account.
MFA afdwingen via IAM-beleid (JSON-implementatie)
Nalevingsnormen kunnen niet afhankelijk zijn van vrijwillige acties van medewerkers. Cloudbeheer vereist afdwinging op beleidsniveau: gebruikers zonder actieve MFA-authenticatie moeten systematisch worden geblokkeerd voor alle AWS API- en consoleacties, behalve de mogelijkheid om hun eigen MFA-apparaat te registreren.
{
"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 evalueert de globale voorwaardesleutel "aws:MultiFactorAuthPresent": "false" met een expliciete Deny. Omdat een expliciete Deny voorrang heeft op alle Allow-statements, worden niet-MFA-sessies direct geblokkeerd voor alle AWS-API's, waardoor de gebruiker rechtstreeks naar het registratiescherm wordt geleid.
AWS CLI & SDK MFA-authenticatie: STS tijdelijke sessietokens
Wanneer IAM-policies MFA afdwingen, krijgen ontwikkelaars die opdrachten zoals aws s3 ls uitvoeren of Terraform-scripts draaien de foutmelding AccessDenied. Permanente toegangssleutels (access keys) kunnen niet interactief om OTP's vragen.
Engineers moeten AWS STS (Security Token Service) gebruiken om permanente sleutels + een 6-cijferige TOTP-code in te wisselen voor tijdelijke inloggegevens:
Automatiseringsscript (aws-mfa-session.sh):
Plaats dit hulpscript in uw lokale omgeving (~/.aws/aws-mfa-session.sh) om het ophalen van tokens te automatiseren:
# AWS permanente sleutels + MFA-code inwisselen voor STS-sessietoken
MFA_ARN="arn:aws:iam::123456789012:mfa/alex-dev"
echo -n "Voer de 6-cijferige 2FA OTP-code in: "
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 "✅ Geauthenticeerd! Tijdelijke sessie geëxporteerd (12 uur geldig)."
else
echo "❌ Authenticatie mislukt. Controleer de tokencode of tijdsafwijking van het apparaat."
fi
Cross-account AssumeRole met MFA-beperkingen
In zakelijke multi-accountomgevingen authenticeren bevoorrechte engineers doorgaans bij een centraal Identity-account en schakelen ze over naar doelaccounts (Production, Staging) via sts:AssumeRole. Om te voorkomen dat verhoogde productierechten worden misbruikt via gelekte inloggegevens, moet het vertrouwensbeleid (Trust Policy) van de productierol een MFA-voorwaarde afdwingen:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
Dit architectuurpatroon zorgt ervoor dat zelfs als een aanvaller inloggegevens in het centrale Identity-account bemachtigt, pogingen om de doelrol aan te nemen zonder MFA direct leiden tot een AccessDenied-fout bij de STS-boundary.
CloudTrail-audits & realtime EventBridge-meldingen
Geautomatiseerde nalevingscontrole vereist directe detectie wanneer een gebruiker de AWS Management Console opent zonder multifactorauthenticatie. Door AWS CloudTrail-gebeurtenissen op te vangen en via Amazon EventBridge te routeren, ontvangen SecOps-teams realtime waarschuwingen:
{
"source": ["aws.signin"],
"detail-type": ["AWS Console Sign In via CloudTrail"],
"detail": {
"eventName": ["ConsoleLogin"],
"additionalEventData": {
"MFAUsed": ["No"]
}
}
}
Bij ontvangst van de gebeurtenis activeert EventBridge een Amazon SNS-melding naar de dienstdoende SOC-engineer of start een AWS Lambda-functie die de actieve IAM-sessie onmiddellijk intrekt.
Beheer van meerdere accounts: AWS Organizations & IAM Identity Center
In bedrijfsomgevingen met tientallen of honderden AWS-accounts binnen Landing Zones is het individueel aanmaken van IAM-gebruikers in elk afzonderlijk account een anti-pattern.
Gecentraliseerde identiteitsfederatie:
Implementeer AWS IAM Identity Center (voorheen AWS SSO) in uw centrale beheeraccount (Management Account). Koppel identiteiten aan zakelijke identity providers (zoals Okta, Microsoft Entra ID of PingFederate). Dwing zakelijke MFA af op het IdP-niveau en voeg Service Control Policies (SCP's) toe aan de root van de organisatie om root-acties in lidaccounts te weigeren:
"Condition": { "StringLike": { "aws:PrincipalArn": ["arn:aws:iam::*:root"] } }
Productie-klare SCP: MFA-beperkingen afdwingen voor alle lidaccounts
In grote organisaties kunnen beheerders van individuele accounts per ongeluk buitensporige rechten toekennen. Door een Service Control Policy (SCP) toe te passen op het niveau van de Organization Root of Organizational Unit (OU), creëert het cloud governance-team een onwrikbare vangrail: destructieve API-aanroepen worden onvoorwaardelijk geweigerd tenzij ze worden geautoriseerd via een actieve MFA-sessie:
{
"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"
}
}
}
]
}
Rolketens (Role Chaining) & beperkingen van de STS-levensduur:
Wanneer IAM-identiteiten tussenrollen aannemen die vervolgens secundaire rollen aannemen ('role chaining'), verwijdert AWS STS de oorspronkelijke aws:MultiFactorAuthPresent-context uit het downstream-sessietoken! Om strikte end-to-end naleving te behouden, kunt u het beste roltoewijzingen rechtstreeks vanuit de geauthenticeerde IAM Identity Center-sessie ontwerpen in plaats van meerdere tussenrollen te koppelen.
Noodherstel: protocol bij verlies van het Root-MFA-apparaat
Wat gebeurt er als alle geregistreerde Root-MFA-hardwaretokens en virtuele apparaten bij een calamiteit verloren gaan?
Officieel out-of-band herstelprotocol:
- Root-aanmelding starten: Voer het e-mailadres en het hoofdwachtwoord van het Root-account in op de AWS Console.
- MFA-problemen oplossen: Klik in het MFA-inlogvenster op "Troubleshoot MFA" (MFA-problemen oplossen).
- Verificatie via primair e-mailadres: AWS verstuurt een tijdelijke verificatielink naar het primaire Root-e-mailadres. Bevestig de verificatie via de e-mail.
- Geautomatiseerde telefonische controle: Klik op "Call me now". Het geautomatiseerde verificatiesysteem van AWS belt het geregistreerde primaire telefoonnummer en leest een 6-cijferige verificatiepincode voor.
Als uw organisatie van telefoonnummer is gewisseld of de contactpersoon is vertrokken zonder de AWS-accountinstellingen bij te werken, mislukt het automatische herstel. Handmatig herstel vereist het indienen van notariële bedrijfsdocumenten bij AWS Trust & Safety, wat 3 tot 7 werkdagen kan duren.
Veelgestelde vragen voor cloud-architecten (FAQ)
Mogen AWS Root-MFA-tokens worden gedeeld binnen een DevOps-team? ▼
Strikt verboden. Het delen van Root-MFA-inloggegevens leidt tot falen bij nalevingsaudits zoals SOC 2 en ISO 27001. Regulier beheer moet verlopen via IAM Identity Center-rollen met individuele verantwoordelijkheid. Root-inloggegevens moeten vergrendeld blijven in fysieke kluizen met dubbel toezicht voor noodsituaties.
Hoe verhoogt de voorwaardesleutel aws:MultiFactorAuthAge de veiligheid? ▼
Deze sleutel dwingt de recentheid van een sessie af. Het instellen van "NumericLessThan": {"aws:MultiFactorAuthAge": "3600"} vereist dat het MFA-token binnen de afgelopen 3.600 seconden (1 uur) is ingevoerd. Risicovolle acties (zoals het verwijderen van RDS-clusters) worden geblokkeerd als de sessie ouder is, wat beschermt tegen sessiekaping.
Kan ik de online authenticator van 2FA-Tool gebruiken om AWS Virtual MFA in te stellen? ▼
Ja. AWS Virtual MFA voldoet strikt aan de RFC 6238 TOTP-specificaties (HMAC-SHA1, interval van 30 seconden, 6 cijfers). U kunt de Base32-geheime sleutel invoeren op 2FA-Tool.com om de twee opeenvolgende authenticatiecodes te genereren die vereist zijn voor registratie, 100% lokaal in uw browser.
Test enterprise TOTP-tokens veilig
Genereer standaard RFC 6238 TOTP-verificatiecodes direct met de W3C Web Crypto API. Geen serveraanroepen, absolute gegevensisolatie in het geheugen, nul risico op gegevenslekken.