У оквиру AWS модела заједничке одговорности, док AWS управља „безбедношћу САМОГ облака“ (Security OF the Cloud — физички дата центри, серверски хардвер, хипервизори), корисник сноси пуну и неподељену одговорност за „безбедност У облаку“ (Security IN the Cloud) — посебно за управљање идентитетима, хигијену акредитива и контролу приступа. Компромитација неограниченог AWS Root налога или привилегованих IAM акредитива омогућава нападачима да покрену хиљаде долара вредне илегалне GPU инстанце за рударење криптовалута, украду податке из приватних S3 резервоара или изврше катастрофална брисања ресурса са циљем изнуде.
MFA је обавезан за све кориснике административне конзоле и представља неоспорни захтев за AWS Root налог.
AWS омогућава регистрацију до 8 различитих FIDO2 и виртуелних TOTP токена по налогу, елиминишући појединачне тачке отказа.
Глобална IAM политика експлицитног одбијања блокира све неовлашћене API позиве док се не потврди активна MFA верификација.
Основне линије усклађености у облаку: CIS Benchmark и регулаторни оквири
Било да се ваша инжењерска организација припрема за SOC 2 Type II сертификацију, ISO 27001 стандард, PCI DSS 4.0 валидацију или се усклађује са безбедносним стубом оквира AWS Well-Architected Framework, имплементација MFA за све IAM идентитете представља фундаментални безбедносни захтев:
| Стандард / Оквир усклађености | Спецификација контроле | Ниво обавезности | Механизам ревизијске провере |
|---|---|---|---|
| CIS AWS Foundations Benchmark v3.0 | 1.5 / 1.6 / 1.10 | Ниво 1 (Обавезно) | Аутоматизована процена преко AWS Security Hub / Prowler алата |
| PCI DSS 4.0 | Захтев 8.4.2 | Обавезно | Ревизија приступа конзоли и API-ју за Cardholder Data Environment (CDE) |
| SOC 2 Type II (Критеријуми поверења) | CC6.1 / CC6.2 | Кључна контрола | Независна ревизорска провера IAM Credential Reports извештаја |
| AWS обавезна примена MFA | AWS смернице 2024–2026 | Платформска примена | Блокирање пријаве на Root налог док се регистрација MFA не заврши |
Апсолутни императив заштите AWS Root налога
Унутар граница AWS налога, Root налог представља свемоћни идентитет створен при креирању самог налога. За разлику од IAM улога или корисника, активности Root налога се у самосталним налозима не могу ограничити IAM политикама заснованим на идентитету нити Service Control политикама.
Катастрофални опсег штете при компромитацији Root налога:
- Неповратно затварање налога: Нападачи могу кликнути на „Close Account“, чиме започињу трајно уништење комплетне инфраструктуре.
- Финансијска отмица и фактурисање: Преусмеравање фактура, замена платних картица компаније и покретање стотина GPU спот инстанци у више од 30 AWS региона за незаконито рударење криптовалута.
- Раскидање структуре сервиса AWS Organizations: Уклањање налога чланица из хијерархије управљања, чиме се урушава праћење усклађености.
- Промена примарних безбедносних контаката: Промена примарне адресе е-поште и броја телефона Root налога трајно прекида канале кроз које званична AWS подршка може да интервенише.
- Нула активних Root Access Keys кључева: Редовно ревидирајте IAM Credential Reports како бисте потврдили да приступни кључеви за Root налог не постоје. Ако постоје, одмах их избришите.
- Чување лозинке уз двоструко старатељство (Dual-Custody): Генеришите насумичну лозинку од 32+ знака, поделите лозинку између директора безбедности (CISO) и правног саветника, и закључајте делове у физичким ватроотпорним сефовима.
- Редундантност са више уређаја (до 8 уређаја): Региструјте најмање два физичка FIDO2 хардверска кључа (YubiKey) плус офлајн виртуелни TOTP уређај као резерву у хладном складишту.
Матрица избора MFA: Виртуелни TOTP наспрам хардверског FIDO2 (YubiKey)
AWS подржава три главне класе MFA уређаја. Архитекте у облаку треба да ускладе избор са моделом претњи и нивоом административних привилегија:
Виртуелне TOTP апликације
Стандардни RFC 6238 токени (Google Authenticator, 1Password, 2FA-Tool). Брзо увођење, без трошкова набавке. Идеално за стандардне програмере.
YubiKey 5 серија
Криптографија отпорна на фишинг. Тврдње о јавном кључу везане за домен порекла спречавају фишинг преко реверзног проксија. Обавезно за Root и администраторе.
Gemalto / Thales картице
Аутономна TOTP картица са сопственим напајањем и LCD екраном, изолована од мреже. Кључна за строго обезбеђене просторије (SCIF) где су паметни телефони и USB уређаји забрањени.
Корпоративни хардверски MFA FIPS 140-2 Level 3 и протоколи сефа са двоструким старатељством:
За велике компаније са листе Fortune 500 и одбрамбене добављаче, безбедност Root налога захтева наменске хардверске токен привеске (нпр. SafeNet/Gemalto IDPrime привеске) сертификоване према FIPS 140-2 Level 3. За разлику од апликација за паметне телефоне, ови физички привесци немају бежичне интерфејсе ни Bluetooth радио, те се не могу пресрести преко мобилног шпијунског софтвера.
Физичко управљање са двоструким старатељством: У протоколима корпоративних дата центара, приступ Root налогу захтева две одвојене особе: један старатељ поседује акредитиве главне е-поште, док независни безбедносни официр чува физички кључ безбедног сефа у коме се налази Root хардверски токен. Ниједна страна не може једнострано приступити AWS Root налогу.
Примена MFA помоћу IAM политика (JSON имплементација)
Безбедносне основе не могу се ослањати на добровољно понашање запослених. Управљање у облаку захтева примену на нивоу политике: корисницима без активне MFA аутентификације морају систематски бити ускраћене све акције у оквиру AWS API-ја и Конзоле, осим могућности да самостално региструју сопствени 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"
}
}
}
]
}
Ставка 4 (Statement 4) евалуира глобални кључ услова "aws:MultiFactorAuthPresent": "false" користећи експлицитно одбијање Deny. С обзиром на то да у AWS моделу ауторизације експлицитно одбијање има приоритет над свим правилима дозволе (Allow), сесије без MFA аутентификације се моментално блокирају на свим AWS API позивима, усмеравајући корисника директно на екран за самосталну регистрацију MFA уређаја.
AWS CLI и SDK MFA аутентификација: STS привремени токени сесије
Када IAM политике захтевају MFA, програмери који покрећу команде попут aws s3 ls или извршавају Terraform кôд добијају грешке типа AccessDenied. Дуготрајни приступни кључеви не могу интерактивно тражити једнократне лозинке (OTP).
Инжењери морају користити AWS STS (Security Token Service) како би заменили дуготрајне кључеве и 6-цифрени TOTP за привремене акредитиве:
Скрипта за аутоматизацију (aws-mfa-session.sh):
Поставите ову помоћну скрипту у своје локално окружење (~/.aws/aws-mfa-session.sh) да бисте аутоматизовали преузимање токена:
# Размена дуготрајних AWS кључева + MFA кода за STS токен сесије
MFA_ARN="arn:aws:iam::123456789012:mfa/alex-dev"
echo -n "Унесите 6-цифрени 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 "✅ Аутентификовано! Привремена сесија је извезена (важи 12 сати)."
else
echo "❌ Аутентификација није успела. Проверите кôд токена или временско одступање сата на уређају."
fi
Међурачунски AssumeRole са MFA ограничењима
У вишерачунским архитектурама предузећа, овлашћени инжењери се обично аутентификују на централизованом идентитетском налогу (Identity account) и пребацују на циљне налоге (Production, Staging) путем sts:AssumeRole. Како би се осигурало да се повишене продукционе дозволе не могу преузети путем процурелих акредитива, политика поверења циљне улоге мора захтевати испуњење MFA услова:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
Овај архитектонски образац гарантује да чак и ако нападач компромитује акредитиве у централном налогу за идентитете, сваки покушај преузимања циљне улоге без успешно завршене MFA верификације моментално изазива грешку AccessDenied на самој граници безбедносног токена.
CloudTrail ревизија и EventBridge обавештења у реалном времену
Аутоматизована провера усклађености захтева моменталну детекцију када било који корисник приступи AWS Management конзоли без вишефакторске аутентификације. Хватањем AWS CloudTrail догађаја и њиховим рутирањем кроз Amazon EventBridge, SecOps тимови постижу узбуњивање у реалном времену:
{
"source": ["aws.signin"],
"detail-type": ["AWS Console Sign In via CloudTrail"],
"detail": {
"eventName": ["ConsoleLogin"],
"additionalEventData": {
"MFAUsed": ["No"]
}
}
}
По пријему догађаја, EventBridge активира Amazon SNS обавештење према дежурном пејџеру Оперативног центра за безбедност (SOC) или покреће AWS Lambda функцију која тренутно поништава активну сесију тог IAM корисника.
Управљање у вишерачунском окружењу: AWS Organizations и IAM Identity Center
У корпоративним окружењима која управљају десетинама или стотинама AWS налога преко тзв. Landing Zones зона, креирање појединачних IAM корисника у сваком налогу представља озбиљан антишаблон.
Централизована федерација идентитета:
Имплементирајте AWS IAM Identity Center (некадашњи AWS SSO) у свом одређеном налогу за управљање (Management Account). Федерализујте идентитете према корпоративним IdP добављачима (Okta, Microsoft Entra ID, PingFederate). Примените корпоративни MFA на IdP нивоу, док на корену организације постављате Service Control политике (SCP) које спречавају акције преко налога чланица:
"Condition": { "StringLike": { "aws:PrincipalArn": ["arn:aws:iam::*:root"] } }
Продукциони SCP: Наметање MFA ограничења на свим налозима чланицама
У великим организацијама, администратори појединачних налога могу нехотице доделити прекомерне привилегије. Повезивањем Service Control политике (SCP) на нивоу корена организације (Organization Root) или организационе јединице (OU), тим за управљање облаком успоставља непроменљиву заштитну ограду: API позиви високог утицаја се безусловно одбијају осим ако нису ауторизовани активном 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"
}
}
}
]
}
Уланчавање улога и временска ограничења трајања STS токена:
Када IAM идентитети преузимају посредничке улоге које потом преузимају секундарне улоге („уланчавање улога“ односно role chaining), AWS STS уклања првобитни контекст aws:MultiFactorAuthPresent из наредног токена сесије! Да бисте одржали строгу усклађеност кроз међурачунске процесе, пројектујте графове преузимања улога директно из аутентификоване сесије IAM Identity Center-а уместо ланчаног преузимања вишеструких посредничких IAM улога.
Опоравак од катастрофа: Протокол у случају губитка Root MFA уређаја
Шта се дешава ако су сви регистровани хардверски токени и виртуелни уређаји за Root MFA уништени у катастрофи?
Званични редослед опоравка ван главног канала (Out-of-Band):
- Започните пријаву на Root налог: Унесите адресу е-поште Root налога и главну лозинку на AWS конзоли.
- Решавање проблема са MFA (Troubleshoot MFA): На екрану са захтевом за MFA, кликните на „Troubleshoot MFA“.
- Верификација преко примарне е-поште: AWS шаље временски ограничен линк за верификацију на примарну адресу е-поште Root налога. Потврдите изазов у примљеној поруци.
- Аутоматизовани телефонски позив: Кликните на „Call me now“. Аутоматизовани AWS систем за верификацију позива регистровани примарни број телефона налога и изговара 6-цифрени потврдни PIN.
Ако је ваша организација променила бројеве телефона или је контакт особа напустила компанију без ажурирања подешавања AWS налога, аутоматизовани опоравак неће успети. Ручно решавање захтева достављање оверених докумената о регистрацији компаније AWS Trust & Safety тиму, при чему преглед траје између 3 и 7 радних дана.
Честа питања архитеката за безбедност у облаку (FAQ)
Могу ли се токени за AWS Root MFA делити унутар DevOps тима? ▼
Строго забрањено. Дељење акредитива за Root MFA нарушава захтеве свих безбедносних ревизија (SOC 2, ISO 27001). Свакодневна администрација мора се одвијати путем улога у IAM Identity Center-у са индивидуалном одговорношћу. Root акредитиви морају остати закључани у физичким сефовима са двоструким старатељством само за ванредне ситуације пробијања стакла (break-glass events).
Како кључ услова aws:MultiFactorAuthAge повећава безбедност? ▼
Овај кључ осигурава свежину сесије. Подешавање "NumericLessThan": {"aws:MultiFactorAuthAge": "3600"} захтева да је MFA токен приложен унутар претходних 3.600 секунди (1 сат). Високоризичне акције (попут брисања RDS кластера) биће блокиране ако је сесија старија од тога, чиме се пружа заштита од отмице дуготрајних сесија.
Могу ли користити 2FA-Tool онлајн генератор за креирање AWS Virtual MFA уређаја? ▼
Да. AWS Virtual MFA стриктно прати спецификације RFC 6238 TOTP (HMAC-SHA1, интервал од 30 секунди, 6 цифара). Можете унети тајни Base32 стринг у 2FA-Tool.com да бисте генерисали два узастопна аутентификациона кода потребна за регистрацију, 100% локално унутар свог веб прегледача.
Безбедно тестирајте пословне TOTP токене
Генеришите стандардне верификационе RFC 6238 TOTP кодове моментално користећи W3C Web Crypto API. Без слања података на сервер, уз потпуну изолацију у меморији и нулто цурење тајни.