V skladu z modelom deljene odgovornosti AWS (Shared Responsibility Model), medtem ko AWS upravlja »varnost samega oblaka« (fizična podatkovna središča, strojna oprema gostiteljev, hipervizorji), stranka ohranja popolno odgovornost za »varnost v oblaku« – zlasti upravljanje identitet, higieno poverilnic in nadzor dostopa. Kompromitacija neomejenega korenskega računa AWS Root ali privilegiranih poverilnic IAM napadalcem omogoča zagon tisočev dolarjev vrednih instanc GPU za rudarjenje kriptovalut, krajo zasebnih podatkovnih jezer S3 ali katastrofalno izsiljevalsko brisanje celotne infrastrukture.
MFA je obvezen za vse uporabnike skrbniške konzole in nepogrešljiv za korenski račun AWS Root.
AWS omogoča registracijo do 8 ločenih ključev FIDO2 in navideznih žetonov TOTP na račun, kar odpravlja posamezno točko odpovedi.
Globalni pogojni pravilnik IAM Deny blokira vse nepooblaščene klice API, dokler ni doseženo aktivno preverjanje pristnosti MFA.
Standardi skladnosti v oblaku: CIS Benchmark in regulativni okviri
Ne glede na to, ali si vaša inženirska organizacija prizadeva za atestacijo SOC 2 Type II, certifikacijo ISO 27001, preverjanje PCI DSS 4.0 ali uskladitev z varnostnim stebrom AWS Well-Architected Framework, je uvedba MFA za identitete IAM temeljna zahteva:
| Standard / Skladnostni okvir | Specifikacija nadzora | Resnost / Obveznost | Mehanizem revizije in potrjevanja |
|---|---|---|---|
| CIS AWS Foundations Benchmark v3.0 | 1.5 / 1.6 / 1.10 | Raven 1 (Obvezno) | Samodejno ocenjevanje prek orodij AWS Security Hub / Prowler |
| PCI DSS 4.0 | Zahteva 8.4.2 | Obvezno | Revizija konzole in API-jev okolja imetnikov kartic (CDE) |
| SOC 2 Type II (Kriteriji zaupanja) | CC6.1 / CC6.2 | Ključni nadzor | Neodvisni pregled poročil IAM Credential Reports s strani revizorja CPA |
| Obvezna uvedba MFA v AWS | Pravilnik AWS 2024–2026 | Uveljavitev na ravni platforme | Blokada prijave v račun Root do zaključka registracije MFA |
Nujnost zaščite korenskega računa AWS Root
Znotraj meja računa AWS račun Root predstavlja vsemogočno identiteto, ustvarjeno ob začetku delovanja računa. V nasprotju z vlogami ali uporabniki IAM dejanj računa Root ni mogoče omejiti s pravilniki identitet IAM ali s pravilniki nadzora storitev (SCP) v samostojnih računih.
Katastrofalne posledice ogroženosti računa Root:
- Nepovratno zaprtje računa: Napadalci lahko kliknejo »Close Account« (Zapri račun), kar sproži trajno uničenje infrastrukture.
- Ugrabitev obračunavanja in financ: Preusmeritev računov, zamenjava plačilnih kartic podjetja ter zagon stotin spotnih instanc GPU v več kot 30 regijah AWS za nezakonito rudarjenje kriptovalut.
- Razpad strukture AWS Organizations: Odstranitev računov članov iz drevesa upravljanja in uničenje organizacijskega nadzora skladnosti.
- Sprememba primarnih varnostnih kontaktov: Sprememba e-poštnega naslova in telefonske številke računa Root trajno onemogoči uradne intervencijske kanale podpore AWS.
- Ničelno število dostopnih ključev Root: Preglejte poročila IAM Credential Reports in potrdite, da za račun Root ne obstajajo dostopni ključi (Access Keys). Če so prisotni, jih takoj izbrišite.
- Shranjevanje gesla z dvojnim nadzorom (Dual-Custody): Ustvarite naključno geslo z več kot 32 znaki, ga razdelite med vodjo informacijske varnosti (CISO) in pravnega svetovalca ter posamezne dele zaklenite v fizične ognjevarne blagajne.
- Podvajanje naprav (do 8 naprav): Registrirajte vsaj dva fizična strojna ključa FIDO2 (YubiKey) in eno navidezno napravo TOTP, shranjeno v hladni shrambi brez povezave kot rezervo.
Izbira MFA: Navidezni TOTP proti strojnemu FIDO2 (YubiKey)
AWS podpira tri glavne razrede naprav MFA. Oblačni arhitekti morajo izbiro prilagoditi modelom groženj in ravnem skrbniških pravic:
Navidezne aplikacije TOTP
Standardni žetoni po RFC 6238 (Google Authenticator, 1Password, 2FA-Tool). Hitra uvedba brez stroškov nabave. Idealno za običajne razvijalce.
Serija YubiKey 5
Odpornost proti lažnemu predstavljanju. Kriptografija, vezana na domeno izvora, onemogoča napade s povratnimi posredniki. Obvezno za račun Root in skrbnike.
Kartice Gemalto / Thales
Kartica TOTP z zaslonom LCD z lastnim napajanjem, fizično ločena od omrežja. Nujna za varovana območja (SCIF), kjer so pametni telefoni in ključi USB prepovedani.
Podjetniški protokoli strojnega MFA s certifikatom FIPS 140-2 Level 3 in sefom z dvojnim skrbništvom:
Za velika podjetja s seznama Fortune 500 in obrambne izvajalce varnost računa Root zahteva namenske strojne obeske (npr. SafeNet/Gemalto IDPrime), certificirane po standardu FIPS 140-2 Level 3. V nasprotju z aplikacijami na pametnih telefonih ti fizični obeski nimajo brezžičnih vmesnikov ali povezave Bluetooth in jih ni mogoče prestreči z mobilno vohunsko programsko opremo.
Fizično upravljanje z dvojnim nadzorom (Dual-Custody): V podjetniških protokolih dostop do računa Root zahteva prisotnost dveh ločenih oseb: en skrbnik hrani poverilnice glavnega e-poštnega računa, neodvisni varnostnik pa ima fizični ključ varnostne blagajne z namenskim strojnim žetonom Root. Nobena stranka ne more enostransko dostopati do računa AWS Root.
Uveljavitev MFA prek pravilnikov IAM (implementacija v JSON)
Varnostna izhodišča se ne morejo zanašati na prostovoljno ravnanje zaposlenih. Upravljanje v oblaku zahteva uveljavitev na ravni pravilnikov: uporabnikom brez aktivnega preverjanja pristnosti prek MFA se sistematično zavrnejo vsa dejanja v vmesnikih AWS API in konzoli, razen možnosti samostojne registracije lastne naprave MFA.
{
"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"
}
}
}
]
}
Stavek 4 ovrednoti globalni pogojni ključ "aws:MultiFactorAuthPresent": "false" z izrecnim pravilom Deny. Ker ima izrecna zavrnitev (Deny) prednost pred vsemi dovoljenji (Allow), se seje brez preverjanja MFA takoj blokirajo pri vseh klicih API v okolju AWS, kar uporabnika neposredno usmeri na zaslon za samostojno registracijo naprave MFA.
Avtentikacija AWS CLI in SDK prek MFA: Začasni sejni žetoni STS
Ko pravilniki IAM zahtevajo MFA, razvijalci ob izvajanju ukazov, kot je aws s3 ls, ali pri izvajanju kode Terraform prejmejo napako AccessDenied. Dolgotrajni dostopni ključi ne morejo interaktivno zahtevati kode OTP.
Inženirji morajo uporabiti storitev AWS STS (Security Token Service) za zamenjavo dolgotrajnih ključev + 6-mestne kode TOTP za začasne poverilnice:
Skript za avtomatizacijo (aws-mfa-session.sh):
Namestite ta pomožni skript v svoje lokalno okolje (~/.aws/aws-mfa-session.sh) za samodejno pridobivanje žetona:
# Zamenjava dolgotrajnih ključev AWS + kode MFA za sejni žeton STS
MFA_ARN="arn:aws:iam::123456789012:mfa/alex-dev"
echo -n "Vnesite 6-mestno kodo 2FA OTP: "
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 "✅ Uspešno overjeno! Začasna seja je izvožena (veljavna 12 ur)."
else
echo "❌ Preverjanje pristnosti ni uspelo. Preverite kodo žetona ali časovni odmik naprave."
fi
Prevzem vlog med računi (AssumeRole) z omejitvami MFA
V podjetniških arhitekturah z več računi se pooblaščeni inženirji običajno prijavijo v osrednji račun identitet (Identity Account) in nato z ukazom sts:AssumeRole prevzamejo vloge v ciljnih računih (produkcija, testno okolje). Da se prepreči ugrabitev povišanih produkcijskih pravic prek ukradenih poverilnic, mora pravilnik zaupanja (Trust Policy) ciljne vloge uveljaviti pogoj MFA:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
Ta arhitekturni vzorec zagotavlja, da tudi če napadalec ogrozi poverilnice v osrednjem računu identitet, poskus prevzema ciljne vloge brez potrditve MFA takoj sproži napako AccessDenied na meji varnostnega žetona.
Revizija s storitvijo CloudTrail in opozorila EventBridge v realnem času
Samodejno preverjanje skladnosti zahteva takojšnje zaznavanje, ko kateri koli uporabnik dostopa do konzole AWS Management Console brez večfaktorske avtentikacije. Z zajemom dogodkov v AWS CloudTrail in njihovim usmerjanjem prek Amazon EventBridge ekipe SecOps dosegajo opozarjanje v realnem času:
{
"source": ["aws.signin"],
"detail-type": ["AWS Console Sign In via CloudTrail"],
"detail": {
"eventName": ["ConsoleLogin"],
"additionalEventData": {
"MFAUsed": ["No"]
}
}
}
Ob prejemu dogodka EventBridge sproži obvestilo prek Amazon SNS dežurnemu varnostnemu centru (SOC) ali zažene funkcijo AWS Lambda, ki takoj prekliče aktivno sejo uporabnika IAM.
Upravljanje več računov: AWS Organizations in IAM Identity Center
V podjetniških okoljih, ki upravljajo na desetine ali stotine računov AWS znotraj pristajalnih območij (Landing Zones), je ročno ustvarjanje posameznih uporabnikov IAM v vsakem računu nezaželen vzorec (anti-pattern).
Centralizirana federacija identitet:
Uvedite AWS IAM Identity Center (prej AWS SSO) v svojem namenskem upravljavskem računu (Management Account). Povežite identitete s korporativnimi ponudniki IdP (Okta, Microsoft Entra ID, PingFederate). Uveljavite korporativni MFA na ravni IdP, hkrati pa na koren organizacije pripnite pravilnike Service Control Policies (SCP), ki prepovedujejo dejanja računa Root v računih članov:
"Condition": { "StringLike": { "aws:PrincipalArn": ["arn:aws:iam::*:root"] } }
Pravilnik SCP za produkcijo: Uveljavljanje omejitev MFA v vseh računih članov
V velikih organizacijah lahko skrbniki posameznih računov nehote dodelijo preširoka pooblastila. S pripetjem pravilnika Service Control Policy (SCP) na ravni korena organizacije ali organizacijske enote (OU) ekipa za upravljanje oblaka vzpostavi nespremenljivo varnostno ograjo: operacije API z visokim vplivom so brezpogojno zavrnjene, razen če so odobrene z aktivno sejo 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"
}
}
}
]
}
Veriženje vlog (Role Chaining) in omejitve življenjske dobe žetona STS:
Kadar identitete IAM prevzamejo posredniške vloge, ki nato prevzamejo sekundarne vloge (»veriženje vlog«), storitev AWS STS odstrani izvirni kontekst aws:MultiFactorAuthPresent iz nadaljnjega sejnega žetona! Za ohranitev stroge skladnosti v večračunskih delovnih tokovih načrtujte grafe prevzemanja vlog neposredno iz avtenticirane seje IAM Identity Center namesto veriženja več vmesnih vlog IAM.
Obnova po katastrofi: Protokol ob izgubi naprave Root MFA
Kaj se zgodi, če so vsi registrirani strojni žetoni in navidezne naprave MFA za račun Root uničeni v nesreči?
Uradni postopek zunajpasovne obnove (Out-of-Band):
- Sprožitev prijave v Root: Vnesite e-poštni naslov računa Root in glavno geslo na konzoli AWS.
- Odpravljanje težav z MFA: Ob pozivu za kodo MFA kliknite »Troubleshoot MFA« (Odpravljanje težav z MFA).
- Preverjanje primarne e-pošte: AWS pošlje časovno omejeno povezavo za preverjanje na primarni e-poštni naslov računa Root. Potrdite e-poštni izziv.
- Samodejni glasovni klic: Kliknite »Call me now« (Pokličite me zdaj). Samodejni sistem AWS pokliče registrirano primarno telefonsko številko računa in sporoči 6-mestno potrditveno kodo PIN.
Če je vaša organizacija spremenila telefonske številke ali je kontaktna oseba zapustila podjetje brez posodobitve nastavitev računa AWS, samodejna obnova ne bo uspela. Ročna rešitev zahteva predložitev notarsko overjenih korporativnih dokumentov ekipi AWS Trust & Safety, kar traja od 3 do 7 delovnih dni.
Pogosta vprašanja za podjetniške arhitekte v oblaku (FAQ)
Ali si lahko ekipa DevOps deli žetone AWS Root MFA? ▼
Strogo prepovedano. Skupna raba poverilnic Root MFA povzroči neuspeh pri vseh revizijah skladnosti (SOC 2, ISO 27001). Rutinsko skrbništvo mora potekati prek vlog IAM Identity Center z individualno odgovornostjo. Poverilnice Root morajo ostati zaklenjene v fizičnih sefih z dvojnim skrbništvom in se uporabljati le ob katastrofalnih izrednih dogodkih (break-glass).
Kako pogojni ključ aws:MultiFactorAuthAge izboljšuje varnost? ▼
Ta ključ zahteva svežino seje. Nastavitev "NumericLessThan": {"aws:MultiFactorAuthAge": "3600"} zahteva, da je bil žeton MFA predložen v zadnjih 3.600 sekundah (1 ura). Dejanja z visokim tveganjem (npr. ustavitev gruč RDS) bodo blokirana, če je seja starejša, kar ščiti pred ugrabitvijo dolgotrajnih sej.
Ali lahko za nastavitev AWS Virtual MFA uporabim spletni avtentikator 2FA-Tool? ▼
Da. Storitev AWS Virtual MFA strogo sledi specifikacijam RFC 6238 TOTP (HMAC-SHA1, 30-sekundni interval, 6 decimalnih mest). Skrivni niz Base32 lahko vnesete v 2FA-Tool.com in ustvarite dve zaporedni overitveni kodi, potrebni za registracijo, 100 % lokalno v svojem brskalniku.
Varno preizkusite podjetniške žetone TOTP
Takoj ustvarite standardne overitvene kode RFC 6238 TOTP z vmesnikom W3C Web Crypto API. Brez klicev strežnika, popolna izolacija v pomnilniku, ničelno tveganje za uhajanje.