Amazon Web Services може да премине от откриване към ограничаване на инцидента за броени секунди, когато ключ за достъп от Identity and Access Management (IAM) се появи в публично хранилище в GitHub.
При контролиран тест за излагане на данни, проведен от Unit 42, AWS прикрепи управляваната си политика AWSCompromisedKeyQuarantineV3 към засегнатия IAM потребител само 10 секунди след като изследователите публикуваха идентификационните данни, което рязко намали прозореца за евентуална злоупотреба.
Дългосрочните IAM ключове за достъп остават привлекателен вектор за първоначален достъп, тъй като могат да осигурят програмен достъп без интерактивно удостоверяване. Разработчиците могат случайно да ги запишат в софтуерния код, конфигурационните файлове или публично достъпните файлове със среди за разработка.
Функцията за сканиране на тайни в GitHub търси разпознаваеми модели на идентификационни данни в публични хранилища и други публични повърхности; чрез интеграцията си с партньори тя съобщава откритите AWS тайни директно на AWS, за да може доставчикът да реагира.
AWS автоматично поставя под карантина разкрити IAM ключове
Според проучване, публикувано от Unit 42, тестът от 19 декември 2025 г. предоставя точна представа за тази автоматизация. Изследователите качиха ключ за достъп и тайна в публично хранилище в 18:50:05 UTC, след като защитата при качване на GitHub (push protection) отправи предупреждение за двете стойности.
В 18:50:15 CloudTrail регистрира събитие AttachUserPolicy, показващо, че AWSCompromisedKeyQuarantineV3 е прикрепена към TestUser.
GitHub изпрати имейл със сигнал една секунда по-късно, AWS Health показа известие „Risk IAM quarantine“ в 18:50:17, AWS изпрати имейл в 18:50:26, а случай за поддръжка (Support case) се появи в 18:50:59.
Един детайл в логовете обаче би могъл да затрудни триажа на инцидента. Полето userIdentity в CloudTrail посочва TestUser като субекта, извършил прикрепянето на политиката, въпреки че потребителят не го е направил, а записът не идентифицира ясно автоматизацията на AWS.
Предупреждението в Health и създаването на случая в Support също не генерираха събитие в CloudTrail по време на теста, което прави записа AttachUserPolicy най-надеждния машиночитаем сигнал.
AWS за първи път въведе политиката AWSCompromisedKeyQuarantine през август 2020 г., последвана от V2 през април 2021 г. и V3 през август 2024 г. Първата версия изрично забраняваше 28 действия в IAM, EC2, Organizations, Lambda и Lightsail.
V2 разшири ограниченията в S3 и в крайна сметка натрупа 61 допълнителни отказани разрешения в 17 услуги, докато по-късните ревизии обърнаха внимание на злоупотреби, свързани с ECS, ECR, Bedrock, SageMaker, STS и други услуги.
Тази еволюция отразява промените в облачните атаки. Ограниченията върху създаването на роли и Lambda възпрепятстват запазването на достъп за копаене на криптовалута, контролите за изтриване в S3 могат да осуетят опити за изнудване с данни, а отказите, свързани с Bedrock, пресичат неоторизираното използване на генеративен изкуствен интелект.
Тъй като изричната забрана (Deny) има предимство пред разрешението (Allow) при оценката на IAM политиките, карантината може да блокира посочените високорискови действия, без да променя съществуващите разрешения на потребителя.
Карантината обаче не е отмяна на права. AWS умишлено блокира само избрани операции, вместо да деактивира ключа или да приложи AWSDenyAll, като по този начин намалява потенциалното прекъсване на легитимни работни процеси.
В резултат на това атакуващият все още може да изпълнява действия, които липсват в списъка със забрани. Администраторите трябва да третират прикрепянето като потвърден инцидент с разкриване на идентификационни данни, да следват случая в AWS Support, да подменят или деактивират ключа и да прегледат активността около изтичането.
Екипите по сигурност трябва да настроят предупреждения за събития IAM AttachUserPolicy, при които requestParameters.policyArn съдържа AWSCompromisedKeyQuarantine, AWSCompromisedKeyQuarantineV2 или AWSCompromisedKeyQuarantineV3.
Те трябва да съпоставят засегнатото потребителско име с предшестващата и последващата активност в CloudTrail, включително заявките GetCallerIdentity, съдържащи автоматизирания потребителски агент за валидиране на GitHub, и да централизират случаите в Support чрез AWS Systems Manager Explorer, за да предотвратят оставането на известията изолирани само при облачните инженери.
От Palo Alto Networks посочват, че Cortex Cloud може да добави контекст за поведението към заплахите в облака, базирани на самоличност, докато Idira PAM поддържа централизирано управление на тайни, достъп точно навреме (just-in-time) и модел без постоянни привилегии (zero standing privileges).
Организациите могат също така да използват Unit 42 Cloud Security Assessment за идентифициране на грешни конфигурации в облака и пропуски в сигурността; те трябва незабавно да ескалират съмненията за компрометиране към екипа за реагиране на инциденти Unit 42 при сложни облачни среди с множество профили.