# Предотвращение утечки данных S3 в реальном времени: пошаговое реагирование на инциденты
Инстанс EC2 с скомпрометированными учетными данными извлекает данные из бакета S3, что вызывает оповещение GuardDuty. Чтобы немедленно остановить это, определите скомпрометированную роль IAM, используя идентификатор инстанса. Затем отзовите все активные сессии для этой роли, прикрепив запрещающую политику, которая аннулирует учетные данные, выданные до текущего временного штампа. Эта политика использует условие на основе aws:TokenIssueTime для запрета всех действий для старых учетных данных. Этот процесс эффективен, поскольку запрет проверяется при каждом запросе API, немедленно останавливая извлечение данных. Вы можете проверить отзыв, проверив CloudTrail на наличие событий AccessDenied и подтвердив, что легитимные рабочие нагрузки остаются незатронутыми, протестировав доступ к бакету S3. Крайне важно изолировать скомпрометированный инстанс после отзыва учетных данных, чтобы предотвратить получение злоумышленником новых. Хотя временные учетные данные в конечном итоге истекают, такое ожидание неприемлемо во время активного извлечения данных. Встроенная политика должна быть удалена после того, как команда разработчиков развернет постоянное исправление, чтобы избежать непреднамеренных отказов в доступе в дальнейшем. Этот целенаправленный подход с использованием политики IAM превосходит более широкие меры, такие как изоляция группы безопасности или запрещающие политики для всего бакета, которые могут вызвать более широкие сбои или не устранить первопричину. Рекомендуемая последовательность реагирования на инциденты включает определение роли, отзыв сессий, изоляцию инстанса, а затем проверку действий.
aws:TokenIssueTimeдля запрета всех действий для старых учетных данных. Этот процесс эффективен, поскольку запрет проверяется при каждом запросе API, немедленно останавливая извлечение данных. Вы можете проверить отзыв, проверив CloudTrail на наличие событийAccessDeniedи подтвердив, что легитимные рабочие нагрузки остаются незатронутыми, протестировав доступ к бакету S3. Крайне важно изолировать скомпрометированный инстанс после отзыва учетных данных, чтобы предотвратить получение злоумышленником новых. Хотя временные учетные данные в конечном итоге истекают, такое ожидание неприемлемо во время активного извлечения данных. Встроенная политика должна быть удалена после того, как команда разработчиков развернет постоянное исправление, чтобы избежать непреднамеренных отказов в доступе в дальнейшем. Этот целенаправленный подход с использованием политики IAM превосходит более широкие меры, такие как изоляция группы безопасности или запрещающие политики для всего бакета, которые могут вызвать более широкие сбои или не устранить первопричину. Рекомендуемая последовательность реагирования на инциденты включает определение роли, отзыв сессий, изоляцию инстанса, а затем проверку действий.