У межах моделі спільної відповідальності AWS (Shared Responsibility Model), тоді як AWS відповідає за «безпеку самої хмари» (Security OF the Cloud) (фізичні центри обробки даних, апаратні сервери, гіпервізори), клієнт несе повну відповідальність за «безпеку всередині хмари» (Security IN the Cloud) — зокрема управління ідентифікацією, гігієну облікових даних та контроль доступу. Компрометація необмеженого облікового запису AWS Root або привілейованого користувача IAM дозволяє зловмисникам розгортати незаконні інстанси з GPU для криптомайнінгу на тисячі доларів, викрадати конфіденційні озера даних S3 або здійснювати катастрофічне видалення ресурсів із вимаганням викупу.
MFA є обов'язковим для всіх користувачів консолі керування та безапеляційною вимогою для облікового запису AWS Root.
AWS дозволяє реєструвати до 8 окремих токенів FIDO2 та Virtual TOTP на один акаунт, що усуває єдину точку відмови.
Глобальна політика умовного заборонення IAM блокує всі несанкціоновані виклики API до успішної перевірки MFA.
Базові стандарти відповідності в хмарі: CIS Benchmark та регуляторні вимоги
Незалежно від того, проходить ваша інженерна організація атестацію SOC 2 Type II, сертифікацію ISO 27001, валідацію PCI DSS 4.0 чи узгоджує архітектуру зі стовпом безпеки AWS Well-Architected Security Pillar, впровадження 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 Credential Reports |
| Обов'язкове впровадження MFA від AWS | Політика AWS 2024–2026 | Примусово на рівні платформи | Блокування шлюзу входу Root до завершення реєстрації MFA |
Критична необхідність захисту облікового запису AWS Root
У межах облікового запису AWS акаунт Root є всемогутньою сутністю, яка створюється під час відкриття акаунта. На відміну від ролей або користувачів IAM, дії облікового запису Root не можуть бути обмежені політиками на основі ідентичності IAM або політиками Service Control Policies в автономних облікових записах.
Катастрофічний радіус ураження в разі компрометації облікового запису Root:
- Незворотне закриття акаунта: Зловмисники можуть натиснути «Close Account», ініціювавши остаточне знищення всієї інфраструктури.
- Захоплення білінгу та фінансів: Зміна платіжних адрес, заміна корпоративних банківських карток і розгортання сотень спотових інстансів GPU у понад 30 регіонах AWS для нелегального видобутку криптовалюти.
- Руйнування структури AWS Organizations: Видалення підпорядкованих облікових записів із дерева керування, що руйнує весь організаційний моніторинг безпеки та відповідності.
- Модифікація основних контактів безпеки: Зміна адреси електронної пошти та номерів телефонів Root назавжди блокує канали екстреного втручання офіційної служби підтримки AWS.
- Нуль ключів доступу (Access Keys) для Root: Проведіть аудит звітів IAM Credential Reports, щоб переконатися, що ключі доступу для облікового запису Root відсутні. Якщо вони існують — негайно видаліть їх.
- Зберігання пароля за принципом роздільного контролю (Dual-Custody): Згенеруйте випадковий пароль довжиною від 32 символів, розділіть його між CISO (директором з інформаційної безпеки) та юридичним радником компанії й помістіть фрагменти у фізичні вогнетривкі сейфи.
- Резервування кількох пристроїв (до 8 пристроїв): Зареєструйте щонайменше два фізичні апаратні ключі FIDO2 (YubiKey) плюс резервний пристрій Virtual TOTP, збережений у холодному сховищі.
Матриця вибору MFA: Virtual TOTP проти апаратних FIDO2 (YubiKey)
AWS підтримує три основні класи пристроїв MFA. Хмарні архітектори повинні обирати варіант залежно від моделі загроз та рівня адміністративних привілеїв:
Додатки Virtual TOTP
Стандартні токени RFC 6238 (Google Authenticator, 1Password, 2FA-Tool). Швидке підключення, відсутність витрат на закупівлю обладнання. Ідеально підходить для звичайних розробників.
Серія YubiKey 5
Стійка до фішингу криптографія. Прив'язка відкритих ключів до домену (Origin-bound) нейтралізує фішингові атаки зі зворотним проксі. Обов'язково для Root та адміністраторів.
Картки Gemalto / Thales
Автономна картка TOTP із вбудованою батареєю та рідкокристалічним екраном без підключення до мережі. Необхідна для режимних захищених об'єктів (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 має бути систематично заборонено всі дії в 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. Оскільки явне Deny має пріоритет над будь-якими інструкціями 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) для автоматизації отримання токенів:
# 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
Міжакаунтний 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 у кожному акаунті є антипатерном.
Централізована федерація ідентичностей:
Розгорніть 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 приймають проміжні ролі, які згодом приймають вторинні ролі («ланцюжок ролей»), AWS STS видаляє початковий контекст aws:MultiFactorAuthPresent із наступного токена сесії! Щоб забезпечити суворе наскрізне дотримання вимог у міжакаунтних пайплайнах, проєктуйте ланцюжки зміни ролей безпосередньо з автентифікованої сесії IAM Identity Center, уникаючи послідовного ланцюжка з кількох проміжних ролей IAM.
Аварійне відновлення: протокол дій у разі втрати пристрою Root MFA
Що відбувається, якщо всі зареєстровані апаратні токени та віртуальні пристрої Root MFA знищено внаслідок катастрофи?
Офіційна послідовність відновлення поза основним каналом (Out-of-Band):
- Ініціюйте вхід до Root: Введіть адресу електронної пошти облікового запису Root та майстер-пароль на консолі AWS.
- Усунення несправностей MFA: У вікні запиту коду MFA натисніть «Troubleshoot MFA» (Усунення несправностей MFA).
- Верифікація через основну пошту: AWS надсилає посилання для перевірки з обмеженим терміном дії на основну адресу електронної пошти Root. Підтвердьте запит у листі.
- Автоматизований голосовий виклик: Натисніть «Call me now» (Зателефонувати мені зараз). Автоматизована система верифікації AWS зателефонує на зареєстрований основний номер телефону облікового запису та продиктує 6-значний PIN-код підтвердження.
Якщо у вашій організації змінилися номери телефонів або контактна особа звільнилася без оновлення налаштувань акаунта AWS (Account Settings), автоматичне відновлення зазнає невдачі. Ручне відновлення доступу вимагає надання корпоративних нотаріально завірених реєстраційних документів до відділу AWS Trust & Safety, а термін розгляду становить від 3 до 7 робочих днів.
Часті запитання хмарних архітекторів (FAQ)
Чи можна надавати спільний доступ до токенів 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 для генерації двох послідовних кодів автентифікації, необхідних для реєстрації, повністю локально у вашому браузері.
Безпечно тестуйте корпоративні токени TOTP
Генеруйте стандартні перевірочні коди RFC 6238 TOTP миттєво за допомогою W3C Web Crypto API. Жодних запитів до серверів, повна ізоляція в пам'яті браузера, нульовий ризик витоку.