Prema AWS-ovom modelu podijeljene odgovornosti (Shared Responsibility Model), dok AWS upravlja „sigurnošću samog oblaka” (fizički podatkovni centri, poslužiteljski hardver, hipervizori), korisnik zadržava potpunu odgovornost za „sigurnost unutar oblaka” — ponajprije za upravljanje identitetima, higijenu vjerodajnica i kontrolu pristupa. Kompromitacija nezaštićenog AWS Root računa ili povlaštenih IAM vjerodajnica omogućuje napadačima pokretanje neprijavljenih GPU instanci vrijednih tisuće dolara za ilegalno rudarenje kriptovaluta, krađu privatnih podataka iz S3 spremišta podataka (data lakes) ili katastrofalno brisanje resursa u sklopu ucjenjivačkih napada.
MFA je obvezan za sve administratore konzole i apsolutno neupitan za AWS Root račun.
AWS dopušta registraciju do 8 zasebnih FIDO2 i virtualnih TOTP tokena po računu, eliminirajući jednu točku kvara.
Globalna uvjetna politika uskraćivanja u IAM-u blokira sve neautorizirane API pozive dok se ne izvrši aktivna MFA provjera.
Standardi usklađenosti u oblaku: CIS Benchmark i regulatorni okviri
Bilo da vaša inženjerska organizacija teži certifikatu SOC 2 Type II, ISO 27001 certifikaciji, PCI DSS 4.0 provjeri ili usklađivanju s AWS Well-Architected stupom sigurnosti, **implementacija MFA na svim IAM identitetima temeljni je uvjet usklađenosti**:
| Standard / Norma usklađenosti | Specifikacija kontrole | Ozbiljnost / Obveza | Mehanizam validacije revizije |
|---|---|---|---|
| CIS AWS Foundations Benchmark v3.0 | 1.5 / 1.6 / 1.10 | Razina 1 (Obvezno) | Automatizirana provjera putem AWS Security Hub / Prowler alata |
| PCI DSS 4.0 | Zahtjev 8.4.2 | Obvezno | Revizija konzole i API-ja u okruženju podataka o vlasnicima kartica (CDE) |
| SOC 2 Type II (Kriteriji povjerenja) | CC6.1 / CC6.2 | Ključna kontrola | Neovisna revizorska provjera IAM izvješća o vjerodajnicama (Credential Reports) |
| AWS obvezno uvođenje MFA | Pravilo AWS 2024.–2026. | Provođenje na razini platforme | Blokada prijave za Root račun dok se ne dovrši registracija MFA uređaja |
Apsolutni imperativ zaštite AWS Root računa
Unutar granica AWS računa, Root račun predstavlja svemogući identitet stvoren pri samom otvaranju računa. Za razliku od IAM uloga ili korisnika, **radnje Root računa ne mogu se ograničiti IAM politikama temeljenim na identitetu niti politikama kontrole servisa (SCP) unutar samostalnih računa**.
Katastrofalni raspon štete (Blast Radius) kompromitiranog Root računa:
- Nepovratno zatvaranje računa: Napadači mogu kliknuti „Close Account”, zakazujući trajno uništenje cjelokupne infrastrukture.
- Financijska otmica i naplata: Preusmjeravanje faktura, zamjena korporativnih platnih kartica i pokretanje stotina GPU spot instanci diljem više od 30 AWS regija za ilegalno rudarenje kriptovaluta.
- Prekid strukture AWS Organizations: Uklanjanje računa članova iz upravljačkog stabla, čime se demontira organizacijski nadzor usklađenosti.
- Izmjena primarnih sigurnosnih kontakata: Promjena adrese e-pošte i telefonskih brojeva Root računa trajno onemogućuje službene kanale intervencije AWS podrške.
- Nula pristupnih ključeva za Root: Pregledajte IAM Credential Reports kako biste potvrdili da pristupni ključevi (Access Keys) za Root račun ne postoje. Ako postoje, odmah ih obrišite.
- Pohrana lozinke uz dvostruko skrbništvo: Generirajte nasumičnu lozinku od 32+ znaka, podijelite lozinku između CISO-a i pravnog savjetnika te pohranite dijelove u zasebne fizičke vatrostalne sefove.
- Redundancija na više uređaja (do 8 uređaja): Registrirajte najmanje **dva fizička FIDO2 hardverska ključa (YubiKey)** uz jedan izvanmrežni, hladno pohranjeni virtualni TOTP rezervni uređaj.
Matrica odabira MFA: Virtualni TOTP naspram hardverskog FIDO2 (YubiKey)
AWS podržava tri primarne klase MFA uređaja. Arhitekti za oblak trebali bi uskladiti odabir na temelju modela prijetnji i razine administrativnih ovlasti:
Virtualne TOTP aplikacije
Standardni RFC 6238 tokeni (Google Authenticator, 1Password, 2FA-Tool). Brzo uvođenje, bez troškova nabave. Idealno za standardne inženjere i razvojne programere.
YubiKey serija 5
Kriptografija **otporna na phishing**. Potvrde javnim ključem vezane uz izvornu domenu sprječavaju napade reverznim proxyjem. **Obvezno za Root i administratore**.
Gemalto / Thales kartice
Samostalno napajana TOTP kartica s LCD zaslonom, potpuno izolirana od mreže. Neophodna za strogo zaštićene objekte (SCIF) u kojima su pametni telefoni i USB uređaji zabranjeni.
Korporativni hardverski MFA prema FIPS 140-2 Level 3 i protokoli sefa s dvostrukim skrbništvom:
Za tvrtke s popisa Fortune 500 i obrambene ugovaratelje, sigurnost Root računa nalaže **namjenske hardverske tokene (npr. SafeNet/Gemalto IDPrime fobs)** certificirane prema standardu FIPS 140-2 Level 3. Za razliku od aplikacija na pametnim telefonima, ovi fizički tokeni nemaju bežična sučelja, nemaju Bluetooth i ne mogu biti presretnuti mobilnim špijunskim softverom.
Fizičko upravljanje uz dvostruko skrbništvo: U protokolima korporativnih podatkovnih centara, pristup Root računu zahtijeva dvije zasebne osobe: jedan skrbnik posjeduje glavne vjerodajnice e-pošte, dok neovisni sigurnosni časnik posjeduje fizički ključ sefa u kojem se nalazi hardverski token za Root. Niti jedna strana ne može jednostrano pristupiti AWS Root računu.
Primjena MFA putem IAM politika (JSON implementacija)
Sigurnosni standardi ne mogu se oslanjati na dobrovoljno postupanje zaposlenika. Upravljanje oblakom zahtijeva provedbu na razini pravila: **korisnicima bez aktivne MFA autentifikacije mora se sustavno uskratiti izvođenje svih AWS API i Console radnji, osim mogućnosti samostalne registracije vlastitog MFA uređaja**.
{
"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"
}
}
}
]
}
Izjava 4 (Statement 4) evaluira globalni ključ uvjeta "aws:MultiFactorAuthPresent": "false" uz eksplicitno uskraćivanje (Deny). Budući da eksplicitni Deny nadjačava sve Allow izjave, sesije bez MFA-a odmah se blokiraju na svim AWS API-jima, usmjeravajući korisnika izravno na zaslon za samostalnu registraciju MFA uređaja.
Autentifikacija putem AWS CLI i SDK-a: Privremeni sesijski tokeni u STS-u
Kada IAM politike nalažu MFA, inženjeri koji pokreću naredbe poput aws s3 ls ili izvršavaju Terraform kod primit će pogreške AccessDenied. Dugotrajni pristupni ključevi ne mogu interaktivno tražiti jednokratne lozinke (OTP).
Inženjeri moraju koristiti AWS STS (Security Token Service) kako bi zamijenili dugotrajne ključeve + 6-znamenkasti TOTP za privremene vjerodajnice:
Automatizacijska skripta (aws-mfa-session.sh):
Spremite ovu pomoćnu skriptu u svoje lokalno okruženje (~/.aws/aws-mfa-session.sh) kako biste automatizirali preuzimanje tokena:
# Zamjena dugotrajnih AWS ključeva + MFA koda za privremeni STS sesijski token
MFA_ARN="arn:aws:iam::123456789012:mfa/alex-dev"
echo -n "Unesite 6-znamenkasti 2FA OTP kod: "
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 "✅ Autentifikacija uspješna! Privremena sesija izvezena (Vrijedi 12 sati)."
else
echo "❌ Autentifikacija nije uspjela. Provjerite kod tokena ili vremenski pomak uređaja."
fi
Međuračunski AssumeRole uz MFA ograničenja
U višeračunskim korporativnim arhitekturama, povlašteni inženjeri obično se autentificiraju na centraliziranom Identity računu i prelaze na ciljne račune (Production, Staging) putem sts:AssumeRole. Kako bi se osiguralo da se povišene produkcijske ovlasti ne mogu preuzeti kompromitiranim vjerodajnicama, odnos povjerenja (trust relationship) produkcijske uloge mora nametnuti MFA uvjet:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
Ovaj arhitektonski obrazac osigurava da čak i ako napadač kompromitira vjerodajnice u središnjem Identity računu, pokušaj preuzimanja ciljne uloge bez zadovoljavanja MFA provjere odmah izaziva pogrešku AccessDenied na samoj granici sigurnosnog tokena.
Revizija putem CloudTraila i upozorenja u stvarnom vremenu putem EventBridgea
Automatizirana provjera usklađenosti zahtijeva trenutačno otkrivanje kada bilo koji korisnik pristupi AWS Management Consoleu bez višefaktorske autentifikacije. Hvatanjem događaja u servisu AWS CloudTrail i njihovim usmjeravanjem kroz Amazon EventBridge, SecOps timovi dobivaju upozorenja u stvarnom vremenu:
{
"source": ["aws.signin"],
"detail-type": ["AWS Console Sign In via CloudTrail"],
"detail": {
"eventName": ["ConsoleLogin"],
"additionalEventData": {
"MFAUsed": ["No"]
}
}
}
Po primitku događaja, EventBridge pokreće Amazon SNS obavijest prema dežurnom pozivnom uređaju operativnog centra za sigurnost (SOC) ili poziva AWS Lambda funkciju koja trenutačno poništava aktivnu sesiju IAM korisnika.
Upravljanje s više računa: AWS Organizations i IAM Identity Center
U korporativnim okruženjima koja upravljaju desecima ili stotinama AWS računa kroz Landing Zone, stvaranje pojedinačnih IAM korisnika na svakom računu predstavlja antimodel (anti-pattern).
Centralizirano udruživanje identiteta (Identity Federation):
Implementirajte **AWS IAM Identity Center (ranije AWS SSO)** u svom zadanom upravljačkom računu (Management Account). Ujedinite identitete s korporativnim davateljima identiteta (IdP - Okta, Microsoft Entra ID, PingFederate). Nametnite korporativni MFA na razini IdP-a, dok na korijenskoj razini organizacije dodajete Service Control Policies (SCP) koje zabranjuju izvođenje akcija putem Root računa članova:
"Condition": { "StringLike": { "aws:PrincipalArn": ["arn:aws:iam::*:root"] } }
Produkcijski SCP: Nametanje MFA ograničenja na svim računima članova
U velikim organizacijama, administratori pojedinih računa mogu nehotice dodijeliti prevelike ovlasti. Dodavanjem **Service Control Policy (SCP)** na razini korijena organizacije ili organizacijske jedinice (OU), tim za upravljanje oblakom uspostavlja nepromjenjivu sigurnosnu ogradu: operacije s visokim utjecajem bezuvjetno se odbijaju osim ako nisu autorizirane aktivnom MFA sesijom:
{
"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"
}
}
}
]
}
Lančano preuzimanje uloga (Role Chaining) i ograničenja trajanja STS tokena:
Kada IAM identiteti preuzimaju posredničke uloge koje zatim preuzimaju sekundarne uloge („lančano preuzimanje uloga”), AWS STS uklanja izvorni kontekst aws:MultiFactorAuthPresent iz nizvodnog sesijskog tokena! Kako biste održali strogu usklađenost kroz međuračunske cjevovode, dizajnirajte grafikone preuzimanja uloga izravno iz autentificirane sesije u servisu IAM Identity Center umjesto ulančavanja više posredničkih IAM uloga.
Oporavak od katastrofe: Protokol za slučaj gubitka Root MFA uređaja
Što se događa ako se svi registrirani Root MFA hardverski tokeni i virtualni uređaji unište u katastrofalnom događaju?
Službeni izvanpojasni slijed oporavka (Out-of-Band):
- Pokretanje prijave Root računom: Unesite adresu e-pošte i glavnu lozinku Root računa na AWS konzoli.
- Rješavanje problema s MFA: Na upitu za MFA kliknite „Troubleshoot MFA” (Riješi probleme s MFA-om).
- Provjera putem primarne e-pošte: AWS šalje vremenski ograničenu poveznicu za provjeru na primarnu adresu e-pošte Root računa. Potvrdite izazov e-pošte.
- Automatizirani glasovni poziv: Kliknite „Call me now”. Automatizirani sustav za provjeru poziva registrirani primarni telefonski broj računa i izgovara 6-znamenkasti potvrdni PIN.
Ako je vaša organizacija promijenila telefonske brojeve ili je kontaktna osoba napustila tvrtku bez ažuriranja postavki AWS računa, automatizirani oporavak neće uspjeti. Ručno rješavanje zahtijeva slanje službeno ovjerenih dokumenata o registraciji tvrtke AWS timu za povjerenje i sigurnost (Trust & Safety), a pregled traje između 3 i 7 radnih dana.
Često postavljana pitanja arhitekata za oblak (FAQ)
Mogu li se AWS Root MFA tokeni dijeliti unutar DevOps tima? ▼
Strogo zabranjeno. Dijeljenje vjerodajnica Root MFA-a ruši sve revizije usklađenosti (SOC 2, ISO 27001). Rutinska administracija mora se odvijati putem uloga u IAM Identity Centeru uz pojedinačnu odgovornost. Root vjerodajnice moraju ostati zaključane u fizičkim sefovima s dvostrukim skrbništvom, isključivo za hitne situacije (break-glass).
Kako ključ uvjeta aws:MultiFactorAuthAge povećava sigurnost? ▼
Ovaj ključ provodi svježinu sesije. Konfiguracija "NumericLessThan": {"aws:MultiFactorAuthAge": "3600"} zahtijeva da je MFA token unesen unutar prethodnih 3.600 sekundi (1 sat). Radnje visokog rizika (npr. brisanje RDS klastera) bit će blokirane ako je sesija starija od toga, čime se štiti od otmice dugotrajnih sesija.
Mogu li koristiti mrežni autentifikator 2FA-Tool za postavljanje AWS Virtual MFA? ▼
Da. AWS Virtual MFA strogo se pridržava RFC 6238 TOTP specifikacija (HMAC-SHA1, 30-sekundni interval, 6 znamenki). Možete unijeti Base32 tajni niz u 2FA-Tool.com kako biste generirali dva uzastopna autentifikacijska koda potrebna za registraciju, 100% lokalno u vašem pregledniku.
Sigurno testirajte korporativne TOTP tokene
Generirajte standardne RFC 6238 TOTP verifikacijske kodove trenutačno pomoću W3C Web Crypto API-ja. Bez poziva poslužitelju, uz potpuno zadržavanje u memoriji i nulto curenje podataka.