V rámci modelu sdílené odpovědnosti AWS spravuje poskytovatel „Bezpečnost CLOUDU“ (fyzická datacentra, hostitelský hardware, hypervizory), zatímco zákazník nese plnou a nedělitelnou odpovědnost za „Bezpečnost V CLOUDU“ – konkrétně za správu identit, hygienu přihlašovacích údajů a řízení přístupu. Kompromitace neomezeného účtu AWS Root nebo privilegovaných údajů IAM umožňuje útočníkům nasadit instance pro těžbu kryptoměn za tisíce dolarů, odcizit privátní data z S3 nebo provést katastrofické smazání infrastruktury.
MFA je povinné pro všechny uživatele konzole s administrátorskými právy a zcela bezpodmínečné pro účet AWS Root.
AWS umožňuje zaregistrovat až 8 různých FIDO2 a virtuálních TOTP tokenů na účet, což eliminuje jediný bod selhání.
Globální politika IAM s podmíněným zákazem blokuje všechna volání API, dokud neproběhne aktivní ověření přes MFA.
Standardy shody v cloudu: CIS Benchmark a regulatorní rámce
Ať už vaše organizace usiluje o atestaci SOC 2 Type II, certifikaci ISO 27001, audit PCI DSS 4.0, nebo se řídí pilířem bezpečnosti AWS Well-Architected Framework, zavedení MFA napříč všemi identitami IAM představuje základní a povinný požadavek:
| Standard / Norma shody | Specifikace kontroly | Závažnost / Mandát | Mechanismus ověření auditem |
|---|---|---|---|
| CIS AWS Foundations Benchmark v3.0 | 1.5 / 1.6 / 1.10 | Úroveň 1 (Povinné) | Automatizované hodnocení AWS Security Hub / Prowler |
| PCI DSS 4.0 | Požadavek 8.4.2 | Povinné | Audit konzole a API prostředí držitelů platebních karet (CDE) |
| SOC 2 Type II (Trust Criteria) | CC6.1 / CC6.2 | Klíčová kontrola | Nezávislá kontrola výpisů IAM Credential Reports auditorem CPA |
| Povinné zavedení MFA ze strany AWS | Politika AWS 2024–2026 | Vynucení platformou | Blokace přihlášení k účtu Root do dokončení registrace MFA |
Absolutní nutnost zabezpečení účtu AWS Root
V rámci hranic AWS účtu představuje účet Root všemocnou identitu vytvořenou při vzniku účtu. Na rozdíl od rolí nebo běžných uživatelů IAM nelze akce účtu Root omezit politikami založenými na identitě v IAM ani politikami Service Control Policies (SCP) v samostatných účtech.
Ničivý dopad kompromitovaného účtu Root:
- Nevratné uzavření účtu: Útočníci mohou kliknout na „Zavřít účet“, čímž naplánují trvalé zničení veškeré infrastruktury.
- Finanční únos a nelegální těžba: Změna fakturačních údajů, nahrazení platebních karet a okamžité spuštění stovek drahých GPU instancí napříč 30+ regiony AWS pro těžbu kryptoměn.
- Rozbití struktury AWS Organizations: Odstranění členských účtů ze stromu správy, čímž se vyřadí centrální monitoring shody.
- Změna primárních kontaktů: Přepsání e-mailu a telefonních čísel root účtu zcela odřízne oficiální zásah podpory AWS.
- Nulové přístupové klíče (Zero Access Keys): Zkontrolujte výkazy IAM Credential Reports a ujistěte se, že pro účet Root neexistují žádné přístupové klíče API. Pokud existují, okamžitě je smažte.
- Uložení hesla s duální kontrolou: Vygenerujte náhodné heslo o délce 32+ znaků, rozdělte přístupovou frázi mezi CISO a hlavního právníka a uzamkněte jednotlivé části v oddělených ohnivzdorných trezorech.
- Redundance zařízení (až 8 zařízení): Zaregistrujte alespoň dva fyzické hardwarové klíče FIDO2 (YubiKey) a jedno záložní virtuální zařízení TOTP uložené offline v trezoru.
Matice výběru MFA: Virtuální TOTP vs. hardwarový FIDO2 (YubiKey)
AWS podporuje tři primární třídy zařízení MFA. Cloudoví architekti by měli volit typ zařízení podle modelu hrozeb a úrovně administrátorských oprávnění:
Virtuální TOTP aplikace
Standardní tokeny RFC 6238 (Google Authenticator, 1Password, 2FA-Tool). Bleskové zavedení, nulové náklady na hardware. Ideální pro běžné vývojáře.
Řada YubiKey 5
Kryptografie odolná proti phishingu. Ověření vázané na doménu zamezuje útokům přes reverzní proxy. Povinné pro Root a administrátory.
Karty Gemalto / Thales
Autonomní TOTP karta s LCD displejem. Nezbytná pro zabezpečená armádní a vládní pracoviště (SCIF), kde jsou zakázány smartphony i USB disky.
Podnikové hardwarové MFA s certifikací FIPS 140-2 Level 3 a protokoly duální správy:
Pro společnosti z žebříčku Fortune 500 a vládní dodavatele vyžaduje zabezpečení účtu Root vyhrazené hardwarové tokeny (např. klíčenky SafeNet/Gemalto IDPrime) s certifikací FIPS 140-2 Level 3. Na rozdíl od chytrých telefonů nemají tyto klíčenky bezdrátová rozhraní, postrádají bluetooth a nelze je napadnout mobilním spywarem.
Fyzická duální správa (Dual-Custody Governance): V datacentrových bezpečnostních protokolech vyžaduje přístup k Root účtu přítomnost dvou nezávislých osob: jeden správce zná hlavní e-mailové přihlašovací údaje, zatímco nezávislý bezpečnostní důstojník drží fyzický klíč od bezpečnostního trezoru s hardwarovým tokenem. Ani jedna strana nemůže k účtu přistoupit jednostranně.
Vynucení MFA pomocí IAM politik (Implementace v JSON)
Bezpečnostní standardy se nemohou spoléhat na dobrovolnou iniciativu zaměstnanců. Řízení cloudu vyžaduje vynucení na úrovni politik: uživatelům bez aktivního ověření MFA musí být systematicky odepřen přístup ke všem operacím API a konzole AWS, s jedinou výjimkou – možností nastavit si vlastní MFA zařízení.
{
"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"
}
}
}
]
}
Čtvrté pravidlo (Statement 4) vyhodnocuje globální podmínkový klíč "aws:MultiFactorAuthPresent": "false" s explicitním účinkem Deny. Protože explicitní Deny má v logice AWS přednost před všemi Allow pravidly, relace bez aktivního MFA jsou okamžitě zablokovány u všech API kromě registrace vlastního zařízení.
AWS CLI a dočasné tokeny relací STS
Když politiky IAM vynucují MFA, vývojáři spouštějící příkazy jako aws s3 ls nebo spouštějící Terraform obdrží chybu AccessDenied. Dlouhodobé přístupové klíče totiž nedokážou interaktivně vyžádat jednorázový kód.
Inženýři proto musí použít AWS STS (Security Token Service) k výměně dlouhodobých klíčů a 6místného kódu TOTP za dočasné přihlašovací údaje:
Automatizační skript (aws-mfa-session.sh):
Uložte si tento pomocný skript do svého lokálního prostředí (~/.aws/aws-mfa-session.sh) pro snadné získávání dočasných tokenů:
# Výměna dlouhodobých klíčů AWS a MFA kódu za dočasný STS token
MFA_ARN="arn:aws:iam::123456789012:mfa/alex-dev"
echo -n "Zadejte 6místný 2FA OTP kód: "
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 "✅ Úspěšně ověřeno! Dočasná relace byla exportována (platnost 12 hodin)."
else
echo "❌ Autentizace selhala. Zkontrolujte kód nebo posun systémového času zařízení."
fi
Přebírání rolí mezi účty (AssumeRole) s podmínkou MFA
V podnikových architekturách s více účty se oprávnění inženýři obvykle autentizují v centrálním účtu identit a následně přebírají role v cílových účtech (Production, Staging) pomocí sts:AssumeRole. Aby se zamezilo zneužití uniklých přihlašovacích údajů, musí vztah důvěry (trust relationship) cílové role vyžadovat aktivní ověření MFA:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
Tento architektonický vzor zaručuje, že i kdyby útočník získal přístupové údaje v centrálním účtu identit, pokus o převzetí produkční role bez splnění požadavku MFA skončí okamžitou chybou AccessDenied přímo na hranici bezpečnostního tokenu.
Auditování CloudTrail a výstrahy v EventBridge v reálném čase
Automatizovaná kontrola souladu vyžaduje okamžitou detekci v situaci, kdy kterýkoli uživatel přistoupí do konzole AWS Management Console bez vícefaktorového ověření. Zachycením událostí AWS CloudTrail a jejich směrováním přes Amazon EventBridge získávají týmy SecOps výstrahy v reálném čase:
{
"source": ["aws.signin"],
"detail-type": ["AWS Console Sign In via CloudTrail"],
"detail": {
"eventName": ["ConsoleLogin"],
"additionalEventData": {
"MFAUsed": ["No"]
}
}
}
Po doručení události může EventBridge aktivovat upozornění přes Amazon SNS na pohotovostní službu bezpečnostního dohledového centra (SOC) nebo spustit funkci AWS Lambda, která okamžitě ukončí aktivní relaci uživatele IAM.
Správa více účtů: AWS Organizations a IAM Identity Center
V podnikových prostředích spravujících desítky nebo stovky účtů AWS v rámci Landing Zones je zakládání individuálních uživatelů IAM v každém účtu nevhodným antipatternem.
Centralizovaná federace identit:
Nasaďte AWS IAM Identity Center (dříve AWS SSO) ve vašem centrálním správcovském účtu (Management Account). Propojte identity s podnikovým IdP (Okta, Microsoft Entra ID, PingFederate). Vynuťte podnikové MFA na úrovni IdP a připojte Service Control Policies (SCP) v kořenu organizace, které zakazují akce uživatele root v členských účtech:
"Condition": { "StringLike": { "aws:PrincipalArn": ["arn:aws:iam::*:root"] } }
Produkční SCP: Vynucení MFA napříč všemi členskými účty
Ve velkých organizacích mohou správci jednotlivých účtů nedopatřením udělit příliš široká oprávnění. Připojením Service Control Policy (SCP) v kořenu organizace nebo organizační jednotky (OU) stanoví bezpečnostní tým neprolomitelnou bariéru: kritické operace API jsou bezpodmínečně zakázány bez aktivní relace s MFA:
{
"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"
}
}
}
]
}
Řetězení rolí (Role Chaining) a ztráta kontextu STS:
Když IAM identity přebírají zprostředkující role, které následně přebírají další role („role chaining“), služba AWS STS odstraní původní kontext aws:MultiFactorAuthPresent z následného tokenu relace! Pro zachování striktní shody proto navrhujte přebírání rolí přímo z relace IAM Identity Center, nikoli zřetězením několika zprostředkujících rolí IAM za sebou.
Obnova po havárii: Protokol při ztrátě zařízení Root MFA
Co nastane v případě, že jsou všechny registrované hardwarové i virtuální tokeny účtu Root zničeny při nehodě či havárii?
Oficiální mimopásmový postup obnovy (Out-of-Band Recovery):
- Zahájení přihlášení jako Root: Zadejte e-mail účtu Root a hlavní heslo v konzoli AWS.
- Řešení potíží s MFA: Při výzvě k zadání kódu klikněte na odkaz „Troubleshoot MFA“ (Řešení potíží s MFA).
- Ověření primárního e-mailu: AWS zašle časově omezený ověřovací odkaz na primární e-mailovou adresu účtu Root. Potvrďte tuto e-mailovou výzvu.
- Automatizovaný telefonický hovor: Klikněte na „Zavolejte mi nyní“. Automatický ověřovací systém AWS zavolá na telefonní číslo registrované u účtu a sdělí 6místný potvrzovací PIN.
Pokud organizace změnila telefonní čísla nebo kontaktní osoba ze společnosti odešla bez aktualizace nastavení účtu AWS, automatizovaná obnova selže. Manuální řešení pak vyžaduje zaslání notářsky ověřených dokumentů o registraci společnosti oddělení AWS Trust & Safety, přičemž vyřízení trvá 3 až 7 pracovních dní.
Často kladené otázky podnikového architekta (FAQ)
Lze tokeny AWS Root MFA sdílet napříč týmem DevOps? ▼
To je přísně zakázáno. Sdílení přihlašovacích údajů účtu Root vede k okamžitému neúspěchu v auditech shody (SOC 2, ISO 27001). Běžná správa musí probíhat prostřednictvím rolí v IAM Identity Center s individuální odpovědností konkrétních osob. Údaje k účtu Root musí zůstat uzamčeny v trezoru pod duální správou a použity pouze pro krizové situace.
Jak podmínkový klíč aws:MultiFactorAuthAge zvyšuje úroveň zabezpečení? ▼
Tento klíč vynucuje čerstvost relace. Nastavením podmínky "NumericLessThan": {"aws:MultiFactorAuthAge": "3600"} je požadováno, aby token MFA byl zadán v průběhu posledních 3 600 sekund (1 hodiny). Vysoce rizikové akce (např. smazání clusteru RDS) budou zablokovány, pokud je relace starší, což chrání před únosy dlouhodobě otevřených relací.
Lze použít online autentizátor 2FA-Tool pro registraci AWS Virtual MFA? ▼
Ano. AWS Virtual MFA striktně dodržuje specifikaci RFC 6238 TOTP (HMAC-SHA1, 30sekundový interval, 6 číslic). Můžete zadat Base32 tajný klíč do 2FA-Tool.com pro vygenerování dvou po sobě jdoucích ověřovacích kódů požadovaných při registraci, a to 100% lokálně ve vašem prohlížeči.
Otestujte podnikové tokeny TOTP bezpečně
Generujte standardní ověřovací kódy TOTP podle RFC 6238 okamžitě pomocí W3C Web Crypto API. Žádné volání serveru, absolutní izolace v paměti a nulové riziko úniku.