AWS MFA labākās prakses: Root konta un IAM lietotāju aizsardzība ar virtuālo MFA

📌 Kopsavilkums un AWS Well-Architected matrica

Saskaņā ar AWS dalītās atbildības modeli (Shared Responsibility Model), kamēr AWS pārvalda "Drošību MĀKONIM" (Security OF the Cloud — fiziskie datu centri, resursdatora aparatūra, hipervizori), klients saglabā pilnu atbildību par "Drošību MĀKONĪ" (Security IN the Cloud) — konkrēti identitātes pārvaldību, akreditācijas datu higiēnu un piekļuves kontroli. Neierobežota AWS Root konta vai priviliģētu IAM akreditācijas datu kompromitēšana ļauj uzbrucējiem izveidot tūkstošiem dolāru vērtas nelikumīgas GPU kriptovalūtu rakšanas instances, nopludināt privātos S3 datu ezerus vai veikt katastrofālu datu dzēšanu izspiešanas nolūkos.

CIS Benchmark bāzes līnija 1.5 un 1.6 sadaļas kontroles

MFA ir obligāta visiem administratīvās konsoles lietotājiem un neapstrīdama AWS Root kontam.

Vairāku MFA dublēšana Līdz 8 MFA ierīcēm

AWS ļauj katram kontam reģistrēt līdz 8 atsevišķiem FIDO2 un virtuālajiem TOTP marķieriem, novēršot vienu atteices punktu.

Programmatiskā izpilde aws:MultiFactorAuthPresent

Globālā IAM nosacītā atteikuma politika bloķē visus neautorizētos API izsaukumus, kamēr nav veikta aktīva MFA validācija.

Mākoņa atbilstības bāzes līnijas: CIS Benchmark un regulatīvās sistēmas

Neatkarīgi no tā, vai jūsu inženieru organizācija tiecas pēc SOC 2 Type II atbilstības, ISO 27001 sertifikācijas, PCI DSS 4.0 validācijas vai saskaņošanas ar AWS Well-Architected drošības pīlāru, MFA ieviešana visās IAM identitātēs ir fundamentāla pamatprasība:

Standarts / Atbilstības standarts	Kontroles specifikācija	Nopietnība / Pilnvarojums	Audita validācijas mehānisms
CIS AWS Foundations Benchmark v3.0	1.5 / 1.6 / 1.10	1. līmenis (Obligāts)	AWS Security Hub / Prowler automatizēts novērtējums
PCI DSS 4.0	Requirement 8.4.2	Obligāts	Kartes īpašnieka datu vides (CDE) konsoles un API audits
SOC 2 Type II (Uzticamības kritēriji)	CC6.1 / CC6.2	Galvenā kontrole	Neatkarīga zvērināta revidenta (CPA) IAM akreditācijas datu pārskatu pārbaude
AWS obligātā MFA ieviešana	AWS 2024–2026 politika	Platformas izpilde	Root pieteikšanās vārtejas bloķēšana līdz MFA reģistrācijas pabeigšanai

AWS Root konta aizsardzības absolūtā nepieciešamība

AWS konta robežās Root konts pārstāv visvareno identitāti, kas izveidota konta radīšanas brīdī. Atšķirībā no IAM lomām vai lietotājiem, Root konta darbības atsevišķos kontos nevar ierobežot ar IAM identitātes politikām vai pakalpojumu kontroles politikām (SCP).

Kompromitēta Root konta katastrofālais ietekmes rādiuss (Blast Radius):

Neatgriezeniska konta slēgšana: Uzbrucēji var noklikšķināt uz "Close Account", ieplānojot neatgriezenisku infrastruktūras iznīcināšanu.
Rēķinu un finanšu pārtveršana: Novirzīt rēķinus, aizstāt uzņēmuma norēķinu maksājumu kartes un izvietot simtiem GPU instances vairāk nekā 30 AWS reģionos nelikumīgai kriptovalūtu ieguvei.
AWS Organizations struktūras saraušana: Noņemt dalībkontus no pārvaldības kokiem, izjaucot organizācijas atbilstības uzraudzību.
Primāro drošības kontaktu maiņa: Root e-pasta un tālruņa ierakstu maiņa neatgriezeniski pārtrauc oficiālos AWS atbalsta iejaukšanās kanālus.

