Съгласно Модела на споделена отговорност на AWS (Shared Responsibility Model), докато AWS управлява „сигурността НА облака“ (Security OF the Cloud) – физическите центрове за данни, хардуера на хостовете и хипервайзорите – клиентът носи пълната отговорност за „сигурността В облака“ (Security IN the Cloud), особено управлението на идентичността, хигиената на удостоверенията и контрола на достъпа. Компрометирането на неограничен AWS Root акаунт или привилегирован IAM профил позволява на нападателите да натрупат хиляди долари разходи за незаконно копаене на криптовалути чрез GPU инстанции, да източат данни от частни S3 хранилища или да извършат катастрофално изтриване с цел откуп.
MFA е задължителна за всички потребители с достъп до административната конзола и безапелационно задължителна за AWS Root акаунта.
AWS позволява регистриране на до 8 отделни FIDO2 и виртуални TOTP токена за един акаунт, елиминирайки единичните точки на отказ (SPOF).
Глобална IAM политика с условно отказване (Deny) блокира всички неоторизирани 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 за средата с картодържателски данни (CDE) |
| SOC 2 Type II (Критерии за доверие) | CC6.1 / CC6.2 | Ключов контрол | Независима проверка от сертифициран одитор на IAM отчетите за идентификационни данни |
| Задължително въвеждане на MFA от AWS | Политика на AWS 2024–2026 г. | Платформено налагане | Блокиране на входа в Root профила до завършване на регистрацията на MFA |
Абсолютната необходимост от защита на главния AWS Root акаунт
В границите на един AWS акаунт Root акаунтът представлява всемогъщата идентичност, създадена при първоначалното откриване. За разлика от IAM ролите и потребителите, действията на Root акаунта не могат да бъдат ограничени чрез IAM политики, базирани на идентичност, нито чрез Service Control Policies в самостоятелни акаунти.
Катастрофален мащаб на щетите при компрометиран Root акаунт:
- Необратимо закриване на акаунта: Нападателите могат да кликнат върху „Close Account“, насрочвайки окончателно унищожаване на цялата ви инфраструктура.
- Финансово превземане и злоупотреби с фактурирането: Промяна на платежните банкови карти, пренасочване на фактури и стартиране на стотици GPU Spot инстанции в над 30 региона на AWS за нерегламентиран добив на криптовалути.
- Разрушаване на структурата на AWS Organizations: Премахване на дъщерните акаунти от йерархията на управление, което деактивира централизирания мониторинг за сигурност.
- Промяна на основните контакти за сигурност: Смяната на имейла и телефонния номер на Root акаунта окончателно прекъсва официалните канали за спешна намеса на поддръжката на AWS.
- Нула ключове за достъп (Access Keys) на Root: Одитирайте отчетите за идентификационни данни на IAM (Credential Reports), за да потвърдите, че за Root акаунта не съществуват API ключове за достъп. Ако има такива, ги изтрийте незабавно.
- Съхранение на паролата под споделен контрол (Dual-Custody): Генерирайте случайна парола с дължина над 32 знака, разделете я на две части между директора по информационна сигурност (CISO) и правния съветник и заключете частите в отделни физически огнеупорни сейфове.
- Резервираност с множество устройства (до 8 устройства): Регистрирайте поне два физически FIDO2 хардуерни ключа (YubiKey) плюс резервно офлайн, „студено“ съхранявано виртуално TOTP устройство.
Матрица за избор на MFA: Виртуален TOTP срещу хардуерен FIDO2 (YubiKey)
AWS поддържа три основни класа MFA устройства. Облачните архитекти трябва да изберат подходящия метод спрямо моделите на заплахи и нивата на административни привилегии:
Виртуални TOTP приложения
Стандартни токени по RFC 6238 (Google Authenticator, 1Password, 2FA-Tool). Бързо внедряване без разходи за хардуер. Идеално за редови разработчици.
Серия YubiKey 5
Защитена от фишинг криптография. Публично-ключовите удостоверявания, обвързани с домейна (origin-bound), предотвратяват фишинг атаки чрез обратни проксита. Задължително за 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, и не могат да бъдат компрометирани от мобилен шпионски софтуер.
Физически двоен контрол (Dual-Custody): В протоколите на корпоративните центрове за данни достъпът до Root профила изисква участието на две отделни лица: единият пазител съхранява данните за вход в главния имейл, докато независим служител по сигурността държи физическия ключ за защитения сейф, съдържащ хардуерния токен на Root акаунта. Никоя от страните не може да осъществи достъп до AWS Root акаунта самостоятелно.
Налагане на MFA чрез IAM политики (JSON имплементация)
Базовите нива на сигурност не могат да зависят от доброволните действия на служителите. Облачното управление изисква принудително налагане на ниво политика: на потребителите без активна MFA автентикация трябва систематично да се отказват всякакви действия в конзолата и през API на AWS, с единственото изключение на възможността да регистрират свое собствено 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 (Отказ). Тъй като изричният отказ има приоритет над всички разрешения (Allow), сесиите без валидиран MFA незабавно се блокират за всички AWS API услуги, насочвайки потребителя единствено към екрана за самостоятелна регистрация на устройство.
MFA автентикация за AWS CLI и SDK: Временни токени за сесии чрез STS
Когато IAM политиките налагат използването на MFA, разработчиците, изпълняващи команди като aws s3 ls или стартиращи Terraform код, ще получават грешки AccessDenied. Дългосрочните ключове за достъп нямат възможност за интерактивно въвеждане на еднократен код.
Инженерите трябва да използват 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 "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
Поемане на роли между акаунти (AssumeRole) с MFA ограничения
В корпоративните архитектури с множество акаунти привилегированите инженери обикновено се автентикират в централизиран Identity акаунт и след това преминават към целевите акаунти (Production, Staging) чрез sts:AssumeRole. За да се гарантира, че повишените права в производствената среда не могат да бъдат откраднати чрез изтекли данни, политиката на доверие (Trust Policy) на производствената роля трябва задължително да налага MFA условие:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
Този архитектурен шаблон гарантира, че дори нападател да се сдобие с идентификационни данни в централния Identity акаунт, опитът за поемане на целевата роля без валидиран MFA предизвиква незабавна грешка AccessDenied на самата граница на токена за сигурност.
Одит с CloudTrail и известия в реално време чрез EventBridge
Автоматизираната проверка на съответствието изисква мигновено откриване на всеки случай, в който потребител осъществи достъп до AWS Management Console без мултифакторна автентикация. Чрез прихващане на събития от 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 потребители във всеки индивидуален акаунт е порочна практика (anti-pattern).
Централизирана федерация на идентичността:
Внедрете AWS IAM Identity Center (по-рано AWS SSO) във вашия специализиран управляващ акаунт (Management Account). Федеративната идентичност се свързва с корпоративни IdP доставчици (Okta, Microsoft Entra ID, PingFederate). Наложете корпоративна MFA на нивото на доставчика на идентичност (IdP), като същевременно закачите политики за контрол на услугите (Service Control Policies - SCP) в корена на организацията, за да забраните действия от Root профилите на дъщерните акаунти:
"Condition": { "StringLike": { "aws:PrincipalArn": ["arn:aws:iam::*:root"] } }
Производствена SCP политика: Налагане на MFA ограничения във всички дъщерни акаунти
В големи организации администраторите на индивидуални акаунти могат по невнимание да предоставят прекомерни привилегии. Чрез прикачване на Service Control Policy (SCP) на ниво корен на организацията (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"
}
}
}
]
}
Верижно поемане на роли (Role Chaining) и ограничения за продължителността на STS токените:
Когато IAM идентичности поемат междинни роли, които впоследствие поемат вторични роли („role chaining“), AWS STS премахва първоначалния контекст aws:MultiFactorAuthPresent от последващия токен на сесията! За да поддържате стриктно съответствие от край до край във веригите от множество акаунти, изграждайте графа на поемане на роли директно от първоначално автентикираната сесия в IAM Identity Center, вместо да навързвате последователно множество междинни IAM роли.
Аварийно възстановяване: Протокол при изгубено Root MFA устройство
Какво се случва, ако всички регистрирани хардуерни и виртуални MFA токени на Root акаунта бъдат унищожени при непредвидено бедствие?
Официална последователност за извънбордово (out-of-band) възстановяване:
- Иницииране на вход с Root: Въведете имейл адреса и главната парола на Root акаунта в конзолата на AWS.
- Отстраняване на неизправности с MFA: На екрана за въвеждане на MFA код кликнете върху „Troubleshoot MFA“ (Отстраняване на неизправности с MFA).
- Потвърждение през основния имейл: AWS изпраща ограничена по време връзка за верификация до основния имейл адрес на Root акаунта. Потвърдете връзката.
- Автоматизирано гласово обаждане: Кликнете върху „Call me now“ (Обадете ми се сега). Автоматизираната система за верификация на AWS се обажда на регистрирания основен телефонен номер на акаунта и прочита 6-цифрен PIN код за потвърждение.
Ако вашата организация е променила телефонните си номера или лицето за контакт е напуснало компанията без актуализиране на настройките на акаунта в AWS, автоматизираното възстановяване ще се провали. Ръчното решаване на проблема изисква подаване на официални нотариално заверени фирмени документи пред екипа по доверие и безопасност на AWS (Trust & Safety), като разглеждането отнема между 3 и 7 работни дни.
ЧЗВ за корпоративни облачни архитекти
Могат ли токените за AWS Root MFA да се споделят между членовете на DevOps екипа? ▼
Това е строго забранено. Споделянето на идентификационни данни за Root MFA проваля всички одити за съответствие (SOC 2, ISO 27001). Рутинното администриране трябва да преминава през роли в IAM Identity Center с персонална отчетност. Данните за Root акаунта трябва да останат заключени във физически сейфове под двоен контрол единствено за аварийни ситуации от тип „разбиване на стъклото“ (break-glass).
Как ключът за условия aws:MultiFactorAuthAge подобрява сигурността? ▼
Този ключ следи за актуалността на сесията. Конфигурирането на "NumericLessThan": {"aws:MultiFactorAuthAge": "3600"} изисква MFA токенът да е бил представен през последните 3600 секунди (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. Без сървърни заявки, абсолютна изолация в паметта и нулево изтичане на данни.