AWS:n jaetun vastuun mallin (Shared Responsibility Model) mukaisesti AWS hallinnoi "pilven turvallisuutta" (fyysiset datakeskukset, isäntälaitteisto, hypervisorit), kun taas asiakas kantaa jakamattoman vastuun "turvallisuudesta pilvessä"—erityisesti identiteetinhallinnasta, tunnistetietojen hygieniasta ja pääsynhallinnasta. Rajoittamattoman AWS Root -tilin tai etuoikeutetun IAM-tunnisteen vaarantuminen mahdollistaa hyökkääjille tuhansien dollarien arvoisten luvattomien GPU-kryptolouhintainstanssien käynnistämisen, yksityisten S3-tietoaltaiden vuotamisen tai tuhoisien lunnasohjelmien poisto-operaatioiden suorittamisen.
MFA on pakollinen kaikille hallintakonsolin käyttäjille ja ehdoton AWS Root -tilille.
AWS mahdollistaa jopa 8 erillisen FIDO2- ja virtuaalisen TOTP-tunnisteen rekisteröinnin tiliä kohden, mikä poistaa yksittäiset vikaantumispisteet.
Globaali IAM-ehdollinen esto (conditional deny) estää kaikki valtuuttamattomat API-kutsut, kunnes aktiivinen MFA-todennus on suoritettu.
Pilven vaatimustenmukaisuuden perustasot: CIS Benchmark ja sääntelykehykset
Tavoitteleepa kehitysorganisaatiosi SOC 2 Type II -todennusta, ISO 27001 -sertifiointia, PCI DSS 4.0 -validointia tai AWS Well-Architected Security Pillar -suositusten noudattamista, MFA:n käyttöönotto kaikille IAM-identiteeteille on perustavanlaatuinen pääsyvaatimus:
| Standardi / Vaatimuskehys | Valvonnan määrittely | Vakavuusaste / Velvoite | Auditoinnin validointimekanismi |
|---|---|---|---|
| CIS AWS Foundations Benchmark v3.0 | 1.5 / 1.6 / 1.10 | Taso 1 (Pakollinen) | AWS Security Hub / Prowler -automaattinen arviointi |
| PCI DSS 4.0 | Vaatimus 8.4.2 | Pakollinen | Kortinhaltijoiden data-alueen (CDE) konsoli- ja API-auditointi |
| SOC 2 Type II (Luottamuskriteerit) | CC6.1 / CC6.2 | Keskeinen valvontakohta | Riippumattoman CPA-tarkastajan IAM-tunnisteraporttien tarkastus |
| AWS:n pakollinen MFA-käyttöönotto | AWS 2024–2026 -käytäntö | Alustan valvonta | Root-kirjautumisportin esto, kunnes MFA-rekisteröinti on tehty |
AWS Root -tilin suojaamisen ehdoton välttämättömyys
AWS-tilin rajojen sisällä Root-tili edustaa kaikkivoipaa identiteettiä, joka luodaan tiliä perustettaessa. Toisin kuin IAM-rooleja tai -käyttäjiä, Root-tilin toimia ei voida rajoittaa IAM-identiteettipohjaisilla käytännöillä tai Service Control Policy (SCP) -säännöillä erillisissä tileissä.
Vaarantuneen Root-tilin katastrofaalinen tuhovaikutus:
- Peruuttamaton tilin sulkeminen: Hyökkääjät voivat napsauttaa "Close Account", mikä ajoittaa koko infrastruktuurin pysyvän tuhoamisen.
- Laskutus ja taloudellinen kaappaus: Vaihtaa laskutusosoitteita, korvata yrityksen maksukortteja ja ottaa käyttöön satoja GPU-spottiesiintymiä yli 30 AWS-alueella laitonta kryptovaluutan louhintaa varten.
- AWS Organizations -rakenteen rikkominen: Poistaa jäsentilejä hallintapuusta, mikä purkaa organisaation vaatimustenmukaisuuden seurannan.
- Ensisijaisten turvayhteystietojen muuttaminen: Root-sähköpostin ja puhelinnumeron muuttaminen katkaisee pysyvästi virallisen AWS-tuen toimintamahdollisuudet.
- Ei lainkaan Root-käyttöoikeusavaimia: Auditoi IAM-tunnisteraportit varmistaaksesi, ettei Root-tilille ole olemassa käyttöoikeusavaimia (Access Keys). Jos sellaisia on, poista ne välittömästi.
- Kahden hengen salasanalukitus (Dual-Custody Vaulting): Luo vähintään 32-merkkinen satunnainen salasana, jaa salasanalauseke tietoturvajohtajan (CISO) ja lakiasiainjohtajan (General Counsel) kesken, ja lukitse osat fyysisiin paloturvallisiin kassakaappeihin.
- Usean laitteen redundanssi (jopa 8 laitetta): Rekisteröi vähintään kaksi fyysistä FIDO2-laitteistoavainta (YubiKey) sekä offline-tilassa kylmäsäilytyksessä oleva virtuaalinen TOTP-varalaite.
MFA-valintamatriisi: Virtuaalinen TOTP vs. laitteisto-FIDO2 (YubiKey)
AWS tukee kolmea pääasiallista MFA-laiteluokkaa. Pilviarkkitehtien tulee sovittaa valinta uhkamallien ja hallinnollisten käyttöoikeustasojen mukaisesti:
Virtuaaliset TOTP-sovellukset
Standardit RFC 6238 -tunnisteet (Google Authenticator, 1Password, 2FA-Tool). Nopea käyttöönotto, ei hankintaviiveitä. Ihanteellinen peruskehittäjille.
YubiKey 5 -sarja
Tietojenkalastelun kestävä kryptografia. Alkuperään sidotut julkisen avaimen väittämät estävät käänteisvälityspalvelinten kalastelutyökalut. Pakollinen Root- ja pääkäyttäjille.
Gemalto- / Thales-kortit
Omalla virtalähteellä varustettu, ilmaroikossa (air-gap) toimiva TOTP-kortti LCD-näytöllä. Välttämätön turvatiloissa (SCIF), joissa älypuhelimet ja USB-avaimet ovat kiellettyjä.
Yritystason laitteisto-MFA FIPS 140-2 Level 3 ja kahden henkilön holvikäytännöt:
Fortune 500 -yrityksille ja puolustusalan alihankkijoille Root-tilin suojaaminen edellyttää erillisiä laitteistoavaimia (esim. SafeNet/Gemalto IDPrime -tunnisteet), jotka on sertifioitu FIPS 140-2 Level 3 -standardin mukaisesti. Toisin kuin älypuhelinsovelluksissa, näissä fyysisissä tunnisteissa ei ole langattomia liitäntöjä eikä Bluetooth-yhteyksiä, eikä niitä voida kaapata mobiilivakoiluohjelmilla.
Fyysinen kahden hengen hallinta (Dual-Custody): Yritystason datakeskuskäytännöissä Root-pääsy vaatii kaksi eri henkilöä: toinen valvoja hallitsee pääsähköpostin kirjautumistietoja, kun taas riippumaton turvallisuusvastaava hallitsee fyysistä avainta turvakaappiin, jossa Root-laitteistotunnistetta säilytetään. Kumpikaan osapuoli ei voi käyttää AWS Root -tiliä yksin.
MFA:n pakottaminen IAM-käytännöillä (JSON-toteutus)
Tietoturvan perustasot eivät voi nojata työntekijöiden vapaaehtoisuuteen. Pilvihallinta edellyttää käytäntötason valvontaa: käyttäjiltä, joilla ei ole aktiivista MFA-todennusta, on järjestelmällisesti evättävä kaikki AWS API- ja konsolitoiminnot, lukuun ottamatta mahdollisuutta rekisteröidä oma MFA-laitteensa.
{
"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"
}
}
}
]
}
Lauseke 4 (Statement 4) arvioi yleistä ehtoavainta "aws:MultiFactorAuthPresent": "false" käyttäen eksplisiittistä Deny-määritystä. Koska eksplisiittinen Deny ohittaa kaikki Allow-lausekkeet, istunnot ilman MFA:ta estetään välittömästi kaikissa AWS API -kutsuissa, mikä ohjaa käyttäjän suoraan laitteen rekisteröintinäkymään.
AWS CLI- ja SDK-MFA-todennus: Väliaikaiset STS-istuntotunnisteet
Kun IAM-käytännöt edellyttävät MFA:ta, kehittäjät, jotka suorittavat komentoja kuten aws s3 ls tai ajavat Terraform-koodia, saavat virheilmoituksen AccessDenied. Pitkäaikaiset käyttöoikeusavaimet eivät voi pyytää kertakoodeja interaktiivisesti.
Insinöörien on käytettävä AWS STS (Security Token Service) -palvelua vaihtaakseen pitkäaikaiset avaimet ja 6-numeroisen TOTP-koodin väliaikaisiin tunnistetietoihin:
Automaatioskripti (aws-mfa-session.sh):
Sijoita tämä apuskripti paikalliseen ympäristöösi (~/.aws/aws-mfa-session.sh) automatisoidaksesi tunnisteiden hankinnan:
# 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
Tilien välinen AssumeRole MFA-rajoituksilla
Yritystason usean tilin arkkitehtuureissa valtuutetut insinöörit tunnistautuvat yleensä keskitetylle identiteettitilille ja siirtyvät kohdetileille (tuotanto, testiympäristö) käyttämällä komentoa sts:AssumeRole. Sen varmistamiseksi, ettei korotettuja tuotanto-oikeuksia voida kaapata vuotaneiden tunnisteiden avulla, tuotantoroolin luottamussuhteen on edellytettävä MFA-ehtoa:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
Tämä arkkitehtuurimalli varmistaa, että vaikka hyökkääjä vaarantaisi tunnisteet keskitetyllä identiteettitilillä, yritys omaksua kohderooli ilman MFA-vahvistusta aiheuttaa välittömän AccessDenied -virheen suojaustunnisteen rajalla.
CloudTrail-auditointi ja reaaliaikaiset EventBridge-hälytykset
Automaattinen vaatimustenmukaisuuden varmistaminen edellyttää välitöntä havaitsemista, jos joku käyttäjä kirjautuu AWS Management Consoleen ilman monivaiheista todennusta. Reitittämällä AWS CloudTrail -tapahtumat Amazon EventBridgen kautta tietoturvatiimit saavat reaaliaikaisia hälytyksiä:
{
"source": ["aws.signin"],
"detail-type": ["AWS Console Sign In via CloudTrail"],
"detail": {
"eventName": ["ConsoleLogin"],
"additionalEventData": {
"MFAUsed": ["No"]
}
}
}
Tapahtuman vastaanottaessaan EventBridge laukaisee Amazon SNS -ilmoituksen tietoturvakeskuksen (SOC) päivystäjälle tai kutsuu AWS Lambda -funktion, joka mitätöi välittömästi aktiivisen IAM-käyttäjäistunnon.
Monen tilin hallinta: AWS Organizations ja IAM Identity Center
Yritysympäristöissä, joissa hallitaan kymmeniä tai satoja AWS-tilejä Landing Zone -rakenteissa, yksittäisten IAM-käyttäjien luominen jokaiseen tiliin on huono käytäntö (anti-pattern).
Keskitetty identiteettifederaatio:
Ota käyttöön AWS IAM Identity Center (aiemmin AWS SSO) nimetyssä hallintatilissäsi (Management Account). Liitä identiteetit yrityksen IdP-järjestelmiin (Okta, Microsoft Entra ID, PingFederate). Valvo yrityksen MFA:ta IdP-tasolla samalla kun liität Service Control Policy (SCP) -käytännöt organisaation juureen estääksesi jäsentilien Root-toiminnot:
"Condition": { "StringLike": { "aws:PrincipalArn": ["arn:aws:iam::*:root"] } }
Tuotantotason SCP: MFA-rajoitusten valvonta kaikilla jäsentileillä
Suurissa organisaatioissa yksittäiset tilien ylläpitäjät saattavat vahingossa myöntää liiallisia käyttöoikeuksia. Liittämällä Service Control Policy (SCP) -säännön organisaation juureen tai organisaatioyksikköön (OU), pilvihallintatiimi asettaa murtumattoman suojakaiteen: kriittiset API-kutsut estetään ehdottomasti, ellei niitä ole valtuutettu aktiivisella MFA-istunnolla:
{
"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"
}
}
}
]
}
Roolien ketjutus ja STS-tunnisteen elinkaarirajoitukset:
Kun IAM-identiteetit omaksuvat välillisiä rooleja, jotka vuorostaan omaksuvat toissijaisia rooleja ("roolien ketjutus", role chaining), AWS STS poistaa alkuperäisen aws:MultiFactorAuthPresent -kontekstin jatkoistuntotunnisteesta! Jotta tiukka päästä päähän -vaatimustenmukaisuus säilyisi tilien välisissä putkissa, suunnittele roolinomaksumispolut suoraan todennetusta IAM Identity Center -istunnosta sen sijaan, että ketjuttaisit useita välillisiä IAM-rooleja.
Hätäpalautus: Kadonneen Root MFA -laitteen protokolla
Mitä tapahtuu, jos kaikki rekisteröidyt Root MFA -laitteistotunnisteet ja virtuaaliset laitteet tuhoutuvat katastrofissa?
Virallinen kanavan ulkopuolinen (Out-of-Band) palautusjärjestys:
- Aloita Root-kirjautuminen: Syötä Root-tilin sähköpostiosoite ja pääsalasana AWS Consolessa.
- MFA:n vianmääritys: Napsauta MFA-kehotteessa "Troubleshoot MFA".
- Ensisijaisen sähköpostin vahvistus: AWS lähettää aikasidonnaisen vahvistuslinkin ensisijaiseen Root-sähköpostiosoitteeseen. Vahvista sähköpostihaaste.
- Automatisoitu puheluhaaste: Napsauta "Call me now". AWS:n automatisoitu järjestelmä soittaa tilille rekisteröityyn ensisijaiseen puhelinnumeroon ja ilmoittaa 6-numeroisen vahvistus-PIN-koodin.
Jos organisaatiosi on vaihtanut puhelinnumeroita tai yhteyshenkilö on lähtenyt yrityksestä päivittämättä AWS-tilin asetuksia, automaattinen palautus epäonnistuu. Manuaalinen ratkaisu edellyttää yrityksen virallisesti vahvistettujen rekisteröintiasiakirjojen toimittamista AWS Trust & Safety -tiimille, ja tarkistuskäsittely kestää 3–7 arkipäivää.
Yritystason pilviarkkitehdin FAQ
Voiko AWS Root MFA -tunnisteita jakaa DevOps-tiimin kesken? ▼
Ehdottomasti kielletty. Root MFA -tunnisteiden jakaminen rikkoo kaikkia vaatimustenmukaisuusauditointeja (SOC 2, ISO 27001). Rutiinihallinnan on tapahduttava IAM Identity Center -roolien kautta yksilöllisellä vastuuvelvollisuudella. Root-tunnistetiedot tulee pitää lukittuina fyysisissä kahden hengen kassakaapeissa vain äärimmäisiä hätätilanteita (break-glass) varten.
Miten ehtoavain aws:MultiFactorAuthAge parantaa tietoturvaa? ▼
Tämä avain valvoo istunnon tuoreutta. Asettamalla "NumericLessThan": {"aws:MultiFactorAuthAge": "3600"} vaaditaan, että MFA-tunniste on esitetty edellisten 3 600 sekunnin (1 tunti) kuluessa. Korkean riskin toiminnot (kuten RDS-klustereiden poistaminen) estetään, jos istunto on vanhempi, mikä suojaa pitkäkestoisilta istuntokaappauksilta.
Voinko käyttää 2FA-Tool-verkkotodentajaa AWS Virtual MFA:n provisiointiin? ▼
Kyllä. AWS Virtual MFA noudattaa tiukasti RFC 6238 TOTP -määrityksiä (HMAC-SHA1, 30 sekunnin aikaväli, 6 numeroa). Voit syöttää Base32-salaisuusmerkkijonon 2FA-Tool.com-palveluun luodaksesi kaksi peräkkäistä todennuskoodia, joita rekisteröinti vaatii – 100 % paikallisesti selaimessasi.
Testaa yritystason TOTP-tunnisteita turvallisesti
Luo standardit RFC 6238 TOTP -vahvistuskoodit välittömästi W3C Web Crypto API:lla. Ei palvelinkutsuja, täydellinen muistin eristys, nolla vuotoa.