🛡️ Trīs nemainīgie Root higiēnas baušļi:

Nulle Root piekļuves atslēgu (Zero Root Access Keys): Auditējiet IAM Credential Reports, lai apstiprinātu, ka Root kontam nav piekļuves atslēgu. Ja tādas ir, nekavējoties tās izdzēsiet.
Divkāršās uzraudzības paroļu glabātava (Dual-Custody Password Vaulting): Izveidojiet 32+ rakstzīmju nejaušu paroli, sadaliet ieejas frāzi starp CISO un juridisko direktoru un ievietojiet daļas fiziskos ugunsdrošos seifos.
Vairāku ierīču dublēšana (līdz 8 ierīcēm): Reģistrējiet vismaz divas fiziskas FIDO2 aparatūras atslēgas (YubiKeys) un bezsaistes, aukstajā glabātavā esošu virtuālo TOTP rezerves ierīci.

MFA atlases matrica: Virtuālais TOTP pret aparatūras FIDO2 (YubiKey)

AWS atbalsta trīs galvenās MFA ierīču klases. Mākoņarhitektiem izvēle jāsaskaņo, pamatojoties uz draudu modeļiem un administratīvo privilēģiju līmeņiem:

Programmatūras virtuālais MFA

Virtuālās TOTP lietotnes

Standarta RFC 6238 marķieri (Google Authenticator, 1Password, 2FA-Tool). Ātra ieviešana, nulle iepirkuma šķēršļu. Ideāli piemērots standarta izstrādātājiem.

Aparatūras FIDO2 / WebAuthn

YubiKey 5 sērija

Aizsardzība pret pikšķerēšanu (Phishing-Resistant). Ar izcelsmi saistīti publiskās atslēgas apgalvojumi novērš apgrieztā starpniekservera pikšķerēšanas uzbrukumus. Obligāts Root kontam un administratoriem.

Īpašs aparatūras marķieris

Gemalto / Thales kartes

Autonoma, no tīkla atdalīta (air-gapped) TOTP karte ar LCD ekrānu. Būtiska stingri aizsargātām telpām (SCIF), kur viedtālruņi un USB atslēgas ir aizliegtas.

Uzņēmuma aparatūras MFA FIPS 140-2 Level 3 un divkāršās uzraudzības seifu protokoli:

Fortune 500 uzņēmumiem un aizsardzības nozares darbuzņēmējiem Root konta drošība prasa īpašus aparatūras piekariņus (piem., SafeNet/Gemalto IDPrime fobs), kas sertificēti saskaņā ar FIPS 140-2 Level 3. Atšķirībā no viedtālruņu lietotnēm šiem fiziskajiem piekariņiem nav bezvadu saskarņu, nav Bluetooth radio, un tos nevar pārtvert ar mobilo spiegprogrammatūru.

Fiziskā divkāršā uzraudzība: Uzņēmuma datu centru protokolos Root piekļuvei ir nepieciešamas divas atsevišķas personas: viens glabātājs pārvalda galvenā e-pasta akreditācijas datus, savukārt neatkarīgs drošības darbinieks glabā fizisko atslēgu no droša seifa, kurā atrodas Root aparatūras marķieris. Neviena puse nevar vienpusēji piekļūt AWS Root kontam.

MFA izpilde, izmantojot IAM politikas (JSON ieviešana)

Drošības pamatprincipus nevar atstāt atkarīgus no darbinieku brīvprātīgas rīcības. Mākoņa pārvaldībai nepieciešama politikas līmeņa izpilde: lietotājiem bez aktīvas MFA autentifikācijas ir sistemātiski jāliedz visas AWS API un konsoles darbības, izņemot iespēju pašiem reģistrēt savu MFA ierīci.

// Production-grade IAM Policy: Enforce-MFA-Self-Management-Policy.json
{
  "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"
        }
      }
    }
  ]
}

Novērtēšanas loģikas sadalījums:

4. nosacījums novērtē globālo nosacījumu atslēgu "aws:MultiFactorAuthPresent": "false", izmantojot skaidru Deny. Tā kā skaidrs atteikums ignorē visus atļaušanas (Allow) paziņojumus, sesijas bez MFA tiek nekavējoties bloķētas visās AWS API, novirzot lietotāju tieši uz pašreģistrācijas ekrānu.

AWS CLI un SDK MFA autentifikācija: STS pagaidu sesijas marķieri

