У тесті, який Unit 42 описала 21 вересня, AWS обмежила використання оприлюдненого ключа доступу за 10 секунд — ще до надходження листа з попередженням. Найважливіше тут — що саме зробив захист: додав політику із забороною окремих дій. Замінити скомпрометовані облікові дані та з’ясувати, як їх використовували, мав власник акаунта.
Експеримент відбувся 19 грудня 2025 року. Новий звіт описує вимірювання роботи наявного механізму, а не запуск нової функції AWS чи підтверджений злам чужої інфраструктури. Для розробників і невеликих команд, чиї системи залежать від довгострокових ключів, різниця суттєва: карантин — це привід почати реагування, а не доказ завершення інциденту.
Попередження було до витоку, а обмеження — до листа
Спочатку захист GitHub від надсилання секретів виявив тестові облікові дані. Дослідники свідомо дозволили публічний коміт. Через 10 секунд після оприлюднення CloudTrail зафіксував додавання AWSCompromisedKeyQuarantineV3. Ще за секунду надійшов лист GitHub, за наступну — сповіщення AWS Health. Звернення до Support з’явилося через 54 секунди після коміту.
Ці інтервали стосуються одного контрольованого тесту. AWS не обіцяє такої швидкості для кожного витоку, особливо поза публічним репозиторієм, який перевіряють. Видалення секрету з коміту теж не дорівнює його відкликанню: отримана раніше копія може залишитися після видалення файлу.
Що саме шукати в журналі
В опублікованому прикладі CloudTrail у полях ідентичності зазначено TestUser, але є й позначки AWS Internal. Саме ім’я користувача не доводить, що він власноруч додав політику карантину.
Корисне поєднання ознак — eventName: AttachUserPolicy, eventSource: iam.amazonaws.com та ARN політики карантину в requestParameters.policyArn. Таке сповіщення разом із повідомленнями AWS Health і Support має отримувати той, хто може розслідувати витік хмарних облікових даних. Лист у скриньці інженерної команди ще не означає, що хтось узяв відповідальність за реагування.
Що змінює карантин
AWS описує цю політику як спосіб обмежити шкоду від шахрайських дій і несанкціоновані витрати, зберігши роботу наявних ресурсів. Вона явно забороняє вибрані операції. Явна заборона має перевагу над дозволом, однак це не суцільне блокування всіх дій в AWS.
У поточній документації AWS типовою вказана версія v3, змінена 16 березня 2026 року — вже після експерименту. Серед обмежень є створення ключів доступу, запуск інстансів EC2, читання об’єктів S3 та виклики моделей Bedrock. Фактичний доступ також залежить від інших політик і дозволів акаунта: відсутність операції в цьому списку не означає автоматичного дозволу. Сама політика також не робить оприлюднений секрет недійсним.
Саме тому карантин відрізняється від заміни облікових даних. Обмеження змінює набір дозволених дій. Відкликання ключа припиняє подальшу автентифікацію за його допомогою. Жодна з цих операцій сама по собі не встановлює, що сталося до локалізації інциденту.
Зберегти обмеження й завершити реагування
Документація політики AWS вказує залишити карантин і виконати інструкції з пов’язаного звернення до Support. Через довірену адміністративну ідентичність замініть оприлюднений ключ у легітимних застосунках, деактивуйте старий, перевірте роботу заміни та видаліть старі облікові дані. Для самої ідентичності на карантині операції керування ключами обмежені.
Перегляньте події CloudTrail, нових користувачів і ключі, незнайомі ресурси та несподівані витрати. Якщо залучені тимчасові облікові дані ролей, окремо опрацюйте їхні сеанси. Послідовність реагування описана в інструкції AWS щодо компрометації акаунта; повідомлення про карантин є початковою зачіпкою, а не підтвердженням безпеки.
Різні секрети потребують різних меж захисту: тест AgentCore показав, як службовий токен можна отримати з пам’яті. Перш ніж замінювати облікові дані, потрібно зрозуміти, звідки вони витекли, щоб новий секрет не повторив шлях старого.
Джерела
- Маргарет Келлі. «From Exposure to Lockdown: How AWS Neutralizes Compromised IAM Credentials through Managed Policies». Unit 42, 21 вересня 2026 року. Дослідження та матеріали тесту.
- Amazon Web Services. «AWSCompromisedKeyQuarantineV3». Довідник керованих політик AWS, змінено 16 березня 2026 року; перевірено 22 вересня 2026 року. Чинна політика та обмеження.
- Amazon Web Services. «What can I do if I notice unauthorized activity in my AWS account?» AWS re:Post, перевірено 22 вересня 2026 року. Реагування на компрометацію акаунта.
