Az AWS megosztott felelősségi modellje (Shared Responsibility Model) alapján, miközben az AWS felel a „Felhő biztonságáért” (Security OF the Cloud) — fizikai adatközpontok, hardver, hypervisorok —, az ügyfél kizárólagos felelőssége a „Felhőbeli biztonság” (Security IN the Cloud), különösen az identitáskezelés, a hitelesítő adatok védelme és a hozzáférés-vezérlés. Egy korlátlan AWS Root-fiók vagy egy felhatalmazott IAM hitelesítő adat kompromittálódása lehetővé teszi a támadók számára, hogy több ezer dolláros illegális GPU kriptobányász példányokat hozzanak létre, privát S3 adattavakat szivárogtassanak ki, vagy katasztrofális zsarolóvírusos törléseket hajtsanak végre.
Az MFA kötelező minden felügyeleti konzol felhasználónak, és elengedhetetlen az AWS Root-fiók esetében.
Az AWS fiókonként akár 8 különböző FIDO2 és virtuális TOTP token regisztrálását teszi lehetővé, kiküszöbölve az egyetlen hibapontot.
Globális IAM feltételes megtagadási házirend, amely blokkolja az összes illetéktelen API-hívást, amíg az aktív MFA-hitelesítés nem történik meg.
Felhőmegfelelőségi alapszintek: CIS Benchmark és szabályozási keretrendszerek
Függetlenül attól, hogy mérnökcsapata SOC 2 Type II tanúsításra, ISO 27001 minősítésre, PCI DSS 4.0 megfelelőségre törekszik, vagy az AWS Well-Architected Security Pillar alapelveit valósítja meg, az MFA bevezetése az IAM-identitásokon alapvető követelmény:
| Szabvány / Megfelelőségi keretrendszer | Ellenőrzési specifikáció | Súlyosság / Kötelezettség | Audit ellenőrzési mechanizmus |
|---|---|---|---|
| CIS AWS Foundations Benchmark v3.0 | 1.5 / 1.6 / 1.10 | 1. szint (Kötelező) | AWS Security Hub / Prowler automatizált felmérés |
| PCI DSS 4.0 | 8.4.2 követelmény | Kötelező | Kártyabirtokosi adatkörnyezet (CDE) konzol és API audit |
| SOC 2 Type II (Bizalmi kritériumok) | CC6.1 / CC6.2 | Kulcsfontosságú kontroll | Független könyvvizsgálói ellenőrzés az IAM hitelesítő adatok jelentésein (Credential Reports) |
| AWS kötelező MFA bevezetés | AWS 2024–2026 szabályzat | Platformszintű kikényszerítés | Root bejelentkezési kapu blokkolása az MFA regisztráció befejezéséig |
Az AWS Root-fiók védelmének abszolút elengedhetetlensége
Egy AWS-fiók határain belül a Root-fiók a létrehozáskor keletkező, teljhatalmú identitást képviseli. Az IAM szerepkörökkel vagy felhasználókkal ellentétben a Root-fiók műveleteit önálló fiókokban nem korlátozhatják az IAM identitásalapú házirendek vagy a Service Control Policy-k (SCP).
A kompromittált Root-fiók katasztrofális hatásai:
- Visszafordíthatatlan fiókbezárás: A támadók a „Close Account” gombra kattintva ütemezhetik a teljes infrastruktúra végleges megsemmisítését.
- Számlázási és pénzügyi eltérítés: Számlák átirányítása, vállalati fizetési kártyák cseréje, és több száz GPU spot példány indítása több mint 30 AWS-régióban illegális kriptovaluta-bányászathoz.
- Az AWS Organizations struktúra szétzilálása: A tagfiókok eltávolítása a felügyeleti fákból, szétrombolva a szervezeti megfelelőségi ellenőrzést.
- Elsődleges biztonsági kapcsolattartók módosítása: A root e-mail cím és telefonszám megváltoztatása véglegesen elvágja a hivatalos AWS támogatási beavatkozási csatornákat.
- Nulla Root hozzáférési kulcs (Zero Root Access Keys): Ellenőrizze az IAM hitelesítési jelentéseket, és győződjön meg arról, hogy nem léteznek hozzáférési kulcsok a Root-fiókhoz. Ha vannak, azonnal törölje őket.
- Kettős felügyeletű jelszótárolás (Dual-Custody Password Vaulting): Generáljon legalább 32 karakteres véletlenszerű jelszót, ossza meg a jelszórészletet a CISO és a jogi vezető között, és zárja a darabokat fizikai tűzálló széfekbe.
- Többeszközös redundancia (akár 8 eszköz): Regisztráljon legalább két fizikai FIDO2 hardverkulcsot (YubiKey), valamint egy offline, hidegen tárolt virtuális TOTP tartalék eszközt.
MFA kiválasztási mátrix: Virtuális TOTP vs. Hardveres FIDO2 (YubiKey)
Az AWS három fő MFA-eszközosztályt támogat. A felhőarchitekteknek a fenyegetettségi modellek és az adminisztrátori jogosultsági szintek alapján kell választaniuk:
Virtuális TOTP alkalmazások
Szabványos RFC 6238 tokenek (Google Authenticator, 1Password, 2FA-Tool). Gyors bevezetés, nulla beszerzési nehézség. Ideális általános fejlesztők számára.
YubiKey 5 sorozat
Adathalászat-biztos (Phishing-Resistant) kriptográfia. A tartományhoz kötött (origin-bound) nyilvános kulcsú igazolások meghiúsítják a fordított proxys adathalász készleteket. Kötelező a Root és az adminisztrátorok számára.
Gemalto / Thales kártyák
Önálló tápellátású, hálózattól elzárt (air-gapped) TOTP kártya LCD kijelzővel. Nélkülözhetetlen a szigorúan védett létesítményekben (SCIF), ahol az okostelefonok és az USB-kulcsok használata tilos.
Vállalati hardveres MFA FIPS 140-2 Level 3 és kettős felügyeletű széfprotokollok:
A Fortune 500 vállalatok és védelmi beszállítók számára a Root-fiók biztonsága FIPS 140-2 Level 3 tanúsítvánnyal rendelkező dedikált hardveres kulcsokat (pl. SafeNet/Gemalto IDPrime kulcsok) ír elő. Az okostelefonos alkalmazásokkal ellentétben ezek a fizikai eszközök nem rendelkeznek vezeték nélküli interfésszel, nincs bennük Bluetooth, és mobil spyware-rel sem kompromittálhatók.
Fizikai kettős felügyelet (Dual-Custody): A vállalati adatközponti protokollokban a Root-hozzáféréshez két különálló személy szükséges: az egyik felügyelő a mester e-mail hitelesítő adatokat birtokolja, míg egy független biztonsági tisztviselő rendelkezik a Root hardver tokent tartalmazó biztonsági széf fizikai kulcsával. Egyik fél sem férhet hozzá egyoldalúan az AWS Root-fiókhoz.
MFA kikényszerítése IAM házirendekkel (JSON megvalósítás)
A biztonsági alapkövetelmények nem alapulhatnak a munkavállalók önkéntes döntésén. A felhőirányítás házirend szintű kikényszerítést követel meg: az aktív MFA-hitelesítéssel nem rendelkező felhasználóktól szisztematikusan meg kell tagadni minden AWS API- és konzolműveletet, kivéve saját MFA-eszközük önálló regisztrációját.
{
"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"
}
}
}
]
}
A 4. feltétel (Statement 4) az "aws:MultiFactorAuthPresent": "false" globális feltételkifejezést értékeli ki egy kifejezett Deny szabállyal. Mivel a kifejezett Deny felülír minden Allow szabályt, az MFA nélküli munkamenetek azonnal blokkolásra kerülnek az összes AWS API-ban, a felhasználót közvetlenül az önregisztrációs felületre irányítva.
AWS CLI és SDK MFA hitelesítés: STS ideiglenes munkamenet-tokenek
Amikor az IAM házirendek kikényszerítik az MFA-t, az olyan parancsokat futtató fejlesztők, mint az aws s3 ls vagy a Terraform parancsok végrehajtása, AccessDenied hibát kapnak. A hosszú távú hozzáférési kulcsok nem képesek interaktívan bekérni az OTP-kódokat.
A mérnököknek az AWS STS (Security Token Service) szolgáltatást kell használniuk a hosszú távú kulcsok és a 6 számjegyű TOTP kód ideiglenes hitelesítő adatokra való beváltásához:
Automatizálási szkript (aws-mfa-session.sh):
Helyezze el ezt a segédszkriptet a helyi környezetében (~/.aws/aws-mfa-session.sh) a tokenlekérés automatizálásához:
# 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
Fiókok közötti AssumeRole MFA korlátozásokkal
A vállalati több-fiókos architektúrákban a privilegizált mérnökök általában egy központi Identity fiókban hitelesítik magukat, majd az sts:AssumeRole hívással lépnek át a célfiókokba (Production, Staging). Annak biztosítására, hogy a megemelt éles jogosultságok ne legyenek eltéríthetők kiszivárgott hitelesítő adatokkal, a production szerepkör megbízhatósági házirendjének (trust relationship) MFA feltételt kell kikényszerítenie:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
Ez az architekturális minta biztosítja, hogy még ha a támadó meg is szerzi a központi Identity fiók hitelesítő adatait, a cél szerepkör átvételének megkísérlése az MFA teljesítése nélkül azonnali AccessDenied hibát vált ki a biztonsági token határánál.
CloudTrail auditálás és EventBridge valós idejű riasztások
Az automatizált megfelelőségi ellenőrzés azonnali észlelést követel meg, ha bármely felhasználó többtényezős hitelesítés nélkül lép be az AWS felügyeleti konzolba (Management Console). Az AWS CloudTrail események rögzítésével és Amazon EventBridge-en keresztüli továbbításával a SecOps csapatok valós idejű riasztást valósíthatnak meg:
{
"source": ["aws.signin"],
"detail-type": ["AWS Console Sign In via CloudTrail"],
"detail": {
"eventName": ["ConsoleLogin"],
"additionalEventData": {
"MFAUsed": ["No"]
}
}
}
Az esemény beérkezésekor az EventBridge egy Amazon SNS értesítést küld a biztonsági műveleti központ (SOC) ügyeletesének, vagy meghív egy AWS Lambda függvényt, amely azonnal visszavonja az aktív IAM felhasználói munkamenetet.
Több-fiókos irányítás: AWS Organizations és IAM Identity Center
A több tucat vagy több száz AWS-fiókot kezelő vállalati környezetekben a Landing Zone-okon keresztül különálló IAM-felhasználók létrehozása minden fiókban antiminta (anti-pattern).
Központosított identitásföderáció:
Vezesse be az AWS IAM Identity Center-t (korábbi nevén AWS SSO) a kijelölt felügyeleti fiókban (Management Account). Föderálja a személyazonosságokat vállalati IdP-kkel (Okta, Microsoft Entra ID, PingFederate). Kényszerítse ki a vállalati MFA-t az IdP szintjén, miközben Service Control Policy-kat (SCP) kapcsol a szervezet gyökeréhez, megtagadva a tagfiókok root műveleteit:
"Condition": { "StringLike": { "aws:PrincipalArn": ["arn:aws:iam::*:root"] } }
Éles szintű SCP: MFA megkötések kikényszerítése minden tagfiókban
Nagy szervezetekben az egyes fiókadminisztrátorok véletlenül túlzott jogosultságokat adhatnak. A szervezet gyökeréhez (Organization Root) vagy a szervezeti egységhez (OU) kapcsolt Service Control Policy (SCP) segítségével a felhőirányítási csapat megdönthetetlen korlátot állít fel: a kritikus hatású API-hívások feltétel nélkül megtagadásra kerülnek, kivéve, ha aktív MFA-munkamenet hitelesíti őket:
{
"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"
}
}
}
]
}
Szerepkör-láncolás (Role Chaining) és STS token élettartam korlátai:
Amikor az IAM-identitások olyan köztes szerepköröket vesznek fel, amelyek később másodlagos szerepköröket vesznek fel („szerepkör-láncolás”), az AWS STS eltávolítja az eredeti aws:MultiFactorAuthPresent kontextust a lefelé irányuló munkamenet-tokenből! A fiókok közötti folyamatok szigorú megfelelőségének fenntartása érdekében a szerepkör-átvételi gráfokat közvetlenül a hitelesített IAM Identity Center munkamenetből építse fel, ahelyett, hogy több köztes IAM-szerepkört láncolna össze.
Katasztrófa utáni helyreállítás: Elveszett Root MFA eszköz protokoll
Mi történik, ha egy katasztrófa során az összes regisztrált Root MFA hardveres token és virtuális eszköz megsemmisül?
Hivatalos sávon kívüli (Out-of-Band) helyreállítási folyamat:
- Root bejelentkezés kezdeményezése: Adja meg a Root-fiók e-mail címét és a mesterjelszót az AWS felügyeleti konzolon.
- MFA hibaelhárítás: Az MFA bekérő ablakban kattintson a „Troubleshoot MFA” lehetőségre.
- Elsődleges e-mail ellenőrzés: Az AWS időkorlátos ellenőrző linket küld az elsődleges Root e-mail címre. Erősítse meg az e-mail kihívást.
- Automatikus hanghívásos ellenőrzés: Kattintson a „Call me now” gombra. Az AWS automatizált ellenőrző rendszere felhívja a regisztrált elsődleges telefonszámot, és beolvas egy 6 számjegyű megerősítő PIN-kódot.
Ha a szervezet telefonszámot váltott, vagy a kapcsolattartó kilépett anélkül, hogy frissítették volna az AWS-fiók beállításait, az automatikus helyreállítás meghiúsul. A manuális feloldáshoz közjegyző által hitelesített vállalati cégkivonatot kell benyújtani az AWS Trust & Safety csapatának, amelynek elbírálása 3–7 munkanapot vesz igénybe.
Vállalati felhőarchitektúra GYIK
Megoszthatók-e az AWS Root MFA tokenek a DevOps csapat tagjai között? ▼
Szigorúan tilos. A Root MFA hitelesítési adatok megosztása minden megfelelőségi auditon (SOC 2, ISO 27001) azonnali bukást eredményez. A napi adminisztrációt IAM Identity Center szerepkörökön keresztül kell végezni egyéni elszámoltathatósággal. A Root hitelesítő adatokat fizikai, kettős felügyeletű széfekben kell elzárva tartani, kizárólag vészhelyzeti katasztrófaeseményekre („break-glass”).
Hogyan növeli a biztonságot az aws:MultiFactorAuthAge feltételkifejezés? ▼
Ez a kulcs a munkamenet frissességét kényszeríti ki. A "NumericLessThan": {"aws:MultiFactorAuthAge": "3600"} beállítás megköveteli, hogy az MFA tokent az elmúlt 3600 másodpercen (1 órán) belül adják meg. A magas kockázatú műveletek (pl. RDS adatbázisfürtök leállítása) blokkolásra kerülnek, ha a munkamenet ennél régebbi, védve a hosszú távú munkamenet-eltérítések ellen.
Használhatom a 2FA-Tool online hitelesítőt az AWS virtuális MFA beállításához? ▼
Igen. Az AWS Virtual MFA szigorúan követi az RFC 6238 TOTP specifikációt (HMAC-SHA1, 30 másodperces időköz, 6 számjegy). A Base32 titkos karakterláncot beírhatja a 2FA-Tool.com oldalra a regisztrációhoz szükséges két egymást követő hitelesítési kód generálásához, 100%-ban helyben a böngészőjében.
Vállalati TOTP tokenek biztonságos tesztelése
Generáljon szabványos RFC 6238 TOTP ellenőrző kódokat azonnal a W3C Web Crypto API segítségével. Szerverhívások nélkül, abszolút memóriazártság, nulla szivárgás.