Kad IAM politikas pieprasa MFA, izstrādātāji, kas izpilda komandas, piemēram, aws s3 ls, vai palaiž Terraform kodu, saņems AccessDenied kļūdas. Ilgtermiņa piekļuves atslēgas nevar interaktīvi pieprasīt OTP kodus. Inženieriem ir jāizmanto AWS STS (Security Token Service), lai apmainītu ilgtermiņa atslēgas + 6 ciparu TOTP pret īslaicīgiem akreditācijas datiem:

Automatizācijas skripts (aws-mfa-session.sh):

Ievietojiet šo palīgskriptu savā lokālajā vidē (~/.aws/aws-mfa-session.sh), lai automatizētu marķieru iegūšanu:

#!/usr/bin/env bash
# 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

Starpkontu AssumeRole ar MFA ierobežojumiem

Uzņēmuma vairāku kontu arhitektūrās priviliģētie inženieri parasti autentificējas centralizētā Identity kontā un pāriet uz mērķa kontiem (Production, Staging), izmantojot sts:AssumeRole. Lai nodrošinātu, ka paaugstinātās ražošanas atļaujas nevar tikt nolaupītas noplūdušu akreditācijas datu dēļ, ražošanas lomas uzticamības attiecībām (trust relationship) ir jāpieprasa MFA nosacījums:

// Target Role Trust Policy requiring active MFA
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  ]
}

Šis arhitektūras modelis nodrošina, ka pat tad, ja uzbrucējs iegūst akreditācijas datus centrālajā Identity kontā, mēģinājums pieņemt mērķa lomu bez MFA veikšanas izraisa tūlītēju AccessDenied kļūdu pie drošības marķiera robežas.

CloudTrail auditēšana un EventBridge reāllaika brīdinājumi

Automatizētai atbilstības validācijai nepieciešama tūlītēja atklāšana, kad kāds lietotājs piekļūst AWS pārvaldības konsolei bez daudzfaktoru autentifikācijas. Tverot AWS CloudTrail notikumus un maršrutējot tos caur Amazon EventBridge, SecOps komandas iegūst reāllaika brīdinājumus:

// EventBridge Rule Pattern: Console Login Without MFA
{
  "source": ["aws.signin"],
  "detail-type": ["AWS Console Sign In via CloudTrail"],
  "detail": {
    "eventName": ["ConsoleLogin"],
    "additionalEventData": {
      "MFAUsed": ["No"]
    }
  }
}

Pēc notikuma saņemšanas EventBridge aktivizē Amazon SNS paziņojumu Drošības operāciju centra (SOC) dežurantam vai izsauc AWS Lambda funkciju, kas nekavējoties atsauc aktīvo IAM lietotāja sesiju.

Vairāku kontu pārvaldība: AWS Organizations un IAM Identity Center

Uzņēmumu vidēs, kurās tiek pārvaldīti desmitiem vai simtiem AWS kontu visās piezemēšanās zonās (Landing Zones), atsevišķu IAM lietotāju nodrošināšana katrā kontā ir pretmodelis.

Centralizēta identitātes federācija:

Izvietojiet AWS IAM Identity Center (iepriekš AWS SSO) savā norādītajā pārvaldības kontā. Apvienojiet identitātes ar korporatīvajiem IdP (Okta, Microsoft Entra ID, PingFederate). Ieviesiet korporatīvo MFA IdP līmenī, vienlaikus piesaistot pakalpojumu kontroles politikas (SCP) organizācijas saknei, lai liegtu dalībkonta Root darbības:

"Action": "*", "Resource": "*",
"Condition": { "StringLike": { "aws:PrincipalArn": ["arn:aws:iam::*:root"] } }

Ražošanas līmeņa SCP: MFA ierobežojumu ieviešana visos dalībkontos

Lielās organizācijās atsevišķi kontu administratori var nejauši piešķirt pārmērīgas privilēģijas. Pievienojot pakalpojumu kontroles politiku (SCP) organizācijas saknes vai organizatoriskās vienības (OU) līmenī, mākoņa pārvaldības komanda izveido nemainīgu aizsargbarjeru: augstas ietekmes API izsaukumi tiek bez nosacījumiem noraidīti, ja vien tos nav autorizējusi aktīva MFA sesija:

// AWS Organizations SCP: Deny destructive API operations without active 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"
        }
      }
    }
  ]
}

Lomu ķēde un STS marķiera darbības laika ierobežojumi:

Kad IAM identitātes pieņem starpposma lomas, kas pēc tam pieņem sekundāras lomas ("lomu ķēde" jeb role chaining), AWS STS atņem sākotnējo aws:MultiFactorAuthPresent kontekstu no pakārtotās sesijas marķiera! Lai uzturētu stingru visaptverošu atbilstību starpkontu konveijeros, veidojiet lomu pieņemšanas grafikus tieši no autentificētās IAM Identity Center sesijas, nevis ķēdējot vairākas starpposma IAM lomas.

Avārijas atjaunošana: nozaudētas Root MFA ierīces protokols

Kas notiek, ja katastrofas laikā tiek iznīcināti visi reģistrētie Root MFA aparatūras marķieri un virtuālās ierīces?

Oficiālā ārpusjoslas atjaunošanas secība (Out-of-Band Recovery):

Sākt Root pieteikšanos: Ievadiet Root konta e-pastu un galveno paroli AWS konsolē.
Novērst MFA problēmas: MFA uzvednē noklikšķiniet uz "Troubleshoot MFA".
Primārā e-pasta verifikācija: AWS nosūta laika ziņā ierobežotu verifikācijas saiti uz primāro Root e-pasta adresi. Apstipriniet e-pasta izaicinājumu.
Automatizēts balss zvans: Noklikšķiniet uz "Call me now". Automatizētā AWS verifikācijas sistēma zvana uz reģistrēto primārā konta tālruņa numuru un nolasa 6 ciparu apstiprinājuma PIN kodu.

Kritisks brīdinājums: Uzturiet primāros kontaktus atjauninātus!

Ja jūsu organizācija ir mainījusi tālruņa numurus vai kontaktpersona ir aizgājusi, neatjauninot AWS konta iestatījumus, automatizētā atjaunošana neizdodas. Manuālai risināšanai ir jāiesniedz notariāli apliecināti uzņēmuma reģistrācijas dokumenti AWS Trust & Safety komandai, un izskatīšana aizņem 3–7 darba dienas.

Uzņēmumu mākoņarhitektu BUJ

Vai AWS Root MFA marķierus var koplietot visā DevOps komandā? ▼

Stingri aizliegts. Root MFA akreditācijas datu koplietošana neiztur visus atbilstības auditus (SOC 2, ISO 27001). Ikdienas administrēšanai jānotiek caur IAM Identity Center lomām ar individuālu atbildību. Root akreditācijas datiem jāpaliek bloķētiem fiziskos divkāršās uzraudzības seifos tikai ārkārtas "stikla laušanas" (break-glass) gadījumiem.

Kā nosacījuma atslēga aws:MultiFactorAuthAge uzlabo drošību? ▼

Šī atslēga nodrošina sesijas svaigumu. Konfigurējot "NumericLessThan": {"aws:MultiFactorAuthAge": "3600"}, ir nepieciešams, lai MFA marķieris būtu uzrādīts iepriekšējo 3600 sekunžu (1 stundas) laikā. Augsta riska darbības (piemēram, RDS klasteru pārtraukšana) tiks bloķētas, ja sesija ir vecāka, aizsargājot pret ilgstošu sesiju nolaupīšanu.

Vai varu izmantot 2FA-Tool tiešsaistes autentifikatoru, lai iestatītu AWS virtuālo MFA? ▼

Jā. AWS virtuālais MFA stingri atbilst RFC 6238 TOTP specifikācijām (HMAC-SHA1, 30 sekunžu intervāls, 6 cipari). Varat ievadīt Base32 slepeno virkni vietnē 2FA-Tool.com, lai ģenerētu divus secīgus autentifikācijas kodus, kas nepieciešami reģistrācijai, 100% lokāli savā pārlūkprogrammā.

Klienta puses nulles uzticamības aprēķins

Pārbaudiet uzņēmuma TOTP marķierus droši

Ģenerējiet standarta RFC 6238 TOTP verifikācijas kodus uzreiz, izmantojot W3C Web Crypto API. Bez servera izsaukumiem, absolūta atmiņas izolācija, nulle noplūžu.

Palaist 2FA ģeneratoru Izpētīt drošības rokasgrāmatu centru